: here is some more data on my problems with SCSI tapes connected to AHA1542
: with 2.1.x (2.1.119 and 2.1.122 to be specific):
: <unfortunate block size causes scsi reset>
: one more problem is that after the message
: aha1542.c: Trying device reset for target ...
: interrupts are disabled for several seconds and the system clock
: so looses many ticks (and other devices may et in trouble too).
: is it really necessary to block interrupts for such a long period
: when aha1542 issues a reset ??
This time lost is caused by the code
* Wait for the thing to settle down a bit. Unfortunately
* this is going to basically lock up the machine while we
* wait for this to complete. To be 100% correct, we need to
* check for timeout, and if we are doing something like this
* we are pretty desperate anyways.
in aha1542.c (called with io_request_lock held, so that absolutely
nothing happens anymore, not even console switches).
Unfortunately, the aha1542 abort code does not do anything
and the aha1542 reset code is wrong, so all this device reset and
bus reset stuff can better be commented out. Then scsi_error.c causes
problems because it assumes that the low level driver is functioning
correctly, and it isn't.
Conclusion: when either your hardware is not perfect, or there is a bug
elsewhere in the SCSI code (and there probably is in your case) then
aha1542 will greatly aggravate the situation, and often end up killing
the entire system.
But if you comment out the reset stuff in both aha1542.c and scsi_error.c
then things are not so bad, and you just have the original error to
I wrote a new aha1542.c a few weeks ago, but it is not yet ready
for prime time. (Testing is time-consuming, the documentation is poor,
and I do not have a 1542 myself at present.)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/