Date: Wed, 25 Mar 2009 20:40:20 -0500 From: Robert Noland <rnoland@FreeBSD.org> To: Brandon Gooch <jamesbrandongooch@gmail.com> Cc: freebsd-current@freebsd.org, Jung-uk Kim <jkim@freebsd.org> Subject: Re: [HEADSUP] amd64 suspend/resume code to be comitted Message-ID: <1238031620.1828.92.camel@balrog.2hip.net> In-Reply-To: <179b97fb0903251622g3d24e8d3qb420cd258503de46@mail.gmail.com> 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> <179b97fb0903251622g3d24e8d3qb420cd258503de46@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-MK+hdDrbCt2cW4WlI6S1 Content-Type: multipart/mixed; boundary="=-fjex/E/gB+ZQeXe+Vu6l" --=-fjex/E/gB+ZQeXe+Vu6l Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2009-03-25 at 18:22 -0500, Brandon Gooch wrote: > On Wed, Mar 25, 2009 at 3:53 PM, Robert Noland <rnoland@freebsd.org> wrot= e: > > 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> = 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@egr.msu.e= du> wrote: > >> >> > Brandon Gooch wrote: > >> >> >> > >> >> >> On Mon, Mar 23, 2009 at 4:28 PM, Jung-uk Kim <jkim@freebsd.org> = wrote: > >> >> >> > >> >> >>> > >> >> >>> On Monday 23 March 2009 05:16 pm, Brandon Gooch wrote: > >> >> >>> > >> >> >>>> > >> >> >>>> The committed version is working well, I am suspending and res= uming > >> >> >>>> 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 t= he patch > >> >> > set which didn't work, but the code in -current lets me suspend a= nd 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 ab= le to > >> >> > suspend and resume in a successful or useful way, and I've been j= ealous of > >> >> > the Thinkpad users that could claim otherwise. I could suspend a= nd 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 wa= s 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 pow= er-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@freebsd.org mailing list > >> >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@fre= ebsd.org" > >> >> > > >> >> > >> >> The sluggish response in X on Intel video has been an issue the pas= t > >> >> 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/00496= 8.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@freeb= sd.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? 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 reall= y > > test s/r still... > > > > robert. > > > >> -Brandon > > -- > > Robert Noland <rnoland@FreeBSD.org> > > FreeBSD > > >=20 > 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=3D3 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. =20 > Your thoughts and instruction are welcome! >=20 > -Brandon --=20 Robert Noland <rnoland@FreeBSD.org> FreeBSD --=-fjex/E/gB+ZQeXe+Vu6l Content-Disposition: attachment; filename="i915_suspend.patch" Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name="i915_suspend.patch"; charset="us-ascii" SW5kZXg6IGk5MTVfc3VzcGVuZC5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0gaTkxNV9zdXNwZW5kLmMJKHJl dmlzaW9uIDE5MDQwMikNCisrKyBpOTE1X3N1c3BlbmQuYwkod29ya2luZyBjb3B5KQ0KQEAgLTUy Miw2ICs1MjIsMTIgQEANCiANCiAJaTkxNV9yZXN0b3JlX3ZnYShkZXYpOw0KIA0KKwkvKiBJbnRl cnJ1cHQgc3RhdGUgKi8NCisJSTkxNV9XUklURShQSVBFQVNUQVQsIGRldl9wcml2LT5zYXZlUElQ RUFTVEFUKTsNCisJSTkxNV9XUklURShQSVBFQlNUQVQsIGRldl9wcml2LT5zYXZlUElQRUJTVEFU KTsNCisJSTkxNV9XUklURShJRVIsIGRldl9wcml2LT5zYXZlSUVSKTsNCisJSTkxNV9XUklURShJ TVIsIGRldl9wcml2LT5zYXZlSU1SKTsNCisNCiAJcmV0dXJuIDA7DQogfQ0KIA0K --=-fjex/E/gB+ZQeXe+Vu6l-- --=-MK+hdDrbCt2cW4WlI6S1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknK3QQACgkQM4TrQ4qfROOuigCfQ+PQDXjmx+zHViqfJCciQ1WC jrYAnjcCdDz11C5OhGF41dfGOLA4CDM7 =kgjc -----END PGP SIGNATURE----- --=-MK+hdDrbCt2cW4WlI6S1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1238031620.1828.92.camel>