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