[HEADSUP] amd64 suspend/resume code to be comitted

Brandon Gooch jamesbrandongooch at gmail.com
Wed Mar 25 16:22:19 PDT 2009


On Wed, Mar 25, 2009 at 3:53 PM, Robert Noland <rnoland at freebsd.org> wrote:
> On Wed, 2009-03-25 at 10:21 -0500, Brandon Gooch wrote:
>> 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).
>
> Can you try the attached patch?  This was a last minute change that I
> made and I don't know why it seems to be upsetting things so, but it
> looks like it causes things to not shutdown properly.
>
> It looks like it isn't safe to suspend with / on usb2, so I can't really
> test s/r still...
>
> robert.
>
>> -Brandon
> --
> Robert Noland <rnoland at FreeBSD.org>
> FreeBSD
>

Applying the patch and rebuilding does get me back to successful
suspend/resume cycle, but the sluggish application weirdness still
persists.

It's odd, but for brief moment (about a second) after resume, the
screen comes back on as if it has been issued a "DPMS on" (as in say,
vbetool or something), and then it flashes off again, only to come
back on another second later. I assume this has something to do with
resetting or restoring bits some place, but I wondered if this is an
expected behavior.

BTW, what utility would provide a decent test with quantifiable
results. I feel there may be a better way to help us understand what
is actually causing the symptoms and to pinpoint it in the source for
you. Describing a GTK app as "laggy" or "sluggish" is hardly good
enough :)

Your thoughts and instruction are welcome!

-Brandon


More information about the freebsd-current mailing list