PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : samsung notebook - boot problem



OpOs
16.08.06, 21:50
hi

es geht um folgende fehlermeldung:
<4>ide: failed opcode was: unknown
<4>hda: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
<4>hda: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=195371567, high=11, low=10822191, sector=195371567
<4>ide: failed opcode was: unknown
<4>hda: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
<4>hda: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=195371567, high=11, low=10822191, sector=195371567
<4>ide: failed opcode was: unknown
<4>ide0: reset: success
<4>hda: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
<4>hda: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=195371567, high=11, low=10822191, sector=195371567
<4>ide: failed opcode was: unknown
<4>end_request: I/O error, dev hda, sector 195371567
<4>hda: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
<4>hda: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=195371567, high=11, low=10822191, sector=195371567
<4>ide: failed opcode was: unknown
<4>hda: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
<4>hda: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=195371567, high=11, low=10822191, sector=195371567
<4>ide: failed opcode was: unknown
<4>hda: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
<4>hda: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=195371567, high=11, low=10822191, sector=195371567
<4>ide: failed opcode was: unknown
<4>hda: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
<4>hda: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=195371567, high=11, low=10822191, sector=195371567
<4>ide: failed opcode was: unknown
<4>ide0: reset: success

das iss bloss ein auszug. dieses zeug erstreckt sich ueber schlappe 1800 zeile plus minus ein paar zerquetschte. die zahlen sind immer mal andere, aber ich glaub nich dass das wichtig is.

wenn ich nach aehnlichen fehlermeldungen suche, finde ich nur wilde spekulationen aber nichts wirklich hilfreiches.

ich konnte das problem auf einen nicht beschreibbaren mbr eingrenzen. wenn ich den schreibschutz im bios abstelle, bootet alles sauber. wenn der schreibschutz aktiviert ist, dauert es ein paar minuten, bis alle fehlermeldungen durchgelaufen sind und dann geht das booten ohne probleme.

leider wird die einstellung im bios bei jedem boot zurueckgesetzt... ziemlich laestig

ich suche nun nach einer dauerhaften loesung, moechlichst ohne flashen, patchen oder kernel kompilieren, wenn es sich vermeiden laesst.

hat da jemand 'nen vorschlag fuer mich?

Notebook iss Samsung X20, SuSE 10.1, GRUB im MBR

danke

kshade
16.08.06, 22:14
hat da jemand 'nen vorschlag fuer mich?

Ja, installier dir mal badblocks, führe es als root aus und poste die Ausgabe hier: badblocks -s /dev/hda

Ich hab' mal ein Paar Berichte zum X20 (http://www.linux-on-laptops.com/samsung.html) überflogen und konnte nirgends dein Problem wiederfinden, eventuell hat deine Festplatte eine Macke.

