Sony VAIO - suspend/resume works, but SLOW

Eric Kjeldergaard kjelderg at gmail.com
Tue Oct 4 22:45:33 PDT 2005


On 10/5/05, Eric Anderson <anderson at centtech.com> wrote:
> Nate Lawson wrote:
> > Eric Anderson wrote:
> >
> >> Fabian Keil wrote:
> >>
> >>>
> >>> If I didn't overlook it, your kernel lacks "device pmtimer".
> >>> Without it, I get the symptoms you described.
> >>
> >>
> >>
> >> Right you are.  I've just added it - rebuilding kernel now.
> >>
> >> How are others keeping their custom kernel config up-to-date?  This
> >> seems like a real issue to me, unless there's a tool to do this
> >> already and I'm just not using it.  I cp GENERIC, make my changes, and
> >> move on. As my machine tracks -CURRENT, the GENERIC kernel changes,
> >> but my custom config stays the same (I never 'merge' any changes in).
> >>
> >> Thanks Fabian for the hint..
> >
> >
> > My kernel config begins with:
> >
> > include GENERIC
> > nodevice aac
> > etc.
> >
> > Check out the PAE kernel config to see the syntax.
> >
>
> Thanks - I'll give that a try, seems like an elegant solution.
>
> Back to the original subject - I've added the pmtimer to my kernel, and
> now it does resume and act normal - yea!
>
> A couple things I noticed now:
> - after resume, system won't reboot.  It goes through the entire
> process, but stops after the "Rebooting...".  I have to manually power
> off the machine, and power it back on.
>
> - when in X, and I do acpiconf -s3, it does indeed suspend.  Resuming
> appears to be coming back, but my xwindows is locked up (no mouse
> movement, no screen updates, and a little screen distortion at the top -
> so a video driver issue?).  My caps lock and num lock keys seemed to
> work, but I couldn't break from X.  I think did the (not so smart) break
> to debugger, which left me in a state I couldn't recover from.  Reboot
> ensued.  I have a Radeon card in this laptop.
>
> So two questions:
> When does one need the reset_video switch on/off?
>
> What's the next logical step in debugging this?

One thing that I wonder immediately is if you have DRI being used in
X.  If so, it tends to lock on resume.  Otherwise many people have
success twiddling with the sysctl hw.syscons.sc_no_suspend_vtswitch
and hw.acpi.reset_video .  I'm not sure the actual rules for when
these work although the reset_video one says: Call the VESA reset BIOS
vector on the resume path .  I guess I would assume this to be a quirk
workaround.  Best of luck,

Eric

--
If I write a signature, my emails will appear more personalised.


More information about the freebsd-acpi mailing list