Date: Tue, 27 Apr 2010 15:11:10 -0400 From: Alexander Sack <pisymbol@gmail.com> 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: <p2v3c0b01821004271211p48547fevd59963b982587e6b@mail.gmail.com> 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
On Tue, Apr 27, 2010 at 12:04 PM, John Baldwin <jhb@freebsd.org> wrote: > On Thursday 22 April 2010 4:07:37 pm Maxim Sobolev wrote: >> 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 avo= id >> >>>>> 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 astonishing= ly >> >>>> slow, which is not factored by the timeout routines. Reading keyboa= rd >> >>>> 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 keyboar= d > ports so >> >>> they can emulate a PS/2 keyboard when a USB keyboard is inserted. = =A0Do > you have >> >>> any BIOS options related to the USB legacy compat? =A0I know of the > Nehalem >> >>> systems I've seen they have a separate option for controlling port 6= 0/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 passwo= rd >> >> 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 d= o a >> >> review. >> > >> > Hmm, not all i386 CPUs that we support have a TSC. =A0Is the change to >> > atkbdc_isa.c sufficient to fix the hang? =A0If so, I'd rather just com= mit > 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? > > Hmm, I think you should definitely commit the atkbdc_isa.c change first o= f > all. =A0I'm still thinking about the other change. =A0I wonder if we can = figure > out that a keyboard isn't present sooner somehow? =A0Do you know if the k= eyboard > appears to be present but just slow vs if the keyboard is eventually foun= d to > not be present? S5520UR, Intel BIOS 48 (last 2 digits), Build 2/27/10. If I disable 60/64 emulation the box refuses to go into the BIOS or boot anything. The BIOS just simply hangs after the Intel logo screen. This just seems like a bug. On the last generation Alcolu based machines, we usually have 60/64h emulation disabled which works just fine (USB Legacy Mode is still enabled so things like the debugger still/kinda/sorta work). I will work through our Intel channels to have them look at this (we already discovered some other bugs with respect to flashing and RMM3). I am looking at the atkbd driver for the first time. It would seem to me at first glance that John makes a very good point: there is already code to deal with a lack of a keyboard in the i386 code. I would *assume* that turning it on for amd64 would be all that is necessar= y? Btw these systems also fail other keyboard related tests. I also see: "atkbd: unable to set the command byte." On all Nehalem systems (this might be less serious given the OS has taken over from the BIOS). I am testing a variant of Maxim's patch right now. Stay tuned, -aps
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p2v3c0b01821004271211p48547fevd59963b982587e6b>