Gentoo-dev-sources, Hotplugging, IRQ #11, GAG

ginipigginipig OH, NOES
edited July 2004 in Science & Tech
Yeah, I took the plunge into the 2.6.x world. From what I've read, 2.6.x seems to be more efficient (read: faster) when it comes to VM-management, FS-usage, etc.

So far, I'm relying on my 2.4.25 kernel (via Grub) to get me back in the game. 2.6.x boots fine until it hits "starting USB & PCI hotplugging". A "Disabling IRQ #11" message accompanies the system halt (well, actually, I can still switch VTs, but there is no output). Usually, I'd find the offending module/hardware, and configure my kernel to reflect the changes made.

'Tis not the case. From dmesg output (2.4.25), Irq #11 is used by my Windows.O/S Raid Array. My Grub contains "noraid" kernel parameters, so this is strange to say the least. In my attempts to work around the hotplugging issue, I appended a "nohotplug" parameter to Grub.config. No Go. Same error messages. Same nonsense.

What am I to do?! Using my 2.4.25 kernel, I can see that "enabling .. hotplugging" takes place at the end of the bootup cycle. This is driving me nuts. If I knew what to look for, I'd fix it up. Trouble is, short of perusing all of the startup scripts (and making sure they're properly used by both kernels,) I don't know how to proceed. Meanwhile, I'm googling my ass off.

Help me SM-kenobi, you're my only hope. :sad2:

Comments

  • Straight_ManStraight_Man Geeky, in my own way Naples, FL Icrontian
    edited March 2004
    I am not he, but can tell you it is basicly doing a system probe, seeing the RAID and possibly a network card on IRQ 11 or a video card (that is not normal, but has happened to me) and sensing an IRQ conflict. Has happened to me before, especially with a board that has IDE RAID os SATA where the kernel does not have a driver that its hardware probing finds.

    I did not get one thing:

    If 2.4.25 boots, can you go into console and do this as sudo root???

    modprobe -aq | modprobe.txt

    lpr modprobe.txt

    and then use that list to build modules for a compiled kernel???

    At the very least, you will discover what is on IRQ 11 for that kernel that does work.... Also, did you compile your kernel with stock modules, or did you custom compile it??? Sometimes the best way is a resuce CD boot into the malfing install, BTW, and a Live CD can sometimes get you access into the linux file system you are trying to look at. Then, if you mount and descend into it, you can read the detailed logs and see what they say.

    This is likely to be a module probe hang due to drivers not meshing with physically present resources, and stacked resources on one or more IRQs. Trick will be to find out WHAT resource is stacked against what, but NIC and video are likely to be problem with a total hang (one or both) or a south bridge running embedded video, NIC, and RAID, and a BIOS that uses IRQ 11 to point to the south bridge in the chipset.

    At a guess, it is not recognizing the south bridge, for starters, if you have an embedded video card and not a PCI or AGP card. Try also noacpi as boot command if nothing rings a bell with the above. AND, if the BIOS has an option to disable uPNP, use it please. uPNPwill virutalize IRQWs sometimes, and drive a kernel wonky and batty if it is of Linux or BSD kinds. My XP boxes run with uPNP OFF.

    John D.
  • LIQuidLIQuid Raleigh, NC
    edited March 2004
    i dont even use hotplugging with 2.6.3 ;/ or any 2.6 kernel for that matter
  • ginipigginipig OH, NOES
    edited March 2004
    Thanks for the replies, guys.

    These are the commands I've tried:
    lspci ;; lsmod ;; cat /proc/interrupts ;; cat /proc/ioports ;; less /var/log/dmesg

    Turns out that IRQ #11 was assigned to my raid-array, as I originally thought. Every other piece of hardware (besides the Plantronics dsp 500 -> Alsa-config is a completely different story) checked out fine in terms of interrupts and module-loading.

    I delved deeper into my /var/log/message, and here's what I found:
    Mar  8 11:04:02 thugstah libata version 1.00 loaded.
