On Fri, Jun 10, 2011 at 5:59 PM, Jeremy Chadwick <free...@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 >> <free...@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 <delp...@delphij.net> http://www.delphij.net _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"