sbp2port.sys, IEEE 1394 port driver

device driver

    Sponsored Links

    Next

  • 1. the external USB 2.0 HUB enumeartion
    Hi, The situation: there are two HID USB 1.1 devices connected to the system thru the external USB 2.0 HUB. The external HUB is enumerated as a High-speed device under USB\ROOT_HUB20, proprietary (unsigned) drivers are installed for HID devices, everything is fine and dandy. But sometimes, under unclear circumstances, the external HUB is enumerated as a Full speed device under USB\ROOT_HUB with a message "This device can perform faster if you connect it to a Hi-Speed USB 2.0 port. For a list of available ports click here"; and, as a result, HID devices are re-installed with standard drivers, customers are unhappy What the problem here? Any ideas? TIA Andrew
  • 2. KeSaveFloatingPointState in APC_LEVEL
    Hello! I have a problem: when my system service works in APC_LEVEL, in Windows 2000 only, it faults in the KeSaveFloatingPointState call with General Protection exeption. I have found where it faults in assemler code - on second fxsave instruction. I think, it arise from the instruction's operand have not been aligned on paragraph. Please, tell me, how I can resolve this issue?
  • 3. Runaway driver
    I have a W2K3 server that's running at 50% CPU utilization all the time. When I restart, activity looks normal for a minute then jumps right to 50%. Task Manager shows System as the source of the activity. I'm thinking that it's a runaway device driver or some other kernel object that's busted. I've poked around in Windbg trying to find a way dump the threads in System in a way that would show their activity. I've also looked at !devobj listings but no joy there, either. Is there a way to show the list of drivers in order of their activity? Or some other way of determining the source of high utilization coming from System? Thanks in advance... bill boswell
  • 4. same driver installed as filter driver to more than one class
    Hi, I have a WDM filter driver (say busguard.sys). I installed this driver as upper filter driver to the following classes 1. PCMCIA Adapters 2. IDE ATA/ATAPI controllers Is there any problem in installing same driver as filter to more than one classes. How many times my driver will be loaded to memory. John
  • 5. Does the implement of DispatchPnP routines serialize?
    Dear all: I have checked several DDK's samples and found that they set new PnP state in DispatchPnP without any synchronization, such as KeAcquireSpinLock. for example, win2000DDK\toaster\func, ToasterStartDevice calls SET_NEW_PNP_STATE without KeAcquireSpinLock. 1)So I think that the PnP manager serializes the implement of DispatchPnP routines. However in many other samples, the calls of SET_NEW_PNP_STATE are protected by KeAcquireSpinLock and KeReleaseSpinLock. For example, xpddk\usb\bulkpnp.c I'm confused. 2)I guess that this synchronization implement is just for the synchronization between DispatchPnP and DispatchIoctl. Does anyone give me the correct explains about (1) and (2). Thanks in advance. Regards Zhou

sbp2port.sys, IEEE 1394 port driver

Postby c2hhaw » Sun, 01 Feb 2004 03:36:05 GMT

Hello,

We are chip vender for the IDE/ATA storagebox that is connected to 1394 (Firewire).

Microsoft's generic 1394 port driver(sbp2port.sys) translates SRBs from DISK CLASS driver into SBP-2 commands which are issued to the underlying IEEE 1394 driver stack. So, we are able to read/write/format etc.

My question is, 
1. How can we send the vender specific ATA SMART commands from our management applicaction through the above mentioned driver stack?

2. Is the IEEE 1394 prot driver (sbp2prot.sys) also provides pass through support something similar to ATA_PASS_THROUGH provided by atapi.sys?

Please help, 

Thanks in advance,
Shakeel

Re: sbp2port.sys, IEEE 1394 port driver

Postby David J. Craig » Sun, 01 Feb 2004 04:12:36 GMT

This is a good question.  For USB 2.0 and earlier, the answer is that
the only ones who know if it can be done have source code for those port
drivers.  My suspicion is that 1394 might be the same.  There has been
an attempt with ATA_PASS_THROUGH to permit some commands, but the
support is still inadequate if what I have seen in these newsgroups is
true.  There are some ATA devices, specifically a CompactFlash adapter
that connects to the hard drive cable, that requires vendor commands
that are not multiples of 512 bytes.  I have heard, but not tested since
I don't have access to the hardware anymore, that even the new ATA does
not support this.  Use DOS and ding the ports yourself.





1394 (Firewire).
from DISK CLASS driver into SBP-2 commands which are issued to the
underlying IEEE 1394 driver stack. So, we are able to read/write/format
etc.
management applicaction through the above mentioned driver stack?
through support something similar to ATA_PASS_THROUGH provided by
atapi.sys?



Re: sbp2port.sys, IEEE 1394 port driver

Postby Phil Barila » Sun, 01 Feb 2004 15:48:54 GMT

"David J. Craig" < XXXX@XXXXX.COM > wrote in



If I remember right, you were trying to use the undocumented
IDE_PASS_THROUGH interface, and found a lot of limitations, such as the fact
that it didn't do writes well.  One thing you might not be considering, as
of now, there is only one size of ATA sectors, and that's 512 bytes.  The
whole interface is wrapped around that.  In fact, with the exception of DMA
and Multi-Sector commands, every defined command that returns data has to
return it in integer multiples of 512 bytes, the device is supposed to
interrupt after each sector transferred.  So it's not unreasonable for the
driver to limit the ATA_PASS_THROUGH interface to that size.  If you were
going to do that device yourself, you could work around that issue by moving
two sectors.

That said, you are right, only the port driver writer knows for sure.
However, since the lingua franca of the port drivers is SCSI CDBs, it's
likely that there is some SCSI_PASS_THROUGH interface of some kind.  The
limitations of said interface, if it exists in a given port driver, may
prevent you from doing certain things.  It might give sufficient leeway to
allow you to implement a vendor-unique SCSI command in your hardware that
implements an ATA_PASS_TRHOUGH.

Phil
-- 
Philip D. Barila  Windows DDK MVP
Seagate Technology, LLC
(720) 684-1842
As if I need to say it:  Not speaking for Seagate.
E-mail address is pointed at a domain squatter.  Use reply-to instead.



Re: sbp2port.sys, IEEE 1394 port driver

Postby David J. Craig » Mon, 02 Feb 2004 08:36:02 GMT

ou are correct as to the old IDE_PASS_THROUGH interface being the only
one available at the time, except SCSI_PASS_THROUGH. Yes, I know that
almost all IDE/ATA devices are 512 bytes, but CDs and DVDs are not and
those sectors are not a modulo of 512 either in raw mode or on non-mode1
media. However, there is a major manufacturer of CompactFlash that has
a special sector that is accessed via a vendor unique command as allowed
by the ATAPI spec. It contains 512 + 16 bytes, where the 16 byte part
contain configuration information for the embedded controller in the
media. There is a hardware device that connects to the ATA cable that
permits CompactFlash to be used on that bus. The only way I know of to
access those bytes, read and write, is via DOS where the IDE ports can
be accessed directly. I do not know if that 'feature' of the
CompactFlash media is common to media from other manufacturers, but it
is for that one. The application was for using XP embedded where the OS
boots from the CF. I know a vendor ATA miniport driver could make this
work, but it wasn't possible in a no-reboot environment.

I know you have to know that sooner or later hard drives will have to
have larger physical sectors on the media to increase capacity. The
overhead for 512 byte sectors is rather large and with the current state
of error correcting hardware/firmware in today's drives, this decreases
the total capacity of the 'rust' based media too much. Just as
Microsoft had a special format for 1.44MB floppy media that actually
allowed about 1.8MB to be stored just by increasing the number of
sectors per track. Early floppy drives didn't have the tolerances to
write and read that much data reliably, but the floppy is almost dead as
a useful storage device. If Microsoft had their way, it would be deader
than a doornail, but do seem to tolerate the USB floppy since it fixes
some of the deficiencies - slightly faster, PnP, and media arrival
capability. Too bad that USB is always a slave at the device level so
it takes constant polling to detect the state changes. SCSI's multiple
initiator is so nice - why couldn't 1394 and USB be designed that way?

