From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 22 23:44:23 2008 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 642BF106566B; Wed, 22 Oct 2008 23:44:21 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Wed, 22 Oct 2008 19:44:08 -0400 User-Agent: KMail/1.6.2 References: <1224616985.00027652.1224606603@10.7.7.3> <48FF9925.4090007@FreeBSD.org> <48FF9AFA.3030201@root.org> In-Reply-To: <48FF9AFA.3030201@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200810221944.13406.jkim@FreeBSD.org> Cc: Alexander Motin , freebsd-amd64@freebsd.org Subject: Re: Semi-working patch for amd64 suspend/resume 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: Wed, 22 Oct 2008 23:44:23 -0000 On Wednesday 22 October 2008 05:28 pm, Nate Lawson wrote: > Alexander Motin wrote: > > Jung-uk Kim wrote: > >> When you do 'sysctl debug.acpi.suspend_bounce=1' and 'acpiconf > >> -s 3', does it bounce back? If it does not, there are other > >> problems, e.g., device drivers. On my desktop, for example, > >> vga(4) tries to restore previous state while resuming but it > >> hangs system. In fact, I believe ISA-era EGA/VGA save/restore > >> routines do not work for modern graphics cards at all. :-( > > > > Test passed from both console and XOrg. I have integrated i965GM > > video. > > > > Here is verbose messages from that trip "there and back again": > > > > Oct 23 00:11:55 mavbook acpi: suspend at 20081023 00:11:55 > > > > Oct 23 00:12:00 mavbook kernel: vga0: saving 68 bytes of video > > state Oct 23 00:12:00 mavbook kernel: pci0:0:2:0: Transition from > > D0 to D3 Oct 23 00:12:00 mavbook kernel: pci0:0:2:1: Transition > > from D0 to D3 Oct 23 00:12:00 mavbook kernel: pci0:0:26:7: > > Transition from D0 to D3 Oct 23 00:12:00 mavbook kernel: acpi: > > bad write to port 0x080 (32), val 0xbb > > Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition from D0 > > to D3 Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: Transition > > from D0 to D3 > > > > Oct 23 00:12:06 mavbook kernel: pci0:0:2:0: Transition from D3 to > > D0 Oct 23 00:12:06 mavbook kernel: pci0:0:2:1: Transition from D3 > > to D0 Oct 23 00:12:06 mavbook kernel: acpi: bad write to port > > 0x080 (32), val 0xaa > > Oct 23 00:12:06 mavbook kernel: pci0:0:26:7: Transition from D3 > > to D0 Oct 23 00:12:06 mavbook kernel: pci0:0:27:0: Transition > > from D3 to D0 Oct 23 00:12:06 mavbook kernel: pci0:0:31:2: > > Transition from D3 to D0 > > That's kind of weird. The above devices were turned off (D3) then > back on again (D0). I'm wondering about that blocked write also. The port 0x80 is usually used for BIOS debugging. http://www.coreboot.org/FAQ#POST_card Probably BIOS developer forgot to comment out the lines. :-) Jung-uk Kim