The behavior you see will depend a lot on which scsi card you are using,
which set of error handling code it uses, how well it implements the various
functions for error handling, and whether there are bugs in the error
handling.
With 2.3.35 (plus a few of my patches), I was able to take a faulty
cdrom, and essentially do something like:
tar cf - * | tar tvf -
It paused a number of times as it retried commands a couple of times, and
finally at one point it threw up it's hands and ended up taking the device
offline. In any event, I ended up with a live command prompt at the end,
and no other ill effects.
-Eric
----- Original Message -----
From: Paul W. Abrahams <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 04, 2000 11:39 AM
Subject: SCSI CDROM problem freezes system
> I have a SCSI CDROM drive (NEC 466) that apparently had a dirty lens.
> The result was that when I attempted to read from it, at some point my
> system (SuSE Linux 6.2 with kernel 2.2.13) would freeze totally, with
> both mouse and keyboard dead. I was able to get this behavior, among
> other ways, by logging in as root (not within X) and typing
>
> dd if=/dev/scd0 of=/dev/null
>
> The drive light would flash for a little bit and then go out. The
> machine was then fully hung; even CapsLock had no effect (that's my
> usual test for a hung keyboard). Only a hard reboot would restart
> it. Interestingly, if I mounted the drive and then attempted to read
> from it, I would encounter the same problem -- but then I would be
> able to eject the disk, which normally I can't do with a mounted
> drive.
>
> I was able to get the drive running again by using a cleaning CDROM in
> it, in audio mode.
>
> So what's the problem, you may ask?
>
> The problem is that although a malfunctioning drive certainly can't be
> expected to yield data it can't read, the malfunction should not
> freeze the system entirely; it should just produce some kind of error
> message. Fortunately I'm not running a system in a critical
> environment; but if I was, this kind of misbehavior would be a serious
> hazard. What's needed, I think, is some kind of time-out test; if the
> test times out, then the operation is cleanly aborted.
>
> Paul Abrahams
> [EMAIL PROTECTED]
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]