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

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?

> 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

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))
#else
#define	KBD_RETRY(kbd)		(5000)
#endif

and then use 'KBD_RETRY(kbd)' to initialize 'retry' in various places.

-- 
John Baldwin