Compaq ProLiant 1600 server freezes when detecting keyboard
controller
Tillman Hodgson
tillman at seekingfire.com
Sun Nov 20 07:33:02 PST 2005
On Sun, Nov 20, 2005 Craig wrote:
> > 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.
It is indeed a single processor system. I used the system utilities to
change the system type to "Other", with no change in behaviour.
I watched the boot closely this time and noticed that it complains about
too many IRQ 0s and aborts the keyboard controller. I don't have the
exact wording for this -- again, I don't have the serial console set up.
I'll try the UnixWare setting next, though it's not an SMP kernel. I had
been using the Linux setting, for no particular reason.
On Sun, Nov 20, 2005 at 04:25:36AM +0000, Bill Paul wrote:
> 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"
I tried this next. With this set, it makes it past the keyboard
controller, sc0, sio0, sio1 and vga0. Then the following line appears:
RTC BIOS diagnostic error 29<config_unit,fixed_disk>
Timecounter lines then appear, then IPsec, ipfe2, the delay for SCSI
devices to settle, then:
sym0: unable to abort current chip operation.
sym0: suspicious SCSI data while resetting the BUS.
sym0: dp1, d15-8,dp0,d7-0,rst,req,ack,bsy,sel,atn,msg,c/d,i/o = 0x0, expecting 0x100
sym0: unable to abort current chip operation.
sym1: suspicious SCSI data while resetting the BUS.
sym1: dp1, d15-8,dp0,d7-0,rst,req,ack,bsy,sel,atn,msg,c/d,i/o = 0x0, expecting 0x100
And there it hangs. The Aug 20 kernel doesn't show any SCSI bus errors.
> 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.
Oh, interesting background, thanks!
-T
--
"If 'everybody knows' such-and-such, then it ain't so, by at least ten
thousand to one."
-- Robert Heinlein
More information about the freebsd-current
mailing list