https://bugzilla.kernel.org/show_bug.cgi?id=17692

           Summary: Intermittent failure to resume from suspend-to-ram in
                    radeon_resume
           Product: Drivers
           Version: 2.5
    Kernel Version: 2.6.35.4
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Video(DRI - non Intel)
        AssignedTo: drivers_video-...@kernel-bugs.osdl.org
        ReportedBy: bugs+ker...@karlt.net
        Regression: No


TRACE_RESUMEs around this line indicate that it gets as far as radeon_resume,
but not as far as radeon_pm_resume:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=blob;f=drivers/gpu/drm/radeon/radeon_device.c;h=a7184636dcb494b36d470af30c2b513382d38019;hb=1506707a6c740db316e422239a53ae5df1727591#l798

Adding additional TRACE_RESUMEs earlier in radeon_resume_kms (and using them)
seems to make failure less frequent, as if there is a timing issue involved.

Possibly interesting messages on startup:

[drm] initializing kernel modesetting (RV515 0x1002:0x7145).
ATOM BIOS: M54CSP/M52CSP
[drm] Loading R500 Microcode
[drm] Initialized radeon 2.5.0 20080528 for 0000:01:00.0 on minor 0

and during successful resume:

radeon 0000:01:00.0: power state changed by ACPI to D0
radeon 0000:01:00.0: power state changed by ACPI to D0
radeon 0000:01:00.0: setting latency timer to 64
radeon 0000:01:00.0: ffff8800bfba5e00 unpin not necessary
[drm] radeon: 1 quad pipes, 1 z pipes initialized.
[drm] PCIE GART of 512M enabled (table at 0x00040000).
[drm] radeon: ring at 0x0000000008000000
[drm] ring test succeeded in 2 usecs
[drm] ib test succeeded in 0 usecs

ata1: EH complete
[drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 1sec aborting
[drm:atom_execute_table_locked] *ERROR* atombios stuck executing EC38 (len 86,
WS 4, PS 0) @ 0xEC6B
PM: resume of devices complete after 1660.086 msecs

http://bugs.freedesktop.org/show_bug.cgi?id=27744

I have radeon.dynclks=1 on the command line.
I had intermittent resume failures even without this, though I haven't
confirmed that the failure is at the same point.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to