Created attachment 23776 [details] xorg log System Environment: -------------------------- Libdrm: (master)82eac8060b98b425f29051bfd7830ba3622be7d8 Mesa: (mesa_7_4_branch)2adaec12267767747a22646c759b0d6c1651d3bf Xserver: (server-1.6-branch)f469726fec502ce29999eda6919c3c3d26c127d8 Xf86_video_intel: (2.7)4e334ef33c38e2e930958a4b68d79f1860bb9efa Kernel: (for-airlied)edde72a59461d766997b469f6d20afdf5fe9b5b4 Bug detailed description: ------------------------- we tried S3/S4 with KMS enabled, but it can not bring back to X after suspending. we can only see the frame buffer console, and can access the machine by remote. Sometime, Kernel will OOPS the issue happens on acer aspire one. reproduce steps: ------------------------ 1.xinit& 2.echo mem(or disk) >/sys/power/state 3. power on
Created attachment 23777 [details] xorg conf
Created attachment 23778 [details] reg_dump before S3/S4
Created attachment 23779 [details] reg dump after S3
Created attachment 23780 [details] reg dump after S4
Created attachment 23781 [details] dmesg when resume from S4 OOPS
this is netbook
I can reproduce in moblin, of which gfx components were replaced by upstream's moblin + Libdrm:(master)+ mesa_7_4_branch + server-1.6-branch + Xf86_video_intel:(2.7)
The oops looks network related; do you see that w/o KMS also? Can you get a backtrace of X trying to resume? Presumably it's stuck in EnterVT somewhere... The register dumps don't indicate anything bad, though it looks like the front buffer address changed between suspend and resume... @@ -71,7 +71,7 @@ (II): DSPBSTRIDE: 0x00001000 (4096 bytes) (II): DSPBPOS: 0x00000000 (0, 0) (II): DSPBSIZE: 0x025703ff (1024, 600) -(II): DSPBBASE: 0x00c00000 +(II): DSPBBASE: 0x007df000 (II): DSPBSURF: 0x00000000 (II): DSPBTILEOFF: 0x00000000 (II): PIPEBCONF: 0x80000000 (enabled, single-wide) And it seems to work fine on my GM45 test machine w/the -rc7 bits from today...
now, It works well in my moblin platform Kernel:for-airlied 2.6.29-rc7 Libdrm:(master) mesa_7_4_branch server-1.6-branch Xf86_video_intel:(2.7)
(In reply to comment #8) > The oops looks network related; do you see that w/o KMS also? Can you get a > backtrace of X trying to resume? Presumably it's stuck in EnterVT somewhere... > > The register dumps don't indicate anything bad, though it looks like the front > buffer address changed between suspend and resume... > > @@ -71,7 +71,7 @@ > (II): DSPBSTRIDE: 0x00001000 (4096 bytes) > (II): DSPBPOS: 0x00000000 (0, 0) > (II): DSPBSIZE: 0x025703ff (1024, 600) > -(II): DSPBBASE: 0x00c00000 > +(II): DSPBBASE: 0x007df000 > (II): DSPBSURF: 0x00000000 > (II): DSPBTILEOFF: 0x00000000 > (II): PIPEBCONF: 0x80000000 (enabled, single-wide) > > And it seems to work fine on my GM45 test machine w/the -rc7 bits from today... > with -rc7 kernel, it's working now. The configuration is as below: Libdrm: (master)82eac8060b98b425f29051bfd7830ba3622be7d8 Mesa: (mesa_7_4_branch)45c4b4dfbd019260dd0df37ba6776c77149ec7ba Xserver: (server-1.6-branch)f469726fec502ce29999eda6919c3c3d26c127d8 Xf86_video_intel: (2.7)490cb578aef761e3fdd0a559bec36cdab96e6b2a Kernel: (for-airlied)dc529a4fe1ae4667c819437a94185e8581e1e680
verified. Thanks
Closing old verified.
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.