Re: Compaq ProLiant 1600 server freezes when detecting keyboard controller

> On Fri, Nov 18, 2005 at 03:34:07PM -0600, Tillman Hodgson wrote:
> > In my case, I have a -current kernel from August 20th 2005 that
> > continues to boot properly. Subsequent kernels, including both Oct 20
> > and Nov 17, fail to boot past the atkbdc point. It's an interesting
> > freeze in that cntrl-alt-del doesn't perform a reboot. The Aug 20 kernel
> > lines corresponding to that point look like this:
> > 
> > atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
> > atkbd0: <AT Keyboard> irq 1 on atkbdc0
> 
> I've seen this freeze on a couple of 1600s with 6.0-RELEASE.  Does this
> system have multiple processors?  If not, try changing the "OS Type"
> setting in the BIOS to "Other".  That fixed it for me.

What you can also try, if the BIOS doesn't support this option, is
to break to the OK prompt in the boot loader and type:

OK set hw.pci.enable_io_modes="0"

Use "show hw.pci.enable_io_modes" to verify it's been set correctly.

When the kernel wedges here, it's likely because of a bad interaction
between the PCI code and the vm86 code. The vm86 code (which lets
you run 16 bit BIOS code in an emulated environment using a special
feature of the Pentium) uses physical page 0 contain the instructions
that run when making a vm86 bios call. What can happen sometimes
is that the PCI BIOS leaves one of the PCI devices unconfigured,
in which case its base address register is set to 0. Our PCI code
then comes along and enables all of the devices but doesn't necessarily
update the base address registers on some of them, which has the effect
of mapping one of the PCI devices at physical address 0.

This problem remains more or less hidden until the keyboard driver
code goes to make a vm86 bioscall to access the keyboard. The CPU
is switched to vm86 mode and tries to jump to the code at page 0,
but code execution doesn't work because a PCI device has been
mapped here by mistake. The result is the CPU locks up hard.

Setting hw.pci.enable_io_modes to 1 prevents the PCI code from
unconditionally enabling I/O mode and memory mapped mode of all
devices.

> I've had success with using Other for non-SMP kernels, and using the
> UnixWare 2.1 setting for SMP kernels.  I didn't have to use this
> workaround on 5.4, but I'm not sure when it broke.
> 
> ProLiants in general seem to be finicky beasts with BSD...  I also
> noticed that 6.0 detects a phantom USB controller and when it attempts
> to allocate resources to it (and fails), the serial port redirection for
> the console dies.  I can't prove that there isn't hardware on the board
> somewhere, but these boxes have no USB ports and there's no mention of
> it in the BIOS.  Commenting out uhci from the kernel fixes the serial
> console.

My celeron machine at work also claims to have a USB controller,
but it's not wired up to any connectors on the back panel. I suspect
it's part of the motherboard chipset but whoever made the motherboard
or assembled the system never wired it up.

-Bill
 
--
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
                 wpaul_at_windriver.com | Wind River Systems
=============================================================================
              <adamw> you're just BEGGING to face the moose
=============================================================================