Debian bootet nicht mehr

[chb]

Die beruhigende Antwort auf die beunruhigende Meldung "AMI BIOS detected: BIOS may corrupt low RAM, working around it." finde ich hier: http://fixunix.com/kernel/557785-%5Bpat ... boxen.html
- soweit ich das erkennen kann, ein modernes kernel feature um potientiellen Konflikten mit einem buggy BIOS entgegenzuwirken
(was es nicht alles gibt )

Letztlich ist es Unixators Entscheidung, aber ich würde keinesfalls ohne triftigen Grund zum kompletten Zerpflücken des PC raten.
Solange nicht absehbar ist, ob hier vielleicht doch nur ein ungewöhnliches Konfigurationsproblem, ein fehlerhafter Speicherriegel oder ein übertakteter Prozessor vor sich hinwerkeln, kann ich jedenfalls keinen erkennen.

Wenn kürzlich an der Hardware des PC umgebaut wurde, hat Simmel sicher Recht, dass nach evtl. dadurch erzeugten Fehler(quelle)n Ausschau gehalten werden muss. Unixator, wurde denn kürzlich an Deinem Rechner etwas eingebaut /umgerüstet? Heutzutage sind z.B. IRQ -Konflikte recht selten geworden, aber evtl. kann ein buggy BIOS, dass zudem 'verkonfiguriert' wird, zusammen mit einer buggy Grafikkarte o.ä. immer noch für dolle Effekte sorgen...?

Vielleicht kann der TE ja bald etwas über erste Erfolge oder Erkenntnisse zu berichten

[Unixator]

Zunächst Danke für das zahlreiche Feedback.

Das System ist relativ neu, und arbeitet seit Oktober ohne jegliche Probleme. Es gab keine Hardwareänderungen oder ähnliches.

Die einzige signifikante Änderung, die ich bemerkt hatte, dass ich am Abend, bevor ich diese Probleme zum ersten Mal bemerkte, Updates installiert hatte:

Code: Alles auswählen

Start-Date: 2012-02-23  19:15:11
Upgrade: libmodplug1:i386 (0.8.8.1-1+squeeze1, 0.8.8.1-1+squeeze2), libarchive1:i386 (2.8.4-1, 2.8.4-1+squeeze1), libvorbisfile3:i386 (1.3.1-1, 1.3.1-1+squeeze1), python-libxml2:i386 (2.7.8.dfsg-2+squeeze2, 2.7.8.dfsg-2+squeeze3), libvorbisenc2:i386 (1.3.1-1, 1.3.1-1+squeeze1), libxml2:i386 (2.7.8.dfsg-2+squeeze2, 2.7.8.dfsg-2+squeeze3), libxml2-utils:i386 (2.7.8.dfsg-2+squeeze2, 2.7.8.dfsg-2+squeeze3), libvorbis0a:i386 (1.3.1-1, 1.3.1-1+squeeze1)
End-Date: 2012-02-23  19:15:18


An sich kann ich auf der Maschine arbeiten. Nur stellenweise habe ich die bereits beschriebenen Aussetzer.

Ich werde mir mal die HIRENS Boot CD laden und ein paar Hardwaretests durchziehen.

Das Board (ELKOS) sieht gut aus. Die Temperatur von MB und CPU sind auch immer im grünen Bereich, wenn ich mir nach einem Crash die Temperaturen anzeigen lasse.
Memtest+ lasse ich durchlaufen bis er mir zum ersten Mal sagt, Test passed. Ich werde mal einen längeren Lauf mit jeweils nur einem Riegel laufen lassen.

RAM Riegel wäre ja noch das einfachste. Der Rest sitzt "im Board" bzw die CPU muss man sich auch noch organisieren.
Netzteil kann ich leider auch nicht vertesten.

ein anderes mal war das Kabel des Reset-Schalters blank und ist immer ans Gehäuse gekommen.

