Bug 21476 - [KMS] Xorg server segfault on server regeneration
Summary: [KMS] Xorg server segfault on server regeneration
Status: RESOLVED DUPLICATE of bug 20516
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: git
Hardware: Other All
: medium critical
Assignee: Eric Anholt
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-29 09:28 UTC by Francesco R
Modified: 2009-07-01 00:25 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
bug.zip (347.83 KB, application/octet-stream)
2009-04-29 09:28 UTC, Francesco R
no flags Details
Xorg.0.log (14.04 KB, application/octet-stream)
2009-04-29 09:29 UTC, Francesco R
no flags Details
Xorg.0.log (14.04 KB, text/plain)
2009-04-29 09:33 UTC, Francesco R
no flags Details
intel_reg_dumper-dumps.zip (541.81 KB, application/zip)
2009-05-02 15:57 UTC, Francesco R
no flags Details

Description Francesco R 2009-04-29 09:28:17 UTC
Created attachment 25257 [details]
bug.zip

with latest git of the whole X stack Xorg crashes when exiting from either glxgears or glxinfo.
Additionally if Xorg is left to draw it's own backtrace sometimes freeze and become un-killable.

x11-base/xorg-server-1.6.0
1ae2ddc1dd4c90d50b8c57c4de677f8ab96b1fa2 branch 'master' of git://anongit.freedesktop.org/git/cairo
11b60973bca1bc9bbda44be4c695e22d28d8ca4a branch 'master' of git://anongit.freedesktop.org/git/mesa/drm
2bef065b70f70af520b5de8fb23529254d15f003 branch 'master' of git://anongit.freedesktop.org/git/xorg/lib/libX11
801a33ae44355b89cebed47e9e48e39545522f6e branch 'master' of git://anongit.freedesktop.org/mesa/mesa
e6725408d518624ce73ec578a5fdd37eb90b4d8d branch 'master' of git://anongit.freedesktop.org/git/xcb/util
417f3784b7fae8de3559c7607a2de60661a6a448 branch 'master' of git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel

uname -a
Linux user 2.6.30-rc3-git6-debug #5 SMP Wed Apr 29 15:14:27 CEST 2009 x86_64 Intel(R) Core(TM)2 Duo CPU E4500 @ 2.20GHz GenuineIntel GNU/Linux

step to reproduce:
term 1:
launch X

term 2
launch glxinfo

term 1:
read backtrace

unzip -l bug.zip
Archive:  bug.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
        0  04-29-09 18:06   bug/
   126434  04-29-09 17:54   bug/dmesg.log
     2239  04-29-09 18:05   bug/README
   958455  04-29-09 17:39   bug/kernel-trace.log
    15140  04-29-09 16:55   bug/lshw.log
    15683  04-29-09 16:55   bug/lspci.log
     4283  04-29-09 18:06   bug/emerge-info.log
     2002  04-29-09 17:37   bug/backtrace.log
     1404  04-29-09 16:54   bug/lsmod.log
    13270  04-29-09 17:33   bug/Xorg.0.log
     9245  04-29-09 17:53   bug/messages.log
  2096632  04-29-09 17:37   bug/core.24014
     1964  04-29-09 16:56   bug/xorg.conf
 --------                   -------
  3246751                   13 files
Comment 1 Francesco R 2009-04-29 09:29:12 UTC
Created attachment 25258 [details]
Xorg.0.log

Xorg.0.log from a run outside of gdb
Comment 2 Francesco R 2009-04-29 09:33:31 UTC
Created attachment 25259 [details]
Xorg.0.log

wrong mimetype :(
Comment 3 Francesco R 2009-05-02 10:19:32 UTC
also, this is the dmesg of a zombie X, it happen but not all the times, and never in a gdb run.


[ 8071.706720] [drm] DAC-6: set mode 1152x864 18
[ 8092.659194] INFO: RCU detected CPU 0 stall (t=4297305094/3000 jiffies)
[ 8092.659200] Pid: 12542, comm: X Not tainted 2.6.30-rc4-debug #7
[ 8092.659200] Call Trace:
[ 8092.659200]  <IRQ>  [<ffffffff802c1891>] __rcu_pending+0x1b1/0x300
[ 8092.659200]  [<ffffffff8020c296>] ? ftrace_call+0x5/0x2b
[ 8092.659200]  [<ffffffff802c1a1b>] rcu_pending+0x3b/0x90
[ 8092.659200]  [<ffffffff802676b0>] ? run_local_timers+0x30/0x50
[ 8092.659200]  [<ffffffff80267722>] update_process_times+0x52/0xa0
[ 8092.659200]  [<ffffffff8028985d>] ? tick_do_update_jiffies64+0x8d/0xf0
[ 8092.659200]  [<ffffffff8028995a>] tick_nohz_handler+0x9a/0x140
[ 8092.659200]  [<ffffffff80761cc0>] smp_apic_timer_interrupt+0x80/0xc6
[ 8092.659200]  [<ffffffff8020d193>] apic_timer_interrupt+0x13/0x20
[ 8092.659200]  <EOI>  [<ffffffff807595e3>] ? __mutex_lock_common+0x343/0x450
[ 8092.659200]  [<ffffffffa00c2b75>] ? drm_vm_shm_close+0xc5/0x2a0 [drm]
[ 8092.659200]  [<ffffffffa00c2b37>] ? drm_vm_shm_close+0x87/0x2a0 [drm]
[ 8092.659200]  [<ffffffff8030fc56>] ? remove_vma+0x56/0xc0
[ 8092.659200]  [<ffffffff8030fdf0>] ? exit_mmap+0x130/0x180
[ 8092.659200]  [<ffffffff8036da92>] ? exit_aio+0x12/0x100
[ 8092.659200]  [<ffffffff80256737>] ? mmput+0x87/0x100
[ 8092.659200]  [<ffffffff8025bec5>] ? exit_mm+0x125/0x180
[ 8092.659200]  [<ffffffff8025ddf5>] ? do_exit+0x135/0x820
[ 8092.659200]  [<ffffffff8025e53c>] ? do_group_exit+0x5c/0xe0
[ 8092.659200]  [<ffffffff8026d2fa>] ? get_signal_to_deliver+0x2fa/0x460
[ 8092.659200]  [<ffffffff8075b892>] ? _spin_unlock_irqrestore+0x52/0x90
[ 8092.659200]  [<ffffffff8020c296>] ? ftrace_call+0x5/0x2b
[ 8092.659200]  [<ffffffff8020b80a>] ? do_notify_resume+0xea/0x840
[ 8092.659200]  [<ffffffff8075b81f>] ? _spin_unlock_irq+0x3f/0x60
[ 8092.659200]  [<ffffffff8020c5cc>] ? sysret_check+0x27/0x62
[ 8092.659200]  [<ffffffff8028fc52>] ? trace_hardirqs_on_caller+0x32/0x200
[ 8092.659200]  [<ffffffff8020c296>] ? ftrace_call+0x5/0x2b
[ 8092.659200]  [<ffffffff8028fc52>] ? trace_hardirqs_on_caller+0x32/0x200
[ 8092.659200]  [<ffffffff8020c698>] ? sysret_signal+0x7c/0xcb

kernel, and all x11 parts except xorg-server have been updated to the lastest git version.

Comment 4 Francesco R 2009-05-02 15:57:57 UTC
Created attachment 25379 [details]
intel_reg_dumper-dumps.zip

today trying with xorg-server from git, the attached file contain the dump of intel_reg_dumper tool in various point in time.

(gdb) bt
#0  drm_intel_bo_alloc (bufmgr=0x0, name=0x7f71fdb126c1 "HW cursors", size=40960, alignment=1048576) at intel_bufmgr.c:51
#1  0x00007f71fdad1ee0 in i830_allocate_memory_bo () from /usr/lib64/xorg/modules/drivers/intel_drv.so
#2  0x00007f71fdad23f9 in i830_allocate_memory () from /usr/lib64/xorg/modules/drivers/intel_drv.so
#3  0x00007f71fdad3448 in i830_allocate_cursor_buffers () from /usr/lib64/xorg/modules/drivers/intel_drv.so
#4  0x00007f71fdad3876 in i830_allocate_2d_memory () from /usr/lib64/xorg/modules/drivers/intel_drv.so
#5  0x00007f71fdac81ef in i830_try_memory_allocation () from /usr/lib64/xorg/modules/drivers/intel_drv.so
#6  0x00007f71fdac83da in i830_memory_init () from /usr/lib64/xorg/modules/drivers/intel_drv.so
#7  0x00007f71fdac8f60 in I830ScreenInit () from /usr/lib64/xorg/modules/drivers/intel_drv.so
#8  0x0000000000430f5b in AddScreen (pfnInit=0x7f71fdac8b2a <I830ScreenInit>, argc=1, argv=0x7fff0a1a5d18) at dispatch.c:4032
#9  0x0000000000463874 in InitOutput (pScreenInfo=0x7b1820, argc=1, argv=0x7fff0a1a5d18) at xf86Init.c:1233
#10 0x00000000004291b2 in main (argc=1, argv=0x7fff0a1a5d18, envp=<value optimized out>) at main.c:202
(gdb) list
46
47      drm_intel_bo *
48      drm_intel_bo_alloc(drm_intel_bufmgr *bufmgr, const char *name,
49                         unsigned long size, unsigned int alignment)
50      {
51         return bufmgr->bo_alloc(bufmgr, name, size, alignment);
52      }
53
54      drm_intel_bo *
55      drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr, const char *name,
(gdb)
Comment 5 Eric Anholt 2009-05-04 12:49:38 UTC
Nothing GL related here, you're just triggering the nasty path of trying to deinitialize the driver and reinitialize it after the last client closes.  You could do it with any X app and a bare X server.

I'm working on getting this fixed, but as always our init/close paths are rather tricky.

If you're just trying to do testing, then I'd recommend keeping another application open when running glxgears or test applications.
Comment 6 Francesco R 2009-05-09 13:18:14 UTC
you have my simpathy awfull stuff to debug, just in case ...

I do own 5 pc with the configuration show in this same bug, and some nightly time to spare, if some debug/testing is needed feel free to contact me francesco<>pnpitalia<>it
Comment 7 Jesse Barnes 2009-05-11 11:21:55 UTC
Adjusting severity: crashes & hangs should be marked critical.
Comment 8 Eric Anholt 2009-07-01 00:25:10 UTC

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


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.