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

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.

Hmm, ok.

> >> 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.
> 
> Please take a closer look. Use of rdtsc() in this version is conditonal 
> on __amd64__ only.

Ok, that does look a lot better.  I don't like having to use rdtsc() to time
the delay but I don't have any better suggestions.  I think you should add a
block comment above the calibration section to explain why you are doing it
(i.e. some BIOSes' PS/2 emulation take a really long time to execute).

-- 
John Baldwin