After seeing reports about some Dell machines not being able to boot our
stock install CDs, I walk around the office and tested a -current amd64 CD
on all Dell machines I found.
One of them, a slightly oldish Vostro 200, indeed failed to boot it.
There are two separate problems. First, the usb keyboard is turned into
a legacy pc keyboard via some emulation by the bios. Maybe this can be
turned off, but I didn't want to change too many settings, as it is not
my personal machine.
This, however, is both good an bad. Bad, because the keyboard does not
work - keyboard attaches at pckbc, but later the usb port is blocked
and bios does not give up ownership. Then our usb code disables the port,
and the keyboard is dead. Good, because by booting with -c and disabling
ehci and uhci I get a working keyboard very early, even before ukbd would
have a chance to attach.
Now let us ignore the keyboard problem for now. The machine hangs when it
should discover ATA devices. Everything waits for those to finish probing
and decrementing config defer count - which never happens.
With the keyboard hack I could use ddb and examine: apparently cpu 1 never
makes it to it's idle loop. "mach cpu 1" says it is not paused, ps does
not show the cpu specific threads. Cpu 0 is in the idle loop, a few kernel
threads (like the atabus config one for the first sata controller) have
been created, but never get scheduled. I suppose the half-running cpu
prevents all scheduling (by holding the scheduler lock or something).
When booted with -1 all works fine.
Booting with or without acpi does not make any difference.
I know nothing about cpu spinup on x86 - should there be a watchdog/timeout?
Any instrumentation I could add to track this further? I have a working
pxeboot environment for this machine now.