B
Bruce Palmer
I'm trying to develop a virtual 1394 emulation driver. Certain makes of
DVD recorders will only accept input over Firewire from a DV camcorder,
and I want to make a Windows XP Pro SP2 box with Firewire ports look
like a camcorder as far as the DVDR goes so it will accept an
isochronous stream of DV video.
I progressed to the point where I could add/remove a Unit Directory
to/from the PC host Configuration ROM using an IEEE1394_API_REQUEST with
IEEE1394_API_ADD_VIRTUAL_DEVICE and IEEE1394_API_REMOVE_VIRTUAL_DEVICE
after having successfully created a V1394 device in conjunction with my
driver.
To verify that the Unit Directory was being added and removed properly I
use the demo version of Pionsys Devolyzer. Pionsys is a company that
apparently was working on 1394 Windows code a few years ago. Their demo
software is still available from their website and runs for 20 minutes
before timing out. That's plenty long enough for my testing requirements.
I found that after a Unit Directory was added to the host Config ROM and
then later removed, it could not be added back again. The Pionsys
software showed that the contents of the Config ROM was invalid from the
moment I attempted to add the Unit Directory a second time. Getting it
back into a valid state required disabling and then re-enabling the OHCI
Compliant IEEE 1394 Host Controller with Device Manager (or rebooting).
I saw a few posts on this newsgroup from 2003 where others had a similar
problem and there was apparently never any followup or resolution. Then
I discovered Microsoft KB887170 which addresses a similar-sounding
problem, so I applied the hotfix for it and it updated the 1394bus.sys
driver. File version shows 5.1.2600.2532 as per
http://support.microsoft.com/kb/887170
The problem I've described persists even with the hotfix applied. I
decided to fire up my kernel debugger and do some tracing inside
1394bus.sys. I found at least 1 and possibly 2 bugs, which, from what I
understand after having read some of the archives of this newsgroup, is
not too surprising.
I developed a workaround wherein I take the hCromData handle member of
the SET_LOCAL_HOST_PROPS3 structure and manipulate the contents of the
undocumented structure it points to. I do this in my driver code after
removing the Unit Directory from the Config ROM. I don't actually
manipulate the contents of *that* structure, but one linked to it via a
LIST_ENTRY (Flink and Blink) member of the same undocumented structure.
There is a list of these structures maintained by the system for added
Unit Directories. When a new Unit Directory is added, the existing
structures each have a pointer that is updated to point to their data
(1394 quads) in the Config ROM. When a Unit Directory is added, those
pointers are updated accordingly. When a Unit Directory is removed,
they are not. At this point the Config ROM itself is still valid. It
is upon subsequent attempts to add another new Unit Directory that
things go wrong, because the system is now using bad information about
where things are located in the ROM.
I can live with my workaround. Very little seems to have ever been done
with regards to virtual 1394 emulation drivers. There are dribs and
drabs of information around the net, the best of which are Bill
McKenzie's three articles at wd-3.com. Therefore I am not too worried
that my fooling around inside an undocumented structure will cause any
unwanted side effects. If any serious work had been done in this area
then I would certainly not be the first person to find this bug inside
of 1394bus.sys.
There also appears to be another bug that does not affect me directly,
but it should still be fixed. At one point a number of bytes needs to
be memmove'd and to get that number, a number of *quads* is added to
another number of bytes. A quad is 4 bytes, not 1, and the wrong number
of bytes gets moved. Luckily this isn't fatal to the driver or the
system because the first number is wrong, too, and an excessive number
of bytes is moved even without the proper quad-to-bytes calculation.
So here are my questions...
What is the best way to let MS know about this bug? I think calling
1-800-MICROSOFT, as suggested by
http://support.microsoft.com/gp/contactbug is probably not the best way
to handle it. I also don't want to open up any sort of support incident
that I would have to pay for. I would be more than happy to supply my
supporting documentation of this problem, although without access to the
source code even my best guess as to what's happening - based on my
reading of a disassembly listing - might sound unfamiliar to the
developers. Indeed, my understanding of the problem may be incorrect.
I do know for a fact, however, that there are bugs in 1394bus.sys's
Bus1394RemoveCROMData() routine.
My second question is, what are the odds MS would be interested in
fixing it at all? MS in general seems to be deprecating Firewire. I
notice they decided not to support 1394b in Vista, despite assertions to
the contrary in the past. The whole Apple Firewire vs. Intel USB debate
thing, which is OT for this newsgroup but it does make me wonder
sometimes. I also notice they are doing away with NIC1394 network
support as per a recent announcement. On the other hand, the hotfix for
KB887170 is relatively recent so perhaps there's hope for getting this
fixed on XP, even in the face of a headlong rush to Vista.
Any comments or suggestions would be appreciated. Thanks.
BP
DVD recorders will only accept input over Firewire from a DV camcorder,
and I want to make a Windows XP Pro SP2 box with Firewire ports look
like a camcorder as far as the DVDR goes so it will accept an
isochronous stream of DV video.
I progressed to the point where I could add/remove a Unit Directory
to/from the PC host Configuration ROM using an IEEE1394_API_REQUEST with
IEEE1394_API_ADD_VIRTUAL_DEVICE and IEEE1394_API_REMOVE_VIRTUAL_DEVICE
after having successfully created a V1394 device in conjunction with my
driver.
To verify that the Unit Directory was being added and removed properly I
use the demo version of Pionsys Devolyzer. Pionsys is a company that
apparently was working on 1394 Windows code a few years ago. Their demo
software is still available from their website and runs for 20 minutes
before timing out. That's plenty long enough for my testing requirements.
I found that after a Unit Directory was added to the host Config ROM and
then later removed, it could not be added back again. The Pionsys
software showed that the contents of the Config ROM was invalid from the
moment I attempted to add the Unit Directory a second time. Getting it
back into a valid state required disabling and then re-enabling the OHCI
Compliant IEEE 1394 Host Controller with Device Manager (or rebooting).
I saw a few posts on this newsgroup from 2003 where others had a similar
problem and there was apparently never any followup or resolution. Then
I discovered Microsoft KB887170 which addresses a similar-sounding
problem, so I applied the hotfix for it and it updated the 1394bus.sys
driver. File version shows 5.1.2600.2532 as per
http://support.microsoft.com/kb/887170
The problem I've described persists even with the hotfix applied. I
decided to fire up my kernel debugger and do some tracing inside
1394bus.sys. I found at least 1 and possibly 2 bugs, which, from what I
understand after having read some of the archives of this newsgroup, is
not too surprising.
I developed a workaround wherein I take the hCromData handle member of
the SET_LOCAL_HOST_PROPS3 structure and manipulate the contents of the
undocumented structure it points to. I do this in my driver code after
removing the Unit Directory from the Config ROM. I don't actually
manipulate the contents of *that* structure, but one linked to it via a
LIST_ENTRY (Flink and Blink) member of the same undocumented structure.
There is a list of these structures maintained by the system for added
Unit Directories. When a new Unit Directory is added, the existing
structures each have a pointer that is updated to point to their data
(1394 quads) in the Config ROM. When a Unit Directory is added, those
pointers are updated accordingly. When a Unit Directory is removed,
they are not. At this point the Config ROM itself is still valid. It
is upon subsequent attempts to add another new Unit Directory that
things go wrong, because the system is now using bad information about
where things are located in the ROM.
I can live with my workaround. Very little seems to have ever been done
with regards to virtual 1394 emulation drivers. There are dribs and
drabs of information around the net, the best of which are Bill
McKenzie's three articles at wd-3.com. Therefore I am not too worried
that my fooling around inside an undocumented structure will cause any
unwanted side effects. If any serious work had been done in this area
then I would certainly not be the first person to find this bug inside
of 1394bus.sys.
There also appears to be another bug that does not affect me directly,
but it should still be fixed. At one point a number of bytes needs to
be memmove'd and to get that number, a number of *quads* is added to
another number of bytes. A quad is 4 bytes, not 1, and the wrong number
of bytes gets moved. Luckily this isn't fatal to the driver or the
system because the first number is wrong, too, and an excessive number
of bytes is moved even without the proper quad-to-bytes calculation.
So here are my questions...
What is the best way to let MS know about this bug? I think calling
1-800-MICROSOFT, as suggested by
http://support.microsoft.com/gp/contactbug is probably not the best way
to handle it. I also don't want to open up any sort of support incident
that I would have to pay for. I would be more than happy to supply my
supporting documentation of this problem, although without access to the
source code even my best guess as to what's happening - based on my
reading of a disassembly listing - might sound unfamiliar to the
developers. Indeed, my understanding of the problem may be incorrect.
I do know for a fact, however, that there are bugs in 1394bus.sys's
Bus1394RemoveCROMData() routine.
My second question is, what are the odds MS would be interested in
fixing it at all? MS in general seems to be deprecating Firewire. I
notice they decided not to support 1394b in Vista, despite assertions to
the contrary in the past. The whole Apple Firewire vs. Intel USB debate
thing, which is OT for this newsgroup but it does make me wonder
sometimes. I also notice they are doing away with NIC1394 network
support as per a recent announcement. On the other hand, the hotfix for
KB887170 is relatively recent so perhaps there's hope for getting this
fixed on XP, even in the face of a headlong rush to Vista.
Any comments or suggestions would be appreciated. Thanks.
BP