PROBLEM: do_IRQ: [number] No irq handler for vector (irq -1) [resend]
I repeatedly get "No irq handler for vector" since upgrading to 3.12. I have confirmed it happens in git master as of yesterday morning (061f49ec2d722f485237870f04544d8bec15a778). Fixed by disabling VT-d quirk. [please cc me on responses; I'm not subscribed to the list. Adding linux-kernel because the iommu list seems broken.] DETAILS: This is on a ASUS Sabertooth X58 board. Ever since upgrading to 3.12, I've been flooded with messages like: Jan 5 19:06:46 Zia kernel: [292039.181501] do_IRQ: 1.76 No irq handler for vector (irq -1) Jan 5 19:08:26 Zia kernel: [292138.390433] do_IRQ: 2.140 No irq handler for vector (irq -1) Jan 5 19:40:16 Zia kernel: [294049.535992] do_IRQ: 1.84 No irq handler for vector (irq -1) Jan 5 23:12:18 Zia kernel: [306774.882154] do_IRQ: 1.227 No irq handler for vector (irq -1) When first booting 3.12, I got the "This system BIOS has enabled interrupt remapping on a chipset that contains an erratum making that feature unstable. To maintain system stability interrupt remapping is being disabled. Please contact your BIOS vendor for an update" message. I believe I also got the do_IRQ messages in that configuration, but am not completely sure. After seeing that, I rebooted the machine and turned off VT-d in the BIOS. The warning went away after that. However, the do_IRQ messages are definitely present in that configuration. I have found one configuration that stops them. I turned back on VT-d in the BIOS, and then disabled the fix "iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets" (03bbcb2e7e292838bb0244f5a7816d194c911d62). Also, I am running BIOS version 1402 (the latest), released 2012-08-29, with the release notes "improve VT-d compatibility issue." The machine has been perfectly stable, running pre-3.12 kernels with VT-d enabled (though I'm not sure I'm actually really using that feature, as I sometimes use KVM, but don't redirect any real hardware to the VMs). Here is the patch I used to disable the quirk: diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c index bab10b1..a5bf817 100644 --- a/drivers/iommu/intel_irq_remapping.c +++ b/drivers/iommu/intel_irq_remapping.c @@ -530,10 +530,11 @@ static int __init intel_irq_remapping_supported(void) "on a chipset that contains an erratum making that\n" "feature unstable. To maintain system stability\n" "interrupt remapping is being disabled. Please\n" - "contact your BIOS vendor for an update\n"); - add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK); + "contact your BIOS vendor for an update\n" + "Ignoring and leaving enabled anyway!\n"); + /* add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK); disable_irq_remap = 1; - return 0; + return 0; */ } if (!dmar_ir_support()) SYSTEM INFO: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz stepping: 5 microcode : 0x19 cpu MHz : 1600.000 cache size : 8192 KB physical id : 0 siblings: 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx f xsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonsto p_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dth erm tpr_shadow vnmi flexpriority ept vpid bogomips: 5612.59 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: ... (repeats through 7) 00:00.0 Host bridge: Intel Corporation 5520/5500/X58 I/O Hub to ESI Port (rev 13) Subsystem: ASUSTeK Computer Inc. Device 836b Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-SERR- 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 1 (rev 13) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-SERR-TAbort-Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 2 (rev 13) (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV-
PROBLEM: do_IRQ: [number] No irq handler for vector (irq -1) [resend]
I repeatedly get No irq handler for vector since upgrading to 3.12. I have confirmed it happens in git master as of yesterday morning (061f49ec2d722f485237870f04544d8bec15a778). Fixed by disabling VT-d quirk. [please cc me on responses; I'm not subscribed to the list. Adding linux-kernel because the iommu list seems broken.] DETAILS: This is on a ASUS Sabertooth X58 board. Ever since upgrading to 3.12, I've been flooded with messages like: Jan 5 19:06:46 Zia kernel: [292039.181501] do_IRQ: 1.76 No irq handler for vector (irq -1) Jan 5 19:08:26 Zia kernel: [292138.390433] do_IRQ: 2.140 No irq handler for vector (irq -1) Jan 5 19:40:16 Zia kernel: [294049.535992] do_IRQ: 1.84 No irq handler for vector (irq -1) Jan 5 23:12:18 Zia kernel: [306774.882154] do_IRQ: 1.227 No irq handler for vector (irq -1) When first booting 3.12, I got the This system BIOS has enabled interrupt remapping on a chipset that contains an erratum making that feature unstable. To maintain system stability interrupt remapping is being disabled. Please contact your BIOS vendor for an update message. I believe I also got the do_IRQ messages in that configuration, but am not completely sure. After seeing that, I rebooted the machine and turned off VT-d in the BIOS. The warning went away after that. However, the do_IRQ messages are definitely present in that configuration. I have found one configuration that stops them. I turned back on VT-d in the BIOS, and then disabled the fix iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets (03bbcb2e7e292838bb0244f5a7816d194c911d62). Also, I am running BIOS version 1402 (the latest), released 2012-08-29, with the release notes improve VT-d compatibility issue. The machine has been perfectly stable, running pre-3.12 kernels with VT-d enabled (though I'm not sure I'm actually really using that feature, as I sometimes use KVM, but don't redirect any real hardware to the VMs). Here is the patch I used to disable the quirk: diff --git a/drivers/iommu/intel_irq_remapping.c b/drivers/iommu/intel_irq_remapping.c index bab10b1..a5bf817 100644 --- a/drivers/iommu/intel_irq_remapping.c +++ b/drivers/iommu/intel_irq_remapping.c @@ -530,10 +530,11 @@ static int __init intel_irq_remapping_supported(void) on a chipset that contains an erratum making that\n feature unstable. To maintain system stability\n interrupt remapping is being disabled. Please\n - contact your BIOS vendor for an update\n); - add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK); + contact your BIOS vendor for an update\n + Ignoring and leaving enabled anyway!\n); + /* add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK); disable_irq_remap = 1; - return 0; + return 0; */ } if (!dmar_ir_support()) SYSTEM INFO: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz stepping: 5 microcode : 0x19 cpu MHz : 1600.000 cache size : 8192 KB physical id : 0 siblings: 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx f xsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonsto p_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dth erm tpr_shadow vnmi flexpriority ept vpid bogomips: 5612.59 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: ... (repeats through 7) 00:00.0 Host bridge: Intel Corporation 5520/5500/X58 I/O Hub to ESI Port (rev 13) Subsystem: ASUSTeK Computer Inc. Device 836b Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-SERR- 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 1 (rev 13) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-SERR-TAbort-Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 2 (rev 13) (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Glenn Maynard wrote: I've heard the claim, several times, that that creating a derivative work requires creative input, that linking stuff together with "ld" is completely uncreative, therefore no derivative work is created. (I'm not sure if you're making (here or elsewhere) that claim, but it seems like it.) What's the basis for this claim? (If you're not making it, anybody that does believe this is free to respond.) It's based on Title 17 USC, Sec. 101, where "derivative work" is defined: A âderivative workâ is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an ORIGINAL WORK OF AUTHORSHIP, is a âderivative workâ. (emphasis added) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Glenn Maynard wrote: I've heard the claim, several times, that that creating a derivative work requires creative input, that linking stuff together with ld is completely uncreative, therefore no derivative work is created. (I'm not sure if you're making (here or elsewhere) that claim, but it seems like it.) What's the basis for this claim? (If you're not making it, anybody that does believe this is free to respond.) It's based on Title 17 USC, Sec. 101, where derivative work is defined: A derivative work is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an ORIGINAL WORK OF AUTHORSHIP, is a derivative work. (emphasis added) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
