Date: Thu, 22 Apr 2010 13:07:37 -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: <4BD0AC89.5080306@FreeBSD.org> In-Reply-To: <201004221530.41197.jhb@freebsd.org> References: <4BCD5A7B.2070505@FreeBSD.org> <201004220911.14743.jhb@freebsd.org> <4BD0954A.6010000@FreeBSD.org> <201004221530.41197.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Thursday 22 April 2010 2:28:26 pm Maxim Sobolev wrote: >> John Baldwin wrote: >>> On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote: >>>> Maxim Sobolev wrote: >>>>> There is already a code to detect non-existing AT keyboard and avoid >>>>> attaching atkbd to it. The code is i386-only at the moment, I am trying >>>>> to figure out how to modify it so that it works on amd64 as well. >>>> Looks like this huge delay is caused by the inb() being astonishingly >>>> slow, which is not factored by the timeout routines. Reading keyboard >>>> status port once takes about 0.003s! I am not sure if it's common >>>> behaviour of the platform, or something specific to this particular >>>> model. Do you know by any chance? >>> Well, many BIOSes trigger an SMI# when doing inb/outb to the keyboard ports so >>> they can emulate a PS/2 keyboard when a USB keyboard is inserted. Do you have >>> any BIOS options related to the USB legacy compat? I know of the Nehalem >>> systems I've seen they have a separate option for controlling port 60/64 >>> emulation which we leave disabled by default. >> That makes sense. Unfortunately I don't have access to the BIOS >> settings. This is a hosted system, and the provider keeps BIOS password >> for themselves. >> >> I have a patch that fixes that issue by measuring status register >> reading time first and then factoring it in the calculations of the >> number of retries: >> >> http://sobomax.sippysoft.com/atkbdc.diff >> >> It also applies the same logic to detect broken/non-existing keyboard >> controller to amd64 as we do to the i386. I'd appreciate if you can do a >> review. > > Hmm, not all i386 CPUs that we support have a TSC. Is the change to > atkbdc_isa.c sufficient to fix the hang? If so, I'd rather just commit that > bit and leave out the read_delay changes. No, it's not sufficient. The problem here is that for some reason that test passes on that system (probably emulation works) and so that normal keyboard attach routine is invoked early in boot, when we don't even have clock initialized. What if I make TSC-related changes amd64? Will that be OK? -Maxim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BD0AC89.5080306>