From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 21 16:41:48 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 7187416A4CE for ; Mon, 21 Mar 2005 16:41:48 +0000 (GMT) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BB5A43D46 for ; Mon, 21 Mar 2005 16:41:48 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from [10.70.0.244] (daemon.mj.niksun.com [10.70.0.244]) by anuket.mj.niksun.com (8.13.1/8.12.11) with ESMTP id j2LGfkw3006091; Mon, 21 Mar 2005 11:41:47 -0500 (EST) (envelope-from jkim@niksun.com) From: Jung-uk Kim Organization: Niksun, Inc. To: Scott Long Date: Mon, 21 Mar 2005 11:41:40 -0500 User-Agent: KMail/1.6.2 References: <2fd864e05032105366eaf8b2c@mail.gmail.com> <200503211113.52233.jkim@niksun.com> <423EF3D2.9050205@samsco.org> In-Reply-To: <423EF3D2.9050205@samsco.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503211141.40409.jkim@niksun.com> X-Virus-Scanned: ClamAV 0.83/778/Mon Mar 21 05:48:43 2005 on anuket.mj.niksun.com X-Virus-Status: Clean cc: freebsd-amd64@freebsd.org 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 16:41:48 -0000 On Monday 21 March 2005 11:18 am, Scott Long wrote: > Jung-uk Kim wrote: > > On Monday 21 March 2005 11:07 am, Scott Long wrote: > >>Jung-uk Kim wrote: > >>>On Monday 21 March 2005 08:36 am, 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