From owner-freebsd-amd64@FreeBSD.ORG Thu Mar 24 16:33:46 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 4C6E516A4CE for ; Thu, 24 Mar 2005 16:33:46 +0000 (GMT) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC9F343D41 for ; Thu, 24 Mar 2005 16:33:45 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1DEVH7-0000n0-00; Thu, 24 Mar 2005 17:33:37 +0100 Date: Thu, 24 Mar 2005 17:33:36 +0100 To: Astrodog Message-ID: <20050324163336.GU2298@poupinou.org> References: <2fd864e05032105366eaf8b2c@mail.gmail.com> <200503211049.11110.jkim@niksun.com> <200503211748.12817.nb_root@videotron.ca> <200503211753.29889.jkim@niksun.com> <2fd864e05032115283dc09da7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2fd864e05032115283dc09da7@mail.gmail.com> User-Agent: Mutt/1.5.6+20040907i From: Bruno Ducrot 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: Thu, 24 Mar 2005 16:33:46 -0000 On Mon, Mar 21, 2005 at 03:28:32PM -0800, Astrodog wrote: > On Mon, 21 Mar 2005 17:53:29 -0500, Jung-uk Kim wrote: > > On Monday 21 March 2005 05:48 pm, Nicolas Blais wrote: > > > What about the PowerNow! kernel module? Is that still required? > > > > If you are okay with 800MHz, no. ;-) You can grab the latest > > powernow-k8 driver from: > > > > http://www.poupinou.org/cpufreq/bsd/powernow.tar.gz > > > > Jung-uk Kim > > > > > Thanks, > > > Nicolas. > > > > > > On March 21, 2005 10:49, 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 > > > > > > > > > --- Harrison Grundy > > _______________________________________________ > > freebsd-amd64@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > > > > Powernow works great, by the way. I'm upgrading to 6-CURRENT now > because I need the ath driver for AMD64 for a wireless card I have, > but I tested things out in 5.4-PRERELEASE, and it works great once > these few, relatively easy to fix issues are resolved. The powernow driver have just been updated btw, would be fine if I got some feedback. It's close to be committed I believe. There is though an unlikely situation where a kernel panic happens if using acpi_perf driver at kldload time (it happens due to known BIOS bugs), and since acpi_perf is compiled now statically, the ACPI path will be taken at first in the powernow driver (this should not be an issue for releng_5 and powernow alone). The below patch (which maybe already committed, who knows) fix this. Index: acpi_perf.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_perf.c,v retrieving revision 1.16 diff -u -p -r1.16 acpi_perf.c --- acpi_perf.c 20 Mar 2005 03:51:18 -0000 1.16 +++ acpi_perf.c 24 Mar 2005 12:52:17 -0000 @@ -244,6 +244,7 @@ acpi_perf_evaluate(device_t dev) ACPI_OBJECT *pkg, *res; ACPI_STATUS status; int error, i, j; + int count; uint32_t *p; /* Get the control values and parameters for each state. */ @@ -272,27 +273,31 @@ acpi_perf_evaluate(device_t dev) * BusMasterLatency, ControlVal, StatusVal}, sorted from highest * performance to lowest. */ - for (i = 0; i < sc->px_count; i++) { + for (count = 0, i = 0; i < sc->px_count; i++) { res = &pkg->Package.Elements[i]; if (!ACPI_PKG_VALID(res, 6)) { device_printf(dev, "invalid _PSS package\n"); continue; } - /* - * Check for some impossible frequencies that some systems - * use to indicate they don't actually support Px states. - */ p = &sc->px_states[i].core_freq; - if (*p == 9999 || *p == 0xffff) - goto out; - /* Parse the rest of the package into the struct. */ for (j = 0; j < 6; j++, p++) acpi_PkgInt32(res, j, p); + + /* + * Check for some impossible frequencies that some systems + * use to indicate they don't actually support this Px state. + */ + if (sc->px_states[i].core_freq == 9999 || + sc->px_states[i].core_freq == 0xffff) + continue; + count++; } AcpiOsFree(buf.Pointer); + sc->px_count = count; + /* Get the control and status registers (one of each). */ buf.Pointer = NULL; buf.Length = ACPI_ALLOCATE_BUFFER; Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care.