yep
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Robert Stankey
Sent: Monday, April 19, 2004 10:56 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Question regarding ScsiPort and failed START_DEVICE
requests
On Mon, 19 Apr 2004 08:57:09 -0700, Peter Wieland wrote:
One last thing…
This sounds like a stupid question to ask but I’m going to anyway. Can
I assume PnP won’t send any other PnP request to a device currently in a
START_DEVICE/REMOVE_PENDING state. In other words, I shouldn’t see a
QUERY_REMOVE_DEVICE until I’ve completed the START_DEVICE request.
Bob
Returning STATUS_PENDING seems like a good choice.
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Robert Stankey
Sent: Monday, April 19, 2004 7:30 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Question regarding ScsiPort and failed
START_DEVICE requests
On Fri, 16 Apr 2004 09:55:42 -0700, Peter Wieland wrote:
Hi Peter,
Thanks for your response. From what I can tell the reset condition is
caused by multiple storage arrays are coming up on the loop causing a
LIP condition. I believe the behavior of the HBA I’m using may return
this condition but only for a very short period of time.
I can detect this condition and try again but I’m thinking of a more
general case where some condition may not be cleared in a timely
manner which would hold up the PnP start process. In this case I
should probably return a PENDING status from the START_DEVICE request.
Thoughts?
Bob
> I think you’re focussing on the wrong problem.
>
> What is the cause of the bus reset? Is the device timing out? Is
> the
> device resetting the bus for some reason? What does the event log
say?
>
> What’s the reasoning behind failing the device start if a reset
> occurs
> while you’re probing it? This may or may not be the “right thing to
> do”.
>
>
> PNP will disable the device. You’ll need to go into device manager
> and enable the device in order for it to get rediscovered.
>
> SCSIPORT won’t delete its PDO when this remove comes down because
> scsiport knows the hardware is still present (unless you’ve managed
> to
> make the device stop responding to inquiries or have changed its
> inquiry data … Then it will get deleted eventually). But it will
> do
> everything else associated with a remove.
>
> -p
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Robert Stankey
> Sent: Friday, April 16, 2004 9:27 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Question regarding ScsiPort and failed START_DEVICE
> requests
>
> I’ve been troubleshooting a condition where I’m running into problems
> with Lun 0 from a storage array. I’ve tracked the problem down to an
> issue during the START_DEVICE request. After passing the PnP request
> to the lower level drivers my driver issues a couple of inquiry
> requests to the device to gather some information necessary for
> proper
operation.
> One of these requests fails due to a BUS_RESET condition, upon which
> I
> fail the START_DEVICE. According to the DDK documentation…
>
> "If a driver for a device fails the IRP_MN_START_DEVICE request, the
> PnP Manager sends an IRP_MN_REMOVE_DEVICE request to the device stack
> (on Windows 2000 and later systems). In response to this IRP, the
> drivers for the device undo their start operations (if they succeeded
> the start IRP), undo their AddDevice operations, and detach from the
device stack.
> The PnP Manager marks such a device “failed start.”"
>
> My questions are:
>
> - Will ScsiPort remove its PDO when this happens?
> - Lets say I determine the condition has cleared. How do I get PnP
> to
> reattempt a START_DEVICE? If ScsiPort has removed the PDO
> invalidating the BusRelations for the adapter port’s PDO should
> rediscover it. If ScsiPort hasn’t removed the PDO I don’t know how
> to
accomplish this.
>
> Thanks,
> Bob
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@windows.microsoft.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@windows.microsoft.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@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com