UDMA Fehler? Bootet nicht mehr (SUSE 10.3)

[amöbe]

Hallo!

Ich habe gerade mein kernel auf 2.6.22.19 geupdated und jetzt hängt er sich jedes mal, wenn ich boote mit:

SCSI subsystem initialized
libata version 3.00 loaded.
pata_amd 0000:00:04.0: version 0.3.8
PCI: Setting latency timer of device 0000:00:04.0 to 64
scsi0 : pata_amd
scsi1 : pata_amd
ata1: PATA max UDMA/133 cmd 0x00000000000101f0 ctl 0x00000000000103f6 bmdma 0x000000000001f000 irq 14
ata2: PATA max UDMA/133 cmd 0x0000000000010170 ctl 0x0000000000010376 bmdma 0x000000000001f008 irq 15
[also hier hängt er dann, das geht dann nur im failsave boot: ]
ata1.00: ATAPI: _NEC DVD_RW ND-3500AG, 2.88, max UDMA/33
ata1.00: configured for UDMA/33
ata2: port disabled. ignoring.
scsi 0:0:0:0: CD-ROM _NEC DVD_RW ND-3500AG 2.88 PQ: 0 ANSI: 5
sata_nv 0000:00:05.0: version 3.4
PCI: Setting latency timer of device 0000:00:05.0 to 64
scsi2 : sata_nv
scsi3 : sata_nv
ata3: SATA max UDMA/133 cmd 0x000000000001d400 ctl 0x000000000001d802 bmdma 0x000000000001e400 irq 15
ata4: SATA max UDMA/133 cmd 0x000000000001dc00 ctl 0x000000000001e002 bmdma 0x000000000001e408 irq 15
ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3.00: HPA unlocked: 976771055 -> 976773168, native 976773168
ata3.00: ATA-7: WDC WD5000AAJS-00TKA0, 12.01C01, max UDMA/133

Also ich weiß jetzt nicht so recht, wie ich das deuten soll?
Irgendwie kommt das immer direkt nachdem er das bootlog startet - scheint also was mit der Festplatte zu sein. Ist eine WesternDigital 500GB 7200U WD5000AAJS-0 12.0 (also SATA, nicht PATA?)
Und UDMA ist ja auch sowas in die Richtung.

Naja, jetzt wenn ich in Grub auf failsafe gehe, dann bootet es mehr oder weniger normal. Ist wohl irgendetwas falsch eingestellt, oder?

Ich kenne mich jetzt nicht so mit der Konfiguration von solchen Sachen aus, deswegen wäre ich euch sehr verbunden, wenn ihr mit da etwas helfen könntet...

Erst hatte ich gedacht, es leigt möglicherweise auch am CD-Laufwerk. Denn in /var/log/dmesg steht nach dem failsave boot direkt nach den 2 Zeilen, wo es hängen bleibt das CD-Laufwerk. Doch selbst wen ich das CD-Laufwerk ausbaue, bleibt es immer noch an der selben Stelle hängen, auch wenn garnichts mit PATA angeschlossen ist.

Im übrigen klappt alles icht nur im failsave modus, sondern auch mit "acpi=off", was natürlich sehr schlecht ist, da der Computer sich dann nicht ausschalten kann und Standby etc. geht auch nicht.

also liegt das der Hase begraben? Ähm... was ist da los!?

Bevor jemand fragt:

uname -a
Linux dhcppc5 2.6.22.19-0.1-default #1 SMP 2008-10-14 22:17:43 +0200 x86_64 x86_64 x86_64 GNU/Linux

 

[Gast1]

Naja, jetzt wenn ich in Grub auf failsafe gehe, dann bootet es mehr oder weniger normal. Ist wohl irgendetwas falsch eingestellt, oder?

Dann zeig uns doch mal die beiden Kernelzeilen der entsprechenden Booteinträge aus der /boot/grub/menu.lst.

Im übrigen klappt alles icht nur im failsave modus, sondern auch mit "acpi=off", was natürlich sehr schlecht ist, da der Computer sich dann nicht ausschalten kann und Standby etc. geht auch nicht.

Falls sich beim Update kein Fehler beim automatischen Schreiben der menu.lst eingeschlichen hat, dann könnte das auch der "ganz normale ACPI-Bug" sein, wäre nicht das erste Mal, daß es nach einem Kernelupdate ACPI-Probleme gibt.

