Hi,
Marc SCHAEFER <[EMAIL PROTECTED]> wrote:
> Yes, knowing that some drives will auto-replace blocks and this can
> take some time (upto 10-15 seconds on old drives, much less on new
> drives).
>
> However, this kind of delay is not going to make Linux timeout.
Can relocating blocks cause short scsi blocks?
I have the following problem:
I have (apart from other things) 1 2GB Samsung Ultra drive and a Teac CDR56s on
an adaptec 2940UW.
Everything worked well for 2 or 3 weeks (~40 burned CD's mixed audio and data).
After that I got more and more often buffer underruns of the burner internal
buffer -- the cdrecord buffer was at 99+% at the same time.
Now I know (after a lot of error tracking) that this Samsung drive is developing
defect sector at a rapid pace (grown defect list grown from 30 to 450+ in
days). So I never got an error message (medium error or something) from the
linux scsi.
Every time I access (burn from or just access while burning from somewhere
else) this Samsung drive, a burn in 6x will fail almost certainly at some
random time. When burning from the Samsung at a reproducable random place.
cdrecord offers some timing information on the scsi commands acualy sent to the
burner and these have after a row of completely normal timing a very long
completion time (0.2s or something like that).
If this happens repeatedly the internal buffer is empty. According to Joerg
Schilling (author of cdrecord) cdrecor will write as often as it can to the
burner.
So it seems that getting read errors on drive A can block writing to the CDR
even if there are 10MB of data in RAM memory.
Is this possible?
By the way: The Samsung drive is configured for 16 retries on read/write
errors. If I set it to 1 and run badblocks it's dead after 1 minute and wont be
recognised on the scsi bus on reboot. A powercycle clears it again.
Strangely during my error tracking I didn't get the errors in Win95 -- there I
could burn from the dying drive quite happily. That's what's giving me the idea
that something in the linux scsi (aic7xxx) is coughing on these timing problems
but it shouldn't be unavoidable.
I still have the drive in my box if I could try to track whats happening. But I
already tried to tell aic7xxx to be more verbose but didn't get much useful
information from that.
K.-H.
----------------------------------------------------------
E-Mail: Karl-Heinz Herrmann <[EMAIL PROTECTED]>
Date: 06-Aug-99 Time: 16:38:54
----------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
