Disconnecting VGA cable => kernel: Disabling IRQ #16

[risa2000]

I am running x86_64 gentoo on Core i3 530 (using H55 chipset). The machine is configured as server, so it does not have any X.org stuff on it and there is normally no keyboard or monitor attached.
Recently I noticed interesting behavior: When disconnecting VGA cable (which I used to connect monitor to be able to flash BIOS and review BIOS settings), following message appears in messages:

Code: Select all

Nov 28 08:55:01 core-i3 kernel: irq 16: nobody cared (try booting with the "irqpoll" option)
Nov 28 08:55:01 core-i3 kernel: Pid: 0, comm: kworker/0:1 Not tainted 2.6.36.1 #1
Nov 28 08:55:01 core-i3 kernel: Call Trace:
Nov 28 08:55:01 core-i3 kernel: <IRQ>  [<ffffffff81061f9c>] __report_bad_irq+0x38/0x87
Nov 28 08:55:01 core-i3 kernel: [<ffffffff810620fe>] note_interrupt+0x113/0x179
Nov 28 08:55:01 core-i3 kernel: [<ffffffff81062882>] handle_fasteoi_irq+0xa2/0xc7
Nov 28 08:55:01 core-i3 kernel: [<ffffffff81004927>] handle_irq+0x1f/0x28
Nov 28 08:55:01 core-i3 kernel: [<ffffffff81003fca>] do_IRQ+0x57/0xbe
Nov 28 08:55:01 core-i3 kernel: [<ffffffff8143d5d3>] ret_from_intr+0x0/0xa
Nov 28 08:55:01 core-i3 kernel: <EOI>  [<ffffffff8128edb8>] ? intel_idle+0xdc/0x102
Nov 28 08:55:01 core-i3 kernel: [<ffffffff8128ed9b>] ? intel_idle+0xbf/0x102
Nov 28 08:55:01 core-i3 kernel: [<ffffffff8135d092>] cpuidle_idle_call+0x9f/0xd5
Nov 28 08:55:01 core-i3 kernel: [<ffffffff810011e1>] cpu_idle+0x5a/0x91
Nov 28 08:55:01 core-i3 kernel: [<ffffffff81437f23>] start_secondary+0x192/0x196
Nov 28 08:55:01 core-i3 kernel: handlers:
Nov 28 08:55:01 core-i3 kernel: [<ffffffff81328829>] (usb_hcd_irq+0x0/0x60)
Nov 28 08:55:01 core-i3 kernel: Disabling IRQ #16

I have read irqpoll explanation, but it seems to me this is not the case (i.e. misconfigured IRQ routing in BIOS). I believe the problem is that the same line is shared with Intel integrate graphics and when I disconnect VGA cable, hardware tries to signal that. But according to kernel, in my case, there is no gfx driver registered on IRQ 16:

Code: Select all

core-i3 log # cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
  0:         43          2          1          1   IO-APIC-edge      timer
  1:          2          2          2          2   IO-APIC-edge      i8042
  4:        364        360        376        415   IO-APIC-edge      serial
  9:          0          0          0          0   IO-APIC-fasteoi   acpi
 16:         10          6          6          6   IO-APIC-fasteoi   ehci_hcd:usb1
 18:       2031       2076       2081       2025   IO-APIC-fasteoi   ethx
 21:      46425      46366      46357      46383   IO-APIC-fasteoi   ath9k
 23:         58         54         52         54   IO-APIC-fasteoi   ehci_hcd:usb2
 40:       1643       1664       1642       1624   PCI-MSI-edge      ahci
 41:       1708       1713       1727       1733   PCI-MSI-edge      eth0
NMI:          0          0          0          0   Non-maskable interrupts
LOC:      14911      29575       9859       9312   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:          0          0          0          0   Performance monitoring interrupts
PND:          0          0          0          0   Performance pending work
RES:       1258        733         43         31   Rescheduling interrupts
CAL:         36        198        242        250   Function call interrupts
TLB:         10         13          4         23   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:          8          8          8          8   Machine check polls
ERR:          3
MIS:          0

The interesting consequence is that when systems disables IRQ 16 line, it actually disables ehci_hcd:usb1, which should be perfectly fine.

I do not want to install X.org just to investigate it further. I wonder if there might be other solution (apart from using either irqpoll or noirqdebug) without sacrificing complete IRQ 16 line. So far it seems there is nothing on vanilla kernel level, which can handle such interrupt.

Interestingly though, lspci shows VGA hw is linked to IRQ 11:

Code: Select all

00:02.0 VGA compatible controller: Intel Corporation Clarkdale Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
        Subsystem: Intel Corporation Device 0036
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at fe000000 (64-bit, non-prefetchable) [size=4M]
        Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at f100 [size=8]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
                Address: 00000000  Data: 0000
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a4] PCI Advanced Features
                AFCap: TP+ FLR+
                AFCtrl: FLR-
                AFStatus: TP-

[eyoung100]

Was there a USB port on the monitor you unplugged? Dell is famous for this...

As a possible work around compile ehci_hcd as a module, unload it, plug monitor in so the usb is not detected, perform upgrades/updates, unplug monitor, and reload module remotely using modprobe ehci_hcd

Option 2:
Use a monitor that has no usb ports

[risa2000]

Option 2:
Use a monitor that has no usb ports

Actually, I used old Samsung CRT connected through standard "D-SUB" VGA connector, which does not have any USB ports. But I am not sure, if there could be some proprietary communication line on D-SUB.

If I understood correctly, you suggest that reloading ehci_hcd driver might get it working again. So as a workaround I could simply do both module unload and reload after it happens (which is usually easier). Unless there is some reason to unload driver before, which I do not see now.

[idella4]

go tou your /usr/src/linux,
post output of

grep CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS .config

This is in place in a vanilla kernel.

Code: Select all

genny linux-2.6.36 # grep CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS .config
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y

[risa2000]

go tou your /usr/src/linux,
post output of

grep CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS .config

For me, it is not set. I guess I turned it off long time ago, since I thought it did not apply to me. I understood it addressed something happening at boot with broken BIOSes.

Code: Select all

risa@core-i3 ~ $ grep CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS /boot/config-2.6.36.1
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set

[idella4]

It's just my best guess, and I am guessing. Try it out. Perhaps another related IRQ kernel setting.
hey, Neddy is here; with some luck....