Ein

rpm -q --changelog kernel-default | less

zeigt Dir die Veränderungen an, sollte da irgendwas an ACPI gedreht worden sein, dann steht es da drin.

Greetz,

RM

 

[amöbe]

Danke schonmal!

Also:
menu.lst:

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 10.3 - 2.6.22.19-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.19-0.1-default root=/dev/disk/by-id/scsi-SATA_WDC_WD5000AAJS-_WD-WCAPW5418686-part2 resume=/dev/sda1 splash=silent showopts
initrd /boot/initrd-2.6.22.19-0.1-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 10.3 - 2.6.22.19-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.22.19-0.1-default root=/dev/disk/by-id/scsi-SATA_WDC_WD5000AAJS-_WD-WCAPW5418686-part2 showopts ide=nodma apm=off acpi=off noresume edd=off 3
initrd /boot/initrd-2.6.22.19-0.1-default

Im changelog ist der oberste Eintrag von 15.10. also zu lange her, was mich aber ein bisschen wundert, schleißlich hatte ich gestern noch 2.6.22.12.~
d.h. wie lange muss ich da zurückgehen?

Ich hätte da:

* Mi Okt 15 2008 - **********
- patches.drivers/cciss-panic-in-blk_rq_map_sg: Delete.
- patches.fixes/acpica_sizeof.patch: Delete.


* Mo Aug 04 2008 - **********
- patches.fixes/acpi_make_processor_not_present_debug.patch: Do
not print an error for not available, hot-pluggable processors
(bnc#409513).


* Di Jun 24 2008 - **********
- patches.fixes/acpi_evaluate_null_pointer_check.patch: ACPICA:
Warn if packages with invalid references are evaluated
(bnc #350017).
- patches.fixes/acpi_mem_corruption.patch: ACPI: fix boot oops
regression in thermal (bnc #350017).

Bisschen blöd, mit dem alten kernel hat eigentlich acpi immer geklappt...
... also zu dem Booteintrag acpi=off dazu und dann warten, bis es nach einem kernelupdate wieder klappt?

 

[Gast1]

Also:
menu.lst:

OK, keine offensichtlichen Fehler, das ist es also nicht.

Man könnte es mit "acpi=force" probieren, mit ungewissem Ausgaben.

Zunächst nur beim Booten direkt eintippen, wenn es was bringt, dann in fest in die menu.lst eintragen.

Im changelog ist der oberste Eintrag von 15.10. also zu lange her, was mich aber ein bisschen wundert, schleißlich hatte ich gestern noch 2.6.22.12.~
d.h. wie lange muss ich da zurückgehen?

Dann ist Dein letztes Kernelupdate davor aber schon eine Ewigkeit her, es gab seither 2.6.22.13, 2.6.22.16-0.1, 2.6.22.16-0.2, 2.6.22.17-0.1 und 2.6.22.18-0.2.

... also zu dem Booteintrag acpi=off dazu und dann warten, bis es nach einem kernelupdate wieder klappt?

Siehe oben, falls das acpi=force nichts bringt, dann ja.

Ein Bugreport bei bugzilla.novell.com wäre auch eine gute Idee.

 

[amöbe]

Man könnte es mit "acpi=force" probieren

Endet leider beim selben Fehler.

Dann ist Dein letztes Kernelupdate davor aber schon eine Ewigkeit her

Jupp, weil ich nicht wollte, dass sich der Grafiktreiber wieder verabschiedet... scheint aber zu klappen jetzt.
Allerdings hilft es anscheinend, wenn man paar Tage, nachdem das Update raus gekommen ist, hier rein schaut: http://forums.opensuse.org/install-boot-login/. Da hab ich jetzt zu meinem Problem nichts gefunden, aber da wird sowas oft gepostet.
Vielleicht poste ich diesen Thread mit dem Problem erstmal mal da, bevor ich einen Bugreport mache?

 

[Gast1]

Nein, denn wenn es wirklich ein Bug sein sollte, dann ist der Bugzilla die einzig richtige Anlaufstelle, weil dort auch die Paketmaintainer den Report mitbekommen.

 

[amöbe]

OK: https://bugzilla.novell.com/show_bug.cgi?id=440886