Hier werde ich mal gucken bzw "abtapen". Einige Kabel liegen auch blank rum, und können durchaus ans Gehäuse kommen. Nur frage ich mich wieso erst jetzt auf einmal. Aber das wird noch gecheckt.

[spiralnebelverdreher]

Zunächst Danke für das zahlreiche Feedback.

Das System ist relativ neu, und arbeitet seit Oktober ohne jegliche Probleme. Es gab keine Hardwareänderungen oder ähnliches.

Die einzige signifikante Änderung, die ich bemerkt hatte, dass ich am Abend, bevor ich diese Probleme zum ersten Mal bemerkte, Updates installiert hatte:

Code: Alles auswählen

Start-Date: 2012-02-23  19:15:11
Upgrade: libmodplug1:i386 (0.8.8.1-1+squeeze1, 0.8.8.1-1+squeeze2), libarchive1:i386 (2.8.4-1, 2.8.4-1+squeeze1), libvorbisfile3:i386 (1.3.1-1, 1.3.1-1+squeeze1), python-libxml2:i386 (2.7.8.dfsg-2+squeeze2, 2.7.8.dfsg-2+squeeze3), libvorbisenc2:i386 (1.3.1-1, 1.3.1-1+squeeze1), libxml2:i386 (2.7.8.dfsg-2+squeeze2, 2.7.8.dfsg-2+squeeze3), libxml2-utils:i386 (2.7.8.dfsg-2+squeeze2, 2.7.8.dfsg-2+squeeze3), libvorbis0a:i386 (1.3.1-1, 1.3.1-1+squeeze1)
End-Date: 2012-02-23  19:15:18


An sich kann ich auf der Maschine arbeiten. Nur stellenweise habe ich die bereits beschriebenen Aussetzer.
...
Einige Kabel liegen auch blank rum, und können durchaus ans Gehäuse kommen.

Neues Mainboard lässt defekte Elkos erstmal in der Verdachtsreihe nach hinten schlüpfen. Blanke Kabel (in dem Sinne das man das Kupfer sieht) dürfen natürlich überhaupt nicht sein und sollten als Erstes ersetzt werden. Stark durch Einklemmen gecknickte Kabel natürlich ebenfalls.
Die SW-Updates würde ich in Betracht ziehen, wenn es bestimmte Anwendungen sind die mit den Aussetzern in Zusammenhang stehen.

[Unixator]

Hallo zusammen,

nun habe ich x-Tests durchgeführt von der HIRENS Boot CD aus, und jeder Test wurde ohne Fehler bestanden.
Folgende Tests habe ich durchgeführt:
memtest, goldMemory, westerndigital diagnostics, CPU/Video/Disk Performance Test, S&M Stress Tool, Video Memory Stress Test 1.7.116.
Kein Freeze, keine Fehler

Das OS hat gestern gar nicht erfolgreich gebootet (entweder Kernel gar nicht erst geladen, oder in die Kernel errors gelaufen), oder spätestens nach dem gnome Login ist die Kiste (Screen, Tastatur, Maus) eingefroren.
Im recovery Modus bin ich dann auf den testing _Zweig gerutscht und habe mir den 3.2.0.1 Kernel geladen. Aber da ging nicht viel. Grauer Bildschirm und es schien wie eingefroren.
Dann habe ich eine Ubuntu Live CD starten wollen, was gar nicht ging. Eine Kernel Bug Meldung und freeze, direkt nach der Auswahl: Ubuntu ohne Installation starten..
Jetzt habe ich wieder den 2.6.35 stable Kernel am Start und bin zur Zeit in der GUI, und ich kann arbeiten.

CMOS gecleared, Battery raus hatte ich auch noch, ohne Erfolg, getan.

Ideen? Was würdet Ihr jetzt eintauschen? Bin kurz davor das Motherboard als defekt zu deklarieren. Ein anderes Netzteil zum Testen kaufen? Oder gar die CPU?
So was habe ich noch nicht erlebt. Kein eindeutiges Zeichen.

Danke & Gruss

[cirrussc]

