Created attachment 135851 [details] Kernel Conflicts Hi, While booting the kernel I am getting a irq 16: nobody cared (try booting with the "irqpoll" option). Booting w/o irqpoll options disallows me from accessing USB ports while simultaneously crippling graphics[ very slow / sluggish ]. I have attached relevant conflicts w/ the kernel and the entire dmesg log.
Created attachment 135861 [details] dmesg
Created attachment 135871 [details] Corrected dmesg Had attached the incorrect dmesg.
acpidump and lspci please: # acpidump > acpidump.txt # lspci -vx > lspci Also, please try acpi=noirq kernel cmdline option.
Created attachment 136661 [details] acpidump.txt acpidump 2&> acpidump.txt
Created attachment 136671 [details] lspci -vx lspci -vx 2&> lspci.txt
With acpi=noirq kernel option, the USB and interrupt issue go away though the other 2 persist. Also, I've gained access to USB devices and smooth graphics using this option? Does this mean, I should be booting with this option everytime?
Also with acpi=noirq, I've noticed that the GUI performs faster than without it, but much slower than irqpoll boot.
I should have noticed this earlier: [ 1.023098] pci 0000:00:14.0: can't derive routing for PCI INT A [ 1.023099] pci 0000:00:14.0: PCI INT A: no GSI - using ISA IRQ 11 [ 1.023176] pci 0000:00:14.0: can't derive routing for PCI INT A I checked the acpi table, there is no entry for this USB host controller which is a bug of the BIOS. Can you please check if there is a BIOS update on your vendor web page? And from the result: irq16 nobody cared, it seems the irq pin of the USB host controller is routed to the same IOAPIC pin as the graphics card(which also uses irq 16 from the acpi table). This could explain when USB hardware fires an interrupt, all the other hardware that uses irq 16 don't think it has anything to deal with and OS found that irq16 is problematic. I wonder if there is a cmdline to force a device to use an irq, will check later.
Created attachment 137711 [details] dmesg dmesg post bios update This is the latest bios update from the manufacturer. The kernel has been booted with irqpoll parameter
Unfortunately, the new BIOS still has this problem. I have no idea what is the correct way to handle this. Hi Bjorn, The USB host controller 14.0 device doesn't have an entry in _PRT table so acpi can't give it a correct irq, this caused the 'irq16 nobody cared' problem. Can you please give some advice how this problem should be solved? Currently Amit is using irqpoll. Thanks.
Bug closed as this is clearly a BIOS bug. Aaron, can you please provide a customized DSDT for the reporter to use, in order to workaround the problem for amit.
Presumably this machine does work well with Windows, so having to use the irqpoll parameter or a customized DSDT means the Linux user experience is poor. It would be better if we could figure out a way to work around this BIOS bug so Linux would just work.
well, we can have a quirk either in pci_link.c to fake a _PRT entry for the specified model, or in PCI code to override the controller' interrupt bits in PCI config space. Not sure if they're doable and which is preferred. what do you think?
I think it's unlikely that Windows has a quirk for this box. I think it's more likely that Windows uses a different algorithm that is able to tolerate issues like this. I don't know what that algorithm would be or whether it could work in Linux, but it's possible somebody could reverse-engineer it by booting Windows on an instrumented qemu. But I'm not really an IRQ person, so this is all just speculation on my part, and I've certainly added my share of quirks like you're proposing.