Lenny: Immernoch die selben Bugs

[clue]

chr.gogolin hat geschrieben:Viel wichtiger scheint mir das Problem beim Booten mit Luks. Sollte man da nicht mal noch tiefer graben bzw. einen bugreport schreiben?

Sehe ich auch so.

Schon erledigt. Aber ob er hilfreich ist, ist fraglich. Außerdem ist der Fehler schon seit 10 Neustarts nicht aufgetreten. Scheint wohl nur bei einem frisch installierten Lenny aufzutreten. Komisch das!
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514147

Bei den binären Nvidia-Treibern hat man eh keine Chance etwas zu verändern und Nvidia scheint sich auch nicht darum zu kümmern.

Trotzdem wollen die jetzt ein Log (steht bei mir eh nichts drin, wenn's passiert) und eine debugging backtrace von mir:

To make things clear: you have 2 users logged in graphical sessions,
right? So only the first one has DRI support and Compiz I guess (we want
the log of this one then).

Wie mache ich das? Und dann auch nur vom user mit Zugehörigkeit zu "video" bei dem das Problem auftritt?

[habakug]

Hallo!

Ich habe mir gerade deinen Bugreport angesehen. Die Informationen, wie lspci, kernel.log usw., hättest du auch hier geben können. Ich sehe ein eindeutiges Hardwareproblem, dem Rechner gehen schlicht die Interrupts aus. Ich habe es hier mal so zusammengefasst:

Code: Alles auswählen

00:09.1 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 43) (prog-if 10 [OHCI])
	Interrupt: pin B routed to IRQ 5
00:09.2 USB Controller [0c03]: NEC Corporation USB 2.0 [1033:00e0] (rev 04) (prog-if 20 [EHCI])
	Interrupt: pin C routed to IRQ 10
00:0b.0 Multimedia audio controller [0401]: C-Media Electronics Inc CM8738 [13f6:0111] (rev 10)
	Interrupt: pin A routed to IRQ 10
00:0d.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139] (rev 10)
	Interrupt: pin A routed to IRQ 10
00:11.2 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 1b) (prog-if 00 [UHCI])
	Interrupt: pin D routed to IRQ 10
00:11.3 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 1b) (prog-if 00 [UHCI])
	Interrupt: pin D routed to IRQ 10
00:11.4 USB Controller [0c03]: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] (rev 1b) (prog-if 00 [UHCI])
	Interrupt: pin D routed to IRQ 10
00:09.0 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 43) (prog-if 10 [OHCI])
	Interrupt: pin A routed to IRQ 11
00:11.1 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] (rev 06) (prog-if 8a [Master SecP PriP])
	Interrupt: pin A routed to IRQ 11
01:00.0 VGA compatible controller [0300]: nVidia Corporation NV25 [GeForce4 Ti 4200] [10de:0253] (rev a3) (prog-if 00 [VGA controller])
	Interrupt: pin A routed to IRQ 11
00:11.1 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] (rev 06) (prog-if 8a [Master SecP PriP])
	Interrupt: pin A routed to IRQ 11

[    5.708412] ACPI: PCI Interrupt 0000:00:11.3[D] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10
[    5.815460] ACPI: PCI Interrupt 0000:00:11.4[D] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10
[    5.917356] ACPI: PCI Interrupt 0000:00:0d.0[A] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10
[   16.643636] ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10
[   34.830147] ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11

Der IDE-Controller bekommt zum Schluß von ACPI gar keinen IRQ mehr zugewiesen (oder du hast diesen Teil des Logs nicht gepostet). Laut lspci teilen sich die Grafikkarte und IDE einen Interrrupt. Es ist ein Wunder, das es überhaupt halbwegs stabil läuft. Betreibst du in dem Rechner eine USB2.0-Karte (IRQ 10 und 5) ? Du könntest sie mal probeweise entfernen und schauen ob es zu einer anderen Interruptverteilung kommt, die dir ein stabileres System bietet.

Gruß, habakug

[clue]

Betreibst du in dem Rechner eine USB2.0-Karte (IRQ 10 und 5)

