[intrepid] becomes unresponsive after some time; unexpected IRQ trap? (Dell Latitude D430)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
With the intrepid kernel (2.6.26-4), my system becomes very sluggish after some hours of working with it. Typing in terminals feels like tar, and every key stroke takes about 0.5 seconds response time. Also, shutdown becomes veeery slow and most of the time just hangs. OTOH, firefox works just fine.
I noticed that after a while dmesg has several dozen repeats of the following messages:
[20563.433058] ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
[20563.433058] PM: Writing back config space on device 0000:0c:00.0 at offset 1 (was 100002, writing 100006)
[20563.433058] iwl3945: Radio disabled by HW RF Kill switch
[20563.433058] ACPI: PCI interrupt for device 0000:0c:00.0 disabled
[20714.959047] ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 17
[20714.959047] PM: Writing back config space on device 0000:0c:00.0 at offset 1 (was 100002, writing 100006)
[20714.959047] iwl3945: Radio disabled by HW RF Kill switch
[20714.959047] ACPI: PCI interrupt for device 0000:0c:00.0 disabled
[20725.262003] irq 219, desc: c0478c00, depth: 0, count: 0, unhandled: 0
[20725.262003] ->handle_irq(): c016aef0, handle_
[20725.262003] ->chip(): c044d8c0, no_irq_
[20725.262003] ->action(): 00000000
[20725.262003] IRQ_DISABLED set
[20725.262003] IRQ_MASKED set
[20725.262003] unexpected IRQ trap at vector db
I cannot confirm whether these messages start when the system becomes sluggish. I'll put some more attention to that.
This does not happen at all when running Intrepid with the Hardy kernel, the system runs happily for days, through suspends and hibernates, etc.
Changed in linux: | |
assignee: | nobody → ubuntu-kernel-team |
Oh, for the record, this is a Dell Latitude D430, running i386 hardy. System is docked, with the wifi turned off with the killswitch (as dmesg says correctly).
top etc. show that the CPU is at 0% while that happens, so there is no specific process blocking CPU or I/O.