DRM lockup on X startup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Hi, 

out of curiosity about the current state of the Linux 3D stack, I've
tried to get it going on my Ati X800 Pro R423 PCIE. Here are the
versions I've tried with:

drm-2.6.git at 9e67e5b Merge tag 'v2.6.34' into drm-radeon-testing
libdrm git at 607e228 Enable silent automake rules.
xf86-video-ati git at 428125c r3xx-r5xx: enable color tiling by default on KMS
mesa git at b202c78 r300: fix blits for textures of width/height greater than 2048 on r5xx

The kernel boots up just fine and the text console switches to the drm
framebuffer device as expected. When starting the X server, the VT
switch occurs, but the display just freezes (presumably at modesetting
time). The kernel doesn't crash, but graphics become unusable (no VT
switching, modesetting whatsoever possible from the command line). In my
kernel logs, I see the following:

Jun  3 17:51:06 kea kernel: INFO: task X:3245 blocked for more than 120 seconds.
Jun  3 17:51:06 kea kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jun  3 17:51:06 kea kernel: X             D ffffffff8175c820     0  3245   3243 0x00400004
Jun  3 17:51:06 kea kernel: ffff88007c515788 0000000000000046 0000000000000000 ffffffff00000000
Jun  3 17:51:06 kea kernel: ffff88007c515fd8 ffff88007c515fd8 ffff88007a961040 0000000000014000
Jun  3 17:51:06 kea kernel: ffff88007c515fd8 0000000000014000 ffffffff81a67020 ffff88007a961040
Jun  3 17:51:06 kea kernel: Call Trace:
Jun  3 17:51:06 kea kernel: [<ffffffff81743bc3>] mutex_lock_nested+0x183/0x370
Jun  3 17:51:06 kea kernel: [<ffffffff813bfb5b>] ? radeon_ring_lock+0x2b/0x60
Jun  3 17:51:06 kea kernel: [<ffffffff813bfb5b>] radeon_ring_lock+0x2b/0x60
Jun  3 17:51:06 kea kernel: [<ffffffff8174519b>] ? _raw_write_unlock_irqrestore+0x3b/0x60
Jun  3 17:51:06 kea kernel: [<ffffffff813d36a1>] r300_gpu_is_lockup+0x71/0x190
Jun  3 17:51:06 kea kernel: [<ffffffff813a8aee>] radeon_fence_wait+0x32e/0x3c0
Jun  3 17:51:06 kea kernel: [<ffffffff810926b0>] ? autoremove_wake_function+0x0/0x40
Jun  3 17:51:06 kea kernel: [<ffffffff813a82a5>] ? radeon_fence_emit+0xe5/0x130
Jun  3 17:51:06 kea kernel: [<ffffffff814074c8>] radeon_pm_set_clocks+0x428/0x670
Jun  3 17:51:06 kea kernel: [<ffffffff81407742>] ? radeon_pm_compute_clocks+0x32/0x280
Jun  3 17:51:06 kea kernel: [<ffffffff814077f0>] radeon_pm_compute_clocks+0xe0/0x280
Jun  3 17:51:06 kea kernel: [<ffffffff813ac42c>] radeon_crtc_mode_fixup+0x2c/0x50
Jun  3 17:51:06 kea kernel: [<ffffffff81358958>] drm_crtc_helper_set_mode+0x138/0x3c0
Jun  3 17:51:06 kea kernel: [<ffffffff81359657>] drm_crtc_helper_set_config+0x837/0x8e0
Jun  3 17:51:06 kea kernel: [<ffffffff8136be00>] drm_mode_setcrtc+0x170/0x3c0
Jun  3 17:51:06 kea kernel: [<ffffffff8135e79a>] drm_ioctl+0x33a/0x4c0
Jun  3 17:51:06 kea kernel: [<ffffffff8136bc90>] ? drm_mode_setcrtc+0x0/0x3c0
Jun  3 17:51:06 kea kernel: [<ffffffff810973de>] ? up_read+0x1e/0x40
Jun  3 17:51:06 kea kernel: [<ffffffff81114a98>] vfs_ioctl+0x38/0xd0
Jun  3 17:51:06 kea kernel: [<ffffffff81114c7a>] do_vfs_ioctl+0x8a/0x640
Jun  3 17:51:06 kea kernel: [<ffffffff8111527a>] sys_ioctl+0x4a/0x80
Jun  3 17:51:06 kea kernel: [<ffffffff81032f42>] system_call_fastpath+0x16/0x1b
Jun  3 17:51:06 kea kernel: 6 locks held by X/3245:
Jun  3 17:51:06 kea kernel: #0:  (&dev->mode_config.mutex){......}, at: [<ffffffff8136bcca>] drm_mode_setcrtc+0x3a/0x3c0
Jun  3 17:51:06 kea kernel: #1:  (&rdev->pm.mutex){......}, at: [<ffffffff81407742>] radeon_pm_compute_clocks+0x32/0x280
Jun  3 17:51:06 kea kernel: #2:  (&dev->struct_mutex){......}, at: [<ffffffff814070d1>] radeon_pm_set_clocks+0x31/0x670
Jun  3 17:51:06 kea kernel: #3:  (&rdev->vram_mutex){......}, at: [<ffffffff814070db>] radeon_pm_set_clocks+0x3b/0x670
Jun  3 17:51:06 kea kernel: #4:  (&rdev->cp.mutex){......}, at: [<ffffffff814070e5>] radeon_pm_set_clocks+0x45/0x670
Jun  3 17:51:06 kea kernel: #5:  (&rdev->cp.mutex){......}, at: [<ffffffff813bfb5b>] radeon_ring_lock+0x2b/0x60

I've had a quick look at the code, seems radeon_ring_lock cannot acquire
the lock, since it's already taken by radeon_pm_set_clocks? But maybe
the r300_gpu_is_lockup call indicates there's a bigger problem occurring
before? You see, I don't know the code ;)

If you want me to try patches, different versions etc. I'm happy to
help. Keep up the good work!

Mattias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/dri-users/attachments/20100603/a6faa4b1/attachment.pgp>


[Index of Archives]     [Linux DRI Development]     [Linux Intel Graphics]     [Linux AMD Graphics]     [Video for Linux]     [Linux Audio Users]     [Yosemite Waterfalls]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux Media]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux