On Wed, 2009-03-25 at 18:22 -0500, Brandon Gooch wrote: > 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! Ok, here is what I would like to do. Apply this patch. This adds some debugging info to sysctl hw.dri.0.vblank, I also added a couple of lines so that we should be able to see what interrupts are enabled and masked. There isn't really a good place to do this at the moment, but we should hit the paths to at least show it. So, apply the patch, before suspending capture hw.dri.0.vblank output, turn on hw.dri.0.debug and suspend. Once you resume, you can turn off hw.dri.0.debug and recapture hw.dri.0.vblank. robert. > -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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:45 UTC