Date: Wed, 25 Mar 2009 18:22:15 -0500 From: Brandon Gooch <jamesbrandongooch@gmail.com> To: Robert Noland <rnoland@freebsd.org> Cc: freebsd-current@freebsd.org, Jung-uk Kim <jkim@freebsd.org> Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted Message-ID: <179b97fb0903251622g3d24e8d3qb420cd258503de46@mail.gmail.com> In-Reply-To: <1238014404.1828.27.camel@balrog.2hip.net> References: <1236802980.00085518.1236789602@10.7.7.3> <200903162053.28614.jkim@FreeBSD.org> <179b97fb0903231416j4659101eu88dcc5ecf578167b@mail.gmail.com> <200903231728.46911.jkim@FreeBSD.org> <179b97fb0903232306y548144dx94836b534d9441dd@mail.gmail.com> <49C94D4C.5050104@egr.msu.edu> <179b97fb0903241631h76e8758dxd87900597a5cba4a@mail.gmail.com> <1237950378.1829.13.camel@balrog.2hip.net> <179b97fb0903250821g44aa9aceq7568abc90f0d5cf9@mail.gmail.com> <1238014404.1828.27.camel@balrog.2hip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 25, 2009 at 3:53 PM, Robert Noland <rnoland@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@freebsd.org> wr= ote: >> > On Tue, 2009-03-24 at 18:31 -0500, Brandon Gooch wrote: >> >> On Tue, Mar 24, 2009 at 4:14 PM, Adam McDougall <mcdouga9@egr.msu.edu= > wrote: >> >> > Brandon Gooch wrote: >> >> >> >> >> >> On Mon, Mar 23, 2009 at 4:28 PM, Jung-uk Kim <jkim@freebsd.org> wr= ote: >> >> >> >> >> >>> >> >> >>> On Monday 23 March 2009 05:16 pm, Brandon Gooch wrote: >> >> >>> >> >> >>>> >> >> >>>> The committed version is working well, I am suspending and resum= ing >> >> >>>> on my Lenovo X300. Thanks for your work on this, it is one of th= e >> >> >>>> major things I needed to work so I could run FreeBSD primarily o= n >> >> >>>> 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! =A0In the past (months ago) I tried t= he 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)! =A0I 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 jea= lous of >> >> > the Thinkpad users that could claim otherwise. =A0I could suspend a= nd resume >> >> > fine while in the console, then I ran startx and the suspend and re= sume >> >> > worked while I was in X with intel graphics, however my system was = slow >> >> > after that resume. =A0I 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 fr= equency >> >> > 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 th= e mouse >> >> > or typing though). =A0I 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 th= eir >> >> > screen on resume: =A0In the past it seemed to help me to have a pow= er-on >> >> > password set in my BIOS since the BIOS will turn on the screen on r= esume to >> >> > ask me for my password. =A0I don't know if it is still helping me, = but I've >> >> > seen in the past where it has. >> >> > _______________________________________________ >> >> > freebsd-current@freebsd.org mailing list >> >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freeb= sd.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 VT= Y >> >> 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@freebsd.org mailing list >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= .org" >> > -- >> > Robert Noland <rnoland@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? =A0This 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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?179b97fb0903251622g3d24e8d3qb420cd258503de46>