Port-xen archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: dom0 crash with thinkpad keyboard



Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes:

> On Sat, Feb 27, 2021 at 03:00:36PM -0500, Greg Troxel wrote:
>> 
>> An update: it also crashes with an old mac wired keyboard, in basically
>> the same way.  I still don't have  core dump.
>> 
>> I wonder if anyone has recent current in a dom0 and it works or
>> doesn't.
>
> I does but I use serial console.
>
> Maybe try to disable pckbd ?

Thanks for the hint; I think that led me to the issue.

First, I added "userconf=disable pckbc" to my boot.cfg (not in a menu).
Booting into NetBSD direct worked fine, and booting into Xen got me a
heap overflow.  Probably userconf has to be on the load line for the
dom0 kernel, and I'll figure that out as part of the boot docs rototill.

I then started reading the code and trying to trace the twisty maze of
console setup.  I think it's fragile, and essentially there's an assert
that if the ukbd driver thinks it is supposed to attach a console but
wsdisplay thinks it already did, it KASSERTS.  The logic of how this
can't happen is really hard to follow, and even harder to convince
myself it is right.

There's a scheme to try to attach things that are VGA-like, and then
things that are keyboard like, with the notion that only the first one
that "works" is enabled.  ukbd is special in that it reports success,
and the defers attaching a ukbd to console until one appears.

There is a confusing option in GENERIC:

  # don't attach pckbd as the console if no PS/2 keyboard is found
  options         PCKBD_CNATTACH_MAY_FAIL

and basically, *without* that defined, pckbc is attached even if there
is no keyboard.  That's basically wrong IMHO, especially with
motherboards that have pckbc in silicon but don't bring it out to the
back of the case (like mine :-).

That option is NOT in XEN3_DOM0, and I'm going to test with it added.

There's the other issue, which is that if the pckbc cnattach succeeded,
then the ukbd cnattach should not have been called.   The xen console
init code is quite different from the x86 one.

Probably a device being enabled for console keyboard (not the mux being
attached, but things hooking into the mux) should be noted in dmesg; it
strikes me as important.

Probably instead of KASSERT, there should be some way for
wskdb_cnattach to just fail, saying "no you can't; somebody already
did", with the caller just not recording that they are the console,
perhaps with an error.

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index