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

From: Alexander Sack <pisymbol_at_gmail.com>
Date: Tue, 27 Apr 2010 15:11:10 -0400
On Tue, Apr 27, 2010 at 12:04 PM, John Baldwin <jhb_at_freebsd.org> wrote:
> 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?

S5520UR, Intel BIOS 48 (last 2 digits), Build 2/27/10.  If I disable
60/64 emulation the box refuses to go into the BIOS or boot anything.
The BIOS just simply hangs after the Intel logo screen.  This just
seems like a bug.  On the last generation Alcolu based machines, we
usually have 60/64h emulation disabled which works just fine (USB
Legacy Mode is still enabled so things like the debugger
still/kinda/sorta work).

I will work through our Intel channels to have them look at this (we
already discovered some other bugs with respect to flashing and RMM3).

I am looking at the atkbd driver for the first time.  It would seem to
me at first glance that John makes a very good point:  there is
already code to deal with a lack of a keyboard in the i386 code.

I would *assume* that turning it on for amd64 would be all that is necessary?

Btw these systems also fail other keyboard related tests.  I also see:

"atkbd: unable to set the command byte."

On all Nehalem systems (this might be less serious given the OS has
taken over from the BIOS).

I am testing  a variant of Maxim's patch right now.

Stay tuned,

-aps
Received on Tue Apr 27 2010 - 17:11:16 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC