Unable to boot Lenovo T520

[Jeremy Chadwick]

On Fri, Jun 10, 2011 at 04:48:31PM -0700, Xin LI wrote:
> 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.

I read the commit message -- sadly it also does not explain what the
numbers mean.  0xf000f859 and 0xf000e82e appear to be 32-bit vector
addresses (e.g. used for indirect JMP), except nobody explains where
those values came from or what they actually point to.  Therefore, they
are "magic values" until they can be defined otherwise.

Someone digging through the source code is not going to see the commit
message.  They're going to have to track it down by hand using cvsweb or
SVN, just to look at annotations.  Don't worry, I don't mean for this to
sound like I'm picking on this single commit -- this kind of craziness
is all over the FreeBSD source tree, and as I said, it's infuriating
when trying to look at the code (it is an open-source project, right?)
and figure out what's going on/why something is the way it is.

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, US |
| Making life hard for others since 1977.               PGP 4BD6C0CB |