On Sat, Mar 08, 2003 at 01:55:28PM -0500, Elton Woo wrote:
He can save himself a lot of headaches and wasted time by looking at Bug # 84160 "I/O error while burning an .iso file with kernel >=2.4.20..." Actually, it's not just a problem burning just ISO files but *any* data files at *any* speed.
We've done a lot of work on this issue. There are several issues in play:
1) IDE sucks: When a command is issued to the CD/DVD buring device on the bus, no other commands placed on the bus (does not matter if it is to the CD/DVD burner or another device on the same bus) will complete. The command will time out and a bus reset will be issued.
2) New IDE code: IDE bus resets take longer than they did with the previous IDE code
3) no locking: With Phoebe beta 3 there is no way to gain exclusive control of the CD/DVD recorder
4) More than one device maps to the physical device: even if there was a way to gain exclusive access to /dev/sgN, operations to the corresponding /dev/scdN device could interfere with burning
5) KDE/GNOME are set up to poll CD/DVD drives: every 5 seconds they will issue commands to the drive via CDROM_DRIVE_STATUS ioctl to see if a disc is present in the drive.
So: if applications are polling the drive while it's burning, we can get resets that look like:
scsi : aborting command due to timeout : pid 18793, scsi0, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00 SCSI host 0 abort (pid 18793) timed out - resetting SCSI bus is being reset for host 0 channel 0. hdc: ATAPI reset complete
We had a few options on how to address this. We could use user-space locking mechanism like lockdev to lock the device (after writing some code to make the sg device back to the scd device, because that's the common access path). That looked to be a bit of work and hard to get right on the first try.
Another option was to change the semantics of the open() call on the scd device such that it would fail if the O_EXCL flag was set in the mode parameter and any other process had an open file descriptor to the device (including if the device is mounted). The kernel change to make that happen was very simple.
Once the kernel had a way to lock out new open() calls to a device if it's already being used, we had to modify the applications which are not playing well together. The CD/DVD recording apps had to reverse map the sg device to the scd device and hold it open while it is burning. To make the burning apps more robust we also do the open with O_EXCL in a retry loop, so we know that we're the only user of the device.
Finally, the CD/DVD monitoring programs had to be modified to call open() with O_EXCL on the devices they are polling, so if a burn is happening they won't try talking to the device.
There is one more issue that has been fixed. Many people reported hard lockups during burns. We found that this was happening on SMP machines during the IDE bus reset (that was being caused by the party described above). This lockup has been fixed.
We've found one more IDE bus reset lockup on SMP machines, but I believe we're still having some problems finding the root cause of that.
Short answer: you should be able to burn much better if magicdev/autorun isn't running.
Cheers,
Matt [EMAIL PROTECTED] -- Matt Wilson Manager, Base Operating Systems Red Hat, Inc.
Thanks for the information about the problems and paths to resolve the issues.
Since my burned psyche and phoebe discs seemed to have errors relating to resetting the buss that were actually reported on the disc during the mediacheck on the laptop, I'll kill automount and magicdev, before burning, to see what the discs do on my laptop computer.
I assume that this might have been a problem within RH8 also.
Jim
--
Nothing will dispel enthusiasm like a small admission fee.
-- Kim Hubbard-- Phoebe-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/phoebe-list
