Exact Kernel version: 2.5.46-bk2 Distribution: Red Hat Rawhide Hardware Environment: Gigabyte GA -7VAX, latest bios I'm trying to move from an pure usb hid + acpi + io-apic UP 2.4 system to a 2.5 one. Hardware is via kt400 based. The problem is : * 2.5 io-apic kills usb input device not accepting address", see http://linux-usb.sourceforge.net/FAQ.html#ts6 * without io-apic build-in rt8139too do not work with acpi : nov 5 20:50:30 rousalka ifup: nov 5 20:50:30 rousalka ifup: D
Reassign to Jeff Garzik since there is a network part and he declared himself willing on linux-kernel (must have been out of his mind:)
Unfortunately while this has a networking component, it is only related as a symptom of another problem. You might try booting "noapic" to see if that fixes your problems. On uniprocessor boxes, IO-APIC is often a bad idea because the BIOS-provided MP tables which Linux uses are faulty, providing bad information to Linux which in turn uses that information and sets up interrupts incorrectly. In any case, the people who need to fix this are the ACPI guys, and any IO-APIC hackers that exist...
Well, the problem is not io-apic + network, but network + acpi - io-apic = broken So the rt8139too works with io-apic, but not without when acpi in build-in
*** Bug 70 has been marked as a duplicate of this bug. ***
what I need is info preferably in the form of: working /proc/interrupts w/o acpi ... broken /proc/interrupts w/acpi - also, which devs don't work? ... *with everything else the same* thanks.
Well, that's the list at the begining of the bug. You can ignore all the uhci/ehci differences -- they worked and broke together, not enabling one of them didn't seem to change inteupt routing at all. (and I think I never got ehci to work on 2.4 due to the state of 2.4 ehci driver). The rule (for 2.5) basicaly is : - with acpi and local io-apic usb (uhci and ehci) do not work - with acpi but without local apic (be it only local apic or local-apic + io-apic) netwotk does not work. On 2.4 acpi+io-apic+uhci+network works (though I don't think I got the power button to do anything unlike in 2.5). The funny thing is the interrupt routing seems to be the same, but both the usb and the network maintener told me the problem was in acpi. I can re-do a test run, I don't expect the results to be any different. All tested 2.5 kernels were generated using pretty much the same monolithic config, only enabling/disabling apics and acpi (and uhci/ehci, but this didn't change anything). Here are some other results (I changed my rc scripts to copy /proc/interrupts at the end of rc.local, so I have a stash of these) : 2.4.20-rc2-ac1 monolithic, all works CPU0 0: 3630 IO-APIC-edge timer 1: 4 IO-APIC-edge keyboard 2: 0 XT-PIC cascade 8: 1 IO-APIC-edge rtc 9: 0 IO-APIC-edge acpi 14: 55 IO-APIC-edge ide0 15: 2881 IO-APIC-edge ide1 18: 44 IO-APIC-level cs46xx, eth0 21: 325 IO-APIC-level usb-uhci, usb-uhci, usb-uhci NMI: 0 LOC: 3580 ERR: 0 MIS: 0 2.5.47-ac6 monolithic, no acpi, no local apic, all works CPU0 0: 34203 XT-PIC timer 2: 0 XT-PIC cascade 8: 1 XT-PIC rtc 11: 91 XT-PIC CS46XX, eth0 12: 343 XT-PIC ehci-hcd 14: 46 XT-PIC ide0 15: 2770 XT-PIC ide1 NMI: 0 ERR: 0 (I'm sorry I didn't build any broken 2.5 acpi kernel in a while, I can do it agin if you want. With usb input that breaks every few days having acpi to do software shutdonw via the power button would be great)
I'll do a apcpi but no local apic kernel tomorrow, seems I've forgotten to copy this config's interrupts in bugzilla:(
OK so there are two problems. bug 71 is about the network scenario. This bug is just about ioapic + acpi + usb. Modifying summary accordingly. Please confirm that in every case where USB doesn't work, it is configured as IO-APIC-edge. Thanks -- Andy
2.5.48-bk4 acpi ioapic usb broken network works CPU0 0: 38398 IO-APIC-edge timer 2: 0 XT-PIC cascade 8: 1 IO-APIC-edge rtc 9: 0 IO-APIC-level acpi 12: 0 IO-APIC-edge ehci-hcd 14: 47 IO-APIC-edge ide0 15: 2873 IO-APIC-edge ide1 18: 79 IO-APIC-level CS46XX, eth0 NMI: 0 LOC: 38321 ERR: 0 MIS: 0
Corresponding dmesg : Nov 22 19:37:01 rousalka kernel: Linux version 2.5.48bk4-acpi-ioapic (root@rousalka) (gcc version 3.2 20021115 (Red Hat Linux 8.0 3.2-14)) #1 Fri Nov 22 19:24:26 CET 2002 Nov 22 19:37:01 rousalka kernel: Video mode to be used for restore is ffff Nov 22 19:37:01 rousalka kernel: BIOS-provided physical RAM map: Nov 22 19:37:01 rousalka kernel: BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) Nov 22 19:37:01 rousalka kernel: BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) Nov 22 19:37:01 rousalka kernel: BIOS-e820: 0000000000100000 - 000000001fff0000 (usable) Nov 22 19:37:01 rousalka kernel: BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS) Nov 22 19:37:01 rousalka kernel: BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data) Nov 22 19:37:01 rousalka kernel: BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) Nov 22 19:37:01 rousalka kernel: BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) Nov 22 19:37:01 rousalka kernel: BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) Nov 22 19:37:01 rousalka kernel: 511MB LOWMEM available. Nov 22 19:37:01 rousalka kernel: found SMP MP-table at 000f4b50 Nov 22 19:37:01 rousalka kernel: hm, page 000f4000 reserved twice. Nov 22 19:37:01 rousalka kernel: hm, page 000f5000 reserved twice. Nov 22 19:37:01 rousalka kernel: hm, page 000f0000 reserved twice. Nov 22 19:37:01 rousalka kernel: hm, page 000f1000 reserved twice. Nov 22 19:37:01 rousalka kernel: On node 0 totalpages: 131056 Nov 22 19:37:01 rousalka kernel: DMA zone: 4096 pages, LIFO batch:1 Nov 22 19:37:01 rousalka kernel: Normal zone: 126960 pages, LIFO batch:16 Nov 22 19:37:01 rousalka kernel: HighMem zone: 0 pages, LIFO batch:1 Nov 22 19:37:01 rousalka kernel: ACPI: RSDP (v000 GBT ) @ 0x000f64b0 Nov 22 19:37:01 rousalka kernel: ACPI: RSDT (v001 GBT AWRDACPI 16944.11825) @ 0x1fff3000 Nov 22 19:37:01 rousalka kernel: ACPI: FADT (v001 GBT AWRDACPI 16944.11825) @ 0x1fff3040 Nov 22 19:37:01 rousalka kernel: ACPI: MADT (v001 GBT AWRDACPI 16944.11825) @ 0x1fff6ac0 Nov 22 19:37:02 rousalka kernel: ACPI: DSDT (v001 GBT AWRDACPI 00000.04096) @ 0x00000000 Nov 22 19:37:02 rousalka kernel: ACPI: BIOS passes blacklist Nov 22 19:37:02 rousalka kernel: ACPI: Local APIC address 0xfee00000 Nov 22 19:37:02 rousalka kernel: ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Nov 22 19:37:02 rousalka kernel: Processor #0 6:6 APIC version 16 Nov 22 19:37:02 rousalka kernel: ACPI: LAPIC_NMI (acpi_id[0x00] polarity[0x0] trigger[0x0] lint[0x1]) Nov 22 19:37:02 rousalka kernel: ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0]) Nov 22 19:37:02 rousalka kernel: IOAPIC[0]: Assigned apic_id 2 Nov 22 19:37:02 rousalka kernel: IOAPIC[0]: apic_id 2, version 3, address 0xfec00000, IRQ 0-23 Nov 22 19:37:02 rousalka kernel: ACPI: INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x0] trigger[0x0]) Nov 22 19:37:02 rousalka kernel: ACPI: INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x3] trigger[0x3]) Nov 22 19:37:02 rousalka kernel: Using ACPI (MADT) for SMP configuration information Nov 22 19:37:02 rousalka kernel: Building zonelist for node : 0 Nov 22 19:37:02 rousalka kernel: Kernel command line: ro root=/dev/hdc1 video=matrox:vesa:0x11B,fh:96,fv:160 Nov 22 19:37:02 rousalka kernel: Initializing CPU#0 Nov 22 19:37:02 rousalka kernel: Detected 1741.289 MHz processor. Nov 22 19:37:02 rousalka kernel: Console: colour dummy device 80x25 Nov 22 19:37:02 rousalka kernel: Calibrating delay loop... 3432.44 BogoMIPS Nov 22 19:37:02 rousalka kernel: Memory: 514384k/524224k available (2223k kernel code, 9096k reserved, 1231k data, 144k init, 0k highmem) Nov 22 19:37:02 rousalka kernel: Security Scaffold v1.0.0 initialized Nov 22 19:37:02 rousalka kernel: Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Nov 22 19:37:02 rousalka kernel: Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Nov 22 19:37:02 rousalka kernel: Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Nov 22 19:37:02 rousalka kernel: -> /dev Nov 22 19:37:02 rousalka kernel: -> /dev/console Nov 22 19:37:02 rousalka kernel: -> /root Nov 22 19:37:02 rousalka kernel: CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) Nov 22 19:37:02 rousalka kernel: CPU: L2 Cache: 256K (64 bytes/line) Nov 22 19:37:02 rousalka kernel: Intel machine check architecture supported. Nov 22 19:37:02 rousalka kernel: Intel machine check reporting enabled on CPU#0. Nov 22 19:37:02 rousalka kernel: Machine check exception polling timer started. Nov 22 19:37:02 rousalka kernel: CPU: AMD Athlon(tm) XP 2100+ stepping 02 Nov 22 19:37:02 rousalka kernel: Enabling fast FPU save and restore... done. Nov 22 19:37:02 rousalka kernel: Enabling unmasked SIMD FPU exception support... done. Nov 22 19:37:02 rousalka kernel: Checking 'hlt' instruction... OK. Nov 22 19:37:02 rousalka kernel: POSIX conformance testing by UNIFIX Nov 22 19:37:02 rousalka kernel: enabled ExtINT on CPU#0 Nov 22 19:37:02 rousalka kernel: ESR value before enabling vector: 00000000 Nov 22 19:37:02 rousalka kernel: ESR value after enabling vector: 00000000 Nov 22 19:37:02 rousalka kernel: ENABLING IO-APIC IRQs Nov 22 19:37:02 rousalka kernel: ..TIMER: vector=0x31 pin1=2 pin2=0 Nov 22 19:37:02 rousalka kernel: testing the IO APIC....................... Nov 22 19:37:02 rousalka kernel: Nov 22 19:37:02 rousalka kernel: WARNING: unexpected IO-APIC, please mail Nov 22 19:37:02 rousalka kernel: to linux-smp@vger.kernel.org Nov 22 19:37:02 rousalka kernel: .................................... done. Nov 22 19:37:02 rousalka kernel: Using local APIC timer interrupts. Nov 22 19:37:02 rousalka kernel: calibrating APIC timer ... Nov 22 19:37:02 rousalka kernel: ..... CPU clock speed is 1741.0226 MHz. Nov 22 19:37:02 rousalka kernel: ..... host bus clock speed is 267.0880 MHz. Nov 22 19:37:02 rousalka kernel: Linux NET4.0 for Linux 2.4 Nov 22 19:37:02 rousalka kernel: Based upon Swansea University Computer Society NET3.039 Nov 22 19:37:02 rousalka kernel: Initializing RT netlink socket Nov 22 19:37:02 rousalka kernel: mtrr: v2.0 (20020519) Nov 22 19:37:02 rousalka kernel: PCI: Using configuration type 1 Nov 22 19:37:02 rousalka kernel: BIO: pool of 256 setup, 14Kb (56 bytes/bio) Nov 22 19:37:02 rousalka kernel: biovec pool[0]: 1 bvecs: 256 entries (12 bytes) Nov 22 19:37:02 rousalka kernel: biovec pool[1]: 4 bvecs: 256 entries (48 bytes) Nov 22 19:37:02 rousalka kernel: biovec pool[2]: 16 bvecs: 256 entries (192 bytes) Nov 22 19:37:02 rousalka kernel: biovec pool[3]: 64 bvecs: 256 entries (768 bytes) Nov 22 19:37:02 rousalka kernel: biovec pool[4]: 128 bvecs: 256 entries (1536 bytes) Nov 22 19:37:02 rousalka kernel: biovec pool[5]: 256 bvecs: 256 entries (3072 bytes) Nov 22 19:37:02 rousalka kernel: ACPI: Subsystem revision 20021115 Nov 22 19:37:02 rousalka kernel: ACPI-0508: *** Info: GPE Block0 defined as GPE0 to GPE15 Nov 22 19:37:02 rousalka kernel: ACPI: Interpreter enabled Nov 22 19:37:02 rousalka kernel: ACPI: Using IOAPIC for interrupt routing Nov 22 19:37:02 rousalka kernel: ACPI: PCI Root Bridge [PCI0] (00:00) Nov 22 19:37:02 rousalka kernel: PCI: Probing PCI hardware (bus 00) Nov 22 19:37:02 rousalka kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 *10 11 12 14 15) Nov 22 19:37:02 rousalka kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 *7 10 11 12 14 15) Nov 22 19:37:02 rousalka kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) Nov 22 19:37:02 rousalka kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 11 *12 14 15) Nov 22 19:37:02 rousalka kernel: ACPI: PCI Interrupt Link [ALKA] (IRQs 20, disabled) Nov 22 19:37:02 rousalka kernel: ACPI: PCI Interrupt Link [ALKB] (IRQs 21, disabled) Nov 22 19:37:02 rousalka kernel: ACPI: PCI Interrupt Link [ALKC] (IRQs 22, disabled) Nov 22 19:37:02 rousalka kernel: ACPI: PCI Interrupt Link [ALKD] (IRQs 23, disabled) nov 22 19:37:02 rousalka random: Initialisation du générateur de nombre aléatoire : succeeded Nov 22 19:37:02 rousalka kernel: block request queues: Nov 22 19:37:02 rousalka kernel: 128 requests per read queue Nov 22 19:37:02 rousalka kernel: 128 requests per write queue Nov 22 19:37:02 rousalka kernel: 8 requests per batch Nov 22 19:37:02 rousalka kernel: enter congestion at 31 Nov 22 19:37:02 rousalka kernel: exit congestion at 33 Nov 22 19:37:02 rousalka kernel: drivers/usb/core/usb.c: registered new driver usbfs Nov 22 19:37:02 rousalka kernel: drivers/usb/core/usb.c: registered new driver hub Nov 22 19:37:02 rousalka kernel: ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 0 Nov 22 19:37:02 rousalka kernel: ACPI: PCI Interrupt Link [ALKB] enabled at IRQ 0 Nov 22 19:37:02 rousalka kernel: ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 0 Nov 22 19:37:02 rousalka kernel: ACPI: PCI Interrupt Link [ALKD] enabled at IRQ 0 Nov 22 19:37:02 rousalka kernel: ACPI: No IRQ known for interrupt pin A of device 00:10.0 - using IRQ 10 Nov 22 19:37:02 rousalka kernel: ACPI: No IRQ known for interrupt pin B of device 00:10.1 - using IRQ 7 Nov 22 19:37:02 rousalka kernel: ACPI: No IRQ known for interrupt pin C of device 00:10.2 - using IRQ 11 Nov 22 19:37:02 rousalka kernel: ACPI: No IRQ known for interrupt pin D of device 00:10.3 - using IRQ 12 Nov 22 19:37:02 rousalka kernel: ACPI: No IRQ known for interrupt pin A of device 00:11.1 - using IRQ 255 Nov 22 19:37:02 rousalka kernel: PCI: Using ACPI for IRQ routing Nov 22 19:37:02 rousalka kernel: PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off' Nov 22 19:37:02 rousalka kernel: IA-32 Microcode Update Driver: v1.11 <tigran@veritas.com> Nov 22 19:37:02 rousalka kernel: Starting kswapd Nov 22 19:37:02 rousalka kernel: aio_setup: sizeof(struct page) = 40 Nov 22 19:37:02 rousalka kernel: [c151e040] eventpoll: successfully initialized. Nov 22 19:37:02 rousalka kernel: VFS: Disk quotas vdquot_6.5.1 Nov 22 19:37:02 rousalka kernel: Journalled Block Device driver loaded Nov 22 19:37:02 rousalka kernel: udf: registering filesystem Nov 22 19:37:02 rousalka kernel: Capability LSM initialized Nov 22 19:37:02 rousalka kernel: ACPI: Power Button (FF) [PWRF] Nov 22 19:37:02 rousalka kernel: ACPI: Processor [CPU0] (supports C1 C2, 2 throttling states)
2.5.48-bk4 acpi, local apic, no io-apic usb works network fails CPU0 0: 129145 XT-PIC timer 2: 0 XT-PIC cascade 8: 1 XT-PIC rtc 9: 0 XT-PIC acpi 11: 0 XT-PIC CS46XX 12: 174 XT-PIC ehci-hcd 14: 48 XT-PIC ide0 15: 2895 XT-PIC ide1 NMI: 0 LOC: 129083 ERR: 268 And the dmesg : Linux version 2.5.48-bk4-acpi-apic (root@rousalka) (gcc version 3.2 20021115 (Red Hat Linux 8.0 3.2-14)) #1 Fri Nov 22 19:49:46 CET 2002 Video mode to be used for restore is ffff BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001fff0000 (usable) BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS) BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 511MB LOWMEM available. found SMP MP-table at 000f4b50 hm, page 000f4000 reserved twice. hm, page 000f5000 reserved twice. hm, page 000f0000 reserved twice. hm, page 000f1000 reserved twice. On node 0 totalpages: 131056 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 126960 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 ACPI: RSDP (v000 GBT ) @ 0x000f64b0 ACPI: RSDT (v001 GBT AWRDACPI 16944.11825) @ 0x1fff3000 ACPI: FADT (v001 GBT AWRDACPI 16944.11825) @ 0x1fff3040 ACPI: MADT (v001 GBT AWRDACPI 16944.11825) @ 0x1fff6ac0 ACPI: DSDT (v001 GBT AWRDACPI 00000.04096) @ 0x00000000 ACPI: BIOS passes blacklist ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 6:6 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] polarity[0x0] trigger[0x0] lint[0x1]) Using ACPI for processor (LAPIC) configuration information Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000 I/O APIC #2 Version 17 at 0xFEC00000. Enabling APIC mode: Flat. Using 1 I/O APICs Processors: 1 Building zonelist for node : 0 Kernel command line: ro root=/dev/hdc1 video=matrox:vesa:0x11B,fh:96,fv:160 Initializing CPU#0 Detected 1741.269 MHz processor. Console: colour dummy device 80x25 Calibrating delay loop... 3432.44 BogoMIPS Memory: 514424k/524224k available (2216k kernel code, 9056k reserved, 1210k data, 136k init, 0k highmem) Security Scaffold v1.0.0 initialized Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) -> /dev -> /dev/console -> /root CPU: Before vendor init, caps: 0383fbff c1c3fbff 00000000, vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0383fbff c1c3fbff 00000000 00000000 CPU: After generic, caps: 0383fbff c1c3fbff 00000000 00000000 CPU: Common caps: 0383fbff c1c3fbff 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Machine check exception polling timer started. CPU: AMD Athlon(tm) XP 2100+ stepping 02 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX enabled ExtINT on CPU#0 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 1741.0084 MHz. ..... host bus clock speed is 267.0859 MHz. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket mtrr: v2.0 (20020519) PCI: Using configuration type 1 BIO: pool of 256 setup, 14Kb (56 bytes/bio) biovec pool[0]: 1 bvecs: 256 entries (12 bytes) biovec pool[1]: 4 bvecs: 256 entries (48 bytes) biovec pool[2]: 16 bvecs: 256 entries (192 bytes) biovec pool[3]: 64 bvecs: 256 entries (768 bytes) biovec pool[4]: 128 bvecs: 256 entries (1536 bytes) biovec pool[5]: 256 bvecs: 256 entries (3072 bytes) ACPI: Subsystem revision 20021115 spurious 8259A interrupt: IRQ7. ACPI-0508: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 *7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 11 *12 14 15) ACPI: PCI Interrupt Link [ALKA] (IRQs 20, disabled) ACPI: PCI Interrupt Link [ALKB] (IRQs 21, disabled) ACPI: PCI Interrupt Link [ALKC] (IRQs 22, disabled) ACPI: PCI Interrupt Link [ALKD] (IRQs 23, disabled) block request queues: 128 requests per read queue 128 requests per write queue 8 requests per batch enter congestion at 31 exit congestion at 33 drivers/usb/core/usb.c: registered new driver usbfs drivers/usb/core/usb.c: registered new driver hub ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 0 ACPI: PCI Interrupt Link [ALKB] enabled at IRQ 0 ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 0 ACPI: PCI Interrupt Link [ALKD] enabled at IRQ 0 PCI: Using ACPI for IRQ routing PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
Is this ok or do you need more info ?
Afew versions and a bios upgrade later (2.4.20-ac1 & 2.5.50-bk8), still the same problem. No change in interrupt config, 2.4 uses IO-APIC-level for usb : CPU0 0: 3641 IO-APIC-edge timer 1: 4 IO-APIC-edge keyboard 2: 0 XT-PIC cascade 8: 1 IO-APIC-edge rtc 9: 0 IO-APIC-edge acpi 14: 55 IO-APIC-edge ide0 15: 2851 IO-APIC-edge ide1 18: 27 IO-APIC-level cs46xx, eth0 21: 199 IO-APIC-level usb-uhci, usb-uhci, usb-uhci NMI: 0 LOC: 3592 ERR: 0 MIS: 0 and 2.5.50 uses edge : CPU0 0: 34550 IO-APIC-edge timer 2: 0 XT-PIC cascade 8: 1 IO-APIC-edge rtc 9: 0 IO-APIC-level acpi 12: 0 IO-APIC-edge ehci-hcd 14: 47 IO-APIC-edge ide0 15: 2794 IO-APIC-edge ide1 18: 58 IO-APIC-level CS46XX, eth0 NMI: 0 LOC: 34475 ERR: 0 MIS: 0 Where should I look to make 2.5 behave like 2.4 ? At least to make sure the real problem is the type of io-apic used for usb ?
Still in 2.5.58
Still in 2.5.63-bk2
Please attach output from "lspci -v" and "cat /proc/acpi/dsdt" You may want to wait and try the sf.net patch going up tomorrow...that has some PCI-related stuff that --who knows-- may fix things. Thanks -- Andy
Created attachment 182 [details] lspci -v for GA-7VAX
For the /proc/acpi/dsdt I'll have to rebuild an acpi kernel and reboot (hope it'll work via ssh, else you'll have to wait a bit)
Created attachment 183 [details] cat /proc/acpi/dst for GA-7VAX
Created attachment 184 [details] Kernel config for GA-7VAX
Created attachment 185 [details] dmesg for GA-7VAX
Created attachment 198 [details] mptable output for GA-7VAX In case this can make the problem clearer
Marking normal priority, workaround available
-> high The workaround is building a kernel without acpi. That's not a workaround, that's removing features (wich worked in 2.4 even)
For me it's a show stopper to use USB as my coputer just doesn't shutdown properly withoutr ACPI. I'm using an MSI K7T Master.
Created attachment 214 [details] Dmesg from kernel boot I've also included some stack dumps that happend during the bootup process. While still having ACPI and │ │<*> EHCI HCD (USB 2.0) support │ │ │ │<*> OHCI HCD support │ │ │ │<*> UHCI HCD (most Intel and VIA) support Enabled. If I turn the HCD support of there is no issue anymore, but then I can't use the USB storage driver.
Created attachment 215 [details] Dmesg from kernel boot I've also included some stack dumps that happend during the bootup process. While still having ACPI and │ │<*> EHCI HCD (USB 2.0) support │ │ │ │<*> OHCI HCD support │ │ │ │<*> UHCI HCD (most Intel and VIA) support Enabled. If I turn the HCD support of there is no issue anymore, but then I can't use the USB storage driver.
Checked 2.5.64-bk3, since it's got some new Via quirks. Didn't change a damn thing. CC-ing Alan on this bug in case he's got useful hints (The network part in bug 71 certainly seems quirks-related)
The quirk handler may well not cover ACPI cases. You could stick some printk in the quirk code and in the quirk handler itself (ie pci/quirks.c and also arch/i386/pci/...). VIA requires that the INTERRUPT_LINE as well as INTERRUPT_PIN is written. For some daft reason Linus is opposed to doing this in the general case
Ok, I'll try it this evening (plus there are still Via bits trickling into Linus' tree, so who knows)
Well, I let the kernel print quirks, and I get this for usb : PCI: Calling quirk c03516a0 for 00:10.3 PCI: Calling quirk c0227d80 for 00:10.3 PCI: Calling quirk c04c2580 for 00:10.3 ACPI: No IRQ known for interrupt pin D of device 00:10.3 PCI: Calling quirk c0227c40 for 00:10.3 ACPI: No IRQ known for interrupt pin D of device 00:10.3 ehci-hcd 00:10.3: VIA Technologies, In USB 2.0 ehci-hcd 00:10.3: irq 12, pci mem e082e000 ehci-hcd 00:10.3: new USB bus registered, assigned bus number 1 PCI: 00:10.3 PCI cache line size set incorrectly (32 bytes) by BIOS/FW, correcting to 64 ehci-hcd 00:10.3: USB 2.0 enabled, EHCI 1.00, driver 2003-Jan-22 There are lots of things we don't know about it it seems, its quirked three times, the kernel complains about cache line, acpi about pin, etc.
I am still seeing what appears to be this problem on 2.5.66-bk5. I don't have any usb devices hooked to my computer but both snd-via82xx and via-rhine do not work on 2.5.66-bk5 with ioapic and acpi enabled. On 2.4.21-pre5-ac3 everything works fine with both ioapic and acpi enabled. Is anyone still working on this problem?
I certainly hope so. I didn't update the bug recently but I did build a few other kernels and they did fail as miserably as the rest
I'm also seeing this with 2.4.21-pre5-ac3 (with my own semi-merged XFS), and 2.5.x, making the Rhine II in my KT400 unusable, unless I disable allocation of an IRQ for video and USB (which share IRQ 11 with the NIC), and boot with "noapic".
I tried using 2.5.66-bk9+ (riel's bk pull from earlier today) and acpi would not compile, so after turning it off I noticed that both my nic and sound work fine without acpi being enabled. So my problem is definitely related to the acpi being broken in current 2.5.
Still in 2.5.68-bk7
Well, after looking a bit at the acpi code it seems we enter acpi_pci_irq_enable, fail acpi_pci_irq_lookup, fail acpi_pci_irq_derive and leave by the else { printk("\n"); return_VALUE(0); } of the next if Wich is a pitty because just two lines bellow there is an interesting block labeled /* * Make sure all (legacy) PCI IRQs are set as level-triggered. */ So it is known the default legacy should be level, but we leave the function just before.
Still in 2.5.68-bk10
*** Bug 712 has been marked as a duplicate of this bug. ***
using 2.5.69, please uncomment the code block at line 331 of drivers/acpi/pci_root.c and attach the expanded dmesg. Thanks.
Created attachment 366 [details] Abit KD7-RAID (KT400) dmesg 2.5.69-bk15
See above for my dmesg output from 2.5.69-bk15. This bug is now also in the 2.4 series it was introduced somewhere between 2.4.21-pre7-ac1 and 2.4.21-rc2-ac2 (those being the two kernels I have installed on my system).
Will retest in a few days when the KT400 system hard drive has been replaced (died on monday, sorry)
Does this thread have anything to do with this bug (it looked like it might to me)? http://marc.theaimsgroup.com/?l=linux-kernel&m=105276809421903&w=2
I don't think so. That message was discussing ACPI yes, MPS yes, MADT no. This system certainly appears to have an MADT. Jos may have a point but that's not this bug.
Created attachment 376 [details] dmesg for GA-7VAX (2.5.69-bk17 + acpi debug)
Here is the requested dmesg - hardware is the same except for the broken disk that was replaced by a raid1 2-disk array. Distro is still up-to-date Rawhide (not that it changed anything) Hope this helps pinpointing the bug.
I'll check bug 71 now
This bug appears to be older than 2.5.46-bk2. I tried out 2.5.46 a few minutes ago and it seemed to do the same thing wrt setting irqs incorrectly. The only kernel I know for certain works right is the 2.4.21-pre7-ac1 I currently have on my machine, I believe it worked for most of the 2.4.21-pre series though I haven't gone through and found when it started and when it broke again.
2.5.46-bk2 is just the first 2.5 kernel I tried on this hardware 2.4.x used to work till its ACPI was "fixed"
It appears the common factor with breaking boxes is that they dont have MADTs, ACPI then falls back to PIC based IRQ servicing as opposed to IOAPIC, hence the non delivery.
My mistake Andy, i had looked at the dmesg for the MSI board, which didn't have an MADT instead of the KT400
Created attachment 519 [details] Kernel config for GA-7VAX
Created attachment 520 [details] dmesg for GA-7VAX (2.5.75-bk1 + acpi debug)
*** Bug 955 has been marked as a duplicate of this bug. ***
*** Bug 968 has been marked as a duplicate of this bug. ***
*** Bug 969 has been marked as a duplicate of this bug. ***
Same with 2.6.0-test2-mm1 - thought the failure mode is really different due to to nvidia ACPIfix patch
Created attachment 601 [details] dmesg for GA-7VAX (2.6.0-test2-mm1)
Created attachment 602 [details] interrupts for 2.6.0-test2-mm1 on GA-7VAX
Does anyone has any new status about this issue? So far, 2.6.0-test4 could resolve the broken network (acpi + network + usb - io-apic). Would you pleas have it a try. I'm not sure the another problem. (acpi + network + usb + io-apic = broken USB ) you could try it either. Please attach the dmesg after testing. Thanks, Luming
I tested this with 2.6.0-test4, and it seems to be working ok now with acpi + local apic + io-apic. I have a Abit AT7-MAX board.
Created attachment 726 [details] dmesg on Abit AT7-MAX 2.6.0-test4 acpi+local apic+io-apic (apic disabled in bios)
I was a bit too quick. Itś working (network + usb) when apic is disabled in bios. If I turn on apic in bios, usb doesn
Created attachment 727 [details] dmesg on Abit AT7-MAX 2.6.0-test4 acpi+local apic+io-apic (apic enabled)
Created attachment 728 [details] dmesg for GA-7VAX (2.6.0-test4-bk2, acpi + io-apic + eth + usb + raid)
Still no go. With acpi + io-apic eth & raid works, but usb is never initialised (same config without acpi+apic works on this kernel). The ehci led on the external hub never lights up. The usb error messages disappeared though.
Scenario in comment 61 is bug #71 which seems almost solved (everything that failed works now, albeit not good enough for normal use - the mouse just crawls instead of flying)
There are errors in dmesg like: "ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing." Would you try to remove below code from drivers\acpi\pci_link.c /*Make sure the active IRQ is the one we requested. */ result = acpi_pci_link_get_current(link); if(result) { return_VALUE(result); } and see what happend. I want to know whether there are any unresolved problems. Thanks Luming
There are errors in dmesg like: "ACPI: Unable to set IRQ for PCI Interrupt Link [ALKB] (likely buggy ACPI BIOS). Aborting ACPI-based IRQ routing." Would you try to remove below code from drivers\acpi\pci_link.c /*Make sure the active IRQ is the one we requested. */ result = acpi_pci_link_get_current(link); if(result) { return_VALUE(result); } and see what will happen. I want to know whether there are any unresolved problems. Thanks Luming
I will test removing this bit this evening (cet) Thank you for following this problem.
Created attachment 767 [details] dmesg for GA-7VAX (2.6.0-test4-bk2, acpi + io-apic + eth + usb + raid) + code backout
Here is the requested dmesg. It seems partial - removing the requested bit of code makes boot very chatty. I'll try to get a more complete one now (btw the boot fails as usual but that's no surprise)
Created attachment 768 [details] full dmesg for GA-7VAX (2.6.0-test4-bk2, acpi + io-apic + eth + usb + raid) + code backout
I'm sorry, I think the code in acpi_pci_link_set should be: static int acpi_pci_link_set ( struct acpi_pci_link *link, int irq) { .... #ifdef DONT_REMOVE_CHECK /* Make sure the active IRQ is the one we requested. */ result = acpi_pci_link_get_current(link); if (result) { return_VALUE(result); } if (link->irq.active != irq) { ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Attempt to enable at IRQ %d resulted in IRQ %d\n", irq, link->irq.active)); link->irq.active = 0; acpi_ut_evaluate_object (link->handle, "_DIS", 0, NULL); return_VALUE(-ENODEV); } #else link->irq.active = irq; #endif ... } Would you please retry it? I want to know if there are any USB problem.
Re-testing with : diff -uNr linux-2.6.0-test4-bk2.orig/drivers/acpi/pci_link.c linux-2.6.0-test4-bk2/drivers/acpi/pci_link.c --- linux-2.6.0-test4-bk2.orig/drivers/acpi/pci_link.c 2003-08-23 01:52:08.000000000 +0200 +++ linux-2.6.0-test4-bk2/drivers/acpi/pci_link.c 2003-08-30 10:05:20.514059029 +0200 @@ -360,6 +360,8 @@ return_VALUE(-ENODEV); } + +#ifdef DONT_REMOVE_CHECK /* Make sure the active IRQ is the one we requested. */ result = acpi_pci_link_get_current(link); if (result) { @@ -375,6 +377,10 @@ return_VALUE(-ENODEV); } +#else + link->irq.active = irq; +#endif + ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Set IRQ %d\n", link->irq.active)); return_VALUE(0);
You know, I was very sceptical after all those months on problem reporting with no fix in sight. But this did it ! The system boots, usb works (and is not dog-slow like in the local apic - io-apic scenario) and everything seems to be fine. I won't mark the bug as closed with a code-fix now, because I assume you'll want to fix the check instead of merely removing it, but I'll run kernels with this patch till you get a better fix and everyone with the problem should test it. You found the proble source. Yep-ee !
Created attachment 773 [details] Initial fix for GA-7VAX
Created attachment 774 [details] full dmesg for GA-7VAX (2.6.0-test4-bk2, acpi + io-apic + eth + usb + raid) + initial fix
Comment on attachment 768 [details] full dmesg for GA-7VAX (2.6.0-test4-bk2, acpi + io-apic + eth + usb + raid) + code backout Obsoleted by initial fix
Created attachment 775 [details] Interrupts for fixed 2.6.0-test4-bk2 + initial fix
Wow. Thank you very much for all your work done to solve this bug. I never got onboard net(via-rhine),usb,sound working on my EPOX 8k5a3+ when it run in IO-APIC mode. These onboard devices always got an interrupt assigned, but they never recieved one. Now with 2.6.0-test4-mm4 + your "initial fix" everything is fine in APIC mode.
Created attachment 828 [details] full dmesg for GA-7VAX (2.6.0-test4-bk8 + acpi patches
Created attachment 829 [details] Interrupts for fixed 2.6.0-test4-bk8 + acpi patches
Fixed with the acpi patches posted at http://marc.theaimsgroup.com/?l=acpi4linux&m=106280663518829&w=2
The patch posted in bug #845 also works on 2.6.0-test5-bk1
Is this still floating around as a patch, or is it merged back already?
I think it's merged (or at least the relevant bits for my system since I run vanilla kernels again)
I've got access to a GA-7VAX, the system this was originally filed against. Fedora Core 1 SMP kernel booted with "acpi=on" comes upcorrectly in IO-APIC mode, with ethernet, USB, and ACPI button all working. We see the results of the workaround for the VIA BIOS bug in dmesg: _CRS returns NULL! Using IRQ 21 for device (PCI Interrupt Link [ALKB]). ACPI: PCI Interrupt Link [ALKB] enabled at IRQ 21 IOAPIC[0]: Set PCI routing entry (2-21 -> 0xc9 -> IRQ 21 Mode:1 Active:1) 00:00:10[A] -> 2-21 -> IRQ 21 2.4.23-rc5 and 2.6.0-test11 (shown w/ CONFIG_ACPI_DEBUG) also work properly: pci_link-0258 [23] acpi_pci_link_get_curr: No IRQ resource found pci_link-0292 [22] acpi_pci_link_try_get_: No active IRQ resource found _CRS returns NULL! Using IRQ 21 fordevice (PCI Interrupt Link [ALKB]). ACPI: PCI Interrupt Link [ALKB] enabled at IRQ 21 IOAPIC[0]: Set PCI routing entry (2-21 -> 0xc9 -> IRQ 21 Mode:1 Active:1) 00:00:10[A] -> 2-21 -> IRQ 21 closing this bug -- thanks for all the help!