FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
John Baldwin
jhb at freebsd.org
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
trying
> >>>>> 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
Nehalem
> >>> 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:
> >>
> >> http://sobomax.sippysoft.com/atkbdc.diff
> >>
> >> 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
that
> > 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