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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:45 UTC