irq 11: nobody cared..

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
Antworten
Benutzeravatar
Corcovado
Beiträge: 222
Registriert: 13.02.2005 13:01:55

irq 11: nobody cared..

Beitrag von Corcovado » 12.06.2006 22:34:59

Hallo,
Seitdem ich mein Thinkpad X31 habe, geistert bei mir ein Problem herum: Eingangssignale meiner USB Maus werden nicht sauber von PS/2 Signalen getrennt, mysterioes zufaellig auftretendes Doppelklicken der Maus, seltsame Probleme beim konfigurieren der Daumentasten der Maus mit imwheel, was ich schliesslich auf dem Computer irgendwann aufgab. Im Forum befuerchtete damals jemand schon ein IRQ Problem, mit verschiedensten Einstellungen allerdings konnte ich die Effekte immer wieder umgehen bzw. daempfen. Ein anderes Problem war, dass nach einem booten mit angestecktem externen USB Laufwerk plus USB Maus, sich der Mauszeiger nur sehr schwerfaellig bewegen lies, bzw gar nicht mehr.

Nun habe ich beim aktuellen Kernel, der ca seit 2 Monate mit versehentlich vergessener inotify Option laeuft, versucht diese "inotify" nachzuruesten und den Kernel neu zu backen. Daraufhin lief der Mauszeiger wieder mal nur noch sehr schwerfaellig. Ein dmesg schleuderte mir aber diesmal haufenweise kryptische IRQ 11 Flueche entgegen und damit wende ich mich nun wieder ans Forum. Ich denke das dieses Problem immens wichtig ist, da es wohl mit verschiedensten Auswirkungen zusammenhaengt. :( :( :(

Ist das ein Interrupt Problem von IRQ 11?
Was kann ich tun?
Falls andere gravierende Maengel in den dmesgs auffallen, bitte Bescheid geben!


[der nichtkonfigurierte Lirc sollte nicht das Thema werden, ich werde ihn deinstallieren, habe ihn aber beibehalten um beide Files vergleichen zu koennen.]

Kernel .config (bei beiden gleich ausser CONFIG_INOTIFY )
http://nopaste.debianforum.de/3409

dmesg vom alten Kernel
http://nopaste.debianforum.de/3410

dmesg vom neuen Kernel (mit inotify, sonst alles gleich)
http://nopaste.debianforum.de/3411


Kleiner Nachtrag:

Code: Alles auswählen

drops 13 # cat /proc/interrupts
           CPU0
  0:    1225683          XT-PIC  timer
  1:      24916          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  7:          0          XT-PIC  parport0
  8:          4          XT-PIC  rtc
  9:        105          XT-PIC  acpi
 11:     200391          XT-PIC  yenta, yenta, uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, ehci_hcd:usb4, Intel 82801DB-ICH4 Modem, ohci1394, wifi0, Intel 82801DB-ICH4
 12:        244          XT-PIC  i8042
 14:      16489          XT-PIC  ide0
NMI:          0
LOC:          0
ERR:          0
MIS:          0

Benutzeravatar
Corcovado
Beiträge: 222
Registriert: 13.02.2005 13:01:55

Problem Geloest!!

Beitrag von Corcovado » 13.06.2006 00:16:08

Yeah! I cared - Super-Corco!!! ich! ich! ich! :P :P :P :wink:

Es war ein Interrupt Problem meines IBM Thinkpad X31! Ich habe soeben voller low-level-Verachtung mein BIOS penetriert und eine Option gefunden unter "PCI", die festlegt welche Interrupts verwendet werden sollen. Diese befanden sich alle samt (afair waren es 8 Stk) auf IRQ 11. Nach etwas herumspielen fand ich dort die Moeglichkeit diese auf "Automatic" zu setzen statt auf 11, so dass wohl je nach Bedarf auch ein anderer freier nicht-ISA oder nicht-EISA IRQ genutzt werden darf. Das war die Loesung des Problems (bis jetzt). Ich habe den ersten auf 11 gelassen und alle anderen auf "Automatic" gesetzt. Ein anderer Weg waere wohl gewesen, die IRQs manuell zu setzen - da haette ich das Forum hier aber wahrscheinlich noch gut genervt.

Ich habe einiges an aehnlichen Fehlermeldungen mit Google gefunden, jedoch alle samt ohne Loesung. Meisstens scheint es wohl darauf hinauszulaufen, dass man bei einem nobody-cared-Fehler einen Bugreport schreibt, da es in vielen Faellen anscheinend am Kernel zu liegen scheint, somit hilft wechseln des Kernels, mitgeben entsprechender bootparameter (sh output), ausfindigmachen der stoerenden Module (in meinem Fall wohl die Intel ICH4 Sound und Modem Module), evtl dort entsprechende Parameter beim laden mitgeben bis hin zu Abaenderungen im Kernelcode, die man durchfuehren soll (ob das so einfach geht?!) oder direkt unbehebbaren Hardware Unvertraeglichkeiten, wie ich gelesen habe - dies trat nach meiner Info v.a. bei Nvidia Chips mit Kernel 2.6.<10 auf (hab das aber nur ueberflogen und da half oft ein neuer Kernel). Ich kann aus meiner Foobie Erfahrung nun dazu raten sich mal die Interrupt Setzung im BIOS etwas genauer anzusehen, diese sehen bei mir nun so aus:

Code: Alles auswählen

drops user # cat /proc/interrupts
           CPU0
  0:      66808          XT-PIC  timer
  1:       1033          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  5:          0          XT-PIC  yenta, Intel 82801DB-ICH4 Modem, Intel 82801DB-ICH4
  7:          0          XT-PIC  parport0
  8:          4          XT-PIC  rtc
  9:        103          XT-PIC  acpi
 11:       5033          XT-PIC  ohci1394, yenta, wifi0, ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4
 12:        178          XT-PIC  i8042
 14:       8686          XT-PIC  ide0
NMI:          0
LOC:          0
ERR:          0
MIS:          0


Hilft das nichts, scheint man ein echtes Problem zu haben...

Edit: habe nun alle auf "Automatic" gesetzt.

Antworten