Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Apr 2010 13:26:09 -0700
From:      Maxim Sobolev <sobomax@FreeBSD.org>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        freebsd-current@FreeBSD.org, mj@feral.com
Subject:   Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
Message-ID:  <4BD74861.30603@FreeBSD.org>
In-Reply-To: <201004271204.43057.jhb@freebsd.org>
References:  <4BCD5A7B.2070505@FreeBSD.org> <201004221530.41197.jhb@freebsd.org> <4BD0AC89.5080306@FreeBSD.org> <201004271204.43057.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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:

http://sobomax.sippysoft.com/atkbdc.diff

-Maxim



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