T23 hängt sich ständig auf

C

crash_landing

New member
Themenstarter
Registriert
4 Dez. 2006
Beiträge
15
Hallo,

ich habe hier ein T23 (PIII, 1,2GHz, 512MB) das mir Probleme macht. Gestern habe ich opeSUSE 10.2 draufgespielt. Die Installation klappte erst im vierten Anlauf mit minimaler Paketselektion, davor hat er sich immer bei einer (vermutlich zufälligen) Prozentzahl komplett aufgehängt.

Nach einigen kleineren Problemen hatte ich dann auch DMA am Laufen und das System ist eigentlich richtig flott. Nur sobald ich Daten von CD/DVD auf die Platte kopiere hängt sich das System auch wieder nach unterschiedlicher Zeit komplett auf. Rien ne va plus...
Ursprünglich habe ich auf einen Fehler beim CD-Drive getippt, da "hdparm /dev/hdc" den folgenden Fehler liefert:
>> HDIO_GETGEO failed: Inappropriate ioctl for device

Naja, dann zum Test eine Datei aus einer NFS-Freigabe auf die Platte kopieren wollen und wieder nach mal 50, mal 100MB komplett gehängt. Inzwischen tritt das Problem sogar beim Nachinstallieren von Paketen per yast auf, mitten im Installationsvorgang hängt das System.

So langsam habe ich keine Idee mehr, wo ich noch nachschauen könnte...

Peter

EDIT: Inzwischen hängt sich das System auch ohne große Schreiboperationen nach ein paar Minuten auf. Leider wird das nicht im /var/log/messages protokolliert, so dass ich keinerlei Ahnung habe, woher das kommt (und auch ohne intalliertes CD-Drive tritt das Problem auf) oder habe ich inzwischen dank der vielen Aufhänger ein inkonsistentes System - ext3 sollte dies doch verhindern.
 
Hier steht als Verdacht eine unzuverlässige Platte oder defektes Ram im Raum.

Vom Plattenhersteller ein Testtool laden und von der i.d.R. vom Tool erstellten Boot-CD aus testen lassen.

Fürs Ram nimm am besten memtest86, das kommt im bootfähigen Image.

Fang am besten mit dem Ram an.

Wenn das alles o.k. war, bleibt eigentlich nur schlechte Prozessorkühlung oder ein defektes Board ...

Gruß
Roger
 
Danke für deine Antwort!

Ich habe jetzt memtest86 und das Samsung-Texttool durchlaufen lassen. Beide Tests haben keinerlei Fehler ergeben (ich gehe mal davon aus, dass bei memtest86 ein Durchlauf reicht).

Während beiden Test (und das war jedesmal eine längere Zeit) ist das System nicht eingefroren.

Zu den anderen Vorschlägen:

Mangelhafte Kühlung hätte sich doch hier auch bemerkbar machen müssen, außerdem friert das System meiner Beobachtung nach immer beim Schreibzugriff auf die Festplatte ein.

Defektes Mainboard - Hab das Gerär erst vom Händler gekauft, allerdings wollte ich den Fehler schon lokalisieren, bevor ich das Ding unnötig einschick, und ich lediglich einen Konfigurationsfehler gemacht habe...

Peter
 
Sehr gut, das ist schon mal eine vernüntige Basis für die weitere Suche. Bei memtest werden speziellere Fehler allerdings oft erst im letzten Durchlauf angezeigt. Die gängigen Betriebssysteme können Speicherfehler aber in Grenzen korrigieren, sodass diese Fehler lange nicht auffallen und wir das hier erstmal unter den Tisch fallen lassen. Aber besser bei Gelegenheit mal nachholen, so lange die Rückgabefrist noch läuft ;) .

Was ich noch nicht erwähnt habe, ist die Möglichkeit eines Defektes des optischen Laufwerks. Kannst Du das testweise ersetzen oder die Installations-CDs mal testweise von einem externen USB-Plattenlaufwerk einspielen, um das opt. Laufwerk zu umgehen (Achtung, USB 1.1 ...) ?

//EDIT: Sehe gerade, das tritt auch ohne Laufwerk auf ...

Läuft der Prozessorlüfter beim Einschalten an ?
 
Dann lasse ich memtest heute Nacht mal durchlaufen, vielleicht ergibt das noch Fehler.

Ja, der Lüfter läuft direkt beim Einschalten für ein paar Sekunden und danach je nach Benutzung hin und wieder. Ich vermute also, dass die Regelung funktioniert.

