I just installed a second harddrive on the second channel of my asus-a7v motherboard. Whenever I put high IO-load on either of hde, or hdg the system eventually locks up. The system is somewhat more stable if I disable DMA but that only helps so long, eventually it locks up anyway. I've tried this with 2.4.26-gentoo-r9 and 2.6.8-gentoo-r1 with the same results. The problem looks identical to the above-mentioned URL, with the difference that I'm running 2.4.x kernel now, and although I've found various mentions of this on the net, they all say that this is not an issue with 2.4.x kernels, just 2.6.x ones, unfortunately, this is not the case... Reproducible: Always Steps to Reproduce: 1. Install HDE on primary channel of a pdc20265 chip 2. Install HDG on secondary channel of a pdc20265 chip 3. Start a big filecopy between the two harddrives, or any other activity that causes high IO-load. Actual Results: System lockup, IO-errors Expected Results: Allowed me to copy the files in peace. ---- AMD-DURON 700MHz Asus A7V MB, BIOS ver. 1011 ---- /dev/hde: ATA device, with non-removable media Model Number: WDC WD300BB-32AUA1 Serial Number: WD-WMA6R1223494 Firmware Revision: 18.20D18 /dev/hdg: ATA device, with non-removable media Model Number: ST3200822A Serial Number: 3LJ1R0Q1 Firmware Revision: 3.01 ---- Portage 2.0.50-r9 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3.20040420-r1, 2.4.26-gentoo-r9) ================================================================= System uname: 2.4.26-gentoo-r9 i686 AMD Duron(tm) Processor Gentoo Base System version 1.4.16 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=athlon -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=athlon -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://ds.thn.htu.se/linux/gentoo http://ftp.du.se/pub/os/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X alsa apm avi berkdb cdr crypt cups esd foomaticdb gdbm gif gpm gtk gtk2 imlib java jpeg libg++ libwww mad mikmod mmx motif mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png python quicktime readline sdl slang spell ssl tcpd truetype x86 xml2 xmms xv zlib"
Hello, I'm not screaming YES, just yet, but it seems as if the following URI: http://forums.gentoo.org/viewtopic.php?p=1417524#1417524 solved my problem as well. The lines in question are : Edit : /usr/src/linux/drivers/ide/ide-io.c and change the lines as indicated : - if (hwif->irq != masked_irq) + if (masked_irq != IDE_NO_IRQ && hwif->irq != masked_irq) - if (hwif->irq != masked_irq) + if (masked_irq != IDE_NO_IRQ && hwif->irq != masked_irq) I performed the above changes and it "appears" to have worked. I'll do some more testing...
Please paste in the output of `cat /proc/interrupts`.
Hello, I've successfully managed to transfer some 40 GB of data, 20GB from one drive to the other and back again, without hickups, and without any strange entries to dmesg. I don't know if the applied patch can be regarded as a proper fix for whatever problem I had, but after applying it, I'm unable to reproduce the problem. Output from /proc/interrupts: gentoo mp3 # cat /proc/interrupts CPU0 0: 1425082 XT-PIC timer 1: 7122 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 1319433 XT-PIC eth0 9: 0 XT-PIC Ensoniq AudioPCI 10: 1553067 XT-PIC ide2, ide3 11: 267968 XT-PIC nvidia 12: 67914 XT-PIC PS/2 Mouse 15: 13 XT-PIC ide1 NMI: 0 LOC: 1425020 ERR: 453
Hm, ide2 and ide3 are on the same interrupt which is possibly why you were getting this problem. Either way, this bug exists in the upstream kernel so could you file a bug at http://bugme.osdl.org with the patch so the upstream developers can get it included or look further at the issue? Thanks!
Sure, will do.
