Bug 15884
Summary: | cd-burning reduces other simultaneous IO performance | ||
---|---|---|---|
Product: | IO/Storage | Reporter: | Dan Hollocher (danielhollocher) |
Component: | IDE | Assignee: | io_ide (io_ide) |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | danielhollocher, hancockrwd, tj |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | Subsystem: | ||
Regression: | No | Bisected commit-id: | |
Attachments: |
/var/log/kern.log from the sda/testing install, after I burned a cd
fresh boot dmesg |
Description
Dan Hollocher
2010-04-30 15:42:02 UTC
I originally filed a bug on launchpad here: https://bugs.launchpad.net/linux/+bug/262867 You can't have a command outstanding on both the master and slave drive on a PATA channel at the same time. If the software issues a command like "erase disc" to the drive, during the time that command is outstanding no commands can be issued to the other drive on that channel, it's the way PATA works. Now, there may be a difference in what commands the burning software is using or the ordering that results in some of them taking longer than it does in Windows or something. (I don't know the MMC commands that well but I think some of them do have a mode where you can issue the command and poll periodically to see if it's done rather than blocking on the operation until it finishes.) That isn't anything the kernel can do anything about, though - if something issues a command to one drive on the channel that takes a long time, anything wanting to access the other drive just has to wait. Hmm... can you please attach kernel boot log? They don't need to occupy the same channel. Maybe windows is switching the controller to another mode? Created attachment 26235 [details]
/var/log/kern.log from the sda/testing install, after I burned a cd
the I/O errors on sr0 happen when I put a disk in the drive (I've seen this with 3 RW disks. I don't have any other non-RW disks). The kjournald thing happened when I started k3b. I'm pretty sure the later I/O errors happened when the disk burning was completed.
That part of the log isn't very interesting, obviously someone's trying to read from the disc and the drive's saying no (possibly because the disc's still blank). Can you post the output of dmesg after bootup? Created attachment 26252 [details]
fresh boot dmesg
oops, I'm sorry. I didn't realize that kern.log would contain so little.
Ah, it's one of those JMicron PATA controllers. I'm assuming you only have one physical PATA connector on the board, so splitting the devices onto different channels isn't an option. Unfortunately I don't think there's much that can be done about this at the kernel level, it's kind of an inherent limitation of PATA. The burning software might be able to improve on things with different selection/ordering of commands, but the kernel doesn't have any control over that, it just passes the commands through to the drive. Honestly I think the best solution here is to either add another PATA controller to provide another channel, or replace one of the devices with a SATA one. The -immed flag to wodim may improve the situation, if you can make k3b add it to the wodim command line somehow: -immed Tell wodim to set the SCSI IMMED flag in certain commands (load/eject/blank/close_track/close_session). This can be use- ful on broken systems with ATAPI harddisk and CD/DVD writer on the same bus or with SCSI systems that don’t use discon- nect/reconnect. These systems will freeze while blanking or fixating a CD/DVD or while a DVD writer is filling up a session to the minimum amount (approx. 800 MB). Setting the -immed flag will request the command to return immediately while the opera- tion proceeds in background, making the bus usable for the other devices and avoiding the system freeze. This is an experimental feature which may work or not, depending on the model of the CD/DVD writer. A correct solution would be to set up a correct cabling but there seem to be notebooks around that have been set up the wrong way by the manufacturer. As it is impossible to fix this problem in notebooks, the -immed option has been added. A second experimental feature of the -immed flag is to tell wodim to try to wait short times while writing to the media. This is expected to free the IDE bus if the CD/DVD writer and the data source are connected to the same IDE cable. In this case, the CD/DVD writer would otherwise usually block the IDE bus for nearly all the time making it impossible to fetch data from the source drive. See also minbuf= and -v option. That is an awesome find Robert! I will test and report back. Btw, I tested with nerolinux, and that performs allot better, so it looks like you are correct. Testing with -immed should firm that up. Tested and confirmed. Here are directions on how to apply this to k3b (for others that may stop by): Settings > Configure K3b... > Programs > User Parameters Click near cdrecord, and add the option -immed. You may need to ensure that cdrecord is selected by: Settings > Configure K3b... > Advanced > Show advanced GUI elements During the burning setup, you will have an option to select cdrecord. |