Created attachment 40753 [details] ATOM BIOS During resume, I get: [18832.030013] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [18832.030016] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing E8B8 (len 86, WS 4, PS 0) @ 0xE8EB [18837.060015] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [18837.060019] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing E8B8 (len 86, WS 4, PS 0) @ 0xE8EB [18842.380012] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [18842.380016] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing E8B8 (len 86, WS 4, PS 0) @ 0xE8EB [18842.430097] PM: resume of drv:radeon dev:0000:01:00.0 complete after 15575.937 msecs I have a: (--) RADEON(0): Chipset: "ATI Mobility Radeon X1600" (ChipID = 0x71c5)
Created attachment 40754 [details] Kernel log
Created attachment 40755 [details] Xorg log
We need a dump of your video bios see bottom of http://dri.freedesktop.org/wiki/TestingAndDebugging
Jerome the bios is attached already, This is the UpdateCRTC_DoubleBufferRegisters table, I've got the same issue here on my rv530 I just noticed. decoding the table shows it waiting for both crtcs, I wonder if they made this table saner in r6xx.
*** Bug 32307 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > Jerome the bios is attached already, > > This is the UpdateCRTC_DoubleBufferRegisters table, I've got the same issue > here on my rv530 I just noticed. > > decoding the table shows it waiting for both crtcs, I wonder if they made this > table saner in r6xx. We don't get this issue during normal modeset, so I suspect the regs are in a wonky state after resume. Perhaps a hard reset before asic_init would help.
I'm currently running ubuntu nartty with xorg-edgers, so its pretty easy for me to test something. Let me know if there is something you'd like me to try.
Created attachment 41218 [details] [review] possible fix This patch should fix the issues. We were attempting to unblank the displays before the timing was set up in the resume path.
*** Bug 27744 has been marked as a duplicate of this bug. ***
I'am sorry, but the patch doesn't fix the issue.
Created attachment 41343 [details] dmesg output after patch
(In reply to comment #10) > I'am sorry, but the patch doesn't fix the issue. Can you attach a copy of your vbios? (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/<pci bus id> echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom
Shame on me! I'm so sorry! I was my failure: I booted up the old kernel. I tested the patch with vanilla-kernel 2.6.37-rc6 and everything works perfect! It is a really nice christmans present for me, to see this bug fixed :-) Thank you Alex
General Question, maybe I should open an other bug: Did your terminal scroll sometimes slow "from top to bottom" (exampe dmesg), after the second or third suspend-cycle? This is fixed by "ctrl+l" or the next suspend-cycle. What I forgot: Will we see this patch in the next rc7 ord rc8, if all results are well as mine? Happy Christmas! Thanks
(In reply to comment #14) > General Question, maybe I should open an other bug: > Did your terminal scroll sometimes slow "from top to bottom" (exampe dmesg), > after the second or third suspend-cycle? This is fixed by "ctrl+l" or the next > suspend-cycle. > Not familiar with that. > What I forgot: > Will we see this patch in the next rc7 ord rc8, if all results are well as > mine? I've sent the patch to Dave. Hopefully it will hit 2.6.37.
In my case, error is not shown now in dmesg (after applying patch), but there still is a significant delay waking up. ATI HD5850, BIOS in the bug 32307.
What need time for wakeup dmesg prints? Mine is around 500msec
Tested 2.6.37-rc8 (patch is included already). Works perfect. No glitches here.
I haven't had a chance to test yet, but I did notice an additional debug message: [drm:atom_execute_table_locked] *ERROR* atombios stuck executing E8B8 (len 86, WS 4, PS 0) @ 0xE8EB
Just testing with 2.6.37 and this is fixed.
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.