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. Ok, I'll commit this for the time being then... > 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. I would need to see a drm debug across suspend resume to get an idea of what is going on for sure. If the interrupt handler is being uninstalled and reinstalled, it should work right... What I am doing now, probably due to the intel 2d driver being buggy, is when we reinstall the irq handler, I force vblank interrupts on and schedule them to be turned off 5 seconds later if nothing has asked for them. If the interrupt handler isn't being uninstalled, then I probably need to look at the suspend/resume bit of the intel drm driver and make sure that all of the interrupt foo is being saved/restored. Try the attached patch in addition to what you have now. Let's see if restoring the interrupt registers helps things. > 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 :) You are correct, laggy is very useful... What seems to be happening is that we either lose interrupts, or they are getting disabled and not re-enabled... Running "vblank_mode=3 glxgears" should behave badly if it is vblank interrupts that are borked. User interrupts will disrupt the entire pipeline as they are used to mark what commands have been sent and processed. But, I don't have a clear method for determining exactly what is broken right now... That is what makes this so frustrating... robert. > Your thoughts and instruction are welcome! > > -Brandon -- Robert Noland <rnoland_at_FreeBSD.org> FreeBSD
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:45 UTC