sbp2port.sys, IEEE 1394 port driver

device driver

    Sponsored Links


  • 1. Printer driver document events
    Hi I am developing a virtual printer driver starting from the MSPLOT DDK sample. What I need to do is: - when the printing starts, show a dialog box so the user can choose a file name - render the print job to the selected file - when the print job is finished, open the generated file and show the result to the user I show the first dialog box in the DrvDocumentEvent, STARTDOCPOST event, and I pass the file name to the renderer dll in the JOB_INFO_2 structure. That works fine, I can read the job information in the renderer dll and generate the printing file. The problem is that when the job is finished, how can I open the generated file from the context of the user that started the print job? The logic option would be DrvDocumentEvent, ENDDOC or ENDDOCPOST events, but these events don't come at all (the spool is enabled). And even if they would come, they do not have a parameter for the job id, so I cannot retrieve the file name. Where should I implement this tasks on the end print job? Thanks, Luminita
  • 2. DrvQueryFontTree fails with Splwow64.exe
    OS: Windows XP Professional x64 Version 2003 Service Pack 1 DDK: Windows DDK 3790.1830 Case: Printing from a 32-bit application DrvQueryFontTree returns a pointer to an FD_GLLYPHSET structure. After that ntdll.dll fails. Following is the call stack information: tdll.dll!RtlCopyMemory () + 0xb0 bytes When the application that prints is a 64-bit application, there is no failure even though the content of D_GLLYPHSETstructure seems to be identical with the one from printing from 32-bit application.
  • 3. PreAcquireForSectionSynchronization call back - open file for read
    I am in the context of the PreAcquireForSectionSynchronization call back and would like to open the file that is being referred to by the Data->FileObject->Filename for READ access, read the data, and then close it before this call is allowed to proceed. I have enclosed a copy of the "open " that I've been using with most everything else when I need to read a file, but it does not work here! STATUS_SHARING_VIOLATION is returned, IO_STATUS_BLOCK has Information = 35 Pointer = 35 Information =35 Can you advise me about a strategy that will work. PS. I have gone through "The NT Insider:Finding File Contents in Memory" article from OSR. It does not cover all cases and is only about 80% complete, furthermore, it does not deal with files larger that 256K, . The articles references structures that have no IFS kit documentation. InitializeObjectAttributes(&ObjAttrs,InFile,OBJ_KERNEL_HANDLE|OBJ_CASE_INSEN SITIVE,NULL,NULL); // Status = ZwCreateFile(&FileHandle,GENERIC_READ|FILE_READ_ATTRIBUTES|FILE_READ_DATA, &ObjAttrs,&StatusBlock,0, //allocation size FILE_ATTRIBUTE_NORMAL, FILE_SHARE_READ|FILE_SHARE_DELETE, //share access FILE_OPEN, // disposition FILE_NON_DIRECTORY_FILE|FILE_SYNCHRONOUS_IO_NONALERT, // CreateOptions, 0, // EaBuffer OPTIONAL, 0 ); // EaLength } -- Gak - Finecats
  • 4. Satisfying the Found New Hardware wizard
    Hello, I am working on the driver for a USB printer. Unfortunately the driver is not certified, and I fear this is part of the problem. The problem is that every time a user plugs in the printer, or reboots the PC, etc., the Found New Hardware wizard comes up. Sometimes, going the Found New Hardware wizard will make everything right. Sometimes, the user ends up with the wizard coming up constantly no matter what. I have a postinstall DLL that does some other functions. Is it possible to do something there to help sort this out? I have tried using SetupOEMCopyInf() but that did not help. I'm not sure if I messed up the call or if that's the wrong function to use. I have SetupAPI logging turned on, but I'm not sure what to look for. When I plug in the printer, I see some stuff about driver ranks, but nothing I do seems to change them. -- Matt Kane XXXX@XXXXX.COM

sbp2port.sys, IEEE 1394 port driver

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


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,

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
management applicaction through the above mentioned driver stack?
through support something similar to ATA_PASS_THROUGH provided by

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.

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

"Phil Barila" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
the fact
considering, as
of DMA
leeway to

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


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.

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?

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 ...
the OS
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.

dead as
cheap and
it just
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

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

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

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

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

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


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


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?


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


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?


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 15 guest