Hi,
On 06-Aug-99 Chiaki Ishikawa wrote:
> Have you tried to limit the maximu # of tag for samsung drive?
> I and others have experienced tag related problems sometime ago
> with Samsung 2gb drive (not sure if it was Ultra, etc..)
Yes I even switched off (depth =1) tagged queing. That got me rid of the
occasional tag problem with the drive. But it doesn't of course cure the
bad blocks.
Unfortunately I can't "find" these bad blocks during a bios check or
format, because then the drive will do the 16 retries and seems to get the
data at some point.
Right now I'm more concerned with a reason (and maybe fix?) why the block
errors of the one drive can prevent cdrecord from writing to CD-R.
> The model I have is:
> Vendor: SAMSUNG Model: WN321010S Rev: 1224
Mine is at least not the same:
Vendor: SAMSUNG Model: WN32162U Rev: 0100
Type: Direct-Access ANSI SCSI revision: 02
This one didn't lock up with tagged queuing but caused occsasional tag
reordering (Which of course will block the complete scsi layer for a while
an cause bad CDs).
Therefor I already switched off tags for the Samsung.
But I got buffer underruns without any message in my system log -- no tag
problems, no resets,.... Only after a very long time when cdrecord times
out (log message) the CD-R is 'dead' until reboot. Seems the Teac 56s takes
buffer underruns in real write mode as an offence and starts sulking ;-/
(during a simulation it recovers flawlessly).
I hope to get a (warranty) replacement for the drive sometime soon, but I'm
not sure if a drive which won't fail the bios check and which behaves
mostly moderately fine will be accepted as defect.
The only thing I can claim for sure is 450+ grown defects. I can't switch
the drive to '1 retry' permanently because that drive refuses *any*
permanent change to it's settings. The local dealer told me more or less
it's in the specs -- if I change internal settings it's my problem.
If I could deliver a 'proof' that the drive is ruining the scsi bus timing
it could help persuading them the drive is broken.
And maybe there is some problem in the scsi layer which get's triggered by
this drive -- some silent timeout? Can the scsi layer be blocked for a
little while (~0.2s) because of the drive? disconnection is on for all bus
units (now 1 quantum, 1 IBM, Teac CD-R, Plex CDrom and sometimes an old
exabyte tape -- usually all behaving well together).
Can the drive reconnect without really having the data ready and then
keeping everything busy until it finaly recovers the data?
K.-H.
-----------------------------
Karl-Heinz Herrmann
E-Mail: [EMAIL PROTECTED]
-----------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
