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 will also try more of the suggested tests below. Thank you, Stefan On Tue, Nov 13, 2012 at 8:55 AM, matt <sendtom...@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 <sendtom...@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 > _______________________________________________ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
