From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 10:53:59 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87F6F1065672 for ; Sun, 17 Jul 2011 10:53:59 +0000 (UTC) (envelope-from ml@os2.kiev.ua) Received: from s1.sdv.com.ua (s1.sdv.com.ua [77.120.97.61]) by mx1.freebsd.org (Postfix) with ESMTP id 475E28FC0A for ; Sun, 17 Jul 2011 10:53:59 +0000 (UTC) Received: from 90-105-243-80.cust.centrio.cz ([80.243.105.90] helo=[192.168.100.107]) by s1.sdv.com.ua with esmtpsa (SSLv3:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QiObV-000Pol-KD for freebsd-stable@freebsd.org; Sun, 17 Jul 2011 13:29:44 +0300 Message-ID: <4E22B98F.20008@os2.kiev.ua> Date: Sun, 17 Jul 2011 12:29:35 +0200 From: Alex Samorukov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SA-Score: -1.0 Subject: Dtrace with PHP scripts works on FreeBSD8-STABLE! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 10:53:59 -0000 Hello, I was able to compile [1] and and run PHP Dtrace provider on FreeBSD-STABLE. Everything works as expected and looks very cool. It works both from Apache (mod_php) and cli. If there are port commiters with dtrace experience - please, take it. Below there is a small demo: This is a test script: PrintTest(); class demoClass{ function demoClass(){ @chdir("/notexists"); } function PrintTest(){ echo "TEST\n"; } } ?> This is the most basic output to demonstrate how provider works: # dtrace -n 'php*::: /arg0/ {printf("\t\t%s%s%s",copyinstr(arg3),copyinstr(arg4),copyinstr(arg0))}' dtrace: description 'php*::: ' matched 24 probes dtrace: buffer size lowered to 2m CPU ID FUNCTION:NAME 2 44455 php_dtrace_execute_internal:function-entry file_get_contents 2 44457 php_dtrace_execute_internal:function-return file_get_contents 2 44456 php_dtrace_execute:function-entry demoClass::demoClass 2 44455 php_dtrace_execute_internal:function-entry chdir 2 44457 php_dtrace_execute_internal:function-return chdir 2 44458 php_dtrace_execute:function-return demoClass::demoClass 2 44456 php_dtrace_execute:function-entry demoClass::PrintTest 2 44458 php_dtrace_execute:function-return demoClass::PrintTest As you could see there is information about all functions (and classnames) in our test. Also there is a possibility to trace syscalls used by PHP function. This is output from ./php_syscolors.d (with minor modifications): for the file_get_contents (reads file to variable): 1 16019/100898 6 test.php:4 func -> file_get_contents 1 16019/100898 18 ":- syscall -> __getcwd 1 16019/100898 8 ":- syscall <- __getcwd 1 16019/100898 8 ":- syscall -> clock_gettime 1 16019/100898 4 ":- syscall <- clock_gettime 1 16019/100898 5 ":- syscall -> open 1 16019/100898 9 ":- syscall <- open 1 16019/100898 5 ":- syscall -> fstat 1 16019/100898 5 ":- syscall <- fstat 1 16019/100898 4 ":- syscall -> lseek 1 16019/100898 4 ":- syscall <- lseek 1 16019/100898 5 ":- syscall -> fstat 1 16019/100898 4 ":- syscall <- fstat 1 16019/100898 4 ":- syscall -> read 1 16019/100898 6 ":- syscall <- read 1 16019/100898 9 ":- syscall -> read 1 16019/100898 5 ":- syscall <- read 1 16019/100898 4 ":- syscall -> read 1 16019/100898 4 ":- syscall <- read 1 16019/100898 5 ":- syscall -> close 1 16019/100898 10 ":- syscall <- close 1 16019/100898 8 test.php:4 func <- file_get_contents Of course it is possible to use aggregations, filtering and all other dtrace features. Problems: I found that buffer size in dtrace is always about 2m. I am using a lot of events while trying to debug running web server. Todo: latest PHP alpha releases include dtrace support internally (and it is extended, compared to this pecl extension). Currently build failing on BSD and i had no time to investigate problem source (i think they are using some ugly linker hacks). It would be great to get it fixed before PHP release to have it in FreeBSD out of the box. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=158983 From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 10:06:17 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 450A01065670 for ; Mon, 18 Jul 2011 10:06:17 +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 4D34B8FC20 for ; Mon, 18 Jul 2011 10:06:15 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA20500; Mon, 18 Jul 2011 13:06:14 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E240596.3030702@FreeBSD.org> Date: Mon, 18 Jul 2011 13:06:14 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: lev@FreeBSD.org References: <1856442536.20110717011928@serebryakov.spb.ru> In-Reply-To: <1856442536.20110717011928@serebryakov.spb.ru> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: Please, MFC r204087 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 10:06:17 -0000 on 17/07/2011 00:19 Lev Serebryakov said the following: > Hello, Freebsd-stable. > > I've got panics, related to race, fixed in r204087, every second > reboot on my 8-STABLE. This patch fixed them all. > > Applying custom patch after each update is painful. You would get a better a chance of anyone looking into your request if you provided a link to the commit or the commit log. Just saying... -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 10:58:11 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3BFB106564A for ; Mon, 18 Jul 2011 10:58:10 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 81D148FC0A for ; Mon, 18 Jul 2011 10:58:09 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.4/8.14.4) with ESMTP id p6IAcMcQ012694 for ; Mon, 18 Jul 2011 12:38:23 +0200 Received: from pmp.uni-hannover.de (unknown [130.75.117.3]) by www.pmp.uni-hannover.de (Postfix) with SMTP id C772372 for ; Mon, 18 Jul 2011 12:38:22 +0200 (CEST) Date: Mon, 18 Jul 2011 12:38:22 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-stable@freebsd.org Message-Id: <20110718123822.b47c9e7e.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.7.18.102714 Subject: diskless booting with 8.2 regression? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gerrit.kuehn@aei.mpg.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 10:58:11 -0000 Hi all, I just updated my nfs/tftp server for diskless booting from 8.0-rel to 8.2-stable. I have a bunch of Linux clients that used to work with the 8.0-setup, but fail to boot now. On the server side I see Jul 18 11:18:24 mclane tftpd[72434]: Got ERROR packet: TFTP Aborted in the log/messages, but the Linux kernel appears to be transferred over the net just fine (so this is probably not the real issue). It starts to boot and fails at some later point (with no apparent error message on screen) causing an endless reboot loop. I already googled for quite some time on this now, but nothing useful came up. The error message above seems to be harmless, at least the machines of people reporting them work nevertheless. Are there any known issues/regressions with tftp/nfs diskless booting? I read in some posts that people were vaguely "having problems" with it when updating to 8.2-something, but could not find any details. Are there any further hints what I could do to narrow down the problem? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 11:12:47 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13C0E1065678; Mon, 18 Jul 2011 11:12:47 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id CDF5E8FC15; Mon, 18 Jul 2011 11:12:46 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:699c:2567:b544:4319]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id A36DA4AC2D; Mon, 18 Jul 2011 15:12:45 +0400 (MSD) Date: Mon, 18 Jul 2011 15:12:43 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <18310331806.20110718151243@serebryakov.spb.ru> To: Andriy Gapon In-Reply-To: <4E240596.3030702@FreeBSD.org> References: <1856442536.20110717011928@serebryakov.spb.ru> <4E240596.3030702@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: lev@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Please, MFC r204087 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 11:12:47 -0000 Hello, Andriy. You wrote 18 =E8=FE=EB=FF 2011 =E3., 14:06:14: >> I've got panics, related to race, fixed in r204087, every second >> reboot on my 8-STABLE. This patch fixed them all. >> Applying custom patch after each update is painful. > You would get a better a chance of anyone looking into your request if you > provided a link to the commit or the commit log. > Just saying... Really, message was sent to committer too. But here is a links: http://svnweb.freebsd.org/base?view=3Drevision&revision=3D204087 Log Message: Fix a race in regard of p_numthreads. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 14:02:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2CAA1065670 for ; Mon, 18 Jul 2011 14:02:28 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 745478FC12 for ; Mon, 18 Jul 2011 14:02:28 +0000 (UTC) Received: by vxg33 with SMTP id 33so3039188vxg.13 for ; Mon, 18 Jul 2011 07:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rYT1uwlymmNSNWN+sJmcy55QKzyCOgIrDqqnf5JQxYQ=; b=H+NDnZkXQcX0ZE/Q8GiTPlTAoyCdzcEB1Tw+hR/SK4bEniT2sxqnrUWQbetNiQaqVi W+BVNv6eZtq4tQbHnvBP/asSDE5vgLZ9elYB+dz+sqV6oQmx+bJNMpOpsrnpYPLf40iu RSKSkltWydqBbK59Im9REJH6hjMA5ynaQbUDQ= MIME-Version: 1.0 Received: by 10.52.38.230 with SMTP id j6mr1946364vdk.390.1310997747842; Mon, 18 Jul 2011 07:02:27 -0700 (PDT) Received: by 10.52.113.161 with HTTP; Mon, 18 Jul 2011 07:02:27 -0700 (PDT) In-Reply-To: <4E1F554A.90405@gmail.com> References: <20110712151858.GA1091@faust> <4E1F554A.90405@gmail.com> Date: Mon, 18 Jul 2011 15:02:27 +0100 Message-ID: From: Tom Evans To: Jim Bryant Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org, Zoran Kolic Subject: Re: recommendations for laptop and desktop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 14:02:28 -0000 On Thu, Jul 14, 2011 at 9:44 PM, Jim Bryant wrote: > stay away from newer hp laptops. > HP also like to lock-down which wifi cards you can use from BIOS - the machines won't complete POST with a 'bad' wifi card, so that's another strike as far as I am concerned. I've never had problems from modern dell laptops with nvidia graphics. I'm typing this on a Dell Latitude E6410 - Core i5, iwn wifi, em lan, nvidia graphics, webcam supported by webcamd... Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 14:35:57 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60728106566B for ; Mon, 18 Jul 2011 14:35:57 +0000 (UTC) (envelope-from zkolic@sbb.rs) Received: from smtp3.sbb.rs (smtp3.sbb.rs [89.216.2.35]) by mx1.freebsd.org (Postfix) with ESMTP id D07F78FC12 for ; Mon, 18 Jul 2011 14:35:56 +0000 (UTC) Received: from mycenae (cable-94-189-188-210.dynamic.sbb.rs [94.189.188.210]) by smtp3.sbb.rs (8.14.0/8.14.0) with ESMTP id p6IEZrre019212 for ; Mon, 18 Jul 2011 16:35:54 +0200 Received: by mycenae (Postfix, from userid 1001) id 2AFC25C5E; Mon, 18 Jul 2011 16:36:16 +0200 (CEST) Date: Mon, 18 Jul 2011 16:36:16 +0200 From: Zoran Kolic To: freebsd-stable@freebsd.org Message-ID: <20110718143616.GA1241@mycenae.sbb.rs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: -1.8 Subject: recommendations for laptop and desktop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 14:35:57 -0000 > I'm typing this on a Dell Latitude E6410 - Core i5, iwn wifi, em lan, > nvidia graphics, webcam supported by webcamd... There seems to be one interesting new laptop, lenovo e320, coded as 685D089. It is i3, 3000hd graphics, probably 5100 wifi. Model with freedos for about 460 euros. Matte screen, as far as I could find right now. And 13 inch. Available for 3-4 weeks. I assume 9.0 will have code ready. Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 15:08:45 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB2E1106566B for ; Mon, 18 Jul 2011 15:08:45 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA1F8FC0A for ; Mon, 18 Jul 2011 15:08:44 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.4/8.14.4) with ESMTP id p6IF8aCJ000808 for ; Mon, 18 Jul 2011 17:08:37 +0200 Received: from pmp.uni-hannover.de (unknown [130.75.117.3]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 9BB1372 for ; Mon, 18 Jul 2011 17:08:36 +0200 (CEST) Date: Mon, 18 Jul 2011 17:08:36 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-stable@freebsd.org Message-Id: <20110718170836.b40ff254.gerrit@pmp.uni-hannover.de> In-Reply-To: <20110718123822.b47c9e7e.gerrit@pmp.uni-hannover.de> References: <20110718123822.b47c9e7e.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 3.0.3 (GTK+ 2.22.1; amd64-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.7.18.150015 Subject: Re: diskless booting with 8.2 regression? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gerrit.kuehn@aei.mpg.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 15:08:45 -0000 On Mon, 18 Jul 2011 12:38:22 +0200 Gerrit K=FChn wrote about diskless booting with 8.2 regression?: I guess I found the root of all evil now: device nodes on zfs! This is how a linux /dev/console looked on the 8.0-FreeBSD server on zfsv15: crw------- 1 root wheel 5, 1 Oct 28 2010 /tank/diskless/gco-fe2/dev/= console Now, after updating to FreeBSD-8.2 and zfsv28 it looks like this on the ser= ver: crw-r--r-- 1 root wheel 255, 0xffff00ff Jul 18 16:33 /tank/diskless/pt-f= e2/dev/console Strange enough, the Linux client still displays the correct values when usi= ng "ls -la", but it refuses to work properly. I tried creating new device nodes from the client side with mknod and I tri= ed getting correct ones from a backup, but they always end up being broken.= Even movong the directories over to a ufs volume leaves them unusable: crw-r--r-- 1 root wheel 0, 0 Jul 18 16:33 /tmp/console Luckily, I am back into business now with my machines, because moving the s= tuff from zfs to ufs and dropping in a correct version of /dev on the ufs s= ide works just fine. However, it would be great if this could be fixed, because I do not have ma= ny ufs partitions left these days... cu Gerrit GK> Hi all, GK>=20 GK> I just updated my nfs/tftp server for diskless booting from 8.0-rel to GK> 8.2-stable. I have a bunch of Linux clients that used to work with the GK> 8.0-setup, but fail to boot now. GK>=20 GK> On the server side I see GK>=20 GK> Jul 18 11:18:24 mclane tftpd[72434]: Got ERROR packet: TFTP Aborted GK>=20 GK> in the log/messages, but the Linux kernel appears to be transferred GK> over the net just fine (so this is probably not the real issue). It GK> starts to boot and fails at some later point (with no apparent error GK> message on screen) causing an endless reboot loop. GK> I already googled for quite some time on this now, but nothing useful GK> came up. The error message above seems to be harmless, at least the GK> machines of people reporting them work nevertheless. GK>=20 GK> Are there any known issues/regressions with tftp/nfs diskless booting? GK> I read in some posts that people were vaguely "having problems" with GK> it when updating to 8.2-something, but could not find any details. Are GK> there any further hints what I could do to narrow down the problem? GK>=20 GK>=20 GK> cu GK> Gerrit GK> _______________________________________________ GK> freebsd-stable@freebsd.org mailing list GK> http://lists.freebsd.org/mailman/listinfo/freebsd-stable GK> To unsubscribe, send any mail to GK> "freebsd-stable-unsubscribe@freebsd.org" GK>=20 From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 19:13:21 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFFE51065742 for ; Mon, 18 Jul 2011 19:13:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C76CE8FC19 for ; Mon, 18 Jul 2011 19:13:21 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 77D7146B2A; Mon, 18 Jul 2011 15:13:21 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 196C48A02E; Mon, 18 Jul 2011 15:13:21 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org, markmc@dataabstractsolutions.com Date: Mon, 18 Jul 2011 14:02:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> In-Reply-To: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107181402.12755.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 18 Jul 2011 15:13:21 -0400 (EDT) Cc: Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 19:13:22 -0000 On Friday, July 15, 2011 6:07:31 pm Mark McConnell wrote: > Dear folks, > > I have two LSI raid cards, one of which (SCSI 320-I) supports > 64-bit DMA when 4GB+ of DDR is present and another which > does not (SATA 150-D) . Consquently I've disabled 64-bit > addressing for amr devices. > > I would like to disable 64-bit addressing for the SATA card, but > permit it for the SCSI card. Is this possible? You'd have to hack the driver perhaps to only disable 64-bit DMA for certain PCI IDs. It probably already does this? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 21:06:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 597D71065670; Mon, 18 Jul 2011 21:06:47 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 18C2C8FC14; Mon, 18 Jul 2011 21:06:46 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id p6IL6f9l078291; Mon, 18 Jul 2011 15:06:41 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <201107181402.12755.jhb@freebsd.org> Date: Mon, 18 Jul 2011 15:06:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <797CACDE-729E-4F3A-AEFF-531C00C2B83A@samsco.org> References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181402.12755.jhb@freebsd.org> To: John Baldwin , markmc@dataabstractsolutions.com X-Mailer: Apple Mail (2.1084) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 21:06:47 -0000 On Jul 18, 2011, at 12:02 PM, John Baldwin wrote: > On Friday, July 15, 2011 6:07:31 pm Mark McConnell wrote: >> Dear folks, >>=20 >> I have two LSI raid cards, one of which (SCSI 320-I) supports=20 >> 64-bit DMA when 4GB+ of DDR is present and another which=20 >> does not (SATA 150-D) . Consquently I've disabled 64-bit=20 >> addressing for amr devices. >>=20 >> I would like to disable 64-bit addressing for the SATA card, but=20 >> permit it for the SCSI card. Is this possible? >=20 > You'd have to hack the driver perhaps to only disable 64-bit DMA for = certain=20 > PCI IDs. It probably already does this? >=20 The driver already had a table for determining 64bit DMA based on the = PCI ID. I guess there's a mistake in the table for this particular = card. I think that changing the following line to remove the = AMR_ID_DO_SG64 flag will fix the problem: {0x1000, 0x1960, AMR_ID_QUARTZ | AMR_ID_DO_SG64 | AMR_ID_PROBE_SIG}, Actually, what's probably going on is that the driver is only looking at = the vendor and device id's, and is ignoring the subvendor and subdevice = id's that would give it a better clue on the exact hardware in use. = Fixing the driver to look at all 64bits of id info (and take into = account wildcards where needed) would be a good project, if anyone is = interested. Btw, I *HATE* the "chip" and "card" identifiers used in pciconf. Can we = change it to emit the standard (sub)vendor/(sub)device terminology? Scott From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 21:14:49 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1D811065673 for ; Mon, 18 Jul 2011 21:14:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 773B98FC15 for ; Mon, 18 Jul 2011 21:14:49 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2C18446B2A; Mon, 18 Jul 2011 17:14:49 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BC4548A02E; Mon, 18 Jul 2011 17:14:48 -0400 (EDT) From: John Baldwin To: Scott Long Date: Mon, 18 Jul 2011 17:14:07 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181402.12755.jhb@freebsd.org> <797CACDE-729E-4F3A-AEFF-531C00C2B83A@samsco.org> In-Reply-To: <797CACDE-729E-4F3A-AEFF-531C00C2B83A@samsco.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107181714.07827.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 18 Jul 2011 17:14:48 -0400 (EDT) Cc: markmc@dataabstractsolutions.com, "freebsd-stable@freebsd.org Stable" Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 21:14:49 -0000 On Monday, July 18, 2011 5:06:40 pm Scott Long wrote: > On Jul 18, 2011, at 12:02 PM, John Baldwin wrote: > > On Friday, July 15, 2011 6:07:31 pm Mark McConnell wrote: > >> Dear folks, > >> > >> I have two LSI raid cards, one of which (SCSI 320-I) supports > >> 64-bit DMA when 4GB+ of DDR is present and another which > >> does not (SATA 150-D) . Consquently I've disabled 64-bit > >> addressing for amr devices. > >> > >> I would like to disable 64-bit addressing for the SATA card, but > >> permit it for the SCSI card. Is this possible? > > > > You'd have to hack the driver perhaps to only disable 64-bit DMA for certain > > PCI IDs. It probably already does this? > > > > The driver already had a table for determining 64bit DMA based on the PCI ID. > I guess there's a mistake in the table for this particular card. I think that > changing the following line to remove the AMR_ID_DO_SG64 flag will fix the > problem: > > {0x1000, 0x1960, AMR_ID_QUARTZ | AMR_ID_DO_SG64 | AMR_ID_PROBE_SIG}, > > Actually, what's probably going on is that the driver is only looking at the > vendor and device id's, and is ignoring the subvendor and subdevice id's that > would give it a better clue on the exact hardware in use. Fixing the driver > to look at all 64bits of id info (and take into account wildcards where > needed) would be a good project, if anyone is interested. > > Btw, I *HATE* the "chip" and "card" identifiers used in pciconf. Can we > change it to emit the standard (sub)vendor/(sub)device terminology? Oh, yeah. I hate that too. Would you want them as 4 separate entities or to just rename the labels to 'devid' and 'subdevid'? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 21:22:36 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44AA5106564A; Mon, 18 Jul 2011 21:22:36 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id D37528FC14; Mon, 18 Jul 2011 21:22:35 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id p6ILMR14078714; Mon, 18 Jul 2011 15:22:27 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <201107181714.07827.jhb@freebsd.org> Date: Mon, 18 Jul 2011 15:22:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181402.12755.jhb@freebsd.org> <797CACDE-729E-4F3A-AEFF-531C00C2B83A@samsco.org> <201107181714.07827.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: markmc@dataabstractsolutions.com, "freebsd-stable@freebsd.org Stable" Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 21:22:36 -0000 On Jul 18, 2011, at 3:14 PM, John Baldwin wrote: > On Monday, July 18, 2011 5:06:40 pm Scott Long wrote: >> On Jul 18, 2011, at 12:02 PM, John Baldwin wrote: >>> On Friday, July 15, 2011 6:07:31 pm Mark McConnell wrote: >>>> Dear folks, >>>>=20 >>>> I have two LSI raid cards, one of which (SCSI 320-I) supports=20 >>>> 64-bit DMA when 4GB+ of DDR is present and another which=20 >>>> does not (SATA 150-D) . Consquently I've disabled 64-bit=20 >>>> addressing for amr devices. >>>>=20 >>>> I would like to disable 64-bit addressing for the SATA card, but=20 >>>> permit it for the SCSI card. Is this possible? >>>=20 >>> You'd have to hack the driver perhaps to only disable 64-bit DMA for = certain=20 >>> PCI IDs. It probably already does this? >>>=20 >>=20 >> The driver already had a table for determining 64bit DMA based on the = PCI ID. >> I guess there's a mistake in the table for this particular card. I = think that >> changing the following line to remove the AMR_ID_DO_SG64 flag will = fix the >> problem: >>=20 >> {0x1000, 0x1960, AMR_ID_QUARTZ | AMR_ID_DO_SG64 | = AMR_ID_PROBE_SIG}, >>=20 >> Actually, what's probably going on is that the driver is only looking = at the >> vendor and device id's, and is ignoring the subvendor and subdevice = id's that >> would give it a better clue on the exact hardware in use. Fixing the = driver >> to look at all 64bits of id info (and take into account wildcards = where >> needed) would be a good project, if anyone is interested. >>=20 >> Btw, I *HATE* the "chip" and "card" identifiers used in pciconf. Can = we >> change it to emit the standard (sub)vendor/(sub)device terminology? >=20 > Oh, yeah. I hate that too. Would you want them as 4 separate = entities or to > just rename the labels to 'devid' and 'subdevid'? >=20 If we're going to change it, might as well break it down into 4 fields. = Maybe we retain the old format under a legacy switch and/or env variable = for users that have tools that parse the output (cough yahoo cough). Scott From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 21:49:41 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E9EE106564A for ; Mon, 18 Jul 2011 21:49:41 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E8B5F8FC12 for ; Mon, 18 Jul 2011 21:49:39 +0000 (UTC) Received: by iwr19 with SMTP id 19so4257132iwr.13 for ; Mon, 18 Jul 2011 14:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=pew9BxGSurcWwLg9JAcfAb1IAPSmlKA1kJbYjETo8EU=; b=XbMfhQ96sxgXIygMDbPfmjZk+TyEvyveAmB8vBK98fAgwSEfoNI7O6tNl0koAjXm1I vZxSdBDyB0+3xPoEePRfRy2Zhg6ieujUAVBoFuZm69HGXXRgb56tEYB9vwOJFb/uDu8Y aZZB+QU1rhpRgP7AI9rWj5K55AN6w+9PZHbLQ= Received: by 10.42.145.73 with SMTP id e9mr5036040icv.486.1311024384398; Mon, 18 Jul 2011 14:26:24 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id er13sm959425ibb.2.2011.07.18.14.26.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jul 2011 14:26:23 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 18 Jul 2011 14:25:20 -0700 From: YongHyeon PYUN Date: Mon, 18 Jul 2011 14:25:20 -0700 To: Scott Long Message-ID: <20110718212520.GB5063@michelle.cdnetworks.com> References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181402.12755.jhb@freebsd.org> <797CACDE-729E-4F3A-AEFF-531C00C2B83A@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <797CACDE-729E-4F3A-AEFF-531C00C2B83A@samsco.org> User-Agent: Mutt/1.4.2.3i Cc: markmc@dataabstractsolutions.com, "freebsd-stable@freebsd.org Stable" , John Baldwin Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 21:49:41 -0000 On Mon, Jul 18, 2011 at 03:06:40PM -0600, Scott Long wrote: > On Jul 18, 2011, at 12:02 PM, John Baldwin wrote: > > On Friday, July 15, 2011 6:07:31 pm Mark McConnell wrote: > >> Dear folks, > >> > >> I have two LSI raid cards, one of which (SCSI 320-I) supports > >> 64-bit DMA when 4GB+ of DDR is present and another which > >> does not (SATA 150-D) . Consquently I've disabled 64-bit > >> addressing for amr devices. > >> > >> I would like to disable 64-bit addressing for the SATA card, but > >> permit it for the SCSI card. Is this possible? > > > > You'd have to hack the driver perhaps to only disable 64-bit DMA for certain > > PCI IDs. It probably already does this? > > > > The driver already had a table for determining 64bit DMA based on the PCI ID. I guess there's a mistake in the table for this particular card. I think that changing the following line to remove the AMR_ID_DO_SG64 flag will fix the problem: > > {0x1000, 0x1960, AMR_ID_QUARTZ | AMR_ID_DO_SG64 | AMR_ID_PROBE_SIG}, > > Actually, what's probably going on is that the driver is only looking at the vendor and device id's, and is ignoring the subvendor and subdevice id's that would give it a better clue on the exact hardware in use. Fixing the driver to look at all 64bits of id info (and take into account wildcards where needed) would be a good project, if anyone is interested. > > Btw, I *HATE* the "chip" and "card" identifiers used in pciconf. Can we change it to emit the standard (sub)vendor/(sub)device terminology? > +1 > Scott From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 22:04:39 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 982B4106564A; Mon, 18 Jul 2011 22:04:39 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 44F928FC14; Mon, 18 Jul 2011 22:04:38 +0000 (UTC) Received: by gwb15 with SMTP id 15so1857745gwb.13 for ; Mon, 18 Jul 2011 15:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=n6W9sNJ107v+uPA5r2nJxrb1wG7eVgyA4oWAgNoSxEY=; b=SEEPrCHgc3Jw6CMPHPAzRpmbcKmTVmjbxJtTX+Dyi/3LRixD54mm9ku+izM3AkdTyY D9EtHPliLuve6PQ1z0/RmAvxvwbIUxnYNSvL8xthzJsxu7ig1MKL4pTcGhb+hCLKqCpC qDFhwd4tlqh1Y7AmvSLOR8woQdKbuHpanHvl0= MIME-Version: 1.0 Received: by 10.151.109.8 with SMTP id l8mr6524146ybm.27.1311026678429; Mon, 18 Jul 2011 15:04:38 -0700 (PDT) Received: by 10.151.27.21 with HTTP; Mon, 18 Jul 2011 15:04:38 -0700 (PDT) In-Reply-To: <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181402.12755.jhb@freebsd.org> <797CACDE-729E-4F3A-AEFF-531C00C2B83A@samsco.org> <201107181714.07827.jhb@freebsd.org> <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> Date: Mon, 18 Jul 2011 15:04:38 -0700 Message-ID: From: Kevin Oberman To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: markmc@dataabstractsolutions.com, "freebsd-stable@freebsd.org Stable" , John Baldwin Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 22:04:39 -0000 On Mon, Jul 18, 2011 at 2:22 PM, Scott Long wrote: > > On Jul 18, 2011, at 3:14 PM, John Baldwin wrote: > >> On Monday, July 18, 2011 5:06:40 pm Scott Long wrote: >>> On Jul 18, 2011, at 12:02 PM, John Baldwin wrote: >>>> On Friday, July 15, 2011 6:07:31 pm Mark McConnell wrote: >>>>> Dear folks, >>>>> >>>>> I have two LSI raid cards, one of which (SCSI 320-I) supports >>>>> 64-bit DMA when 4GB+ of DDR is present and another which >>>>> does not (SATA 150-D) . =A0Consquently I've disabled 64-bit >>>>> addressing for amr devices. >>>>> >>>>> I would like to disable 64-bit addressing for the SATA card, but >>>>> permit it for the SCSI card. =A0Is this possible? >>>> >>>> You'd have to hack the driver perhaps to only disable 64-bit DMA for c= ertain >>>> PCI IDs. =A0It probably already does this? >>>> >>> >>> The driver already had a table for determining 64bit DMA based on the P= CI ID. >>> I guess there's a mistake in the table for this particular card. =A0I t= hink that >>> changing the following line to remove the AMR_ID_DO_SG64 flag will fix = the >>> problem: >>> >>> =A0 =A0{0x1000, 0x1960, AMR_ID_QUARTZ | AMR_ID_DO_SG64 | AMR_ID_PROBE_S= IG}, >>> >>> Actually, what's probably going on is that the driver is only looking a= t the >>> vendor and device id's, and is ignoring the subvendor and subdevice id'= s that >>> would give it a better clue on the exact hardware in use. =A0Fixing the= driver >>> to look at all 64bits of id info (and take into account wildcards where >>> needed) would be a good project, if anyone is interested. >>> >>> Btw, I *HATE* the "chip" and "card" identifiers used in pciconf. =A0Can= we >>> change it to emit the standard (sub)vendor/(sub)device terminology? >> >> Oh, yeah. =A0I hate that too. =A0Would you want them as 4 separate entit= ies or to >> just rename the labels to 'devid' and 'subdevid'? >> > > If we're going to change it, might as well break it down into 4 fields. = =A0Maybe we retain the > old format under a legacy switch and/or env variable for users that have = tools that parse > the output (cough yahoo cough). Pretty please! This would be wonderful. --=20 R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 22:18:35 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AAA51065673 for ; Mon, 18 Jul 2011 22:18:35 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5CFF98FC13 for ; Mon, 18 Jul 2011 22:18:34 +0000 (UTC) Received: by ywf7 with SMTP id 7so1874243ywf.13 for ; Mon, 18 Jul 2011 15:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0aLtXwAvx9xYC5dPxj9CYfHfZwaGx1TY6daZ1WKC5fk=; b=TAsIQoaUc2nrXUY0NEJ/XgwKcdW2npyHjgmh7UHfaLNVYQBT+aiZusD/b5C9JyDWxf eX3uk0U1UQ8mJnniAV4DuS+/DgYu+wMNRgUGnKbA6LqDhl4HXxtUVW/cwYF6TGAsVJFo FBQlCx3UQ5DPYRxBWTCyo5iIoKosYEdLa6go8= MIME-Version: 1.0 Received: by 10.151.51.7 with SMTP id d7mr4993745ybk.426.1311027514399; Mon, 18 Jul 2011 15:18:34 -0700 (PDT) Received: by 10.151.27.21 with HTTP; Mon, 18 Jul 2011 15:18:34 -0700 (PDT) In-Reply-To: References: <20110712151858.GA1091@faust> <4E1F554A.90405@gmail.com> Date: Mon, 18 Jul 2011 15:18:34 -0700 Message-ID: From: Kevin Oberman To: Tom Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, Jim Bryant , Zoran Kolic Subject: Re: recommendations for laptop and desktop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 22:18:35 -0000 On Mon, Jul 18, 2011 at 7:02 AM, Tom Evans wrote: > On Thu, Jul 14, 2011 at 9:44 PM, Jim Bryant wrote: >> stay away from newer hp laptops. >> > > HP also like to lock-down which wifi cards you can use from BIOS - the > machines won't complete POST with a 'bad' wifi card, so that's another > strike as far as I am concerned. > > I've never had problems from modern dell laptops with nvidia graphics. > I'm typing this on a Dell Latitude E6410 - Core i5, iwn wifi, em lan, > nvidia graphics, webcam supported by webcamd... I have a new Lenovo T520 which locks down the WiFi. How rude!! I even tried installing am Intel 6502, a card Lenovo sells with that system, but I still get the 104-unknown wireless card" message. I'm to the point where I am thinking of patching the whitelist in BIOS, but Lenovo's BIOS update is shipped as a CD image (.iso) and contains a single bootable file, [BOOT]. I know trat, if I screw it up, I have a dead MOBO, so it makes me more than a little nervous. I would assume that Lenovo ships its own version of the 6205 with a different PCI ID, but I have failed to find it on their web site. This leaves me tied to the wired GE port. :-( As far as nVidia graphics goes, beware the new nVidia daughter cards shipping with second gen Core i processors (a.k.a. Sandy Bridge). These processors include an integrated Intel GPU (Intel 3000) and nVidia is shipping "Optimus" versions of their GPUs which use the Intel GPU as the frame buffer and for some other (unspecified) functions. There is no xorg support and nVidia has stated very clearly that they have no plans to ever support Optimus cards for any OS but Windows. Since the Optimus versions share the model number of standalone graphics cards with the addition of "Optimus", it's easy to get one of these useless things by accident. I would have if I hadn't been warned at the last minute. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 22:50:16 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 770B4106564A for ; Mon, 18 Jul 2011 22:50:16 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3EA6E8FC1C for ; Mon, 18 Jul 2011 22:50:15 +0000 (UTC) Received: by yic13 with SMTP id 13so1887991yic.13 for ; Mon, 18 Jul 2011 15:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=pGKHhvkug91dMisGQRwXX4W5EXWWgmjeMF7jaWiX7sU=; b=oAgjyK7m0/500I+SUm4rlILFcBvPJbsg4Ahit9wgelLRaRivkOPm1770o/8IJkeIM1 zDwWA/lCH4IbbZmqlh4/y3b2NxDt9ZeNwYPxDrJ4OyA7/iO/rm8fK7EnYsDl06O6Nosh bEEYWWiQNNg3ENuRZpS03AL9bF+Jged8kidlM= MIME-Version: 1.0 Received: by 10.150.210.2 with SMTP id i2mr1455989ybg.312.1311029415417; Mon, 18 Jul 2011 15:50:15 -0700 (PDT) Received: by 10.151.27.21 with HTTP; Mon, 18 Jul 2011 15:50:15 -0700 (PDT) Date: Mon, 18 Jul 2011 15:50:15 -0700 Message-ID: From: Kevin Oberman To: "freebsd-stable@freebsd.org Stable" Content-Type: text/plain; charset=ISO-8859-1 Subject: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 22:50:16 -0000 I just want to check on the status of 4K sector support in FreeBSD. I read a long thread on the topic from a while back and it looks like I might hit some issues if I'm not REALLY careful. Since I will be keeping the existing Windows installation, I need to be sure that I can set up the disk correctly without screwing up Windows 7. I was planning on just DDing the W7 slice over, but I am not sure how well this would play with GPT. Or should I not try to use GPT at all? I'd like to as this laptop spreads Windows 7 over two slices and adds a third for the recovery system, leaving only one for FreeBSD and I'd like to put my files in a separate slice. GPT would offer that fifth slice. I have read the handbook and don't see any reference to 4K sectors and only a one-liner about gpart(8) and GPT. Oncew I get this all figured out, I'll see about writing an update about this as GPT looks like the way to go in e future. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 23:41:26 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4293D106568C for ; Mon, 18 Jul 2011 23:41:26 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 2983F8FC1E for ; Mon, 18 Jul 2011 23:41:25 +0000 (UTC) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta02.emeryville.ca.mail.comcast.net with comcast id 9bhD1h0040S2fkCA2bhNJQ; Mon, 18 Jul 2011 23:41:22 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta09.emeryville.ca.mail.comcast.net with comcast id 9bhM1h00N1t3BNj8VbhMdf; Mon, 18 Jul 2011 23:41:22 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3347E102C36; Mon, 18 Jul 2011 16:41:24 -0700 (PDT) Date: Mon, 18 Jul 2011 16:41:24 -0700 From: Jeremy Chadwick To: Kevin Oberman Message-ID: <20110718234124.GA5626@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 23:41:26 -0000 On Mon, Jul 18, 2011 at 03:50:15PM -0700, Kevin Oberman wrote: > I just want to check on the status of 4K sector support in FreeBSD. I read > a long thread on the topic from a while back and it looks like I might hit some > issues if I'm not REALLY careful. Since I will be keeping the existing Windows > installation, I need to be sure that I can set up the disk correctly without > screwing up Windows 7. > > I was planning on just DDing the W7 slice over, but I am not sure how well this > would play with GPT. Or should I not try to use GPT at all? I'd like > to as this laptop > spreads Windows 7 over two slices and adds a third for the recovery > system, leaving > only one for FreeBSD and I'd like to put my files in a separate slice. > GPT would offer > that fifth slice. > > I have read the handbook and don't see any reference to 4K sectors and only a > one-liner about gpart(8) and GPT. Oncew I get this all figured out, > I'll see about writing > an update about this as GPT looks like the way to go in e future. When you say "4KB sector support", what do you mean by this? All drives on the market as of this writing, that I've seen, all claim a physical/logical sector size of 512 bytes -- yes, even SSDs, and EARS drives which we know use 4KB sectors. They do this to guarantee full compatibility with existing software. Since you're talking about gpart and "4KB sector support", did you mean to ask "what's the state of FreeBSD and aligned partition support to ensure decent performance with 4KB-sector drives?" If so: there have been some commits in recent days to RELENG_8 to help try to address the shortcomings of the existing utilities and GEOM infrastructure. Read the most recent commit text carefully: http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/geom/class/part/geom_part.c But the currently "known method" is to use gnop(8). Here's an example: http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optimized-for-4k-sector-drives/ Now, that's for ZFS, but I'm under the impression the exact same is needed for FFS/UFS. Do I bother doing this with my SSDs? No. Am I suffering in performance? Probably. Why do I not care? Because the level of annoyance is extremely high -- remember, all of this has to be done from within the installer environment (referring to "Emergency Shell"), which on FreeBSD lacks an incredible amount of usability, and is even worse to deal with when doing a remote install via PXE/serial. Fixit is the only decent environment. Given that floppies are more or less gone, I don't understand why the Fixit environment doesn't replace the "Emergency Shell". -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 00:29:47 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E4BA106564A; Tue, 19 Jul 2011 00:29:47 +0000 (UTC) (envelope-from markmc@dataabstractsolutions.com) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by mx1.freebsd.org (Postfix) with ESMTP id 03DC28FC13; Tue, 19 Jul 2011 00:29:46 +0000 (UTC) Received: from [192.168.1.35] (75-150-37-150-Oregon.hfc.comcastbusiness.net [75.150.37.150]) by smtp1.pacifier.net (Postfix) with ESMTP id 9C4896EF34; Mon, 18 Jul 2011 17:00:02 -0700 (PDT) From: "Mark McConnell" To: freebsd-stable@freebsd.org Date: Mon, 18 Jul 2011 17:00:02 -0700 MIME-Version: 1.0 Message-ID: <4E24C902.4460.164669ED@markmc.dataabstractsolutions.com> Priority: normal In-reply-to: <797CACDE-729E-4F3A-AEFF-531C00C2B83A@samsco.org> References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com>, <201107181402.12755.jhb@freebsd.org>, <797CACDE-729E-4F3A-AEFF-531C00C2B83A@samsco.org> X-mailer: Pegasus Mail for Windows (4.52) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Cc: John Baldwin Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: markmc@dataabstractsolutions.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 00:29:47 -0000 On 18 Jul 2011 at 15:06, Scott Long wrote: {Re: disable 64-bit dma for one PCI ...}: > >> I would like to disable 64-bit addressing for the SATA card, but > >> permit it for the SCSI card. Is this possible? > > > > You'd have to hack the driver perhaps to only disable 64-bit DMA for certain > > PCI IDs. It probably already does this? > > > > The driver already had a table for determining 64bit DMA > based on the PCI ID. I guess there's a mistake in the > table for this particular card. I think that changing > the following line to remove the AMR_ID_DO_SG64 flag > will fix the problem: > > {0x1000, 0x1960, AMR_ID_QUARTZ | AMR_ID_DO_SG64 | AMR_ID_PROBE_SIG}, > > Actually, what's probably going on is that the driver is > only looking at the vendor and device id's, and is > ignoring the subvendor and subdevice id's that would > give it a better clue on the exact hardware in use. > Fixing the driver to look at all 64bits of id info (and > take into account wildcards where needed) would be a > good project, if anyone is interested. > > Btw, I *HATE* the "chip" and "card" identifiers used in > pciconf. Can we change it to emit the standard > (sub)vendor/(sub)device terminology? > > Scott Thank you for the discussion, John and Scott. I see where this change would be made, Scott, and I want to try it when I have an opportunity. Mark -- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 03:59:45 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E68F106566C for ; Tue, 19 Jul 2011 03:59:45 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 596E48FC08 for ; Tue, 19 Jul 2011 03:59:45 +0000 (UTC) Received: by gwb15 with SMTP id 15so1965158gwb.13 for ; Mon, 18 Jul 2011 20:59:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=3pONQ5NqVMhzlGOq/HwPxOMGX8f4tXjNt+Lb3D9ngu8=; b=CQQrCHSzeukowSTWYh53kmFLg1Fu/oLGYkgaK5bfayGBSn5jRdCLADjyaGgARlVxKa Q5XkYWv/THhkOPpTEYZcKkofG9YROj0+KOIvn8TVZ9MTsnDv6wHbuHU+71H1W9lPLxS1 8RzFCf46X0Nw6WkIIrW8ygpn/y5sUD5t1VhsU= Received: by 10.236.185.229 with SMTP id u65mr4592298yhm.511.1311046683175; Mon, 18 Jul 2011 20:38:03 -0700 (PDT) Received: from schism.local (c-76-124-49-145.hsd1.pa.comcast.net [76.124.49.145]) by mx.google.com with ESMTPS id f4sm3800597yhn.41.2011.07.18.20.38.01 (version=SSLv3 cipher=OTHER); Mon, 18 Jul 2011 20:38:01 -0700 (PDT) Message-ID: <4E24FC18.3010605@gmail.com> Date: Mon, 18 Jul 2011 23:38:00 -0400 From: Glen Barber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Jeremy Chadwick References: <20110718234124.GA5626@icarus.home.lan> In-Reply-To: <20110718234124.GA5626@icarus.home.lan> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 03:59:45 -0000 On 7/18/11 7:41 PM, Jeremy Chadwick wrote: > On Mon, Jul 18, 2011 at 03:50:15PM -0700, Kevin Oberman wrote: >> I just want to check on the status of 4K sector support in FreeBSD. I read >> a long thread on the topic from a while back and it looks like I might hit some >> issues if I'm not REALLY careful. Since I will be keeping the existing Windows >> installation, I need to be sure that I can set up the disk correctly without >> screwing up Windows 7. >> >> I was planning on just DDing the W7 slice over, but I am not sure how well this >> would play with GPT. Or should I not try to use GPT at all? I'd like >> to as this laptop >> spreads Windows 7 over two slices and adds a third for the recovery >> system, leaving >> only one for FreeBSD and I'd like to put my files in a separate slice. >> GPT would offer >> that fifth slice. >> >> I have read the handbook and don't see any reference to 4K sectors and only a >> one-liner about gpart(8) and GPT. Oncew I get this all figured out, >> I'll see about writing >> an update about this as GPT looks like the way to go in e future. > > When you say "4KB sector support", what do you mean by this? All > drives on the market as of this writing, that I've seen, all claim a > physical/logical sector size of 512 bytes -- yes, even SSDs, and EARS > drives which we know use 4KB sectors. They do this to guarantee full > compatibility with existing software. > > Since you're talking about gpart and "4KB sector support", did you mean > to ask "what's the state of FreeBSD and aligned partition support to > ensure decent performance with 4KB-sector drives?" > > If so: there have been some commits in recent days to RELENG_8 to help > try to address the shortcomings of the existing utilities and GEOM > infrastructure. Read the most recent commit text carefully: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/geom/class/part/geom_part.c > > But the currently "known method" is to use gnop(8). Here's an example: > > http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optimized-for-4k-sector-drives/ > Notice: I'm reading this as "how badly do 'green drives' suck?" FWIW, I've recently done the gnop(8) trick to two "green" drives in one of my machines because I was seeing horrifying performance problems with what I consider to be basic stuff, like 'portsnap extract', but more severely with copying large data (file-backed bacula files to be exact) into said datasets. I have yet to retry my read/write tests with drives I have not converted with gnop(8). I have not conclusively tested all possible combinations of configurations, nor reverted the changes to the drives to retest, but if it is of any interest, here's what I'm seeing. I have comparisons between WD "green" and "black" drives. Unfortunately, the machines are not completely similar - one is a Core2Quad, the other Core2Duo; one has 6GB RAM, the other 8GB RAM; also, 'orion' is running a month-old 8-STABLE; 'kaos' is running a 2-week-old -CURRENT. Both machines are using ZFSv28: orion % sysctl -n hw.ncpu; sysctl -n hw.physmem 4 6353416192 kaos % sysctl -n hw.ncpu; sysctl -n hw.physmem 2 8534401024 The drives in 'orion' are 1TB WD green drives in a ZFS mirror; the drives in 'kaos' are 1TB WD black drives in a raidz1 (3 drives). First the read test: kaos % sh -c 'time find /usr/src -type f -name \*.\[1-9\] >/dev/null' 12.94 real 0.60 user 11.95 sys orion % sh -c 'time find /usr/src -type f -name \*.\[1-9\] >/dev/null' 118.02 real 0.46 user 8.74 sys I guess no real surprise here. 'kaos' has more spindles to read from, on top of faster seek times. Next the write test: The 'compressed' and 'dedup' datasets referenced below are 'lzjb' and 'sha256,verify', respectively. I'd wait for the 'compressed+dedup' tests to finish, but I have to wake up tomorrow morning. orion# sh -c 'time portsnap extract -p /zstore/perftest >/dev/null' 306.71 real 44.37 user 110.28 sys orion# sh -c 'time portsnap extract -p /zstore/perftest_compress >/dev/null' 166.62 real 43.87 user 109.49 sys orion# sh -c 'time portsnap extract -p /zstore/perftest_dedup >/dev/null' 3576.43 real 44.98 user 109.12 sys kaos# sh -c 'time portsnap extract -p /perftest >/dev/null' 311.31 real 51.23 user 193.37 sys kaos# sh -c 'time portsnap extract -p /perftest_compress >/dev/null' 269.85 real 49.55 user 191.56 sys kaos# sh -c 'time portsnap extract -p /perftest_dedup >/dev/null' 4655.73 real 51.86 user 196.22 sys Like I said, I have not yet had the time to retest this on drives without the gnop(8) fix (another similar zpool with 2 drives), so maybe the data I'm providing isn't relevant, but since the gnop(8) fix for 4K sector drives was mentioned, I thought it might be relevant to a point. > Now, that's for ZFS, but I'm under the impression the exact same is > needed for FFS/UFS. > > Do I bother doing this with my SSDs? No. Am I suffering in > performance? Probably. Why do I not care? Because the level of > annoyance is extremely high -- remember, all of this has to be done from > within the installer environment (referring to "Emergency Shell"), which > on FreeBSD lacks an incredible amount of usability, and is even worse to > deal with when doing a remote install via PXE/serial. Fixit is the only > decent environment. Given that floppies are more or less gone, I don't > understand why the Fixit environment doesn't replace the "Emergency > Shell". > Not that it necessarily helps in a PXE environment, but a memstick of 9-CURRENT has helped me recover minor "oops" situations a few times over the past few months. What are these "floppies" you speak of, again? :) Regards, -- Glen Barber From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 04:05:48 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CF821065670 for ; Tue, 19 Jul 2011 04:05:48 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 41C798FC17 for ; Tue, 19 Jul 2011 04:05:47 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta03.emeryville.ca.mail.comcast.net with comcast id 9g4t1h0021HpZEsA3g5l4u; Tue, 19 Jul 2011 04:05:45 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta14.emeryville.ca.mail.comcast.net with comcast id 9g5l1h00H1t3BNj8ag5ljd; Tue, 19 Jul 2011 04:05:46 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8C027102C36; Mon, 18 Jul 2011 21:05:44 -0700 (PDT) Date: Mon, 18 Jul 2011 21:05:44 -0700 From: Jeremy Chadwick To: Glen Barber Message-ID: <20110719040544.GA9607@icarus.home.lan> References: <20110718234124.GA5626@icarus.home.lan> <4E24FC18.3010605@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E24FC18.3010605@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 04:05:48 -0000 On Mon, Jul 18, 2011 at 11:38:00PM -0400, Glen Barber wrote: > On 7/18/11 7:41 PM, Jeremy Chadwick wrote: > > On Mon, Jul 18, 2011 at 03:50:15PM -0700, Kevin Oberman wrote: > >> I just want to check on the status of 4K sector support in FreeBSD. I read > >> a long thread on the topic from a while back and it looks like I might hit some > >> issues if I'm not REALLY careful. Since I will be keeping the existing Windows > >> installation, I need to be sure that I can set up the disk correctly without > >> screwing up Windows 7. > >> > >> I was planning on just DDing the W7 slice over, but I am not sure how well this > >> would play with GPT. Or should I not try to use GPT at all? I'd like > >> to as this laptop > >> spreads Windows 7 over two slices and adds a third for the recovery > >> system, leaving > >> only one for FreeBSD and I'd like to put my files in a separate slice. > >> GPT would offer > >> that fifth slice. > >> > >> I have read the handbook and don't see any reference to 4K sectors and only a > >> one-liner about gpart(8) and GPT. Oncew I get this all figured out, > >> I'll see about writing > >> an update about this as GPT looks like the way to go in e future. > > > > When you say "4KB sector support", what do you mean by this? All > > drives on the market as of this writing, that I've seen, all claim a > > physical/logical sector size of 512 bytes -- yes, even SSDs, and EARS > > drives which we know use 4KB sectors. They do this to guarantee full > > compatibility with existing software. > > > > Since you're talking about gpart and "4KB sector support", did you mean > > to ask "what's the state of FreeBSD and aligned partition support to > > ensure decent performance with 4KB-sector drives?" > > > > If so: there have been some commits in recent days to RELENG_8 to help > > try to address the shortcomings of the existing utilities and GEOM > > infrastructure. Read the most recent commit text carefully: > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/geom/class/part/geom_part.c > > > > But the currently "known method" is to use gnop(8). Here's an example: > > > > http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optimized-for-4k-sector-drives/ > > > > Notice: I'm reading this as "how badly do 'green drives' suck?" It's important to note that not all WD Caviar Green drives use 4KB sectors. WD, as of this writing, uses the 4-letter "EARS" string in the drive model that denotes use of 4KB sectors. The Green series do have other problems that people have experienced, such as bugs/quirks in the firmware causing the drive to repetitively park its heads in the landing zone (witnessed as either really bad drive performance, or the drive falling off the bus + reattaching). You can detect this situation by looking at SMART attribute 193 (Load_Cycle_Count). A very high number (in the tens or hundreds of thousands for a drive that has only been in use for a week or so) is an indicator of the problem. WD apparently has given people firmware updates to fix the issue. However the drive firmware version number does not change after updating the microcode, but it does fix the problem. (For what it's worth, Samsung pulled this same manoeuvre when it came to firmware updates for a catastrophic bug on their SpinPoint F4 drives.) What I'm saying is there's no way to detect whether or not your drive is running the fixed firmware, other than looking at said SMART attribute. I do have references for this issue, but it will take me some time to dig up the URLs and so on. > FWIW, I've recently done the gnop(8) trick to two "green" drives in one > of my machines because I was seeing horrifying performance problems with > what I consider to be basic stuff, like 'portsnap extract', but more > severely with copying large data (file-backed bacula files to be exact) > into said datasets. I have yet to retry my read/write tests with drives > I have not converted with gnop(8). I imagine this would have a tremendous effect on performance. With SSDs, the estimated performance impact is between 30-50% depending on what the workload is. Meaning with SSDs, drives with aligned partitions perform 30-50% better. When you read about how NAND cell and NAND flash pages work (look it up on Wikipedia, look for FTL (flash transition layer)) it makes sense. With mechanical HDDs, I'm not sure what the performance hit is, but I imagine it's large. Furthermore, talking about SSDs again: I want to make folks aware of the fact that Intel SSDs use an 8KB NAND flash page (not 4KB!). NAND pages are erased 256 pages at a time (8*256=2MByte). When it comes to alignment, flash page size is what's of concern. So for Intel SSDs (X25 series, 320 series, and 510 series), 8KByte-aligned is the way to go. > I have not conclusively tested all possible combinations of > configurations, nor reverted the changes to the drives to retest, but if > it is of any interest, here's what I'm seeing. > > I have comparisons between WD "green" and "black" drives. > Unfortunately, the machines are not completely similar - one is a > Core2Quad, the other Core2Duo; one has 6GB RAM, the other 8GB RAM; also, > 'orion' is running a month-old 8-STABLE; 'kaos' is running a 2-week-old > -CURRENT. Both machines are using ZFSv28: > > orion % sysctl -n hw.ncpu; sysctl -n hw.physmem > 4 > 6353416192 > > kaos % sysctl -n hw.ncpu; sysctl -n hw.physmem > 2 > 8534401024 > > The drives in 'orion' are 1TB WD green drives in a ZFS mirror; the > drives in 'kaos' are 1TB WD black drives in a raidz1 (3 drives). > > First the read test: > > kaos % sh -c 'time find /usr/src -type f -name \*.\[1-9\] >/dev/null' > 12.94 real 0.60 user 11.95 sys > > orion % sh -c 'time find /usr/src -type f -name \*.\[1-9\] >/dev/null' > 118.02 real 0.46 user 8.74 sys > > I guess no real surprise here. 'kaos' has more spindles to read from, > on top of faster seek times. > > Next the write test: > > The 'compressed' and 'dedup' datasets referenced below are 'lzjb' and > 'sha256,verify', respectively. I'd wait for the 'compressed+dedup' > tests to finish, but I have to wake up tomorrow morning. > > orion# sh -c 'time portsnap extract -p /zstore/perftest >/dev/null' > 306.71 real 44.37 user 110.28 sys > > orion# sh -c 'time portsnap extract -p /zstore/perftest_compress >/dev/null' > 166.62 real 43.87 user 109.49 sys > > orion# sh -c 'time portsnap extract -p /zstore/perftest_dedup >/dev/null' > 3576.43 real 44.98 user 109.12 sys > > kaos# sh -c 'time portsnap extract -p /perftest >/dev/null' > 311.31 real 51.23 user 193.37 sys > > kaos# sh -c 'time portsnap extract -p /perftest_compress >/dev/null' > 269.85 real 49.55 user 191.56 sys > > kaos# sh -c 'time portsnap extract -p /perftest_dedup >/dev/null' > 4655.73 real 51.86 user 196.22 sys > > Like I said, I have not yet had the time to retest this on drives > without the gnop(8) fix (another similar zpool with 2 drives), so maybe > the data I'm providing isn't relevant, but since the gnop(8) fix for 4K > sector drives was mentioned, I thought it might be relevant to a point. The problem with what you're testing here is that it's not really "testing the drive" -- it's testing multiple drives with ZFS in the middle. Using dd would address that. For testing "non-aligned" offsets (for the EARS drive), use the seek= parameter. I would also recommend in picking an awkwardly-sized bs= value, such as 61340. > > Now, that's for ZFS, but I'm under the impression the exact same is > > needed for FFS/UFS. > > > > Do I bother doing this with my SSDs? No. Am I suffering in > > performance? Probably. Why do I not care? Because the level of > > annoyance is extremely high -- remember, all of this has to be done from > > within the installer environment (referring to "Emergency Shell"), which > > on FreeBSD lacks an incredible amount of usability, and is even worse to > > deal with when doing a remote install via PXE/serial. Fixit is the only > > decent environment. Given that floppies are more or less gone, I don't > > understand why the Fixit environment doesn't replace the "Emergency > > Shell". > > > > Not that it necessarily helps in a PXE environment, but a memstick of > 9-CURRENT has helped me recover minor "oops" situations a few times over > the past few months. What are these "floppies" you speak of, again? :) Sure, USB flash drives work great. But it's a little hard to install a USB flash drive when you're 3000 miles away. :-) mm's mfsBSD is also useful for recovery situations: http://mfsbsd.vx.sk/ My point, though, was this: Fixit was separate from Emergency Shell because of space concerns on floppy disks (Fixit wouldn't fit). Since floppies really aren't used much any more, this concern should be revised. IMHO Fixit should be removed and Emergency Shell should provide the same environment/utilities/etc. as Fixit. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 06:03:34 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 136CD1065675; Tue, 19 Jul 2011 06:03:34 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from proxy.kirov.so-ups.ru (proxy.kirov.so-cdu.ru [77.72.136.146]) by mx1.freebsd.org (Postfix) with ESMTP id 76CBD8FC14; Tue, 19 Jul 2011 06:03:33 +0000 (UTC) Received: from kirov.so-cdu.ru (ns.kirov.oduur.so [172.21.81.1]) by proxy.kirov.so-ups.ru (Postfix) with ESMTP id 3AD44B802A; Tue, 19 Jul 2011 09:56:42 +0400 (MSD) Received: by ns.kirov.so-cdu.ru (Postfix, from userid 1010) id 3597BB841A; Tue, 19 Jul 2011 09:56:42 +0400 (MSD) Received: from [10.118.3.52] (elsukov.kirov.oduur.so [10.118.3.52]) by ns.kirov.so-cdu.ru (Postfix) with ESMTP id 00D3BB83F9; Tue, 19 Jul 2011 09:56:41 +0400 (MSD) Message-ID: <4E251C96.5050105@FreeBSD.org> Date: Tue, 19 Jul 2011 09:56:38 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Scott Long References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181402.12755.jhb@freebsd.org> <797CACDE-729E-4F3A-AEFF-531C00C2B83A@samsco.org> <201107181714.07827.jhb@freebsd.org> <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> In-Reply-To: <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAACBA9FE227B9492AA59DB54" Cc: markmc@dataabstractsolutions.com, freebsd-stable@freebsd.org, John Baldwin Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 06:03:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAACBA9FE227B9492AA59DB54 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 19.07.2011 1:22, Scott Long wrote: >>> Btw, I *HATE* the "chip" and "card" identifiers used in pciconf. Can= we change it to emit >>> the standard (sub)vendor/(sub)device terminology? >>=20 >> Oh, yeah. I hate that too. Would you want them as 4 separate entitie= s or to just rename the >> labels to 'devid' and 'subdevid'? >>=20 >=20 > If we're going to change it, might as well break it down into 4 fields.= Maybe we retain the old > format under a legacy switch and/or env variable for users that have to= ols that parse the output > (cough yahoo cough). Hi, Scott i think for keeping POLA it is better add new option to make new output f= ormat. --=20 WBR, Andrey V. Elsukov --------------enigAACBA9FE227B9492AA59DB54 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJOJRyZAAoJEAHF6gQQyKF6Hb8IAKKS0HGR44200xDVHs4Co9Tm 2hd7O9zNkA8WVF/FELD7u4QTx1/esc9fkamGHbH2QKfXw2fCNiyO6fOPBT8FS51X diNGnA83o6DcU3ZMuEao+bEv2kalD14s0y/cO0ItlROBQy7EMwQJw/JI3kiCyMbu ejYuEGQzDoJrxbkGAew/W7HaQR2BO5cpzu4viOtkdt9Hg8Txb1EhpvzB86Co75yk 5gCSwLX8H1YAcRyKagPZdGAS0yB1ykVO5XYSMA16mlEtFq0eIFM3GIXmxUUBu8ma 1JXJz/mpwj9aOXCjml3Qz5XzcUlolRXoOMmrm9sAPJaKmoP22v540/oPObSPaC4= =scSu -----END PGP SIGNATURE----- --------------enigAACBA9FE227B9492AA59DB54-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 06:04:16 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7CCF1065673 for ; Tue, 19 Jul 2011 06:04:15 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id A7A228FC1A for ; Tue, 19 Jul 2011 06:04:15 +0000 (UTC) Received: by ywf7 with SMTP id 7so2006796ywf.13 for ; Mon, 18 Jul 2011 23:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OMT2tdYspBOwCAocvcnudlum0ZR/r/9l9jYhRQSNvfg=; b=cuosByW2oLOtQu9M+k8wfzaLgJW3ms4BG+aj0jZhk7nHUIw3UCELuEU8Vg2qLiqFRy a2mfdrM6gqMcq6UIqtDlrkhm4ji4u3rDdcQAgZ1UJVwKSaqNin84q87Kd8ip595Trz9U U1WSiUlIFJNYYt2O7RBIzdyRhVP810IMvRMiE= MIME-Version: 1.0 Received: by 10.150.63.19 with SMTP id l19mr6080398yba.369.1311055454967; Mon, 18 Jul 2011 23:04:14 -0700 (PDT) Received: by 10.151.27.21 with HTTP; Mon, 18 Jul 2011 23:04:14 -0700 (PDT) In-Reply-To: <20110718234124.GA5626@icarus.home.lan> References: <20110718234124.GA5626@icarus.home.lan> Date: Mon, 18 Jul 2011 23:04:14 -0700 Message-ID: From: Kevin Oberman To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 06:04:16 -0000 On Mon, Jul 18, 2011 at 4:41 PM, Jeremy Chadwick wrote: > On Mon, Jul 18, 2011 at 03:50:15PM -0700, Kevin Oberman wrote: >> I just want to check on the status of 4K sector support in FreeBSD. =A0I= read >> a long thread on the topic from a while back and it looks like I might h= it some >> issues if I'm not REALLY careful. Since I will be keeping the existing W= indows >> installation, I need to be sure that I can set up the disk correctly wit= hout >> screwing up Windows 7. >> >> I was planning on just DDing the W7 slice over, but I am not sure how we= ll this >> would play with GPT. Or should I not try to use GPT at all? I'd like >> to as this laptop >> spreads Windows 7 over two slices and adds a third for the recovery >> system, leaving >> only one for FreeBSD and I'd like to put my files in a separate slice. >> GPT would offer >> that fifth slice. >> >> I have read the handbook and don't see any reference to 4K sectors and o= nly a >> one-liner about gpart(8) and GPT. Oncew I get this all figured out, >> I'll see about writing >> an update about this as GPT looks like the way to go in e future. > > When you say "4KB sector support", what do you mean by this? =A0All > drives on the market as of this writing, that I've seen, all claim a > physical/logical sector size of 512 bytes -- yes, even SSDs, and EARS > drives which we know use 4KB sectors. =A0They do this to guarantee full > compatibility with existing software. > > Since you're talking about gpart and "4KB sector support", did you mean > to ask "what's the state of FreeBSD and aligned partition support to > ensure decent performance with 4KB-sector drives?" > > If so: there have been some commits in recent days to RELENG_8 to help > try to address the shortcomings of the existing utilities and GEOM > infrastructure. =A0Read the most recent commit text carefully: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/geom/class/part/geom_part.= c > > But the currently "known method" is to use gnop(8). =A0Here's an example: > > http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optimi= zed-for-4k-sector-drives/ > > Now, that's for ZFS, but I'm under the impression the exact same is > needed for FFS/UFS. Jeremy, Yes, this is exactly what I mean. If I shell out for a high-end 7200 RPM drive for my laptop only to have it run like a dog. Thanks for the pointers. The first is good news. I'm a bit confused as to w= hat I will need gnop(8) for, but I'll be spending some time reading both the arti= cle and the gnop man page and hopefully that will make it clear. I've only used gpart once and to took way too long to figure out what I needed to do, but it did= work fine. I just wish FreeBSD had some decent documentation on such a fundament= al operation. Fortunately there are some pretty good articles folks have written, but they did leave me with several questions. --=20 R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 12:17:31 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24FF8106566C for ; Tue, 19 Jul 2011 12:17:31 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id D37418FC14 for ; Tue, 19 Jul 2011 12:17:30 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Qj9Ev-0002DI-1b for freebsd-stable@freebsd.org; Tue, 19 Jul 2011 14:17:29 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Jul 2011 14:17:29 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Jul 2011 14:17:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 19 Jul 2011 14:17:17 +0200 Lines: 22 Message-ID: References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181402.12755.jhb@freebsd.org> <797CACDE-729E-4F3A-AEFF-531C00C2B83A@samsco.org> <201107181714.07827.jhb@freebsd.org> <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> <4E251C96.5050105@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <4E251C96.5050105@FreeBSD.org> X-Enigmail-Version: 1.1.2 Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 12:17:31 -0000 On 19/07/2011 07:56, Andrey V. Elsukov wrote: > On 19.07.2011 1:22, Scott Long wrote: >>>> Btw, I *HATE* the "chip" and "card" identifiers used in pciconf. Can we change it to emit >>>> the standard (sub)vendor/(sub)device terminology? >>> >>> Oh, yeah. I hate that too. Would you want them as 4 separate entities or to just rename the >>> labels to 'devid' and 'subdevid'? >>> >> >> If we're going to change it, might as well break it down into 4 fields. Maybe we retain the old >> format under a legacy switch and/or env variable for users that have tools that parse the output >> (cough yahoo cough). > > Hi, Scott > > i think for keeping POLA it is better add new option to make new output format. This is a too strict interpretation of POLA! If the change is done for better compliance with standards and it is done in a major version (i.e. 9.0 or 10.0), it's not a matter of POLA (otherwise, the change will never happen). From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 13:31:38 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83CBD106564A for ; Tue, 19 Jul 2011 13:31:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 43A778FC16 for ; Tue, 19 Jul 2011 13:31:38 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id ADD4646B29; Tue, 19 Jul 2011 09:31:37 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2B8128A02C; Tue, 19 Jul 2011 09:31:37 -0400 (EDT) From: John Baldwin To: Scott Long Date: Tue, 19 Jul 2011 09:31:36 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181714.07827.jhb@freebsd.org> <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> In-Reply-To: <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107190931.36492.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 19 Jul 2011 09:31:37 -0400 (EDT) Cc: markmc@dataabstractsolutions.com, "freebsd-stable@freebsd.org Stable" Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 13:31:38 -0000 On Monday, July 18, 2011 5:22:26 pm Scott Long wrote: > > On Jul 18, 2011, at 3:14 PM, John Baldwin wrote: > > > On Monday, July 18, 2011 5:06:40 pm Scott Long wrote: > >> On Jul 18, 2011, at 12:02 PM, John Baldwin wrote: > >>> On Friday, July 15, 2011 6:07:31 pm Mark McConnell wrote: > >>>> Dear folks, > >>>> > >>>> I have two LSI raid cards, one of which (SCSI 320-I) supports > >>>> 64-bit DMA when 4GB+ of DDR is present and another which > >>>> does not (SATA 150-D) . Consquently I've disabled 64-bit > >>>> addressing for amr devices. > >>>> > >>>> I would like to disable 64-bit addressing for the SATA card, but > >>>> permit it for the SCSI card. Is this possible? > >>> > >>> You'd have to hack the driver perhaps to only disable 64-bit DMA for certain > >>> PCI IDs. It probably already does this? > >>> > >> > >> The driver already had a table for determining 64bit DMA based on the PCI ID. > >> I guess there's a mistake in the table for this particular card. I think that > >> changing the following line to remove the AMR_ID_DO_SG64 flag will fix the > >> problem: > >> > >> {0x1000, 0x1960, AMR_ID_QUARTZ | AMR_ID_DO_SG64 | AMR_ID_PROBE_SIG}, > >> > >> Actually, what's probably going on is that the driver is only looking at the > >> vendor and device id's, and is ignoring the subvendor and subdevice id's that > >> would give it a better clue on the exact hardware in use. Fixing the driver > >> to look at all 64bits of id info (and take into account wildcards where > >> needed) would be a good project, if anyone is interested. > >> > >> Btw, I *HATE* the "chip" and "card" identifiers used in pciconf. Can we > >> change it to emit the standard (sub)vendor/(sub)device terminology? > > > > Oh, yeah. I hate that too. Would you want them as 4 separate entities or to > > just rename the labels to 'devid' and 'subdevid'? > > > > If we're going to change it, might as well break it down into 4 fields. Maybe > we retain the old format under a legacy switch and/or env variable for users > that have tools that parse the output (cough yahoo cough). The only reason it might be nice to stick with two fields is due to the line length (though the first line is over 80 cols even in the current format). Here are two possible suggestions: old: hostb0@pci0:0:0:0: class=0x060000 card=0x20108086 chip=0x01008086 rev=0x09 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 card=0x20108086 chip=0x01018086 rev=0x09 hdr=0x01 pcib2@pci0:0:1:1: class=0x060400 card=0x20108086 chip=0x01058086 rev=0x09 hdr=0x01 none0@pci0:0:22:0: class=0x078000 card=0x47428086 chip=0x1c3a8086 rev=0x04 hdr=0x00 em0@pci0:0:25:0: class=0x020000 card=0x00008086 chip=0x15038086 rev=0x04 hdr=0x00 ... A) hostb0@pci0:0:0:0: class=0x060000 vendor=0x8086 device=0x0100 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 vendor=0x8086 device=0x0101 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x01 pcib2@pci0:0:1:1: class=0x060400 vendor=0x8086 device=0x0105 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x01 none0@pci0:0:22:0: class=0x078000 vendor=0x8086 device=0x1c3a subvendor=0x8086 subdevice=0x4742 rev=0x04 hdr=0x00 em0@pci0:0:25:0: class=0x020000 vendor=0x8086 device=0x1503 subvendor=0x8086 subdevice=0x0000 rev=0x04 hdr=0x00 ... B) hostb0@pci0:0:0:0: class=0x060000 devid=0x8086:0100 subid=0x8086:2010 rev=0x09 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 devid=0x8086:0101 subid=0x8086:2010 rev=0x09 hdr=0x01 pcib2@pci0:0:1:1: class=0x060400 devid=0x8086:0105 subid=0x8086:2010 rev=0x09 hdr=0x01 none0@pci0:0:22:0: class=0x078000 devid=0x8086:1c3a subid=0x8086:4742 rev=0x04 hdr=0x00 em0@pci0:0:25:0: class=0x020000 devid=0x8086:1503 subid=0x8086:0000 rev=0x04 hdr=0x00 ... I went with vendor word first for both A) and B) as in my experience that is the more common ordering in driver tables, etc. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 13:32:02 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3F8C1065672 for ; Tue, 19 Jul 2011 13:32:02 +0000 (UTC) (envelope-from callumgibson@optusnet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 5431C8FC0C for ; Tue, 19 Jul 2011 13:32:01 +0000 (UTC) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p6JBKbAX029665 for ; Tue, 19 Jul 2011 21:20:37 +1000 Received: from omma.gibson.athome (c122-106-15-156.rivrw1.nsw.optusnet.com.au [122.106.15.156]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with SMTP id p6JBKXpW007711 for ; Tue, 19 Jul 2011 21:20:34 +1000 Received: (qmail 51972 invoked by uid 107); 19 Jul 2011 21:20:33 +1000 Date: 19 Jul 2011 21:20:33 +1000 Date: Tue, 19 Jul 2011 21:20:33 +1000 From: Callum Gibson To: freebsd-stable@freebsd.org Message-ID: <20110719112033.GA51765@omma.gibson.athome> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-amd64@freebsd.org Subject: powernow regression in 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 13:32:02 -0000 Hi, I've just noticed and tracked down a regression in x86/cpufreq/powernow.c (on amd64) which was first mentioned here: http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023509.html although no followup seems to have occurred. Symptoms are that powerd stops working because the dev.cpu.0.freq OID is no longer gettable nor settable. This seems to have been caused by the following revision: http://svnweb.freebsd.org/base?view=revision&revision=222148 which was in turn an MFC of r221102, so I guess the problem exists on -current as well, although I can't confirm that since I don't run it. Reverting the change fixes the problem and powerd will work again. Also other utilities, such as xacpim, work properly. I'm running a ML-40 Turion laptop (HP Compaq nx6125). regards, Callum -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 13:44:29 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8FD9106566B; Tue, 19 Jul 2011 13:44:29 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 978388FC14; Tue, 19 Jul 2011 13:44:29 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id p6JDiOuW033279; Tue, 19 Jul 2011 07:44:24 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <201107190931.36492.jhb@freebsd.org> Date: Tue, 19 Jul 2011 07:44:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7C636476-7D0A-45C6-8127-A423D9170D0E@samsco.org> References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181714.07827.jhb@freebsd.org> <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> <201107190931.36492.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1084) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: markmc@dataabstractsolutions.com, "freebsd-stable@freebsd.org Stable" Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 13:44:29 -0000 On Jul 19, 2011, at 7:31 AM, John Baldwin wrote: >>=20 >> If we're going to change it, might as well break it down into 4 = fields. Maybe >> we retain the old format under a legacy switch and/or env variable = for users >> that have tools that parse the output (cough yahoo cough). >=20 > The only reason it might be nice to stick with two fields is due to = the line > length (though the first line is over 80 cols even in the current = format). Here > are two possible suggestions: >=20 I like A for the explicitness, but B is a bit easier to read on an 80 = column display. There's no 'verbose' flag for pciconf, and the '-v' = flag has already been claimed for another use; if a verbose flag were to = appear, I'd suggest hiding the rev and hdr fields under it and otherwise = shortening the line. However, it's not my bikeshed to paint, and I'll = be thrilled with either option A or B or anything in between. > I went with vendor word first for both A) and B) as in my experience = that is > the more common ordering in driver tables, etc. >=20 Indeed. Thanks a lot for working on this. Scott From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 16:05:02 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 6D380106566B; Tue, 19 Jul 2011 16:05:02 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Tue, 19 Jul 2011 12:04:51 -0400 User-Agent: KMail/1.6.2 References: <20110719112033.GA51765@omma.gibson.athome> In-Reply-To: <20110719112033.GA51765@omma.gibson.athome> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107191204.53865.jkim@FreeBSD.org> Cc: Callum Gibson , freebsd-amd64@freebsd.org Subject: Re: powernow regression in 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 16:05:02 -0000 On Tuesday 19 July 2011 07:20 am, Callum Gibson wrote: > Hi, > I've just noticed and tracked down a regression in > x86/cpufreq/powernow.c (on amd64) which was first mentioned here: > > http://lists.freebsd.org/pipermail/freebsd-current/2011-March/02350 >9.html > > although no followup seems to have occurred. > > Symptoms are that powerd stops working because the dev.cpu.0.freq > OID is no longer gettable nor settable. > > This seems to have been caused by the following revision: > http://svnweb.freebsd.org/base?view=revision&revision=222148 > which was in turn an MFC of r221102, so I guess the problem exists > on -current as well, although I can't confirm that since I don't > run it. > > Reverting the change fixes the problem and powerd will work again. > Also other utilities, such as xacpim, work properly. > > I'm running a ML-40 Turion laptop (HP Compaq nx6125). HP again... Can you please show me verbose boot messages? Thanks, Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 18:17:05 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB04F106566B for ; Tue, 19 Jul 2011 18:17:04 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7228B8FC12 for ; Tue, 19 Jul 2011 18:17:04 +0000 (UTC) Received: by wwe6 with SMTP id 6so4234774wwe.31 for ; Tue, 19 Jul 2011 11:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZdzqH6Fa73SE3Q4vp3qFCFYbUmPj485RyX5NS4/yHQY=; b=OvhE9xur+rGnH72e6xuz6DQQQn0rQ14NJfysj0lehACywq83j1ivxBaQAnCctg7YxF u/kNKNog6EZc2HWx642rS18Q/iz6hAuNZVeKAzMdCySiolBUadCCshEP3Af1181I0d4E xLiexSEAWEL3CilycfvP4N5P1/kYFOICICVgc= MIME-Version: 1.0 Received: by 10.217.4.66 with SMTP id t44mr4402444wes.25.1311099422507; Tue, 19 Jul 2011 11:17:02 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.216.46.18 with HTTP; Tue, 19 Jul 2011 11:17:02 -0700 (PDT) In-Reply-To: <201107190931.36492.jhb@freebsd.org> References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181714.07827.jhb@freebsd.org> <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> <201107190931.36492.jhb@freebsd.org> Date: Tue, 19 Jul 2011 11:17:02 -0700 X-Google-Sender-Auth: -zE2sQ3PjxGXeXiQrtsxHhRHXV8 Message-ID: From: Artem Belevich To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: markmc@dataabstractsolutions.com, "freebsd-stable@freebsd.org Stable" Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 18:17:05 -0000 On Tue, Jul 19, 2011 at 6:31 AM, John Baldwin wrote: > The only reason it might be nice to stick with two fields is due to the l= ine > length (though the first line is over 80 cols even in the current format)= . =A0Here > are two possible suggestions: > > old: > > hostb0@pci0:0:0:0: =A0 =A0 =A0class=3D0x060000 card=3D0x20108086 chip=3D0= x01008086 rev=3D0x09 hdr=3D0x00 > pcib1@pci0:0:1:0: =A0 =A0 =A0 class=3D0x060400 card=3D0x20108086 chip=3D0= x01018086 rev=3D0x09 hdr=3D0x01 > pcib2@pci0:0:1:1: =A0 =A0 =A0 class=3D0x060400 card=3D0x20108086 chip=3D0= x01058086 rev=3D0x09 hdr=3D0x01 > none0@pci0:0:22:0: =A0 =A0 =A0class=3D0x078000 card=3D0x47428086 chip=3D0= x1c3a8086 rev=3D0x04 hdr=3D0x00 > em0@pci0:0:25:0: =A0 =A0 =A0 =A0class=3D0x020000 card=3D0x00008086 chip= =3D0x15038086 rev=3D0x04 hdr=3D0x00 > ... > > A) > > hostb0@pci0:0:0:0: =A0 =A0 =A0class=3D0x060000 vendor=3D0x8086 device=3D0= x0100 subvendor=3D0x8086 subdevice=3D0x2010 rev=3D0x09 hdr=3D0x00 > pcib1@pci0:0:1:0: =A0 =A0 =A0 class=3D0x060400 vendor=3D0x8086 device=3D0= x0101 subvendor=3D0x8086 subdevice=3D0x2010 rev=3D0x09 hdr=3D0x01 > pcib2@pci0:0:1:1: =A0 =A0 =A0 class=3D0x060400 vendor=3D0x8086 device=3D0= x0105 subvendor=3D0x8086 subdevice=3D0x2010 rev=3D0x09 hdr=3D0x01 > none0@pci0:0:22:0: =A0 =A0 =A0class=3D0x078000 vendor=3D0x8086 device=3D0= x1c3a subvendor=3D0x8086 subdevice=3D0x4742 rev=3D0x04 hdr=3D0x00 > em0@pci0:0:25:0: =A0 =A0 =A0 =A0class=3D0x020000 vendor=3D0x8086 device= =3D0x1503 subvendor=3D0x8086 subdevice=3D0x0000 rev=3D0x04 hdr=3D0x00 > ... > > B) > > hostb0@pci0:0:0:0: =A0 =A0 =A0class=3D0x060000 devid=3D0x8086:0100 subid= =3D0x8086:2010 rev=3D0x09 hdr=3D0x00 > pcib1@pci0:0:1:0: =A0 =A0 =A0 class=3D0x060400 devid=3D0x8086:0101 subid= =3D0x8086:2010 rev=3D0x09 hdr=3D0x01 > pcib2@pci0:0:1:1: =A0 =A0 =A0 class=3D0x060400 devid=3D0x8086:0105 subid= =3D0x8086:2010 rev=3D0x09 hdr=3D0x01 > none0@pci0:0:22:0: =A0 =A0 =A0class=3D0x078000 devid=3D0x8086:1c3a subid= =3D0x8086:4742 rev=3D0x04 hdr=3D0x00 > em0@pci0:0:25:0: =A0 =A0 =A0 =A0class=3D0x020000 devid=3D0x8086:1503 subi= d=3D0x8086:0000 rev=3D0x04 hdr=3D0x00 > ... > > I went with vendor word first for both A) and B) as in my experience that= is > the more common ordering in driver tables, etc. Do we need to print (class|devid|device|subvendor|etc.)=3D on every line? IMHO they belong to a header line. Something like this: Driver Handle Class Vnd:Dev Sub Vnd:Dev Rev Hdr ------------------------------------------------------------------ hostb0 pci0:0:0:0 0x060000 0x8086:0100 0x8086:2010 0x09 0x00 pcib1 pci0:0:1:0 0x060400 0x8086:0101 0x8086:2010 0x09 0x01 pcib2 pci0:0:1:1 0x060400 0x8086:0105 0x8086:2010 0x09 0x01 none0 pci0:0:22:0 0x078000 0x8086:1c3a 0x8086:4742 0x04 0x00 em0 pci0:0:25:0 0x020000 0x8086:1503 0x8086:0000 0x04 0x00 --Artem From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 18:55:03 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62990106564A for ; Tue, 19 Jul 2011 18:55:03 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id 428CD8FC13 for ; Tue, 19 Jul 2011 18:55:03 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp029.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LOL00877DR3V660@asmtp029.mac.com> for freebsd-stable@freebsd.org; Tue, 19 Jul 2011 10:54:39 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-07-19_05:2011-07-19, 2011-07-19, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107190136 From: Chuck Swiger In-reply-to: Date: Tue, 19 Jul 2011 10:54:38 -0700 Message-id: References: <20110718234124.GA5626@icarus.home.lan> To: Kevin Oberman X-Mailer: Apple Mail (2.1084) Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 18:55:03 -0000 On Jul 18, 2011, at 11:04 PM, Kevin Oberman wrote: > I just wish FreeBSD had some decent documentation on such a fundamental > operation. Fortunately there are some pretty good articles folks have > written, but they did leave me with several questions. Is there something in FreeBSD which is preventing you from using the drive's native DEV_BSIZE of 4096 bytes, or is it that the drive claims to have a physical block size of 512 bytes when it is really 4k? Except for a PC BIOS maybe wanting a 512-byte boot sector, there shouldn't be anything magical about that sector size. Unix operating systems like SunOS 3 and NEXTSTEP would happily run with a DEV_BSIZE of 1024 or larger-- they'd boot fine off of optical media using 2048-byte sectors, for example, and some of the early 1990's era SCSI hard drives supported low-level reformatting to a different sector size like 1024 or 2048 bytes. Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 19:30:18 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF9CB106564A for ; Tue, 19 Jul 2011 19:30:18 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 9821F8FC15 for ; Tue, 19 Jul 2011 19:30:18 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QjFzk-0001t2-F4 for freebsd-stable@freebsd.org; Tue, 19 Jul 2011 21:30:16 +0200 Received: from cpe-188-129-78-173.dynamic.amis.hr ([188.129.78.173]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Jul 2011 21:30:16 +0200 Received: from ivoras by cpe-188-129-78-173.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Jul 2011 21:30:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 19 Jul 2011 21:29:44 +0200 Lines: 23 Message-ID: References: <20110718234124.GA5626@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-78-173.dynamic.amis.hr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 In-Reply-To: Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 19:30:19 -0000 On 19.7.2011. 19:54, Chuck Swiger wrote: > On Jul 18, 2011, at 11:04 PM, Kevin Oberman wrote: >> I just wish FreeBSD had some decent documentation on such a fundamental >> operation. Fortunately there are some pretty good articles folks have >> written, but they did leave me with several questions. > > > Is there something in FreeBSD which is preventing you from using the drive's native DEV_BSIZE of 4096 bytes, or is it that the drive claims to have a physical block size of 512 bytes when it is really 4k? Nope, "only" that. The current state of the matter (i.e. for 9.0) is: * The new ATA driver has quirks for certain models of HDDs which have this false advertising (which can be manually triggered by kern.cam.ada.X.quirks=1) which causes the drive to report stripesize of 4k. * This information is used in gpart to size & align partitions; it will be used by the new installer * Default fragment size for UFS was raised to 4K so it will be aligned by default. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 19:38:00 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D3AA106566B for ; Tue, 19 Jul 2011 19:38:00 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id E76F98FC0C for ; Tue, 19 Jul 2011 19:37:59 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp023.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LOL00JQOIIM2110@asmtp023.mac.com> for freebsd-stable@freebsd.org; Tue, 19 Jul 2011 12:37:34 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-07-19_05:2011-07-19, 2011-07-19, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107190158 From: Chuck Swiger In-reply-to: Date: Tue, 19 Jul 2011 12:37:34 -0700 Message-id: <19976EC2-462E-4B2E-AD57-57EC0921A0BF@mac.com> References: <20110718234124.GA5626@icarus.home.lan> To: "freebsd-stable@freebsd.org Stable" X-Mailer: Apple Mail (2.1084) Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 19:38:00 -0000 On Jul 19, 2011, at 12:29 PM, Ivan Voras wrote: >> Is there something in FreeBSD which is preventing you from using the drive's native DEV_BSIZE of 4096 bytes, or is it that the drive claims to have a physical block size of 512 bytes when it is really 4k? > > Nope, "only" that. :-) It's nice to have well-defined problems-- although it's perhaps not so nice when hardware is compelled to lie about its status because of backwards-compatibility (C/H/S vs LBA comes to mind also). > The current state of the matter (i.e. for 9.0) is: > > * The new ATA driver has quirks for certain models of HDDs which have this false advertising (which can be manually triggered by kern.cam.ada.X.quirks=1) which causes the drive to report stripesize of 4k. > > * This information is used in gpart to size & align partitions; it will be used by the new installer > > * Default fragment size for UFS was raised to 4K so it will be aligned by default. Excellent; thanks for the detailed reply. Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 20:58:14 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3331B106564A for ; Tue, 19 Jul 2011 20:58:14 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id E0E4E8FC0C for ; Tue, 19 Jul 2011 20:58:13 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC41C31.dip.t-dialin.net [79.196.28.49]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id B7053844010; Tue, 19 Jul 2011 22:41:26 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.1.12]) by outgoing.leidinger.net (Postfix) with ESMTP id 094E1283C; Tue, 19 Jul 2011 22:41:24 +0200 (CEST) Date: Tue, 19 Jul 2011 22:41:26 +0200 From: Alexander Leidinger To: Jeremy Chadwick Message-ID: <20110719224126.00000a25@unknown> In-Reply-To: <20110718234124.GA5626@icarus.home.lan> References: <20110718234124.GA5626@icarus.home.lan> X-Mailer: Claws Mail 3.7.8cvs47 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: B7053844010.AD48B X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.923, required 6, autolearn=disabled, ALL_TRUSTED -1.00, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1311712887.11659@RTKkVflNP5oqQWlEyiG3mg X-EBL-Spam-Status: No Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 20:58:14 -0000 On Mon, 18 Jul 2011 16:41:24 -0700 Jeremy Chadwick wrote: > But the currently "known method" is to use gnop(8). Here's an > example: > > http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optimized-for-4k-sector-drives/ > > Now, that's for ZFS, but I'm under the impression the exact same is > needed for FFS/UFS. Info: gnop will not work for FFS/UFS because gnop is a temporary solution (needs to be done by hand at each reboot). For FFS/UFS you need to align the slice/partition and chose a good blocksize/fragsize combination (e.g. 32k/4k). Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 21:10:51 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4E331065673 for ; Tue, 19 Jul 2011 21:10:51 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id 2DE588FC0A for ; Tue, 19 Jul 2011 21:10:43 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p6JLAehA024997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2011 07:10:41 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id p6JLAe4H016141; Wed, 20 Jul 2011 07:10:40 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id p6JLAd9P016140; Wed, 20 Jul 2011 07:10:39 +1000 (EST) (envelope-from peter) Date: Wed, 20 Jul 2011 07:10:39 +1000 From: Peter Jeremy To: Chuck Swiger Message-ID: <20110719211039.GA16085@server.vk2pj.dyndns.org> References: <20110718234124.GA5626@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 21:10:51 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Jul-19 10:54:38 -0700, Chuck Swiger wrote: > Unix operating >systems like SunOS 3 and NEXTSTEP would happily run with a DEV_BSIZE >of 1024 or larger-- they'd boot fine off of optical media using >2048-byte sectors, Actually, Sun used customised CD-ROM drives that faked 512-byte sectors to work around their lack of support for anything else. > some of the early 1990's era SCSI >hard drives supported low-level reformatting to a different sector >size like 1024 or 2048 bytes. Did anyone actually do this? I wanted to but was warned against it by the local OS rep (this was a Motorola SVR2). --=20 Peter Jeremy --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk4l8s8ACgkQ/opHv/APuIdr6QCbB0i+eC2SlCpl8QEOI4k6D9bi UpEAoLmRwdNcctv41lYY3bmRtKhK7tLO =fzEl -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 21:33:28 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B7C4106566B for ; Tue, 19 Jul 2011 21:33:28 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A1408FC0A for ; Tue, 19 Jul 2011 21:33:28 +0000 (UTC) Received: by gxk28 with SMTP id 28so2405937gxk.13 for ; Tue, 19 Jul 2011 14:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1fDWOEldK07AISpVHPwEAntsxhJYu4PofV5ivJRJ2lQ=; b=io4/QwiFMyh4VRDVTr+968CwuSPydt9tRIALqHctsxEg83E3V3cRuyYoTI/1ZEBa7a YnYF8zt9x4BlROXpJ5hoQdZN6fX8mZXF7K8dnYCzXvckaa83AS2dpPmt90xRlSuPIgdm DFrw3IjJ6u7yzVz+3tfw9JxdMjjmEhHeqeNYM= MIME-Version: 1.0 Received: by 10.150.164.4 with SMTP id m4mr304823ybe.369.1311111207573; Tue, 19 Jul 2011 14:33:27 -0700 (PDT) Received: by 10.151.27.21 with HTTP; Tue, 19 Jul 2011 14:33:27 -0700 (PDT) In-Reply-To: <20110719224126.00000a25@unknown> References: <20110718234124.GA5626@icarus.home.lan> <20110719224126.00000a25@unknown> Date: Tue, 19 Jul 2011 14:33:27 -0700 Message-ID: From: Kevin Oberman To: Alexander Leidinger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org Stable" , Jeremy Chadwick Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 21:33:28 -0000 On Tue, Jul 19, 2011 at 1:41 PM, Alexander Leidinger wrote: > On Mon, 18 Jul 2011 16:41:24 -0700 Jeremy Chadwick > wrote: > >> But the currently "known method" is to use gnop(8). =A0Here's an >> example: >> >> http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optim= ized-for-4k-sector-drives/ >> >> Now, that's for ZFS, but I'm under the impression the exact same is >> needed for FFS/UFS. > > Info: gnop will not work for FFS/UFS because gnop is a temporary > solution (needs to be done by hand at each reboot). For FFS/UFS you > need to align the slice/partition and chose a good blocksize/fragsize > combination (e.g. 32k/4k). > > Bye, > Alexander. > > -- > http://www.Leidinger.net =A0 =A0Alexander @ Leidinger.net: PGP ID =3D B00= 63FE7 > http://www.FreeBSD.org =A0 =A0 =A0 netchild @ FreeBSD.org =A0: PGP ID =3D= 72077137 > Thanks, Alexander. This is what I had expected after reading the man pages, though I would think -b 65560 -f 8192' would be a bit more reasonable in this day of bloated file formats. it's been years since I have hit a problem with lack of inodes. Probably around 1993 on an old SparcStation 1 running SunOS and then only due to a bad assumption I made when 'newfs'ing it. Again, thanks for the advice. At very least it will save me a bit of time! --=20 R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 21:50:07 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 436B41065670 for ; Tue, 19 Jul 2011 21:50:07 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id EE39B8FC12 for ; Tue, 19 Jul 2011 21:50:06 +0000 (UTC) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta12.westchester.pa.mail.comcast.net with comcast id 9xq01h0010EZKEL5Cxq7nE; Tue, 19 Jul 2011 21:50:07 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta01.westchester.pa.mail.comcast.net with comcast id 9xpr1h00Y1t3BNj3Mxq0zd; Tue, 19 Jul 2011 21:50:04 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 09EDD102C36; Tue, 19 Jul 2011 14:49:50 -0700 (PDT) Date: Tue, 19 Jul 2011 14:49:50 -0700 From: Jeremy Chadwick To: Kevin Oberman Message-ID: <20110719214949.GA28709@icarus.home.lan> References: <20110718234124.GA5626@icarus.home.lan> <20110719224126.00000a25@unknown> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Alexander Leidinger , "freebsd-stable@freebsd.org Stable" Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 21:50:07 -0000 On Tue, Jul 19, 2011 at 02:33:27PM -0700, Kevin Oberman wrote: > On Tue, Jul 19, 2011 at 1:41 PM, Alexander Leidinger > wrote: > > On Mon, 18 Jul 2011 16:41:24 -0700 Jeremy Chadwick > > wrote: > > > >> But the currently "known method" is to use gnop(8). ?Here's an > >> example: > >> > >> http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optimized-for-4k-sector-drives/ > >> > >> Now, that's for ZFS, but I'm under the impression the exact same is > >> needed for FFS/UFS. > > > > Info: gnop will not work for FFS/UFS because gnop is a temporary > > solution (needs to be done by hand at each reboot). For FFS/UFS you > > need to align the slice/partition and chose a good blocksize/fragsize > > combination (e.g. 32k/4k). > > > > Bye, > > Alexander. > > > > -- > > http://www.Leidinger.net ? ?Alexander @ Leidinger.net: PGP ID = B0063FE7 > > http://www.FreeBSD.org ? ? ? netchild @ FreeBSD.org ?: PGP ID = 72077137 > > > > Thanks, Alexander. > > This is what I had expected after reading the man pages, though I > would think -b 65560 -f 8192' would be a bit more reasonable in this ^^^^^^^^ ^^^^^^^^ Where did this number come from? Did you mean 65536? 65560 would not be properly aligned. > day of bloated file formats. it's been years since I have hit a > problem with lack of inodes. Probably around 1993 on an old > SparcStation 1 running SunOS and then only due to a bad assumption I > made when 'newfs'ing it. > > Again, thanks for the advice. At very least it will save me a bit of time! Agreed -- thanks for the advice, Alexander. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 22:00:27 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD428106564A for ; Tue, 19 Jul 2011 22:00:27 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id A30968FC12 for ; Tue, 19 Jul 2011 22:00:27 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp023.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LOL00LG9P4QY170@asmtp023.mac.com> for freebsd-stable@freebsd.org; Tue, 19 Jul 2011 15:00:27 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-07-19_05:2011-07-19, 2011-07-19, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107190185 From: Chuck Swiger In-reply-to: <20110719211039.GA16085@server.vk2pj.dyndns.org> Date: Tue, 19 Jul 2011 15:00:26 -0700 Message-id: <02D367A5-CA74-4E8A-BE3E-F81485B287A7@mac.com> References: <20110718234124.GA5626@icarus.home.lan> <20110719211039.GA16085@server.vk2pj.dyndns.org> To: Peter Jeremy X-Mailer: Apple Mail (2.1084) Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 22:00:27 -0000 On Jul 19, 2011, at 2:10 PM, Peter Jeremy wrote: > On 2011-Jul-19 10:54:38 -0700, Chuck Swiger wrote: >> Unix operating >> systems like SunOS 3 and NEXTSTEP would happily run with a DEV_BSIZE >> of 1024 or larger-- they'd boot fine off of optical media using >> 2048-byte sectors, > > Actually, Sun used customised CD-ROM drives that faked 512-byte > sectors to work around their lack of support for anything else. Hmm-- my brain could be fuzzy about things twenty-plus years ago. But I remember booting a Sun3_35 or _60 from a non-Sun or Sun OEM'ed SCSI CD-ROM drive, probably a Plextor? >> some of the early 1990's era SCSI hard drives supported low-level reformatting to a different sector size like 1024 or 2048 bytes. > > Did anyone actually do this? I wanted to but was warned against > it by the local OS rep (this was a Motorola SVR2). Worked fine with 250MB Seagate ST1280 drives, and also a a 1GB Micropolis 2112. It made a decent gain to available disk capacity (about 10-15%), and a smaller improvement to performance (about 5% IIRC). It wouldn't work with drives using a dedicated embedded servo for sector positioning (ie, Quantum and DEC), but other vendors like Seagate used a normal platter surface for servo positioning, and you could reformat it with a different sector size. Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 22:17:18 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C1C31065672 for ; Tue, 19 Jul 2011 22:17:18 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2A33B8FC08 for ; Tue, 19 Jul 2011 22:17:17 +0000 (UTC) Received: by yxl31 with SMTP id 31so2434084yxl.13 for ; Tue, 19 Jul 2011 15:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=kUU6j6wdd9bmGWjiBZllepktfTdniDLfWc+uogVW8UE=; b=sAprrRTUAoNSD3rsuL8DsXLtX8abh3QTZT+Ggu9fwxhn5e/Tcd8TGxfNeeC6NExG5F EHGGtFm8YQE+R3QmOSYDpMq38oE1wc1OxANCFMUXDWiNM6lzvg5q1XGHtY/3AiZ3vc68 PDxgcjru+RYwss02HL0Mtdtw3gJo1aTVrz4XY= MIME-Version: 1.0 Received: by 10.150.164.4 with SMTP id m4mr341968ybe.369.1311113837222; Tue, 19 Jul 2011 15:17:17 -0700 (PDT) Received: by 10.151.27.21 with HTTP; Tue, 19 Jul 2011 15:17:17 -0700 (PDT) In-Reply-To: <20110719214949.GA28709@icarus.home.lan> References: <20110718234124.GA5626@icarus.home.lan> <20110719224126.00000a25@unknown> <20110719214949.GA28709@icarus.home.lan> Date: Tue, 19 Jul 2011 15:17:17 -0700 Message-ID: From: Kevin Oberman To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Leidinger , "freebsd-stable@freebsd.org Stable" Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 22:17:18 -0000 On Tue, Jul 19, 2011 at 2:49 PM, Jeremy Chadwick wrote: > On Tue, Jul 19, 2011 at 02:33:27PM -0700, Kevin Oberman wrote: >> On Tue, Jul 19, 2011 at 1:41 PM, Alexander Leidinger >> wrote: >> > On Mon, 18 Jul 2011 16:41:24 -0700 Jeremy Chadwick >> > wrote: >> > >> >> But the currently "known method" is to use gnop(8). ?Here's an >> >> example: >> >> >> >> http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-op= timized-for-4k-sector-drives/ >> >> >> >> Now, that's for ZFS, but I'm under the impression the exact same is >> >> needed for FFS/UFS. >> > >> > Info: gnop will not work for FFS/UFS because gnop is a temporary >> > solution (needs to be done by hand at each reboot). For FFS/UFS you >> > need to align the slice/partition and chose a good blocksize/fragsize >> > combination (e.g. 32k/4k). >> > >> > Bye, >> > Alexander. >> > >> > -- >> > http://www.Leidinger.net ? ?Alexander @ Leidinger.net: PGP ID =3D B006= 3FE7 >> > http://www.FreeBSD.org ? ? ? netchild @ FreeBSD.org ?: PGP ID =3D 7207= 7137 >> > >> >> Thanks, Alexander. >> >> This is what I had expected after reading the man pages, though I >> would think -b 65560 -f 8192' would be a bit more reasonable in this > =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^^^^^^ > =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^^^^^^ > Where did this number come from? =A0Did you mean 65536? =A065560 would no= t > be properly aligned. Ack! Fingers and brain out of sync. Yes, 65536 is what I meant. >> day of bloated file formats. it's been years since I have hit a >> problem with lack of inodes. Probably around 1993 on an old >> SparcStation 1 running SunOS and then only due to a bad assumption I >> made when 'newfs'ing it. >> >> Again, thanks for the advice. At very least it will save me a bit of tim= e! > > Agreed -- thanks for the advice, Alexander. > > -- > | Jeremy Chadwick =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0jdc at parodius.com | > | Parodius Networking =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://= www.parodius.com/ | > | UNIX Systems Administrator =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mountain= View, CA, US | > | Making life hard for others since 1977. =A0 =A0 =A0 =A0 =A0 =A0 =A0 PGP= 4BD6C0CB | > > --=20 R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 00:30:30 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CBDF1065787; Wed, 20 Jul 2011 00:30:30 +0000 (UTC) (envelope-from Peter.Ross@bogen.in-berlin.de) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by mx1.freebsd.org (Postfix) with ESMTP id 0EBCC8FC0A; Wed, 20 Jul 2011 00:30:28 +0000 (UTC) X-Envelope-From: Peter.Ross@bogen.in-berlin.de Received: from localhost (okapi.in-berlin.de [192.109.42.117]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id p6K0URmT000390; Wed, 20 Jul 2011 02:30:27 +0200 Received: from 124-254-118-24-static.bb.ispone.net.au (124-254-118-24-static.bb.ispone.net.au [124.254.118.24]) by webmail.in-berlin.de (Horde Framework) with HTTP; Wed, 20 Jul 2011 10:30:27 +1000 Message-ID: <20110720103027.73392kcq4jrnkvxf@webmail.in-berlin.de> Date: Wed, 20 Jul 2011 10:30:27 +1000 From: "Peter Ross" To: "Peter Ross" References: <20110706122339.61453nlqra1vqsrv@webmail.in-berlin.de> <20110706023234.GA72048@icarus.home.lan> <20110706130753.182053f3ellasn0p@webmail.in-berlin.de> <20110706032425.GA72757@icarus.home.lan> <20110706135412.15276i0fxavg09k4@webmail.in-berlin.de> <20110706041504.GA73698@icarus.home.lan> <20110706143129.10696235ldx9bjmp@webmail.in-berlin.de> <20110706173242.23404ffbhkxz6mqi@webmail.in-berlin.de> <20110706182141.13056plxp148y61h@webmail.in-berlin.de> <20110711115947.51686v4930s7ze37@webmail.in-berlin.de> In-Reply-To: <20110711115947.51686v4930s7ze37@webmail.in-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) 4.3.3 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 Cc: Yong-Hyeon Pyun , freebsd-stable List , "Vogel, Jack" , Scott Sipe , davidch@freebsd.org, Jeremy Chadwick Subject: Re: scp: Write Failed: Cannot allocate memory - Problem found and solved (for me) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 00:30:30 -0000 Quoting "Peter Ross" : > Quoting "Scott Sipe" : > >> On Wed, Jul 6, 2011 at 4:21 AM, Peter Ross =20 >> wrote: >> >>> Quoting "Peter Ross" : >>> >>> Quoting "Peter Ross" : >>>> >>>> Quoting "Jeremy Chadwick" : >>>>> >>>>> On Wed, Jul 06, 2011 at 01:54:12PM +1000, Peter Ross wrote: >>>>>> >>>>>>> Quoting "Jeremy Chadwick" : >>>>>>> >>>>>>> On Wed, Jul 06, 2011 at 01:07:53PM +1000, Peter Ross wrote: >>>>>>>> >>>>>>>>> Quoting "Jeremy Chadwick" : >>>>>>>>> >>>>>>>>> On Wed, Jul 06, 2011 at 12:23:39PM +1000, Peter Ross wrote: >>>>>>>>>> >>>>>>>>>>> Quoting "Jeremy Chadwick" : >>>>>>>>>>> >>>>>>>>>>> On Tue, Jul 05, 2011 at 01:03:20PM -0400, Scott Sipe wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I'm running virtualbox 3.2.12_1 if that has anything to do wit= h >>>>>>>>>>>>> it. >>>>>>>>>>>>> >>>>>>>>>>>>> sysctl vfs.zfs.arc_max: 6200000000 >>>>>>>>>>>>> >>>>>>>>>>>>> While I'm trying to scp, kstat.zfs.misc.arcstats.size is >>>>>>>>>>>>> hovering right around that value, sometimes above, sometimes >>>>>>>>>>>>> below (that's as it should be, right?). I don't think that it >>>>>>>>>>>>> dies when crossing over arc_max. I can run the same scp 10 tim= es >>>>>>>>>>>>> and it might fail 1-3 times, with no correlation to the >>>>>>>>>>>>> arcstats.size being above/below arc_max that I can see. >>>>>>>>>>>>> >>>>>>>>>>>>> Scott >>>>>>>>>>>>> >>>>>>>>>>>>> On Jul 5, 2011, at 3:00 AM, Peter Ross wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> just as an addition: an upgrade to last Friday's >>>>>>>>>>>>>> FreeBSD-Stable and to VirtualBox 4.0.8 does not fix the >>>>>>>>>>>>>> problem. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I will experiment a bit more tomorrow after hours and grab >>>>>>>>>>>>>> >>>>>>>>>>>>> some statistics. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> Peter >>>>>>>>>>>>>> >>>>>>>>>>>>>> Quoting "Peter Ross" : >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I noticed a similar problem last week. It is also very >>>>>>>>>>>>>>> similar to one reported last year: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://lists.freebsd.org/**pipermail/freebsd-stable/2010-** >>>>>>>>>>>>>>> September/058708.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My server is a Dell T410 server with the same bge card (the >>>>>>>>>>>>>>> same pciconf -lvc output as described by Mahlon: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://lists.freebsd.org/**pipermail/freebsd-stable/2010-** >>>>>>>>>>>>>>> September/058711.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yours, Scott, is a em(4).. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Another similarity: In all cases we are using VirtualBox. I >>>>>>>>>>>>>>> just want to mention it, in case it matters. I am still >>>>>>>>>>>>>>> running VirtualBox 3.2. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Most of the time kstat.zfs.misc.arcstats.size was reaching >>>>>>>>>>>>>>> vfs.zfs.arc_max then, but I could catch one or two cases >>>>>>>>>>>>>>> then the value was still below. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I added vfs.zfs.prefetch_disable=3D1 to sysctl.conf but it >>>>>>>>>>>>>>> >>>>>>>>>>>>>> does not help. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> BTW: It looks as ARC only gives back the memory when I >>>>>>>>>>>>>>> destroy the ZFS (a cloned snapshot containing virtual >>>>>>>>>>>>>>> machines). Even if nothing happens for hours the buffer >>>>>>>>>>>>>>> isn't released.. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My machine was still running 8.2-PRERELEASE so I am upgradin= g. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am happy to give information gathered on old/new kernel if= it >>>>>>>>>>>>>>> helps. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>> Peter >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Quoting "Scott Sipe" : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Jul 2, 2011, at 12:54 AM, jhell wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Fri, Jul 01, 2011 at 03:22:32PM -0700, Jeremy Chadwick >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Fri, Jul 01, 2011 at 03:13:17PM -0400, Scott Sipe wrot= e: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I'm running 8.2-RELEASE and am having new problems >>>>>>>>>>>>>>>>>>> with scp. When scping >>>>>>>>>>>>>>>>>>> files to a ZFS directory on the FreeBSD server -- >>>>>>>>>>>>>>>>>>> most notably large files >>>>>>>>>>>>>>>>>>> -- the transfer frequently dies after just a few >>>>>>>>>>>>>>>>>>> seconds. In my last test, I >>>>>>>>>>>>>>>>>>> tried to scp an 800mb file to the FreeBSD system and >>>>>>>>>>>>>>>>>>> the transfer died after >>>>>>>>>>>>>>>>>>> 200mb. It completely copied the next 4 times I >>>>>>>>>>>>>>>>>>> tried, and then died again on >>>>>>>>>>>>>>>>>>> the next attempt. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On the client side: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> "Connection to home closed by remote host. >>>>>>>>>>>>>>>>>>> lost connection" >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> In /var/log/auth.log: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Jul 1 14:54:42 freebsd sshd[18955]: fatal: Write >>>>>>>>>>>>>>>>>>> failed: Cannot allocate >>>>>>>>>>>>>>>>>>> memory >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I've never seen this before and have used scp before >>>>>>>>>>>>>>>>>>> to transfer large files >>>>>>>>>>>>>>>>>>> without problems. This computer has been used in >>>>>>>>>>>>>>>>>>> production for months and >>>>>>>>>>>>>>>>>>> has a current uptime of 36 days. I have not been >>>>>>>>>>>>>>>>>>> able to notice any problems >>>>>>>>>>>>>>>>>>> copying files to the server via samba or netatalk, or >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> any problems in >>>>>>>>>>> >>>>>>>>>>>> apache. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Uname: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> FreeBSD xeon 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Sat >>>>>>>>>>>>>>>>>>> Feb 19 01:02:54 EST >>>>>>>>>>>>>>>>>>> 2011 root@xeon:/usr/obj/usr/src/**sys/GENERIC amd64 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I've attached my dmesg and output of vmstat -z. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I have not restarted the sshd daemon or rebooted the >>>>>>>>>>>>>>>>>>> computer. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Am glad to provide any other information or test anythin= g >>>>>>>>>>>>>>>>>>> else. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> {snip vmstat -z and dmesg} >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> You didn't provide details about your networking setup >>>>>>>>>>>>>>>>>> (rc.conf, >>>>>>>>>>>>>>>>>> ifconfig -a, etc.). netstat -m would be useful too. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Next, please see this thread circa September 2010, titled >>>>>>>>>>>>>>>>>> "Network >>>>>>>>>>>>>>>>>> memory allocation failures": >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://lists.freebsd.org/**pipermail/freebsd-stable/2010-= ** >>>>>>>>>>>>>>>>>> September/thread.html#58708 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The user in that thread is using rsync, which relies on >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> scp by default. >>>>>>>>>>> >>>>>>>>>>>> I believe this problem is similar, if not identical, to yours. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please also provide your output of ( /usr/bin/limits -a ) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> for the server >>>>>>>>>>> >>>>>>>>>>>> end and the client. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I am not quite sure I agree with the need for ifconfig -a = but >>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>> information about the networking driver your using for the >>>>>>>>>>>>>>>>> interface >>>>>>>>>>>>>>>>> would be helpful, uptime of the boxes. And configuration >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> of the pool. >>>>>>>>> >>>>>>>>>> e.g. ( zpool status -a ;zfs get all ) You should proba= bly >>>>>>>>>>>>>>>>> prop this information up somewhere so you can reference by >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> URL whenever >>>>>>>>>>> >>>>>>>>>>>> needed. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> rsync(1) does not rely on scp(1) whatsoever but rsync(1) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> can be made to >>>>>>>>>>> >>>>>>>>>>>> use ssh(1) instead of rsh(1) and I believe that is what Jeremy = is >>>>>>>>>>>>>>>>> stating here but correct me if I am wrong. It does use ssh= (1) >>>>>>>>>>>>>>>>> by >>>>>>>>>>>>>>>>> default. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Its a possiblity as well that if using tmpfs(5) or mdmfs(8= ) >>>>>>>>>>>>>>>>> for /tmp >>>>>>>>>>>>>>>>> type filesystems that rsync(1) may be just filling up your >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> temp ram area >>>>>>>>>>> >>>>>>>>>>>> and causing the connection abort which would be >>>>>>>>>>>>>>>>> expected. ( df -h ) would >>>>>>>>>>>>>>>>> help here. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm not using tmpfs/mdmfs at all. The clients yesterday >>>>>>>>>>>>>>>> were 3 different OSX computers (over gigabit). The FreeBSD >>>>>>>>>>>>>>>> server has 12gb of ram and no bce adapter. For what it's >>>>>>>>>>>>>>>> worth, the server is backed up remotely every night with >>>>>>>>>>>>>>>> rsync (remote FreeBSD uses rsync to pull) to an offsite >>>>>>>>>>>>>>>> (slow cable connection) FreeBSD computer, and I have not >>>>>>>>>>>>>>>> seen any errors in the nightly rsync. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sorry for the omission of networking info, here's the >>>>>>>>>>>>>>>> output of the requested commands and some that popped up >>>>>>>>>>>>>>>> in the other thread: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://www.cap-press.com/misc/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In rc.conf: ifconfig_em1=3D"inet 10.1.1.1 netmask 255.255.= 0.0" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Scott >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> Just to make it crystal clear to everyone: >>>>>>>>>>>> >>>>>>>>>>>> There is no correlation between this problem and use of ZFS. >>>>>>>>>>>> People are >>>>>>>>>>>> attempting to correlate "cannot allocate memory" messages with >>>>>>>>>>>> "anything >>>>>>>>>>>> on the system that uses memory". The VM is much more complex t= han >>>>>>>>>>>> that. >>>>>>>>>>>> >>>>>>>>>>>> Given the nature of this problem, it's much more likely the iss= ue >>>>>>>>>>>> is >>>>>>>>>>>> "somewhere" within a networking layer within FreeBSD, whether i= t >>>>>>>>>>>> be >>>>>>>>>>>> driver-level or some sort of intermediary layer. >>>>>>>>>>>> >>>>>>>>>>>> Two people who have this issue in this thread are both using >>>>>>>>>>>> VirtualBox. >>>>>>>>>>>> Can one, or both, of you remove VirtualBox from the configurati= on >>>>>>>>>>>> entirely (kernel, etc. -- not sure what is required) and then s= ee >>>>>>>>>>>> if the >>>>>>>>>>>> issue goes away? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On the machine in question I only can do it after hours so I wil= l >>>>>>>>>>> do >>>>>>>>>>> it tonight. >>>>>>>>>>> >>>>>>>>>>> I was _successfully_ sending the file over the loopback interfac= e >>>>>>>>>>> using >>>>>>>>>>> >>>>>>>>>>> cat /zpool/temp/zimbra_oldroot.vdi | ssh localhost "cat > >>>>>>>>>>> /dev/null" >>>>>>>>>>> >>>>>>>>>>> I did it, btw, with the IPv6 localhost address first (accidently= ), >>>>>>>>>>> and then using IPv4. Both worked. >>>>>>>>>>> >>>>>>>>>>> It always fails if I am sending it through the bce(4) interface, >>>>>>>>>>> even if my target is the VirtualBox bridged to the bce card (so = it >>>>>>>>>>> does not "leave" the computer physically). >>>>>>>>>>> >>>>>>>>>>> Below the uname -a, ifconfig -a, netstat -rn, pciconf -lv and >>>>>>>>>>> kldstat output. >>>>>>>>>>> >>>>>>>>>>> I have another box where I do not see that problem. It copies fi= les >>>>>>>>>>> happily over the net using ssh. >>>>>>>>>>> >>>>>>>>>>> It is an an older HP ML 150 with 3GB RAM only but with a bge(4) >>>>>>>>>>> driver instead. It runs the same last week's RELENG_8. I install= ed >>>>>>>>>>> VirtualBox and enabled vboxnet (so it loads the kernel modules). >>>>>>>>>>> But >>>>>>>>>>> I do not run VirtualBox on it (because it hasn't enough RAM). >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Peter >>>>>>>>>>> >>>>>>>>>>> DellT410one# uname -a >>>>>>>>>>> FreeBSD DellT410one.vv.fda 8.2-STABLE FreeBSD 8.2-STABLE #1: Thu >>>>>>>>>>> Jun >>>>>>>>>>> 30 17:07:18 EST 2011 >>>>>>>>>>> root@DellT410one.vv.fda:/usr/**obj/usr/src/sys/GENERIC amd64 >>>>>>>>>>> DellT410one# ifconfig -a >>>>>>>>>>> bce0: flags=3D8943>>>>>>>>>> MULTICAST> >>>>>>>>>>> metric 0 mtu 1500 >>>>>>>>>>> options=3Dc01bb>>>>>>>>>> VLAN_MTU,VLAN_HWTAGGING,JUMBO_**MTU,VLAN_HWCSUM,TSO4,VLAN_** >>>>>>>>>>> HWTSO,LINKSTATE> >>>>>>>>>>> ether 84:2b:2b:68:64:e4 >>>>>>>>>>> inet 192.168.50.220 netmask 0xffffff00 broadcast >>>>>>>>>>> 192.168.50.255 >>>>>>>>>>> inet 192.168.50.221 netmask 0xffffff00 broadcast >>>>>>>>>>> 192.168.50.255 >>>>>>>>>>> inet 192.168.50.223 netmask 0xffffff00 broadcast >>>>>>>>>>> 192.168.50.255 >>>>>>>>>>> inet 192.168.50.224 netmask 0xffffff00 broadcast >>>>>>>>>>> 192.168.50.255 >>>>>>>>>>> inet 192.168.50.225 netmask 0xffffff00 broadcast >>>>>>>>>>> 192.168.50.255 >>>>>>>>>>> inet 192.168.50.226 netmask 0xffffff00 broadcast >>>>>>>>>>> 192.168.50.255 >>>>>>>>>>> inet 192.168.50.227 netmask 0xffffff00 broadcast >>>>>>>>>>> 192.168.50.255 >>>>>>>>>>> inet 192.168.50.219 netmask 0xffffff00 broadcast >>>>>>>>>>> 192.168.50.255 >>>>>>>>>>> media: Ethernet autoselect (1000baseT ) >>>>>>>>>>> status: active >>>>>>>>>>> bce1: flags=3D8802 metric 0 mtu 1= 500 >>>>>>>>>>> options=3Dc01bb>>>>>>>>>> VLAN_MTU,VLAN_HWTAGGING,JUMBO_**MTU,VLAN_HWCSUM,TSO4,VLAN_** >>>>>>>>>>> HWTSO,LINKSTATE> >>>>>>>>>>> ether 84:2b:2b:68:64:e5 >>>>>>>>>>> media: Ethernet autoselect >>>>>>>>>>> lo0: flags=3D8049 metric 0 mtu >>>>>>>>>>> 16384 >>>>>>>>>>> options=3D3 >>>>>>>>>>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb >>>>>>>>>>> inet6 ::1 prefixlen 128 >>>>>>>>>>> inet 127.0.0.1 netmask 0xff000000 >>>>>>>>>>> nd6 options=3D3 >>>>>>>>>>> vboxnet0: flags=3D8802 metric 0 m= tu >>>>>>>>>>> 1500 >>>>>>>>>>> ether 0a:00:27:00:00:00 >>>>>>>>>>> DellT410one# netstat -rn >>>>>>>>>>> Routing tables >>>>>>>>>>> >>>>>>>>>>> Internet: >>>>>>>>>>> Destination Gateway Flags Refs Use Ne= tif >>>>>>>>>>> Expire >>>>>>>>>>> default 192.168.50.201 UGS 0 52195 b= ce0 >>>>>>>>>>> 127.0.0.1 link#11 UH 0 6 = lo0 >>>>>>>>>>> 192.168.50.0/24 link#1 U 0 1118212 >>>>>>>>>>> bce0 >>>>>>>>>>> 192.168.50.219 link#1 UHS 0 9670 = lo0 >>>>>>>>>>> 192.168.50.220 link#1 UHS 0 8347 = lo0 >>>>>>>>>>> 192.168.50.221 link#1 UHS 0 103024 = lo0 >>>>>>>>>>> 192.168.50.223 link#1 UHS 0 43614 = lo0 >>>>>>>>>>> 192.168.50.224 link#1 UHS 0 8358 = lo0 >>>>>>>>>>> 192.168.50.225 link#1 UHS 0 8438 = lo0 >>>>>>>>>>> 192.168.50.226 link#1 UHS 0 8338 = lo0 >>>>>>>>>>> 192.168.50.227 link#1 UHS 0 8333 = lo0 >>>>>>>>>>> 192.168.165.0/24 192.168.50.200 UGS 0 3311 >>>>>>>>>>> bce0 >>>>>>>>>>> 192.168.166.0/24 192.168.50.200 UGS 0 699 >>>>>>>>>>> bce0 >>>>>>>>>>> 192.168.167.0/24 192.168.50.200 UGS 0 3012 >>>>>>>>>>> bce0 >>>>>>>>>>> 192.168.168.0/24 192.168.50.200 UGS 0 552 >>>>>>>>>>> bce0 >>>>>>>>>>> >>>>>>>>>>> Internet6: >>>>>>>>>>> Destination Gateway >>>>>>>>>>> Flags Netif Expire >>>>>>>>>>> ::1 ::1 = UH >>>>>>>>>>> lo0 >>>>>>>>>>> fe80::%lo0/64 link#11 = U >>>>>>>>>>> lo0 >>>>>>>>>>> fe80::1%lo0 link#11 = UHS >>>>>>>>>>> lo0 >>>>>>>>>>> ff01::%lo0/32 fe80::1%lo0 = U >>>>>>>>>>> lo0 >>>>>>>>>>> ff02::%lo0/32 fe80::1%lo0 = U >>>>>>>>>>> lo0 >>>>>>>>>>> DellT410one# kldstat >>>>>>>>>>> Id Refs Address Size Name >>>>>>>>>>> 1 19 0xffffffff80100000 dbf5d0 kernel >>>>>>>>>>> 2 3 0xffffffff80ec0000 4c358 vboxdrv.ko >>>>>>>>>>> 3 1 0xffffffff81012000 131998 zfs.ko >>>>>>>>>>> 4 1 0xffffffff81144000 1ff1 opensolaris.ko >>>>>>>>>>> 5 2 0xffffffff81146000 2940 vboxnetflt.ko >>>>>>>>>>> 6 2 0xffffffff81149000 8e38 netgraph.ko >>>>>>>>>>> 7 1 0xffffffff81152000 153c ng_ether.ko >>>>>>>>>>> 8 1 0xffffffff81154000 e70 vboxnetadp.ko >>>>>>>>>>> DellT410one# pciconf -lv >>>>>>>>>>> .. >>>>>>>>>>> bce0@pci0:1:0:0: class=3D0x020000 card=3D0x028d1028 >>>>>>>>>>> chip=3D0x163b14e4 rev=3D0x20 hdr=3D0x00 >>>>>>>>>>> vendor =3D 'Broadcom Corporation' >>>>>>>>>>> class =3D network >>>>>>>>>>> subclass =3D ethernet >>>>>>>>>>> bce1@pci0:1:0:1: class=3D0x020000 card=3D0x028d1028 >>>>>>>>>>> chip=3D0x163b14e4 rev=3D0x20 hdr=3D0x00 >>>>>>>>>>> vendor =3D 'Broadcom Corporation' >>>>>>>>>>> class =3D network >>>>>>>>>>> subclass =3D ethernet >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Could you please provide "pciconf -lvcb" output instead, specific= to >>>>>>>>>> the >>>>>>>>>> bce chips? Thanks. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Her it is: >>>>>>>>> >>>>>>>>> bce0@pci0:1:0:0: class=3D0x020000 card=3D0x028d1028 >>>>>>>>> chip=3D0x163b14e4 rev=3D0x20 hdr=3D0x00 >>>>>>>>> vendor =3D 'Broadcom Corporation' >>>>>>>>> class =3D network >>>>>>>>> subclass =3D ethernet >>>>>>>>> bar [10] =3D type Memory, range 64, base 0xda000000, size >>>>>>>>> 33554432, enabled >>>>>>>>> cap 01[48] =3D powerspec 3 supports D0 D3 current D0 >>>>>>>>> cap 03[50] =3D VPD >>>>>>>>> cap 05[58] =3D MSI supports 16 messages, 64 bit enabled with 1 mes= sage >>>>>>>>> cap 11[a0] =3D MSI-X supports 9 messages in map 0x10 >>>>>>>>> cap 10[ac] =3D PCI-Express 2 endpoint max data 256(512) link x4(x4= ) >>>>>>>>> ecap 0003[100] =3D Serial 1 842b2bfffe6864e4 >>>>>>>>> ecap 0001[110] =3D AER 1 0 fatal 0 non-fatal 1 corrected >>>>>>>>> ecap 0004[150] =3D unknown 1 >>>>>>>>> ecap 0002[160] =3D VC 1 max VC0 >>>>>>>>> >>>>>>>> >>>>>>>> Thanks Peter. >>>>>>>> >>>>>>>> Adding Yong-Hyeon and David to the discussion, since they've both >>>>>>>> worked >>>>>>>> on the bce(4) driver in recent months (most of the changes made >>>>>>>> recently >>>>>>>> are only in HEAD), and also adding Jack Vogel of Intel who maintain= s >>>>>>>> em(4). Brief history for the devs: >>>>>>>> >>>>>>>> The issue is described "Network memory allocation failures" and was >>>>>>>> reported last year, but two users recently (Scott and Peter) have >>>>>>>> reported the issue again: >>>>>>>> >>>>>>>> http://lists.freebsd.org/**pipermail/freebsd-stable/2010-** >>>>>>>> September/thread.html#58708 >>>>>>>> >>>>>>>> And was mentioned again by Scott here, which also contains some >>>>>>>> technical details: >>>>>>>> >>>>>>>> http://lists.freebsd.org/**pipermail/freebsd-stable/2011-** >>>>>>>> July/063172.html >>>>>>>> >>>>>>>> What's interesting is that Scott's issue is identical in form but h= e's >>>>>>>> using em(4), which isn't known to behave like this. Both individua= ls >>>>>>>> are using VirtualBox, though we're not sure at this point if that i= s >>>>>>>> the >>>>>>>> piece which is causing the anomaly. >>>>>>>> >>>>>>>> Relevant details of Scott's system (em-based): >>>>>>>> >>>>>>>> http://www.cap-press.com/misc/ >>>>>>>> >>>>>>>> Relevant details of Peter's system (bce-based): >>>>>>>> >>>>>>>> http://lists.freebsd.org/**pipermail/freebsd-stable/2011-** >>>>>>>> July/063221.html >>>>>>>> http://lists.freebsd.org/**pipermail/freebsd-stable/2011-** >>>>>>>> July/063223.html >>>>>>>> >>>>>>>> I think the biggest complexity right now is figuring out how/why sc= p >>>>>>>> fails intermittently in this nature. The errno probably "trickles >>>>>>>> down" >>>>>>>> to userland from the kernel, but the condition regarding why it >>>>>>>> happens >>>>>>>> is unknown. >>>>>>>> >>>>>>> >>>>>>> BTW: I also saw 2 of the errors coming from a BIND9 running in a >>>>>>> jail on that box. >>>>>>> >>>>>>> DellT410one# fgrep -i allocate /jails/bind/20110315/var/log/**messag= es >>>>>>> Apr 13 05:17:41 bind named[23534]: internal_send: >>>>>>> 192.168.50.145#65176: Cannot allocate memory >>>>>>> Jun 21 23:30:44 bind named[39864]: internal_send: >>>>>>> 192.168.50.251#36155: Cannot allocate memory >>>>>>> Jun 24 15:28:00 bind named[39864]: internal_send: >>>>>>> 192.168.50.251#28651: Cannot allocate memory >>>>>>> Jun 28 12:57:52 bind named[2462]: internal_send: >>>>>>> 192.168.165.154#1201: Cannot allocate memory >>>>>>> >>>>>>> My initial guess: it happens sooner or later somehow - whether it is >>>>>>> a lot of traffic in one go (ssh/scp copies of virtual disks) or a >>>>>>> lot of traffic over a longer period (a nameserver gets asked again >>>>>>> and again). >>>>>>> >>>>>> >>>>>> Scott, are you also using jails? If both of you are: is there any >>>>>> possibility you can remove use of those? I'm not sure how VirtualBox >>>>>> fits into the picture (jails + VirtualBox that is), but I can imagine >>>>>> jails having different environmental constraints that might cause thi= s. >>>>>> >>>>>> Basically the troubleshooting process here is to remove pieces of the >>>>>> puzzle until you figure out which piece is causing the issue. I don'= t >>>>>> want to get the NIC driver devs all spun up for something that, for >>>>>> example, might be an issue with the jail implementation. >>>>>> >>>>> >>>>> I understand this. As said, I do some afterhours debugging tonight. >>>>> >>>>> The scp/ssh problems are happening _outside_ the jails. The bind runs >>>>> _inside_ the jail. >>>>> >>>>> I wanted to use the _host_ system to send VirtualBox virtual disks and >>>>> filesystems used by jails to archive them and/or having them available= on >>>>> other FreeBSD systems (as a cold standby solution). >>>>> >>>> >>>> I just switched off the VirtualBox (without removing the kernel modules= ). >>>> >>>> The copy succeeds now. >>>> >>>> Well, it could be a VirtualBox related problem, or is the server just >>>> relieved to have 2GB more memory at hands now? >>>> >>>> Do you have a quick idea to "emulate" the 2GB memory load usually >>>> delivered by VirtualBox? >>>> >>> >>> Well, managed that (using lookbusy) >>> >>> Interestingly I could copy a large file (30GB) without problems, as soon= as >>> I switched off the VirtualBox. As said, the kernel modules weren't =20 >>> unloaded, >>> they are still there. >>> >>> The copy crashes seconds after I started the VirtualBox. According to >>> vmstat and top I had more free memory (ca. 1.5GB) as I had without >>> VirtualBox and lookbusy (ca. 350MB). >>> >>> So, it looks (to me, at least) as I have a VirtualBox related problem, >>> somehow. >>> >>> Any ideas? I am happy to play a bit more to get it sorted although it ha= s >>> some limits (it is running the company mailserver, after all) >>> >>> Regards >>> Peter >>> >> >> This is it -- I'm seeing the exact same thing. >> >> Scp dies reliably with VirtualBox running. Quit VirtualBox and I was able= to >> scp about 30 large files with no errors. Once I started VirtualBox an >> in-progress scp died within seconds. >> >> Ditto that the Kernel modules merely being loaded don't seem to make a >> difference, it's VirtualBox actually running. >> >> virtualbox-ose-3.2.12_1 > > Hi, > > I wonder whether anyone has new ideas. > > I am puzzled that it happens when VirtualBoxes are running, while =20 > the load or unload of the VirtualBox kernel modules doesn't seem to =20 > have an effect. > > Should I describe the case at the -emulation mailing list to get =20 > some ideas from the engineers working on VirtualBox? I finally did that, and, especially thanks to Adam Vande More, have a soluti= on http://lists.freebsd.org/pipermail/freebsd-emulation/2011-July/008977.html I put net.graph.maxdata=3D65536 in my /boot/loader.conf. Before I could see that the write error increased the "NetGraph data =20 items" failures (seen via vmstat -z). In one way it makes sense that the _start_ of the VirtualBox makes the difference. It is a busy company mailserver with SMTP and HTTP access and a lot of traffic going through - it all has to go through the netgraph system. Is this assumption false/true? Is the tuning a fix or just a =20 workaround? Should it be noted somewhere, e.g. as a package message =20 when installing VirtualBox? I am not the only one bitten by it, and I would like to avoid =20 disappointment for others in the future, or just remarks as "FreeBSD =20 virtualization sucks" based on this problem. (E.g. Marlon was running =20 out of time and had to head down the Citrix path). Regards Peter From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 00:38:36 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 717171065670 for ; Wed, 20 Jul 2011 00:38:36 +0000 (UTC) (envelope-from callumgibson@optusnet.com.au) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id E565E8FC0C for ; Wed, 20 Jul 2011 00:38:35 +0000 (UTC) Received: from omma.gibson.athome (c122-106-15-156.rivrw1.nsw.optusnet.com.au [122.106.15.156]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with SMTP id p6K0cUiI020244 for ; Wed, 20 Jul 2011 10:38:31 +1000 Received: (qmail 74874 invoked by uid 107); 20 Jul 2011 10:38:30 +1000 Date: 20 Jul 2011 10:38:30 +1000 Date: Wed, 20 Jul 2011 10:38:30 +1000 From: Callum Gibson To: Jung-uk Kim Message-ID: <20110720003830.GA68380@omma.gibson.athome> References: <20110719112033.GA51765@omma.gibson.athome> <201107191204.53865.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107191204.53865.jkim@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: powernow regression in 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 00:38:36 -0000 On 19Jul11 12:04, Jung-uk Kim wrote: }On Tuesday 19 July 2011 07:20 am, Callum Gibson wrote: }> I've just noticed and tracked down a regression in }> x86/cpufreq/powernow.c (on amd64) which was first mentioned here: }> }> http://lists.freebsd.org/pipermail/freebsd-current/2011-March/02350 }>9.html }> }> although no followup seems to have occurred. }> }> Symptoms are that powerd stops working because the dev.cpu.0.freq }> OID is no longer gettable nor settable. }[snip] } }HP again... Can you please show me verbose boot messages? I've put them in http://members.optusnet.com.au/callumgibson/verboseboot.out for you. This is a boot (and shutdown) of the kernel which exhibits the problem (hence kernel.old in output). (On the plus side, this HP laptop now suspends and resumes properly after 5 years. Not sure when that started happening.) regards, Callum -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 01:46:27 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3728106564A for ; Wed, 20 Jul 2011 01:46:27 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 6C0868FC13 for ; Wed, 20 Jul 2011 01:46:27 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id p6K1JGIr084816; Tue, 19 Jul 2011 19:19:16 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id p6K1JGSG084813; Tue, 19 Jul 2011 19:19:16 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Tue, 19 Jul 2011 19:19:16 -0600 (MDT) From: Warren Block To: Chuck Swiger In-Reply-To: Message-ID: References: <20110718234124.GA5626@icarus.home.lan> 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 IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 19 Jul 2011 19:19:16 -0600 (MDT) Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 01:46:27 -0000 On Tue, 19 Jul 2011, Chuck Swiger wrote: > Is there something in FreeBSD which is preventing you from using the > drive's native DEV_BSIZE of 4096 bytes, or is it that the drive claims > to have a physical block size of 512 bytes when it is really 4k? Are there any 4K-block drives that are honest about it, rather than reporting 512-byte blocks for backwards compatibility? From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 02:49:06 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03D5A106566C for ; Wed, 20 Jul 2011 02:49:06 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 9FB288FC08 for ; Wed, 20 Jul 2011 02:49:05 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p6K2n17r048249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Jul 2011 19:49:02 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p6K2mxW1048248; Tue, 19 Jul 2011 19:48:59 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA17752; Tue, 19 Jul 11 19:39:05 PDT Date: Wed, 20 Jul 2011 02:39:28 -0700 From: perryh@pluto.rain.com To: cswiger@mac.com Message-Id: <4e26a250.iKKzhkOLoTB3sdOr%perryh@pluto.rain.com> References: <20110718234124.GA5626@icarus.home.lan> <20110719211039.GA16085@server.vk2pj.dyndns.org> <02D367A5-CA74-4E8A-BE3E-F81485B287A7@mac.com> In-Reply-To: <02D367A5-CA74-4E8A-BE3E-F81485B287A7@mac.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, peterjeremy@acm.org Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 02:49:06 -0000 Chuck Swiger wrote: > On Jul 19, 2011, at 2:10 PM, Peter Jeremy wrote: > > On 2011-Jul-19 10:54:38 -0700, Chuck Swiger wrote: > >> Unix operating systems like SunOS 3 and NEXTSTEP would happily > >> run with a DEV_BSIZE of 1024 or larger-- they'd boot fine off > >> of optical media using 2048-byte sectors, > > > > Actually, Sun used customised CD-ROM drives that faked 512-byte > > sectors to work around their lack of support for anything else. > > Hmm-- my brain could be fuzzy about things twenty-plus years > ago. But I remember booting a Sun3_35 or _60 from a non-Sun > or Sun OEM'ed SCSI CD-ROM drive, probably a Plextor? IIRC, Plextor (and maybe some others) had a switch to select 512 or 2048 as the default transfer size, precisely so that they could be used as boot devices with systems that supported only 512. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 03:14:34 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF899106564A for ; Wed, 20 Jul 2011 03:14:34 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id A291B8FC08 for ; Wed, 20 Jul 2011 03:14:34 +0000 (UTC) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta12.emeryville.ca.mail.comcast.net with comcast id A3EU1h0041ZMdJ4AC3EXou; Wed, 20 Jul 2011 03:14:31 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta16.emeryville.ca.mail.comcast.net with comcast id A3DR1h02B1t3BNj8c3DSBG; Wed, 20 Jul 2011 03:13:26 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 03036102C36; Tue, 19 Jul 2011 20:14:32 -0700 (PDT) Date: Tue, 19 Jul 2011 20:14:31 -0700 From: Jeremy Chadwick To: perryh@pluto.rain.com Message-ID: <20110720031431.GA33758@icarus.home.lan> References: <20110718234124.GA5626@icarus.home.lan> <20110719211039.GA16085@server.vk2pj.dyndns.org> <02D367A5-CA74-4E8A-BE3E-F81485B287A7@mac.com> <4e26a250.iKKzhkOLoTB3sdOr%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4e26a250.iKKzhkOLoTB3sdOr%perryh@pluto.rain.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org, peterjeremy@acm.org Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 03:14:34 -0000 On Wed, Jul 20, 2011 at 02:39:28AM -0700, perryh@pluto.rain.com wrote: > Chuck Swiger wrote: > > On Jul 19, 2011, at 2:10 PM, Peter Jeremy wrote: > > > On 2011-Jul-19 10:54:38 -0700, Chuck Swiger wrote: > > >> Unix operating systems like SunOS 3 and NEXTSTEP would happily > > >> run with a DEV_BSIZE of 1024 or larger-- they'd boot fine off > > >> of optical media using 2048-byte sectors, > > > > > > Actually, Sun used customised CD-ROM drives that faked 512-byte > > > sectors to work around their lack of support for anything else. > > > > Hmm-- my brain could be fuzzy about things twenty-plus years > > ago. But I remember booting a Sun3_35 or _60 from a non-Sun > > or Sun OEM'ed SCSI CD-ROM drive, probably a Plextor? > > IIRC, Plextor (and maybe some others) had a switch to select 512 or > 2048 as the default transfer size, precisely so that they could be > used as boot devices with systems that supported only 512. I don't think Plextor was around back then; they used to be called TEXEL back in the early 90s. The only Sun SCSI CD drives I saw were external and caddy-based, so I mentally correlate them with NEC. Back then I wasn't looking at brands as much as I do today, though. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 03:49:12 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF2A61065670 for ; Wed, 20 Jul 2011 03:49:12 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by mx1.freebsd.org (Postfix) with ESMTP id A682C8FC13 for ; Wed, 20 Jul 2011 03:49:12 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.21.177] by asmtp020.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LOM0085259IAU50@asmtp020.mac.com> for freebsd-stable@freebsd.org; Tue, 19 Jul 2011 20:48:57 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-07-20_01:2011-07-19, 2011-07-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107190259 From: Chuck Swiger In-reply-to: <20110720031431.GA33758@icarus.home.lan> Date: Tue, 19 Jul 2011 20:48:54 -0700 Message-id: <84CC369B-4E70-414C-8C57-5FE772C7134F@mac.com> References: <20110718234124.GA5626@icarus.home.lan> <20110719211039.GA16085@server.vk2pj.dyndns.org> <02D367A5-CA74-4E8A-BE3E-F81485B287A7@mac.com> <4e26a250.iKKzhkOLoTB3sdOr%perryh@pluto.rain.com> <20110720031431.GA33758@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1084) Cc: freebsd-stable@freebsd.org, perryh@pluto.rain.com, peterjeremy@acm.org Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 03:49:12 -0000 On Jul 19, 2011, at 8:14 PM, Jeremy Chadwick wrote: > On Wed, Jul 20, 2011 at 02:39:28AM -0700, perryh@pluto.rain.com wrote: >> IIRC, Plextor (and maybe some others) had a switch to select 512 or >> 2048 as the default transfer size, precisely so that they could be >> used as boot devices with systems that supported only 512. Come to think of it, I do remember that switch, yes. Do you happen to know whether this limitation was part of the Sun hardware, or of SunOS? CMU had a lot of Sun3 machines and NeXT clusters, so I ended up mixing NeXT CD-ROM and the Canon? magneto-optical drives with Sun H/W, and vice versa. SunOS wasn't the only O/S which was run on a m68k Sun box. ;-) > I don't think Plextor was around back then; they used to be called TEXEL > back in the early 90s. The only Sun SCSI CD drives I saw were external > and caddy-based, so I mentally correlate them with NEC. Back then I > wasn't looking at brands as much as I do today, though. I'm pretty sure some folks had NEC caddy drives as well. Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 08:22:06 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3225E106566B for ; Wed, 20 Jul 2011 08:22:06 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 0B8568FC08 for ; Wed, 20 Jul 2011 08:22:06 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p6K8M2LG089396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jul 2011 01:22:03 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p6K8M2aF089395; Wed, 20 Jul 2011 01:22:02 -0700 (PDT) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA18536; Wed, 20 Jul 11 01:01:44 PDT Date: Wed, 20 Jul 2011 08:02:07 -0700 From: perryh@pluto.rain.com To: cswiger@mac.com, freebsd@jdc.parodius.com Message-Id: <4e26edef.9op324NPX/MVOW1Y%perryh@pluto.rain.com> References: <20110718234124.GA5626@icarus.home.lan> <20110719211039.GA16085@server.vk2pj.dyndns.org> <02D367A5-CA74-4E8A-BE3E-F81485B287A7@mac.com> <4e26a250.iKKzhkOLoTB3sdOr%perryh@pluto.rain.com> <20110720031431.GA33758@icarus.home.lan> <84CC369B-4E70-414C-8C57-5FE772C7134F@mac.com> In-Reply-To: <84CC369B-4E70-414C-8C57-5FE772C7134F@mac.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, peterjeremy@acm.org Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 08:22:06 -0000 Jeremy Chadwick wrote: > On Wed, Jul 20, 2011 at 02:39:28AM -0700, perryh@pluto.rain.com wrote: > > IIRC, Plextor (and maybe some others) had a switch to select 512 or > > 2048 as the default transfer size, precisely so that they could be > > used as boot devices with systems that supported only 512. > > I don't think Plextor was around back then; they used to be called > TEXEL back in the early 90s. The only Sun SCSI CD drives I saw > were external and caddy-based, so I mentally correlate them with > NEC. Back then I wasn't looking at brands as much as I do today, > though. I still have a non-Sun 512-2048 drive; turns out it is a (caddy- based) Hitachi CDR-1750S rather than a Plextor. So much for remembering all the details from late in the Sun-3 era. (Plextor still rings a bell WRT the 512-2048 switch though; maybe some of the early Plextor drives also provided one.) Chuck Swiger wrote: > Come to think of it, I do remember that switch, yes. > > Do you happen to know whether this limitation was part of the Sun > hardware, or of SunOS? CMU had a lot of Sun3 machines and NeXT > clusters, so I ended up mixing NeXT CD-ROM and the Canon? magneto- > optical drives with Sun H/W, and vice versa. Dunno if there were any hardware limitations, but most Sun-3 _bootroms_ predated CDROM support and thus could boot from a CD only by being fooled into believing it was a normal MFM or ESDI hard drive connected via an Adaptec ACB-4000 (SCSI-MFM) or Emulex MD21 (SCSI-ESDI) bridge controller. Remember those? This only worked if the CD drive's transfer size matched the expected hard drive sector size. I think the SunOS sr driver took the path of least resistance and issued an explicit "set transfer size 512" before trying to access the drive, thus enabling off-brand CD drives to work with the OS without running into any limitations that might have existed in either the hardware or the lower-level SCSI drivers, but that only worked after the OS had been booted :) > SunOS wasn't the only O/S which was run on a m68k Sun box. ;-) I'm aware of a NetBSD port that may still exist even today. Others? From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 10:06:46 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 470D2106566B for ; Wed, 20 Jul 2011 10:06:46 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm7.bullet.mail.ne1.yahoo.com (nm7.bullet.mail.ne1.yahoo.com [98.138.90.70]) by mx1.freebsd.org (Postfix) with SMTP id E2A138FC08 for ; Wed, 20 Jul 2011 10:06:45 +0000 (UTC) Received: from [98.138.90.49] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 20 Jul 2011 09:54:08 -0000 Received: from [98.138.226.59] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 20 Jul 2011 09:54:08 -0000 Received: from [127.0.0.1] by smtp210.mail.ne1.yahoo.com with NNFMP; 20 Jul 2011 09:54:08 -0000 X-Yahoo-Newman-Id: 56332.57601.bm@smtp210.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: fQWmwNUVM1kmvi.jyFckTxIX6hDTCrrrrjNsFJgg0_I8IbV KBAYqbWtQXeoxDxtotKg6FiOclr3NHU9boOqHMqS1p5r8qSIzhAYFz8ITdef rOAtDpZRkUuApgc2BJkAaY72xeAj6FgCnKf_WsGQIPAH6XQs3aewU1Wg6WoH XQIV_XFJ00SJLvEdW_g5c2BTTyyT2TlRHqsYq0hX425FSMOTPaPgeMOd3Rss LJHiBUQWTFm5240G7vU85Y1gq1c30gJ6evZt8AZTD5.R7izG6teXWDaa4Cjo BawwL8g87cQ6_tA6ecCV2qbBVMgUzAXwduW8H1TvCpdp6Ao_BofANQoMN8Fg z.AlCQ7QHrsS4h5aES8wibLjltg-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.151.77 with plain) by smtp210.mail.ne1.yahoo.com with SMTP; 20 Jul 2011 02:54:07 -0700 PDT Message-ID: <4E26A5BE.4000909@freebsd.org> Date: Wed, 20 Jul 2011 11:54:06 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181714.07827.jhb@freebsd.org> <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> <201107190931.36492.jhb@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 10:06:46 -0000 Am 19.07.2011 20:17, schrieb Artem Belevich: > On Tue, Jul 19, 2011 at 6:31 AM, John Baldwin wrote: >> The only reason it might be nice to stick with two fields is due to the line >> length (though the first line is over 80 cols even in the current format). Here >> are two possible suggestions: >> >> old: >> >> hostb0@pci0:0:0:0: class=0x060000 card=0x20108086 chip=0x01008086 rev=0x09 hdr=0x00 >> pcib1@pci0:0:1:0: class=0x060400 card=0x20108086 chip=0x01018086 rev=0x09 hdr=0x01 >> pcib2@pci0:0:1:1: class=0x060400 card=0x20108086 chip=0x01058086 rev=0x09 hdr=0x01 >> none0@pci0:0:22:0: class=0x078000 card=0x47428086 chip=0x1c3a8086 rev=0x04 hdr=0x00 >> em0@pci0:0:25:0: class=0x020000 card=0x00008086 chip=0x15038086 rev=0x04 hdr=0x00 >> ... >> >> A) >> >> hostb0@pci0:0:0:0: class=0x060000 vendor=0x8086 device=0x0100 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x00 >> pcib1@pci0:0:1:0: class=0x060400 vendor=0x8086 device=0x0101 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x01 >> pcib2@pci0:0:1:1: class=0x060400 vendor=0x8086 device=0x0105 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x01 >> none0@pci0:0:22:0: class=0x078000 vendor=0x8086 device=0x1c3a subvendor=0x8086 subdevice=0x4742 rev=0x04 hdr=0x00 >> em0@pci0:0:25:0: class=0x020000 vendor=0x8086 device=0x1503 subvendor=0x8086 subdevice=0x0000 rev=0x04 hdr=0x00 >> ... >> >> B) >> >> hostb0@pci0:0:0:0: class=0x060000 devid=0x8086:0100 subid=0x8086:2010 rev=0x09 hdr=0x00 >> pcib1@pci0:0:1:0: class=0x060400 devid=0x8086:0101 subid=0x8086:2010 rev=0x09 hdr=0x01 >> pcib2@pci0:0:1:1: class=0x060400 devid=0x8086:0105 subid=0x8086:2010 rev=0x09 hdr=0x01 >> none0@pci0:0:22:0: class=0x078000 devid=0x8086:1c3a subid=0x8086:4742 rev=0x04 hdr=0x00 >> em0@pci0:0:25:0: class=0x020000 devid=0x8086:1503 subid=0x8086:0000 rev=0x04 hdr=0x00 >> ... >> >> I went with vendor word first for both A) and B) as in my experience that is >> the more common ordering in driver tables, etc. > > Do we need to print (class|devid|device|subvendor|etc.)= on every > line? IMHO they belong to a header line. Something like this: > > Driver Handle Class Vnd:Dev Sub Vnd:Dev Rev Hdr > ------------------------------------------------------------------ > hostb0 pci0:0:0:0 0x060000 0x8086:0100 0x8086:2010 0x09 0x00 > pcib1 pci0:0:1:0 0x060400 0x8086:0101 0x8086:2010 0x09 0x01 > pcib2 pci0:0:1:1 0x060400 0x8086:0105 0x8086:2010 0x09 0x01 > none0 pci0:0:22:0 0x078000 0x8086:1c3a 0x8086:4742 0x04 0x00 > em0 pci0:0:25:0 0x020000 0x8086:1503 0x8086:0000 0x04 0x00 This is a very good idea, IMHO. When I committed pciconf back in 1996 (it had been contributed by gwollman) for PCI 1.0 (at a time when their was no standard for PCI to PCI brigdes, yet ;-) ), the current format seemed sensible, but the tabular form suggested by Artem is much better to parse. I'd want to suggest another slightly different format: Driver Handle Class Vnd Dev SubVnd SubDev Rev Hdr hostb0 0:0:0:0 0x060000 0x8086 0x0100 0x8086 0x2010 0x09 0x00 pcib1 0:0:1:0 0x060400 0x8086 0x0101 0x8086 0x2010 0x09 0x01 pcib2 0:0:1:1 0x060400 0x8086 0x0105 0x8086 0x2010 0x09 0x01 none0 0:0:22:0 0x078000 0x8086 0x1c3a 0x8086 0x4742 0x04 0x00 em0 0:0:25:0 0x020000 0x8086 0x1503 0x8086 0x0000 0x04 0x00 dummy0 65535:255:31:7 0x020000 0x8086 0x1503 0x8086 0x0000 0x04 0x00 I.e., print only one header line (no "---"), make the "Handle" column wide enough to hold the longest possible value, use only white space to separate columns and print 0x as a prefix for all hex numbers. Instead of "pci0:0:0:0" for the PCI handle, just "0:0:0:0" could be printed, IMHO. (But this is bikeshed material, I guess ...) The "Rev" column is required for of devices that are not uniquely identified by their Vnd/Dev-IDs. (These used to exist, e.g. the Symbios SCSI controllers, though I'm not aware of any device that needed a different driver depending on the PCI revision number.) I'd be happy to modify pciconf to print the new format in -CURRENT (having been the maintainer of the PCI code for quite some time), if consensus is reached on a format and if this change is accepted by RE. Regards, STefan From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 12:25:26 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70E57106564A; Wed, 20 Jul 2011 12:25:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id BA3808FC12; Wed, 20 Jul 2011 12:25:25 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p6KCPMJq025969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2011 15:25:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p6KCPM3b088553; Wed, 20 Jul 2011 15:25:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p6KCPLiL088552; Wed, 20 Jul 2011 15:25:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Jul 2011 15:25:21 +0300 From: Kostik Belousov To: Stefan Esser Message-ID: <20110720122521.GJ17489@deviant.kiev.zoral.com.ua> References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181714.07827.jhb@freebsd.org> <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> <201107190931.36492.jhb@freebsd.org> <4E26A5BE.4000909@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bina0ufSB9dLMnVr" Content-Disposition: inline In-Reply-To: <4E26A5BE.4000909@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 12:25:26 -0000 --Bina0ufSB9dLMnVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jul 20, 2011 at 11:54:06AM +0200, Stefan Esser wrote: > The "Rev" column is required for of devices that are not uniquely > identified by their Vnd/Dev-IDs. (These used to exist, e.g. the Symbios > SCSI controllers, though I'm not aware of any device that needed a > different driver depending on the PCI revision number.) Might be there is indeed no such device which require different driver due to revision, but there are definitely devices that require different workarounds in the driver based on revision. Seeing the revision in the output of pciconf very much helps to reduce the mail turnaround when analyzing user reports. --Bina0ufSB9dLMnVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4myTEACgkQC3+MBN1Mb4jx7gCg6bgT+K3jWV00mGgZ0MlXCyJT VxYAniX1SsUiXD9RxgJOhOb/y7EHN+tf =AALZ -----END PGP SIGNATURE----- --Bina0ufSB9dLMnVr-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 16:11:39 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94DCC106566B; Wed, 20 Jul 2011 16:11:39 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 37A418FC1A; Wed, 20 Jul 2011 16:11:38 +0000 (UTC) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id p6KGBY8b072629; Wed, 20 Jul 2011 10:11:35 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Scott Long In-Reply-To: <4E26A5BE.4000909@freebsd.org> Date: Wed, 20 Jul 2011 10:11:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2D778497-B02A-439B-8897-B484CCD799C8@samsco.org> References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181714.07827.jhb@freebsd.org> <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> <201107190931.36492.jhb@freebsd.org> <4E26A5BE.4000909@freebsd.org> To: Stefan Esser X-Mailer: Apple Mail (2.1084) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: freebsd-stable@FreeBSD.org Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 16:11:39 -0000 On Jul 20, 2011, at 3:54 AM, Stefan Esser wrote: >=20 > This is a very good idea, IMHO. >=20 > When I committed pciconf back in 1996 (it had been contributed by > gwollman) for PCI 1.0 (at a time when their was no standard for PCI to > PCI brigdes, yet ;-) ), the current format seemed sensible, but the > tabular form suggested by Artem is much better to parse. >=20 > I'd want to suggest another slightly different format: >=20 > Driver Handle Class Vnd Dev SubVnd SubDev Rev Hdr > hostb0 0:0:0:0 0x060000 0x8086 0x0100 0x8086 0x2010 0x09 0x00 > pcib1 0:0:1:0 0x060400 0x8086 0x0101 0x8086 0x2010 0x09 0x01 > pcib2 0:0:1:1 0x060400 0x8086 0x0105 0x8086 0x2010 0x09 0x01 > none0 0:0:22:0 0x078000 0x8086 0x1c3a 0x8086 0x4742 0x04 0x00 > em0 0:0:25:0 0x020000 0x8086 0x1503 0x8086 0x0000 0x04 0x00 > dummy0 65535:255:31:7 0x020000 0x8086 0x1503 0x8086 0x0000 0x04 0x00 >=20 > I.e., print only one header line (no "---"), make the "Handle" column > wide enough to hold the longest possible value, use only white space = to > separate columns and print 0x as a prefix for all hex numbers. >=20 > Instead of "pci0:0:0:0" for the PCI handle, just "0:0:0:0" could be > printed, IMHO. (But this is bikeshed material, I guess ...) >=20 > The "Rev" column is required for of devices that are not uniquely > identified by their Vnd/Dev-IDs. (These used to exist, e.g. the = Symbios > SCSI controllers, though I'm not aware of any device that needed a > different driver depending on the PCI revision number.) >=20 Actually, a few drivers (amr in particular) look at this rev field = during probe, though they should be looking at the subdev/ven ids = instead. I think that this behavior has actually caused recent = headaches for LSI with other drivers. But as Kostik points out, the rev = field is still moderately useful for informational purposes. > I'd be happy to modify pciconf to print the new format in -CURRENT > (having been the maintainer of the PCI code for quite some time), if > consensus is reached on a format and if this change is accepted by RE. >=20 I'm pretty sure that we scrape the current format at Yahoo and use it in = our tools. Implementing a switch of some sort to fall back to the old = format is something that will have to happen at some point, whether it's = done now or not. I'd probably implement it as an env variable such as = "PCICONF_COMPAT", similar to what is used by expr(1). Scott From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 16:26:23 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B215106564A; Wed, 20 Jul 2011 16:26:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id B2F438FC12; Wed, 20 Jul 2011 16:26:22 +0000 (UTC) Received: by iyb11 with SMTP id 11so463471iyb.13 for ; Wed, 20 Jul 2011 09:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=DKnPEOVR4QDVX8K7ZOCcT8pLg9zU57reyB4ebp2VgOE=; b=CN95F0VWIOlKin8IzIQbghIu3bC02701W865Mu4ymOGhi8n4rYD8cvW9iGu+ARxPM8 yxSO0qohMIW+K/RQ6ggGmAMOfzOR8GSy8XmdfFN+5AtWS3j0vqsmphTwjAbC15rcCkBH 3ktaTTqZMdB2CVHc6YHCM3TktnBAphlm5S2RE= Received: by 10.231.83.196 with SMTP id g4mr8236989ibl.54.1311179182140; Wed, 20 Jul 2011 09:26:22 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id v16sm250281ibf.42.2011.07.20.09.26.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 09:26:21 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 20 Jul 2011 09:25:18 -0700 From: YongHyeon PYUN Date: Wed, 20 Jul 2011 09:25:18 -0700 To: Stefan Esser Message-ID: <20110720162518.GA11521@michelle.cdnetworks.com> References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181714.07827.jhb@freebsd.org> <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> <201107190931.36492.jhb@freebsd.org> <4E26A5BE.4000909@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E26A5BE.4000909@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 16:26:23 -0000 On Wed, Jul 20, 2011 at 11:54:06AM +0200, Stefan Esser wrote: > Am 19.07.2011 20:17, schrieb Artem Belevich: > > On Tue, Jul 19, 2011 at 6:31 AM, John Baldwin wrote: > >> The only reason it might be nice to stick with two fields is due to the line > >> length (though the first line is over 80 cols even in the current format). Here > >> are two possible suggestions: > >> > >> old: > >> > >> hostb0@pci0:0:0:0: class=0x060000 card=0x20108086 chip=0x01008086 rev=0x09 hdr=0x00 > >> pcib1@pci0:0:1:0: class=0x060400 card=0x20108086 chip=0x01018086 rev=0x09 hdr=0x01 > >> pcib2@pci0:0:1:1: class=0x060400 card=0x20108086 chip=0x01058086 rev=0x09 hdr=0x01 > >> none0@pci0:0:22:0: class=0x078000 card=0x47428086 chip=0x1c3a8086 rev=0x04 hdr=0x00 > >> em0@pci0:0:25:0: class=0x020000 card=0x00008086 chip=0x15038086 rev=0x04 hdr=0x00 > >> ... > >> > >> A) > >> > >> hostb0@pci0:0:0:0: class=0x060000 vendor=0x8086 device=0x0100 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x00 > >> pcib1@pci0:0:1:0: class=0x060400 vendor=0x8086 device=0x0101 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x01 > >> pcib2@pci0:0:1:1: class=0x060400 vendor=0x8086 device=0x0105 subvendor=0x8086 subdevice=0x2010 rev=0x09 hdr=0x01 > >> none0@pci0:0:22:0: class=0x078000 vendor=0x8086 device=0x1c3a subvendor=0x8086 subdevice=0x4742 rev=0x04 hdr=0x00 > >> em0@pci0:0:25:0: class=0x020000 vendor=0x8086 device=0x1503 subvendor=0x8086 subdevice=0x0000 rev=0x04 hdr=0x00 > >> ... > >> > >> B) > >> > >> hostb0@pci0:0:0:0: class=0x060000 devid=0x8086:0100 subid=0x8086:2010 rev=0x09 hdr=0x00 > >> pcib1@pci0:0:1:0: class=0x060400 devid=0x8086:0101 subid=0x8086:2010 rev=0x09 hdr=0x01 > >> pcib2@pci0:0:1:1: class=0x060400 devid=0x8086:0105 subid=0x8086:2010 rev=0x09 hdr=0x01 > >> none0@pci0:0:22:0: class=0x078000 devid=0x8086:1c3a subid=0x8086:4742 rev=0x04 hdr=0x00 > >> em0@pci0:0:25:0: class=0x020000 devid=0x8086:1503 subid=0x8086:0000 rev=0x04 hdr=0x00 > >> ... > >> > >> I went with vendor word first for both A) and B) as in my experience that is > >> the more common ordering in driver tables, etc. > > > > Do we need to print (class|devid|device|subvendor|etc.)= on every > > line? IMHO they belong to a header line. Something like this: > > > > Driver Handle Class Vnd:Dev Sub Vnd:Dev Rev Hdr > > ------------------------------------------------------------------ > > hostb0 pci0:0:0:0 0x060000 0x8086:0100 0x8086:2010 0x09 0x00 > > pcib1 pci0:0:1:0 0x060400 0x8086:0101 0x8086:2010 0x09 0x01 > > pcib2 pci0:0:1:1 0x060400 0x8086:0105 0x8086:2010 0x09 0x01 > > none0 pci0:0:22:0 0x078000 0x8086:1c3a 0x8086:4742 0x04 0x00 > > em0 pci0:0:25:0 0x020000 0x8086:1503 0x8086:0000 0x04 0x00 > > This is a very good idea, IMHO. > > When I committed pciconf back in 1996 (it had been contributed by > gwollman) for PCI 1.0 (at a time when their was no standard for PCI to > PCI brigdes, yet ;-) ), the current format seemed sensible, but the > tabular form suggested by Artem is much better to parse. > > I'd want to suggest another slightly different format: > > Driver Handle Class Vnd Dev SubVnd SubDev Rev Hdr > hostb0 0:0:0:0 0x060000 0x8086 0x0100 0x8086 0x2010 0x09 0x00 > pcib1 0:0:1:0 0x060400 0x8086 0x0101 0x8086 0x2010 0x09 0x01 > pcib2 0:0:1:1 0x060400 0x8086 0x0105 0x8086 0x2010 0x09 0x01 > none0 0:0:22:0 0x078000 0x8086 0x1c3a 0x8086 0x4742 0x04 0x00 > em0 0:0:25:0 0x020000 0x8086 0x1503 0x8086 0x0000 0x04 0x00 > dummy0 65535:255:31:7 0x020000 0x8086 0x1503 0x8086 0x0000 0x04 0x00 > > I.e., print only one header line (no "---"), make the "Handle" column > wide enough to hold the longest possible value, use only white space to > separate columns and print 0x as a prefix for all hex numbers. > > Instead of "pci0:0:0:0" for the PCI handle, just "0:0:0:0" could be > printed, IMHO. (But this is bikeshed material, I guess ...) > > The "Rev" column is required for of devices that are not uniquely > identified by their Vnd/Dev-IDs. (These used to exist, e.g. the Symbios > SCSI controllers, though I'm not aware of any device that needed a > different driver depending on the PCI revision number.) > re(4) and rl(4) are one of example that needs the "Rev". > I'd be happy to modify pciconf to print the new format in -CURRENT > (having been the maintainer of the PCI code for quite some time), if > consensus is reached on a format and if this change is accepted by RE. > > Regards, STefan From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 18:45:06 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC816106564A for ; Wed, 20 Jul 2011 18:45:06 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm18.bullet.mail.bf1.yahoo.com (nm18.bullet.mail.bf1.yahoo.com [98.139.212.177]) by mx1.freebsd.org (Postfix) with SMTP id 80E628FC08 for ; Wed, 20 Jul 2011 18:45:06 +0000 (UTC) Received: from [98.139.212.153] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 20 Jul 2011 18:31:32 -0000 Received: from [98.139.211.203] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 20 Jul 2011 18:31:32 -0000 Received: from [127.0.0.1] by smtp212.mail.bf1.yahoo.com with NNFMP; 20 Jul 2011 18:31:32 -0000 X-Yahoo-Newman-Id: 484071.21266.bm@smtp212.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: _5eE9HgVM1kCOojTkqnObothbVR2fZZlRrZP4Qn46bUcNT2 SZWCTSoNgRE2gknmONIqX2fp.HeEe1HRMCVO5ElncmvpB5gA59m.t1EFYHLe eoKsUupx02EYrUvHMWArmxxIkUnBNLnVcXBc79OVfc_pIynp4wkq458tl4dQ usqnxpGSMENfiFHUTyJ1T2WRC_zMaPVv9CGTzSvBUI8rvw3YMaNu68dNsuVS IxkRWumE5YFgzbZWvdLLTeEJhXqzjMJ068oIECyezt9Aj3Gk7SyVC6zeKLh3 hz7fXTnYq8zpHg0NhnOQ9NvbzvJcsCpaZWAtPM4yMQextk2_MezA_6z_Q_6U 69nC9t6q9JDLPyZ_G826ixXi6_g-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.152.255 with plain) by smtp212.mail.bf1.yahoo.com with SMTP; 20 Jul 2011 11:31:30 -0700 PDT Message-ID: <4E271EFF.7060109@freebsd.org> Date: Wed, 20 Jul 2011 20:31:27 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Scott Long References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181714.07827.jhb@freebsd.org> <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> <201107190931.36492.jhb@freebsd.org> <4E26A5BE.4000909@freebsd.org> <2D778497-B02A-439B-8897-B484CCD799C8@samsco.org> In-Reply-To: <2D778497-B02A-439B-8897-B484CCD799C8@samsco.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 18:45:06 -0000 Am 20.07.2011 18:11, schrieb Scott Long: > On Jul 20, 2011, at 3:54 AM, Stefan Esser wrote: >> >> This is a very good idea, IMHO. >> >> When I committed pciconf back in 1996 (it had been contributed by >> gwollman) for PCI 1.0 (at a time when their was no standard for PCI to >> PCI brigdes, yet ;-) ), the current format seemed sensible, but the >> tabular form suggested by Artem is much better to parse. >> >> I'd want to suggest another slightly different format: >> >> Driver Handle Class Vnd Dev SubVnd SubDev Rev Hdr >> hostb0 0:0:0:0 0x060000 0x8086 0x0100 0x8086 0x2010 0x09 0x00 >> pcib1 0:0:1:0 0x060400 0x8086 0x0101 0x8086 0x2010 0x09 0x01 >> pcib2 0:0:1:1 0x060400 0x8086 0x0105 0x8086 0x2010 0x09 0x01 >> none0 0:0:22:0 0x078000 0x8086 0x1c3a 0x8086 0x4742 0x04 0x00 >> em0 0:0:25:0 0x020000 0x8086 0x1503 0x8086 0x0000 0x04 0x00 >> dummy0 65535:255:31:7 0x020000 0x8086 0x1503 0x8086 0x0000 0x04 0x00 >> >> I.e., print only one header line (no "---"), make the "Handle" column >> wide enough to hold the longest possible value, use only white space to >> separate columns and print 0x as a prefix for all hex numbers. >> >> Instead of "pci0:0:0:0" for the PCI handle, just "0:0:0:0" could be >> printed, IMHO. (But this is bikeshed material, I guess ...) >> >> The "Rev" column is required for of devices that are not uniquely >> identified by their Vnd/Dev-IDs. (These used to exist, e.g. the Symbios >> SCSI controllers, though I'm not aware of any device that needed a >> different driver depending on the PCI revision number.) > > Actually, a few drivers (amr in particular) look at this rev field during > probe, though they should be looking at the subdev/ven ids instead. > I think that this behavior has actually caused recent headaches for > LSI with other drivers. But as Kostik points out, the rev field is > still moderately useful for informational purposes. Dependency on the revision is bad, if it is a required criterion for the selection of a driver. This used to be the case for the Symbios 53c810 vs. 53c860 (where the latter could take advantage of the "sym" driver, while the prior lacked support of features originally required by the sym driver and only worked with "ncr"). The subvendor/subdevice ID is not well suited to select a driver in that case, since it was not used in general (PCI 1.0, on-board controllers) and even if it was used, the list of subvendor/subdevice tuples is hard to maintain if there are many vendors using a certain PCI(e) chip. >> I'd be happy to modify pciconf to print the new format in -CURRENT >> (having been the maintainer of the PCI code for quite some time), if >> consensus is reached on a format and if this change is accepted by RE. > > I'm pretty sure that we scrape the current format at Yahoo and use it > in our tools. Implementing a switch of some sort to fall back to the > old format is something that will have to happen at some point, > whether it's done now or not. I'd probably implement it as an env > variable such as "PCICONF_COMPAT", similar to what is used by expr(1). Hmm, then how about a new option (e.g. "-t" for tabular output, or "-L" for an alternate list format). For the current format, "-l" can be combined with "-b", "-c" and/or "-v" to print BARs, CAPs and/or decoded vendor and device information. The new tabular format suggested above does not mix well with these extended list options, and thus I think we should introduce a new list option that is incompatible with -b, -c and -v. The old option would produce unchanged output and thus there is no need for PCICONF_COMPAT. Regards, STefan From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 20:35:29 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 917EF106564A for ; Wed, 20 Jul 2011 20:35:29 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm2-vm4.bullet.mail.ne1.yahoo.com (nm2-vm4.bullet.mail.ne1.yahoo.com [98.138.91.162]) by mx1.freebsd.org (Postfix) with SMTP id 54C508FC0C for ; Wed, 20 Jul 2011 20:35:29 +0000 (UTC) Received: from [98.138.90.56] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 20 Jul 2011 20:35:28 -0000 Received: from [98.138.226.125] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 20 Jul 2011 20:35:28 -0000 Received: from [127.0.0.1] by smtp204.mail.ne1.yahoo.com with NNFMP; 20 Jul 2011 20:35:28 -0000 X-Yahoo-Newman-Id: 675009.16125.bm@smtp204.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: aRwKg0gVM1koDZx5WYNocnkbKXf_Ot43C5Twf5zEPy2gTQI MBCcIcwhQv8oT2kdnKMvMK326zreqV5wRdtrt_sn5EuECpfVsuyDT0yLuHKl wbPzvGlvYaPAQFF_fVGB.rCYZPzMHPWaWBpPy.HtApBkxd0Q.WlHRHWKoOrL GjzAtRK8pX1s4JJUdm_JSAWoKy0ZxbBj7i09yipXvm_AJCOGoVaHvAwsYSqk Jttg_EWu1j1KRBqGu7CtWV7evplc4VLpyN6GGV5IAFc2LtgP07HrI_ow6xH8 JwSeJ85pZ0o3ah43IReqK6QNVELhaa1LcaapfGsJR2iyfR0naEinaQKXwr8B nDdvkCjw73mK6.WrsiLck4JmpDA-- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.152.255 with plain) by smtp204.mail.ne1.yahoo.com with SMTP; 20 Jul 2011 13:35:28 -0700 PDT Message-ID: <4E273C09.8090505@freebsd.org> Date: Wed, 20 Jul 2011 22:35:21 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4E20BA23.13717.66C6F57@markmcconnell.iinet.com> <201107181714.07827.jhb@freebsd.org> <4F739848-E3CE-4E2C-A91E-90F33410E7AC@samsco.org> <201107190931.36492.jhb@freebsd.org> <4E26A5BE.4000909@freebsd.org> <20110720162518.GA11521@michelle.cdnetworks.com> In-Reply-To: <20110720162518.GA11521@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: disable 64-bit dma for one PCI slot only? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 20:35:29 -0000 On 20.07.2011 18:25, YongHyeon PYUN wrote: >> The "Rev" column is required for of devices that are not uniquely >> identified by their Vnd/Dev-IDs. (These used to exist, e.g. the Symbios >> SCSI controllers, though I'm not aware of any device that needed a >> different driver depending on the PCI revision number.) >> > > re(4) and rl(4) are one of example that needs the "Rev". Does the decision whether "re" or "rl" attaches the device depend on the revision field? This used to be the case for "ncr" and "sym", too, but one driver was extended to cover all devices supported by the other ... Anyway: I agree that the revision is significant information and should be kept in pciconf output. Regards, STefan From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 23:29:12 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id E90DD1065679; Wed, 20 Jul 2011 23:29:11 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Wed, 20 Jul 2011 19:28:34 -0400 User-Agent: KMail/1.6.2 References: <20110719112033.GA51765@omma.gibson.athome> In-Reply-To: <20110719112033.GA51765@omma.gibson.athome> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_1S2JOs5PZu1wWD6" Message-Id: <201107201928.54079.jkim@FreeBSD.org> Cc: Callum Gibson , freebsd-amd64@freebsd.org Subject: Re: powernow regression in 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 23:29:12 -0000 --Boundary-00=_1S2JOs5PZu1wWD6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 19 July 2011 07:20 am, Callum Gibson wrote: > Hi, > I've just noticed and tracked down a regression in > x86/cpufreq/powernow.c (on amd64) which was first mentioned here: > > http://lists.freebsd.org/pipermail/freebsd-current/2011-March/02350 >9.html > > although no followup seems to have occurred. The above thread is irrelevant. It was an Intel processor. > Symptoms are that powerd stops working because the dev.cpu.0.freq > OID is no longer gettable nor settable. > > This seems to have been caused by the following revision: > http://svnweb.freebsd.org/base?view=3Drevision&revision=3D222148 > which was in turn an MFC of r221102, so I guess the problem exists > on -current as well, although I can't confirm that since I don't > run it. > > Reverting the change fixes the problem and powerd will work again. > Also other utilities, such as xacpim, work properly. > > I'm running a ML-40 Turion laptop (HP Compaq nx6125). =46rom your dmesg output, I see that the processor speed was not=20 calibrated properly. ML-40's max. core freq. is 2,200 MHz according=20 to its specification but it was probed at 2,282 MHz, which is too=20 high. I think that's the problem. Can you please try the attached=20 patch? Jung-uk Kim --Boundary-00=_1S2JOs5PZu1wWD6 Content-Type: text/plain; charset="iso-8859-1"; name="kern_cpu.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kern_cpu.diff" Index: sys/kern/kern_cpu.c =================================================================== --- sys/kern/kern_cpu.c (revision 224231) +++ sys/kern/kern_cpu.c (working copy) @@ -159,16 +159,21 @@ cpufreq_attach(device_t dev) CF_MTX_INIT(&sc->lock); sc->curr_level.total_set.freq = CPUFREQ_VAL_UNKNOWN; SLIST_INIT(&sc->saved_freq); - /* Try to get nominal CPU freq to use it as maximum later if needed */ - sc->max_mhz = cpu_get_nominal_mhz(dev); - /* If that fails, try to measure the current rate */ - if (sc->max_mhz <= 0) { - pc = cpu_get_pcpu(dev); - if (cpu_est_clockrate(pc->pc_cpuid, &rate) == 0) - sc->max_mhz = rate / 1000000; - else - sc->max_mhz = CPUFREQ_VAL_UNKNOWN; + if (sc->max_mhz == CPUFREQ_VAL_UNKNOWN) { + /* Try to get nominal CPU freq to use it as maximum later. */ + sc->max_mhz = cpu_get_nominal_mhz(dev); + /* If that fails, try to measure the current rate */ + if (sc->max_mhz <= 0) { + pc = cpu_get_pcpu(dev); + if (cpu_est_clockrate(pc->pc_cpuid, &rate) == 0) + sc->max_mhz = rate / 1000000; + else + sc->max_mhz = CPUFREQ_VAL_UNKNOWN; + } } + if (sc->max_mhz == CPUFREQ_VAL_UNKNOWN) + CF_DEBUG("unknown max frequency for %s\n", + device_get_nameunit(dev)); /* * Only initialize one set of sysctls for all CPUs. In the future, @@ -1001,7 +1006,9 @@ int cpufreq_register(device_t dev) { struct cpufreq_softc *sc; + struct cf_setting *sets; device_t cf_dev, cpu_dev; + int error, max, set_count, type; /* Add a sysctl to get each driver's settings separately. */ SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev), @@ -1009,14 +1016,29 @@ cpufreq_register(device_t dev) OID_AUTO, "freq_settings", CTLTYPE_STRING | CTLFLAG_RD, dev, 0, cpufreq_settings_sysctl, "A", "CPU frequency driver settings"); + /* Get settings from the device and find maximum if possible. */ + max = CPUFREQ_VAL_UNKNOWN; + if (CPUFREQ_DRV_TYPE(dev, &type) == 0 && + (type & CPUFREQ_TYPE_MASK) == CPUFREQ_TYPE_ABSOLUTE) { + set_count = MAX_SETTINGS; + sets = malloc(set_count * sizeof(*sets), M_TEMP, M_NOWAIT); + if (sets != NULL) { + if (CPUFREQ_DRV_SETTINGS(dev, sets, &set_count) == 0 && + set_count > 0) + max = sets[0].freq; + free(sets, M_TEMP); + } + } + /* * Add only one cpufreq device to each CPU. Currently, all CPUs * must offer the same levels and be switched at the same time. */ cpu_dev = device_get_parent(dev); - if ((cf_dev = device_find_child(cpu_dev, "cpufreq", -1))) { + cf_dev = device_find_child(cpu_dev, "cpufreq", -1); + if (cf_dev != NULL) { sc = device_get_softc(cf_dev); - sc->max_mhz = CPUFREQ_VAL_UNKNOWN; + sc->max_mhz = max; return (0); } @@ -1025,8 +1047,12 @@ cpufreq_register(device_t dev) if (cf_dev == NULL) return (ENOMEM); device_quiet(cf_dev); - - return (device_probe_and_attach(cf_dev)); + error = device_probe(cf_dev); + if (error != 0) + return (error); + sc = device_get_softc(cf_dev); + sc->max_mhz = max; + return (device_attach(cf_dev)); } int --Boundary-00=_1S2JOs5PZu1wWD6-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 02:28:23 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84B221065670 for ; Thu, 21 Jul 2011 02:28:23 +0000 (UTC) (envelope-from callumgibson@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 08D608FC15 for ; Thu, 21 Jul 2011 02:28:22 +0000 (UTC) Received: from omma.gibson.athome (c122-106-15-156.rivrw1.nsw.optusnet.com.au [122.106.15.156]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with SMTP id p6L2SJ3a017000 for ; Thu, 21 Jul 2011 12:28:20 +1000 Received: (qmail 20173 invoked by uid 107); 21 Jul 2011 12:28:19 +1000 Date: 21 Jul 2011 12:28:19 +1000 Date: Thu, 21 Jul 2011 12:28:19 +1000 From: Callum Gibson To: Jung-uk Kim Message-ID: <20110721022818.GA17771@omma.gibson.athome> References: <20110719112033.GA51765@omma.gibson.athome> <201107201928.54079.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107201928.54079.jkim@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: powernow regression in 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 02:28:23 -0000 On 20Jul11 19:28, Jung-uk Kim wrote: }From your dmesg output, I see that the processor speed was not }calibrated properly. ML-40's max. core freq. is 2,200 MHz according }to its specification but it was probed at 2,282 MHz, which is too }high. I think that's the problem. Can you please try the attached }patch? Yes, I have seen core freq wobble around for most of the time I've owned it, but usually close to 2200. This morning (with my reverted powernow.c) I had: dev.cpu.0.freq_levels: 3080/35000 2800/29000 2520/24000 2240/20000 1120/9000 which I don't believe I've seen before. Anyway... With your new patch applied (and powernow.c changed back to r222148) I get exact freq levels: dev.cpu.0.freq_levels: 2200/35000 2000/29000 1800/24000 1600/20000 800/9000 However, dev.cpu.0.freq OID is still missing from sysctl output. As another data point, with your new patch applied, but the old powernow.c, (which I booted into mistakenly first time), I did have dev.cpu.0.freq, but the freq levels weren't exact. Here is a new verbose boot output with a cleaned and built kernel, 8-STABLE as at time=1311028656 and your patch applied: http://members.optusnet.com.au/callumgibson/verboseboot2.out regards, Callum -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 07:48:15 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAE0A106564A for ; Thu, 21 Jul 2011 07:48:15 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.205]) by mx1.freebsd.org (Postfix) with ESMTP id 861188FC13 for ; Thu, 21 Jul 2011 07:48:15 +0000 (UTC) Date: Thu, 21 Jul 2011 09:48:12 +0200 From: vermaden To: freebsd-stable@freebsd.org X-Mailer: interia.pl/pf09 In-Reply-To: References: <20110704091558.GA32271@icarus.home.lan> X-Originating-IP: 194.0.181.128 Message-Id: MIME-Version: 1.0 X-EMID: 89f8aa82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: 8.2-STABLE: /dev/da* device is not created after attaching digital camera SONY DSC-S60 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 07:48:15 -0000 Hi, like in the topic, the /dev/da* device is not created: % dmesg ugen7.3: at usbus7 umass0: on usbus7 umass0: RBC over CBI; quirks =3D 0x1000 umass0:4:0:-1: Attached to scbus4 % usbconfig ugen0.1: at usbus0, cfg=3D0 md=3DHOST spd=3DFULL (12M= bps) pwr=3DSAVE ugen1.1: at usbus1, cfg=3D0 md=3DHOST spd=3DFULL (12M= bps) pwr=3DSAVE ugen2.1: at usbus2, cfg=3D0 md=3DHOST spd=3DFULL (12M= bps) pwr=3DSAVE ugen3.1: at usbus3, cfg=3D0 md=3DHOST spd=3DHIGH (480= Mbps) pwr=3DSAVE ugen4.1: at usbus4, cfg=3D0 md=3DHOST spd=3DFULL (12M= bps) pwr=3DSAVE ugen5.1: at usbus5, cfg=3D0 md=3DHOST spd=3DFULL (12M= bps) pwr=3DSAVE ugen6.1: at usbus6, cfg=3D0 md=3DHOST spd=3DFULL (12M= bps) pwr=3DSAVE ugen7.1: at usbus7, cfg=3D0 md=3DHOST spd=3DHIGH (480= Mbps) pwr=3DSAVE ugen3.2: at usbus3, cfg=3D0 md=3DHOST spd=3D= HIGH (480Mbps) pwr=3DSAVE ugen7.2: at= usbus7, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON ugen3.3: at usbus3, cfg=3D0 md=3DHOST spd= =3DLOW (1.5Mbps) pwr=3DON ugen4.2: at usbus4, cfg=3D0 md=3DHOST spd=3DFULL (1= 2Mbps) pwr=3DON ugen3.4: at usbus3, cfg=3D0 md=3DHOST spd=3D= HIGH (480Mbps) pwr=3DSAVE ugen3.5: at usbus3, cfg=3D0 md=3DHOST= spd=3DFULL (12Mbps) pwr=3DON ugen3.6: at usbus3, cfg=3D0 md=3DHOST spd=3D= HIGH (480Mbps) pwr=3DSAVE ugen2.2: <5880 Broadcom Corp> at usbus2, cfg=3D0 md=3DHOST spd=3DFULL (12Mb= ps) pwr=3DON ugen3.7: at usbus3, cfg=3D0 md=3DHOST spd=3DFU= LL (12Mbps) pwr=3DSAVE ugen3.8: at usbus3, cfg=3D0 md=3DHOST spd=3DFULL (= 12Mbps) pwr=3DON ugen7.3: at usbus7, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) = pwr=3DON % uname -a FreeBSD e6400 8.2-STABLE FreeBSD 8.2-STABLE #0: Wed Jul 20 14:03:01 CEST 20= 11 root@e6400:/usr/obj/usr/src/sys/GENERIC amd64 The hardware is Dell Latitude E6400 if that helps. Regards and thanks in advance, vermaden ---------------------------------------------------------------- Najwieksza baza samochodow nowych i uzywanych Sprawdz >> http://linkint.pl/f29e3 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 13:02:52 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93B45106564A for ; Thu, 21 Jul 2011 13:02:52 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3AA318FC17 for ; Thu, 21 Jul 2011 13:02:52 +0000 (UTC) Received: from outgoing.leidinger.net (p4FC41B21.dip.t-dialin.net [79.196.27.33]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 711AC84400D; Thu, 21 Jul 2011 15:02:37 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTP id AD65429A1; Thu, 21 Jul 2011 15:02:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1311253354; bh=teUn4z4VYPERgYVVezEXIdc/CTixwKzJkszL02dAHTA=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=t7NmUNtdcxMnmxQFhUy9Q0H/zqg5tR/dnEkad92MNMEGE13G1Tjsi27RQELpUv+bN KXsz3zkAA8ozJKD4QwoCZHU3IhYCTC6k/7NyXfjTPoW8g7HOIy7MS0R8caG+DqJV8i kQycmAbVIpSe2GpoLJsWEurjRs/+sZZcKvtlmBCHINzqtroPBbXNzEpkkjoAlX0D5q pRhC9ugjlFY+RZfA0uiSSHGbfkmzEglTR01LsGkI0+0RX5cpNvD8YMtRwjkLlRa86x BrdeDciBd0j5JxHyJzTNgGIbZ7kw96n8VAoHGN19JyZ/TTbXDwcnHqfH3iHlPO2k5S 2g0MuxtDwVbmg== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.14.4/Submit) id p6LD2XH7015244; Thu, 21 Jul 2011 15:02:33 +0200 (CEST) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from p5DD4571B.dip.t-dialin.net (p5DD4571B.dip.t-dialin.net [93.212.87.27]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 21 Jul 2011 15:02:33 +0200 Message-ID: <20110721150233.765349kg5ed4p9bd@webmail.leidinger.net> Date: Thu, 21 Jul 2011 15:02:33 +0200 From: Alexander Leidinger To: Kevin Oberman References: <20110718234124.GA5626@icarus.home.lan> <20110719224126.00000a25@unknown> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 711AC84400D.AF7E0 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.023, required 6, autolearn=disabled, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, TW_ZF 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1311858159.29771@B20Qeh41GGfT8QGizyCQzQ X-EBL-Spam-Status: No Cc: "freebsd-stable@freebsd.org Stable" , Jeremy Chadwick Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 13:02:52 -0000 Quoting Kevin Oberman (from Tue, 19 Jul 2011 =20 14:33:27 -0700): > On Tue, Jul 19, 2011 at 1:41 PM, Alexander Leidinger > wrote: >> On Mon, 18 Jul 2011 16:41:24 -0700 Jeremy Chadwick >> wrote: >> >>> But the currently "known method" is to use gnop(8). =C2=A0Here's an >>> example: >>> >>> http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-opti= mized-for-4k-sector-drives/ >>> >>> Now, that's for ZFS, but I'm under the impression the exact same is >>> needed for FFS/UFS. >> >> Info: gnop will not work for FFS/UFS because gnop is a temporary >> solution (needs to be done by hand at each reboot). For FFS/UFS you >> need to align the slice/partition and chose a good blocksize/fragsize >> combination (e.g. 32k/4k). > Thanks, Alexander. > > This is what I had expected after reading the man pages, though I > would think -b 65560 -f 8192' would be a bit more reasonable in this > day of bloated file formats. it's been years since I have hit a > problem with lack of inodes. I suggest to test this somewhere first. I have no evidence that it can =20 not work, but the blocksize/fragsize settings where subject to some =20 unexpected results in the past when they where changed to a bad =20 combination. IIRC this should be fixed now, but my memory may cheat on =20 me... Bye, Alexander. --=20 The speed of anything depends on the flow of everything. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 14:51:07 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A74241065674 for ; Thu, 21 Jul 2011 14:51:07 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 64A9B8FC13 for ; Thu, 21 Jul 2011 14:51:07 +0000 (UTC) Received: by gxk28 with SMTP id 28so803860gxk.13 for ; Thu, 21 Jul 2011 07:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CQNhUrMwPBa64d1OlJ472ScY7Eg+qE3/2HhX4LXXGgs=; b=oZ1unclwbjjyw2K0OLzt7wRbHE6SKraP8zsAmhwg7X3KPhT5BxUxpvPTORVnqd3NVt pjWQNSmTEGW7+LAqGaSK0fK3ffkn9mCPpYVyDTdfuAOn3jweoMXky/tn8KOydoJlcXp8 Xy/peLyu6fQrBgvl1SdFpVRl+ZSjxbTSoSk2Y= MIME-Version: 1.0 Received: by 10.151.109.8 with SMTP id l8mr840655ybm.27.1311259866583; Thu, 21 Jul 2011 07:51:06 -0700 (PDT) Received: by 10.151.27.21 with HTTP; Thu, 21 Jul 2011 07:51:06 -0700 (PDT) In-Reply-To: <20110721150233.765349kg5ed4p9bd@webmail.leidinger.net> References: <20110718234124.GA5626@icarus.home.lan> <20110719224126.00000a25@unknown> <20110721150233.765349kg5ed4p9bd@webmail.leidinger.net> Date: Thu, 21 Jul 2011 07:51:06 -0700 Message-ID: From: Kevin Oberman To: Alexander Leidinger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-stable@freebsd.org Stable" , Jeremy Chadwick Subject: Re: Status of support for 4KB disk sectors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 14:51:07 -0000 On Thu, Jul 21, 2011 at 6:02 AM, Alexander Leidinger wrote: > Quoting Kevin Oberman (from Tue, 19 Jul 2011 14:33:27 > -0700): > >> On Tue, Jul 19, 2011 at 1:41 PM, Alexander Leidinger >> wrote: >>> >>> On Mon, 18 Jul 2011 16:41:24 -0700 Jeremy Chadwick >>> wrote: >>> >>>> But the currently "known method" is to use gnop(8). =A0Here's an >>>> example: >>>> >>>> >>>> http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-opt= imized-for-4k-sector-drives/ >>>> >>>> Now, that's for ZFS, but I'm under the impression the exact same is >>>> needed for FFS/UFS. >>> >>> Info: gnop will not work for FFS/UFS because gnop is a temporary >>> solution (needs to be done by hand at each reboot). For FFS/UFS you >>> need to align the slice/partition and chose a good blocksize/fragsize >>> combination (e.g. 32k/4k). > >> Thanks, Alexander. >> >> This is what I had expected after reading the man pages, though I >> would think -b 65560 -f 8192' would be a bit more reasonable in this >> day of bloated file formats. it's been years since I have hit a >> problem with lack of inodes. > > I suggest to test this somewhere first. I have no evidence that it can no= t > work, but the blocksize/fragsize settings where subject to some unexpecte= d > results in the past when they where changed to a bad combination. IIRC th= is > should be fixed now, but my memory may cheat on me... Alexander, Thanks for the advice. I would never try this on my system without a clone of the disk, especially with the limited experience I have with gpart and Lenovo's weird SYSTEM_DRV slice that seems to bite so many people. (Still can't find any good explanation of what it's about, but I do see a lot of incorrect ones.) --=20 R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 16:07:50 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id E4594106564A; Thu, 21 Jul 2011 16:07:49 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Thu, 21 Jul 2011 12:07:38 -0400 User-Agent: KMail/1.6.2 References: <20110719112033.GA51765@omma.gibson.athome> <201107201928.54079.jkim@FreeBSD.org> <20110721022818.GA17771@omma.gibson.athome> In-Reply-To: <20110721022818.GA17771@omma.gibson.athome> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107211207.41663.jkim@FreeBSD.org> Cc: Callum Gibson , freebsd-amd64@freebsd.org Subject: Re: powernow regression in 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 16:07:50 -0000 On Wednesday 20 July 2011 10:28 pm, Callum Gibson wrote: > On 20Jul11 19:28, Jung-uk Kim wrote: > }From your dmesg output, I see that the processor speed was not > }calibrated properly. ML-40's max. core freq. is 2,200 MHz > according }to its specification but it was probed at 2,282 MHz, > which is too }high. I think that's the problem. Can you please > try the attached }patch? > > Yes, I have seen core freq wobble around for most of the time I've > owned it, but usually close to 2200. This morning (with my reverted > powernow.c) I had: dev.cpu.0.freq_levels: 3080/35000 2800/29000 > 2520/24000 2240/20000 1120/9000 which I don't believe I've seen > before. Anyway... > > With your new patch applied (and powernow.c changed back to > r222148) I get exact freq levels: > > dev.cpu.0.freq_levels: 2200/35000 2000/29000 1800/24000 1600/20000 > 800/9000 That's better. :-) > However, dev.cpu.0.freq OID is still missing from sysctl output. > > As another data point, with your new patch applied, but the old > powernow.c, (which I booted into mistakenly first time), I did have > dev.cpu.0.freq, but the freq levels weren't exact. > > Here is a new verbose boot output with a cleaned and built kernel, > 8-STABLE as at time=1311028656 and your patch applied: > > http://members.optusnet.com.au/callumgibson/verboseboot2.out Can you please do "set debug.cpufreq.verbose=1" from loader prompt and show me the dmesg output? I want to see intial settings. You can reset it from command line with "sysctl debug.cpufreq.verbose=0" later. Thanks, Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 17:48:20 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8940C1065670; Thu, 21 Jul 2011 17:48:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5E9A38FC13; Thu, 21 Jul 2011 17:48:20 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 148D846B0A; Thu, 21 Jul 2011 13:48:20 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9D7A08A02E; Thu, 21 Jul 2011 13:48:19 -0400 (EDT) From: John Baldwin To: freebsd-amd64@freebsd.org Date: Thu, 21 Jul 2011 13:48:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <20110719112033.GA51765@omma.gibson.athome> <201107201928.54079.jkim@FreeBSD.org> <20110721022818.GA17771@omma.gibson.athome> In-Reply-To: <20110721022818.GA17771@omma.gibson.athome> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107211348.18954.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 21 Jul 2011 13:48:19 -0400 (EDT) Cc: Callum Gibson , freebsd-stable@freebsd.org, Jung-uk Kim Subject: Re: powernow regression in 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 17:48:20 -0000 On Wednesday, July 20, 2011 10:28:19 pm Callum Gibson wrote: > On 20Jul11 19:28, Jung-uk Kim wrote: > }From your dmesg output, I see that the processor speed was not > }calibrated properly. ML-40's max. core freq. is 2,200 MHz according > }to its specification but it was probed at 2,282 MHz, which is too > }high. I think that's the problem. Can you please try the attached > }patch? > > Yes, I have seen core freq wobble around for most of the time I've owned it, > but usually close to 2200. Possibly try disabling legacy USB in your BIOS as a test? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 20:56:03 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DC1C1065680 for ; Thu, 21 Jul 2011 20:56:03 +0000 (UTC) (envelope-from callumgibson@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id B42008FC28 for ; Thu, 21 Jul 2011 20:56:02 +0000 (UTC) Received: from omma.gibson.athome (c122-106-15-156.rivrw1.nsw.optusnet.com.au [122.106.15.156]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with SMTP id p6LKu0IU001419 for ; Fri, 22 Jul 2011 06:56:01 +1000 Received: (qmail 52729 invoked by uid 107); 22 Jul 2011 06:56:00 +1000 Date: 22 Jul 2011 06:56:00 +1000 Date: Fri, 22 Jul 2011 06:56:00 +1000 From: Callum Gibson To: Jung-uk Kim Message-ID: <20110721205600.GA52261@omma.gibson.athome> References: <20110719112033.GA51765@omma.gibson.athome> <201107201928.54079.jkim@FreeBSD.org> <20110721022818.GA17771@omma.gibson.athome> <201107211207.41663.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107211207.41663.jkim@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: powernow regression in 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 20:56:03 -0000 On 21Jul11 12:07, Jung-uk Kim wrote: }Can you please do "set debug.cpufreq.verbose=1" from loader prompt and }show me the dmesg output? I want to see intial settings. You can }reset it from command line with "sysctl debug.cpufreq.verbose=0" }later. http://members.optusnet.com.au/callumgibson/boot_verboser.out Also, as suggested by jhb@, with legacy usb disabled: http://members.optusnet.com.au/callumgibson/boot_verboser_nousb.out and dev.cpu.0.freq reappears! Spooky. Is that a solution or a workaround? I noticed this disables usb keyboard support at the boot menus. C -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 21:43:13 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17FCE106566B for ; Thu, 21 Jul 2011 21:43:13 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id F24548FC08 for ; Thu, 21 Jul 2011 21:43:12 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta03.emeryville.ca.mail.comcast.net with comcast id AksN1h0021zF43QA3ljAKp; Thu, 21 Jul 2011 21:43:10 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta24.emeryville.ca.mail.comcast.net with comcast id Alie1h0011t3BNj8kliegN; Thu, 21 Jul 2011 21:42:39 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B8CE4102C36; Thu, 21 Jul 2011 14:43:10 -0700 (PDT) Date: Thu, 21 Jul 2011 14:43:10 -0700 From: Jeremy Chadwick To: Callum Gibson Message-ID: <20110721214310.GA74656@icarus.home.lan> References: <20110719112033.GA51765@omma.gibson.athome> <201107201928.54079.jkim@FreeBSD.org> <20110721022818.GA17771@omma.gibson.athome> <201107211207.41663.jkim@FreeBSD.org> <20110721205600.GA52261@omma.gibson.athome> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110721205600.GA52261@omma.gibson.athome> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org, freebsd-amd64@FreeBSD.org, Jung-uk Kim Subject: Re: powernow regression in 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 21:43:13 -0000 On Fri, Jul 22, 2011 at 06:56:00AM +1000, Callum Gibson wrote: > On 21Jul11 12:07, Jung-uk Kim wrote: > }Can you please do "set debug.cpufreq.verbose=1" from loader prompt and > }show me the dmesg output? I want to see intial settings. You can > }reset it from command line with "sysctl debug.cpufreq.verbose=0" > }later. > > http://members.optusnet.com.au/callumgibson/boot_verboser.out > > Also, as suggested by jhb@, with legacy usb disabled: > http://members.optusnet.com.au/callumgibson/boot_verboser_nousb.out > and dev.cpu.0.freq reappears! Spooky. Is that a solution or a workaround? > I noticed this disables usb keyboard support at the boot menus. "Legacy USB" support is a horribly-named BIOS option. What the option actually does, without getting into the technicalities, is make your USB keyboard work inside of environments where there is no USB driver. The most commonly-used examples are bootloader/bootstraps and MS-DOS. The BIOS itself (meaning the firmware/BIOS, not "the BIOS as in a piece of legacy technology") has a tiny USB stack in it. That's how your USB keyboard is able to work (e.g. to press Del or F2 to get into the BIOS itself), and how you're able to boot from USB-attached devices. You should keep "Legacy USB" enabled if you want your keyboard to work in bootloaders/bootstraps. If enabling this feature breaks something else, that sounds like a bug in the vendor BIOS to me, and you should contact the vendor or motherboard manufacturer to inform them of the bug. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 21:53:56 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id B83A0106567B; Thu, 21 Jul 2011 21:53:55 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-amd64@FreeBSD.org Date: Thu, 21 Jul 2011 17:53:39 -0400 User-Agent: KMail/1.6.2 References: <20110719112033.GA51765@omma.gibson.athome> <201107211207.41663.jkim@FreeBSD.org> <20110721205600.GA52261@omma.gibson.athome> In-Reply-To: <20110721205600.GA52261@omma.gibson.athome> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_m/JKO1yz80K9iDR" Message-Id: <201107211753.42373.jkim@FreeBSD.org> Cc: Callum Gibson , freebsd-stable@freebsd.org Subject: Re: powernow regression in 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 21:53:56 -0000 --Boundary-00=_m/JKO1yz80K9iDR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thursday 21 July 2011 04:56 pm, Callum Gibson wrote: > On 21Jul11 12:07, Jung-uk Kim wrote: > }Can you please do "set debug.cpufreq.verbose=1" from loader prompt > and }show me the dmesg output? I want to see intial settings. You > can }reset it from command line with "sysctl > debug.cpufreq.verbose=0" }later. > > http://members.optusnet.com.au/callumgibson/boot_verboser.out > > Also, as suggested by jhb@, with legacy usb disabled: > http://members.optusnet.com.au/callumgibson/boot_verboser_nousb.out > and dev.cpu.0.freq reappears! Spooky. Is that a solution or a > workaround? I noticed this disables usb keyboard support at the > boot menus. It is a workaround. Please try the attached patch. Jung-uk Kim --Boundary-00=_m/JKO1yz80K9iDR Content-Type: text/plain; charset="iso-8859-1"; name="kern_cpu2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kern_cpu2.diff" Index: sys/kern/kern_cpu.c =================================================================== --- sys/kern/kern_cpu.c (revision 224245) +++ sys/kern/kern_cpu.c (working copy) @@ -157,17 +157,18 @@ cpufreq_attach(device_t dev) sysctl_ctx_init(&sc->sysctl_ctx); TAILQ_INIT(&sc->all_levels); CF_MTX_INIT(&sc->lock); - sc->curr_level.total_set.freq = CPUFREQ_VAL_UNKNOWN; SLIST_INIT(&sc->saved_freq); /* Try to get nominal CPU freq to use it as maximum later if needed */ - sc->max_mhz = cpu_get_nominal_mhz(dev); - /* If that fails, try to measure the current rate */ - if (sc->max_mhz <= 0) { - pc = cpu_get_pcpu(dev); - if (cpu_est_clockrate(pc->pc_cpuid, &rate) == 0) - sc->max_mhz = rate / 1000000; - else - sc->max_mhz = CPUFREQ_VAL_UNKNOWN; + if (sc->max_mhz == CPUFREQ_VAL_UNKNOWN) { + sc->max_mhz = cpu_get_nominal_mhz(dev); + /* If that fails, try to measure the current rate */ + if (sc->max_mhz <= 0) { + pc = cpu_get_pcpu(dev); + if (cpu_est_clockrate(pc->pc_cpuid, &rate) == 0) + sc->max_mhz = rate / 1000000; + else + sc->max_mhz = CPUFREQ_VAL_UNKNOWN; + } } /* @@ -1000,8 +1001,11 @@ out: int cpufreq_register(device_t dev) { + struct cf_setting set; + struct cf_setting *sets; struct cpufreq_softc *sc; device_t cf_dev, cpu_dev; + int error, freq, max, set_count, type; /* Add a sysctl to get each driver's settings separately. */ SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev), @@ -1009,14 +1013,34 @@ cpufreq_register(device_t dev) OID_AUTO, "freq_settings", CTLTYPE_STRING | CTLFLAG_RD, dev, 0, cpufreq_settings_sysctl, "A", "CPU frequency driver settings"); + /* Get settings from the device and find current and maximum frequencies */ + freq = max = CPUFREQ_VAL_UNKNOWN; + if (CPUFREQ_DRV_TYPE(dev, &type) == 0 && + (type & CPUFREQ_TYPE_MASK) == CPUFREQ_TYPE_ABSOLUTE) { + if (CPUFREQ_DRV_GET(dev, &set) == 0) + freq = set.freq; + set_count = MAX_SETTINGS; + sets = malloc(set_count * sizeof(*sets), M_TEMP, M_NOWAIT); + if (sets != NULL) { + if (CPUFREQ_DRV_SETTINGS(dev, sets, &set_count) == 0 && + set_count > 0) + max = sets[0].freq; + free(sets, M_TEMP); + } + } + /* * Add only one cpufreq device to each CPU. Currently, all CPUs * must offer the same levels and be switched at the same time. */ cpu_dev = device_get_parent(dev); - if ((cf_dev = device_find_child(cpu_dev, "cpufreq", -1))) { + cf_dev = device_find_child(cpu_dev, "cpufreq", -1); + if (cf_dev != NULL) { sc = device_get_softc(cf_dev); - sc->max_mhz = CPUFREQ_VAL_UNKNOWN; + if (sc->curr_level.total_set.freq == CPUFREQ_VAL_UNKNOWN) + sc->curr_level.total_set.freq = freq; + if (sc->max_mhz == CPUFREQ_VAL_UNKNOWN) + sc->max_mhz = max; return (0); } @@ -1025,8 +1049,13 @@ cpufreq_register(device_t dev) if (cf_dev == NULL) return (ENOMEM); device_quiet(cf_dev); - - return (device_probe_and_attach(cf_dev)); + error = device_probe(cf_dev); + if (error != 0) + return (error); + sc = device_get_softc(cf_dev); + sc->curr_level.total_set.freq = freq; + sc->max_mhz = max; + return (device_attach(cf_dev)); } int --Boundary-00=_m/JKO1yz80K9iDR-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 22:14:49 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAEE8106564A for ; Thu, 21 Jul 2011 22:14:49 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id C9D7A8FC0C for ; Thu, 21 Jul 2011 22:14:49 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 7C7F0B827 for ; Thu, 21 Jul 2011 14:56:17 -0700 (PDT) To: freebsd-stable@freebsd.org Date: Thu, 21 Jul 2011 14:56:17 -0700 From: Bakul Shah Message-Id: <20110721215617.7C7F0B827@mail.bitblocks.com> Subject: OS X Lion time machine => (afpd|iSCSI) => ZFS question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 22:14:49 -0000 I am in no hurry to upgrade my MBP to OS X Lion but given Lion time machine and netatalk issues, I got wondering if iSCSI on FreeBSD is stable enough for time machine use. How much duct tape and baling wire are needed to make it work?! Thanks. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 22:28:39 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 736A1106566C for ; Thu, 21 Jul 2011 22:28:39 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id 5B9D58FC08 for ; Thu, 21 Jul 2011 22:28:39 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp021.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LOP00HRPFQW8X50@asmtp021.mac.com> for freebsd-stable@freebsd.org; Thu, 21 Jul 2011 15:28:09 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-07-21_09:2011-07-21, 2011-07-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107210224 From: Chuck Swiger In-reply-to: <20110721215617.7C7F0B827@mail.bitblocks.com> Date: Thu, 21 Jul 2011 15:28:08 -0700 Message-id: References: <20110721215617.7C7F0B827@mail.bitblocks.com> To: Bakul Shah X-Mailer: Apple Mail (2.1084) Cc: freebsd-stable@freebsd.org Subject: Re: OS X Lion time machine => (afpd|iSCSI) => ZFS question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 22:28:39 -0000 On Jul 21, 2011, at 2:56 PM, Bakul Shah wrote: > I am in no hurry to upgrade my MBP to OS X Lion but given Lion > time machine and netatalk issues, Which issues? (And did you file a bug report? :-) > I got wondering if iSCSI on FreeBSD is stable enough for > time machine use. How much duct tape and baling wire are needed > to make it work?! There was a fine discussion about this here: http://freebsd.1045724.n5.nabble.com/ZFS-vs-OSX-Time-Machine-td4346562.html Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 22:40:46 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19FEE106564A for ; Thu, 21 Jul 2011 22:40:46 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id F07678FC08 for ; Thu, 21 Jul 2011 22:40:45 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 8A016B84F; Thu, 21 Jul 2011 15:40:45 -0700 (PDT) To: Chuck Swiger In-reply-to: Your message of "Thu, 21 Jul 2011 15:28:08 PDT." References: <20110721215617.7C7F0B827@mail.bitblocks.com> Comments: In-reply-to Chuck Swiger message dated "Thu, 21 Jul 2011 15:28:08 -0700." Date: Thu, 21 Jul 2011 15:40:45 -0700 From: Bakul Shah Message-Id: <20110721224045.8A016B84F@mail.bitblocks.com> Cc: Bakul Shah , freebsd-stable@freebsd.org Subject: Re: OS X Lion time machine => (afpd|iSCSI) => ZFS question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 22:40:46 -0000 On Thu, 21 Jul 2011 15:28:08 PDT Chuck Swiger wrote: > On Jul 21, 2011, at 2:56 PM, Bakul Shah wrote: > > I am in no hurry to upgrade my MBP to OS X Lion but given Lion > > time machine and netatalk issues, > > Which issues? (And did you file a bug report? :-) Google `os x lion netatalk time machine'! But briefly, a newer version of the appletalk protocol is used with lion time machine which is not supported by netatalk in the ports. netafp.com (I think that is the right name) has a new version but at least for now it is closed source (only their customers get it -- whether they are breaking the GPL or not is a discussion belongs elsehere). The version in sourceforge is not quite upto snuff from what I hear. > > I got wondering if iSCSI on FreeBSD is stable enough for > > time machine use. How much duct tape and baling wire are needed > > to make it work?! > > There was a fine discussion about this here: > > http://freebsd.1045724.n5.nabble.com/ZFS-vs-OSX-Time-Machine-td4346562.html Thanks. I think I saw it back then.... Nothing new since then? From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 23:17:32 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E0F21065670 for ; Thu, 21 Jul 2011 23:17:32 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id 848BA8FC0A for ; Thu, 21 Jul 2011 23:17:32 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com ([17.209.4.71]) by asmtp021.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LOP00J1MI08Y810@asmtp021.mac.com> for freebsd-stable@freebsd.org; Thu, 21 Jul 2011 16:16:57 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-07-21_09:2011-07-21, 2011-07-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1107210237 From: Chuck Swiger In-reply-to: <20110721224045.8A016B84F@mail.bitblocks.com> Date: Thu, 21 Jul 2011 16:16:56 -0700 Message-id: References: <20110721215617.7C7F0B827@mail.bitblocks.com> <20110721224045.8A016B84F@mail.bitblocks.com> To: Bakul Shah X-Mailer: Apple Mail (2.1084) Cc: freebsd-stable@freebsd.org Subject: Re: OS X Lion time machine => (afpd|iSCSI) => ZFS question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 23:17:32 -0000 On Jul 21, 2011, at 3:40 PM, Bakul Shah wrote: > On Thu, 21 Jul 2011 15:28:08 PDT Chuck Swiger wrote: >> On Jul 21, 2011, at 2:56 PM, Bakul Shah wrote: >>> I am in no hurry to upgrade my MBP to OS X Lion but given Lion >>> time machine and netatalk issues, >> >> Which issues? (And did you file a bug report? :-) > > Google `os x lion netatalk time machine'! With due respect for the search folks up the road in Mountain View, I asked which issues you'd had and whether you'd filed a bug report about them. > But briefly, a newer version of the appletalk protocol is used with lion time > machine which is not supported by netatalk in the ports. Ah, yes: anything below AFP 3.2 or direct block access is likely ENOTSUP. >>> I got wondering if iSCSI on FreeBSD is stable enough for >>> time machine use. How much duct tape and baling wire are needed >>> to make it work?! >> >> There was a fine discussion about this here: >> >> http://freebsd.1045724.n5.nabble.com/ZFS-vs-OSX-Time-Machine-td4346562.html > > Thanks. I think I saw it back then.... Nothing new since then? Aside from Lion, you mean? Well, FreeBSD seems to be making progress with ZFS and memory tuning; I'm not as familiar with work being done on iSCSI. Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 23:25:20 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0D8D1065674 for ; Thu, 21 Jul 2011 23:25:20 +0000 (UTC) (envelope-from sean@gothic.net.au) Received: from hosted.gothic.net.au (eth1539.vic.adsl.internode.on.net [150.101.217.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7DB8A8FC15 for ; Thu, 21 Jul 2011 23:25:20 +0000 (UTC) Received: from hosted.gothic.net.au (localhost [127.0.0.1]) by hosted.gothic.net.au (Postfix) with ESMTP id 8E13C8DF443; Fri, 22 Jul 2011 09:09:50 +1000 (EST) X-Virus-Scanned: amavisd-new at gothic.net.au Received: from hosted.gothic.net.au ([127.0.0.1]) by hosted.gothic.net.au (hosted.gothic.net.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbEjEJv4RyCa; Fri, 22 Jul 2011 09:09:44 +1000 (EST) Received: from queen.gothic.net.au (eth1540.vic.adsl.internode.on.net [150.101.217.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sean@gothic.net.au) by hosted.gothic.net.au (Postfix) with ESMTPSA id 5FD708DF44B; Fri, 22 Jul 2011 09:09:44 +1000 (EST) Date: Fri, 22 Jul 2011 09:09:43 +1000 (EST) From: Sean To: Bakul Shah In-Reply-To: <20110721224045.8A016B84F@mail.bitblocks.com> Message-ID: References: <20110721215617.7C7F0B827@mail.bitblocks.com> <20110721224045.8A016B84F@mail.bitblocks.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: OS X Lion time machine => (afpd|iSCSI) => ZFS question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 23:25:20 -0000 On Thu, 21 Jul 2011, Bakul Shah wrote: > On Thu, 21 Jul 2011 15:28:08 PDT Chuck Swiger wrote: >> On Jul 21, 2011, at 2:56 PM, Bakul Shah wrote: >>> I am in no hurry to upgrade my MBP to OS X Lion but given Lion >>> time machine and netatalk issues, >> >> Which issues? (And did you file a bug report? :-) > > Google `os x lion netatalk time machine'! But briefly, a newer > version of the appletalk protocol is used with lion time > machine which is not supported by netatalk in the ports. > netafp.com (I think that is the right name) has a new version > but at least for now it is closed source (only their customers > get it -- whether they are breaking the GPL or not is a > discussion belongs elsehere). The version in sourceforge is > not quite upto snuff from what I hear. The 2.2beta apparently supports AFP 3.3, but it's not in the ports tree yet. > >>> I got wondering if iSCSI on FreeBSD is stable enough for >>> time machine use. How much duct tape and baling wire are needed >>> to make it work?! >> >> There was a fine discussion about this here: >> >> http://freebsd.1045724.n5.nabble.com/ZFS-vs-OSX-Time-Machine-td4346562.html > > Thanks. I think I saw it back then.... Nothing new since then? > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 08:09:19 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 095A6106566C; Fri, 22 Jul 2011 08:09:18 +0000 (UTC) (envelope-from eugene@imedia.ru) Received: from lynx.imedia.ru (lynx.imedia.ru [83.242.167.254]) by mx1.freebsd.org (Postfix) with ESMTP id 3F62C8FC13; Fri, 22 Jul 2011 08:09:17 +0000 (UTC) X-All-Recipients: DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=imedia.ru; s=common; t=1311320899; bh=wx4G1KMQiLMqIiYaDAMKz4wsTLJzZyybV643/DYcEZ4=; h=From:Reply-To:To:Subject:Date:MIME-Version:Content-Type: Content-Transfer-Encoding:Message-Id; b=Ao4ZMms8vQad9cuGZ8hfBPzBSKwBve9VGrS6yQWx/FCspeLfpmO9oJ0upke5p020j OjQrXqcHRCKhxY43ngJYPMtw5nvEuhTLctQcOZajl1ney4qSLaqFI9HaPnu08fEAxT +eKGySaz+KzozRtpjYWypjwDyHpXTK2lyH7RUieo= Received: from badger.imedia.ru (root@badger.imedia.ru [10.167.1.243]) by lynx.imedia.ru (8.14.3/8.14.3/TWINS7_LDAP) with ESMTP id p6M7mJUF059930; Fri, 22 Jul 2011 11:48:19 +0400 (MSD) (envelope-from eugene@imedia.ru) Received: from badger.imedia.ru (localhost [127.0.0.1]) by badger.imedia.ru (8.14.4/8.14.4) with ESMTP id p6M7mIHC097180; Fri, 22 Jul 2011 11:48:18 +0400 (MSD) (envelope-from eugene@imedia.ru) Received: from localhost (localhost [[UNIX: localhost]]) by badger.imedia.ru (8.14.4/8.14.4/Submit) id p6M7mDZM097179; Fri, 22 Jul 2011 11:48:13 +0400 (MSD) (envelope-from eugene@imedia.ru) X-Authentication-Warning: badger.imedia.ru: eugene set sender to eugene@imedia.ru using -f From: Eugene Mitrofanov Organization: Sanoma Independent Media To: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Date: Fri, 22 Jul 2011 11:48:12 +0400 User-Agent: KMail/1.9.10 X-Origin: badger.imedia.ru MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201107221148.13100.eugene@imedia.ru> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (lynx.imedia.ru [10.167.0.252]); Fri, 22 Jul 2011 11:48:19 +0400 (MSD) X-Virus-Scanned: clamav-milter 0.97-exp at lynx.imedia.ru X-Virus-Status: Clean Cc: Subject: ZFS v28 and aclmode X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eugene Mitrofanov List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 08:09:19 -0000 Hi all, I just updated to 8.2S and zfs v28 and notice strange thing: in the manual i can read about aclmode but i can not use it in the real life: # zfs set aclmode=passthrough data/public cannot set property for 'data/public': invalid property 'aclmode' Obsolete manual? Good luck -- EMIT-RIPN, EVM7-RIPE From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 10:02:23 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A251106566B for ; Fri, 22 Jul 2011 10:02:23 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 4690D8FC0C for ; Fri, 22 Jul 2011 10:02:22 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QkCYn-0002TJ-VO for freebsd-stable@freebsd.org; Fri, 22 Jul 2011 12:02:21 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jul 2011 12:02:21 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jul 2011 12:02:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Fri, 22 Jul 2011 12:02:10 +0200 Lines: 7 Message-ID: References: <20110721215617.7C7F0B827@mail.bitblocks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <20110721215617.7C7F0B827@mail.bitblocks.com> X-Enigmail-Version: 1.1.2 Subject: Re: OS X Lion time machine => (afpd|iSCSI) => ZFS question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 10:02:23 -0000 On 21/07/2011 23:56, Bakul Shah wrote: > I got wondering if iSCSI on > FreeBSD is stable enough for time machine use. How much duct > tape and baling wire are needed to make it work?! iSCSI as in the target (server) function? net/istgt in ports seemed ok last time I tried it. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 10:08:42 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA562106566B; Fri, 22 Jul 2011 10:08:42 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (ingresso-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:176e::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9546F8FC16; Fri, 22 Jul 2011 10:08:42 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1QkCev-0003IG-Qv; Fri, 22 Jul 2011 11:08:41 +0100 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QkCev-0004uM-Q6; Fri, 22 Jul 2011 11:08:41 +0100 To: freebsd-stable@freebsd.org, ivoras@freebsd.org In-Reply-To: Message-Id: From: Pete French Date: Fri, 22 Jul 2011 11:08:41 +0100 Cc: Subject: Re: OS X Lion time machine => (afpd|iSCSI) => ZFS question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 10:08:42 -0000 > iSCSI as in the target (server) function? net/istgt in ports seemed ok > last time I tried it. Plus the older (and simpler) net/iscsi-target works fine. Quite some time agao I did spent a lot of time playing around with the initiator. My expereinces were that it works very nicely when connectivity works, but that a permanent loss of the far end oif the connection doesn't lead to a nice failure ... but then nether does ripping a SCSI drive off a bus, so I am not too fusssed about that in general! Re-establishing the connection fixes the problem. I got less good results layering other things (gmirror + zfs) on top of it though, but again it was the failire behaviour which lead me not to use it in the end, rather than the normal fucntionality, which works very well. -pete. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 11:13:08 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89FA3106566C for ; Fri, 22 Jul 2011 11:13:08 +0000 (UTC) (envelope-from callumgibson@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 0B7CB8FC21 for ; Fri, 22 Jul 2011 11:13:07 +0000 (UTC) Received: from omma.gibson.athome (c122-106-15-156.rivrw1.nsw.optusnet.com.au [122.106.15.156]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with SMTP id p6MBD5Uh005241 for ; Fri, 22 Jul 2011 21:13:06 +1000 Received: (qmail 77318 invoked by uid 107); 22 Jul 2011 21:13:05 +1000 Date: 22 Jul 2011 21:13:05 +1000 Date: Fri, 22 Jul 2011 21:13:05 +1000 From: Callum Gibson To: Jung-uk Kim Message-ID: <20110722111305.GB76391@omma.gibson.athome> References: <20110719112033.GA51765@omma.gibson.athome> <201107211207.41663.jkim@FreeBSD.org> <20110721205600.GA52261@omma.gibson.athome> <201107211753.42373.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107211753.42373.jkim@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: powernow regression in 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 11:13:08 -0000 On 21Jul11 17:53, Jung-uk Kim wrote: }> }> http://members.optusnet.com.au/callumgibson/boot_verboser_nousb.out }> and dev.cpu.0.freq reappears! Spooky. Is that a solution or a }> workaround? I noticed this disables usb keyboard support at the }> boot menus. } }It is a workaround. Please try the attached patch. Sorry, no improvement that I can see. See verbose output: http://members.optusnet.com.au/callumgibson/boot_verboser2.out C -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 12:16:54 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 424CC1065675; Fri, 22 Jul 2011 12:16:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 16CC58FC15; Fri, 22 Jul 2011 12:16:54 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id AB8F246B03; Fri, 22 Jul 2011 08:16:53 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 49DBC8A02C; Fri, 22 Jul 2011 08:16:53 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 22 Jul 2011 08:16:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <20110719112033.GA51765@omma.gibson.athome> <20110721205600.GA52261@omma.gibson.athome> <20110721214310.GA74656@icarus.home.lan> In-Reply-To: <20110721214310.GA74656@icarus.home.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107220816.52901.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 22 Jul 2011 08:16:53 -0400 (EDT) Cc: Attilio Rao , Jung-uk Kim , Callum Gibson , freebsd-amd64@freebsd.org, Jeremy Chadwick Subject: Re: powernow regression in 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 12:16:54 -0000 On Thursday, July 21, 2011 5:43:10 pm Jeremy Chadwick wrote: > On Fri, Jul 22, 2011 at 06:56:00AM +1000, Callum Gibson wrote: > > On 21Jul11 12:07, Jung-uk Kim wrote: > > }Can you please do "set debug.cpufreq.verbose=1" from loader prompt and > > }show me the dmesg output? I want to see intial settings. You can > > }reset it from command line with "sysctl debug.cpufreq.verbose=0" > > }later. > > > > http://members.optusnet.com.au/callumgibson/boot_verboser.out > > > > Also, as suggested by jhb@, with legacy usb disabled: > > http://members.optusnet.com.au/callumgibson/boot_verboser_nousb.out > > and dev.cpu.0.freq reappears! Spooky. Is that a solution or a workaround? > > I noticed this disables usb keyboard support at the boot menus. > > "Legacy USB" support is a horribly-named BIOS option. > > What the option actually does, without getting into the technicalities, > is make your USB keyboard work inside of environments where there is no > USB driver. The most commonly-used examples are bootloader/bootstraps > and MS-DOS. > > The BIOS itself (meaning the firmware/BIOS, not "the BIOS as in a piece > of legacy technology") has a tiny USB stack in it. That's how your > USB keyboard is able to work (e.g. to press Del or F2 to get into the > BIOS itself), and how you're able to boot from USB-attached devices. > > You should keep "Legacy USB" enabled if you want your keyboard to work > in bootloaders/bootstraps. If enabling this feature breaks something > else, that sounds like a bug in the vendor BIOS to me, and you should > contact the vendor or motherboard manufacturer to inform them of the > bug. It's a known issue that the Legacy USB option can break our TSC calibration code causing an inflated value of the TSC frequency. The issue is that the legacy USB code is often very dumb. It is implemented via polling in SMI#. It appears that each interrupt from the ISA timer triggers an SMI# that polls the USB bus looking for any keyboards and checking for any pending keyboard events) that it can then use to trigger simulated PS/2 keyboard actions. The problem is that we calibrate the TSC using this algorithm: - grab the TSC - spin on the ISA timer waiting for it to run for a second - grab the TSC The issue is that the SMI# fires at the same time we want to be execuiting step 3, and step 3 is deferred while the SMI# handler runs. As a result, the TSC delta ends up being "1 second + time of an SMI# to poll USB". We have a hack fix for this at work that originally came from Attilio Rao. This is a patch for it relative to 8. It disables interrupt generation for the ISA timer while we calibrate the TSC (which disables the SMI# temporarily): Index: x86/isa/clock.c =================================================================== --- x86/isa/clock.c (.../mirror/FreeBSD/stable/8/sys) (revision 224114) +++ x86/isa/clock.c (.../stable/8/sys) (revision 224114) @@ -119,7 +119,7 @@ static unsigned i8254_get_timecount(struct timecounter *tc); static unsigned i8254_simple_get_timecount(struct timecounter *tc); -static void set_i8254_freq(u_int freq, int intr_freq); +static void set_i8254_freq(u_int freq, int intr_freq, int freerun); static struct timecounter i8254_timecounter = { i8254_get_timecount, /* get_timecount */ @@ -447,15 +447,32 @@ #endif } +/* + * XXX: This is a gross hack to workaround USB legacy emulation. For + * some systems, the USB legacy emulation is implemented by a periodic + * SMI# triggered by the i8254. The resulting SMI# could cause the + * DELAY() to run too long resulting in the TSC being miscalibrated. + * The workaround is to disable i8254 interrupts while calibrating the + * TSC. + */ +void +DELAY_TSCCAL(int n) +{ + + set_i8254_freq(i8254_freq, hz, 1); + DELAY(n); + set_i8254_freq(i8254_freq, hz, 0); +} + static void -set_i8254_freq(u_int freq, int intr_freq) +set_i8254_freq(u_int freq, int intr_freq, int freerun) { int new_i8254_real_max_count; i8254_timecounter.tc_frequency = freq; mtx_lock_spin(&clock_lock); i8254_freq = freq; - if (using_lapic_timer != LAPIC_CLOCK_NONE) + if (using_lapic_timer != LAPIC_CLOCK_NONE || freerun) new_i8254_real_max_count = 0x10000; else new_i8254_real_max_count = TIMER_DIV(intr_freq); @@ -508,7 +525,7 @@ { mtx_init(&clock_lock, "clk", NULL, MTX_SPIN | MTX_NOPROFILE); - set_i8254_freq(i8254_freq, hz); + set_i8254_freq(i8254_freq, hz, 0); } void @@ -517,7 +534,7 @@ atrtc_start(); - set_i8254_freq(i8254_freq, hz); + set_i8254_freq(i8254_freq, hz, 0); tc_init(&i8254_timecounter); init_TSC(); @@ -565,7 +582,7 @@ i8254_timecounter.tc_get_timecount = i8254_simple_get_timecount; i8254_timecounter.tc_counter_mask = 0xffff; - set_i8254_freq(i8254_freq, hz); + set_i8254_freq(i8254_freq, hz, 0); } /* @@ -627,7 +644,7 @@ freq = i8254_freq; error = sysctl_handle_int(oidp, &freq, 0, req); if (error == 0 && req->newptr != NULL) - set_i8254_freq(freq, hz); + set_i8254_freq(freq, hz, 0); return (error); } Index: amd64/include/clock.h =================================================================== --- amd64/include/clock.h (.../mirror/FreeBSD/stable/8/sys) (revision 224114) +++ amd64/include/clock.h (.../stable/8/sys) (revision 224114) @@ -32,10 +70,11 @@ /* * Driver to clock driver interface. */ void startrtclock(void); void init_TSC(void); void init_TSC_tc(void); +void DELAY_TSCCAL(int n); #define HAS_TIMER_SPKR 1 int timer_spkr_acquire(void); Index: amd64/amd64/tsc.c =================================================================== --- amd64/amd64/tsc.c (.../mirror/FreeBSD/stable/8/sys) (revision 224114) +++ amd64/amd64/tsc.c (.../stable/8/sys) (revision 224114) @@ -87,7 +92,7 @@ printf("Calibrating TSC clock ... "); tscval[0] = rdtsc(); - DELAY(1000000); + DELAY_TSCCAL(1000000); tscval[1] = rdtsc(); tsc_freq = tscval[1] - tscval[0]; -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 21:58:19 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 28598106566C; Fri, 22 Jul 2011 21:58:17 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Callum Gibson Date: Fri, 22 Jul 2011 17:57:58 -0400 User-Agent: KMail/1.6.2 References: <20110719112033.GA51765@omma.gibson.athome> <201107211753.42373.jkim@FreeBSD.org> <20110722111305.GB76391@omma.gibson.athome> In-Reply-To: <20110722111305.GB76391@omma.gibson.athome> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_pJfKOvpaM48NZ7P" Message-Id: <201107221758.01272.jkim@FreeBSD.org> Cc: freebsd-stable@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: powernow regression in 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 21:58:19 -0000 --Boundary-00=_pJfKOvpaM48NZ7P Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Friday 22 July 2011 07:13 am, Callum Gibson wrote: > On 21Jul11 17:53, Jung-uk Kim wrote: > }> > }> > http://members.optusnet.com.au/callumgibson/boot_verboser_nousb.out > }> and dev.cpu.0.freq reappears! Spooky. Is that a solution or a }> > workaround? I noticed this disables usb keyboard support at the }> > boot menus. > } > }It is a workaround. Please try the attached patch. > > Sorry, no improvement that I can see. See verbose output: > > http://members.optusnet.com.au/callumgibson/boot_verboser2.out Please try the attached patch. If it doesn't work, I need to see "acpidump -dt" output. Jung-uk Kim --Boundary-00=_pJfKOvpaM48NZ7P Content-Type: text/plain; charset="iso-8859-1"; name="kern_cpu3.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kern_cpu3.diff" Index: sys/kern/kern_cpu.c =================================================================== --- sys/kern/kern_cpu.c (revision 224271) +++ sys/kern/kern_cpu.c (working copy) @@ -145,9 +145,7 @@ static int cpufreq_attach(device_t dev) { struct cpufreq_softc *sc; - struct pcpu *pc; device_t parent; - uint64_t rate; int numdevs; CF_DEBUG("initializing %s\n", device_get_nameunit(dev)); @@ -157,18 +155,7 @@ cpufreq_attach(device_t dev) sysctl_ctx_init(&sc->sysctl_ctx); TAILQ_INIT(&sc->all_levels); CF_MTX_INIT(&sc->lock); - sc->curr_level.total_set.freq = CPUFREQ_VAL_UNKNOWN; SLIST_INIT(&sc->saved_freq); - /* Try to get nominal CPU freq to use it as maximum later if needed */ - sc->max_mhz = cpu_get_nominal_mhz(dev); - /* If that fails, try to measure the current rate */ - if (sc->max_mhz <= 0) { - pc = cpu_get_pcpu(dev); - if (cpu_est_clockrate(pc->pc_cpuid, &rate) == 0) - sc->max_mhz = rate / 1000000; - else - sc->max_mhz = CPUFREQ_VAL_UNKNOWN; - } /* * Only initialize one set of sysctls for all CPUs. In the future, @@ -500,6 +487,7 @@ cf_get_method(device_t dev, struct cf_level *level goto out; } } + CF_DEBUG("get freq failed, estimated freq %d\n", (int)rate); error = ENXIO; out: @@ -551,17 +539,23 @@ cf_levels_method(device_t dev, struct cf_level *le * provide settings for informational purposes only. */ error = CPUFREQ_DRV_TYPE(devs[i], &type); - if (error || (type & CPUFREQ_FLAG_INFO_ONLY)) { - if (error == 0) { - CF_DEBUG("skipping info-only driver %s\n", - device_get_nameunit(devs[i])); - } + if (error) continue; - } set_count = MAX_SETTINGS; error = CPUFREQ_DRV_SETTINGS(devs[i], sets, &set_count); if (error || set_count == 0) continue; + if ((type & CPUFREQ_TYPE_MASK) == CPUFREQ_TYPE_ABSOLUTE && + sc->max_mhz < sets[0].freq) { + CF_DEBUG("setting max freq %d from %s\n", + sets[0].freq, device_get_nameunit(devs[i])); + sc->max_mhz = sets[0].freq; + } + if ((type & CPUFREQ_FLAG_INFO_ONLY) != 0) { + CF_DEBUG("skipping info-only driver %s\n", + device_get_nameunit(devs[i])); + continue; + } /* Add the settings to our absolute/relative lists. */ switch (type & CPUFREQ_TYPE_MASK) { @@ -867,8 +861,9 @@ cpufreq_dup_set(struct cpufreq_softc *sc, struct c static int cpufreq_curr_sysctl(SYSCTL_HANDLER_ARGS) { + struct cf_level level; + struct cf_level *levels; struct cpufreq_softc *sc; - struct cf_level *levels; int count, devcount, error, freq, i, n; device_t *devs; @@ -876,10 +871,10 @@ cpufreq_curr_sysctl(SYSCTL_HANDLER_ARGS) sc = oidp->oid_arg1; levels = sc->levels_buf; - error = CPUFREQ_GET(sc->dev, &levels[0]); + error = CPUFREQ_GET(sc->dev, &level); if (error) goto out; - freq = levels[0].total_set.freq; + freq = level.total_set.freq; error = sysctl_handle_int(oidp, &freq, 0, req); if (error != 0 || req->newptr == NULL) goto out; @@ -1000,8 +995,11 @@ out: int cpufreq_register(device_t dev) { + struct cf_setting set; + struct cf_setting *sets; struct cpufreq_softc *sc; device_t cf_dev, cpu_dev; + int error, freq, max, set_count, type; /* Add a sysctl to get each driver's settings separately. */ SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev), @@ -1009,14 +1007,34 @@ cpufreq_register(device_t dev) OID_AUTO, "freq_settings", CTLTYPE_STRING | CTLFLAG_RD, dev, 0, cpufreq_settings_sysctl, "A", "CPU frequency driver settings"); + /* Get settings from the device and find current and maximum frequencies */ + freq = max = CPUFREQ_VAL_UNKNOWN; + if (CPUFREQ_DRV_TYPE(dev, &type) == 0 && + (type & CPUFREQ_TYPE_MASK) == CPUFREQ_TYPE_ABSOLUTE) { + if (CPUFREQ_DRV_GET(dev, &set) == 0) + freq = set.freq; + set_count = MAX_SETTINGS; + sets = malloc(set_count * sizeof(*sets), M_TEMP, M_NOWAIT); + if (sets != NULL) { + if (CPUFREQ_DRV_SETTINGS(dev, sets, &set_count) == 0 && + set_count > 0) + max = sets[0].freq; + free(sets, M_TEMP); + } + } + /* * Add only one cpufreq device to each CPU. Currently, all CPUs * must offer the same levels and be switched at the same time. */ cpu_dev = device_get_parent(dev); - if ((cf_dev = device_find_child(cpu_dev, "cpufreq", -1))) { + cf_dev = device_find_child(cpu_dev, "cpufreq", -1); + if (cf_dev != NULL) { sc = device_get_softc(cf_dev); - sc->max_mhz = CPUFREQ_VAL_UNKNOWN; + if (sc->curr_level.total_set.freq == CPUFREQ_VAL_UNKNOWN) + sc->curr_level.total_set.freq = freq; + if (sc->max_mhz < max) + sc->max_mhz = max; return (0); } @@ -1025,8 +1043,13 @@ cpufreq_register(device_t dev) if (cf_dev == NULL) return (ENOMEM); device_quiet(cf_dev); - - return (device_probe_and_attach(cf_dev)); + error = device_probe(cf_dev); + if (error) + return (error); + sc = device_get_softc(cf_dev); + sc->curr_level.total_set.freq = freq; + sc->max_mhz = max; + return (device_attach(cf_dev)); } int --Boundary-00=_pJfKOvpaM48NZ7P-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 23 08:13:07 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C496106564A for ; Sat, 23 Jul 2011 08:13:07 +0000 (UTC) (envelope-from callumgibson@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 9E85E8FC0C for ; Sat, 23 Jul 2011 08:13:06 +0000 (UTC) Received: from omma.gibson.athome (c122-106-15-156.rivrw1.nsw.optusnet.com.au [122.106.15.156]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with SMTP id p6N8D4Rr006976 for ; Sat, 23 Jul 2011 18:13:04 +1000 Received: (qmail 14529 invoked by uid 107); 23 Jul 2011 18:13:04 +1000 Date: 23 Jul 2011 18:13:04 +1000 Date: Sat, 23 Jul 2011 18:13:04 +1000 From: Callum Gibson To: John Baldwin Message-ID: <20110723081304.GA14172@omma.gibson.athome> References: <20110719112033.GA51765@omma.gibson.athome> <20110721205600.GA52261@omma.gibson.athome> <20110721214310.GA74656@icarus.home.lan> <201107220816.52901.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107220816.52901.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Attilio Rao , freebsd-stable@freebsd.org, Jung-uk Kim , freebsd-amd64@freebsd.org Subject: Re: powernow regression in 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 08:13:07 -0000 On 22Jul11 08:16, John Baldwin wrote: }The problem is that we calibrate the TSC using this algorithm: } } - grab the TSC } - spin on the ISA timer waiting for it to run for a second } - grab the TSC } }The issue is that the SMI# fires at the same time we want to be execuiting }step 3, and step 3 is deferred while the SMI# handler runs. As a result, the }TSC delta ends up being "1 second + time of an SMI# to poll USB". We have a }hack fix for this at work that originally came from Attilio Rao. This is a }patch for it relative to 8. It disables interrupt generation for the ISA }timer while we calibrate the TSC (which disables the SMI# temporarily): Thanks, John. The hack works as intended, but I guess it's not a "real" solution which is why you haven't committed it? C -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ From owner-freebsd-stable@FreeBSD.ORG Sat Jul 23 08:21:11 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46E321065672 for ; Sat, 23 Jul 2011 08:21:11 +0000 (UTC) (envelope-from callumgibson@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id B7F048FC0C for ; Sat, 23 Jul 2011 08:21:10 +0000 (UTC) Received: from omma.gibson.athome (c122-106-15-156.rivrw1.nsw.optusnet.com.au [122.106.15.156]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with SMTP id p6N8L8pK027340 for ; Sat, 23 Jul 2011 18:21:09 +1000 Received: (qmail 14814 invoked by uid 107); 23 Jul 2011 18:21:08 +1000 Date: 23 Jul 2011 18:21:08 +1000 Date: Sat, 23 Jul 2011 18:21:08 +1000 From: Callum Gibson To: Jung-uk Kim Message-ID: <20110723082108.GB14172@omma.gibson.athome> References: <20110719112033.GA51765@omma.gibson.athome> <201107211753.42373.jkim@FreeBSD.org> <20110722111305.GB76391@omma.gibson.athome> <201107221758.01272.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201107221758.01272.jkim@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: powernow regression in 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 08:21:11 -0000 On 22Jul11 17:57, Jung-uk Kim wrote: }Please try the attached patch. If it doesn't work, I need to see }"acpidump -dt" output. Sorry, no difference. Given jhb's response is there any point pursuing this further? Seems to be a "known issue" with legacy usb that perhaps can't be fixed. In any case, acpidump output here: http://members.optusnet.com.au/callumgibson/acpidump.out.gz C -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ From owner-freebsd-stable@FreeBSD.ORG Sat Jul 23 08:47:45 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D4BF1065672 for ; Sat, 23 Jul 2011 08:47:45 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 51DE38FC12 for ; Sat, 23 Jul 2011 08:47:45 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta04.emeryville.ca.mail.comcast.net with comcast id BLmW1h0021HpZEsA4LnL8o; Sat, 23 Jul 2011 08:47:20 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta14.emeryville.ca.mail.comcast.net with comcast id BLnP1h0011t3BNj8aLnPRf; Sat, 23 Jul 2011 08:47:24 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5BA78102C36; Sat, 23 Jul 2011 01:47:21 -0700 (PDT) Date: Sat, 23 Jul 2011 01:47:21 -0700 From: Jeremy Chadwick To: Callum Gibson Message-ID: <20110723084721.GA7931@icarus.home.lan> References: <20110719112033.GA51765@omma.gibson.athome> <20110721205600.GA52261@omma.gibson.athome> <20110721214310.GA74656@icarus.home.lan> <201107220816.52901.jhb@freebsd.org> <20110723081304.GA14172@omma.gibson.athome> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110723081304.GA14172@omma.gibson.athome> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Attilio Rao , freebsd-amd64@freebsd.org, freebsd-stable@freebsd.org, Jung-uk Kim , John Baldwin Subject: Re: powernow regression in 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 08:47:45 -0000 On Sat, Jul 23, 2011 at 06:13:04PM +1000, Callum Gibson wrote: > On 22Jul11 08:16, John Baldwin wrote: > }The problem is that we calibrate the TSC using this algorithm: > } > } - grab the TSC > } - spin on the ISA timer waiting for it to run for a second > } - grab the TSC > } > }The issue is that the SMI# fires at the same time we want to be execuiting > }step 3, and step 3 is deferred while the SMI# handler runs. As a result, the > }TSC delta ends up being "1 second + time of an SMI# to poll USB". We have a > }hack fix for this at work that originally came from Attilio Rao. This is a > }patch for it relative to 8. It disables interrupt generation for the ISA > }timer while we calibrate the TSC (which disables the SMI# temporarily): > > Thanks, John. The hack works as intended, but I guess it's not a "real" > solution which is why you haven't committed it? This sort of thing is going to have to get dealt with officially sooner or later, hack-fix or elegant solution either way[1]. More and more systems are using native USB keyboards, and most system BIOSes I've seen (from multiple vendors, specifically Supermicro, Lenovo, Asus, Dell, HP, and Gigabyte[2]) are defaulting to having these options enabled (and rightfully so). If the hack-fix has repercussions, it would be helpful to know what those are or how those might manifest themselves. Otherwise, has anyone taken a look at how Linux addresses this problem? To my knowledge GRUB and similar bootstraps do not have a native USB stack, so I'm left wondering how they deal with this. [1]: I'm in no way saying "Hey! Fix this! {contributes nothing}", I'm simply pointing out that we're at a point where we really don't have much of a choice. The more I read technical explanations from John the more hate x86 architecture. ;-) [2]: On a couple Gigabyte boards I have the default values for said option is enabled (for both keyboard and mouse). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |