Skip site navigation (1)Skip section navigation (2)
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>