Date: Fri, 16 Nov 2012 16:32:15 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Stefan Horomnea <stefan.horomnea@gmail.com> Cc: freebsd-acpi@freebsd.org Subject: Re: Sleep/resume in FreeBSD 9 on a ThinkPad Message-ID: <20121116160823.M72475@sola.nimnet.asn.au> In-Reply-To: <CAN3YWja4yApP9UEJbP2yjGMwXiY4S=VrGW=9T-Hcw3ReTypD6w@mail.gmail.com> References: <CAN3YWjYAPGny1f0zC0axfhOm3DTTTos8vAJejB2C83vop7Skqg@mail.gmail.com> <50A12DF9.8090107@gmail.com> <CAN3YWjbA62_Vcx3Wsvqg=3dfMwTfo3LLK=BRq6ZMTFwBG-xNSQ@mail.gmail.com> <50A1FCEC.9020404@gmail.com> <CAN3YWja4yApP9UEJbP2yjGMwXiY4S=VrGW=9T-Hcw3ReTypD6w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 14 Nov 2012 00:09:38 +0100, Stefan Horomnea wrote: > Hi, > > Thanks for your suggestions, so I have a couple more tests to try. > I have just tried with: > sysctl debug.bootverbose=1 > sysctl debug.acpi.suspend_bounce=1 > > And the monitor switches a bit to the terminal, and then gets back to X, so > I guess is suppose to do that. How do I get the needed information after > that ? Run dmesg ? > I just ran dmesg and got: > https://www.dropbox.com/s/lro38v935vpnxn6/dmesg-sleep-bounce.txt > I really don't know how to read/interpret dmesg messages, so I can't tell > what's happening, how the sleep process happens, if it shows why it fails, > etc. > But I can spot as being errors are some lines like this: > ubt0: ubt_intr_read_callback:767: interrupt transfer failed: USB_ERR_STALLED > > should this be the cause, or other ? I picked this message out of the whole thread due to seeing this error message. I've also read the thread honestqiao@gmail.com refers to, and in the light of your more recent message about hearing the continuous piercing beep after attempting to resume with debug.acpi.resume_beep=1, I can suggest something you might want to try. I had a similar problem on my older Thinkpad T23 from 8.0 to 8.2, except after (exactly) 60 seconds of waiting, or waiting through the piercing resume beep, it would come good. I presume you've waited at least that long sometimes? In my case it turned out to be an issue with the uhci driver, which was resolved by a) building a kernel without uhci, ohci or ehci (and for USB 3 I expect xhci too) but leaving USB itself otherwise alone. Here: # 7/7/11 test just the theory that uhci causes the 60-second resume stall include GENERIC ident NO_UHCI # load on boot, unload/reload around suspend/resume nodevice uhci # UHCI PCI->USB interface # not used nodevice ohci # OHCI PCI->USB interface # not used, USB 1 only nodevice ehci # EHCI PCI->USB interface (USB 2.0) b) adding to /etc/rc.suspend: # If a device driver has problems suspending, try unloading it before # suspend and reloading it on resume. Example: # kldunload usb #% 9/7/11 it works! kldunload uhci #% 4/11/11 playing with usb 2.0 pccard, uses ehci on ohci kldunload ehci kldunload ohci and c) adding to /etc/rc.resume the complementary: # If a device driver has problems resuming, try unloading it before # suspend and reloading it on resume. Example: # kldload usb #% 9/7/11 it works! kldload uhci #% 4/11/11 playing with usb 2.0 pccard, uses ehci on ohci kldload ohci kldload ehci Now, this was supposed to have been fixed, I thought, but as I'm still happily running 8.2R for my $realwork, I haven't tried again on 9.x, or even 8.3. This could be completely unrelated to your problem - others have mentioned unloading video drivers instead, etc - but seeing you're desperate, it might be worth a try. FWIW, I looked into the resume code, and resume beep, when enabled, is turned on very early in the resume cycle, and cleared upon success, so your stall or hang is for sure occurring while trying to resume. cheers, Ian > I will also try more of the suggested tests below. > > Thank you, > Stefan > > On Tue, Nov 13, 2012 at 8:55 AM, matt <sendtomatt@gmail.com> wrote: > > > On 11/12/12 23:13, Stefan Horomnea wrote: > > > Hi, > > > > > > I have tried with 1 and then 0 to both settings (hw.pci.do_power_suspend > > > and hw.pci.do_power_resume) but with no luck, it does the same. > > > What happens is, after executing the sleep command, I hear a short beep, > > > the power button blinks rapidly three times, and then monitor, hdd, stop, > > > and the power button pulses as you say, at a slow pace, like it went to > > > sleep. But when I wake it, it reboots. > > > > > > Thanks for your suggestion anyway. Any other suggestions ? > > > > > > Stefan > > > > > > On Mon, Nov 12, 2012 at 6:12 PM, matt <sendtomatt@gmail.com> wrote: > > > > > > > > That sounds quite odd...unfortunately I think the L series is only > > cosmetically similar to the SL series. I gave it away, so I can't test > > with it anymore to see if it's a recent change. > > > > Try debug.acpi.suspend_bounce=1 and try to suspend. This will either > > work with no problems, work with a lot of kernel printf errors, or > > reboot. I think the result of that would be interesting. > > Try debug.acpi.resume_beep=1 (with suspend_bounce cleared) and try > > again...does it beep before rebooting? > > > > With my SL410, I also went into the bios and disabled everything I > > didn't use (although it didn't help). You could also try sending > > power_off to usb devices manually with usbconfig, and setting > > hw.pci.do_power_nodriver=3 > > > > debug.acpi.reset_video actually caused a similar problem for me on my > > x220, so make sure it's off as well (I doubt you have it on, but it's > > worth a mention given the symptoms) > > > > Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121116160823.M72475>