FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
sobomax at FreeBSD.org
Tue Apr 27 21:06:30 UTC 2010
John Baldwin wrote:
> On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote:
>> John Baldwin wrote:
>>> 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?
>> Our syscons does keyboard probing two times - once early during kernel
>> initialization before most of the subsystems have been initialized yet,
>> and then "real" probing later in boot process. Interesting thing is that
>> initially keyboard looks present. Reading status port in
>> atkbdc_configure() gives value other than 0xff, although reading is
>> thousand times slower than usually. This causes syscons try attaching
>> it. Even though reading status port works, apparently either emulation
>> is not complete or there is some other issue, so that it never responds
>> to some commands. Slow access and lack of response results in
>> wait_for_data() function waiting several minutes instead of 200ms as
>> designed. This what causes that 6-10 minutes delay in boot process.
> I believe the USB driver has disabled the keyboard emulation by the time the
> second probe happens in syscons. Can you try disabling legacy USB support in
> the BIOS just to make sure that is what causes the delay?
Unfortunately it's not possible. Hosting provider doesn't allow me to
have access to BIOS settings.
>> In fact I've also tried sending 0xAA command instead of just checking
>> that value read from the status port is not 0xFF, and it actually
>> completed fine at this point. The controller has returned 0x55 as
>> expected. Therefore, I believe measuring inb() delay is the only
>> reasonable way to avoid that big boot delay at this point.
>> Later on, when we probe/attach keyboard second time (in atkbdc_isa.c)
>> reading status port returns 0xff, so the we can fail attachment process
>> immediately. However, this is not a big issue since at this point
>> reading from status port is as fast as any other ISA inb() operations,
>> so it doesn't cause any noticeable delay.
>> Here is the latest version of the patch:
> Hmm, still has the issue that we can't assume a TSC on i386. I would still
> commit the easy bits to change various '#if defined(__i386__)' to
> '#if defined(__i386__) || defined(__amd64__)' now.
> One thing that could make this cleaner would be to have a macro defined
> something like this in atkbdc.c:
> /* CPU will stay inside loops for 100msec at most. */
> #ifdef __amd64__
> #define KBD_RETRY(kbd) (100000 / ((KBDD_DELAYTIME * 2) + kbdc->read_delay))
> #define KBD_RETRY(kbd) (5000)
> and then use 'KBD_RETRY(kbd)' to initialize 'retry' in various places.
Please take a closer look. Use of rdtsc() in this version is conditonal
on __amd64__ only.
More information about the freebsd-current