On Sat, Jul 03, 2004 at 10:04:09AM +0200, Stefan Müller wrote:
Hallo Martin,
Ja, dann werd ich mich heute wohl mal ans Basteln machen.
Meinst Du denn tatsächlich, dass sich Deine Systemabstürze dem Kernel zuordnen lassen?
Also ich kriege nach dem Resume ab und zu Abstürze. Es steht was von Kernel-panic da und irgendwas mit netzwerktreiber bn.c oder sowas. Der Fehler könnte behoben sein.
hm, bn.c gibts in den Kernelquellen nicht. Wenn du die kernel-panic genau (inklusive stackdump) abschreiben kannst, oder zumindest genau die Funktion nennen kannst, dann hilft das beim Fixen des Bugs ungemein, denn dann können die Experten genau feststellen, woran es lag.
Abgestürzte resums sind besonders nervig, weil `noresume' die Swap-Partition nicht richtig aufräumt. Nach dem Neustart, bildet sich
Das sollte nicht sein. Entweder sie wird nicht aufgeräumt (bug), dann hast du aber gar keinen Swap, oder sie wird mittels "mkswap" neu formatiert.
das System ein, sein Speicher sei voll (512 MB und nur KDE gestartet) und hat auch noch was im Swap und swapt wie blöde.
Du hast nicht zufällig mehr als eine Swap-Partition? Weil die Swap-Partition ge-'mkswap'-t wird, somit "wie neu" ist (die ist nach einem vermurksten resume nämlich "richtig" kaputt, sprich sie kann nicht eingebunden werden, weil sie keine gültige Signatur hat. Darum ist folgender Code in /etc/init.d/boot.swap: get_swap_id() { local line; fdisk -l | while read line; do case "$line" in /*Linux\ swap) echo "${line%% *}" esac done } check_swap_sig () { local part="$(get_swap_id)" local where what type rest p c while read where what type rest ; do test "$type" = "swap" || continue c=continue for p in $part ; do test "$p" = "$where" && c=true done $c case "$(dd if=$where bs=1 count=6 skip=4086 2>/dev/null)" in S1SUSP|S2SUSP) mkswap $where esac done < /etc/fstab } der das wieder fixed. Insofern kann ich mir das nicht ganz erklären.
Nach einem abgestürzten resume muß ich also zweimal booten.
Außerdem scheint das System beim Throtling abzustürzen. Es versucht auf die Platte zuzugreifen und bleibt dann mit leuchtender Plattendiode stehen. Ob das nun am Throttling/nicht erkannten Prozessor liegt, weiß ich aber nicht.
Lass doch mal das Throttling aus (ist bei einem Dothan eh nicht nötig, der hat ja richtige Stromsparfunktionen). Dann siehst du, ob es am Throttling liegt.
Insgesamt würde ich das als ein nicht funktionierendes Betriebssystem bezeichnen und Suse sollte der Ehre halber da mal was nachschieben (auch ohne 50 € für die nächste Version).
Nun ja, wenn das alles ist, was nicht funktioniert: suspend ist ganz klar als experimentell und nicht unterstützt markiert, und wenn es einen fix für den Throttling-Bug (so es denn einer ist) gibt, dann wird der auch früher oder später in einen YOU-Kernel einfliessen.
Der Kernel findet nur 64K Cache, ob das für die Performance relevant ist, weiß ich nicht, eigentlich müßte sich ja der Prozessor von selbst um seinen Cach kümmern, oder spielt das irgendwo im Linux-Code eine Rolle?
Das weiss ich nicht, ich vermute aber, daß das dem Kernel relativ egal sein wird. Insgesamt riecht mir das ganze ein wenig nach einem Vermurksten BIOS, aber das ist natürlich immer schwer zu beweisen. Gruss, Stefan -- Stefan Seyfried