Re: Unable to boot Lenovo T520
On Fri, Jun 10, 2011 at 06:24:51PM -0700, Xin LI wrote: > On Fri, Jun 10, 2011 at 5:59 PM, Jeremy Chadwick > 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 > >> 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). It's quite alright. I realise it sounds like I'm harping about nothing, but "magic numbers" usually are things that should be documented, even if just a one or two-line comment. The next time someone looks at the code, they'll say "Oh that's what those numbers are!" rather than "...what the heck?" > Just want to say that Jung-uk have spend a lot of h
Re: Unable to boot Lenovo T520
On Fri, Jun 10, 2011 at 5:59 PM, Jeremy Chadwick 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 >> 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 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"
Re: Unable to boot Lenovo T520
On Fri, Jun 10, 2011 at 04:48:31PM -0700, Xin LI wrote: > On Fri, Jun 10, 2011 at 4:42 PM, Jeremy Chadwick > 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 j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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"
Re: Unable to boot Lenovo T520
On Fri, Jun 10, 2011 at 4:42 PM, Jeremy Chadwick 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 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"
Re: Unable to boot Lenovo T520
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. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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"
Re: Unable to boot Lenovo T520
-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). Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJN8qWrAAoJEATO+BI/yjfBfNgH/1FBHJzQuRIkG1gIKrhAi2ES tyvxsaBc/6e/htXSsRSLoXXZ+Ds427Yes6MVVjyMlVPne7QzF9HxRQVTzNv9sTmc /Jx3pIbnIaugg/tVR+K49s+IU3UxtkSl4f7aKXG2eacWz52S/A8DzXFbe5WX41lE xn47myobsiGEBv6wnss7Q9gW42CoVfAp753lrBlKUMqGpZR04cPIGMsxjgPGoBpg QUTxoYbXj53ZdEMI3gYCF69m/Nf3lNY33nb7TI//I7qYBTspXdoCJ221MFJWYn04 hhxOdvo3xJ2shZOSJ4IH3waSk0G2hlOjPhud2m+t1KMtDt2e09A3ZD1xhmCxs0s= =fDcF -END PGP SIGNATURE- ___ 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"
