Bug 90861
Summary: | Panic on suspend from KDE with radeon | ||
---|---|---|---|
Product: | Drivers | Reporter: | Jon Arne Jørgensen (jonjon.arnearne) |
Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
Status: | NEW --- | ||
Severity: | normal | CC: | alexdeucher, bugs, julien.isorce, szg00000 |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
Kernel Version: | 3.19.0-rc2-219-g693a30b8 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
full dmesg from panic
Complete Xorg.log Full pm-suspend log |
Description
Jon Arne Jørgensen
2015-01-06 20:41:54 UTC
Please attach your xorg log and full dmesg output. Created attachment 162731 [details]
full dmesg from panic
Created attachment 162741 [details]
Complete Xorg.log
This is the Xorg.log from a reproduced crash because i forgot to save the Xorg log when I ran the crashkernel.
Created attachment 162751 [details]
Full pm-suspend log
This is also from a reproduced crash.
I reproduced the panic when I tried to suspend when radeon was loaded without radeon.dpm=1. I was _not_ able to reproduce the panic with kernel-3.10.0-rc7 that I had lying around in my /boot directory. Looks like dpm_watchdog_handler kicks in while the radeon driver is waiting for a fence to signal. Maybe the Radeon GPU IRQ is disabled too early during suspend or something like that? (In reply to Jon Arne Jørgensen from comment #5) > I was _not_ able to reproduce the panic with kernel-3.10.0-rc7 that I had > lying around in my /boot directory. Can you bisect? I retried some kernels, and it seems like the problem was introduced in the 3.18 merge window. In v3.17 I can't reproduce the panic, while in v3.18-rc1 and later I can reproduce the panic. I'm trying to bisect now, but I'm troubled by a gpu freeze bug in some of the commits that crashes Xorg before I'm able to suspend the computer. It looks like a bug early in the v3.18 merge window, but I'm not sure if I should skip the crashing commits while doing the bisect? (In reply to Jon Arne Jørgensen from comment #7) > I'm trying to bisect now, but I'm troubled by a gpu freeze bug in some of > the commits that crashes Xorg before I'm able to suspend the computer. > > It looks like a bug early in the v3.18 merge window, but I'm not sure if I > should skip the crashing commits while doing the bisect? I'd skip them for now. Finaly managed to get a clean bisect, this is the culprit: commit f2c24b83ae90292d315aa7ac029c6ce7929e01aa Author: Maarten Lankhorst <maarten.lankhorst@canonical.com> Date: Wed Apr 2 17:14:48 2014 +0200 drm/ttm: flip the switch, and convert to dma_fence Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Possibly related to bug 90741. Maarten, any ideas? I tested attachment 164421 [details] from bug 90741, and can report that the patch seems to fix the crash. Does attachment 166571 [details] fix the bug for you too? I think that would be the best version to upstream.
I'm sorry to report that attachment 166571 [details] doesn't fix the crash, but I can also report that your suggestion from Bug 90741 comment 60 does fix the crash. That is, attachment 166571 [details] + if (fence->ring == R600_RING_TYPE_DMA_INDEX) udelay(50); in radeon_fence_enable_signaling? after the irq_get. I tried with udelay(50);, and mb(); both seems to work. I was not able to compile the kernel with "RREG32(DMA_CNTL + DMA0_REGISTER_OFFSET);" because of missing defines. What header should I include? Ok, in that case it's probably a duplicate. Can you attachment 166571 [details] on top of http://cgit.freedesktop.org/~agd5f/linux/log/?h=posting-read? Yep, that's a fix. |