From owner-freebsd-current@FreeBSD.ORG Fri Jun 20 06:44:25 2003 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 6998237B401 for ; Fri, 20 Jun 2003 06:44:25 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id A20BC43FBD for ; Fri, 20 Jun 2003 06:44:22 -0700 (PDT) (envelope-from freebsd-current@m.gmane.org) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19TMBZ-0000Ol-00 for ; Fri, 20 Jun 2003 15:44:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19TMBX-0000OU-00 for ; Fri, 20 Jun 2003 15:44:11 +0200 From: Jesse Guardiani Date: Fri, 20 Jun 2003 09:44:18 -0400 Organization: WingNET Lines: 87 Message-ID: References: <200306191916.MAA15640@mina.soco.agilent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@main.gmane.org User-Agent: KNode/0.7.2 X-Mail-Copies-To: never Sender: news Subject: Re: APM problem in 5.1-RELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jesse@wingnet.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2003 13:44:25 -0000 Jesse Guardiani wrote: > Jesse Guardiani wrote: > >> Jesse Guardiani wrote: >> >>> Darryl Okahata wrote: >>> >>>> Jesse Guardiani wrote: >> >> [...] >> >>> Now, if I can just get that lousy CD-ROM to not crash my system on >>> resume I'll be a VERY happy man... I did some more testing on this last night, and it appears that the atacontrol detach method _does_ work, but only in specialized circumstances. I have modified my /etc/rc.suspend to call 'atacontrol detach 1' _before_ it calls 'apm -z'. I have also modified my /etc/rc.resume to call 'atacontrol attach 1' _after_ syncing the disks. If anyone wants to have a look at these files, just let me know. When it works: -------------- 1.) I have to be looking at a VTY, not X. (Geez. Just when I thought I got around this with the kernel option SC_NO_SUSPEND_VTYSWITCH...) 2.) The /dev/acd0 device has to be unused, otherwise the kernel panics. This means I have to stop playing any CDs and terminate the CD playing program. I assume this means that the device has to be _not_ open, but I haven't really performed much testing in this area. When it doesn't work: --------------------- 1.) If I try to suspend while looking at X, the kernel panics and auto- reboots. 2.) If I try to suspend while anything is accessing the acd0 device the kernel panics and auto-reboots. Those things aside, I can usually suspend my machine within 8 seconds, as long as the hard disk isn't under high load. And it comes back on-line in under 3 seconds. I've tested this 6 or 7 times in a row, swapping back and forth from X before doing the next suspend, so I'm pretty confident that it's reliable. A plus is that the little green "drive in use" light on the side of my Ultrabay goes off when the machine is in suspend mode, and since I call: atacontrol attach 1 Upon resume from suspend, I could very easily swap out my drives while in suspend mode. I've tested this. Pretty neat! Things I would like to improve upon: ------------------------------------ 1.) I need to find some way to automatically kill any processes that are using (or have opened) the /dev/acd0 device BEFORE executing apm -z from /etc/rc.suspend. If I can accomplish that, then I will have successfully eliminated the "stupid human" factor that sometimes causes me to forget I have a program running that uses the /dev/acd0 device. Does anyone have any ideas here? 2.) I'd love to automate (or do away with) the process of switching to a VTY from X before executing 'atacontrol detach 1'. Can anyone give me a _reason_ why I have to do that? It just seems odd to me. Thanks! -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net