Kenn Humborg wrote:
>
> I've got a problem with two DEC RZ55 drives on an Advansys ABP3925
> host adapter.
>
> If the drives are powered up before I insmod the advansys module,
> everything works fine. The driver spins up the drives and all is
> good.
>
> However, if I load the module while the drives are powered down,
> I get the following:
>
> May 9 21:51:19 avalon kernel: scsi : aborting command due to timeout :
> pid 49, scsi0, channel 0, id 1, lun 0 Test Unit Ready 00 00 00 00 00
> May 9 21:51:25 avalon kernel: scsi : aborting command due to timeout :
> pid 49, scsi0, channel 0, id 1, lun 0 Test Unit Ready 00 00 00 00 00
> May 9 21:51:31 avalon kernel: scsi : aborting command due to timeout :
> pid 50, scsi0, channel 0, id 2, lun 0 Test Unit Ready 00 00 00 00 00
> May 9 21:51:37 avalon kernel: scsi : aborting command due to timeout :
> pid 50, scsi0, channel 0, id 2, lun 0 Test Unit Ready 00 00 00 00 00
> May 9 21:51:43 avalon kernel: scsi : aborting command due to timeout :
> pid 51, scsi0, channel 0, id 3, lun 0 Test Unit Ready 00 00 00 00 00
> May 9 21:51:49 avalon kernel: scsi : aborting command due to timeout :
> pid 51, scsi0, channel 0, id 3, lun 0 Test Unit Ready 00 00 00 00 00
> May 9 21:51:55 avalon kernel: scsi : aborting command due to timeout :
> pid 52, scsi0, channel 0, id 4, lun 0 Test Unit Ready 00 00 00 00 00
> May 9 21:52:01 avalon kernel: scsi : aborting command due to timeout :
> pid 52, scsi0, channel 0, id 4, lun 0 Test Unit Ready 00 00 00 00 00
> May 9 21:52:07 avalon kernel: scsi : aborting command due to timeout :
> pid 53, scsi0, channel 0, id 5, lun 0 Test Unit Ready 00 00 00 00 00
> May 9 21:52:13 avalon kernel: scsi : aborting command due to timeout :
> pid 53, scsi0, channel 0, id 5, lun 0 Test Unit Ready 00 00 00 00 00
> May 9 21:52:19 avalon kernel: scsi : aborting command due to timeout :
> pid 54, scsi0, channel 0, id 6, lun 0 Test Unit Ready 00 00 00 00 00
> May 9 21:52:25 avalon kernel: scsi : aborting command due to timeout :
> pid 54, scsi0, channel 0, id 6, lun 0 Test Unit Ready 00 00 00 00 00
>
> This happens with both 2.2.15 and 2.3.99-pre6. Interrupts get locked out
> every few seconds during this process. But the module does eventually
> load OK.
>
> To get some more info, I compiled up 2.3.99-pre6 with scsi logging and
> did echo "scsi log all" > /proc/scsi/scsi. After doing this, a
> modprobe advansys generated loads of info, but worked fine without
> any delays.
>
> This suggests to me that the issue is timing related. So, I want to
> try enabling various subsets of the logging types until I see which
> one 'cures' the timeout problem.
>
> Can anyone tell me what the logging levels in "scsi log <token> <level>"
> mean? How high do they go? Is there any particular <token> that
> is likely to be the critical one, so I should focus my attention there?
To quote from my notes:
To start (or stop) logging information being sent to the console/log use:
echo "scsi log <token> <n>" > /proc/scsi/scsi
where <token> is one of: {all, none, error, timeout, scan, mlqueue,
mlcomplete, llqueue, llcomplete, hlqueue, hlcomplete, ioctl}
and <n> is a number between 0 and 7. The tokens "all" and "none" don't take
an <n> argument. Prefix meanings:
hl upper level drivers [exception: sg uses "timeout"]
ml mid level
ll lower level drivers [adapter drivers often have there own flags]
The value "0" turns off logging while "7" maximizes the volume of output.
Logging information will only be output if CONFIG_SCSI_LOGGING was selected
in the kernel build.
Warning: "scsi log all" (and several other variants) can cause a logging
infinite loop if the log file (typically /var/log/messages) lies on a SCSI
disk. One solution to this is to turn off the kernel logging daemon (or
direct it to a non SCSI device).
....
So it would seem the most appropriate logging level would be:
$ echo "scsi log scan 7" > /proc/scsi/scsi
The advansys driver has its own debug define:
#define ADVANSYS_DEBUG
which is normally commented out. The current advansys driver (3.2M
in both the lk 2.2 and 2.3 series) uses the old error handling but
I believe a new version is in development that uses the new "eh"
error handling amongst other enhancements.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
