Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Apr 2010 16:06:44 -0700
From:      Maxim Sobolev <sobomax@FreeBSD.org>
To:        Alexander Sack <pisymbol@gmail.com>
Cc:        freebsd-current@FreeBSD.org, mj@feral.com, John Baldwin <jhb@FreeBSD.org>
Subject:   Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
Message-ID:  <4BD76E04.30604@FreeBSD.org>
In-Reply-To: <g2m3c0b01821004271437wcaf82bc0o751bb19f04ceed46@mail.gmail.com>
References:  <4BCD5A7B.2070505@FreeBSD.org> <201004271654.07340.jhb@freebsd.org>	 <4BD751DD.80407@FreeBSD.org> <201004271725.36518.jhb@freebsd.org> <g2m3c0b01821004271437wcaf82bc0o751bb19f04ceed46@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Sack wrote:
> On Tue, Apr 27, 2010 at 5:25 PM, John Baldwin <jhb@freebsd.org> wrote:
>> On Tuesday 27 April 2010 5:06:37 pm Maxim Sobolev wrote:
>>> 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.
> 
> Stunt double:  I tried it and it has no effect.  The waits in atkdbd
> kills it with or without USB legacy support on.  The wait on this
> machine is about 1-2 minutes before boot.  Just another data point.

Have you tried my patch? Does it help?

-Maxim



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BD76E04.30604>