Re[2]: 1394 bus reset and XP-SP2

NTDEV
1

> There can be bus resets at any given time (for example think of a

firewire disk that is powered up). Are you shure that this will not
happen in your app?
As far as I know there might be also a reset storm from time to time.
How do you handle that case?
Uwe

Multiple bus resets (even reset storms are not a problem). Once the
resets settle down communication will get back to normal and will sort
itself out. The application will, of course, experience a moment of
unavoidable disruption in such a case but will then proceed normally.

Following a reset (or reset storm) the driver will detect if the PC is
not the root node and if necessary reset the bus once more with the
force root bit set. This is currently a requirement as Windows has
abdicated the roll of ensuring that the root node is cycle master
capable (a non-optional requirement for any node claiming to be IRM
capable).

In XP-SP2 bus resets always come in pairs. For example, submitting a
REQUEST_BUS_RESET IRB to the bus driver will result in 2 bus resets
rather than 1. If the IRB is submitted with the
BUS_RESET_FLAGS_FORCE_ROOT flag the first reset will result, as
expected in the host PC becoming root. However, the second reset which
immediately follows the first will nullify this result. In some bus
configurations it now becomes impossible to ever force the PC to be
the root node.

Ironically, it is easy to guarantee that my device becomes root since
I can send it a PhyConfigurationPacket (REQUEST_SEND_PHY_CONFIG_PACKET
IRB) following each bus reset setting its force root bit ready for the
next bus reset (whenever it occurs). This option
is not available, however, for the local node where the only API
provided (as far as I know) to set the force root bit is in the
REQUEST_BUS_RESET itself.

I can see that the long term solution to this problem is to add more
capability to my device so that the requirement to have the host PC be
root can be relaxed. This, however, involves a firmware update and is
a fairly major undertaking that will take some time.

In the short term, I have determined that if the NIC1394 virtual
device is gone the double reset
behavior also goes. Strangely enough, just disabled it does not help.
I haven’t yet
tried issuing an IOCTL_IEEE1394_API_REQUEST on the bus driver to make
the NIC1394 device go away so I don’t know if that will work (Some OS
component could be monitoring and re-add the device). Besides, I would
prefer an nice, friendly, documented way over a nasty hack. In our
case, our device is always used in a carefully setup installation with
a dedicated PC and I have no problem with the idea of making the
turning off of 1394 networking one of the setup steps if I have to.

Robert Newton
VX Technologies

2

Robert Newton wrote:

>There can be bus resets at any given time (for example think of a
>firewire disk that is powered up). Are you shure that this will not
>happen in your app?
>As far as I know there might be also a reset storm from time to time.
>How do you handle that case?
>Uwe
>
>

Multiple bus resets (even reset storms are not a problem). Once the
resets settle down communication will get back to normal and will sort
itself out. The application will, of course, experience a moment of
unavoidable disruption in such a case but will then proceed normally.

Following a reset (or reset storm) the driver will detect if the PC is
not the root node and if necessary reset the bus once more with the
force root bit set. This is currently a requirement as Windows has
abdicated the roll of ensuring that the root node is cycle master
capable (a non-optional requirement for any node claiming to be IRM
capable).

In XP-SP2 bus resets always come in pairs. For example, submitting a
REQUEST_BUS_RESET IRB to the bus driver will result in 2 bus resets
rather than 1. If the IRB is submitted with the
BUS_RESET_FLAGS_FORCE_ROOT flag the first reset will result, as
expected in the host PC becoming root. However, the second reset which
immediately follows the first will nullify this result. In some bus
configurations it now becomes impossible to ever force the PC to be
the root node.

Ironically, it is easy to guarantee that my device becomes root since
I can send it a PhyConfigurationPacket (REQUEST_SEND_PHY_CONFIG_PACKET
IRB) following each bus reset setting its force root bit ready for the
next bus reset (whenever it occurs). This option
is not available, however, for the local node where the only API
provided (as far as I know) to set the force root bit is in the
REQUEST_BUS_RESET itself.

