From owner-freebsd-amd64@FreeBSD.ORG Mon Mar 21 18:31:00 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 150EF16A4CE for ; Mon, 21 Mar 2005 18:31:00 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B5B443D49 for ; Mon, 21 Mar 2005 18:30:55 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2LITokD057359; Mon, 21 Mar 2005 11:29:54 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <423F1236.4000401@samsco.org> Date: Mon, 21 Mar 2005 11:28:06 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Astrodog References: <2fd864e05032105366eaf8b2c@mail.gmail.com> <200503211113.52233.jkim@niksun.com> <423EF3D2.9050205@samsco.org> <200503211141.40409.jkim@niksun.com> <2fd864e05032109304c2ad323@mail.gmail.com> In-Reply-To: <2fd864e05032109304c2ad323@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.3 required=3.8 tests=ALL_TRUSTED,OPTING_OUT autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org 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 18:31:00 -0000 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. Scott