Date: Thu, 26 Mar 2009 19:02:32 -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: <1238112152.1777.6.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
--=-HvemGFtbauss/A9uML9B Content-Type: multipart/mixed; boundary="=-V02lBAxAJtiLQxV96XE9" --=-V02lBAxAJtiLQxV96XE9 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. >=20 > 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. >=20 > 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 :) >=20 > 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Robert Noland <rnoland@FreeBSD.org> FreeBSD --=-V02lBAxAJtiLQxV96XE9 Content-Disposition: attachment; filename="drm-vblank-intel-debug.patch" Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name="drm-vblank-intel-debug.patch"; charset="us-ascii" SW5kZXg6IGRldi9kcm0vZHJtX3N5c2N0bC5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQotLS0gZGV2L2RybS9kcm1f c3lzY3RsLmMJKHJldmlzaW9uIDE5MDQwMikNCisrKyBkZXYvZHJtL2RybV9zeXNjdGwuYwkod29y a2luZyBjb3B5KQ0KQEAgLTM4LDYgKzM4LDcgQEANCiBzdGF0aWMgaW50CSAgIGRybV92bV9pbmZv IERSTV9TWVNDVExfSEFORExFUl9BUkdTOw0KIHN0YXRpYyBpbnQJICAgZHJtX2NsaWVudHNfaW5m byBEUk1fU1lTQ1RMX0hBTkRMRVJfQVJHUzsNCiBzdGF0aWMgaW50CSAgIGRybV9idWZzX2luZm8g RFJNX1NZU0NUTF9IQU5ETEVSX0FSR1M7DQorc3RhdGljIGludAkgICBkcm1fdmJsYW5rX2luZm8g RFJNX1NZU0NUTF9IQU5ETEVSX0FSR1M7DQogDQogc3RydWN0IGRybV9zeXNjdGxfbGlzdCB7DQog CWNvbnN0IGNoYXIgKm5hbWU7DQpAQCAtNDcsNiArNDgsNyBAQA0KIAl7InZtIiwJICAgIGRybV92 bV9pbmZvfSwNCiAJeyJjbGllbnRzIiwgZHJtX2NsaWVudHNfaW5mb30sDQogCXsiYnVmcyIsICAg IGRybV9idWZzX2luZm99LA0KKwl7InZibGFuayIsICAgIGRybV92YmxhbmtfaW5mb30sDQogfTsN CiAjZGVmaW5lIERSTV9TWVNDVExfRU5UUklFUyAoc2l6ZW9mKGRybV9zeXNjdGxfbGlzdCkvc2l6 ZW9mKGRybV9zeXNjdGxfbGlzdFswXSkpDQogDQpAQCAtMzEzLDMgKzMxNSwyNSBAQA0KIAlmcmVl KHRlbXBwcml2cywgRFJNX01FTV9EUklWRVIpOw0KIAlyZXR1cm4gcmV0Y29kZTsNCiB9DQorDQor c3RhdGljIGludCBkcm1fdmJsYW5rX2luZm8gRFJNX1NZU0NUTF9IQU5ETEVSX0FSR1MNCit7DQor CXN0cnVjdCBkcm1fZGV2aWNlICpkZXYgPSBhcmcxOw0KKwljaGFyIGJ1ZlsxMjhdOw0KKwlpbnQg cmV0Y29kZTsNCisJaW50IGk7DQorDQorCURSTV9TWVNDVExfUFJJTlQoIlxuY3J0YyByZWYgY291 bnQgICAgbGFzdCAgICAgZW5hYmxlZCBpbm1vZGVzZXRcbiIpOw0KKwlmb3IoaSA9IDAgOyBpIDwg ZGV2LT5udW1fY3J0Y3MgOyBpKyspIHsNCisJCURSTV9TWVNDVExfUFJJTlQoIiAgJTAyZCAgJTAy ZCAlMDhkICUwOGQgJTAyZCAgICAgICUwMmRcbiIsDQorCQkgICAgaSwgYXRvbWljX3JlYWQoJmRl di0+dmJsYW5rW2ldLnJlZmNvdW50KSwNCisJCSAgICBhdG9taWNfcmVhZCgmZGV2LT52Ymxhbmtb aV0uY291bnQpLA0KKwkJICAgIGF0b21pY19yZWFkKCZkZXYtPnZibGFua1tpXS5sYXN0KSwNCisJ CSAgICBhdG9taWNfcmVhZCgmZGV2LT52YmxhbmtbaV0uZW5hYmxlZCksDQorCQkgICAgYXRvbWlj X3JlYWQoJmRldi0+dmJsYW5rW2ldLmlubW9kZXNldCkpOw0KKwl9DQorDQorCVNZU0NUTF9PVVQo cmVxLCAiIiwgLTEpOw0KK2RvbmU6DQorCXJldHVybiByZXRjb2RlOw0KK30NCkluZGV4OiBkZXYv ZHJtL2RybV9pcnEuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIGRldi9kcm0vZHJtX2lycS5jCShyZXZpc2lv biAxOTA0MzMpDQorKysgZGV2L2RybS9kcm1faXJxLmMJKHdvcmtpbmcgY29weSkNCkBAIC0zNDUs MTMgKzM0NSwxMSBAQA0KIAlzdHJ1Y3QgZHJtX21vZGVzZXRfY3RsICptb2Rlc2V0ID0gZGF0YTsN CiAJaW50IGNydGMsIHJldCA9IDA7DQogDQotCURSTV9ERUJVRygibnVtX2NydGNzPSVkXG4iLCBk ZXYtPm51bV9jcnRjcyk7DQogCS8qIElmIGRybV92YmxhbmtfaW5pdCgpIGhhc24ndCBiZWVuIGNh bGxlZCB5ZXQsIGp1c3Qgbm8tb3AgKi8NCiAJaWYgKCFkZXYtPm51bV9jcnRjcykNCiAJCWdvdG8g b3V0Ow0KIA0KIAljcnRjID0gbW9kZXNldC0+Y3J0YzsNCi0JRFJNX0RFQlVHKCJjcnRjPSVkXG4i LCBjcnRjKTsNCiAJaWYgKGNydGMgPj0gZGV2LT5udW1fY3J0Y3MpIHsNCiAJCXJldCA9IEVJTlZB TDsNCiAJCWdvdG8gb3V0Ow0KQEAgLTM2Niw3ICszNjQsNyBAQA0KIAkgKi8NCiAJc3dpdGNoICht b2Rlc2V0LT5jbWQpIHsNCiAJY2FzZSBfRFJNX1BSRV9NT0RFU0VUOg0KLQkJRFJNX0RFQlVHKCJw cmUtbW9kZXNldFxuIik7DQorCQlEUk1fREVCVUcoInByZS1tb2Rlc2V0LCBjcnRjICVkXG4iLCBj cnRjKTsNCiAJCWlmICghZGV2LT52YmxhbmtbY3J0Y10uaW5tb2Rlc2V0KSB7DQogCQkJZGV2LT52 YmxhbmtbY3J0Y10uaW5tb2Rlc2V0ID0gMHgxOw0KIAkJCWlmIChkcm1fdmJsYW5rX2dldChkZXYs IGNydGMpID09IDApDQpAQCAtMzc0LDcgKzM3Miw3IEBADQogCQl9DQogCQlicmVhazsNCiAJY2Fz ZSBfRFJNX1BPU1RfTU9ERVNFVDoNCi0JCURSTV9ERUJVRygicG9zdC1tb2Rlc2V0XG4iKTsNCisJ CURSTV9ERUJVRygicG9zdC1tb2Rlc2V0LCBjcnRjICVkXG4iLCBjcnRjKTsNCiAJCWlmIChkZXYt PnZibGFua1tjcnRjXS5pbm1vZGVzZXQpIHsNCiAJCQlEUk1fU1BJTkxPQ0soJmRldi0+dmJsX2xv Y2spOw0KIAkJCWRldi0+dmJsYW5rX2Rpc2FibGVfYWxsb3dlZCA9IDE7DQpAQCAtNDc3LDYgKzQ3 NSw5IEBADQogCQkJbXR4X3VubG9jaygmZGV2LT5pcnFfbG9jayk7DQogCQl9DQogDQorCQlpZiAo cmV0ID09IEVXT1VMREJMT0NLKQ0KKwkJCURSTV9FUlJPUigidGltZWQgb3V0IHdhaXRpbmcgb24g dmJsYW5rXG4iKTsNCisNCiAJCWlmIChyZXQgIT0gRUlOVFIgJiYgcmV0ICE9IEVSRVNUQVJUKSB7 DQogCQkJc3RydWN0IHRpbWV2YWwgbm93Ow0KIA0KSW5kZXg6IGRldi9kcm0vaTkxNV9pcnEuYw0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KLS0tIGRldi9kcm0vaTkxNV9pcnEuYwkocmV2aXNpb24gMTkwNDAyKQ0KKysr IGRldi9kcm0vaTkxNV9pcnEuYwkod29ya2luZyBjb3B5KQ0KQEAgLTIwNSw3ICsyMDUsNyBAQA0K IAlpaXIgPSBJOTE1X1JFQUQoSUlSKTsNCiANCiAJaWYgKElTX0k5NjVHKGRldikpIHsNCi0JCXZi bGFua19zdGF0dXMgPSBJOTE1X1NUQVJUX1ZCTEFOS19JTlRFUlJVUFRfU1RBVFVTOw0KKwkJdmJs YW5rX3N0YXR1cyA9IFBJUEVfU1RBUlRfVkJMQU5LX0lOVEVSUlVQVF9TVEFUVVM7DQogCQl2Ymxh bmtfZW5hYmxlID0gUElQRV9TVEFSVF9WQkxBTktfSU5URVJSVVBUX0VOQUJMRTsNCiAJfSBlbHNl IHsNCiAJCXZibGFua19zdGF0dXMgPSBJOTE1X1ZCTEFOS19JTlRFUlJVUFRfU1RBVFVTOw0KQEAg LTM0Myw2ICszNDMsNyBAQA0KIA0KIAlEUk1fREVCVUcoImlycV9ucj0lZCBicmVhZGNydW1iPSVk XG4iLCBpcnFfbnIsDQogCQkgIFJFQURfQlJFQURDUlVNQihkZXZfcHJpdikpOw0KKwlEUk1fREVC VUcoImllcjogJTA4eCwgaW1yOiAlMDh4XG4iLCBJOTE1X1JFQUQoSUVSKSwgSTkxNV9SRUFEKElF UikpOw0KIA0KIAlpOTE1X3VzZXJfaXJxX2dldChkZXYpOw0KIAlEUk1fV0FJVF9PTihyZXQsIGRl dl9wcml2LT5pcnFfcXVldWUsIDMgKiBEUk1fSFosDQo= --=-V02lBAxAJtiLQxV96XE9-- --=-HvemGFtbauss/A9uML9B 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) iEYEABECAAYFAknMF5gACgkQM4TrQ4qfROOAZACfTN8CukhonbkEpOgcWtb+uuEt dnUAni/P4hmUgZ6U2c01x1qokCfHK3sB =Knd0 -----END PGP SIGNATURE----- --=-HvemGFtbauss/A9uML9B--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1238112152.1777.6.camel>