lkml.org 
[lkml]   [2000]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: CD Burning still busted 2.4.0-test3 - SCSI timeouts
"Michael H. Warfield" wrote:
>
> Ok gang...
>
> This has been busted for most of 2.3.x and I've complained about
> it a couple of time in the past, each time digging deeper into the problem.
> Note... This works fine on 2.2.16 and now I'm having to drop back to
> 2.2.16 every time I want to burn CD's. This sucks.

I have had no problems burning CD-Rs in the 2.3/2.4 series but
I have my Yamaha 4416S on a different adapter from my main
disk.

> The problem is that the system goes in the weeds (read that as slow
> as all hell and jerky) while burning the CD and the the fixation always
> seems to abort with a SCSI timeout after about 30 seconds, even though
> cdrecord sets the SCSI timeout on the fixation command to several minutes.
>
> I traced through the kernel code earlier and found that the generic
> scsi command to fixate the disk does have the correct timeout value.
> The problem is that other SCSI commands stacked up behind it end up
> timing out because their smaller timeout values are initialized and
> timers started by "scsi_add_timer()" when they are entered into the
> queue rather than when they are issued to the drive (thats ONE problem -
> the problem that results in the early timeout).

Ouch, that seems like a problem. Cdrecord doesn't queue commands to
my knowledge (haven't checked the last few alphas) so that will
probably be IO to your disk queued up behind it. The Yamaha 4416S
neither supports disconnect nor tagged queueing.

> I can "kludge around" that problem by going into scsi_error.c
> and changing scsi_add_timer so the timeout values are really big
> (multiplied by 4). But that doesn't solve the other problem and it's
> certainly not the CORRECT solution to the timeout problem anyways.

Agreed.

> The other problem (the system performance and jerky response)
> seems to be some sort of problem in the queue with the generic access
> used by the CD burner. Now this, I'll admit, is pure conjecture on
> my part, but it seems like the generic SCSI action is holding up all
> the other commands in the queue, including commands for other drives
> which might otherwise be processed. So, during the burning process,
> everytime we are waiting on a burner command to complete, my system
> can't get at swap or other disk access, so it acts slow and jerky.
> It's also flat out DEAD during the 30 second timeout before the
> fixation fails.

Well the "jerkiness" has been a latter 2.3 series "feature" that
we don't think the SCSI subsystem is responsble for. Happily
this seems to be improving in the 2.4.0-test3-pre series.
In your case, if the cdwriter monopolizes the SCSI bus which
contains your disks for over a minute, it's no surprise that
your system may be a little unresponsive for that period.

The system being completely DEAD for 30 seconds is "normal"
when a SCSI bus reset occurs on an all SCSI system. The typical
response to a timeout is a SCSI bus reset.

> When a long timeout command (like fixating with a several minute
> timeout) gets in the command, the disk commands end up timing out
> before they ever even get issued to the drives. That then aborts
> everything in the SCSI queue, resets the SCSI bus, and screws up
> everything. I see it as an abort of the fixation command right at
> about 30 seconds (+- 2 or 3 seconds).

#define SD_TIMEOUT (30 * HZ)
[from drivers/scsi/sd.c]

[snip]

> (would it
> help to have the burner on a second controller?) I've got three SCSI
> drives, a SCSI zip drive and a 4x4x6 CD-R drive (YAMAHA Model CRW4416S).

Yes, having a second SCSI controller would certainly help. Even
something like an old aha1542 (16 bit ISA) would help. Leave your
disks on the current adapter and move the ZIP drive and especially
the 4416S.

Doug Gilbert

-
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.tux.org/lkml/

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