So, to get to the point, if I can keep to it, as more and more devices
are designed to provide some form of mass storage on these busses
non-mod 512 data transfers should be accommodated. I have a SanDisk
CF/SM dual media reader on USB 1.1 where I cannot access the
SmartMedia's CIS blocks nor the 16 byte redundant data area. Some of
that is due to restrictions designed into the reader's firmware, but
some of those restrictions are probably (possibly) there because of
limitations in the Windows storage stacks. If sectors could be made
64KB in size, what would the capacity of a 160GB hard drive become? The
control and other space surrounding the data is a significant amount of
overhead.

"Phil Barila" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
in
that
port
been
is
adapter
since
does
the fact
considering, as
The
of DMA
to
the
were
moving
it's
The
may
leeway to
that



Re: sbp2port.sys, IEEE 1394 port driver

Postby c2hhaw » Wed, 04 Feb 2004 03:21:09 GMT

David and Philip

Thanks for your inputs. I think we are missing the point here. My question was how can we send ATA SMART commands to a disk connected through firewire (IEEE 1394). The drive shows up in Device manager as disk drive, but as SBP2 1394 device

The driver stack for our device shows up a

----------Partition Manage
            
            |--Disk Class drive
                |---SPB2PORT.SYS ( I am guessing this is IEEE-1394 port driver
                     
                     |    |---
                     |---| IEEE 1394 driver stac
                          |----

I am wondering is there pass through mechanism available for this also

Thanks,
Shak 

Re: sbp2port.sys, IEEE 1394 port driver

Postby Jeff Goldner [MS] » Thu, 05 Feb 2004 02:16:59 GMT

you can't. SBP-2 is a SCSI protocol and uses SCSI CDBs; it allows sending
arbitrary CDBs (with some documented exceptions) using the SCSI passthrough
interface. It does not support IDE_PASS_THROUGH or the newer
ATA_PASS_THROUGH because it doesn't know what an ATA command looks like. The
bridge device (1394->ATA, aka tailgate) does the translations between SCSI
commands and ATA, but unless you have some private CDB defined for the
bridge and some proprietary encapsulation of ATA commands using that private
CDB, there isn't a way to send ATA commands to the underlying device.

SAS (a new serial SCSI protocol) has the notion of SATA tunneling (STP) but
this isn't defined for other interfaces.






was how can we send ATA SMART commands to a disk connected through firewire
(IEEE 1394). The drive shows up in Device manager as disk drive, but as SBP2
1394 device.
driver)



Re: sbp2port.sys, IEEE 1394 port driver

Postby Phil Barila » Thu, 05 Feb 2004 16:13:37 GMT

David J. Craig" < XXXX@XXXXX.COM > wrote in
message news:%23ELZ$ XXXX@XXXXX.COM ...

Where did you see in the ATA spec that you can use ATAPI transfers for ATA
devices, which CFA devices are? ATAPI is, sort of, SCSI over the ATA wires.
CFA is sector-based ATA, with some limitations. Your customer's device was
just non-compliant.


Yes, T13 is talking about that now. I don't know why those bus be the way
they be, ask the folks that designed them. USB was designed to be cheap and
require the host CPU to burn cycles managing it. Not sure what the 1394
design goals were, but evidently it wasn't to provide a complete SCSI
implementation over serial wires.


160 GB? The limitation isn't in the LBA space, it's in the areal density.
Making larger sectors doesn't provide any increase in areal density, it just
reduces the number of LBAs. Do you really want the minimum FS allocation
unit to be 64K? To be fair, an FS could do more work to subdivide the disk
native sector size into smaller units, but who want's the over head of a 64K
RMW to write your 10 byte batch file?

Phil
--
Philip D. Barila Windows DDK MVP
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
E-mail address is pointed at a domain squatter. Use reply-to instead.



Re: sbp2port.sys, IEEE 1394 port driver

Postby David J. Craig » Mon, 09 Feb 2004 06:53:14 GMT

omments inline:

"Phil Barila" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
in
only
that
and
non-mode1
has
allowed
part
that
to
can
it
the OS
this
ATA
wires.
device was
CompactFlash does have some interesting things going on, but there has
to be a way to permit some behaviors to be modified. Some of the
controls available can be used to inhibit or permit certain power
states. The commands are vendor commands and should be allowed to be
non-mod 512 sizes. I think the manufacturer should consider the various
operating systems, but many of these devices were developed for non-PC
environments first. SmartMedia was invented for cameras first and later
on computer usage became common. If I could get the CIS from the
SmartMedia, I can detect the real size of the media.

