After you fixed bug #2243 one of my system got fixed, still one to go. This is a Asus CUV266-DLS, Dual P3 with Via Apollo Pro 266 chipset. Don't know what info you want or need, I'll attach acpidmp, dmesg, interrupts and lspci. Hope you'll figure out this one as well :) Thanks.
Created attachment 3145 [details] dmesg from 2.6.7-rc3 with acpi
Created attachment 3146 [details] interrupts from 2.6.7-rc3 with acpi
Created attachment 3147 [details] lspci -v
Created attachment 3148 [details] dsdt
Created attachment 3149 [details] lspci -vv Just found out that it is lspci -vv you need. Sorry.
Uhh, I just realised that my interrupts does not match my summary for this bug. The reason is that I made the dmesg and interrupts with patch from bug #2574, which moved my usb interrupt from 9 to 11. Sorry about that.
/proc/interrupts shows USB getting more interrupts than eth0. Is this due to devices plugged into USB? Does USB track eth0 1:1 if you have no USB devices plugged in? since you're using the patch from the previous bug report, all the links are disabled except LNKD on IRQ11. There is 1 use of LNKD in an APIC mode _PRT: Package (0x04) { 0x0011FFFF, 0x03, \_SB.LNKD, 0x00 } }) 0000:00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 18) (prog-if 00 [UHCI]) pinD 0000:00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 18) (prog-if 00 [UHCI]) pinD 0000:00:11.4 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 18) (prog-if 00 [UHCI]) pinD eth0 is here: 0000:00:05.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) pinA which uses LNKD in PIC mode, but is hard-coded to IRQ19 in IOAPIC mode. 0000:00:0c.0 Multimedia controller: Philips Semiconductors SAA7134 (rev 01) pinA also uses LNKD in PIC mode and IRQ19 in IOAPIC mode -- though I don't see a driver loaded for this device. --- Can you simplify the system and still see the problem? ie. disable all optional devices in the BIOS and exclude the drivers from the kernel except usb and eth0? I'm sort of curious where the yenta devices hang... Also, if you boot with acpi=off, does MPS configure the interrups the same way as ACPI? Do you see the problem in that case?
>/proc/interrupts shows USB getting more interrupts than eth0. >Is this due to devices plugged into USB? >Does USB track eth0 1:1 if you have no USB devices plugged in? No... USB seems to get some more. With no usb devices I have after a while with network activity: usb: 107456 eth: 77301 >since you're using the patch from the previous bug report, >all the links are disabled except LNKD on IRQ11. > >There is 1 use of LNKD in an APIC mode _PRT: >Package (0x04) { 0x0011FFFF, 0x03, \_SB.LNKD, 0x00 } }) > >0000:00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev >18) (prog-if 00 [UHCI]) pinD >0000:00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev >18) (prog-if 00 [UHCI]) pinD >0000:00:11.4 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev >18) (prog-if 00 [UHCI]) pinD > >eth0 is here: >0000:00:05.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) pinA >which uses LNKD in PIC mode, but is hard-coded to IRQ19 in IOAPIC mode. > >0000:00:0c.0 Multimedia controller: Philips Semiconductors SAA7134 (rev 01) pinA >also uses LNKD in PIC mode and IRQ19 in IOAPIC mode -- >though I don't see a driver loaded for this device. The driver is called saa7134 and is indeed loaded (grep dmesg for saa7134). And if not that's enough, I also get these lines: saa7134[0]/irq[10,-257154]: r=0x20 s=0x00 PE saa7134[0]/irq: looping -- clearing enable bits _when_ network is initialized. >Can you simplify the system and still see the problem? >ie. disable all optional devices in the BIOS and exclude >the drivers from the kernel except usb and eth0? >I'm sort of curious where the yenta devices hang... Yes, I removed every expansion card from my system, except VGA, and I disabled everything in BIOS except SCSI (since that's where the root-disk is), and the problem was still there. Do you want to see dmesg and/or interrupts from that scenario? There was no change (except for all the missing devices..) >Also, if you boot with acpi=off, does MPS configure >the interrups the same way as ACPI? Do you see >the problem in that case? This system have never booted in MPS mode. Neither with kernel 2.4, and that have caused me some grief with certain Linux-installers and stuff... It hangs after these three lines: ENABLING IO-APIC IRQs Setting 2 in the phys_id_present_map ...changing IO-APIC Physical APIC ID to 2 ... ok. So I have no idea whether I get the problems in MPS-mode... My girlfriends pc have excactly the same behaviour as mine. That is a VIA KLE133 socket A chipset from Microstar. So it seems this is VIA specific, and not just a broken BIOS on my computer... Do you want dmesg and interrupts from her pc as well? Hope this helps...
> saa7134[0]/irq[10,-257154]: r=0x20 s=0x00 PE > saa7134[0]/irq: looping -- clearing enable bits This doesn't look healthy. Is it possible to disable this device (and the others) in the BIOS? Maybe some clues can be gleaned by loading w/ debug. eg # modprobe saa7134 irq_debug=2 What is the relationship between the saa7134 and eth0? saa7134 complains when eth0 is configured, but doesn't complain otherwise? Do the spurious usb interrupts still happen if saa7134 is configured but eth0 is disabled?
Well, as I wrote in my last comment, I still get spurious interrupts without the saa7134 card or yenta adapter inserted, so I doubt it has anything to do with them. Btw. saa7134 is a tv-card. It's working fine, even with those messages. eth0 and saa7134 have no relation, except they are sharing the same irq.. I'll try to compile saa7134 as a module and load it with irq-debug later today... As I said, my girlfriends pc have the same symptoms, and she doesn't have one single pci-card in her pc. Thanks for looking into this :)
Created attachment 3493 [details] IRQ's in Windows 2000 Here is the interrupts from Windows 2000. As you can see, the usb-interrupts are on another irq here. I don't know if that matters. Anyway, I hope this sheds some light on this issue.
Is it possible to force usb-irq to 9 (since that's what Windows XP uses) and see if it gets better then? I finally found out what causes the pc to not boot when booting in IO-APIC mode. In IO-APIC mode usb does not work (just like my other VIA-board in IO-APIC mode...), but usb gets IRQ 19, the same as eth0 (which might explain why they are tied together?) I'll attach dmesg and interrupts. Please look at this bug again.
Created attachment 3693 [details] dmesg with acpi=off
Created attachment 3694 [details] nterrupts with acpi=off
same with 2.6.9?
Yes, sorry.. Also with latest 2.6.10-rc1-bk.
As interrupt wires are assigned to slots rather than devices... Is it possible to modify the configuration and move devices between slots to see if the issues stay with the slot or move with the device?
Cool that you have not yet forgot me :) Happy new year, btw. Since the problem is with usb and ethernet, and both these devices are integrated, it's not possible to move them, sorry. Anyway, I have earlier tried to remove every add-in card from the pc, it doesn't change anything. And my girlfriends pc (which have the same problem, as I've told earlier) doesn't have any add-in cards neither).
Hi again, I just wonder, would it help if I open a new bug with information from my girlfriends pc? It is still a VIA chipset, but not Apollo Pro. It's a AMD cpu and UP. Maybe that would make it easier to see, if you get a new view of things? :) It exhibits the excact same behavior. Best regards, Stian
Still the same with 2.6.18-rc2...
Len; will it help if I ship my motherboard to you for testing? :) I will need it back, but if you think it will help to have it your self, I'd be more than willing to pay shipping both ways.
Hmm. Could this be the problem: ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt 0000:00:11.2[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 LNKD is enabled at irq 9, still it get's irq 11? And it makes sense if that's the problem, since Windows has usb in irq 9. Is there a way to force usb to irq 9, at least for testing?
dmesg of kernel 2.6.18-rc6 http://lkml.org/lkml/2006/9/10/120 drivers/acpi/pci_link.c, line #583 acpi_irq_penalty[link->irq.active] += PIRQ_PENALTY_PCI_USING; printk(PREFIX "%s [%s] enabled at IRQ %d\n", acpi_device_name(link->device), acpi_device_bid(link->device), link->irq.active); bug #2243 may have some clues
>ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) >ACPI: PCI Interrupt 0000:00:11.2[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 I wonder how could this happen. irq 9 is in LNKD's possible irq list, so kernel doesn't change it. Do you get the output from the stock kernel or do you patches it? Can you try a latest kernel?
Created attachment 9751 [details] dmesg from 2.6.19 This is dmesg from 2.6.19. It's exactly the same. No patches, this is vanilla from kernel.org. And yeah, it's really weird, don't see how this can happen. But it's been like this forever, and I would be incredibly happy to get this finally fixed...
Can you narrow down how kernel changes it? From the code, I can't get it. the routine is 'acpi_pci_link_allocate', link->irq.active is 9 at the begining of the routine, but it gets changed to 11. Can you have some investigations and check which steps changed it? Print something in the routine might help.
Sorry, that's beyond my skills. If you would whip up a patch, I'd be happy to apply it and test it...
Well, I figured printk out :P It changes with this block: /* Attempt to enable the link device at this IRQ. */ if (acpi_pci_link_set(link, irq)) { printk(KERN_ERR PREFIX "Unable to set IRQ for %s [%s]. " "Try pci=noacpi or acpi=off\n", acpi_device_name(link->device), acpi_device_bid(link->device)); return -ENODEV; } else { acpi_irq_penalty[link->irq.active] += PIRQ_PENALTY_PCI_USING; printk(PREFIX "%s [%s] enabled at IRQ %d\n", acpi_device_name(link->device), acpi_device_bid(link->device), link->irq.active); } Does this help?
Created attachment 10747 [details] Patch that fixes the issue Just for the record, the atteched patch fixes this issue. But it breaks nforce chipsets, so it's far from perfect.
Hi Stian, I assume that 2.6.22.stable un-patched still fails here?
Yes, I'm sorry. Both 2.6.22.6 and 2.6.23-rc5 fails. Isn't it possible to use a dmi-blacklist-thingy to apply this "fix" only to VIA-chipsets? Or something more clever?
Hi, Stian Will you please test it using the kernel of 2.6.22.6 ? (enable the debug function of pci and acpi in kernel configuration). Please boot with option of noapic apic=debug initcall_debug and upload the following info. a. dmesg b. interrupts. c. lspci -xxx Thanks.
Created attachment 13180 [details] test the kernel using the workaround patch Hi, Stian Will you please test the kernel of using the workaround patch?(kernel can be 2.6.22.6 ) After applying the workaround patch, please boot system with option of apic=debug initcall_debug and verify whether the system can work well.(acpi is enabled, I/O APIC mode is used). It is helpful that the following info is uploaded. a. dmesg b. interrupts. Thanks.
Hi! Thanks for looking into this. I'm sorry I didn't respont earlier, I have been out of town this week. Anyway, 2.6.22.6 with your workaround patch, and booted with apic=debug initcall_debug seems to work very well. As you can see in my /proc/interrupts, usb now shares irq 17 with eth0, so it's hard to "test" if my issue is solved, but now it won't be a problem, I guess. Please tell me if you'd need anything else. Is this workaround patch something that might end up in the kernel some day?
Created attachment 13201 [details] dmesg from kernel 2.6.22.6 with debug patch
Created attachment 13202 [details] /proc/interrupts from 2.6.22.6 with debug patch
Created attachment 13203 [details] lspci -xxx
Oops, I spoke to fast. USB does not work with this patch :( Sorry about that...
Hi, Stian the dmesg in comment #35 is incompleate. Will you please enable PCI debug in kernel configuration and upload the full dmesg ?
Hi, Stian Will you please test the system with boot option of noapic apic=debug?(Not using the workaround patch in #comment 33). At the same time the PCI and acpi debug had better be enabled in kernel configuration. Thanks.
Hi, Stian Will you please confirm whether USB can work well in comment #31? (Not using the workaround patch in #33). Thanks.
Hmm. Actually it doesn't. I'll have to investigate this more later when I'm back home later today. With the Ubuntu 2.6.22-kernel it works as it should with the same irq-s as with vanilla 2.6.22.6 without your patch, so I don't see why it doesn't work. I'll try to figure it out tonight. I'll also enable more debug and post logs then. Thanks again :)
Hi, Stian Will you please confirm whether USB can work well with the boot option of noapic apic=debug(not using the workaround patch in #comment 33)? Thanks.
Stian, any response?
Hi Michael and Yakui! First of all, I'm very, very sorry for replying so late! It's been extremely busy for me lately, and I have bought my first house! But enough of that. Second, I'm sorry I said usb didn't work with kernel 2.6.22.6 earlier. It was a misconfiguration on my part. (Missing the CONFIG_USB_DEVICE_CLASS / the udev-rule-replacement). That means that 2.6.24-rc4 works just as well as any other kernel. I still have to use "noirqdebug", but with that, usb is working and everything is perfectly well. Using your debug patch in comment #33, usb still works, albeit extremely slow. But if I copy some files over the network, the usb transfer speeds up. I guess this is because they share the same irq. Besides irq 9 (acpi) gets disabled with your debug patch. (see attached dmesg). I'll attach dmesg and interrupts from 2.6.24-rc4 with your debug-patch.
Created attachment 13978 [details] dmesg
Created attachment 13979 [details] interrupts
Just FYI, 2.6.24-rc4 also works perfectly using the patch in comment #29.
Hi, Stian Thanks for the info. It will be great if you can attach the output of dmesg and /proc/interrupts after the patch in comment #29 is applied on the kernel of 2.6.24-rc4. Thanks.
Hi, Stian Will you please try the following test besides the test in comment #49? Test the kernel 2.6.24-rc4(not using any patch) and attach the output of dmesg and /proc/interrupts using the following boot options? a. noapic b. acpi_irq_nobalance Thanks.
Created attachment 13990 [details] dmesg using workaround patch in comment #29
Created attachment 13991 [details] interrupts using workaround patch in comment #29
Created attachment 13992 [details] dmesg using noapic
Created attachment 13993 [details] interrupts using noapic
Created attachment 13994 [details] dmesg using acpi_irq_nobalance As far as I can see, the acpi_irq_nobalance kernel option doesn't seem to do anything...
Created attachment 13995 [details] interrupts using acpi_irq_nobalance
Hi, Stian From the info in comment #51 and #55 it seems that the boot option of acpi_irq_nobalance and the patch in comment #29 have the same meaning. The won't change the default setting of LNK device. The root cause of this bug is related to the VIA chipset and the analysis about this bug is listed in the following: a. acpi=off . The USB host controller and ethernet controller share the same interrupt. Their interrupts are all routed to the Pin 19 of IO APIC. b. noapic : The USB host controller and ethernet controller use the same LINK device(LNKD). The interrupt is routed to Pin 9 of I8259. c. when the system is booted with ACPI and I/O APIC is used, the interrupt routes for USB and ethernet are totally different. The interrupt of USB controller is routed to 9 through LNKD device in case of no irqbalance(If irq balance is used, maybe it will be routed to 11).And ethernet device is directly routed to Pin 19 of I/O APIC. (The interrupt route info is found in the ACPI PRT table). d. When the patch in comment #32 is applied,the interrupt of USB host is forced to be routed to the pin 19 of I/O APIC.Only acpi interrupt is registered for IRQ 9 and LNKD device is disabled by calling the _DIS method. But the system reports that the error message of IRQ 9 nobody cared for. The only explanation for this is that _DIS method can't disable the LNKD device and the interrupt pins of USB hosts are still hardrouted to IRQ 9 through LNKD device. From the above analysis it seems that there are two routes for the interrupt pin of USB and ethernet in I/O APIC mode. One is directly routed to Pin 19 and the other is routed to I/O APIC through LNKD device. So it seems that USB interrupt and ethernet interrupt are tied together. And this bug is related to the hardware. It can't be fixed by software if there is no available spec for this chipset.
(In reply to comment #57) > d. When the patch in comment #32 is applied,the interrupt of USB host is > forced to be routed to the pin 19 of I/O APIC.Only acpi interrupt is > registered > for IRQ 9 and LNKD device is disabled by calling the _DIS method. > But the system reports that the error message of IRQ 9 nobody cared for. The > only explanation for this is that _DIS method can't disable the LNKD device > and > the interrupt pins of USB hosts are still hardrouted to IRQ 9 through LNKD > device. > drivers/acpi/pci_link.c, line #583 acpi_irq_penalty[link->irq.active] += PIRQ_PENALTY_PCI_USING; printk(PREFIX "%s [%s] enabled at IRQ %d\n", acpi_device_name(link->device), acpi_device_bid(link->device), link->irq.active); this code is very old, year 2002, so maybe this code is not need it anymore and is the root of the problem, hardrouted something with IRQ_PENALTY. Could you take a look at those code , and see if it can be deleted. As far as I know, you are saying that ACPI, now, find irq routing for those device, and IIRC those code (pci_link.c) is for devices that we don't know the irq routing. Thanks,
Hi, Sergio The patch in comment #29 can make the system work.But the root problem of this bug can't be fixed by the patch in comment #29. In fact the boot option of acpi_no_irqbalance is equal to the patch in comment #29 and both can make the system work. The problem in the comment #58 is explained from the following two views: a. The LINK device is programmed into default IRQ number by BIOS. When the LINK device driver is loaded, the _DIS method is called to disable the LINK device. When a LINK device is used by some PCI devices, it will be reprogrammed. In case of ACPI irq balance the OS will select the IRQ number according to irq penalty table. Maybe it will caused that the result IRQ number is different with the default IRQ number. If LINK device is hardrouted , the problem appears. If no irq balanced is used, the LINK device will be reprogrammed by the default IRQ number and there will be no problem. If the LINK device is hardrouted, maybe it will be better that no irq balance is used. (In current kernel the IRQ balance is the default mode). b. The source pointed to in comment #58 to has another purpose. If one LINK device is not programmed by BIOS(it means that Link->irq.active is zero) and used by some PCI devices, OS should select a proper IRQ number for this LINK device according to the irq penalty tables. Otherwise there will another problem(some irq is shared by too many PCI devices). So I think that the source code can't be deleted. Thanks.
(In reply to comment #59) Hi, last change ykzhao remind me, is some here on bios setup change the IRQs for usb devices