Re[4]: [ros-kernel] Finally have good stack trace on crash I'm experiencing...

[Royce M. I. <ro...@ev...>]

Hello Eric,

Here's the relevant snippet:

Initializing system32\drivers\disk.sys...
DriverBase for system32\drivers\disk.sys: dcccc000
(atapi.c:783) Srb c04de636  XferLen 0  XferSz 512  LastBlk TRUE  TgtAddr ccc6448
2
(atapi.c:783) Srb c04de636  XferLen 0  XferSz 512  LastBlk TRUE  TgtAddr ccc6448
2
(atapi.c:783) Srb c00b4440  XferLen 0  XferSz 53456  LastBlk TRUE  TgtAddr c04dd
78a
Page fault at high IRQL was 12
Bug detected code: 0x1D
Page Fault Exception: 14(2)


Just so as there's no confusion, here's my atapi.c:783 :

      DPRINT1("Srb %p  XferLen %lu  XferSz %lu  LastBlk %s  TgtAddr %lx\n",
              Srb, Srb->DataTransferLength, TransferSize,
              (IsLastBlock) ? "TRUE" : "FALSE", (ULONG)TargetAddress );

Why would Srb->DataTransferLength be 0???

Royce3

Sunday, September 1, 2002, 7:47:37 AM, you wrote:

EK> Well, it clearly shows that something is going wrong.

EK> In AtapiInterrupt() you will find some more DPRINT() macros. Enable one of
EK> them, by changing it to DPRINT1(), to get some more information about the
EK> failed data transfer.

EK> For example, enable the DPRINT() at line 718 to check the validity of the
EK> SRB (Scsi Request Block). The SRB should be the same for each valid
EK> interrupt of a data-transfer.

EK> Or enable the DPRINT()s at lines 757, 758 and 771 to check the progress of
EK> the current transfer. IsLastBlock should be TRUE at the last interrupt of a
EK> transfer. TransferLength is the number of bytes that will have to be
EK> transferred to complete the transfer. It should diminish by 512 (0x200) upon
EK> each interrupt.

EK> Your harddisk might generate an excessive interrupt after the data transfer
EK> has completed. In this case atapi.sys might not identify this interrupt as
EK> invalid.


EK> Eric