intel driver suspend/resume failure

[Remy Bosch]

James Bottomley wrote:
> On Sun, 2007-06-10 at 19:03 +0800, Wang Zhenyu wrote:
>   
>> On 2007.06.08 16:10:39 +0000, Jesse Barnes wrote:
>>     
>>> On Friday, June 8, 2007 3:28:51 James Bottomley wrote:
>>>       
>>>> On Fri, 2007-06-08 at 15:17 -0700, Jesse Barnes wrote:
>>>>         
>>>>> Can you send copies of video.state.0 prior to suspend and after?  That
>>>>> way we'll know which registers are getting clobbered on resume...
>>>>>           
>>>> Sure; attached as video_state.0 and video_state.0.after (which is what I
>>>> get on resume but before I overlay video_state.0).
>>>>
>>>> James
>>>>         
>>> -0000e0 0020 0000 0000 0000 0000 0000 0000 0000
>>> -0000f0 0000 3464 00ff 0000 0000 0005 0000 0000
>>> +0000e0 0000 0000 0000 0000 0000 0000 0000 0000
>>> +0000f0 0000 3464 0000 0000 0000 0005 0000 0000
>>>
>>> I think the changes are just in the SWSMI scratch field and part of the legacy 
>>> backlight register, so I'm not sure why this would make a difference for your 
>>> machine, but I guess we should clear them...
>>>
>>>       
>> Not sure if James has tried to clear this, and really fixed the resume?
>> Or this field change was caused by something else?
>>
>> Andreas Mohr has worked out i815 resume fix, which is on -mm tree now.
>> see ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/broken-out/working-3d-dri-intel-agpko-resume-for-i815-chip.patch
>> which also contains some facility code to debug this kind of resume problem,
>> but it's a compile option, better to be a module param. This looks good to
>> try and better to clean up the .suspend/.resume funcs.
>>     
>
> Unfortunately not, since the suspend/resume plugs into the AGP
> device ... these Fujitsu laptops seem to be directly coupled i915 chips,
> so no AGP port.
>
> I'm in two minds about this one ... as Greg says, the DRM driver could
> do it ... on the other hand, a userspace restore of the PCI state does
> work ... that seems a reasonable argument for simply doing the latter.
>   
>From what i've read on the suspend2 lists, inux want's the kernel to be
inteligent. Iow: The kernel needs to resume; not the userspace apps.
This does sound logical is you take into account that you want the
kernel to work  anywhere and not just on distrbution A or B.

With this in mind I'd vote the DRM option. The sooner the state is
restored the less impact on the userspace programs it has. I also read
that re-setting/re-loading the regisers is dangerous? Wouldn't that
imply that it is better to run these operations in the kernel in the
first place?

Just my two cents as I'm following this line with intrest.
I have suspend to ram working though without vbetools. Sometimes X
crashes an even hangs the whole laptop. I'm prepared to post a few logs
of the kernel and Xorg is you wish. I use
- gentoo xserver-1.3.0.0
- intel-2.0.0
- linux-2.6.21-r5-suspend2
- i915GM centrino
- Acer Travelmate 3002

Regards,

Remy