Bug 9305

Created attachment 8061 [details]
xorg.conf

Created attachment 8062 [details]
Xorg.0.log

Output from the kernel crash is useful - please attach it.

Created attachment 8063 [details]
/var/log/messages

Here's the messages file.  Every single boot is the result of 
this shutdown crash.

You've not yet shown there is a kernel crash.

Please upload what you think is the kernel crash data, as there's nothing in
that last log either.

re: showing a kernel crash

First, thanks very much for having a look at this.

But wrt the kernel crash, the evidence is the console freezes (no response to
special keys), the network freezes, and there are no further console messages
output to syslog, messages, etc.  I'm not sure what further evidence you 
would find helpful.  I am quite happy to run any test you think might 
help, including compiling and running the whole of X if need be.  
The beautiful little laptop is just sitting there without X at this 
point.

Given there's nothing useful yet to even know what's caused the crash. I'd
suggest setting up a serial console and taking a closer look at the logfiles,
and what the kernel has done after the Xserver closes.

The last entries in the /var/log/messages file before the hang are always:

Dec 12 09:57:31 knuth kernel: [drm] Initialized drm 1.0.1 20051102
Dec 12 09:57:31 knuth kernel: ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16
(level, low) -> IRQ 21
Dec 12 09:57:31 knuth kernel: [drm] Initialized i915 1.5.0 20060119 on minor 0
Dec 12 10:02:04 knuth syslogd 1.4.1#18: restart.

Is there a way to make the drm system more verbose?  What part of the
src tree has this code?

I compiled a 2.6.18.1 kernel with every debug switch turned on that seemed
relevant.  Also hangcheck timer enabled.  Here's the relevant entries
in the /var/log/debug file, KDE shutdown at 09:57:31, poweroff and 
reboot at 10:02:04:

Dec 12 09:57:31 knuth kernel: CLASS: registering class device: ID = 'vcs7'
Dec 12 09:57:31 knuth kernel: class_uevent - name = vcs7
Dec 12 09:57:31 knuth kernel: class_device_create_uevent called for vcs7
Dec 12 09:57:31 knuth kernel: CLASS: registering class device: ID = 'vcsa7'
Dec 12 09:57:31 knuth kernel: class_uevent - name = vcsa7
Dec 12 09:57:31 knuth kernel: class_device_create_uevent called for vcsa7
Dec 12 09:57:31 knuth kernel: device class 'drm': registering
Dec 12 09:57:31 knuth kernel: CLASS: registering class device: ID = 'card0'
Dec 12 09:57:31 knuth kernel: class_uevent - name = card0
Dec 12 09:57:31 knuth kernel: class_device_create_uevent called for card0
Dec 12 09:57:42 knuth kernel: APIC error on CPU0: 40(40)
Dec 12 09:57:42 knuth kernel: APIC error on CPU1: 40(40)
Dec 12 09:57:42 knuth kernel: APIC error on CPU1: 40(40)
Dec 12 09:57:42 knuth kernel: APIC error on CPU0: 40(40)
Dec 12 09:57:42 knuth kernel: APIC error on CPU1: 40(40)
Dec 12 09:57:42 knuth kernel: APIC error on CPU0: 40(40)
Dec 12 09:57:50 knuth kernel: APIC error on CPU0: 40(40)
Dec 12 09:57:50 knuth kernel: APIC error on CPU1: 40(40)
Dec 12 10:02:04 knuth kernel: bus pci: add driver HDA Intel
Dec 12 10:02:04 knuth kernel: APIC error on CPU1: 40(40)
Dec 12 10:02:04 knuth kernel: APIC error on CPU0: 40(40)
Dec 12 10:02:04 knuth kernel: CLASS: registering class device: ID = 'pcmcia_socket0'

Still nothing there. Using the debug flag to drm will make it more verbose, you
can check the wiki on it's usage.

But I really do suggest using a serial console.

Well that was an adventure.  The serial console hangs after startx
prints out the single following line in response to KDE shutdown:

waiting for X server to shut down Synaptics DeviceOff called

If you have any suggestions on what I should be watching from
the serial console I'd be happy to follow them.

Here's gdb attached to X, continuing through the shutdown:

Attaching to program: /usr/bin/X, process 2657                                  
0x00002adbc6196a35 in ?? ()                                                     
(gdb) run                                                                       
The program being debugged has been started already.                            
Start it from the beginning? (y or n) n                                         
Program not restarted.                                                          
(gdb) cont                                                                      
Continuing.                                                                     
                                                                                
Program received signal SIGTERM, Terminated.                                    
0x00002adbc6196a35 in ?? ()                                                     
(gdb)                                                                           
Continuing.                                                                     

The hang occurred right after I hit 'enter' at the last
(gdb) prompt.  Doesn't look too informative to me.  I suppose
I could download the debian sources to X and compile with -g.

So I went off and built and installed debian's Xorg server and the i810
driver with debugging symbols not stripped out.

Doing a bit more snooping, I see that the meat of the server is in the
"Xorg" binary, but all I see from 'ps' when X11 is mostly idle is 'X',
which from the size of it and permissions is just an suid wrapper.
If I make things busy in X11, I see "Xorg" running in 'top', but never
do I see it in 'ps'.  Thus it is problematical to attach gdb to "Xorg".

How do you guys gdb attach to a running "Xorg"?

It's not DRI and it's not the Synaptics touchpad.

Hmm, 
built my first i386 xserver back in what, '94, using tweten's patches, on
FreeBSD?  This was a self contained creature, then.  And now, we've got, in
xorg, a big steaming pile of what?  I downloaded and followed all of the varied
wiki instructions on building a current ("git") Xorg,  and I ended up with a
segfault in xcb/xcblib.

Off now to to live in microserf land, from which I had experienced 6 years of
freedom: thanks very much!  It was only three days of my time lost, trivial, if
you think about it.

The Xorg process should appear in ps just as another other process.

The alternative is to start Xorg within gdb.

I'm sorry you feel that you've wasted time, and back off to pastures revisited.

If you have no more time to look at this, then can you please close the report.

Thanks.

*** This bug has been marked as a duplicate of 9498 ***