From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 30 11:35:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B062096D for ; Sun, 30 Jun 2013 11:35:47 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 264851BFD for ; Sun, 30 Jun 2013 11:35:46 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7) with ESMTP id r5UB6WKS001142 for ; Sun, 30 Jun 2013 13:06:32 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7/Submit) with ESMTP id r5UB6WiX001139 for ; Sun, 30 Jun 2013 13:06:32 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Sun, 30 Jun 2013 13:06:32 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: Re: what's got messed with geli in newest 9.* kernel (svn) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Sun, 30 Jun 2013 13:06:33 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 11:35:47 -0000 really nobody use geli. tried today - still geli crash system within a minute. On Fri, 21 Jun 2013, Wojciech Puchar wrote: > after getting yesterday new kernel, upgrading everything (including userland, > all in sync) my geli encrypted partition starts to randomly produce > read/write errors (error number 11) or just random reboots. > > going back to kernel compiled from 6 day older sources fixes everything. > > evidently a serious bug, making this kernel useless. > > Should i sent-pr or just sent all needed data (including kernel config) to > someone directly? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 30 14:49:33 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 36398A60 for ; Sun, 30 Jun 2013 14:49:33 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id C7A5910A8 for ; Sun, 30 Jun 2013 14:49:32 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id j14so1588931eak.22 for ; Sun, 30 Jun 2013 07:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:x-mailer; bh=ru48wiTDRBBoAO/9EZTfapfg2UOfgGP0BWR7CneeJyQ=; b=B5NzZ/aGV40OsyAx6pqODiHBkvwr9DLK5XpjPagfdRv1hwR59Ipd0jdEPNtiVb2sxQ +/BBwx7u39TX6CdazogimZ7BJ+6lX0XWwgnef3cPyR0K604a+x7uq35yl7PfgQad1GNT 0WUD+On2YuXcOqXLA5g5WVE+LNR4qb7YughIA01mqi5fZKkOIwTqNzf8HsPaQ2DlNIvW 8T2ig2c7Ik6I6l+WjSj21u3Fg2nM1GtcurQkLTviZwT4CvQGqgdgPBhyjn42cWLOvYmt 0TrimK2cws2Mj7BReKaJdVfuZ+TEWiEgS4D6SdmUvDKayPTvSBkmP64mbrFUaB2M7xGr PX+w== X-Received: by 10.14.88.193 with SMTP id a41mr17201159eef.151.1372603767295; Sun, 30 Jun 2013 07:49:27 -0700 (PDT) Received: from DOMYPC ([82.193.208.225]) by mx.google.com with ESMTPSA id p49sm23629237eeu.2.2013.06.30.07.49.25 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 30 Jun 2013 07:49:26 -0700 (PDT) Message-ID: <20130630.144926.847.1@DOMY-PC> From: rank1seeker@gmail.com To: hackers@freebsd.org Subject: Re: make targets, fail for ports, when DESTDIR is set Date: Sun, 30 Jun 2013 16:49:26 +0200 X-Mailer: POP Peeper (3.8.1.0) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 14:49:33 -0000 > 9.1-RELEASE-p4 i386 > > # make showconfig -C /usr/ports/benchmarks/unixbench DESTDIR=/usr/TZONE > ===> Creating some important subdirectories > realpath: /usr/TZONE/___temp___: No such file or directory > *** [do-chroot] Error code 1 > > Stop in /usr/ports/benchmarks/unixbench. Ping! I'm still unable to install ports into DESTDIR, after kernel and world installation ... When will this be fixed? From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 30 17:25:34 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 78B72479 for ; Sun, 30 Jun 2013 17:25:34 +0000 (UTC) (envelope-from robertames@hotmail.com) Received: from blu0-omc2-s18.blu0.hotmail.com (blu0-omc2-s18.blu0.hotmail.com [65.55.111.93]) by mx1.freebsd.org (Postfix) with ESMTP id 4B7251645 for ; Sun, 30 Jun 2013 17:25:33 +0000 (UTC) Received: from BLU177-W9 ([65.55.111.73]) by blu0-omc2-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 30 Jun 2013 10:24:27 -0700 X-TMN: [3dYevcWZTuxQKn/B4RUEJdBkaYDyziU/] X-Originating-Email: [robertames@hotmail.com] Message-ID: From: Robert Ames To: "freebsd-hackers@freebsd.org" Subject: Intel D2500CC serial ports Date: Sun, 30 Jun 2013 13:24:27 -0400 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jun 2013 17:24:27.0938 (UTC) FILETIME=[AC877820:01CE75B6] X-Mailman-Approved-At: Sun, 30 Jun 2013 18:25:23 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 17:25:34 -0000 I just picked up an Intel D2500CCE motherboard and was disappointed=0A= to find the serial ports didn't work.=A0 There has been discussion=0A= about this problem here:=0A= =0A= http://lists.freebsd.org/pipermail/freebsd-current/2013-April/040897.html= =0A= http://lists.freebsd.org/pipermail/freebsd-current/2013-May/042088.html=0A= =0A= As seen in the second link=2C Juergen Weiss was able to work around=0A= the problem.=A0 This patch (for 8.4-RELEASE amd64) makes all 4 serial=0A= ports functional.=0A= =0A= --- /usr/src/sys/amd64/amd64/io_apic.c.orig 2013-06-02 13:23:05.000000000 -= 0500=0A= +++ /usr/src/sys/amd64/amd64/io_apic.c=A0=A0=A0=A0=A0 2013-06-28 18:52:03.0= 00000000 -0500=0A= @@ -452=2C6 +452=2C10 @@=0A= =A0=A0=A0=A0=A0=A0=A0 KASSERT(!(trig =3D=3D INTR_TRIGGER_CONFORM || pol =3D= =3D INTR_POLARITY_CONFORM)=2C=0A= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ("%s: Conforming trigger or polarity\n"= =2C __func__))=3B=0A= =A0=0A= +=A0=A0=A0=A0=A0=A0 if (trig =3D=3D INTR_TRIGGER_EDGE && pol =3D=3D INTR_PO= LARITY_LOW) {=0A= +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pol =3D INTR_POLARITY_HIGH=3B= =0A= +=A0=A0=A0=A0=A0=A0 }=0A= +=0A= =A0=A0=A0=A0=A0=A0=A0 /*=0A= =A0=A0=A0=A0=A0=A0=A0=A0 * EISA interrupts always use active high polarity= =2C so don't allow=0A= =A0=A0=A0=A0=A0=A0=A0=A0 * them to be set to active low.=0A= =0A= However this is just a work around and not a general solution.=A0 Does=0A= anyone have suggestions on a fix that could be committed so the=0A= serial ports for this board will work out of the box? = From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 1 21:47:37 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 78FAA28B; Mon, 1 Jul 2013 21:47:37 +0000 (UTC) (envelope-from torek@torek.net) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) by mx1.freebsd.org (Postfix) with ESMTP id 3C00C13CC; Mon, 1 Jul 2013 21:47:36 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id r61LlUr7002898; Mon, 1 Jul 2013 15:47:30 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201307012147.r61LlUr7002898@elf.torek.net> From: Chris Torek To: freebsd-hackers@freebsd.org Subject: Re: expanding amd64 past the 1TB limit In-reply-to: Your message of "Fri, 28 Jun 2013 14:33:55 -0600." <201306282033.r5SKXtYK053022@elf.torek.net> Date: Mon, 01 Jul 2013 15:47:30 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Mon, 01 Jul 2013 15:47:30 -0600 (MDT) Cc: Konstantin Belousov , alc@freebsd.org, kib@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 21:47:37 -0000 I went ahead and implemented the "ndmpdpphys" change I had thought about. Here's that patch by itself. At this point it might be reasonable to use the patch without the AMD64_HUGE option, just increasing the KVM area, as the direct map no longer consumes extra pages. (There's a glitch in the comment in the original patch, I'll fix that if/when there's any agreement on whether it gets applied in some form :-) ) Chris diff --git a/amd64/amd64/pmap.c b/amd64/amd64/pmap.c index acf5af2..f1ed8b6 100644 --- a/amd64/amd64/pmap.c +++ b/amd64/amd64/pmap.c @@ -232,6 +232,7 @@ u_int64_t KPML4phys; /* phys addr of kernel level 4 */ static u_int64_t DMPDphys; /* phys addr of direct mapped level 2 */ static u_int64_t DMPDPphys; /* phys addr of direct mapped level 3 */ +static int ndmpdpphys; /* number of DMPDPphys pages */ static struct rwlock_padalign pvh_global_lock; @@ -543,7 +544,18 @@ create_pagetables(vm_paddr_t *firstaddr) ndmpdp = (ptoa(Maxmem) + NBPDP - 1) >> PDPSHIFT; if (ndmpdp < 4) /* Minimum 4GB of dirmap */ ndmpdp = 4; - DMPDPphys = allocpages(firstaddr, NDMPML4E); + ndmpdpphys = howmany(ndmpdp, NPML4EPG); + if (ndmpdpphys > NDMPML4E) { + /* + * Each NDMPML4E allows 512 GB, so limit to that, + * and then readjust ndmpdp and ndmpdpphys. + */ + printf("NDMPML4E limits system to %d GB\n", NDMPML4E * 512); + Maxmem = atop(NDMPML4E * NBPML4); + ndmpdpphys = NDMPML4E; + ndmpdp = NDMPML4E * NPDEPG; + } + DMPDPphys = allocpages(firstaddr, ndmpdpphys); ndm1g = 0; if ((amd_feature & AMDID_PAGE1GB) != 0) ndm1g = ptoa(Maxmem) >> PDPSHIFT; @@ -626,7 +638,7 @@ create_pagetables(vm_paddr_t *firstaddr) p4_p[PML4PML4I] |= PG_RW | PG_V | PG_U; /* Connect the Direct Map slot(s) up to the PML4. */ - for (i = 0; i < NDMPML4E; i++) { + for (i = 0; i < ndmpdpphys; i++) { p4_p[DMPML4I + i] = DMPDPphys + ptoa(i); p4_p[DMPML4I + i] |= PG_RW | PG_V | PG_U; } @@ -1698,7 +1710,7 @@ pmap_pinit(pmap_t pmap) pmap->pm_pml4[KPML4BASE + i] = (KPDPphys + (i << PAGE_SHIFT)) | PG_RW | PG_V | PG_U; } - for (i = 0; i < NDMPML4E; i++) { + for (i = 0; i < ndmpdpphys; i++) { pmap->pm_pml4[DMPML4I + i] = (DMPDPphys + (i << PAGE_SHIFT)) | PG_RW | PG_V | PG_U; } @@ -1955,7 +1967,7 @@ pmap_release(pmap_t pmap) for (i = 0; i < NKPML4E; i++) /* KVA */ pmap->pm_pml4[KPML4BASE + i] = 0; - for (i = 0; i < NDMPML4E; i++) /* Direct Map */ + for (i = 0; i < ndmpdpphys; i++)/* Direct Map */ pmap->pm_pml4[DMPML4I + i] = 0; pmap->pm_pml4[PML4PML4I] = 0; /* Recursive Mapping */ From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 2 00:42:11 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B92216FB for ; Tue, 2 Jul 2013 00:42:11 +0000 (UTC) (envelope-from david.lee.tn@programmer.net) Received: from mout.gmx.net (mout.gmx.net [74.208.4.201]) by mx1.freebsd.org (Postfix) with ESMTP id 8AD471B65 for ; Tue, 2 Jul 2013 00:42:11 +0000 (UTC) Received: from mailout-us.gmx.com ([172.19.198.48]) by mrigmx.server.lan (mrigmxus002) with ESMTP (Nemesis) id 0MZVCj-1Ufs9n2rZF-00LDQE for ; Tue, 02 Jul 2013 02:42:10 +0200 Received: (qmail 7401 invoked by uid 0); 2 Jul 2013 00:42:10 -0000 Received: from 216.39.156.27 by rms-us021 with HTTP Date: Mon, 01 Jul 2013 20:42:07 -0400 From: "David Sanford" Message-ID: <20130702004207.5510@gmx.com> MIME-Version: 1.0 Subject: another question To: freebsd-hackers@freebsd.org X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 X-GMX-UID: iESgcUNj3zOl1DCzJXwhZDl+IGRvb0AH X-Mailman-Approved-At: Tue, 02 Jul 2013 02:20:59 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 00:42:11 -0000 Hi, Thanks for your responses to my first question. They were very helpful. In looking at the code, I ran across the functions setprogname and getprogname. According to the man page: In FreeBSD, the name of the program is set by the start-up code that is run before *main*(); thus, running *setprogname*() is not necessary. I'm confused by how this is done. Where is this "start-up code" defined? Is this included in all executables compiled on FreeBSD? Even the programs released under the GNU GPL? Sincerely, David Lee from Tennessee From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 2 03:25:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 97A44E83 for ; Tue, 2 Jul 2013 03:25:47 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 67C9611FB for ; Tue, 2 Jul 2013 03:25:47 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id i7so5825432oag.16 for ; Mon, 01 Jul 2013 20:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=05ehRY34tSzR8XJLky6UzrA0xcot074tvncIQp8ludE=; b=xVyaWFa3ro7cEcVT/3HTdoup76rpczKsmBLSefd3WWqJkR+QpdJQGfmBMeD39Sf/Uf /HGcCSK2SmTz8No+nReFIwq4fvJFaKVyVREiUmuoyt8Ol6K/jAsOU56XorhN61JijMTu /QBkuK2qpSsxGJkAljiEb6x+WMflPAE+D/hUEaIMsguQbcrDBKlijPOzXdqSaEkZK7zG QGcOacurdQ01i77YPZa2FdTEQY1Cprhb/ObCMPaZv3qwjziiCLnhmWDf3m0Sbheo8EXp pPN6whXnc3wU2JUblY3a8oODzvlez0SWGlFEA+6nHuLJX6aN6kRF52sL5EnlFoiCREZw QMug== MIME-Version: 1.0 X-Received: by 10.60.42.101 with SMTP id n5mr10871663oel.4.1372735546897; Mon, 01 Jul 2013 20:25:46 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.182.162.65 with HTTP; Mon, 1 Jul 2013 20:25:46 -0700 (PDT) In-Reply-To: <20130702004207.5510@gmx.com> References: <20130702004207.5510@gmx.com> Date: Mon, 1 Jul 2013 20:25:46 -0700 X-Google-Sender-Auth: w1DZ94dwXfpNrvT_vjN2c-E-Rwg Message-ID: Subject: Re: another question From: mdf@FreeBSD.org To: David Sanford Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 03:25:47 -0000 On Mon, Jul 1, 2013 at 5:42 PM, David Sanford wrote: > Hi, > > Thanks for your responses to my first question. They were very helpful. > > In looking at the code, I ran across the functions setprogname and > getprogname. According to the man page: > In FreeBSD, the name of the program is set by the start-up code that is > run before *main*(); thus, running *setprogname*() is not necessary. > I'm confused by how this is done. Where is this "start-up code" defined? > Is this included in all executables compiled on FreeBSD? Even the programs > released under the GNU GPL? I believe the code that does this is in lib/csu/common/ignore_init.c; see handle_argv() and the use of __progname[]. This will run for anything that links against csu, which is anything compiled on FreeBSD. The same csu library sets the ABI note.tag, which tells the kernel which syscall table to use when the binary is executed. Cheers, matthew From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 2 12:39:32 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7BAA16D for ; Tue, 2 Jul 2013 12:39:32 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 359581AAE for ; Tue, 2 Jul 2013 12:39:32 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Utzkq-000Jin-Ig for freebsd-hackers@freebsd.org; Tue, 02 Jul 2013 15:32:20 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-hackers Subject: hw.physmem/hw.realmem question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Jul 2013 15:32:20 +0300 From: Daniel Braniss Message-ID: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 12:39:32 -0000 Hi, to run some tests, I reduced the physical memory by setting hw.physmem, which got me to do some comparisons, and the more I looked around the more confused I got. for example, this host has has 32G of physical memory from dmesg: Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-STABLE #26: Thu Jun 20 16:00:00 IDT 2013 danny@rnd:/home/obj/rnd/r+d/stable/9/sys/HUJI amd64 gcc version 4.2.1 20070831 patched [FreeBSD] CPU: Intel(R) Xeon(R) CPU E5-2643 0 @ 3.30GHz (3300.06-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206d7 Family = 0x6 Model = 0x2d Stepping = 7 Features=0xbfebfbff Features2=0x1fbee3ff AMD Features=0x2c100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 32191340544 (30700 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: and from sysctl: hw.physmem: 34284916736 hw.usermem: 32964923392 hw.realmem: 36507222016 after setting hw.physmem=16G from dmesg: real memory = 34359738368 (32768 MB) avail memory = 13999382528 (13350 MB) and sysctl: hw.physmem: 14957563904 hw.usermem: 10094678016 hw.realmem: 17179869184 from the numbers, I can assume that realmem is the real physical memory, (or whatever is set in hw.physmem), if so, where did almost 2G go? (realmem - physmen) the only info I found so far is: from loader(8): hw.physmem Limit the amount of physical memory the system will use. By default the size is in bytes, but the k, K, m, M, g and G suffixes are also accepted and indicate kilobytes, megabytes and gigabytes respectively. An invalid suffix will result in the variable being ignored by the kernel. what is physmem and realmem, and what's the relationship - if any - between them? cheers, danny From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 2 13:44:33 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D7CCF3E8; Tue, 2 Jul 2013 13:44:33 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 916431EA7; Tue, 2 Jul 2013 13:44:33 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id wc20so5598304obb.32 for ; Tue, 02 Jul 2013 06:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=o8DWfZxjSJpAvY5xAUh/b2R7PepFDrnddlgKNSRGHLw=; b=mNRlFYElbZ5egyYvq5HhDfXgPLD8M2bMAXn0c3iMID539uFHWnFTzueoKqUOcgIr+Q OtmE0WqUcaXsowYjxHySe2YKLhXajDxVDgsxJS8dmOBf9/keNoeTgAXoN4il/H/Vj8Yt QkrhuEsWC4HG+S8rGg99kta1yW2jusb2+wik/P3cmEwuPotHrzSYN+SYceec/v3aOorC 6AP/7Txhoj4l/4zUdklIz49l7oEPdN7jizZcF8ruXTtqpSL53wWGl9Dq8J74JWTiVBmg 3s22n1F8RpYmfPZi66xCjtyWv+NTMUUl7V/i5hen6TwE4p4enlmtwAGuu1DDc1SC7qD/ yl1w== MIME-Version: 1.0 X-Received: by 10.182.66.77 with SMTP id d13mr13372462obt.32.1372772673183; Tue, 02 Jul 2013 06:44:33 -0700 (PDT) Sender: pali.gabor@gmail.com Received: by 10.182.65.229 with HTTP; Tue, 2 Jul 2013 06:44:33 -0700 (PDT) Date: Tue, 2 Jul 2013 15:44:33 +0200 X-Google-Sender-Auth: -1-i74eKeUavCvGVksvAMESqSaE Message-ID: Subject: FreeBSD 2013-Q2 status reports due: July 7 From: Gabor Pali To: developers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 13:44:33 -0000 On Mon, Jun 24, 2013 at 10:25 PM, Gabor Pali wrote: > On Mon, Jun 17, 2013 at 7:14 PM, Isabell Long wrote: >> It's that time again! On behalf of monthly@, I would like to inform >> you that the next submission date for the April to June quarterly >> status reports is July 7th, 2013 - less than a month away. > > Note that you have a little less than 2 weeks left to prepare and send > us your reports. There is only 5 days left... :-) From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 2 20:15:45 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 116A8254 for ; Tue, 2 Jul 2013 20:15:45 +0000 (UTC) (envelope-from torek@torek.net) Received: from elf.torek.net (50-73-42-1-utah.hfc.comcastbusiness.net [50.73.42.1]) by mx1.freebsd.org (Postfix) with ESMTP id E0A9112FF for ; Tue, 2 Jul 2013 20:15:44 +0000 (UTC) Received: from elf.torek.net (localhost [127.0.0.1]) by elf.torek.net (8.14.5/8.14.5) with ESMTP id r62KFSk4095408; Tue, 2 Jul 2013 14:15:29 -0600 (MDT) (envelope-from torek@torek.net) Message-Id: <201307022015.r62KFSk4095408@elf.torek.net> From: Chris Torek To: Daniel Braniss Subject: Re: hw.physmem/hw.realmem question In-reply-to: Your message of "Tue, 02 Jul 2013 15:32:20 +0300." Date: Tue, 02 Jul 2013 14:15:28 -0600 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.torek.net [127.0.0.1]); Tue, 02 Jul 2013 14:15:29 -0600 (MDT) Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 20:15:45 -0000 >for example, this host has has 32G of physical memory ... >[snip - dmesg:] >real memory = 34359738368 (32768 MB) >avail memory = 32191340544 (30700 MB) >[snip] >and from sysctl: >hw.physmem: 34284916736 >hw.usermem: 32964923392 >hw.realmem: 36507222016 > >after setting > hw.physmem=16G > >from dmesg: >real memory = 34359738368 (32768 MB) >avail memory = 13999382528 (13350 MB) > >and sysctl: > > hw.physmem: 14957563904 > hw.usermem: 10094678016 > hw.realmem: 17179869184 > >from the numbers, I can assume that realmem is the real physical memory, >(or whatever is set in hw.physmem), I think there are three numbers (though one is not always a single number) of interest, which I believe were the original intent of the three sysctl values ("real", "phys", and "user" memory, specially called out in sysctl.h under the "HW" section). These are: - The RAM present in hardware. This would be 32 GB on your particular system. On some machines, RAM is not even close to physically contiguous, e.g., there might be 4 GB of RAM starting at address 8 TB, then 32 GB of RAM starting at address 16 TB, then 1 TB of RAM starting at address 24 TB, on a machine where each DIMM slot is simply located at each 8-TB position (with "architectural room" for up to 8 TB per slot), and "slot 0" reserved for boot ROMs (hence physical space starting at 8 TB). These enormous "holes" in the physical space should (my opinion) be reflected in whatever interface gets you the RAM map. That makes this one not a "single number". Of course, if you can't or won't show the holes, you can make up a single number. (On x86 systems you don't have holes this big, although you do have the historical "I/O space" windows, e.g., that annoying gap at 640kB :-) . Worse, there's always a half-GB gap at 3.5GB, although some memory controllers work around this. See: http://lists.freebsd.org/pipermail/freebsd-amd64/2005-August/005849.html for example.) - The amount of "usable" RAM for the OS. This subtracts off any spaces reserved by boot ROMs / BIOSes / what-have-you, and in the case of (e.g.) FreeBSD-9 on amd64, the 1 TB direct-map limit (which you must take care of manually with the loader's hw.physmem setting). This is what "phys mem" should be and mostly is. If you boot a machine with 1.5 TB of RAM but the OS is limited to 1 TB, hw.physmem should be 1 TB minus a bit for the BIOS, etc. - The amount of memory left after subtracting more or less fixed kernel resources, such as kernel text and data (including loaded modules), page table pages, "vm_page" array data structures, and so on. This will shift over time. This is what "user mem" is, more or less -- to be exact, it's: ctob(physmem - cnt.v_wire_count) where "ctob" is "clicks to bytes" which is really "pages to bytes", as these things count in terms of pages (4K at a time, on the x86). The "wire count" is the number of pages that are not page-in/out-able, so subtracting that from physmem gives you the number of pageable, hence user-use-able, pages. There's a fourth number, which is not really very useful, but I need to describe for the below: - The highest useable physical address in the system (or really, just after that -- the same way if the machine is to count to 4, you go "0 1 2 3" and that gives you 4). This is called "Maxmem" in amd64/amd64/machdep.c (and pmap.c). Note that the printf output: real memory = ( MB) generally comes from the amount reported by the BIOS, which is different yet again! My box with 8GB says: real memory = 8589934592 (8192 MB) but on my machine, Maxmem is 8.5 GB, which also shows up in sysctl (more on that in a moment): hw.realmem: 9126805504 I have the Intel memory controller that "moves up" the shadowed (by PCI hole) RAM at 3.5 GB. If I were to set hw.physmem to 8 GB in my loader.conf, I would actually give up half a gigabyte. So, on to this: >if so, where did almost 2G go? (realmem - physmem) ... >what is physmem and realmem, and what's the relationship - if any >- between them? "hw.realmem" is a snapshot of the value of Maxmem, before a few adjustments are made. If you have 32 GB of physical RAM and you have not limited it (and you don't have the remapping noted below), "realmem" will be 32 GB. If you *have* limited it, realmem captures the limit (which I think is wrong -- the snapshot should happen earlier, at the least). "hw.physmem" results from counting up useable pages. After finding Maxmem, which gives you "maximum valid address plus 1", the machdep.c code goes through all the segments -- segments being stuff like "64k to 640k", with the first 64k off limits because BIOSes tend to munch on it and the 640k limit due to the ISA hole -- and checks that each page in that segment for useability. If the page is good, it's added to physmem. Your 2 GB (542555 pages, to be exact) is space eaten up by your BIOS and architectural holes, including the large PCI hole. Your BIOS and motherboard etc may (or may not) allow you to remap some of your "hidden" or "shadowed" RAM (out of the PCI hole), increasing the boot-time value of Maxmem, and hence also increasing both "hw.realmem" and actual, useable pages. Note: the x86's architectural holes still use up some dedicated kernel memory, even with shadowed-memory remapping: if addresses from zero to 8.5 GB are valid (as they are on my box), the kernel allocates enough "vm_page" data structures to have one for all 8.5 GB, even though there's a .5 GB PCI hole with no RAM behind it. Those pages are marked "not here, never use these" -- but they still take sizeof(struct vm_page) bytes (120 bytes) to represent. 512 MB of hole = 512*1024*1024 / 4096 = 131072 pages, which means the kernel is using 15728640 bytes (15 MB) to track this empty area. So my remapping hardware gains me 512 MB and then the kernel loses 15, for a net of 497 MB recovered. Chris From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 2 21:46:26 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 795C3B39 for ; Tue, 2 Jul 2013 21:46:26 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id DC8ED1874 for ; Tue, 2 Jul 2013 21:46:25 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7) with ESMTP id r62LjwKd004778; Tue, 2 Jul 2013 23:45:58 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.7/8.14.7/Submit) with ESMTP id r62LjvV4004775; Tue, 2 Jul 2013 23:45:57 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Tue, 2 Jul 2013 23:45:57 +0200 (CEST) From: Wojciech Puchar To: Daniel Braniss Subject: Re: hw.physmem/hw.realmem question In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (wojtek.tensor.gdynia.pl [127.0.0.1]); Tue, 02 Jul 2013 23:45:58 +0200 (CEST) Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 21:46:26 -0000 > AMD Features2=0x1 > TSC: P-state invariant, performance statistics > real memory = 34359738368 (32768 MB) > avail memory = 32191340544 (30700 MB) 2GB memory "disappears" too even when you don't set anything. i asked such a question for other machine some time ago without much answer. in your laptop it may be shared graphics memory reserved by chipset still on my dell server real memory = 34359738368 (32768 MB) avail memory = 33166921728 (31630 MB) i have over 1GB unavailable and it doesn't have shared graphics memory. it would be nice to be able to look exactly how memory is used. > Event timer "LAPIC" quality 600 > ACPI APIC Table: > > and from sysctl: > hw.physmem: 34284916736 > hw.usermem: 32964923392 > hw.realmem: 36507222016 > > after setting > hw.physmem=16G > > from dmesg: > real memory = 34359738368 (32768 MB) > avail memory = 13999382528 (13350 MB) > > and sysctl: > > hw.physmem: 14957563904 > hw.usermem: 10094678016 > hw.realmem: 17179869184 > > from the numbers, I can assume that realmem is the real physical memory, > (or whatever is set in hw.physmem), > if so, where did almost 2G go? (realmem - physmen) > > the only info I found so far is: > from loader(8): > > hw.physmem Limit the amount of physical memory the system will use. > By default the size is in bytes, but the k, K, m, M, g and > G suffixes are also accepted and indicate kilobytes, > megabytes and gigabytes respectively. An invalid suffix > will result in the variable being ignored by the kernel. > > what is physmem and realmem, and what's the relationship - if any - between > them? > > cheers, > danny > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Wed Jul 3 06:31:45 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8FE99CBA for ; Wed, 3 Jul 2013 06:31:45 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 1BF481FA1 for ; Wed, 3 Jul 2013 06:31:44 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1UuGbK-0008Cw-Eu; Wed, 03 Jul 2013 09:31:38 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Chris Torek Subject: Re: hw.physmem/hw.realmem question In-reply-to: <201307022015.r62KFSk4095408@elf.torek.net> References: <201307022015.r62KFSk4095408@elf.torek.net> Comments: In-reply-to Chris Torek message dated "Tue, 02 Jul 2013 14:15:28 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jul 2013 09:31:38 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 06:31:45 -0000 Thanks Chris! It will take me some time do fully digets all this!, but at least the picture is less murky. danny > >for example, this host has has 32G of physical memory ... > >[snip - dmesg:] > >real memory = 34359738368 (32768 MB) > >avail memory = 32191340544 (30700 MB) > >[snip] > >and from sysctl: > >hw.physmem: 34284916736 > >hw.usermem: 32964923392 > >hw.realmem: 36507222016 > > > >after setting > > hw.physmem=16G > > > >from dmesg: > >real memory = 34359738368 (32768 MB) > >avail memory = 13999382528 (13350 MB) > > > >and sysctl: > > > > hw.physmem: 14957563904 > > hw.usermem: 10094678016 > > hw.realmem: 17179869184 > > > >from the numbers, I can assume that realmem is the real physical memory, > >(or whatever is set in hw.physmem), > > I think there are three numbers (though one is not always a single > number) of interest, which I believe were the original intent of > the three sysctl values ("real", "phys", and "user" memory, > specially called out in sysctl.h under the "HW" section). These > are: > > - The RAM present in hardware. This would be 32 GB on > your particular system. > > On some machines, RAM is not even close to physically > contiguous, e.g., there might be 4 GB of RAM starting at > address 8 TB, then 32 GB of RAM starting at address 16 TB, > then 1 TB of RAM starting at address 24 TB, on a machine where > each DIMM slot is simply located at each 8-TB position (with > "architectural room" for up to 8 TB per slot), and "slot 0" > reserved for boot ROMs (hence physical space starting at 8 > TB). These enormous "holes" in the physical space should (my > opinion) be reflected in whatever interface gets you the RAM > map. That makes this one not a "single number". Of course, > if you can't or won't show the holes, you can make up a single > number. > > (On x86 systems you don't have holes this big, although you do > have the historical "I/O space" windows, e.g., that annoying > gap at 640kB :-) . Worse, there's always a half-GB gap at > 3.5GB, although some memory controllers work around this. > See: > > http://lists.freebsd.org/pipermail/freebsd-amd64/2005-August/005849.html > > for example.) > > - The amount of "usable" RAM for the OS. This subtracts off > any spaces reserved by boot ROMs / BIOSes / what-have-you, and > in the case of (e.g.) FreeBSD-9 on amd64, the 1 TB direct-map > limit (which you must take care of manually with the loader's > hw.physmem setting). > > This is what "phys mem" should be and mostly is. If you boot > a machine with 1.5 TB of RAM but the OS is limited to 1 TB, > hw.physmem should be 1 TB minus a bit for the BIOS, etc. > > - The amount of memory left after subtracting more or less fixed > kernel resources, such as kernel text and data (including loaded > modules), page table pages, "vm_page" array data structures, and > so on. This will shift over time. > > This is what "user mem" is, more or less -- to be exact, it's: > > ctob(physmem - cnt.v_wire_count) > > where "ctob" is "clicks to bytes" which is really "pages to > bytes", as these things count in terms of pages (4K at a time, > on the x86). The "wire count" is the number of pages that are > not page-in/out-able, so subtracting that from physmem gives > you the number of pageable, hence user-use-able, pages. > > There's a fourth number, which is not really very useful, but I > need to describe for the below: > > - The highest useable physical address in the system (or > really, just after that -- the same way if the machine is to > count to 4, you go "0 1 2 3" and that gives you 4). This > is called "Maxmem" in amd64/amd64/machdep.c (and pmap.c). > > Note that the printf output: > > real memory = ( MB) > > generally comes from the amount reported by the BIOS, which is > different yet again! My box with 8GB says: > > real memory = 8589934592 (8192 MB) > > but on my machine, Maxmem is 8.5 GB, which also shows up in > sysctl (more on that in a moment): > > hw.realmem: 9126805504 > > I have the Intel memory controller that "moves up" the shadowed > (by PCI hole) RAM at 3.5 GB. If I were to set hw.physmem to 8 > GB in my loader.conf, I would actually give up half a gigabyte. > > So, on to this: > > >if so, where did almost 2G go? (realmem - physmem) ... > >what is physmem and realmem, and what's the relationship - if any > >- between them? > > "hw.realmem" is a snapshot of the value of Maxmem, before a few > adjustments are made. If you have 32 GB of physical RAM and you > have not limited it (and you don't have the remapping noted > below), "realmem" will be 32 GB. If you *have* limited it, > realmem captures the limit (which I think is wrong -- the snapshot > should happen earlier, at the least). > > "hw.physmem" results from counting up useable pages. After > finding Maxmem, which gives you "maximum valid address plus 1", > the machdep.c code goes through all the segments -- segments being > stuff like "64k to 640k", with the first 64k off limits because > BIOSes tend to munch on it and the 640k limit due to the ISA hole > -- and checks that each page in that segment for useability. If > the page is good, it's added to physmem. > > Your 2 GB (542555 pages, to be exact) is space eaten up by your > BIOS and architectural holes, including the large PCI hole. Your > BIOS and motherboard etc may (or may not) allow you to remap some > of your "hidden" or "shadowed" RAM (out of the PCI hole), > increasing the boot-time value of Maxmem, and hence also > increasing both "hw.realmem" and actual, useable pages. > > Note: the x86's architectural holes still use up some dedicated > kernel memory, even with shadowed-memory remapping: if addresses > from zero to 8.5 GB are valid (as they are on my box), the kernel > allocates enough "vm_page" data structures to have one for all 8.5 > GB, even though there's a .5 GB PCI hole with no RAM behind it. > Those pages are marked "not here, never use these" -- but they > still take sizeof(struct vm_page) bytes (120 bytes) to represent. > 512 MB of hole = 512*1024*1024 / 4096 = 131072 pages, which means > the kernel is using 15728640 bytes (15 MB) to track this empty > area. So my remapping hardware gains me 512 MB and then the > kernel loses 15, for a net of 497 MB recovered. > > Chris From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 4 05:37:34 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BCD138B9; Thu, 4 Jul 2013 05:37:34 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by mx1.freebsd.org (Postfix) with ESMTP id 7D6901F16; Thu, 4 Jul 2013 05:37:34 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id f4so1364975oah.21 for ; Wed, 03 Jul 2013 22:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cEqPyVCWZlHoDbxQwKRCS4DpCw13iaQBxaHEoxY2OZA=; b=E0XrjdPhohdHVf4hRmraiCO1Gzzk9zzco5saNohKecF0CvtOQXMF8D+HzbsBf+ybAL /pQnvFMpxBAIrklIc+QKe/C7bbpKyk4Xw+4xh9E+4xZzdzMCSCrx0E5z60AaynXG3UuN mnbmilgy513SgjYISPrmF1z8leR+DyfnEz7HDb/t6+kauwm69SQ0H0v8433wBIvfKskV o8OFpQfBeeRWK4VXp2fplnQWhyQlevvlmC+A+M2Cf1ZWP9zbksl4EqgF/xbLyqWvqQRB 0MBy1xbNM5qswcoYj8e6dDwNwYD6KEEUsXlef/w+VW2cxlvTGc8RGnXxlCS6IZLrfSBH Mh7w== X-Received: by 10.182.66.137 with SMTP id f9mr4291545obt.24.1372916253840; Wed, 03 Jul 2013 22:37:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.130.204 with HTTP; Wed, 3 Jul 2013 22:37:03 -0700 (PDT) In-Reply-To: <20130108150155.GF82219@kib.kiev.ua> References: <20110129084125.GA54969@freebsd.org> <20130108150155.GF82219@kib.kiev.ua> From: Jia-Shiun Li Date: Thu, 4 Jul 2013 13:37:03 +0800 Message-ID: Subject: Re: cpufreq not working as module on i386/amd64 To: Konstantin Belousov Content-Type: multipart/mixed; boundary=089e0160c35a9ddd6c04e0a8f975 Cc: freebsd-hackers@freebsd.org, avg@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 05:37:34 -0000 --089e0160c35a9ddd6c04e0a8f975 Content-Type: text/plain; charset=UTF-8 ok anyone can help test and review this patch? It will allow cpufreq to be removed from kernel conf, loaded and function correctly as kernel module. I've tested it ok on my own i5-3450. It removes get_features method definition from acpi_if.m and corresponding implementations from est, p4tcc, & hwpstate. Feature flags are set directly in acpi_cpu.c omitting previous procedure of querying cpufreq drivers. After this, I'd like to find some ways to feed CPU loading info directly in kernel to cpufreq for finer & quicker control of frequencies. On Tue, Jan 8, 2013 at 11:01 PM, Konstantin Belousov wrote: > On Tue, Jan 08, 2013 at 01:15:59PM +0800, Jia-Shiun Li wrote: >> Hi all, >> >> move to -hackers as it seems a better place to discuss. >> >> Turns out, at acpi_cpu_attach(), the bus probe will query >> ACPI_GET_FEATURES() to get cpu_features flags from each cpufreq >> drivers. Since it is only executed once at booting, subsequent module >> loading after booting will not be called get_features() and will not >> be able to express interests in terms of ACPI_CAP_* flags. And if >> these flags were not set first, acpi_perf won't get attached. Later >> when loading cpufreq.ko, est_attach(), etc. will not be able to find >> acpi_perf and thus failed to attach. >> >> After referred to Intel doc. #302223 mentioned in >> dev/acpica/acpivar.h, I got confused by the meaning of these bits. >> According to the document, capability bits probably should be set as >> long as OSPM is *capable* of using them, no matter when they will be >> used. I am not familiar with ACPI, but I suppose it will expose >> states/methods to OSPM according to these bits? >> >> To confirm this, I add a line to simply OR'd (ACPI_CAP_PERF_MSRS | >> ACPI_CAP_C1_IO_HALT) to sc->cpu_features after the loop calling >> ACPI_GET_FEATURES(). And then I am able to load cpufreq.ko after boot. >> powerd also works fine with it. >> >> If this is true, then probably we don't need get_features() for acpi >> interface/drivers. It is sufficient to just turn on proper bits >> directly for acpi_cpu when related code is added to repository. >> >> Any comments? >> >> ----->8----->8----->8----- >> # svn diff >> Index: sys/dev/acpica/acpi_cpu.c >> =================================================================== >> --- sys/dev/acpica/acpi_cpu.c (revision 245148) >> +++ sys/dev/acpica/acpi_cpu.c (working copy) >> @@ -350,6 +350,7 @@ >> sc->cpu_features |= features; >> } >> free(drivers, M_TEMP); >> + sc->cpu_features |= ACPI_CAP_PERF_MSRS | ACPI_CAP_C1_IO_HALT; >> } > I had almost word-to-word identical conversation with Andrey Gapon, > might be a year ago. I Cc:ed him. > >> >> /* >> >> ----->8----->8----->8----- >> >> >> Jia-Shiun >> >> On Wed, Dec 26, 2012 at 2:10 AM, Jia-Shiun Li wrote: >> > I was cleaning up hard drive and found these old logs. Anyway I added >> > some printf() >> > and saw the process failed at device_find_child(..., "acpi_perf", ...) >> > of est_acpi_info() i.e. it cannot find acpi_perf device. >> > >> > devinfo did confirmed the absence of acpi_perf. Comparing the dmesgs >> > revealed the main difference: IST (i-state?) OEM tables in SSDT seems >> > not loaded if cpufreq was not compiled into kernel, as it shows below. >> > >> > Before I diving into the ACPI part, can anyone familiar with how ACPI >> > works shed me some light? >> > >> > ----->8----->8----->8----- >> > % diff -bu cpufreq-nb.log cpufreq-no.log >> > ... >> > @@ -158,17 +158,11 @@ >> > acpi0: Power Button (fixed) >> > cpu0: Processor \\_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 >> > cpu0: on acpi0 >> > -ACPI: SSDT 0xbfd8dc98 00223 (v01 PmRef Cpu0Ist 00003000 INTL 20051117) >> > -ACPI: Dynamic OEM Table Load: >> > -ACPI: SSDT 0 00223 (v01 PmRef Cpu0Ist 00003000 INTL 20051117) >> > ACPI: SSDT 0xbfd8b598 00537 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) >> > ACPI: Dynamic OEM Table Load: >> > ACPI: SSDT 0 00537 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) >> > cpu1: Processor \\_PR_.CPU1 (ACPI ID 2) -> APIC ID 1 >> > cpu1: on acpi0 >> > -ACPI: SSDT 0xbfd8ce18 001CF (v01 PmRef ApIst 00003000 INTL 20051117) >> > -ACPI: Dynamic OEM Table Load: >> > -ACPI: SSDT 0 001CF (v01 PmRef ApIst 00003000 INTL 20051117) >> > ACPI: SSDT 0xbfd8df18 0008D (v01 PmRef ApCst 00003000 INTL 20051117) >> > ACPI: Dynamic OEM Table Load: >> > ACPI: SSDT 0 0008D (v01 PmRef ApCst 00003000 INTL 20051117 >> > >> > On Sat, Jan 29, 2011 at 4:41 PM, Alexander Best wrote: >> >> On Sat Jan 29 11, Jia-Shiun Li wrote: >> >>> Hi all, >> >>> >> >>> I found that cpufreq driver failed to attach when compiled as module >> >>> and loaded, but it works fine when compiled into kernel. I am >> >>> wondering if this is due to some kind of limitation, or can be fixed? >> >> >> >> that's rather odd. for me neither the module nor the kernel code works, since >> >> my cpu isn't supported by sys/x86/cpufreq/est.c. actually only pentium mobile >> >> cpus seem to be supported. >> >> >> >> maybe you can add some printf's to est.c:est_get_info() to identify at which >> >> point error gets set. also you might want to make >> >> >> >> "est: cpu_vendor %s, msr %0jx\n", cpu_vendor, msr); >> >> >> >> non-conditional. maybe the output differy in kernel/module mode. >> >> >> >> cheers. >> >> alex >> >> >> >>> >> >>> Tested on a Pentium E5200 desktop (i386) and a Pentium T4200 laptop >> >>> (amd64). Both got the same result. dmesg of T4200 attached. >> >>> >> >>> kldload module: >> >>> ----->8----->8----->8----- >> >>> est0: on cpu0 >> >>> est: CPU supports Enhanced Speedstep, but is not recognized. >> >>> est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a >> >>> device_attach: est0 attach returned 6 >> >>> est1: on cpu1 >> >>> est: CPU supports Enhanced Speedstep, but is not recognized. >> >>> est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a >> >>> -----8<-----8<-----8<----- >> >>> (repeated 6 times, kldload retries?) >> >>> >> >>> compiled into kernel: >> >>> ----->8----->8----->8----- >> >>> ... >> >>> fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 >> >>> uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 >> >>> isa_probe_children: probing PnP devices >> >>> coretemp0: on cpu0 >> >>> coretemp0: Setting TjMax=104 >> >>> p4tcc0: on cpu0 >> >>> est0: on cpu0 >> >>> coretemp1: on cpu1 >> >>> coretemp1: Setting TjMax=104 >> >>> p4tcc1: on cpu1 >> >>> est1: on cpu1 >> >>> Device configuration finished. >> >>> procfs registered >> >>> ... >> >>> -----8<-----8<-----8<----- >> >>> >> >>> Jia-Shiun. >> >> >> >> >> >> -- >> >> a13x >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --089e0160c35a9ddd6c04e0a8f975 Content-Type: application/octet-stream; name="cpufreq-module.patch" Content-Disposition: attachment; filename="cpufreq-module.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hipirp8a1 SW5kZXg6IHN5cy9kZXYvYWNwaWNhL2FjcGlfY3B1LmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9h Y3BpY2EvYWNwaV9jcHUuYwkocmV2aXNpb24gMjUyNTM3KQorKysgc3lzL2Rldi9hY3BpY2EvYWNw aV9jcHUuYwkod29ya2luZyBjb3B5KQpAQCAtMjc5LDkgKzI3OSw3IEBACiAgICAgc3RydWN0IGFj cGlfY3B1X3NvZnRjICpzYzsKICAgICBzdHJ1Y3QgYWNwaV9zb2Z0YwkgICphY3BpX3NjOwogICAg IEFDUElfU1RBVFVTCQkgICBzdGF0dXM7Ci0gICAgdV9pbnQJCSAgIGZlYXR1cmVzOwotICAgIGlu dAkJCSAgIGNwdV9pZCwgZHJ2X2NvdW50LCBpOwotICAgIGRyaXZlcl90IAkJICAqKmRyaXZlcnM7 CisgICAgaW50CQkJICAgY3B1X2lkOwogICAgIHVpbnQzMl90CQkgICBjYXBfc2V0WzNdOwogCiAg ICAgLyogVVVJRCBuZWVkZWQgYnkgX09TQyBldmFsdWF0aW9uICovCkBAIC0zNDQsMTMgKzM0Miwx MiBAQAogICAgICAqIFNNUCBjb250cm9sIHdoZXJlIGVhY2ggQ1BVIGNhbiBoYXZlIGRpZmZlcmVu dCBzZXR0aW5ncy4KICAgICAgKi8KICAgICBzYy0+Y3B1X2ZlYXR1cmVzID0gQUNQSV9DQVBfU01Q X1NBTUUgfCBBQ1BJX0NBUF9TTVBfU0FNRV9DMzsKLSAgICBpZiAoZGV2Y2xhc3NfZ2V0X2RyaXZl cnMoYWNwaV9jcHVfZGV2Y2xhc3MsICZkcml2ZXJzLCAmZHJ2X2NvdW50KSA9PSAwKSB7Ci0JZm9y IChpID0gMDsgaSA8IGRydl9jb3VudDsgaSsrKSB7Ci0JICAgIGlmIChBQ1BJX0dFVF9GRUFUVVJF Uyhkcml2ZXJzW2ldLCAmZmVhdHVyZXMpID09IDApCi0JCXNjLT5jcHVfZmVhdHVyZXMgfD0gZmVh dHVyZXM7Ci0JfQotCWZyZWUoZHJpdmVycywgTV9URU1QKTsKLSAgICB9CisgICAgLyogZXN0ICov CisgICAgc2MtPmNwdV9mZWF0dXJlcyB8PSBBQ1BJX0NBUF9QRVJGX01TUlMgfCBBQ1BJX0NBUF9D MV9JT19IQUxUOworICAgIC8qIHA0dGNjICovCisgICAgc2MtPmNwdV9mZWF0dXJlcyB8PSBBQ1BJ X0NBUF9USFJfTVNSUzsKKyAgICAvKiBod3BzdGF0ZSAqLworICAgIHNjLT5jcHVfZmVhdHVyZXMg fD0gQUNQSV9DQVBfUEVSRl9NU1JTOwogCiAgICAgLyoKICAgICAgKiBDUFUgY2FwYWJpbGl0aWVz IGFyZSBzcGVjaWZpZWQgaW4KSW5kZXg6IHN5cy9kZXYvYWNwaWNhL2FjcGlfaWYubQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSBzeXMvZGV2L2FjcGljYS9hY3BpX2lmLm0JKHJldmlzaW9uIDI1MjUzNykKKysrIHN5 cy9kZXYvYWNwaWNhL2FjcGlfaWYubQkod29ya2luZyBjb3B5KQpAQCAtMTU5LDE5ICsxNTksNiBA QAogfTsKIAogIwotIyBRdWVyeSBhIGdpdmVuIGRyaXZlciBmb3IgaXRzIHN1cHBvcnRlZCBmZWF0 dXJlKHMpLiAgVGhpcyBzaG91bGQgYmUKLSMgY2FsbGVkIGJ5IHRoZSBwYXJlbnQgYnVzIGJlZm9y ZSB0aGUgZHJpdmVyIGlzIHByb2JlZC4KLSMKLSMgZHJpdmVyX3QgKmRyaXZlcjogIGNoaWxkIGRy aXZlcgotIwotIyB1X2ludCAqZmVhdHVyZXM6ICByZXR1cm5lZCBiaXRtYXNrIG9mIGFsbCBzdXBw b3J0ZWQgZmVhdHVyZXMKLSMKLVNUQVRJQ01FVEhPRCBpbnQgZ2V0X2ZlYXR1cmVzIHsKLQlkcml2 ZXJfdAkqZHJpdmVyOwotCXVfaW50CQkqZmVhdHVyZXM7Ci19OwotCi0jCiAjIFJlYWQgZW1iZWRk ZWQgY29udHJvbGxlciAoRUMpIGFkZHJlc3Mgc3BhY2UKICMKICMgZGV2aWNlX3QgZGV2OiAgRUMg ZGV2aWNlCkluZGV4OiBzeXMveDg2L2NwdWZyZXEvZXN0LmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL3g4 Ni9jcHVmcmVxL2VzdC5jCShyZXZpc2lvbiAyNTI1MzcpCisrKyBzeXMveDg2L2NwdWZyZXEvZXN0 LmMJKHdvcmtpbmcgY29weSkKQEAgLTg5OSw3ICs4OTksNiBAQAogfTsKIAogc3RhdGljIHZvaWQJ ZXN0X2lkZW50aWZ5KGRyaXZlcl90ICpkcml2ZXIsIGRldmljZV90IHBhcmVudCk7Ci1zdGF0aWMg aW50CWVzdF9mZWF0dXJlcyhkcml2ZXJfdCAqZHJpdmVyLCB1X2ludCAqZmVhdHVyZXMpOwogc3Rh dGljIGludAllc3RfcHJvYmUoZGV2aWNlX3QgcGFyZW50KTsKIHN0YXRpYyBpbnQJZXN0X2F0dGFj aChkZXZpY2VfdCBwYXJlbnQpOwogc3RhdGljIGludAllc3RfZGV0YWNoKGRldmljZV90IHBhcmVu dCk7CkBAIC05MjgsOSArOTI3LDYgQEAKIAlERVZNRVRIT0QoY3B1ZnJlcV9kcnZfdHlwZSwJZXN0 X3R5cGUpLAogCURFVk1FVEhPRChjcHVmcmVxX2Rydl9zZXR0aW5ncywJZXN0X3NldHRpbmdzKSwK IAotCS8qIEFDUEkgaW50ZXJmYWNlICovCi0JREVWTUVUSE9EKGFjcGlfZ2V0X2ZlYXR1cmVzLAll c3RfZmVhdHVyZXMpLAotCiAJezAsIDB9CiB9OwogCkBAIC05NDMsMTggKzkzOSw2IEBACiBzdGF0 aWMgZGV2Y2xhc3NfdCBlc3RfZGV2Y2xhc3M7CiBEUklWRVJfTU9EVUxFKGVzdCwgY3B1LCBlc3Rf ZHJpdmVyLCBlc3RfZGV2Y2xhc3MsIDAsIDApOwogCi1zdGF0aWMgaW50Ci1lc3RfZmVhdHVyZXMo ZHJpdmVyX3QgKmRyaXZlciwgdV9pbnQgKmZlYXR1cmVzKQotewotCi0JLyoKLQkgKiBOb3RpZnkg dGhlIEFDUEkgQ1BVIHRoYXQgd2Ugc3VwcG9ydCBkaXJlY3QgYWNjZXNzIHRvIE1TUnMuCi0JICog WFhYIEMxICJJL08gdGhlbiBIYWx0IiBzZWVtcyBuZWNlc3NhcnkgZm9yIHNvbWUgYnJva2VuIEJJ T1MuCi0JICovCi0JKmZlYXR1cmVzID0gQUNQSV9DQVBfUEVSRl9NU1JTIHwgQUNQSV9DQVBfQzFf SU9fSEFMVDsKLQlyZXR1cm4gKDApOwotfQotCiBzdGF0aWMgdm9pZAogZXN0X2lkZW50aWZ5KGRy aXZlcl90ICpkcml2ZXIsIGRldmljZV90IHBhcmVudCkKIHsKSW5kZXg6IHN5cy94ODYvY3B1ZnJl cS9od3BzdGF0ZS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy94ODYvY3B1ZnJlcS9od3BzdGF0ZS5jCShy ZXZpc2lvbiAyNTI1MzcpCisrKyBzeXMveDg2L2NwdWZyZXEvaHdwc3RhdGUuYwkod29ya2luZyBj b3B5KQpAQCAtMTEyLDcgKzExMiw2IEBACiBzdGF0aWMgaW50CWh3cHN0YXRlX3NldHRpbmdzKGRl dmljZV90IGRldiwgc3RydWN0IGNmX3NldHRpbmcgKnNldHMsIGludCAqY291bnQpOwogc3RhdGlj IGludAlod3BzdGF0ZV90eXBlKGRldmljZV90IGRldiwgaW50ICp0eXBlKTsKIHN0YXRpYyBpbnQJ aHdwc3RhdGVfc2h1dGRvd24oZGV2aWNlX3QgZGV2KTsKLXN0YXRpYyBpbnQJaHdwc3RhdGVfZmVh dHVyZXMoZHJpdmVyX3QgKmRyaXZlciwgdV9pbnQgKmZlYXR1cmVzKTsKIHN0YXRpYyBpbnQJaHdw c3RhdGVfZ2V0X2luZm9fZnJvbV9hY3BpX3BlcmYoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBwZXJm X2Rldik7CiBzdGF0aWMgaW50CWh3cHN0YXRlX2dldF9pbmZvX2Zyb21fbXNyKGRldmljZV90IGRl dik7CiBzdGF0aWMgaW50CWh3cHN0YXRlX2dvdG9fcHN0YXRlKGRldmljZV90IGRldiwgaW50IHBz dGF0ZV9pZCk7CkBAIC0xMzYsOSArMTM1LDYgQEAKIAlERVZNRVRIT0QoY3B1ZnJlcV9kcnZfc2V0 dGluZ3MsCWh3cHN0YXRlX3NldHRpbmdzKSwKIAlERVZNRVRIT0QoY3B1ZnJlcV9kcnZfdHlwZSwJ aHdwc3RhdGVfdHlwZSksCiAKLQkvKiBBQ1BJIGludGVyZmFjZSAqLwotCURFVk1FVEhPRChhY3Bp X2dldF9mZWF0dXJlcywJaHdwc3RhdGVfZmVhdHVyZXMpLAotCiAJezAsIDB9CiB9OwogCkBAIC00 OTMsMTIgKzQ4OSwzIEBACiAJLyogaHdwc3RhdGVfZ290b19wc3RhdGUoZGV2LCAwKTsgKi8KIAly ZXR1cm4gKDApOwogfQotCi1zdGF0aWMgaW50Ci1od3BzdGF0ZV9mZWF0dXJlcyhkcml2ZXJfdCAq ZHJpdmVyLCB1X2ludCAqZmVhdHVyZXMpCi17Ci0KLQkvKiBOb3RpZnkgdGhlIEFDUEkgQ1BVIHRo YXQgd2Ugc3VwcG9ydCBkaXJlY3QgYWNjZXNzIHRvIE1TUnMgKi8KLQkqZmVhdHVyZXMgPSBBQ1BJ X0NBUF9QRVJGX01TUlM7Ci0JcmV0dXJuICgwKTsKLX0KSW5kZXg6IHN5cy94ODYvY3B1ZnJlcS9w NHRjYy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHN5cy94ODYvY3B1ZnJlcS9wNHRjYy5jCShyZXZpc2lvbiAy NTI1MzcpCisrKyBzeXMveDg2L2NwdWZyZXEvcDR0Y2MuYwkod29ya2luZyBjb3B5KQpAQCAtNjks NyArNjksNiBAQAogI2RlZmluZSBUQ0NfUkVHX09GRlNFVAkJMQogI2RlZmluZSBUQ0NfU1BFRURf UEVSQ0VOVCh4KQkoKDEwMDAwICogKHgpKSAvIFRDQ19OVU1fU0VUVElOR1MpCiAKLXN0YXRpYyBp bnQJcDR0Y2NfZmVhdHVyZXMoZHJpdmVyX3QgKmRyaXZlciwgdV9pbnQgKmZlYXR1cmVzKTsKIHN0 YXRpYyB2b2lkCXA0dGNjX2lkZW50aWZ5KGRyaXZlcl90ICpkcml2ZXIsIGRldmljZV90IHBhcmVu dCk7CiBzdGF0aWMgaW50CXA0dGNjX3Byb2JlKGRldmljZV90IGRldik7CiBzdGF0aWMgaW50CXA0 dGNjX2F0dGFjaChkZXZpY2VfdCBkZXYpOwpAQCAtOTMsOSArOTIsNiBAQAogCURFVk1FVEhPRChj cHVmcmVxX2Rydl90eXBlLAlwNHRjY190eXBlKSwKIAlERVZNRVRIT0QoY3B1ZnJlcV9kcnZfc2V0 dGluZ3MsCXA0dGNjX3NldHRpbmdzKSwKIAotCS8qIEFDUEkgaW50ZXJmYWNlICovCi0JREVWTUVU SE9EKGFjcGlfZ2V0X2ZlYXR1cmVzLAlwNHRjY19mZWF0dXJlcyksCi0KIAl7MCwgMH0KIH07CiAK QEAgLTEwOCwxNSArMTA0LDYgQEAKIHN0YXRpYyBkZXZjbGFzc190IHA0dGNjX2RldmNsYXNzOwog RFJJVkVSX01PRFVMRShwNHRjYywgY3B1LCBwNHRjY19kcml2ZXIsIHA0dGNjX2RldmNsYXNzLCAw LCAwKTsKIAotc3RhdGljIGludAotcDR0Y2NfZmVhdHVyZXMoZHJpdmVyX3QgKmRyaXZlciwgdV9p bnQgKmZlYXR1cmVzKQotewotCi0JLyogTm90aWZ5IHRoZSBBQ1BJIENQVSB0aGF0IHdlIHN1cHBv cnQgZGlyZWN0IGFjY2VzcyB0byBNU1JzICovCi0JKmZlYXR1cmVzID0gQUNQSV9DQVBfVEhSX01T UlM7Ci0JcmV0dXJuICgwKTsKLX0KLQogc3RhdGljIHZvaWQKIHA0dGNjX2lkZW50aWZ5KGRyaXZl cl90ICpkcml2ZXIsIGRldmljZV90IHBhcmVudCkKIHsK --089e0160c35a9ddd6c04e0a8f975-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 4 13:49:22 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ED9B6863 for ; Thu, 4 Jul 2013 13:49:22 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 7401E1766 for ; Thu, 4 Jul 2013 13:49:22 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id ea20so1235909lab.8 for ; Thu, 04 Jul 2013 06:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Uk9+jwtKjsxnlW6w81u3i54x/qYmYAbupVhVlHtfJ24=; b=0DFfME8/ky2wl+JNyTUiWjoZR+oqPqk9Yi/8bv+NnTmXOon9E8pKckXZIIApGTzRZo Ld3ZYSlk3qMTW61DoX9FMVLPh44S8ldSAkBXgzrvMlbD9eAcXcm1fmeqqwy/+Wa4JhAD hEdRIfPBxo3GVArV9NKZDMfvePuSvsP4Vs4tVR0fg5fp0IR6fT4wGNhTQzx9YSzxIgu3 nUK2jSK6f4d6W28o2WKm17tL98+6kAne+dNtsHu1uFhqSqSIv9lT4MSPshBmvQ5EykgR PFeP+rw+ICnlcVoDIrzjCjYN6yPLN4hHRHPBczMWKjT9q28txIhZiYxa+sEoREm4L+T3 y2EA== X-Received: by 10.152.27.137 with SMTP id t9mr2994931lag.28.1372945761486; Thu, 04 Jul 2013 06:49:21 -0700 (PDT) Received: from [192.168.1.139] (mau.donbass.com. [92.242.127.250]) by mx.google.com with ESMTPSA id n17sm1318997lbv.2.2013.07.04.06.49.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Jul 2013 06:49:20 -0700 (PDT) Message-ID: <51D57D5F.50008@gmail.com> Date: Thu, 04 Jul 2013 16:49:19 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130627 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jia-Shiun Li Subject: Re: cpufreq not working as module on i386/amd64 References: <20110129084125.GA54969@freebsd.org> <20130108150155.GF82219@kib.kiev.ua> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 13:49:23 -0000 04.07.2013 08:37, Jia-Shiun Li wrote: > ok anyone can help test and review this patch? > > It will allow cpufreq to be removed from kernel conf, loaded and > function correctly as kernel module. I've tested it ok on my own > i5-3450. Works here at AMD X4 750K: # kldload cpufreq Jul 4 16:00:11 ar1l0u kernel: hwpstate0: on cpu0 # sysctl -a | grep cpufreq debug.cpufreq.lowest: 0 debug.cpufreq.verbose: 0 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 # kldunload cpufreq Jul 4 16:48:26 ar1l0u kernel: hwpstate0: detached -- Sphinx of black quartz, judge my vow. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 4 14:58:31 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5EE30FC8 for ; Thu, 4 Jul 2013 14:58:31 +0000 (UTC) (envelope-from mailist@yandex.com) Received: from forward16.mail.yandex.net (forward16.mail.yandex.net [IPv6:2a02:6b8:0:1402::1]) by mx1.freebsd.org (Postfix) with ESMTP id B5E611ADE for ; Thu, 4 Jul 2013 14:58:28 +0000 (UTC) Received: from web8g.yandex.ru (web8g.yandex.ru [95.108.252.108]) by forward16.mail.yandex.net (Yandex) with ESMTP id 94FC9D21000 for ; Thu, 4 Jul 2013 18:58:26 +0400 (MSK) Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web8g.yandex.ru (Yandex) with ESMTP id 4C45243F0001; Thu, 4 Jul 2013 18:58:26 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1372949906; bh=VBJ6DANyvOVjNiuDkNEZ2H7oLcCQKD7/vGNNu7EwVVE=; h=From:To:Subject:Date; b=Vl2pnam2Ba1Qox7jQFM1IwN/Oh7DLSsBw8vqOZn2GlWcv6GQJtiUA24fOqsPLM4Dg iUPjDJiGsymJGdpHsp5QMt2mIVw9NbwoV8Fn8HwfoVC+vOh/D73L5OeNeHJsGtfB5W ViLrAh4xf3M+g6bPdosrwcSHAvBnnRw7AboKgw5Y= Received: from 78.161.187.1.dynamic.ttnet.com.tr (78.161.187.1.dynamic.ttnet.com.tr [78.161.187.1]) by web8g.yandex.ru with HTTP; Thu, 04 Jul 2013 18:58:25 +0400 From: =?utf-8?B?RW1yZSDDh2FtYWxhbg==?= Envelope-From: mailist@yandex.com.tr To: freebsd-hackers@freebsd.org Subject: HP ILO FreeBSD 8.3 Installation problem MIME-Version: 1.0 Message-Id: <201711372949905@web8g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 04 Jul 2013 17:58:25 +0300 Content-Type: multipart/mixed; boundary="----==--bound.20172.web8g.yandex.ru" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 14:58:31 -0000 ------==--bound.20172.web8g.yandex.ru Content-Transfer-Encoding: 7bit Content-Type: text/plain Hi, I'm trying to install FreeBSD with an HP ILO 4 advanced, web interface. I tried to install FreeBSD 8.2, FreeBSD 8.3 and FreeBSD 8.4. I tried to use acd0 and cd0 as media. I got the same result. Details about the problem I attach pictures. ERROR: I'm trying to add freebsd8.3iso from ILO such as virtual drive not from cd or dvd. Error: mounting /dev/acd0 on /dist: Input/output error (5) other ERROR: Unable to initialize selected media. Would you like to adjust your media configuration and try again? ------==--bound.20172.web8g.yandex.ru-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 5 08:53:51 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3E1B0CA6 for ; Fri, 5 Jul 2013 08:53:51 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id EECE21C88 for ; Fri, 5 Jul 2013 08:53:50 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Uv1lv-0000wY-9K for freebsd-hackers@freebsd.org; Fri, 05 Jul 2013 11:53:43 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-hackers@freebsd.org Subject: make buildworld is now 50% slower Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Jul 2013 11:53:43 +0300 From: Daniel Braniss Message-ID: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 08:53:51 -0000 Hi, after today's update of 9.1-STABLE I noticed that make build[world|kernel] are taking conciderable more time, is it because the upgrade of clang? and if so, is the code produced any better? before: buildwordl: 26m4.52s real 2h28m32.12s user 36m6.27s sys buildkernel: 7m29.42s real 23m22.22s user 4m26.26s sys today: buildwordl: 34m29.80s real 2h38m9.37s user 37m7.61s sys buildkernel: 15m31.52s real 22m59.40s user 4m33.06s sys danny From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 5 09:01:50 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6B6D51FC for ; Fri, 5 Jul 2013 09:01:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B7BA61D70 for ; Fri, 5 Jul 2013 09:01:49 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA26625; Fri, 05 Jul 2013 12:01:41 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Uv1tc-000JA8-SP; Fri, 05 Jul 2013 12:01:40 +0300 Message-ID: <51D68B23.1020104@FreeBSD.org> Date: Fri, 05 Jul 2013 12:00:19 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jia-Shiun Li Subject: Re: cpufreq not working as module on i386/amd64 References: <20110129084125.GA54969@freebsd.org> <20130108150155.GF82219@kib.kiev.ua> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 09:01:50 -0000 on 04/07/2013 08:37 Jia-Shiun Li said the following: > ok anyone can help test and review this patch? I can not bless this change, but I won't argue against it either. My opinion is still that OS should advertise to ACPI the capabilities that it actually has not those that it potentially may have. So I prefer the status quo. I think that this is a minor issue and cpufreq should just be in kernel, and that's it. > It will allow cpufreq to be removed from kernel conf, loaded and > function correctly as kernel module. I've tested it ok on my own > i5-3450. > > It removes get_features method definition from acpi_if.m and > corresponding implementations from est, p4tcc, & hwpstate. Feature > flags are set directly in acpi_cpu.c omitting previous procedure of > querying cpufreq drivers. > > > After this, I'd like to find some ways to feed CPU loading info > directly in kernel to cpufreq for finer & quicker control of > frequencies. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 5 21:03:26 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D3A6C3C7; Fri, 5 Jul 2013 21:03:26 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by mx1.freebsd.org (Postfix) with ESMTP id 952B212EF; Fri, 5 Jul 2013 21:03:26 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id g12so3861597oah.39 for ; Fri, 05 Jul 2013 14:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1RjaC/4/87qACydRUU7pr2GdZdaJrBg7Q19LVL77SYw=; b=Pvf7qryHtzaFvxtrECTqd1frwpE9Dsl3bmLvMb3llTmC7AMPD1LALu3mD8iDSeCwA6 gizQLXwmNHK33H+Xg91Yf8EZd+D1WyWTG724F4Ruyb2yI7VZ0vLN6tXlF1Exn+bz7KGC HNvHwkJd4EovFsrccuUsEbUWPBnK6BPQrZzRFiD4EjXE3ELQ9luaCMpcFiIvJYKlgkEu qRepWjUTqoAbgCdGWZo8YNoaVdlDRPnlO/dTUeAIUVA35HUWPdp4xV7HRKKXKSu0MhSu AXR0mO1sK3+tQHkMRjMxBfF+cF0MS8nXo25wwym51salW75f1KkADZ/rCZejVfHMqoXV 89nA== X-Received: by 10.60.146.134 with SMTP id tc6mr12737073oeb.95.1373058206079; Fri, 05 Jul 2013 14:03:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.130.204 with HTTP; Fri, 5 Jul 2013 14:02:55 -0700 (PDT) In-Reply-To: <51D68B23.1020104@FreeBSD.org> References: <20110129084125.GA54969@freebsd.org> <20130108150155.GF82219@kib.kiev.ua> <51D68B23.1020104@FreeBSD.org> From: Jia-Shiun Li Date: Sat, 6 Jul 2013 05:02:55 +0800 Message-ID: Subject: Re: cpufreq not working as module on i386/amd64 To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 21:03:26 -0000 On Fri, Jul 5, 2013 at 5:00 PM, Andriy Gapon wrote: > I can not bless this change, but I won't argue against it either. > > My opinion is still that OS should advertise to ACPI the capabilities that it > actually has not those that it potentially may have. So I prefer the status > quo. I think that this is a minor issue and cpufreq should just be in kernel, > and that's it. > May I know your concern? My understanding is that ACPI may export different interfaces according to _PDC evaluation. I think though ACPI may export more than actually used, as long as nobody is playing with the additional interfaces, there should be no side effects. Or these interfaces may have dependencies or interactions I am not aware of? Flexibility is good as long as it does not introduce too much complexicity. It could have benefit of less compile time, smaller size, less boot up time, etc. Regards, Jia-Shiun. From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 6 22:58:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C6F61473; Sat, 6 Jul 2013 22:58:08 +0000 (UTC) (envelope-from pali.gabor@gmail.com) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id 7F22F18CE; Sat, 6 Jul 2013 22:58:08 +0000 (UTC) Received: by mail-ob0-f180.google.com with SMTP id eh20so4205317obb.11 for ; Sat, 06 Jul 2013 15:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=AjigpH6+yL0VQQIog7RpG+EINTeXk9lGW7goO9mQbDY=; b=knD1/50MNOQNEgmj/+dyjvZjjkQlVtZ0dKOrzigltr8fGXnyZQYsRUZtlaXZOwkEK7 U/Ab54cK7+yMJA8Et8GAFZMm07sdPQatCu+kby/CU+YgMLYjUhbLXJKMdPPF+SYIbMr7 RpgzadjIY+1h7IfKZsLlUMk0jpyT/1V1pGQthzP7s8Xk/v9d8/3BpnFg1t7cklHJOEWx kBJFj+TOmz30MbTfmTzNDTvtGAmJ9CwaS6M1B2I7TLN2F/pahdB31HYpPYF198P0Mjqf Z/kV4LOdlUW8+COXLG958tlPfKby+kCnQ3HJIJFzktQuEntUonhhePivb2YlbqdUOMco 1yPg== MIME-Version: 1.0 X-Received: by 10.60.34.194 with SMTP id b2mr16058861oej.2.1373151487373; Sat, 06 Jul 2013 15:58:07 -0700 (PDT) Sender: pali.gabor@gmail.com Received: by 10.182.27.101 with HTTP; Sat, 6 Jul 2013 15:58:07 -0700 (PDT) Date: Sun, 7 Jul 2013 00:58:07 +0200 X-Google-Sender-Auth: TJzByZkga69Mi6QjstpV4HMpe-Q Message-ID: Subject: Final Reminder: FreeBSD 2013-Q2 status reports due: July 7 (Today!) From: Gabor Pali To: developers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 22:58:08 -0000 On Tue, Jul 2, 2013 at 3:44 PM, Gabor Pali wrote: > On Mon, Jun 24, 2013 at 10:25 PM, Gabor Pali wrote: >> On Mon, Jun 17, 2013 at 7:14 PM, Isabell Long wrote: >>> It's that time again! On behalf of monthly@, I would like to inform >>> you that the next submission date for the April to June quarterly >>> status reports is July 7th, 2013 - less than a month away. >> >> Note that you have a little less than 2 weeks left to prepare and send >> us your reports. > > There is only 5 days left... :-) Just for your information, today is the deadline for submitting those reports.