Date: Fri, 17 Oct 2003 10:25:45 -0700 (PDT) From: Nate Lawson <nate@root.org> To: acpi-jp@jp.FreeBSD.org Cc: freebsd-current@freebsd.org Subject: Re: [acpi-jp 2745] ACPI, USB, and the tangled web Message-ID: <20031017101531.H41079@root.org> In-Reply-To: <200310162152.22187.mistry.7@osu.edu> References: <200310162152.22187.mistry.7@osu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 16 Oct 2003, Anish Mistry wrote: > -----BEGIN PGP SIGNED MESSAGE----- Um, that's great. :) > First off, if you've been following my dabbling in fixing the USB resume > problem on my laptop you know that I have been plauged by the infamous > restart on second suspend with a usb device being accessed during the second > suspend (ie. wiggling mouse). Yesterday after finally updating to a current > that boots my system after a couple of weeks without it I suspended the > system and resumed it to check some ACPI issues had been fixed, but that's > for another time. After resume I realized I needed my mouse, so I plugged it > in, dynamically loaded the kernel module and the mouse worked (normal/ > previous). Then I suspend the laptop and was wiggling the mouse while it was > suspending (bad habit from testing) and the system REBOOTED, and my patches > weren't even applied! The problem is USB although ACPI magnifies it. USB devices can generate wake events. In my current testing of a new acpi_cpu driver, I've found that just having the USB bus enabled in the kernel (with no devices attached) causes it to generate a steady stream of bm_sts sets even though the laptop is completely idle. Try disabling usb in your kernel config and see if it helps your laptop not wake up. If that works, we've narrowed it down a little. You can also try setting debug.acpi.avoid to USB_ to try to get it to avoid evaluating that namespace. I'll probably get around to looking at the USB issue at some point. There's a lot of work needed there: suspend/resume for *hci, possibly avoiding setting acpi wake events on usb, etc. > There seems to be some ACPI problem, since I just tested the same procedure > on with ACPI disabled and there was no reboot. How were you able to test that with it disabled? Were you suspending with apm instead? -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031017101531.H41079>