lkml.org 
[lkml]   [2000]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectCD Burning still busted 2.4.0-test3 - SCSI timeouts
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.

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).

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.

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.

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).

With a 4x burner, fixating typically takes 60 to 90 seconds.
The 30 second timeout on the other commands is really hosing this command.
But their timeouts shouldn't depend on the timeout of another command,
should it? They all fail before they even have a chance to be issued to
their drives. Should these commands be stuck waiting for the burner to
finish ANYWAYS?

I noticed this comment just above scsi_add_timer:

* More Notes: Each scsi command has it's own timer, and as it is added to
* the queue, we set up the timer. When the command completes,
* we cancel the timer. Pretty simple, really, especially
* compared to the old way of handling this crap.

Was this a change from 2.2.x to 2.3.x? Per chance is it not
as simple as it might seem? Maybe it's not a problem in the timeout
logic at all. If I were to come up with a single cause for both
problems, I would guess it's something in the logic issuing commands
to the drives causing the commands to stack up behind that generic
command when they shouldn't.

System Details:

System is a 350 MHz AMD K6 single processor with an Adaptec
AIC7xxx SCSI controller (not a wide controller). It's a SCSI only
system (no IDE drives) and only a single SCSI controller. (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).

Again... 2.2.x never exhibited this behavior and 2.2.16 burns
CD's without this problem. I have not been able to reliably burn CD's
since about mid 2.3.

This thing is broken. What can I do to help FIX IT???

Mike
--
Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
(The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!


-
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.235 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site