Messages in this thread | | | Date | Mon, 10 Jul 2000 23:29:14 -0400 | From | "Michael H. Warfield" <> | Subject | CD 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/
| |