lkml.org 
[lkml]   [1998]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [(patch?)] W95 can handle SCSI errors - Linux can't

Sorry about the last one - my fingers slipped.

Couple of points - I would tend to agree that media change should
re-enable access to the device. There is a slight risk of introducing
error handling loops, however, so my guess is that we would only want to
do this if the device is still sane enough to respond to TEST_UNIT_READY.
In other words, if the device has gone completely insane you really do
want to leave the thing alone. If it still responds to simple test
commands but is unable to transfer any data, then it would be reasonable
to allow the media change detection to do it's job.

I would want to see the exact sequence you are seeing (turning on
logging if needed) so that I can see the actual return status and the
sense data. I would have thought that you would have ended up with a
MEDIUM_ERROR, but I don't *think* that this should ever cause the error
handler thread to actually do anything. Then again, if it is a timeout
that triggers this, the code path will be different. Once I see the
sequence of events, it should become much clearer as to what the actual
problem is.

The RQ_SCSI_BUSY issue sounds like a bug somewhere - scsi_error.c
is a possibility. With more information it should be easy to pin down.

The request.sem issue was an oversight. I agree that stray stack
pointers of this sort shouldn't be left dangling.

Finally, the mailbox problem could be a bug, I guess. If the
error handling gets invoked as result of a timeout, then it may be
possible to run out of mailboxes as I know of no way to abort running
commands. Then again, it could be a driver bug, where we don't mark the
mailboxes as free in some of the reset functions. This problem is likely
to be 1542 specific.

Your suggestion to avoid bus resets in some cases seems reasonable
on the surface.

On an unrelated note, is anyone working on finer grained locking
of the request queues prior to 2.2? I was going to work on some stuff for
2.3, and I would need to do this as part of this work if it hadn't been
done already.

-Eric

"The world was a library, and its books were the stones, leaves,
brooks, grass, and the birds of the earth. We learned to do what only
a student of nature ever learns, and that was to feel beauty."
Chief Luther Standing Bear - Teton Sioux
On Tue, 18 Aug 1998 Andries.Brouwer@cwi.nl wrote:

