Date: Wed, 5 Oct 2005 06:32:30 +0900 From: Eric Kjeldergaard <kjelderg@gmail.com> To: Eric Anderson <anderson@centtech.com> Cc: freebsd-acpi@freebsd.org Subject: Re: Sony VAIO - suspend/resume works, but SLOW Message-ID: <d9175cad0510041432u613d317u@mail.gmail.com> In-Reply-To: <4342A9E6.3020701@centtech.com> References: <434286E0.6020708@centtech.com> <20051004160118.3f2050d4@localhost> <43428C42.2020806@centtech.com> <4342A1FB.5020301@root.org> <4342A9E6.3020701@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/5/05, Eric Anderson <anderson@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d9175cad0510041432u613d317u>