IRQ-Problem mit 2.6.32 / 2.6.39-Kernel unter Debian Squeeze x86_64
4959
MasterM
Ich habe vor kurzem einen neuen Computer zusammengebaut, damit die gesamte Hardware ziemlich neu ist. Seitdem habe ich Probleme mit IRQs bei der Ausführung von Debian 6.0. Bei zufälligen Anlässen, normalerweise nach etwa einer Stunde Laufen, höre ich einen Piepton, und dieser zeigt sich in dmesg:
Danach frisst Xorg entweder die CPU oder ist instabil (bis das System komplett aufgehängt ist). Wenn ich Xorg neu starte, ist alles wieder in Ordnung und das Problem tritt erst beim nächsten Neustart auf.
Ich habe versucht, den Kernel von stock 2.6.32auf 2.6.39unstable repository zu aktualisieren, aber das hat nicht geholfen. Das Booten mit irqpollOption scheint nur die anfängliche Zeitspanne zu verlängern, nach der das Problem auftritt.
Ich verwende die neuesten NVIDIA-Treiber und die Realtek-Firmware aus dem firmware-realtekPaket. Ich habe zwei GTX 560Ti, die in SLI laufen. Das Deaktivieren von SLI oder das vollständige Herausnehmen einer Karte löst das Problem ebenfalls nicht.
Ausgabe von uname -aist:
Linux whitestar 2.6.39-2-amd64 #1 SMP Wed Jun 8 11:01:04 UTC 2011 x86_64 GNU/Linux
Ausgabe von lspciist:
00:00.0 Host bridge: Intel Corporation Sandy Bridge DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Sandy Bridge PCI Express Root Port (rev 09) 00:01.1 PCI bridge: Intel Corporation Sandy Bridge PCI Express Root Port (rev 09) 00:16.0 Communication controller: Intel Corporation Cougar Point HECI Controller #1 (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 05) 00:1a.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #2 (rev 05) 00:1b.0 Audio device: Intel Corporation Cougar Point High Definition Audio Controller (rev 05) 00:1c.0 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 1 (rev b5) 00:1c.1 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 2 (rev b5) 00:1c.2 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 3 (rev b5) 00:1c.4 PCI bridge: Intel Corporation Cougar Point PCI Express Root Port 5 (rev b5) 00:1c.6 PCI bridge: Intel Corporation 82801 PCI Bridge (rev b5) 00:1d.0 USB Controller: Intel Corporation Cougar Point USB Enhanced Host Controller #1 (rev 05) 00:1f.0 ISA bridge: Intel Corporation Cougar Point LPC Controller (rev 05) 00:1f.2 SATA controller: Intel Corporation Cougar Point 6 port SATA AHCI Controller (rev 05) 00:1f.3 SMBus: Intel Corporation Cougar Point SMBus Controller (rev 05) 01:00.0 VGA compatible controller: nVidia Corporation Device 1200 (rev a1) 01:00.1 Audio device: nVidia Corporation Device 0e0c (rev a1) 02:00.0 VGA compatible controller: nVidia Corporation Device 1200 (rev a1) 02:00.1 Audio device: nVidia Corporation Device 0e0c (rev a1) 04:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) 06:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) 07:00.0 PCI bridge: Device 1b21:1080 (rev 01) 08:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10) 08:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0)
Zu guter Letzt sind diese Zeilen direkt nach dem Booten normalerweise in vorhanden dmesg:
[ 18.367094] hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj. [ 18.458859] hda-intel: IRQ timing workaround is activated for card #2. Suggest a bigger bdl_pos_adj.
Ich bin mir nicht sicher, ob es sich um ein verwandtes Problem oder um ein Symptom für ein größeres Problem handelt. Ich poste es also nur für den Fall.
Ich weiß nicht wirklich, welche anderen Informationen hier relevant sein könnten. Zögern Sie nicht, in den Kommentaren nach mehr zu fragen.
Anscheinend habe ich endlich eine Lösung für dieses Problem gefunden.
Man muss pci=routeirqdem Kernel eine Boot-Option hinzufügen . Wie in der Dokumentation angegeben, wird Folgendes ausgeführt:
Führen Sie IRQ-Routing für alle PCI-Geräte durch. Dies wird normalerweise in pci_enable_device () durchgeführt. Daher ist diese Option eine temporäre Problemumgehung für defekte Treiber, die sie nicht aufrufen.
Es scheint, dass der NVIDIA Xorg-Treiber hier der Schuldige ist. Ich sollte wahrscheinlich einen Fehlerbericht einreichen.
0
LawrenceC
Nur eine Vermutung ... Gehen Sie in Ihr BIOS und deaktivieren Sie alles über Ihre "SERR" -Funktion. Sie können auch versuchen, ein Update auf einen späteren Kernel durchzuführen, wenn dies möglich ist.
Leider habe ich keine solche Option in meinem BIOS. Wenn es um Kernel geht, laufe ich 2.6.39, also ist die nächste Version 3.0.0, die sich noch im RC-Stadium befindet.
MasterM vor 12 Jahren
0
0
ghost3k
Ich habe genau das gleiche Problem, wenn ich Debian 6.0 laufe, viele Kernel (2.6.32, 2.6.38, 2.6.39) und viele Kernel-Parameter ("irqpoll" oder "noapic") ausgemacht habe, aber "acpi =" off "machte das System manchmal für einige Tage nutzbar). Sie können also versuchen, mit "acpi = off" zu starten.
Mein Mainboard ist ein Asus P8H67-M EVO. Verwenden Sie auch ein Asus Mainboard mit einem Sandy Bridge-Chipsatz? Wenn ja, versuchen Sie auch, das BIOS zu aktualisieren, um das Problem möglicherweise zu beheben.
Ja, ich habe Asus P8P67 EVO mit einem Core i7 2600K. Ich habe kürzlich sowohl den BIOS- als auch den Linux-Kernel (3.0.0) auf die neueste Version aktualisiert, und das Problem schien leider nicht zu verschwinden.
MasterM vor 12 Jahren
0
Ich bekomme Kernel-Oopses, die IRQ 17 mit firewire_ohci und hda_intel auf 17 deaktivieren.
für das Protokoll ... Ich habe keine Nachrichten erhalten, seit ich noirqdebug zu command_line_linux_default in Grub hinzugefügt habe.
Eddie B vor 12 Jahren
0