Re: Boot halts on Thinkpad X220 (Sandy Bridge)

From: Xin LI <delphij_at_gmail.com>
Date: Mon, 6 Jun 2011 12:00:24 -0700
On Tue, May 31, 2011 at 5:03 PM, Jung-uk Kim <jkim_at_freebsd.org> wrote:
[...]
> 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)
> _at__at_ -1100,7 +1100,8 _at__at_ 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 _at_ 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).

Sorry for the delay.  I finally got a copy of (U)EFI spec and found
the requirement of fixed entry there.

Option #1 sounds like a good idea to me too (if the "BIOS" can break
one rule, it can also break more).  Could you please commit the change
(maybe revert mine before that?) and merge it back to -STABLE?

Thanks for your time on investigating this!

Cheers,
-- 
Xin LI <delphij_at_delphij.net> http://www.delphij.net
Received on Mon Jun 06 2011 - 17:00:26 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:14 UTC