Ja, und endlich habe ich eine, die wirklich gut funktioniert. Aber gut, wenn Du meinst, ich sollte mal die IRQ's umverteilen, dann werd ich das mal tun. Sollte aber eigentlich unnötig sein, weil ich sonst keine Probleme habe. Das System läuft, bis auf compiz, recht stabil. Nur xine braucht manchmal mehr cpu als unter Etch und hängt beim Abspielen von *wmv.part Dateien im loop-modus gerne mal. Aber weswegen die IRQs mit compiz und dem Zugehören zur Gruppe "video" Schwierigkeiten machen sollen, will nicht in meinen Kopf rein.

[clue]

Kann mir bitte jemand einen Hinweis geben, wie ich KDM mit gdb laufen lassen kann, so daß die gewünschten Logfiles an die bug-mailing-Liste geschickt werden können. Und wie ich das Problem mit den fehlenden debugging symbols lösen kann

[habakug]

Hallo!

Die Mitglieder der Gruppe "video" dürfen den Videospeicher beschreiben. Das ist z.B. für das Modul "nvidia" erforderlich.
Doch wichtiger erscheint mir diese Stelle in dmesg:

Code: Alles auswählen

[   34.830771] NVRM: loading NVIDIA Linux x86 Kernel Module  96.43.07  Wed Jul  2 12:17:43 PDT 2008
[   34.932137] agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
[   34.932168] agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
[   34.932228] agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode

Dein Chipset ist nämlich nicht gerade das zuverlässigste. Unter Via Chipsets findet man folgenden Hinweis:

KT266 contains a hardware bug which cause system instability when using the AGP slot at the specified max capacity of 4x.

Weihnachten war ja gerade, sonst würde ich sagen nach all den Jahren vielleicht mal was neueres wünschen.

Gruß, habakug

[paniccinap]

Das hier beschriebene Problem kommt mir bekannt vor, und zwar unter Lenny, mit GDM/Gnome und intel-onboard-Grafik. Beim Ab- und Wiederanmelden kackt der X-Server ab. Manchmal passiert das gleich beim Hochfahren. Manchmal lässt sich der X mit Strg-alt-backspace neu starten, manchmal nicht. Die Logs zeigen aber keine Fehler, höchstens Warnungen. Mit vesa ist das Ganze auch nicht mehr gelaufen. Dafür werden irgendwelche 3D-Spiränzchen geladen ... vielleicht sind 256mb mittlerweile einfach zu wenig? kene Ahnung...

[clue]

Dein Chipset ist nämlich nicht gerade das zuverlässigste. Unter Via Chipsets findet man folgenden Hinweis:

KT266 contains a hardware bug which cause system instability when using the AGP slot at the specified max capacity of 4x.

Danke, habakug! Schade, daß es so ist. Aber: Ich hatte eigentlich nie Probleme damit, weder unter Etch, noch unter XP. Zugegeben, ich bin mir nicht 100% sicher, ob mein user der Video-Gruppe angehört hat, als ich unter Etch mit compiz rumgespielt habe.

Kann mir denn niemand sagen, wie ich das ganze mit gdb laufen lassen kann. Die wollen ein Log von mir mit backtrace und zwar von dem user, bei dem das Problem auftritt. Ich habe mal gdb xine versucht (weil es bei mir gerne mal abschmiert), aber irgendwie startet gdb xine nicht.

Wie mache ich denn das nun? Die Leute warten auf meine logs.

[clue]

Gute Nachrichten: Während ich gerade dabei war, die Kiste neuzustarten, weil sie beim Versuch ein gutes backtrace für mein compiz_mit_video_Gruppe_Problem zu erstellen, abgeschmiert war, blieb sie während des Neustarts wiedermal stehen. Diesmal war ich nicht faul, und habe alles vom Bildschirm abgeschrieben und dem bug-report zugefügt:

It happened again. This time I was able to write the last screen messages down:

