Kernel-Ooops mit vmware, danach kein Reboot möglich
Hallo Liste, folgender Rechner: P4 3 GHz, Via P4M890/Via VT8237A Chipsatz, 1 GB Ram, mit SUSE 10.1 und Kernel 2.6.18-5-bigsmp lief bis heute morgen ganz normal. Heute abend wollte ich von einem anderen Rechner aus im installierten vmware-server 1.0.1 eine neue VM anlegen (es gibt schon zwei VMs, die bisher gut liefen), wobei der Rechner sich aufhing. Ich konnte keinen Reboot und kein Halt mehr machen, die Befehle wurden zwar angenommen (die Warnmessage dazu wurde auch auf die Konsole geworfen), aber er fuhr nicht runter. Also musste ich ihn einfach ausmachen (Aua!). Nach dem nächsten Booten versuchte ich das Ganze nochmal, wobei mir der Kernel diesmal sofort ein dickes "Ooops" um die Ohren schmiss. Und auch diesmal ging kein Reboot. Der Auszug zu dem Ooops aus /var/log/messages folgt am Ende der Mail. Möglicherweise ist es ein Filesystem-Problem, denn beim ersten Versuch hing sich der Rechner beim Anlegen der virtuellen Festplatte weg und im CallTrace-Abschnitt steht auch gleich was von reiserfs. Unabhängig davon: Wie kann ich den Rechner in so einem Zustand möglichst schadfrei herunterfahren? Wie gesagt, reboot, halt, shutdown -h usw. funktionieren nicht, init abschiessen hab ich auch nicht hinbekommen. Ich kann aber noch alle möglichen anderen Programme starten, wie top und so weiter. mfG, Jens Auszug aus /var/log/messages: Oct 4 19:38:45 miniserver vmware-authd[8058]: pam_unix2 (vmware-authd:auth): Unknown option: `shadow' Oct 4 19:38:45 miniserver vmware-authd[8058]: pam_unix2 (vmware-authd:setcred): Unknown option: `shadow' Oct 4 19:38:45 miniserver vmware-authd[8058]: login from 192.168.1.100 as root Oct 4 19:39:31 miniserver kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000018 Oct 4 19:39:31 miniserver kernel: printing eip: Oct 4 19:39:31 miniserver kernel: f907d530 Oct 4 19:39:31 miniserver kernel: *pde = 37b06001 Oct 4 19:39:31 miniserver kernel: Oops: 0000 [#1] Oct 4 19:39:31 miniserver kernel: SMP Oct 4 19:39:31 miniserver kernel: last sysfs file: /class/net/lo/ifindex Oct 4 19:39:31 miniserver kernel: Modules linked in: nfsd exportfs ipv6 edd vmnet vmmon nfs lockd nfs_acl sunrpc button battery ac loop usbhid dm_mod via_rhine mii ehci_hcd uhci_hcd usbcore ide_cd cdrom parport_pc lp parport reiserfs fan thermal processor ide_generic via82cxxx ide_disk ide_core Oct 4 19:39:31 miniserver kernel: CPU: 1 Oct 4 19:39:31 miniserver kernel: EIP: 0060:[<f907d530>] Tainted: P U VLI Oct 4 19:39:31 miniserver kernel: EFLAGS: 00010282 (2.6.18-5-bigsmp #1) Oct 4 19:39:31 miniserver kernel: EIP is at get_neighbors+0x38/0x12d [reiserfs] Oct 4 19:39:31 miniserver kernel: eax: f72e1e5c ebx: 00000000 ecx: 7aaaab01 edx: 00000000 Oct 4 19:39:31 miniserver kernel: esi: f72e1b8c edi: 00000001 ebp: 00000002 esp: f72e1b08 Oct 4 19:39:31 miniserver kernel: ds: 007b es: 007b ss: 0068 Oct 4 19:39:31 miniserver kernel: Process vmware-serverd (pid: 2821, ti=f72e0000 task=dfd9c630 task.ti=f72e0000) Oct 4 19:39:31 miniserver kernel: Stack: 00000000 00000000 c1897400 00000000 f72e1b8c 00000000 c1aa23e0 f907ec1a Oct 4 19:39:31 miniserver kernel: 00000000 000003f4 00000000 d23e4000 00000000 00000070 00000001 00000000 Oct 4 19:39:31 miniserver kernel: 000003f4 00000001 00000000 f72e1e5c 00000002 f72e1b8c 00000fd0 00000fd0 Oct 4 19:39:31 miniserver kernel: Call Trace: Oct 4 19:39:31 miniserver kernel: [<f907ec1a>] fix_nodes+0x338/0x694 [reiserfs] Oct 4 19:39:31 miniserver kernel: [<f9089f37>] reiserfs_paste_into_item+0x101/0x1e2 [reiserfs] Oct 4 19:39:31 miniserver kernel: [<f907ad75>] reiserfs_file_write+0xcd7/0x1a54 [reiserfs] Oct 4 19:39:31 miniserver kernel: [<c0165ec5>] vfs_write+0xa8/0x15f Oct 4 19:39:31 miniserver kernel: [<c01664fb>] sys_write+0x41/0x67 Oct 4 19:39:31 miniserver kernel: [<c0103ddd>] sysenter_past_esp+0x56/0x79 Oct 4 19:39:31 miniserver kernel: DWARF2 unwinder stuck at sysenter_past_esp+0x56/0x79 Oct 4 19:39:32 miniserver kernel: Leftover inexact backtrace: Oct 4 19:39:32 miniserver kernel: Code: ec 0c 8b 40 10 8b 56 08 03 28 89 54 24 08 83 bc be d4 00 00 00 00 74 79 8b 54 be 3c 39 54 e8 08 75 09 8b 8c be fc 00 00 00 eb 07 <8b> 42 18 0f b7 48 02 8b 52 18 8b 5c 24 08 0f b7 42 02 8b 9b 98 Oct 4 19:39:32 miniserver kernel: EIP: [<f907d530>] get_neighbors+0x38/0x12d [reiserfs] SS:ESP 0068:f72e1b08 Oct 4 19:39:32 miniserver kernel: BUG: warning at kernel/exit.c:857/do_exit() Oct 4 19:39:32 miniserver kernel: [<c01054ae>] show_trace_log_lvl+0x5b/0x16d Oct 4 19:39:32 miniserver kernel: [<c0105b4b>] show_trace+0xf/0x11 Oct 4 19:39:32 miniserver kernel: [<c0105c45>] dump_stack+0x15/0x17 Oct 4 19:39:32 miniserver kernel: [<c0123a64>] do_exit+0x4c/0x791 Oct 4 19:39:32 miniserver kernel: [<c0105aec>] die+0x289/0x2ae Oct 4 19:39:32 miniserver kernel: [<c02afc30>] do_page_fault+0x548/0x630 Oct 4 19:39:32 miniserver kernel: [<c0105039>] error_code+0x39/0x40 Oct 4 19:39:32 miniserver kernel: DWARF2 unwinder stuck at error_code+0x39/0x40 Oct 4 19:39:32 miniserver kernel: Leftover inexact backtrace: Oct 4 19:39:32 miniserver kernel: [<f907d530>] get_neighbors+0x38/0x12d [reiserfs] Oct 4 19:39:32 miniserver kernel: [<f907ec1a>] fix_nodes+0x338/0x694 [reiserfs] Oct 4 19:39:32 miniserver kernel: [<f9089f37>] reiserfs_paste_into_item+0x101/0x1e2 [reiserfs] Oct 4 19:39:32 miniserver kernel: [<c0174501>] open_namei+0x1f8/0x603 Oct 4 19:39:32 miniserver kernel: [<f907ad75>] reiserfs_file_write+0xcd7/0x1a54 [reiserfs] Oct 4 19:39:32 miniserver kernel: [<c012b856>] group_send_sig_info+0x4e/0x56 Oct 4 19:39:32 miniserver kernel: [<c0174ce7>] send_sigio_to_task+0xb6/0xd6 Oct 4 19:39:32 miniserver kernel: [<f908e684>] journal_end+0xc2/0xc9 [reiserfs] Oct 4 19:39:32 miniserver kernel: [<c017450f>] open_namei+0x206/0x603 Oct 4 19:39:32 miniserver kernel: [<c0174501>] open_namei+0x1f8/0x603 Oct 4 19:39:32 miniserver kernel: [<c0164434>] do_filp_open+0x37/0x3e Oct 4 19:39:32 miniserver kernel: [<f907a09e>] reiserfs_file_write+0x0/0x1a54 [reiserfs] Oct 4 19:39:32 miniserver kernel: [<c0165ec5>] vfs_write+0xa8/0x15f Oct 4 19:39:32 miniserver kernel: [<c01664fb>] sys_write+0x41/0x67 Oct 4 19:39:32 miniserver kernel: [<c0103ddd>] sysenter_past_esp+0x56/0x79
Hallo, Am Mit, 04 Okt 2006, Jens Nixdorf schrieb:
Unabhängig davon: Wie kann ich den Rechner in so einem Zustand möglichst schadfrei herunterfahren? Wie gesagt, reboot, halt, shutdown -h usw. funktionieren nicht, init abschiessen hab ich auch nicht hinbekommen. Ich kann aber noch alle möglichen anderen Programme starten, wie top und so weiter.
Sysrq. Sysrq + s sync Sysrq + u umount (= remount ro in dem Fall) Sysrq + b reboot Sysrq + o shut off Sysrq ist: Strg+Alt+Druck. Ausserdem musst du Sysrq aktivieren. Ich habe meine Kernel so kompiliert, dass es per default aktiv ist: # cat /proc/sys/kernel/sysrq 1 Aktivieren geht "per Hand" mit 'echo 1 > /proc/sys/kernel/sysrq'. Oder mit sysctl. Hm. Ich bin mir nicht sicher ob das mit Kernel 2.6.x noch unter /proc/ ist. Wenn nicht dann eben /sys/kernel/sysrq vermutlich ;) Oder a la SuSE: ==== /etc/sysconfig/sysctl ==== # Enable Magic SysRq Keys? # If you say yes here, you will have some control over the system even # if it crashes (e.g. during kernel debugging). # For further information see /usr/src/linux/Documentation/sysrq.txt # ENABLE_SYSRQ="yes" ==== Anschliessend ist kein SuSEconfig noetig, /etc/sysconfig/sysctl wird direkt von /etc/init.d/boot.proc eingelesen (SUSE 10.1). Bei aeltern SuSEn sollte man das kontrollieren (grep -i sysctl /etc/init.d/boot*).
Oct 4 19:39:31 miniserver kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000018 [..] Oct 4 19:39:31 miniserver kernel: Process vmware-serverd (pid: 2821, ti=f72e0000 task=dfd9c630 task.ti=f72e0000) [..] Oct 4 19:39:31 miniserver kernel: Call Trace: Oct 4 19:39:31 miniserver kernel: [<f907ec1a>] fix_nodes+0x338/0x694 [reiserfs] Oct 4 19:39:31 miniserver kernel: [<f9089f37>] reiserfs_paste_into_item+0x101/0x1e2 [reiserfs] Oct 4 19:39:31 miniserver kernel: [<f907ad75>] reiserfs_file_write+0xcd7/0x1a54 [reiserfs]
Und ja, das scheint Reiserfs nicht zu wollen. Hast du schon die Hardware (RAM, Platten) geprueft? -dnh -- Time is an illusion; lunchtime, doubly so. -- Ford Prefect
Am Mittwoch, 4. Oktober 2006 22:27 schrieb David Haller:
Und ja, das scheint Reiserfs nicht zu wollen. Hast du schon die Hardware (RAM, Platten) geprueft?
Erst mal danke für den Tipp mit sysrq, das sieht gut aus. Ja, reiserfsck hatte im ersten readonly-Durchlauf 113 Fehler gefunden, davon 2, die ohne reiserfsck --rebuild-tree nicht reparierbar seien. Ist grad durchgelaufen, schaut bis auf ein paar verlorene Dateien (glücklicherweise nichts Wichtiges) ganz gut aus. mfG, Jens
-----Ursprüngliche Nachricht----- Von: Jens Nixdorf [mailto:jens.nixdorf.liste@trackpoint.de] Gesendet: Mittwoch, 4. Oktober 2006 22:44 An: SuSE Linux Betreff: Re: Kernel-Ooops mit vmware, danach kein Reboot möglich
Am Mittwoch, 4. Oktober 2006 22:27 schrieb David Haller:
Und ja, das scheint Reiserfs nicht zu wollen. Hast du schon die Hardware (RAM, Platten) geprueft?
Erst mal danke für den Tipp mit sysrq, das sieht gut aus. Ja, reiserfsck hatte im ersten readonly-Durchlauf 113 Fehler gefunden, davon 2, die ohne reiserfsck --rebuild-tree nicht reparierbar seien.
Ist grad durchgelaufen, schaut bis auf ein paar verlorene Dateien (glücklicherweise nichts Wichtiges) ganz gut aus.
Ich würde darüber nachdenken auf ext3 zu wechseln. Kann ja sein das ich es mir einbilde aber solche Probleme lese ich immer im Zusammenhang mit defekter Hardware oder aber ReiserFS ist im Einsatz.
Am Donnerstag, den 05.10.2006, 07:41 +0200 schrieb ralf.prengel@comline.de: ...
Ich würde darüber nachdenken auf ext3 zu wechseln. Kann ja sein das ich es mir einbilde aber solche Probleme lese ich immer im Zusammenhang mit defekter Hardware oder aber ReiserFS ist im Einsatz.
Auch wenn immer das Gegenteil behauptet wird, aber auch meine
Erfahrungen bestätigen das. VMware mit ext3, "Null Problemo".
--
Dr. Reiner Pietrzak
Am Donnerstag, 5. Oktober 2006 08:55 schrieb Dr. Reiner Pietrzak:
Ich würde darüber nachdenken auf ext3 zu wechseln. Kann ja sein das ich es mir einbilde aber solche Probleme lese ich immer im Zusammenhang mit defekter Hardware oder aber ReiserFS ist im Einsatz.
Auch wenn immer das Gegenteil behauptet wird, aber auch meine Erfahrungen bestätigen das. VMware mit ext3, "Null Problemo".
Gibt es Möglichkeiten, eine volle Platte zu konvertieren? mfG, Jens
Jens Nixdorf schrieb:
Am Donnerstag, 5. Oktober 2006 08:55 schrieb Dr. Reiner Pietrzak:
Ich würde darüber nachdenken auf ext3 zu wechseln. Kann ja sein das ich es mir einbilde aber solche Probleme lese ich immer im Zusammenhang mit defekter Hardware oder aber ReiserFS ist im Einsatz.
Auch wenn immer das Gegenteil behauptet wird, aber auch meine Erfahrungen bestätigen das. VMware mit ext3, "Null Problemo".
Gibt es Möglichkeiten, eine volle Platte zu konvertieren?
mfG, Jens
Sorry: Totaler Blödsinn! Reiser-FS ist nur auf Hardwarefehler "Anfälliger" weil man zerstörte Daten schneller bemerkt. Die sind aber bei ext3 genau so zerstört (bei gleichem Fehler natürlich) nur fällt es erst viel später auf. Ich betreibe einige Server im Terrabyte-Bereich mit Reiserfs und hatte nie Probleme damit - einzige Ausnahme: Motherboards OHNE ECC. Dann kommt es unter Garantie irgend wann zu Speicherfehlern (Das bedeutet nicht, dass der Speicher kaputt ist, sondern z.B. sich ein Alphateiclchen verirrt hat und ein Bit gedreht wurde - das ist Systembedingt nicht zu vermeiden) die ganz einfach nicht bemerkt werden und das gibt den Dateisystemen dann den Rest. -- Mit freundlichen Grüßen / best regards Ing. Rainer Pietsch ---------------------------------------------------------- PCS - Pichler Computer Systeme Inh. Claudia Pichler-Pietsch Hauptplatz 10 A-2751 Steinabrückl ---------------------------------------------------------- mail: r.pietsch@sys-adm.net web: http://www.sys-adm.net tel.: +43 (2622) 420 19 / 15 mobil: +43 (676) 31 242 69 fax: +43 (2622) 420 19 / 20 ----------------------------------------------------------
Also schrieb Dr. Reiner Pietrzak am Donnerstag, 5. Oktober 2006 08:55:
Auch wenn immer das Gegenteil behauptet wird, aber auch meine Erfahrungen bestätigen das. VMware mit ext3, "Null Problemo". Namastè!
Dem kann ich zustimmen. Bei mir crasht der Kernel auch hin und wieder im Zusammenhang mit Vmware, bloß gibt es bei mir (ext3) keine Dateisystemfehler. Wann crasht bei mir der Kernel? Ich benutze meine USB-Musikperipherie auch unter Vmware. Wenn ich nun die USB-Peripherie dem USB-Stecker entnehme (ausstöpsel), dann kann ich alles noch verwenden, außer meine Tastatur. /var/log/messages zeigt dann oft einen Kernel-Oops. Mit SysRq kann ich den Rechner manchmal ordentlich herunterfahren (sync + unmount, etc), aber oft geht auch das nicht. Bei mir muss ich dann dafür sorgen, dass ich die USB-Musikperipherie vor dem booten dem Rechner entnommen habe, und einstöpsel sobald WinXP-VM läuft. Tschau, Ulrich. -- ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø My Box said: "Install WinXP/Vista/Longhorn (what ever) or better ..." So I installed Linux. ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø
Hallo, Am Don, 05 Okt 2006, Ulrich Grün schrieb:
Ich benutze meine USB-Musikperipherie auch unter Vmware. Wenn ich nun die USB-Peripherie dem USB-Stecker entnehme (ausstöpsel), dann kann ich alles noch verwenden, außer meine Tastatur. /var/log/messages zeigt dann oft einen Kernel-Oops. Mit SysRq kann ich den Rechner manchmal ordentlich herunterfahren (sync + unmount, etc), aber oft geht auch das nicht.
Kein Wunder, wenn die Tastatur oder das ganze USB-Subsystem durch ein Oops lahmgelegt wird. Apropos: man kann auch einen Joystick verwenden, wenn der ganz altmodisch am Gameport haengt kann man den noch verwenden wenn sich die Tastatur weggehaengt hat => joyd. -dnh -- "HPUX" and "sane" have never been uttered in the same sentence without accompanying negatives. -- Richard Henderson on gcc ml
Hallo, Am Mit, 04 Okt 2006, Jens Nixdorf schrieb:
Am Mittwoch, 4. Oktober 2006 22:27 schrieb David Haller:
Und ja, das scheint Reiserfs nicht zu wollen. Hast du schon die Hardware (RAM, Platten) geprueft?
Erst mal danke für den Tipp mit sysrq, das sieht gut aus. Ja, reiserfsck hatte im ersten readonly-Durchlauf 113 Fehler gefunden, davon 2, die ohne reiserfsck --rebuild-tree nicht reparierbar seien.
Ich meinte eher, dass du mal nach Plattendefekten schaust, also erstmal mit 'smartctl' was die Platte selber dazu sagt und dann mal mit badblocks. -dnh -- Treat your password like your toothbrush. Don't let anybody else use it, and get a new one every six months. -- Clifford Stoll [found in ssl_engine_pphrase.c]
Am Donnerstag, 5. Oktober 2006 13:58 schrieb David Haller:
Ich meinte eher, dass du mal nach Plattendefekten schaust, also erstmal mit 'smartctl' was die Platte selber dazu sagt und dann mal mit badblocks.
smartctl -h sagt "PASSED", und badblocks sagt auch: Checking for bad blocks (read-only test): done 864 Pass completed, 0 bad blocks found. Also nochmal Glück gehabt, denke ich. Was bedeutet eigentlich diese 864 bei badblocks? mfG, Jens
Hallo, Am Don, 05 Okt 2006, Jens Nixdorf schrieb:
Am Donnerstag, 5. Oktober 2006 13:58 schrieb David Haller:
Ich meinte eher, dass du mal nach Plattendefekten schaust, also erstmal mit 'smartctl' was die Platte selber dazu sagt und dann mal mit badblocks.
smartctl -h sagt "PASSED",
-h, --help, --usage Prints a usage message to STDOUT and exits. Meintest du 'smartctl -H'? Das ist nicht sehr Aussagekraeftig. Schau dir mal die Ausgabe von 'smartctl -A' an. Eventuell auch die von 'smartctl -a' die die Ausgabe von -A nochmal enthaelt. In der Ausgabe sind v.a. die folgenden Werte interessant: Raw_Read_Error_Rate, Reallocated_Sector_Ct, Reallocated_Event_Count, Current_Pending_Sector und Offline_Uncorrectable(?). Evtl. auch noch Seek_Error_Rate, Temperature_Celsius, Hardware_ECC_Recovered, UDMA_CRC_Error_Count, Multi_Zone_Error_Rate und Soft_Read_Error_Rate
und badblocks sagt auch: Checking for bad blocks (read-only test): done 864 Pass completed, 0 bad blocks found.
Aber das ist schonmal gut, wenn badblocks nichts findet.
Also nochmal Glück gehabt, denke ich.
Ja.
Was bedeutet eigentlich diese 864 bei badblocks?
Weiss ich auch nicht, ich nehme immer 'e2fsck -c' :) -dnh -- Och yes. I used to have a brain once. If anyone sees it, please ask it to come back, I miss it sometimes. -- Frossie
Am Donnerstag, 5. Oktober 2006 23:55 schrieb David Haller:
Meintest du 'smartctl -H'? Das ist nicht sehr Aussagekraeftig. Schau dir mal die Ausgabe von 'smartctl -A' an.
Ja, ich meinte -H.
Eventuell auch die von 'smartctl -a' die die Ausgabe von -A nochmal enthaelt. In der Ausgabe sind v.a. die folgenden Werte interessant: Raw_Read_Error_Rate, Reallocated_Sector_Ct, Reallocated_Event_Count, Current_Pending_Sector und Offline_Uncorrectable(?).
Raw_Read_Error_Rate gibts hier nicht, die anderen stehen auf 0. Hier der Rest: ---------8<-------------------------------------------------------------- SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 3 Spin_Up_Time 0x0027 225 221 063 Pre-fail Always - 7306 4 Start_Stop_Count 0x0032 252 252 000 Old_age Always - 3512 5 Reallocated_Sector_Ct 0x0033 253 253 063 Pre-fail Always - 0 6 Read_Channel_Margin 0x0001 253 253 100 Pre-fail Offline - 0 7 Seek_Error_Rate 0x000a 253 252 000 Old_age Always - 0 8 Seek_Time_Performance 0x0027 244 244 187 Pre-fail Always - 33381 9 Power_On_Minutes 0x0032 240 240 000 Old_age Always - 474h+13m 10 Spin_Retry_Count 0x002b 253 252 157 Pre-fail Always - 0 11 Calibration_Retry_Count 0x002b 253 252 223 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 249 249 000 Old_age Always - 1822 192 Power-Off_Retract_Count 0x0032 253 253 000 Old_age Always - 0 193 Load_Cycle_Count 0x0032 253 253 000 Old_age Always - 0 194 Temperature_Celsius 0x0032 253 253 000 Old_age Always - 44 195 Hardware_ECC_Recovered 0x000a 253 252 000 Old_age Always - 34749 196 Reallocated_Event_Count 0x0008 253 253 000 Old_age Offline - 0 197 Current_Pending_Sector 0x0008 253 253 000 Old_age Offline - 0 198 Offline_Uncorrectable 0x0008 253 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0008 199 199 000 Old_age Offline - 0 200 Multi_Zone_Error_Rate 0x000a 253 252 000 Old_age Always - 0 201 Soft_Read_Error_Rate 0x000a 253 252 000 Old_age Always - 28 202 TA_Increase_Count 0x000a 253 252 000 Old_age Always - 0 203 Run_Out_Cancel 0x000b 253 252 180 Pre-fail Always - 0 204 Shock_Count_Write_Opern 0x000a 253 252 000 Old_age Always - 0 205 Shock_Rate_Write_Opern 0x000a 253 252 000 Old_age Always - 0 207 Spin_High_Current 0x002a 253 252 000 Old_age Always - 0 208 Spin_Buzz 0x002a 253 252 000 Old_age Always - 0 209 Offline_Seek_Performnce 0x0024 150 150 000 Old_age Offline - 0 99 Unknown_Attribute 0x0004 253 253 000 Old_age Offline - 0 100 Unknown_Attribute 0x0004 253 253 000 Old_age Offline - 0 101 Unknown_Attribute 0x0004 253 253 000 Old_age Offline - 0 ---------8<--------------------------------------------------------------
Evtl. auch noch Seek_Error_Rate, Temperature_Celsius, Hardware_ECC_Recovered, UDMA_CRC_Error_Count, Multi_Zone_Error_Rate und Soft_Read_Error_Rate
Hardware_ECC_Recovered steht bei 34749, was ja mal eine heftige Zahl ist. Muss ich mir da Sorgen machen? Und dann sagt smartctl -a auch noch das hier: ---------8<-------------------------------------------------------------- SMART Error Log Version: 1 Warning: ATA error count 488 inconsistent with error log pointer 5 ATA Error Count: 488 (device log contains only the most recent five errors) CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 488 occurred at disk power-on lifetime: 1633 hours (68 days + 1 hours) When the command that caused the error occurred, the device was in an unknown state. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 b4 04 1b e1 Error: UNC 1 sectors at LBA = 0x011b04b4 = 18547892 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 01 b4 04 1b e1 00 03:58:15.136 READ DMA e5 00 00 b4 04 1b a0 00 03:58:15.120 CHECK POWER MODE c8 00 01 b4 04 1b e1 00 03:58:10.144 READ DMA e5 00 00 52 20 00 a0 00 03:58:10.144 CHECK POWER MODE c8 00 01 52 20 00 e0 00 03:58:10.144 READ DMA Error 487 occurred at disk power-on lifetime: 1633 hours (68 days + 1 hours) When the command that caused the error occurred, the device was in an unknown state. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 b4 04 1b e1 Error: UNC 1 sectors at LBA = 0x011b04b4 = 18547892 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 01 b4 04 1b e1 00 03:58:10.144 READ DMA e5 00 00 52 20 00 a0 00 03:58:10.144 CHECK POWER MODE c8 00 01 52 20 00 e0 00 03:58:10.144 READ DMA c8 00 bc 50 20 00 e0 00 03:58:10.128 READ DMA e5 00 00 54 20 00 a0 00 03:58:10.128 CHECK POWER MODE Error 486 occurred at disk power-on lifetime: 1633 hours (68 days + 1 hours) When the command that caused the error occurred, the device was in an unknown state. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 b4 04 1b e1 Error: UNC 1 sectors at LBA = 0x011b04b4 = 18547892 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 01 b4 04 1b e1 00 03:56:47.904 READ DMA e5 00 00 b4 04 1b a0 00 03:56:47.888 CHECK POWER MODE c8 00 01 b4 04 1b e1 00 03:56:42.928 READ DMA e5 00 00 b4 04 1b a0 00 03:56:42.896 CHECK POWER MODE c8 00 01 b4 04 1b e1 00 03:56:37.952 READ DMA Error 485 occurred at disk power-on lifetime: 1633 hours (68 days + 1 hours) When the command that caused the error occurred, the device was in an unknown state. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 b4 04 1b e1 Error: UNC 1 sectors at LBA = 0x011b04b4 = 18547892 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 01 b4 04 1b e1 00 03:56:42.928 READ DMA e5 00 00 b4 04 1b a0 00 03:56:42.896 CHECK POWER MODE c8 00 01 b4 04 1b e1 00 03:56:37.952 READ DMA e5 00 00 b4 04 1b a0 00 03:56:37.920 CHECK POWER MODE c8 00 01 b4 04 1b e1 00 03:55:27.424 READ DMA Error 484 occurred at disk power-on lifetime: 1633 hours (68 days + 1 hours) When the command that caused the error occurred, the device was in an unknown state. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 b4 04 1b e1 Error: UNC 1 sectors at LBA = 0x011b04b4 = 18547892 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 01 b4 04 1b e1 00 03:56:37.952 READ DMA e5 00 00 b4 04 1b a0 00 03:56:37.920 CHECK POWER MODE c8 00 01 b4 04 1b e1 00 03:55:27.424 READ DMA e5 00 00 b4 04 1b a0 00 03:55:27.408 CHECK POWER MODE c8 00 01 b4 04 1b e1 00 03:55:22.448 READ DMA SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 4529 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. ---------8<-------------------------------------------------------------- Die Platte ist eigentlich aus einem Topfield-Satreceiver, der kaputt gegangen ist und kam jetzt erst in einen neuen Rechner rein. Am Anfang konnte SUSE mit dem Rechner noch nicht richtig umgehen, und zwar weil der Original-Kernel 2.6.16(?) von SUSE 10.1 nicht richtig mit dem Via-P4M890/VT8237A-Chipsatz umgehen kann. Das äußerte sich darin, daß SUSE die IDE-Geräte nicht fand (auch schon beim Installieren), erst ein "insmod=ide-generic" als Übergabe an grub hat überhaupt eine Installation ermöglicht. Und bis dann der Kernel 2.6.18-5 installiert war, liefen die Platten damit. Da gingdann kein DMA usw. Vielleicht rühren die Einträge auch daher? mfG, Jens
Hallo, Am Fre, 06 Okt 2006, Jens Nixdorf schrieb:
Am Donnerstag, 5. Oktober 2006 23:55 schrieb David Haller:
Meintest du 'smartctl -H'? Das ist nicht sehr Aussagekraeftig. Schau dir mal die Ausgabe von 'smartctl -A' an. [..] 5 Reallocated_Sector_Ct 0x0033 253 253 063 Pre-fail Always - 0
Gut.
194 Temperature_Celsius 0x0032 253 253 000 Old_age Always - 44
Noch ok.
195 Hardware_ECC_Recovered 0x000a 253 252 000 Old_age Always - 34749
s.u.
196 Reallocated_Event_Count 0x0008 253 253 000 Old_age Offline - 0 197 Current_Pending_Sector 0x0008 253 253 000 Old_age Offline - 0 198 Offline_Uncorrectable 0x0008 253 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0008 199 199 000 Old_age Offline - 0 200 Multi_Zone_Error_Rate 0x000a 253 252 000 Old_age Always - 0
Gut.
201 Soft_Read_Error_Rate 0x000a 253 252 000 Old_age Always - 28
Hm. Das ist bei mir bei 4/5 "0" und bei der 5ten "15". [Rest ok]
Evtl. auch noch Seek_Error_Rate, Temperature_Celsius, Hardware_ECC_Recovered, UDMA_CRC_Error_Count, Multi_Zone_Error_Rate und Soft_Read_Error_Rate
Hardware_ECC_Recovered steht bei 34749, was ja mal eine heftige Zahl ist. Muss ich mir da Sorgen machen?
Nö. Bei mir: Device Pwr_On [1] Hw_ECC_Rec.[2] -------- ---------- -------------- /dev/sda 608 61309 /dev/hda 1770 7855257 /dev/hdb 6603h+35m 7751 /dev/hdc 7177h+57m 132343100 /dev/hdd 392h+36m[3] 397 [1] Power_On_Half_Minutes (h+m) bzw. Power_On_Hours [2] Hardware_ECC_Recovered [3] Besonderheit bei Maxtor, wird alle 1092h wieder 0, hdd ist einiges aelter als hdc.
Und dann sagt smartctl -a auch noch das hier: [..] Error 488 occurred at disk power-on lifetime: 1633 hours (68 days + 1 hours) When the command that caused the error occurred, the device was in an unknown state.
After command completion occurred, registers were: ER ST SC SN CL CH DH 40 51 01 b4 04 1b e1 Error: UNC 1 sectors at LBA = 0x011b04b4 = 18547892 [..]
Lies http://smartmontools.sourceforge.net/BadBlockHowTo.txt und frag (ggfs. per PM) falls du was nicht verstehst oder sonst Fragen hast. Achso: beim lesen/schreiben auf den Sektor: lass die Rechnerei und greif ueber das device zu, siehe im "second example" die Zeile bei "We could also probably use:". HTH, -dnh -- It is traditional, when loading wire trolleys, to put the most fragile items at the bottom. -- Terry Pratchett, Reaper Man
Am Freitag, 6. Oktober 2006 13:46 schrieb David Haller:
After command completion occurred, registers were: ER ST SC SN CL CH DH 40 51 01 b4 04 1b e1 Error: UNC 1 sectors at LBA = 0x011b04b4 = 18547892
[..]
Lies http://smartmontools.sourceforge.net/BadBlockHowTo.txt und frag (ggfs. per PM) falls du was nicht verstehst oder sonst Fragen hast. Achso: beim lesen/schreiben auf den Sektor: lass die Rechnerei und greif ueber das device zu, siehe im "second example" die Zeile bei "We could also probably use:".
Ich habe jetzt erstmal folgendes wie in dem HowTo gemacht: miniserver:~ # export i=18547850 miniserver:~ # while [ $i -lt 18547950 ] > do echo $i > dd if=/dev/hdb of=/dev/null bs=512 count=1 skip=$i > let i+=1 > done Dabei gab es aber keinen Fehler. Das Ganze habe ich insgesamt 10 mal durchlaufen lassen, immer alles OK. Ich denke mal, das die Platte noch ganz OK ist. mfG, Jens
Sorry, vergessen: Danke für die Hilfe bisher... mfG, Jens
Hallo, Am Sam, 07 Okt 2006, Jens Nixdorf schrieb:
Am Freitag, 6. Oktober 2006 13:46 schrieb David Haller:
After command completion occurred, registers were: ER ST SC SN CL CH DH 40 51 01 b4 04 1b e1 Error: UNC 1 sectors at LBA = 0x011b04b4 = 18547892
[..] Lies http://smartmontools.sourceforge.net/BadBlockHowTo.txt und frag (ggfs. per PM) falls du was nicht verstehst oder sonst Fragen hast. Achso: beim lesen/schreiben auf den Sektor: lass die Rechnerei und greif ueber das device zu, siehe im "second example" die Zeile bei "We could also probably use:".
Ich habe jetzt erstmal folgendes wie in dem HowTo gemacht:
miniserver:~ # export i=18547850 miniserver:~ # while [ $i -lt 18547950 ]
do echo $i dd if=/dev/hdb of=/dev/null bs=512 count=1 skip=$i let i+=1 done
Dabei gab es aber keinen Fehler.
Hat die Platte evtl. beim ersten Versuch anders geklungen als sonst?
Das Ganze habe ich insgesamt 10 mal durchlaufen lassen, immer alles OK. Ich denke mal, das die Platte noch ganz OK ist.
Moment. Hattest du 'sync' aufgerufen und dann anschliessend 'smartctl -t long' und 'smartctl -t selftest' (und evtl. 'smartctl -t offline') ausgefuehrt? Und anschliessend mit 'smartctl -A' nachgeschaut, ob sich an den relevanten Eintraegen was geaendert hat? Und was sagt 'smartctl -a' anschliessend? -dnh -- Windows 98? Warum? Ich hab' das alte noch nicht zu Ende gespielt.
Am Sonntag, 8. Oktober 2006 02:11 schrieb David Haller:
Das Ganze habe ich insgesamt 10 mal durchlaufen lassen, immer alles OK. Ich denke mal, das die Platte noch ganz OK ist.
Moment. Hattest du 'sync' aufgerufen und dann anschliessend 'smartctl -t long' und 'smartctl -t selftest' (und evtl. 'smartctl -t offline') ausgefuehrt? Und anschliessend mit 'smartctl -A' nachgeschaut, ob sich an den relevanten Eintraegen was geaendert hat?
smartctl -t selftest gibts hier nicht(?), habe smartctl -t long laufen lassen. Hier die Unterschiede in der Ausgabe von smartctl A vorher und nachher (Vorher-Werte in Klammern): 8 Seek_Time_Performance 0x0027 250 244 187 Pre-fail Always - 52088 (42362) 195 Hardware_ECC_Recovered 0x000a 253 252 000 Old_age Always - 46443 (30151) 201 Soft_Read_Error_Rate 0x000a 253 252 000 Old_age Always - 6 (10) 203 Run_Out_Cancel 0x000b 253 252 180 Pre-fail Always - 0 (1) Also die Seek_Time_Performance- und Hardware_ECC_Recovered-Werte sind größer, die anderen beiden sind kleiner geworden. Hardware_ECC_Recovered war aber vor zwei Tagen auch schon rund 34749 und bei smartctl -a (siehe unten) wieder einen ganz anderen Wert.
Und was sagt 'smartctl -a' anschliessend?
Hier kommen die Sachen die sich geändert haben: 3 Spin_Up_Time 0x0027 225 221 063 Pre-fail Always - 7443 (7306) 8 Seek_Time_Performance 0x0027 250 244 187 Pre-fail Always - 52127 (33381) 195 Hardware_ECC_Recovered 0x000a 253 252 000 Old_age Always - 46443 (34749) 201 Soft_Read_Error_Rate 0x000a 253 252 000 Old_age Always - 6 (28) Dann steht da jetzt noch neu: SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 4573 Die Änderungen an der Temperatur und reine Zählerdaten wie Power_On_Minutes hab ich jetzt mal weggelassen. mfG, Jens
Hallo, Am Son, 08 Okt 2006, Jens Nixdorf schrieb:
Am Sonntag, 8. Oktober 2006 02:11 schrieb David Haller:
Das Ganze habe ich insgesamt 10 mal durchlaufen lassen, immer alles OK. Ich denke mal, das die Platte noch ganz OK ist.
Moment. Hattest du 'sync' aufgerufen und dann anschliessend 'smartctl -t long' und 'smartctl -t selftest' (und evtl. 'smartctl -t offline') ausgefuehrt? Und anschliessend mit 'smartctl -A' nachgeschaut, ob sich an den relevanten Eintraegen was geaendert hat?
smartctl -t selftest gibts hier nicht(?), habe smartctl -t long laufen lassen. Hier die Unterschiede in der Ausgabe von smartctl A vorher und nachher (Vorher-Werte in Klammern): [..]
Interessant sind: Reallocated_Sector_Ct, Reallocated_Event_Count, Current_Pending_Sector, Offline_Uncorrectable -dnh -- "...you want a .sig with that?"
Am Sonntag, 8. Oktober 2006 20:33 schrieb David Haller: Sorry, Antwort hat ein bischen gedauert, weil die T-Com den DSL-Anschluss umschaltet, aber die dazu nötige Hardware nicht liefern kann und mein altes Modem tat es nicht mit dem "neuen" DSL. Hmpf!!
Reallocated_Sector_Ct, Reallocated_Event_Count, Current_Pending_Sector, Offline_Uncorrectable
Alle vier Werte stehen auf 0. mfG, Jens
Hallo, Am Die, 10 Okt 2006, Jens Nixdorf schrieb:
Am Sonntag, 8. Oktober 2006 20:33 schrieb David Haller:
Sorry, Antwort hat ein bischen gedauert, weil die T-Com den DSL-Anschluss umschaltet, aber die dazu nötige Hardware nicht liefern kann und mein altes Modem tat es nicht mit dem "neuen" DSL. Hmpf!!
Reallocated_Sector_Ct, Reallocated_Event_Count, Current_Pending_Sector, Offline_Uncorrectable
Alle vier Werte stehen auf 0.
Ok. Dann ist's wohl gut :) -dnh -- Documentation: Cryptic, lacking, erroneous. Pick any three.
participants (6)
-
David Haller -
Dr. Reiner Pietrzak -
Jens Nixdorf -
Rainer Pietsch -
ralf.prengel＠comline.de -
Ulrich Grün