1394 devices: Bus reset while processing SRB_INITIALIZE_DEVICE !

Hello list!

I am still working on the issue that my drivers fail to communicate with
a IEEE1394 ( firewire ) device on device initialization.

This is what I see:

The driver gets an SRB_INITIALIZE_DEVICE request. While this happens,
another bus reset is happening on the IEEE-1394 bus which changes the
generation count.

Now the driver tries to access the device to initalize the drivers
structures and the device state BUT every register access fails due to
"STATUS_INVALID_GENERATION".

According to MSDN, the driver should now request the current generation
count using the REQUEST_GET_GENERATION_COUNT bus request BUT it should
not use this generation count unless the next Bus Reset Notification is
recevied by the driver. And in fact, it is not possible to do a single
register access while processing the SRB_INITIALIZE_DEVICE request from
now on.


So what am I supposed to do in this situation?

If I fail the SRB_INITIALIZE_DEVICE request with STATUS_IO_DEVICE_ERROR,
the driver gets unloaded for the device and is not accessible at all.

If I succeed the SRB_INITIALIZE_DEVICE in the hope that I get the Bus
Reset Notification afterwards to update the generation count and finish
the initialization in SRB_INITIALIZATION_COMPLETE also does not work
because SRB_INITIALIZATION_COMPLETE is called first and the Bus Reset
Notification is called later on.


Worst of all, this behaviour is completely reproducable on my system
since I installed the Service Pack 2 for windows XP! If I uninstall the
service pack, I do not get multiple bus resets when connecting the
device ( at least I do not get a bus reset while processing
SRB_INITIALIZE_DEVICE ) anymore and everything works fine.

I am completely stuck. I fear, this one is going to cause BIG TROUBLE!!!


-Arne

Philip
Thu Aug 19 07:31:41 CDT 2004

"Arne Caspari" <arne_caspari@nospam> wrote in message
news:%230q9KEchEHA.3076@tk2msftngp13.phx.gbl...
> Hello list!
>
> I am still working on the issue that my drivers fail to communicate with
> a IEEE1394 ( firewire ) device on device initialization.
>
> This is what I see:
>
> The driver gets an SRB_INITIALIZE_DEVICE request. While this happens,
> another bus reset is happening on the IEEE-1394 bus which changes the
> generation count.
>
> Now the driver tries to access the device to initalize the drivers
> structures and the device state BUT every register access fails due to
> "STATUS_INVALID_GENERATION".
>
> According to MSDN, the driver should now request the current generation
> count using the REQUEST_GET_GENERATION_COUNT bus request BUT it should
> not use this generation count unless the next Bus Reset Notification is
> recevied by the driver. And in fact, it is not possible to do a single
> register access while processing the SRB_INITIALIZE_DEVICE request from
> now on.
>
>
> So what am I supposed to do in this situation?
>
> If I fail the SRB_INITIALIZE_DEVICE request with STATUS_IO_DEVICE_ERROR,
> the driver gets unloaded for the device and is not accessible at all.
>
> If I succeed the SRB_INITIALIZE_DEVICE in the hope that I get the Bus
> Reset Notification afterwards to update the generation count and finish
> the initialization in SRB_INITIALIZATION_COMPLETE also does not work
> because SRB_INITIALIZATION_COMPLETE is called first and the Bus Reset
> Notification is called later on.
>
>
> Worst of all, this behaviour is completely reproducable on my system
> since I installed the Service Pack 2 for windows XP! If I uninstall the
> service pack, I do not get multiple bus resets when connecting the
> device ( at least I do not get a bus reset while processing
> SRB_INITIALIZE_DEVICE ) anymore and everything works fine.
>
> I am completely stuck. I fear, this one is going to cause BIG TROUBLE!!!
>
>
> -Arne

Somewhat off topic, I hope your device is IRM capable if you plan on using
isochronous I/O on WinXP SP2. MS removed IRM capability from its host
controller driver in SP2 (but not SP2 RC2!!). If no one on the network is
the IRM, then no one will be able to allocate channels and bandwidth.

