From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 13:45:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4FDB16A4CE for ; Fri, 2 Jan 2004 13:45:17 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id D0E5843D39 for ; Fri, 2 Jan 2004 13:45:16 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 9934 invoked by uid 1000); 2 Jan 2004 21:45:18 -0000 Date: Fri, 2 Jan 2004 13:45:18 -0800 (PST) From: Nate Lawson To: Lukas Ertl In-Reply-To: <20031230211930.K64407@leelou.in.tern> Message-ID: <20040102134132.W9534@root.org> References: <20031230115806.M98869@root.org> <20031230211930.K64407@leelou.in.tern> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi-jp@jp.freebsd.org cc: current@freebsd.org Subject: Re: rc.suspend/rc.resume acpi support added X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2004 21:45:17 -0000 On Tue, 30 Dec 2003, Lukas Ertl wrote: > On Tue, 30 Dec 2003, Nate Lawson wrote: > > This helps for uhci where we have to unload and reload usb.ko across > > suspends since it doesn't re-initialize correctly. See the usb comments > > in the files for an example. > > If I understand correctly, usb.ko can't be unloaded, because it has no > detach method connected. (At least I wasn't able to unload it.) > > Anyway, this bandaid wouldn't work on this machine, since I tried to load > the usb module after a suspend and UHCI still wouldn't work (see > kern/59747) - it seems like all controller register bits are set, and I > couldn't find a way to clear them. Oops, you're right. It may help for sound drivers though. > The UHCI controller works fine with APM suspend, though. That's because the BIOS does all the reinitialization in the APM case. The biggest issue with ACPI suspend/resume is that suddenly all of our device drivers are responsible for detecting the state of various hardware (from uninitialized to various partially-initialized states) and restoring the rest. Like the kid's game "Operation", poking a register that already has been initialized or neglecting to restore something the BIOS no longer handles makes the driver inoperable (i.e. uhci) or worse, breaks resume (i.e. many video drivers). It would be great if each driver author would go back to the datasheet and make sure they're doing things correctly and not relying on the BIOS. -Nate