[NTDEV] Awaiting an event during boot up

Here is a dump of the call stack of the process that is initializing the
system –

fc8d5cec 804d71cb 80e7c468 80e7c3d0 fc8d5d8c nt!KiSwapContext+0x2f (FPO:
[EBP 0xfc8d5d24] [0,0,4])
fc8d5cfc 804d61b8 80e8c708 fc8d5ddc 80e8c440 nt!KiSwapThread+0x6c (FPO: [EBP
0xfc8d5d24] [0,0,4])
fc8d5d24 fc4ff259 00000000 00000000 00000000 nt!KeWaitForSingleObject+0x1ae
(FPO: [Non-Fpo])
fc8d5dac fc4ff298 80e8c708 001b0501 000000ec
disk!DiskPerformSmartCommand+0x150 (FPO: [Non-Fpo])
fc8d601c fc4ffa5c 80e8c440 fc8d624f 80e8c7c4 disk!DiskGetIdentifyInfo+0x34
(FPO: [Non-Fpo])
fc8d6244 fc501606 80e8c440 80e8c7c4 80e8e4c8
disk!DiskDetectFailurePrediction+0x22 (FPO: [Non-Fpo])
fc8d626c fc5129b0 80e8c388 00000000 80e91f04 disk!DiskInitFdo+0x22b (FPO:
fc8d6294 fc512c0e 01e8c388 80e91f20 80e8e030
CLASSPNP!ClassPnpStartDevice+0x1e4 (FPO: [Non-Fpo])
fc8d62bc 804d85ef 80e8c388 80e91e70 80e8c218 CLASSPNP!ClassDispatchPnp+0x160
(FPO: [Non-Fpo])
fc8d62cc fc7461a9 80e91f4c 80e47dc8 80e91e70 nt!IopfCallDriver+0x31 (FPO:
fc8d6300 804d85ef 80e8c160 80e91e70 fc8d637c PartMgr!PmPnp+0x247 (FPO:
fc8d6310 805c6a4d fc8d637c 80e8e9a0 00000000 nt!IopfCallDriver+0x31 (FPO:
fc8d633c 805a2150 80e8c160 fc8d6358 00000000 nt!IopSynchronousCall+0xb8
(FPO: [Non-Fpo])
fc8d637c 804fc8f2 80e8e9a0 c00002ce 00000001 nt!IopStartDevice+0x51 (FPO:
fc8d6398 805a2a7c 80e8e9a0 00000000 00000000 nt!PipProcessStartPhase1+0x4c
(FPO: [Non-Fpo])
fc8d65e0 804fffbb 80e9f5a0 00000000 e12a9600 nt!PipProcessDevNodeTree+0x171
(FPO: [Non-Fpo])
fc8d6624 804ffcdd 00000000 00000000 80091e68 nt!PipDeviceActionWorker+0xab
(FPO: [Non-Fpo])
fc8d663c 8068d57a 00000000 00000005 00000000 nt!PipRequestDeviceAction+0x116
(FPO: [Non-Fpo])
fc8d66a0 806839ee 80087000 fc8d67e4 00034000
nt!IopInitializeBootDrivers+0x380 (FPO: [Non-Fpo])
fc8d6840 806848d1 80087000 00000000 80e7c3d0 nt!IoInitSystem+0x5e7 (FPO:
fc8d6dac 8056b103 80087000 00000000 00000000 nt!Phase1Initialization+0x925
(FPO: [1,341,3])
fc8d6ddc 805128c1 806841c9 80087000 00000000 nt!PspSystemThreadStartup+0x34
(FPO: [Non-Fpo])
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

The problem that I am having is that my SCSI mini-port has been called
numerous times find it’s targets. This dump was taken after the first target
has received a READ_CAPACITY (0x25), and the adapter replied with a Check
condition. In this specific case, there was a successful retry followed by a
READ (0x28), and the system then appeared to freeze. Looking at the dump
above I see that the boot process is in KeWaitForSingleObject. My assumption
here is that the event associated with the IRP created by
disk!DiskPerformSmartCommand has NOT been triggered. Why I do not know,
since every SRB has been completed.

I do suspect that the root cause is in how I am handling the check
condition. My adapter is telling me that I have 32 bytes of sense data, but
the SRB has only allocated 18 bytes for the sense buffer. Currently, I
simply limit the sense data to the size allocated for the SRB and copy it to
the SRB. Part of the sense data, at byte 7 (AddtionalSenseLength) is the
count of the remaining bytes in the sense buffer. From the adapter that is
24, and adding that to the preceding header the size of sense is indeed 32.
I have a classic dilemma here — how to stuff 4 pounds of shit into a 2
pound bag. I am reading the docs again, but this far, properly handling
sense data is not clearly defined.

The condition of the disks and partitions are not known. They may or may not
be formatted. Another assumption is that the ClassPnP driver is looking for
partitions now and creating PDOs for the ones that it finds.

Or, am I chasing a white rabbit and a check condition’s sense data has
nothing to do with why the system will not continue initialization?

Gary G. Little
Broadband Storage, Inc.

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com