Unable to boot Lenovo T520

[Xin LI]

On Fri, Jun 10, 2011 at 5:59 PM, Jeremy Chadwick
<freebsd at jdc.parodius.com> wrote:
> 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.

I'm not in good mood and I find it a waste of my time, sorry for that.
 I have committed a fix (r222967).

Just want to say that Jung-uk have spend a lot of his time
investigating and fixing this issue, and I just don't see why people
typing that much doesn't want to submit a patch.  I think Open Source
projects expect everyone there to contribute rather than asking
someone else to do the work.

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