Sleep/resume in FreeBSD 9 on a ThinkPad

[Ian Smith]

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 at 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 at 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 at 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