Unable to boot Lenovo T520

[Xin LI]

On Fri, Jun 10, 2011 at 4:42 PM, Jeremy Chadwick
<freebsd at jdc.parodius.com> wrote:
> On Fri, Jun 10, 2011 at 04:15:56PM -0700, Xin LI wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> On 06/10/11 15:15, Kevin Oberman wrote:
>> > I am hitting the problem reported some time ago with atkbd and svn
>> > 197392.
>> >
>> > It's not clear that this has ben finally resolved, but I am still
>> > hitting it with -stable on my new T520. I really want to get FreeBSD up
>> > on it, but I am dead in the water at this time. I guess I'll have to
>> > build a new kernel with any fix and replace the kernel in the ISO.
>> >
>> > Also, I am hoping to use it on an amd64 kernel and I am even less sure
>> > that any patch will work on that arch.
>> >
>> > The original thread was
>> > http://freebsd.1045724.n5.nabble.com/svn-rev-197392-hangs-during-boot-td3926276.html
>>
>> The fix was not (yet) merged back to 8-STABLE.  You may use a
>> 8.0-RELEASE kernel to boot the system temporarily and apply this patch:
>>
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/atkbdc/atkbd.c.diff?r1=1.63;r2=1.64
>>
>> (If hunk #1 fails to apply, it's Ok to just ignore it).
>
> Specifically:
>
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/atkbdc/atkbd.c#rev1.64
>
> -       if (x86bios_get_intr(0x15) == 0 || x86bios_get_intr(0x16) == 0)
> +       if (x86bios_get_intr(0x15) != 0xf000f859 ||
> +           x86bios_get_intr(0x16) != 0xf000e82e)
>
> What are these magic numbers?  Where did they come from?  What do they
> represent?  Why are they not documented in the source code/commit
> itself?  No offence, but this is an open-source project; anyone looking
> at this code isn't going to know what those vectors represent.  The
> commit message is also lacking (again: magic values not mentioned), and
> expecting a developer to dig through commits/annotations to determine
> what this piece of code is for is unreasonable.
>
> No I'm not in a bad mood (honest!), I just find this kind of thing
> infuriating the more I dig through kernel source code.

The commit log explicitly say:

Validate INT 15h and 16h vectors more strictly.  Traditionally these entry
points are fixed addresses and (U)EFI CSM specification also mandated that.
Unfortunately, (U)EFI CSM specification does not specifically mention this
is to call service routine via interrupt vector table or to jump directly
to the entry point.  As a result, some CSM seems to install two routines
and acts differently, depending on how it was executed, unfortunately.
When INT 15h is used, it calls a function pointer (which is probably a UEFI
service function).  When it jumps directly to the entry point, it executes
a simple and traditional INT 15h service routine.  Therefore, actually there
are two possible fixes, i. e., this fix or jumping directly to the fixed
entry point.  However, we chose this fix because a) keyboard typematic
support via BIOS is becoming extremely rarer and b) we cannot support random
service routine installed by a firmware or a boot loader.  This should fix
Lenovo X220 laptop, specifically.

Be reasonable, please.

Cheers,
-- 
Xin LI <delphij at delphij.net> http://www.delphij.net