Date: Fri, 10 Jun 2011 18:24:51 -0700 From: Xin LI <delphij@gmail.com> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-stable@freebsd.org Subject: Re: Unable to boot Lenovo T520 Message-ID: <BANLkTin9BoVnC15kNKd5DioV0EjXpXoSzA@mail.gmail.com> In-Reply-To: <20110611005951.GA55990@icarus.home.lan> References: <20110610221525.A1C791CC0B@ptavv.es.net> <4DF2A5AC.6070804@delphij.net> <20110610234227.GA54846@icarus.home.lan> <BANLkTikfyEmkGsKm_rWrBsPJ6p-w1av6mw@mail.gmail.com> <20110611005951.GA55990@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jun 10, 2011 at 5:59 PM, Jeremy Chadwick <freebsd@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@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 FreeBS= D up >> >> > on it, but I am dead in the water at this time. I guess I'll have t= o >> >> > 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 s= ure >> >> > that any patch will work on that arch. >> >> > >> >> > The original thread was >> >> > http://freebsd.1045724.n5.nabble.com/svn-rev-197392-hangs-during-bo= ot-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 patc= h: >> >> >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/atkbdc/atkbd.c.diff= ?r1=3D1.63;r2=3D1.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) =3D=3D 0 || x86bios_get_intr(0x1= 6) =3D=3D 0) >> > + ?? ?? ?? if (x86bios_get_intr(0x15) !=3D 0xf000f859 || >> > + ?? ?? ?? ?? ?? x86bios_get_intr(0x16) !=3D 0xf000e82e) >> > >> > What are these magic numbers? ??Where did they come from? ??What do th= ey >> > represent? ??Why are they not documented in the source code/commit >> > itself? ??No offence, but this is an open-source project; anyone looki= ng >> > at this code isn't going to know what those vectors represent. ??The >> > commit message is also lacking (again: magic values not mentioned), an= d >> > 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. =C2=A0Traditionally thes= e entry >> points are fixed addresses and (U)EFI CSM specification also mandated th= at. >> Unfortunately, (U)EFI CSM specification does not specifically mention th= is >> is to call service routine via interrupt vector table or to jump directl= y >> to the entry point. =C2=A0As a result, some CSM seems to install two rou= tines >> and acts differently, depending on how it was executed, unfortunately. >> When INT 15h is used, it calls a function pointer (which is probably a U= EFI >> service function). =C2=A0When it jumps directly to the entry point, it e= xecutes >> a simple and traditional INT 15h service routine. =C2=A0Therefore, actua= lly there >> are two possible fixes, i. e., this fix or jumping directly to the fixed >> entry point. =C2=A0However, we chose this fix because a) keyboard typema= tic >> support via BIOS is becoming extremely rarer and b) we cannot support ra= ndom >> service routine installed by a firmware or a boot loader. =C2=A0This sho= uld fix >> Lenovo X220 laptop, specifically. >> >> Be reasonable, please. > > I read the commit message -- sadly it also does not explain what the > numbers mean. =C2=A00xf000f859 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. =C2=A0Therefore, t= hey > are "magic values" until they can be defined otherwise. > > Someone digging through the source code is not going to see the commit > message. =C2=A0They're going to have to track it down by hand using cvswe= b or > SVN, just to look at annotations. =C2=A0Don't worry, I don't mean for thi= s 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, --=20 Xin LI <delphij@delphij.net> http://www.delphij.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTin9BoVnC15kNKd5DioV0EjXpXoSzA>