-------------
starting boot logger: bootlogd
setting system clock
activating swap (I don't have any swap)
checking root file system ... fsck ...
debian_root : clean ... (check in 3 mounts)
done.
-------------

After that, system gets stuck. Then I pressed alt+print+f to kill memory eating process which brought this:

---------
[826,79] swap cache: add 0, delete 0, find 0/0
free swap= 0kb
total=0kb
196592 pages of ram
0 pages of highmem
[...]
[826,79] out of memory: kill process 960 (rc) score 70 or a child
[826,79] killed process 1749 (sh)
/etc/init.d/rc : line 207: 1749 killed $debug $sh ”$script” $action
setting the system clock
cleaning up ifupdown ....
loading kernel modules 828,86 loop: module loaded
done
starting early crypto disks ... privat: insecure mode for /etc/hda6key
privat (starting)
---------

Now it hangs again, so I wrote everything to paper and pressed alt+print+F again, wich led to:

---------
[1366,24] SysRq: Manual OOM execution
----------

It still hangs, so I repeatet the above (alt+print+F) which always led to the same message from above. (SysRq: Manual OOM execution)
Then I hit alt+print+l which brought up this:

----------
SysRq: Show backtrace of all active CPU's
CPU 0:
PID: 0, com: swapper Not tainted (2.6.26-1-686 #1)
EIP: 0060: [<f082429a>] EFLAGS: 00000206 CPU: 0
EIP is at acpi_idle_enter_simple+0195/0x203 [processor]
EAX: c03bf42c EBX: 00003b39 ECX: 00002c2c EDX: 01251000
ESI: 00000000 EDI: 00c7677a EBP: 00c72c41 ESP: c0379fc0
DS: 007b ES: 007b FS: 00df GS: 0000 SS: 006f
CR0: 8005003b CR2: 0804dd70 CR3: 28459000 CR4: 000006d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
[<c024990d>] ? cpuidle_idle_call + 0x5b/0x96
[<c02498b2>] ? cpuidle_idle_call + 0x0/0x86
[<c01025ce>] ? cpu_idle_ + 0xab/0xcb
==================
-----------------
That was all. When hitting again alt+print+l it shows always very similar results, which differ only in some of the numbers. When I hit alt+print+c it said only: Crashdump triggered. But nothing happened.

I have made a complete backup of my /var/log folder – right after the crash. If you want it, I could send it to you.

I hope this helps you to find the bug.

[clue]

Die Antwort der Kernel-maintainer kann ich nicht richtig verstehen:

tags 514147 moreinfo
thanks

On Wed, Feb 04, 2009 at 07:25:02PM +0100, clue wrote:
> ** Tainted: P (1)

We can't and won't support binary-only crap.

Please reproduce without.

Bastian

Wie meint er das mit dem binär-Kram? Der Kernel hat etwas als tainted gemeldet. Aber das ist doch kein Grund für den Kernel, einfach mal ab und zu beim starten stehen zu bleiben. Wie kann ich denn rausfinden, was sich als tainted meldet, also welches Modul/Treiber für diese Meldung verantwortlich ist?

Und dann sagt ein anderer:

Assuming you can reproduce without, it'd be helpful to try and capture
backtraces of the running processes. Alt+SysRQ+t will do this. If it
works, it will produce a lot of output, so I'd suggest hooking up a
serial console if you have one.

Würde ich sehr gerne, aber nur wenn mir jemand sagt, wie.

[Danielx]

Wie meint er das mit dem binär-Kram?

Ein "binäres" Kernel-Modul liegt nur in schon kompilierter Form vor, den Quellcode kennt nur der Hersteller, der Treiber ist unfrei.

Der Kernel hat etwas als tainted gemeldet.

Er wurde von einem nicht freien Modul verunreinigt.

Aber das ist doch kein Grund für den Kernel, einfach mal ab und zu beim starten stehen zu bleiben.

Nein, aber das unfreie Kernel-Modul könnte evtl. das Problem verursachen.

Wie kann ich denn rausfinden, was sich als tainted meldet, also welches Modul/Treiber für diese Meldung verantwortlich ist?

Das unfreie Nvidia-Modul verursacht diese Meldung, steht ja auch in dem von dir verfassten Bug-Report:

Code: Alles auswählen

[   34.567250] nvidia: module license 'NVIDIA' taints kernel.

Man ist nur bereit bzw. überhaupt in der Lage dir weiterzuhelfen, wenn du das Problem auch ohne den unfreien Nvidia-Treiber reproduzieren kannst!
Vorher brauchst du die gar nicht erst wieder mit deinem unfreien Mist/Schrott (eben "crap") "belästigen" , denn wenn der Fehler beim unfreien Nvidia-Modul liegt, kann dir (außer Nvidia) leider niemand weiterhelfen.

Und dann sagt ein anderer:

Assuming you can reproduce without, it'd be helpful to try and capture
backtraces of the running processes. Alt+SysRQ+t will do this. If it
works, it will produce a lot of output, so I'd suggest hooking up a
serial console if you have one.

Würde ich sehr gerne, aber nur wenn mir jemand sagt, wie.

Er möchte die Backtraces der laufenden Prozesse haben, da diese Ausgabe aber extrem lang sein kann und somit das Abtippen kaum möglich ist, empfiehlt er den Einsatz einer seriellen Konsole.
Bei einer serielle Konsole verbindest du einen anderen Rechner mit deinem Rechner über ein serielles Kabel und kannst so auf dem anderen Rechner diese Ausgaben abrufen bzw. anzeigen lassen und auch kopieren:
http://www.zdnet.de/anwendungsentwicklu ... 8453-1.htm
http://www.rrze.uni-erlangen.de/dienste ... sole.shtml

Also erstmal den unfreien Nvidia-Treiber von deinem Rechner runterwerfen bzw. dafür sorgen, dass dieser nicht mehr geladen wird und wenn dann das Problem bei dir weiterhin auftreten sollte, wird bzw. kann man bei dem Problem evtl. weiterhelfen.

Gruß,
Daniel

[clue]

Danke vielmals Danielx und auch Ihr anderen! Ohne Euch würde ich feststecken. Nochmal kurz 'ne Frage: Wird schon so früh das Nvidia-Modul geladen? Immerhin wäre das ja sofort nach dem mounten der root Partition. Und das halte ich für äußerst unwahrscheinlich. Ich dachte immer, es würde erst viel später geladen. Bei mir wurden nvidia-glx-legacy und nvidia-kernel erst in runlevel 2 standardmäßig eingetragen. Also frage ich mich, wie es schon sofort nach Luks-Passworteingabe für Ärger sorgen kann. Könnte es nicht eher ein anderes binär Modul sein?

[Danielx]

Ich dachte immer, es würde erst viel später geladen.

Hm, ja eigentlich schon.
Also kurz nach dem Mounten der root-Partition:

Code: Alles auswählen

[   11.232788] EXT3-fs: mounted filesystem with ordered data mode.

Kommt ja auch schon der Eintrag für diesen VIA-Chip:

Code: Alles auswählen

[   14.446714] Linux agpgart interface v0.103
[   14.464457] agpgart: Detected VIA KT266/KY266x/KT333 chipset
[   14.472430] agpgart: AGP aperture is 128M @ 0xd0000000

Der soll ja laut habakug problematisch sein, evtl. hängt es damit zusammen.

Ich würde das nvidia-Modul aber dennoch mal deaktivieren und probieren das Problem zu reproduzieren.
Dann sind die Bug-Bearbeiter auch besser gelaunt, wenn da kein unfreies Modul beteiligt ist.

Könnte es nicht eher ein anderes binär Modul sein?

Ich kann kein anderes "binäres" Modul sehen, welches sollte das sein?

Gruß,
Daniel

[clue]

1.

Der soll ja laut habakug problematisch sein, evtl. hängt es damit zusammen.

Naja ... aber warum sollte mein Board auf einmal unter Lenny Schwierigkeiten machen? Es lief doch seit über 8 Jahren problemlos sowohl unter Suse 7.1, RedHat 9, Fedora 1-4 und auch Etch & Ubuntu 8.04.

2.
Zu meinem Compiz + Video-Gruppen Problem:

Ich erhalte folgende Fehlermeldungen wenn ich

Code: Alles auswählen

compiz -- replace &

ausführe:

NVIDIA: could not open the device file /dev/nvidiactl (Permission denied).
NVIDIA: Direct rendering failed; attempting indirect rendering.
/usr/bin/compiz.real (core) - Error: Plugin 'text' not loaded.

/usr/bin/compiz.real (ring) - Warn: No compatible text plugin found.

Scheinbar bin ich nicht der Einzige mit diesem Problem: http://www.nvnews.net/vbulletin/showthread.php?t=89965 Stellt sich nur noch die Frage, welche Lösung für Lenny ratsam wäre.

[clue]

Hihi ... es ist schon wieder passiert: Ich habe gestern Abend den Rechner mit

Code: Alles auswählen

shutdown -Fh now

ausgeschaltet. Heute beim Hochfahren führte er den Fs-Check wie geplant durch. Er zeigte 100% an, und daß alles clean sei. Aber danach passierte gar nichts mehr.

Und jetzt kommts: Ein zwangsläufiger Reset per Schalter und erneutes Hochfahren lies nochmals den selben filesystemscheck durchlaufen wie zuvor. Das System blieb also so frühzeitig stehen, daß noch nicht einmal festgehalten werden konnte, daß dieser check bereits erfolgreich gelaufen war.

Ich glaube also nicht, daß LUKS daran beteiligt ist, weil der fs-check ja nur bei bereits entschlüsseltem Dateisystem laufen kann.

Irgendwelche Ideen?

[Danielx]

Irgendwelche Ideen?

Möchtest du dein System wieder Hochfahren können oder wie soll ich diese Frage verstehen?

Die Option -F legt jedenfalls die Datei /forcefsck an, welche dafür sorgt, dass der Check durchgeführt wird.
Du kannst diese Datei löschen oder dem Kernel die Option fastboot übergeben, dann sollte der Check übersprungen werden.
Dein Dateisystem, ist aber dann immer noch nicht wieder ok, falls es denn kaputt sein sollte.

Gruß,
Daniel

[clue]

Möchtest du dein System wieder Hochfahren können oder wie soll ich diese Frage verstehen?

Oh, entschuldige! Ich hatte wohl meine Frage nicht richtig forum-liert ! Nein, das System fuhr beim zweiten Mal und dem zweiten Check wieder sauber hoch. Was ich wissen wollte, war, ob diese Informationen irgendwie zur Eingrenzung des Problems beitragen können. Ich möchte nicht den Bugtracking-Leute unnötig Arbeit machen. Und weil ich eben nicht so versiert bin wie Ihr, wollte ich vorher Eure Meinung einholen (was natürlich Euch Arbeit macht !).

[clue]

[Teilweise gelöst]

Zumindest dieser Fehler

NVIDIA: could not open the device file /dev/nvidiactl (Permission denied).
NVIDIA: Direct rendering failed; attempting indirect rendering.

lässt sich beheben:

1. In /etc/modprobe.d die Datei "nvidia" anlegen
2. Die Zeile

Code: Alles auswählen

options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=44 NVreg_DeviceFileMode=0666 

einfügen
3. Beim nächsten Neustart sollte alles o.k. sein.

Der Bug mit dem stehenbleibenden Kernel scheint seit dem Update nicht mehr vorzukommen. Zumindest bis jetzt noch nicht. Daher bin ich vorsichtig optimistisch.

Das Problem mit Compiz und der Zugehörigkeit zur Video-Gruppe scheint tatsächlich ein Nvidia-Treiber Problem zu sein, da es sowohl unter Etch als auch unter Lenny auftritt. Zwar wurde eine neue Treiber-Version veröffentlicht, aber zumindest unter Etch hat sie nichts gebracht. Ich müsste sie aber noch bei Gelegenheit unter Lenny testen, da Nvidia behauptet, der Treiber würde nun besser mit den neueren Kernel & Xorg Versionen zusammenarbeiten. Mal schauen.

[Lumines]

[... ] der Treiber würde nun besser mit den neueren Kernel & Xorg Versionen zusammenarbeiten.

bezieht sich das nicht eher auf 7.4?

[clue]

bezieht sich das nicht eher auf 7.4?

Weiß nicht. Aber ich meine gelesen zu haben, auch 7.3 sei mit eingeschlossen. Egal, auf jeden Fall haben die Nvidia-Leute eine Menge Bugs mit der neuen Version behoben. Alle male ein update wert.