Red Hat Bugzilla – Bug 169569
Bad interactive performance under heavy disc I/O with 2.6.13-1.1526_FC4
Last modified: 2015-01-04 17:22:20 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7
Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start Rhythmbox
2. dd if=/dev/zero of=test bs=1M count=1024
Actual Results: Symptoms include:
1. Rhythmbox stops playing or skips for a while and then stops
2. Switching workspaces can be delayed for up to 1 or more minutes
3. Mouse movement is very jerky and precision becomes impossible
4. pdflush and kjournald use up lots of CPU as shown in top
Expected Results: Rhythmbox should keep playing.
System should still be usable interactively.
It may also be worth noting that if you kill dd then pdflush and kjournald stay chewing cycles until /bin/sync is run manually.
This does not happen with kernel-2.6.12-1.1398_FC4, but I am unable to boot any kernel in between so I am not sure if it affects any later 2.6.12 kernels.
The machine is a ThinkPad R52.
I suspect it may have something with writes into an ext3.
I see the same effect when I run mkisofs. However, any other
disk activities have no effect on Rhythmbox, e.g. find, tar.
Kernel compiles do no harm either. It was like that since FC4 shipped
(I am on 2.6.13-1.1580_FC5 now)
Maybe, but I can also get the same effect when loading a VMware guest, which I
would have thought was mostly reads.
Mass update to all FC4 bugs:
An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (188.8.131.52). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.
Please retest with this update, and update this bug if necessary.
I'm experiencing this as well. I installed kernel-2.6.13-1.1526_FC4 last night,
and my machine seemed sluggish, going back to kernel-2.6.12-1.1456_FC4 restored
the expected behavior.
In my case it seems like all disc I/O is slow, starting at boot-up. Using the
very "scientific" method of looking at the drive-light: under 2.6.12-1.1456_FC4
the light is solid during I/O, but under 2.6.13-1.1526_FC4 is flashes rapidly...
This behavior seems to be hardware dependent, this is the affected HW configuration:
--- DELL-Precision-M70 --- /sbin/lspci
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express
Processor to DRAM Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile 915GM/PM Express PCI Express Root
Port (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI
Express Port 1 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
USB UHCI #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
USB UHCI #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
USB UHCI #3 (rev 03)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
USB UHCI #4 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3)
00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW
(ICH6 Family) AC'97 Audio Controller (rev 03)
00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem
Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 03)
00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus
Controller (rev 03)
01:00.0 VGA compatible controller: nVidia Corporation NV41 [Quadro FX Go1400]
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit
Ethernet PCI Express (rev 01)
03:01.0 CardBus bridge: Texas Instruments: Unknown device 8036
03:01.5 Communication controller: Texas Instruments: Unknown device 8038
03:03.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)
Yes, this occurs with both 1525 and 1526 and as with Peter's experience, earlier
kernels do not display this behaviour.
i am running debian sarge/testing with kernel 2.6.11/12 and 13. my acer
travelmate 4650 is using the same ide controller:
schleppi:~# lspci | grep -i ide
0000:00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller
an i am using ext2 instead of the above reported ext3.
i just came along this bug report and tought i'd add my 2 cents.
Happens to me too.
Symptoms: commands cp and mv cause machine to freeze for very long periods,
kjournald+mv|cp+pdflush+kblockd take up 100% CPU.
machine: IBM Thinkpad T43
chipset: Intel Corporation Mobile 915GM/PM/GMS/910GML Express
If there's any other information you would like me to extract I'll be happy to
I fixed my laptop (DELL D610) by adding ide0=noprobe to the kernel line in
I don't know why I should have to do that.
For the sake of completeness, my controlle is also:
IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03)
ide0=noprobe worked for me too.
Only visible difference is that my hard disk is now seen as /dev/sda, whereas
with the problem kernel it was seen as /dev/hda. (Older kernels saw it as /dev/sda.)
ide0=noprobe worked for me also...
There is this difference in /var/log/messages:
Oct 8 05:21:31 loki kernel: SCSI subsystem initialized
Oct 8 05:21:31 loki kernel: ata: 0x1f0 IDE port busy
Oct 8 05:21:31 loki kernel: ata: 0x170 IDE port busy
Oct 8 05:21:31 loki kernel: ata_piix: probe of 0000:00:1f.2 failed with error -16
Oct 8 18:20:29 loki kernel: SCSI subsystem initialized
Oct 8 18:20:29 loki kernel: ata: 0x170 IDE port busy
Oct 8 18:20:29 loki kernel: ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma
0x18C0 irq 14
Oct 8 18:20:29 loki kernel: ata1: dev 0 ATA, max UDMA/100, 117210240 sectors:
Created attachment 119743 [details]
dmesg for 2.6.13-1.1526_FC4 without/with "ide0=noprobe"
"ide0=noprobe" seems to have solved the problem for me as well. Details in
attachment to comment #13.
The latest update kernel (2.6.13-1.1532_FC4) no longer displays this behaviour here.
Yup, 1532 fixed it for me too.