Hallo,
einige Zeit nach dem Starten kommt die Meldung auf der Konsole und in /var/log/kern.log:
irq 7: nobody cared (try booting with the "irqpoll" option)
Call Trace: <IRQ> [<ffffffff802a42f9>] __report_bad_irq+0x30/0x7d [<ffffffff802a4533>] note_interrupt+0x1ed/0x22e [<ffffffff802a3a32>] __do_IRQ+0xc7/0x105 [<ffffffff80210381>] __do_softirq+0x5e/0xd5 [<ffffffff80263731>] do_IRQ+0x65/0x73 [<ffffffff8026181f>] default_idle+0x0/0x50 [<ffffffff80258111>] ret_from_intr+0x0/0xa <EOI> [<ffffffff80261848>] default_idle+0x29/0x50 [<ffffffff802450da>] cpu_idle+0x95/0xb8 [<ffffffff8026c113>] start_secondary+0x43e/0x44d
handlers: [<ffffffff80374fb6>] (usb_hcd_irq+0x0/0x55) Disabling IRQ #7
Booten mit der Option irqpoll funktioniert nicht. Der Kernel ist weiterhin mit der Option noapic gestartet, ohne geht es nicht, also weder die eine noch die andere Option einzeln als auch zusammen. Der Kernel ist ein 2.6.18-6-amd64.
/proc/interrupts zeigt bei irq 7 vor und nach der Meldung nur auf ehci_hcd:usb2 Die Zählerstände für CPU0 und 1 erhöhen sich hier weiterhin kontinuierlich.
Auf irq 11 ist noch ein ohci_hcd:usb1 bei dem die CPU-Zähler auf 0 stehen.
Es sind jedoch keine USB-Geräte am Rechner angeschlossen.
Google und Co. haben mir hier keine hilfreichen Informationen gegeben, wie das abzustellen ist bzw. ob das im jetzigen Zustand kritisch ist.
Kann mir dazu jemand etwas genaueres sagen?
Gruß Rico
Hi Rico,
On Wed, Jun 18, 2008 at 20:04:45 +0200, Rico Koerner wrote:
irq 7: nobody cared (try booting with the "irqpoll" option)
[...]
Disabling IRQ #7
Eventuell fehlerhaftes ACPI-BIOS. Probier mal die Bootoption "noirqdebug". Das beseitigt zwar nicht die Fehlerquelle, aber so schaltet der Kernel IRQ 7 nicht mehr ab.
Gruss, Chris
Christian Perle schrieb:
Hi Rico,
On Wed, Jun 18, 2008 at 20:04:45 +0200, Rico Koerner wrote:
irq 7: nobody cared (try booting with the "irqpoll" option)
[...]
Disabling IRQ #7
Eventuell fehlerhaftes ACPI-BIOS. Probier mal die Bootoption "noirqdebug". Das beseitigt zwar nicht die Fehlerquelle, aber so schaltet der Kernel IRQ 7 nicht mehr ab.
Ob das nach den neuen Erkenntnissen (siehe andere Mail) jetzt sinnvoll ist?
Gruß Rico
Hi Rico,
On Thu, Jun 19, 2008 at 18:37:34 +0200, Rico Koerner wrote:
[noirqdebug]
Ob das nach den neuen Erkenntnissen (siehe andere Mail) jetzt sinnvoll ist?
Probieren kann man es. Ich gehe nach wie vor von kaputtem IRQ-Routing durch fehlerhafte ACPI-Tables aus. Neuere Kernelversionen federn die ACPI-Fehler auch nur besser ab, im BIOS bleiben sie drin.
Ansonsten wundere ich mich schon, dass FSC einen *Server* mit NVidia-Chipsatz baut (von dem ich ungefaehr genausoviel halte wie von VIA).
Gruss, Chris
Christian Perle schrieb:
Hi Rico,
On Thu, Jun 19, 2008 at 18:37:34 +0200, Rico Koerner wrote:
[noirqdebug]
Ob das nach den neuen Erkenntnissen (siehe andere Mail) jetzt sinnvoll ist?
Probieren kann man es. Ich gehe nach wie vor von kaputtem IRQ-Routing durch fehlerhafte ACPI-Tables aus. Neuere Kernelversionen federn die ACPI-Fehler auch nur besser ab, im BIOS bleiben sie drin.
Ansonsten wundere ich mich schon, dass FSC einen *Server* mit NVidia-Chipsatz baut (von dem ich ungefaehr genausoviel halte wie von VIA).
Inzwischen wunder ich mich auch schon, was die da als Server anbieten, die BIOS-Einstellungen sind sehr dürftig. Daß man bei einem Server im BIOS "POST Errors" ausschalten muß, damit er nicht wegen fehlender Tastatur hängenbleibt, ist auch nicht sinnvoll. Muß man erstmal drauf kommen, daß das dort versteckt ist und sollte bei einem Server vielleicht von vornherein ausgeschaltet sein.
Die Kernel-Bootoption "noirqdebug" hat er anscheinend auch ignoriert, dmesg zeigt mir die Option nicht mit an und der Fehler tritt weiterhin auf. Hab den EIntrag schon in die menu.lst von grub eingetragen, weil ich dachte, auf der Kommandozeile etwas falsch gemacht zu haben.
Der SATA-Controller scheint übrigens nicht die Fehlerquelle zu sein, da nachdem alle Einstellungen wieder auf dem ursprünglichen Zustand sind, sich die beiden libata's auf irq 5 und 10 verteilt haben und ehci auf irq 7 wieder allein unterwegs ist.
# cat /proc/interrupts CPU0 CPU1 0: 235594 1194 XT-PIC timer 2: 0 0 XT-PIC cascade 4: 559 328 XT-PIC serial 5: 10403 80 XT-PIC libata 7: 2537 345039 XT-PIC ehci_hcd:usb1 8: 0 1 XT-PIC rtc 9: 0 0 XT-PIC acpi 10: 98391 928 XT-PIC libata, eth0 11: 0 0 XT-PIC ohci_hcd:usb2 12: 126 4 XT-PIC i8042 NMI: 54 39 LOC: 236713 236689 ERR: 247797 MIS: 0
# lsusb Bus 002 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000
ist inzwischen auch nicht mehr so umfangreich, obwohl die Einstellungen wie im Ausgangszustand sind.
Auch lsmod zeigt mir keinen verdächtigen Parallelport, der ja möglicherweise auf irq 7 unterwegs sein könnte. Das Board hat übrigens gar keinen LPT.
# lsmod Module Size Used by button 12192 0 ac 10376 0 battery 15496 0 ipv6 286048 37 loop 20112 0 tsdev 13056 0 evdev 15360 0 pcspkr 7808 0 serio_raw 12036 0 psmouse 44432 0 sg 40744 0 i2c_nforce2 12544 0 i2c_core 27776 1 i2c_nforce2 sr_mod 22436 0 cdrom 40488 1 sr_mod ext3 138512 8 jbd 65392 1 ext3 mbcache 14216 1 ext3 dm_mirror 25216 0 dm_snapshot 20664 0 dm_mod 62800 17 dm_mirror,dm_snapshot raid1 27008 2 md_mod 82844 3 raid1 ide_generic 5760 0 [permanent] sd_mod 25856 6 amd74xx 19504 0 [permanent] generic 10500 0 [permanent] ide_core 147584 3 ide_generic,amd74xx,generic sata_nv 17412 4 libata 106784 1 sata_nv ohci_hcd 24836 0 forcedeth 46340 0 ehci_hcd 36104 0 scsi_mod 153008 4 sg,sr_mod,sd_mod,libata thermal 20240 0 processor 38248 1 thermal fan 9864 0
Gruß Rico
Hi, * Rico Koerner rico.koerner@heico.net [2008-06-19 10:53]:
[...] irq 7: nobody cared (try booting with the "irqpoll" option)
"irqpoll" willst du nicht wirklich ;)
[...] handlers: [<ffffffff80374fb6>] (usb_hcd_irq+0x0/0x55) Disabling IRQ #7
Womit dein USB Port warscheinlich ins leere ruft.
Booten mit der Option irqpoll funktioniert nicht.
Und wenn würdest du keinen Spaß damit haben, da irqs ja gerade dazu da sind polling zu vermeiden.
Der Kernel ist weiterhin mit der Option noapic gestartet, ohne geht es nicht, also weder die eine noch die andere Option einzeln als auch zusammen. Der Kernel ist ein 2.6.18-6-amd64.
Einmal eine etwas neuere (>=2.6.22) ausprobiert? Ich hatte (von der 2.6.12) bis zur 2.6.24 immer Fehler "APIC error on CPU0: 40 (40)" wenn mein Rechner was zu tun hatte, das hat sich mit der .24 gegeben.
/proc/interrupts zeigt bei irq 7 vor und nach der Meldung nur auf ehci_hcd:usb2 Die Zählerstände für CPU0 und 1 erhöhen sich hier weiterhin kontinuierlich.
Was ist das für ein Controller? Was sagt lspci/lsusb, ist der ehci-treiber geladen, stehen zu dem irgendwelche Meldungen im Log?
Auf irq 11 ist noch ein ohci_hcd:usb1 bei dem die CPU-Zähler auf 0 stehen.
Na das Problem scheind ja der EHCI auf 7 zu sein.
Es sind jedoch keine USB-Geräte am Rechner angeschlossen.
Google und Co. haben mir hier keine hilfreichen Informationen gegeben, wie das abzustellen ist bzw. ob das im jetzigen Zustand kritisch ist.
Im besten Fall geht dein EHCI USB-Port nicht, weil der Treiber net funktioniert. Im schlimmsten Fall hat sich irgendwas auf deiner Hardware verabschiedet.
Kann mir dazu jemand etwas genaueres sagen?
Ich so jetzt leider erst einmal nicht.
Grüße,
Jan L.
Jan Losinski schrieb:
Hi,
- Rico Koerner rico.koerner@heico.net [2008-06-19 10:53]:
[...] irq 7: nobody cared (try booting with the "irqpoll" option)
"irqpoll" willst du nicht wirklich ;)
Nein, nicht wirklich, aber getestet hab ichs mal. ;-)
[...] handlers: [<ffffffff80374fb6>] (usb_hcd_irq+0x0/0x55) Disabling IRQ #7
Womit dein USB Port warscheinlich ins leere ruft.
auch wenn ich nicht verstehe, was mir diese Zeile sagen will, aber ich nehm das mal so hin.
Booten mit der Option irqpoll funktioniert nicht.
Und wenn würdest du keinen Spaß damit haben, da irqs ja gerade dazu da sind polling zu vermeiden.
Und Polling nur dazu da ist, wenn es sonst mit einem irq-sharing nicht klappt, wenn ich das richtig verstanden habe. Aber dort ist ja nur ein Kernelmodul/Gerät oder was auch immer drauf, noch dazu ein unbenutzes USB-*.
Der Kernel ist weiterhin mit der Option noapic gestartet, ohne geht es nicht, also weder die eine noch die andere Option einzeln als auch zusammen. Der Kernel ist ein 2.6.18-6-amd64.
Einmal eine etwas neuere (>=2.6.22) ausprobiert? Ich hatte (von der 2.6.12) bis zur 2.6.24 immer Fehler "APIC error on CPU0: 40 (40)" wenn mein Rechner was zu tun hatte, das hat sich mit der .24 gegeben.
Nein, hatte ich auch nicht unbedingt vor. Ich wollte mit dem leben, was mir etch bietet.
/proc/interrupts zeigt bei irq 7 vor und nach der Meldung nur auf ehci_hcd:usb2 Die Zählerstände für CPU0 und 1 erhöhen sich hier weiterhin kontinuierlich.
Was ist das für ein Controller? Was sagt lspci/lsusb, ist der ehci-treiber geladen, stehen zu dem irgendwelche Meldungen im Log?
lspci sagt diesbezüglich: 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
lsusb: Bus 005 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 002 Device 001: ID 0000:0000
Auf irq 11 ist noch ein ohci_hcd:usb1 bei dem die CPU-Zähler auf 0 stehen.
Na das Problem scheind ja der EHCI auf 7 zu sein.
Ja, ich habs nur erwähnt, weil ebenfalls USB aber andererseits nicht ehci sondern ohci. Hab mich grad mal informiert, was die Unterschiede sind (OHCI=USB1.0, EHCI=USB2.0). Im BIOS kann ich kein USB, 1.1 allein oder 1.1+2.0 einstellen, letzteres ist aktuell der Fall. Allerdings geht es hier wohl eher um die Protokollunterstützung, nicht um verschiedene Ports oder Controller. Außerdem noch der USB BIOS Legacy Support, der allerdings nichts beeinflußt.
Ich hab soeben mal den USB2.0-Support im BIOS abgeschaltet, jetzt ist auf dem irq 7 ein zweites libata aktiv, das bisher nur auf irq 5. Anscheinend haben sich auch einige andere irq anders verteilt, denn auf der 11 ist zum ohci noch eth0 gekommen, das vorher mit einem anderen Gerät zusammenlag. EHCI ist jetzt verständlicherweise nicht mehr mit in der Liste.
# lsusb Bus 001 Device 001: ID 0000:0000
ist entsprechend knapper. Die Ausgabe von lspci wegen Zeilenumbruch in der Mail in den Anhang verlegt.
Nach einigen Minuten mußte ich erstaunt feststellen, daß die Fehlermeldung irq 7 disabled weiterhin erscheint und jetzt auf ein Problem mit SATA hinweisen (siehe kern.log-Auszug im Anhang). Am USB lags damit wohl nicht.
Da mir hier die sda-Platte rausfliegt, betrifft es den SATA0-Controller im BIOS. Dort kann ich von "native" auf "compatible" umschalten. Das hat dann zur Folge, daß die Interrupttabelle neu gemischt wird, nur noch ein libata auftaucht, allerdings wieder auf irq 7, irq 5 ist jetzt unbenutzt. Dafür tauchen ide0 und ide1 auf und fdisk zeigt mir jetzt eine der Platten als hda und die andere als sda, da sie auf beide Controller verteilt waren. Das war auch nicht das gewünschte Ergebnis.
Der irq 7 Fehler inkl. SATA-Fehlermeldungen tritt weiterhin auf, immer noch in Bezug auf sda. Nach meiner Theorie müßte doch vorher der 1. SATA-Controller sda und der 2. sdb zur Verfügung gestellt haben. Wenn der 1. jetzt im Kompatibilitätsmodus als ide -> hda autaucht, müßte doch der 2. Controller jetzt sda zur Verfügung stellen, die vorher sdb war? Jetzt ist natürlich die sda-Platte rausgeflogen und das System vollkommen gecrasht. Na zum Glück ist der Server noch nicht im Produktiveinsatz.
Ich vermute das Problem langsam beim sata-Treiber.
Ich hoffe die neuen Erkenntnisse bringen etwas Licht ins dunkel.
Im besten Fall geht dein EHCI USB-Port nicht, weil der Treiber net funktioniert. Im schlimmsten Fall hat sich irgendwas auf deiner Hardware verabschiedet.
Das ist ein neuer Server (Siemens Primergy Econel EC130S1) mit einem nvidia MCP51 Chipsatz. Dann wäre es wohl ein Garantiefall.
Gruß Rico
00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2) 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2) 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2) 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2) 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2) 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2) 00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:05.0 VGA compatible controller: nVidia Corporation C51 PCI Express Bridge (rev a2) 00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2) 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3) 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3) 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) 00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev f1) 00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev f1) 00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev f1) 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) 00:14.0 Ethernet controller: nVidia Corporation MCP51 Ethernet Controller (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
Jun 19 17:08:09 dhcp-17 kernel: irq 7: nobody cared (try booting with the "irqpoll" option) Jun 19 17:08:09 dhcp-17 kernel: Jun 19 17:08:09 dhcp-17 kernel: Call Trace: Jun 19 17:08:09 dhcp-17 kernel: <IRQ> [<ffffffff802a42f9>] __report_bad_irq+0x30/0x7d Jun 19 17:08:09 dhcp-17 kernel: [<ffffffff802a4533>] note_interrupt+0x1ed/0x22e Jun 19 17:08:09 dhcp-17 kernel: [<ffffffff802a3a32>] __do_IRQ+0xc7/0x105 Jun 19 17:08:09 dhcp-17 kernel: [<ffffffff80210381>] __do_softirq+0x5e/0xd5 Jun 19 17:08:09 dhcp-17 kernel: [<ffffffff80263731>] do_IRQ+0x65/0x73 Jun 19 17:08:09 dhcp-17 kernel: [<ffffffff8026181f>] default_idle+0x0/0x50 Jun 19 17:08:09 dhcp-17 kernel: [<ffffffff80258111>] ret_from_intr+0x0/0xa Jun 19 17:08:09 dhcp-17 kernel: <EOI> [<ffffffff80261848>] default_idle+0x29/0x50 Jun 19 17:08:09 dhcp-17 kernel: [<ffffffff802450da>] cpu_idle+0x95/0xb8 Jun 19 17:08:09 dhcp-17 kernel: [<ffffffff8026c113>] start_secondary+0x43e/0x44d Jun 19 17:08:09 dhcp-17 kernel: Jun 19 17:08:09 dhcp-17 kernel: handlers: Jun 19 17:08:09 dhcp-17 kernel: [<ffffffff88067114>] (nv_generic_interrupt+0x0/0xa7 [sata_nv]) Jun 19 17:08:09 dhcp-17 kernel: Disabling IRQ #7 Jun 19 17:08:44 dhcp-17 kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Jun 19 17:08:44 dhcp-17 kernel: ata1.00: tag 0 cmd 0xea Emask 0x4 stat 0x40 err 0x0 (timeout) Jun 19 17:08:45 dhcp-17 kernel: ata1: soft resetting port Jun 19 17:08:45 dhcp-17 kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Jun 19 17:09:15 dhcp-17 kernel: ata1.00: qc timeout (cmd 0xec) Jun 19 17:09:15 dhcp-17 kernel: ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) Jun 19 17:09:15 dhcp-17 kernel: ata1.00: revalidation failed (errno=-5) Jun 19 17:09:15 dhcp-17 kernel: ata1: failed to recover some devices, retrying in 5 secs Jun 19 17:09:20 dhcp-17 kernel: ata1: hard resetting port Jun 19 17:09:20 dhcp-17 kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Jun 19 17:09:50 dhcp-17 kernel: ata1.00: qc timeout (cmd 0xec) Jun 19 17:09:50 dhcp-17 kernel: ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) Jun 19 17:09:50 dhcp-17 kernel: ata1.00: revalidation failed (errno=-5) Jun 19 17:09:50 dhcp-17 kernel: ata1: failed to recover some devices, retrying in 5 secs Jun 19 17:09:55 dhcp-17 kernel: ata1: hard resetting port Jun 19 17:09:56 dhcp-17 kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Jun 19 17:10:26 dhcp-17 kernel: ata1.00: qc timeout (cmd 0xec) Jun 19 17:10:26 dhcp-17 kernel: ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) Jun 19 17:10:26 dhcp-17 kernel: ata1.00: revalidation failed (errno=-5) Jun 19 17:10:26 dhcp-17 kernel: ata1.00: disabled Jun 19 17:10:26 dhcp-17 kernel: ata1: EH complete Jun 19 17:10:26 dhcp-17 kernel: sd 0:0:0:0: SCSI error: return code = 0x00040000 Jun 19 17:10:26 dhcp-17 kernel: end_request: I/O error, dev sda, sector 488391877 Jun 19 17:10:26 dhcp-17 kernel: raid1: Disk failure on sda3, disabling device. Jun 19 17:10:26 dhcp-17 kernel: ^IOperation continuing on 1 devices Jun 19 17:10:26 dhcp-17 kernel: sd 0:0:0:0: SCSI error: return code = 0x00040000 Jun 19 17:10:26 dhcp-17 kernel: end_request: I/O error, dev sda, sector 385343 Jun 19 17:10:26 dhcp-17 kernel: raid1: Disk failure on sda1, disabling device. Jun 19 17:10:26 dhcp-17 kernel: ^IOperation continuing on 1 devices Jun 19 17:10:26 dhcp-17 kernel: RAID1 conf printout: Jun 19 17:10:26 dhcp-17 kernel: --- wd:1 rd:2 Jun 19 17:10:26 dhcp-17 kernel: disk 0, wo:1, o:0, dev:sda3 Jun 19 17:10:26 dhcp-17 kernel: disk 1, wo:0, o:1, dev:sdb3 Jun 19 17:10:26 dhcp-17 kernel: RAID1 conf printout: Jun 19 17:10:26 dhcp-17 kernel: --- wd:1 rd:2 Jun 19 17:10:26 dhcp-17 kernel: disk 1, wo:0, o:1, dev:sdb3 Jun 19 17:10:26 dhcp-17 kernel: RAID1 conf printout: Jun 19 17:10:26 dhcp-17 kernel: --- wd:1 rd:2 Jun 19 17:10:26 dhcp-17 kernel: disk 0, wo:1, o:0, dev:sda1 Jun 19 17:10:26 dhcp-17 kernel: disk 1, wo:0, o:1, dev:sdb1 Jun 19 17:10:26 dhcp-17 kernel: RAID1 conf printout: Jun 19 17:10:26 dhcp-17 kernel: --- wd:1 rd:2 Jun 19 17:10:26 dhcp-17 kernel: disk 1, wo:0, o:1, dev:sdb1
lug-dd@mailman.schlittermann.de
-
Christian Perle -
Jan Losinski -
Rico Koerner -
Rico Koerner