| View previous topic :: View next topic |
| Author |
Message |
risa2000
n00b
Joined: 17 Oct 2004
Posts: 35
|
 Posted: Sun Nov 28, 2010 9:33 am Post subject: Disconnecting VGA cable => kernel: Disabling IRQ #16 |
 |
|
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: | 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: | 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: | 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- |
|
|
| Back to top |
|
 |
eyoung100
Veteran
Joined: 23 Jan 2004
Posts: 1428
|
| Posted: Mon Nov 29, 2010 4:39 pm Post subject: |
|
|
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
_________________
The Birth and Growth of Science is the Death and Atrophy of Art -- Unknown
Registerd Linux User #363735
Adopt a Post | Strip Comments| Emerge Wrapper |
|
| Back to top |
|
|
risa2000
n00b
Joined: 17 Oct 2004
Posts: 35
|
| Posted: Mon Nov 29, 2010 4:54 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
idella4
Retired Dev
Joined: 09 Jun 2006
Posts: 1600
Location: Australia, Perth
|
| Posted: Mon Nov 29, 2010 5:50 pm Post subject: |
|
|
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: |
genny linux-2.6.36 # grep CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS .config
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
|
_________________
idella4@aus |
|
| Back to top |
|
|
risa2000
n00b
Joined: 17 Oct 2004
Posts: 35
|
| Posted: Mon Nov 29, 2010 5:58 pm Post subject: |
|
|
| 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.
| Code: | 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 |
|
|
| Back to top |
|
|
idella4
Retired Dev
Joined: 09 Jun 2006
Posts: 1600
Location: Australia, Perth
|
| Posted: Mon Nov 29, 2010 6:01 pm Post subject: |
|
|
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....
_________________
idella4@aus |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
