Created attachment 29312 [details] dmesg without acpi=noirq With this card: 00:09.0 Serial controller [0700]: NetMos Technology PCI 9835 Multi-I/O Controller [9710:9835] (rev 01) (prog-if 02 [16550]) Subsystem: IBM Device [1014:0299] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 10 Region 0: I/O ports at 1898 [size=8] Region 1: I/O ports at 1890 [size=8] Region 2: I/O ports at 1888 [size=8] Region 3: I/O ports at 1880 [size=8] Region 4: I/O ports at 1878 [size=8] Region 5: I/O ports at 1850 [size=16] Kernel driver in use: serial Kernel modules: parport_serial 00: 10 97 35 98 03 01 80 02 01 02 00 07 08 40 00 00 10: 99 18 00 00 91 18 00 00 89 18 00 00 81 18 00 00 20: 79 18 00 00 51 18 00 00 00 00 00 00 14 10 99 02 30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00 40: 80 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 The ttyS4/5 ports are not working when acpi irq routing is used. There are several combinations: 1) acpi routing enabled (no kernel parameter) => ports 4+5 defunct. ports 4+5+6+7 are all on irq 11 2) acpi routing disabled (acpi=noirq) => all ports working, 4+5 on irq 10, 6+7 on irq 11 3) with the quirk [1] and acpi routing enabled => all ports working, ports 4+5 on irq 10, 6+7 on irq 11 4) in windows (ACPI enabled) => 4+5+6+7 are all on irq 9 and the ports are all working.
Created attachment 29322 [details] dmesg with acpi=noirq
Created attachment 29332 [details] acpidump
Created attachment 29342 [details] proposed patch I proposed this patch which solves this issue for me, but after the discussion at: http://lkml.org/lkml/2010/6/27/85 I don't know, whether there is a bug in the ACPI code or it is a broken BIOS.
Will you please also attach the output of lspci -vxxx, dmesg after the system is booted without the boot option of "acpi=noirq"? Thanks.
(In reply to comment #4) > Will you please also attach the output of lspci -vxxx, dmesg after the system > is booted without the boot option of "acpi=noirq"? Dmesg without acpi=noirq is already attached as attachment 29312 [details]. Currently I have lspci noly from acpi=noirq run. I'll attach the other lspci output later.
Created attachment 29712 [details] lspci -nnvvvxxx with acpi=noirq
Created attachment 29902 [details] lspci -nnvvvxxx without acpi=noirq
Created attachment 41762 [details] use the attached tool to dump the BIOS PRT table info Will you please use the attached tool to dump the corresponding BIOS PRT info on your box? Thanks. Yakui
Created attachment 43182 [details] result without acpi_noirq
Created attachment 43192 [details] result with acpi_noirq
Done, but I cannot change the needinfo flag to something sane.
With this change it works _without_ acpi=noirq: --- a/drivers/acpi/pci_link.c +++ b/drivers/acpi/pci_link.c @@ -557,7 +557,7 @@ static int acpi_pci_link_allocate(struct * the use of IRQs 9, 10, 11, and >15. */ for (i = (link->irq.possible_count - 1); i >= 0; i--) { - if (acpi_irq_penalty[irq] > + if (acpi_irq_penalty[irq] >= acpi_irq_penalty[link->irq.possible[i]]) irq = link->irq.possible[i]; } dmesg then shows difference like: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A -ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11 -PCI: setting IRQ 11 as level-triggered -serial 0000:00:09.0: PCI INT A -> Link[LNKB] -> GSI 11 (level, low) -> IRQ 11 -0000:00:09.0: ttyS4 at I/O 0x1898 (irq = 11) is a 16550A -0000:00:09.0: ttyS5 at I/O 0x1890 (irq = 11) is a 16550A +ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 +PCI: setting IRQ 10 as level-triggered +serial 0000:00:09.0: PCI INT A -> Link[LNKB] -> GSI 10 (level, low) -> IRQ 10 +0000:00:09.0: ttyS4 at I/O 0x1898 (irq = 10) is a 16550A +0000:00:09.0: ttyS5 at I/O 0x1890 (irq = 10) is a 16550A ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 +PCI: setting IRQ 11 as level-triggered serial 0000:00:0b.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11 0000:00:0b.0: ttyS6 at I/O 0x18c0 (irq = 11) is a 16550A 0000:00:0b.0: ttyS7 at I/O 0x18b8 (irq = 11) is a 16550A
It's great that kernel bugzilla is back. Jiri, can you please verify if the problem still exists in the latest upstream kernel?