From owner-svn-src-stable-9@FreeBSD.ORG Tue Apr 10 17:13:19 2012 Return-Path: Delivered-To: svn-src-stable-9@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id ECF101065675; Tue, 10 Apr 2012 17:13:18 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Gavin Atkinson Date: Tue, 10 Apr 2012 13:13:07 -0400 User-Agent: KMail/1.6.2 References: <201204021813.q32IDTmf009879@svn.freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204101313.09608.jkim@FreeBSD.org> Cc: svn-src-stable@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, svn-src-stable-9@FreeBSD.org Subject: Re: svn commit: r233797 - in stable/9/sys: amd64/conf i386/conf X-BeenThere: svn-src-stable-9@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for only the 9-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 17:13:19 -0000 On Monday 09 April 2012 07:01 pm, Gavin Atkinson wrote: > On Mon, 2 Apr 2012, Jung-uk Kim wrote: > > Author: jkim > > Date: Mon Apr 2 18:13:29 2012 > > New Revision: 233797 > > URL: http://svn.freebsd.org/changeset/base/233797 > > > > Log: > > MFC: r232416, r232561 > > > > Add VESA option to GENERIC for amd64 and i386. > > This commit breaks resume for me on an IBM ThinkPad X60 running > i386 9.0. Removing VESA from the kernel again fixes resume. On > resume, I get this panic: > http://people.freebsd.org/~gavin/IMAG0881.jpg . I've tested it on > head, and get the same panic with VESA in the kernel. From the > debugger, "show registers" gives: > cs 0xc000 > ss 0x28 > edx 0x80 > esp 0xc1821fe8 > eip 0xe44f > efl 0xb0202 > with all other registers are zero. > Unfortunately, I don't know what other information I can get from > this panic. The backtrace gives no useful information, and the IP > is not within kernel space. The address is for VM86 call for video BIOS (i.e., 16-bit real mode) and it is trying to access 0x1000, which is not in the mapped address range. I have heard that some broken IBM/Lenovo BIOSes may do something like this, unfortunately. Probably we should map the whole first page for that to work around it. I'll write a patch for that and let you know privately. > BTW, this machine used to require hw.acpi.reset_video=1, but no > longer appears to require this. However, whether this is set or > not appears to make no difference to the panic above. "hw.acpi.reset_video" tunable is dangerous and deprecated. VESA module does it more safely and that's why I added it by default. :-) Jung-uk Kim