> Executive summary:
> - Reading a bad CD-ROM on a SCSI drive kills 2.0.33 entirely.
> - 2.1.115 survives, but can no longer access the CD-ROM drive.
> - Win95 mentions `I/O error' and happily reads the next CD-ROM.
> Suggestions and perhaps patches below.
>
>
> A few days ago I set up a SuSE 5.1 system on an old 486/80
> with Adaptec 1542 SCSI card. Ah, such a lot of bad memories!
> Reading a bad CDROM (or getting a SCSI error in any other way)
> would always crash the system in a loop of
> SCSI bus is being reset ...
> Sent BUS DEVICE RESET ...
> Sending DID_RESET ...
> aha1542_intr_handle: Unexpected interrupt ...
> etc.
> I tried the 2.0.33 kernel that came with SuSE 5.1, and it
> died in precisely this way. An unclean reboot is the only way out.
>
> Then I tried Windows 95, which was already installed on that machine,
> and it said: Cannot read file, and was otherwise unimpressed. Hmm.
> We can learn something. But have we learnt already?
>
> I tried 2.1.115, and it survived, more or less, but rather inelegantly.
>
> One bug is shown by the kernel message
> negative putlock from ...
> upon use of a good CDROM after the bad one.
> The reason is that scsi_allocate_device() expects to be called
> while io_request_lock is held, but sr_do_ioctl() calls it without
> first claiming this lock.
> Maybe a patch like
>
> --- /g2/linux/linux-2.1.115/linux/drivers/scsi/sr_ioctl.c Tue Aug 4 20:50:51 1998
> +++ ./sr_ioctl.c Mon Aug 17 21:22:46 1998
> @@ -56,7 +56,10 @@
> unsigned long flags;
>
> SDev = scsi_CDs[target].device;
> - SCpnt = scsi_allocate_device(NULL, scsi_CDs[target]..device, 1);
> +
> + spin_lock_irqsave(&io_request_lock, flags);
> + SCpnt = scsi_allocate_device(NULL, SDev, 1);
> + spin_unlock_irqrestore(&io_request_lock, flags);
>
> retry:
> if( !scsi_block_when_processing_errors(SDev) )
>
>
> would be an improvement. At least it avoids the negative putlock.
> But now in scsi_allocate_device() the code
>
> if (wait && SCwait && SCwait->request.rq_status != RQ_INACTIVE) {
> spin_unlock(&io_request_lock); /* FIXME!!!! */
> sleep_on(&device->device_wait);
> spin_lock_irq(&io_request_lock); /* FIXME!!!! */
>
> waits forever, since the scsi_error handling left rq_status as
> RQ_SCSI_BUSY, but (most likely) nothing will ever happen anymore.
> Is this a bug in scsi_error.c?
>
> So, what I am pointing out is first of all that the source code
> is logically incorrect. Probably we need a file with explicit
> documentation of all assumptions about the various states the
> system can be in, and the values the variables can have.
> I would like to be able to check mechanically that assumptions
> are verified.
>
> But in the second place, apart from the fact that the code is
> logically buggy, the code is technically stupid.
> (At least up to and including 2.0.33 we have: Bus reset? Worse than panic.
> And also in 2.1.115 the scsi_error code loves to do bus resets.
> Win95 does no such thing. If my scanner has problems, and my
> disks are working fine, there is no reason I can see to do a
> hard bus reset followed by a hard host reset, like the present
> code does.
>
> One might for example consider code like
> (untested, not even compiled):
> ----------------------------------------------------------------
> rtn = scsi_try_bus_device_reset(SCloop, RESET_TIMEOUT);
>
> if( rtn == SUCCESS ) {
> rtn = scsi_test_unit_ready(SCloop);
> if( rtn == SUCCESS && scsi_unit_is_ready(SCloop) ) {
> rtn = scsi_eh_retry_command(SCloop);
> if( rtn == SUCCESS ) {
> SCloop->host->host_failed--;
> scsi_eh_finish_command(&SCdone,SCloop);
> }
> }
> /*
> * The bus device reset succeeded, but the unit is not ready.
> * Better not start resetting the bus and kill the system.
> * Certainly it must be a mistake to do a hard bus reset
> * and a hard host reset while disk I/O is fine.
> * Maybe this is a CDROM drive with a bad CD -- aeb.
> */
> if( host->host_failed ) {
> SCloop->host->host_failed--;
> scsi_eh_finish_command(&SCdone,SCloop);
> ourrtn = FALSE;
> goto leave;
> }
> }
> }
> ----------------------------------------------------------------
> (don't take this particular code too seriously - I just want to
> show that at this point: bus device reset failed, we must not
> blindly continue with a bus reset).
>
> Finally, after doing all that it can think of, the scsi_error
> code takes the device off-line. But in cases of removable
> devices we would like it to come back on line when it is
> exchanged. One bad CD-ROM does not mean the drive is bad.
>
> [After typing all this nonsense I tried the above code;
> it was partially successful in that it survived the first
> bad read, but died on the third or fourth with
> panic("Unable to find empty mailbox for aha1542.\n");
> . So, some more cleanup is required in the error_handler.]
>
> Andries
>
>
> P.S. Is detailed information on the Adaptec 1542 available today?
> For example, it would be nice to have an abort routine that
> really worked.
>
> P.S. 2: Quite often a semaphore is allocated on the stack,
> and a pointer to it is left in some structure after the
> stack frame has become invalid. I cannot see places where
> this might cause errors, but it is a bad practice,
> and might cause mysterious errors.
> E.g., one should add
> SCpnt->request.sem = NULL;
> in sr.c.
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.058 / U:0.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site