I can see that the long term solution to this problem is to add more
capability to my device so that the requirement to have the host PC be
root can be relaxed. This, however, involves a firmware update and is
a fairly major undertaking that will take some time.

If your are talking here about the IRM (Channel and Bandwidth
management) I think you may be wrong.
I checkt out a video camcorder from JVC. It’s IRM capable, but XPSP2
doesn’t care about it.
My firewire device sended channel and bandwidth information to the
camcorder, because it’s the only
device on the bus which sets the contender bit. But windows simply
ignored these informations.
Of course your situation is a little bit different. You recommended your
device to be root and busmanager at the same time.
But I personally think it’s not worth trying. You may be disapointed
afterwards.

In the short term, I have determined that if the NIC1394 virtual
device is gone the double reset
behavior also goes. Strangely enough, just disabled it does not help.
I haven’t yet
tried issuing an IOCTL_IEEE1394_API_REQUEST on the bus driver to make
the NIC1394 device go away so I don’t know if that will work (Some OS
component could be monitoring and re-add the device). Besides, I would
prefer an nice, friendly, documented way over a nasty hack. In our
case, our device is always used in a carefully setup installation with
a dedicated PC and I have no problem with the idea of making the
turning off of 1394 networking one of the setup steps if I have to.

Robert Newton
VX Technologies

Sorry, but I don’t know how to get rid of the second bus reset.
Uwe

3

This bus driver just gets better and better.

It would really be nice if someone from the Microsoft 1394 team coming on
here and clarifying some of these issues, and perhaps give us an idea of
where this bus driver architecture is headed. There was some noise a while
back about a rewrite of this bus driver, but that was a while back, is this
still planned? How about a fix of all the bugs people keep reporting here?
Or at least a clarification. Microsoft is the only party that can provide
this.

The higher speed 1394b is starting to catch on, and it would be nice to know
if Windows will become a platform worthy of running these devices out of the
box, or whether a third party bus driver should be purchased.

–
Bill McKenzie
Software Engineer - Prism 802.11 Wireless Solutions
Conexant Systems, Inc.

“Robert Newton” wrote in message
news:xxxxx@ntdev…
> Okay, I’ve confirmed that XP-SP2 always produces 1394 bus resets in
> pairs (preventing me from forcing the PC to be root) and that this
> behavior has
> nothing to do with my device or driver (not
> attached/loaded during the test). I’m fairly confident that the 1394
> networking stuff is doing it. If anyone knows the correct way to
> uninstall 1394 networking permanently (i.e. past the next bus reset)
> please let me know. Disabling the 1394nic in
> device manager does not do the job.
>
> Thanks,
> Robert Newton
> VX Technologies
>
>
>

4

> If your are talking here about the IRM (Channel and Bandwidth

management) I think you may be wrong.
I checkt out a video camcorder from JVC. It’s IRM capable, but XPSP2
doesn’t care about it.
My firewire device sended channel and bandwidth information to the
camcorder, because it’s the only
device on the bus which sets the contender bit. But windows simply
ignored these informations.
Of course your situation is a little bit different. You recommended your
device to be root and busmanager at the same time.
But I personally think it’s not worth trying. You may be disapointed
afterwards.

Thanks for your reply. Ideally i should make my device IRM capable but
as you mention, with XP-SP2, it probably won’t really do any good. A
simpler task is simply to make my node cycle master capable so that
isochronous communication can proceed properly if my device is root. I
can then take over the job of IRM in my driver and force a root that
is cycle master capable. That is the real reason I currently try to
make force the host PC to be root.

Note, I have no real problem in situations where I have only a single
device connected directly to the computer. This problem is critical,
however, in cases where I am controlling multiple instances of my
device on a bus with repeaters and hubs etc. In this configuration I
can currently get isochronous communication from all of my devices
only if the PC is root.

Unfortunately, solving the double reset problem is not really a
firewire issue. It is a 1394 networking issue (I’ve verified this).
I’ll do some work to figure out how to turn it off cleanly.

Robert Newton