On Wed, May 19, 2010 at 11:44 PM, Matthew Dempsky <matt...@dempsky.org> wrote:
> ahci_ata_cmd() at ahci_ata_cmd+0x10c
> ata_exec() at ata_exec+0xe
> scsi_xs_exec() at scsi_xs_exec+0x24
> scsi_xs_sync() at scsi_xs_sync+0x6f
I poked around a bunch at this, and have a bit more information to
report. With some luck, maybe it's of some use to someone with actual
knowledge of how SCSI, AHCI, et al actually fit together.
I've found the most reliable way to kernel panic is to insert a BD,
and then run "disklabel cd1" repeatedly while the drive initially
scans the disc. (Simply running "disklabel cd1" if the disc was
already in at boot time doesn't seem to trigger it.)
Immediately after running the last "disklabel cd1" command before
panic, in the kernel output I get:
ahci0.3: ahci_ata_get_xfer got slot 17
ahci0.3: interrupt: 40000001<TFES,DHRS>
ahci0.3: error slot 17, TFD: 6851<ERR>, SERR: 0, DIAG: 0
(At this point xa->state is set to ATA_S_ERROR on line 1862 of ahci.c.)
ahci0.3: slot 17 is complete (error)
This error propagates back to scsi_xs_sync, which calls scsi_xs_error
to interpret the error. This calls scsi_interpret_sense:
cd1(ahci0:3:0): Check Condition (error 0x70) on opcode 0x0
SENSE KEY: Unit Attention
and eventually falls through to calling scsi_delay on line 1473 of
scsi_base.c, which returns ERESTART.
Finally, scsi_xs_sync then loops calling scsi_xs_exec again with the
same (now errored) xs it got from scsi_scsi_cmd, which eventually
reaches ahci_ata_cmd and kernel panics because xa->status ==
ATA_S_ERROR.
Anyway, that's where I'm stuck.
