Bug#369167: DRI probably broken: where to reportbug
On Tue, May 30, 2006 at 08:32:32AM +0200, Michel Dänzer wrote:
> On Tue, 2006-05-30 at 01:57 +0200, Wolfgang Pfeiffer wrote:
> > On Mon, May 29, 2006 at 09:53:39AM +0200, Michel Dänzer wrote:
> > > Does any of the following make a difference?
> > >
> > > * Commenting out Option "AGPMode", "EnablePageFlip" or
> > > "BackingStore".
> > > * Not loading the "ddc", "int10", "vbe" and "v4l" modules in
> > > Section "Module".
> > After commenting *everything* you mentioned above and enabling the
> > DRI load, a '/etc/init.d/kdm start' crashes the system:
> Hmm, then it's not likely a configuration issue. Would be great if you
> could try with the DRM from DRI CVS, see
> > BTW: Is it possible to ssh into such a crashed system/machine and shut
> > it down cleanly instead of stupidly pressing the power button I was
> > doing so far after these crashes?
> Depends how hard the crash is. Would be interesting to know at any rate.
> [ ... ]
It's possible :)
But first this: I learned SSH the last days (I really didn't know
anything about it before, except that it *somehow* might provide a way
to access one computer with another one), that's why I'm a bit late to
continue this thread. So thanks for being patient until now.
Most of the following from my lousy memory:
I provoked one of these ugly crashes on the alu-book, where I
re-enabled dri via xorg.conf again, without having installed the new
DRM you, Michel, were recommending:
I logged into the crashed system on the alu-book from an older Ti-IV
Powerbook via ssh (I think I did before the system crashed), su-ed to
root after some time , watched the processes via top, and saw xorg
taking around 99% CPU at the time of the crash. I could not even stop
xorg via a 'kill -s 9 <xorg-PID>'
didn't help either.
At another instance of a crash like that, on the alu-book screen after
some time some sort of garbled non-console screen was showing up. I would
not even call it a garbled KDE login screen .. Difficult to define ...
At the time of the crash:
# tail -f /var/log/kern.log
Jun 4 15:27:29 debby1-6 kernel: [ 329.913335] radeonfb: Idle Timeout !
Jun 4 15:27:29 debby1-6 kernel: [ 332.322620] radeonfb: Idle Timeout !
Jun 4 15:27:34 debby1-6 kernel: [ 334.863572] radeonfb: Idle Timeout !
Jun 4 15:27:34 debby1-6 kernel: [ 337.273485] radeonfb: Idle Timeout !
Jun 4 15:27:39 debby1-6 kernel: [ 339.784720] radeonfb: Idle Timeout !
Jun 4 15:27:39 debby1-6 kernel: [ 342.194073] radeonfb: Idle Timeout !
Jun 4 15:27:44 debby1-6 kernel: [ 344.717566] radeonfb: Idle Timeout !
Jun 4 15:27:44 debby1-6 kernel: [ 347.128199] radeonfb: Idle Timeout !
Jun 4 15:27:49 debby1-6 kernel: [ 349.648255] radeonfb: Idle Timeout !
Jun 4 15:27:49 debby1-6 kernel: [ 352.057512] radeonfb: Idle Timeout !
# ps ax | grep kdm
2986 ? Ss 0:00 /usr/bin/kdm
3058 pts/0 S+ 0:00 grep kdm
I did a 'kill -s 9 2986', after that kdm was gone, but 'top' still
showed 'Xorg' swallowing ~99% CPU.
'/etc/init.d/x11-common status' gave me zero output, ditto a
Perhaps not being so important, but anyway:
Could someone tell me what exactly 'top' means by 'Xorg'? Because if
there are other, so far unknown instances of the xorg-server I should
know about, I'd like to try close them down instead of shutting down
the whole system.
As one might guess from the latter, this here worked :) :
# shutdown -r now
Broadcast message from root@debby1-6 (pts/0) (Sun Jun 4 14:21:56 2006):
The system is going down for reboot NOW!
[ ... ]
... and the crashed machine was rebooted .. :)
Michel: Do you want to do me more tests on this alu-book around the
time it crashes, before I try to install the DRM you suggested to try?
I'll wait until tomorrow (Monday) afternoon with the DRM
install/tests. And no problem if you want some more time than until
tomorrow: After all it's week-end .. Just let me know in time, please
Thanks in anticipation
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
Key ID: E3037113