On Tuesday 31 May 2011 04:50 pm, Jung-uk Kim wrote:
> On Friday 27 May 2011 01:14 pm, Xin LI wrote:
> > On Thu, May 19, 2011 at 5:18 AM, Johannes Dieterich
> >
> > <dieterich....@googlemail.com> wrote:
> > > On Wed, May 18, 2011 at 7:40 PM, Xin LI <delp...@delphij.net>
>
> wrote:
> > >> -----BEGIN PGP SIGNED MESSAGE-----
> > >> Hash: SHA256
> > >>
> > >> Try this patch?
> > >
> > > The attached patch makes 9-CURRENT-amd64 boot on the X220 w/o
> > > any hints or BIOS fixes needed. Thanks a lot! :-)
> > >
> > >> (I'm still opted to disable the typematic rate detection by
> > >> default at least for amd64, as we don't do it in the past for
> > >> amd64)
> > >
> > > What does this mean concerning getting the fix into CURRENT?
> >
> > Well, that's not a perfect fix and we do lose the ability of
> > detecting typematic rate (by default), so technically it's a
> > workaround (sufficient to make the kernel boot and work, though)
> > and doesn't fix anything.
> >
> > I have committed it anyway since we do not have better fix (yet),
> > and have updated atkbd(4) manual page so one can enable it again
> > when wanted.
> >
> > The problem we had was that it seems that running the BIOS in the
> > x86emu emulator on amd64 would cause problem. This doesn't seem
> > to be fixable without hands-on experiments on a system in
> > question, it's either a BIOS bug or an emulator bug. The strange
> > part of the problem is that the functionality is quite common in
> > the Good Old Days (TM).
>
> I got BIOS dump from gnn last week. I've been scratching my head
> cause it should just fail and exit gracefully unless I am totally
> missing something. :-(
>
> Are you guys sure that INT 15h is causing hangs? Maybe INT 16h is
> the real culprit (which is more probable, BTW)?
I found something strange about this BIOS (well, if we can call it
that). Please try this:
Index: sys/dev/atkbdc/atkbd.c
===================================================================
--- sys/dev/atkbdc/atkbd.c (revision 222550)
+++ sys/dev/atkbdc/atkbd.c (working copy)
@@ -1100,7 +1100,8 @@ get_typematic(keyboard_t *kbd)
if (!(kbd->kb_config & KB_CONF_PROBE_TYPEMATIC))
return (ENODEV);
- if (x86bios_get_intr(0x15) == 0 || x86bios_get_intr(0x16) == 0)
+ if (x86bios_get_intr(0x15) != 0xf000f859 ||
+ x86bios_get_intr(0x16) != 0xf000e82e)
return (ENODEV);
/* Is BIOS system configuration table supported? */
You must re-enable typematic probing from loader to test it, of
course. I think the following line should do:
hint.atkbd.0.flags="0x10"
Note: You may add printf() before and after the check to make sure it
is being called (and it fails immediately).
A long answer goes like this. INT 0x15 and 0x16 vectors have fixed
entry points in *real* BIOS, i.e., 0xf000:0xf859 and 0xf000:0xe82e.
For this BIOS (or CSM), INT 0x16 vector is correct but INT 0x15
vector is not (0xf000:0xb4f1). Funny thing is 0xf000:0xf859 actually
points to a working INT 15h handler, it seems, which confused me
totally. Probably it was done like this because (U)EFI CSM spec.
mandated it to be located @ 0xf000:0xf859. If we follow the
interrupt vector (0xf000:0xb4f1), it gets nowhere (or jumps to an
unknown external interrupt handler). If we follow the fixed address,
it will exit gracefully. So, actually there are two possible
solutions, i.e., 1) check whether the interrupt vector is modified
(the above patch), or 2) jump directly to the fixed interrupt entry
point. I chose Option #1 because it is very hard to find BIOS
typematic support these days (as you pointed out).
Cheers,
Jung-uk Kim
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
