Bug 9305 - i810 945GM shutdown crash
Summary: i810 945GM shutdown crash
Status: RESOLVED DUPLICATE of bug 9498
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: 7.1 (2006.05)
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Alan Hourihane
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-11 13:56 UTC by Russell L. Carter
Modified: 2007-01-09 02:38 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
xorg.conf (3.15 KB, text/plain)
2006-12-11 13:57 UTC, Russell L. Carter
no flags Details
Xorg.0.log (66.79 KB, text/plain)
2006-12-11 13:58 UTC, Russell L. Carter
no flags Details
/var/log/messages (569.73 KB, text/plain)
2006-12-11 15:21 UTC, Russell L. Carter
no flags Details

Description Russell L. Carter 2006-12-11 13:56:14 UTC
have a Toshiba U205-S5044 debian amd64-testing
laptop with an i810 945GM that hard crashes the
kernel when the xserver is shut down.  Both the
original installed i810 driver version 1.7.2 and
version 1.7.3 that I built myself exhibit the same
behavior.  (I compiled the 1.7.3 driver against
xorg-dev 7.1 installed by debian, except libdrm,
which is version 2.2).  The kernel is 2.6.18.

Before attempting to shutdown by logging out
of KDE or FVWM, everything seems to work fine.
When shutting down, the icons disappear and the
hang occurs when the screen is blank.  Nothing shows
up in /var/log/messages.  It looks like a hard hang,
as network is hosed simultaneously.

There's nothing that looks like an error in
/var/log/Xorg.0.log nor the output from startx.

~/.xsession-errors has this at the tail:

WARNING: deleting stale lockfile /root/.kde/share/config/kdeglobals.lock
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  12
  Minor opcode:  0
  Resource id:  0x1a00007
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  8
  Minor opcode:  0
  Resource id:  0x1a00007
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  12
  Minor opcode:  0
  Resource id:  0x1c00009
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  8
  Minor opcode:  0
  Resource id:  0x1c00009
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  12
  Minor opcode:  0
  Resource id:  0x1c00009
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  8
  Minor opcode:  0
  Resource id:  0x1c00009

There's nothing of note in /var/log/messages
Comment 1 Russell L. Carter 2006-12-11 13:57:39 UTC
Created attachment 8061 [details]
xorg.conf
Comment 2 Russell L. Carter 2006-12-11 13:58:00 UTC
Created attachment 8062 [details]
Xorg.0.log
Comment 3 Alan Hourihane 2006-12-11 14:13:17 UTC
Output from the kernel crash is useful - please attach it.
Comment 4 Russell L. Carter 2006-12-11 15:21:03 UTC
Created attachment 8063 [details]
/var/log/messages

Here's the messages file.  Every single boot is the result of 
this shutdown crash.
Comment 5 Alan Hourihane 2006-12-12 01:07:11 UTC
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.
Comment 6 Russell L. Carter 2006-12-12 06:36:56 UTC
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.
Comment 7 Alan Hourihane 2006-12-12 08:09:45 UTC
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.
Comment 8 Russell L. Carter 2006-12-12 09:21:24 UTC
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'
Comment 9 Alan Hourihane 2006-12-12 09:34:35 UTC
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.
Comment 10 Russell L. Carter 2006-12-12 12:09:25 UTC
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.
Comment 11 Russell L. Carter 2006-12-12 12:31:50 UTC
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.
Comment 12 Russell L. Carter 2006-12-12 16:53:23 UTC
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"?
Comment 13 Russell L. Carter 2006-12-13 13:48:51 UTC
It's not DRI and it's not the Synaptics touchpad.
Comment 14 Russell L. Carter 2006-12-13 20:15:28 UTC
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.
Comment 15 Alan Hourihane 2006-12-14 06:37:44 UTC
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.
Comment 16 Alan Hourihane 2007-01-09 02:38:35 UTC

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


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.