From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 21 21:18:40 2005 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A5F216A4D3 for ; Mon, 21 Mar 2005 21:18:40 +0000 (GMT) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0158E43D39 for ; Mon, 21 Mar 2005 21:18:40 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 1488 invoked from network); 21 Mar 2005 21:18:39 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 21 Mar 2005 21:18:39 -0000 Received: from [10.50.41.231] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j2LLIPeT048944; Mon, 21 Mar 2005 16:18:33 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-amd64@FreeBSD.org Date: Mon, 21 Mar 2005 14:40:21 -0500 User-Agent: KMail/1.6.2 References: <2fd864e05032105366eaf8b2c@mail.gmail.com> <423F1236.4000401@samsco.org> <200503211411.58425.jkim@niksun.com> In-Reply-To: <200503211411.58425.jkim@niksun.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503211440.21752.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.3 required=4.2 tests=ALL_TRUSTED,OPTING_OUT, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx Subject: Re: R3000Z Laptop Status X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2005 21:18:40 -0000 On Monday 21 March 2005 02:11 pm, Jung-uk Kim wrote: > On Monday 21 March 2005 01:28 pm, Scott Long wrote: > > Astrodog wrote: > > >>>>>>>I was wondering if the R3000Z fixes have been committed to > > >>>>>>> the RELENG_5 branch, I don't see anything on the lists > > >>>>>>> about it. Should I expect 5.4 to work with the R3000 line? > > >>>>>> > > >>>>>>Yes. hint.atkbd.0.flags="0x9" is all you need now. Try the > > >>>>>>latest snapshot and let us know. > > >>>>>> > > >>>>>>Thanks, > > >>>>>> > > >>>>>>Jung-uk Kim > > >>>>> > > >>>>>Is there any way that these systems can be detected at runtime > > >>>>>and have the work-arounds be automatically activated? > > >>>> > > >>>>I believe DMI-based quirk table is the only way but we don't > > >>>> want to do that, right? > > >>>> > > >>>>Jung-uk Kim > > >>>> > > >>>>>Scott > > >>> > > >>>Well, it's gross, but it's not impossible to do. Is there a > > >>>technical reason why we wouldn't want this? > > >> > > >>The only technical reason that I can think of is some systems (e. > > >> g., IBM e345 and e346 Opteron servers) have DMI structures in > > >> ACPI NVS area, which is not accessible from early stage. If you > > >> want to do something like that, you will have to add gross hack > > >> in pmap.c to temporarily map it, I think. > > >> > > >>>Are there any alternatives, like detecting a signature in ACPI, > > >>>either a text string or a certain bit of ASL bytecode? > > >> > > >>We already have the quirk for this broken BIOS. However, > > >> keyboard probing happens way earlier to use this quirk. :-( > > >> > > >>Jung-uk Kim > > >> > > >>>Scott > > > > > > Something that came up originally, when this issue was first > > > noticed, was trying to figure out what, if any platforms, would > > > have problems if this was made to apply to all AMD64 machines, > > > and use the flag to drive an opt-out. In as far as I'm aware, no > > > AMD64-based machines are effected if you just "break" the > > > keyboard test functionality, though I'm not certain this is a > > > path worth looking at, since its still a bit ugly. > > > > My number 1 concern is that 5.4-RELEASE 'Just Works' when you load > > it onto a machine. Undocumented and under-documented work-arounds > > are very hard to manage and don't help users that aren't intimately > > familiar with the problem. This is a place where ("Alert! Don the > > asbestos skivvies now!") adding an option to ("I'm warning you! > > Prepare for flamage!") beastie.4th might be a good idea. > > One possibility is adding DMI scan code in loader and passing BIOS ID > strings to kernel because loader can easily call BIOS function calls. > This won't require ugly hack in kernel space. I like this approach better. We already provide hints to ACPI via the loader. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org