FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

John Baldwin jhb at
Tue Apr 27 16:51:43 UTC 2010

On Thursday 22 April 2010 4:07:37 pm Maxim Sobolev wrote:
> John Baldwin wrote:
> > On Thursday 22 April 2010 2:28:26 pm Maxim Sobolev wrote:
> >> John Baldwin wrote:
> >>> On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote:
> >>>> Maxim Sobolev wrote:
> >>>>> There is already a code to detect non-existing AT keyboard and avoid 
> >>>>> attaching atkbd to it. The code is i386-only at the moment, I am 
> >>>>> to figure out how to modify it so that it works on amd64 as well.
> >>>> Looks like this huge delay is caused by the inb() being astonishingly 
> >>>> slow, which is not factored by the timeout routines. Reading keyboard 
> >>>> status port once takes about 0.003s! I am not sure if it's common 
> >>>> behaviour of the platform, or something specific to this particular 
> >>>> model. Do you know by any chance?
> >>> Well, many BIOSes trigger an SMI# when doing inb/outb to the keyboard 
ports so 
> >>> they can emulate a PS/2 keyboard when a USB keyboard is inserted.  Do 
you have 
> >>> any BIOS options related to the USB legacy compat?  I know of the 
> >>> systems I've seen they have a separate option for controlling port 60/64 
> >>> emulation which we leave disabled by default.
> >> That makes sense. Unfortunately I don't have access to the BIOS 
> >> settings. This is a hosted system, and the provider keeps BIOS password 
> >> for themselves.
> >>
> >> I have a patch that fixes that issue by measuring status register 
> >> reading time first and then factoring it in the calculations of the 
> >> number of retries:
> >>
> >>
> >>
> >> It also applies the same logic to detect broken/non-existing keyboard 
> >> controller to amd64 as we do to the i386. I'd appreciate if you can do a 
> >> review.
> > 
> > Hmm, not all i386 CPUs that we support have a TSC.  Is the change to
> > atkbdc_isa.c sufficient to fix the hang?  If so, I'd rather just commit 
> > bit and leave out the read_delay changes.
> No, it's not sufficient. The problem here is that for some reason that 
> test passes on that system (probably emulation works) and so that normal 
> keyboard attach routine is invoked early in boot, when we don't even 
> have clock initialized. What if I make TSC-related changes amd64? Will 
> that be OK?

Hmm, I think you should definitely commit the atkbdc_isa.c change first of 
all.  I'm still thinking about the other change.  I wonder if we can figure 
out that a keyboard isn't present sooner somehow?  Do you know if the keyboard 
appears to be present but just slow vs if the keyboard is eventually found to 
not be present?

John Baldwin

More information about the freebsd-current mailing list