Date: Thu, 22 Apr 2010 15:30:41 -0400 From: John Baldwin <jhb@freebsd.org> To: Maxim Sobolev <sobomax@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: <201004221530.41197.jhb@freebsd.org> In-Reply-To: <4BD0954A.6010000@FreeBSD.org> References: <4BCD5A7B.2070505@FreeBSD.org> <201004220911.14743.jhb@freebsd.org> <4BD0954A.6010000@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201004221530.41197.jhb>