# 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:

```
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:

```
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:

```
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

 *eyoung100 wrote:*   

> 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.

```

genny linux-2.6.36 # grep CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS .config

CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y

```

----------

## risa2000

 *idella4 wrote:*   

> 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.

```
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....

----------

