Boot halts on Thinkpad X220 (Sandy Bridge)

[Jung-uk Kim]

On Tuesday 31 May 2011 04:50 pm, Jung-uk Kim wrote:
> On Friday 27 May 2011 01:14 pm, Xin LI wrote:
> > On Thu, May 19, 2011 at 5:18 AM, Johannes Dieterich
> >
> > <dieterich.joh at googlemail.com> wrote:
> > > On Wed, May 18, 2011 at 7:40 PM, Xin LI <delphij at delphij.net>
>
> wrote:
> > >> -----BEGIN PGP SIGNED MESSAGE-----
> > >> Hash: SHA256
> > >>
> > >> Try this patch?
> > >
> > > The attached patch makes 9-CURRENT-amd64 boot on the X220 w/o
> > > any hints or BIOS fixes needed. Thanks a lot! :-)
> > >
> > >> (I'm still opted to disable the typematic rate detection by
> > >> default at least for amd64, as we don't do it in the past for
> > >> amd64)
> > >
> > > What does this mean concerning getting the fix into CURRENT?
> >
> > Well, that's not a perfect fix and we do lose the ability of
> > detecting typematic rate (by default), so technically it's a
> > workaround (sufficient to make the kernel boot and work, though)
> > and doesn't fix anything.
> >
> > I have committed it anyway since we do not have better fix (yet),
> > and have updated atkbd(4) manual page so one can enable it again
> > when wanted.
> >
> > The problem we had was that it seems that running the BIOS in the
> > x86emu emulator on amd64 would cause problem.  This doesn't seem
> > to be fixable without hands-on experiments on a system in
> > question, it's either a BIOS bug or an emulator bug.  The strange
> > part of the problem is that the functionality is quite common in
> > the Good Old Days (TM).
>
> I got BIOS dump from gnn last week.  I've been scratching my head
> cause it should just fail and exit gracefully unless I am totally
> missing something. :-(
>
> Are you guys sure that INT 15h is causing hangs?  Maybe INT 16h is
> the real culprit (which is more probable, BTW)?

I found something strange about this BIOS (well, if we can call it 
that).  Please try this:

Index: sys/dev/atkbdc/atkbd.c
===================================================================
--- sys/dev/atkbdc/atkbd.c	(revision 222550)
+++ sys/dev/atkbdc/atkbd.c	(working copy)
@@ -1100,7 +1100,8 @@ get_typematic(keyboard_t *kbd)
 	if (!(kbd->kb_config & KB_CONF_PROBE_TYPEMATIC))
 		return (ENODEV);
 
-	if (x86bios_get_intr(0x15) == 0 || x86bios_get_intr(0x16) == 0)
+	if (x86bios_get_intr(0x15) != 0xf000f859 ||
+	    x86bios_get_intr(0x16) != 0xf000e82e)
 		return (ENODEV);
 
 	/* Is BIOS system configuration table supported? */

You must re-enable typematic probing from loader to test it, of 
course.  I think the following line should do:

hint.atkbd.0.flags="0x10"

Note: You may add printf() before and after the check to make sure it 
is being called (and it fails immediately).

A long answer goes like this.  INT 0x15 and 0x16 vectors have fixed 
entry points in *real* BIOS, i.e., 0xf000:0xf859 and 0xf000:0xe82e.  
For this BIOS (or CSM), INT 0x16 vector is correct but INT 0x15 
vector is not (0xf000:0xb4f1).  Funny thing is 0xf000:0xf859 actually 
points to a working INT 15h handler, it seems, which confused me 
totally.  Probably it was done like this because (U)EFI CSM spec. 
mandated it to be located @ 0xf000:0xf859.  If we follow the 
interrupt vector (0xf000:0xb4f1), it gets nowhere (or jumps to an 
unknown external interrupt handler).  If we follow the fixed address, 
it will exit gracefully.  So, actually there are two possible 
solutions, i.e., 1) check whether the interrupt vector is modified 
(the above patch), or 2) jump directly to the fixed interrupt entry 
point.  I chose Option #1 because it is very hard to find BIOS 
typematic support these days (as you pointed out).

Cheers,

Jung-uk Kim