From owner-freebsd-current Wed Mar 19 14:10:32 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 EBF5137B401 for ; Wed, 19 Mar 2003 14:10:30 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 5D17D43F3F for ; Wed, 19 Mar 2003 14:10:30 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 12716 invoked by uid 1000); 19 Mar 2003 22:10:31 -0000 Date: Wed, 19 Mar 2003 14:10:31 -0800 (PST) From: Nate Lawson To: Andrew Gallatin Cc: freebsd-current@freebsd.org Subject: Re: secondary ACPI problems In-Reply-To: <15992.59411.447270.923913@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Wed, 19 Mar 2003, Andrew Gallatin wrote: > 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! ;) I am trying to eliminate a backlog of email. I can only manage actually reading cvs-src and developers it seems. > Shouldn't a driver without a suspend/resume implementation implicitly > veto the suspend? That's how OS-X does it. Currently the default is null_suspend which returns 0 (i.e. "ok"). You could create a new default, refuse_suspend and then go to all drivers and add an explicit call to null_suspend but I'm not sure this is the best idea. > 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 Sorry, I have no knowledge of video hw except that it does need to be reset on suspend. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message