Microsoft has attempted to force all media to have a CHS where the heads
are always 255 and the sectors per track are 63. This can cause size
information from the DISK GEOMETRY request to be off by up to 8MB. I
discovered a way to get around that problem that will work under 2000
also, but it was a pain. I do have a nice format utility almost
finished that can format SmartMedia correctly as the SSFDC requires.
The primary reason for the special format is that it keeps each cluster
from being spread across multiple physical blocks. If this is not
followed, flash memory will wear out much more quickly as each flash
block can only be erased and written so many times before it fails. The
total number of erase/write cycles is much better than when the first
Intel flash memory devices were invented, but it is still much more
limited compared to the 'rust' in a hard drive.

Just like with Seagate the actual low level details of how each drive is
formatted and what vendor commands exist are not released to all but a
select few. There have been some discussions lately on some of these
newsgroups about how each vendor of USB or 1394 to ATAPI bridge chips
must include special command translations that permit more control than
the simple read, write, verify, etc. normally used if special features
are needed. Cache control, bad block info, etc. are some that come to
mind. Even a more complete inquiry that permits access to all the pages
would be nice, but they are not documented. Try getting the
manufacturer's name and model number of some hard drives in a USB 2.0
external box. Not easy and frequently not possible. I have not
completed the format program because I don't have a 1394 drive available
to check basic functionality.

to
state
decreases
to
dead as
deader
fixes
so
multiple
way?
way
cheap and
1394
devices
of
The
of
density.
it just
allocation
disk
a 64K
What is the total number of bytes available on a 160GB drive including
all servo data that can be reduced by using larger sectors? I think
64KB sectors would have some use, especially in specialized storage
drives. If you use Ghost to backup a standard drive, all the files
created are 2GB in size except for the last one. Also MP3 files are
larger than 64KB as they run about 3 to 7 MB per file. The larger
sector size would not impact the effective storage size of the drive.
Also, if you use FAT32 for large drives less than 32GB the cluster size
is 16KB and larger than 32GB creates 32KB clusters. Doubling the size
would have an impact, but maybe the extra space obtained would still
allow the same amount

Re: sbp2port.sys, IEEE 1394 port driver

Postby Phil Barila » Mon, 09 Feb 2004 14:38:00 GMT

David J. Craig" < XXXX@XXXXX.COM > wrote in
message news:% XXXX@XXXXX.COM ...


It's not about catering to the limitations of any given OS, it's about
conforming to a specification. The ATA spec says that sectors are 512
bytes, and that PIO data transfers are in integer numbers of sectors. If
you read ATA-6 differently, please cite the location of the reference that
suggests otherwise.


No argument here. Except to note that the architectural quirk of the MS
storage stack still being wrapped around CHS has nothing to do with the
legitimacy of a device that doesn't comply with the governing specification.


No kidding, I'm the one who told one of the OPs that (s)he would have to
implement one of those, and then use SPTI to get to the vendor-unique
command.


Yes, the drivers and bridges aren't designed to provide maximum information
or flexibility for managing ATA disks, they are designed to provide the
minimum function and information necessary to store and retrieve user
information as inexpensively as possible.



The amount of platter used by the servo is a function of the spindle speed
and the TPI(tracks per inch). The native sector size has no impact on the
servo overhead.


I've never ghosted to a network drive, so I don't know if Ghost produces 2
GB file segments because it has an assumption of FAT built into it, or if
the 2 GB file sizes I've seen is a consequence of the fact that it doesn't
ship with an NTFS DOS driver, so I'm ghosting to a file on a FAT32 volume.
Since the largest filesize FAT32 supports is 2GB, the largest ghost image
file will be 2 GB, as well.

Larger sectors don't buy you much in reduced overhead. They buy you better
ECC, but at the cost of more metadata, so the net capacity gain is
negligible. The reliability and data integrity gain is measurably
significant.


You argued above that you didn't want to tie yourself to a particular OS.
Now you want to tie yourself to the quirks of a particularly inefficient FS
implementation?


Fixed disks haven't been encoded that way for a very long time. There is
some per-sector info, but it's mostly ECC.

