Re: [HEADSUP] amd64 suspend/resume code to be comitted

From: Brandon Gooch <jamesbrandongooch_at_gmail.com>
Date: Wed, 25 Mar 2009 10:21:21 -0500
On Tue, Mar 24, 2009 at 10:06 PM, Robert Noland <rnoland_at_freebsd.org> wrote:
> On Tue, 2009-03-24 at 18:31 -0500, Brandon Gooch wrote:
>> On Tue, Mar 24, 2009 at 4:14 PM, Adam McDougall <mcdouga9_at_egr.msu.edu> wrote:
>> > Brandon Gooch wrote:
>> >>
>> >> On Mon, Mar 23, 2009 at 4:28 PM, Jung-uk Kim <jkim_at_freebsd.org> wrote:
>> >>
>> >>>
>> >>> On Monday 23 March 2009 05:16 pm, Brandon Gooch wrote:
>> >>>
>> >>>>
>> >>>> The committed version is working well, I am suspending and resuming
>> >>>> on my Lenovo X300. Thanks for your work on this, it is one of the
>> >>>> major things I needed to work so I could run FreeBSD primarily on
>> >>>> my notebook.
>> >>>>
>> >>
>> >> I just finished a kernel build and it seems as though your
>> >> recent commits have fixed the clock (at least for me)!
>> >>
>> >> I feel sorry for all the i386 folks on ACPI notebooks...
>> >>
>> >> Thanks!
>> >>
>> >> -Brandon
>> >>
>> >
>> > Picking a semi-random message here..
>> >
>> > Thanks for your work on this!  In the past (months ago) I tried the patch
>> > set which didn't work, but the code in -current lets me suspend and resume
>> > successfully on my Dell Latitude E6500 (acpiconf -s 3)!  I think this is a
>> > first for me, of all the laptops I've had, none have ever been able to
>> > suspend and resume in a successful or useful way, and I've been jealous of
>> > the Thinkpad users that could claim otherwise.  I could suspend and resume
>> > fine while in the console, then I ran startx and the suspend and resume
>> > worked while I was in X with intel graphics, however my system was slow
>> > after that resume.  I didn't spend much time looking at it since I was at
>> > work, and I didn't see any obvious reasons for the slowness (cpu frequency
>> > was fine, cx states were C2 or lower (C1), top showed mostly idle, no
>> > evidence of an IRQ storm) yet processes ran fairly sluggish (not the mouse
>> > or typing though).  I didn't go back to console, I just shut down without
>> > trying any other situations yet.
>> >
>> > A tip I want to note for any users who may not have success with their
>> > screen on resume:  In the past it seemed to help me to have a power-on
>> > password set in my BIOS since the BIOS will turn on the screen on resume to
>> > ask me for my password.  I don't know if it is still helping me, but I've
>> > seen in the past where it has.
>> > _______________________________________________
>> > freebsd-current_at_freebsd.org mailing list
>> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>> >
>>
>> The sluggish response in X on Intel video has been an issue the past
>> couple of days, triggered by suspend/resume or simply switching to VTY
>> and back.
>
> I just committed code that should fix this...
>
> robert.
>
>> See this thread:
>> http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004968.html
>>
>> Firefox is unusable, but xterms are still usable. I have to reboot to
>> get back to "normal"
>>
>> -Brandon
>> _______________________________________________
>> freebsd-current_at_freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> --
> Robert Noland <rnoland_at_FreeBSD.org>
> FreeBSD
>

It seems to have helped -- slightly. Firefox is still too laggy when
interacting with interface elements (scrollbar, toolbars, menus), and
typing within HTML textboxes. XTerm, xpdf, xcalc, etc are still OK to
use, perhaps because they're not as graphically intensive :)

Also, it seems to have broken the suspend/resume. The machine does
wake up, but X is no longer there (I'm at the VTY from which I started
X) and I can't switch to another VTY. The machine still "works" for a
period, but attempts to switch VTY or enter commands from the keyboard
eventually lock it up, resulting in a continuous beep tone and
requiring a hard power-off (holding down the power button).

-Brandon
Received on Wed Mar 25 2009 - 14:21:23 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:44 UTC