scsiinfo -d causes a
"aborting command due to timeout... Read Defect Data"
>From that moment on the system seems to execute never-ending SCSI bus
resets. I have a AHA 2940 with BIOS 1.21 that otherwise works well.
I have enabled "DEBUG_TIMEOUT" in scsi.c and booted Linux with
"single debug". Interestingly in this constellation the scsiinfo at
least terminates but with varying results (e.g. defect list is said
to be empty).
I have written down some of the possibly "interesting" messages:
aic7xxx: (abort) Aborting scb 2, TCL=0/0/0
...
SCSI host 0 abort (pid 9363) timed out - resetting
aic7xxx: (reset) target/channel 0/0
(abort_reset) scb state 0x1, Data-in pahse, SCSISIGI=0xc6
(abort_scb) asserted ATN - bus device reset in message buffer
SCSI host 0 channel 0 reset (pid 9363) timed out - trying harder
aic7xxx: (reset) target/channel 0/0
(reset_device) target/channel -1/A, active_scb 2
(match_scb) comparing target/channel -1/A to scb 0/A
(reset_channel) Resetting current channel A
(reset_channel) Channel reset, sequencer restarted
(done_aborted_scbs) Aborting scb 2, TCL=0/0/0
I noticed that the value for wait_for_request alsways stayed the same,
namedly at 001dff00. Also I noticed that during bus or device reset the
system had seriously delayed console switching (several seconds). Is
that a bug?
What is really interesting is that even that I was able to get
scsiinfo finished, the system was unable to read any further block
from the SCSI disk. I think that is the real bug. Unfortunately I can't
tell whether the problem is in the aic7xxx driver or in scsi.c.
After such a disk read error I also got spurious messages from the ext2
filesystem.
For aic7xxx: the comparison of -1/A and 0/A seems odd to me. also
sometimes channels seem to be printed as a digit and sometimes as a
letter.
Hopefully this report is useful to someone. I'm not subscribed to thes
lists, and I'm on holiday for another week...
Ulrich Windl