Phil
--
Philip D. Barila Windows DDK MVP
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
E-mail address is pointed at a domain squatter. Use reply-to instead.



Re: sbp2port.sys, IEEE 1394 port driver

Postby Maxim S. Shatskih » Tue, 10 Feb 2004 01:21:11 GMT

> Since the largest filesize FAT32 supports is 2GB

4GB. About 20 minutes of DV video.

-- 
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
 XXXX@XXXXX.COM 
 http://www.**--****.com/ 



Re: sbp2port.sys, IEEE 1394 port driver

Postby David J. Craig » Tue, 10 Feb 2004 01:47:40 GMT

You are correct in some ways.  If you are using Windows, then 4GB will
work.  If you are using DOS, which Ghost does, you are pretty much
limited to 2GB because the 'set file position' command takes a 32-bit
offset that is signed.  Therefore, the seekable limit is 2GB and the
MS-DOS Programmer's Reference says that the limit is 2GB because DOS
only uses 31-bits for the file size.








Similar Threads:

1.1394, 61883 and sbp2port.sys

Hi,

Problem Description:
I am writing two C++ user mode applications using Visual C++. This
application should use FCP (Function Control Protocol IEC 61883-1 General)
of 61883 for request and response queries. The application should use SBP2
to transmit bulk data. 
As i found from message groups and microsoft website, there is no user mode
API available for the applications to use them to interact with 61883.sys
and sbp2port.sys.
The application will send and receive data using the 1394 layer. Two Windows
XP machines with 1394a cards and 6 pin to 6 pin connection. 
As there is a 1394 api layer to communicate from the usermode, i would like
to know how to get my application talk to FCP driver and SBP2Port driver
from user mode.

My solution to this problem:
By tying the 61883.h to 1394 API 
When i tried to bind 61883.h with the 1394 API, windows xp crashed.
I didnt find any links to use sbp2port.sys and i didnt find any particular
header file to see the various command sets for use.
Only thing that worked for me is using windows sockets to communicate over
1394, but i dont want to use TCP/IP. I want to use 61883 and sbp2port on
1394 from a user mode application. 

2.VIA OHCI Compliant IEEE 1394 Host Controller

3.OHCI on IEEE 1394

Hello,

We are developing a standalone device that communicates 
via 1394 with a PC. The device has OHCI compatible 1394 
device. I installed 1394 board in the PC and windows 
2000/XP found it. The ohci1394 driver is attached to it.
Could you tell how I can find out what are interfaces of 
ohci1394 driver and how I can communicate with it in C/C++ 
from user mode?

4.IEEE 1394 sound card driver: where to start?

Dear experts!

I am trying to figure out what precisely needs to be done to make an IEEE
1394 device appear as a sound card to audio applications. This device is a
new piece of hardware, which uses IEC61883-6 protocol for streaming audio
and AV/C Audio Subunit for connection management and controlling. Please
bear with me as I am not really a software designer although I have some
experience with debugging and modifying NT kernel drivers. I am now trying
to go through a huge pile of documentation on the MSDN site, but I have a
feeling that this will take forever unless someone could guide me.

Also, is there a difference between Windows XP home and pro editions for the
purpose of IEEE 1394 driver development?


Thanks,
/Mikhail


5.PC 2 PC Comm over IEEE 1394 (not TCP/IP)

Hi,

I'm trying to find information about how I can communicate isochronously 
between two PC's over IEEE 1394 without using the built-in TCP/IP stack.  
Basically, I want to write a driver or app that can automatically detect 
another PC with my app/driver, and allow for the PC's to send and receive 
real-time data that I specify.  The intent is to allow one PC to stream audio 
to another PC for output on a remote PC in real-time.  This way, I can have a 
remote PC playing a CD or MP3 file and have it redirected to another PC.  
Sure, I could use remote desktop, but I don't need the desktop visible 
either.  And I don't want to use TCP/IP because I want real-time capability.

Anyone know how this can be done, or if there's sample code available?

Thanks.

6. ieee-1394 driver

7. belkin ieee 1394 card listed as "device cannot start"

8. controller host bus IEEE 1394



Return to device driver

 

Who is online

Users browsing this forum: No registered users and 34 guest