Ja, der Defekt tritt auch ohne optisches Laufwerk auf (wenn stattdessen der Akku im Ultrabay steckt, und ich schon mit diesem gebootet habe).
Um das Laufwerk im Betrieb zu entfernen habe ich auch mal
>> echo eject > /proc/acpi/ibm/bay
versucht, damit hängt er sich nach Erlöschen der Ultrabay-LED zuverlässig auf ;-(

Hm, mit meinem naiven Desktop-Computer-Verstand hätte ich jetzt mal den IDE-Controller im Verdacht. Der ist ja das Bindeglied zwischen Festplatte und optischem Drive, und die Fehler haben immer etwas mit einem von den beiden zu tun (hängt beim Schreiben, hängt beim Auswerfen des Ultrabay, Fehlermeldung für das opt. Laufwerk von hdparm). Das würde ja einen Tausch des kompletten Gerätes erzwingen erzwingen ;-(

Ein weiteres optisches Laufwerk habe ich auch nicht da (das vom TP600 geht laut ThinkWiki nicht).

Peter
 
Ja, der Controller ist mir auch verdächtig. Kabel scheiden im Gegensatz zum Desktop hier auch aus ...

Der Vollständigkeit halber vielleicht mal die Platte vom T600 einsetzen (wenn die keine 12 mm hohe Platte ist).
 
Versuche mal folgendes: In /boot/grub die menu.lst mit einem Editor öffnen und in der Zeile "kernel" jeweils acpi=off einstellen. Nach dem nächsten Booten sollte er normal laufen. Solche massiven Probleme treten neuerdings wieder gehäuft auch bei A2x/3x-Systemen auf. Die sind alle so Baujahr Ende 2000 - Ende 2003. Da scheinen Inkompatibilitäten der ACPI-Tabellen die Ursache zu sein.

Gruß
enrico65
 
Hm, also ich bin immer noch am experimentieren...

Gestern habe ich noch WindowsXP auf meiner anderen Platte installiert, das hat perfekt funktioniert, keine Abstürze. Und weil ich es schon drauf hatte, gleich noch das neuste BIOS draufgespielt. Da ich das Teil jedoch wieder MS-free haben möchte, hab ich dann wieder mal versucht, die openSUSE zusätzlich auf diese Platte zu installieren, und schon beim Partitionen ändern hängt er sich wieder auf.
An der Festplatte liegt es damit wohl nicht, was mich aber beunruhigt, ist dass es unter Windows keine Problem eauch bei massivem Festplattenzugriff gab.

Momentan installiere ich gerade mal SUSE10.0, wenn das durch ist, werde ich die ACPI-Deaktivierung mal separat testen (in Kombinationen mit anderen Bootoptionen hatte ich sie schon, da ist das Problem trotzdem aufgetreten). Allerdings ist ein funktionierendes ACPI für mich absolut Pflicht, also wäre das Deaktivieren keine Lösung.

Könnte unter Umständen auch der Kernel (openSUSE10.2 ist ja noch nicht so lange draußen) irgendwelche Probleme machen, sprich ein Kernelupdate bzw. das Deaktivieren von irgendwelchen Optionen helfen? Dann müsste ich mich doch mal damit befassen...

Sobald ich sagen kann, ob die SUSE10.0-Installation erfolgreich ist, melde ich mich wieder.

Peter
 
@ crash_landing
ich hatte auf meinem t 23 testweise suse 10.2 installiert da hat alles einwandfrei funktioniert
ich hab allerdings den 1133 prozessor und damals nur 256 ram
also ich denke am suse kanns auch nicht liegen
es hat auch alles erkannt soweit ich weiß , aber ich bin halt kein linuxprofi :(
gehapert hats bei mir nur am fritz w-lanstick
ich hoffe ich konnte dir damit a bissl helfen
 
Hm, also die Installation von SUSE10.0 ist sauber durchgelaufen, auch ein paar GB Daten konnte ich erfolgreich kopieren. Werde jetzt doch mal versuchen, einen anderen Kernel zu testen.

By the Way: Auch unter SUSE10.0 kam bei "hdparm /dev/hdc" (optisches Laufwerk) die Ausgabe:
>> HDIO_GETGEO failed: Inappropriate ioctl for device
Vielleicht könnte jemand mit einem funktionierenden SUSE-System auf einem T23 das mal testen, vielleicht ist zumindest diese Fehlermeldung ja "völlig irrelevant" für mein Problem...

Peter

EDIT: Gerade gesehen, dass jemand das gleiche Problem hat, leider auch keine Lösung ;-(
http://www.unixboard.de/vb3/archive/index.php/t-25752.html

EDIT2: Der PC friert auch ohne gestarteten X-Server ein, sobald ich Daten kopiere ;-(
 
So, also ACPI=OFF bringt auch keine Besserung. Inzwischen habe ich in einigen Foren hinweise auf einfrierende openSUSE 10.2-Installationen gefunden, aber keine wirkliche Lösung.

EDIT: Stimmt nicht ganz, siehe Posts weiter unten. Irgendwie habe ich wohl Optionen vermischt...

Das muss doch irgendwie zum Laufen zu bringen sein, weil die restlichen Neuigkeiten der Version gefallen mir ganz gut...

Peter
 
hast du mal eine andere linux distribution versucht ((k)ubuntu) ?
wär interessant ,ob sichs da auch aufhängt
und wie schon gesagt auf meinem hat suse 10.2 einwandfrei gefunzt
 
Also Ubuntu habe ich gerade auch mal installiert, da scheint alles zu tun (die Fehlermeldung von hdparm erscheint hier auch, scheint also normal zu sein).
Sogar das auswerfen und hotplug des Ultrabay-Drives funktioniert ohne einzufrieren.

Leider ist Ubuntu (obwohl ich sehr viel davon halte) nicht das OS, das ich auf dem Laptop nutzen möchte, da sind mir einige Sachen auf der openSUSE10.2 zu attraktiv ;-)
Abgesehen davon möchte ich das gleiche System wie auf dem Desktop (vereinfacht Synchronisation und Paketmanagement).

Vielleicht hat ja noch jemand einen kleinen Tipp, wo ich weitersuchen kann. Mir scheint die Hardware ist soweit doch in Ordnung?

Nutzt es was, einfach einen neueren Kernel einzuspielen? Oder könnte es genügen, den vorhandenen einfach mit anderen Optionen zu compilieren?
Oder kann ich vielleicht bestimmte Dienste deaktivieren?

Peter
 
Also, nach weiteren endlosen Stunden rumgebastele und probieren mit den verschiedenen Bootoptionen kann ich sagen:

SUSE 10.0, Ubuntu und WindowsXP (schäm) laufen,
SUSE10.1 und openSUSE10.2 haben das Einfrier-Problem.

Im Installationsmodus "sichere Optionen" klappt die Installation und das System arbeitet zuverlässig. Problem: Kein ACPI -> keine Akkuinformationen, kein Zugriff auf spezielle Hardwarefunktionen, ...
Nehme ich die Option "acpi=no" raus, funktioniert die Akkuanzeige etc, aber beim Festplattenzugriff oder auswerfen von Hardware friert er ein.

Ich sehe momentan noch vier Möglichkeiten:
- Versuchen, einen anderen RAM-Riegel zu bekommen, ob damit das Problem auch auftritt (mir wäre da aber der Zusammenhang mit ACPI unklar)

- ACPI deaktivieren (kommt ja gar nicht in Frage, wie soll ich denn da noch ein positives Wort über Linux verlieren können ;-) )

- Gerät reklamieren: Zum einen ist der Fehler ja ohne SUSE10.2-Installation schlecht reproduzierbar und der Einzeltest von Festplatte und RAM ok, zum anderen laufe ich dann Gefahr, evt. ein abgenutzteres oder ohne interne WLAN-Antennen zurückzubekommen, deshalb ist das für mich die letzte Option

- Vielleicht gibt es eine Möglichkeit, irgendeinen Teil der Installation, der mit dem ACPI zu tun hat, zu aktualisieren/ändern/entfernen, so dass ich trotzdem mein ACPI nutzen kann. Das neueste BIOS habe ich ja schon installiert.

Ich würde mich freuen, wenn noch jemand einen Tipp parat hat (insbesondere zur letzten Möglichkeit), so langsam kostet mich der Spaß nämlich mehr Zeit, als ich investieren wollte ;-(

Peter
 
Also diese Einfrierprobleme habe ich in den letzten Tagen bei verschiedenen Gerätetypen nachvollziehen können, und zwar auch mit Dreamlinux und Ubuntu 6.10 sowie MintLinux 2.1. Alle Geräte laufen mit älteren Versionen (Ubuntu 6.06 und 6.06.1, Xandros 3.11, CentOS 4.4, SAM 2006-3) problemlos, nicht jedoch mit openSuse 10.2 und - ganz krass - mit Mandriva 2007 One (Official). Googlen hat ergeben, dass ganz klar auch Geräte anderer Hersteller betroffen sind und dass es überall die ACPI-Implementationen sind, also nicht an der Hardware liegt, sondern die neuen Kernel-Versionen offensichtlich wegen extrem fehlerhafter ACPI-Implementationen massive Probleme haben mit bestimmten Notebooks. Das Einfrieren hat bei teilweise auch dazu geführt, dass nach sofortigem erneuten Einschalten der Bildschirm schwarz blieb oder der Rechner beim Booten hängenblieb. Nach der Entnahme des Akkus und der Speicherbausteine und ein paar Stunden Wartens lief das System dann wieder problemlos.

Wie dmesg zu entnehmen ist, sind die ACPI-Einstellungen im Jahr 2006 modifiziert worden, das scheint jetzt durchzuschlagen. Da kann man eigentlich Linux keinen Vorwurf machen, denn die ACPI-Spezifikationen sind ursprünglich von Microsoft massiv mitentwickelt worden, sind daher proprietär und nicht offen zugänglich. Zudem haben viele Hersteller von Notebooks bis dato keine fehlerfreie ACPI-Implementation vorzuweisen. Bei ACPI übernimmt das Betriebssystem die Kontrolle über die Hardware und nicht mehr - wie bei APM - die Hardware selbst. Ich habe jetzt überall die Kerneloption acpi=off eingesetzt, dann laufen die Systeme rund. Andere Möglichkeit wird wohl nur sein: Fehler melden und ein paar Wochen warten, bis die Entwickler einen Bugfix bereitstellen. Bei Ubuntu übrigens tritt das Problem bei den 6.06-Versionen nicht bei den Kernel-Versionen für 386-CPU's auf, wohl aber bei 686-Kerneln.
 
Hallo mal wieder,

@enrico65: Na das sind doch mal Fakten, die mir einiges erklären. Danke für die ausführliche Beschreibung!

Inzwischen hab ich mich schon etwas mit dem "APM statt ACPI" abgefunden. Ist zwar schade, dass dann Akkustand, momentaner Leistungsbedarf und Zustand der einzelnen Akkus undetaillierter /nicht angezeigt werden, und so Spielchen wie Ultrabay-Hotswapping und Zugriff auf die Thinkpas-Hardware nicht funktioniert. Aber dann gebe ich die Hoffnung auf einen Patch mal nicht auf.

Mit APM funktioniert die Sache bisher ganz gut (allerdings ist mir die Kiste beim Kopieren von einigen GB übers Netzwerk trotzdem wieder ein paar mal eingefroren, aber das lässt sich meiner Erfahrung nach umgehen, wenn man "kleinere Portionen kopiert"). Die Festplatte wird mit max. 53°C gut warm, aber das scheint ja normal zu sein.
Immerhin hat das Notebook dann wohl keinen prinzipiellen Fehler und mir bleibt der Umtauschstress erspart.

@nicklos: Falls du mal zufällig ins BIOS schaust, würde mich auch interessieren, welche BIOS/Embedded-Controller-Version bei dir drauf ist.

Vielen Dank erstmal für eure Hilfe, ich hoffe mal dass in einer zukünftigen Kernelversion dann auch das ACPI wieder verwendbar wird.

Peter
 
@crash_landing

ich hab das 1.2o bios mit dem 1.06 embedded controller
 
Hm, das ist das gleiche, wie meins. Dann liegt es da dran schonmal nicht. Aber du hast ja den anderen Prozessor, vielleicht ist deshalb ein anderes Board verbaut...

Naja, ich warte jetzt mal ab, vll gibts ja bald einen Patch und dann kann ich mich freuen ;-)

Peter
 
@crash_landing:
LAN-Ausfälle: Schau Dir im BIOS mal unter "PCI" die IRQ-Belegungen an. Wenn die alle auf "11" stehen, bedeutet dies, dass die shared benutzt werden. Ich stelle die generell um auf verschiedene freie IRQ's, erhöht deutlich die Stabilität. Es gibt übrigens für dieses Problem von IBM einen Patch, der die IRQ-Zuweisung modifiziert. Solltest Du mal einspielen, dann dürfte es auch kein Problm mehr sein, ein ISO-Image mit 4 GB bei 750 kb/sec. ohne Abbruch herunterzuladen :D
Gruß
enrico65
 
Ja, die IRQ waren ursprünglich alle auf 11, ich habe sie dann auf "Auto" umgestellt. Ist das schlecht? Kann ich die einfach von 11 aufsteigend belegen, oder muss ich da noch bestimmte freihalten?

Nach dem Patch werde ich mich gleich mal umsehen

Peter
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben