Hello,
does anyone know if the 1394bus.sys serializes asynchronous reads or
writes if accessed from different drivers? Does a REQUEST_ASYNC_WRITE
fail if submitted at the same time from different drivers (using the
same ohci controller card)?
I’m sometimes getting a STATUS_IO_TIMEOUT (0xc00000b5) or
STATUS_DEVICE_BUSY (0x80000011) but doesn’t know the reason why.
Thanks
Uwe
No, it passes them down to OHCI1394, which creates the DMA descriptor
chains to service them.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “uwe kirst”
To: “Windows System Software Devs Interest List”
Sent: Saturday, September 11, 2004 1:50 PM
Subject: [ntdev] does 1394bus.sys serialize async access from different
drivers?
> Hello,
> does anyone know if the 1394bus.sys serializes asynchronous reads or
> writes if accessed from different drivers? Does a REQUEST_ASYNC_WRITE
> fail if submitted at the same time from different drivers (using the
> same ohci controller card)?
>
> I’m sometimes getting a STATUS_IO_TIMEOUT (0xc00000b5) or
> STATUS_DEVICE_BUSY (0x80000011) but doesn’t know the reason why.
> Thanks
> Uwe
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
Maxim S. Shatskih wrote:
No, it passes them down to OHCI1394, which creates the DMA descriptor
chains to service them.
So what happens if the internal descriptor processing within OHCI1394 is
interrupted by a second write access from a different driver. Are
OHCI1394 and 1394BUS supposed to cope with this situation even if the
two accesses address different targets?
Do you know in which situations I’ll get STATUS_IO_TIMEOUT (0xc00000b5)?
It seems I’m having a problem to access more than one firewire device
at the same time.
Thanks
Uwe
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com----- Original Message -----
From: “uwe kirst”
>To: “Windows System Software Devs Interest List”
>Sent: Saturday, September 11, 2004 1:50 PM
>Subject: [ntdev] does 1394bus.sys serialize async access from different
>drivers?
>
>
>
>
>>Hello,
>>does anyone know if the 1394bus.sys serializes asynchronous reads or
>>writes if accessed from different drivers? Does a REQUEST_ASYNC_WRITE
>>fail if submitted at the same time from different drivers (using the
>>same ohci controller card)?
>>
>>I’m sometimes getting a STATUS_IO_TIMEOUT (0xc00000b5) or
>>STATUS_DEVICE_BUSY (0x80000011) but doesn’t know the reason why.
>>Thanks
>>Uwe
>>
>>
>>
>>—
>>Questions? First check the Kernel Driver FAQ at
>>
>>
>http://www.osronline.com/article.cfm?id=256
>
>
>>You are currently subscribed to ntdev as: xxxxx@storagecraft.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>
>
>
>—
>Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@gmx.de
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
“uwe kirst” wrote in message news:xxxxx@ntdev…
> Hello,
> does anyone know if the 1394bus.sys serializes asynchronous reads or
> writes if accessed from different drivers? Does a REQUEST_ASYNC_WRITE
> fail if submitted at the same time from different drivers (using the
> same ohci controller card)?
>
> I’m sometimes getting a STATUS_IO_TIMEOUT (0xc00000b5) or
> STATUS_DEVICE_BUSY (0x80000011) but doesn’t know the reason why.
> Thanks
> Uwe
>
>
>
Hello. I have quite frequently seen this issue in the past (but with one
device), and it turned out to be a firmware issue, where the asynchronous
command queue was not large enough (esp. for STATUS_DEVICE_BUSY, which seems
to be mapped to ack_busy_x or 1/2 on the bus), or that the device simply
just did not respond quickly enough. Since I did not work on the firmware
fixes, I really can’t say much more on the issue.
I have seen on WinXP SP2, that when I have isoch running, and I put in a
barrage of bus resets and asynchronous I/O, the PnP manager sometimes
unloads my driver (surprise removal). The bus reset barrage must be quite
intense to have this effect. I don’t have this issue on WinXP SP1, though.
I don’t see any ack_busy on the bus in this case at all. Have ever you
noted this?
thanks,
Philip Lukidis
Philip Lukidis wrote:
“uwe kirst” wrote in message news:xxxxx@ntdev…
>
>
>>Hello,
>>does anyone know if the 1394bus.sys serializes asynchronous reads or
>>writes if accessed from different drivers? Does a REQUEST_ASYNC_WRITE
>>fail if submitted at the same time from different drivers (using the
>>same ohci controller card)?
>>
>>I’m sometimes getting a STATUS_IO_TIMEOUT (0xc00000b5) or
>>STATUS_DEVICE_BUSY (0x80000011) but doesn’t know the reason why.
>>Thanks
>>Uwe
>>
>>
>>
>>
>>
>Hello. I have quite frequently seen this issue in the past (but with one
>device), and it turned out to be a firmware issue, where the asynchronous
>command queue was not large enough (esp. for STATUS_DEVICE_BUSY, which seems
>to be mapped to ack_busy_x or 1/2 on the bus), or that the device simply
>just did not respond quickly enough. Since I did not work on the firmware
>fixes, I really can’t say much more on the issue.
>
>
I’m now also thinking that it’s firmware related. We’re trying to speed
up the async accesses, at least for some critical addresses.
>I have seen on WinXP SP2, that when I have isoch running, and I put in a
>barrage of bus resets and asynchronous I/O, the PnP manager sometimes
>unloads my driver (surprise removal). The bus reset barrage must be quite
>intense to have this effect. I don’t have this issue on WinXP SP1, though.
>I don’t see any ack_busy on the bus in this case at all. Have ever you
>noted this?
>
>thanks,
>
>Philip Lukidis
>
>
>
No,
I removed the code responsible for creating bus resets some times ago,
because the meaning of that pice of code was not clear to me.
I’ll try to check more bus topologies if I have more time and the most
important bugs in our driver a fixed. I think in the most common cases
you do not need to create bus resets?
thanks
Uwe
[snip]
No,
I removed the code responsible for creating bus resets some times ago,
because the meaning of that pice of code was not clear to me.
I’ll try to check more bus topologies if I have more time and the most
important bugs in our driver a fixed. I think in the most common cases
you do not need to create bus resets?
thanks
Uwe
I’m not sure which piece of code you are referring to. I have a stress app
which sends IOCTLs for lab use only, which simply requests a bus reset via
the REQUEST_BUS_RESET IOCTL and/or sends large amounts of async I/O. I
noticed that under WinXP SP2, with isoch stream is on, and combined with a
heavy barrage of bus resets, the PnP manager surprise removes my device
after a while. Somehow the bus driver is convinced that the device did not
respond quickly enough after the bus resets. Granted, it takes a very large
amount of bus resets to have this effect, but this was never a problem under
WinXP SP1.
The actual production driver does not have this IOCTL compiled in at all.
And unfortunately for my case I was referring to the simplest topology of
all, host controller and device.
Philip Lukidis
Philip Lukidis wrote:
[snip]
>No,
>I removed the code responsible for creating bus resets some times ago,
>because the meaning of that pice of code was not clear to me.
>I’ll try to check more bus topologies if I have more time and the most
>important bugs in our driver a fixed. I think in the most common cases
>you do not need to create bus resets?
>thanks
>Uwe
>
>
>
I’m not sure which piece of code you are referring to. I have a stress app
which sends IOCTLs for lab use only, which simply requests a bus reset via
the REQUEST_BUS_RESET IOCTL and/or sends large amounts of async I/O. I
noticed that under WinXP SP2, with isoch stream is on, and combined with a
heavy barrage of bus resets, the PnP manager surprise removes my device
after a while. Somehow the bus driver is convinced that the device did not
respond quickly enough after the bus resets. Granted, it takes a very large
amount of bus resets to have this effect, but this was never a problem under
WinXP SP1.The actual production driver does not have this IOCTL compiled in at all.
And unfortunately for my case I was referring to the simplest topology of
all, host controller and device.Philip Lukidis
Ok, now I understand. If you are in that situation (device does not
respond quickly enough). What happens next? Does the device and driver
recover from that situation if you stop the IOCTLs or do you have to
power it off and on again?
Today I hopefully have fixed the STATUS_IO_TIMEOUT problem, but
introduced a new one: If I turn off one device the other sometimes does
not revcover from the bus reset.
Uwe
“uwe kirst” wrote in message news:xxxxx@ntdev…
> Philip Lukidis wrote:
>
> >[snip]
> >
> >
> >>No,
> >>I removed the code responsible for creating bus resets some times ago,
> >>because the meaning of that pice of code was not clear to me.
> >>I’ll try to check more bus topologies if I have more time and the most
> >>important bugs in our driver a fixed. I think in the most common cases
> >>you do not need to create bus resets?
> >>thanks
> >>Uwe
> >>
> >>
> >>
> >I’m not sure which piece of code you are referring to. I have a stress
app
> >which sends IOCTLs for lab use only, which simply requests a bus reset
via
> >the REQUEST_BUS_RESET IOCTL and/or sends large amounts of async I/O. I
> >noticed that under WinXP SP2, with isoch stream is on, and combined with
a
> >heavy barrage of bus resets, the PnP manager surprise removes my device
> >after a while. Somehow the bus driver is convinced that the device did
not
> >respond quickly enough after the bus resets. Granted, it takes a very
large
> >amount of bus resets to have this effect, but this was never a problem
under
> >WinXP SP1.
> >
> >The actual production driver does not have this IOCTL compiled in at all.
> >And unfortunately for my case I was referring to the simplest topology of
> >all, host controller and device.
> >
> >Philip Lukidis
> >
> >
> >
> >
> Ok, now I understand. If you are in that situation (device does not
> respond quickly enough). What happens next? Does the device and driver
> recover from that situation if you stop the IOCTLs or do you have to
> power it off and on again?
>
After the PnP manager unloads my device, many times it does recover in the
sense that I don’t have to turn the device off and on again…it is simply
redetected. This does not always occur, though. It’s only a guess that the
device does not respond quickly enough for the 1394 bus driver’s fancy…I
could be totally off base. I would have thought that
IoInvalidateDeviceRelations would have been called in that case by the 1394
bus driver, but I did not see that called…(maybe my symbols were wrong?).
Have you seen this? Again, not an issue for me on SP1.
> Today I hopefully have fixed the STATUS_IO_TIMEOUT problem, but
> introduced a new one: If I turn off one device the other sometimes does
> not revcover from the bus reset.
> Uwe
>
>
>
When you say that your second device does not recover, how so? Does the PnP
manager send you a surprise removal? Do you have to power on/off?
I have yet to test SP2 with multiple devices.
WPP tracing is such a pain for someone who has not done much, ok…any WMI
:-o I have some strange preproc issues to deal with.
I can’t wait to get WPP tracing working on Win2k.
Philip Lukidis
>>
>
When you say that your second device does not recover, how so? Does the PnP
manager send you a surprise removal? Do you have to power on/off?
In my case (a read or write returns STATUS_IO_TIMEOUT) one of the two devices is blocked. I did not get a surprise removal or bus reset. Even the isoch streaming continues for quite a while.
Uwe
“Philip Lukidis” wrote in message
news:xxxxx@ntdev…
>
> WPP tracing is such a pain for someone who has not done much, ok…any
> WMI
> :-o I have some strange preproc issues to deal with.
>
> I can’t wait to get WPP tracing working on Win2k.
>
>
What kind of issues are you having? I recently had a bunch of problems
trying to get a driver to conditionally compile for W2K WPP vs WXP WPP.
Here’s what eventually led to success:
1) Do everything that the tracedrv sample in the DDK does, and then damn it
for containing only one file, being in a .C file and being a legacy driver
that creates its one device object in DriverEntry (then once you get the
basic stuff working you can also damn it for not using levels).
2) If you’re using the .CPP extension, add -dll to your RUN_WPP macro and
“extern “C”” around your #include TMH’s
3) The WPP_INIT_TRACING macro can only appear in one module, even if it’s
conditionally compiled out. The trace preprocessor completely ignores #if’s
and splurges a bunch of stuff into the TMHs for modules that have this
macro. So, you’ll end up with multiple definitions of random functions and
variables if WPP_INIT_TRACING is in more than one module.
HTH,
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Scott Noone” wrote in message news:xxxxx@ntdev…
>
> “Philip Lukidis” wrote in message
> news:xxxxx@ntdev…
> >
> > WPP tracing is such a pain for someone who has not done much, ok…any
> > WMI
> > :-o I have some strange preproc issues to deal with.
> >
> > I can’t wait to get WPP tracing working on Win2k.
> >
> >
>
> What kind of issues are you having? I recently had a bunch of problems
> trying to get a driver to conditionally compile for W2K WPP vs WXP WPP.
> Here’s what eventually led to success:
>
> 1) Do everything that the tracedrv sample in the DDK does, and then damn
it
> for containing only one file, being in a .C file and being a legacy driver
> that creates its one device object in DriverEntry (then once you get the
> basic stuff working you can also damn it for not using levels).
>
> 2) If you’re using the .CPP extension, add -dll to your RUN_WPP macro and
> “extern “C”” around your #include TMH’s
>
> 3) The WPP_INIT_TRACING macro can only appear in one module, even if it’s
> conditionally compiled out. The trace preprocessor completely ignores
#if’s
> and splurges a bunch of stuff into the TMHs for modules that have this
> macro. So, you’ll end up with multiple definitions of random functions and
> variables if WPP_INIT_TRACING is in more than one module.
>
> HTH,
>
> -scott
>
> –
> Scott Noone
> Software Engineer
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
>
>
Thanks for your offer of help. But I finally got it to compile. I was
using 1) and 2) from the beginning, as those issues were mentioned in the
archive. My last real issue was number 3). I found the solution totally by
chance (someone should document that, or is it documented somewhere?
Perhaps it’s too obvious to document, but it tricked me for a while).
Instead of using the tracedrv sample, I used the toaster function featured2
sample as a template to implement a simple WMI handler which can also handle
Win2k WPP tracing. Thank God Eliyas put in WPP tracing with levels in the
toaster featured2 sample for both Win2k and WinXP.
thanks,
Philip Lukidis