Back to your question, I have always used the new retrieved generation
count the moment I retrieve it after I got a STATUS_INVALID_GENERATION. If
my device has departed, then I will be apprised of this with a surprise
removal/query_removal, and then I will no longer send I/O. What happens if
you use the new retrieved generation count right away?

good luck,

Philip Lukidis

Arne
Thu Aug 19 07:49:32 CDT 2004

Philip Lukidis wrote:

> Somewhat off topic, I hope your device is IRM capable if you plan on using
> isochronous I/O on WinXP SP2. MS removed IRM capability from its host
> controller driver in SP2 (but not SP2 RC2!!). If no one on the network is
> the IRM, then no one will be able to allocate channels and bandwidth.

Is there an article on this? But allocating bandwidth and channel with
the explicit bus requests should be possible anyway, shouldn't it?


> Back to your question, I have always used the new retrieved generation
> count the moment I retrieve it after I got a STATUS_INVALID_GENERATION. If
> my device has departed, then I will be apprised of this with a surprise
> removal/query_removal, and then I will no longer send I/O. What happens if
> you use the new retrieved generation count right away?

In the described situation, GET_GENERATION_COUNT returns the same
generation as before and the call still fails with
"STATUS_INVALID_GENERATION".

-Arne

Philip
Thu Aug 19 08:02:33 CDT 2004

"Arne Caspari" <arne_caspari@nospam> wrote in message
news:OljefrehEHA.2624@TK2MSFTNGP12.phx.gbl...
> Philip Lukidis wrote:
>
> > Somewhat off topic, I hope your device is IRM capable if you plan on
using
> > isochronous I/O on WinXP SP2. MS removed IRM capability from its host
> > controller driver in SP2 (but not SP2 RC2!!). If no one on the network
is
> > the IRM, then no one will be able to allocate channels and bandwidth.
>
> Is there an article on this? But allocating bandwidth and channel with
> the explicit bus requests should be possible anyway, shouldn't it?
>

No. Someone noticed this and posted it on the NTDEV mailing list. If there
is no IRM on the 1394 topology, then no channel allocation and bandwidth
allocation would be impossible to coordinate, because the IRM implements the
registers which specifiy which channels are available and how much bandwidth
is available. And this is new to build 2180, and not present in build 2149.

>
> > Back to your question, I have always used the new retrieved generation
> > count the moment I retrieve it after I got a STATUS_INVALID_GENERATION.
If
> > my device has departed, then I will be apprised of this with a surprise
> > removal/query_removal, and then I will no longer send I/O. What happens
if
> > you use the new retrieved generation count right away?
>
> In the described situation, GET_GENERATION_COUNT returns the same
> generation as before and the call still fails with
> "STATUS_INVALID_GENERATION".
>
Oh. I have not yet seen that on my side. Async I/O seems to work fine...so
far.
> -Arne

good luck,

Philip Lukidis

Arne
Thu Aug 19 08:25:53 CDT 2004

Philip Lukidis wrote:


>>Is there an article on this? But allocating bandwidth and channel with
>>the explicit bus requests should be possible anyway, shouldn't it?

>
> No. Someone noticed this and posted it on the NTDEV mailing list. If there
> is no IRM on the 1394 topology, then no channel allocation and bandwidth
> allocation would be impossible to coordinate, because the IRM implements the
> registers which specifiy which channels are available and how much bandwidth
> is available. And this is new to build 2180, and not present in build 2149.

BTW.:

The SelfID still says it is IRM capable. WinDBG says the system is:

Built by: 2600.xpsp_sp2_rtm.040803-2158

Is 2158 the build version? Where do I get 2180 then?


-Arne

Philip
Thu Aug 19 09:05:28 CDT 2004

"Arne Caspari" <arne_caspari@nospam> wrote in message
news:%23uyYz$ehEHA.632@TK2MSFTNGP12.phx.gbl...
> Philip Lukidis wrote:
>
>
> >>Is there an article on this? But allocating bandwidth and channel with
> >>the explicit bus requests should be possible anyway, shouldn't it?
>
> >
> > No. Someone noticed this and posted it on the NTDEV mailing list. If
there
> > is no IRM on the 1394 topology, then no channel allocation and bandwidth
> > allocation would be impossible to coordinate, because the IRM implements
the
> > registers which specifiy which channels are available and how much
bandwidth
> > is available. And this is new to build 2180, and not present in build
2149.
>
> BTW.:
>
> The SelfID still says it is IRM capable. WinDBG says the system is:
>
> Built by: 2600.xpsp_sp2_rtm.040803-2158
>
> Is 2158 the build version? Where do I get 2180 then?
>
>
> -Arne

I though RC2 was 2149. Anyhow, the RTM version can be downloaded here:
http://www.microsoft.com/downloads/details.aspx?FamilyId=049C9DBE-3B8E-4F30-8245-9E368D3CDB5A&displaylang=en

The self ID of the host controller in build 2180 is does not indicate IRM
capability. Interestingly enough, when on SP2 RC2 (build 2149), I copied
over the final build 2180 1394bus and ohci1394 drivers. And the selfID of
the host controller indicated IRM capability. So I wonder where in build
2180 this is set...not in those 2180 drivers. Maybe there is a registry key
somewhere controlling this?

Anyways, try build 2180 and see if it changes anything for you.

good luck,

Philip Lukidis

Arne
Thu Aug 19 09:11:12 CDT 2004

Philip Lukidis wrote:


>
> I though RC2 was 2149. Anyhow, the RTM version can be downloaded here:
> http://www.microsoft.com/downloads/details.aspx?FamilyId=049C9DBE-3B8E-4F30-8245-9E368D3CDB5A&displaylang=en
>

Actually, this is the version I use for testing and it has IRM
activated. Maybe some other thing caused it to deactivate?

Maybe it deactivates itself if another IRM contender is on the bus?

-Arne

Philip
Thu Aug 19 09:24:26 CDT 2004

"Arne Caspari" <arne_caspari@nospam> wrote in message
news:eBMUIZfhEHA.1764@TK2MSFTNGP10.phx.gbl...
> Philip Lukidis wrote:
>
>
> >
> > I though RC2 was 2149. Anyhow, the RTM version can be downloaded here:
> >
http://www.microsoft.com/downloads/details.aspx?FamilyId=049C9DBE-3B8E-4F30-8245-9E368D3CDB5A&displaylang=en
> >
>
> Actually, this is the version I use for testing and it has IRM
> activated. Maybe some other thing caused it to deactivate?
>
> Maybe it deactivates itself if another IRM contender is on the bus?
>
> -Arne

Please confirm. Are you testing with build 2180, and you note that the MS
host node is IRM capable? I can confirm that when no other devices on the
bus are IRM capable, the MS host node is not IRM capable.

What is your topology when you note that the host node is IRM capable? Are
all the other non MS devices IRM capable or not?

Philip Lukidis

Philip
Thu Aug 19 09:34:41 CDT 2004

"Philip Lukidis" <pagefault0x0@hotmail.com> wrote in message
news:Oy$caffhEHA.2340@TK2MSFTNGP11.phx.gbl...
> "Arne Caspari" <arne_caspari@nospam> wrote in message
> news:eBMUIZfhEHA.1764@TK2MSFTNGP10.phx.gbl...
> > Philip Lukidis wrote:
> >
> >
> > >
> > > I though RC2 was 2149. Anyhow, the RTM version can be downloaded
here:
> > >
>
http://www.microsoft.com/downloads/details.aspx?FamilyId=049C9DBE-3B8E-4F30-8245-9E368D3CDB5A&displaylang=en
> > >
> >
> > Actually, this is the version I use for testing and it has IRM
> > activated. Maybe some other thing caused it to deactivate?
> >
> > Maybe it deactivates itself if another IRM contender is on the bus?
> >
> > -Arne
>
> Please confirm. Are you testing with build 2180, and you note that the MS
> host node is IRM capable? I can confirm that when no other devices on the
> bus are IRM capable, the MS host node is not IRM capable.
>
> What is your topology when you note that the host node is IRM capable?
Are
> all the other non MS devices IRM capable or not?
>
> Philip Lukidis
>
>

Ahh. Did you perchance do a Sp1(a) -> Sp2 (2180), or sp1(a) -> SP2 RC2
(2149) -> SP2 (2180)? I found that this results in the MS node being IRM
capable. Wouldn't this mean that there is a public interface (the registry)
which sets this?

Philip Lukidis

Arne
Thu Aug 19 10:09:35 CDT 2004

Philip Lukidis wrote:

> "Philip Lukidis" <pagefault0x0@hotmail.com> wrote in message
> news:Oy$caffhEHA.2340@TK2MSFTNGP11.phx.gbl...
>

>
> Ahh. Did you perchance do a Sp1(a) -> Sp2 (2180), or sp1(a) -> SP2 RC2
> (2149) -> SP2 (2180)? I found that this results in the MS node being IRM
> capable. Wouldn't this mean that there is a public interface (the registry)
> which sets this?
>

I never installed the RC2 so it is SP1->SP2.

Topology is MS-Host->HUB->{1394camera,PCILYNX sniffer}

None of the other devices is IRM capable ( in fact, the sniffer and the
HUB are inactive links ).

BTW. looks like I fixed the bus_reset issue, I will post details tomorrow.


-Arne

Philip
Thu Aug 19 10:19:43 CDT 2004

"Arne Caspari" <arne_caspari@nospam> wrote in message
news:uL45v5fhEHA.1764@TK2MSFTNGP10.phx.gbl...
> Philip Lukidis wrote:
>
> > "Philip Lukidis" <pagefault0x0@hotmail.com> wrote in message
> > news:Oy$caffhEHA.2340@TK2MSFTNGP11.phx.gbl...
> >
>
> >
> > Ahh. Did you perchance do a Sp1(a) -> Sp2 (2180), or sp1(a) -> SP2 RC2
> > (2149) -> SP2 (2180)? I found that this results in the MS node being
IRM
> > capable. Wouldn't this mean that there is a public interface (the
registry)
> > which sets this?
> >
>
> I never installed the RC2 so it is SP1->SP2.
>
> Topology is MS-Host->HUB->{1394camera,PCILYNX sniffer}
>
> None of the other devices is IRM capable ( in fact, the sniffer and the
> HUB are inactive links ).
>
> BTW. looks like I fixed the bus_reset issue, I will post details tomorrow.
>
>
> -Arne

If you see that the MS host controller is IRM capable, and on SP2 build
2180, then you have observed something new, and different from my own and
someone else's (on the NTDEV group) observations.

When you have time, could you please confirm that you see the MS host node
is IRM capable, and on build 2180? And if you have a work around for the
bus reset issue, could you please post it?

thanks,

Philip Lukidis

r_konjeti
Fri Aug 20 14:17:55 CDT 2004

I observed GET_GENERATION_COUNT was giving same generation count when
I called from Dispatch level. So I redesigned to call
GET_GENERATION_COUNT at lowest IRQL and to sleep for 50 milliseconds
before I send the GENERATION_COUNT request. This I imitate from
sonydcam.sys sample driver code. After this bus reset handling
improved.

Thanks.

Arne Caspari <arne_caspari@nospam> wrote in message news:<uL45v5fhEHA.1764@TK2MSFTNGP10.phx.gbl>...
> Philip Lukidis wrote:
>
> > "Philip Lukidis" <pagefault0x0@hotmail.com> wrote in message
> > news:Oy$caffhEHA.2340@TK2MSFTNGP11.phx.gbl...
> >
>
> >
> > Ahh. Did you perchance do a Sp1(a) -> Sp2 (2180), or sp1(a) -> SP2 RC2
> > (2149) -> SP2 (2180)? I found that this results in the MS node being IRM
> > capable. Wouldn't this mean that there is a public interface (the registry)
> > which sets this?
> >
>
> I never installed the RC2 so it is SP1->SP2.
>
> Topology is MS-Host->HUB->{1394camera,PCILYNX sniffer}
>
> None of the other devices is IRM capable ( in fact, the sniffer and the
> HUB are inactive links ).
>
> BTW. looks like I fixed the bus_reset issue, I will post details tomorrow.
>
>
> -Arne