Hey folks, I having a problem similar to one of the commenters on bug #13347. But that report in general is kinda confusing, and it seemed like the devs had trouble understanding the issue. One possibility is that the issue that I and the commenter have may not be the same as the original bug in 13347. I also have a reliable way to trigger the bug in a bad way, just burn a cd. So, I am posting this new bug report. Basically, my system feels a bit sluggish, and when I try to burn a CD, my system becomes unusable. I will explain in further detail after I describe my setup. My system: ASUS P5B motherboard a 500GB SATA drive connect through one of the SATA ports (sda) an 60 GB PATA drive, connect as the master on the single Jmicron IDE (sdb) a Verbatim CD-RW, connected on the slave of the same IDE My OSs: I have windows on the first partition of sdb I have my main Ubuntu install on another partition of sdb (linux version 2.6.31) I have a testing Ubuntu install on one of the partitions of sda (linux version 2.6.32) Now, I have always noticed that my main felt a bit sluggish. Windows felt faster, and I would just chock it up to "weirdness". I suspect that I'm getting poor performance in general, but it really shows up when I'm burning a disk. My computer becomes unusable, as any IO operations no matter how small end up having several second wait times. I have to be careful just moving a window around. I tested on windows, and I can burn a disk, defrag the drive, and open open office all at the same time. The system is correspondingly sluggish, but that is to be expected. I get no lockups like I do on linux. I have had this issue for the life of the computer, accross several ubuntu releases. I have also tester a kernel from the ubuntu mainline ppa of version 2.6.33. As you can see, I haven't tried downloading the source code and compiling myself yet. I don't know if that makes a difference. Here are some illuminating tests. I was booted on the nice drive (sda) with the testing install. $ sudo hdparm -tT /dev/sdb /dev/sdb: Timing cached reads: 2146 MB in 2.00 seconds = 1073.83 MB/sec Timing buffered disk reads: 128 MB in 3.03 seconds = 42.27 MB/sec $ sudo hdparm -tT /dev/sda /dev/sda: Timing cached reads: 2308 MB in 2.00 seconds = 1154.93 MB/sec Timing buffered disk reads: 284 MB in 3.01 seconds = 94.50 MB/sec I started the burn process, and caught this test while it was erasing the CDRW: /dev/sdb: Timing cached reads: 2294 MB in 2.00 seconds = 1147.90 MB/sec Timing buffered disk reads: 2 MB in 88.41 seconds = 23.16 kB/sec During the burn process, which displays a speed of 0.7MB/s: $ sudo hdparm -tT /dev/sdb /dev/sdb: Timing cached reads: 908 MB in 2.00 seconds = 453.90 MB/sec Timing buffered disk reads: 6 MB in 3.87 seconds = 1.55 MB/sec $ sudo hdparm -tT /dev/sda /dev/sda: Timing cached reads: 2254 MB in 2.00 seconds = 1127.28 MB/sec Timing buffered disk reads: 282 MB in 3.00 seconds = 93.98 MB/sec So while burning on the slave of the IDE, I loose almost all my "buffered disk read" performance for the master IDE channel! Does that make sense? If I burn a cd at 1MB/s, it should not take up 41MB/s bandwidth.
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.