| Summary: | DRM lockup on X startup | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Mattias Nissler <mattias.nissler> |
| Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | DRI git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/130. |
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.
I've tried to get the DRM/KMS stuff going on my Ati X800 Pro R423 PCIE. Here are theversions 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 300_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!