From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 27 05:39:51 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0046B16A400 for ; Tue, 27 Feb 2007 05:39:50 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id D003713C4B3 for ; Tue, 27 Feb 2007 05:39:50 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 38436 invoked from network); 27 Feb 2007 05:39:36 -0000 Received: from ppp-71-139-18-69.dsl.snfc21.pacbell.net (HELO ?10.0.5.55?) (nate-mail@71.139.18.69) by root.org with ESMTPA; 27 Feb 2007 05:39:36 -0000 Message-ID: <45E3C420.4090208@root.org> Date: Mon, 26 Feb 2007 21:39:44 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: drgerlists@gmail.com References: <45e3bc0e.ysCcBQJVFan8KBpdQmS3zu1U@lmrmac.uhw.utoledo.edu> In-Reply-To: <45e3bc0e.ysCcBQJVFan8KBpdQmS3zu1U@lmrmac.uhw.utoledo.edu> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: No ad0 following ACPI Resume on Toshiba Sat Pro 6100/6.2-R ? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2007 05:39:51 -0000 Dr. Gary E. RAFE wrote: > Having yet another look at ACPI Suspend/Resume > on my Toshiba Satellite Pro 6100 now running 6.2-R. > > The system goes into Suspend-to-Ram state OK, > but the resume-on-power-switch-actuation fails > with a kernel panic. > > I don't know where to look next at this; > hints & suggestions from the experts are welcome. > > Note that I had the same behavior under 6.1-R, > and that APM Suspend/Resume works reliably on this hardware. In apm, the bios reinitializes a lot of devices, including ata in your case. > This looks alot like the problem reported by > A. Scherbanov in a recent freebsd-current message > Yes, this looks like an ata problem. I forwarded it on to an ata person, and maybe he can help. > wakeup from sleeping state (slept 00:01:08) > ata0: reiniting channel .. > ata0: reset tp1 mask=03 ostat0=80 ostat1=80 > ata0: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0: stat0=0x80 err=0x80 lsb=0x80 msb=0x80 > ata0: stat0=0x50 err=0x00 lsb=0xfe msb=0x3f > ata0: stat1=0x00 err=0x00 lsb=0xfe msb=0x3f > ata0: reset tp2 stat0=50 stat1=00 devices=0x0 > subdisk0: detached <== That can't be right ! > ad0: detached <== That can't be right ! > ata0: reinit done .. > ata1: reiniting channel .. > ata1: reset tp1 mask=03 ostat0=50 ostat1=00 > ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: stat1=0x00 err=0x04 lsb=0x00 msb=0x00 > ata1: reset tp2 stat0=00 stat1=00 devices=0x4 All the below errors are due to the drive disappearing, as you point out. > g_vfs_done():ad0s2a[WRITE(offset=10314055680, length=10240)]error = 6 > (... message repeated another 9 times here ...) > acd0: setting PIO4 on ICH3 chip > acd0: setting UDMA33 on ICH3 chip > ata1: reinit done .. > battery0: battery initialization start > battery0: battery initialization done, tried 1 times > battery1: battery initialization start > atkbd: the current kbd controller command byte 0065 > atkbd: keyboard ID 0x41ab (2) > kbdc: RESET_KBD return code:00fa > kbdc: RESET_KBD status:00aa > g_vfs_done():ad0s2a[READ(offset=10256183296, length=2048)]error = 6 > panic: vinvalbuf: dirty bufs > Uptime: 58s > Cannot dump. No dump device defined. > Automatic reboot in 15 seconds - press a key on the console to abort > --> Press a key on the console to reboot, > --> or switch off the system now. > Rebooting... -- Nate