Mar  8 11:04:02 thugstah sata_sil version 0.52
Mar  8 11:04:02 thugstah ata1: SATA max UDMA/133 cmd 0xF988C080 ctl 0xF988C08A bmdma 0xF988C000 irq 11
Mar  8 11:04:02 thugstah ata2: SATA max UDMA/133 cmd 0xF988C0C0 ctl 0xF988C0CA bmdma 0xF988C008 irq 11
Mar  8 11:04:03 thugstah ata1: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3c01 87:4003 88:207f
Mar  8 11:04:03 thugstah ata1: dev 0 ATA, max UDMA/133, 72303840 sectors (lba48)
Mar  8 11:04:03 thugstah irq 11: nobody cared!
Mar  8 11:04:03 thugstah Call Trace:
Mar  8 11:04:03 thugstah [<c010cdea>] __report_bad_irq+0x2a/0x90
Mar  8 11:04:03 thugstah [<c010cedc>] note_interrupt+0x6c/0xb0
Mar  8 11:04:03 thugstah [<c010d191>] do_IRQ+0x121/0x130
Mar  8 11:04:03 thugstah [<c010b4f4>] common_interrupt+0x18/0x20
Mar  8 11:04:03 thugstah [<c0128ac0>] do_softirq+0x40/0xa0
Mar  8 11:04:03 thugstah [<c010d16d>] do_IRQ+0xfd/0x130
Mar  8 11:04:03 thugstah [<c010b4f4>] common_interrupt+0x18/0x20
Mar  8 11:04:03 thugstah [<c0119894>] delay_tsc+0x14/0x20
Mar  8 11:04:03 thugstah [<c02c1632>] __delay+0x12/0x20
Mar  8 11:04:03 thugstah [<f999327d>] ata_busy_sleep+0x1d/0x130 [libata]
Mar  8 11:04:03 thugstah [<f9993b32>] ata_dev_set_xfermode+0x92/0x180 [libata]
Mar  8 11:04:03 thugstah [<f9993c72>] ata_dev_set_udma+0x52/0xc0 [libata]
Mar  8 11:04:03 thugstah [<f999323f>] pata_phy_config+0x3f/0x60 [libata]
Mar  8 11:04:03 thugstah [<f9993065>] ata_port_reset+0x85/0xc0 [libata]
Mar  8 11:04:03 thugstah [<f9994ed9>] ata_thread_iter+0x59/0x130 [libata]
Mar  8 11:04:03 thugstah [<f9994ff6>] ata_thread+0x46/0x100 [libata]
Mar  8 11:04:03 thugstah [<f9994fb0>] ata_thread+0x0/0x100 [libata]
Mar  8 11:04:03 thugstah [<c0109289>] kernel_thread_helper+0x5/0xc
Mar  8 11:04:03 thugstah
Mar  8 11:04:03 thugstah handlers:
Mar  8 11:04:03 thugstah [<f9994cb0>] (ata_interrupt+0x0/0x140 [libata])
Mar  8 11:04:03 thugstah Disabling IRQ #11
Mar  8 11:04:03 thugstah ata1: dev 0 configured for UDMA/133
Mar  8 11:04:03 thugstah scsi0 : sata_sil
Mar  8 11:04:03 thugstah ata2: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3c01 87:4003 88:207f
Mar  8 11:04:03 thugstah ata2: dev 0 ATA, max UDMA/133, 72303840 sectors (lba48)
Mar  8 11:04:03 thugstah ata2: dev 0 configured for UDMA/133
Mar  8 11:04:03 thugstah scsi1 : sata_sil
Mar  8 11:04:03 thugstah Vendor: ATA       Model: WDC WD360GD-00FN  Rev: 1.00
Mar  8 11:04:03 thugstah Type:   Direct-Access                      ANSI SCSI revision: 05
Mar  8 11:04:03 thugstah scsi.agent[3690]: how to add device type= at /devices/pci0000:00/0000:00:08.0/0000:01:0b.0/host0/0:0:0:0 ??
Mar  8 11:04:03 thugstah SCSI device sda: 72303840 512-byte hdwr sectors (37020 MB)
Mar  8 11:04:03 thugstah SCSI device sda: drive cache: write through
Mar  8 11:04:33 thugstah /dev/scsi/host0/bus0/target0/lun0:<3>ata1: DMA timeout, stat 0x4

    Now, I'm pretty sure that this is an error message (the "irq 11: nobody cared!" line gave it away.) I've perused most boards, and I've come to the conclusion that the Silicon Image 3112 (latest bios leeched from short-media) doesn't play nicely with the 2.6.x modules (none to date.)

    This is a nut-breaker, no doubt about it.

    I don't believe that Irq-mishandling had anything to do with it. Either I have to enable Highmem (which is my next task, seeing as how I neglected to enable it in the 3-4 odd years that I've been using *nix,) or wait until either I or some other developer properly codes the modules (I probably won't; I've never taken any comp classes, let alone programming courses, ever.)

    What do you guys recommend that I do? For those of you who have struggled with Raid/DMA/2.6.x kernels in the past, what steps did you take to remedy the problem?

    I'll try to research some more, but I'll check back frequently.
  • mardukmarduk
    edited June 2004
    I just encountered this problem for the first time, after having used 2.6 since the pre* era. But it just showed up for me in 2.6.7 (both development & gentoo-dev). I submitted a bug at Gentoo's bugzilla: http://bugs.gentoo.org/show_bug.cgi?id=54413 but the work-around, for me at least, seems to be to add ehci_hcd to /etc/modules.autoload.d/kernel-2.6. Perhaps what is happening is that the ehci_hcd module is disabling irq 11 which is already in use? The weird thing is that /proc/interrupts still shows 11 being used for a lot of things.
  • skrykingskryking
    edited July 2004
    could this be related to the change of the 8K to 4K stacks in this version of the kernel?

    Skryking
Sign In or Register to comment.