Date: Tue, 10 Apr 2012 13:13:07 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Gavin Atkinson <gavin@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 Message-ID: <201204101313.09608.jkim@FreeBSD.org> In-Reply-To: <alpine.LNX.2.00.1204092152260.9103@ury.york.ac.uk> References: <201204021813.q32IDTmf009879@svn.freebsd.org> <alpine.LNX.2.00.1204092152260.9103@ury.york.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201204101313.09608.jkim>