From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 27 18:04:22 2012 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 79DE3106566C; Mon, 27 Feb 2012 18:04:21 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-acpi@FreeBSD.org Date: Mon, 27 Feb 2012 13:03:50 -0500 User-Agent: KMail/1.6.2 References: <4F4AA530.4030606@shadowsun.net> In-Reply-To: <4F4AA530.4030606@shadowsun.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202271304.09523.jkim@FreeBSD.org> Cc: Subject: Re: Suspend/resume on Macbooks: partial diagnosis 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: Mon, 27 Feb 2012 18:04:22 -0000 On Sunday 26 February 2012 04:33 pm, Eric McCorkle wrote: > A while ago, I tried to diagnose the reason why suspend/resume > doesn't work on my macbook (9.0-STABLE, 13' unibody macbook pro, > 5,5, I think). I got a partial answer, but then got busy and never > finished. The recent KDE update apparently triggers a suspend, so > I had incentive to look at it again, and also to report my previous > findings, in case someone else has information or can fix it. Can you please show us more detail, e.g., "devinfo -rv", "pciconf -lv", verbose dmesg, etc? > Here's what I have: > > The USB system sometimes fails to come back up, but this seems to > be a more general issue not specific to the hardware. The firewire > system would also sometimes trigger a kernel panic, but that was > almost a year ago on 9-CURRENT, and firewire was causing other > issues, so I disabled it and haven't used it since. These are very common issues, unfortunately. :-( > The VGA system fails to come back up, reporting "vga0: failed to > reload state". I traced this error using extra logging messages to > the BIOS POST call, at which point the x86emu system emulates the > bios. From looking at the error message, disassembly of the BIOS > code, and the memory map I am almost certain I know why. I'd meant > to confirm it 100%, but I got busy. Actually, the error message has nothing to do with BIOS POST call. Do you have NVIDIA GPU on it? > The root problem seems to be bad BIOS code that accesses the stack > one word above the region allocated by the BIOS memory map (the map > allocates 0x1000-0x1fff, the code dereferences 0x2000, or something > similar). This is *technically* an error, but it does not cause a > problem during boot, because there is always good memory at that > address. The BIOS emulation system, however, seems to only > allocate the regions described by the memory map, and thus treats > it as an error (as a strictly-conforming BIOS implementation > would). > > A quick-and-dirty fix might be to add an extra page above the stack > region. I'm not sure what a more "legitimate" fix might be, since > it's the BIOS code and not FreeBSD that's causing the problem. > I'll probably take a closer look in the near future. x86bios virtualizes real-mode memory and invalid memory access immedidately halts the emulator. In other words, it shouldn't happen. ;-) Jung-uk Kim