From owner-freebsd-current Wed Mar 19 13:58:54 2003 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 103D137B401 for ; Wed, 19 Mar 2003 13:58:53 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52DEA43F85 for ; Wed, 19 Mar 2003 13:58:49 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.8/8.12.8) with ESMTP id h2JLwmRv010844 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 19 Mar 2003 16:58:48 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h2JLwhg02568; Wed, 19 Mar 2003 16:58:43 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15992.59411.447270.923913@grasshopper.cs.duke.edu> Date: Wed, 19 Mar 2003 16:58:43 -0500 (EST) To: Nate Lawson Cc: freebsd-current@freebsd.org Subject: Re: secondary ACPI problems In-Reply-To: References: <15867.45188.294955.716962@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate Lawson writes: > On Sat, 14 Dec 2002, Andrew Gallatin wrote: > > This does not happen if I do not have rp.ko loaded. I suspect that > > the rocketport card needs some setup when power is restored. It > > polls all its ports, so it makes sense that a swi would get clogged. > > > > I thought it might be sufficent to unload the driver and reload after > > resume. However, it doens't appear to be unloadable now. > > > > Before I get too far into this, will unloading rp and reloading it > > suffice, or is there a better way which could just allow me to save > > and restore the card state so I wouldn't have to reload it on resume? > > See the device_suspend/resume implementations in various drivers > (i.e. rl(4)). Wow, what a blast from the past! ;) Shouldn't a driver without a suspend/resume implementation implicitly veto the suspend? That's how OS-X does it. Anyway, I'll worry about this when/if somebody can tell me how to get my video back after suspending to S3: none2@pci1:0:0: class=0x030000 card=0x7106174b chip=0x54461002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies' device = 'Rage 128 Pro AGP 4x' class = display Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message