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! -BrandonReceived on Wed Mar 25 2009 - 22:22:19 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:45 UTC