Caps-Lock und Scroll LEDs blinken --> System friert ein !
Hi, ich habe folgendes Problem. Was hat das zu bedeutenm wenn Caps-Lock und Scroll LED blinken ? Das System friert dabei ein ! Kann das am Kernel liegen (Kernel-Panic)? In den Log files steht nichts. Ciao Tobias
Am Samstag, 2. Februar 2002 19:29 schrieben Sie:
Hi, ich habe folgendes Problem.
Was hat das zu bedeutenm wenn Caps-Lock und Scroll LED blinken ? Das System friert dabei ein !
Kann das am Kernel liegen (Kernel-Panic)? In den Log files steht nichts.
Ich denke schon, ich hab das jetzt mehrfach mit dem SuSE-Kernel 2.4.10, den die 7.3 installiert, erlebt. Manchmal hatte ich kaum Zeit, die lilo.conf zu ändern, um meinen eigenen Kernel zu aktivieren. Mit eigenem Kernel (> 2.4.10) hab ich so was aber noch nie erlebt.
Hi Tobias, Hatte das gleiche Problem beim installieren von Linux 7.3. Verwendete einen RAID SCSI Kontroller von Adaptec und ein ASUS A7V266-E. Loesung : Anderes Motherboard z.B ASUS A7V266 OHNE E laeuft spitze. mfg Thomas Mayr Am Samstag 02 Februar 2002 19:29 schrieb Tobias Geis:
Hi, ich habe folgendes Problem.
Was hat das zu bedeutenm wenn Caps-Lock und Scroll LED blinken ? Das System friert dabei ein !
Kann das am Kernel liegen (Kernel-Panic)? In den Log files steht nichts.
Ciao Tobias
On Mon, Feb 04, 2002 at 08:13:26AM +0100, Thomas wrote:
Hi Tobias,
Hatte das gleiche Problem beim installieren von Linux 7.3. Verwendete einen RAID SCSI Kontroller von Adaptec und ein ASUS A7V266-E.
Ich hab das Problem auch! Allerdings habe ich keinerlei SCSI in dem Rechner. Kann es sein, dass das irgendwie am Board selber liegt?
Loesung : Anderes Motherboard z.B ASUS A7V266 OHNE E laeuft spitze.
mfg Thomas Mayr
Am Samstag 02 Februar 2002 19:29 schrieb Tobias Geis:
Hi, ich habe folgendes Problem.
Was hat das zu bedeutenm wenn Caps-Lock und Scroll LED blinken ? Das System friert dabei ein !
Kann das am Kernel liegen (Kernel-Panic)? In den Log files steht nichts.
Ciao Tobias
Gruß Martin Spöhrle
Am Montag, 4. Februar 2002 10:21 schrieb Martin Spöhrle:
On Mon, Feb 04, 2002 at 08:13:26AM +0100, Thomas wrote:
Hi Tobias,
Hatte das gleiche Problem beim installieren von Linux 7.3. Verwendete einen RAID SCSI Kontroller von Adaptec und ein ASUS A7V266-E.
Ich hab das Problem auch! Allerdings habe ich keinerlei SCSI in dem Rechner. Kann es sein, dass das irgendwie am Board selber liegt?
Wahrscheinlich liegt es teilweise an der Hardware, da aber ein neuer (selbstkompilerter) Kernel bei mir Abhilfe schaffte, kann es das nicht allein sein. Ich hab das Problem jetzt auf drei verschiedenen Boards gesehen (von Asus und Gigabyte) Ich würde mal mit den Bootoptionen "enableapic, disableapic, noapic" spielen.
Am Montag, 4. Februar 2002 10:36:10 schrieb Mathias Weigt:
Am Montag, 4. Februar 2002 10:21 schrieb Martin Spöhrle:
On Mon, Feb 04, 2002 at 08:13:26AM +0100, Thomas wrote:
Hatte das gleiche Problem beim installieren von Linux 7.3. Verwendete einen RAID SCSI Kontroller von Adaptec und ein ASUS A7V266-E. Ich hab das Problem auch! Allerdings habe ich keinerlei SCSI in dem Rechner. Kann es sein, dass das irgendwie am Board selber liegt? Wahrscheinlich liegt es teilweise an der Hardware, da aber ein neuer (selbstkompilerter) Kernel bei mir Abhilfe schaffte, kann es das nicht allein sein. Ich hab das Problem jetzt auf drei verschiedenen Boards gesehen (von Asus und Gigabyte) Ich würde mal mit den Bootoptionen "enableapic, disableapic, noapic" spielen.
Ist zwar ein uralter Thread, aber ich fass den trotzdem nochmal an, weil es mir jetzt nämlich auch passiert - allerdings unter genau nachzuvollziehenden Umständen: Hardware: - AthlonXP - Gigabyte GA-7VRXP (VIA KT333 mit VT8233A(CE) Southbridge) - LAN onBoard (Realtek 8100 irgendwas) - Netzwerkkarte (Realtek 8139) - Promise, USB, Sound und Zeuch ist alles abgeschaltet - Adaptec 2940 SCSI-Controller - ISDN-Karte - Speicher wurde intensiv mit Memtest überprüft - keine Fehler Software: - Kernel 2.4.19-pre10 (vanilla) - pppd 2.4.1 mit pppoe-patch fürs DSL Immer dann, wenn die Telekom die DSL-Verbindung unterbricht, bleibt die Kiste einfach stehen - nur die beiden Tastaturdioden blinken. Keine Einträge in den logs, nichts. Ansonsten läuft die Kiste super stabil. Wenn der Verbindungsabbau von mir ausgeht, passiert auch nichts. Bei Kernel <2.4.19-pre-irgendwas taucht das Problem nicht auf. Der ganze pic-Kram hat keine Auswirkungen. Momentan hoffe ich noch, dass es am "pre10" im Kernel liegt. Ich bin gerade dabei, mal die ac-Kernel zu testen. Hat noch jemand Interesse an Erfahrungsberichten oder das Problem vielleicht auch schon gelöst? Weiß jemand, was mit die blinkenden LEDs sagen wollen? Martin -- when in danger or in doubt, run in circles, scream and shout! pgp-key: via wwwkeys.de.pgp.net, key id is 0x21eec9b0
martin.borchert@gmx.de schrieb:
Hat noch jemand Interesse an Erfahrungsberichten oder das Problem vielleicht auch schon gelöst? Weiß jemand, was mit die blinkenden LEDs sagen wollen?
IMHO blinken diese Dioden nach einem Kernel-Panik. Schau doch einmal in Deine /var/log/messages - ich meine, dass er da meistens auch noch etwas reinschreibt bei einem Crash. Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53
Konrad Neitzel schrieb:
martin.borchert@gmx.de schrieb:
Hat noch jemand Interesse an Erfahrungsberichten oder das Problem vielleicht auch schon gelöst? Weiß jemand, was mit die blinkenden LEDs sagen wollen?
IMHO blinken diese Dioden nach einem Kernel-Panik. Schau doch einmal in Deine /var/log/messages - ich meine, dass er da meistens auch noch etwas reinschreibt bei einem Crash.
Hallo, haben das gleiche Problem. In der /var/log/messages steht aber nichts intressantes drin. Die Abstürtze sind ganz wahllos. Wo gibts eine Lösung ? Tschau Georg Nies
Am Mit, 2002-06-19 um 13.29 schrieb lima:
haben das gleiche Problem. In der /var/log/messages steht aber nichts intressantes drin. Die Abstürtze sind ganz wahllos.
Wo gibts eine Lösung ?
Ich hatte das Problem mit der SuSE 7.3 und dem Standardkernel in Verbindung mit DSL. Bei inaktivität ist mir die Karre auch so abgeschmiert.. Das Update auf den von SuSE bereitgestellten Kernel 2.4.16 hat dann das Problem behoben.. Aber ob das auch das Problem bei dir ist.. :) Bye, Marcus -- You can't be a real country unless you have a beer and an airline. It helps if you have some kind of a football team, or some nuclear weapons, but at the very least you need a beer. -- Frank Zappa
Hi! Ich hab das gleich Motherboard und hatte das selbe Problem! Einfach in die Append-Zeile für Kernel-Parameter beim LILO "noapic" reinschreiben! Fertig! Seitdem hatte ich niewieder Probleme! Ach ja, Neustarts verträgt mein Motherboard auch nicht! Also immer ausschalten und wieder einschalten. Dann is alles wunderbar und wirklich super Flott. lG Michi. On Wednesday 19 June 2002 12:01, Martin Borchert wrote:
Am Montag, 4. Februar 2002 10:36:10 schrieb Mathias Weigt:
Am Montag, 4. Februar 2002 10:21 schrieb Martin Spöhrle:
On Mon, Feb 04, 2002 at 08:13:26AM +0100, Thomas wrote:
Hatte das gleiche Problem beim installieren von Linux 7.3. Verwendete einen RAID SCSI Kontroller von Adaptec und ein ASUS A7V266-E.
Ich hab das Problem auch! Allerdings habe ich keinerlei SCSI in dem Rechner. Kann es sein, dass das irgendwie am Board selber liegt?
Wahrscheinlich liegt es teilweise an der Hardware, da aber ein neuer (selbstkompilerter) Kernel bei mir Abhilfe schaffte, kann es das nicht allein sein. Ich hab das Problem jetzt auf drei verschiedenen Boards gesehen (von Asus und Gigabyte) Ich würde mal mit den Bootoptionen "enableapic, disableapic, noapic" spielen.
Ist zwar ein uralter Thread, aber ich fass den trotzdem nochmal an, weil es mir jetzt nämlich auch passiert - allerdings unter genau nachzuvollziehenden Umständen:
Hardware:
- AthlonXP - Gigabyte GA-7VRXP (VIA KT333 mit VT8233A(CE) Southbridge) - LAN onBoard (Realtek 8100 irgendwas) - Netzwerkkarte (Realtek 8139) - Promise, USB, Sound und Zeuch ist alles abgeschaltet - Adaptec 2940 SCSI-Controller - ISDN-Karte - Speicher wurde intensiv mit Memtest überprüft - keine Fehler
Software: - Kernel 2.4.19-pre10 (vanilla) - pppd 2.4.1 mit pppoe-patch fürs DSL
Immer dann, wenn die Telekom die DSL-Verbindung unterbricht, bleibt die Kiste einfach stehen - nur die beiden Tastaturdioden blinken. Keine Einträge in den logs, nichts. Ansonsten läuft die Kiste super stabil. Wenn der Verbindungsabbau von mir ausgeht, passiert auch nichts. Bei Kernel <2.4.19-pre-irgendwas taucht das Problem nicht auf. Der ganze pic-Kram hat keine Auswirkungen.
Momentan hoffe ich noch, dass es am "pre10" im Kernel liegt. Ich bin gerade dabei, mal die ac-Kernel zu testen.
Hat noch jemand Interesse an Erfahrungsberichten oder das Problem vielleicht auch schon gelöst? Weiß jemand, was mit die blinkenden LEDs sagen wollen?
Martin
Am Mit, 2002-06-19 um 12.01 schrieb Martin Borchert:
Weiß jemand, was mit die blinkenden LEDs sagen wollen? Blinkende LEDs deuten in der Regel auf Speicherzugriffsfehler auf unterster Ebene im Kernel hin, meist illegale Zugriffe auf den Tastaturkontroller.
D.h. ausser, dass sie darauf hindeuten, dass irgendetwas im Kernel gewaltig schief läuft, haben sie normalerweise keinerlei tiefere Bedeutung. Ralf
Hallo, Am Mittwoch, 19. Juni 2002 12:29 schrieb Ralf Corsepius:
Blinkende LEDs deuten in der Regel auf Speicherzugriffsfehler auf unterster Ebene im Kernel hin, meist illegale Zugriffe auf den Tastaturkontroller.
Nein. Das ist der Kernel (nur neuere 2.4er), der absichtlich(!) die LED (NumLock + ShiftLock) blinken lässt um dir die Kernel-Panik auch auf diesem Weg zu signalisieren. Hat also mit illegalen Zugriffen auf den Tastaturkontroller (bib's zu: den hast du dir zusammengedichtet ;-) auch rein gar nichts zu tun. Schöne Grüße aus Bremen hartmut
Am Mit, 2002-06-19 um 18.48 schrieb Hartmut Meyer:
Hallo,
Am Mittwoch, 19. Juni 2002 12:29 schrieb Ralf Corsepius:
Blinkende LEDs deuten in der Regel auf Speicherzugriffsfehler auf unterster Ebene im Kernel hin, meist illegale Zugriffe auf den Tastaturkontroller.
Nein.
Das ist der Kernel (nur neuere 2.4er), Wäre mir neu, ab welchem Kernel?
Wo ist das dokumentiert? Wo ist der SDB-Artikel bzw. der entsprechende Abschnitt im SuSE-Handbuch?
der absichtlich(!) die LED (NumLock + ShiftLock) blinken lässt um dir die Kernel-Panik auch auf diesem Weg zu signalisieren. Welches Quellfile?
Hat also mit illegalen Zugriffen auf den Tastaturkontroller (bib's zu: den hast du dir zusammengedichtet ;-) auch rein gar nichts zu tun. Tastaturen werden über IO-Controller angesprochen ob Du es glauben magst oder nicht (bei PS2-Tastatur psaux-Device, bei serieller Schnittstelle über den Controller der seriellen Schnittstelle). Die Komunikation der CPU mit diesen Controller erfolgt dabei normalerweise über IO-Ports.
Mag sein, dass im Kernel ein Feature implementiert ist um Kernel-Paniks über LEDs zu signalisieren, doch funktioniert auch das nur dann und nur dann wenn der Kernel nicht allzu sehr abgestürzt ist, insbesondere nicht Amok über die Portbereiche läuft. Wenn ein Kernel nun wirklich durchgeht, ist rein alles möglich, auch blinkende LEDS - Selbst wenn der Kernel damit eine Panik signalisieren will ist deren Bedeutung ausserordentlich fragwürdig (Es ist eine Eigenschaft einer Kernelpanik, dass sie Unsinn anrichtet). Deshalb gibt es blinkende LEDs nach Kernelabstürzen auch nicht erst seit gestern - Ich persönlich habe sie ca. 1993 zum ersten Mal gesehen - sondern kann ebenso gut ein Zufallsprodukt eines Fehlers an anderer Stelle sein. Ralf
Hallo, Am Donnerstag, 20. Juni 2002 00:18 schrieb Ralf Corsepius:
Am Mit, 2002-06-19 um 18.48 schrieb Hartmut Meyer:
Am Mittwoch, 19. Juni 2002 12:29 schrieb Ralf Corsepius:
Blinkende LEDs deuten in der Regel auf Speicherzugriffsfehler auf unterster Ebene im Kernel hin, meist illegale Zugriffe auf den Tastaturkontroller.
Nein.
Das ist der Kernel (nur neuere 2.4er),
Wäre mir neu, ab welchem Kernel?
Ich muss raten: irgendwann zwischen 2.4.4 (SL 7.2) und 2.4.10 (SL 7.3).
Wo ist das dokumentiert?
Ist mir nicht bekannt.
Wo ist der SDB-Artikel bzw. der entsprechende Abschnitt im SuSE-Handbuch?
Ist mir auch nicht bekannt.
der absichtlich(!) die LED (NumLock + ShiftLock) blinken lässt um dir die Kernel-Panik auch auf diesem Weg zu signalisieren.
Welches Quellfile?
Ich habe nie danach gesucht.
Hat also mit illegalen Zugriffen auf den Tastaturkontroller (bib's zu: den hast du dir zusammengedichtet ;-) auch rein gar nichts zu tun.
Tastaturen werden über IO-Controller angesprochen ob Du es glauben magst oder nicht (bei PS2-Tastatur psaux-Device, bei serieller Schnittstelle über den Controller der seriellen Schnittstelle). Die Komunikation der CPU mit diesen Controller erfolgt dabei normalerweise über IO-Ports.
Glaube ich. Ähnliche Effekte habe ich mit meienn ersten C-Programmen auf einem Atari ST erzeugen können (natürlich ungewollt), der ja keine MMU hatte.
Mag sein, dass im Kernel ein Feature implementiert ist um Kernel-Paniks über LEDs zu signalisieren, doch funktioniert auch das nur dann und nur dann wenn der Kernel nicht allzu sehr abgestürzt ist, insbesondere nicht Amok über die Portbereiche läuft.
Ja. Solch einen Absturz eines Kernels habe ich allerdings noch nicht gesehen (was nicht heißt, dass es ihn deswegen nicht geben kann). Fakt ist, dass der Kernel das Blinken selbst erzeugt um die Kernel-Panic zu signalisieren (beispielsweise wenn beim Booten die Root-Partition nicht gemounted werden kann). Dieser Mechanismus scheint sehr zuverlässig zu funktionieren, weshalb ich bei einem gleichzeitigen Blinken von Numlock und ShiftLock sicher davon ausgehen würde, dass dies kein wilder Pointer ist der Amok läuft. Schöne Grüße aus Bremen hartmut
* On Thu, 20 Jun 2002 at 8:25 +0200, Hartmut Meyer wrote:
Am Donnerstag, 20. Juni 2002 00:18 schrieb Ralf Corsepius:
Am Mit, 2002-06-19 um 18.48 schrieb Hartmut Meyer:
Am Mittwoch, 19. Juni 2002 12:29 schrieb Ralf Corsepius: [..] der absichtlich(!) die LED (NumLock + ShiftLock) blinken lässt um dir die Kernel-Panik auch auf diesem Weg zu signalisieren.
Welches Quellfile?
Ich habe nie danach gesucht.
Kernerl 2.4.18-SuSE: --8<--- kernel/panic.c --- #if defined(__i386__) && defined(CONFIG_VT) extern void panic_blink(void); panic_blink(); #endif ---8<--- drivers/char/pc_keyb.c --- /* Tell the user who may be running in X and not see the console that we have panic'ed. This is to distingush panics from "real" lockups. Could in theory send the panic message as morse, but that is left as an exercise for the reader. */ void panic_blink(void) { static unsigned long last_jiffie; static char led; /* Roughly 1/2s frequency. KDB uses about 1s. Make sure it is different. */ if (jiffies - last_jiffie > HZ/2) { led ^= 0x01 | 0x04; while (kbd_read_status() & KBD_STAT_IBF) mdelay(1); kbd_write_output(KBD_CMD_SET_LEDS); mdelay(1); while (kbd_read_status() & KBD_STAT_IBF) mdelay(1); mdelay(1); kbd_write_output(led); last_jiffie = jiffies; } } ---8<--- Ist SuSE-spezifisch, im vanilla-Kernel finde ich nichts derartiges. -- Adalbert PGP welcome, request public key: mailto:adalbert+key@lopez.at
participants (12)
-
Adalbert Michelic -
Hartmut Meyer -
Konrad Neitzel -
lima -
Marcus Franke -
Martin Borchert -
Martin Spöhrle -
Mathias Weigt -
Michael Rösch jun. -
Ralf Corsepius -
Thomas -
Tobias Geis