Ideen? Was würdet Ihr jetzt eintauschen? Bin kurz davor das Motherboard als defekt zu deklarieren. Ein anderes Netzteil zum Testen kaufen? Oder gar die CPU?
So was habe ich noch nicht erlebt. Kein eindeutiges Zeichen.

Wahrlich ein verworrener Fall.
Hm ...
CD-Laufwerk schon ausgeschlossen?
Mal eine andere HDD mit einer frischen Installation getestet/zur Hand?
Ansonsten würde ich hartnäckig weiter testen; wenn etwas defekt ist, dann muss es sich doch auch in irgend einem Test bemerkbar zeigen.

[chb]

Hallo Unixator,

habe ich das richtig verstanden, solange Du die HIRENS Boot CD laufen lässt, treten stundenlang keine Freezes, lockups, etc auf?
Grob defekte Hardwarekomponenten wie zB das Netzteil müssten sich eigentlich unabhängig vom Betriebssystem auswirken.
Und alle durchgeführten Testläufe blieben ohne Befund? Hmmm.
Vielleicht muss man sich die Software auch noch mal vornehmen.

Ich habe versucht, mir Deine syslogs noch mal näher anzusehen. Tritt denn (fast) immer das gleiche Problem auf?
Also wiederholter Kernel Oops (Feb 27 07:39:49 tatort kernel: [ 300.894485] Oops: 0000 [#2] SMP ), ausgelöst durch Dereferenzieren eines nullpointers (gibt idR. 'nen page fault), und das (fast) immer im Zusammenhang mit Zugriff auf Blockdevices und/oder do_vfs_ioctl? Oder treten auch völlig beliebig ganz andere Fehler auf (einschließlich segfault und /oder 'echter' Kernel panic)? Da Du zudem die ganzen virtualbox Kernel-Module geladen hast - hast Du denn gerade damit gearbeitet? Es wäre auch hilfreich zu wissen,was/wie/welches Debian auf der zweiten Platte installiert ist (identische Version und Konfiguration).

Dass die Ubuntu Live CD nicht problemlos bootet muss Dich nicht unbedingt beunruhigen - das habe die Dinger auf meinen (verschiedensten) Rechnern seit Jahren auch fast nie *g*
Zwei Ideen kämen mir da auf die Schnelle:
- Dein aktueller Kernel erkennt das BIOS anscheinend als 'somewhat buggy'. Wenn Du was für Geduldsspiele übrig hast, ist das stufenweise Variieren /Kombinieren der Bootparameter acpi_osi="Linux" acpi_osi="!Windows 2006", acpi_osi="" oder acpi=noirq ggf zusammen mit pci=noacpi, pnpacpi=off, noapic, nolapic einen Versuch wert.

-Ein neueres Debian -System probieren, mit einem deutlich späteren Kernel. Probiere doch mal (je nach Architektur)
http://alioth.debian.org/~gilbert-guest ... 6-mini.iso
oder http://alioth.debian.org/~gilbert-guest ... 4-mini.iso
vom CUT Team für die zweite Platte. Da gibt's einen kleinen Fehler in der Textdarstellung des Installers, sonst könnt's aber klappen.
Viel Erfolg

[Unixator]

Hi,
Danke für die Rückmeldung. In der Tat treten recht identische Meldungen auf. Und das seit dem Update. In der Regel irgendwelche NullPointer Dereferenzen. Mit Virtualbox habe ich zu diesem Zeitpunkt gearbeitet. Hatte ich auch mal disabled. Also das beim Booten keine virtualbox geladen wird...
So ganz bin auch nicht von einem Hardwarefehler überzeugt.
Ja, alles HIRENS tst sind ohne Probleme passed worden. Und da wird ja auf jegliche Hardware zu gegriffen.

Ich werde mal versuchen mit acpi_osi="Linux" acpi_osi="!Windows 2006", acpi_osi="" oder acpi=noirq ggf zusammen mit pci=noacpi, pnpacpi=off, noapic, nolapic zu spielen.

Auf der anderen Platte war ebenfalls ein debian 6.0.4 installiert. Ohne virtualbox. Also selber Kernel. Was anderes hatte ich noch nicht probiert.

Ich probiere mal die iso's.. Welche version/Kernel?

[chb]

Image je nach Architektur. Erstellt sind die ISOs am 3. oder 4. Februar, könnte also schon ein 3.2er Kernel drin sein.
Testhalber könnte evtl. auch ein Liquorix-Kernel einen Versuch wert sein.

[Unixator]

Ok, wenn ich einen Kernel 3.x installiere bekomme ich einen grauen verzerrten Bildschirm udn es tut sich nicht viel. Liegt wohl an der Radeon Karte. Mit einem radeon.modset=0 bootet er..

jetzt habe ich mal die fglrx Pakete installiert.. Bin gerade mit dem 2.6.32-5-686 Kernel wieder am Arbeiten. Läuft noch. Die acpi_osi Modis haben nicht geholfen.
Hier sind eine Reihe von error Meldungen von nicht geglückten Boot Versuchen:
http://nopaste.debianforum.de/36299

[niemand]

NoPaste!

[chb]

Im Laufe des Abends werde ich mal versuchen, Deine syslogs nach brauchbaren Anhaltspunkten durchzusuchen. Es gibt afaik Fälle, in denen bei Einsatz von virtualbox mit unterschiedlicher Architektur in host / guest, speziell bei Beteiligung eines 2.6.xyz -pae Kernels freezes und lockups auftraten. Gut informiert bin ich in dieser Angelegenheit nicht, da ist Recherche nötig - vielleicht kennt sich im Debianforum jemand damit gut aus?
Ich habe aber zunehmend den Verdacht, dass Deine Schwierigkeiten mit den Radeon -chipsatz in Verbindung stehen. Bei mir werkelt zZt als Desktop -Ersatz eine ci5 /Mobility Radeon HD5650 'Zickenmaschine' unter Wheezy/Sid mix mit 3.2er Kernel (die auch mit 'Standardeinstellungen' von *buntu -Live-CDs noch nie zu betreiben war), allerdings unter dem open-source radeon -Treiber, nicht fglrx. Gibt es für dessen Nutzung bei Dir einen speziellen Grund? Irgendwann unter Squeeze wurde für die meisten Grafikmodule defaultmäßig 'kernel mode setting' (kms) aktiviert, was leider bei einigen Radeonchipsätzen zu Fummelbedarf (zB. /etc/modprobe.d/radeon-kms.conf) führte. Am 3.2er Kernel 'an sich' liegt das keinesfalls. Poste doch bitte mal die Ausgabe von "lspci -nn | grep VGA".
Evtl. hilft auch der Thread hier im Debianforum "[wheezy] radeon Treiber = System freeze?" viewtopic.php?f=13&t=134485 weiter.

Sobald ich am Abend zu Hause bin, sehe ich mir mal meine Konfiguration auf meinem Mobility Radeon Rechner an, auch mit welchen Images /Parametern ich seinerzeit installierte, am End' lässt sich da einiges auf Dein Gerät übertragen

[Unixator]

Hallo,
Danke für das Angebot. Ich komme die Tage daruf zurück In all meiner Verzweifelung habe ich mein Board als RMA eingeschickt.

Was mich an dem ganzen wundert ist, dass dieses Auffälligkeit von heute auf morgen aufgetreten ist. Virtualbox habe ich schon seit Wochen installiert gehabt. Der Chipsatz lief bis jetzt ohne fglrx... Ich werde wenn das Board wieder eingebaut ist, wieder mit dem opensource treiber von radeon arbeiten. Auf dem Board ist eine Radeon HD6000 series verbaut. Scheint irgendwie nicht wirklich unter den supporteten Treiber zu sein?
http://wiki.debian.org/AtiHowTo

[chb]

Dann drücke ich Dir mal die Daumen, dass die Probleme daran lagen !

Da gestern Nacht das Debianforum länger offline war, poste ich nun trotzdem nachträglich die ursprüngliche Antwort, just in case..., hoffe aber, dass Du diesen Thread nicht mehr benötigst, wenn Dein Mainboard getauscht wurde.
Viel Glück

Ursprünglicher Text:
Die aktuellen syslogs geben imho keinen klaren Hinweis auf einen Zusammenhang mit virtualbox, im Gesamtbild scheint dies die Vermutung zu stärken, dass evtl. ein ähnlich gelagertes Problem vorliegt wie z.B. unter [1] [2] [3] geschildert.
Zwei Rechner mit relativ aktuellen Radeon Grafikchipsätzen hatte ich 2010 /2011 per Netz-Installations CD-Image [testing], dem aktuellen firmware tarball auf usb-Medium [4] und je angepasster xorg.conf (obsolet) installiert. Mittlerweile(?) gibt es (inoffizielle) Installations-Images, die bereits die firmware enthalten [4], so dass Schwierigkeiten wie unter [1], [2] nicht auftreten sollten.
Vom Debian -'Abkömmling' Crunchbang linux gibt's eine recht Fehler -& Hardware-tolerante Live CD [5], firmware-linux-/free/-nonfree und aktuelle backports sind enthalten. Liegt kein Hardwaredefekt vor, sollte zumindest im 'failsafe mode' Betrieb möglich sein.
----
[1] Debian Bug report logs - #627497 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627497
[2] Debian Bug report logs - #649448 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649448
[3] OpenSUSE Error Loading Installer - Possible Issue with UDEV/Video Drivers http://forums.opensuse.org/english/get- ... ivers.html
[4] debian/Wiki/Firmware http://wiki.debian.org/Firmware
[5] CrunchBang 10 “Statler” R20120207+ http://crunchbang.org/dl/crunchbang-10- ... 64.bpo.iso
-----

[Unixator]

Ok, Shit.. Neues Board endlich eingebaut, selbes Verhalten..

Obwohl er nun sehr häufig in folgende Meldung läuft:

BUG: soft lockup - CPU#2 stuck for 23s! [udevd:58]
Process udevd
Stack
Call Trace
Code.....

Ich versuche das Ganze nun auf dem 3.2.0 Kernel zum Laufen zu kriegen..

hatte jetzt auch mal ein Fedora installiert. Ist irgendwann auch weg gefreezt.

Ideen? Wie geht man jetzt weiter vor am Geschicktesten?

Werde wohl CPU und RAM nun auf Verdacht austauschen. Es muss eigentlich Hardware sein..

[chb]

Hallo Unixator,
...there and back again...
Bedauerlich, dass Du wieder 'eingecheckt' hast.

Leicht veränderte System- & Fehlermeldungen könnten eine Folge einer etwas höheren /anderen Version /Revision der verbauten Chipsätze bzw. der BIOS -Routine sein (auf'm Austausch-Mainboard). BIOS neu konfiguriert ?
Hattest Du Dir meine letzte Antwort damals durchgelesen, auch die verlinkten Dokumente?
Hier evtl. auch mal reinsehen [1], ähnliches: [2]...

Aktueller Liquorix-Kernel (s.o.) brachte auch keinerlei Veränderung?
Das aktuelle Crunchbang (s.o.) im Live-CD 'failsafe' mode (ggf. +'radeon.modset=0') -- läuft das tatsächlich gar nicht?
Ich könnte Dir testhalber mal meine 3.3-rc7 686/amd64 Kernel-builds schicken (PN dann), falls gewünscht.
Edit [20/03/2012/074536]: linux-image-3.3.0-rc6-amd64 ist in experimental, wird unter wheezy z. Testzwecken wohl taugen [3]:

[1] http://us.generation-nt.com/answer/bug- ... 83042.html
[2] http://us.generation-nt.com/s/soft+lockup+cpu/
[3] http://packages.debian.org/experimental ... -rc6-amd64