Vielleicht hilft wegen des automatischen zurückstellen des Schreibschutzes ein BIOS-Update (http://www.samsungpc.com/products/x20/x20_bios.htm).

OpOs
16.08.06, 22:38
naja, ich wollte das eigentlich ohne bios update machen... schlechte erinnerungen...
aber samsung schweigt sich auf der seite auch ziemlich aus. oder sollen die fixes, die da stehen, alles sein? und passen die updates fuer alle X20-varianten? fragen ueber fragen.
ich gucke morgen mal, welche bios version ich hab...
und ueberhaupt, wieso brauche ich windows um ein update zu machen. gut, ich hab eins installiert, aber trotzdem :-(

das mit dem badblocks probier ich auch morgen.

ich glaub nich, dass die hd kaputt iss... wie gesagt, wenn ich den schutz ausschalte, gibt's keine probleme. ich vermute eher, grub versucht sich da was in den bootsektor zu schreiben (oder vielleicht auch nur von da zu lesen) und wird vom bios davon abgehalten.

fuer heute iss erstma feierabend. gute nacht

stefan.becker
16.08.06, 23:08
Ist das eine IDE Platte? Hast du per hdparm an den Parametern rummgespielt?

jensrenner
17.08.06, 07:52
Ich hatte das auch wiederkehrend bei meinem X05 (mit Debian unstable und Kernels > 2.6.15).

Meistens häuften sich die Fehlermeldungen mit fortschreitender Zeit, insgesamt hatte ich in einem halben Jahr vier kaputte Filesysteme (mit unterschiedlichen HDDs und FSs).
Schlussendlich ist wohl ein fehlerhaftes BIOS Schuld gewesen. Per Default wurde bei jedem Boot eine Auto Detection durchgeführt, soweit ok. Aber obwohl die Plattengeometrie korrekt erkannt wurde, schlug manchmal die Berechnung der Plattengröße per LBA fehl.
Das Problem war reproduzierbar, der Samsung-Hotline aber nicht bekannt. Abhilfe konnte geschaffen werden, indem nach einer korrekten Erkennung der HDD die Parameter im BIOS "eingefroren" wurden.

Langer Rede kurzer Sinn :D : ob es einen direkten Zusammenhang zwischen den Fehlern und meinem BIOS-Problem gab, weiß ich nicht. Zumindest schien es mir so. Auf jeden Fall besteht die Möglichkeit, dass etwas im BIOS generell nicht in Ordnung ist.

Gruß

Jens

kshade
17.08.06, 15:21
Interessant, bei meinem X10+ ist mir sowas nie passiert.

OpOs
17.08.06, 21:19
so, bad blocks laeuft grad und dauert noch 'n bisschen, bis jetzt hat sich an der front noch nix spannendes ergeben...

bios version ist 10ZA, update steht also nich zur debatte...

im anhang noch mal die beiden logs zum nachlesen, einmal mit und mal ohne protection. das feature nennt sich uebrigens irgendwas mit "recovery area", musste aber deaktiviert werden, damit ich die partitionstabelle speichern konnte...

Lindiot
17.08.06, 21:46
Meistens häuften sich die Fehlermeldungen mit fortschreitender Zeit, insgesamt hatte ich in einem halben Jahr vier kaputte Filesysteme (mit unterschiedlichen HDDs und FSs).
Schlussendlich ist wohl ein fehlerhaftes BIOS Schuld gewesen. Per Default wurde bei jedem Boot eine Auto Detection durchgeführt, soweit ok. Aber obwohl die Plattengeometrie korrekt erkannt wurde, schlug manchmal die Berechnung der Plattengröße per LBA fehl.
Das Problem war reproduzierbar, der Samsung-Hotline aber nicht bekannt.


Das ist so irgendwie auch nicht schlüssig. Die 'Geometrie-Parameter' usw werden von der Platte gemeldet, 'ausgemessen' wird da eh nichts. Wie soll es wenn der Datentransfer korrekt ist zu diesen fehlerhaften LBA Zuordnungen kommen ? Davon ab, ist das nichts anderes als eine fortlaufende Durchnummerierung der Sektoren, die Umsetzung auf die realen Zuordnungen sollten im Laufwerk selbst vonstatten gehen. (dafür existiert ein LBA-Mode im LW)

Deshalb kann ich das so nicht richtig unter einen Hut bekommen.

sysop
17.08.06, 21:59
habe hier selber ein x20 und kann den fehler nicht nachvollziehen, auch dein bios problem ist für mich nicht reproduzierbar.

OpOs
17.08.06, 23:17
so, badblocks iss fertig, durchlauf mit deaktiviertem schutz, 0 defekte bloecke gefunden...

jetzt muesst ich das eigentlich nochmal neustarten und nochma aber nich mehr heute...

gute nacht

OpOs
18.08.06, 17:03
habe hier selber ein x20 und kann den fehler nicht nachvollziehen, auch dein bios problem ist für mich nicht reproduzierbar.
was hast'n fuer 'ne bios version und welche distri?

OpOs
20.08.06, 07:53
hab jetzt badblocks nochmal mit aktiviertem schutz durchlaufen lassen, und dabei iss was kurioses passiert:

nicht, dass es etwa defekte bloecke gefunden haette, aber meine hd besitzt 9,7 mio bloecke, und als badblocks mit denen fertig war, hat's fleissig weitergescannt: 10 mio, 11 mio, 12 mio... bei 14 mio hab ich dann abgebrochen.
hat jemand dafuer 'ne erklaerung?

danke schonmal!

kshade
20.08.06, 16:23
Sieht die Ausgabe von fdisk -l /dev/hda mit aktiver "recovery area" eigentlich anders aus als mit deaktivierter?

OpOs
20.08.06, 17:45
hmm, guter hinweis... ja
wenn die protection aktiviert iss hab ich 193.016 zylinder und deaktiviert 193.821, dem entsprechend 99,6 GB bzw 100,0 GB...

wenn die (nicht mehr vorhandene) recovery area am ende liegen sollte, dann kollidiert das natuerlich mit meiner swap-partition. bis jetzt dachte ich, der mbr ist einfach schreibgeschuetzt, um die partition zu erhalten, aber das bios scheint 'nen ganzen teil der festplatte zu verbergen. darauf hab ich noch gar nicht geachtet...

also bleibt mir wohl nur die moeglichkeit, meine swap-partition zu verkleinern und mich um den rest der platte nich zu kuemmern...

kshade
20.08.06, 18:04
Hm, könntest du das Feature nicht abschalten und die Swap-Partition über den gesamten freien Bereich neu anlegen?

OpOs
20.08.06, 18:15
naja, das meinte ich doch... im moment erstreckt sich meine swap bis in den geschuetzten bereich hinein, und ich nehme an, da kommen die zugriffsprobleme her.
ich kann also nur den swap bereich verkleinern, so dass er im letzten ungeschuetzten zylinder aufhoert. und dann hab ich ein paar hundert mb auf der platte verschwendet.
da kann ich ja dann geheimdienstberichte und beweisfotos verstecken...

Lindiot
20.08.06, 18:27
OpOs
wenn die (nicht mehr vorhandene) recovery area am ende liegen sollte, dann kollidiert das natuerlich mit meiner swap-partition. bis jetzt dachte ich, der mbr ist einfach schreibgeschuetzt, um die partition zu erhalten, aber das bios scheint 'nen ganzen teil der festplatte zu verbergen. darauf hab ich noch gar nicht geachtet...

http://www.linuxforen.de/forums/showthread.php?s=&p=1411701#post1411701

es ist fraglich ob du die überhaupt deaktivieren kannst mit deinen Mitteln, ich vermute fast nein.

kshade
20.08.06, 19:12
Vielleicht hilft dir ja das ("http://www.p35-forum.de/board/thread.php?threadid=2073&sid=), sieht so aus als müßtest du zum Deaktivieren dieser Funktion eine Windows-Software benutzen.