From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 00:08:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A95E1065674 for ; Sun, 12 Sep 2010 00:08:32 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4AF8FC08 for ; Sun, 12 Sep 2010 00:08:31 +0000 (UTC) Received: from [10.123.2.180] (DIR-655 [192.168.1.65]) by monday.kientzle.com (8.14.3/8.14.3) with ESMTP id o8C08Vfd011559; Sun, 12 Sep 2010 00:08:31 GMT (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <579405651.776013.1284247201493.JavaMail.root@erie.cs.uoguelph.ca> Date: Sat, 11 Sep 2010 17:08:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <579405651.776013.1284247201493.JavaMail.root@erie.cs.uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@freebsd.org Subject: Re: Experimental NFS server oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 00:08:32 -0000 On Sep 11, 2010, at 4:20 PM, Rick Macklem wrote: >> I just tried adding >>=20 >> nfsv4_server_enable=3D"YES" >>=20 >> to my rc.conf and found that after I rebooted the server, my FreeBSD = 8 >> client (still using NFSv3) couldn't connect because there was no RPC >> mapping for nfs. > Did you specify both of these in rc.conf? > nfs_server_enable=3D"YES" > nfsv4_server_enable=3D"YES" >=20 > You need to specify both of them (and nfsuserd=3D"YES" if you going to = use > NFSv4). See "man nfsv4" for more. Both specified, as well as rpcbind_enable=3D"YES" > If you did specify both, then do a "ps axHl" to see what didn't start = up. rpcbind, mountd, and nfsuserd are all running, but nfsd is not running. > You can also look in /var/log/messages to see if any of the daemons > are complaining about something. Only warning I see on a system reboot is: nfsd: can't open /var/db/nfs-stablerestart Creating this file and then rebooting the system seems to get things = working. This file certainly wasn't required by the old nfsd. Should this file be created by /etc/rc.d/nfsserver at boot time (if it = doesn't exist)? Or should it be created by installworld? Tim From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 00:12:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14C511065673; Sun, 12 Sep 2010 00:12:23 +0000 (UTC) (envelope-from rfarmer@predatorlabs.net) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id B1FAD8FC08; Sun, 12 Sep 2010 00:12:22 +0000 (UTC) Received: by vws7 with SMTP id 7so4210452vws.13 for ; Sat, 11 Sep 2010 17:12:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.122.203 with SMTP id m11mr1300968vcr.118.1284250341205; Sat, 11 Sep 2010 17:12:21 -0700 (PDT) Received: by 10.220.200.8 with HTTP; Sat, 11 Sep 2010 17:12:21 -0700 (PDT) X-Originating-IP: [71.1.133.114] Date: Sat, 11 Sep 2010 17:12:21 -0700 Message-ID: From: Rob Farmer To: freebsd-current@freebsd.org, Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: ZFS v28 and sendfile() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 00:12:23 -0000 Seems to not work properly, at least as implemented in the nginx web server (specifically www/nginx-devel from ports). I have "sendfile on;" in my nginx.conf and files served from a ZFS filesystem are garbled in seemingly random ways (their md5 changes every time). Shutting it off resolves the problem. Using sendfile with a UFS partition on the same machine causes no problems. -- Rob Farmer From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 00:12:55 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 9AA721065670; Sun, 12 Sep 2010 00:12:54 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Sun, 12 Sep 2010 09:12:48 +0900 From: Norikatsu Shigemura To: freebsd-current@FreeBSD.org, freebsd-acpi@FreeBSD.org Message-Id: <20100912091248.5c95bf2c.nork@FreeBSD.org> In-Reply-To: <20100912081409.9f4d74d0.nork@FreeBSD.org> References: <20100912014855.984a89ed.nork@FreeBSD.org> <4C8BCAC5.5050008@root.org> <20100912081409.9f4d74d0.nork@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Norikatsu Shigemura , Nate Lawson Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 00:12:55 -0000 On Sun, 12 Sep 2010 08:14:09 +0900 Norikatsu Shigemura wrote: > According to acpidump -dt, I could find CPU0CST table, but > not found _CST. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Scope (\) > { > Name (SSDT, Package (0x0C) > { > : > "CPU0CST ", > 0xDA9AB618, > 0x000005CD, > : > }) > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Hum... ACPI CA 20100806 has a bug? Humm... I wonder if CF-R9 required another initialization? I don't know what is HI0 and HC0. But default values of HI0 and HC0 is 0, and HI0 and HC0 are set CST related values by GCAP, I think.. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Scope (\_PR.CPU0) { Name (HI0, Zero) Name (HC0, Zero) : Method (GCAP, 1, NotSerialized) { CreateDWordField (Arg0, Zero, STS0) CreateDWordField (Arg0, 0x04, CAP0) If (LOr (LEqual (STS0, 0x06), LEqual (STS0, 0x0A))) { Return (Zero) } If (And (STS0, One)) { And (CAP0, 0x0BFF, CAP0) Return (Zero) } Or (And (PDC0, 0x7FFFFFFF), CAP0, PDC0) If (And (CFGD, One)) { If (LAnd (LAnd (And (CFGD, 0x01000000), LEqual (And (PDC0, 0x09), 0x09)), LNot (And (SDTL, One)))) { Or (SDTL, One, SDTL) OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, One)), DerefOf (Index (SSDT, 0x02 ))) Load (IST0, HI0) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (PDC0, 0x18 )), LNot (And (SDTL, 0x02)))) { Or (SDTL, 0x02, SDTL) OperationRegion (CST0, SystemMemory, DerefOf (Index (SSDT, 0x07)), DerefOf (Index (SSDT, 0x08 ))) Load (CST0, HC0) } } Return (Zero) } - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Thank you. -- Norikatsu Shigemura From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 00:26:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03F5A106566B for ; Sun, 12 Sep 2010 00:26:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id B60588FC0A for ; Sun, 12 Sep 2010 00:26:36 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAHu7i0yDaFvO/2dsb2JhbACDGJ8hrRmRCIEigyd0BIog X-IronPort-AV: E=Sophos;i="4.56,353,1280721600"; d="scan'208";a="91551508" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 11 Sep 2010 20:26:35 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E306BB3F34; Sat, 11 Sep 2010 20:26:35 -0400 (EDT) Date: Sat, 11 Sep 2010 20:26:35 -0400 (EDT) From: Rick Macklem To: Tim Kientzle Message-ID: <2141503959.776811.1284251195858.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-current@freebsd.org Subject: Re: Experimental NFS server oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 00:26:37 -0000 > On Sep 11, 2010, at 4:20 PM, Rick Macklem wrote: > > >> I just tried adding > >> > >> nfsv4_server_enable="YES" > >> > >> to my rc.conf and found that after I rebooted the server, my > >> FreeBSD 8 > >> client (still using NFSv3) couldn't connect because there was no > >> RPC > >> mapping for nfs. > > > Did you specify both of these in rc.conf? > > nfs_server_enable="YES" > > nfsv4_server_enable="YES" > > > > You need to specify both of them (and nfsuserd="YES" if you going to > > use > > NFSv4). See "man nfsv4" for more. > > Both specified, as well as > rpcbind_enable="YES" > > > If you did specify both, then do a "ps axHl" to see what didn't > > start up. > > rpcbind, mountd, and nfsuserd are all running, but nfsd is not > running. > > > You can also look in /var/log/messages to see if any of the daemons > > are complaining about something. > > Only warning I see on a system reboot is: > nfsd: can't open /var/db/nfs-stablerestart > > Creating this file and then rebooting the system seems to get things > working. > > This file certainly wasn't required by the old nfsd. > Should this file be created by /etc/rc.d/nfsserver at boot time (if it > doesn't exist)? > Or should it be created by installworld? > Technically, it should only be created for a fresh install on a disk that has never been set up before. (ie. Not on an update/upgrade unless it has never existed before.) If this file is lost during a crash, the technically correct thing is to recover it from backups and not let the server start until it is recovered, since the information in it is critical to a correct reboot recovery of the NFSv4 state. So the answer is "no" for /etc/rc.d/nfsserver unless you don't care about correct server crash recovery. I don't know if installworld can differentiate between a fresh install and an upgrade? (I suppose it could create it if it doesn't already exist.) As such, I just documented it in "man nfsv4" for now, rick From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 02:11:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F25CF106564A for ; Sun, 12 Sep 2010 02:11:58 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id D47758FC0C for ; Sun, 12 Sep 2010 02:11:58 +0000 (UTC) Received: from [10.123.2.180] (DIR-655 [192.168.1.65]) by monday.kientzle.com (8.14.3/8.14.3) with ESMTP id o8C2Bvvq012234; Sun, 12 Sep 2010 02:11:57 GMT (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <2141503959.776811.1284251195858.JavaMail.root@erie.cs.uoguelph.ca> Date: Sat, 11 Sep 2010 19:11:56 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <2141503959.776811.1284251195858.JavaMail.root@erie.cs.uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@freebsd.org Subject: Re: Experimental NFS server oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 02:11:59 -0000 On Sep 11, 2010, at 5:26 PM, Rick Macklem wrote: >> On Sep 11, 2010, at 4:20 PM, Rick Macklem wrote: >> >>> You can also look in /var/log/messages to see if any of the daemons >>> are complaining about something. >> >> Only warning I see on a system reboot is: >> nfsd: can't open /var/db/nfs-stablerestart >> >> Creating this file and then rebooting the system seems to get things >> working. >> >> This file certainly wasn't required by the old nfsd. >> Should this file be created by /etc/rc.d/nfsserver at boot time (if it >> doesn't exist)? >> Or should it be created by installworld? >> > Technically, it should only be created for a fresh install on a disk > that has never been set up before. (ie. Not on an update/upgrade > unless it has never existed before.) > .... > As such, I just documented it in "man nfsv4" for now, This is going to bite people on upgrades since the old server didn't require this file, so people upgrading from the old nfsd are going to hit this problem pretty consistently. I'd like to at least consider alternatives to the current behavior; maybe one of the following? * If the file doesn't exist on startup, create it and warn loudly. * Similar to isc-dhcp, periodically make a a backup copy of the file and only create a fresh blank one if the file and backup are both missing. * "make installworld" is certainly capable of creating this file only if it doesn't already exist. (That doesn't cover the binary update case, of course.) From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 02:40:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id A65001065672; Sun, 12 Sep 2010 02:40:49 +0000 (UTC) Date: Sun, 12 Sep 2010 02:40:49 +0000 From: Alexander Best To: John Baldwin Message-ID: <20100912024049.GA32655@freebsd.org> References: <20100909191750.GA58228@freebsd.org> <20100909194109.GA64914@freebsd.org> <20100909195045.GA68352@freebsd.org> <201009100747.39964.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <201009100747.39964.jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: {arch}/conf/DEFAULTS and uart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 02:40:49 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri Sep 10 10, John Baldwin wrote: > On Thursday, September 09, 2010 3:50:45 pm Alexander Best wrote: > > On Thu Sep 9 10, Alexander Best wrote: > > > On Thu Sep 9 10, Alexander Best wrote: > > > > hi there, > > > > > > > > except for arm most archs seem to enforce uart support in conf/DEFAULTS. is > > > > this really necessary? shouldn't DEFAULTS only contain vital devices/options > > > > without a kernel on a specific arch won't function at all? > > > > > > jhb just explained to me, that the uart entry in DEFAULTS is not a controller > > > or something like that, but the uart backend to use *if* uart gets defined in > > > the kernel config. > > > > > > sorry for the noise folks. > > > > however i found some missing comments and incorrect syntax which i fixed. > > > > see the attached patch. > > I think the ia64 ordering for 'io and mem' is probably more correct > (alphabetically sorted), so I would fix i386 and amd64 and leave ia64 alone. > > The powerpc 'machine' changes are wrong I think as it would break GENERIC64 > and powerpc64 kernel configs in general. Nathan purposefully removed > 'machine' from the powerpc DEFAULTS. here's try #2. ;) cheers. alex > > -- > John Baldwin -- a13x --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="DEFAULTS.diff2" diff --git a/sys/amd64/conf/DEFAULTS b/sys/amd64/conf/DEFAULTS index 1fb52b3..c525935 100644 --- a/sys/amd64/conf/DEFAULTS +++ b/sys/amd64/conf/DEFAULTS @@ -5,12 +5,12 @@ machine amd64 -# Bus support. +# Bus support device isa -# Pseudo devices. -device mem # Memory and kernel memory devices +# Pseudo devices device io # I/O device +device mem # Memory and kernel memory devices # UART chips on this platform device uart_ns8250 diff --git a/sys/arm/conf/DEFAULTS b/sys/arm/conf/DEFAULTS index 591a0a1..5e1512f 100644 --- a/sys/arm/conf/DEFAULTS +++ b/sys/arm/conf/DEFAULTS @@ -5,7 +5,9 @@ machine arm -device mem +# Pseudo devices +device mem # Memory and kernel memory devices +# Default partitioning schemes options GEOM_PART_BSD options GEOM_PART_MBR diff --git a/sys/i386/conf/DEFAULTS b/sys/i386/conf/DEFAULTS index 32e77e4..d364389 100644 --- a/sys/i386/conf/DEFAULTS +++ b/sys/i386/conf/DEFAULTS @@ -5,16 +5,16 @@ machine i386 -# Bus support. +# Bus support device isa options ISAPNP -# Floating point support. +# Floating point support device npx -# Pseudo devices. -device mem # Memory and kernel memory devices +# Pseudo devices device io # I/O device +device mem # Memory and kernel memory devices # UART chips on this platform device uart_ns8250 @@ -26,5 +26,5 @@ options GEOM_PART_EBR_COMPAT options GEOM_PART_MBR # enable support for native hardware -options NATIVE device atpic +options NATIVE diff --git a/sys/ia64/conf/DEFAULTS b/sys/ia64/conf/DEFAULTS index 2cb2330..608dcc1 100644 --- a/sys/ia64/conf/DEFAULTS +++ b/sys/ia64/conf/DEFAULTS @@ -5,16 +5,17 @@ machine ia64 -# Bus support. +# Bus support device acpi # ACPI support -# Pseudo devices. +# Pseudo devices device io # I/O & EFI runtime device device mem # Memory and kernel memory devices # UART chips on this platform device uart_ns8250 +# Default partitioning schemes options GEOM_PART_BSD options GEOM_PART_GPT options GEOM_PART_MBR diff --git a/sys/mips/conf/DEFAULTS b/sys/mips/conf/DEFAULTS index dc480ce..59e4442 100644 --- a/sys/mips/conf/DEFAULTS +++ b/sys/mips/conf/DEFAULTS @@ -5,9 +5,12 @@ machine mips -device mem +# Pseudo devices +device mem # Memory and kernel memory devices +# UART chips on this platform device uart_ns8250 +# Default partitioning schemes options GEOM_PART_BSD options GEOM_PART_MBR diff --git a/sys/pc98/conf/DEFAULTS b/sys/pc98/conf/DEFAULTS index f30501e..246f309 100644 --- a/sys/pc98/conf/DEFAULTS +++ b/sys/pc98/conf/DEFAULTS @@ -6,16 +6,16 @@ machine pc98 i386 options PC98 -# Bus support. +# Bus support device isa options ISAPNP -# Floating point support. +# Floating point support device npx -# Pseudo devices. -device mem # Memory and kernel memory devices +# Pseudo devices device io # I/O device +device mem # Memory and kernel memory devices # UART chips on this platform device uart_ns8250 diff --git a/sys/powerpc/conf/DEFAULTS b/sys/powerpc/conf/DEFAULTS index 658c221..5623732 100644 --- a/sys/powerpc/conf/DEFAULTS +++ b/sys/powerpc/conf/DEFAULTS @@ -3,12 +3,13 @@ # # $FreeBSD$ -# Pseudo devices. +# Pseudo devices device mem # Memory and kernel memory devices # UART chips on this platform device uart_ns8250 device uart_z8530 +# Default partitioning schemes options GEOM_PART_APM options GEOM_PART_MBR diff --git a/sys/powerpc/conf/GENERIC b/sys/powerpc/conf/GENERIC index 891d9aa..d8a8f4e 100644 --- a/sys/powerpc/conf/GENERIC +++ b/sys/powerpc/conf/GENERIC @@ -12,8 +12,8 @@ # latest information. # # An exhaustive list of options and more detailed explanations of the -# device lines is also present in the ../../conf/NOTES and NOTES files. -# If you are in doubt as to the purpose or necessity of a line, check first +# device lines is also present in the ../../conf/NOTES and NOTES files. +# If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD$ @@ -21,60 +21,60 @@ cpu AIM ident GENERIC -machine powerpc powerpc +machine powerpc powerpc -makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols +makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols # Platform support -options POWERMAC #NewWorld Apple PowerMacs -options PSIM #GDB PSIM ppc simulator -options MAMBO #IBM Mambo Full System Simulator - -options SCHED_ULE #ULE scheduler -options INET #InterNETworking -options INET6 #IPv6 communications protocols -options SCTP #Stream Control Transmission Protocol -options FFS #Berkeley Fast Filesystem -options SOFTUPDATES #Enable FFS soft updates support -options UFS_ACL #Support for access control lists -options UFS_DIRHASH #Improve performance on big directories -options UFS_GJOURNAL #Enable gjournal-based UFS journaling -options MD_ROOT #MD is a potential root device -options NFSCLIENT #Network Filesystem Client -options NFSSERVER #Network Filesystem Server -options NFSLOCKD #Network Lock Manager -options NFS_ROOT #NFS usable as root device -options MSDOSFS #MSDOS Filesystem -options CD9660 #ISO 9660 Filesystem -options PROCFS #Process filesystem (requires PSEUDOFS) -options PSEUDOFS #Pseudo-filesystem framework -options GEOM_PART_GPT #GUID Partition Tables. -options GEOM_LABEL #Provides labelization -options COMPAT_FREEBSD4 #Keep this for a while -options COMPAT_FREEBSD5 #Compatible with FreeBSD5 -options COMPAT_FREEBSD6 #Compatible with FreeBSD6 -options COMPAT_FREEBSD7 #Compatible with FreeBSD7 -options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI -options KTRACE #ktrace(1) syscall trace support -options STACK #stack(9) support -options SYSVSHM #SYSV-style shared memory -options SYSVMSG #SYSV-style message queues -options SYSVSEM #SYSV-style semaphores +options POWERMAC # NewWorld Apple PowerMacs +options PSIM # GDB PSIM ppc simulator +options MAMBO # IBM Mambo Full System Simulator + +options SCHED_ULE # ULE scheduler +options INET # InterNETworking +options INET6 # IPv6 communications protocols +options SCTP # Stream Control Transmission Protocol +options FFS # Berkeley Fast Filesystem +options SOFTUPDATES # Enable FFS soft updates support +options UFS_ACL # Support for access control lists +options UFS_DIRHASH # Improve performance on big directories +options UFS_GJOURNAL # Enable gjournal-based UFS journaling +options MD_ROOT # MD is a potential root device +options NFSCLIENT # Network Filesystem Client +options NFSSERVER # Network Filesystem Server +options NFSLOCKD # Network Lock Manager +options NFS_ROOT # NFS usable as root device +options MSDOSFS # MSDOS Filesystem +options CD9660 # ISO 9660 Filesystem +options PROCFS # Process filesystem (requires PSEUDOFS) +options PSEUDOFS # Pseudo-filesystem framework +options GEOM_PART_GPT # GUID Partition Tables. +options GEOM_LABEL # Provides labelization +options COMPAT_FREEBSD4 # Keep this for a while +options COMPAT_FREEBSD5 # Compatible with FreeBSD5 +options COMPAT_FREEBSD6 # Compatible with FreeBSD6 +options COMPAT_FREEBSD7 # Compatible with FreeBSD7 +options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI +options KTRACE # ktrace(1) syscall trace support +options STACK # stack(9) support +options SYSVSHM # SYSV-style shared memory +options SYSVMSG # SYSV-style message queues +options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores -options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions +options _KPOSIX_PRIORITY_SCHEDULING # Posix P1003_1B real-time extensions options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework -options INCLUDE_CONFIG_FILE # Include this file in kernel +options INCLUDE_CONFIG_FILE # Include this file in kernel # Debugging for use in -current -options KDB #Enable the kernel debugger -options DDB #Support DDB -#options DEADLKRES #Enable the deadlock resolver -options INVARIANTS #Enable calls of extra sanity checking -options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS -options WITNESS #Enable checks to detect deadlocks and cycles -options WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed +options KDB # Enable the kernel debugger +options DDB # Support DDB +#options DEADLKRES # Enable the deadlock resolver +options INVARIANTS # Enable calls of extra sanity checking +options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS +options WITNESS # Enable checks to detect deadlocks and cycles +options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones # To make an SMP kernel, the next line is needed @@ -145,7 +145,7 @@ device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. -device bpf #Berkeley packet filter +device bpf # Berkeley packet filter # USB support options USB_DEBUG # enable debug msgs @@ -185,4 +185,3 @@ device pmu # Powermac I2C support device iicbus # I2C bus code device kiic # Keywest I2C - diff --git a/sys/sparc64/conf/DEFAULTS b/sys/sparc64/conf/DEFAULTS index 38b2408..2e60c94 100644 --- a/sys/sparc64/conf/DEFAULTS +++ b/sys/sparc64/conf/DEFAULTS @@ -5,7 +5,7 @@ machine sparc64 -# Pseudo devices. +# Pseudo devices device mem # Memory and kernel memory devices # UART chips on this platform @@ -17,5 +17,5 @@ device uart_z8530 options GEOM_PART_BSD options GEOM_PART_VTOC8 -# Let sunkbd emulate an AT keyboard by default. +# Let sunkbd emulate an AT keyboard by default options SUNKBD_EMULATE_ATKBD diff --git a/sys/sun4v/conf/DEFAULTS b/sys/sun4v/conf/DEFAULTS index 87a55ec..4c21bc9 100644 --- a/sys/sun4v/conf/DEFAULTS +++ b/sys/sun4v/conf/DEFAULTS @@ -5,7 +5,7 @@ machine sun4v sparc64 -# Pseudo devices. +# Pseudo devices device mem # Memory and kernel memory devices # Default partitioning schemes --oyUTqETQ0mS9luUI-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 07:39:21 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0A7E106566C; Sun, 12 Sep 2010 07:39:21 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AB6FF8FC1D; Sun, 12 Sep 2010 07:39:20 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA24172; Sun, 12 Sep 2010 10:39:16 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ouh9g-000FgF-FC; Sun, 12 Sep 2010 10:39:16 +0300 Message-ID: <4C8C83A3.9010009@icyb.net.ua> Date: Sun, 12 Sep 2010 10:39:15 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Nate Lawson References: <20100912014855.984a89ed.nork@FreeBSD.org> <4C8BCAC5.5050008@root.org> In-Reply-To: <4C8BCAC5.5050008@root.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 07:39:21 -0000 on 11/09/2010 21:30 Nate Lawson said the following: >> PROCESSOR-0311 [255895] cpu_attach : acpi_cpu3: P_BLK at 0x410/6 >> PROCESSOR-0696 [257314] cpu_cx_cst : acpi_cpu3: C2[1] not available. >> PROCESSOR-0730 [257314] cpu_cx_cst : acpi_cpu3: Got C3 - 245 latency > > I think the issue is that C2 is not available for some reason and thus > C3 can't be used either. The way to tell is to use acpidump and look for > the CPU objects' _CST fields. > The "not available" message means that transition latency is defined too high. That is, in this case latency is greater than 100 for C2. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 08:01:21 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39B7A106564A; Sun, 12 Sep 2010 08:01:21 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 12FF78FC1A; Sun, 12 Sep 2010 08:01:19 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA24343; Sun, 12 Sep 2010 11:01:17 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OuhUy-000Fh6-Ms; Sun, 12 Sep 2010 11:01:16 +0300 Message-ID: <4C8C88CC.5060302@icyb.net.ua> Date: Sun, 12 Sep 2010 11:01:16 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Nate Lawson References: <20100912014855.984a89ed.nork@FreeBSD.org> <4C8BCAC5.5050008@root.org> In-Reply-To: <4C8BCAC5.5050008@root.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 08:01:21 -0000 on 11/09/2010 21:30 Nate Lawson said the following: > I think the issue is that C2 is not available for some reason and thus > C3 can't be used either. The way to tell is to use acpidump and look for > the CPU objects' _CST fields. >From reading of the code, C3 should be used in this case even if C2 is not available. But I think that it might get removed for a different reason: PM2_CNT_BLK length seems to be zero. With ACPI_DB_INFO enabled there should be "no BM control" message in the log. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 08:03:07 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B8CB1065672; Sun, 12 Sep 2010 08:03:07 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5F6848FC14; Sun, 12 Sep 2010 08:03:06 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA24351; Sun, 12 Sep 2010 11:03:05 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OuhWi-000FhE-Pj; Sun, 12 Sep 2010 11:03:04 +0300 Message-ID: <4C8C8938.4030500@icyb.net.ua> Date: Sun, 12 Sep 2010 11:03:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Norikatsu Shigemura References: <20100912014855.984a89ed.nork@FreeBSD.org> <4C8BCAC5.5050008@root.org> <20100912081409.9f4d74d0.nork@FreeBSD.org> In-Reply-To: <20100912081409.9f4d74d0.nork@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org, Nate Lawson Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 08:03:07 -0000 on 12/09/2010 02:14 Norikatsu Shigemura said the following: > According to acpidump -dt, I could find CPU0CST table, but > not found _CST. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Scope (\) > { > Name (SSDT, Package (0x0C) > { > : > "CPU0CST ", > 0xDA9AB618, > 0x000005CD, > : > }) > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Hum... ACPI CA 20100806 has a bug? How do you conclude? Does a different version work? It seems that our acpidump doesn't dump a dynamically loaded table. That the table was loaded we can see from these messages: ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 005CD (v01 PmRef Cpu0Cst 00003001 INTL 20061109) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 08:12:44 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA092106566B for ; Sun, 12 Sep 2010 08:12:44 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 528F28FC17 for ; Sun, 12 Sep 2010 08:12:43 +0000 (UTC) Received: by bwz20 with SMTP id 20so336941bwz.13 for ; Sun, 12 Sep 2010 01:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=zx3UopHs2kS6fHtJLWbjMG7a+S/4sZgb0Au9HZmmMxw=; b=aTsKpD076+OeAvtmO6vImi0JXRwoiRGeaB0kQvKwaUuiqtdh/TBjaDepdjAG69Qkgt sWaZ7wvU4GqoN936Gmov5RmYb4EuwxFHOsNYyiS81uNlrT1orYbS4jmJPkTse+PT3aTw MNMoPu1lAozunIpIiJLCxwGXexs362vTxjRzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=SIWnZ3ZNbgvG+uy+bMH4lfXeamC06YE1LQDNhYkYN+QGLJDC4j7SMl0gYPiEiTX7V9 LuWhvRNReczzEzoOLKPznqc1OWNnC5agMvve34TWm11HTsSfO9HrOMepfn9UNc7EGqGq 2/utsAaxObjjyzRzaILCAJbWiTDzfgOy0rojI= Received: by 10.204.117.136 with SMTP id r8mr2068164bkq.119.1284279158282; Sun, 12 Sep 2010 01:12:38 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y2sm3513608bkx.8.2010.09.12.01.12.36 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Sep 2010 01:12:37 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8C8B64.8020907@FreeBSD.org> Date: Sun, 12 Sep 2010 11:12:20 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Andriy Gapon , Norikatsu Shigemura , FreeBSD-Current References: <4C8BCAC5.5050008@root.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 08:12:44 -0000 Andriy Gapon wrote: > on 11/09/2010 21:30 Nate Lawson said the following: >>> PROCESSOR-0311 [255895] cpu_attach : acpi_cpu3: P_BLK at 0x410/6 >>> PROCESSOR-0696 [257314] cpu_cx_cst : acpi_cpu3: C2[1] not available. >>> PROCESSOR-0730 [257314] cpu_cx_cst : acpi_cpu3: Got C3 - 245 latency >> I think the issue is that C2 is not available for some reason and thus >> C3 can't be used either. The way to tell is to use acpidump and look for >> the CPU objects' _CST fields. >> > > The "not available" message means that transition latency is defined too high. > That is, in this case latency is greater than 100 for C2. Just an idea. Limits of 100 and 1000 are defined for detection of C-states using P_LVLx_LAT registers. Because _CST explicitly specifies which states are available, these limitations may not apply there. I would try to comment these checks in acpi_cpu_cx_cst() and look what happen. At least I haven't found in ACPI 3.0 specification any latency limits applied to _CST. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 08:30:47 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C616D106564A; Sun, 12 Sep 2010 08:30:47 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id ACF828FC14; Sun, 12 Sep 2010 08:30:46 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA24595; Sun, 12 Sep 2010 11:30:44 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OuhxU-000FiF-Fh; Sun, 12 Sep 2010 11:30:44 +0300 Message-ID: <4C8C8FB3.9060100@icyb.net.ua> Date: Sun, 12 Sep 2010 11:30:43 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alexander Motin References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> In-Reply-To: <4C8C8B64.8020907@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 08:30:47 -0000 on 12/09/2010 11:12 Alexander Motin said the following: > Just an idea. Limits of 100 and 1000 are defined for detection of > C-states using P_LVLx_LAT registers. Because _CST explicitly specifies > which states are available, these limitations may not apply there. I > would try to comment these checks in acpi_cpu_cx_cst() and look what > happen. At least I haven't found in ACPI 3.0 specification any latency > limits applied to _CST. Not 100% sure, but what you said does make sense. I couldn't also find any such wording in ACPI 4.0 spec. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 09:26:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 956E3106564A; Sun, 12 Sep 2010 09:26:31 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Sun, 12 Sep 2010 18:26:25 +0900 From: Norikatsu Shigemura To: Alexander Motin Message-Id: <20100912182625.c49d3f1d.nork@FreeBSD.org> In-Reply-To: <4C8C8B64.8020907@FreeBSD.org> References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sun__12_Sep_2010_18_26_25_+0900_Ounoful9LC=1Uxzy" Cc: FreeBSD-Current , Andriy Gapon , Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 09:26:32 -0000 This is a multi-part message in MIME format. --Multipart=_Sun__12_Sep_2010_18_26_25_+0900_Ounoful9LC=1Uxzy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi avg and mav. On Sun, 12 Sep 2010 11:12:20 +0300 Alexander Motin wrote: > >>> PROCESSOR-0696 [257314] cpu_cx_cst : acpi_cpu3: C2[1] not available. > >>> PROCESSOR-0730 [257314] cpu_cx_cst : acpi_cpu3: Got C3 - 245 latency > >> I think the issue is that C2 is not available for some reason and thus > >> C3 can't be used either. The way to tell is to use acpidump and look for > >> the CPU objects' _CST fields. > > The "not available" message means that transition latency is defined too high. > > That is, in this case latency is greater than 100 for C2. > Just an idea. Limits of 100 and 1000 are defined for detection of > C-states using P_LVLx_LAT registers. Because _CST explicitly specifies Oops! I forgot. Thank you, I tried. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --- sys/dev/acpica/acpi_cpu.c.orig 2010-09-12 01:31:38.144243000 +0900 +++ sys/dev/acpica/acpi_cpu.c 2010-09-12 18:06:14.651938193 +0900 @@ -597,7 +597,7 @@ /* Validate and allocate resources for C2 (P_LVL2). */ gas.SpaceId = ACPI_ADR_SPACE_SYSTEM_IO; gas.BitWidth = 8; - if (AcpiGbl_FADT.C2Latency <= 100) { + if (AcpiGbl_FADT.C2Latency <= 1000) { gas.Address = sc->cpu_p_blk + 4; acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &sc->cpu_rid, &gas, &cx_ptr->p_lvlx, RF_SHAREABLE); @@ -613,7 +613,7 @@ return; /* Validate and allocate resources for C3 (P_LVL3). */ - if (AcpiGbl_FADT.C3Latency <= 1000 && !(cpu_quirks & CPU_QUIRK_NO_C3)) { + if (AcpiGbl_FADT.C3Latency <= 10000 && !(cpu_quirks & CPU_QUIRK_NO_C3)) { gas.Address = sc->cpu_p_blk + 5; acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &sc->cpu_rid, &gas, &cx_ptr->p_lvlx, RF_SHAREABLE); @@ -690,7 +690,7 @@ sc->cpu_cx_count++; continue; case ACPI_STATE_C2: - if (cx_ptr->trans_lat > 100) { + if (cx_ptr->trans_lat > 1000) { ACPI_DEBUG_PRINT((ACPI_DB_INFO, "acpi_cpu%d: C2[%d] not available.\n", device_get_unit(sc->cpu_dev), i)); @@ -700,7 +700,7 @@ break; case ACPI_STATE_C3: default: - if (cx_ptr->trans_lat > 1000 || + if (cx_ptr->trans_lat > 10000 || (cpu_quirks & CPU_QUIRK_NO_C3) != 0) { ACPI_DEBUG_PRINT((ACPI_DB_INFO, - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - But cx_lowest is not changed: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ sysctl -a | grep cx hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_supported: C1/3 C2/245 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% last 3641us dev.cpu.1.cx_supported: C1/3 C2/245 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% last 798us dev.cpu.2.cx_supported: C1/3 C2/245 dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_usage: 100.00% 0.00% last 158us dev.cpu.3.cx_supported: C1/3 C2/245 dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_usage: 100.00% 0.00% last 227us - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please see also attached dmesg.txt. Thank you. -- Norikatsu Shigemura --Multipart=_Sun__12_Sep_2010_18_26_25_+0900_Ounoful9LC=1Uxzy Content-Type: text/plain; name="dmesg.txt" Content-Disposition: attachment; filename="dmesg.txt" Content-Transfer-Encoding: 7bit ACPI set debug layer 'ACPI_ALL_DRIVERS ACPI_DB_INFO' level 'ACPI_LV_INFO' Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #2: Sun Sep 12 18:11:16 JST 2010 nork@pelsia.ninth-nine.com:/usr/obj/usr/src/sys/PELSIA amd64 Table 'FACP' at 0xda9aea98 Table 'APIC' at 0xda9aef18 Table 'MCFG' at 0xda9b0f18 Table 'HPET' at 0xda9b0e98 Table 'ASF!' at 0xda9af918 Table 'SLIC' at 0xda98ae18 Table 'SSDT' at 0xda9a9018 Table 'SSDT' at 0xda9a8c18 Table 'SSDT' at 0xda9a7c98 Table 'DMAR' at 0xda9a8f18 Table 'TCPA' at 0xda9b0e18 Table 'SSDT' at 0xda973a98 ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80be1000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff80be13b0. Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0xffffffff80be1a58. Preloaded elf obj module "/boot/kernel/krpc.ko" at 0xffffffff80be2088. Preloaded elf obj module "/boot/kernel/if_iwn.ko" at 0xffffffff80be26b0. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff80be2c58. Preloaded elf obj module "/boot/kernel/acpi_panasonic.ko" at 0xffffffff80be2cb8. Calibrating TSC clock ... TSC clock: 1197030122 Hz CPU: Intel(R) Core(TM) i7 CPU U 640 @ 1.20GHz (1197.03-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x20652 Family = 6 Model = 25 Stepping = 2 Features=0xbfebfbff Features2=0x298e3ff AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4303355904 (4104 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000097fff, 618496 bytes (151 pages) 0x0000000000c12000 - 0x00000000d254ffff, 3516129280 bytes (858430 pages) 0x00000000da969000 - 0x00000000da96dfff, 20480 bytes (5 pages) 0x00000000daa04000 - 0x00000000db3fffff, 10469376 bytes (2556 pages) 0x0000000100000000 - 0x0000000117feffff, 402587648 bytes (98288 pages) avail memory = 3907776512 (3726 MB) Event timer "LAPIC" frequency 0 Hz quality 600 ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 5 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 3 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 4 lapic0: CMCI unmasked x86bios: IVT 0x000000-0x0004ff at 0xffffff0000000000 x86bios: SSEG 0x001000-0x001fff at 0xffffff8000023000 x86bios: EBDA 0x09b000-0x09ffff at 0xffffff000009b000 x86bios: ROM 0x0a0000-0x0fefff at 0xffffff00000a0000 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf0410 00024 (v02 MATBIO) ACPI: XSDT 0xda9afe18 00084 (v01 MATBIO CFR9-1 06222004 MSFT 00010013) ACPI: FACP 0xda9aea98 000F4 (v04 MATBIO CFR9-1 06222004 MSFT 00010013) ACPI Warning: 32/64X FACS address mismatch in FADT - 0xDA9C1F40/0x00000000DA9D5D40, using 32 (20100806/tbfadt-586) ACPI: DSDT 0xda957018 119B4 (v01 MATBIO CFR9-1 00000000 INTL 20061109) ACPI: FACS 0xda9c1f40 00040 ACPI: APIC 0xda9aef18 0008C (v02 MATBIO CFR9-1 06222004 MSFT 00010013) ACPI: MCFG 0xda9b0f18 0003C (v01 MATBIO CFR9-1 06222004 MSFT 00000097) ACPI: HPET 0xda9b0e98 00038 (v01 MATBIO CFR9-1 06222004 AMI. 00000003) ACPI: ASF! 0xda9af918 00063 (v32 INTEL HCG 00000001 TFSM 000F4240) ACPI: SLIC 0xda98ae18 00176 (v01 MATBIO CFR9-1 06222004 AMI 00010013) ACPI: SSDT 0xda9a9018 009F1 (v01 PmRef CpuPm 00003000 INTL 20061109) ACPI: SSDT 0xda9a8c18 00259 (v01 PmRef Cpu0Tst 00003000 INTL 20061109) ACPI: SSDT 0xda9a7c98 0020F (v01 PmRef ApTst 00003000 INTL 20061109) ACPI: DMAR 0xda9a8f18 000B8 (v01 INTEL CP_DALE 00000001 INTL 00000001) ACPI: TCPA 0xda9b0e18 00032 (v02 MATBIO CFR9-1 00000001 MSFT 01000013) ACPI: SSDT 0xda973a98 002EF (v01 SataRe SataTabl 00001000 INTL 20061109) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 wlan: <802.11 Link Layer> random: cpuctl: access to MSR registers/cpuid info. VESA: INT 0x10 vector 0xc000:0x0014 VESA: information block 0000 56 45 53 41 00 03 00 01 00 02 01 00 00 00 40 00 0010 00 02 ff 01 00 01 3e 01 00 02 50 01 00 02 7c 01 0020 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040 60 01 61 01 62 01 63 01 64 01 65 01 66 01 67 01 0050 68 01 69 01 6a 01 6b 01 6c 01 6d 01 6e 01 6f 01 0060 70 01 71 01 3c 01 4d 01 5c 01 3a 01 4b 01 5a 01 0070 07 01 1a 01 1b 01 05 01 17 01 18 01 12 01 14 01 0080 15 01 01 01 03 01 11 01 ff ff 00 00 00 00 00 00 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100 49 6e 74 65 6c 28 52 29 49 72 6f 6e 6c 61 6b 65 0110 20 4d 6f 62 69 6c 65 20 47 72 61 70 68 69 63 73 0120 20 43 68 69 70 73 65 74 20 41 63 63 65 6c 65 72 0130 61 74 65 64 20 56 47 41 20 42 49 4f 53 00 49 6e 0140 74 65 6c 20 43 6f 72 70 6f 72 61 74 69 6f 6e 00 0150 49 6e 74 65 6c 28 52 29 49 72 6f 6e 6c 61 6b 65 0160 20 4d 6f 62 69 6c 65 20 47 72 61 70 68 69 63 73 0170 20 43 6f 6e 74 72 6f 6c 6c 65 72 00 48 61 72 64 0180 77 61 72 65 20 56 65 72 73 69 6f 6e 20 30 2e 30 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 9 mode(s) found VESA: v3.0, 32704k memory, flags:0x1, mode table:0xffffff8000079040 (2000040) VESA: Intel(R)Ironlake Mobile Graphics Chipset Accelerated VGA BIOS VESA: Intel Corporation Intel(R)Ironlake Mobile Graphics Controller Hardware Version 0.0 io: kbd: new array size 4 kbd1 at kbdmux0 mem: crypto: null: smbios0: at iomem 0xf0440-0xf045e on motherboard smbios0: Version: 2.6, BCD Revision: 2.6 aesni0: on motherboard crypto: assign aesni0 driver id 0, flags 16777216 crypto: aesni0 registers alg 11 flags 0 maxoplen 0 cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 1, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xf8000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI Error (dswload-0772): [DD02] Namespace lookup failure, AE_NOT_FOUND ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20100806/psloop-326) ACPI Error (psparse-0633): Method parse/execution failed [\\] (Node 0xffffffff80812720), AE_NOT_FOUND ACPI Error (dswload-0772): [EHC1] Namespace lookup failure, AE_NOT_FOUND ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20100806/psloop-326) ACPI Error (psparse-0633): Method parse/execution failed [\\] (Node 0xffffffff80812720), AE_NOT_FOUND ACPI Error (dswload-0772): [EHC1] Namespace lookup failure, AE_NOT_FOUND ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20100806/psloop-326) ACPI Error (psparse-0633): Method parse/execution failed [\\] (Node 0xffffffff80812720), AE_NOT_FOUND ACPI: Executed 5 blocks of module-level executable AML code AcpiOsDerivePciId: \\_SB_.PCI0.SBUS.SMPB -> bus 0 dev 31 func 3 acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.CPBG.IMCH.PBUS -> bus 63 dev 0 func 1 AcpiOsDerivePciId: \\_SB_.PCI0.HBUS -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPCB.LPC0 -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPCB.LPC1 -> bus 0 dev 31 func 0 acpi0: reservation of e0000, 20000 (3) failed ACPI timer: 0/16 0/17 0/16 1/1 1/1 1/1 1/1 0/16 0/15 0/15 -> 4 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 PROCESSOR-0311 [230584] cpu_attach : acpi_cpu0: P_BLK at 0x410/6 ACPI: SSDT 0xda9adc18 002AA (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 002AA (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: SSDT 0xda9ab618 005CD (v01 PmRef Cpu0Cst 00003001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 005CD (v01 PmRef Cpu0Cst 00003001 INTL 20061109) PROCESSOR-0730 [241753] cpu_cx_cst : acpi_cpu0: Got C2 - 205 latency PROCESSOR-0730 [241753] cpu_cx_cst : acpi_cpu0: Got C3 - 245 latency cpu1: on acpi0 PROCESSOR-0311 [241991] cpu_attach : acpi_cpu1: P_BLK at 0x410/6 ACPI: SSDT 0xda9aca98 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: SSDT 0xda9aad98 00119 (v01 PmRef ApCst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00119 (v01 PmRef ApCst 00003000 INTL 20061109) PROCESSOR-0730 [254000] cpu_cx_cst : acpi_cpu1: Got C2 - 205 latency PROCESSOR-0730 [254000] cpu_cx_cst : acpi_cpu1: Got C3 - 245 latency cpu2: on acpi0 PROCESSOR-0311 [254238] cpu_attach : acpi_cpu2: P_BLK at 0x410/6 PROCESSOR-0730 [255657] cpu_cx_cst : acpi_cpu2: Got C2 - 205 latency PROCESSOR-0730 [255657] cpu_cx_cst : acpi_cpu2: Got C3 - 245 latency cpu3: on acpi0 PROCESSOR-0311 [255895] cpu_attach : acpi_cpu3: P_BLK at 0x410/6 PROCESSOR-0730 [257314] cpu_cx_cst : acpi_cpu3: Got C2 - 205 latency PROCESSOR-0730 [257314] cpu_cx_cst : acpi_cpu3: Got C3 - 245 latency acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 4 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 4 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 5 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 3 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x0044, revid=0x12 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x0046, revid=0x12 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xf0000000, size 22, enabled map[18]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled map[20]: type I/O Port, range 32, base 0xe0b0, size 3, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x10ea, revid=0x06 domain=0, bus=0, slot=25, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf4800000, size 17, enabled map[14]: type Memory, range 32, base 0xf4829000, size 12, enabled map[18]: type I/O Port, range 32, base 0xe040, size 5, enabled pcib0: matched entry for 0.25.INTA pcib0: slot 25 INTA hardwired to IRQ 20 found-> vendor=0x8086, dev=0x3b3c, revid=0x06 domain=0, bus=0, slot=26, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf4828000, size 10, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3b56, revid=0x06 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf4820000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x3b42, revid=0x06 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x10 (4000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3b46, revid=0x06 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x10 (4000 ns), maxlat=0x00 (0 ns) intpin=c, irq=4 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3b48, revid=0x06 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x10 (4000 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3b34, revid=0x06 domain=0, bus=0, slot=29, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf4827000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xa6 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x10 (4000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3b07, revid=0x06 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3b2f, revid=0x06 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0xe090, size 3, enabled map[14]: type I/O Port, range 32, base 0xe080, size 2, enabled map[18]: type I/O Port, range 32, base 0xe070, size 3, enabled map[1c]: type I/O Port, range 32, base 0xe060, size 2, enabled map[20]: type I/O Port, range 32, base 0xe020, size 5, enabled map[24]: type Memory, range 32, base 0xf4826000, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3b30, revid=0x06 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=4 map[10]: type Memory, range 64, base 0xf4825000, size 8, enabled map[20]: type I/O Port, range 32, base 0xe000, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3b32, revid=0x06 domain=0, bus=0, slot=31, func=6 class=11-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=4 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xf4824000, size 12, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 vgapci0: port 0xe0b0-0xe0b7 mem 0xf0000000-0xf03fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 32764k stolen memory em0: port 0xe040-0xe05f mem 0xf4800000-0xf481ffff,0xf4829000-0xf4829fff irq 20 at device 25.0 on pci0 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 49 em0: using IRQ 256 for MSI em0: Using an MSI interrupt em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:1b:d3:89:b8:6e ehci0: mem 0xf4828000-0xf48283ff irq 16 at device 26.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 50 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: on ehci0 hdac0: mem 0xf4820000-0xf4823fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 51 hdac0: using IRQ 257 for MSI hdac0: [MPSAFE] hdac0: [ITHREAD] hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib1: irq 16 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0xf4600000-0xf47fffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 18 at device 28.2 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xc000-0xcfff pcib2: memory decode 0xf4400000-0xf45fffff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x8086, dev=0x422c, revid=0x35 domain=0, bus=2, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=4 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf4400000, size 13, enabled pcib2: requested memory range 0xf4400000-0xf4401fff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 iwn0: mem 0xf4400000-0xf4401fff irq 18 at device 0.0 on pci2 iwn0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 258 to local APIC 0 vector 52 iwn0: using IRQ 258 for MSI iwn0: MIMO 2T2R, MoW, address 00:23:14:21:69:00 iwn0: [MPSAFE] iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps pcib3: irq 19 at device 28.3 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 11 pcib3: I/O decode 0xa000-0xbfff pcib3: memory decode 0xf0400000-0xf43fffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x1180, dev=0xe476, revid=0x00 domain=0, bus=3, slot=0, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x04 (1000 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf2c01000, size 12, enabled pcib3: requested memory range 0xf2c01000-0xf2c01fff: good pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 19 found-> vendor=0x1180, dev=0xe822, revid=0x02 domain=0, bus=3, slot=0, func=1 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf2c00000, size 8, enabled pcib3: requested memory range 0xf2c00000-0xf2c000ff: good pcib3: matched entry for 3.0.INTB pcib3: slot 0 INTB hardwired to IRQ 16 cbb0: mem 0xf2c01000-0xf2c01fff irq 19 at device 0.0 on pci3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 53 cbb0: [MPSAFE] cbb0: [FILTER] cbb0: PCI Configuration space: 0x00: 0xe4761180 0x00100007 0x06070000 0x00820000 0x10: 0xf2c01000 0x020000a0 0x20040403 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc 0x30: 0x00000000 0x0000fffc 0x00000000 0x04000113 0x40: 0x833810f7 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00710010 0x0590ffc0 0x000b2810 0x01076c11 0x90: 0x10110142 0x00000000 0xfe038001 0x48004000 0xa0: 0x00809805 0x00000000 0x00000000 0x00000000 0xb0: 0x30040001 0x00000000 0x08c608c6 0x00000000 0xc0: 0x00003000 0x00000001 0x5e000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x90000000 0xe0: 0x00020000 0x00000000 0x00000000 0x833810f7 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 sdhci0: mem 0xf2c00000-0xf2c000ff irq 16 at device 0.1 on pci3 sdhci0-slot0: 50MHz HS 4bits 3.3V DMA sdhci0-slot0: ============== REGISTER DUMP ============== sdhci0-slot0: Sys addr: 0x00000000 | Version: 0x00000400 sdhci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci0-slot0: Present: 0x01f20000 | Host ctl: 0x00000000 sdhci0-slot0: Power: 0x00000000 | Blk gap: 0x00000000 sdhci0-slot0: Wake-up: 0x00000000 | Clock: 0x00000000 sdhci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci0-slot0: Caps: 0x01e032b2 | Max curr: 0x00000040 sdhci0-slot0: =========================================== sdhci0: 1 slot(s) allocated sdhci0: [MPSAFE] sdhci0: [ITHREAD] ehci1: mem 0xf4827000-0xf48273ff irq 23 at device 29.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 54 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci1 pcib4: at device 30.0 on pci0 pcib4: domain 0 pcib4: secondary bus 12 pcib4: subordinate bus 12 pcib4: I/O decode 0xf000-0xfff pcib4: no prefetched decode pcib4: Subtractively decoded bridge. pci12: on pcib4 pci12: domain=0, physical bus=12 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xe090-0xe097,0xe080-0xe083,0xe070-0xe077,0xe060-0xe063,0xe020-0xe03f mem 0xf4826000-0xf48267ff irq 19 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 259 to local APIC 0 vector 55 ahci0: using IRQ 259 for MSI ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd EM 6ports ahci0: Caps2: APST ahci0: EM Caps: ALHD XMT SMB LED ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ahcich0: Caps: ichsmb0: port 0xe000-0xe01f mem 0xf4825000-0xf48250ff irq 18 at device 31.3 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 56 ichsmb0: [MPSAFE] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 pci0: at device 31.6 (no driver attached) pcib5: on acpi0 pcib5: could not get PCI interrupt routing table for \\_SB_.CPBG - AE_NOT_FOUND pci63: on pcib5 pci63: domain=0, physical bus=63 found-> vendor=0x8086, dev=0x2c62, revid=0x02 domain=0, bus=63, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d01, revid=0x02 domain=0, bus=63, slot=0, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d10, revid=0x02 domain=0, bus=63, slot=2, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d11, revid=0x02 domain=0, bus=63, slot=2, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d12, revid=0x02 domain=0, bus=63, slot=2, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d13, revid=0x02 domain=0, bus=63, slot=2, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) acpi_panasonic0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 8 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), MSI, 64bit, periodic hpet0: t1: irqs 0x00f00000 (0), MSI hpet0: t2: irqs 0x00f00800 (0), MSI hpet0: t3: irqs 0x00f01000 (0), MSI hpet0: t4: irqs 0x00000000 (0), MSI hpet0: t5: irqs 0x00000000 (0), MSI hpet0: t6: irqs 0x00000000 (0), MSI hpet0: t7: irqs 0x00000000 (0), MSI Timecounter "HPET" frequency 14318180 Hz quality 900 msi: routing MSI-X IRQ 260 to local APIC 0 vector 57 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 261 to local APIC 0 vector 58 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 262 to local APIC 0 vector 59 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 263 to local APIC 0 vector 60 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 264 to local APIC 0 vector 61 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 265 to local APIC 0 vector 62 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 266 to local APIC 0 vector 63 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 267 to local APIC 0 vector 64 hpet0: [MPSAFE] hpet0: [FILTER] Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 65 atrtc0: [MPSAFE] atrtc0: [FILTER] Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 attimer0: [MPSAFE] attimer0: [FILTER] ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 66 Event timer "i8254" frequency 1193182 Hz quality 100 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 67 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 68 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 acpi0: wakeup code va 0xffffff8071a1a000 pa 0x4000 isab0: found ICH10 or equivalent chipset: Intel QM57 watchdog timer isa_probe_children: disabling PnP devices ichwd0: on isa0 isab0: found ICH10 or equivalent chipset: Intel QM57 watchdog timer ichwd0: Intel QM57 watchdog timer (ICH10 or equivalent) ichwd0: timer disabled atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 isa_probe_children: probing PnP devices coretemp0: on cpu0 coretemp0: Tj(target) value 105 does not seem right. coretemp0: Setting TjMax=100 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 coretemp1: Tj(target) value 105 does not seem right. coretemp1: Setting TjMax=100 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 coretemp2: Tj(target) value 105 does not seem right. coretemp2: Setting TjMax=100 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 coretemp3: Tj(target) value 105 does not seem right. coretemp3: Setting TjMax=100 est3: on cpu3 p4tcc3: on cpu3 Device configuration finished. ZFS filesystem version 4 ZFS storage pool version 15 Timecounter "TSC" frequency 1197030122 Hz quality -100 lapic: Divisor 2, Frequency 66501657 Hz Timecounters tick every 1.000 msec crypto: Linux ELF exec handler installed IPsec: Initialized Security Association Processing. lo0: bpf attached hdac0: Probing codec #0... hdac0: HDA Codec #0: Conexant (Unknown) hdac0: HDA Codec ID: 0x14f15068 hdac0: Vendor: 0x14f1 hdac0: Device: 0x5068 hdac0: Revision: 0x03 hdac0: Stepping: 0x02 hdac0: PCI Subvendor: 0x833810f7 hdac0: Found audio FG nid=1 startnode=16 endnode=38 total=22 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0x40000004 NumGPIO=4 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdac0: nid 25 0x022110f0 as 15 seq 0 Headphones Jack jack 1 loc 2 color Black misc 0 hdac0: nid 26 0x02a110f0 as 15 seq 0 Mic Jack jack 1 loc 2 color Black misc 0 hdac0: nid 27 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 28 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 29 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 30 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 31 0x901701f0 as 15 seq 0 Speaker Fixed jack 7 loc 16 color Unknown misc 1 hdac0: nid 32 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 34 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 35 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: Patched pins configuration: hdac0: nid 25 0x022110f0 as 15 seq 0 Headphones Jack jack 1 loc 2 color Black misc 0 hdac0: nid 26 0x02a110f0 as 15 seq 0 Mic Jack jack 1 loc 2 color Black misc 0 hdac0: nid 27 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 28 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 29 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 30 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 31 0x901701f0 as 15 seq 0 Speaker Fixed jack 7 loc 16 color Unknown misc 1 hdac0: nid 32 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 34 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 35 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: 3 associations found: hdac0: Association 0 (15) out: hdac0: Pin nid=25 seq=0 hdac0: Association 1 (15) in: hdac0: Pin nid=26 seq=0 hdac0: Association 2 (15) out: hdac0: Pin nid=31 seq=0 hdac0: Tracing association 0 (15) hdac0: Pin 25 traced to DAC 16 hdac0: Association 0 (15) trace succeeded hdac0: Tracing association 1 (15) hdac0: Pin 26 traced to ADC 20 hdac0: Association 1 (15) trace succeeded hdac0: Tracing association 2 (15) hdac0: Pin 31 traced to DAC 17 hdac0: Association 2 (15) trace succeeded hdac0: Tracing input monitor hdac0: Tracing other input monitors hdac0: Tracing nid 26 to out hdac0: Tracing beeper hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: IN amp: 0x00000000 hdac0: OUT amp: 0x00000000 hdac0: hdac0: nid: 16 hdac0: Name: audio output hdac0: Widget cap: 0x00000c1d hdac0: LRSWAP PWR STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Output amp: 0x80034a4a hdac0: mute=1 step=74 size=3 offset=74 hdac0: hdac0: nid: 17 hdac0: Name: audio output hdac0: Widget cap: 0x00000c1d hdac0: LRSWAP PWR STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Output amp: 0x80034a4a hdac0: mute=1 step=74 size=3 offset=74 hdac0: hdac0: nid: 18 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000611 hdac0: PWR DIGITAL STEREO hdac0: Stream cap: 0x00000005 hdac0: AC3 PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: hdac0: nid: 19 hdac0: Name: beep widget hdac0: Widget cap: 0x0070000c hdac0: Association: -2 (0x00000000) hdac0: OSS: speaker (speaker) hdac0: Output amp: 0x000f0707 hdac0: mute=0 step=7 size=15 offset=7 hdac0: hdac0: nid: 20 hdac0: Name: audio input hdac0: Widget cap: 0x00100d1b hdac0: LRSWAP PWR STEREO hdac0: Association: 1 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Input amp: 0x8003504a hdac0: mute=1 step=80 size=3 offset=74 hdac0: connections: 4 hdac0: | hdac0: + <- nid=23 [audio selector] (selected) hdac0: + <- nid=24 [audio selector] hdac0: + [DISABLED] <- nid=35 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=36 [audio mixer] [DISABLED] hdac0: hdac0: nid: 21 [DISABLED] hdac0: Name: audio input hdac0: Widget cap: 0x00100d1b hdac0: LRSWAP PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Input amp: 0x8003504a hdac0: mute=1 step=80 size=3 offset=74 hdac0: connections: 4 hdac0: | hdac0: + [DISABLED] <- nid=23 [audio selector] (selected) hdac0: + <- nid=24 [audio selector] hdac0: + [DISABLED] <- nid=35 [pin: Other (None)] [DISABLED] hdac0: + <- nid=36 [audio mixer] [DISABLED] hdac0: hdac0: nid: 22 [DISABLED] hdac0: Name: audio input hdac0: Widget cap: 0x00100d1b hdac0: LRSWAP PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Input amp: 0x8003504a hdac0: mute=1 step=80 size=3 offset=74 hdac0: connections: 4 hdac0: | hdac0: + [DISABLED] <- nid=23 [audio selector] (selected) hdac0: + <- nid=24 [audio selector] hdac0: + [DISABLED] <- nid=35 [pin: Other (None)] [DISABLED] hdac0: + <- nid=36 [audio mixer] [DISABLED] hdac0: hdac0: nid: 23 hdac0: Name: audio selector hdac0: Widget cap: 0x0030050d hdac0: PWR STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic hdac0: Output amp: 0x00270400 hdac0: mute=0 step=4 size=39 offset=0 hdac0: connections: 4 hdac0: | hdac0: + <- nid=26 [pin: Mic (Black Jack)] (selected) hdac0: + [DISABLED] <- nid=27 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=30 [pin: Other (None)] [DISABLED] hdac0: hdac0: nid: 24 hdac0: Name: audio selector hdac0: Widget cap: 0x0030050d hdac0: PWR STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic hdac0: Output amp: 0x00270400 hdac0: mute=0 step=4 size=39 offset=0 hdac0: connections: 4 hdac0: | hdac0: + <- nid=26 [pin: Mic (Black Jack)] (selected) hdac0: + [DISABLED] <- nid=27 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=30 [pin: Other (None)] [DISABLED] hdac0: hdac0: nid: 25 hdac0: Name: pin: Headphones (Black Jack) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0000001c hdac0: PDC HP OUT hdac0: Pin config: 0x022110f0 hdac0: Pin control: 0x000000c0 HP OUT hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + [DISABLED] <- nid=17 [audio output] hdac0: hdac0: nid: 26 hdac0: Name: pin: Mic (Black Jack) hdac0: Widget cap: 0x00400481 hdac0: PWR UNSOL STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic (mic) hdac0: Pin cap: 0x00001324 hdac0: PDC IN VREF[ 50 80 HIZ ] hdac0: Pin config: 0x02a110f0 hdac0: Pin control: 0x00000024 IN VREFs hdac0: hdac0: nid: 27 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00011334 hdac0: PDC OUT IN VREF[ 50 80 HIZ ] EAPD hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: EAPD: 0x00000002 hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + <- nid=17 [audio output] hdac0: hdac0: nid: 28 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00000014 hdac0: PDC OUT hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + <- nid=17 [audio output] hdac0: hdac0: nid: 29 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00010034 hdac0: PDC OUT IN EAPD hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: EAPD: 0x00000002 hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + <- nid=17 [audio output] hdac0: hdac0: nid: 30 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400481 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00000024 hdac0: PDC IN hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 31 hdac0: Name: pin: Speaker (Fixed) hdac0: Widget cap: 0x00400501 hdac0: PWR STEREO hdac0: Association: 2 (0x00000001) hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x901701f0 hdac0: Pin control: 0x00000040 OUT hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=16 [audio output] hdac0: + <- nid=17 [audio output] (selected) hdac0: hdac0: nid: 32 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400781 hdac0: PWR DIGITAL UNSOL STEREO hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=18 [audio output] [DISABLED] hdac0: hdac0: nid: 33 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000611 hdac0: PWR DIGITAL STEREO hdac0: Stream cap: 0x00000005 hdac0: AC3 PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: hdac0: nid: 34 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400781 hdac0: PWR DIGITAL UNSOL STEREO hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=33 [audio output] [DISABLED] hdac0: hdac0: nid: 35 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x0040040b hdac0: PWR STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: Input amp: 0x002f0400 hdac0: mute=0 step=4 size=47 offset=0 hdac0: hdac0: nid: 36 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020050b hdac0: PWR STEREO hdac0: Input amp: 0x80034a4a hdac0: mute=1 step=74 size=3 offset=74 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=16 [audio output] hdac0: + [DISABLED] <- nid=17 [audio output] hdac0: hdac0: nid: 37 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: pcm0: at cad 0 nid 1 on hdac0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0560 pcm0: 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 16 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0160 pcm0: 16 20 24 bits, 44 48 96 KHz pcm0: ADC: 20 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=25 [pin: Headphones (Black Jack)] pcm0: | pcm0: + <- nid=16 [audio output] [src: pcm] pcm0: pcm0: Record: pcm0: pcm0: nid=20 [audio input] pcm0: | pcm0: + <- nid=23 [audio selector] [src: mic] pcm0: | pcm0: + <- nid=26 [pin: Mic (Black Jack)] [src: mic] pcm0: + <- nid=24 [audio selector] [src: mic] pcm0: | pcm0: + <- nid=26 [pin: Mic (Black Jack)] [src: mic] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- ctl 1 (nid 16 out): -74/0dB (75 steps) + mute pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- ctl 1 (nid 16 out): -74/0dB (75 steps) + mute pcm0: pcm0: Microphone Volume (OSS: mic) pcm0: | pcm0: +- ctl 7 (nid 23 out): 0/40dB (5 steps) pcm0: +- ctl 8 (nid 24 out): 0/40dB (5 steps) pcm0: pcm0: Speaker/Beep Volume (OSS: speaker) pcm0: | pcm0: +- ctl 3 (nid 19 out): -28/0dB (8 steps) pcm0: pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- ctl 4 (nid 20 in 0): -74/6dB (81 steps) + mute pcm0: +- ctl 8 (nid 24 out): 0/40dB (5 steps) pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "mic": pcm0: Mixer "rec": pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 35d0000, 4000; 0xffffff8071a46000 -> 35d0000 pcm0: sndbuf_setmap 35e0000, 4000; 0xffffff8071a56000 -> 35e0000 pcm1: at cad 0 nid 1 on hdac0 pcm1: +--------------------------------------+ pcm1: | DUMPING PCM Playback/Record Channels | pcm1: +--------------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x000e0560 pcm1: 16 20 24 bits, 44 48 96 192 KHz pcm1: DAC: 17 pcm1: pcm1: +-------------------------------+ pcm1: | DUMPING Playback/Record Paths | pcm1: +-------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: nid=31 [pin: Speaker (Fixed)] pcm1: | pcm1: + <- nid=17 [audio output] [src: pcm] pcm1: pcm1: +-------------------------+ pcm1: | DUMPING Volume Controls | pcm1: +-------------------------+ pcm1: pcm1: Master Volume (OSS: vol) pcm1: | pcm1: +- ctl 2 (nid 17 out): -74/0dB (75 steps) + mute pcm1: pcm1: PCM Volume (OSS: pcm) pcm1: | pcm1: +- ctl 2 (nid 17 out): -74/0dB (75 steps) + mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: clone manager: deadline=750ms flags=0x8000001e pcm1: sndbuf_setmap 35f0000, 4000; 0xffffff8071a66000 -> 35f0000 usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ahcich0: AHCI reset... ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ahcich0: SATA connect time=0ms status=00000123 ahcich0: ready wait time=1ms ahcich0: AHCI reset done: device found (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 acpi_acad0: acline initialization start battery0: battery initialization start ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 SATA 2.x device ada0: Serial Number DC01S00951SE951A2260GEOM: new disk ada0 ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C) pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-7 SATA 2.x device pass0: Serial Number DC01S00951SE951A2260 pass0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) pass0: Command Queueing enabled llaappiicc45:: C CMMCCI uIn muansmkaskeedd SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000100f2 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x05000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x04000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 4 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 5 vector 48 GEOM: ada0: partition 4 does not start on a track boundary.ioapic0: routing intpin 18 ( GEOM: ada0: partition 4 does not end on a track boundary.PCI IRQ 18 GEOM: ada0: partition 3 does not start on a track boundary.) to lapic 1 vector 49 GEOM: ada0: partition 3 does not end on a track boundary. ioapic0: routing intpin 19 ( GEOM: ada0: partition 2 does not start on a track boundary.PCI IRQ 19 GEOM: ada0: partition 2 does not end on a track boundary.) to lapic 4 vector 49 GEOM: ada0: partition 1 does not start on a track boundary. ioapic0: routing intpin 23 ( GEOM: ada0: partition 1 does not end on a track boundary.PCI IRQ 23 ) to lapic 5 vector 49 msi: Assigning MSI IRQ 257 to local APIC 1 vector 50 msi: Assigning MSI IRQ 258 to local APIC 4 vector 50 msi: Assigning MSI IRQ 259 to local APIC 5 vector 50acpi_acad0: msi: Assigning MSI-X IRQ 261 to local APIC 1 vector 51On Line msi: Assigning MSI-X IRQ 262 to local APIC 4 vector 51 acpi_acad0: msi: Assigning MSI-X IRQ 263 to local APIC 5 vector 51acline initialization done, tried 1 times Root mount waiting for: usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 Root mount waiting for: usbus1 usbus0 uhub2: 6 ports with 6 removable, self powered uhub3: 8 ports with 8 removable, self powered Trying to mount root from zfs:zoot/system ct_to_ts([2010-09-12 18:17:41]) = 1284315461.000000000 start_init: trying /sbin/init procfs registered em0: Link is up 1000 Mbps Full Duplex acpi_lid0: Lid closed PROCESSOR-0730 [382326] cpu_cx_cst : acpi_cpu0: Got C2 - 245 latency PROCESSOR-0730 [382812] cpu_cx_cst : acpi_cpu1: Got C2 - 245 latency PROCESSOR-0730 [383298] cpu_cx_cst : acpi_cpu2: Got C2 - 245 latency PROCESSOR-0730 [383941] cpu_cx_cst : acpi_cpu3: Got C2 - 245 latency ts_to_ct(1284315479.166767491) = [2010-09-12 18:17:59] --Multipart=_Sun__12_Sep_2010_18_26_25_+0900_Ounoful9LC=1Uxzy-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 09:29:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA6061065673; Sun, 12 Sep 2010 09:29:59 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 36CB88FC13; Sun, 12 Sep 2010 09:29:58 +0000 (UTC) Received: by bwz20 with SMTP id 20so367048bwz.13 for ; Sun, 12 Sep 2010 02:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=k49bwJJnmVfOCX+sGt5h8LaMEE62TecDgypLP0OcnJQ=; b=I+BtbASSC03EtIMPtN4T3mzJZhLRuzOGvBweVFoPHoaFCWla26uEvgMssLaDS2O5jN fQO6eXVIIEm9JUxR5kgCneE10GPORA5fgsyqDkJF9cbJmPOz/VhGeo5jkc9cSucJp8d0 gVFB0kirEMXGnkeI0c0/B3+v4aVrFv0A72Gj0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=BnX4ONJkGZBOWKzux913aYq0z9R2AqJEB6oyr4XSNzNsMmsUjYTuWiXb/L8UsMUDQi +S63p5vqfK9q+FXqcVhCXwgJLlVGOIB5QNgmNSgYP0NK60myhkRcxCoV0dFSKIrkEQq0 A7GiJV113ZU56rSceRbOiABArGMsZesjskFu0= Received: by 10.204.118.202 with SMTP id w10mr2150803bkq.40.1284283797892; Sun, 12 Sep 2010 02:29:57 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id x19sm3567621bkv.21.2010.09.12.02.29.56 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Sep 2010 02:29:56 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8C9D81.9090401@FreeBSD.org> Date: Sun, 12 Sep 2010 12:29:37 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Norikatsu Shigemura References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> In-Reply-To: <20100912182625.c49d3f1d.nork@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , Andriy Gapon Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 09:30:00 -0000 Norikatsu Shigemura wrote: > On Sun, 12 Sep 2010 11:12:20 +0300 > Alexander Motin wrote: >>>>> PROCESSOR-0696 [257314] cpu_cx_cst : acpi_cpu3: C2[1] not available. >>>>> PROCESSOR-0730 [257314] cpu_cx_cst : acpi_cpu3: Got C3 - 245 latency >>>> I think the issue is that C2 is not available for some reason and thus >>>> C3 can't be used either. The way to tell is to use acpidump and look for >>>> the CPU objects' _CST fields. >>> The "not available" message means that transition latency is defined too high. >>> That is, in this case latency is greater than 100 for C2. >> Just an idea. Limits of 100 and 1000 are defined for detection of >> C-states using P_LVLx_LAT registers. Because _CST explicitly specifies > > Oops! I forgot. Thank you, I tried. > But cx_lowest is not changed: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > $ sysctl -a | grep cx > hw.acpi.cpu.cx_lowest: C1 > dev.cpu.0.cx_supported: C1/3 C2/245 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% last 3641us > dev.cpu.1.cx_supported: C1/3 C2/245 > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_usage: 100.00% 0.00% last 798us > dev.cpu.2.cx_supported: C1/3 C2/245 > dev.cpu.2.cx_lowest: C1 > dev.cpu.2.cx_usage: 100.00% 0.00% last 158us > dev.cpu.3.cx_supported: C1/3 C2/245 > dev.cpu.3.cx_lowest: C1 > dev.cpu.3.cx_usage: 100.00% 0.00% last 227us > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - hw.acpi.cpu.cx_lowest has default in C1. Have you tried to rise it via sysctl? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 09:36:11 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2C3A106566C; Sun, 12 Sep 2010 09:36:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id AC80A8FC16; Sun, 12 Sep 2010 09:36:10 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA25347; Sun, 12 Sep 2010 12:36:08 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ouiym-000Fkb-GH; Sun, 12 Sep 2010 12:36:08 +0300 Message-ID: <4C8C9F06.4090505@icyb.net.ua> Date: Sun, 12 Sep 2010 12:36:06 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Norikatsu Shigemura References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> In-Reply-To: <20100912182625.c49d3f1d.nork@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , FreeBSD-Current Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 09:36:11 -0000 on 12/09/2010 12:26 Norikatsu Shigemura said the following: > Hi avg and mav. > > On Sun, 12 Sep 2010 11:12:20 +0300 > Alexander Motin wrote: >>>>> PROCESSOR-0696 [257314] cpu_cx_cst : acpi_cpu3: C2[1] not available. >>>>> PROCESSOR-0730 [257314] cpu_cx_cst : acpi_cpu3: Got C3 - 245 latency >>>> I think the issue is that C2 is not available for some reason and thus >>>> C3 can't be used either. The way to tell is to use acpidump and look for >>>> the CPU objects' _CST fields. >>> The "not available" message means that transition latency is defined too high. >>> That is, in this case latency is greater than 100 for C2. >> Just an idea. Limits of 100 and 1000 are defined for detection of >> C-states using P_LVLx_LAT registers. Because _CST explicitly specifies > > Oops! I forgot. Thank you, I tried. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > --- sys/dev/acpica/acpi_cpu.c.orig 2010-09-12 01:31:38.144243000 +0900 > +++ sys/dev/acpica/acpi_cpu.c 2010-09-12 18:06:14.651938193 +0900 > @@ -597,7 +597,7 @@ > /* Validate and allocate resources for C2 (P_LVL2). */ > gas.SpaceId = ACPI_ADR_SPACE_SYSTEM_IO; > gas.BitWidth = 8; > - if (AcpiGbl_FADT.C2Latency <= 100) { > + if (AcpiGbl_FADT.C2Latency <= 1000) { > gas.Address = sc->cpu_p_blk + 4; > acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &sc->cpu_rid, > &gas, &cx_ptr->p_lvlx, RF_SHAREABLE); > @@ -613,7 +613,7 @@ > return; > > /* Validate and allocate resources for C3 (P_LVL3). */ > - if (AcpiGbl_FADT.C3Latency <= 1000 && !(cpu_quirks & CPU_QUIRK_NO_C3)) { > + if (AcpiGbl_FADT.C3Latency <= 10000 && !(cpu_quirks & CPU_QUIRK_NO_C3)) { > gas.Address = sc->cpu_p_blk + 5; > acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &sc->cpu_rid, &gas, > &cx_ptr->p_lvlx, RF_SHAREABLE); The above changes are incorrect. > @@ -690,7 +690,7 @@ > sc->cpu_cx_count++; > continue; > case ACPI_STATE_C2: > - if (cx_ptr->trans_lat > 100) { > + if (cx_ptr->trans_lat > 1000) { > ACPI_DEBUG_PRINT((ACPI_DB_INFO, > "acpi_cpu%d: C2[%d] not available.\n", > device_get_unit(sc->cpu_dev), i)); > @@ -700,7 +700,7 @@ > break; > case ACPI_STATE_C3: > default: > - if (cx_ptr->trans_lat > 1000 || > + if (cx_ptr->trans_lat > 10000 || > (cpu_quirks & CPU_QUIRK_NO_C3) != 0) { > > ACPI_DEBUG_PRINT((ACPI_DB_INFO, You should simply remove the check instead of bumping the threshold. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > But cx_lowest is not changed: Why do you expect it to be changed? > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > $ sysctl -a | grep cx > hw.acpi.cpu.cx_lowest: C1 > dev.cpu.0.cx_supported: C1/3 C2/245 cx_supported has C2 now though. > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% last 3641us > dev.cpu.1.cx_supported: C1/3 C2/245 > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_usage: 100.00% 0.00% last 798us > dev.cpu.2.cx_supported: C1/3 C2/245 > dev.cpu.2.cx_lowest: C1 > dev.cpu.2.cx_usage: 100.00% 0.00% last 158us > dev.cpu.3.cx_supported: C1/3 C2/245 > dev.cpu.3.cx_lowest: C1 > dev.cpu.3.cx_usage: 100.00% 0.00% last 227us -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 09:38:15 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E1721065679; Sun, 12 Sep 2010 09:38:15 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 08A388FC08; Sun, 12 Sep 2010 09:38:13 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA25358; Sun, 12 Sep 2010 12:38:12 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ouj0m-000Fke-1i; Sun, 12 Sep 2010 12:38:12 +0300 Message-ID: <4C8C9F83.7090504@icyb.net.ua> Date: Sun, 12 Sep 2010 12:38:11 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Norikatsu Shigemura References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9D81.9090401@FreeBSD.org> In-Reply-To: <4C8C9D81.9090401@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , FreeBSD-Current Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 09:38:15 -0000 on 12/09/2010 12:29 Alexander Motin said the following: > hw.acpi.cpu.cx_lowest has default in C1. Have you tried to rise it via > sysctl? > And also check performance_cx_lowest, economy_cx_lowest in /etc/defaults/rc.conf. And /etc/rc.d/power_profile. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 09:39:26 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 782321065694; Sun, 12 Sep 2010 09:39:25 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Sun, 12 Sep 2010 18:39:19 +0900 From: Norikatsu Shigemura To: Alexander Motin Message-Id: <20100912183919.da8f052b.nork@FreeBSD.org> In-Reply-To: <4C8C9D81.9090401@FreeBSD.org> References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9D81.9090401@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , Andriy Gapon , nork@FreeBSD.org Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 09:39:26 -0000 Hi mav. On Sun, 12 Sep 2010 12:29:37 +0300 Alexander Motin wrote: > > But cx_lowest is not changed: > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > $ sysctl -a | grep cx > > hw.acpi.cpu.cx_lowest: C1 : > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > hw.acpi.cpu.cx_lowest has default in C1. Have you tried to rise it via > sysctl? Oops, I forgot usage of cx_lowest. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # sysctl hw.acpi.cpu.cx_lowest=C2 hw.acpi.cpu.cx_lowest: C1 -> C2 # sysctl -a | grep cx hw.acpi.cpu.cx_lowest: C2 dev.cpu.0.cx_supported: C1/3 C2/245 dev.cpu.0.cx_lowest: C2 dev.cpu.0.cx_usage: 19.34% 80.65% last 49us dev.cpu.1.cx_supported: C1/3 C2/245 dev.cpu.1.cx_lowest: C2 dev.cpu.1.cx_usage: 15.28% 84.71% last 922us dev.cpu.2.cx_supported: C1/3 C2/245 dev.cpu.2.cx_lowest: C2 dev.cpu.2.cx_usage: 77.90% 22.09% last 6034us dev.cpu.3.cx_supported: C1/3 C2/245 dev.cpu.3.cx_lowest: C2 dev.cpu.3.cx_usage: 80.28% 19.71% last 398us - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - And I can get CPU cooling ~50C(about 45C). Before sysctl cx_lowest=C2, I got 50C~! Thank you. -- Norikatsu Shigemura From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 10:00:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 721521065673; Sun, 12 Sep 2010 10:00:47 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C20D98FC1A; Sun, 12 Sep 2010 10:00:46 +0000 (UTC) Received: by bwz20 with SMTP id 20so379403bwz.13 for ; Sun, 12 Sep 2010 03:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=5ZMreQcB9ldDHeQ5lGj9dkgR/EkeoT4sGL/UO95rnkw=; b=RIaGKvbCeee1JICmAX7K1F5zeOep5W7UmMDApmiksE1URM1UxjphttDeG7iEyBYG4/ ULNU96cBWCdx0GeMnxpC4bYhuVe6eizR4gnME6wYBRqoeYaFXX8tXoBHxnd76I90ErS9 A1IU673eImN/ssNiFnc4ZLbWU34tu8gb3Kvaw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=aGphubmh6/yJeNSzRuXOWPkt9iWL+8LnRap6PDlHEgFGKaKNLV54l4e53VB64DEHau 8MxkYXvyapW7ivyf/bFMou851xhAmIVFzSvP9X00QwsgQkIOfyOnlGE+OqHu2SG9+no8 asoKP7ni6rheUidT9/5B5alqkMmvYT2LJolSs= Received: by 10.204.47.99 with SMTP id m35mr2141295bkf.106.1284285645235; Sun, 12 Sep 2010 03:00:45 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 24sm3577138bkr.7.2010.09.12.03.00.39 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Sep 2010 03:00:42 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8CA4B6.6090501@FreeBSD.org> Date: Sun, 12 Sep 2010 13:00:22 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Norikatsu Shigemura , FreeBSD-Current References: <4C8C9D81.9090401@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 10:00:47 -0000 Norikatsu Shigemura wrote: > On Sun, 12 Sep 2010 12:29:37 +0300 > Alexander Motin wrote: |>> hw.acpi.cpu.cx_lowest has default in C1. Have you tried to rise it via >> sysctl? > > Oops, I forgot usage of cx_lowest. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > # sysctl hw.acpi.cpu.cx_lowest=C2 > hw.acpi.cpu.cx_lowest: C1 -> C2 > # sysctl -a | grep cx > hw.acpi.cpu.cx_lowest: C2 > dev.cpu.0.cx_supported: C1/3 C2/245 > dev.cpu.0.cx_lowest: C2 > dev.cpu.0.cx_usage: 19.34% 80.65% last 49us > dev.cpu.1.cx_supported: C1/3 C2/245 > dev.cpu.1.cx_lowest: C2 > dev.cpu.1.cx_usage: 15.28% 84.71% last 922us > dev.cpu.2.cx_supported: C1/3 C2/245 > dev.cpu.2.cx_lowest: C2 > dev.cpu.2.cx_usage: 77.90% 22.09% last 6034us > dev.cpu.3.cx_supported: C1/3 C2/245 > dev.cpu.3.cx_lowest: C2 > dev.cpu.3.cx_usage: 80.28% 19.71% last 398us > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - `sysctl -a` is a bad tool to estimate C-states usage. It causes a lot of context switches, making data dirty. To get more precise data, try: sysctl hw.acpi.cpu.cx_lowest=C2 && sleep 10 && sysctl dev.cpu.0.cx_usage dev.cpu.1.cx_usage dev.cpu.2.cx_usage dev.cpu.3.cx_usage -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 10:05:44 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 2AFCE106566B; Sun, 12 Sep 2010 10:05:43 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Sun, 12 Sep 2010 19:05:37 +0900 From: Norikatsu Shigemura To: Andriy Gapon Message-Id: <20100912190537.621e357e.nork@FreeBSD.org> In-Reply-To: <4C8C9F06.4090505@icyb.net.ua> References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9F06.4090505@icyb.net.ua> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sun__12_Sep_2010_19_05_37_+0900_a8svMvsOO8prOeQU" Cc: Alexander Motin , FreeBSD-Current , nork@FreeBSD.org Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 10:05:44 -0000 This is a multi-part message in MIME format. --Multipart=_Sun__12_Sep_2010_19_05_37_+0900_a8svMvsOO8prOeQU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi avg. On Sun, 12 Sep 2010 12:36:06 +0300 Andriy Gapon wrote: > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > --- sys/dev/acpica/acpi_cpu.c.orig 2010-09-12 01:31:38.144243000 +0900 > > +++ sys/dev/acpica/acpi_cpu.c 2010-09-12 18:06:14.651938193 +0900 > > @@ -597,7 +597,7 @@ : > > gas.BitWidth = 8; > > - if (AcpiGbl_FADT.C2Latency <= 100) { > > + if (AcpiGbl_FADT.C2Latency <= 1000) { > > gas.Address = sc->cpu_p_blk + 4; > > acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &sc->cpu_rid, : > > /* Validate and allocate resources for C3 (P_LVL3). */ > > - if (AcpiGbl_FADT.C3Latency <= 1000 && !(cpu_quirks & CPU_QUIRK_NO_C3)) { > > + if (AcpiGbl_FADT.C3Latency <= 10000 && !(cpu_quirks & CPU_QUIRK_NO_C3)) { > > gas.Address = sc->cpu_p_blk + 5; > > acpi_bus_alloc_gas(sc->cpu_dev, &cx_ptr->res_type, &sc->cpu_rid, &gas, : > The above changes are incorrect. > > @@ -690,7 +690,7 @@ : > > case ACPI_STATE_C2: > > - if (cx_ptr->trans_lat > 100) { > > + if (cx_ptr->trans_lat > 1000) { > > ACPI_DEBUG_PRINT((ACPI_DB_INFO, : > > default: > > - if (cx_ptr->trans_lat > 1000 || > > + if (cx_ptr->trans_lat > 10000 || > > (cpu_quirks & CPU_QUIRK_NO_C3) != 0) { : > You should simply remove the check instead of bumping the threshold. I re-tried to test following patch. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --- sys/dev/acpica/acpi_cpu.c.orig 2010-09-12 01:31:38.144243000 +0900 +++ sys/dev/acpica/acpi_cpu.c 2010-09-12 18:47:56.057309965 +0900 @@ -690,19 +690,13 @@ sc->cpu_cx_count++; continue; case ACPI_STATE_C2: - if (cx_ptr->trans_lat > 100) { - ACPI_DEBUG_PRINT((ACPI_DB_INFO, - "acpi_cpu%d: C2[%d] not available.\n", - device_get_unit(sc->cpu_dev), i)); - continue; - } - sc->cpu_non_c3 = i; - break; + ACPI_DEBUG_PRINT((ACPI_DB_INFO, + "acpi_cpu%d: C2[%d] not available.\n", + device_get_unit(sc->cpu_dev), i)); + continue; case ACPI_STATE_C3: default: - if (cx_ptr->trans_lat > 1000 || - (cpu_quirks & CPU_QUIRK_NO_C3) != 0) { - + if (cpu_quirks & CPU_QUIRK_NO_C3) { ACPI_DEBUG_PRINT((ACPI_DB_INFO, "acpi_cpu%d: C3[%d] not available.\n", device_get_unit(sc->cpu_dev), i)); @@ -731,6 +725,9 @@ cx_ptr++; sc->cpu_cx_count++; } +else { +device_printf(sc->cpu_dev, "cx_ptr->p_lvlx IS NULL.\n"); +} } AcpiOsFree(buf.Pointer); - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - But not works:-(. Please see also attached dmesg.txt. > > But cx_lowest is not changed: > Why do you expect it to be changed? Sorry, I forgot about *_cx_lowest="LOW" in /etc/rc.conf. I wrote following setting to /etc/rc.conf. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - performance_cx_lowest="LOW" economy_cx_lowest="LOW" - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Thank you. -- Norikatsu Shigemura --Multipart=_Sun__12_Sep_2010_19_05_37_+0900_a8svMvsOO8prOeQU Content-Type: text/plain; name="dmesg.txt" Content-Disposition: attachment; filename="dmesg.txt" Content-Transfer-Encoding: 7bit ACPI set debug layer 'ACPI_ALL_DRIVERS ACPI_DB_INFO' level 'ACPI_LV_INFO' Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #3: Sun Sep 12 18:52:55 JST 2010 nork@pelsia.ninth-nine.com:/usr/obj/usr/src/sys/PELSIA amd64 Table 'FACP' at 0xda9aea98 Table 'APIC' at 0xda9aef18 Table 'MCFG' at 0xda9b0f18 Table 'HPET' at 0xda9b0e98 Table 'ASF!' at 0xda9af918 Table 'SLIC' at 0xda98ae18 Table 'SSDT' at 0xda9a9018 Table 'SSDT' at 0xda9a8c18 Table 'SSDT' at 0xda9a7c98 Table 'DMAR' at 0xda9a8f18 Table 'TCPA' at 0xda9b0e18 Table 'SSDT' at 0xda973a98 ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80be1000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff80be13b0. Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0xffffffff80be1a58. Preloaded elf obj module "/boot/kernel/krpc.ko" at 0xffffffff80be2088. Preloaded elf obj module "/boot/kernel/if_iwn.ko" at 0xffffffff80be26b0. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff80be2c58. Preloaded elf obj module "/boot/kernel/acpi_panasonic.ko" at 0xffffffff80be2cb8. Calibrating TSC clock ... TSC clock: 1197032730 Hz CPU: Intel(R) Core(TM) i7 CPU U 640 @ 1.20GHz (1197.03-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x20652 Family = 6 Model = 25 Stepping = 2 Features=0xbfebfbff Features2=0x298e3ff AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4303355904 (4104 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000097fff, 618496 bytes (151 pages) 0x0000000000c12000 - 0x00000000d254ffff, 3516129280 bytes (858430 pages) 0x00000000da969000 - 0x00000000da96dfff, 20480 bytes (5 pages) 0x00000000daa04000 - 0x00000000db3fffff, 10469376 bytes (2556 pages) 0x0000000100000000 - 0x0000000117feffff, 402587648 bytes (98288 pages) avail memory = 3907776512 (3726 MB) Event timer "LAPIC" frequency 0 Hz quality 600 ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 5 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 3 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 4 lapic0: CMCI unmasked x86bios: IVT 0x000000-0x0004ff at 0xffffff0000000000 x86bios: SSEG 0x001000-0x001fff at 0xffffff8000023000 x86bios: EBDA 0x09b000-0x09ffff at 0xffffff000009b000 x86bios: ROM 0x0a0000-0x0fefff at 0xffffff00000a0000 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf0410 00024 (v02 MATBIO) ACPI: XSDT 0xda9afe18 00084 (v01 MATBIO CFR9-1 06222004 MSFT 00010013) ACPI: FACP 0xda9aea98 000F4 (v04 MATBIO CFR9-1 06222004 MSFT 00010013) ACPI Warning: 32/64X FACS address mismatch in FADT - 0xDA9C1F40/0x00000000DA9D5D40, using 32 (20100806/tbfadt-586) ACPI: DSDT 0xda957018 119B4 (v01 MATBIO CFR9-1 00000000 INTL 20061109) ACPI: FACS 0xda9c1f40 00040 ACPI: APIC 0xda9aef18 0008C (v02 MATBIO CFR9-1 06222004 MSFT 00010013) ACPI: MCFG 0xda9b0f18 0003C (v01 MATBIO CFR9-1 06222004 MSFT 00000097) ACPI: HPET 0xda9b0e98 00038 (v01 MATBIO CFR9-1 06222004 AMI. 00000003) ACPI: ASF! 0xda9af918 00063 (v32 INTEL HCG 00000001 TFSM 000F4240) ACPI: SLIC 0xda98ae18 00176 (v01 MATBIO CFR9-1 06222004 AMI 00010013) ACPI: SSDT 0xda9a9018 009F1 (v01 PmRef CpuPm 00003000 INTL 20061109) ACPI: SSDT 0xda9a8c18 00259 (v01 PmRef Cpu0Tst 00003000 INTL 20061109) ACPI: SSDT 0xda9a7c98 0020F (v01 PmRef ApTst 00003000 INTL 20061109) ACPI: DMAR 0xda9a8f18 000B8 (v01 INTEL CP_DALE 00000001 INTL 00000001) ACPI: TCPA 0xda9b0e18 00032 (v02 MATBIO CFR9-1 00000001 MSFT 01000013) ACPI: SSDT 0xda973a98 002EF (v01 SataRe SataTabl 00001000 INTL 20061109) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 wlan: <802.11 Link Layer> random: cpuctl: access to MSR registers/cpuid info. VESA: INT 0x10 vector 0xc000:0x0014 VESA: information block 0000 56 45 53 41 00 03 00 01 00 02 01 00 00 00 40 00 0010 00 02 ff 01 00 01 3e 01 00 02 50 01 00 02 7c 01 0020 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040 60 01 61 01 62 01 63 01 64 01 65 01 66 01 67 01 0050 68 01 69 01 6a 01 6b 01 6c 01 6d 01 6e 01 6f 01 0060 70 01 71 01 3c 01 4d 01 5c 01 3a 01 4b 01 5a 01 0070 07 01 1a 01 1b 01 05 01 17 01 18 01 12 01 14 01 0080 15 01 01 01 03 01 11 01 ff ff 00 00 00 00 00 00 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100 49 6e 74 65 6c 28 52 29 49 72 6f 6e 6c 61 6b 65 0110 20 4d 6f 62 69 6c 65 20 47 72 61 70 68 69 63 73 0120 20 43 68 69 70 73 65 74 20 41 63 63 65 6c 65 72 0130 61 74 65 64 20 56 47 41 20 42 49 4f 53 00 49 6e 0140 74 65 6c 20 43 6f 72 70 6f 72 61 74 69 6f 6e 00 0150 49 6e 74 65 6c 28 52 29 49 72 6f 6e 6c 61 6b 65 0160 20 4d 6f 62 69 6c 65 20 47 72 61 70 68 69 63 73 0170 20 43 6f 6e 74 72 6f 6c 6c 65 72 00 48 61 72 64 0180 77 61 72 65 20 56 65 72 73 69 6f 6e 20 30 2e 30 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 9 mode(s) found VESA: v3.0, 32704k memory, flags:0x1, mode table:0xffffff8000079040 (2000040) VESA: Intel(R)Ironlake Mobile Graphics Chipset Accelerated VGA BIOS VESA: Intel Corporation Intel(R)Ironlake Mobile Graphics Controller Hardware Version 0.0 io: kbd: new array size 4 kbd1 at kbdmux0 mem: crypto: null: smbios0: at iomem 0xf0440-0xf045e on motherboard smbios0: Version: 2.6, BCD Revision: 2.6 aesni0: on motherboard crypto: assign aesni0 driver id 0, flags 16777216 crypto: aesni0 registers alg 11 flags 0 maxoplen 0 cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 1, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xf8000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI Error (dswload-0772): [DD02] Namespace lookup failure, AE_NOT_FOUND ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20100806/psloop-326) ACPI Error (psparse-0633): Method parse/execution failed [\\] (Node 0xffffffff808126a0), AE_NOT_FOUND ACPI Error (dswload-0772): [EHC1] Namespace lookup failure, AE_NOT_FOUND ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20100806/psloop-326) ACPI Error (psparse-0633): Method parse/execution failed [\\] (Node 0xffffffff808126a0), AE_NOT_FOUND ACPI Error (dswload-0772): [EHC1] Namespace lookup failure, AE_NOT_FOUND ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20100806/psloop-326) ACPI Error (psparse-0633): Method parse/execution failed [\\] (Node 0xffffffff808126a0), AE_NOT_FOUND ACPI: Executed 5 blocks of module-level executable AML code AcpiOsDerivePciId: \\_SB_.PCI0.SBUS.SMPB -> bus 0 dev 31 func 3 acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.CPBG.IMCH.PBUS -> bus 63 dev 0 func 1 AcpiOsDerivePciId: \\_SB_.PCI0.HBUS -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPCB.LPC0 -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPCB.LPC1 -> bus 0 dev 31 func 0 acpi0: reservation of e0000, 20000 (3) failed ACPI timer: 0/18 0/17 0/18 0/18 0/18 0/17 0/15 0/15 0/16 0/16 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 PROCESSOR-0311 [230584] cpu_attach : acpi_cpu0: P_BLK at 0x410/6 ACPI: SSDT 0xda9adc18 002AA (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 002AA (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: SSDT 0xda9ab618 005CD (v01 PmRef Cpu0Cst 00003001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 005CD (v01 PmRef Cpu0Cst 00003001 INTL 20061109) PROCESSOR-0695 [241753] cpu_cx_cst : acpi_cpu0: C2[1] not available. PROCESSOR-0724 [241753] cpu_cx_cst : acpi_cpu0: Got C3 - 245 latency cpu1: on acpi0 PROCESSOR-0311 [241991] cpu_attach : acpi_cpu1: P_BLK at 0x410/6 ACPI: SSDT 0xda9aca98 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: SSDT 0xda9aad98 00119 (v01 PmRef ApCst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00119 (v01 PmRef ApCst 00003000 INTL 20061109) PROCESSOR-0695 [254000] cpu_cx_cst : acpi_cpu1: C2[1] not available. PROCESSOR-0724 [254000] cpu_cx_cst : acpi_cpu1: Got C3 - 245 latency cpu2: on acpi0 PROCESSOR-0311 [254238] cpu_attach : acpi_cpu2: P_BLK at 0x410/6 PROCESSOR-0695 [255657] cpu_cx_cst : acpi_cpu2: C2[1] not available. PROCESSOR-0724 [255657] cpu_cx_cst : acpi_cpu2: Got C3 - 245 latency cpu3: on acpi0 PROCESSOR-0311 [255895] cpu_attach : acpi_cpu3: P_BLK at 0x410/6 PROCESSOR-0695 [257314] cpu_cx_cst : acpi_cpu3: C2[1] not available. PROCESSOR-0724 [257314] cpu_cx_cst : acpi_cpu3: Got C3 - 245 latency acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 4 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 4 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 5 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 3 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x0044, revid=0x12 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x0046, revid=0x12 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xf0000000, size 22, enabled map[18]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled map[20]: type I/O Port, range 32, base 0xe0b0, size 3, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x10ea, revid=0x06 domain=0, bus=0, slot=25, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf4800000, size 17, enabled map[14]: type Memory, range 32, base 0xf4829000, size 12, enabled map[18]: type I/O Port, range 32, base 0xe040, size 5, enabled pcib0: matched entry for 0.25.INTA pcib0: slot 25 INTA hardwired to IRQ 20 found-> vendor=0x8086, dev=0x3b3c, revid=0x06 domain=0, bus=0, slot=26, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf4828000, size 10, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3b56, revid=0x06 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf4820000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x3b42, revid=0x06 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x10 (4000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3b46, revid=0x06 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x10 (4000 ns), maxlat=0x00 (0 ns) intpin=c, irq=4 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3b48, revid=0x06 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x10 (4000 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3b34, revid=0x06 domain=0, bus=0, slot=29, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf4827000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xa6 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x10 (4000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3b07, revid=0x06 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3b2f, revid=0x06 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0xe090, size 3, enabled map[14]: type I/O Port, range 32, base 0xe080, size 2, enabled map[18]: type I/O Port, range 32, base 0xe070, size 3, enabled map[1c]: type I/O Port, range 32, base 0xe060, size 2, enabled map[20]: type I/O Port, range 32, base 0xe020, size 5, enabled map[24]: type Memory, range 32, base 0xf4826000, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3b30, revid=0x06 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=4 map[10]: type Memory, range 64, base 0xf4825000, size 8, enabled map[20]: type I/O Port, range 32, base 0xe000, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3b32, revid=0x06 domain=0, bus=0, slot=31, func=6 class=11-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=4 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xf4824000, size 12, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 vgapci0: port 0xe0b0-0xe0b7 mem 0xf0000000-0xf03fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 32764k stolen memory em0: port 0xe040-0xe05f mem 0xf4800000-0xf481ffff,0xf4829000-0xf4829fff irq 20 at device 25.0 on pci0 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 49 em0: using IRQ 256 for MSI em0: Using an MSI interrupt em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:1b:d3:89:b8:6e ehci0: mem 0xf4828000-0xf48283ff irq 16 at device 26.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 50 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: on ehci0 hdac0: mem 0xf4820000-0xf4823fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 51 hdac0: using IRQ 257 for MSI hdac0: [MPSAFE] hdac0: [ITHREAD] hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib1: irq 16 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0xf4600000-0xf47fffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 18 at device 28.2 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xc000-0xcfff pcib2: memory decode 0xf4400000-0xf45fffff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x8086, dev=0x422c, revid=0x35 domain=0, bus=2, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=4 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf4400000, size 13, enabled pcib2: requested memory range 0xf4400000-0xf4401fff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 iwn0: mem 0xf4400000-0xf4401fff irq 18 at device 0.0 on pci2 iwn0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 258 to local APIC 0 vector 52 iwn0: using IRQ 258 for MSI iwn0: MIMO 2T2R, MoW, address 00:23:14:21:69:00 iwn0: [MPSAFE] iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps pcib3: irq 19 at device 28.3 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 11 pcib3: I/O decode 0xa000-0xbfff pcib3: memory decode 0xf0400000-0xf43fffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x1180, dev=0xe476, revid=0x00 domain=0, bus=3, slot=0, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x04 (1000 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf2c01000, size 12, enabled pcib3: requested memory range 0xf2c01000-0xf2c01fff: good pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 19 found-> vendor=0x1180, dev=0xe822, revid=0x02 domain=0, bus=3, slot=0, func=1 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf2c00000, size 8, enabled pcib3: requested memory range 0xf2c00000-0xf2c000ff: good pcib3: matched entry for 3.0.INTB pcib3: slot 0 INTB hardwired to IRQ 16 cbb0: mem 0xf2c01000-0xf2c01fff irq 19 at device 0.0 on pci3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 53 cbb0: [MPSAFE] cbb0: [FILTER] cbb0: PCI Configuration space: 0x00: 0xe4761180 0x00100007 0x06070000 0x00820000 0x10: 0xf2c01000 0x020000a0 0x20040403 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc 0x30: 0x00000000 0x0000fffc 0x00000000 0x04000113 0x40: 0x833810f7 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00710010 0x0590ffc0 0x000b2810 0x01076c11 0x90: 0x10110142 0x00000000 0xfe038001 0x48004000 0xa0: 0x00809805 0x00000000 0x00000000 0x00000000 0xb0: 0x30040001 0x00000000 0x08c608c6 0x00000000 0xc0: 0x00003000 0x00000001 0x5e000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x90000000 0xe0: 0x00020000 0x00000000 0x00000000 0x833810f7 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 sdhci0: mem 0xf2c00000-0xf2c000ff irq 16 at device 0.1 on pci3 sdhci0-slot0: 50MHz HS 4bits 3.3V DMA sdhci0-slot0: ============== REGISTER DUMP ============== sdhci0-slot0: Sys addr: 0x00000000 | Version: 0x00000400 sdhci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci0-slot0: Present: 0x01f20000 | Host ctl: 0x00000000 sdhci0-slot0: Power: 0x00000000 | Blk gap: 0x00000000 sdhci0-slot0: Wake-up: 0x00000000 | Clock: 0x00000000 sdhci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci0-slot0: Caps: 0x01e032b2 | Max curr: 0x00000040 sdhci0-slot0: =========================================== sdhci0: 1 slot(s) allocated sdhci0: [MPSAFE] sdhci0: [ITHREAD] ehci1: mem 0xf4827000-0xf48273ff irq 23 at device 29.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 54 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci1 pcib4: at device 30.0 on pci0 pcib4: domain 0 pcib4: secondary bus 12 pcib4: subordinate bus 12 pcib4: I/O decode 0xf000-0xfff pcib4: no prefetched decode pcib4: Subtractively decoded bridge. pci12: on pcib4 pci12: domain=0, physical bus=12 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xe090-0xe097,0xe080-0xe083,0xe070-0xe077,0xe060-0xe063,0xe020-0xe03f mem 0xf4826000-0xf48267ff irq 19 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 259 to local APIC 0 vector 55 ahci0: using IRQ 259 for MSI ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd EM 6ports ahci0: Caps2: APST ahci0: EM Caps: ALHD XMT SMB LED ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ahcich0: Caps: ichsmb0: port 0xe000-0xe01f mem 0xf4825000-0xf48250ff irq 18 at device 31.3 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 56 ichsmb0: [MPSAFE] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 pci0: at device 31.6 (no driver attached) pcib5: on acpi0 pcib5: could not get PCI interrupt routing table for \\_SB_.CPBG - AE_NOT_FOUND pci63: on pcib5 pci63: domain=0, physical bus=63 found-> vendor=0x8086, dev=0x2c62, revid=0x02 domain=0, bus=63, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d01, revid=0x02 domain=0, bus=63, slot=0, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d10, revid=0x02 domain=0, bus=63, slot=2, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d11, revid=0x02 domain=0, bus=63, slot=2, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d12, revid=0x02 domain=0, bus=63, slot=2, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d13, revid=0x02 domain=0, bus=63, slot=2, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) acpi_panasonic0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 8 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), MSI, 64bit, periodic hpet0: t1: irqs 0x00f00000 (0), MSI hpet0: t2: irqs 0x00f00800 (0), MSI hpet0: t3: irqs 0x00f01000 (0), MSI hpet0: t4: irqs 0x00000000 (0), MSI hpet0: t5: irqs 0x00000000 (0), MSI hpet0: t6: irqs 0x00000000 (0), MSI hpet0: t7: irqs 0x00000000 (0), MSI Timecounter "HPET" frequency 14318180 Hz quality 900 msi: routing MSI-X IRQ 260 to local APIC 0 vector 57 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 261 to local APIC 0 vector 58 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 262 to local APIC 0 vector 59 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 263 to local APIC 0 vector 60 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 264 to local APIC 0 vector 61 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 265 to local APIC 0 vector 62 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 266 to local APIC 0 vector 63 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 267 to local APIC 0 vector 64 hpet0: [MPSAFE] hpet0: [FILTER] Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 65 atrtc0: [MPSAFE] atrtc0: [FILTER] Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 attimer0: [MPSAFE] attimer0: [FILTER] ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 66 Event timer "i8254" frequency 1193182 Hz quality 100 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 67 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 68 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 acpi0: wakeup code va 0xffffff8071a1a000 pa 0x4000 isab0: found ICH10 or equivalent chipset: Intel QM57 watchdog timer isa_probe_children: disabling PnP devices ichwd0: on isa0 isab0: found ICH10 or equivalent chipset: Intel QM57 watchdog timer ichwd0: Intel QM57 watchdog timer (ICH10 or equivalent) ichwd0: timer disabled atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 isa_probe_children: probing PnP devices coretemp0: on cpu0 coretemp0: Tj(target) value 105 does not seem right. coretemp0: Setting TjMax=100 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 coretemp1: Tj(target) value 105 does not seem right. coretemp1: Setting TjMax=100 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 coretemp2: Tj(target) value 105 does not seem right. coretemp2: Setting TjMax=100 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 coretemp3: Tj(target) value 105 does not seem right. coretemp3: Setting TjMax=100 est3: on cpu3 p4tcc3: on cpu3 Device configuration finished. ZFS filesystem version 4 ZFS storage pool version 15 Timecounter "TSC" frequency 1197032730 Hz quality -100 lapic: Divisor 2, Frequency 66501806 Hz Timecounters tick every 1.000 msec crypto: Linux ELF exec handler installed IPsec: Initialized Security Association Processing. lo0: bpf attached hdac0: Probing codec #0... hdac0: HDA Codec #0: Conexant (Unknown) hdac0: HDA Codec ID: 0x14f15068 hdac0: Vendor: 0x14f1 hdac0: Device: 0x5068 hdac0: Revision: 0x03 hdac0: Stepping: 0x02 hdac0: PCI Subvendor: 0x833810f7 hdac0: Found audio FG nid=1 startnode=16 endnode=38 total=22 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0x40000004 NumGPIO=4 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdac0: nid 25 0x022110f0 as 15 seq 0 Headphones Jack jack 1 loc 2 color Black misc 0 hdac0: nid 26 0x02a110f0 as 15 seq 0 Mic Jack jack 1 loc 2 color Black misc 0 hdac0: nid 27 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 28 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 29 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 30 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 31 0x901701f0 as 15 seq 0 Speaker Fixed jack 7 loc 16 color Unknown misc 1 hdac0: nid 32 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 34 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 35 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: Patched pins configuration: hdac0: nid 25 0x022110f0 as 15 seq 0 Headphones Jack jack 1 loc 2 color Black misc 0 hdac0: nid 26 0x02a110f0 as 15 seq 0 Mic Jack jack 1 loc 2 color Black misc 0 hdac0: nid 27 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 28 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 29 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 30 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 31 0x901701f0 as 15 seq 0 Speaker Fixed jack 7 loc 16 color Unknown misc 1 hdac0: nid 32 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 34 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 35 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: 3 associations found: hdac0: Association 0 (15) out: hdac0: Pin nid=25 seq=0 hdac0: Association 1 (15) in: hdac0: Pin nid=26 seq=0 hdac0: Association 2 (15) out: hdac0: Pin nid=31 seq=0 hdac0: Tracing association 0 (15) hdac0: Pin 25 traced to DAC 16 hdac0: Association 0 (15) trace succeeded hdac0: Tracing association 1 (15) hdac0: Pin 26 traced to ADC 20 hdac0: Association 1 (15) trace succeeded hdac0: Tracing association 2 (15) hdac0: Pin 31 traced to DAC 17 hdac0: Association 2 (15) trace succeeded hdac0: Tracing input monitor hdac0: Tracing other input monitors hdac0: Tracing nid 26 to out hdac0: Tracing beeper hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: IN amp: 0x00000000 hdac0: OUT amp: 0x00000000 hdac0: hdac0: nid: 16 hdac0: Name: audio output hdac0: Widget cap: 0x00000c1d hdac0: LRSWAP PWR STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Output amp: 0x80034a4a hdac0: mute=1 step=74 size=3 offset=74 hdac0: hdac0: nid: 17 hdac0: Name: audio output hdac0: Widget cap: 0x00000c1d hdac0: LRSWAP PWR STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Output amp: 0x80034a4a hdac0: mute=1 step=74 size=3 offset=74 hdac0: hdac0: nid: 18 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000611 hdac0: PWR DIGITAL STEREO hdac0: Stream cap: 0x00000005 hdac0: AC3 PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: hdac0: nid: 19 hdac0: Name: beep widget hdac0: Widget cap: 0x0070000c hdac0: Association: -2 (0x00000000) hdac0: OSS: speaker (speaker) hdac0: Output amp: 0x000f0707 hdac0: mute=0 step=7 size=15 offset=7 hdac0: hdac0: nid: 20 hdac0: Name: audio input hdac0: Widget cap: 0x00100d1b hdac0: LRSWAP PWR STEREO hdac0: Association: 1 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Input amp: 0x8003504a hdac0: mute=1 step=80 size=3 offset=74 hdac0: connections: 4 hdac0: | hdac0: + <- nid=23 [audio selector] (selected) hdac0: + <- nid=24 [audio selector] hdac0: + [DISABLED] <- nid=35 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=36 [audio mixer] [DISABLED] hdac0: hdac0: nid: 21 [DISABLED] hdac0: Name: audio input hdac0: Widget cap: 0x00100d1b hdac0: LRSWAP PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Input amp: 0x8003504a hdac0: mute=1 step=80 size=3 offset=74 hdac0: connections: 4 hdac0: | hdac0: + [DISABLED] <- nid=23 [audio selector] (selected) hdac0: + <- nid=24 [audio selector] hdac0: + [DISABLED] <- nid=35 [pin: Other (None)] [DISABLED] hdac0: + <- nid=36 [audio mixer] [DISABLED] hdac0: hdac0: nid: 22 [DISABLED] hdac0: Name: audio input hdac0: Widget cap: 0x00100d1b hdac0: LRSWAP PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Input amp: 0x8003504a hdac0: mute=1 step=80 size=3 offset=74 hdac0: connections: 4 hdac0: | hdac0: + [DISABLED] <- nid=23 [audio selector] (selected) hdac0: + <- nid=24 [audio selector] hdac0: + [DISABLED] <- nid=35 [pin: Other (None)] [DISABLED] hdac0: + <- nid=36 [audio mixer] [DISABLED] hdac0: hdac0: nid: 23 hdac0: Name: audio selector hdac0: Widget cap: 0x0030050d hdac0: PWR STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic hdac0: Output amp: 0x00270400 hdac0: mute=0 step=4 size=39 offset=0 hdac0: connections: 4 hdac0: | hdac0: + <- nid=26 [pin: Mic (Black Jack)] (selected) hdac0: + [DISABLED] <- nid=27 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=30 [pin: Other (None)] [DISABLED] hdac0: hdac0: nid: 24 hdac0: Name: audio selector hdac0: Widget cap: 0x0030050d hdac0: PWR STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic hdac0: Output amp: 0x00270400 hdac0: mute=0 step=4 size=39 offset=0 hdac0: connections: 4 hdac0: | hdac0: + <- nid=26 [pin: Mic (Black Jack)] (selected) hdac0: + [DISABLED] <- nid=27 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=30 [pin: Other (None)] [DISABLED] hdac0: hdac0: nid: 25 hdac0: Name: pin: Headphones (Black Jack) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0000001c hdac0: PDC HP OUT hdac0: Pin config: 0x022110f0 hdac0: Pin control: 0x000000c0 HP OUT hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + [DISABLED] <- nid=17 [audio output] hdac0: hdac0: nid: 26 hdac0: Name: pin: Mic (Black Jack) hdac0: Widget cap: 0x00400481 hdac0: PWR UNSOL STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic (mic) hdac0: Pin cap: 0x00001324 hdac0: PDC IN VREF[ 50 80 HIZ ] hdac0: Pin config: 0x02a110f0 hdac0: Pin control: 0x00000024 IN VREFs hdac0: hdac0: nid: 27 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00011334 hdac0: PDC OUT IN VREF[ 50 80 HIZ ] EAPD hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: EAPD: 0x00000002 hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + <- nid=17 [audio output] hdac0: hdac0: nid: 28 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00000014 hdac0: PDC OUT hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + <- nid=17 [audio output] hdac0: hdac0: nid: 29 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00010034 hdac0: PDC OUT IN EAPD hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: EAPD: 0x00000002 hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + <- nid=17 [audio output] hdac0: hdac0: nid: 30 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400481 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00000024 hdac0: PDC IN hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 31 hdac0: Name: pin: Speaker (Fixed) hdac0: Widget cap: 0x00400501 hdac0: PWR STEREO hdac0: Association: 2 (0x00000001) hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x901701f0 hdac0: Pin control: 0x00000040 OUT hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=16 [audio output] hdac0: + <- nid=17 [audio output] (selected) hdac0: hdac0: nid: 32 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400781 hdac0: PWR DIGITAL UNSOL STEREO hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=18 [audio output] [DISABLED] hdac0: hdac0: nid: 33 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000611 hdac0: PWR DIGITAL STEREO hdac0: Stream cap: 0x00000005 hdac0: AC3 PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: hdac0: nid: 34 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400781 hdac0: PWR DIGITAL UNSOL STEREO hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=33 [audio output] [DISABLED] hdac0: hdac0: nid: 35 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x0040040b hdac0: PWR STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: Input amp: 0x002f0400 hdac0: mute=0 step=4 size=47 offset=0 hdac0: hdac0: nid: 36 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020050b hdac0: PWR STEREO hdac0: Input amp: 0x80034a4a hdac0: mute=1 step=74 size=3 offset=74 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=16 [audio output] hdac0: + [DISABLED] <- nid=17 [audio output] hdac0: hdac0: nid: 37 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: pcm0: at cad 0 nid 1 on hdac0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0560 pcm0: 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 16 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0160 pcm0: 16 20 24 bits, 44 48 96 KHz pcm0: ADC: 20 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=25 [pin: Headphones (Black Jack)] pcm0: | pcm0: + <- nid=16 [audio output] [src: pcm] pcm0: pcm0: Record: pcm0: pcm0: nid=20 [audio input] pcm0: | pcm0: + <- nid=23 [audio selector] [src: mic] pcm0: | pcm0: + <- nid=26 [pin: Mic (Black Jack)] [src: mic] pcm0: + <- nid=24 [audio selector] [src: mic] pcm0: | pcm0: + <- nid=26 [pin: Mic (Black Jack)] [src: mic] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- ctl 1 (nid 16 out): -74/0dB (75 steps) + mute pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- ctl 1 (nid 16 out): -74/0dB (75 steps) + mute pcm0: pcm0: Microphone Volume (OSS: mic) pcm0: | pcm0: +- ctl 7 (nid 23 out): 0/40dB (5 steps) pcm0: +- ctl 8 (nid 24 out): 0/40dB (5 steps) pcm0: pcm0: Speaker/Beep Volume (OSS: speaker) pcm0: | pcm0: +- ctl 3 (nid 19 out): -28/0dB (8 steps) pcm0: pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- ctl 4 (nid 20 in 0): -74/6dB (81 steps) + mute pcm0: +- ctl 8 (nid 24 out): 0/40dB (5 steps) pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "mic": pcm0: Mixer "rec": pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 3b60000, 4000; 0xffffff8071a46000 -> 3b60000 pcm0: sndbuf_setmap 3b70000, 4000; 0xffffff8071a56000 -> 3b70000 pcm1: at cad 0 nid 1 on hdac0 pcm1: +--------------------------------------+ pcm1: | DUMPING PCM Playback/Record Channels | pcm1: +--------------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x000e0560 pcm1: 16 20 24 bits, 44 48 96 192 KHz pcm1: DAC: 17 pcm1: pcm1: +-------------------------------+ pcm1: | DUMPING Playback/Record Paths | pcm1: +-------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: nid=31 [pin: Speaker (Fixed)] pcm1: | pcm1: + <- nid=17 [audio output] [src: pcm] pcm1: pcm1: +-------------------------+ pcm1: | DUMPING Volume Controls | pcm1: +-------------------------+ pcm1: pcm1: Master Volume (OSS: vol) pcm1: | pcm1: +- ctl 2 (nid 17 out): -74/0dB (75 steps) + mute pcm1: pcm1: PCM Volume (OSS: pcm) pcm1: | pcm1: +- ctl 2 (nid 17 out): -74/0dB (75 steps) + mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: clone manager: deadline=750ms flags=0x8000001e pcm1: sndbuf_setmap 3b90000, 4000; 0xffffff8071a66000 -> 3b90000 usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ahcich0: AHCI reset... ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ahcich0: SATA connect time=0ms status=00000123 ahcich0: ready wait time=0ms ahcich0: AHCI reset done: device found (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 acpi_acad0: acline initialization start battery0: battery initialization start ada0 at ahcich0 bus 0 scbus0 target 0 lun 0GEOM: new disk ada0 ada0: ATA-7 SATA 2.x device ada0: Serial Number DC01S00951SE951A2260 ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C) pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-7 SATA 2.x device pass0: Serial Number DC01S00951SE951A2260 pass0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) pass0: Command Queueing enabled lapilcapic54:: CCMMCCII uunnmmaasskkeedd SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000100f2 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x04000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x05000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 4 vector 48acpi_acad0: ioapic0: routing intpin 12 (On LineISA IRQ 12 acpi_acad0: ) to lapic 5 vector 48acline initialization done, tried 1 times GEOM: ada0: partition 4 does not start on a track boundary.ioapic0: routing intpin 18 ( PCI IRQ 18 GEOM: ada0: partition 4 does not end on a track boundary.) to lapic 1 vector 49 GEOM: ada0: partition 3 does not start on a track boundary. ioapic0: routing intpin 19 ( GEOM: ada0: partition 3 does not end on a track boundary.PCI IRQ 19 GEOM: ada0: partition 2 does not start on a track boundary.) to lapic 4 vector 49 GEOM: ada0: partition 2 does not end on a track boundary. ioapic0: routing intpin 23 ( GEOM: ada0: partition 1 does not start on a track boundary.PCI IRQ 23 GEOM: ada0: partition 1 does not end on a track boundary.) to lapic 5 vector 49 msi: Assigning MSI IRQ 257 to local APIC 1 vector 50 msi: Assigning MSI IRQ 258 to local APIC 4 vector 50 msi: Assigning MSI IRQ 259 to local APIC 5 vector 50 msi: Assigning MSI-X IRQ 261 to local APIC 1 vector 51 msi: Assigning MSI-X IRQ 262 to local APIC 4 vector 51 msi: Assigning MSI-X IRQ 263 to local APIC 5 vector 51 Root mount waiting for: usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 Root mount waiting for: usbus1 usbus0 uhub3: 8 ports with 8 removable, self powered Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 uhub_attach: getting hub descriptor failed,error=USB_ERR_TIMEOUT device_attach: uhub2 attach returned 6 uhub2: on usbus0 Root mount waiting for: usbus0 uhub2: 6 ports with 6 removable, self powered Trying to mount root from zfs:zoot/system ct_to_ts([2010-09-12 18:56:42]) = 1284317802.000000000 start_init: trying /sbin/init procfs registered em0: Link is up 1000 Mbps Full Duplex PROCESSOR-0695 [382219] cpu_cx_cst : acpi_cpu0: C2[1] not available. PROCESSOR-0695 [382703] cpu_cx_cst : acpi_cpu1: C2[1] not available. PROCESSOR-0695 [383190] cpu_cx_cst : acpi_cpu2: C2[1] not available. PROCESSOR-0695 [383825] cpu_cx_cst : acpi_cpu3: C2[1] not available. acpi_lid0: Lid closed ts_to_ct(1284317819.386966403) = [2010-09-12 18:56:59] --Multipart=_Sun__12_Sep_2010_19_05_37_+0900_a8svMvsOO8prOeQU-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 10:09:54 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 7D7DB106566C; Sun, 12 Sep 2010 10:09:53 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Sun, 12 Sep 2010 19:09:52 +0900 From: Norikatsu Shigemura To: Andriy Gapon Message-Id: <20100912190952.8c0d5726.nork@FreeBSD.org> In-Reply-To: <20100912190537.621e357e.nork@FreeBSD.org> References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9F06.4090505@icyb.net.ua> <20100912190537.621e357e.nork@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alexander Motin , FreeBSD-Current , Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 10:09:54 -0000 Hi avg. On Sun, 12 Sep 2010 19:05:37 +0900 Norikatsu Shigemura wrote: > I re-tried to test following patch. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > --- sys/dev/acpica/acpi_cpu.c.orig 2010-09-12 01:31:38.144243000 +0900 > +++ sys/dev/acpica/acpi_cpu.c 2010-09-12 18:47:56.057309965 +0900 > @@ -690,19 +690,13 @@ > sc->cpu_cx_count++; > continue; > case ACPI_STATE_C2: : > + ACPI_DEBUG_PRINT((ACPI_DB_INFO, > + "acpi_cpu%d: C2[%d] not available.\n", > + device_get_unit(sc->cpu_dev), i)); > + continue; Logic is mistake. I'll re-make a patch and retry. Thank you. -- Norikatsu Shigemura From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 10:20:14 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id C0FB4106564A; Sun, 12 Sep 2010 10:20:13 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Sun, 12 Sep 2010 19:20:07 +0900 From: Norikatsu Shigemura To: Alexander Motin Message-Id: <20100912192007.603e553e.nork@FreeBSD.org> In-Reply-To: <4C8CA4B6.6090501@FreeBSD.org> References: <4C8C9D81.9090401@FreeBSD.org> <4C8CA4B6.6090501@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , nork@FreeBSD.org Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 10:20:14 -0000 Hi mav. On Sun, 12 Sep 2010 13:00:22 +0300 Alexander Motin wrote: > `sysctl -a` is a bad tool to estimate C-states usage. It causes a lot of > context switches, making data dirty. To get more precise data, try: > sysctl hw.acpi.cpu.cx_lowest=C2 && sleep 10 && sysctl dev.cpu.0.cx_usage > dev.cpu.1.cx_usage dev.cpu.2.cx_usage dev.cpu.3.cx_usage I tried, got following results: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # sysctl hw.acpi.cpu.cx_lowest=C2 && sleep 10 && sysctl dev.cpu.0.cx_usage dev.cpu.1.cx_usage dev.cpu.2.cx_usage dev.cpu.3.cx_usage hw.acpi.cpu.cx_lowest: C3 -> C2 dev.cpu.0.cx_usage: 2.37% 97.62% last 3028us dev.cpu.1.cx_usage: 0.87% 99.12% last 4379us dev.cpu.2.cx_usage: 0.54% 99.45% last 14314us dev.cpu.3.cx_usage: 1.36% 98.63% last 16982us # sysctl hw.acpi.cpu.cx_lowest=C2 && sleep 10 && sysctl dev.cpu.0.cx_usage dev.cpu.1.cx_usage dev.cpu.2.cx_usage dev.cpu.3.cx_usage hw.acpi.cpu.cx_lowest: C2 -> C2 dev.cpu.0.cx_usage: 1.82% 98.17% last 2672us dev.cpu.1.cx_usage: 0.71% 99.28% last 3413us dev.cpu.2.cx_usage: 0.00% 100.00% last 13543us dev.cpu.3.cx_usage: 2.00% 97.99% last 16190us - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - That's perfect! Thank you. -- Norikatsu Shigemura From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 10:25:25 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 685821065670; Sun, 12 Sep 2010 10:25:24 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Sun, 12 Sep 2010 19:25:18 +0900 From: Norikatsu Shigemura To: Andriy Gapon Message-Id: <20100912192518.e791c191.nork@FreeBSD.org> In-Reply-To: <20100912190952.8c0d5726.nork@FreeBSD.org> References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9F06.4090505@icyb.net.ua> <20100912190537.621e357e.nork@FreeBSD.org> <20100912190952.8c0d5726.nork@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sun__12_Sep_2010_19_25_18_+0900_QssXb=5hk8sE19dG" Cc: Alexander Motin , FreeBSD-Current , Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 10:25:25 -0000 This is a multi-part message in MIME format. --Multipart=_Sun__12_Sep_2010_19_25_18_+0900_QssXb=5hk8sE19dG Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi avg. On Sun, 12 Sep 2010 19:09:52 +0900 Norikatsu Shigemura wrote: > Logic is mistake. I'll re-make a patch and retry. I re-tried following patch: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --- sys/dev/acpica/acpi_cpu.c.orig 2010-09-12 01:31:38.144243000 +0900 +++ sys/dev/acpica/acpi_cpu.c 2010-09-12 19:11:00.906223222 +0900 @@ -690,19 +690,11 @@ sc->cpu_cx_count++; continue; case ACPI_STATE_C2: - if (cx_ptr->trans_lat > 100) { - ACPI_DEBUG_PRINT((ACPI_DB_INFO, - "acpi_cpu%d: C2[%d] not available.\n", - device_get_unit(sc->cpu_dev), i)); - continue; - } sc->cpu_non_c3 = i; break; case ACPI_STATE_C3: default: - if (cx_ptr->trans_lat > 1000 || - (cpu_quirks & CPU_QUIRK_NO_C3) != 0) { - + if (cpu_quirks & CPU_QUIRK_NO_C3) { ACPI_DEBUG_PRINT((ACPI_DB_INFO, "acpi_cpu%d: C3[%d] not available.\n", device_get_unit(sc->cpu_dev), i)); @@ -731,6 +723,9 @@ cx_ptr++; sc->cpu_cx_count++; } +else { +device_printf(sc->cpu_dev, "DEBUG: cx_ptr->p_lvlx IS NULL.\n"); +} } AcpiOsFree(buf.Pointer); - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Test is OK: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # sysctl hw.acpi.cpu.cx_lowest=C2 && sleep 10 && sysctl dev.cpu.0.cx_usage dev.cpu.1.cx_usage dev.cpu.2.cx_usage dev.cpu.3.cx_usage hw.acpi.cpu.cx_lowest: C3 -> C2 dev.cpu.0.cx_usage: 2.37% 97.62% last 3028us dev.cpu.1.cx_usage: 0.87% 99.12% last 4379us dev.cpu.2.cx_usage: 0.54% 99.45% last 14314us dev.cpu.3.cx_usage: 1.36% 98.63% last 16982us - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - But I don't know how I couldn't get C3:-(. Not reachable my DEBUG code. Thank you. -- Norikatsu Shigemura --Multipart=_Sun__12_Sep_2010_19_25_18_+0900_QssXb=5hk8sE19dG Content-Type: text/plain; name="dmesg.txt" Content-Disposition: attachment; filename="dmesg.txt" Content-Transfer-Encoding: 7bit ACPI set debug layer 'ACPI_ALL_DRIVERS ACPI_DB_INFO' level 'ACPI_LV_INFO' Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #4: Sun Sep 12 19:11:19 JST 2010 nork@pelsia.ninth-nine.com:/usr/obj/usr/src/sys/PELSIA amd64 Table 'FACP' at 0xda9aea98 Table 'APIC' at 0xda9aef18 Table 'MCFG' at 0xda9b0f18 Table 'HPET' at 0xda9b0e98 Table 'ASF!' at 0xda9af918 Table 'SLIC' at 0xda98ae18 Table 'SSDT' at 0xda9a9018 Table 'SSDT' at 0xda9a8c18 Table 'SSDT' at 0xda9a7c98 Table 'DMAR' at 0xda9a8f18 Table 'TCPA' at 0xda9b0e18 Table 'SSDT' at 0xda973a98 ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80be1000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff80be13a0. Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0xffffffff80be1a48. Preloaded elf obj module "/boot/kernel/krpc.ko" at 0xffffffff80be2078. Preloaded elf obj module "/boot/kernel/if_iwn.ko" at 0xffffffff80be26a0. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff80be2c48. Preloaded elf obj module "/boot/kernel/acpi_panasonic.ko" at 0xffffffff80be2ca8. Calibrating TSC clock ... TSC clock: 1197028208 Hz CPU: Intel(R) Core(TM) i7 CPU U 640 @ 1.20GHz (1197.03-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x20652 Family = 6 Model = 25 Stepping = 2 Features=0xbfebfbff Features2=0x298e3ff AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4303355904 (4104 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000097fff, 618496 bytes (151 pages) 0x0000000000c12000 - 0x00000000d254ffff, 3516129280 bytes (858430 pages) 0x00000000da969000 - 0x00000000da96dfff, 20480 bytes (5 pages) 0x00000000daa04000 - 0x00000000db3fffff, 10469376 bytes (2556 pages) 0x0000000100000000 - 0x0000000117feffff, 402587648 bytes (98288 pages) avail memory = 3907776512 (3726 MB) Event timer "LAPIC" frequency 0 Hz quality 600 ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 5 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 3 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 4 lapic0: CMCI unmasked x86bios: IVT 0x000000-0x0004ff at 0xffffff0000000000 x86bios: SSEG 0x001000-0x001fff at 0xffffff8000023000 x86bios: EBDA 0x09b000-0x09ffff at 0xffffff000009b000 x86bios: ROM 0x0a0000-0x0fefff at 0xffffff00000a0000 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf0410 00024 (v02 MATBIO) ACPI: XSDT 0xda9afe18 00084 (v01 MATBIO CFR9-1 06222004 MSFT 00010013) ACPI: FACP 0xda9aea98 000F4 (v04 MATBIO CFR9-1 06222004 MSFT 00010013) ACPI Warning: 32/64X FACS address mismatch in FADT - 0xDA9C1F40/0x00000000DA9D5D40, using 32 (20100806/tbfadt-586) ACPI: DSDT 0xda957018 119B4 (v01 MATBIO CFR9-1 00000000 INTL 20061109) ACPI: FACS 0xda9c1f40 00040 ACPI: APIC 0xda9aef18 0008C (v02 MATBIO CFR9-1 06222004 MSFT 00010013) ACPI: MCFG 0xda9b0f18 0003C (v01 MATBIO CFR9-1 06222004 MSFT 00000097) ACPI: HPET 0xda9b0e98 00038 (v01 MATBIO CFR9-1 06222004 AMI. 00000003) ACPI: ASF! 0xda9af918 00063 (v32 INTEL HCG 00000001 TFSM 000F4240) ACPI: SLIC 0xda98ae18 00176 (v01 MATBIO CFR9-1 06222004 AMI 00010013) ACPI: SSDT 0xda9a9018 009F1 (v01 PmRef CpuPm 00003000 INTL 20061109) ACPI: SSDT 0xda9a8c18 00259 (v01 PmRef Cpu0Tst 00003000 INTL 20061109) ACPI: SSDT 0xda9a7c98 0020F (v01 PmRef ApTst 00003000 INTL 20061109) ACPI: DMAR 0xda9a8f18 000B8 (v01 INTEL CP_DALE 00000001 INTL 00000001) ACPI: TCPA 0xda9b0e18 00032 (v02 MATBIO CFR9-1 00000001 MSFT 01000013) ACPI: SSDT 0xda973a98 002EF (v01 SataRe SataTabl 00001000 INTL 20061109) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 wlan: <802.11 Link Layer> random: cpuctl: access to MSR registers/cpuid info. VESA: INT 0x10 vector 0xc000:0x0014 VESA: information block 0000 56 45 53 41 00 03 00 01 00 02 01 00 00 00 40 00 0010 00 02 ff 01 00 01 3e 01 00 02 50 01 00 02 7c 01 0020 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040 60 01 61 01 62 01 63 01 64 01 65 01 66 01 67 01 0050 68 01 69 01 6a 01 6b 01 6c 01 6d 01 6e 01 6f 01 0060 70 01 71 01 3c 01 4d 01 5c 01 3a 01 4b 01 5a 01 0070 07 01 1a 01 1b 01 05 01 17 01 18 01 12 01 14 01 0080 15 01 01 01 03 01 11 01 ff ff 00 00 00 00 00 00 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100 49 6e 74 65 6c 28 52 29 49 72 6f 6e 6c 61 6b 65 0110 20 4d 6f 62 69 6c 65 20 47 72 61 70 68 69 63 73 0120 20 43 68 69 70 73 65 74 20 41 63 63 65 6c 65 72 0130 61 74 65 64 20 56 47 41 20 42 49 4f 53 00 49 6e 0140 74 65 6c 20 43 6f 72 70 6f 72 61 74 69 6f 6e 00 0150 49 6e 74 65 6c 28 52 29 49 72 6f 6e 6c 61 6b 65 0160 20 4d 6f 62 69 6c 65 20 47 72 61 70 68 69 63 73 0170 20 43 6f 6e 74 72 6f 6c 6c 65 72 00 48 61 72 64 0180 77 61 72 65 20 56 65 72 73 69 6f 6e 20 30 2e 30 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 9 mode(s) found VESA: v3.0, 32704k memory, flags:0x1, mode table:0xffffff8000079040 (2000040) VESA: Intel(R)Ironlake Mobile Graphics Chipset Accelerated VGA BIOS VESA: Intel Corporation Intel(R)Ironlake Mobile Graphics Controller Hardware Version 0.0 io: kbd: new array size 4 kbd1 at kbdmux0 mem: crypto: null: smbios0: at iomem 0xf0440-0xf045e on motherboard smbios0: Version: 2.6, BCD Revision: 2.6 aesni0: on motherboard crypto: assign aesni0 driver id 0, flags 16777216 crypto: aesni0 registers alg 11 flags 0 maxoplen 0 cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 1, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xf8000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI Error (dswload-0772): [DD02] Namespace lookup failure, AE_NOT_FOUND ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20100806/psloop-326) ACPI Error (psparse-0633): Method parse/execution failed [\\] (Node 0xffffffff808126a0), AE_NOT_FOUND ACPI Error (dswload-0772): [EHC1] Namespace lookup failure, AE_NOT_FOUND ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20100806/psloop-326) ACPI Error (psparse-0633): Method parse/execution failed [\\] (Node 0xffffffff808126a0), AE_NOT_FOUND ACPI Error (dswload-0772): [EHC1] Namespace lookup failure, AE_NOT_FOUND ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20100806/psloop-326) ACPI Error (psparse-0633): Method parse/execution failed [\\] (Node 0xffffffff808126a0), AE_NOT_FOUND ACPI: Executed 5 blocks of module-level executable AML code AcpiOsDerivePciId: \\_SB_.PCI0.SBUS.SMPB -> bus 0 dev 31 func 3 acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.CPBG.IMCH.PBUS -> bus 63 dev 0 func 1 AcpiOsDerivePciId: \\_SB_.PCI0.HBUS -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPCB.LPC0 -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPCB.LPC1 -> bus 0 dev 31 func 0 acpi0: reservation of e0000, 20000 (3) failed ACPI timer: 0/17 0/16 0/14 0/17 0/17 0/17 0/15 0/14 0/15 0/15 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 PROCESSOR-0311 [230584] cpu_attach : acpi_cpu0: P_BLK at 0x410/6 ACPI: SSDT 0xda9adc18 002AA (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 002AA (v01 PmRef Cpu0Ist 00003000 INTL 20061109) ACPI: SSDT 0xda9ab618 005CD (v01 PmRef Cpu0Cst 00003001 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 005CD (v01 PmRef Cpu0Cst 00003001 INTL 20061109) PROCESSOR-0722 [241753] cpu_cx_cst : acpi_cpu0: Got C2 - 205 latency PROCESSOR-0722 [241753] cpu_cx_cst : acpi_cpu0: Got C3 - 245 latency cpu1: on acpi0 PROCESSOR-0311 [241991] cpu_attach : acpi_cpu1: P_BLK at 0x410/6 ACPI: SSDT 0xda9aca98 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00303 (v01 PmRef ApIst 00003000 INTL 20061109) ACPI: SSDT 0xda9aad98 00119 (v01 PmRef ApCst 00003000 INTL 20061109) ACPI: Dynamic OEM Table Load: ACPI: SSDT 0 00119 (v01 PmRef ApCst 00003000 INTL 20061109) PROCESSOR-0722 [254000] cpu_cx_cst : acpi_cpu1: Got C2 - 205 latency PROCESSOR-0722 [254000] cpu_cx_cst : acpi_cpu1: Got C3 - 245 latency cpu2: on acpi0 PROCESSOR-0311 [254238] cpu_attach : acpi_cpu2: P_BLK at 0x410/6 PROCESSOR-0722 [255657] cpu_cx_cst : acpi_cpu2: Got C2 - 205 latency PROCESSOR-0722 [255657] cpu_cx_cst : acpi_cpu2: Got C3 - 245 latency cpu3: on acpi0 PROCESSOR-0311 [255895] cpu_attach : acpi_cpu3: P_BLK at 0x410/6 PROCESSOR-0722 [257314] cpu_cx_cst : acpi_cpu3: Got C2 - 205 latency PROCESSOR-0722 [257314] cpu_cx_cst : acpi_cpu3: Got C3 - 245 latency acpi_ec0: port 0x62,0x66 on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 4 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 4 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 5 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 255 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 1 3 4 5 6 7 10 12 14 15 Validation 0 3 N 0 1 3 4 5 6 7 10 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 10 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 1 3 4 5 6 7 11 12 14 15 Validation 0 11 N 0 1 3 4 5 6 7 11 12 14 15 After Disable 0 255 N 0 1 3 4 5 6 7 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x0044, revid=0x12 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x0046, revid=0x12 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xf0000000, size 22, enabled map[18]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled map[20]: type I/O Port, range 32, base 0xe0b0, size 3, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x10ea, revid=0x06 domain=0, bus=0, slot=25, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf4800000, size 17, enabled map[14]: type Memory, range 32, base 0xf4829000, size 12, enabled map[18]: type I/O Port, range 32, base 0xe040, size 5, enabled pcib0: matched entry for 0.25.INTA pcib0: slot 25 INTA hardwired to IRQ 20 found-> vendor=0x8086, dev=0x3b3c, revid=0x06 domain=0, bus=0, slot=26, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf4828000, size 10, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3b56, revid=0x06 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf4820000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x3b42, revid=0x06 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x10 (4000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3b46, revid=0x06 domain=0, bus=0, slot=28, func=2 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x10 (4000 ns), maxlat=0x00 (0 ns) intpin=c, irq=4 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3b48, revid=0x06 domain=0, bus=0, slot=28, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x10 (4000 ns), maxlat=0x00 (0 ns) intpin=d, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3b34, revid=0x06 domain=0, bus=0, slot=29, func=0 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf4827000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x2448, revid=0xa6 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x10 (4000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3b07, revid=0x06 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3b2f, revid=0x06 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0xe090, size 3, enabled map[14]: type I/O Port, range 32, base 0xe080, size 2, enabled map[18]: type I/O Port, range 32, base 0xe070, size 3, enabled map[1c]: type I/O Port, range 32, base 0xe060, size 2, enabled map[20]: type I/O Port, range 32, base 0xe020, size 5, enabled map[24]: type Memory, range 32, base 0xf4826000, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3b30, revid=0x06 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=4 map[10]: type Memory, range 64, base 0xf4825000, size 8, enabled map[20]: type I/O Port, range 32, base 0xe000, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3b32, revid=0x06 domain=0, bus=0, slot=31, func=6 class=11-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=4 powerspec 3 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xf4824000, size 12, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 vgapci0: port 0xe0b0-0xe0b7 mem 0xf0000000-0xf03fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 32764k stolen memory em0: port 0xe040-0xe05f mem 0xf4800000-0xf481ffff,0xf4829000-0xf4829fff irq 20 at device 25.0 on pci0 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 49 em0: using IRQ 256 for MSI em0: Using an MSI interrupt em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:1b:d3:89:b8:6e ehci0: mem 0xf4828000-0xf48283ff irq 16 at device 26.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 50 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: on ehci0 hdac0: mem 0xf4820000-0xf4823fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 51 hdac0: using IRQ 257 for MSI hdac0: [MPSAFE] hdac0: [ITHREAD] hdac0: Caps: OSS 4, ISS 4, BSS 0, NSDO 1, 64bit, CORB 256, RIRB 256 pcib1: irq 16 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0xf4600000-0xf47fffff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 18 at device 28.2 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xc000-0xcfff pcib2: memory decode 0xf4400000-0xf45fffff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x8086, dev=0x422c, revid=0x35 domain=0, bus=2, slot=0, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=4 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf4400000, size 13, enabled pcib2: requested memory range 0xf4400000-0xf4401fff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 iwn0: mem 0xf4400000-0xf4401fff irq 18 at device 0.0 on pci2 iwn0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 258 to local APIC 0 vector 52 iwn0: using IRQ 258 for MSI iwn0: MIMO 2T2R, MoW, address 00:23:14:21:69:00 iwn0: [MPSAFE] iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps pcib3: irq 19 at device 28.3 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 11 pcib3: I/O decode 0xa000-0xbfff pcib3: memory decode 0xf0400000-0xf43fffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x1180, dev=0xe476, revid=0x00 domain=0, bus=3, slot=0, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x04 (1000 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf2c01000, size 12, enabled pcib3: requested memory range 0xf2c01000-0xf2c01fff: good pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 19 found-> vendor=0x1180, dev=0xe822, revid=0x02 domain=0, bus=3, slot=0, func=1 class=08-05-01, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf2c00000, size 8, enabled pcib3: requested memory range 0xf2c00000-0xf2c000ff: good pcib3: matched entry for 3.0.INTB pcib3: slot 0 INTB hardwired to IRQ 16 cbb0: mem 0xf2c01000-0xf2c01fff irq 19 at device 0.0 on pci3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 53 cbb0: [MPSAFE] cbb0: [FILTER] cbb0: PCI Configuration space: 0x00: 0xe4761180 0x00100007 0x06070000 0x00820000 0x10: 0xf2c01000 0x020000a0 0x20040403 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc 0x30: 0x00000000 0x0000fffc 0x00000000 0x04000113 0x40: 0x833810f7 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x00710010 0x0590ffc0 0x000b2810 0x01076c11 0x90: 0x10110142 0x00000000 0xfe038001 0x48004000 0xa0: 0x00809805 0x00000000 0x00000000 0x00000000 0xb0: 0x30040001 0x00000000 0x08c608c6 0x00000000 0xc0: 0x00003000 0x00000001 0x5e000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x90000000 0xe0: 0x00020000 0x00000000 0x00000000 0x833810f7 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 sdhci0: mem 0xf2c00000-0xf2c000ff irq 16 at device 0.1 on pci3 sdhci0-slot0: 50MHz HS 4bits 3.3V DMA sdhci0-slot0: ============== REGISTER DUMP ============== sdhci0-slot0: Sys addr: 0x00000000 | Version: 0x00000400 sdhci0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci0-slot0: Present: 0x01f20000 | Host ctl: 0x00000000 sdhci0-slot0: Power: 0x00000000 | Blk gap: 0x00000000 sdhci0-slot0: Wake-up: 0x00000000 | Clock: 0x00000000 sdhci0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci0-slot0: AC12 err: 0x00000000 | Slot int: 0x00000000 sdhci0-slot0: Caps: 0x01e032b2 | Max curr: 0x00000040 sdhci0-slot0: =========================================== sdhci0: 1 slot(s) allocated sdhci0: [MPSAFE] sdhci0: [ITHREAD] ehci1: mem 0xf4827000-0xf48273ff irq 23 at device 29.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 54 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci1 pcib4: at device 30.0 on pci0 pcib4: domain 0 pcib4: secondary bus 12 pcib4: subordinate bus 12 pcib4: I/O decode 0xf000-0xfff pcib4: no prefetched decode pcib4: Subtractively decoded bridge. pci12: on pcib4 pci12: domain=0, physical bus=12 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xe090-0xe097,0xe080-0xe083,0xe070-0xe077,0xe060-0xe063,0xe020-0xe03f mem 0xf4826000-0xf48267ff irq 19 at device 31.2 on pci0 ahci0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 259 to local APIC 0 vector 55 ahci0: using IRQ 259 for MSI ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd EM 6ports ahci0: Caps2: APST ahci0: EM Caps: ALHD XMT SMB LED ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ahcich0: Caps: ichsmb0: port 0xe000-0xe01f mem 0xf4825000-0xf48250ff irq 18 at device 31.3 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 56 ichsmb0: [MPSAFE] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 pci0: at device 31.6 (no driver attached) pcib5: on acpi0 pcib5: could not get PCI interrupt routing table for \\_SB_.CPBG - AE_NOT_FOUND pci63: on pcib5 pci63: domain=0, physical bus=63 found-> vendor=0x8086, dev=0x2c62, revid=0x02 domain=0, bus=63, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d01, revid=0x02 domain=0, bus=63, slot=0, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d10, revid=0x02 domain=0, bus=63, slot=2, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d11, revid=0x02 domain=0, bus=63, slot=2, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d12, revid=0x02 domain=0, bus=63, slot=2, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2d13, revid=0x02 domain=0, bus=63, slot=2, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) acpi_panasonic0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 8 timers, legacy route hpet0: t0: irqs 0x00f00000 (0), MSI, 64bit, periodic hpet0: t1: irqs 0x00f00000 (0), MSI hpet0: t2: irqs 0x00f00800 (0), MSI hpet0: t3: irqs 0x00f01000 (0), MSI hpet0: t4: irqs 0x00000000 (0), MSI hpet0: t5: irqs 0x00000000 (0), MSI hpet0: t6: irqs 0x00000000 (0), MSI hpet0: t7: irqs 0x00000000 (0), MSI Timecounter "HPET" frequency 14318180 Hz quality 900 msi: routing MSI-X IRQ 260 to local APIC 0 vector 57 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 261 to local APIC 0 vector 58 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 262 to local APIC 0 vector 59 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 263 to local APIC 0 vector 60 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 264 to local APIC 0 vector 61 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 265 to local APIC 0 vector 62 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 266 to local APIC 0 vector 63 hpet0: [MPSAFE] hpet0: [FILTER] msi: routing MSI-X IRQ 267 to local APIC 0 vector 64 hpet0: [MPSAFE] hpet0: [FILTER] Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 65 atrtc0: [MPSAFE] atrtc0: [FILTER] Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 attimer0: [MPSAFE] attimer0: [FILTER] ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 66 Event timer "i8254" frequency 1193182 Hz quality 100 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 67 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 68 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 acpi0: wakeup code va 0xffffff8071a1a000 pa 0x4000 isab0: found ICH10 or equivalent chipset: Intel QM57 watchdog timer isa_probe_children: disabling PnP devices ichwd0: on isa0 isab0: found ICH10 or equivalent chipset: Intel QM57 watchdog timer ichwd0: Intel QM57 watchdog timer (ICH10 or equivalent) ichwd0: timer disabled atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 isa_probe_children: probing PnP devices coretemp0: on cpu0 coretemp0: Tj(target) value 105 does not seem right. coretemp0: Setting TjMax=100 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 coretemp1: Tj(target) value 105 does not seem right. coretemp1: Setting TjMax=100 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 coretemp2: Tj(target) value 105 does not seem right. coretemp2: Setting TjMax=100 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 coretemp3: Tj(target) value 105 does not seem right. coretemp3: Setting TjMax=100 est3: on cpu3 p4tcc3: on cpu3 Device configuration finished. ZFS filesystem version 4 ZFS storage pool version 15 Timecounter "TSC" frequency 1197028208 Hz quality -100 lapic: Divisor 2, Frequency 66501562 Hz Timecounters tick every 1.000 msec crypto: Linux ELF exec handler installed IPsec: Initialized Security Association Processing. lo0: bpf attached hdac0: Probing codec #0... hdac0: HDA Codec #0: Conexant (Unknown) hdac0: HDA Codec ID: 0x14f15068 hdac0: Vendor: 0x14f1 hdac0: Device: 0x5068 hdac0: Revision: 0x03 hdac0: Stepping: 0x02 hdac0: PCI Subvendor: 0x833810f7 hdac0: Found audio FG nid=1 startnode=16 endnode=38 total=22 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0x40000004 NumGPIO=4 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdac0: nid 25 0x022110f0 as 15 seq 0 Headphones Jack jack 1 loc 2 color Black misc 0 hdac0: nid 26 0x02a110f0 as 15 seq 0 Mic Jack jack 1 loc 2 color Black misc 0 hdac0: nid 27 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 28 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 29 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 30 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 31 0x901701f0 as 15 seq 0 Speaker Fixed jack 7 loc 16 color Unknown misc 1 hdac0: nid 32 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 34 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: nid 35 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 hdac0: Patched pins configuration: hdac0: nid 25 0x022110f0 as 15 seq 0 Headphones Jack jack 1 loc 2 color Black misc 0 hdac0: nid 26 0x02a110f0 as 15 seq 0 Mic Jack jack 1 loc 2 color Black misc 0 hdac0: nid 27 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 28 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 29 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 30 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 31 0x901701f0 as 15 seq 0 Speaker Fixed jack 7 loc 16 color Unknown misc 1 hdac0: nid 32 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 34 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: nid 35 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] hdac0: 3 associations found: hdac0: Association 0 (15) out: hdac0: Pin nid=25 seq=0 hdac0: Association 1 (15) in: hdac0: Pin nid=26 seq=0 hdac0: Association 2 (15) out: hdac0: Pin nid=31 seq=0 hdac0: Tracing association 0 (15) hdac0: Pin 25 traced to DAC 16 hdac0: Association 0 (15) trace succeeded hdac0: Tracing association 1 (15) hdac0: Pin 26 traced to ADC 20 hdac0: Association 1 (15) trace succeeded hdac0: Tracing association 2 (15) hdac0: Pin 31 traced to DAC 17 hdac0: Association 2 (15) trace succeeded hdac0: Tracing input monitor hdac0: Tracing other input monitors hdac0: Tracing nid 26 to out hdac0: Tracing beeper hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: IN amp: 0x00000000 hdac0: OUT amp: 0x00000000 hdac0: hdac0: nid: 16 hdac0: Name: audio output hdac0: Widget cap: 0x00000c1d hdac0: LRSWAP PWR STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Output amp: 0x80034a4a hdac0: mute=1 step=74 size=3 offset=74 hdac0: hdac0: nid: 17 hdac0: Name: audio output hdac0: Widget cap: 0x00000c1d hdac0: LRSWAP PWR STEREO hdac0: Association: 2 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0560 hdac0: 16 20 24 bits, 44 48 96 192 KHz hdac0: Output amp: 0x80034a4a hdac0: mute=1 step=74 size=3 offset=74 hdac0: hdac0: nid: 18 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000611 hdac0: PWR DIGITAL STEREO hdac0: Stream cap: 0x00000005 hdac0: AC3 PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: hdac0: nid: 19 hdac0: Name: beep widget hdac0: Widget cap: 0x0070000c hdac0: Association: -2 (0x00000000) hdac0: OSS: speaker (speaker) hdac0: Output amp: 0x000f0707 hdac0: mute=0 step=7 size=15 offset=7 hdac0: hdac0: nid: 20 hdac0: Name: audio input hdac0: Widget cap: 0x00100d1b hdac0: LRSWAP PWR STEREO hdac0: Association: 1 (0x00000001) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Input amp: 0x8003504a hdac0: mute=1 step=80 size=3 offset=74 hdac0: connections: 4 hdac0: | hdac0: + <- nid=23 [audio selector] (selected) hdac0: + <- nid=24 [audio selector] hdac0: + [DISABLED] <- nid=35 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=36 [audio mixer] [DISABLED] hdac0: hdac0: nid: 21 [DISABLED] hdac0: Name: audio input hdac0: Widget cap: 0x00100d1b hdac0: LRSWAP PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Input amp: 0x8003504a hdac0: mute=1 step=80 size=3 offset=74 hdac0: connections: 4 hdac0: | hdac0: + [DISABLED] <- nid=23 [audio selector] (selected) hdac0: + <- nid=24 [audio selector] hdac0: + [DISABLED] <- nid=35 [pin: Other (None)] [DISABLED] hdac0: + <- nid=36 [audio mixer] [DISABLED] hdac0: hdac0: nid: 22 [DISABLED] hdac0: Name: audio input hdac0: Widget cap: 0x00100d1b hdac0: LRSWAP PWR STEREO hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: Input amp: 0x8003504a hdac0: mute=1 step=80 size=3 offset=74 hdac0: connections: 4 hdac0: | hdac0: + [DISABLED] <- nid=23 [audio selector] (selected) hdac0: + <- nid=24 [audio selector] hdac0: + [DISABLED] <- nid=35 [pin: Other (None)] [DISABLED] hdac0: + <- nid=36 [audio mixer] [DISABLED] hdac0: hdac0: nid: 23 hdac0: Name: audio selector hdac0: Widget cap: 0x0030050d hdac0: PWR STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic hdac0: Output amp: 0x00270400 hdac0: mute=0 step=4 size=39 offset=0 hdac0: connections: 4 hdac0: | hdac0: + <- nid=26 [pin: Mic (Black Jack)] (selected) hdac0: + [DISABLED] <- nid=27 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=30 [pin: Other (None)] [DISABLED] hdac0: hdac0: nid: 24 hdac0: Name: audio selector hdac0: Widget cap: 0x0030050d hdac0: PWR STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic hdac0: Output amp: 0x00270400 hdac0: mute=0 step=4 size=39 offset=0 hdac0: connections: 4 hdac0: | hdac0: + <- nid=26 [pin: Mic (Black Jack)] (selected) hdac0: + [DISABLED] <- nid=27 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=29 [pin: Other (None)] [DISABLED] hdac0: + [DISABLED] <- nid=30 [pin: Other (None)] [DISABLED] hdac0: hdac0: nid: 25 hdac0: Name: pin: Headphones (Black Jack) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x0000001c hdac0: PDC HP OUT hdac0: Pin config: 0x022110f0 hdac0: Pin control: 0x000000c0 HP OUT hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + [DISABLED] <- nid=17 [audio output] hdac0: hdac0: nid: 26 hdac0: Name: pin: Mic (Black Jack) hdac0: Widget cap: 0x00400481 hdac0: PWR UNSOL STEREO hdac0: Association: 1 (0x00000001) hdac0: OSS: mic (mic) hdac0: Pin cap: 0x00001324 hdac0: PDC IN VREF[ 50 80 HIZ ] hdac0: Pin config: 0x02a110f0 hdac0: Pin control: 0x00000024 IN VREFs hdac0: hdac0: nid: 27 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00011334 hdac0: PDC OUT IN VREF[ 50 80 HIZ ] EAPD hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: EAPD: 0x00000002 hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + <- nid=17 [audio output] hdac0: hdac0: nid: 28 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00000014 hdac0: PDC OUT hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + <- nid=17 [audio output] hdac0: hdac0: nid: 29 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400581 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00010034 hdac0: PDC OUT IN EAPD hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: EAPD: 0x00000002 hdac0: connections: 2 hdac0: | hdac0: + <- nid=16 [audio output] (selected) hdac0: + <- nid=17 [audio output] hdac0: hdac0: nid: 30 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400481 hdac0: PWR UNSOL STEREO hdac0: Pin cap: 0x00000024 hdac0: PDC IN hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: hdac0: nid: 31 hdac0: Name: pin: Speaker (Fixed) hdac0: Widget cap: 0x00400501 hdac0: PWR STEREO hdac0: Association: 2 (0x00000001) hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x901701f0 hdac0: Pin control: 0x00000040 OUT hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=16 [audio output] hdac0: + <- nid=17 [audio output] (selected) hdac0: hdac0: nid: 32 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400781 hdac0: PWR DIGITAL UNSOL STEREO hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=18 [audio output] [DISABLED] hdac0: hdac0: nid: 33 [DISABLED] hdac0: Name: audio output hdac0: Widget cap: 0x00000611 hdac0: PWR DIGITAL STEREO hdac0: Stream cap: 0x00000005 hdac0: AC3 PCM hdac0: PCM cap: 0x000e0160 hdac0: 16 20 24 bits, 44 48 96 KHz hdac0: hdac0: nid: 34 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x00400781 hdac0: PWR DIGITAL UNSOL STEREO hdac0: Pin cap: 0x00000010 hdac0: OUT hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: connections: 1 hdac0: | hdac0: + <- nid=33 [audio output] [DISABLED] hdac0: hdac0: nid: 35 [DISABLED] hdac0: Name: pin: Other (None) hdac0: Widget cap: 0x0040040b hdac0: PWR STEREO hdac0: Pin cap: 0x00000020 hdac0: IN hdac0: Pin config: 0x40f001f0 hdac0: Pin control: 0x00000000 hdac0: Input amp: 0x002f0400 hdac0: mute=0 step=4 size=47 offset=0 hdac0: hdac0: nid: 36 [DISABLED] hdac0: Name: audio mixer hdac0: Widget cap: 0x0020050b hdac0: PWR STEREO hdac0: Input amp: 0x80034a4a hdac0: mute=1 step=74 size=3 offset=74 hdac0: connections: 2 hdac0: | hdac0: + [DISABLED] <- nid=16 [audio output] hdac0: + [DISABLED] <- nid=17 [audio output] hdac0: hdac0: nid: 37 [DISABLED] hdac0: Name: vendor widget hdac0: Widget cap: 0x00f00000 hdac0: pcm0: at cad 0 nid 1 on hdac0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0560 pcm0: 16 20 24 bits, 44 48 96 192 KHz pcm0: DAC: 16 pcm0: pcm0: Record: pcm0: pcm0: Stream cap: 0x00000001 pcm0: PCM pcm0: PCM cap: 0x000e0160 pcm0: 16 20 24 bits, 44 48 96 KHz pcm0: ADC: 20 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=25 [pin: Headphones (Black Jack)] pcm0: | pcm0: + <- nid=16 [audio output] [src: pcm] pcm0: pcm0: Record: pcm0: pcm0: nid=20 [audio input] pcm0: | pcm0: + <- nid=23 [audio selector] [src: mic] pcm0: | pcm0: + <- nid=26 [pin: Mic (Black Jack)] [src: mic] pcm0: + <- nid=24 [audio selector] [src: mic] pcm0: | pcm0: + <- nid=26 [pin: Mic (Black Jack)] [src: mic] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Master Volume (OSS: vol) pcm0: | pcm0: +- ctl 1 (nid 16 out): -74/0dB (75 steps) + mute pcm0: pcm0: PCM Volume (OSS: pcm) pcm0: | pcm0: +- ctl 1 (nid 16 out): -74/0dB (75 steps) + mute pcm0: pcm0: Microphone Volume (OSS: mic) pcm0: | pcm0: +- ctl 7 (nid 23 out): 0/40dB (5 steps) pcm0: +- ctl 8 (nid 24 out): 0/40dB (5 steps) pcm0: pcm0: Speaker/Beep Volume (OSS: speaker) pcm0: | pcm0: +- ctl 3 (nid 19 out): -28/0dB (8 steps) pcm0: pcm0: Recording Level (OSS: rec) pcm0: | pcm0: +- ctl 4 (nid 20 in 0): -74/6dB (81 steps) + mute pcm0: +- ctl 8 (nid 24 out): 0/40dB (5 steps) pcm0: pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "mic": pcm0: Mixer "rec": pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 35d0000, 4000; 0xffffff8071a46000 -> 35d0000 pcm0: sndbuf_setmap 35e0000, 4000; 0xffffff8071a56000 -> 35e0000 pcm1: at cad 0 nid 1 on hdac0 pcm1: +--------------------------------------+ pcm1: | DUMPING PCM Playback/Record Channels | pcm1: +--------------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x000e0560 pcm1: 16 20 24 bits, 44 48 96 192 KHz pcm1: DAC: 17 pcm1: pcm1: +-------------------------------+ pcm1: | DUMPING Playback/Record Paths | pcm1: +-------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: nid=31 [pin: Speaker (Fixed)] pcm1: | pcm1: + <- nid=17 [audio output] [src: pcm] pcm1: pcm1: +-------------------------+ pcm1: | DUMPING Volume Controls | pcm1: +-------------------------+ pcm1: pcm1: Master Volume (OSS: vol) pcm1: | pcm1: +- ctl 2 (nid 17 out): -74/0dB (75 steps) + mute pcm1: pcm1: PCM Volume (OSS: pcm) pcm1: | pcm1: +- ctl 2 (nid 17 out): -74/0dB (75 steps) + mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: clone manager: deadline=750ms flags=0x8000001e pcm1: sndbuf_setmap 35f0000, 4000; 0xffffff8071a66000 -> 35f0000 usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ahcich0: AHCI reset... ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ahcich0: SATA connect time=0ms status=00000123 ahcich0: ready wait time=0ms ahcich0: AHCI reset done: device found (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 acpi_acad0: acline initialization start battery0: battery initialization start ada0 at ahcich0 bus 0 scbus0 target 0 lun 0GEOM: new disk ada0 ada0: ATA-7 SATA 2.x device ada0: Serial Number DC01S00951SE951A2260 ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C) pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-7 SATA 2.x device pass0: Serial Number DC01S00951SE951A2260 pass0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) pass0: Command Queueing enabled llapaipcic54:: CCMMCIC Iu numnamsakedsked SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000100f2 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x05000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x04000000 VER: 0x01060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 cmci: 0x000000f2 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 9 (GEOM: ada0: partition 4 does not start on a track boundary.ISA IRQ 9acpi_acad0: GEOM: ada0: partition 4 does not end on a track boundary.On Line GEOM: ada0: partition 3 does not start on a track boundary. acpi_acad0: ) to lapic 4 vector 48acline initialization done, tried 1 times ioapic0: routing intpin 12 (ISA IRQ 12 GEOM: ada0: partition 3 does not end on a track boundary.) to lapic 5 vector 48 GEOM: ada0: partition 2 does not start on a track boundary. ioapic0: routing intpin 18 ( GEOM: ada0: partition 2 does not end on a track boundary.PCI IRQ 18 GEOM: ada0: partition 1 does not start on a track boundary.) to lapic 1 vector 49 GEOM: ada0: partition 1 does not end on a track boundary. ioapic0: routing intpin 19 ( PCI IRQ 19) to lapic 4 vector 49 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 5 vector 49 msi: Assigning MSI IRQ 257 to local APIC 1 vector 50 msi: Assigning MSI IRQ 258 to local APIC 4 vector 50 msi: Assigning MSI IRQ 259 to local APIC 5 vector 50 msi: Assigning MSI-X IRQ 261 to local APIC 1 vector 51 msi: Assigning MSI-X IRQ 262 to local APIC 4 vector 51 msi: Assigning MSI-X IRQ 263 to local APIC 5 vector 51 Root mount waiting for: usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus1 usbus0 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 uhub3: on usbus1 Root mount waiting for: usbus1 usbus0 uhub2: 6 ports with 6 removable, self powered uhub3: 8 ports with 8 removable, self powered Trying to mount root from zfs:zoot/system ct_to_ts([2010-09-12 19:14:58]) = 1284318898.000000000 start_init: trying /sbin/init procfs registered acpi_lid0: Lid closed em0: Link is up 1000 Mbps Full Duplex PROCESSOR-0722 [402244] cpu_cx_cst : acpi_cpu0: Got C2 - 245 latency PROCESSOR-0722 [403097] cpu_cx_cst : acpi_cpu1: Got C2 - 245 latency PROCESSOR-0722 [403855] cpu_cx_cst : acpi_cpu2: Got C2 - 245 latency PROCESSOR-0722 [405022] cpu_cx_cst : acpi_cpu3: Got C2 - 245 latency ts_to_ct(1284318915.602392650) = [2010-09-12 19:15:15] --Multipart=_Sun__12_Sep_2010_19_25_18_+0900_QssXb=5hk8sE19dG-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 10:31:33 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1C30106566C; Sun, 12 Sep 2010 10:31:32 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B93568FC12; Sun, 12 Sep 2010 10:31:31 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA25836; Sun, 12 Sep 2010 13:31:30 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OujqL-000FnC-Vo; Sun, 12 Sep 2010 13:31:30 +0300 Message-ID: <4C8CAC01.70004@icyb.net.ua> Date: Sun, 12 Sep 2010 13:31:29 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Norikatsu Shigemura References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9F06.4090505@icyb.net.ua> <20100912190537.621e357e.nork@FreeBSD.org> <20100912190952.8c0d5726.nork@FreeBSD.org> <20100912192518.e791c191.nork@FreeBSD.org> In-Reply-To: <20100912192518.e791c191.nork@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , FreeBSD-Current Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 10:31:33 -0000 on 12/09/2010 13:25 Norikatsu Shigemura said the following: > Hi avg. > > On Sun, 12 Sep 2010 19:09:52 +0900 > Norikatsu Shigemura wrote: >> Logic is mistake. I'll re-make a patch and retry. > > I re-tried following patch: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > --- sys/dev/acpica/acpi_cpu.c.orig 2010-09-12 01:31:38.144243000 +0900 > +++ sys/dev/acpica/acpi_cpu.c 2010-09-12 19:11:00.906223222 +0900 > @@ -690,19 +690,11 @@ > sc->cpu_cx_count++; > continue; > case ACPI_STATE_C2: > - if (cx_ptr->trans_lat > 100) { > - ACPI_DEBUG_PRINT((ACPI_DB_INFO, > - "acpi_cpu%d: C2[%d] not available.\n", > - device_get_unit(sc->cpu_dev), i)); > - continue; > - } > sc->cpu_non_c3 = i; > break; > case ACPI_STATE_C3: > default: > - if (cx_ptr->trans_lat > 1000 || > - (cpu_quirks & CPU_QUIRK_NO_C3) != 0) { > - > + if (cpu_quirks & CPU_QUIRK_NO_C3) { > ACPI_DEBUG_PRINT((ACPI_DB_INFO, > "acpi_cpu%d: C3[%d] not available.\n", > device_get_unit(sc->cpu_dev), i)); The above looks good. > @@ -731,6 +723,9 @@ > cx_ptr++; > sc->cpu_cx_count++; > } > +else { > +device_printf(sc->cpu_dev, "DEBUG: cx_ptr->p_lvlx IS NULL.\n"); > +} > } > AcpiOsFree(buf.Pointer); What's this? The indentation is messed up too :-) > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Test is OK: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > # sysctl hw.acpi.cpu.cx_lowest=C2 && sleep 10 && sysctl dev.cpu.0.cx_usage dev.cpu.1.cx_usage dev.cpu.2.cx_usage dev.cpu.3.cx_usage > hw.acpi.cpu.cx_lowest: C3 -> C2 > dev.cpu.0.cx_usage: 2.37% 97.62% last 3028us > dev.cpu.1.cx_usage: 0.87% 99.12% last 4379us > dev.cpu.2.cx_usage: 0.54% 99.45% last 14314us > dev.cpu.3.cx_usage: 1.36% 98.63% last 16982us > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > But I don't know how I couldn't get C3:-(. > Not reachable my DEBUG code. > > Thank you. acpi_lid0: Lid closed em0: Link is up 1000 Mbps Full Duplex PROCESSOR-0722 [402244] cpu_cx_cst : acpi_cpu0: Got C2 - 245 latency PROCESSOR-0722 [403097] cpu_cx_cst : acpi_cpu1: Got C2 - 245 latency PROCESSOR-0722 [403855] cpu_cx_cst : acpi_cpu2: Got C2 - 245 latency PROCESSOR-0722 [405022] cpu_cx_cst : acpi_cpu3: Got C2 - 245 latency Maybe because of this? It seems like you do something and ACPI disables C3, leaving only C2/ -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 10:38:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7305E106564A; Sun, 12 Sep 2010 10:38:14 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C1E368FC1A; Sun, 12 Sep 2010 10:38:13 +0000 (UTC) Received: by bwz20 with SMTP id 20so394652bwz.13 for ; Sun, 12 Sep 2010 03:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=GS6hSi1cmwPGXKwUnB0tfrLjZe1/ql8amguDb9DlrtQ=; b=sXx4uOBAnto2VgAbnVpy2K8MPbCa7SUWg6CQf5pYH3mY5WLgRsiTu7IUG4t6bQDCC4 +fOVo7T+xJugyiX4tljUjTXOyvN+VHZn5bIpWQXrrzCp/p/FTMqqhV+6ta/s8sNjVSOe 9ZNHYW/SKCpr593Xjqc3BQO98/FADRC1sEOXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Xj5C5f8vgzkM5v6DW2nu5/ERe7A8EYx4KDsRHjeB8JyGc80TlXyDTniVTTjUmdJa5h Zu5YGctvd18IiVMlsDY5r+cuWGJumVAF4p59ErcHJLeyMy1ydyLRFFRGPaIoc5f3Xzrf km7URf4aJTSMQ8DOlGJG0j30Lf6x9mfJuoqYc= Received: by 10.204.73.211 with SMTP id r19mr2222751bkj.131.1284287890644; Sun, 12 Sep 2010 03:38:10 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y19sm3599791bkw.6.2010.09.12.03.38.08 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Sep 2010 03:38:09 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8CAD7D.50602@FreeBSD.org> Date: Sun, 12 Sep 2010 13:37:49 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Andriy Gapon References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9F06.4090505@icyb.net.ua> <20100912190537.621e357e.nork@FreeBSD.org> <20100912190952.8c0d5726.nork@FreeBSD.org> <20100912192518.e791c191.nork@FreeBSD.org> <4C8CAC01.70004@icyb.net.ua> In-Reply-To: <4C8CAC01.70004@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 10:38:14 -0000 Andriy Gapon wrote: > acpi_lid0: Lid closed > em0: Link is up 1000 Mbps Full Duplex > PROCESSOR-0722 [402244] cpu_cx_cst : acpi_cpu0: Got C2 - 245 latency > PROCESSOR-0722 [403097] cpu_cx_cst : acpi_cpu1: Got C2 - 245 latency > PROCESSOR-0722 [403855] cpu_cx_cst : acpi_cpu2: Got C2 - 245 latency > PROCESSOR-0722 [405022] cpu_cx_cst : acpi_cpu3: Got C2 - 245 latency > > Maybe because of this? > It seems like you do something and ACPI disables C3, leaving only C2/ One strange thing. During boot it can be seen: acpi_cpu0: Got C2 - 205 latency acpi_cpu0: Got C3 - 245 latency , but after boot in sysctl we can see: dev.cpu.0.cx_supported: C1/3 C2/245 It respecting latency it looks like not C3 got lost, but C2. AFAIR, sysctl numbers C-states completely abstract, just as array indexes. So thing reported as C2 could instead be C3, while C2 is absent for some reason. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 10:58:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 176DB106564A; Sun, 12 Sep 2010 10:58:03 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 053068FC19; Sun, 12 Sep 2010 10:57:44 +0000 (UTC) Received: by bwz20 with SMTP id 20so401929bwz.13 for ; Sun, 12 Sep 2010 03:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=+I9oiDZk20RrofyCSq/XSHVwJWVSrSCa99ouOXykk/g=; b=bsV2M0aeLHvzu2q2xFd5zZTm4o4iqXK7QIjACca9M2qWxqQiuq8pqTJVkfManVnfxY Xum5T3q2oXVkOhi8BhVUVsqCHarYgd/jNPzrq7tmci2WBwl0/uahIxBrZS+UTD2/X+eG jMN/kASOYcO9Dg24hIZWM7CGOCQEASRfjUIr8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=a3zEpY046cQQYqqkOCRXrjxii2pjkiI6cH2sSzhgUrKBNyM26fK5dN0pT9TtQydKN1 Z2vUEFImuZLBXTPG8lgB2ON4Ilfx+HWaniXtqtkPBWxepZpNNakmQoHuYUu+7Z10iyap E537/MiOsOXk+Adv8Xb8v9ULSKDUR2WoCrYCk= Received: by 10.204.78.8 with SMTP id i8mr245218bkk.176.1284289063785; Sun, 12 Sep 2010 03:57:43 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 11sm3613115bkj.11.2010.09.12.03.57.41 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Sep 2010 03:57:42 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8CB211.6020308@FreeBSD.org> Date: Sun, 12 Sep 2010 13:57:21 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Norikatsu Shigemura References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9F06.4090505@icyb.net.ua> <20100912190537.621e357e.nork@FreeBSD.org> <20100912190952.8c0d5726.nork@FreeBSD.org> <20100912192518.e791c191.nork@FreeBSD.org> <4C8CAC01.70004@icyb.net.ua> <4C8CAD7D.50602@FreeBSD.org> In-Reply-To: <4C8CAD7D.50602@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , Andriy Gapon Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 10:58:03 -0000 Alexander Motin wrote: > Andriy Gapon wrote: >> acpi_lid0: Lid closed >> em0: Link is up 1000 Mbps Full Duplex >> PROCESSOR-0722 [402244] cpu_cx_cst : acpi_cpu0: Got C2 - 245 latency >> PROCESSOR-0722 [403097] cpu_cx_cst : acpi_cpu1: Got C2 - 245 latency >> PROCESSOR-0722 [403855] cpu_cx_cst : acpi_cpu2: Got C2 - 245 latency >> PROCESSOR-0722 [405022] cpu_cx_cst : acpi_cpu3: Got C2 - 245 latency >> >> Maybe because of this? >> It seems like you do something and ACPI disables C3, leaving only C2/ > > One strange thing. During boot it can be seen: > acpi_cpu0: Got C2 - 205 latency > acpi_cpu0: Got C3 - 245 latency > , but after boot in sysctl we can see: > dev.cpu.0.cx_supported: C1/3 C2/245 > > It respecting latency it looks like not C3 got lost, but C2. AFAIR, > sysctl numbers C-states completely abstract, just as array indexes. So > thing reported as C2 could instead be C3, while C2 is absent for some > reason. BTW, have you tried to unplug power? My laptop hides C3 state when power cord is plugged-in. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 11:26:14 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id EA58A1065675; Sun, 12 Sep 2010 11:26:13 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Sun, 12 Sep 2010 20:26:07 +0900 From: Norikatsu Shigemura To: Alexander Motin Message-Id: <20100912202607.07ee9f64.nork@FreeBSD.org> In-Reply-To: <4C8CB211.6020308@FreeBSD.org> References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9F06.4090505@icyb.net.ua> <20100912190537.621e357e.nork@FreeBSD.org> <20100912190952.8c0d5726.nork@FreeBSD.org> <20100912192518.e791c191.nork@FreeBSD.org> <4C8CAC01.70004@icyb.net.ua> <4C8CAD7D.50602@FreeBSD.org> <4C8CB211.6020308@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , Andriy Gapon , nork@FreeBSD.org Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 11:26:14 -0000 Hi mav. On Sun, 12 Sep 2010 13:57:21 +0300 Alexander Motin wrote: > BTW, have you tried to unplug power? My laptop hides C3 state when power > cord is plugged-in. Oh! You are right! I got C3 state. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sep 12 20:14:54 pelsia kernel: ts_to_ct(1284322495.185795464) = [2010-09-12 20:14:55] Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [862354] cpu_cx_cst : acpi_cpu0: Got C2 - 205 latency Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [862355] cpu_cx_cst : acpi_cpu0: Got C3 - 245 latency Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [862936] cpu_cx_cst : acpi_cpu1: Got C2 - 205 latency Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [862936] cpu_cx_cst : acpi_cpu1: Got C3 - 245 latency Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [863524] cpu_cx_cst : acpi_cpu2: Got C2 - 205 latency Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [863524] cpu_cx_cst : acpi_cpu2: Got C3 - 245 latency Sep 12 20:19:04 pelsia power_profile: changed to 'economy' Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [864399] cpu_cx_cst : system power profile changedacpi_cpu3: Got C2 to 'economy'- 205 latency Sep 12 20:19:04 pelsia kernel: Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [864516] cpu_cx_cst : acpi_cpu3: Got C3 - 245 latency Sep 12 20:19:04 pelsia kernel: acpi_acad0: Off Line Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [872292] cpu_cx_cst : acpi_cpu0: Got C2 - 205 latency Sep 12 20:19:04 pelsia kernel: PROCESSOR-0722 [872394] cpu_cx_cst : acpi_cpu0: Got C3 - 245 latency Sep 12 20:19:05 pelsia kernel: PROCESSOR-0722 [873422] cpu_cx_cst : acpi_cpu1: Got C2 - 205 latency Sep 12 20:19:05 pelsia kernel: PROCESSOR-0722 [873422] cpu_cx_cst : acpi_cpu1: Got C3 - 245 latency Sep 12 20:19:05 pelsia kernel: PROCESSOR-0722 [874564] cpu_cx_cst : acpi_cpu2: Got C2 - 205 latency Sep 12 20:19:05 pelsia kernel: PROCESSOR-0722 [874576] cpu_cx_cst : acpi_cpu2: Got C3 - 245 latency Sep 12 20:19:05 pelsia kernel: PROCESSOR-0722 [875727] cpu_cx_cst : acpi_cpu3: Got C2 - 205 latency Sep 12 20:19:05 pelsia kernel: PROCESSOR-0722 [875727] cpu_cx_cst : acpi_cpu3: Got C3 - 245 latency Sep 12 20:19:12 pelsia kernel: PROCESSOR-0722 [889604] cpu_cx_cst : acpi_cpu0: Got C2 - 205 latency Sep 12 20:19:12 pelsia kernel: PROCESSOR-0722 [889604] cpu_cx_cst : acpi_cpu0: Got C3 - 245 latency Sep 12 20:19:13 pelsia kernel: PROCESSOR-0722 [890194] cpu_cx_cst : acpi_cpu1: Got C2 - 205 latency Sep 12 20:19:13 pelsia kernel: PROCESSOR-0722 [890194] cpu_cx_cst : acpi_cpu1: Got C3 - 245 latency Sep 12 20:19:13 pelsia kernel: PROCESSOR-0722 [890784] cpu_cx_cst : acpi_cpu2: Got C2 - 205 latency Sep 12 20:19:13 pelsia kernel: PROCESSOR-0722 [890784] cpu_cx_cst : acpi_cpu2: Got C3 - 245 latency Sep 12 20:19:13 pelsia kernel: PROCESSOR-0722 [891441] cpu_cx_cst : acpi_cpu3: Got C2 - 205 latency Sep 12 20:19:13 pelsia kernel: PROCESSOR-0722 [891441] cpu_cx_cst : acpi_cpu3: Got C3 - 245 latency Sep 12 20:20:43 pelsia kernel: PROCESSOR-0722 [1083168] cpu_cx_cst : acpi_cpu0: Got C2 - 205 latency Sep 12 20:20:43 pelsia kernel: PROCESSOR-0722 [1083197] cpu_cx_cst : acpi_cpu0: Got C3 - 245 latency Sep 12 20:20:43 pelsia kernel: PROCESSOR-0722 [1084498] cpu_cx_cst : acpi_cpu1: Got C2 - 205 latency Sep 12 20:20:43 pelsia kernel: PROCESSOR-0722 [1084498] cpu_cx_cst : acpi_cpu1: Got C3 - 245 latency Sep 12 20:20:43 pelsia kernel: PROCESSOR-0722 [1085468] cpu_cx_cst : acpi_cpu2: Got C2 - 205 latency Sep 12 20:20:43 pelsia kernel: PROCESSOR-0722 [1085468] cpu_cx_cst : acpi_cpu2: Got C3 - 245 latency Sep 12 20:20:44 pelsia kernel: PROCESSOR-0722 [1086504] cpu_cx_cst : acpi_cpu3: Got C2 - 205 latency Sep 12 20:20:44 pelsia kernel: PROCESSOR-0722 [1086508] cpu_cx_cst : acpi_cpu3: Got C3 - 245 latency - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # sysctl -a | grep cx hw.acpi.cpu.cx_lowest: C2 dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 dev.cpu.0.cx_lowest: C2 dev.cpu.0.cx_usage: 12.48% 87.51% 0.00% last 1947us dev.cpu.1.cx_supported: C1/3 C2/205 C3/245 dev.cpu.1.cx_lowest: C2 dev.cpu.1.cx_usage: 60.83% 39.16% 0.00% last 182us dev.cpu.2.cx_supported: C1/3 C2/205 C3/245 dev.cpu.2.cx_lowest: C2 dev.cpu.2.cx_usage: 45.65% 54.34% 0.00% last 36us dev.cpu.3.cx_supported: C1/3 C2/205 C3/245 dev.cpu.3.cx_lowest: C2 dev.cpu.3.cx_usage: 6.78% 93.21% 0.00% last 8038us - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # sysctl hw.acpi.cpu.cx_lowest=C3 && sleep 10 && sysctl dev.cpu.0.cx_usage dev.cpu.1.cx_usage dev.cpu.2.cx_usage dev.cpu.3.cx_usage hw.acpi.cpu.cx_lowest: C2 -> C3 dev.cpu.0.cx_usage: 0.73% 0.16% 99.10% last 2145us dev.cpu.1.cx_usage: 0.67% 0.22% 99.09% last 1559us dev.cpu.2.cx_usage: 0.27% 0.00% 99.72% last 13994us dev.cpu.3.cx_usage: 0.81% 0.27% 98.91% last 21592us - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Humm.. Why only C3 state appear when unplug power? :-( Thank you. -- Norikatsu Shigemura From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 12:01:59 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id F08D0106566B; Sun, 12 Sep 2010 12:01:58 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Sun, 12 Sep 2010 21:01:53 +0900 From: Norikatsu Shigemura To: FreeBSD-Current Message-Id: <20100912210153.622b2920.nork@FreeBSD.org> In-Reply-To: <20100912202607.07ee9f64.nork@FreeBSD.org> References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9F06.4090505@icyb.net.ua> <20100912190537.621e357e.nork@FreeBSD.org> <20100912190952.8c0d5726.nork@FreeBSD.org> <20100912192518.e791c191.nork@FreeBSD.org> <4C8CAC01.70004@icyb.net.ua> <4C8CAD7D.50602@FreeBSD.org> <4C8CB211.6020308@FreeBSD.org> <20100912202607.07ee9f64.nork@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alexander Motin , Andriy Gapon , Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 12:01:59 -0000 Hi. On Sun, 12 Sep 2010 20:26:07 +0900 Norikatsu Shigemura wrote: > Humm.. Why only C3 state appear when unplug power? :-( Ah, I got it. Every times, evaluating _CST on acpi_cpu_cx_cst, and _CST is a black box because I couldn't see _CST. Maybe, _CST look at AC status. So I think that following patch is OK. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --- sys/dev/acpica/acpi_cpu.c.orig 2010-09-12 01:31:38.144243000 +0900 +++ sys/dev/acpica/acpi_cpu.c 2010-09-12 20:53:49.252917961 +0900 @@ -690,19 +690,11 @@ sc->cpu_cx_count++; continue; case ACPI_STATE_C2: - if (cx_ptr->trans_lat > 100) { - ACPI_DEBUG_PRINT((ACPI_DB_INFO, - "acpi_cpu%d: C2[%d] not available.\n", - device_get_unit(sc->cpu_dev), i)); - continue; - } sc->cpu_non_c3 = i; break; case ACPI_STATE_C3: default: - if (cx_ptr->trans_lat > 1000 || - (cpu_quirks & CPU_QUIRK_NO_C3) != 0) { - + if (cpu_quirks & CPU_QUIRK_NO_C3) { ACPI_DEBUG_PRINT((ACPI_DB_INFO, "acpi_cpu%d: C3[%d] not available.\n", device_get_unit(sc->cpu_dev), i)); - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Thank you. -- Norikatsu Shigemura From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 14:43:02 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43DCD106564A for ; Sun, 12 Sep 2010 14:43:02 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id ED9EF8FC16 for ; Sun, 12 Sep 2010 14:43:01 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id A627360DB for ; Sun, 12 Sep 2010 10:43:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1284302580; bh=w4xCXQWloA8pSZ2LwdN9I5nEEmTvRhfSjiJ91ftnarY=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=LHMoi9oWZ81tokUjDYqLoINi2fo6LRh/QtkUEYcNprVZCXomO62TKyYpj+wy8sWGN qbRtovMlFiMLPfGetrXa7wBSA+yez9DFDOReCF8jw+Y89+bOWUjKHpDLDcfBYQ4 DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: x-enigmail-version:openpgp:content-type; b=PxjW1Rp2COCnDFzlkGihy2/px8fbT4BAU8x7OvG6RYtxEbEi5rFCeyJZJwDzo1Gn/ zyfkoU1x+NWgS0KGzD2wcWNx6GNZloF70zLXqWjsmYzdXlI5DFXTFesGC2M/uzm Message-ID: <4C8CE6F1.3030400@protected-networks.net> Date: Sun, 12 Sep 2010 10:42:57 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.9) Gecko/20100911 Thunderbird/3.1.3 MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 1.1.2 OpenPGP: id=0442D492 Content-Type: multipart/mixed; boundary="------------060306090909040004080408" Cc: Subject: r212281 breaks KDE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 14:43:02 -0000 This is a multi-part message in MIME format. --------------060306090909040004080408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit For the last week, on and off, I've been looking for something that caused KDE to be horridly unstable, i.e. machine freezes with and without a core-dump. Removing r212281 (and r212282) restores that stability. Is there a race condition that this update exposes by reducing lock strength? The most common failure with this code included produces a back-trace similar to the one attached, imb --------------060306090909040004080408 Content-Type: text/plain; name="core.txt.0" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="core.txt.0" toshi.auburn.protected-networks.net dumped core - see /var/crash/vmcore.0 Sat Sep 11 15:33:22 EDT 2010 FreeBSD toshi.auburn.protected-networks.net 9.0-CURRENT FreeBSD 9.0-CURRENT #5 r212466M: Sat Sep 11 10:10:59 EDT 2010 root@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI i386 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x22c fault code = supervisor read, page not present instruction pointer = 0x20:0xc066705a stack pointer = 0x28:0xe944b7f8 frame pointer = 0x28:0xe944b810 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1938 (kdeinit4) trap number = 12 panic: page fault cpuid = 0 Uptime: 2m33s Physical memory: 3049 MB Dumping 225 MB: 210 194 178 162 146 130 114 98 82 66 50 34 18 2 Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko #0 doadump () at pcpu.h:231 231 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:231 #1 0xc06760f7 in boot (howto=260) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:416 #2 0xc06764e8 in panic (fmt=0x104
) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:590 #3 0xc09950ff in trap_fatal (frame=0xe944b7b8, eva=40) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:980 #4 0xc0995469 in trap_pfault (frame=0xe944b7b8, usermode=0, eva=556) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:893 #5 0xc09958f7 in trap (frame=0xe944b7b8) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:568 #6 0xc097e16c in calltrap () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:168 #7 0xc066705a in _mtx_lock_sleep (m=0xc81c26e8, tid=3343885696, opts=0, file=0x0, line=0) at /usr/home/imb/svn/head/sys/kern/kern_mutex.c:369 #8 0xc09385d8 in vnode_create_vobject (vp=0xc825a330, isize=512, td=0xc74fa580) at /usr/home/imb/svn/head/sys/vm/vnode_pager.c:111 #9 0xc0904751 in ufs_lookup_ino (vdp=0xc825a330, vpp=0xe944bb40, cnp=0xe944bb54, dd_ino=0x0) at /usr/home/imb/svn/head/sys/ufs/ufs/ufs_lookup.c:260 #10 0xc0905370 in ufs_lookup (ap=0xe944b97c) at /usr/home/imb/svn/head/sys/ufs/ufs/ufs_lookup.c:215 #11 0xc06f9cc6 in vfs_cache_lookup (ap=0xe944ba08) at vnode_if.h:80 #12 0xc09b2811 in VOP_LOOKUP_APV (vop=0xc0ac7480, a=0xe944ba08) at vnode_if.c:123 #13 0xc0700e89 in lookup (ndp=0xe944bb28) at vnode_if.h:54 #14 0xc070218c in namei (ndp=0xe944bb28) at /usr/home/imb/svn/head/sys/kern/vfs_lookup.c:268 #15 0xc0711513 in kern_statat_vnhook (td=0xc74fa580, flag=0, fd=-100, path=0x2b2aa050
, pathseg=UIO_USERSPACE, sbp=0xe944bbe4, hook=0) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:2352 #16 0xc07116b7 in kern_statat (td=0xc74fa580, flag=0, fd=-100, path=0x2b2aa050
, pathseg=UIO_USERSPACE, sbp=0xe944bbe4) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:2333 #17 0xc07117db in kern_stat (td=0xc74fa580, path=0x2b2aa050
, pathseg=UIO_USERSPACE, sbp=0xe944bbe4) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:2325 #18 0xc071186f in stat (td=0xc74fa580, uap=0xe944bcec) at /usr/home/imb/svn/head/sys/kern/vfs_syscalls.c:2294 #19 0xc06b4087 in syscallenter (td=0xc74fa580, sa=0xe944bce4) at /usr/home/imb/svn/head/sys/kern/subr_trap.c:319 #20 0xc09954cc in syscall (frame=0xe944bd28) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:1095 #21 0xc097e1d1 in Xint0x80_syscall () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:266 #22 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) --------------060306090909040004080408-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 11:32:44 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E50EF10656A4 for ; Sun, 12 Sep 2010 11:32:44 +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 AA2038FC13 for ; Sun, 12 Sep 2010 11:32:44 +0000 (UTC) Received: by smtpo.poczta.interia.pl (INTERIA.PL, from userid 502) id DA9BB1A42D6D; Sun, 12 Sep 2010 13:17:44 +0200 (CEST) Date: 12 Sep 2010 13:17:43 +0200 From: vermaden Sender: vermaden@interia.pl To: pjd@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=UTF-8 X-ORIGINATE-IP: 85.89.185.12 X-PRIORITY: 3 X-Mailer: PSE3 Message-Id: <20100912111743.F083C116E6@fwb.poczta.interia.pl> X-Interia-Antivirus: OK X-EMID: bfc40acc X-Mailman-Approved-At: Sun, 12 Sep 2010 15:07:08 +0000 Cc: freebsd-current@freebsd.org Subject: ZFS v28 is ready for wider testing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 11:32:45 -0000 Hi, I have just imported your VirtualBox appliance, created some zpool and wanted to try *dedup* on FreeBSD, but while I was able to enable *dedup*, I was not able to check *dedupratio* because that 'property' is not available, on OpenSolaris it looked like that: # zpool get dedupratio pool NAME PROPERTY VALUE SOURCE tpool dedupratio 1.00x - Regards, vermaden ---------------------------------------------- KONKURS: Wygraj nowoczesny telefon komorkowy! Sprawdz >> http://linkint.pl/f2803 From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 15:22:43 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEBA6106564A; Sun, 12 Sep 2010 15:22:43 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A00BF8FC17; Sun, 12 Sep 2010 15:22:42 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA28260; Sun, 12 Sep 2010 18:22:40 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OuoO8-000FyD-Ja; Sun, 12 Sep 2010 18:22:40 +0300 Message-ID: <4C8CF03F.1050902@icyb.net.ua> Date: Sun, 12 Sep 2010 18:22:39 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alexander Motin References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9F06.4090505@icyb.net.ua> <20100912190537.621e357e.nork@FreeBSD.org> <20100912190952.8c0d5726.nork@FreeBSD.org> <20100912192518.e791c191.nork@FreeBSD.org> <4C8CAC01.70004@icyb.net.ua> <4C8CAD7D.50602@FreeBSD.org> In-Reply-To: <4C8CAD7D.50602@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 15:22:43 -0000 on 12/09/2010 13:37 Alexander Motin said the following: > Andriy Gapon wrote: >> acpi_lid0: Lid closed >> em0: Link is up 1000 Mbps Full Duplex >> PROCESSOR-0722 [402244] cpu_cx_cst : acpi_cpu0: Got C2 - 245 latency >> PROCESSOR-0722 [403097] cpu_cx_cst : acpi_cpu1: Got C2 - 245 latency >> PROCESSOR-0722 [403855] cpu_cx_cst : acpi_cpu2: Got C2 - 245 latency >> PROCESSOR-0722 [405022] cpu_cx_cst : acpi_cpu3: Got C2 - 245 latency >> >> Maybe because of this? >> It seems like you do something and ACPI disables C3, leaving only C2/ > > One strange thing. During boot it can be seen: > acpi_cpu0: Got C2 - 205 latency > acpi_cpu0: Got C3 - 245 latency > , but after boot in sysctl we can see: > dev.cpu.0.cx_supported: C1/3 C2/245 > > It respecting latency it looks like not C3 got lost, but C2. AFAIR, > sysctl numbers C-states completely abstract, just as array indexes. So > thing reported as C2 could instead be C3, while C2 is absent for some > reason. Observations are correct, but incomplete; the conclusions are wrong. At the end of the boot there are message like this one: PROCESSOR-0722 [402244] cpu_cx_cst : acpi_cpu0: Got C2 - 245 latency This is a result of re-evaluation of _CST because of a notification from ACPI. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 15:32:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 336A21065673 for ; Sun, 12 Sep 2010 15:32:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id E4BB58FC0A for ; Sun, 12 Sep 2010 15:32:17 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAFmPjEyDaFvO/2dsb2JhbACDGZ8frC6QYoEigyp0BIon X-IronPort-AV: E=Sophos;i="4.56,355,1280721600"; d="scan'208";a="93596759" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 12 Sep 2010 11:32:17 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 252E0B3F39; Sun, 12 Sep 2010 11:32:17 -0400 (EDT) Date: Sun, 12 Sep 2010 11:32:17 -0400 (EDT) From: Rick Macklem To: Tim Kientzle Message-ID: <1596813331.782431.1284305537136.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-current@freebsd.org Subject: Re: Experimental NFS server oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 15:32:18 -0000 > On Sep 11, 2010, at 5:26 PM, Rick Macklem wrote: > >> On Sep 11, 2010, at 4:20 PM, Rick Macklem wrote: > >> > >>> You can also look in /var/log/messages to see if any of the > >>> daemons > >>> are complaining about something. > >> > >> Only warning I see on a system reboot is: > >> nfsd: can't open /var/db/nfs-stablerestart > >> > >> Creating this file and then rebooting the system seems to get > >> things > >> working. > >> > >> This file certainly wasn't required by the old nfsd. > >> Should this file be created by /etc/rc.d/nfsserver at boot time (if > >> it > >> doesn't exist)? > >> Or should it be created by installworld? > >> > > Technically, it should only be created for a fresh install on a disk > > that has never been set up before. (ie. Not on an update/upgrade > > unless it has never existed before.) > > .... > > As such, I just documented it in "man nfsv4" for now, > > This is going to bite people on upgrades since > the old server didn't require this file, so people > upgrading from the old nfsd are going to hit > this problem pretty consistently. > > I'd like to at least consider alternatives to the > current behavior; maybe one of the following? > * If the file doesn't exist on startup, create it > and warn loudly. > * Similar to isc-dhcp, periodically make a > a backup copy of the file and only create a > fresh blank one if the file and backup are > both missing. I think this might be a reasonable compromise. The kernel can signal the master nfsd (which remains in userland) to copy the file to a backup after it has been updated, then the backup can be used if the regular one is lost/corrupted. If neither exists, creating new ones seems reasonable. Other opinions? rick > * "make installworld" is certainly capable > of creating this file only if it doesn't already > exist. (That doesn't cover the binary > update case, of course.) From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 15:39:01 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98BF6106566B; Sun, 12 Sep 2010 15:39:01 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 477308FC13; Sun, 12 Sep 2010 15:39:00 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA28410; Sun, 12 Sep 2010 18:38:58 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ouodu-000Fyv-Lm; Sun, 12 Sep 2010 18:38:58 +0300 Message-ID: <4C8CF412.9080601@icyb.net.ua> Date: Sun, 12 Sep 2010 18:38:58 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.8) Gecko/20100822 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alexander Motin References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9F06.4090505@icyb.net.ua> <20100912190537.621e357e.nork@FreeBSD.org> <20100912190952.8c0d5726.nork@FreeBSD.org> <20100912192518.e791c191.nork@FreeBSD.org> <4C8CAC01.70004@icyb.net.ua> <4C8CAD7D.50602@FreeBSD.org> <4C8CF03F.1050902@icyb.net.ua> In-Reply-To: <4C8CF03F.1050902@icyb.net.ua> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, FreeBSD-Current , Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 15:39:01 -0000 on 12/09/2010 18:22 Andriy Gapon said the following: > Observations are correct, but incomplete; the conclusions are wrong. > At the end of the boot there are message like this one: > PROCESSOR-0722 [402244] cpu_cx_cst : acpi_cpu0: Got C2 - 245 latency > This is a result of re-evaluation of _CST because of a notification from ACPI. > But still, as you suggest, a patch like the following should be tested and committed: --- a/sys/dev/acpica/acpi_cpu.c +++ b/sys/dev/acpica/acpi_cpu.c @@ -828,7 +828,8 @@ acpi_cpu_cx_list(struct acpi_cpu_softc *sc) sbuf_new(&sb, sc->cpu_cx_supported, sizeof(sc->cpu_cx_supported), SBUF_FIXEDLEN); for (i = 0; i < sc->cpu_cx_count; i++) { - sbuf_printf(&sb, "C%d/%d ", i + 1, sc->cpu_cx_states[i].trans_lat); + sbuf_printf(&sb, "C%d/%d ", sc->cpu_cx_states[i].type, + sc->cpu_cx_states[i].trans_lat); if (sc->cpu_cx_states[i].type < ACPI_STATE_C3) sc->cpu_non_c3 = i; } P.S. I restored acpi@ cc: which I think is quite relevant, but was somehow lost. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 15:49:53 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id C24E1106566B; Sun, 12 Sep 2010 15:49:52 +0000 (UTC) (envelope-from nork@FreeBSD.org) Date: Mon, 13 Sep 2010 00:49:46 +0900 From: Norikatsu Shigemura To: Andriy Gapon Message-Id: <20100913004946.6cf945a4.nork@FreeBSD.org> In-Reply-To: <4C8CF412.9080601@icyb.net.ua> References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9F06.4090505@icyb.net.ua> <20100912190537.621e357e.nork@FreeBSD.org> <20100912190952.8c0d5726.nork@FreeBSD.org> <20100912192518.e791c191.nork@FreeBSD.org> <4C8CAC01.70004@icyb.net.ua> <4C8CAD7D.50602@FreeBSD.org> <4C8CF03F.1050902@icyb.net.ua> <4C8CF412.9080601@icyb.net.ua> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alexander Motin , FreeBSD-Current , freebsd-acpi@FreeBSD.org, nork@FreeBSD.org Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 15:49:53 -0000 Hi avg. On Sun, 12 Sep 2010 18:38:58 +0300 Andriy Gapon wrote: > > Observations are correct, but incomplete; the conclusions are wrong. > > At the end of the boot there are message like this one: > > PROCESSOR-0722 [402244] cpu_cx_cst : acpi_cpu0: Got C2 - 245 latency > > This is a result of re-evaluation of _CST because of a notification from ACPI. > But still, as you suggest, a patch like the following should be tested and > committed: Thank you, I'll test your patch. But I'm rebuilding another patches. So please wait next day. -- Norikatsu Shigemura From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 16:01:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13459106566B; Sun, 12 Sep 2010 16:01:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 164D88FC16; Sun, 12 Sep 2010 16:01:24 +0000 (UTC) Received: by bwz20 with SMTP id 20so551750bwz.13 for ; Sun, 12 Sep 2010 09:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=X3ZUo83li3tbc3q6MlfpuTAULq8PwGFt+bPVcJdI/UY=; b=xJ2ea56B54hfEO42RGWSQXusMpRqrvsJgaP4jUp1MNevSVtbn+Us/3v1IUaG0HRvhe xKiVaOmpfeSMiDI8DW1+jOtECURjRM598htYZramyg5Ja3ToHcsVINezl4Dmh911A214 Qy8VKoyarjd7MJm6dr69GngFiop0rwbHgWNZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=LqFIkqJJLdpuakqMZGAtAIHZndGkIPeauJTYL0p4jDqYtG9jxOI0WMOwpFfvaxrEaP WrfYzArA0owTLnhiqDJuVGw4P34Tls2xxK1vx5g5hdHzALJmQFhVH3SsZFYqaOy+ScHy 2je+jUA5ZyJI9Rm7+QoTVp1OEoIy9bcgFOsOg= Received: by 10.204.76.205 with SMTP id d13mr2335335bkk.93.1284307249155; Sun, 12 Sep 2010 09:00:49 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id f16sm3802503bkd.16.2010.09.12.09.00.45 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Sep 2010 09:00:47 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8CF91A.4040804@FreeBSD.org> Date: Sun, 12 Sep 2010 19:00:26 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Andriy Gapon References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9F06.4090505@icyb.net.ua> <20100912190537.621e357e.nork@FreeBSD.org> <20100912190952.8c0d5726.nork@FreeBSD.org> <20100912192518.e791c191.nork@FreeBSD.org> <4C8CAC01.70004@icyb.net.ua> <4C8CAD7D.50602@FreeBSD.org> <4C8CF03F.1050902@icyb.net.ua> <4C8CF412.9080601@icyb.net.ua> In-Reply-To: <4C8CF412.9080601@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, FreeBSD-Current , Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 16:01:26 -0000 Andriy Gapon wrote: > on 12/09/2010 18:22 Andriy Gapon said the following: >> Observations are correct, but incomplete; the conclusions are wrong. >> At the end of the boot there are message like this one: >> PROCESSOR-0722 [402244] cpu_cx_cst : acpi_cpu0: Got C2 - 245 latency >> This is a result of re-evaluation of _CST because of a notification from ACPI. > > But still, as you suggest, a patch like the following should be tested and > committed: > > --- a/sys/dev/acpica/acpi_cpu.c > +++ b/sys/dev/acpica/acpi_cpu.c > @@ -828,7 +828,8 @@ acpi_cpu_cx_list(struct acpi_cpu_softc *sc) > sbuf_new(&sb, sc->cpu_cx_supported, sizeof(sc->cpu_cx_supported), > SBUF_FIXEDLEN); > for (i = 0; i < sc->cpu_cx_count; i++) { > - sbuf_printf(&sb, "C%d/%d ", i + 1, sc->cpu_cx_states[i].trans_lat); > + sbuf_printf(&sb, "C%d/%d ", sc->cpu_cx_states[i].type, > + sc->cpu_cx_states[i].trans_lat); > if (sc->cpu_cx_states[i].type < ACPI_STATE_C3) > sc->cpu_non_c3 = i; > } I am not sure this patch is complete: 1) AFAIR I have seen somewhere example where system had several C-states with different latency, but the same type - C3. Type only means enter/exit semantics, and there could be several states with the same semantics. Not sire how to properly them in this case. May be existing approach was not so bad. It is ACPI C-states, not CPU C-states, they are not same. May be we should just mention type somewhere in addition. 2) This change makes heavily understandable values of cx_lowest. 3) If touch cx_lowest, I would prefer to see there possibility to set it to some abstract C6 or whatever, allowing system automatically choose state it has available at the moment. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 16:06:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E714C106564A; Sun, 12 Sep 2010 16:06:46 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 14D818FC12; Sun, 12 Sep 2010 16:06:45 +0000 (UTC) Received: by bwz20 with SMTP id 20so555039bwz.13 for ; Sun, 12 Sep 2010 09:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=X3ZUo83li3tbc3q6MlfpuTAULq8PwGFt+bPVcJdI/UY=; b=xJ2ea56B54hfEO42RGWSQXusMpRqrvsJgaP4jUp1MNevSVtbn+Us/3v1IUaG0HRvhe xKiVaOmpfeSMiDI8DW1+jOtECURjRM598htYZramyg5Ja3ToHcsVINezl4Dmh911A214 Qy8VKoyarjd7MJm6dr69GngFiop0rwbHgWNZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=LqFIkqJJLdpuakqMZGAtAIHZndGkIPeauJTYL0p4jDqYtG9jxOI0WMOwpFfvaxrEaP WrfYzArA0owTLnhiqDJuVGw4P34Tls2xxK1vx5g5hdHzALJmQFhVH3SsZFYqaOy+ScHy 2je+jUA5ZyJI9Rm7+QoTVp1OEoIy9bcgFOsOg= Received: by 10.204.76.205 with SMTP id d13mr2335335bkk.93.1284307249155; Sun, 12 Sep 2010 09:00:49 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id f16sm3802503bkd.16.2010.09.12.09.00.45 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Sep 2010 09:00:47 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8CF91A.4040804@FreeBSD.org> Date: Sun, 12 Sep 2010 19:00:26 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Andriy Gapon References: <4C8BCAC5.5050008@root.org> <4C8C8B64.8020907@FreeBSD.org> <20100912182625.c49d3f1d.nork@FreeBSD.org> <4C8C9F06.4090505@icyb.net.ua> <20100912190537.621e357e.nork@FreeBSD.org> <20100912190952.8c0d5726.nork@FreeBSD.org> <20100912192518.e791c191.nork@FreeBSD.org> <4C8CAC01.70004@icyb.net.ua> <4C8CAD7D.50602@FreeBSD.org> <4C8CF03F.1050902@icyb.net.ua> <4C8CF412.9080601@icyb.net.ua> In-Reply-To: <4C8CF412.9080601@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, FreeBSD-Current , Norikatsu Shigemura Subject: Re: CPU C-state storange on Panasonic TOUGH BOOK CF-R9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 16:06:47 -0000 Andriy Gapon wrote: > on 12/09/2010 18:22 Andriy Gapon said the following: >> Observations are correct, but incomplete; the conclusions are wrong. >> At the end of the boot there are message like this one: >> PROCESSOR-0722 [402244] cpu_cx_cst : acpi_cpu0: Got C2 - 245 latency >> This is a result of re-evaluation of _CST because of a notification from ACPI. > > But still, as you suggest, a patch like the following should be tested and > committed: > > --- a/sys/dev/acpica/acpi_cpu.c > +++ b/sys/dev/acpica/acpi_cpu.c > @@ -828,7 +828,8 @@ acpi_cpu_cx_list(struct acpi_cpu_softc *sc) > sbuf_new(&sb, sc->cpu_cx_supported, sizeof(sc->cpu_cx_supported), > SBUF_FIXEDLEN); > for (i = 0; i < sc->cpu_cx_count; i++) { > - sbuf_printf(&sb, "C%d/%d ", i + 1, sc->cpu_cx_states[i].trans_lat); > + sbuf_printf(&sb, "C%d/%d ", sc->cpu_cx_states[i].type, > + sc->cpu_cx_states[i].trans_lat); > if (sc->cpu_cx_states[i].type < ACPI_STATE_C3) > sc->cpu_non_c3 = i; > } I am not sure this patch is complete: 1) AFAIR I have seen somewhere example where system had several C-states with different latency, but the same type - C3. Type only means enter/exit semantics, and there could be several states with the same semantics. Not sire how to properly them in this case. May be existing approach was not so bad. It is ACPI C-states, not CPU C-states, they are not same. May be we should just mention type somewhere in addition. 2) This change makes heavily understandable values of cx_lowest. 3) If touch cx_lowest, I would prefer to see there possibility to set it to some abstract C6 or whatever, allowing system automatically choose state it has available at the moment. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 16:19:12 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA0B3106566B for ; Sun, 12 Sep 2010 16:19:12 +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 516C48FC18 for ; Sun, 12 Sep 2010 16:19:11 +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 o8CGJ1S6095298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Sep 2010 19:19:01 +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 o8CGJ1Re006256; Sun, 12 Sep 2010 19:19:01 +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 o8CGJ1Tx006255; Sun, 12 Sep 2010 19:19:01 +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: Sun, 12 Sep 2010 19:19:01 +0300 From: Kostik Belousov To: Michael Butler Message-ID: <20100912161901.GD2465@deviant.kiev.zoral.com.ua> References: <4C8CE6F1.3030400@protected-networks.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZNveOOYjKturpEFp" Content-Disposition: inline In-Reply-To: <4C8CE6F1.3030400@protected-networks.net> 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=-2.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_20, 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: current@freebsd.org Subject: Re: r212281 breaks KDE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 16:19:12 -0000 --ZNveOOYjKturpEFp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 12, 2010 at 10:42:57AM -0400, Michael Butler wrote: > For the last week, on and off, I've been looking for something that > caused KDE to be horridly unstable, i.e. machine freezes with and > without a core-dump. >=20 > Removing r212281 (and r212282) restores that stability. Is there a race > condition that this update exposes by reducing lock strength? >=20 > The most common failure with this code included produces a back-trace > similar to the one attached, >=20 Does the following change make any difference to you ? diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c index 63dfb67..d13e488 100644 --- a/sys/vm/vm_mmap.c +++ b/sys/vm/vm_mmap.c @@ -597,13 +597,15 @@ munmap(td, uap) =20 #ifdef HWPMC_HOOKS /* downgrade the lock to prevent a LOR with the pmc-sx lock */ - vm_map_lock_downgrade(map); - if (pkm.pm_address !=3D (uintptr_t) NULL) - PMC_CALL_HOOK(td, PMC_FN_MUNMAP, (void *) &pkm); - vm_map_unlock_read(map); -#else - vm_map_unlock(map); + if (pkm.pm_address !=3D (uintptr_t)NULL) { + vm_map_lock_downgrade(map); + if (pkm.pm_address !=3D (uintptr_t)NULL) + PMC_CALL_HOOK(td, PMC_FN_MUNMAP, (void *)&pkm); + vm_map_unlock_read(map); + vm_map_lock(map); + } #endif + vm_map_unlock(map); /* vm_map_delete returns nothing but KERN_SUCCESS anyway */ return (0); } --ZNveOOYjKturpEFp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkyM/XQACgkQC3+MBN1Mb4g4QACgvXM8hMci7wFPLrvZijoHBGt6 mVEAoMu0QVgJiDk3VxgWgDSU9JuBNq0Q =SORO -----END PGP SIGNATURE----- --ZNveOOYjKturpEFp-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 16:57:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 204E41065672; Sun, 12 Sep 2010 16:57:45 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 804888FC1C; Sun, 12 Sep 2010 16:57:43 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id o8CGNqG8089754; Sun, 12 Sep 2010 18:23:53 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id o8CGNqJ6089753; Sun, 12 Sep 2010 18:23:52 +0200 (CEST) (envelope-from marius) Date: Sun, 12 Sep 2010 18:23:52 +0200 From: Marius Strobl To: Alexander Best Message-ID: <20100912162352.GA89643@alchemy.franken.de> References: <20100909191750.GA58228@freebsd.org> <20100909194109.GA64914@freebsd.org> <20100909195045.GA68352@freebsd.org> <201009100747.39964.jhb@freebsd.org> <20100912024049.GA32655@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100912024049.GA32655@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: {arch}/conf/DEFAULTS and uart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 16:57:45 -0000 On Sun, Sep 12, 2010 at 02:40:49AM +0000, Alexander Best wrote: > On Fri Sep 10 10, John Baldwin wrote: > > On Thursday, September 09, 2010 3:50:45 pm Alexander Best wrote: > > > On Thu Sep 9 10, Alexander Best wrote: > > > > On Thu Sep 9 10, Alexander Best wrote: > > > > > hi there, > > > > > > > > > > except for arm most archs seem to enforce uart support in conf/DEFAULTS. is > > > > > this really necessary? shouldn't DEFAULTS only contain vital devices/options > > > > > without a kernel on a specific arch won't function at all? > > > > > > > > jhb just explained to me, that the uart entry in DEFAULTS is not a controller > > > > or something like that, but the uart backend to use *if* uart gets defined in > > > > the kernel config. > > > > > > > > sorry for the noise folks. > > > > > > however i found some missing comments and incorrect syntax which i fixed. > > > > > > see the attached patch. > > > > I think the ia64 ordering for 'io and mem' is probably more correct > > (alphabetically sorted), so I would fix i386 and amd64 and leave ia64 alone. > > > > The powerpc 'machine' changes are wrong I think as it would break GENERIC64 > > and powerpc64 kernel configs in general. Nathan purposefully removed > > 'machine' from the powerpc DEFAULTS. > > here's try #2. ;) > > diff --git a/sys/sparc64/conf/DEFAULTS b/sys/sparc64/conf/DEFAULTS > index 38b2408..2e60c94 100644 > --- a/sys/sparc64/conf/DEFAULTS > +++ b/sys/sparc64/conf/DEFAULTS > @@ -5,7 +5,7 @@ > > machine sparc64 > > -# Pseudo devices. > +# Pseudo devices > device mem # Memory and kernel memory devices > > # UART chips on this platform > @@ -17,5 +17,5 @@ device uart_z8530 > options GEOM_PART_BSD > options GEOM_PART_VTOC8 > > -# Let sunkbd emulate an AT keyboard by default. > +# Let sunkbd emulate an AT keyboard by default IMO this is a complete sentence and thus the period should stay. Marius From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 17:03:44 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 0BE0A1065673; Sun, 12 Sep 2010 17:03:44 +0000 (UTC) Date: Sun, 12 Sep 2010 17:03:44 +0000 From: Alexander Best To: Marius Strobl Message-ID: <20100912170344.GA58722@freebsd.org> References: <20100909191750.GA58228@freebsd.org> <20100909194109.GA64914@freebsd.org> <20100909195045.GA68352@freebsd.org> <201009100747.39964.jhb@freebsd.org> <20100912024049.GA32655@freebsd.org> <20100912162352.GA89643@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100912162352.GA89643@alchemy.franken.de> Cc: freebsd-current@freebsd.org Subject: Re: {arch}/conf/DEFAULTS and uart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 17:03:44 -0000 On Sun Sep 12 10, Marius Strobl wrote: > On Sun, Sep 12, 2010 at 02:40:49AM +0000, Alexander Best wrote: > > On Fri Sep 10 10, John Baldwin wrote: > > > On Thursday, September 09, 2010 3:50:45 pm Alexander Best wrote: > > > > On Thu Sep 9 10, Alexander Best wrote: > > > > > On Thu Sep 9 10, Alexander Best wrote: > > > > > > hi there, > > > > > > > > > > > > except for arm most archs seem to enforce uart support in conf/DEFAULTS. is > > > > > > this really necessary? shouldn't DEFAULTS only contain vital devices/options > > > > > > without a kernel on a specific arch won't function at all? > > > > > > > > > > jhb just explained to me, that the uart entry in DEFAULTS is not a controller > > > > > or something like that, but the uart backend to use *if* uart gets defined in > > > > > the kernel config. > > > > > > > > > > sorry for the noise folks. > > > > > > > > however i found some missing comments and incorrect syntax which i fixed. > > > > > > > > see the attached patch. > > > > > > I think the ia64 ordering for 'io and mem' is probably more correct > > > (alphabetically sorted), so I would fix i386 and amd64 and leave ia64 alone. > > > > > > The powerpc 'machine' changes are wrong I think as it would break GENERIC64 > > > and powerpc64 kernel configs in general. Nathan purposefully removed > > > 'machine' from the powerpc DEFAULTS. > > > > here's try #2. ;) > > > > diff --git a/sys/sparc64/conf/DEFAULTS b/sys/sparc64/conf/DEFAULTS > > index 38b2408..2e60c94 100644 > > --- a/sys/sparc64/conf/DEFAULTS > > +++ b/sys/sparc64/conf/DEFAULTS > > @@ -5,7 +5,7 @@ > > > > machine sparc64 > > > > -# Pseudo devices. > > +# Pseudo devices > > device mem # Memory and kernel memory devices > > > > # UART chips on this platform > > @@ -17,5 +17,5 @@ device uart_z8530 > > options GEOM_PART_BSD > > options GEOM_PART_VTOC8 > > > > -# Let sunkbd emulate an AT keyboard by default. > > +# Let sunkbd emulate an AT keyboard by default > > IMO this is a complete sentence and thus the period should stay. agreed. :) also i think i accidently replaced the tab between the two words "powerpc" in sys/powerpc/conf/GENERIC with a space. :( also i noticed that after keywords like "device" there're two tabs, whereas after the keyword "options" there's one space and a tab. since i don't know, if this was done on purpose i didn't change it. cheers. alex > > Marius > -- a13x From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 18:24:31 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 411B21065670 for ; Sun, 12 Sep 2010 18:24:31 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 05DED8FC14 for ; Sun, 12 Sep 2010 18:24:31 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id CD12B60DB; Sun, 12 Sep 2010 14:24:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1284315869; bh=dLATSujHQOHcLff1YICdGPt7p3blTixj63eTXSJQCa0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Diq7UPYzjVWuy5vKDRlrivgpMCeyz7PHIueazH9P4EYmIPA5rzMiMqHVl/WXH2y+R qdKTazoySePCdXyTcQM4IZOCpPJ+2q7LOt/Pg4oxLiJSzwAJr9Ml1riZmaczuBW DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=mUScnGWLXsHqD7rmjRHMMCDG8xFDMpmrwvz9oosaNnECOl/x49bE6h8Ia0RxhKsjL IqxGnkb7cgBv8ODMHrUGxkaQwgwgOKt5vLZetaWVWUyH2FVV1D8JWn8YYGTVBz8 Message-ID: <4C8D1ADA.1090004@protected-networks.net> Date: Sun, 12 Sep 2010 14:24:26 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.9) Gecko/20100911 Thunderbird/3.1.3 MIME-Version: 1.0 To: Kostik Belousov References: <4C8CE6F1.3030400@protected-networks.net> <20100912161901.GD2465@deviant.kiev.zoral.com.ua> In-Reply-To: <20100912161901.GD2465@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: r212281 breaks KDE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 18:24:31 -0000 On 09/12/10 12:19, Kostik Belousov wrote: > On Sun, Sep 12, 2010 at 10:42:57AM -0400, Michael Butler wrote: >> >> Removing r212281 (and r212282) restores that stability. Is there a race >> condition that this update exposes by reducing lock strength? [ .. ] > Does the following change make any difference to you ? It made it worse :-( "Frozen" just as X tries to take over the display, imb From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 19:19:09 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D351C1065672 for ; Sun, 12 Sep 2010 19:19:09 +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 701D38FC19 for ; Sun, 12 Sep 2010 19:19:09 +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 o8CJJ5pm007326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Sep 2010 22:19:05 +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 o8CJJ4Vo010228; Sun, 12 Sep 2010 22:19:04 +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 o8CJJ4tD010227; Sun, 12 Sep 2010 22:19:04 +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: Sun, 12 Sep 2010 22:19:04 +0300 From: Kostik Belousov To: Michael Butler Message-ID: <20100912191904.GF2465@deviant.kiev.zoral.com.ua> References: <4C8CE6F1.3030400@protected-networks.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p8BcnzLwh3ipgLRM" Content-Disposition: inline In-Reply-To: <4C8CE6F1.3030400@protected-networks.net> 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=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, 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: current@freebsd.org Subject: Re: r212281 breaks KDE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 19:19:09 -0000 --p8BcnzLwh3ipgLRM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 12, 2010 at 10:42:57AM -0400, Michael Butler wrote: > For the last week, on and off, I've been looking for something that > caused KDE to be horridly unstable, i.e. machine freezes with and > without a core-dump. >=20 > Removing r212281 (and r212282) restores that stability. Is there a race > condition that this update exposes by reducing lock strength? >=20 > The most common failure with this code included produces a back-trace > similar to the one attached, >=20 > imb > toshi.auburn.protected-networks.net dumped core - see /var/crash/vmcore.0 >=20 > Sat Sep 11 15:33:22 EDT 2010 >=20 > FreeBSD toshi.auburn.protected-networks.net 9.0-CURRENT FreeBSD 9.0-CURRE= NT #5 r212466M: Sat Sep 11 10:10:59 EDT 2010 root@toshi.auburn.protecte= d-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI i386 >=20 > panic: page fault >=20 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "i386-marcel-freebsd"... >=20 > Unread portion of the kernel message buffer: >=20 >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x22c > fault code =3D supervisor read, page not present > instruction pointer =3D 0x20:0xc066705a > stack pointer =3D 0x28:0xe944b7f8 > frame pointer =3D 0x28:0xe944b810 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 1938 (kdeinit4) > trap number =3D 12 > panic: page fault > cpuid =3D 0 > Uptime: 2m33s > Physical memory: 3049 MB > Dumping 225 MB: 210 194 178 162 146 130 114 98 82 66 50 34 18 2 >=20 > Reading symbols from /boot/modules/vboxdrv.ko...done. > Loaded symbols for /boot/modules/vboxdrv.ko > Reading symbols from /boot/modules/vboxnetflt.ko...done. > Loaded symbols for /boot/modules/vboxnetflt.ko > Reading symbols from /boot/modules/vboxnetadp.ko...done. > Loaded symbols for /boot/modules/vboxnetadp.ko > Reading symbols from /usr/local/modules/fuse.ko...done. > Loaded symbols for /usr/local/modules/fuse.ko > #0 doadump () at pcpu.h:231 > 231 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:231 > #1 0xc06760f7 in boot (howto=3D260) > at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:416 > #2 0xc06764e8 in panic (fmt=3D0x104
) > at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:590 > #3 0xc09950ff in trap_fatal (frame=3D0xe944b7b8, eva=3D40) > at /usr/home/imb/svn/head/sys/i386/i386/trap.c:980 > #4 0xc0995469 in trap_pfault (frame=3D0xe944b7b8, usermode=3D0, eva=3D55= 6) > at /usr/home/imb/svn/head/sys/i386/i386/trap.c:893 > #5 0xc09958f7 in trap (frame=3D0xe944b7b8) > at /usr/home/imb/svn/head/sys/i386/i386/trap.c:568 > #6 0xc097e16c in calltrap () > at /usr/home/imb/svn/head/sys/i386/i386/exception.s:168 > #7 0xc066705a in _mtx_lock_sleep (m=3D0xc81c26e8, tid=3D3343885696, opts= =3D0,=20 > file=3D0x0, line=3D0) at /usr/home/imb/svn/head/sys/kern/kern_mutex.c= :369 > #8 0xc09385d8 in vnode_create_vobject (vp=3D0xc825a330, isize=3D512,=20 > td=3D0xc74fa580) at /usr/home/imb/svn/head/sys/vm/vnode_pager.c:111 =46rom the frame 8, please print the content of the *vp, and from it, content of vm object. The corresponding kgdb commands would be frame 8 p *vp p *(vp->v_bufobj.bo_object) --p8BcnzLwh3ipgLRM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkyNJ6gACgkQC3+MBN1Mb4hSkgCfde88UbO2VwA3NtCBiGljMG/K MbsAn2LEt3dOQERTl8JI2fCKHixKIjCo =sxBg -----END PGP SIGNATURE----- --p8BcnzLwh3ipgLRM-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 12 19:19:59 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86608106566B for ; Sun, 12 Sep 2010 19:19:59 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 14F058FC19 for ; Sun, 12 Sep 2010 19:19:58 +0000 (UTC) Received: by ewy4 with SMTP id 4so2842025ewy.13 for ; Sun, 12 Sep 2010 12:19:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=trksGf9t9iRZpSl7SW9B8VkxgcNSNZ0sMozYeoK9sws=; b=tOEeAo83giv2kf0U8t6+DEPSQZ/OcUk8Ivkx/pv2amhcz/IL+EVqiKAEQpZ6IH3cRw 4RpIyRkABJtT1Uk1EU5rcGGIO7fZ+m3FK/Ao61eu2RkTrNJm+6Mej7MDyWFN2Tl/UyIj 95OH2f0ihufoheqHvBTSI4ERWa7AW9zZbhqx8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BxN6aCbmKqZB/IuNXloA3Ur4QUuNTy1b1oGofbi7YVB7GTvr4XIVZr/1dcB2idvucl cDnHWamSSXUyIQQqug9LQU4sP6YlxO9bYiyx0kge7g+mUEiZgtPRE9f3fCObZTQUSCe9 KD3n1zIH7n1adr80XjqaApd/94UJ2Cw7kJays= MIME-Version: 1.0 Received: by 10.213.104.211 with SMTP id q19mr2180517ebo.45.1284317825741; Sun, 12 Sep 2010 11:57:05 -0700 (PDT) Received: by 10.213.28.19 with HTTP; Sun, 12 Sep 2010 11:57:05 -0700 (PDT) In-Reply-To: <4C8D1ADA.1090004@protected-networks.net> References: <4C8CE6F1.3030400@protected-networks.net> <20100912161901.GD2465@deviant.kiev.zoral.com.ua> <4C8D1ADA.1090004@protected-networks.net> Date: Sun, 12 Sep 2010 14:57:05 -0400 Message-ID: From: Ryan Stone To: Michael Butler Content-Type: multipart/mixed; boundary=00c09f7f9dcbc833680490148bc8 Cc: Kostik Belousov , current@freebsd.org Subject: Re: r212281 breaks KDE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 19:19:59 -0000 --00c09f7f9dcbc833680490148bc8 Content-Type: text/plain; charset=ISO-8859-1 Can you try the attached(hackish) patch? --00c09f7f9dcbc833680490148bc8 Content-Type: text/x-diff; charset=US-ASCII; name="unmap_entry_fix.diff" Content-Disposition: attachment; filename="unmap_entry_fix.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ge09kq0h0 SW5kZXg6IHZtX21hcC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHZtX21hcC5jCShyZXZpc2lvbiAyMTI0Nzkp CisrKyB2bV9tYXAuYwkod29ya2luZyBjb3B5KQpAQCAtMTI4LDcgKzEyOCw3IEBACiBzdGF0aWMg dm9pZCB2bV9tYXBfemZpbmkodm9pZCAqbWVtLCBpbnQgc2l6ZSk7CiBzdGF0aWMgdm9pZCBfdm1f bWFwX2luaXQodm1fbWFwX3QgbWFwLCBwbWFwX3QgcG1hcCwgdm1fb2Zmc2V0X3QgbWluLAogICAg IHZtX29mZnNldF90IG1heCk7Ci1zdGF0aWMgdm9pZCB2bV9tYXBfZW50cnlfZGlzcG9zZSh2bV9t YXBfdCBtYXAsIHZtX21hcF9lbnRyeV90IGVudHJ5KTsKK3ZvaWQgdm1fbWFwX2VudHJ5X2Rpc3Bv c2Uodm1fbWFwX3QgbWFwLCB2bV9tYXBfZW50cnlfdCBlbnRyeSk7CiAjaWZkZWYgSU5WQVJJQU5U Uwogc3RhdGljIHZvaWQgdm1fbWFwX3pkdG9yKHZvaWQgKm1lbSwgaW50IHNpemUsIHZvaWQgKmFy Zyk7CiBzdGF0aWMgdm9pZCB2bXNwYWNlX3pkdG9yKHZvaWQgKm1lbSwgaW50IHNpemUsIHZvaWQg KmFyZyk7CkBAIC03MTYsNyArNzE2LDcgQEAKICAqCiAgKglJbnZlcnNlIG9mIHZtX21hcF9lbnRy eV9jcmVhdGUuCiAgKi8KLXN0YXRpYyB2b2lkCit2b2lkCiB2bV9tYXBfZW50cnlfZGlzcG9zZSh2 bV9tYXBfdCBtYXAsIHZtX21hcF9lbnRyeV90IGVudHJ5KQogewogCXVtYV96ZnJlZShtYXAtPnN5 c3RlbV9tYXAgPyBrbWFwZW50em9uZSA6IG1hcGVudHpvbmUsIGVudHJ5KTsKSW5kZXg6IHZtX21t YXAuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSB2bV9tbWFwLmMJKHJldmlzaW9uIDIxMjQ3OSkKKysrIHZtX21t YXAuYwkod29ya2luZyBjb3B5KQpAQCAtMTIzLDYgKzEyMyw4IEBACiBzdGF0aWMgaW50IHZtX21t YXBfc2htKHN0cnVjdCB0aHJlYWQgKiwgdm1fc2l6ZV90LCB2bV9wcm90X3QsIHZtX3Byb3RfdCAq LAogICAgIGludCAqLCBzdHJ1Y3Qgc2htZmQgKiwgdm1fb29mZnNldF90LCB2bV9vYmplY3RfdCAq KTsKIAordm9pZCB2bV9tYXBfZW50cnlfZGlzcG9zZSh2bV9tYXBfdCBtYXAsIHZtX21hcF9lbnRy eV90IGVudHJ5KTsKKwogLyoKICAqIE1QU0FGRQogICovCkBAIC01NTAsNiArNTUyLDggQEAKICNp ZmRlZiBIV1BNQ19IT09LUwogCXN0cnVjdCBwbWNrZXJuX21hcF9vdXQgcGttOwogCXZtX21hcF9l bnRyeV90IGVudHJ5OworCXZtX21hcF9lbnRyeV90IGZyZWVfZW50cnk7CisJdm1fb2JqZWN0X3Qg b2JqZWN0OwogI2VuZGlmCiAJdm1fb2Zmc2V0X3QgYWRkcjsKIAl2bV9zaXplX3Qgc2l6ZSwgcGFn ZW9mZjsKQEAgLTU5NiwxMSArNjAwLDI1IEBACiAJdm1fbWFwX2RlbGV0ZShtYXAsIGFkZHIsIGFk ZHIgKyBzaXplKTsKIAogI2lmZGVmIEhXUE1DX0hPT0tTCisJZnJlZV9lbnRyeSA9IG1hcC0+ZGVm ZXJyZWRfZnJlZWxpc3Q7CisJbWFwLT5kZWZlcnJlZF9mcmVlbGlzdCA9IE5VTEw7CiAJLyogZG93 bmdyYWRlIHRoZSBsb2NrIHRvIHByZXZlbnQgYSBMT1Igd2l0aCB0aGUgcG1jLXN4IGxvY2sgKi8K IAl2bV9tYXBfbG9ja19kb3duZ3JhZGUobWFwKTsKIAlpZiAocGttLnBtX2FkZHJlc3MgIT0gKHVp bnRwdHJfdCkgTlVMTCkKIAkJUE1DX0NBTExfSE9PSyh0ZCwgUE1DX0ZOX01VTk1BUCwgKHZvaWQg KikgJnBrbSk7CiAJdm1fbWFwX3VubG9ja19yZWFkKG1hcCk7CisKKwl3aGlsZSAoZnJlZV9lbnRy eSAhPSBOVUxMKSB7CisJCWVudHJ5ID0gZnJlZV9lbnRyeTsKKwkJZnJlZV9lbnRyeSA9IGZyZWVf ZW50cnktPm5leHQ7CisKKwkJaWYgKChlbnRyeS0+ZWZsYWdzICYgTUFQX0VOVFJZX0lTX1NVQl9N QVApID09IDApIHsKKwkJCW9iamVjdCA9IGVudHJ5LT5vYmplY3Qudm1fb2JqZWN0OworCQkJdm1f b2JqZWN0X2RlYWxsb2NhdGUob2JqZWN0KTsKKwkJfQorCisJCXZtX21hcF9lbnRyeV9kaXNwb3Nl KG1hcCwgZW50cnkpOworCX0KICNlbHNlCiAJdm1fbWFwX3VubG9jayhtYXApOwogI2VuZGlmCg== --00c09f7f9dcbc833680490148bc8-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 01:21:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3830106566C for ; Mon, 13 Sep 2010 01:21:25 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by mx1.freebsd.org (Postfix) with ESMTP id CDBC18FC0A for ; Mon, 13 Sep 2010 01:21:25 +0000 (UTC) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by fallback-in1.mxes.net (Postfix) with ESMTP id 8DA112FD7B2 for ; Sun, 12 Sep 2010 21:05:55 -0400 (EDT) Received: from [10.0.0.171] (unknown [64.9.234.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D1D19509DC for ; Sun, 12 Sep 2010 21:05:53 -0400 (EDT) Message-ID: <4C8D78E3.3080404@gmail.com> Date: Sun, 12 Sep 2010 18:05:39 -0700 From: David Ehrmann User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: NFS lockups with VMware esxi client X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 01:21:26 -0000 I have NFS sharing a ZFS pool that VMware esxi stores files on. When put under stress (an OS installation, but not Linux compilation), the NFS server locks, spiking to 100% CPU usage. Not even kill -KILL can stop the process, so rebooting is required. PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 885 root 4 44 0 5804K 988K CPU2 0 239:39 100.00% nfsd Other people have run into this problem, but I never found a solution. I'm running 8.1-PRERELEASE on amd64, but I think others have seen the problem on 8.1-RELEASE. zpool status reports that the pool is healthy, so that's not it. My only two ideas are hosting on something other than ZFS and trying to reproduce it with a lot of big, random NFS requests. Any other ideas? From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 03:09:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8A00106566B for ; Mon, 13 Sep 2010 03:09:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id A44318FC0A for ; Mon, 13 Sep 2010 03:09:45 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEADIyjUyDaFvO/2dsb2JhbACDGZ8frxeQcoEigyp0BIon X-IronPort-AV: E=Sophos;i="4.56,357,1280721600"; d="scan'208";a="93634519" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 12 Sep 2010 23:09:44 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id B0576B3F26; Sun, 12 Sep 2010 23:09:44 -0400 (EDT) Date: Sun, 12 Sep 2010 23:09:44 -0400 (EDT) From: Rick Macklem To: David Ehrmann Message-ID: <1431942489.798180.1284347384700.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4C8D78E3.3080404@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: freebsd-current@freebsd.org Subject: Re: NFS lockups with VMware esxi client X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 03:09:46 -0000 > I have NFS sharing a ZFS pool that VMware esxi stores files on. When > put under stress (an OS installation, but not Linux compilation), the > NFS server locks, spiking to 100% CPU usage. Not even kill -KILL can > stop the process, so rebooting is required. > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 885 root 4 44 0 5804K 988K CPU2 0 239:39 100.00% nfsd > > Other people have run into this problem, but I never found a solution. > I'm running 8.1-PRERELEASE on amd64, but I think others have seen the > problem on 8.1-RELEASE. > > zpool status reports that the pool is healthy, so that's not it. My > only two ideas are hosting on something other than ZFS and trying to > reproduce it with a lot of big, random NFS requests. Any other ideas? > I believe it is patched in head/current. A compatible patch is at: http://people.freebsd.org/~rmacklem/freebsd8.1-patches/replay.patch rick From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 03:48:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE4031065670; Mon, 13 Sep 2010 03:48:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 686708FC15; Mon, 13 Sep 2010 03:48:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o8D3jb3W055086; Sun, 12 Sep 2010 21:45:37 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 12 Sep 2010 21:45:44 -0600 (MDT) Message-Id: <20100912.214544.934842008339142894.imp@bsdimp.com> To: arundel@freebsd.org From: "M. Warner Losh" In-Reply-To: <20100912170344.GA58722@freebsd.org> References: <20100912024049.GA32655@freebsd.org> <20100912162352.GA89643@alchemy.franken.de> <20100912170344.GA58722@freebsd.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, marius@alchemy.franken.de Subject: Re: {arch}/conf/DEFAULTS and uart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 03:48:12 -0000 In message: <20100912170344.GA58722@freebsd.org> Alexander Best writes: : also i noticed that after keywords like "device" there're two tabs, : whereas after the keyword "options" there's one space and a : tab. since i don't know, if this was done on purpose i didn't change : it. It is on purpose. Warner From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 07:40:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 936AB106566C for ; Mon, 13 Sep 2010 07:40:50 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5C2038FC13 for ; Mon, 13 Sep 2010 07:40:49 +0000 (UTC) Received: by bwz20 with SMTP id 20so411621bwz.13 for ; Mon, 13 Sep 2010 00:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=pnlYlhp+fXYQU3IML53UV1H0q4CZblt8HVjgvpe4TL8=; b=CVCepXCEeF9m/aNzTrEzJMCQE90Xpzf3IZVDbRhryfKACv+2HRvpP7YUFpsy4+4Jjv O6SOWYcLKH2mKhEV/rxu1Iz8bVu9aUpOXdpn+yE3iMTUI+VosBrRjgSTb1ka5vcQ2Yal mIQ/Tit5UJkR/yxHKYpIbl+suotjLhPVrk/eY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=oDpaJgYGF/4QZQDXWBK332ZYZlR80MVDpIbmTO4OOQzFNb9mSNrinieEiaPqhj0b6S LnudC4kdnMVUEDCp+aNWEqBr8a0iNFAiZ3dclI4E7cneqTLHdZEfUUKUKpJg07sY33fO roPiPP91uXCliise4gVohwKi5whJ+dv+bU80Y= Received: by 10.204.117.13 with SMTP id o13mr2864671bkq.48.1284363649136; Mon, 13 Sep 2010 00:40:49 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id f18sm4364471bkf.3.2010.09.13.00.40.47 (version=SSLv3 cipher=RC4-MD5); Mon, 13 Sep 2010 00:40:48 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8DD56F.8060100@FreeBSD.org> Date: Mon, 13 Sep 2010 10:40:31 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: FreeBSD-Current X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: NOTICE: New event timer management code got to HEAD. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 07:40:52 -0000 Hi. I've just committed my new one-shot oriented event timer management code into the HEAD: http://svn.freebsd.org/changeset/base/212541. Details are at referenced commit message. Contact me if you notice any related issues. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 08:11:42 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EEC61065673; Mon, 13 Sep 2010 08:11:42 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7795A8FC16; Mon, 13 Sep 2010 08:11:41 +0000 (UTC) Received: by wyb33 with SMTP id 33so6857251wyb.13 for ; Mon, 13 Sep 2010 01:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:cc:content-type; bh=ikfAkd8f66ExhRFeYpLcqQF47VJX7GRthsKptIN7Jow=; b=W/qmwTofid88MfgFnuwAXXFI/x4OuxAH7rDVg9uSbolO7T1muHHY6JNmn/93lEgBCb 8GFVj7SowFUBfYNSaDyk5NGMyGHmOERyojZ9iBSLFkT9IaewCYXzBbihGKgOpGl4i8ig gaJwhi7APfq7xaH0q106qxyzVUOXyEkqAWzrc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=tajP+ZTtZ+mUnAU/hsyKGV+4Hkh8BDighVDZP+WrCXGJ7lc0ojcti/bmEB08iOqUSh 97E03jq4Dy4qbVyK1YPaKZ2UdLcTXTr8K4KPokhd+KZdLxovkO+fR7tF+MQNw1+sdF6y aijIyMDqeJpAHCcywB0p9zg5djma6yBSUuXZM= MIME-Version: 1.0 Received: by 10.216.48.146 with SMTP id v18mr4077101web.56.1284365500575; Mon, 13 Sep 2010 01:11:40 -0700 (PDT) Received: by 10.216.6.79 with HTTP; Mon, 13 Sep 2010 01:11:40 -0700 (PDT) Date: Mon, 13 Sep 2010 04:11:40 -0400 Message-ID: From: "b. f." To: mav@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@FreeBSD.org Subject: Re: NOTICE: New event timer management code got to HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 08:11:42 -0000 Alexander: Are the changes to sys/kern/sched_ule.c in your supplementary hack http://people.freebsd.org/~mav/tm6292_idle.patch still useful, or have they been superseded by the other changes in http://svn.freebsd.org/changeset/base/212541 ? Regards, b. From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 08:21:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7F00106564A for ; Mon, 13 Sep 2010 08:21:15 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2F4468FC1A for ; Mon, 13 Sep 2010 08:21:14 +0000 (UTC) Received: by bwz20 with SMTP id 20so433171bwz.13 for ; Mon, 13 Sep 2010 01:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=e35u9M7HcCZx0S9RCZwez4UxnYF2BLm9ZnkTk1rZNZM=; b=hHvGXvJ1FvKYPtJFhVCjksaVe/W89HWL7l6aEczh9TEC8w8PUXUEbyEyMhyjKRq+9O I8dhDHHI+NofV1+7ussr5aFW2ahK/8GearL8kRo4DLSlEMACmtaFajF+b5dSnKn0tvbI p3BNqlp9A7lAEFcaGj9kzc3iVIw6NZD1YWMio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=VJl0635KwaXZnOTicwlpqinJTgQhwPLWh3k32J66Og+B2e5+CjyHvQmgFfjAdzwdvF pOK2at+o7ZrYrdBYtkunP5lWUf9k4F/G8Gzcv5m/1dYhFZvmCRJ9ClEd5glf2vIZr/dz gri717wY+aAIBcd3iRvoR3wzLdyK4GDLtT4qo= Received: by 10.204.120.194 with SMTP id e2mr2869715bkr.200.1284366073983; Mon, 13 Sep 2010 01:21:13 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y19sm4389831bkw.6.2010.09.13.01.21.12 (version=SSLv3 cipher=RC4-MD5); Mon, 13 Sep 2010 01:21:12 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8DDEE7.4020109@FreeBSD.org> Date: Mon, 13 Sep 2010 11:20:55 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: bf1783@gmail.com References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: NOTICE: New event timer management code got to HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 08:21:15 -0000 b. f. wrote: > Alexander: > > Are the changes to sys/kern/sched_ule.c in your supplementary hack > > http://people.freebsd.org/~mav/tm6292_idle.patch > > still useful, or have they been superseded by the other changes in > > http://svn.freebsd.org/changeset/base/212541 ? One part that commenting lines should be superseded. Other that adds new is still should be effective. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 12:00:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5026B10656C3 for ; Mon, 13 Sep 2010 12:00:32 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B48D78FC1E for ; Mon, 13 Sep 2010 12:00:31 +0000 (UTC) Received: (qmail 49519 invoked from network); 13 Sep 2010 11:29:01 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Sep 2010 11:29:01 -0000 Message-ID: <4C8E0C1E.2020707@networx.ch> Date: Mon, 13 Sep 2010 13:33:50 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Sep 2010 12:40:42 +0000 Cc: Subject: TCP loopback socket fusing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 12:00:32 -0000 When a TCP connection via loopback back to localhost is made the whole send, segmentation and receive path (with larger packets though) is still executed. This has some considerable overhead. To short-circuit the send and receive sockets on localhost TCP connections I've made a proof-of-concept patch that directly places the data in the other side's socket buffer without doing any packetization and other protocol overhead (like UNIX domain sockets). The connections setup (SYN, SYN-ACK, ACK) and shutdown are still handled by normal TCP segments via loopback so that firewalling stills works. The actual payload data during the session won't be seen and the sequence numbers don't move other than for SYN and FIN. The sequence are remain valid though. Obviously tcpdump won't see any data transfers either if the connection has fused sockets. Preliminary testing (with WITNESS and INVARIANTS enabled) has shown stable operation and a rough doubling of the throughput on loopback connections. I've tested most socket teardown cases and it behaves fine. I'm not entirely sure I've got all possible path's but the way it is integrated should properly defuse the sockets in all situations. Testers and feedback wanted: http://people.freebsd.org/~andre/tcp_loopfuse-20100913.diff -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 12:45:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55F581065670 for ; Mon, 13 Sep 2010 12:45:15 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 136848FC16 for ; Mon, 13 Sep 2010 12:45:14 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id A56A73F592; Mon, 13 Sep 2010 12:45:13 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o8DCjDEZ047012; Mon, 13 Sep 2010 12:45:13 GMT (envelope-from phk@critter.freebsd.dk) To: Andre Oppermann From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 13 Sep 2010 13:33:50 +0200." <4C8E0C1E.2020707@networx.ch> Date: Mon, 13 Sep 2010 12:45:13 +0000 Message-ID: <47011.1284381913@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: TCP loopback socket fusing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 12:45:15 -0000 In message <4C8E0C1E.2020707@networx.ch>, Andre Oppermann writes: >To short-circuit the send and receive sockets on localhost TCP connections >I've made a proof-of-concept patch that directly places the data in the >other side's socket buffer without doing any packetization and other protocol >overhead [...] Can we keep the option (sysctl ?) of doing the full packet thing, it is a very convenient debugging tool... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 12:48:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 218B1106566B for ; Mon, 13 Sep 2010 12:48:52 +0000 (UTC) (envelope-from ganael.laplanche@martymac.org) Received: from data.galacsys.net (webmail.galacsys.net [217.24.81.215]) by mx1.freebsd.org (Postfix) with ESMTP id DC72F8FC13 for ; Mon, 13 Sep 2010 12:48:51 +0000 (UTC) Received: from martymac.org (webmail.galacsys.net [217.24.81.215]) by data.galacsys.net (Postfix) with ESMTP id E844E16BB15; Mon, 13 Sep 2010 14:29:55 +0200 (CEST) From: "Ganael LAPLANCHE" To: Tai-hwa Liang X-Openwebmail-Date: Mon, 13 Sep 2010 14:29:55 +0100 Message-Id: <20100913121924.M42393@martymac.org> In-Reply-To: <10091121072416.9831@www.mmlab.cse.yzu.edu.tw> References: <10091121072416.9831@www.mmlab.cse.yzu.edu.tw> X-Mailer: Open WebMail 2.01 20030425 X-OriginatingIP: 88.163.147.236 (ganael.laplanche@martymac.org) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Date: Mon, 13 Sep 2010 14:29:55 +0200 (CEST) X-Mailman-Approved-At: Mon, 13 Sep 2010 13:01:48 +0000 Cc: freebsd-current@freebsd.org Subject: Re: bonnie++ failed on locally mounted NFS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 12:48:52 -0000 On Sat, 11 Sep 2010 21:52:54 +0800 (CST), Tai-hwa Liang wrote Hi, > Delete files in sequential order...Bonnie: drastic I/O error (rmdir): > Directory not empty This is a known-bug related to NFS (not bonnie++) ; see : http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/57696 and http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/26142 To sum up : files are skipped if unlink()'ed or rename()'d while their parent directory is opened and being readdir()'ed. Best regards, Ganael LAPLANCHE ganael.laplanche@martymac.org http://www.martymac.org | http://contribs.martymac.org From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 12:54:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 280AB106566B for ; Mon, 13 Sep 2010 12:54:36 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 90A488FC24 for ; Mon, 13 Sep 2010 12:54:35 +0000 (UTC) Received: (qmail 50299 invoked from network); 13 Sep 2010 12:49:46 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Sep 2010 12:49:46 -0000 Message-ID: <4C8E1F0B.5090406@networx.ch> Date: Mon, 13 Sep 2010 14:54:35 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Poul-Henning Kamp References: <47011.1284381913@critter.freebsd.dk> In-Reply-To: <47011.1284381913@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Sep 2010 13:09:41 +0000 Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: TCP loopback socket fusing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 12:54:36 -0000 On 13.09.2010 14:45, Poul-Henning Kamp wrote: > In message<4C8E0C1E.2020707@networx.ch>, Andre Oppermann writes: > >> To short-circuit the send and receive sockets on localhost TCP connections >> I've made a proof-of-concept patch that directly places the data in the >> other side's socket buffer without doing any packetization and other protocol >> overhead [...] > > Can we keep the option (sysctl ?) of doing the full packet thing, it is > a very convenient debugging tool... Yes, an appropriate sysctl is already contained in the patch (w/o man page documentation yet). -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 19:53:42 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 539F5106566C for ; Mon, 13 Sep 2010 19:53:42 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A037C8FC13 for ; Mon, 13 Sep 2010 19:53:41 +0000 (UTC) Received: by bwz20 with SMTP id 20so230455bwz.13 for ; Mon, 13 Sep 2010 12:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=10wuYQUPpqrPjvDTbPnoMY4T3ASG2BLNxYt34K3tvaI=; b=QdqRwwGB3D8Qgl8iVJRxtnxBTnAyKOWID0MbSdN32clU5wwDT56rfwUw3KJqydJ4FH 3ecE+w6ZFManxmJUJ6sCVU7pXnHBw54gk3j3jahXKzIzvMaF/HPVJYGmjh3ZZX+mcnAP eRkrhGY+9vPZH1Zb+ezIsAhDxmUcLB06OoOv4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xSDk4pHkr/ClRlwDdV+7rn757VKZXNT6h2HLCWcwzF2CclebXp4fG6j7p8Fgt9uEYx +u9VXaIUVbtkkN0jT2VFtB8rgvx2awMKNaq/Iiv8HH21KqLN+SgG0aT5Jc0aaYQoAMPh fG0F8YLgU0Quj4hqgb0XL1JUCL8RwudQG746c= MIME-Version: 1.0 Received: by 10.204.118.65 with SMTP id u1mr3543545bkq.169.1284407620441; Mon, 13 Sep 2010 12:53:40 -0700 (PDT) Received: by 10.204.80.167 with HTTP; Mon, 13 Sep 2010 12:53:40 -0700 (PDT) In-Reply-To: <4C8ACE52.8060000@FreeBSD.org> References: <4C8A5CA0.1050700@feral.com> <4C8A7ACB.9070408@FreeBSD.org> <20100910234830.87641e07.ray@ddteam.net> <4C8ACE52.8060000@FreeBSD.org> Date: Mon, 13 Sep 2010 21:53:40 +0200 Message-ID: From: David DEMELIER To: Doug Barton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Aleksandr Rybalko , Julien Laffaye , Matthew Jacob , freebsd-current@freebsd.org Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 19:53:42 -0000 2010/9/11 Doug Barton : > On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote: >> >> Hi, >> >> another argument about hostapd :) if have access point we must have >> way to assign IP for AP clients. > > To start with, your assumption is wrong. DHCPd is not *actually* a > requirement, although I admit that practically it is. > >> Last spring I made firmware based on FreeBSD for router with only 4MB >> NOR flash (D-Link DIR-320). > > In this category (micro-miniaturization) you're already in the "significa= nt > customization needed" area, which means that general arguments about "the > base" don't apply. > >> Since this device is router I must be >> able to serve DHCP. And current implementation of dhcpclient, that we >> have, is same isc-dhcp, and I replace system dhcpclient with ports >> one+dhcpd but with small patch that put basic dhcp utils onto >> libdhcp.so. > > Your argument is creative and well thought out, but I personally don't fi= nd > it persuasive. Counter arguments that come immediately to mind are: > 1. The DHCP server is not going to benefit any but a small minority of > FreeBSD users. > 2. The software is already available in the ports tree, and adding a > port/package of it really is not an overwhelming burden. > > More generally, the main reason I want to keep more stuff out of the base= , > and remove some of the stuff that's in there now, is that it makes > maintenance difficult across FreeBSD branches. We have a general policy t= hat > if we have a major version N of something in a release branch that we don= 't > upgrade that major version without a really good reason to avoid POLA > surprises for our users. Once again using BIND as an example, this has le= d > to a really old and past-EOL version of BIND in FreeBSD 6 which I've only > gotten away with because anyone doing serious DNS work nowadays has to > upgrade to at least 9.6 anyway. But it's an ugly situation, and I don't w= ant > to repeat it. > I agree but like Aleksandr said, almost 70% of dhcp code is already in base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea to keep some parts in the ports tree and move out from the base. Perl is a great example, I don't really understand why it's in the base, then the port need to rewrite the links into the base hierarchy and I think this is bad. > The problems get worse and/or more complex with the more 3rd party stuff = you > start including in the base. In part because of the product lifecycle iss= ues > that are similar to BIND's, but also due to the possibility of licensing > issues (such as with gcc and/or other GPL software) and other more esoter= ic > factors. > > Even with home-grown stuff like our pkg_* tools we have problems because > when we want to introduce new features (or deprecate old ones) there is > currently a _minimum_ 3-year cycle we have to follow in order to make sur= e > that the new feature is/is not available on all supported versions of > FreeBSD. That's the main motivation behind my continuing to repeat the > suggestion to move those tools specifically into the ports tree so that w= e > can better support innovation in our ports/packages system. > > In my view what we've needed to do for a long time now is to seriously st= rip > down the notion of what "the base" should be to those items that are need= ed > to work together for a specific API/ABI/AKI release, and move everything > else into the ports tree. (Obviously there would be some exemptions made = for > really basic/vital stuff like ls, etc.) We can do this in a way that find= s a > middle ground between the linux model where literally everything is a > package and the traditional BSD model of providing a "complete system," > which is hardly ever true since I've never been involved with any FreeBSD > system administration where there were absolutely no ports/packages > installed at all. > > Such a system could also be streamlined by creating a ports virtual categ= ory > (something like "system") the packages for which could be included in the > install media as long as we are judicious about what goes in there. Thing= s > like wpa_supplicant, dhclient, DNS tools, etc. could all be in that > category, and all we'd have to do to make that work is to very slightly > expand the list of questions that sysinstall already asks. > > So this is a much longer version of my previous response which hopefully > gives you more background about why it's a bad idea to add *any* more 3rd > party stuff to the base. > > > Doug > > -- > > =C2=A0 =C2=A0 =C2=A0 =C2=A0... and that's just a little bit of history re= peating. > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0-- Propellerheads > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Improve the effectiveness of your Internet pre= sence with > =C2=A0 =C2=A0 =C2=A0 =C2=A0a domain name makeover! =C2=A0 =C2=A0http://Su= persetSolutions.com/ > > --=20 Demelier David From owner-freebsd-current@FreeBSD.ORG Mon Sep 13 20:55:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3D3D106564A for ; Mon, 13 Sep 2010 20:55:39 +0000 (UTC) (envelope-from gordon.tetlow@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 4EE778FC17 for ; Mon, 13 Sep 2010 20:55:38 +0000 (UTC) Received: by gxk8 with SMTP id 8so1198242gxk.13 for ; Mon, 13 Sep 2010 13:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=lV5qbSh0j2oPAWMcj/uCPW+DD+J32mqiNdwivHxBL1U=; b=l1TvaPA4TSZAomnGsbHmODJ/YARRvo2j7wNP1Qq0JmnNyvucVrZaTyYWy/5mvTNlFP Mj7Hu/bZ/JaikDb4cXmMMLNX+s/ox5hU/6OAL4ACLh5L4f1ImJ0V1CcxYfImkIIKTbep N94vyh8exPc+JP/OjJF8N/rIWAiNdv/NrfVVo= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Epz30d9rxRKFonOPdJVWsD1b4CTZdVbrT1IY8ou1dmOOOkOcf4QENKfpr0sAkk5gSW Uc326IPFDOEEvnAWjfpkTIWf0e3721CSe4ObjDztm69ITFO7gptITmYxuMBFhCb5JqyQ k8zdfaDN1ow+wOqVf7vAGsyzd35zXKoMVfsIo= MIME-Version: 1.0 Received: by 10.150.147.5 with SMTP id u5mr775234ybd.438.1284411338319; Mon, 13 Sep 2010 13:55:38 -0700 (PDT) Sender: gordon.tetlow@gmail.com Received: by 10.231.156.78 with HTTP; Mon, 13 Sep 2010 13:55:38 -0700 (PDT) In-Reply-To: References: <4C8A5CA0.1050700@feral.com> <4C8A7ACB.9070408@FreeBSD.org> <20100910234830.87641e07.ray@ddteam.net> <4C8ACE52.8060000@FreeBSD.org> Date: Mon, 13 Sep 2010 13:55:38 -0700 X-Google-Sender-Auth: wNUIUY70cBuM27ZniQvboE3df0s Message-ID: From: Gordon Tetlow To: David DEMELIER Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Julien Laffaye , Aleksandr Rybalko , Doug Barton , Matthew Jacob , freebsd-current@freebsd.org Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 20:55:39 -0000 On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER wrote: > Perl is a great example, I don't really understand why it's in the > base, then the port need to rewrite the links into the base hierarchy > and I think this is bad. Perl is not in the base system anymore. It's in the ports system. Gordon From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 00:59:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id CEC4F1065675; Tue, 14 Sep 2010 00:59:46 +0000 (UTC) Date: Tue, 14 Sep 2010 00:59:46 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20100914005946.GA7417@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: regarding pciids X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 00:59:46 -0000 hi there, any thoughts on using http://pciids.sourceforge.net/ for pciids instead of the Hart and Boemler lists. the SF site seems to be updated more regularly and would get rid of the need to decide for each entry, whether to take the Hart or Boemler one. right now tools/tools/pciid/mk_pci_vendors.pl favours long descriptions over short ones which means that something like: 'Intel(R) ICH9 Family SMBus Controller (8086)' will get discarded in favor of 'Intel(R) ICH9 Family SMBus Controller working fine with http://download.cnet.com/Chipset-Driver-Inte (8086)' also linux seems to be using http://pciids.sourceforge.net/ so it should have a lot of volunteers submitting new entries. and most important of all: "The contents of the database and the generated files can be distributed under the terms of either the GNU General Public License (version 2 or later) or of the 3-clause BSD License." cheers. alex -- a13x From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 01:10:17 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A73641065670 for ; Tue, 14 Sep 2010 01:10:17 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 63E6C8FC1B for ; Tue, 14 Sep 2010 01:10:17 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OvK2I-000696-BH for freebsd-current@freebsd.org; Tue, 14 Sep 2010 03:10:14 +0200 Received: from k.saper.info ([91.121.151.35]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2010 03:10:14 +0200 Received: from saper by k.saper.info with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 14 Sep 2010 03:10:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Marcin Cieslak Date: Tue, 14 Sep 2010 01:10:01 +0000 (UTC) Organization: http://saper.info Lines: 36 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: k.saper.info User-Agent: slrn/0.9.9p1 (FreeBSD) X-Mailman-Approved-At: Tue, 14 Sep 2010 02:02:11 +0000 Subject: tun(4) in -CURRENT: No buffer space available - race condition patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 01:10:17 -0000 Output queue of tun(4) gets full after some time when sending lots of data. I have been observing this on -CURRENT at least since March this year. Looks like it's a race condition (same in tun(4) and tap(4)), the following patch seems to address the issue: Index: if_tap.c =================================================================== --- if_tap.c (revision 212217) +++ if_tap.c (working copy) @@ -881,8 +881,7 @@ mtx_lock(&tp->tap_mtx); tp->tap_flags |= TAP_RWAIT; - mtx_unlock(&tp->tap_mtx); - error = tsleep(tp,PCATCH|(PZERO+1),"taprd",0); + error = mtx_sleep(tp, &tp->tap_mtx, PDROP|PCATCH|(PZERO+1), "taprd", 0); if (error) return (error); } Index: if_tun.c =================================================================== --- if_tun.c (revision 212217) +++ if_tun.c (working copy) @@ -836,8 +836,7 @@ } mtx_lock(&tp->tun_mtx); tp->tun_flags |= TUN_RWAIT; - mtx_unlock(&tp->tun_mtx); - if ((error = tsleep(tp, PCATCH | (PZERO + 1), + if ((error = mtx_sleep(tp, &tp->tun_mtx, PDROP | PCATCH | (PZERO + 1), "tunread", 0)) != 0) { splx(s); return (error); --Marcin From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 05:12:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86BFE106566C; Tue, 14 Sep 2010 05:12:16 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D5E9F8FC0A; Tue, 14 Sep 2010 05:12:15 +0000 (UTC) Received: by bwz20 with SMTP id 20so165517bwz.13 for ; Mon, 13 Sep 2010 22:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ZyDV0LIDU86o0gDGDoPif6EQP/0oWHdMIhbw/Vu14II=; b=gSaEepCj1RLiX/8owDRA5GvBSX/zE4Xu5PaXhyoRXrGfEytiZlgHlL0stTX5acUXw7 zpeVmcHfMTDK497Zsqb0yWQnaEF3MgfUycdqItBqKS5J77BvHAA5CGCML0JzCmRQIreN P9SGA87QlMKxWUj/0efK/Ad5HTtn+wrhp7PuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Cc/SmpZc5yT4+mKMGYZFW2fipltiAvJZHTe/UOz/aF/ZOQyByK9NICkP/UqK3KzY6d NqHiyuuuRm1CHUMNbW6WemvsPkbmWgUaX704nfVZH9mEJlqbnMqS/Qdgtp+sAoCQ2M4F GvwnqPYCMRuuiEVN5rOCB87mO+5LgfyJu9wvA= MIME-Version: 1.0 Received: by 10.204.127.65 with SMTP id f1mr4014789bks.55.1284441088816; Mon, 13 Sep 2010 22:11:28 -0700 (PDT) Received: by 10.204.80.167 with HTTP; Mon, 13 Sep 2010 22:11:28 -0700 (PDT) In-Reply-To: References: <4C8A5CA0.1050700@feral.com> <4C8A7ACB.9070408@FreeBSD.org> <20100910234830.87641e07.ray@ddteam.net> <4C8ACE52.8060000@FreeBSD.org> Date: Tue, 14 Sep 2010 07:11:28 +0200 Message-ID: From: David DEMELIER To: Gordon Tetlow Content-Type: text/plain; charset=UTF-8 Cc: Julien Laffaye , Aleksandr Rybalko , Doug Barton , Matthew Jacob , freebsd-current@freebsd.org Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 05:12:16 -0000 2010/9/13 Gordon Tetlow : > On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER > wrote: >> >> Perl is a great example, I don't really understand why it's in the >> base, then the port need to rewrite the links into the base hierarchy >> and I think this is bad. > > Perl is not in the base system anymore. It's in the ports system. > Gordon Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect ! -- Demelier David From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 08:14:45 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 546A6106566C for ; Tue, 14 Sep 2010 08:14:45 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id E1F2C8FC18 for ; Tue, 14 Sep 2010 08:14:44 +0000 (UTC) Received: by wyb33 with SMTP id 33so8385478wyb.13 for ; Tue, 14 Sep 2010 01:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:cc:content-type; bh=/33fgu1RpcgzVXw0/UUnLtico75gUvdmWhVIjRpqUhw=; b=ASd+MA2VE9eJuzlBvwBVWBuY7uzL9yY/2otechmog8GHbCtc+0jxC1OAyOMlcI34Gp Y4wcsNV63mJH7rGNQ1uG7M4YzLMMFSplkqsYbyshEpiSZ5t9fKEA3iN330cZPAwLcou8 qf7xiOsezsVRirR3HXZ4rjjAeUlBLZK0CAJdM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=ikWRxkYlCKXoqjaj4Nw/4gE/dUu3OJiTyMAzD8aj1/EOl6lWOq5+P/WVY5mrhQLE6C ZV6JpMP11USeJTR4RI5p27dPWxtLQNjK5PKQZ1Y7ns1azNMRu413aD/XMxQbRrS91mi8 mxsyyk1pRW0GYZQl5sy3aoASBnssT0uQ4szS8= MIME-Version: 1.0 Received: by 10.216.145.99 with SMTP id o77mr5240817wej.113.1284452082705; Tue, 14 Sep 2010 01:14:42 -0700 (PDT) Received: by 10.216.6.79 with HTTP; Tue, 14 Sep 2010 01:14:42 -0700 (PDT) Date: Tue, 14 Sep 2010 08:14:42 +0000 Message-ID: From: "b. f." To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: bzeeb+freebsd+lor@zabbadoz.net Subject: An LOR recently observed on r212598 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 08:14:45 -0000 An LOR, which resembles another reported in: http://lists.freebsd.org/pipermail/freebsd-current/2010-August/018986.html but none that I noticed at: http://sources.zabbadoz.net/freebsd/lor.html lock order reversal: 1st 0xffffff0001696098 ufs (ufs) @ /mnt/disk2/usr/src/sys/kern/vfs_lookup.c:501 2nd 0xffffff8026d985b8 bufwait (bufwait) @ /mnt/disk2/usr/src/sys/ufs/ffs/ffs_softdep.c:11309 3rd 0xffffff0001705638 ufs (ufs) @ /mnt/disk2/usr/src/sys/kern/vfs_subr.c:2111 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff801cae5a = db_trace_self_wrapper+0x2a _witness_debugger() at 0xffffffff802ba265 = _witness_debugger+0x65 witness_checkorder() at 0xffffffff802bb513 = witness_checkorder+0x833 __lockmgr_args() at 0xffffffff8025efad = __lockmgr_args+0xd4d ffs_lock() at 0xffffffff8041a9af = ffs_lock+0x8f VOP_LOCK1_APV() at 0xffffffff804ab13b = VOP_LOCK1_APV+0x9b _vn_lock() at 0xffffffff80313c67 = _vn_lock+0x57 vget() at 0xffffffff8030775b = vget+0x7b vfs_hash_get() at 0xffffffff802fb065 = vfs_hash_get+0xd5 ffs_vgetf() at 0xffffffff80415ca8 = ffs_vgetf+0x48 softdep_sync_metadata() at 0xffffffff8041309e = softdep_sync_metadata+0x5de ffs_syncvnode() at 0xffffffff8041a65a = ffs_syncvnode+0x22a ffs_truncate() at 0xffffffff803fac38 = ffs_truncate+0x408 ufs_direnter() at 0xffffffff8042284d = ufs_direnter+0x6fd ufs_makeinode() at 0xffffffff80427a74 = ufs_makeinode+0x254 VOP_CREATE_APV() at 0xffffffff804abaad = VOP_CREATE_APV+0x8d vn_open_cred() at 0xffffffff80313642 = vn_open_cred+0x452 kern_openat() at 0xffffffff803126f1 = kern_openat+0x181 syscallenter() at 0xffffffff802b274a = syscallenter+0x1aa syscall() at 0xffffffff8046dfac = syscall+0x4c Xfast_syscall() at 0xffffffff8045a332 = Xfast_syscall+0xe2 --- syscall (5, FreeBSD ELF64, open), rip = 0x800726ddc, rsp = 0x7fffffffeac8, rbp = 0 --- b. From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 09:33:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53AA6106566C; Tue, 14 Sep 2010 09:33:23 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 72DA38FC12; Tue, 14 Sep 2010 09:33:21 +0000 (UTC) Received: from [10.20.1.1] (unknown [10.2.27.254]) by work.netasq.com (Postfix) with ESMTPSA id 98AA2740015; Tue, 14 Sep 2010 11:17:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Fabien Thomas In-Reply-To: <4C8E0C1E.2020707@networx.ch> Date: Tue, 14 Sep 2010 11:18:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C8E0C1E.2020707@networx.ch> To: Andre Oppermann X-Mailer: Apple Mail (2.1081) Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: TCP loopback socket fusing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 09:33:23 -0000 Great, This will maybe kill the long time debate about "my loopback is slow vs = linux" To have the best of both world what about a socket option to = enable/disable fusing: can be useful when you need to see some connection "packetized". Fabien On 13 sept. 2010, at 13:33, Andre Oppermann wrote: > When a TCP connection via loopback back to localhost is made the whole > send, segmentation and receive path (with larger packets though) is = still > executed. This has some considerable overhead. >=20 > To short-circuit the send and receive sockets on localhost TCP = connections > I've made a proof-of-concept patch that directly places the data in = the > other side's socket buffer without doing any packetization and other = protocol > overhead (like UNIX domain sockets). The connections setup (SYN, = SYN-ACK, > ACK) and shutdown are still handled by normal TCP segments via = loopback so > that firewalling stills works. The actual payload data during the = session > won't be seen and the sequence numbers don't move other than for SYN = and FIN. > The sequence are remain valid though. Obviously tcpdump won't see any = data > transfers either if the connection has fused sockets. >=20 > Preliminary testing (with WITNESS and INVARIANTS enabled) has shown = stable > operation and a rough doubling of the throughput on loopback = connections. > I've tested most socket teardown cases and it behaves fine. I'm not = entirely > sure I've got all possible path's but the way it is integrated should = properly > defuse the sockets in all situations. >=20 > Testers and feedback wanted: >=20 > http://people.freebsd.org/~andre/tcp_loopfuse-20100913.diff >=20 > --=20 > Andre >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 10:12:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3840106566B for ; Tue, 14 Sep 2010 10:12:12 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 67B098FC19 for ; Tue, 14 Sep 2010 10:12:12 +0000 (UTC) Received: from [41.154.88.19] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1OvSUj-0005aB-KJ; Tue, 14 Sep 2010 12:12:10 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OvSUd-0000mU-0l; Tue, 14 Sep 2010 12:12:03 +0200 Message-Id: To: Fabien Thomas From: Ian FREISLICH In-Reply-To: References: <4C8E0C1E.2020707@networx.ch> X-Attribution: BOFH Date: Tue, 14 Sep 2010 12:12:03 +0200 Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann Subject: Re: TCP loopback socket fusing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 10:12:12 -0000 Fabien Thomas wrote: > Great, > > This will maybe kill the long time debate about "my loopback is slow vs > linux" > To have the best of both world what about a socket option to > enable/disable fusing: > can be useful when you need to see some connection "packetized". To chime in, I had a "slow" loopback issue earlier this week. It turned out the problem was caused by delayed ack on the loopback where the client didn't need to transmit any data to the server. It delayed each packet from the server by 100ms. After patching the server to: setsockopt(desc->accept_fd, IPPROTO_TCP, TCP_NODELAY, &x, sizeof(x)); It's now faster than on linux. Perhaps this is one of the causes of "my loopback is slow vs linux". FWIW, I couldn't find a way to turn off dealyed_ack on just loopback interface. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 10:57:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE173106566B for ; Tue, 14 Sep 2010 10:57:20 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from crivens.kernel32.de (crivens.asm68k.org [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id 740398FC13 for ; Tue, 14 Sep 2010 10:57:19 +0000 (UTC) Received: from www.terrorteam.de (localhost [127.0.0.1]) by crivens.kernel32.de (Postfix) with ESMTP id 18AD7B03B9; Tue, 14 Sep 2010 12:57:18 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Tue, 14 Sep 2010 11:57:17 +0100 From: Marian Hettwer To: David DEMELIER In-Reply-To: References: <4C8A5CA0.1050700@feral.com> <4C8A7ACB.9070408@FreeBSD.org> <20100910234830.87641e07.ray@ddteam.net> <4C8ACE52.8060000@FreeBSD.org> Message-ID: <66df85d07cbdb142e53ea8dd5020b7bf@localhost> X-Sender: mh@kernel32.de User-Agent: RoundCube Webmail/0.1-rc2 Cc: Aleksandr Rybalko , Doug Barton , Gordon Tetlow , freebsd-current@freebsd.org, Matthew, Julien Laffaye , Jacob Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 10:57:20 -0000 On Tue, 14 Sep 2010 07:11:28 +0200, David DEMELIER wrote: > 2010/9/13 Gordon Tetlow : >> On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER >> wrote: >>> >>> Perl is a great example, I don't really understand why it's in the >>> base, then the port need to rewrite the links into the base hierarchy >>> and I think this is bad. >> >> Perl is not in the base system anymore. It's in the ports system. >> Gordon > > Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect ! Uh. Perl was moved to ports somewhere in 2002 or 2003, IIRC. Nothing to do with following -current ;-) ./Marian From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 11:00:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C41081065673 for ; Tue, 14 Sep 2010 11:00:52 +0000 (UTC) (envelope-from mdounin@mdounin.ru) Received: from mdounin.cust.ramtel.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mx1.freebsd.org (Postfix) with ESMTP id 8123E8FC17 for ; Tue, 14 Sep 2010 11:00:52 +0000 (UTC) Received: from mdounin.ru (mdounin.cust.ramtel.ru [81.19.69.81]) by mdounin.cust.ramtel.ru (Postfix) with ESMTP id C519217015; Tue, 14 Sep 2010 14:35:49 +0400 (MSD) Date: Tue, 14 Sep 2010 14:35:49 +0400 From: Maxim Dounin To: Ian FREISLICH Message-ID: <20100914103549.GI99657@mdounin.ru> References: <4C8E0C1E.2020707@networx.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org, Andre Oppermann , freebsd-current@freebsd.org, Fabien Thomas Subject: Re: TCP loopback socket fusing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 11:00:52 -0000 Hello! On Tue, Sep 14, 2010 at 12:12:03PM +0200, Ian FREISLICH wrote: > Fabien Thomas wrote: > > Great, > > > > This will maybe kill the long time debate about "my loopback is slow vs > > linux" > > To have the best of both world what about a socket option to > > enable/disable fusing: > > can be useful when you need to see some connection "packetized". > > To chime in, I had a "slow" loopback issue earlier this week. It > turned out the problem was caused by delayed ack on the loopback > where the client didn't need to transmit any data to the server. > It delayed each packet from the server by 100ms. After patching > the server to: > > setsockopt(desc->accept_fd, IPPROTO_TCP, TCP_NODELAY, &x, sizeof(x)); > > It's now faster than on linux. > > Perhaps this is one of the causes of "my loopback is slow vs linux". > > FWIW, I couldn't find a way to turn off dealyed_ack on just loopback > interface. AFAIK in linux delayed ack behaves a bit more gently and doesn't delay first ack(s) in a connection. As a result linux hides some classic delayed ack vs. Nagle problems. Something similar probably should be adapted. Maxim Dounin From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 09:35:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B75A61065679; Tue, 14 Sep 2010 09:35:54 +0000 (UTC) (envelope-from adrian.chadd@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 763A08FC14; Tue, 14 Sep 2010 09:35:54 +0000 (UTC) Received: by iwn34 with SMTP id 34so6779221iwn.13 for ; Tue, 14 Sep 2010 02:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=u0kR7tyWZTN0WlcOVB4A2262sYK3Tr6H4+Rowu48GaU=; b=IkxnNIWta7zfg2Exf1AC3xPRjqT8pAzAvvnJzznF/WRlBqmliAsIgA7OAb8vXRIy4J zt2jVeKmu1pxux7lA7tHrgSA//i4VUMHQAUyLJzhpPJ6KSsoKzsDK9eJitkOn+RzXgU5 RkDW88p8vzoPvKwf3mWddsQ9Bt1cMY5P/euhc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=NDD2pdcnr5irtr479Fv3/HcI7pHRnT/aLlLjpMeathBSEaeWpNRMnd/ZON6JT1gtof UCtME6hiisXS7iLerzq/C6788FicPR7Oh/EB1MPvzKzA2198N35EYLo7wGIIKRyXokfK DU59BNfWiQg07GUYY39TRB4ixTzouF0z2rR+w= MIME-Version: 1.0 Received: by 10.231.190.9 with SMTP id dg9mr7721593ibb.54.1284456953453; Tue, 14 Sep 2010 02:35:53 -0700 (PDT) Received: by 10.231.156.206 with HTTP; Tue, 14 Sep 2010 02:35:53 -0700 (PDT) Date: Tue, 14 Sep 2010 17:35:53 +0800 Message-ID: From: Adrian Chadd To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 14 Sep 2010 11:17:14 +0000 Cc: FreeBSD Net Subject: AR9132 CPU and AR9100 wireless support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 09:35:54 -0000 Hi everyone, I've just pushed the initial support for the AR9100 wireless MAC into my git repository. This is for the WMAC on the AR9132 SoC. I've tested it in 11bg hostap mode on an AP83 derived box - the TP-Link TL-WR1043ND. The source tree has support for the CPU, ethernet (but not the switch PHY; it's enough to get data across it!); flash and the AR9100 WMAC. I've only tested "open" hostap mode on 11bg on a fixed channel. The GIT repo is at: http://www.gitorious.org/~adrianchadd/freebsd/adrianchadd-freebsd ; it's the "work/atheros" branch. You'll need to open the unit up, solder on some pins to get to the serial port and acquire a TTL -> RS232 level converter. There's pictures and howto on the OpenWRT wiki: http://wiki.openwrt.org/toh/tp-link/tl-wr1043nd Ciao! Adrian From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 11:48:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10EF91065674 for ; Tue, 14 Sep 2010 11:48:57 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id E66CB8FC17 for ; Tue, 14 Sep 2010 11:48:56 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1OvThB-0000JI-Bv for freebsd-current@freebsd.org; Tue, 14 Sep 2010 04:29:05 -0700 Message-ID: <29707595.post@talk.nabble.com> Date: Tue, 14 Sep 2010 04:29:05 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org In-Reply-To: <20100914005946.GA7417@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <20100914005946.GA7417@freebsd.org> Subject: Re: regarding pciids X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 11:48:57 -0000 Alexander Best-4 wrote: > > any thoughts on using http://pciids.sourceforge.net/ for pciids instead of > the > Hart and Boemler lists. the SF site seems to be updated more regularly and > would get rid of the need to decide for each entry, whether to take the > Hart or > Boemler one. > > right now tools/tools/pciid/mk_pci_vendors.pl favours long descriptions > over > short ones which means that something like: > > 'Intel(R) ICH9 Family SMBus Controller (8086)' > > will get discarded in favor of > > 'Intel(R) ICH9 Family SMBus Controller working fine with > http://download.cnet.com/Chipset-Driver-Inte (8086)' > +1, since I'm the one[1] with (well, not the only one, ICH9 should be quite popular) "http://download.cnet.com/Chipset-Driver-Inte" device. best regards, - Jakub Lach [1] http://docs.freebsd.org/cgi/getmsg.cgi?fetch=748866+0+archive/2010/freebsd-stable/20100912.freebsd-stable -- View this message in context: http://old.nabble.com/regarding-pciids-tp29704378p29707595.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 16:08:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1140E1065673; Tue, 14 Sep 2010 16:08:37 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id 474688FC22; Tue, 14 Sep 2010 16:08:35 +0000 (UTC) Received: from [10.20.1.1] (unknown [10.2.27.254]) by work.netasq.com (Postfix) with ESMTPSA id 32EFF740002; Tue, 14 Sep 2010 18:08:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Fabien Thomas In-Reply-To: <4C8F978F.1030707@networx.ch> Date: Tue, 14 Sep 2010 18:08:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <89E74A8F-4FF9-482B-83D0-3D076F0E41E4@netasq.com> References: <4C8E0C1E.2020707@networx.ch> <4C8F978F.1030707@networx.ch> To: Andre Oppermann X-Mailer: Apple Mail (2.1081) Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: TCP loopback socket fusing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 16:08:37 -0000 On 14 sept. 2010, at 17:41, Andre Oppermann wrote: > On 14.09.2010 11:18, Fabien Thomas wrote: >> Great, >>=20 >> This will maybe kill the long time debate about "my loopback is slow = vs linux" >> To have the best of both world what about a socket option to = enable/disable fusing: >> can be useful when you need to see some connection "packetized". >=20 > A sysctl to that effect is already in the patch. yes, i'm just wondering on a per connection setting. >=20 > --=20 > Andre >=20 >> Fabien >>=20 >> On 13 sept. 2010, at 13:33, Andre Oppermann wrote: >>=20 >>> When a TCP connection via loopback back to localhost is made the = whole >>> send, segmentation and receive path (with larger packets though) is = still >>> executed. This has some considerable overhead. >>>=20 >>> To short-circuit the send and receive sockets on localhost TCP = connections >>> I've made a proof-of-concept patch that directly places the data in = the >>> other side's socket buffer without doing any packetization and other = protocol >>> overhead (like UNIX domain sockets). The connections setup (SYN, = SYN-ACK, >>> ACK) and shutdown are still handled by normal TCP segments via = loopback so >>> that firewalling stills works. The actual payload data during the = session >>> won't be seen and the sequence numbers don't move other than for SYN = and FIN. >>> The sequence are remain valid though. Obviously tcpdump won't see = any data >>> transfers either if the connection has fused sockets. >>>=20 >>> Preliminary testing (with WITNESS and INVARIANTS enabled) has shown = stable >>> operation and a rough doubling of the throughput on loopback = connections. >>> I've tested most socket teardown cases and it behaves fine. I'm not = entirely >>> sure I've got all possible path's but the way it is integrated = should properly >>> defuse the sockets in all situations. >>>=20 >>> Testers and feedback wanted: >>>=20 >>> http://people.freebsd.org/~andre/tcp_loopfuse-20100913.diff >>>=20 >>> -- >>> Andre >>>=20 >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" >>=20 >>=20 >>=20 >=20 From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 15:41:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E4B8106566C for ; Tue, 14 Sep 2010 15:41:03 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 86D0F8FC19 for ; Tue, 14 Sep 2010 15:41:02 +0000 (UTC) Received: (qmail 62465 invoked from network); 14 Sep 2010 15:36:00 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Sep 2010 15:36:00 -0000 Message-ID: <4C8F978F.1030707@networx.ch> Date: Tue, 14 Sep 2010 17:41:03 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Fabien Thomas References: <4C8E0C1E.2020707@networx.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 14 Sep 2010 16:37:34 +0000 Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: TCP loopback socket fusing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 15:41:03 -0000 On 14.09.2010 11:18, Fabien Thomas wrote: > Great, > > This will maybe kill the long time debate about "my loopback is slow vs linux" > To have the best of both world what about a socket option to enable/disable fusing: > can be useful when you need to see some connection "packetized". A sysctl to that effect is already in the patch. -- Andre > Fabien > > On 13 sept. 2010, at 13:33, Andre Oppermann wrote: > >> When a TCP connection via loopback back to localhost is made the whole >> send, segmentation and receive path (with larger packets though) is still >> executed. This has some considerable overhead. >> >> To short-circuit the send and receive sockets on localhost TCP connections >> I've made a proof-of-concept patch that directly places the data in the >> other side's socket buffer without doing any packetization and other protocol >> overhead (like UNIX domain sockets). The connections setup (SYN, SYN-ACK, >> ACK) and shutdown are still handled by normal TCP segments via loopback so >> that firewalling stills works. The actual payload data during the session >> won't be seen and the sequence numbers don't move other than for SYN and FIN. >> The sequence are remain valid though. Obviously tcpdump won't see any data >> transfers either if the connection has fused sockets. >> >> Preliminary testing (with WITNESS and INVARIANTS enabled) has shown stable >> operation and a rough doubling of the throughput on loopback connections. >> I've tested most socket teardown cases and it behaves fine. I'm not entirely >> sure I've got all possible path's but the way it is integrated should properly >> defuse the sockets in all situations. >> >> Testers and feedback wanted: >> >> http://people.freebsd.org/~andre/tcp_loopfuse-20100913.diff >> >> -- >> Andre >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 16:05:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DD0E106566C for ; Tue, 14 Sep 2010 16:05:12 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id D2B6D8FC17 for ; Tue, 14 Sep 2010 16:05:11 +0000 (UTC) Received: (qmail 62703 invoked from network); 14 Sep 2010 16:00:09 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Sep 2010 16:00:09 -0000 Message-ID: <4C8F9D38.9020100@networx.ch> Date: Tue, 14 Sep 2010 18:05:12 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ian FREISLICH References: <4C8E0C1E.2020707@networx.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 14 Sep 2010 16:37:44 +0000 Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Fabien Thomas Subject: Re: TCP loopback socket fusing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 16:05:12 -0000 On 14.09.2010 12:12, Ian FREISLICH wrote: > Fabien Thomas wrote: >> Great, >> >> This will maybe kill the long time debate about "my loopback is slow vs >> linux" >> To have the best of both world what about a socket option to >> enable/disable fusing: >> can be useful when you need to see some connection "packetized". > > To chime in, I had a "slow" loopback issue earlier this week. It > turned out the problem was caused by delayed ack on the loopback > where the client didn't need to transmit any data to the server. > It delayed each packet from the server by 100ms. After patching > the server to: > > setsockopt(desc->accept_fd, IPPROTO_TCP, TCP_NODELAY,&x, sizeof(x)); > > It's now faster than on linux. > > Perhaps this is one of the causes of "my loopback is slow vs linux". > > FWIW, I couldn't find a way to turn off dealyed_ack on just loopback > interface. Good point. You can't at the moment but it certainly makes a lot of sense. Let me see what I can come up with. -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 16:07:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FA841065672 for ; Tue, 14 Sep 2010 16:07:18 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B14758FC12 for ; Tue, 14 Sep 2010 16:07:17 +0000 (UTC) Received: (qmail 62745 invoked from network); 14 Sep 2010 16:02:15 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Sep 2010 16:02:15 -0000 Message-ID: <4C8F9DB6.4050309@networx.ch> Date: Tue, 14 Sep 2010 18:07:18 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Maxim Dounin References: <4C8E0C1E.2020707@networx.ch> <20100914103549.GI99657@mdounin.ru> In-Reply-To: <20100914103549.GI99657@mdounin.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 14 Sep 2010 16:38:01 +0000 Cc: freebsd-net@freebsd.org, Ian FREISLICH , Fabien Thomas , freebsd-current@freebsd.org Subject: Re: TCP loopback socket fusing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 16:07:18 -0000 On 14.09.2010 12:35, Maxim Dounin wrote: > Hello! > > On Tue, Sep 14, 2010 at 12:12:03PM +0200, Ian FREISLICH wrote: > >> Fabien Thomas wrote: >>> Great, >>> >>> This will maybe kill the long time debate about "my loopback is slow vs >>> linux" >>> To have the best of both world what about a socket option to >>> enable/disable fusing: >>> can be useful when you need to see some connection "packetized". >> >> To chime in, I had a "slow" loopback issue earlier this week. It >> turned out the problem was caused by delayed ack on the loopback >> where the client didn't need to transmit any data to the server. >> It delayed each packet from the server by 100ms. After patching >> the server to: >> >> setsockopt(desc->accept_fd, IPPROTO_TCP, TCP_NODELAY,&x, sizeof(x)); >> >> It's now faster than on linux. >> >> Perhaps this is one of the causes of "my loopback is slow vs linux". >> >> FWIW, I couldn't find a way to turn off dealyed_ack on just loopback >> interface. > > AFAIK in linux delayed ack behaves a bit more gently and doesn't > delay first ack(s) in a connection. As a result linux hides some > classic delayed ack vs. Nagle problems. > > Something similar probably should be adapted. I saw something like that while glancing over the Linux code some time ago. Couldn't make much sense out of the code snipped because their TCP code split into a myriad of small functions and thus hard to follow in the beginning. Not the ours is much easier on a beginner. -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 16:22:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93DAE1065679 for ; Tue, 14 Sep 2010 16:22:45 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 07F348FC18 for ; Tue, 14 Sep 2010 16:22:44 +0000 (UTC) Received: (qmail 62857 invoked from network); 14 Sep 2010 16:17:42 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Sep 2010 16:17:42 -0000 Message-ID: <4C8FA155.8050602@networx.ch> Date: Tue, 14 Sep 2010 18:22:45 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Fabien Thomas References: <4C8E0C1E.2020707@networx.ch> <4C8F978F.1030707@networx.ch> <89E74A8F-4FF9-482B-83D0-3D076F0E41E4@netasq.com> In-Reply-To: <89E74A8F-4FF9-482B-83D0-3D076F0E41E4@netasq.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 14 Sep 2010 16:45:47 +0000 Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: TCP loopback socket fusing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 16:22:45 -0000 On 14.09.2010 18:08, Fabien Thomas wrote: > > On 14 sept. 2010, at 17:41, Andre Oppermann wrote: > >> On 14.09.2010 11:18, Fabien Thomas wrote: >>> Great, >>> >>> This will maybe kill the long time debate about "my loopback is slow vs linux" >>> To have the best of both world what about a socket option to enable/disable fusing: >>> can be useful when you need to see some connection "packetized". >> >> A sysctl to that effect is already in the patch. > yes, i'm just wondering on a per connection setting. I've devised a way to prevent socket fusing when bpf is enabled on the interface the loopback came from. So I'm leaning against adding another obscure and non-portable socket option. -- Andre From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 17:14:01 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8B5A106566C; Tue, 14 Sep 2010 17:14:01 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 03BB68FC16; Tue, 14 Sep 2010 17:14:00 +0000 (UTC) Received: by bwz15 with SMTP id 15so598752bwz.13 for ; Tue, 14 Sep 2010 10:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=XoLPhqLybdgieChDIeSU0ll7rMEpekIJQhEKi0/qSoM=; b=BrjO13nEilbYShYHbJLZV7xrbPMo+eNCboys0jU4ytsM+J74Jz5amqIZMqomVI6WV9 Bt/xnjU+PgplR+gESC4Dpl8aUelB3GLFOSc7G6My6Ar64JwryrhyfIFPe+RCX0oneAs9 DI9THHLuBQXml+T+UXj5paSh3/b/J/9lkg/aM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PsTBGP/CmQ81HFkXhukyS3lHGZjsiLHnOuDPB5nbRgro84NwlmBbD4bkUdYFvrvkDP RJcYHclOzQK2O6SSXz9XAdR70b/1f+ghdnFpV2SN/nUW7TNrFrbXOl5Js6bd7BWqqvpC Bs6gDgGkznkIvBdslFxZhYRxQNqXYHBS6fatY= MIME-Version: 1.0 Received: by 10.204.142.92 with SMTP id p28mr224866bku.2.1284484439185; Tue, 14 Sep 2010 10:13:59 -0700 (PDT) Received: by 10.204.80.167 with HTTP; Tue, 14 Sep 2010 10:13:58 -0700 (PDT) In-Reply-To: <66df85d07cbdb142e53ea8dd5020b7bf@localhost> References: <4C8A5CA0.1050700@feral.com> <4C8A7ACB.9070408@FreeBSD.org> <20100910234830.87641e07.ray@ddteam.net> <4C8ACE52.8060000@FreeBSD.org> <66df85d07cbdb142e53ea8dd5020b7bf@localhost> Date: Tue, 14 Sep 2010 19:13:58 +0200 Message-ID: From: David DEMELIER To: Marian Hettwer Content-Type: text/plain; charset=UTF-8 Cc: Aleksandr Rybalko , Doug Barton , freebsd-current@freebsd.org, Gordon Tetlow , Julien Laffaye , Matthew Jacob Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 17:14:01 -0000 2010/9/14 Marian Hettwer : > On Tue, 14 Sep 2010 07:11:28 +0200, David DEMELIER > wrote: >> 2010/9/13 Gordon Tetlow : >>> On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER >>> wrote: >>>> >>>> Perl is a great example, I don't really understand why it's in the >>>> base, then the port need to rewrite the links into the base hierarchy >>>> and I think this is bad. >>> >>> Perl is not in the base system anymore. It's in the ports system. >>> Gordon >> >> Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect ! > > Uh. Perl was moved to ports somewhere in 2002 or 2003, IIRC. > Nothing to do with following -current ;-) > > ./Marian > Oh then I'm confused, why the ports still rewrite links in /usr/bin then ? -- Demelier David From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 17:21:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 352891065670; Tue, 14 Sep 2010 17:21:00 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1BB6E8FC20; Tue, 14 Sep 2010 17:21:00 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o8EHKtmg017135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Sep 2010 10:20:55 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 4C8A21CC3C; Tue, 14 Sep 2010 10:20:55 -0700 (PDT) To: David DEMELIER In-reply-to: Your message of "Tue, 14 Sep 2010 19:13:58 +0200." Date: Tue, 14 Sep 2010 10:20:55 -0700 From: "Kevin Oberman" Message-Id: <20100914172055.4C8A21CC3C@ptavv.es.net> Cc: Aleksandr Rybalko , Julien Laffaye , Gordon Tetlow , freebsd-current@freebsd.org, Doug Barton , Matthew Jacob , Marian Hettwer Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 17:21:00 -0000 > Date: Tue, 14 Sep 2010 19:13:58 +0200 > From: David DEMELIER > Sender: owner-freebsd-current@freebsd.org > > 2010/9/14 Marian Hettwer : > > On Tue, 14 Sep 2010 07:11:28 +0200, David DEMELIER > > wrote: > >> 2010/9/13 Gordon Tetlow : > >>> On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER > >>> wrote: > >>>> > >>>> Perl is a great example, I don't really understand why it's in the > >>>> base, then the port need to rewrite the links into the base hierarchy > >>>> and I think this is bad. > >>> > >>> Perl is not in the base system anymore. It's in the ports system. > >>> Gordon > >> > >> Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect ! > > > > Uh. Perl was moved to ports somewhere in 2002 or 2003, IIRC. > > Nothing to do with following -current ;-) > > > > ./Marian > > > > Oh then I'm confused, why the ports still rewrite links in /usr/bin then ? This was a way to avoid breaking the huge number of perl scripts that had: #!/usr/bin/perl as the first line. If perl simply moved to /usr/local/bin, this would have broken a LOT of stuff people were doing, so it was decided to put a link in /usr/bin. The port now has an option to control this, but it is still there by default: USE_PERL "Rewritelinks in /usr/bin" on -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 17:30:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CC63106566B; Tue, 14 Sep 2010 17:30:05 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id DC4868FC08; Tue, 14 Sep 2010 17:30:04 +0000 (UTC) Received: by bwz15 with SMTP id 15so618900bwz.13 for ; Tue, 14 Sep 2010 10:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pYp1enZR/kTrRNm1i4MXxxV86GqiAUYvnRvYDeBia4k=; b=GZyOYWFSFIEwJozp1kgfiamz9pfKBBXxraB5WJ/I6Q/9FnZp95O/1zrlS3P8e/qyh5 Lbbm+SbnXOhChshhpI/vh9I1nLRFxvluDpEH/RCrzAvYOGivh1IGWdqCgkDbmigGGQNp DSMehQQLqMERHG+1Qwrf6QZs1nfc7u/zdzMDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KXFsGYG19ldMU8ZwIX0bg/r6urV/YDcFZJU6P4vxcOU+z6TCw1fwtIkvJXppfkquPF zIlUmdF7my9m5ZY3322FpZdJxjXTZwtIAA3QVcFVUkvmq/GkneUlMOavNz+iAR65eZ1R gl5B1yWmU1tsEpI3tGnHIvwWq+m/vM3MBCT+M= MIME-Version: 1.0 Received: by 10.204.48.75 with SMTP id q11mr249549bkf.0.1284485403476; Tue, 14 Sep 2010 10:30:03 -0700 (PDT) Received: by 10.204.80.167 with HTTP; Tue, 14 Sep 2010 10:30:03 -0700 (PDT) In-Reply-To: <20100914172055.4C8A21CC3C@ptavv.es.net> References: <20100914172055.4C8A21CC3C@ptavv.es.net> Date: Tue, 14 Sep 2010 19:30:03 +0200 Message-ID: From: David DEMELIER To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Aleksandr Rybalko , Julien Laffaye , Gordon Tetlow , freebsd-current@freebsd.org, Doug Barton , Matthew Jacob , Marian Hettwer Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 17:30:05 -0000 2010/9/14 Kevin Oberman : >> Date: Tue, 14 Sep 2010 19:13:58 +0200 >> From: David DEMELIER >> Sender: owner-freebsd-current@freebsd.org >> >> 2010/9/14 Marian Hettwer : >> > On Tue, 14 Sep 2010 07:11:28 +0200, David DEMELIER >> > wrote: >> >> 2010/9/13 Gordon Tetlow : >> >>> On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER >> >>> wrote: >> >>>> >> >>>> Perl is a great example, I don't really understand why it's in the >> >>>> base, then the port need to rewrite the links into the base hierarc= hy >> >>>> and I think this is bad. >> >>> >> >>> Perl is not in the base system anymore. It's in the ports system. >> >>> Gordon >> >> >> >> Oh sorry I didn't saw that ! (I'm not following -current yet). Perfec= t ! >> > >> > Uh. Perl was moved to ports somewhere in 2002 or 2003, IIRC. >> > Nothing to do with following -current ;-) >> > >> > ./Marian >> > >> >> Oh then I'm confused, why the ports still rewrite links in /usr/bin then= ? > > This was a way to avoid breaking the huge number of perl scripts that > had: #!/usr/bin/perl as the first line. If perl simply moved to > /usr/local/bin, this would have broken a LOT of stuff people were doing, > so it was decided to put a link in /usr/bin. The port now has an option > to control this, but it is still there by default: > USE_PERL "Rewritelinks in /usr/bin" on > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 =C2=A0EADA 927D EBB3 987B 3751 > Well I see, thanks ! --=20 Demelier David From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 17:42:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D613B106566B for ; Tue, 14 Sep 2010 17:42:33 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 694288FC22 for ; Tue, 14 Sep 2010 17:42:33 +0000 (UTC) Received: by wyb33 with SMTP id 33so9036138wyb.13 for ; Tue, 14 Sep 2010 10:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Pc5X0DH8+5GV6ahLCpzjXS5JdVW93AMWZXi+Cd4Nn8Q=; b=LnLgrC/It/2zAembJtV9ssEgJ/w6bXJo8yMf/RU4CmLLzn/0NwxoZvwsJIgoGaDDT8 HJkaHav8zwGDdeoWci7JNNTpqGsxnyMHixypQLxkDVQXhsXATcOw3KTkwdAO04RVkZiE RUWb3KVaNotufo1xMvQ1FdgU4IdaBxMBfiNEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=VhQAXgUtFTqB9heG8vYWAbWhJhkGFm+/LblqzbhyccC+ayrrWufNBpjZL449DsL0Kp 7UYLbm2nL4VHUPHGuugoAWnXhX8q8MkrYaLBqbghIGrBJd8QyebhMEJWGReoWg/phms5 NDe36sJH7YHexh6W28xUN4IkWP4hHh/zW3Q6g= MIME-Version: 1.0 Received: by 10.216.6.195 with SMTP id 45mr4150283wen.86.1284484738275; Tue, 14 Sep 2010 10:18:58 -0700 (PDT) Received: by 10.216.49.78 with HTTP; Tue, 14 Sep 2010 10:18:58 -0700 (PDT) In-Reply-To: <29707595.post@talk.nabble.com> References: <20100914005946.GA7417@freebsd.org> <29707595.post@talk.nabble.com> Date: Tue, 14 Sep 2010 10:18:58 -0700 Message-ID: From: Jack Vogel To: Jakub Lach Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: regarding pciids X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 17:42:34 -0000 On Tue, Sep 14, 2010 at 4:29 AM, Jakub Lach wrote: > > > Alexander Best-4 wrote: > > > > any thoughts on using http://pciids.sourceforge.net/ for pciids instead > of > > the > > Hart and Boemler lists. the SF site seems to be updated more regularly > and > > would get rid of the need to decide for each entry, whether to take the > > Hart or > > Boemler one. > > > > right now tools/tools/pciid/mk_pci_vendors.pl favours long descriptions > > over > > short ones which means that something like: > > > > 'Intel(R) ICH9 Family SMBus Controller (8086)' > > > > will get discarded in favor of > > > > 'Intel(R) ICH9 Family SMBus Controller working fine with > > http://download.cnet.com/Chipset-Driver-Inte (8086)' > > > > +1, since I'm the one[1] with (well, not the only one, ICH9 should be quite > popular) > "http://download.cnet.com/Chipset-Driver-Inte" device. > > best regards, > - Jakub Lach > JFYI, the sourceforge site is where Intel updates its data, and until this post I was already under the impression we pulled from there. I would say that it would be the better source. Jack From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 19:39:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 9BC6F1065672; Tue, 14 Sep 2010 19:39:22 +0000 (UTC) Date: Tue, 14 Sep 2010 19:39:22 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20100914193922.GA71865@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline Subject: Bad cg number with SU+J X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 19:39:22 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi there, a few minutes ago my machine froze running HEAD (r212616; amd64). after i did a reset i had to deal with a situation i've documented in the attached file. after having a healthy ufs2 fs again the results was: i lost 4 files (unimportant /usr/ports/* stuff). otaku% tunefs -p / tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) rootfs otaku% file -s /dev/ufs/rootfs /dev/ufs/rootfs: Unix Fast File system [v2] (little-endian) last mounted on /, volume name rootfs, last written at Tue Sep 14 20:35:52 2010, clean flag 0, readonly flag 0, number of blocks 117904411, number of data blocks 114192521, number of cylinder groups 1254, block size 16384, fragment size 2048, average file size 16384, average number of files in dir 64, pending blocks to free 0, pending inodes to free 1, system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization otaku% mount /dev/ufs/rootfs on / (ufs, local, noatime, soft-updates) devfs on /dev (devfs, local) devfs on /usr/compat/linux/dev (devfs, local) linprocfs on /usr/local/gentoo-stage3/proc (linprocfs, local) linsysfs on /usr/local/gentoo-stage3/sys (linsysfs, local) devfs on /usr/local/gentoo-stage3/dev (devfs, local) cheers. alex -- a13x --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=bad_fsck Starting file system checks: ** SU+J Recovering /dev/ufs/rootfs ** Reading 33554432 byte journal from inode 3. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. /dev/ufs/rootfs: Bad cg number 77659923 /dev/ufs/rootfs: UNEXPECTED SU+J INCONSISTENCY /dev/ufs/rootfs: INTERNAL ERROR: GOT TO reply() /dev/ufs/rootfs: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY. Automatic file system check failed; help! ERROR: ABORTING BOOT (sending SIGTERM to parent)! Sep 14 20:51:27 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter root password, or ^D to go multi-user Password: Sep 14 20:51:37 init: NSSWITCH(_nsdispatch): nis, passwd_compat, endpwent, not f ound, and no fallback provided Enter full pathname of shell or RETURN for /bin/sh: # fsck / ** /dev/ufs/rootfs USE JOURNAL? [yn] n ** Skipping journal, falling through to full fsck ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes PARTIALLY TRUNCATED INODE I=27697158 SALVAGE? [yn] y 7523097642930302787 BAD I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 4121110496150036596 BAD I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 2319407891165819449 BAD I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 7306371615995291732 BAD I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 7669474378899542850 BAD I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 8101767965670925157 BAD I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 2891438952532243065 BAD I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 3186638930118191459 BAD I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 3539877892726534432 BAD I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 4051323354046740537 BAD I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 3186358554653109302 BAD I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY EXCESSIVE BAD BLKS I=27697158 CONTINUE? [yn] y INCORRECT BLOCK COUNT I=27697158 (64 should be 352) CORRECT? [yn] y 110708408 DUP I=27697432 UNEXPECTED SOFT UPDATE INCONSISTENCY 110708409 DUP I=27697432 UNEXPECTED SOFT UPDATE INCONSISTENCY 110708410 DUP I=27697432 UNEXPECTED SOFT UPDATE INCONSISTENCY 110708411 DUP I=27697432 UNEXPECTED SOFT UPDATE INCONSISTENCY 110708412 DUP I=27697432 UNEXPECTED SOFT UPDATE INCONSISTENCY 110708413 DUP I=27697452 UNEXPECTED SOFT UPDATE INCONSISTENCY 110708414 DUP I=27697452 UNEXPECTED SOFT UPDATE INCONSISTENCY 110708415 DUP I=27697452 UNEXPECTED SOFT UPDATE INCONSISTENCY INCORRECT BLOCK COUNT I=27697559 (32 should be 0) CORRECT? [yn] y INCORRECT BLOCK COUNT I=27698047 (32 should be 0) CORRECT? [yn] y INCORRECT BLOCK COUNT I=27698050 (32 should be 0) CORRECT? [yn] y INTERNAL ERROR: dups with softupdates UNEXPECTED SOFT UPDATE INCONSISTENCY ** Phase 1b - Rescan For More DUPS 110708408 DUP I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 110708409 DUP I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 110708410 DUP I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 110708411 DUP I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 110708412 DUP I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 110708413 DUP I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 110708414 DUP I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY 110708415 DUP I=27697158 UNEXPECTED SOFT UPDATE INCONSISTENCY ** Phase 2 - Check Pathnames DUP/BAD I=27697432 OWNER=root MODE=100600 SIZE=10009 MTIME=Sep 14 03:07 2010 FILE=/var/log/dmesg.today UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? [yn] y DUP/BAD I=27697452 OWNER=root MODE=100644 SIZE=4167 MTIME=Sep 14 13:36 2010 FILE=/usr/ports/emulators/qemu-devel/work/qemu-0.12.5/bsd/amd64/s_ceill.S UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? [yn] y ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=2661472 OWNER=arundel MODE=100600 SIZE=0 MTIME=Sep 14 20:50 2010 CLEAR? [yn] y UNREF FILE I=15145853 OWNER=arundel MODE=100600 SIZE=0 MTIME=Sep 14 20:49 2010 RECONNECT? [yn] y BAD/DUP FILE I=27697158 OWNER=arundel MODE=100600 SIZE=6309280 MTIME=Sep 13 15:41 2010 CLEAR? [yn] y BAD/DUP FILE I=27697432 OWNER=root MODE=100600 SIZE=10009 MTIME=Sep 14 03:07 2010 CLEAR? [yn] y BAD/DUP FILE I=27697452 OWNER=root MODE=100644 SIZE=4167 MTIME=Sep 14 13:36 2010 CLEAR? [yn] y UNREF FILE I=27697497 OWNER=arundel MODE=100600 SIZE=32768 MTIME=Sep 14 20:06 2010 CLEAR? [yn] y UNREF FILE I=27697559 OWNER=arundel MODE=100600 SIZE=0 MTIME=Sep 13 13:16 2010 CLEAR? [yn] y UNREF FILE I=27697645 OWNER=arundel MODE=100600 SIZE=0 MTIME=Sep 13 13:16 2010 CLEAR? [yn] y UNREF FILE I=27697649 OWNER=arundel MODE=100600 SIZE=0 MTIME=Sep 13 13:16 2010 CLEAR? [yn] y UNREF FILE I=27697724 OWNER=arundel MODE=100600 SIZE=0 MTIME=Sep 13 13:16 2010 CLEAR? [yn] y UNREF FILE I=27697725 OWNER=arundel MODE=100600 SIZE=0 MTIME=Sep 13 13:16 2010 CLEAR? [yn] y UNREF FILE I=27697854 OWNER=arundel MODE=100600 SIZE=0 MTIME=Sep 13 13:16 2010 CLEAR? [yn] y UNREF FILE I=27697855 OWNER=arundel MODE=100600 SIZE=0 MTIME=Sep 13 13:16 2010 CLEAR? [yn] y UNREF FILE I=27697919 OWNER=arundel MODE=100600 SIZE=0 MTIME=Sep 13 13:16 2010 CLEAR? [yn] y UNREF FILE I=27697931 OWNER=arundel MODE=100600 SIZE=0 MTIME=Sep 13 13:16 2010 CLEAR? [yn] y UNREF FILE I=27698040 OWNER=arundel MODE=100600 SIZE=0 MTIME=Sep 13 13:16 2010 CLEAR? [yn] y UNREF FILE I=27698047 OWNER=arundel MODE=100600 SIZE=0 MTIME=Sep 13 13:16 2010 CLEAR? [yn] y UNREF FILE I=27698049 OWNER=arundel MODE=100600 SIZE=0 MTIME=Sep 13 13:16 2010 CLEAR? [yn] y UNREF FILE I=27698050 OWNER=arundel MODE=100600 SIZE=0 MTIME=Sep 13 13:16 2010 CLEAR? [yn] y ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 719535 files, 102466267 used, 11726254 free (244134 frags, 1435265 blocks, 0.2% fragmentation) ***** FILE SYSTEM MARKED CLEAN ***** ***** FILE SYSTEM WAS MODIFIED ***** # fsck / ** /dev/ufs/rootfs USE JOURNAL? [yn] n ** Skipping journal, falling through to full fsck ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 719535 files, 102466267 used, 11726254 free (244134 frags, 1435265 blocks, 0.2% fragmentation) ***** FILE SYSTEM IS CLEAN ***** ***** FILE SYSTEM WAS MODIFIED ***** --sm4nu43k4a2Rpi4c-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 20:09:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0CA81065670; Tue, 14 Sep 2010 20:09:04 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 84C988FC16; Tue, 14 Sep 2010 20:09:04 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.4/8.14.4) with ESMTP id o8EK94Y5049832; Tue, 14 Sep 2010 13:09:04 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.4/8.14.4/Submit) id o8EK94aS049831; Tue, 14 Sep 2010 13:09:04 -0700 (PDT) (envelope-from sgk) Date: Tue, 14 Sep 2010 13:09:04 -0700 From: Steve Kargl To: Alexander Best Message-ID: <20100914200904.GA49806@troutmask.apl.washington.edu> References: <20100914193922.GA71865@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100914193922.GA71865@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Bad cg number with SU+J X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 20:09:04 -0000 On Tue, Sep 14, 2010 at 07:39:22PM +0000, Alexander Best wrote: > hi there, > > a few minutes ago my machine froze running HEAD (r212616; amd64). after i did > a reset i had to deal with a situation i've documented in the attached file. > http://lists.freebsd.org/pipermail/freebsd-current/2010-September/019760.html >From an email reply that I received (which was not sent to the mailing list), it seems that this is a known problem with SU+J. When you lock up again (which you will), simply disable journaling. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 20:20:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id A999D10656C1; Tue, 14 Sep 2010 20:20:27 +0000 (UTC) Date: Tue, 14 Sep 2010 20:20:27 +0000 From: Alexander Best To: Steve Kargl Message-ID: <20100914202027.GA79567@freebsd.org> References: <20100914193922.GA71865@freebsd.org> <20100914200904.GA49806@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100914200904.GA49806@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org Subject: Re: Bad cg number with SU+J X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 20:20:27 -0000 On Tue Sep 14 10, Steve Kargl wrote: > On Tue, Sep 14, 2010 at 07:39:22PM +0000, Alexander Best wrote: > > hi there, > > > > a few minutes ago my machine froze running HEAD (r212616; amd64). after i did > > a reset i had to deal with a situation i've documented in the attached file. > > > > http://lists.freebsd.org/pipermail/freebsd-current/2010-September/019760.html > > >From an email reply that I received (which was not sent to the > mailing list), it seems that this is a known problem with > SU+J. When you lock up again (which you will), simply > disable journaling. thanks for the info. it seems as if SU+J still as a few rough edges here and there. hope that jeff and kirk will have these sorted out soon. :) cheers. alex > > -- > Steve -- a13x From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 20:24:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 749FA106566B for ; Tue, 14 Sep 2010 20:24:19 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 38F658FC19 for ; Tue, 14 Sep 2010 20:24:19 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 0641DA05FB; Tue, 14 Sep 2010 20:24:17 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Tue, 14 Sep 2010 22:24:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adrian Chadd X-Mailer: Apple Mail (2.1081) Cc: freebsd-current Subject: Re: AR9132 CPU and AR9100 wireless support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 20:24:19 -0000 Am 14.09.2010 um 11:35 schrieb Adrian Chadd: > Hi everyone, >=20 > I've just pushed the initial support for the AR9100 wireless MAC into > my git repository. This is for the WMAC on the AR9132 SoC. >=20 > I've tested it in 11bg hostap mode on an AP83 derived box - the > TP-Link TL-WR1043ND. The source tree has support for the CPU, ethernet > (but not the switch PHY; it's enough to get data across it!); flash > and the AR9100 WMAC. >=20 > I've only tested "open" hostap mode on 11bg on a fixed channel. >=20 > The GIT repo is at: > http://www.gitorious.org/~adrianchadd/freebsd/adrianchadd-freebsd ; > it's the "work/atheros" branch. You'll need to open the unit up, > solder on some pins to get to the serial port and acquire a TTL -> > RS232 level converter. There's pictures and howto on the OpenWRT wiki: > http://wiki.openwrt.org/toh/tp-link/tl-wr1043nd That sounds really nice! Is there some guide on how to prepare an = image? I'm quite familiar with OpenWrt (patching and building) and have = a number of routers (WRT-160N, WR941NL, 500gP) with serial adapters = attached, but from the messages on the mips list, it felt the = bootstrapping process might be a bit dauting... Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Tue Sep 14 21:39:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DB691065674 for ; Tue, 14 Sep 2010 21:39:27 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9238FC22 for ; Tue, 14 Sep 2010 21:39:26 +0000 (UTC) Received: by eyx24 with SMTP id 24so3936048eyx.13 for ; Tue, 14 Sep 2010 14:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=OPjj4nZM3u3JhdICytyB7i0zRdAxo30fXyoWpuYREyc=; b=QtFCqR130aYPnp7oSanIlGJwLGd7wljTLXTY23Q8MUFw++yV+py3njHrvjOhPlg9by YG+bhYFjAenWL+xXvz96Soj9PCEIg9sxlbddx+0Dulwt8ATh0Ue7tu63df7pKEzqjC1M GXAoFlgo2rOFOYcHoI+uPr+fRTYWYIzomBsmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Bo4ItVm3n9vRjjQTcP1NkxiiTBtF5G981VJ9oKKCoYlC3PJ+40p5slFWSNYiX55mA/ Cl4YUVvEkgvYfHHTnYevMJkz82vWZ/PTP1Uf71UVGPHV0hISws0DWJWEpo0SRPkv6vIi Yfy3QVioZHmKLLauiPMlX9OxkZlFCr4SSk5fo= MIME-Version: 1.0 Received: by 10.213.113.147 with SMTP id a19mr3275596ebq.24.1284498521251; Tue, 14 Sep 2010 14:08:41 -0700 (PDT) Received: by 10.14.47.79 with HTTP; Tue, 14 Sep 2010 14:08:41 -0700 (PDT) In-Reply-To: References: Date: Tue, 14 Sep 2010 17:08:41 -0400 Message-ID: From: Outback Dingo To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Adrian Chadd , freebsd-current Subject: Re: AR9132 CPU and AR9100 wireless support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 21:39:27 -0000 Ive got some Ubiquiti mips devices id love to get FreeBSD on permanently and a Netgear WNDR370, if only we could boot FreeBSD out of redboot and flash it to them it would seriously ROCK, On Tue, Sep 14, 2010 at 4:24 PM, Stefan Bethke wrote: > Am 14.09.2010 um 11:35 schrieb Adrian Chadd: > > > Hi everyone, > > > > I've just pushed the initial support for the AR9100 wireless MAC into > > my git repository. This is for the WMAC on the AR9132 SoC. > > > > I've tested it in 11bg hostap mode on an AP83 derived box - the > > TP-Link TL-WR1043ND. The source tree has support for the CPU, ethernet > > (but not the switch PHY; it's enough to get data across it!); flash > > and the AR9100 WMAC. > > > > I've only tested "open" hostap mode on 11bg on a fixed channel. > > > > The GIT repo is at: > > http://www.gitorious.org/~adrianchadd/freebsd/adrianchadd-freebsd ; > > it's the "work/atheros" branch. You'll need to open the unit up, > > solder on some pins to get to the serial port and acquire a TTL -> > > RS232 level converter. There's pictures and howto on the OpenWRT wiki: > > http://wiki.openwrt.org/toh/tp-link/tl-wr1043nd > > That sounds really nice! Is there some guide on how to prepare an image? > I'm quite familiar with OpenWrt (patching and building) and have a number > of routers (WRT-160N, WR941NL, 500gP) with serial adapters attached, but > from the messages on the mips list, it felt the bootstrapping process might > be a bit dauting... > > > Stefan > > -- > Stefan Bethke Fon +49 151 14070811 > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 01:52:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 131DC1065679 for ; Wed, 15 Sep 2010 01:52:34 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from eu1sys200aog119.obsmtp.com (eu1sys200aog119.obsmtp.com [207.126.144.147]) by mx1.freebsd.org (Postfix) with SMTP id 41CC78FC0A for ; Wed, 15 Sep 2010 01:52:32 +0000 (UTC) Received: from source ([63.174.175.251]) by eu1sys200aob119.postini.com ([207.126.147.11]) with SMTP ID DSNKTJAm4EajShxFY4NJ+BGDTne5hJ1HLbsV@postini.com; Wed, 15 Sep 2010 01:52:33 UTC Received: from [192.168.200.3] (170-177-168-192.bbbx4.vpn.mintel.ad [192.168.177.170]) by bbbx3.usdmm.com (Postfix) with ESMTP id 0CF9DFD01C for ; Wed, 15 Sep 2010 01:35:31 +0000 (UTC) Message-ID: <4C9022F3.4050204@tomjudge.com> Date: Tue, 14 Sep 2010 20:35:47 -0500 From: Tom Judge User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Shredder/3.0.3pre MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: AR9132 CPU and AR9100 wireless support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 01:52:34 -0000 On 09/14/2010 04:08 PM, Outback Dingo wrote: > Ive got some Ubiquiti mips devices id love to get FreeBSD on permanently > and a Netgear WNDR370, if only we could boot FreeBSD out of redboot > and flash it to them it would seriously ROCK, > > Booting FreeBSD out of redboot should be no problem. I have used the redboot loader on a Intel NAS to load a FreeBSD kernel and boot successfully, this was an arm core rather than mips however. If you have a working redboot you can also use the redboot shell to flash your kernel (with embedded MFS image) into the SPI part and then rewrite the load script to boot that. The debian-installer armel handbook had some useful docs in it for the platform I was working on, as well as the official redboot site. Tom > On Tue, Sep 14, 2010 at 4:24 PM, Stefan Bethke wrote: > > >> Am 14.09.2010 um 11:35 schrieb Adrian Chadd: >> >> >>> Hi everyone, >>> >>> I've just pushed the initial support for the AR9100 wireless MAC into >>> my git repository. This is for the WMAC on the AR9132 SoC. >>> >>> I've tested it in 11bg hostap mode on an AP83 derived box - the >>> TP-Link TL-WR1043ND. The source tree has support for the CPU, ethernet >>> (but not the switch PHY; it's enough to get data across it!); flash >>> and the AR9100 WMAC. >>> >>> I've only tested "open" hostap mode on 11bg on a fixed channel. >>> >>> The GIT repo is at: >>> http://www.gitorious.org/~adrianchadd/freebsd/adrianchadd-freebsd ; >>> it's the "work/atheros" branch. You'll need to open the unit up, >>> solder on some pins to get to the serial port and acquire a TTL -> >>> RS232 level converter. There's pictures and howto on the OpenWRT wiki: >>> http://wiki.openwrt.org/toh/tp-link/tl-wr1043nd >>> >> That sounds really nice! Is there some guide on how to prepare an image? >> I'm quite familiar with OpenWrt (patching and building) and have a number >> of routers (WRT-160N, WR941NL, 500gP) with serial adapters attached, but >> from the messages on the mips list, it felt the bootstrapping process might >> be a bit dauting... >> >> >> Stefan >> >> -- >> Stefan Bethke Fon +49 151 14070811 >> >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 03:20:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ED1F106566B for ; Wed, 15 Sep 2010 03:20:24 +0000 (UTC) (envelope-from adrian.chadd@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 E75588FC12 for ; Wed, 15 Sep 2010 03:20:23 +0000 (UTC) Received: by iwn34 with SMTP id 34so7634593iwn.13 for ; Tue, 14 Sep 2010 20:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2rA5ryHYIaDAdOkgJ0K2qR9CJw39JB5qihvPm4fpXSM=; b=kejC9lPp78Ivj1oV7wKNA5s3Bj7mv0NYopliExf6AmIq/awU1HhgOSB4wcFBUQZhf3 JlD30+fWaFmd2R8kNufpKJBJV5282dpEAREljq6z53DZ0wROvzG3AcjYVyk0W6OJNhEI 1CXJj/vD5O0mXa2M+D8iCxMuyu4yc/ltNQDZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=f4Q32+yCZbwh5SuqiWrByjQKxxr1MHH64bg3/eB5DP1GqX1ZsZuRHX3Lyv6gN27KyD kTsjsKn6UIAMzTicL0JRl4MXjhMMsakR/z7Q+N3oHTQz4Im6GrDwHNffxOI4p6kC5AX7 qSyafrO+KLYvnPS6rneK3rSkzwotPeJhy0gpA= MIME-Version: 1.0 Received: by 10.231.192.80 with SMTP id dp16mr1000157ibb.39.1284520823193; Tue, 14 Sep 2010 20:20:23 -0700 (PDT) Received: by 10.231.156.206 with HTTP; Tue, 14 Sep 2010 20:20:23 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Sep 2010 11:20:23 +0800 Message-ID: From: Adrian Chadd To: Outback Dingo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 15 Sep 2010 04:50:11 +0000 Cc: freebsd-current , Stefan Bethke Subject: Re: AR9132 CPU and AR9100 wireless support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 03:20:24 -0000 You can already do that with the rspro. I have a modified mkfwimage and everything which I've been meaning to turn into a port. It should work fine on AR71xx and AR91xx ubiquiti devices. Anything else (eg the AR724x PCIe devices and the earlier SoCs with embedded macs) aren't currently supported. If you have a Routerstation or Routerstation pro then I know for certain everything except the ethernet switch PHY works (so no hardware VLANs.) As for help preparing the images? I can't do that for various reasons, sorry. But I'll make up a mkfwimage port in the next couple days with the modifications to build routerstation pro flash images. Someone with a routerstation board can help me make similar changes for that. Adrian On 15 September 2010 05:08, Outback Dingo wrote: > Ive got some Ubiquiti mips devices id love to get FreeBSD on permanently > and a Netgear WNDR370, if only we could boot FreeBSD out of redboot > and flash it to them=A0it would seriously ROCK, > On Tue, Sep 14, 2010 at 4:24 PM, Stefan Bethke wrote: >> >> Am 14.09.2010 um 11:35 schrieb Adrian Chadd: >> >> > Hi everyone, >> > >> > I've just pushed the initial support for the AR9100 wireless MAC into >> > my git repository. This is for the WMAC on the AR9132 SoC. >> > >> > I've tested it in 11bg hostap mode on an AP83 derived box - the >> > TP-Link TL-WR1043ND. The source tree has support for the CPU, ethernet >> > (but not the switch PHY; it's enough to get data across it!); flash >> > and the AR9100 WMAC. >> > >> > I've only tested "open" hostap mode on 11bg on a fixed channel. >> > >> > The GIT repo is at: >> > http://www.gitorious.org/~adrianchadd/freebsd/adrianchadd-freebsd ; >> > it's the "work/atheros" branch. You'll need to open the unit up, >> > solder on some pins to get to the serial port and acquire a TTL -> >> > RS232 level converter. There's pictures and howto on the OpenWRT wiki: >> > http://wiki.openwrt.org/toh/tp-link/tl-wr1043nd >> >> That sounds really nice! =A0Is there some guide on how to prepare an ima= ge? >> =A0I'm quite familiar with OpenWrt (patching and building) and have a nu= mber >> of routers (WRT-160N, WR941NL, 500gP) with serial adapters attached, but >> from the messages on the mips list, it felt the bootstrapping process mi= ght >> be a bit dauting... >> >> >> Stefan >> >> -- >> Stefan Bethke =A0 Fon +49 151 14070811 >> >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 03:22:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 448CE106566B for ; Wed, 15 Sep 2010 03:22:49 +0000 (UTC) (envelope-from adrian.chadd@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 0AD558FC21 for ; Wed, 15 Sep 2010 03:22:48 +0000 (UTC) Received: by iwn34 with SMTP id 34so7636872iwn.13 for ; Tue, 14 Sep 2010 20:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ULY21YYGA2AX1tKs5vqUCC1b0QgDKlDgMomsdlEe6WU=; b=W3Mkbfb+pbXujh855H62mlVKYTeJ5m+wSJ22/GyRhwUm7KPHaDEtv4ftGvUqqYHQ4P sY86L5rZEdOztjAWmAyTrAwiXg1NW5Suan7VBWg9iZfaoar4sXepX0k1eAFIDVoMLO6v BlIX0DeO3VHMQqcHjQXQ9GOaLvqi49gb5CHEo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Be+43vTrnnac1E38gcg0MeCYX1LR6HlknIJPvOb9aWS7OmwJA0ihkpzVcBOMrr4bl6 k1d8aVOeA6WnXCY4FgBQ7qCHp1bt7lRVLHXce3052b7tr9p3rGgn1CGF09sw2f5VptB3 9EZYRatViR02uftzzNzawoHXmxJ4nDy4gMecE= MIME-Version: 1.0 Received: by 10.231.11.69 with SMTP id s5mr1024934ibs.38.1284520968326; Tue, 14 Sep 2010 20:22:48 -0700 (PDT) Received: by 10.231.156.206 with HTTP; Tue, 14 Sep 2010 20:22:48 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Sep 2010 11:22:48 +0800 Message-ID: From: Adrian Chadd To: Stefan Bethke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 15 Sep 2010 04:51:08 +0000 Cc: freebsd-current Subject: Re: AR9132 CPU and AR9100 wireless support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 03:22:49 -0000 On 15 September 2010 04:24, Stefan Bethke wrote: > That sounds really nice! =A0Is there some guide on how to prepare an imag= e? =A0I'm quite familiar with OpenWrt (patching and building) and have a nu= mber of routers (WRT-160N, WR941NL, 500gP) with serial adapters attached, b= ut from the messages on the mips list, it felt the bootstrapping process mi= ght be a bit dauting... I'll go upload my cross-build scripts for -HEAD. It's actually really easy to cross-build a world/kernel install; you can then cherry pick binaries, libraries, etc to populate an MDROOT. (Or if you're interested, install onto a USB hard disk and run a "real" FreeBSD/mips live environment. :) The major failing atm is a complete lack of flash filesystem support. Well, the major major failing atm is "better" looking flash IO support to write/port a flash filesystem from. I "just" boot the kernel+mdroot from the onboard flash (and TFTP bootstrap things when testing.) Adrian From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 05:47:34 2010 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4E7C106566C for ; Wed, 15 Sep 2010 05:47:34 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 770078FC18 for ; Wed, 15 Sep 2010 05:47:34 +0000 (UTC) Received: by qwg5 with SMTP id 5so5384486qwg.13 for ; Tue, 14 Sep 2010 22:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=4IW/2JedTCThvaKB5/Bbf0EtTbrNoqd1iWbSPEfOYCw=; b=fl4P/nXLxDEfsqcd/92mB8mdw7FfAq1jpmw5d8mu2hOne2dp5CbZI9ljuQSMMUy+yY ghB/x8UokymFZ+FFBGzZZF6gC1J2QQsMfzuP15p12eY0ttWXzoCM4TfovQ5h+8I0BYNR rHgNuKwNfPCf1oPcgHx2zDLdjnlm5cIq0KmTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SUV0HHenU0Oah2LzJgfWoH1MxRX72mkA2URVKMyI98uYr/elTI40PBlxspRewrRddT P1LZsRnOkHfCTIPvih+Q84a5aqkJ3A4anW/XxbSWnTHhjkU1ussAe3m+GIRBHPyRc2Fz xnkfp2D3Gx93JWn9H2BiS1PT1zbnle4zcVJSc= MIME-Version: 1.0 Received: by 10.229.48.74 with SMTP id q10mr586789qcf.168.1284529653697; Tue, 14 Sep 2010 22:47:33 -0700 (PDT) Received: by 10.229.88.211 with HTTP; Tue, 14 Sep 2010 22:47:33 -0700 (PDT) Date: Wed, 15 Sep 2010 00:47:33 -0500 Message-ID: From: "Sam Fourman Jr." To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: pxe NFSroot and firefox 3.6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 05:47:34 -0000 Hello all I am running several FreeBSD 8/9 systems on a nfsroot, and it seems firefox 3.6.9 (sqllite rather) has issues accessing bookmarks, history and other things unless the /var/lib/nfs path exists. firefox 3.6.9 on NFSroot you must: mkdir -p /var/lib/nfs I found details here https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/237970 Since this simple fix works, and firefox is a popular port I was wondering how would we go about making this path exist by default? I dont know much about this, but if several ports need this path then maybe we could have the installworld script add mkdir -p /var/lib/nfs ? or perhaps just have the firefox port add the path? maybe there is yet another way to achieve this... the end goal here is to make this work by default the way it now does on ubuntu / debian comments welcome -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 06:49:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70AC910656A5 for ; Wed, 15 Sep 2010 06:49:05 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from mail.vnode.se (mail.vnode.se [62.119.52.80]) by mx1.freebsd.org (Postfix) with ESMTP id 286788FC1C for ; Wed, 15 Sep 2010 06:49:05 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id EF179E3F07B for ; Wed, 15 Sep 2010 08:32:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flq7pAVc5aCu for ; Wed, 15 Sep 2010 08:32:35 +0200 (CEST) Received: from pluto.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 4EE6FE3F079 for ; Wed, 15 Sep 2010 08:32:35 +0200 (CEST) Date: Wed, 15 Sep 2010 08:32:33 +0200 From: Joel Dahl To: freebsd-current@freebsd.org Message-ID: <20100915063233.GE1036@pluto.vnode.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Multiple hpet messages during boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 06:49:06 -0000 I noticed this during boot (HEAD from yesterday): hpet0: [FILTER] hpet0: [FILTER] hpet0: [FILTER] hpet0: [FILTER] hpet0: [FILTER] hpet0: [FILTER] hpet0: [FILTER] hpet0: [FILTER] Is it really necessary to print this 8 times? -- Joel From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 12:54:25 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FE83106566C; Wed, 15 Sep 2010 12:54:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 092408FC08; Wed, 15 Sep 2010 12:54:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o8FCsO8B063016; Wed, 15 Sep 2010 08:54:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o8FCsOd1063007; Wed, 15 Sep 2010 12:54:24 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 15 Sep 2010 12:54:24 GMT Message-Id: <201009151254.o8FCsOd1063007@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 12:54:25 -0000 TB --- 2010-09-15 12:07:44 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-15 12:07:44 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-09-15 12:07:44 - cleaning the object tree TB --- 2010-09-15 12:08:39 - cvsupping the source tree TB --- 2010-09-15 12:08:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-09-15 12:09:10 - building world TB --- 2010-09-15 12:09:10 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-15 12:09:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-15 12:09:10 - TARGET=powerpc TB --- 2010-09-15 12:09:10 - TARGET_ARCH=powerpc64 TB --- 2010-09-15 12:09:10 - TZ=UTC TB --- 2010-09-15 12:09:10 - __MAKE_CONF=/dev/null TB --- 2010-09-15 12:09:10 - cd /src TB --- 2010-09-15 12:09:10 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 15 12:09:12 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DSTREAMSPTY -DINET6 -I/src/libexec/telnetd/../../contrib/telnet -DAUTHENTICATION -DENCRYPTION -DKRB5 -DFORWARD -Dnet_write=telnet_net_write -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o telnetd global.o slc.o state.o sys_term.o telnetd.o termstat.o utility.o authenc.o -lutil -ltermcap /obj/powerpc.powerpc64/src/libexec/telnetd/../../lib/libtelnet/libtelnet.a -lmp -lcrypto -lcrypt -lpam -lkrb5 -lhx509 -lasn1 -lroken -lcom_err gzip -cn /src/libexec/telnetd/../../contrib/telnet/telnetd/telnetd.8 > telnetd.8.gz ===> libexec/tftpd (all) cc -O2 -pipe -I/src/libexec/tftpd/../../usr.bin/tftp -I/src/libexec/tftpd/../../libexec/tftpd -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/libexec/tftpd/tftpd.c cc -O2 -pipe -I/src/libexec/tftpd/../../usr.bin/tftp -I/src/libexec/tftpd/../../libexec/tftpd -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/libexec/tftpd/tftp-io.c cc1: warnings being treated as errors /src/libexec/tftpd/tftp-io.c: In function 'receive_packet': /src/libexec/tftpd/tftp-io.c:396: warning: variable 'pfrom' might be clobbered by 'longjmp' or 'vfork' *** Error code 1 Stop in /src/libexec/tftpd. *** Error code 1 Stop in /src/libexec. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-15 12:54:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-15 12:54:24 - ERROR: failed to build world TB --- 2010-09-15 12:54:24 - 1768.60 user 658.62 system 2799.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 13:03:28 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8946E1065670; Wed, 15 Sep 2010 13:03:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 436DB8FC0A; Wed, 15 Sep 2010 13:03:26 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o8FD3Q9E026761; Wed, 15 Sep 2010 09:03:26 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o8FD3QDP026756; Wed, 15 Sep 2010 13:03:26 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 15 Sep 2010 13:03:26 GMT Message-Id: <201009151303.o8FD3QDP026756@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 13:03:28 -0000 TB --- 2010-09-15 11:47:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-15 11:47:01 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-09-15 11:47:01 - cleaning the object tree TB --- 2010-09-15 11:47:51 - cvsupping the source tree TB --- 2010-09-15 11:47:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-09-15 11:48:34 - building world TB --- 2010-09-15 11:48:34 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-15 11:48:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-15 11:48:34 - TARGET=powerpc TB --- 2010-09-15 11:48:34 - TARGET_ARCH=powerpc TB --- 2010-09-15 11:48:34 - TZ=UTC TB --- 2010-09-15 11:48:34 - __MAKE_CONF=/dev/null TB --- 2010-09-15 11:48:34 - cd /src TB --- 2010-09-15 11:48:34 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 15 11:48:34 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DSTREAMSPTY -DINET6 -I/src/libexec/telnetd/../../contrib/telnet -DAUTHENTICATION -DENCRYPTION -DKRB5 -DFORWARD -Dnet_write=telnet_net_write -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o telnetd global.o slc.o state.o sys_term.o telnetd.o termstat.o utility.o authenc.o -lutil -ltermcap /obj/powerpc.powerpc/src/libexec/telnetd/../../lib/libtelnet/libtelnet.a -lmp -lcrypto -lcrypt -lpam -lkrb5 -lhx509 -lasn1 -lroken -lcom_err gzip -cn /src/libexec/telnetd/../../contrib/telnet/telnetd/telnetd.8 > telnetd.8.gz ===> libexec/tftpd (all) cc -O2 -pipe -I/src/libexec/tftpd/../../usr.bin/tftp -I/src/libexec/tftpd/../../libexec/tftpd -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/libexec/tftpd/tftpd.c cc -O2 -pipe -I/src/libexec/tftpd/../../usr.bin/tftp -I/src/libexec/tftpd/../../libexec/tftpd -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/libexec/tftpd/tftp-io.c cc1: warnings being treated as errors /src/libexec/tftpd/tftp-io.c: In function 'receive_packet': /src/libexec/tftpd/tftp-io.c:396: warning: variable 'pfrom' might be clobbered by 'longjmp' or 'vfork' *** Error code 1 Stop in /src/libexec/tftpd. *** Error code 1 Stop in /src/libexec. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-15 13:03:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-09-15 13:03:26 - ERROR: failed to build world TB --- 2010-09-15 13:03:26 - 3257.18 user 858.55 system 4584.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 13:13:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD4481065695 for ; Wed, 15 Sep 2010 13:13:33 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 978A68FC18 for ; Wed, 15 Sep 2010 13:13:33 +0000 (UTC) Received: by pzk7 with SMTP id 7so45754pzk.13 for ; Wed, 15 Sep 2010 06:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=JjOBbpe3o0t/FRjP0556CXU7rgmul3XLOaUtJyAWmdE=; b=Mph7YvWwdtusmZwXEzdqm5Xvwe3DwyVoUN+5YzWwfumaWpmF/28WU0D2693Sy+O74c hXYyr908TMbIQWsnDDFH6Rpw3cyhqFWOvTVq08r5wm2ivb3O/zpgF7fXRKD33knmEnXE yljG0eg6GiO3Lh8z3J6aDGMj0kUBASLaasA+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KpVylEUKq86cQt32qYmRebL+ZYluK8+XkBJ2sDTZTFXNesMh9jmW28QBKeDCncaLSC HUJc/J21/XDbPulhpQ+y8RY08m+ArEvkNuBvMjfZfHtgoKDxVROlD6LzlK+CdzEc+l7i IOoO2pp02v0p8epKAw7ncR5Npra6ZwE6UMfZw= MIME-Version: 1.0 Received: by 10.114.94.18 with SMTP id r18mr1622776wab.188.1284554685701; Wed, 15 Sep 2010 05:44:45 -0700 (PDT) Received: by 10.220.15.71 with HTTP; Wed, 15 Sep 2010 05:44:45 -0700 (PDT) Date: Wed, 15 Sep 2010 16:44:45 +0400 Message-ID: From: Dmitry Krivenok To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: buildworld + ccache trouble X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 13:13:33 -0000 Hello All! I recently updated to r212634 and tried to build CURRENT tree with ccache. I added /usr/local/libexec/ccache in my $PATH and added the following in /etc/make.conf: .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && !defined(NOCCACHE) CC=/usr/local/libexec/ccache/world-cc CXX=/usr/local/libexec/ccache/world-c++ .endif Then I set WITHOUT_BOOT = 'YES' DEBUG_FLAGS = '-g -O0' and run make buildworld buildkernel installkernel However, I got build error: ===> lib/csu/i386-elf (obj,depend,all,install) rm -f .depend CC='/usr/local/libexec/ccache/world-cc' mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S /usr/local/libexec/ccache/world-cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -g -O0 -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crti.S /usr/local/libexec/ccache/world-cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -g -O0 -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crtn.S /usr/local/libexec/ccache/world-cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -g -O0 -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -DGCRT -c -o gcrt1_c.o /usr/src/lib/csu/i386-elf/crt1_c.c /usr/local/libexec/ccache/world-cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -g -O0 -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crt1_s.S /usr/src/lib/csu/i386-elf/crt1_s.S: Assembler messages: /usr/src/lib/csu/i386-elf/crt1_s.S:36: Error: suffix or operands invalid for `push' /usr/src/lib/csu/i386-elf/crt1_s.S:39: Error: bad register expression /usr/src/lib/csu/i386-elf/crt1_s.S:40: Error: bad register expression /usr/src/lib/csu/i386-elf/crt1_s.S:42: Error: `8(%ebp)' is not a valid 64 bit base/index expression /usr/src/lib/csu/i386-elf/crt1_s.S:43: Error: suffix or operands invalid for `push' /usr/src/lib/csu/i386-elf/crt1_s.S:44: Error: `4(%ebp)' is not a valid 64 bit base/index expression /usr/src/lib/csu/i386-elf/crt1_s.S:45: Error: suffix or operands invalid for `push' *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Is it a know issue? Any solutions? Thanks in advance! P.S. Build works fine if I don't use ccache. -- Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 14:30:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBBD81065670; Wed, 15 Sep 2010 14:30:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E967E8FC13; Wed, 15 Sep 2010 14:30:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o8FEP7fb088627; Wed, 15 Sep 2010 08:25:07 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 15 Sep 2010 08:25:13 -0600 (MDT) Message-Id: <20100915.082513.802140508206832836.imp@bsdimp.com> To: demelier.david@gmail.com From: "M. Warner Losh" In-Reply-To: References: <20100910234830.87641e07.ray@ddteam.net> <4C8ACE52.8060000@FreeBSD.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: kimelto@gmail.com, ray@ddteam.net, dougb@freebsd.org, mj@feral.com, freebsd-current@freebsd.org Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 14:30:51 -0000 In message: David DEMELIER writes: : 2010/9/11 Doug Barton : : > On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote: : >> : >> Hi, : >> : >> another argument about hostapd :) if have access point we must have : >> way to assign IP for AP clients. : > : > To start with, your assumption is wrong. DHCPd is not *actually* a : > requirement, although I admit that practically it is. : > : >> Last spring I made firmware based on FreeBSD for router with only 4MB : >> NOR flash (D-Link DIR-320). : > : > In this category (micro-miniaturization) you're already in the "significant : > customization needed" area, which means that general arguments about "the : > base" don't apply. : > : >> Since this device is router I must be : >> able to serve DHCP. And current implementation of dhcpclient, that we : >> have, is same isc-dhcp, and I replace system dhcpclient with ports : >> one+dhcpd but with small patch that put basic dhcp utils onto : >> libdhcp.so. : > : > Your argument is creative and well thought out, but I personally don't find : > it persuasive. Counter arguments that come immediately to mind are: : > 1. The DHCP server is not going to benefit any but a small minority of : > FreeBSD users. : > 2. The software is already available in the ports tree, and adding a : > port/package of it really is not an overwhelming burden. : > : > More generally, the main reason I want to keep more stuff out of the base, : > and remove some of the stuff that's in there now, is that it makes : > maintenance difficult across FreeBSD branches. We have a general policy that : > if we have a major version N of something in a release branch that we don't : > upgrade that major version without a really good reason to avoid POLA : > surprises for our users. Once again using BIND as an example, this has led : > to a really old and past-EOL version of BIND in FreeBSD 6 which I've only : > gotten away with because anyone doing serious DNS work nowadays has to : > upgrade to at least 9.6 anyway. But it's an ugly situation, and I don't want : > to repeat it. : > : : I agree but like Aleksandr said, almost 70% of dhcp code is already in : base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea : to keep some parts in the ports tree and move out from the base. Yea. I agree too. Just because BIND was EOLd in 6 isn't a great argument against dhcp server. Most of the code is there anyway, and it isn't evolving as fast as BIND. It would be very convenient to have this particular thing in the base, and we shouldn't be too dogmatic about never having any new 3rd party things in the base. After all, we just added more compression utilities to the base, and nobody said a peep. This is analogous: we have good opportunity to integrate into the system, and users benefit from that integration. Warner From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 15:16:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AA1A106564A for ; Wed, 15 Sep 2010 15:16:38 +0000 (UTC) (envelope-from mkhitrov@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5F1588FC18 for ; Wed, 15 Sep 2010 15:16:38 +0000 (UTC) Received: by pxi17 with SMTP id 17so102770pxi.13 for ; Wed, 15 Sep 2010 08:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=HY2R5lb2huynMQAd1j9wCzBdaWPFnUU7HjyfwXb60Do=; b=heGg8bizLGygjdUZR56GHIp+EaWiL1BdrmCHEAJ3GE+zKZxE2NJm5JkL4NlZ2dvVIc Di7eu/2jNh/OqBD5OGifJG2kbRHY3bOjUKM8xn6yojPQ18oWEWw618zvpiq84Y76ZiFe SHTP9nGUgkRPh3mvNZ7fstm3sIg044TX3kNo4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=VPqxSwWCBCgDAelIkkTWUJ5xd2IrXZJQmPkSchxmQhkevQpjaymSRnYTQ8VrnRKdcd 7hTFtt9hbXhhm5KViL3rz8FvNI+vzDwGRjSNcolH537Kl2Nt+9ze1cUdiORfuCk/rsLw kvrxwdnJbKzmBlzd5XVrBFlYhgD/cj287ZprI= Received: by 10.142.245.13 with SMTP id s13mr1463859wfh.234.1284562400568; Wed, 15 Sep 2010 07:53:20 -0700 (PDT) MIME-Version: 1.0 Sender: mkhitrov@gmail.com Received: by 10.220.200.75 with HTTP; Wed, 15 Sep 2010 07:53:00 -0700 (PDT) In-Reply-To: References: From: Maxim Khitrov Date: Wed, 15 Sep 2010 10:53:00 -0400 X-Google-Sender-Auth: H9KELnplKoyVKZuE09xRhFFXmNg Message-ID: To: Dmitry Krivenok Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: buildworld + ccache trouble X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 15:16:38 -0000 On Wed, Sep 15, 2010 at 8:44 AM, Dmitry Krivenok wrote: > Hello All! > I recently updated to r212634 and tried to build CURRENT tree with ccache. > > However, I got build error: > > > > Stop in /usr/src/lib/csu/i386-elf. > *** Error code 1 > > Is it a know issue? > Any solutions? If I remember correctly, this happens when you try to build 32-bit library set on amd64 (you do not have WITHOUT_LIB32 set in /etc/src.conf). My solution was to disable 32-bit support by setting that option. If you're still using ccache version 2.4, try upgrading to 3.0.1, though I'm not sure if this problem has been fix. The only other alternative that I know of is to not use ccache to buildworld on amd64. - Max From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 15:20:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA673106564A; Wed, 15 Sep 2010 15:20:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 840EF8FC0C; Wed, 15 Sep 2010 15:20:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id D6B4941C7AD; Wed, 15 Sep 2010 17:20:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id aRXBqrc5MKsX; Wed, 15 Sep 2010 17:20:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 5B12441C76D; Wed, 15 Sep 2010 17:20:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id B40CE4448F3; Wed, 15 Sep 2010 15:19:50 +0000 (UTC) Date: Wed, 15 Sep 2010 15:19:50 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Andre Oppermann In-Reply-To: <4C8E0C1E.2020707@networx.ch> Message-ID: <20100915151632.E31898@maildrop.int.zabbadoz.net> References: <4C8E0C1E.2020707@networx.ch> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: TCP loopback socket fusing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 15:20:06 -0000 On Mon, 13 Sep 2010, Andre Oppermann wrote: Hey, > When a TCP connection via loopback back to localhost is made the whole > send, segmentation and receive path (with larger packets though) is still > executed. This has some considerable overhead. > > To short-circuit the send and receive sockets on localhost TCP connections > I've made a proof-of-concept patch that directly places the data in the > other side's socket buffer without doing any packetization and other protocol > overhead (like UNIX domain sockets). The connections setup (SYN, SYN-ACK, > ACK) and shutdown are still handled by normal TCP segments via loopback so > that firewalling stills works. The actual payload data during the session > won't be seen and the sequence numbers don't move other than for SYN and FIN. > The sequence are remain valid though. Obviously tcpdump won't see any data > transfers either if the connection has fused sockets. > > Preliminary testing (with WITNESS and INVARIANTS enabled) has shown stable > operation and a rough doubling of the throughput on loopback connections. > I've tested most socket teardown cases and it behaves fine. I'm not entirely > sure I've got all possible path's but the way it is integrated should > properly > defuse the sockets in all situations. Three comments in reverse order: 1 If S/S+A/A and shutdown aren't shortcut, can you always rely on proper payload order, especially in the shutdown case? 2 Given my experience with epairs, which are basically a loop with two interfaces and even interface queues, any significant delay you are seeing is _not_ due to longer code paths through the stack but simply because of the netisr. 3 If properly doing this for TCP, we should probably also do it for other protocols. /bz -- Bjoern A. Zeeb Welcome a new stage of life. From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 15:23:55 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9663106564A; Wed, 15 Sep 2010 15:23:55 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id A88648FC17; Wed, 15 Sep 2010 15:23:55 +0000 (UTC) Received: from ncsc.bris.ac.uk ([137.222.10.41]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1Ovtpy-0003HU-Ac; Wed, 15 Sep 2010 16:23:54 +0100 Received: from mech-anton240.men.bris.ac.uk ([137.222.187.240]) by ncsc.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ovtpy-0003XO-6i; Wed, 15 Sep 2010 16:23:54 +0100 Received: from mech-anton240.men.bris.ac.uk (localhost [127.0.0.1]) by mech-anton240.men.bris.ac.uk (8.14.4/8.14.4) with ESMTP id o8FFNrKN045651; Wed, 15 Sep 2010 16:23:53 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-anton240.men.bris.ac.uk (8.14.4/8.14.4/Submit) id o8FFNrWA045650; Wed, 15 Sep 2010 16:23:53 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-anton240.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Wed, 15 Sep 2010 16:23:53 +0100 From: Anton Shterenlikht To: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Message-ID: <20100915152353.GA45611@mech-anton240.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: multiple problems between r212316 and r212643 on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 15:23:56 -0000 I just rebuilt world and kernel from r212316 to r212643 on ia64. man(1) doesn't work, I get: % man ls zcat: /usr/share/man/cat1/ls.1.gz already has .gz suffix -- unchanged % man man zcat: /usr/share/man/cat1/man.1.gz already has .gz suffix -- unchanged and so on for any command. sendmail doesn't work: # cd /etc/mail # make start Starting: sendmail-submitmailwrapper: no mapping in /etc/mail/mailer.conf sendmail-clientmqueuemailwrapper: no mapping in /etc/mail/mailer.conf . # Rebooting with 212316 kernel doesn't change anything. I cannot roll back to another revision because svn doesn't work: # cd /usr/src # svn up svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byte sequence # I can build svn, but trying to install it, I get: *skip* /usr/bin/install -c -o root -g wheel -d /usr/local/share/locale/zh_TW/LC_MESSAGES cd subversion/po ; /usr/bin/install -c -o root -g wheel -m 644 zh_TW.mo /usr/local/share/locale/zh_TW/LC_MESSAGES/subversion.mo subversion/svnversion/svnversion . /repos/svn/trunk > /usr/local/include/subversion-1/svn-revision.txt svn: Can't open file '.svn/entries': Illegal byte sequence *** Error code 1 Stop in /usr/ports/devel/subversion-freebsd/work/subversion-1.6.12. *** Error code 1 In addition I get this in /var/log/messages: init: getty repeating too quickly on port /dev/ttyv8, sleeping 30 secs ntpd[976]: select() error: Resource temporarily unavailable last message repeated 29 times Please advise many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 16:14:39 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4246F1065672 for ; Wed, 15 Sep 2010 16:14:39 +0000 (UTC) (envelope-from gljennjohn@googlemail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id BF6978FC1D for ; Wed, 15 Sep 2010 16:14:38 +0000 (UTC) Received: by bwz15 with SMTP id 15so836838bwz.13 for ; Wed, 15 Sep 2010 09:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=cx9Hl1OShTSbuxmVoRQ8jDbY7VUdNE4vou7sn97CHqI=; b=cpaxnw8zog9uD/y2KumIDtfM//QAiV7cQdSlZIEuy6Bd6XtwrOs6TBIIygF+/tZily NUQQUpGfTOrt0lUyFX9YL8tSadVi3bnA/qtIPy4lPSts2cGju30PBNLWWMcyWOU/dxi9 xE8jEf9Bsmta3cS+6bZ/bik1XcMQjdMZIcwyU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=CgaGcwnuCDCIabXnvFPqEShfATcdJzF0C7rmQYgQW3k7/RvxDYnIsP1qJpmYWX0KkX 8Ih7Y+5ZzFlW+k5iUzP4okdhChdEPXYOPJt14PE+LZKAoz6/uOPb+L+jq+vda6Ld2BS/ d/aa6SBOwM3Us4DPA8OdZBbkH0kfSWpRiYkvI= Received: by 10.204.77.212 with SMTP id h20mr1498998bkk.33.1284567274487; Wed, 15 Sep 2010 09:14:34 -0700 (PDT) Received: from ernst.jennejohn.org (p578E15EB.dip.t-dialin.net [87.142.21.235]) by mx.google.com with ESMTPS id d27sm1494439bku.22.2010.09.15.09.14.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Sep 2010 09:14:33 -0700 (PDT) Date: Wed, 15 Sep 2010 18:14:31 +0200 From: Gary Jennejohn To: Andre Oppermann Message-ID: <20100915181431.30677523@ernst.jennejohn.org> In-Reply-To: <20100915151632.E31898@maildrop.int.zabbadoz.net> References: <4C8E0C1E.2020707@networx.ch> <20100915151632.E31898@maildrop.int.zabbadoz.net> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: TCP loopback socket fusing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gljennjohn@googlemail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 16:14:39 -0000 On Mon, 13 Sep 2010, Andre Oppermann wrote: > Preliminary testing (with WITNESS and INVARIANTS enabled) has shown stable > operation and a rough doubling of the throughput on loopback connections. > I've tested most socket teardown cases and it behaves fine. I'm not entirely > sure I've got all possible path's but the way it is integrated should > properly defuse the sockets in all situations. > I tried this out with the following results: a) booted the new kernel, started X, started firefox -> hard hang, had to reset the box to recover. Note that firefox uses wwwoffle as a local, caching proxy and wwwwoffle is accessed through localhost:8080 b) tried (a) again to make sure it wasn't a fluke -> same result c) booted anew but started opera instead, which does _not_ use wwwoffle as its proxy (net.inet.tcp.loopfuse=1) -> OK d) I then set net.inet.tcp.loopfuse=0 before starting firefox -> OK e) set net.inet.tcp.loopfuse=1 and ran cvsup to update my CVS tree followed by checking out the changed sources, which uses loopback to talk to cvsupd -> OK So, somewhow trying to access wwwoffle through localhost:8080 causes a hard hang of the box. Whether this has something to do with the port number or just strange behavior on the part of wwwoffle I can't say, because the hard hang makes debugging impossible. By hard hang I mean that there is no visible activity, gkrellm isn't updating, mouse and keyboard are ignored and ping from a different machine shows no reaction, so I'd say the kernel is pretty much wedged. For now I'm setting net.inet.tcp.loopfuse=0 in /etc/sysctl.conf. -- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 15:48:08 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3E06106564A for ; Wed, 15 Sep 2010 15:48:07 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 555BE8FC14 for ; Wed, 15 Sep 2010 15:48:06 +0000 (UTC) Received: (qmail 72458 invoked from network); 15 Sep 2010 15:42:53 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 15 Sep 2010 15:42:53 -0000 Message-ID: <4C90EAB7.2000902@networx.ch> Date: Wed, 15 Sep 2010 17:48:07 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4C8E0C1E.2020707@networx.ch> <20100915151632.E31898@maildrop.int.zabbadoz.net> In-Reply-To: <20100915151632.E31898@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 15 Sep 2010 17:08:05 +0000 Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: TCP loopback socket fusing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 15:48:08 -0000 On 15.09.2010 17:19, Bjoern A. Zeeb wrote: > On Mon, 13 Sep 2010, Andre Oppermann wrote: > > Hey, > >> When a TCP connection via loopback back to localhost is made the whole >> send, segmentation and receive path (with larger packets though) is still >> executed. This has some considerable overhead. >> >> To short-circuit the send and receive sockets on localhost TCP connections >> I've made a proof-of-concept patch that directly places the data in the >> other side's socket buffer without doing any packetization and other protocol >> overhead (like UNIX domain sockets). The connections setup (SYN, SYN-ACK, >> ACK) and shutdown are still handled by normal TCP segments via loopback so >> that firewalling stills works. The actual payload data during the session >> won't be seen and the sequence numbers don't move other than for SYN and FIN. >> The sequence are remain valid though. Obviously tcpdump won't see any data >> transfers either if the connection has fused sockets. >> >> Preliminary testing (with WITNESS and INVARIANTS enabled) has shown stable >> operation and a rough doubling of the throughput on loopback connections. >> I've tested most socket teardown cases and it behaves fine. I'm not entirely >> sure I've got all possible path's but the way it is integrated should properly >> defuse the sockets in all situations. > > Three comments in reverse order: > > 1 If S/S+A/A and shutdown aren't shortcut, can you always rely on proper > payload order, especially in the shutdown case? Yes. The payload is always directly placed in the receive socket buffer of the other socket, never in the send buffer. There is never any unsent data left in the send buffer that could become reordered. > 2 Given my experience with epairs, which are basically a loop with two > interfaces and even interface queues, any significant delay you are > seeing is _not_ due to longer code paths through the stack but > simply because of the netisr. I haven't measured delay, only bandwidth. And that's with WITNESS and INVARIANTS enabled. You are probably right, the netisr is taking its toll. Especially the TCP_INFO lock may have some contention in the loopback case on SMP. Though a lot of mbuf allocations, packet manipulations and instructions (instruction cache) are avoided by fusing the sockets together. > 3 If properly doing this for TCP, we should probably also do it for > other protocols. UNIX domain sockets already do this. This implementation is particular for TCP and only touches the protocol specific parts. It's not done at the socket layer. For UDP it's not that easy to do as most UDP connections are one-off packets and no permanent binding between two sockets exists. For SCTP I don't know. From glancing over the code it seems they have, at least partially, their own socket buffer code. How difficult a fused socket there would be I can't say. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 17:40:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA22710656A6 for ; Wed, 15 Sep 2010 17:40:29 +0000 (UTC) (envelope-from jasonjwwilliams@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 570ED8FC0A for ; Wed, 15 Sep 2010 17:40:28 +0000 (UTC) Received: by wyb33 with SMTP id 33so602596wyb.13 for ; Wed, 15 Sep 2010 10:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=/THp5FVA9AT//2WphH6uOrKNUN9Vt3ZuTJtOdyph+vo=; b=FdEfJGqdz+7qLe0B2NzHN3uWx37xI0ATc8Plf2ybhuNK6hoBEhHDQAZn+Nf/mPmh7j TWrmFbdpP9h1pISIQ90M3a+V0/g4wQi7bAQ++RQIx1lPkIoY2dX4eHAW6HBdz8UcERAt bkZVGkAKOtB+rB9pqAHfTBwVzrv9SA1vEc2Xg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=OyD0nn0dfQRWdyvqnIZS4ryzTh6V0ULCrjFEdTRqYrc4SbeJG6wVtmVnHNglGEme01 1nwpRwQuvI0oX+57610FKi2cSW7c1LcrDM8AFlAqOhT3Qe0o1Uy2jt68mSaBBUM2BbKr h+EUJvFVjed9vs5V7Hj1Vtqbgn7d2euVxxpiQ= MIME-Version: 1.0 Received: by 10.227.156.202 with SMTP id y10mr1677320wbw.48.1284572428236; Wed, 15 Sep 2010 10:40:28 -0700 (PDT) Received: by 10.216.168.199 with HTTP; Wed, 15 Sep 2010 10:40:28 -0700 (PDT) Date: Wed, 15 Sep 2010 11:40:28 -0600 Message-ID: From: "Jason J. W. Williams" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ZFS Test Suite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 17:40:29 -0000 Does the FreeBSD ZFS port get tested against the ZFS test suite created by Sun? It's a fairly comprehensive suite and has delivered a very reliable set of ZFS beta code for a long time. Trying to gauge the stability and compatibility of the FreeBSD port. Thank you in advance. -J From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 18:27:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FB8C106564A for ; Wed, 15 Sep 2010 18:27:27 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 49BCD8FC16 for ; Wed, 15 Sep 2010 18:27:27 +0000 (UTC) Received: (qmail 13798 invoked by uid 399); 15 Sep 2010 18:27:26 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 15 Sep 2010 18:27:26 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C91100C.5060502@FreeBSD.org> Date: Wed, 15 Sep 2010 11:27:24 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: "M. Warner Losh" References: <20100910234830.87641e07.ray@ddteam.net> <4C8ACE52.8060000@FreeBSD.org> <20100915.082513.802140508206832836.imp@bsdimp.com> In-Reply-To: <20100915.082513.802140508206832836.imp@bsdimp.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 18:27:27 -0000 On 9/15/2010 7:25 AM, M. Warner Losh wrote: > Yea. I agree too. Just because BIND was EOLd in 6 isn't a great > argument against dhcp server. That rather clearly was not the only element of my argument, and not only is it disingenuous for you to indicate that it was, I don't appreciate you doing so. > Most of the code is there anyway, and it isn't evolving as fast as BIND. That is actually a more rational argument, even if I don't agree with it. FWIW, part of the reason that I don't agree with it is that at some point, hopefully in the near future, we will want to include the DHCPv6 client in the mix somewhere; and when we do the code base is not going to be as stable as we have enjoyed so far with the v4 dhclient. > It would be very convenient to have this particular thing in the base, > and we shouldn't be too dogmatic about never having any new 3rd party > things in the base. After all, we just added more compression > utilities to the base, and nobody said a peep. I actually thought that change was rather silly, but it was clear that there was so much critical mass in favor of it that there was no point in stating a dissenting opinion. As part of the project's leadership you should be careful not to mistake silence for agreement, or worse, support. > This is analogous: we > have good opportunity to integrate into the system, and users benefit > from that integration. Given your perspective of wanting more of a complete system in the base I can certainly see how you would be supportive of this change. My intent was to make the argument in a general way that this is the wrong direction to go, and that users would benefit *more* from a robust modularized system. The fact that the v4 DHCPd might accidentally be a good candidate for including in the base today doesn't mean that doing so is the right strategy for the long term. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 18:36:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A62E51065679 for ; Wed, 15 Sep 2010 18:36:27 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 301B88FC1A for ; Wed, 15 Sep 2010 18:36:26 +0000 (UTC) Received: by bwz15 with SMTP id 15so1010770bwz.13 for ; Wed, 15 Sep 2010 11:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=4f2BsH32u/Tn8tEce1B65THDaH3Oxj+nBuz4HDCycCc=; b=FKNJc13BOugTS8yeuNjyOv9Ed7DKLhCW5RvEBAIRbQS8uDJ+oX933wBIuDc/x1rX17 odZ+pIO2kdy70vCl/lmpQuJ0sA/upSHFFBMP6wwM3yQhQQBtunAPWE0WhBDSt/54Ymxh PudxNw77SxUpn3UhyxHEu0SXucygF3ZcTCYWk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ZLMLUQuRGGyaMEMlW9R/pCZ+MvC+YnY8ME/0UzdPnE6KpEudWWQwbV1aK0X94V9UaN VfHuEVuugBADhXAlLJRryp0RkSBtEMRl/o+QjLIIvIg89dVy1nQ3LEQkVHAiXDHZXryn urgLLVECnkwggvVtl/JhNWA8CfeosLNoAeUhk= Received: by 10.204.119.134 with SMTP id z6mr1376627bkq.193.1284575786226; Wed, 15 Sep 2010 11:36:26 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id f18sm1615172bkf.15.2010.09.15.11.36.24 (version=SSLv3 cipher=RC4-MD5); Wed, 15 Sep 2010 11:36:25 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C911214.7060406@FreeBSD.org> Date: Wed, 15 Sep 2010 21:36:04 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: FreeBSD-Current References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Multiple hpet messages during boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 18:36:27 -0000 Joel Dahl wrote: > I noticed this during boot (HEAD from yesterday): > > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > > Is it really necessary to print this 8 times? HPET at present chipsets may use up to 8 IRQs. Driver registers filter interrupt handlers for them. Interrupt handling code prints this. If you boot with verbose, you may see that some network cards prints alike things for the number of supported MSI/MSI-X interrupts. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 18:37:08 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE8321065694 for ; Wed, 15 Sep 2010 18:37:08 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from eu1sys200aog118.obsmtp.com (eu1sys200aog118.obsmtp.com [207.126.144.145]) by mx1.freebsd.org (Postfix) with SMTP id 6EF038FC0C for ; Wed, 15 Sep 2010 18:37:06 +0000 (UTC) Received: from source ([63.174.175.251]) by eu1sys200aob118.postini.com ([207.126.147.11]) with SMTP ID DSNKTJESUTDOhO0NTB26mGjKqVMyYJrtroeM@postini.com; Wed, 15 Sep 2010 18:37:08 UTC Received: from [172.17.10.53] (unknown [172.17.10.53]) by bbbx3.usdmm.com (Postfix) with ESMTP id 738D1FD01F; Wed, 15 Sep 2010 18:37:04 +0000 (UTC) Message-ID: <4C911247.7010309@tomjudge.com> Date: Wed, 15 Sep 2010 13:36:55 -0500 From: Tom Judge User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100826 Lightning/1.0b1 Thunderbird/3.0.7 MIME-Version: 1.0 To: Maxim Khitrov References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Dmitry Krivenok Subject: Re: buildworld + ccache trouble X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 18:37:09 -0000 On 09/15/2010 09:53 AM, Maxim Khitrov wrote: > On Wed, Sep 15, 2010 at 8:44 AM, Dmitry Krivenok > wrote: > >> Hello All! >> I recently updated to r212634 and tried to build CURRENT tree with ccache. >> >> However, I got build error: >> >> >> >> Stop in /usr/src/lib/csu/i386-elf. >> *** Error code 1 >> >> Is it a know issue? >> Any solutions? >> > If I remember correctly, this happens when you try to build 32-bit > library set on amd64 (you do not have WITHOUT_LIB32 set in > /etc/src.conf). > > My solution was to disable 32-bit support by setting that option. If > you're still using ccache version 2.4, try upgrading to 3.0.1, though > I'm not sure if this problem has been fix. The only other alternative > that I know of is to not use ccache to buildworld on amd64. > In the past I have used the solution outlined here: http://www.tomjudge.com/index.php/FreeBSD/Creating_a_%28i386/ia32%29_build_cluster_using_amd64_and_i386_hosts This used to (in the 6.2 days) allow us to build i386 objects on amd64 hosts. It may work for you. Tom -- TJU13-ARIN From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 19:47:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 281FE1065673 for ; Wed, 15 Sep 2010 19:47:04 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1E3358FC15 for ; Wed, 15 Sep 2010 19:47:02 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA15627; Wed, 15 Sep 2010 22:47:01 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ovxwb-00016F-7p; Wed, 15 Sep 2010 22:47:01 +0300 Message-ID: <4C9122B4.2040202@icyb.net.ua> Date: Wed, 15 Sep 2010 22:47:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100912 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Alexander Best , freebsd-current@freebsd.org References: <20100914005946.GA7417@freebsd.org> In-Reply-To: <20100914005946.GA7417@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: regarding pciids X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 19:47:04 -0000 on 14/09/2010 03:59 Alexander Best said the following: > hi there, > > any thoughts on using http://pciids.sourceforge.net/ for pciids instead of the > Hart and Boemler lists. the SF site seems to be updated more regularly and > would get rid of the need to decide for each entry, whether to take the Hart or > Boemler one. +1 FWIW Especially given that the format is what we use too (modulo subvendor, sub-etc) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 20:14:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F078F1065672 for ; Wed, 15 Sep 2010 20:14:31 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id AE99A8FC16 for ; Wed, 15 Sep 2010 20:14:31 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:1434:5729:6089:14c9] (unknown [IPv6:2001:7b8:3a7:0:1434:5729:6089:14c9]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id ECD935C43; Wed, 15 Sep 2010 22:14:29 +0200 (CEST) Message-ID: <4C912926.6070409@FreeBSD.org> Date: Wed, 15 Sep 2010 22:14:30 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.10pre) Gecko/20100910 Lanikai/3.1.4pre MIME-Version: 1.0 To: Dmitry Krivenok References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------090405020008000200050202" Cc: freebsd-current@freebsd.org Subject: Re: buildworld + ccache trouble X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 20:14:32 -0000 This is a multi-part message in MIME format. --------------090405020008000200050202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2010-09-15 14:44, Dmitry Krivenok wrote: > I recently updated to r212634 and tried to build CURRENT tree with ccache. ... > /usr/src/lib/csu/i386-elf/crt1_s.S:42: Error: `8(%ebp)' is not a valid > 64 bit base/index expression I assume this error occurs when building the 32-bit components on amd64. If so, can you please try the attached patch? It should fix the build32 stage with a non-default ${CC} setting. This also applies to building with clang, for instance. --------------090405020008000200050202 Content-Type: text/plain; name="fix-build32-with-nonstandard-cc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fix-build32-with-nonstandard-cc.diff" diff --git a/Makefile.inc1 b/Makefile.inc1 index a08e4ca..66d074f 100644 --- a/Makefile.inc1 +++ b/Makefile.inc1 @@ -299,15 +299,15 @@ LIB32WMAKEENV+= MAKEOBJDIRPREFIX=${OBJTREE}/lib32 \ VERSION="${VERSION}" \ INSTALL="sh ${.CURDIR}/tools/install.sh" \ PATH=${TMPPATH} \ - CC="${CC} ${LIB32FLAGS}" \ - CXX="${CXX} ${LIB32FLAGS}" \ - OBJC="${OBJC} ${LIB32FLAGS}" \ LIBDIR=/usr/lib32 \ SHLIBDIR=/usr/lib32 LIB32WMAKE= ${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32BIT \ -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \ - -DWITHOUT_HTML -DNO_CTF DESTDIR=${LIB32TMP} + -DWITHOUT_HTML -DNO_CTF DESTDIR=${LIB32TMP} \ + CC="${CC} ${LIB32FLAGS}" \ + CXX="${CXX} ${LIB32FLAGS}" \ + OBJC="${OBJC} ${LIB32FLAGS}" LIB32IMAKE= ${LIB32WMAKE:NINSTALL=*:NDESTDIR=*} -DNO_INCS .endif --------------090405020008000200050202-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 21:49:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 308C7106564A for ; Wed, 15 Sep 2010 21:49:50 +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 DC4678FC0A for ; Wed, 15 Sep 2010 21:49: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 5DCC246C16; Wed, 15 Sep 2010 17:49:49 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5EDEB8A050; Wed, 15 Sep 2010 17:49:48 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 15 Sep 2010 17:49:44 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009151749.45038.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 15 Sep 2010 17:49:48 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Marcin Cieslak Subject: Re: tun(4) in -CURRENT: No buffer space available - race condition patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 21:49:50 -0000 On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote: > Output queue of tun(4) gets full after some time when sending lots of data. > I have been observing this on -CURRENT at least since March this year. > > Looks like it's a race condition (same in tun(4) and tap(4)), > the following patch seems to address the issue: This is a good find. I actually went through these drivers a bit further and have a bit of a larger patch to extend the locking some. Would you care to test it? Index: if_tap.c =================================================================== --- if_tap.c (revision 212557) +++ if_tap.c (working copy) @@ -209,7 +209,6 @@ tap_destroy(struct tap_softc *tp) { struct ifnet *ifp = tp->tap_ifp; - int s; /* Unlocked read. */ KASSERT(!(tp->tap_flags & TAP_OPEN), @@ -217,10 +216,8 @@ knlist_destroy(&tp->tap_rsel.si_note); destroy_dev(tp->tap_dev); - s = splimp(); ether_ifdetach(ifp); if_free_type(ifp, IFT_ETHER); - splx(s); mtx_destroy(&tp->tap_mtx); free(tp, M_TAP); @@ -398,7 +395,7 @@ struct tap_softc *tp = NULL; unsigned short macaddr_hi; uint32_t macaddr_mid; - int unit, s; + int unit; char *name = NULL; u_char eaddr[6]; @@ -449,15 +446,13 @@ dev->si_drv1 = tp; tp->tap_dev = dev; - s = splimp(); ether_ifattach(ifp, eaddr); - splx(s); mtx_lock(&tp->tap_mtx); tp->tap_flags |= TAP_INITED; mtx_unlock(&tp->tap_mtx); - knlist_init_mtx(&tp->tap_rsel.si_note, NULL); + knlist_init_mtx(&tp->tap_rsel.si_note, &tp->tap_mtx); TAPDEBUG("interface %s is created. minor = %#x\n", ifp->if_xname, dev2unit(dev)); @@ -474,7 +469,7 @@ { struct tap_softc *tp = NULL; struct ifnet *ifp = NULL; - int error, s; + int error; if (tapuopen == 0) { error = priv_check(td, PRIV_NET_TAP); @@ -497,15 +492,13 @@ tp->tap_pid = td->td_proc->p_pid; tp->tap_flags |= TAP_OPEN; ifp = tp->tap_ifp; - mtx_unlock(&tp->tap_mtx); - s = splimp(); ifp->if_drv_flags |= IFF_DRV_RUNNING; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; if (tapuponopen) ifp->if_flags |= IFF_UP; + mtx_unlock(&tp->tap_mtx); if_link_state_change(ifp, LINK_STATE_UP); - splx(s); TAPDEBUG("%s is open. minor = %#x\n", ifp->if_xname, dev2unit(dev)); @@ -524,7 +517,6 @@ struct ifaddr *ifa; struct tap_softc *tp = dev->si_drv1; struct ifnet *ifp = tp->tap_ifp; - int s; /* junk all pending output */ IF_DRAIN(&ifp->if_snd); @@ -537,25 +529,24 @@ mtx_lock(&tp->tap_mtx); if (((tp->tap_flags & TAP_VMNET) == 0) && (ifp->if_flags & IFF_UP)) { mtx_unlock(&tp->tap_mtx); - s = splimp(); if_down(ifp); + mtx_lock(&tp->tap_mtx); if (ifp->if_drv_flags & IFF_DRV_RUNNING) { + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; + mtx_unlock(&tp->tap_mtx); TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { rtinit(ifa, (int)RTM_DELETE, 0); } if_purgeaddrs(ifp); - ifp->if_drv_flags &= ~IFF_DRV_RUNNING; + mtx_lock(&tp->tap_mtx); } - splx(s); - } else - mtx_unlock(&tp->tap_mtx); + } if_link_state_change(ifp, LINK_STATE_DOWN); funsetown(&tp->tap_sigio); selwakeuppri(&tp->tap_rsel, PZERO+1); - KNOTE_UNLOCKED(&tp->tap_rsel.si_note, 0); + KNOTE_LOCKED(&tp->tap_rsel.si_note, 0); - mtx_lock(&tp->tap_mtx); tp->tap_flags &= ~TAP_OPEN; tp->tap_pid = 0; mtx_unlock(&tp->tap_mtx); @@ -580,8 +571,10 @@ TAPDEBUG("initializing %s\n", ifp->if_xname); + mtx_lock(&tp->tap_mtx); ifp->if_drv_flags |= IFF_DRV_RUNNING; ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; + mtx_unlock(&tp->tap_mtx); /* attempt to start output */ tapifstart(ifp); @@ -599,7 +592,7 @@ struct tap_softc *tp = ifp->if_softc; struct ifreq *ifr = (struct ifreq *)data; struct ifstat *ifs = NULL; - int s, dummy; + int dummy; switch (cmd) { case SIOCSIFFLAGS: /* XXX -- just like vmnet does */ @@ -612,7 +605,6 @@ break; case SIOCGIFSTATUS: - s = splimp(); ifs = (struct ifstat *)data; dummy = strlen(ifs->ascii); mtx_lock(&tp->tap_mtx); @@ -621,14 +613,10 @@ sizeof(ifs->ascii) - dummy, "\tOpened by PID %d\n", tp->tap_pid); mtx_unlock(&tp->tap_mtx); - splx(s); break; default: - s = splimp(); - dummy = ether_ioctl(ifp, cmd, data); - splx(s); - return (dummy); + return (ether_ioctl(ifp, cmd, data)); /* NOT REACHED */ } @@ -645,7 +633,6 @@ tapifstart(struct ifnet *ifp) { struct tap_softc *tp = ifp->if_softc; - int s; TAPDEBUG("%s starting\n", ifp->if_xname); @@ -665,24 +652,19 @@ TAPDEBUG("%s not ready, tap_flags = 0x%x\n", ifp->if_xname, tp->tap_flags); - s = splimp(); do { IF_DEQUEUE(&ifp->if_snd, m); if (m != NULL) m_freem(m); ifp->if_oerrors ++; } while (m != NULL); - splx(s); return; } - mtx_unlock(&tp->tap_mtx); - s = splimp(); ifp->if_drv_flags |= IFF_DRV_OACTIVE; - if (ifp->if_snd.ifq_len != 0) { - mtx_lock(&tp->tap_mtx); + if (!IFQ_IS_EMPTY(&ifp->if_snd)) { if (tp->tap_flags & TAP_RWAIT) { tp->tap_flags &= ~TAP_RWAIT; wakeup(tp); @@ -691,16 +673,16 @@ if ((tp->tap_flags & TAP_ASYNC) && (tp->tap_sigio != NULL)) { mtx_unlock(&tp->tap_mtx); pgsigio(&tp->tap_sigio, SIGIO, 0); - } else - mtx_unlock(&tp->tap_mtx); + mtx_lock(&tp->tap_mtx); + } selwakeuppri(&tp->tap_rsel, PZERO+1); - KNOTE_UNLOCKED(&tp->tap_rsel.si_note, 0); + KNOTE_LOCKED(&tp->tap_rsel.si_note, 0); ifp->if_opackets ++; /* obytes are counted in ether_output */ } ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; - splx(s); + mtx_unlock(&tp->tap_mtx); } /* tapifstart */ @@ -715,7 +697,6 @@ struct tap_softc *tp = dev->si_drv1; struct ifnet *ifp = tp->tap_ifp; struct tapinfo *tapp = NULL; - int s; int f; #if defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD5) || \ defined(COMPAT_FREEBSD4) @@ -724,12 +705,10 @@ switch (cmd) { case TAPSIFINFO: - s = splimp(); tapp = (struct tapinfo *)data; ifp->if_mtu = tapp->mtu; ifp->if_type = tapp->type; ifp->if_baudrate = tapp->baudrate; - splx(s); break; case TAPGIFINFO: @@ -757,26 +736,26 @@ break; case FIOASYNC: - s = splimp(); mtx_lock(&tp->tap_mtx); if (*(int *)data) tp->tap_flags |= TAP_ASYNC; else tp->tap_flags &= ~TAP_ASYNC; mtx_unlock(&tp->tap_mtx); - splx(s); break; case FIONREAD: - s = splimp(); - if (ifp->if_snd.ifq_head) { - struct mbuf *mb = ifp->if_snd.ifq_head; + if (!IFQ_IS_EMPTY(&ifp->if_snd)) { + struct mbuf *mb; - for(*(int *)data = 0;mb != NULL;mb = mb->m_next) + IFQ_LOCK(&ifp->if_snd); + IFQ_POLL_NOLOCK(&ifp->if_snd, mb); + for (*(int *)data = 0; mb != NULL; + mb = mb->m_next) *(int *)data += mb->m_len; + IFQ_UNLOCK(&ifp->if_snd); } else *(int *)data = 0; - splx(s); break; case FIOSETOWN: @@ -797,10 +776,6 @@ /* VMware/VMnet port ioctl's */ - case SIOCGIFFLAGS: /* get ifnet flags */ - bcopy(&ifp->if_flags, data, sizeof(ifp->if_flags)); - break; - #if defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD5) || \ defined(COMPAT_FREEBSD4) case _IO('V', 0): @@ -814,9 +789,9 @@ f &= ~IFF_CANTCHANGE; f |= IFF_UP; - s = splimp(); + mtx_lock(&tp->tap_mtx); ifp->if_flags = f | (ifp->if_flags & IFF_CANTCHANGE); - splx(s); + mtx_unlock(&tp->tap_mtx); break; case OSIOCGIFADDR: /* get MAC address of the remote side */ @@ -851,7 +826,7 @@ struct tap_softc *tp = dev->si_drv1; struct ifnet *ifp = tp->tap_ifp; struct mbuf *m = NULL; - int error = 0, len, s; + int error = 0, len; TAPDEBUG("%s reading, minor = %#x\n", ifp->if_xname, dev2unit(dev)); @@ -867,26 +842,27 @@ } tp->tap_flags &= ~TAP_RWAIT; - mtx_unlock(&tp->tap_mtx); /* sleep until we get a packet */ do { - s = splimp(); IF_DEQUEUE(&ifp->if_snd, m); - splx(s); if (m == NULL) { - if (flag & O_NONBLOCK) + if (flag & O_NONBLOCK) { + mtx_unlock(&tp->tap_mtx); return (EWOULDBLOCK); + } - mtx_lock(&tp->tap_mtx); tp->tap_flags |= TAP_RWAIT; - mtx_unlock(&tp->tap_mtx); - error = tsleep(tp,PCATCH|(PZERO+1),"taprd",0); - if (error) + error = mtx_sleep(tp, &tp->tap_mtx, PCATCH | (PZERO + 1), + "taprd", 0); + if (error) { + mtx_unlock(&tp->tap_mtx); return (error); + } } } while (m == NULL); + mtx_unlock(&tp->tap_mtx); /* feed packet to bpf */ BPF_MTAP(ifp, m); @@ -982,14 +958,14 @@ { struct tap_softc *tp = dev->si_drv1; struct ifnet *ifp = tp->tap_ifp; - int s, revents = 0; + int revents = 0; TAPDEBUG("%s polling, minor = %#x\n", ifp->if_xname, dev2unit(dev)); - s = splimp(); if (events & (POLLIN | POLLRDNORM)) { - if (ifp->if_snd.ifq_len > 0) { + IFQ_LOCK(&ifp->if_snd); + if (!IFQ_IS_EMPTY(&ifp->if_snd)) { TAPDEBUG("%s have data in queue. len = %d, " \ "minor = %#x\n", ifp->if_xname, ifp->if_snd.ifq_len, dev2unit(dev)); @@ -1001,12 +977,12 @@ selrecord(td, &tp->tap_rsel); } + IFQ_UNLOCK(&ifp->if_snd); } if (events & (POLLOUT | POLLWRNORM)) revents |= (events & (POLLOUT | POLLWRNORM)); - splx(s); return (revents); } /* tappoll */ @@ -1019,11 +995,9 @@ static int tapkqfilter(struct cdev *dev, struct knote *kn) { - int s; struct tap_softc *tp = dev->si_drv1; struct ifnet *ifp = tp->tap_ifp; - s = splimp(); switch (kn->kn_filter) { case EVFILT_READ: TAPDEBUG("%s kqfilter: EVFILT_READ, minor = %#x\n", @@ -1040,11 +1014,9 @@ default: TAPDEBUG("%s kqfilter: invalid filter, minor = %#x\n", ifp->if_xname, dev2unit(dev)); - splx(s); return (EINVAL); /* NOT REACHED */ } - splx(s); kn->kn_hook = (caddr_t) dev; knlist_add(&tp->tap_rsel.si_note, kn, 0); @@ -1061,12 +1033,11 @@ static int tapkqread(struct knote *kn, long hint) { - int ret, s; + int ret; struct cdev *dev = (struct cdev *)(kn->kn_hook); struct tap_softc *tp = dev->si_drv1; struct ifnet *ifp = tp->tap_ifp; - s = splimp(); if ((kn->kn_data = ifp->if_snd.ifq_len) > 0) { TAPDEBUG("%s have data in queue. len = %d, minor = %#x\n", ifp->if_xname, ifp->if_snd.ifq_len, dev2unit(dev)); @@ -1076,7 +1047,6 @@ ifp->if_xname, dev2unit(dev)); ret = 0; } - splx(s); return (ret); } /* tapkqread */ @@ -1090,13 +1060,10 @@ static int tapkqwrite(struct knote *kn, long hint) { - int s; struct tap_softc *tp = ((struct cdev *) kn->kn_hook)->si_drv1; struct ifnet *ifp = tp->tap_ifp; - s = splimp(); kn->kn_data = ifp->if_mtu; - splx(s); return (1); } /* tapkqwrite */ Index: if_tun.c =================================================================== --- if_tun.c (revision 212557) +++ if_tun.c (working copy) @@ -344,13 +344,13 @@ tp->tun_flags &= ~TUN_RWAIT; wakeup(tp); } + selwakeuppri(&tp->tun_rsel, PZERO + 1); + KNOTE_LOCKED(&tp->tun_rsel.si_note, 0); if (tp->tun_flags & TUN_ASYNC && tp->tun_sigio) { mtx_unlock(&tp->tun_mtx); pgsigio(&tp->tun_sigio, SIGIO, 0); } else mtx_unlock(&tp->tun_mtx); - selwakeuppri(&tp->tun_rsel, PZERO + 1); - KNOTE_UNLOCKED(&tp->tun_rsel.si_note, 0); } /* XXX: should return an error code so it can fail. */ @@ -385,7 +385,7 @@ IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); ifp->if_snd.ifq_drv_maxlen = 0; IFQ_SET_READY(&ifp->if_snd); - knlist_init_mtx(&sc->tun_rsel.si_note, NULL); + knlist_init_mtx(&sc->tun_rsel.si_note, &sc->tun_mtx); ifp->if_capabilities |= IFCAP_LINKSTATE; ifp->if_capenable |= IFCAP_LINKSTATE; @@ -443,7 +443,6 @@ { struct tun_softc *tp; struct ifnet *ifp; - int s; tp = dev->si_drv1; ifp = TUN2IFP(tp); @@ -451,27 +450,25 @@ mtx_lock(&tp->tun_mtx); tp->tun_flags &= ~TUN_OPEN; tp->tun_pid = 0; - mtx_unlock(&tp->tun_mtx); /* * junk all pending output */ CURVNET_SET(ifp->if_vnet); - s = splimp(); IFQ_PURGE(&ifp->if_snd); - splx(s); if (ifp->if_flags & IFF_UP) { - s = splimp(); + mtx_unlock(&tp->tun_mtx); if_down(ifp); - splx(s); + mtx_lock(&tp->tun_mtx); } /* Delete all addresses and routes which reference this interface. */ if (ifp->if_drv_flags & IFF_DRV_RUNNING) { struct ifaddr *ifa; - s = splimp(); + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; + mtx_unlock(&tp->tun_mtx); TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { /* deal w/IPv4 PtP destination; unlocked read */ if (ifa->ifa_addr->sa_family == AF_INET) { @@ -482,16 +479,14 @@ } } if_purgeaddrs(ifp); - ifp->if_drv_flags &= ~IFF_DRV_RUNNING; - splx(s); + mtx_lock(&tp->tun_mtx); } if_link_state_change(ifp, LINK_STATE_DOWN); CURVNET_RESTORE(); - mtx_lock(&tp->tun_mtx); funsetown(&tp->tun_sigio); selwakeuppri(&tp->tun_rsel, PZERO + 1); - KNOTE_UNLOCKED(&tp->tun_rsel.si_note, 0); + KNOTE_LOCKED(&tp->tun_rsel.si_note, 0); TUNDEBUG (ifp, "closed\n"); cv_broadcast(&tp->tun_cv); @@ -510,9 +505,11 @@ TUNDEBUG(ifp, "tuninit\n"); + mtx_lock(&tp->tun_mtx); ifp->if_flags |= IFF_UP; ifp->if_drv_flags |= IFF_DRV_RUNNING; getmicrotime(&ifp->if_lastchange); + mtx_unlock(&tp->tun_mtx); #ifdef INET if_addr_rlock(ifp); @@ -545,9 +542,8 @@ struct ifreq *ifr = (struct ifreq *)data; struct tun_softc *tp = ifp->if_softc; struct ifstat *ifs; - int error = 0, s; + int error = 0; - s = splimp(); switch(cmd) { case SIOCGIFSTATUS: ifs = (struct ifstat *)data; @@ -576,7 +572,6 @@ default: error = EINVAL; } - splx(s); return (error); } @@ -682,7 +677,6 @@ static int tunioctl(struct cdev *dev, u_long cmd, caddr_t data, int flag, struct thread *td) { - int s; int error; struct tun_softc *tp = dev->si_drv1; struct tuninfo *tunp; @@ -745,9 +739,11 @@ switch (*(int *)data & ~IFF_MULTICAST) { case IFF_POINTOPOINT: case IFF_BROADCAST: + mtx_lock(&tp->tun_mtx); TUN2IFP(tp)->if_flags &= ~(IFF_BROADCAST|IFF_POINTOPOINT|IFF_MULTICAST); TUN2IFP(tp)->if_flags |= *(int *)data; + mtx_unlock(&tp->tun_mtx); break; default: return(EINVAL); @@ -769,17 +765,15 @@ mtx_unlock(&tp->tun_mtx); break; case FIONREAD: - s = splimp(); if (!IFQ_IS_EMPTY(&TUN2IFP(tp)->if_snd)) { struct mbuf *mb; IFQ_LOCK(&TUN2IFP(tp)->if_snd); IFQ_POLL_NOLOCK(&TUN2IFP(tp)->if_snd, mb); - for( *(int *)data = 0; mb != 0; mb = mb->m_next) + for (*(int *)data = 0; mb != NULL; mb = mb->m_next) *(int *)data += mb->m_len; IFQ_UNLOCK(&TUN2IFP(tp)->if_snd); } else *(int *)data = 0; - splx(s); break; case FIOSETOWN: return (fsetown(*(int *)data, &tp->tun_sigio)); @@ -813,7 +807,7 @@ struct tun_softc *tp = dev->si_drv1; struct ifnet *ifp = TUN2IFP(tp); struct mbuf *m; - int error=0, len, s; + int error=0, len; TUNDEBUG (ifp, "read\n"); mtx_lock(&tp->tun_mtx); @@ -824,27 +818,24 @@ } tp->tun_flags &= ~TUN_RWAIT; - mtx_unlock(&tp->tun_mtx); - s = splimp(); do { IFQ_DEQUEUE(&ifp->if_snd, m); if (m == NULL) { if (flag & O_NONBLOCK) { - splx(s); + mtx_unlock(&tp->tun_mtx); return (EWOULDBLOCK); } - mtx_lock(&tp->tun_mtx); tp->tun_flags |= TUN_RWAIT; - mtx_unlock(&tp->tun_mtx); - if ((error = tsleep(tp, PCATCH | (PZERO + 1), - "tunread", 0)) != 0) { - splx(s); + error = mtx_sleep(tp, &tp->tun_mtx, PCATCH | (PZERO + 1), + "tunread", 0); + if (error != 0) { + mtx_unlock(&tp->tun_mtx); return (error); } } } while (m == NULL); - splx(s); + mtx_unlock(&tp->tun_mtx); while (m && uio->uio_resid > 0 && error == 0) { len = min(uio->uio_resid, m->m_len); @@ -957,13 +948,11 @@ static int tunpoll(struct cdev *dev, int events, struct thread *td) { - int s; struct tun_softc *tp = dev->si_drv1; struct ifnet *ifp = TUN2IFP(tp); int revents = 0; struct mbuf *m; - s = splimp(); TUNDEBUG(ifp, "tunpoll\n"); if (events & (POLLIN | POLLRDNORM)) { @@ -981,7 +970,6 @@ if (events & (POLLOUT | POLLWRNORM)) revents |= events & (POLLOUT | POLLWRNORM); - splx(s); return (revents); } @@ -991,11 +979,9 @@ static int tunkqfilter(struct cdev *dev, struct knote *kn) { - int s; struct tun_softc *tp = dev->si_drv1; struct ifnet *ifp = TUN2IFP(tp); - s = splimp(); switch(kn->kn_filter) { case EVFILT_READ: TUNDEBUG(ifp, "%s kqfilter: EVFILT_READ, minor = %#x\n", @@ -1012,10 +998,8 @@ default: TUNDEBUG(ifp, "%s kqfilter: invalid filter, minor = %#x\n", ifp->if_xname, dev2unit(dev)); - splx(s); return(EINVAL); } - splx(s); kn->kn_hook = (caddr_t) dev; knlist_add(&tp->tun_rsel.si_note, kn, 0); @@ -1029,12 +1013,11 @@ static int tunkqread(struct knote *kn, long hint) { - int ret, s; + int ret; struct cdev *dev = (struct cdev *)(kn->kn_hook); struct tun_softc *tp = dev->si_drv1; struct ifnet *ifp = TUN2IFP(tp); - s = splimp(); if ((kn->kn_data = ifp->if_snd.ifq_len) > 0) { TUNDEBUG(ifp, "%s have data in the queue. Len = %d, minor = %#x\n", @@ -1046,7 +1029,6 @@ dev2unit(dev)); ret = 0; } - splx(s); return (ret); } @@ -1057,13 +1039,10 @@ static int tunkqwrite(struct knote *kn, long hint) { - int s; struct tun_softc *tp = ((struct cdev *)kn->kn_hook)->si_drv1; struct ifnet *ifp = TUN2IFP(tp); - s = splimp(); kn->kn_data = ifp->if_mtu; - splx(s); return (1); } -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 21:57:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44036106566C for ; Wed, 15 Sep 2010 21:57:52 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id BB8E98FC0A for ; Wed, 15 Sep 2010 21:57:51 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ovzz6-0007Oe-Vd for freebsd-current@freebsd.org; Wed, 15 Sep 2010 23:57:45 +0200 Received: from k.saper.info ([91.121.151.35]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Sep 2010 23:57:44 +0200 Received: from saper by k.saper.info with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 15 Sep 2010 23:57:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Marcin Cieslak Date: Wed, 15 Sep 2010 21:57:34 +0000 (UTC) Organization: http://saper.info Lines: 86 Message-ID: References: <201009151749.45038.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: k.saper.info User-Agent: slrn/0.9.9p1 (FreeBSD) X-Mailman-Approved-At: Wed, 15 Sep 2010 22:04:06 +0000 Subject: Re: tun(4) in -CURRENT: No buffer space available - race condition patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 21:57:52 -0000 Dnia 15.09.2010 John Baldwin napisał/a: > On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote: >> Output queue of tun(4) gets full after some time when sending lots of data. >> I have been observing this on -CURRENT at least since March this year. >> >> Looks like it's a race condition (same in tun(4) and tap(4)), >> the following patch seems to address the issue: > > This is a good find. I actually went through these drivers a bit further and > have a bit of a larger patch to extend the locking some. Would you care to > test it? Sure, I am installing it right now (for if_tun right now). There are also a LORs during tunclose (I always get one of them when closing the tunnel): -------8<-------------------------------------------------------------------------- lock order reversal: 1st 0xc24db8c8 rtentry (rtentry) @ /usr/src/sys/net/route.c:370 2nd 0xc2472a04 if_afdata (if_afdata) @ /usr/src/sys/netinet6/scope6.c:417 KDB: stack backtrace: db_trace_self_wrapper(c0a4b284,cce14714,c0723185,c0715b2b,c0a4d1f8,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0715b2b,c0a4d1f8,c0c4f308,c21186e8,cce1476c,...) at kdb_backtrace+0x29 _witness_debugger(c0a4d1f8,c2472a04,c0a539ec,c211dfe0,c0a63771,...) at _witness_debugger+0x25 witness_checkorder(c2472a04,9,c0a63771,1a1,0,...) at witness_checkorder+0x6aa _rw_wlock(c2472a04,c0a63771,1a1,0,c2472a04,...) at _rw_wlock+0x38 in6_setscope(cce148c4,c2472800,0,cce147fc,cce147e0,...) at in6_setscope+0x30 in6_purgeaddr(c2539600,0,0,c211e048,c2362364,...) at in6_purgeaddr+0x4af if_purgeaddrs(c2472800,2,0,1cd,c24ab4c0,...) at if_purgeaddrs+0xb0 tunclose(c24d1000,3,2000,c23622c0,1,...) at tunclose+0x197 giant_close(c24d1000,3,2000,c23622c0,c23622c0,...) at giant_close+0x6e devfs_close(cce14a78,cce14a9c,c07785fb,c0aae500,cce14a78,...) at devfs_close+0x2a9 VOP_CLOSE_APV(c0aae500,cce14a78,c0a532d0,12d,c0af0160,...) at VOP_CLOSE_APV+0x42 vn_close(c24ccaa0,3,c2160c80,c23622c0,c23622c0,...) at vn_close+0xdb vn_closefile(c24bc0e0,c23622c0,c24bc0e0,0,cce14b28,...) at vn_closefile+0xe4 devfs_close_f(c24bc0e0,c23622c0,3,0,c24bc0e0,...) at devfs_close_f+0x2b _fdrop(c24bc0e0,c23622c0,cce14b5c,c072327c,0,...) at _fdrop+0x43 closef(c24bc0e0,c23622c0,721,71e,c2362364,...) at closef+0x277 fdfree(c23622c0,0,c0a4549c,107,80000000,...) at fdfree+0x3ba exit1(c23622c0,0,cce14c7c,c071da4a,c23622c0,...) at exit1+0x465 sys_exit(c23622c0,cce14cec,stray irq7 c06a7bac,1,0,...) at sys_exit+0x1d syscallenter(c23622c0,cce14ce4,c06d6stray irq7 d5d,c0cae934,8,...) at syscallenter+0x25a syscall(cce14d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (1, FreeBSD ELF32, sys_exit), eipstray irq7 = 0x28128acf, esp = 0xbfbfed80, ebp = 0xbfbfed8c --- ^Ctun0: link state changed to DOWN -------8<-------------------------------------------------------------------------- lock order reversal: 1st 0xc24db8c8 rtentrystray irq7 (rtentry) @ /usr/src/sys/net/route.c:370 2nd 0xc2482604 if_afdata (if_afdata) @ /usr/src/sys/netinet6/scope6.c:417 KDB: stack backtrace: db_trace_self_wrapper(c0a4912e,cce16714,c0723105,c0715aab,c0a4b0a2,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0715aab,c0a4b0a2,c0c4cb58,c21176e8,cce1676c,...) at kdb_backtrace+0x29 _witness_debugger(c0a4b0a2,c2482604,c0a51896,c211cfe0,c0a6137e,...) at _witness_debugger+0x25 witness_checkorder(c2482604,9,c0a6137e,1a1,0,...) at witness_checkorder+0x6aa _rw_wlock(c2482604,c0a613stray irq7 7e,1a1,c0793997,c2482604,...) at _rw_wlock+0x38 in6_setscope(cce168c4,c2482400,0,cce167fc,cce167e0,...) at in6_setscope+0x30 in6_purgeaddr(c253e000,0,0,c211d048,c2361364,...) at in6_purgeaddr+0x4af if_purgeaddrs(c2482400,2,0,1cd,c24aa5c0,...) at if_purgeaddrs+0xb0 tunclose(c2539a00,3,2000,c23612c0,1,...) at tunclose+0x136 giant_close(c2539a00,3,2000,c23612c0,c23612c0,...) at giant_close+0x6e devfs_close(cce16a78,cce16a9c,c077857b,c0aac0e0,cce16a78,...) at devfs_close+0x2a9 VOP_CLOSE_APV(c0aac0e0,cce16a78,c0a5117a,12d,c0aedac0,...) at VOP_CLOSE_APV+0x42 vn_close(c25d2770,3,c215fc80,c23612c0,c0b10180,...) at vn_close+0xdb vn_closefile(c24bba10,c23612c0,c24bba10,0,cce16b28,...) at vn_closefile+0xe4 devfs_close_f(c24bba10,c23612c0,3,0,c24bba10,...) at devfs_close_f+0x2b _fdrop(c24bba10,c23612c0,cce16b5c,c07231fc,0,...) at _fdrop+0x43 closef(c24bba10,c23612c0,721,71e,c2361364,...) at closef+0x277 fdfree(c23612c0,0,c0a43346,107,c2361364,...) at fdfree+0x3ba exit1(c23612c0,0,cce16c7c,c071d9ca,c23612c0,...) at exit1+0x465 sys_exit(c23612c0,cce16cec,28087460,1,0,...) at sys_exit+0x1d syscallenter(c23612c0,cce16ce4,c09a564e,c23612c0,cce16d28,...) at syscallenter+0x25a syscall(cce16d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x28128acf, esp = 0xbfbfed80, ebp = 0xbfbfed8c --- tun0: link state changed to DOWN -------8<-------------------------------------------------------------------------- --Marcin From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 22:08:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id A717F1065670; Wed, 15 Sep 2010 22:08:32 +0000 (UTC) Date: Wed, 15 Sep 2010 22:08:32 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20100915220832.GA24698@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: WITHOUT_BIND=true and `make delete-old` X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 22:08:32 -0000 hi there, just wanted to ask if the following entries from BSD.include.dist: "lwres" and BSD.usr.dist: "bind9" (including arm and misc) could be moved to BIND.chroot.dist so `make delete-old` doesn't have to remove those directories after every installworld and WITHOUT_BIND=true? cheers. alex -- a13x From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 22:23:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A9F0106566C; Wed, 15 Sep 2010 22:23:41 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id 409828FC13; Wed, 15 Sep 2010 22:23:41 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from sa-nc-common3-235.static.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp023.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L8T00FCN4R2FX30@asmtp023.mac.com>; Wed, 15 Sep 2010 14:23:28 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1009150116 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-09-15_15:2010-09-15, 2010-09-15, 1970-01-01 signatures=0 From: Marcel Moolenaar In-reply-to: <20100915152353.GA45611@mech-anton240.men.bris.ac.uk> Date: Wed, 15 Sep 2010 14:23:26 -0700 Message-id: <5667FD77-8DBC-4638-80B6-67BCF9D4FB29@mac.com> References: <20100915152353.GA45611@mech-anton240.men.bris.ac.uk> To: Anton Shterenlikht X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: multiple problems between r212316 and r212643 on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 22:23:41 -0000 On Sep 15, 2010, at 8:23 AM, Anton Shterenlikht wrote: > > % man ls > zcat: /usr/share/man/cat1/ls.1.gz already has .gz suffix -- unchanged > % man man > zcat: /usr/share/man/cat1/man.1.gz already has .gz suffix -- unchanged > > > # cd /etc/mail > # make start > Starting: sendmail-submitmailwrapper: no mapping in /etc/mail/mailer.conf > sendmail-clientmqueuemailwrapper: no mapping in /etc/mail/mailer.conf > . > # > > # cd /usr/src > # svn up > svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byte sequence > # > I think your file system is borked. Nonetheless, let me upgrade myself and see if I run onto it too. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 00:47:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69C31106566C for ; Thu, 16 Sep 2010 00:47:26 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 150BD8FC08 for ; Thu, 16 Sep 2010 00:47:25 +0000 (UTC) Received: by gyg4 with SMTP id 4so294803gyg.13 for ; Wed, 15 Sep 2010 17:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=OtTLb1yj9u3nX/LfWyyVJJrLgXjrym2iE1uaTa7Vc/U=; b=L9xhGMHH1dMmmumogOC1d2aZGxpw0aoZJMYTu1EAN1rMXFM5Rc3CTTd1qDAz2BCcum fjiGaAE1joc5ktH2vnSXuVdMHhRVAUyuv30Ml9WjAO+pi4YHgJ12yvPyV9dXZUQm+f/s +gDJ3A+CABzU8FN6oqNZ4rcLCyqG/SZIFMDCs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=btP32wqYtRP/xyhyExv8MsZduPpQIsLWmdsVS1QwG47JtCefmed1k6R/aj8MZck6rs 9u4Hvo2ParOBIV8zWJPBgbbplpNHA11+pKLFUjW6ekjBg/qJ6v5EhG4ecAfnUuCv6lwo W95W87n2hoU88ylvrcgZkkZPaZSNjDwot6abs= Received: by 10.150.12.6 with SMTP id 6mr2460725ybl.46.1284598045095; Wed, 15 Sep 2010 17:47:25 -0700 (PDT) Received: from centel.dataix.local ([99.181.146.122]) by mx.google.com with ESMTPS id q17sm2861659ybk.5.2010.09.15.17.47.23 (version=SSLv3 cipher=RC4-MD5); Wed, 15 Sep 2010 17:47:24 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C91691A.9040207@DataIX.net> Date: Wed, 15 Sep 2010 20:47:22 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.9) Gecko/20100908 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: "Jason J. W. Williams" References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ZFS Test Suite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 00:47:26 -0000 On 09/15/2010 13:40, Jason J. W. Williams wrote: > Does the FreeBSD ZFS port get tested against the ZFS test suite > created by Sun? It's a fairly comprehensive suite and has delivered a > very reliable set of ZFS beta code for a long time. Trying to gauge > the stability and compatibility of the FreeBSD port. Thank you in > advance. > Got a download link. Seems from this point on hub.opensolaris.org is down. -- jhell,v From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 01:45:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D165A10656D4 for ; Thu, 16 Sep 2010 01:45:18 +0000 (UTC) (envelope-from jasonjwwilliams@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 659B48FC3B for ; Thu, 16 Sep 2010 01:45:18 +0000 (UTC) Received: by wwi17 with SMTP id 17so8399wwi.31 for ; Wed, 15 Sep 2010 18:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oBRXMxulmiP8vL6q9fqMWkf41hmr4tTNhRGTk8CaQvU=; b=BR2kT9JwoJOtgEpFNsDaUGHiA0eMWvhM6QDqKwsXg8JTm8N2HuR7VRTO3foOu9uMr6 1SOz9f2ZNHYogk/dyKq7q6Fr+2B/Le21yYJa8RiGotgnnzKBnWtSwUN/c3d3UAv6CCNk YqSPnDAuOS4sywc3XSe5vRDio1WGzdL63u8R4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oZmJbdRE1tZ+lRhLuOhCvN6Rz/JkMqCBtJqOu84Ze//t8TOVTvRPJ7CLLBwt/5kPM8 +cA8En7RyqwvQeef1oTx1vkbhotA6LDS1QSrroqzkt0CqhkYCH+sEfq6ISiifnuS+EHH lYLPx17iy5Z5Mq/+C1x0CRJfAFxFhQT7sJKNw= MIME-Version: 1.0 Received: by 10.216.161.17 with SMTP id v17mr6029450wek.1.1284601514162; Wed, 15 Sep 2010 18:45:14 -0700 (PDT) Received: by 10.216.168.199 with HTTP; Wed, 15 Sep 2010 18:45:14 -0700 (PDT) In-Reply-To: <4C91691A.9040207@DataIX.net> References: <4C91691A.9040207@DataIX.net> Date: Wed, 15 Sep 2010 19:45:14 -0600 Message-ID: From: "Jason J. W. Williams" To: jhell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-current@freebsd.org" Subject: Re: ZFS Test Suite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 01:45:19 -0000 Yeah...Oracle closed the gate. Illumos.org probably has a copy in their fork though. -J On Wednesday, September 15, 2010, jhell wrote: > On 09/15/2010 13:40, Jason J. W. Williams wrote: >> Does the FreeBSD ZFS port get tested against the ZFS test suite >> created by Sun? It's a fairly comprehensive suite and has delivered a >> very reliable set of ZFS beta code for a long time. Trying to gauge >> the stability and compatibility of the FreeBSD port. Thank you in >> advance. >> > > Got a download link. Seems from this point on hub.opensolaris.org is down= . > > -- > > =A0jhell,v > From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 02:14:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 924AB106564A for ; Thu, 16 Sep 2010 02:14:19 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 677FA8FC12 for ; Thu, 16 Sep 2010 02:14:19 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1Ow3zN-000Dc8-Fi; Wed, 15 Sep 2010 22:14:17 -0400 Date: Wed, 15 Sep 2010 22:14:17 -0400 From: Gary Palmer To: jhell Message-ID: <20100916021417.GB381@in-addr.com> References: <4C91691A.9040207@DataIX.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C91691A.9040207@DataIX.net> Cc: "Jason J. W. Williams" , freebsd-current@freebsd.org Subject: Re: ZFS Test Suite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 02:14:19 -0000 On Wed, Sep 15, 2010 at 08:47:22PM -0400, jhell wrote: > On 09/15/2010 13:40, Jason J. W. Williams wrote: > > Does the FreeBSD ZFS port get tested against the ZFS test suite > > created by Sun? It's a fairly comprehensive suite and has delivered a > > very reliable set of ZFS beta code for a long time. Trying to gauge > > the stability and compatibility of the FreeBSD port. Thank you in > > advance. > > > > Got a download link. Seems from this point on hub.opensolaris.org is down. http://hub.opensolaris.org/bin/view/Community+Group+zfs/zfstestsuite pointed me at http://dlc.sun.com/osol/test/downloads/current/ The stcnv-zfs-src-20090909.tar.bz2 file was able to be downloaded from the 2nd link and produced a 4.1MB file with about 1565 entries in it according to tar -ztf. Note that I don't run ZFS here so I can't try the test suite. Regards, Gary From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 03:14:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F00571065675 for ; Thu, 16 Sep 2010 03:14:14 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by mx1.freebsd.org (Postfix) with ESMTP id C7AFC8FC0A for ; Thu, 16 Sep 2010 03:14:14 +0000 (UTC) Received: from [10.0.0.247] (unknown [64.9.234.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E89F6509DC; Wed, 15 Sep 2010 23:13:47 -0400 (EDT) Message-ID: <4C918B3E.1070107@gmail.com> Date: Wed, 15 Sep 2010 20:13:02 -0700 From: David Ehrmann User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Rick Macklem References: <1431942489.798180.1284347384700.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1431942489.798180.1284347384700.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: NFS lockups with VMware esxi client X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 03:14:15 -0000 Rick Macklem wrote: >> I have NFS sharing a ZFS pool that VMware esxi stores files on. When >> put under stress (an OS installation, but not Linux compilation), the >> NFS server locks, spiking to 100% CPU usage. Not even kill -KILL can >> stop the process, so rebooting is required. >> > I believe it is patched in head/current. A compatible patch is at: > http://people.freebsd.org/~rmacklem/freebsd8.1-patches/replay.patch > > rick > It worked! I grabbed the latest from STABLE, checked, saw that patch was already in, compiled, and it's working. Thank you. From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 03:53:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 781DB106564A for ; Thu, 16 Sep 2010 03:53:12 +0000 (UTC) (envelope-from joe@via.net) Received: from smtp3.via.net (smtp3.via.net [209.81.9.15]) by mx1.freebsd.org (Postfix) with ESMTP id 61A768FC1C for ; Thu, 16 Sep 2010 03:53:12 +0000 (UTC) Received: from mail.via.net (mail.via.net [209.81.9.12]) by smtp3.via.net (8.14.1/8.12.11-VIANET) with ESMTP id o8G27Dqa025542 for ; Wed, 15 Sep 2010 19:07:13 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at smtp3.via.net Received: from [209.81.2.70] ([209.81.2.70]) by mail.via.net (8.14.1/8.12.11-VIANET) with ESMTP id o8G27Dce018697 for ; Wed, 15 Sep 2010 19:07:13 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.1 at mail.via.net From: joe mcguckin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Sep 2010 19:07:03 -0700 Message-Id: <1C9F72B8-26BC-4A03-AD81-3616A8AA8CA3@via.net> To: freebsd-current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (smtp3.via.net [209.81.9.15]); Wed, 15 Sep 2010 19:07:13 -0700 (PDT) Subject: Can't build PERL under 8.1 Release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 03:53:12 -0000 I just installed 8.1 Release. Trying to build Perl, it dies at: Running Makefile.PL in ext/DynaLoader ../../miniperl -I../../lib Makefile.PL INSTALLDIRS=3Dperl = INSTALLMAN1DIR=3Dnone INSTALLMAN3DIR=3Dnone PERL_CORE=3D1 = LIBPERL_A=3Dlibperl.so LINKTYPE=3Dstatic Writing Makefile for DynaLoader Makefile out-of-date with respect to Makefile.PL Cleaning current config before rebuilding Makefile... make -f Makefile.old clean > /dev/null 2>&1 ../../miniperl "-I../../lib" "-I../../lib" Makefile.PL = "INSTALLDIRS=3Dperl" "INSTALLMAN1DIR=3Dnone" "INSTALLMAN3DIR=3Dnone" = "PERL_CORE=3D1" "LIBPERL_A=3Dlibperl.so" "LINKTYPE=3Dstatic" Writing Makefile for DynaLoader =3D=3D> Your Makefile has been rebuilt. <=3D=3D =3D=3D> Please rerun the make command. <=3D=3D false *** Error code 1 Rerunning make just make it die again in the same location. Any ideas? -joe From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 10:57:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09A161065672; Thu, 16 Sep 2010 10:57:07 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id B97FC8FC19; Thu, 16 Sep 2010 10:57:06 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1OwC9J-0004Vr-JB; Thu, 16 Sep 2010 11:57:05 +0100 Received: from mech-anton240.men.bris.ac.uk ([137.222.187.240]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OwC9J-0007Hw-CI; Thu, 16 Sep 2010 11:57:05 +0100 Received: from mech-anton240.men.bris.ac.uk (localhost [127.0.0.1]) by mech-anton240.men.bris.ac.uk (8.14.4/8.14.4) with ESMTP id o8GAv5OD051851; Thu, 16 Sep 2010 11:57:05 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-anton240.men.bris.ac.uk (8.14.4/8.14.4/Submit) id o8GAv4T9051850; Thu, 16 Sep 2010 11:57:04 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-anton240.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Thu, 16 Sep 2010 11:57:04 +0100 From: Anton Shterenlikht To: Marcel Moolenaar Message-ID: <20100916105704.GB51787@mech-anton240.men.bris.ac.uk> References: <20100915152353.GA45611@mech-anton240.men.bris.ac.uk> <5667FD77-8DBC-4638-80B6-67BCF9D4FB29@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5667FD77-8DBC-4638-80B6-67BCF9D4FB29@mac.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, Anton Shterenlikht , freebsd-ia64@freebsd.org Subject: Re: multiple problems between r212316 and r212643 on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 10:57:07 -0000 On Wed, Sep 15, 2010 at 02:23:26PM -0700, Marcel Moolenaar wrote: > > On Sep 15, 2010, at 8:23 AM, Anton Shterenlikht wrote: > > > > > % man ls > > zcat: /usr/share/man/cat1/ls.1.gz already has .gz suffix -- unchanged > > % man man > > zcat: /usr/share/man/cat1/man.1.gz already has .gz suffix -- unchanged > > > > > > # cd /etc/mail > > # make start > > Starting: sendmail-submitmailwrapper: no mapping in /etc/mail/mailer.conf > > sendmail-clientmqueuemailwrapper: no mapping in /etc/mail/mailer.conf > > . > > # > > > > # cd /usr/src > > # svn up > > svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byte sequence > > # > > > > I think your file system is borked. Nonetheless, let me > upgrade myself and see if I run onto it too. I did "fsck -f" in single user mode - all seems fine: # fsck -f ** /dev/da0p2 ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 723993 files, 7874130 used, 20052947 free (87043 frags, 2495738 blocks, 0.3% fra gmentation) ***** FILE SYSTEM IS CLEAN ***** # -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 12:05:19 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57F5810657C1 for ; Thu, 16 Sep 2010 12:05:19 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 0CFF58FC1D for ; Thu, 16 Sep 2010 12:05:18 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OwDDJ-0007gI-7M for freebsd-current@freebsd.org; Thu, 16 Sep 2010 14:05:17 +0200 Received: from 142-076-ppp.kubtelecom.ru ([142-076-ppp.kubtelecom.ru]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Sep 2010 14:05:17 +0200 Received: from yuri.pankov by 142-076-ppp.kubtelecom.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Sep 2010 14:05:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Yuri Pankov Date: Thu, 16 Sep 2010 12:04:58 +0000 (UTC) Lines: 21 Message-ID: References: <1C9F72B8-26BC-4A03-AD81-3616A8AA8CA3@via.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 213.132.76.142 (Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100916 Firefox/3.6.9) Subject: Re: Can't build PERL under 8.1 Release X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 12:05:19 -0000 joe mcguckin via.net> writes: > Writing Makefile for DynaLoader > ==> Your Makefile has been rebuilt. <== > ==> Please rerun the make command. <== > false > *** Error code 1 Check machine's date/time. > Rerunning make just make it die again in the same location. > > Any ideas? > > -joe HTH, Yuri From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 12:38:08 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62E06106570A for ; Thu, 16 Sep 2010 12:38:08 +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 302878FC08 for ; Thu, 16 Sep 2010 12:38:08 +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 C83EC46B5C; Thu, 16 Sep 2010 08:38:07 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4D20D8A050; Thu, 16 Sep 2010 08:38:06 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 16 Sep 2010 08:27:30 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201009151749.45038.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201009160827.30410.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 16 Sep 2010 08:38:06 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Marcin Cieslak Subject: Re: tun(4) in -CURRENT: No buffer space available - race condition patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 12:38:08 -0000 On Wednesday, September 15, 2010 5:57:34 pm Marcin Cieslak wrote: > Dnia 15.09.2010 John Baldwin napisa=C5=82/a: > > On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote: > >> Output queue of tun(4) gets full after some time when sending lots of = data. > >> I have been observing this on -CURRENT at least since March this year. > >>=20 > >> Looks like it's a race condition (same in tun(4) and tap(4)),=20 > >> the following patch seems to address the issue: > > > > This is a good find. I actually went through these drivers a bit furth= er and=20 > > have a bit of a larger patch to extend the locking some. Would you car= e to=20 > > test it? >=20 > Sure, I am installing it right now (for if_tun right now). >=20 > There are also a LORs during tunclose (I always get one of them when clos= ing the > tunnel): Hmm, this looks to be in the if_purgeaddrs() routine itself and not specific to tun/tap. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 12:38:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B20251065693; Thu, 16 Sep 2010 12:38:10 +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 7E96E8FC1C; Thu, 16 Sep 2010 12:38:10 +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 18B2046B65; Thu, 16 Sep 2010 08:38:10 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B19718A04E; Thu, 16 Sep 2010 08:38:08 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 16 Sep 2010 08:28:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20100915063233.GE1036@pluto.vnode.local> In-Reply-To: <20100915063233.GE1036@pluto.vnode.local> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009160828.35520.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 16 Sep 2010 08:38:09 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Joel Dahl Subject: Re: Multiple hpet messages during boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 12:38:10 -0000 On Wednesday, September 15, 2010 2:32:33 am Joel Dahl wrote: > I noticed this during boot (HEAD from yesterday): > > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > > Is it really necessary to print this 8 times? I'd actually like to remove the interrupt messages that say '[FILTER]' or '[GIANT]', etc. I think in general they only add clutter. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 12:38:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E5AE106576E for ; Thu, 16 Sep 2010 12:38:15 +0000 (UTC) (envelope-from pguzikos@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3C9918FC19 for ; Thu, 16 Sep 2010 12:38:13 +0000 (UTC) Received: by wyb33 with SMTP id 33so1693242wyb.13 for ; Thu, 16 Sep 2010 05:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:x-mimeole; bh=oM78gzQfSbASepdhVY4R1pVYZZz9Zp61KmiAnVzUGKg=; b=o2Y6RJvfrClp6q57JWJDbZ5RNAI4AVdgE6PzZiXu6Vq9pS0Vxx0eKcvnK7S33SFznG Cz8/Uu7CDGLkKHXfG6cpf4trxOSUwazkvOF/NwPEM2nN/ok6MdtcflEok4Kcc1eJR6ii 5Lu0/wUSnIN95hfEfvpcQS0N8rGaFcKQQIF0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :x-mimeole; b=g5wqP9RhLFaVU1xodgMrIXZo1dxpLekwwGu8q/YHNHLVe3N2tmtDPgUIY9lltawFzj ws5wY8ewvjD/6hq/2GBoUl6LfkVZTXrZcgFkrwWJoktYtWluiFF+dFzYyId3pTd4eNlY V4Wg1mM4eyOxMkeu88d/g+aWkndLhxr+xLXNc= Received: by 10.216.47.196 with SMTP id t46mr6558376web.13.1284639059325; Thu, 16 Sep 2010 05:10:59 -0700 (PDT) Received: from r61PC (bud82.internetdsl.tpnet.pl [83.18.159.82]) by mx.google.com with ESMTPS id p45sm1774205weq.45.2010.09.16.05.10.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Sep 2010 05:10:57 -0700 (PDT) From: "Piotr Guzik" To: References: <20100916120025.D573910656D7@hub.freebsd.org> In-Reply-To: <20100916120025.D573910656D7@hub.freebsd.org> Date: Thu, 16 Sep 2010 14:10:54 +0200 Message-ID: <5541058CFB0F4E7FAAD0BD4D053C4437@MetrixMetal.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActVlvXzC9IaxgemSYuJlAYFGJnnXAAATPrg X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18416 Subject: RE: freebsd-current Digest, Vol 361, Issue 4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 12:38:15 -0000 Dziekuje bardzo. Jutro postaramy si=EA odebrac tusze oraz monitor. Pozdrawiam, Piotr Guzik -------------------------------------------------------------- Metrix Metal Sp. z o.o. ul. Piaskowa 3 83-100 Tczew NIP 586-00-23-871 S=B1d Rejonowy Gda=F1sk-P=F3=B3noc VII Gospodarczy KRS: 0000006693 Kapita=B3 zak=B3adowy: 10.000.000,00- PLN =20 -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of freebsd-current-request@freebsd.org Sent: Thursday, September 16, 2010 2:00 PM To: freebsd-current@freebsd.org Subject: freebsd-current Digest, Vol 361, Issue 4 Send freebsd-current mailing list submissions to freebsd-current@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freebsd.org/mailman/listinfo/freebsd-current or, via email, send a message with subject or body 'help' to freebsd-current-request@freebsd.org You can reach the person managing the list at freebsd-current-owner@freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-current digest..." Today's Topics: 1. [head tinderbox] failure on powerpc64/powerpc (FreeBSD Tinderbox) 2. [head tinderbox] failure on powerpc/powerpc (FreeBSD Tinderbox) 3. buildworld + ccache trouble (Dmitry Krivenok) 4. Re: DHCP server in base (M. Warner Losh) 5. Re: buildworld + ccache trouble (Maxim Khitrov) 6. Re: TCP loopback socket fusing (Bjoern A. Zeeb) 7. multiple problems between r212316 and r212643 on ia64 (Anton Shterenlikht) 8. Re: TCP loopback socket fusing (Gary Jennejohn) 9. Re: TCP loopback socket fusing (Andre Oppermann) 10. ZFS Test Suite (Jason J. W. Williams) 11. Re: DHCP server in base (Doug Barton) 12. Re: Multiple hpet messages during boot (Alexander Motin) 13. Re: buildworld + ccache trouble (Tom Judge) 14. Re: regarding pciids (Andriy Gapon) 15. Re: buildworld + ccache trouble (Dimitry Andric) 16. Re: tun(4) in -CURRENT: No buffer space available - race condition patch (John Baldwin) 17. Re: tun(4) in -CURRENT: No buffer space available - race condition patch (Marcin Cieslak) 18. WITHOUT_BIND=3Dtrue and `make delete-old` (Alexander Best) 19. Re: multiple problems between r212316 and r212643 on ia64 (Marcel Moolenaar) 20. Re: ZFS Test Suite (jhell) 21. Re: ZFS Test Suite (Jason J. W. Williams) 22. Re: ZFS Test Suite (Gary Palmer) 23. Re: NFS lockups with VMware esxi client (David Ehrmann) 24. Can't build PERL under 8.1 Release (joe mcguckin) 25. Re: multiple problems between r212316 and r212643 on ia64 (Anton Shterenlikht) ---------------------------------------------------------------------- Message: 1 Date: Wed, 15 Sep 2010 12:54:24 GMT From: FreeBSD Tinderbox Subject: [head tinderbox] failure on powerpc64/powerpc To: FreeBSD Tinderbox , , Message-ID: <201009151254.o8FCsOd1063007@freebsd-current.sentex.ca> TB --- 2010-09-15 12:07:44 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-15 12:07:44 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-09-15 12:07:44 - cleaning the object tree TB --- 2010-09-15 12:08:39 - cvsupping the source tree TB --- 2010-09-15 12:08:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-09-15 12:09:10 - building world TB --- 2010-09-15 12:09:10 - MAKEOBJDIRPREFIX=3D/obj TB --- 2010-09-15 12:09:10 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-15 12:09:10 - TARGET=3Dpowerpc TB --- 2010-09-15 12:09:10 - TARGET_ARCH=3Dpowerpc64 TB --- 2010-09-15 12:09:10 - TZ=3DUTC TB --- 2010-09-15 12:09:10 - __MAKE_CONF=3D/dev/null TB --- 2010-09-15 12:09:10 - cd /src TB --- 2010-09-15 12:09:10 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 15 12:09:12 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DSTREAMSPTY -DINET6 = -I/src/libexec/telnetd/../../contrib/telnet -DAUTHENTICATION -DENCRYPTION -DKRB5 -DFORWARD = -Dnet_write=3Dtelnet_net_write -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall = -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o telnetd global.o slc.o state.o sys_term.o telnetd.o termstat.o utility.o authenc.o -lutil -ltermcap /obj/powerpc.powerpc64/src/libexec/telnetd/../../lib/libtelnet/libtelnet.= a -lmp -lcrypto -lcrypt -lpam -lkrb5 -lhx509 -lasn1 -lroken -lcom_err gzip -cn /src/libexec/telnetd/../../contrib/telnet/telnetd/telnetd.8 > telnetd.8.gz =3D=3D=3D> libexec/tftpd (all) cc -O2 -pipe -I/src/libexec/tftpd/../../usr.bin/tftp -I/src/libexec/tftpd/../../libexec/tftpd -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith = -Wno-uninitialized -Wno-pointer-sign -c /src/libexec/tftpd/tftpd.c cc -O2 -pipe -I/src/libexec/tftpd/../../usr.bin/tftp -I/src/libexec/tftpd/../../libexec/tftpd -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith = -Wno-uninitialized -Wno-pointer-sign -c /src/libexec/tftpd/tftp-io.c cc1: warnings being treated as errors /src/libexec/tftpd/tftp-io.c: In function 'receive_packet': /src/libexec/tftpd/tftp-io.c:396: warning: variable 'pfrom' might be clobbered by 'longjmp' or 'vfork' *** Error code 1 Stop in /src/libexec/tftpd. *** Error code 1 Stop in /src/libexec. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-15 12:54:24 - WARNING: /usr/bin/make returned exit code = 1=20 TB --- 2010-09-15 12:54:24 - ERROR: failed to build world TB --- 2010-09-15 12:54:24 - 1768.60 user 658.62 system 2799.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ------------------------------ Message: 2 Date: Wed, 15 Sep 2010 13:03:26 GMT From: FreeBSD Tinderbox Subject: [head tinderbox] failure on powerpc/powerpc To: FreeBSD Tinderbox , , Message-ID: <201009151303.o8FD3QDP026756@freebsd-current.sentex.ca> TB --- 2010-09-15 11:47:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-09-15 11:47:01 - starting HEAD tinderbox run for = powerpc/powerpc TB --- 2010-09-15 11:47:01 - cleaning the object tree TB --- 2010-09-15 11:47:51 - cvsupping the source tree TB --- 2010-09-15 11:47:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-09-15 11:48:34 - building world TB --- 2010-09-15 11:48:34 - MAKEOBJDIRPREFIX=3D/obj TB --- 2010-09-15 11:48:34 - PATH=3D/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-15 11:48:34 - TARGET=3Dpowerpc TB --- 2010-09-15 11:48:34 - TARGET_ARCH=3Dpowerpc TB --- 2010-09-15 11:48:34 - TZ=3DUTC TB --- 2010-09-15 11:48:34 - __MAKE_CONF=3D/dev/null TB --- 2010-09-15 11:48:34 - cd /src TB --- 2010-09-15 11:48:34 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 15 11:48:34 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DSTREAMSPTY -DINET6 = -I/src/libexec/telnetd/../../contrib/telnet -DAUTHENTICATION -DENCRYPTION -DKRB5 -DFORWARD = -Dnet_write=3Dtelnet_net_write -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall = -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o telnetd global.o slc.o state.o sys_term.o telnetd.o termstat.o utility.o authenc.o -lutil -ltermcap /obj/powerpc.powerpc/src/libexec/telnetd/../../lib/libtelnet/libtelnet.a -lmp -lcrypto -lcrypt -lpam -lkrb5 -lhx509 -lasn1 -lroken -lcom_err gzip -cn /src/libexec/telnetd/../../contrib/telnet/telnetd/telnetd.8 > telnetd.8.gz =3D=3D=3D> libexec/tftpd (all) cc -O2 -pipe -I/src/libexec/tftpd/../../usr.bin/tftp -I/src/libexec/tftpd/../../libexec/tftpd -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith = -Wno-uninitialized -Wno-pointer-sign -c /src/libexec/tftpd/tftpd.c cc -O2 -pipe -I/src/libexec/tftpd/../../usr.bin/tftp -I/src/libexec/tftpd/../../libexec/tftpd -std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith = -Wno-uninitialized -Wno-pointer-sign -c /src/libexec/tftpd/tftp-io.c cc1: warnings being treated as errors /src/libexec/tftpd/tftp-io.c: In function 'receive_packet': /src/libexec/tftpd/tftp-io.c:396: warning: variable 'pfrom' might be clobbered by 'longjmp' or 'vfork' *** Error code 1 Stop in /src/libexec/tftpd. *** Error code 1 Stop in /src/libexec. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-09-15 13:03:26 - WARNING: /usr/bin/make returned exit code = 1=20 TB --- 2010-09-15 13:03:26 - ERROR: failed to build world TB --- 2010-09-15 13:03:26 - 3257.18 user 858.55 system 4584.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ------------------------------ Message: 3 Date: Wed, 15 Sep 2010 16:44:45 +0400 From: Dmitry Krivenok Subject: buildworld + ccache trouble To: freebsd-current@freebsd.org Message-ID: Content-Type: text/plain; charset=3DISO-8859-1 Hello All! I recently updated to r212634 and tried to build CURRENT tree with = ccache. I added /usr/local/libexec/ccache in my $PATH and added the following in /etc/make.conf: .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && !defined(NOCCACHE) CC=3D/usr/local/libexec/ccache/world-cc CXX=3D/usr/local/libexec/ccache/world-c++ .endif Then I set WITHOUT_BOOT =3D 'YES' DEBUG_FLAGS =3D '-g -O0' and run make buildworld buildkernel installkernel However, I got build error: =3D=3D=3D> lib/csu/i386-elf (obj,depend,all,install) rm -f .depend CC=3D'/usr/local/libexec/ccache/world-cc' mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S /usr/local/libexec/ccache/world-cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -g -O0 -std=3Dgnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crti.S /usr/local/libexec/ccache/world-cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -g -O0 -std=3Dgnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crtn.S /usr/local/libexec/ccache/world-cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -g -O0 -std=3Dgnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -DGCRT -c -o gcrt1_c.o /usr/src/lib/csu/i386-elf/crt1_c.c /usr/local/libexec/ccache/world-cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -g -O0 -std=3Dgnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crt1_s.S /usr/src/lib/csu/i386-elf/crt1_s.S: Assembler messages: /usr/src/lib/csu/i386-elf/crt1_s.S:36: Error: suffix or operands invalid for `push' /usr/src/lib/csu/i386-elf/crt1_s.S:39: Error: bad register expression /usr/src/lib/csu/i386-elf/crt1_s.S:40: Error: bad register expression /usr/src/lib/csu/i386-elf/crt1_s.S:42: Error: `8(%ebp)' is not a valid 64 bit base/index expression /usr/src/lib/csu/i386-elf/crt1_s.S:43: Error: suffix or operands invalid for `push' /usr/src/lib/csu/i386-elf/crt1_s.S:44: Error: `4(%ebp)' is not a valid 64 bit base/index expression /usr/src/lib/csu/i386-elf/crt1_s.S:45: Error: suffix or operands invalid for `push' *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Is it a know issue? Any solutions? Thanks in advance! P.S. Build works fine if I don't use ccache. --=20 Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 ------------------------------ Message: 4 Date: Wed, 15 Sep 2010 08:25:13 -0600 (MDT) From: "M. Warner Losh" Subject: Re: DHCP server in base To: demelier.david@gmail.com Cc: kimelto@gmail.com, ray@ddteam.net, dougb@freebsd.org, mj@feral.com, freebsd-current@freebsd.org Message-ID: <20100915.082513.802140508206832836.imp@bsdimp.com> Content-Type: Text/Plain; charset=3Dus-ascii In message: = David DEMELIER writes: : 2010/9/11 Doug Barton : : > On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote: : >> : >> Hi, : >> : >> another argument about hostapd :) if have access point we must have : >> way to assign IP for AP clients. : > : > To start with, your assumption is wrong. DHCPd is not *actually* a : > requirement, although I admit that practically it is. : > : >> Last spring I made firmware based on FreeBSD for router with only = 4MB : >> NOR flash (D-Link DIR-320). : > : > In this category (micro-miniaturization) you're already in the "significant : > customization needed" area, which means that general arguments about "the : > base" don't apply. : > : >> Since this device is router I must be : >> able to serve DHCP. And current implementation of dhcpclient, that = we : >> have, is same isc-dhcp, and I replace system dhcpclient with ports : >> one+dhcpd but with small patch that put basic dhcp utils onto : >> libdhcp.so. : > : > Your argument is creative and well thought out, but I personally = don't find : > it persuasive. Counter arguments that come immediately to mind are: : > 1. The DHCP server is not going to benefit any but a small minority = of : > FreeBSD users. : > 2. The software is already available in the ports tree, and adding a : > port/package of it really is not an overwhelming burden. : > : > More generally, the main reason I want to keep more stuff out of the base, : > and remove some of the stuff that's in there now, is that it makes : > maintenance difficult across FreeBSD branches. We have a general = policy that : > if we have a major version N of something in a release branch that = we don't : > upgrade that major version without a really good reason to avoid = POLA : > surprises for our users. Once again using BIND as an example, this = has led : > to a really old and past-EOL version of BIND in FreeBSD 6 which I've only : > gotten away with because anyone doing serious DNS work nowadays has = to : > upgrade to at least 9.6 anyway. But it's an ugly situation, and I = don't want : > to repeat it. : > :=20 : I agree but like Aleksandr said, almost 70% of dhcp code is already in : base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea : to keep some parts in the ports tree and move out from the base. Yea. I agree too. Just because BIND was EOLd in 6 isn't a great argument against dhcp server. Most of the code is there anyway, and it isn't evolving as fast as BIND. It would be very convenient to have this particular thing in the base, and we shouldn't be too dogmatic about never having any new 3rd party things in the base. After all, we just added more compression utilities to the base, and nobody said a peep. This is analogous: we have good opportunity to integrate into the system, and users benefit from that integration. Warner ------------------------------ Message: 5 Date: Wed, 15 Sep 2010 10:53:00 -0400 From: Maxim Khitrov Subject: Re: buildworld + ccache trouble To: Dmitry Krivenok Cc: freebsd-current@freebsd.org Message-ID: Content-Type: text/plain; charset=3DUTF-8 On Wed, Sep 15, 2010 at 8:44 AM, Dmitry Krivenok wrote: > Hello All! > I recently updated to r212634 and tried to build CURRENT tree with = ccache. > > However, I got build error: > > > > Stop in /usr/src/lib/csu/i386-elf. > *** Error code 1 > > Is it a know issue? > Any solutions? If I remember correctly, this happens when you try to build 32-bit library set on amd64 (you do not have WITHOUT_LIB32 set in /etc/src.conf). My solution was to disable 32-bit support by setting that option. If you're still using ccache version 2.4, try upgrading to 3.0.1, though I'm not sure if this problem has been fix. The only other alternative that I know of is to not use ccache to buildworld on amd64. - Max ------------------------------ Message: 6 Date: Wed, 15 Sep 2010 15:19:50 +0000 (UTC) From: "Bjoern A. Zeeb" Subject: Re: TCP loopback socket fusing To: Andre Oppermann Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Message-ID: <20100915151632.E31898@maildrop.int.zabbadoz.net> Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed On Mon, 13 Sep 2010, Andre Oppermann wrote: Hey, > When a TCP connection via loopback back to localhost is made the whole > send, segmentation and receive path (with larger packets though) is = still > executed. This has some considerable overhead. > > To short-circuit the send and receive sockets on localhost TCP = connections > I've made a proof-of-concept patch that directly places the data in = the > other side's socket buffer without doing any packetization and other protocol > overhead (like UNIX domain sockets). The connections setup (SYN, = SYN-ACK, > ACK) and shutdown are still handled by normal TCP segments via = loopback so > that firewalling stills works. The actual payload data during the = session > won't be seen and the sequence numbers don't move other than for SYN = and FIN. > The sequence are remain valid though. Obviously tcpdump won't see any data > transfers either if the connection has fused sockets. > > Preliminary testing (with WITNESS and INVARIANTS enabled) has shown = stable > operation and a rough doubling of the throughput on loopback = connections. > I've tested most socket teardown cases and it behaves fine. I'm not entirely > sure I've got all possible path's but the way it is integrated should=20 > properly > defuse the sockets in all situations. Three comments in reverse order: 1 If S/S+A/A and shutdown aren't shortcut, can you always rely on proper payload order, especially in the shutdown case? 2 Given my experience with epairs, which are basically a loop with two interfaces and even interface queues, any significant delay you are seeing is _not_ due to longer code paths through the stack but simply because of the netisr. 3 If properly doing this for TCP, we should probably also do it for other protocols. /bz --=20 Bjoern A. Zeeb Welcome a new stage of life. ------------------------------ Message: 7 Date: Wed, 15 Sep 2010 16:23:53 +0100 From: Anton Shterenlikht Subject: multiple problems between r212316 and r212643 on ia64 To: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Message-ID: <20100915152353.GA45611@mech-anton240.men.bris.ac.uk> Content-Type: text/plain; charset=3Dus-ascii I just rebuilt world and kernel from r212316 to r212643 on ia64. man(1) doesn't work, I get: % man ls zcat: /usr/share/man/cat1/ls.1.gz already has .gz suffix -- unchanged % man man zcat: /usr/share/man/cat1/man.1.gz already has .gz suffix -- unchanged and so on for any command. sendmail doesn't work: # cd /etc/mail # make start Starting: sendmail-submitmailwrapper: no mapping in = /etc/mail/mailer.conf sendmail-clientmqueuemailwrapper: no mapping in /etc/mail/mailer.conf . #=20 Rebooting with 212316 kernel doesn't change anything. I cannot roll back to another revision because svn doesn't work: # cd /usr/src # svn up svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byte sequence #=20 I can build svn, but trying to install it, I get: *skip* /usr/bin/install -c -o root -g wheel -d /usr/local/share/locale/zh_TW/LC_MESSAGES cd subversion/po ; /usr/bin/install -c -o root -g wheel -m 644 zh_TW.mo /usr/local/share/locale/zh_TW/LC_MESSAGES/subversion.mo subversion/svnversion/svnversion . /repos/svn/trunk > /usr/local/include/subversion-1/svn-revision.txt svn: Can't open file '.svn/entries': Illegal byte sequence *** Error code 1 Stop in /usr/ports/devel/subversion-freebsd/work/subversion-1.6.12. *** Error code 1 In addition I get this in /var/log/messages: init: getty repeating too quickly on port /dev/ttyv8, sleeping 30 secs ntpd[976]: select() error: Resource temporarily unavailable last message repeated 29 times Please advise many thanks anton --=20 Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ------------------------------ Message: 8 Date: Wed, 15 Sep 2010 18:14:31 +0200 From: Gary Jennejohn Subject: Re: TCP loopback socket fusing To: Andre Oppermann Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Message-ID: <20100915181431.30677523@ernst.jennejohn.org> Content-Type: text/plain; charset=3DUS-ASCII On Mon, 13 Sep 2010, Andre Oppermann wrote: > Preliminary testing (with WITNESS and INVARIANTS enabled) has shown = stable > operation and a rough doubling of the throughput on loopback = connections. > I've tested most socket teardown cases and it behaves fine. I'm not entirely > sure I've got all possible path's but the way it is integrated should=20 > properly defuse the sockets in all situations. >=20 I tried this out with the following results: a) booted the new kernel, started X, started firefox -> hard hang, had = to reset the box to recover. Note that firefox uses wwwoffle as a local, caching proxy and wwwwoffle is accessed through localhost:8080 b) tried (a) again to make sure it wasn't a fluke -> same result c) booted anew but started opera instead, which does _not_ use wwwoffle as its proxy (net.inet.tcp.loopfuse=3D1) -> OK d) I then set net.inet.tcp.loopfuse=3D0 before starting firefox -> OK e) set net.inet.tcp.loopfuse=3D1 and ran cvsup to update my CVS tree followed by checking out the changed sources, which uses loopback to talk to cvsupd -> OK So, somewhow trying to access wwwoffle through localhost:8080 causes a hard hang of the box. Whether this has something to do with the port number or just strange behavior on the part of wwwoffle I can't say, because the hard hang makes debugging impossible. By hard hang I mean that there is no visible activity, gkrellm isn't updating, mouse and keyboard are ignored and ping from a different machine shows no reaction, so I'd say the kernel is pretty much wedged. For now I'm setting net.inet.tcp.loopfuse=3D0 in /etc/sysctl.conf. -- Gary Jennejohn ------------------------------ Message: 9 Date: Wed, 15 Sep 2010 17:48:07 +0200 From: Andre Oppermann Subject: Re: TCP loopback socket fusing To: "Bjoern A. Zeeb" Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Message-ID: <4C90EAB7.2000902@networx.ch> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed On 15.09.2010 17:19, Bjoern A. Zeeb wrote: > On Mon, 13 Sep 2010, Andre Oppermann wrote: > > Hey, > >> When a TCP connection via loopback back to localhost is made the = whole >> send, segmentation and receive path (with larger packets though) is = still >> executed. This has some considerable overhead. >> >> To short-circuit the send and receive sockets on localhost TCP connections >> I've made a proof-of-concept patch that directly places the data in = the >> other side's socket buffer without doing any packetization and other protocol >> overhead (like UNIX domain sockets). The connections setup (SYN, = SYN-ACK, >> ACK) and shutdown are still handled by normal TCP segments via = loopback so >> that firewalling stills works. The actual payload data during the = session >> won't be seen and the sequence numbers don't move other than for SYN = and FIN. >> The sequence are remain valid though. Obviously tcpdump won't see any data >> transfers either if the connection has fused sockets. >> >> Preliminary testing (with WITNESS and INVARIANTS enabled) has shown stable >> operation and a rough doubling of the throughput on loopback = connections. >> I've tested most socket teardown cases and it behaves fine. I'm not entirely >> sure I've got all possible path's but the way it is integrated should properly >> defuse the sockets in all situations. > > Three comments in reverse order: > > 1 If S/S+A/A and shutdown aren't shortcut, can you always rely on = proper > payload order, especially in the shutdown case? Yes. The payload is always directly placed in the receive socket buffer of the other socket, never in the send buffer. There is never any = unsent data left in the send buffer that could become reordered. > 2 Given my experience with epairs, which are basically a loop with two > interfaces and even interface queues, any significant delay you are > seeing is _not_ due to longer code paths through the stack but > simply because of the netisr. I haven't measured delay, only bandwidth. And that's with WITNESS and INVARIANTS enabled. You are probably right, the netisr is taking its toll. Especially the TCP_INFO lock may have some contention in the loopback case on SMP. Though a lot of mbuf allocations, packet manipulations and instructions (instruction cache) are avoided by fusing the sockets together. > 3 If properly doing this for TCP, we should probably also do it for > other protocols. UNIX domain sockets already do this. This implementation is particular for TCP and only touches the protocol specific parts. It's not done at the socket layer. For UDP it's not that easy to do as most UDP = connections are one-off packets and no permanent binding between two sockets exists. For SCTP I don't know. From glancing over the code it seems they have, at least partially, their own socket buffer code. How difficult a fused socket there would be I can't say. --=20 Andre ------------------------------ Message: 10 Date: Wed, 15 Sep 2010 11:40:28 -0600 From: "Jason J. W. Williams" Subject: ZFS Test Suite To: freebsd-current@freebsd.org Message-ID: Content-Type: text/plain; charset=3DISO-8859-1 Does the FreeBSD ZFS port get tested against the ZFS test suite created by Sun? It's a fairly comprehensive suite and has delivered a very reliable set of ZFS beta code for a long time. Trying to gauge the stability and compatibility of the FreeBSD port. Thank you in advance. -J ------------------------------ Message: 11 Date: Wed, 15 Sep 2010 11:27:24 -0700 From: Doug Barton Subject: Re: DHCP server in base To: "M. Warner Losh" Cc: freebsd-current@freebsd.org Message-ID: <4C91100C.5060502@FreeBSD.org> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed On 9/15/2010 7:25 AM, M. Warner Losh wrote: > Yea. I agree too. Just because BIND was EOLd in 6 isn't a great > argument against dhcp server. That rather clearly was not the only element of my argument, and not=20 only is it disingenuous for you to indicate that it was, I don't=20 appreciate you doing so. > Most of the code is there anyway, and it isn't evolving as fast as = BIND. That is actually a more rational argument, even if I don't agree with=20 it. FWIW, part of the reason that I don't agree with it is that at some=20 point, hopefully in the near future, we will want to include the DHCPv6=20 client in the mix somewhere; and when we do the code base is not going=20 to be as stable as we have enjoyed so far with the v4 dhclient. > It would be very convenient to have this particular thing in the base, > and we shouldn't be too dogmatic about never having any new 3rd party > things in the base. After all, we just added more compression > utilities to the base, and nobody said a peep. I actually thought that change was rather silly, but it was clear that=20 there was so much critical mass in favor of it that there was no point=20 in stating a dissenting opinion. As part of the project's leadership you = should be careful not to mistake silence for agreement, or worse, = support. > This is analogous: we > have good opportunity to integrate into the system, and users benefit > from that integration. Given your perspective of wanting more of a complete system in the base=20 I can certainly see how you would be supportive of this change. My=20 intent was to make the argument in a general way that this is the wrong=20 direction to go, and that users would benefit *more* from a robust=20 modularized system. The fact that the v4 DHCPd might accidentally be a=20 good candidate for including in the base today doesn't mean that doing=20 so is the right strategy for the long term. Doug --=20 ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ ------------------------------ Message: 12 Date: Wed, 15 Sep 2010 21:36:04 +0300 From: Alexander Motin Subject: Re: Multiple hpet messages during boot To: FreeBSD-Current Message-ID: <4C911214.7060406@FreeBSD.org> Content-Type: text/plain; charset=3DISO-8859-1 Joel Dahl wrote: > I noticed this during boot (HEAD from yesterday): >=20 > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] > hpet0: [FILTER] >=20 > Is it really necessary to print this 8 times? HPET at present chipsets may use up to 8 IRQs. Driver registers filter interrupt handlers for them. Interrupt handling code prints this. If you boot with verbose, you may see that some network cards prints alike things for the number of supported MSI/MSI-X interrupts. --=20 Alexander Motin ------------------------------ Message: 13 Date: Wed, 15 Sep 2010 13:36:55 -0500 From: Tom Judge Subject: Re: buildworld + ccache trouble To: Maxim Khitrov Cc: freebsd-current@freebsd.org, Dmitry Krivenok Message-ID: <4C911247.7010309@tomjudge.com> Content-Type: text/plain; charset=3DUTF-8 On 09/15/2010 09:53 AM, Maxim Khitrov wrote: > On Wed, Sep 15, 2010 at 8:44 AM, Dmitry Krivenok > wrote: > =20 >> Hello All! >> I recently updated to r212634 and tried to build CURRENT tree with ccache. >> >> However, I got build error: >> >> >> >> Stop in /usr/src/lib/csu/i386-elf. >> *** Error code 1 >> >> Is it a know issue? >> Any solutions? >> =20 > If I remember correctly, this happens when you try to build 32-bit > library set on amd64 (you do not have WITHOUT_LIB32 set in > /etc/src.conf). > > My solution was to disable 32-bit support by setting that option. If > you're still using ccache version 2.4, try upgrading to 3.0.1, though > I'm not sure if this problem has been fix. The only other alternative > that I know of is to not use ccache to buildworld on amd64. > =20 In the past I have used the solution outlined here: http://www.tomjudge.com/index.php/FreeBSD/Creating_a_%28i386/ia32%29_buil= d_c luster_using_amd64_and_i386_hosts This used to (in the 6.2 days) allow us to build i386 objects on amd64 hosts. It may work for you. Tom --=20 TJU13-ARIN ------------------------------ Message: 14 Date: Wed, 15 Sep 2010 22:47:00 +0300 From: Andriy Gapon Subject: Re: regarding pciids To: Alexander Best , freebsd-current@freebsd.org Message-ID: <4C9122B4.2040202@icyb.net.ua> Content-Type: text/plain; charset=3DISO-8859-1 on 14/09/2010 03:59 Alexander Best said the following: > hi there, >=20 > any thoughts on using http://pciids.sourceforge.net/ for pciids = instead of the > Hart and Boemler lists. the SF site seems to be updated more regularly = and > would get rid of the need to decide for each entry, whether to take = the Hart or > Boemler one. +1 FWIW Especially given that the format is what we use too (modulo subvendor, sub-etc) --=20 Andriy Gapon ------------------------------ Message: 15 Date: Wed, 15 Sep 2010 22:14:30 +0200 From: Dimitry Andric Subject: Re: buildworld + ccache trouble To: Dmitry Krivenok Cc: freebsd-current@freebsd.org Message-ID: <4C912926.6070409@FreeBSD.org> Content-Type: text/plain; charset=3D"iso-8859-1" On 2010-09-15 14:44, Dmitry Krivenok wrote: > I recently updated to r212634 and tried to build CURRENT tree with = ccache. ... > /usr/src/lib/csu/i386-elf/crt1_s.S:42: Error: `8(%ebp)' is not a valid > 64 bit base/index expression I assume this error occurs when building the 32-bit components on amd64. If so, can you please try the attached patch? It should fix the build32 stage with a non-default ${CC} setting. This also applies to building with clang, for instance. -------------- next part -------------- diff --git a/Makefile.inc1 b/Makefile.inc1 index a08e4ca..66d074f 100644 --- a/Makefile.inc1 +++ b/Makefile.inc1 @@ -299,15 +299,15 @@ LIB32WMAKEENV+=3D = MAKEOBJDIRPREFIX=3D${OBJTREE}/lib32 \ VERSION=3D"${VERSION}" \ INSTALL=3D"sh ${.CURDIR}/tools/install.sh" \ PATH=3D${TMPPATH} \ - CC=3D"${CC} ${LIB32FLAGS}" \ - CXX=3D"${CXX} ${LIB32FLAGS}" \ - OBJC=3D"${OBJC} ${LIB32FLAGS}" \ LIBDIR=3D/usr/lib32 \ SHLIBDIR=3D/usr/lib32 =20 LIB32WMAKE=3D ${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32BIT \ -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \ - -DWITHOUT_HTML -DNO_CTF DESTDIR=3D${LIB32TMP} + -DWITHOUT_HTML -DNO_CTF DESTDIR=3D${LIB32TMP} \ + CC=3D"${CC} ${LIB32FLAGS}" \ + CXX=3D"${CXX} ${LIB32FLAGS}" \ + OBJC=3D"${OBJC} ${LIB32FLAGS}" LIB32IMAKE=3D ${LIB32WMAKE:NINSTALL=3D*:NDESTDIR=3D*} -DNO_INCS .endif =20 ------------------------------ Message: 16 Date: Wed, 15 Sep 2010 17:49:44 -0400 From: John Baldwin Subject: Re: tun(4) in -CURRENT: No buffer space available - race condition patch To: freebsd-current@freebsd.org Cc: Marcin Cieslak Message-ID: <201009151749.45038.jhb@freebsd.org> Content-Type: Text/Plain; charset=3D"iso-8859-1" On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote: > Output queue of tun(4) gets full after some time when sending lots of data. > I have been observing this on -CURRENT at least since March this year. >=20 > Looks like it's a race condition (same in tun(4) and tap(4)),=20 > the following patch seems to address the issue: This is a good find. I actually went through these drivers a bit = further and=20 have a bit of a larger patch to extend the locking some. Would you care = to=20 test it? Index: if_tap.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- if_tap.c (revision 212557) +++ if_tap.c (working copy) @@ -209,7 +209,6 @@ tap_destroy(struct tap_softc *tp) { struct ifnet *ifp =3D tp->tap_ifp; - int s; =20 /* Unlocked read. */ KASSERT(!(tp->tap_flags & TAP_OPEN), @@ -217,10 +216,8 @@ =20 knlist_destroy(&tp->tap_rsel.si_note); destroy_dev(tp->tap_dev); - s =3D splimp(); ether_ifdetach(ifp); if_free_type(ifp, IFT_ETHER); - splx(s); =20 mtx_destroy(&tp->tap_mtx); free(tp, M_TAP); @@ -398,7 +395,7 @@ struct tap_softc *tp =3D NULL; unsigned short macaddr_hi; uint32_t macaddr_mid; - int unit, s; + int unit; char *name =3D NULL; u_char eaddr[6]; =20 @@ -449,15 +446,13 @@ dev->si_drv1 =3D tp; tp->tap_dev =3D dev; =20 - s =3D splimp(); ether_ifattach(ifp, eaddr); - splx(s); =20 mtx_lock(&tp->tap_mtx); tp->tap_flags |=3D TAP_INITED; mtx_unlock(&tp->tap_mtx); =20 - knlist_init_mtx(&tp->tap_rsel.si_note, NULL); + knlist_init_mtx(&tp->tap_rsel.si_note, &tp->tap_mtx); =20 TAPDEBUG("interface %s is created. minor =3D %#x\n",=20 ifp->if_xname, dev2unit(dev)); @@ -474,7 +469,7 @@ { struct tap_softc *tp =3D NULL; struct ifnet *ifp =3D NULL; - int error, s; + int error; =20 if (tapuopen =3D=3D 0) { error =3D priv_check(td, PRIV_NET_TAP); @@ -497,15 +492,13 @@ tp->tap_pid =3D td->td_proc->p_pid; tp->tap_flags |=3D TAP_OPEN; ifp =3D tp->tap_ifp; - mtx_unlock(&tp->tap_mtx); =20 - s =3D splimp(); ifp->if_drv_flags |=3D IFF_DRV_RUNNING; ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE; if (tapuponopen) ifp->if_flags |=3D IFF_UP; + mtx_unlock(&tp->tap_mtx); if_link_state_change(ifp, LINK_STATE_UP); - splx(s); =20 TAPDEBUG("%s is open. minor =3D %#x\n", ifp->if_xname, dev2unit(dev)); =20 @@ -524,7 +517,6 @@ struct ifaddr *ifa; struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; - int s; =20 /* junk all pending output */ IF_DRAIN(&ifp->if_snd); @@ -537,25 +529,24 @@ mtx_lock(&tp->tap_mtx); if (((tp->tap_flags & TAP_VMNET) =3D=3D 0) && (ifp->if_flags & = IFF_UP)) { mtx_unlock(&tp->tap_mtx); - s =3D splimp(); if_down(ifp); + mtx_lock(&tp->tap_mtx); if (ifp->if_drv_flags & IFF_DRV_RUNNING) { + ifp->if_drv_flags &=3D ~IFF_DRV_RUNNING; + mtx_unlock(&tp->tap_mtx); TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { rtinit(ifa, (int)RTM_DELETE, 0); } if_purgeaddrs(ifp); - ifp->if_drv_flags &=3D ~IFF_DRV_RUNNING; + mtx_lock(&tp->tap_mtx); } - splx(s); - } else - mtx_unlock(&tp->tap_mtx); + } =20 if_link_state_change(ifp, LINK_STATE_DOWN); funsetown(&tp->tap_sigio); selwakeuppri(&tp->tap_rsel, PZERO+1); - KNOTE_UNLOCKED(&tp->tap_rsel.si_note, 0); + KNOTE_LOCKED(&tp->tap_rsel.si_note, 0); =20 - mtx_lock(&tp->tap_mtx); tp->tap_flags &=3D ~TAP_OPEN; tp->tap_pid =3D 0; mtx_unlock(&tp->tap_mtx); @@ -580,8 +571,10 @@ =20 TAPDEBUG("initializing %s\n", ifp->if_xname); =20 + mtx_lock(&tp->tap_mtx); ifp->if_drv_flags |=3D IFF_DRV_RUNNING; ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE; + mtx_unlock(&tp->tap_mtx); =20 /* attempt to start output */ tapifstart(ifp); @@ -599,7 +592,7 @@ struct tap_softc *tp =3D ifp->if_softc; struct ifreq *ifr =3D (struct ifreq *)data; struct ifstat *ifs =3D NULL; - int s, dummy; + int dummy; =20 switch (cmd) { case SIOCSIFFLAGS: /* XXX -- just like vmnet does */ @@ -612,7 +605,6 @@ break; =20 case SIOCGIFSTATUS: - s =3D splimp(); ifs =3D (struct ifstat *)data; dummy =3D strlen(ifs->ascii); mtx_lock(&tp->tap_mtx); @@ -621,14 +613,10 @@ sizeof(ifs->ascii) - dummy, "\tOpened by PID %d\n", tp->tap_pid); mtx_unlock(&tp->tap_mtx); - splx(s); break; =20 default: - s =3D splimp(); - dummy =3D ether_ioctl(ifp, cmd, data); - splx(s); - return (dummy); + return (ether_ioctl(ifp, cmd, data)); /* NOT REACHED */ } =20 @@ -645,7 +633,6 @@ tapifstart(struct ifnet *ifp) { struct tap_softc *tp =3D ifp->if_softc; - int s; =20 TAPDEBUG("%s starting\n", ifp->if_xname); =20 @@ -665,24 +652,19 @@ TAPDEBUG("%s not ready, tap_flags =3D 0x%x\n", ifp->if_xname,=20 tp->tap_flags); =20 - s =3D splimp(); do { IF_DEQUEUE(&ifp->if_snd, m); if (m !=3D NULL) m_freem(m); ifp->if_oerrors ++; } while (m !=3D NULL); - splx(s); =20 return; } - mtx_unlock(&tp->tap_mtx); =20 - s =3D splimp(); ifp->if_drv_flags |=3D IFF_DRV_OACTIVE; =20 - if (ifp->if_snd.ifq_len !=3D 0) { - mtx_lock(&tp->tap_mtx); + if (!IFQ_IS_EMPTY(&ifp->if_snd)) { if (tp->tap_flags & TAP_RWAIT) { tp->tap_flags &=3D ~TAP_RWAIT; wakeup(tp); @@ -691,16 +673,16 @@ if ((tp->tap_flags & TAP_ASYNC) && (tp->tap_sigio !=3D NULL)) { mtx_unlock(&tp->tap_mtx); pgsigio(&tp->tap_sigio, SIGIO, 0); - } else - mtx_unlock(&tp->tap_mtx); + mtx_lock(&tp->tap_mtx); + } =20 selwakeuppri(&tp->tap_rsel, PZERO+1); - KNOTE_UNLOCKED(&tp->tap_rsel.si_note, 0); + KNOTE_LOCKED(&tp->tap_rsel.si_note, 0); ifp->if_opackets ++; /* obytes are counted in ether_output */ } =20 ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE; - splx(s); + mtx_unlock(&tp->tap_mtx); } /* tapifstart */ =20 =20 @@ -715,7 +697,6 @@ struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; struct tapinfo *tapp =3D NULL; - int s; int f; #if defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD5) || \ defined(COMPAT_FREEBSD4) @@ -724,12 +705,10 @@ =20 switch (cmd) { case TAPSIFINFO: - s =3D splimp(); tapp =3D (struct tapinfo *)data; ifp->if_mtu =3D tapp->mtu; ifp->if_type =3D tapp->type; ifp->if_baudrate =3D tapp->baudrate; - splx(s); break; =20 case TAPGIFINFO: @@ -757,26 +736,26 @@ break; =20 case FIOASYNC: - s =3D splimp(); mtx_lock(&tp->tap_mtx); if (*(int *)data) tp->tap_flags |=3D TAP_ASYNC; else tp->tap_flags &=3D ~TAP_ASYNC; mtx_unlock(&tp->tap_mtx); - splx(s); break; =20 case FIONREAD: - s =3D splimp(); - if (ifp->if_snd.ifq_head) { - struct mbuf *mb =3D ifp->if_snd.ifq_head; + if (!IFQ_IS_EMPTY(&ifp->if_snd)) { + struct mbuf *mb; =20 - for(*(int *)data =3D 0;mb !=3D NULL;mb =3D mb->m_next) + IFQ_LOCK(&ifp->if_snd); + IFQ_POLL_NOLOCK(&ifp->if_snd, mb); + for (*(int *)data =3D 0; mb !=3D NULL; + mb =3D mb->m_next) *(int *)data +=3D mb->m_len; + IFQ_UNLOCK(&ifp->if_snd); } else *(int *)data =3D 0; - splx(s); break; =20 case FIOSETOWN: @@ -797,10 +776,6 @@ =20 /* VMware/VMnet port ioctl's */ =20 - case SIOCGIFFLAGS: /* get ifnet flags */ - bcopy(&ifp->if_flags, data, sizeof(ifp->if_flags)); - break; - #if defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD5) || \ defined(COMPAT_FREEBSD4) case _IO('V', 0): @@ -814,9 +789,9 @@ f &=3D ~IFF_CANTCHANGE; f |=3D IFF_UP; =20 - s =3D splimp(); + mtx_lock(&tp->tap_mtx); ifp->if_flags =3D f | (ifp->if_flags & IFF_CANTCHANGE); - splx(s); + mtx_unlock(&tp->tap_mtx); break; =20 case OSIOCGIFADDR: /* get MAC address of the remote side */ @@ -851,7 +826,7 @@ struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; struct mbuf *m =3D NULL; - int error =3D 0, len, s; + int error =3D 0, len; =20 TAPDEBUG("%s reading, minor =3D %#x\n", ifp->if_xname, dev2unit(dev)); =20 @@ -867,26 +842,27 @@ } =20 tp->tap_flags &=3D ~TAP_RWAIT; - mtx_unlock(&tp->tap_mtx); =20 /* sleep until we get a packet */ do { - s =3D splimp(); IF_DEQUEUE(&ifp->if_snd, m); - splx(s); =20 if (m =3D=3D NULL) { - if (flag & O_NONBLOCK) + if (flag & O_NONBLOCK) { + mtx_unlock(&tp->tap_mtx); return (EWOULDBLOCK); + } =20 - mtx_lock(&tp->tap_mtx); tp->tap_flags |=3D TAP_RWAIT; - mtx_unlock(&tp->tap_mtx); - error =3D tsleep(tp,PCATCH|(PZERO+1),"taprd",0); - if (error) + error =3D mtx_sleep(tp, &tp->tap_mtx, PCATCH | (PZERO + 1), + "taprd", 0); + if (error) { + mtx_unlock(&tp->tap_mtx); return (error); + } } } while (m =3D=3D NULL); + mtx_unlock(&tp->tap_mtx); =20 /* feed packet to bpf */ BPF_MTAP(ifp, m); @@ -982,14 +958,14 @@ { struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; - int s, revents =3D 0; + int revents =3D 0; =20 TAPDEBUG("%s polling, minor =3D %#x\n",=20 ifp->if_xname, dev2unit(dev)); =20 - s =3D splimp(); if (events & (POLLIN | POLLRDNORM)) { - if (ifp->if_snd.ifq_len > 0) { + IFQ_LOCK(&ifp->if_snd); + if (!IFQ_IS_EMPTY(&ifp->if_snd)) { TAPDEBUG("%s have data in queue. len =3D %d, " \ "minor =3D %#x\n", ifp->if_xname, ifp->if_snd.ifq_len, dev2unit(dev)); @@ -1001,12 +977,12 @@ =20 selrecord(td, &tp->tap_rsel); } + IFQ_UNLOCK(&ifp->if_snd); } =20 if (events & (POLLOUT | POLLWRNORM)) revents |=3D (events & (POLLOUT | POLLWRNORM)); =20 - splx(s); return (revents); } /* tappoll */ =20 @@ -1019,11 +995,9 @@ static int tapkqfilter(struct cdev *dev, struct knote *kn) { - int s; struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; =20 - s =3D splimp(); switch (kn->kn_filter) { case EVFILT_READ: TAPDEBUG("%s kqfilter: EVFILT_READ, minor =3D %#x\n", @@ -1040,11 +1014,9 @@ default: TAPDEBUG("%s kqfilter: invalid filter, minor =3D %#x\n", ifp->if_xname, dev2unit(dev)); - splx(s); return (EINVAL); /* NOT REACHED */ } - splx(s); =20 kn->kn_hook =3D (caddr_t) dev; knlist_add(&tp->tap_rsel.si_note, kn, 0); @@ -1061,12 +1033,11 @@ static int tapkqread(struct knote *kn, long hint) { - int ret, s; + int ret; struct cdev *dev =3D (struct cdev *)(kn->kn_hook); struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; =20 - s =3D splimp(); if ((kn->kn_data =3D ifp->if_snd.ifq_len) > 0) { TAPDEBUG("%s have data in queue. len =3D %d, minor =3D %#x\n", ifp->if_xname, ifp->if_snd.ifq_len, dev2unit(dev)); @@ -1076,7 +1047,6 @@ ifp->if_xname, dev2unit(dev)); ret =3D 0; } - splx(s); =20 return (ret); } /* tapkqread */ @@ -1090,13 +1060,10 @@ static int tapkqwrite(struct knote *kn, long hint) { - int s; struct tap_softc *tp =3D ((struct cdev *) kn->kn_hook)->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; =20 - s =3D splimp(); kn->kn_data =3D ifp->if_mtu; - splx(s); =20 return (1); } /* tapkqwrite */ Index: if_tun.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- if_tun.c (revision 212557) +++ if_tun.c (working copy) @@ -344,13 +344,13 @@ tp->tun_flags &=3D ~TUN_RWAIT; wakeup(tp); } + selwakeuppri(&tp->tun_rsel, PZERO + 1); + KNOTE_LOCKED(&tp->tun_rsel.si_note, 0); if (tp->tun_flags & TUN_ASYNC && tp->tun_sigio) { mtx_unlock(&tp->tun_mtx); pgsigio(&tp->tun_sigio, SIGIO, 0); } else mtx_unlock(&tp->tun_mtx); - selwakeuppri(&tp->tun_rsel, PZERO + 1); - KNOTE_UNLOCKED(&tp->tun_rsel.si_note, 0); } =20 /* XXX: should return an error code so it can fail. */ @@ -385,7 +385,7 @@ IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); ifp->if_snd.ifq_drv_maxlen =3D 0; IFQ_SET_READY(&ifp->if_snd); - knlist_init_mtx(&sc->tun_rsel.si_note, NULL); + knlist_init_mtx(&sc->tun_rsel.si_note, &sc->tun_mtx); ifp->if_capabilities |=3D IFCAP_LINKSTATE; ifp->if_capenable |=3D IFCAP_LINKSTATE; =20 @@ -443,7 +443,6 @@ { struct tun_softc *tp; struct ifnet *ifp; - int s; =20 tp =3D dev->si_drv1; ifp =3D TUN2IFP(tp); @@ -451,27 +450,25 @@ mtx_lock(&tp->tun_mtx); tp->tun_flags &=3D ~TUN_OPEN; tp->tun_pid =3D 0; - mtx_unlock(&tp->tun_mtx); =20 /* * junk all pending output */ CURVNET_SET(ifp->if_vnet); - s =3D splimp(); IFQ_PURGE(&ifp->if_snd); - splx(s); =20 if (ifp->if_flags & IFF_UP) { - s =3D splimp(); + mtx_unlock(&tp->tun_mtx); if_down(ifp); - splx(s); + mtx_lock(&tp->tun_mtx); } =20 /* Delete all addresses and routes which reference this interface. */ if (ifp->if_drv_flags & IFF_DRV_RUNNING) { struct ifaddr *ifa; =20 - s =3D splimp(); + ifp->if_drv_flags &=3D ~IFF_DRV_RUNNING; + mtx_unlock(&tp->tun_mtx); TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { /* deal w/IPv4 PtP destination; unlocked read */ if (ifa->ifa_addr->sa_family =3D=3D AF_INET) { @@ -482,16 +479,14 @@ } } if_purgeaddrs(ifp); - ifp->if_drv_flags &=3D ~IFF_DRV_RUNNING; - splx(s); + mtx_lock(&tp->tun_mtx); } if_link_state_change(ifp, LINK_STATE_DOWN); CURVNET_RESTORE(); =20 - mtx_lock(&tp->tun_mtx); funsetown(&tp->tun_sigio); selwakeuppri(&tp->tun_rsel, PZERO + 1); - KNOTE_UNLOCKED(&tp->tun_rsel.si_note, 0); + KNOTE_LOCKED(&tp->tun_rsel.si_note, 0); TUNDEBUG (ifp, "closed\n"); =20 cv_broadcast(&tp->tun_cv); @@ -510,9 +505,11 @@ =20 TUNDEBUG(ifp, "tuninit\n"); =20 + mtx_lock(&tp->tun_mtx); ifp->if_flags |=3D IFF_UP; ifp->if_drv_flags |=3D IFF_DRV_RUNNING; getmicrotime(&ifp->if_lastchange); + mtx_unlock(&tp->tun_mtx); =20 #ifdef INET if_addr_rlock(ifp); @@ -545,9 +542,8 @@ struct ifreq *ifr =3D (struct ifreq *)data; struct tun_softc *tp =3D ifp->if_softc; struct ifstat *ifs; - int error =3D 0, s; + int error =3D 0; =20 - s =3D splimp(); switch(cmd) { case SIOCGIFSTATUS: ifs =3D (struct ifstat *)data; @@ -576,7 +572,6 @@ default: error =3D EINVAL; } - splx(s); return (error); } =20 @@ -682,7 +677,6 @@ static int tunioctl(struct cdev *dev, u_long cmd, caddr_t data, int flag, struct thread=20 *td) { - int s; int error; struct tun_softc *tp =3D dev->si_drv1; struct tuninfo *tunp; @@ -745,9 +739,11 @@ switch (*(int *)data & ~IFF_MULTICAST) { case IFF_POINTOPOINT: case IFF_BROADCAST: + mtx_lock(&tp->tun_mtx); TUN2IFP(tp)->if_flags &=3D ~(IFF_BROADCAST|IFF_POINTOPOINT|IFF_MULTICAST); TUN2IFP(tp)->if_flags |=3D *(int *)data; + mtx_unlock(&tp->tun_mtx); break; default: return(EINVAL); @@ -769,17 +765,15 @@ mtx_unlock(&tp->tun_mtx); break; case FIONREAD: - s =3D splimp(); if (!IFQ_IS_EMPTY(&TUN2IFP(tp)->if_snd)) { struct mbuf *mb; IFQ_LOCK(&TUN2IFP(tp)->if_snd); IFQ_POLL_NOLOCK(&TUN2IFP(tp)->if_snd, mb); - for( *(int *)data =3D 0; mb !=3D 0; mb =3D mb->m_next) + for (*(int *)data =3D 0; mb !=3D NULL; mb =3D mb->m_next) *(int *)data +=3D mb->m_len; IFQ_UNLOCK(&TUN2IFP(tp)->if_snd); } else *(int *)data =3D 0; - splx(s); break; case FIOSETOWN: return (fsetown(*(int *)data, &tp->tun_sigio)); @@ -813,7 +807,7 @@ struct tun_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D TUN2IFP(tp); struct mbuf *m; - int error=3D0, len, s; + int error=3D0, len; =20 TUNDEBUG (ifp, "read\n"); mtx_lock(&tp->tun_mtx); @@ -824,27 +818,24 @@ } =20 tp->tun_flags &=3D ~TUN_RWAIT; - mtx_unlock(&tp->tun_mtx); =20 - s =3D splimp(); do { IFQ_DEQUEUE(&ifp->if_snd, m); if (m =3D=3D NULL) { if (flag & O_NONBLOCK) { - splx(s); + mtx_unlock(&tp->tun_mtx); return (EWOULDBLOCK); } - mtx_lock(&tp->tun_mtx); tp->tun_flags |=3D TUN_RWAIT; - mtx_unlock(&tp->tun_mtx); - if ((error =3D tsleep(tp, PCATCH | (PZERO + 1), - "tunread", 0)) !=3D 0) { - splx(s); + error =3D mtx_sleep(tp, &tp->tun_mtx, PCATCH | (PZERO + 1), + "tunread", 0); + if (error !=3D 0) { + mtx_unlock(&tp->tun_mtx); return (error); } } } while (m =3D=3D NULL); - splx(s); + mtx_unlock(&tp->tun_mtx); =20 while (m && uio->uio_resid > 0 && error =3D=3D 0) { len =3D min(uio->uio_resid, m->m_len); @@ -957,13 +948,11 @@ static int tunpoll(struct cdev *dev, int events, struct thread *td) { - int s; struct tun_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D TUN2IFP(tp); int revents =3D 0; struct mbuf *m; =20 - s =3D splimp(); TUNDEBUG(ifp, "tunpoll\n"); =20 if (events & (POLLIN | POLLRDNORM)) { @@ -981,7 +970,6 @@ if (events & (POLLOUT | POLLWRNORM)) revents |=3D events & (POLLOUT | POLLWRNORM); =20 - splx(s); return (revents); } =20 @@ -991,11 +979,9 @@ static int tunkqfilter(struct cdev *dev, struct knote *kn) { - int s; struct tun_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D TUN2IFP(tp); =20 - s =3D splimp(); switch(kn->kn_filter) { case EVFILT_READ: TUNDEBUG(ifp, "%s kqfilter: EVFILT_READ, minor =3D %#x\n", @@ -1012,10 +998,8 @@ default: TUNDEBUG(ifp, "%s kqfilter: invalid filter, minor =3D %#x\n", ifp->if_xname, dev2unit(dev)); - splx(s); return(EINVAL); } - splx(s); =20 kn->kn_hook =3D (caddr_t) dev; knlist_add(&tp->tun_rsel.si_note, kn, 0); @@ -1029,12 +1013,11 @@ static int tunkqread(struct knote *kn, long hint) { - int ret, s; + int ret; struct cdev *dev =3D (struct cdev *)(kn->kn_hook); struct tun_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D TUN2IFP(tp); =20 - s =3D splimp(); if ((kn->kn_data =3D ifp->if_snd.ifq_len) > 0) { TUNDEBUG(ifp, "%s have data in the queue. Len =3D %d, minor =3D %#x\n", @@ -1046,7 +1029,6 @@ dev2unit(dev)); ret =3D 0; } - splx(s); =20 return (ret); } @@ -1057,13 +1039,10 @@ static int tunkqwrite(struct knote *kn, long hint) { - int s; struct tun_softc *tp =3D ((struct cdev *)kn->kn_hook)->si_drv1; struct ifnet *ifp =3D TUN2IFP(tp); =20 - s =3D splimp(); kn->kn_data =3D ifp->if_mtu; - splx(s); =20 return (1); } --=20 John Baldwin ------------------------------ Message: 17 Date: Wed, 15 Sep 2010 21:57:34 +0000 (UTC) From: Marcin Cieslak Subject: Re: tun(4) in -CURRENT: No buffer space available - race condition patch To: freebsd-current@freebsd.org Message-ID: Content-Type: text/plain; charset=3DUTF-8 Dnia 15.09.2010 John Baldwin napisaE=02/a: > On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote: >> Output queue of tun(4) gets full after some time when sending lots of data. >> I have been observing this on -CURRENT at least since March this = year. >>=20 >> Looks like it's a race condition (same in tun(4) and tap(4)),=20 >> the following patch seems to address the issue: > > This is a good find. I actually went through these drivers a bit = further and=20 > have a bit of a larger patch to extend the locking some. Would you = care to=20 > test it? Sure, I am installing it right now (for if_tun right now). There are also a LORs during tunclose (I always get one of them when = closing the tunnel): -------8<----------------------------------------------------------------= --- ------- lock order reversal: 1st 0xc24db8c8 rtentry (rtentry) @ /usr/src/sys/net/route.c:370 2nd 0xc2472a04 if_afdata (if_afdata) @ = /usr/src/sys/netinet6/scope6.c:417 KDB: stack backtrace: db_trace_self_wrapper(c0a4b284,cce14714,c0723185,c0715b2b,c0a4d1f8,...) = at db_trace_self_wrapper+0x26 kdb_backtrace(c0715b2b,c0a4d1f8,c0c4f308,c21186e8,cce1476c,...) at kdb_backtrace+0x29 _witness_debugger(c0a4d1f8,c2472a04,c0a539ec,c211dfe0,c0a63771,...) at _witness_debugger+0x25 witness_checkorder(c2472a04,9,c0a63771,1a1,0,...) at witness_checkorder+0x6aa _rw_wlock(c2472a04,c0a63771,1a1,0,c2472a04,...) at _rw_wlock+0x38 in6_setscope(cce148c4,c2472800,0,cce147fc,cce147e0,...) at = in6_setscope+0x30 in6_purgeaddr(c2539600,0,0,c211e048,c2362364,...) at in6_purgeaddr+0x4af if_purgeaddrs(c2472800,2,0,1cd,c24ab4c0,...) at if_purgeaddrs+0xb0 tunclose(c24d1000,3,2000,c23622c0,1,...) at tunclose+0x197 giant_close(c24d1000,3,2000,c23622c0,c23622c0,...) at giant_close+0x6e devfs_close(cce14a78,cce14a9c,c07785fb,c0aae500,cce14a78,...) at devfs_close+0x2a9 VOP_CLOSE_APV(c0aae500,cce14a78,c0a532d0,12d,c0af0160,...) at VOP_CLOSE_APV+0x42 vn_close(c24ccaa0,3,c2160c80,c23622c0,c23622c0,...) at vn_close+0xdb vn_closefile(c24bc0e0,c23622c0,c24bc0e0,0,cce14b28,...) at = vn_closefile+0xe4 devfs_close_f(c24bc0e0,c23622c0,3,0,c24bc0e0,...) at devfs_close_f+0x2b _fdrop(c24bc0e0,c23622c0,cce14b5c,c072327c,0,...) at _fdrop+0x43 closef(c24bc0e0,c23622c0,721,71e,c2362364,...) at closef+0x277 fdfree(c23622c0,0,c0a4549c,107,80000000,...) at fdfree+0x3ba exit1(c23622c0,0,cce14c7c,c071da4a,c23622c0,...) at exit1+0x465 sys_exit(c23622c0,cce14cec,stray irq7 c06a7bac,1,0,...) at sys_exit+0x1d syscallenter(c23622c0,cce14ce4,c06d6stray irq7 d5d,c0cae934,8,...) at syscallenter+0x25a syscall(cce14d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (1, FreeBSD ELF32, sys_exit), eipstray irq7 =3D 0x28128acf, esp =3D 0xbfbfed80, ebp =3D 0xbfbfed8c --- ^Ctun0: link state changed to DOWN -------8<----------------------------------------------------------------= --- ------- lock order reversal: 1st 0xc24db8c8 rtentrystray irq7 (rtentry) @ /usr/src/sys/net/route.c:370 2nd 0xc2482604 if_afdata (if_afdata) @ = /usr/src/sys/netinet6/scope6.c:417 KDB: stack backtrace: db_trace_self_wrapper(c0a4912e,cce16714,c0723105,c0715aab,c0a4b0a2,...) = at db_trace_self_wrapper+0x26 kdb_backtrace(c0715aab,c0a4b0a2,c0c4cb58,c21176e8,cce1676c,...) at kdb_backtrace+0x29 _witness_debugger(c0a4b0a2,c2482604,c0a51896,c211cfe0,c0a6137e,...) at _witness_debugger+0x25 witness_checkorder(c2482604,9,c0a6137e,1a1,0,...) at witness_checkorder+0x6aa _rw_wlock(c2482604,c0a613stray irq7 7e,1a1,c0793997,c2482604,...) at _rw_wlock+0x38 in6_setscope(cce168c4,c2482400,0,cce167fc,cce167e0,...) at = in6_setscope+0x30 in6_purgeaddr(c253e000,0,0,c211d048,c2361364,...) at in6_purgeaddr+0x4af if_purgeaddrs(c2482400,2,0,1cd,c24aa5c0,...) at if_purgeaddrs+0xb0 tunclose(c2539a00,3,2000,c23612c0,1,...) at tunclose+0x136 giant_close(c2539a00,3,2000,c23612c0,c23612c0,...) at giant_close+0x6e devfs_close(cce16a78,cce16a9c,c077857b,c0aac0e0,cce16a78,...) at devfs_close+0x2a9 VOP_CLOSE_APV(c0aac0e0,cce16a78,c0a5117a,12d,c0aedac0,...) at VOP_CLOSE_APV+0x42 vn_close(c25d2770,3,c215fc80,c23612c0,c0b10180,...) at vn_close+0xdb vn_closefile(c24bba10,c23612c0,c24bba10,0,cce16b28,...) at = vn_closefile+0xe4 devfs_close_f(c24bba10,c23612c0,3,0,c24bba10,...) at devfs_close_f+0x2b _fdrop(c24bba10,c23612c0,cce16b5c,c07231fc,0,...) at _fdrop+0x43 closef(c24bba10,c23612c0,721,71e,c2361364,...) at closef+0x277 fdfree(c23612c0,0,c0a43346,107,c2361364,...) at fdfree+0x3ba exit1(c23612c0,0,cce16c7c,c071d9ca,c23612c0,...) at exit1+0x465 sys_exit(c23612c0,cce16cec,28087460,1,0,...) at sys_exit+0x1d syscallenter(c23612c0,cce16ce4,c09a564e,c23612c0,cce16d28,...) at syscallenter+0x25a syscall(cce16d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (1, FreeBSD ELF32, sys_exit), eip =3D 0x28128acf, esp =3D 0xbfbfed80, ebp =3D 0xbfbfed8c --- tun0: link state changed to DOWN -------8<----------------------------------------------------------------= --- ------- --Marcin ------------------------------ Message: 18 Date: Wed, 15 Sep 2010 22:08:32 +0000 From: Alexander Best Subject: WITHOUT_BIND=3Dtrue and `make delete-old` To: freebsd-current@freebsd.org Message-ID: <20100915220832.GA24698@freebsd.org> Content-Type: text/plain; charset=3Dus-ascii hi there, just wanted to ask if the following entries from BSD.include.dist: "lwres" and BSD.usr.dist: "bind9" (including arm and misc) could be moved to BIND.chroot.dist so `make delete-old` doesn't have to remove those directories after every installworld and WITHOUT_BIND=3Dtrue? cheers. alex --=20 a13x ------------------------------ Message: 19 Date: Wed, 15 Sep 2010 14:23:26 -0700 From: Marcel Moolenaar Subject: Re: multiple problems between r212316 and r212643 on ia64 To: Anton Shterenlikht Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Message-ID: <5667FD77-8DBC-4638-80B6-67BCF9D4FB29@mac.com> Content-Type: text/plain; charset=3Dus-ascii On Sep 15, 2010, at 8:23 AM, Anton Shterenlikht wrote: >=20 > % man ls > zcat: /usr/share/man/cat1/ls.1.gz already has .gz suffix -- unchanged > % man man > zcat: /usr/share/man/cat1/man.1.gz already has .gz suffix -- unchanged >=20 >=20 > # cd /etc/mail > # make start > Starting: sendmail-submitmailwrapper: no mapping in = /etc/mail/mailer.conf > sendmail-clientmqueuemailwrapper: no mapping in /etc/mail/mailer.conf > . > #=20 >=20 > # cd /usr/src > # svn up > svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byte sequence > #=20 >=20 I think your file system is borked. Nonetheless, let me upgrade myself and see if I run onto it too. --=20 Marcel Moolenaar xcllnt@mac.com ------------------------------ Message: 20 Date: Wed, 15 Sep 2010 20:47:22 -0400 From: jhell Subject: Re: ZFS Test Suite To: "Jason J. W. Williams" Cc: freebsd-current@freebsd.org Message-ID: <4C91691A.9040207@DataIX.net> Content-Type: text/plain; charset=3DISO-8859-1 On 09/15/2010 13:40, Jason J. W. Williams wrote: > Does the FreeBSD ZFS port get tested against the ZFS test suite > created by Sun? It's a fairly comprehensive suite and has delivered a > very reliable set of ZFS beta code for a long time. Trying to gauge > the stability and compatibility of the FreeBSD port. Thank you in > advance. >=20 Got a download link. Seems from this point on hub.opensolaris.org is = down. --=20 jhell,v ------------------------------ Message: 21 Date: Wed, 15 Sep 2010 19:45:14 -0600 From: "Jason J. W. Williams" Subject: Re: ZFS Test Suite To: jhell Cc: "freebsd-current@freebsd.org" Message-ID: Content-Type: text/plain; charset=3DISO-8859-1 Yeah...Oracle closed the gate. Illumos.org probably has a copy in their fork though. -J On Wednesday, September 15, 2010, jhell wrote: > On 09/15/2010 13:40, Jason J. W. Williams wrote: >> Does the FreeBSD ZFS port get tested against the ZFS test suite >> created by Sun? It's a fairly comprehensive suite and has delivered a >> very reliable set of ZFS beta code for a long time. Trying to gauge >> the stability and compatibility of the FreeBSD port. Thank you in >> advance. >> > > Got a download link. Seems from this point on hub.opensolaris.org is = down. > > -- > > jhell,v > ------------------------------ Message: 22 Date: Wed, 15 Sep 2010 22:14:17 -0400 From: Gary Palmer Subject: Re: ZFS Test Suite To: jhell Cc: "Jason J. W. Williams" , freebsd-current@freebsd.org Message-ID: <20100916021417.GB381@in-addr.com> Content-Type: text/plain; charset=3Dus-ascii On Wed, Sep 15, 2010 at 08:47:22PM -0400, jhell wrote: > On 09/15/2010 13:40, Jason J. W. Williams wrote: > > Does the FreeBSD ZFS port get tested against the ZFS test suite > > created by Sun? It's a fairly comprehensive suite and has delivered = a > > very reliable set of ZFS beta code for a long time. Trying to gauge > > the stability and compatibility of the FreeBSD port. Thank you in > > advance. > >=20 >=20 > Got a download link. Seems from this point on hub.opensolaris.org is = down. http://hub.opensolaris.org/bin/view/Community+Group+zfs/zfstestsuite = pointed me at http://dlc.sun.com/osol/test/downloads/current/=20 The stcnv-zfs-src-20090909.tar.bz2 file was able to be downloaded from the 2nd link and produced a 4.1MB file with about 1565 entries in it according to tar -ztf. Note that I don't run ZFS here so I can't try = the test suite. Regards, Gary ------------------------------ Message: 23 Date: Wed, 15 Sep 2010 20:13:02 -0700 From: David Ehrmann Subject: Re: NFS lockups with VMware esxi client To: Rick Macklem Cc: freebsd-current@freebsd.org Message-ID: <4C918B3E.1070107@gmail.com> Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed Rick Macklem wrote: >> I have NFS sharing a ZFS pool that VMware esxi stores files on. When >> put under stress (an OS installation, but not Linux compilation), the >> NFS server locks, spiking to 100% CPU usage. Not even kill -KILL can >> stop the process, so rebooting is required. >> =20 > I believe it is patched in head/current. A compatible patch is at: > http://people.freebsd.org/~rmacklem/freebsd8.1-patches/replay.patch > > rick > =20 It worked! I grabbed the latest from STABLE, checked, saw that patch=20 was already in, compiled, and it's working. Thank you. ------------------------------ Message: 24 Date: Wed, 15 Sep 2010 19:07:03 -0700 From: joe mcguckin Subject: Can't build PERL under 8.1 Release To: freebsd-current@freebsd.org Message-ID: <1C9F72B8-26BC-4A03-AD81-3616A8AA8CA3@via.net> Content-Type: text/plain; charset=3Dus-ascii I just installed 8.1 Release. Trying to build Perl, it dies at: Running Makefile.PL in ext/DynaLoader ../../miniperl -I../../lib Makefile.PL INSTALLDIRS=3Dperl = INSTALLMAN1DIR=3Dnone INSTALLMAN3DIR=3Dnone PERL_CORE=3D1 LIBPERL_A=3Dlibperl.so = LINKTYPE=3Dstatic Writing Makefile for DynaLoader Makefile out-of-date with respect to Makefile.PL Cleaning current config before rebuilding Makefile... make -f Makefile.old clean > /dev/null 2>&1 ../../miniperl "-I../../lib" "-I../../lib" Makefile.PL = "INSTALLDIRS=3Dperl" "INSTALLMAN1DIR=3Dnone" "INSTALLMAN3DIR=3Dnone" "PERL_CORE=3D1" "LIBPERL_A=3Dlibperl.so" "LINKTYPE=3Dstatic" Writing Makefile for DynaLoader =3D=3D> Your Makefile has been rebuilt. <=3D=3D =3D=3D> Please rerun the make command. <=3D=3D false *** Error code 1 Rerunning make just make it die again in the same location. Any ideas? -joe ------------------------------ Message: 25 Date: Thu, 16 Sep 2010 11:57:04 +0100 From: Anton Shterenlikht Subject: Re: multiple problems between r212316 and r212643 on ia64 To: Marcel Moolenaar Cc: freebsd-current@freebsd.org, Anton Shterenlikht , freebsd-ia64@freebsd.org Message-ID: <20100916105704.GB51787@mech-anton240.men.bris.ac.uk> Content-Type: text/plain; charset=3Dus-ascii On Wed, Sep 15, 2010 at 02:23:26PM -0700, Marcel Moolenaar wrote: >=20 > On Sep 15, 2010, at 8:23 AM, Anton Shterenlikht wrote: >=20 > >=20 > > % man ls > > zcat: /usr/share/man/cat1/ls.1.gz already has .gz suffix -- = unchanged > > % man man > > zcat: /usr/share/man/cat1/man.1.gz already has .gz suffix -- = unchanged > >=20 > >=20 > > # cd /etc/mail > > # make start > > Starting: sendmail-submitmailwrapper: no mapping in /etc/mail/mailer.conf > > sendmail-clientmqueuemailwrapper: no mapping in = /etc/mail/mailer.conf > > . > > #=20 > >=20 > > # cd /usr/src > > # svn up > > svn: Can't open file '/usr/local/etc/subversion/servers': Illegal = byte sequence > > #=20 > >=20 >=20 > I think your file system is borked. Nonetheless, let me > upgrade myself and see if I run onto it too. I did "fsck -f" in single user mode - all seems fine: # fsck -f ** /dev/da0p2 ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 723993 files, 7874130 used, 20052947 free (87043 frags, 2495738 blocks, = 0.3% fra gmentation) ***** FILE SYSTEM IS CLEAN ***** # --=20 Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ------------------------------ _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" End of freebsd-current Digest, Vol 361, Issue 4 *********************************************** From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 12:50:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3BF7106564A for ; Thu, 16 Sep 2010 12:50:34 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id AF96D8FC1C for ; Thu, 16 Sep 2010 12:50:34 +0000 (UTC) Received: by pxi17 with SMTP id 17so392598pxi.13 for ; Thu, 16 Sep 2010 05:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Xtg0CS7l/8uWoxgPKPj5olJbIzlp9jeKqqF5VrJ8Mow=; b=nx6YcXv0XBoFMc7YwPkjfb4Sc8ArUxVo5HUPxeQ4NfPy78eZypW49TxgpSqPp3jASy MzF90bpyFSuSl2qpfr1LAWAZT+Vwjt1TPMN3U+HYb8kpOr4VrqRKLp+6CWl4NGHgjTHq DBiymOs3HlQ49eTAnE1Tre83b7gdF6O1E1X0U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=BHAXKGkUQ8Vv4mila5Li8Zvy8alh7VIm3JEBf7tpqxWGdK6Fo54Xzyqm0H14WfiQIJ Vx4SxUKMOeAz+IFIcHrlh0Dz5or0mlDeT5Jn6TdB7V/t2GMrMIDDixCYqDULnqsqcIFg z7ZdqD3EmOtdtnsEkD1SUKtLqEmevuhUrSKoE= Received: by 10.114.120.6 with SMTP id s6mr3216940wac.224.1284641433871; Thu, 16 Sep 2010 05:50:33 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-146-122.dsl.klmzmi.sbcglobal.net [99.181.146.122]) by mx.google.com with ESMTPS id s32sm1333715vck.30.2010.09.16.05.50.31 (version=SSLv3 cipher=RC4-MD5); Thu, 16 Sep 2010 05:50:32 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C921296.7070902@DataIX.net> Date: Thu, 16 Sep 2010 08:50:30 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.9) Gecko/20100908 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Gary Palmer References: <4C91691A.9040207@DataIX.net> <20100916021417.GB381@in-addr.com> In-Reply-To: <20100916021417.GB381@in-addr.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Jason J. W. Williams" , freebsd-current@freebsd.org Subject: Re: ZFS Test Suite X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 12:50:35 -0000 On 09/15/2010 22:14, Gary Palmer wrote: > On Wed, Sep 15, 2010 at 08:47:22PM -0400, jhell wrote: >> On 09/15/2010 13:40, Jason J. W. Williams wrote: >>> Does the FreeBSD ZFS port get tested against the ZFS test suite >>> created by Sun? It's a fairly comprehensive suite and has delivered a >>> very reliable set of ZFS beta code for a long time. Trying to gauge >>> the stability and compatibility of the FreeBSD port. Thank you in >>> advance. >>> >> >> Got a download link. Seems from this point on hub.opensolaris.org is down. > > http://hub.opensolaris.org/bin/view/Community+Group+zfs/zfstestsuite pointed > me at http://dlc.sun.com/osol/test/downloads/current/ > > The stcnv-zfs-src-20090909.tar.bz2 file was able to be downloaded from > the 2nd link and produced a 4.1MB file with about 1565 entries in it > according to tar -ztf. Note that I don't run ZFS here so I can't try the > test suite. > Thank you Gary. I am having a slight look at it right now. Looks to be really ksh(1) scripted so if I remember right they use ye-ole form of pdksh for their base utilities to run as. If time permits I may fall back here with an answer of what, if & when, where, why, can... be done with it. Thanks again Gary & Jason this was helpful. Regards, -- jhell,v From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 13:02:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A21FB106564A for ; Thu, 16 Sep 2010 13:02:34 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5288FC0C for ; Thu, 16 Sep 2010 13:02:34 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OwE6i-00015k-Qu for freebsd-current@freebsd.org; Thu, 16 Sep 2010 15:02:32 +0200 Received: from k.saper.info ([91.121.151.35]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Sep 2010 15:02:32 +0200 Received: from saper by k.saper.info with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Sep 2010 15:02:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Marcin Cieslak Date: Thu, 16 Sep 2010 13:02:23 +0000 (UTC) Organization: http://saper.info Lines: 17 Message-ID: References: <201009151749.45038.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: k.saper.info User-Agent: slrn/0.9.9p1 (FreeBSD) X-Mailman-Approved-At: Thu, 16 Sep 2010 14:00:01 +0000 Subject: Re: tun(4) in -CURRENT: No buffer space available - race condition patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 13:02:34 -0000 Dnia 15.09.2010 John Baldwin napisał/a: > On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote: >> Output queue of tun(4) gets full after some time when sending lots of data. >> I have been observing this on -CURRENT at least since March this year. >> >> Looks like it's a race condition (same in tun(4) and tap(4)), >> the following patch seems to address the issue: > > This is a good find. I actually went through these drivers a bit further and > have a bit of a larger patch to extend the locking some. Would you care to > test it? Do you think those drivers could be taken out of Giant after this change? I think that networking code path (via if_start etc.) is not using Giant at all, only cdevsw routines are. Am I right? //Marcin From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 14:06:14 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18A1A106566C for ; Thu, 16 Sep 2010 14:06: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 AA48D8FC13 for ; Thu, 16 Sep 2010 14:06:13 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3AA9A.dip.t-dialin.net [87.179.170.154]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 0195F84400D; Thu, 16 Sep 2010 16:06:08 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 1F17C22CE; Thu, 16 Sep 2010 16:06:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1284645966; bh=00q11Rkivf1HGuqL3kSpzqGGRflP9WrbsFe9dMN8xyM=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=RlonsEIJz+C8Qrtq4KpEqb+TgYRfHskw7hZ3F5Hv11tgLdv6meuqFukk6skHyTwg+ xMcYjMfadPVMSYkPVIZvp57Oiv0yVfFZtPia+EbnbO0bLN7uNPn8f4Gd82QZscsRzS QULLpOwFbwFLe6MzJccYeuZsm4U78R0jxX5EPs2XTB+zSGC3OC9Pbeyx1NF1q/aqPj i3q+qeYsJ3mm/qH2KAnRvcWGC75v53YqQOCciuSQfdwFQO/21vJ0h9Zd3ypi4yjAAo UTvTsg8jQKRWIuHOcAuo6WUb/CzH46hGDFBRfIeu7LOcbbfzI74hgzGyvjY+dPrNmz zCDwI+aIGxhEw== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id o8GE650P083966; Thu, 16 Sep 2010 16:06:05 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 16 Sep 2010 16:06:05 +0200 Message-ID: <20100916160605.50126iu2iydmvns4@webmail.leidinger.net> Date: Thu, 16 Sep 2010 16:06:05 +0200 From: Alexander Leidinger To: Thomas References: <4C920701.5010402@bsdunix.ch> In-Reply-To: <4C920701.5010402@bsdunix.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 0195F84400D.A7705 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.023, required 6, autolearn=disabled, ALL_TRUSTED -1.00, 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: 1285250770.8393@zCQGLQ0e9J+3G7wwFOCGhg X-EBL-Spam-Status: No Cc: stable@freebsd.org, current@freebsd.org Subject: Re: daily_scrub_zfs_enable is missing in /etc/defaults/periodic.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 14:06:14 -0000 Quoting Thomas (from Thu, 16 Sep 2010 14:01:05 +0200): > Hello > > Is there an actual reason why "daily_scrub_zfs_enable" is missing in > /etc/defaults/periodic.conf? Besides the fact that the authoritative source of information is the man-page: the 800.scrub-zfs is handling the defaults internally. More critical are entries in defaults/periodic.conf which are not described in the man-page. On my -current system: ---snip--- # for i in $(grep -v '^#' /etc/defaults/periodic.conf | grep = | tail +3 | head -94 | cut -d '=' -f 1); do grep -q $i periodic.txt|| echo $i not in man-page | egrep -v '_show_(success|info|badconfig)' done daily_status_zfs_enable not in man-page daily_status_mail_rejects_shorten not in man-page daily_status_ntpd_enable not in man-page daily_status_pkg_changes_enable not in man-page daily_status_security_logdir not in man-page daily_status_security_chkportsum_enable not in man-page daily_status_security_ipf6denied_enable not in man-page ---snip--- periodic.txt was generated via zcat /usr/share/man/man5/periodic.conf.5.gz | groff -Tascii -man -a >! periodic.txt Bye, Alexander. -- One reason why George Washington Is held in such veneration: He never blamed his problems On the former Administration. -- George O. Ludcke http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 15:27:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 533511065672; Thu, 16 Sep 2010 15:27:13 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by mx1.freebsd.org (Postfix) with ESMTP id 37AE68FC08; Thu, 16 Sep 2010 15:27:12 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp030.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L8U003H2IX0U100@asmtp030.mac.com>; Thu, 16 Sep 2010 08:27:01 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1009160060 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-09-16_09:2010-09-16, 2010-09-16, 1970-01-01 signatures=0 From: Marcel Moolenaar In-reply-to: <20100916105704.GB51787@mech-anton240.men.bris.ac.uk> Date: Thu, 16 Sep 2010 08:27:00 -0700 Message-id: <9A515150-AAE1-458F-A8F6-29EC97952991@mac.com> References: <20100915152353.GA45611@mech-anton240.men.bris.ac.uk> <5667FD77-8DBC-4638-80B6-67BCF9D4FB29@mac.com> <20100916105704.GB51787@mech-anton240.men.bris.ac.uk> To: Anton Shterenlikht X-Mailer: Apple Mail (2.1081) Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: multiple problems between r212316 and r212643 on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 15:27:13 -0000 On Sep 16, 2010, at 3:57 AM, Anton Shterenlikht wrote: >>> # cd /usr/src >>> # svn up >>> svn: Can't open file '/usr/local/etc/subversion/servers': Illegal byte sequence >>> # >>> >> >> I think your file system is borked. Nonetheless, let me >> upgrade myself and see if I run onto it too. > > I did "fsck -f" in single user mode - all seems fine: I see the svn problem too. I've tried to find suspicious commits, but only found commits to libthr that make me uncomfortable. svn is threaded, though... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Sep 16 22:01:08 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 040411065672; Thu, 16 Sep 2010 22:01:08 +0000 (UTC) Date: Thu, 16 Sep 2010 22:01:08 +0000 From: Alexander Best To: freebsd-current@freebsd.org Message-ID: <20100916220107.GA48632@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: failure to sync vnodes/buffers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 22:01:08 -0000 hi there, yesterday during a regular reboot my system was unable to sync vnodes and buffers. vnodes went down to 1, but then it kept repeating 1 until a timeout was hit. the output of the buffer syncs was running so fast i could hardly make out any numbers at all (but i took a picture, if anyone's interested in it). it seems i'm having the same issue as described in PR #132397. this happens quite regularly actually, but only after my system has been running for a few days and heavy I/O to the disk occured during that period of time. any advice? running HEAD (r212665; amd64). cheers. alex -- a13x From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 01:16:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D75E106566C for ; Fri, 17 Sep 2010 01:16:16 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id B8BA98FC15 for ; Fri, 17 Sep 2010 01:16:15 +0000 (UTC) Received: (qmail 2287 invoked by uid 399); 17 Sep 2010 01:16:15 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 17 Sep 2010 01:16:15 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C92C160.1090701@FreeBSD.org> Date: Thu, 16 Sep 2010 18:16:16 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20100915063233.GE1036@pluto.vnode.local> <201009160828.35520.jhb@freebsd.org> In-Reply-To: <201009160828.35520.jhb@freebsd.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Multiple hpet messages during boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 01:16:16 -0000 On 9/16/2010 5:28 AM, John Baldwin wrote: > On Wednesday, September 15, 2010 2:32:33 am Joel Dahl wrote: >> I noticed this during boot (HEAD from yesterday): >> >> hpet0: [FILTER] >> hpet0: [FILTER] >> hpet0: [FILTER] >> hpet0: [FILTER] >> hpet0: [FILTER] >> hpet0: [FILTER] >> hpet0: [FILTER] >> hpet0: [FILTER] >> >> Is it really necessary to print this 8 times? > > I'd actually like to remove the interrupt messages that say '[FILTER]' or > '[GIANT]', etc. I think in general they only add clutter. +1 -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 01:44:59 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40A571065670 for ; Fri, 17 Sep 2010 01:44:59 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id 0BC598FC16 for ; Fri, 17 Sep 2010 01:44:58 +0000 (UTC) Received: from [192.168.4.132] (207-225-98-3.dia.static.qwest.net [207.225.98.3]) (authenticated bits=0) by aslan.scsiguy.com (8.14.4/8.14.4) with ESMTP id o8H1ivvZ020661 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 Sep 2010 19:44:57 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-ID: <4C92C815.7070508@scsiguy.com> Date: Thu, 16 Sep 2010 19:44:53 -0600 From: "Justin T. Gibbs" Organization: SCSIGuy.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: current@FreeBSD.org, xen@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: CFT - Xen infrastructure and block I/O improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gibbs@scsiguy.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 01:44:59 -0000 At Spectra Logic, we are using FreeBSD amd64 under Xen to serve storage to other Xen domains. Over the past 9 months, we've made several changes to FreeBSD's Xen support. These include: o Support for backend devices (e.g. blkback) o Extensions to the Xen para-virtualized block API to allow for larger and more outstanding I/Os. o A completely rewritten block back driver with support for fronting I/O to both raw devices and files. o General cleanup and documentation of the XenBus and XenStore support code. o Robustness and performance updates for the block front driver. o Fixes to the netfront driver. Some of these changes have already been pushed back into FreeBSD, but the bulk of them need additional testing, especially under i386 PV, before they can be committed. If you work in the Xen area, I'd appreciate your review and/or testing of these changes. http://people.freebsd.org/~gibbs/FreeBSD-head-xen-diffs_2010_09_16.txt Thanks, Justin From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 06:00:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24C001065672 for ; Fri, 17 Sep 2010 06:00:10 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from mail.vnode.se (mail.vnode.se [62.119.52.80]) by mx1.freebsd.org (Postfix) with ESMTP id 780948FC0C for ; Fri, 17 Sep 2010 06:00:01 +0000 (UTC) Received: from mail.vnode.se (localhost [127.0.0.1]) by mail.vnode.se (Postfix) with ESMTP id 5BFBEE3F07A; Fri, 17 Sep 2010 07:59:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at vnode.se Received: from mail.vnode.se ([127.0.0.1]) by mail.vnode.se (mail.vnode.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjgYETSl58GK; Fri, 17 Sep 2010 07:59:56 +0200 (CEST) Received: from pluto.vnode.local (unknown [83.223.1.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.vnode.se (Postfix) with ESMTPSA id 9D6CCE3F079; Fri, 17 Sep 2010 07:59:55 +0200 (CEST) Date: Fri, 17 Sep 2010 07:59:53 +0200 From: Joel Dahl To: John Baldwin Message-ID: <20100917055953.GF1036@pluto.vnode.local> References: <20100915063233.GE1036@pluto.vnode.local> <201009160828.35520.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201009160828.35520.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: Multiple hpet messages during boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 06:00:10 -0000 On 16-09-2010 8:28, John Baldwin wrote: > On Wednesday, September 15, 2010 2:32:33 am Joel Dahl wrote: > > I noticed this during boot (HEAD from yesterday): > > > > hpet0: [FILTER] > > hpet0: [FILTER] > > hpet0: [FILTER] > > hpet0: [FILTER] > > hpet0: [FILTER] > > hpet0: [FILTER] > > hpet0: [FILTER] > > hpet0: [FILTER] > > > > Is it really necessary to print this 8 times? > > I'd actually like to remove the interrupt messages that say '[FILTER]' or > '[GIANT]', etc. I think in general they only add clutter. Definitely agreed. Go for it. -- Joel From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 06:55:28 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 211F31065670 for ; Fri, 17 Sep 2010 06:55:28 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id EE0DC8FC1A for ; Fri, 17 Sep 2010 06:55:27 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id EFE5A34E595; Fri, 17 Sep 2010 01:55:26 -0500 (CDT) Received: from 10.0.10.3 (221.163.108.93.rev.vodafone.pt [93.108.163.221]) by lavabit.com with ESMTP id 4LUMFMT7CVIL; Fri, 17 Sep 2010 01:55:26 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <4C92C815.7070508@scsiguy.com> Date: Fri, 17 Sep 2010 07:55:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1801A881-E1C8-4B41-AD14-940686A37A27@FreeBSD.org> References: <4C92C815.7070508@scsiguy.com> To: gibbs@scsiguy.com X-Mailer: Apple Mail (2.1081) Cc: current@FreeBSD.org, xen@FreeBSD.org Subject: Re: CFT - Xen infrastructure and block I/O improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 06:55:28 -0000 On 17 Sep 2010, at 02:44, Justin T. Gibbs wrote: > At Spectra Logic, we are using FreeBSD amd64 under Xen to serve = storage > to other Xen domains. Over the past 9 months, we've made several = changes > to FreeBSD's Xen support. These include: >=20 > o Support for backend devices (e.g. blkback) > o Extensions to the Xen para-virtualized block API to allow for larger > and more outstanding I/Os. > o A completely rewritten block back driver with support for fronting > I/O to both raw devices and files. > o General cleanup and documentation of the XenBus and XenStore support = code. > o Robustness and performance updates for the block front driver. > o Fixes to the netfront driver. >=20 > Some of these changes have already been pushed back into FreeBSD, but = the > bulk of them need additional testing, especially under i386 PV, before > they can be committed. If you work in the Xen area, I'd appreciate = your > review and/or testing of these changes. >=20 > http://people.freebsd.org/~gibbs/FreeBSD-head-xen-diffs_2010_09_16.txt Justin, this is quite a big diff (16k lines). I wonder if you can create = separate diffs (xenstore, blkback, xenbus, etc.) for easier review and = commenting. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 07:27:51 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3002106564A; Fri, 17 Sep 2010 07:27:51 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 7BBE58FC15; Fri, 17 Sep 2010 07:27:51 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id E253834E5B0; Fri, 17 Sep 2010 02:27:50 -0500 (CDT) Received: from 10.0.10.3 (221.163.108.93.rev.vodafone.pt [93.108.163.221]) by lavabit.com with ESMTP id XDNNPDE2I5V2; Fri, 17 Sep 2010 02:27:50 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <1801A881-E1C8-4B41-AD14-940686A37A27@FreeBSD.org> Date: Fri, 17 Sep 2010 08:27:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <57D2C852-4A1E-41AC-8074-BBBA8E0E7DCF@FreeBSD.org> References: <4C92C815.7070508@scsiguy.com> <1801A881-E1C8-4B41-AD14-940686A37A27@FreeBSD.org> To: gibbs@scsiguy.com X-Mailer: Apple Mail (2.1081) Cc: "current@freebsd.org Current" , xen@FreeBSD.org Subject: Re: CFT - Xen infrastructure and block I/O improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 07:27:51 -0000 On 17 Sep 2010, at 07:55, Rui Paulo wrote: > On 17 Sep 2010, at 02:44, Justin T. Gibbs wrote: >=20 >> At Spectra Logic, we are using FreeBSD amd64 under Xen to serve = storage >> to other Xen domains. Over the past 9 months, we've made several = changes >> to FreeBSD's Xen support. These include: >>=20 >> o Support for backend devices (e.g. blkback) >> o Extensions to the Xen para-virtualized block API to allow for = larger >> and more outstanding I/Os. >> o A completely rewritten block back driver with support for fronting >> I/O to both raw devices and files. >> o General cleanup and documentation of the XenBus and XenStore = support code. >> o Robustness and performance updates for the block front driver. >> o Fixes to the netfront driver. >>=20 >> Some of these changes have already been pushed back into FreeBSD, but = the >> bulk of them need additional testing, especially under i386 PV, = before >> they can be committed. If you work in the Xen area, I'd appreciate = your >> review and/or testing of these changes. >>=20 >> = http://people.freebsd.org/~gibbs/FreeBSD-head-xen-diffs_2010_09_16.txt >=20 > Justin, this is quite a big diff (16k lines). I wonder if you can = create separate diffs (xenstore, blkback, xenbus, etc.) for easier = review and commenting. '... and comment'. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 08:16:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67F6D1065672; Fri, 17 Sep 2010 08:16:51 +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 823518FC19; Fri, 17 Sep 2010 08:16:50 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA18728; Fri, 17 Sep 2010 11:16:49 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OwW7k-0008BC-Ri; Fri, 17 Sep 2010 11:16:48 +0300 Message-ID: <4C9323F0.90500@freebsd.org> Date: Fri, 17 Sep 2010 11:16:48 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100912 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <4C4DB2B8.9080404@freebsd.org> <4C88944C.5060603@freebsd.org> In-Reply-To: <4C88944C.5060603@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: amd64: VM_KMEM_SIZE_SCALE changed to 1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 08:16:51 -0000 [re-post, my address book was polluted with cu_rrr_ent@ entry, sorry] on 09/09/2010 11:01 Andriy Gapon said the following: > on 26/07/2010 19:07 Andriy Gapon said the following: >> >> Anyone knows any reason why VM_KMEM_SIZE_SCALE on amd64 should not be set to 1? >> I mean things potentially breaking, or some unpleasant surprise for an >> administrator/user... > > So, after having the discussion, what is our collective conclusion? > a) Go for it! > or > b) Don't do it, fool! > or > c) Let's wait another year... Nobody said (b), so: http://svn.freebsd.org/viewvc/base?view=revision&revision=212784 This thread in Gmane for your convenience: http://thread.gmane.org/gmane.os.freebsd.architechture/13419/focus=13551 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 15:23:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD9BD1065672 for ; Fri, 17 Sep 2010 15:23:45 +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 63ACA8FC16 for ; Fri, 17 Sep 2010 15:23:45 +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 027AB46B98; Fri, 17 Sep 2010 11:23:45 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B8C7E8A03C; Fri, 17 Sep 2010 11:23:43 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 17 Sep 2010 08:54:56 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201009151749.45038.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201009170854.56516.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 17 Sep 2010 11:23:43 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Marcin Cieslak Subject: Re: tun(4) in -CURRENT: No buffer space available - race condition patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 15:23:45 -0000 On Thursday, September 16, 2010 9:02:23 am Marcin Cieslak wrote: > Dnia 15.09.2010 John Baldwin napisa=C5=82/a: > > On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote: > >> Output queue of tun(4) gets full after some time when sending lots of = data. > >> I have been observing this on -CURRENT at least since March this year. > >>=20 > >> Looks like it's a race condition (same in tun(4) and tap(4)),=20 > >> the following patch seems to address the issue: > > > > This is a good find. I actually went through these drivers a bit furth= er and=20 > > have a bit of a larger patch to extend the locking some. Would you car= e to=20 > > test it? >=20 > Do you think those drivers could be taken out of Giant after this change? > I think that networking code path (via if_start etc.) is not using Giant > at all, only cdevsw routines are. Am I right? Oh, yes. I've updated the patch to remove D_NEEDGIANT. Index: if_tap.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D-- if_tap.c (revision 212732) +++ if_tap.c (working copy) @@ -132,7 +132,7 @@ =20 static struct cdevsw tap_cdevsw =3D { .d_version =3D D_VERSION, =2D .d_flags =3D D_PSEUDO | D_NEEDGIANT | D_NEEDMINOR, + .d_flags =3D D_PSEUDO | D_NEEDMINOR, .d_open =3D tapopen, .d_close =3D tapclose, .d_read =3D tapread, @@ -209,7 +209,6 @@ tap_destroy(struct tap_softc *tp) { struct ifnet *ifp =3D tp->tap_ifp; =2D int s; =20 /* Unlocked read. */ KASSERT(!(tp->tap_flags & TAP_OPEN), @@ -217,10 +216,8 @@ =20 knlist_destroy(&tp->tap_rsel.si_note); destroy_dev(tp->tap_dev); =2D s =3D splimp(); ether_ifdetach(ifp); if_free_type(ifp, IFT_ETHER); =2D splx(s); =20 mtx_destroy(&tp->tap_mtx); free(tp, M_TAP); @@ -398,7 +395,7 @@ struct tap_softc *tp =3D NULL; unsigned short macaddr_hi; uint32_t macaddr_mid; =2D int unit, s; + int unit; char *name =3D NULL; u_char eaddr[6]; =20 @@ -442,22 +439,20 @@ ifp->if_ioctl =3D tapifioctl; ifp->if_mtu =3D ETHERMTU; ifp->if_flags =3D (IFF_BROADCAST|IFF_SIMPLEX|IFF_MULTICAST); =2D ifp->if_snd.ifq_maxlen =3D ifqmaxlen; + IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); ifp->if_capabilities |=3D IFCAP_LINKSTATE; ifp->if_capenable |=3D IFCAP_LINKSTATE; =20 dev->si_drv1 =3D tp; tp->tap_dev =3D dev; =20 =2D s =3D splimp(); ether_ifattach(ifp, eaddr); =2D splx(s); =20 mtx_lock(&tp->tap_mtx); tp->tap_flags |=3D TAP_INITED; mtx_unlock(&tp->tap_mtx); =20 =2D knlist_init_mtx(&tp->tap_rsel.si_note, NULL); + knlist_init_mtx(&tp->tap_rsel.si_note, &tp->tap_mtx); =20 TAPDEBUG("interface %s is created. minor =3D %#x\n",=20 ifp->if_xname, dev2unit(dev)); @@ -474,7 +469,7 @@ { struct tap_softc *tp =3D NULL; struct ifnet *ifp =3D NULL; =2D int error, s; + int error; =20 if (tapuopen =3D=3D 0) { error =3D priv_check(td, PRIV_NET_TAP); @@ -497,15 +492,13 @@ tp->tap_pid =3D td->td_proc->p_pid; tp->tap_flags |=3D TAP_OPEN; ifp =3D tp->tap_ifp; =2D mtx_unlock(&tp->tap_mtx); =20 =2D s =3D splimp(); ifp->if_drv_flags |=3D IFF_DRV_RUNNING; ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE; if (tapuponopen) ifp->if_flags |=3D IFF_UP; if_link_state_change(ifp, LINK_STATE_UP); =2D splx(s); + mtx_unlock(&tp->tap_mtx); =20 TAPDEBUG("%s is open. minor =3D %#x\n", ifp->if_xname, dev2unit(dev)); =20 @@ -524,9 +517,9 @@ struct ifaddr *ifa; struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; =2D int s; =20 /* junk all pending output */ + mtx_lock(&tp->tap_mtx); IF_DRAIN(&ifp->if_snd); =20 /* @@ -534,28 +527,26 @@ * interface, if we are in VMnet mode. just close the device. */ =20 =2D mtx_lock(&tp->tap_mtx); if (((tp->tap_flags & TAP_VMNET) =3D=3D 0) && (ifp->if_flags & IFF_UP)) { mtx_unlock(&tp->tap_mtx); =2D s =3D splimp(); if_down(ifp); + mtx_lock(&tp->tap_mtx); if (ifp->if_drv_flags & IFF_DRV_RUNNING) { + ifp->if_drv_flags &=3D ~IFF_DRV_RUNNING; + mtx_unlock(&tp->tap_mtx); TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { rtinit(ifa, (int)RTM_DELETE, 0); } if_purgeaddrs(ifp); =2D ifp->if_drv_flags &=3D ~IFF_DRV_RUNNING; + mtx_lock(&tp->tap_mtx); } =2D splx(s); =2D } else =2D mtx_unlock(&tp->tap_mtx); + } =20 if_link_state_change(ifp, LINK_STATE_DOWN); funsetown(&tp->tap_sigio); selwakeuppri(&tp->tap_rsel, PZERO+1); =2D KNOTE_UNLOCKED(&tp->tap_rsel.si_note, 0); + KNOTE_LOCKED(&tp->tap_rsel.si_note, 0); =20 =2D mtx_lock(&tp->tap_mtx); tp->tap_flags &=3D ~TAP_OPEN; tp->tap_pid =3D 0; mtx_unlock(&tp->tap_mtx); @@ -580,8 +571,10 @@ =20 TAPDEBUG("initializing %s\n", ifp->if_xname); =20 + mtx_lock(&tp->tap_mtx); ifp->if_drv_flags |=3D IFF_DRV_RUNNING; ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE; + mtx_unlock(&tp->tap_mtx); =20 /* attempt to start output */ tapifstart(ifp); @@ -599,7 +592,7 @@ struct tap_softc *tp =3D ifp->if_softc; struct ifreq *ifr =3D (struct ifreq *)data; struct ifstat *ifs =3D NULL; =2D int s, dummy; + int dummy; =20 switch (cmd) { case SIOCSIFFLAGS: /* XXX -- just like vmnet does */ @@ -612,7 +605,6 @@ break; =20 case SIOCGIFSTATUS: =2D s =3D splimp(); ifs =3D (struct ifstat *)data; dummy =3D strlen(ifs->ascii); mtx_lock(&tp->tap_mtx); @@ -621,14 +613,10 @@ sizeof(ifs->ascii) - dummy, "\tOpened by PID %d\n", tp->tap_pid); mtx_unlock(&tp->tap_mtx); =2D splx(s); break; =20 default: =2D s =3D splimp(); =2D dummy =3D ether_ioctl(ifp, cmd, data); =2D splx(s); =2D return (dummy); + return (ether_ioctl(ifp, cmd, data)); /* NOT REACHED */ } =20 @@ -645,7 +633,6 @@ tapifstart(struct ifnet *ifp) { struct tap_softc *tp =3D ifp->if_softc; =2D int s; =20 TAPDEBUG("%s starting\n", ifp->if_xname); =20 @@ -657,32 +644,28 @@ mtx_lock(&tp->tap_mtx); if (((tp->tap_flags & TAP_VMNET) =3D=3D 0) && ((tp->tap_flags & TAP_READY) !=3D TAP_READY)) { =2D struct mbuf *m =3D NULL; + struct mbuf *m; =20 =2D mtx_unlock(&tp->tap_mtx); =2D /* Unlocked read. */ TAPDEBUG("%s not ready, tap_flags =3D 0x%x\n", ifp->if_xname,=20 tp->tap_flags); =20 =2D s =3D splimp(); =2D do { + for (;;) { IF_DEQUEUE(&ifp->if_snd, m); =2D if (m !=3D NULL) + if (m !=3D NULL) { m_freem(m); =2D ifp->if_oerrors ++; =2D } while (m !=3D NULL); =2D splx(s); + ifp->if_oerrors++; + } else + break; + } + mtx_unlock(&tp->tap_mtx); =20 return; } =2D mtx_unlock(&tp->tap_mtx); =20 =2D s =3D splimp(); ifp->if_drv_flags |=3D IFF_DRV_OACTIVE; =20 =2D if (ifp->if_snd.ifq_len !=3D 0) { =2D mtx_lock(&tp->tap_mtx); + if (!IFQ_IS_EMPTY(&ifp->if_snd)) { if (tp->tap_flags & TAP_RWAIT) { tp->tap_flags &=3D ~TAP_RWAIT; wakeup(tp); @@ -691,16 +674,16 @@ if ((tp->tap_flags & TAP_ASYNC) && (tp->tap_sigio !=3D NULL)) { mtx_unlock(&tp->tap_mtx); pgsigio(&tp->tap_sigio, SIGIO, 0); =2D } else =2D mtx_unlock(&tp->tap_mtx); + mtx_lock(&tp->tap_mtx); + } =20 selwakeuppri(&tp->tap_rsel, PZERO+1); =2D KNOTE_UNLOCKED(&tp->tap_rsel.si_note, 0); + KNOTE_LOCKED(&tp->tap_rsel.si_note, 0); ifp->if_opackets ++; /* obytes are counted in ether_output */ } =20 ifp->if_drv_flags &=3D ~IFF_DRV_OACTIVE; =2D splx(s); + mtx_unlock(&tp->tap_mtx); } /* tapifstart */ =20 =20 @@ -715,7 +698,6 @@ struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; struct tapinfo *tapp =3D NULL; =2D int s; int f; #if defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD5) || \ defined(COMPAT_FREEBSD4) @@ -724,19 +706,21 @@ =20 switch (cmd) { case TAPSIFINFO: =2D s =3D splimp(); tapp =3D (struct tapinfo *)data; + mtx_lock(&tp->tap_mtx); ifp->if_mtu =3D tapp->mtu; ifp->if_type =3D tapp->type; ifp->if_baudrate =3D tapp->baudrate; =2D splx(s); + mtx_unlock(&tp->tap_mtx); break; =20 case TAPGIFINFO: tapp =3D (struct tapinfo *)data; + mtx_lock(&tp->tap_mtx); tapp->mtu =3D ifp->if_mtu; tapp->type =3D ifp->if_type; tapp->baudrate =3D ifp->if_baudrate; + mtx_unlock(&tp->tap_mtx); break; =20 case TAPSDEBUG: @@ -757,26 +741,26 @@ break; =20 case FIOASYNC: =2D s =3D splimp(); mtx_lock(&tp->tap_mtx); if (*(int *)data) tp->tap_flags |=3D TAP_ASYNC; else tp->tap_flags &=3D ~TAP_ASYNC; mtx_unlock(&tp->tap_mtx); =2D splx(s); break; =20 case FIONREAD: =2D s =3D splimp(); =2D if (ifp->if_snd.ifq_head) { =2D struct mbuf *mb =3D ifp->if_snd.ifq_head; + if (!IFQ_IS_EMPTY(&ifp->if_snd)) { + struct mbuf *mb; =20 =2D for(*(int *)data =3D 0;mb !=3D NULL;mb =3D mb->m_next) + IFQ_LOCK(&ifp->if_snd); + IFQ_POLL_NOLOCK(&ifp->if_snd, mb); + for (*(int *)data =3D 0; mb !=3D NULL; + mb =3D mb->m_next) *(int *)data +=3D mb->m_len; + IFQ_UNLOCK(&ifp->if_snd); } else *(int *)data =3D 0; =2D splx(s); break; =20 case FIOSETOWN: @@ -797,10 +781,6 @@ =20 /* VMware/VMnet port ioctl's */ =20 =2D case SIOCGIFFLAGS: /* get ifnet flags */ =2D bcopy(&ifp->if_flags, data, sizeof(ifp->if_flags)); =2D break; =2D #if defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD5) || \ defined(COMPAT_FREEBSD4) case _IO('V', 0): @@ -814,9 +794,9 @@ f &=3D ~IFF_CANTCHANGE; f |=3D IFF_UP; =20 =2D s =3D splimp(); + mtx_lock(&tp->tap_mtx); ifp->if_flags =3D f | (ifp->if_flags & IFF_CANTCHANGE); =2D splx(s); + mtx_unlock(&tp->tap_mtx); break; =20 case OSIOCGIFADDR: /* get MAC address of the remote side */ @@ -851,7 +831,7 @@ struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; struct mbuf *m =3D NULL; =2D int error =3D 0, len, s; + int error =3D 0, len; =20 TAPDEBUG("%s reading, minor =3D %#x\n", ifp->if_xname, dev2unit(dev)); =20 @@ -867,26 +847,27 @@ } =20 tp->tap_flags &=3D ~TAP_RWAIT; =2D mtx_unlock(&tp->tap_mtx); =20 /* sleep until we get a packet */ do { =2D s =3D splimp(); IF_DEQUEUE(&ifp->if_snd, m); =2D splx(s); =20 if (m =3D=3D NULL) { =2D if (flag & O_NONBLOCK) + if (flag & O_NONBLOCK) { + mtx_unlock(&tp->tap_mtx); return (EWOULDBLOCK); + } =20 =2D mtx_lock(&tp->tap_mtx); tp->tap_flags |=3D TAP_RWAIT; =2D mtx_unlock(&tp->tap_mtx); =2D error =3D tsleep(tp,PCATCH|(PZERO+1),"taprd",0); =2D if (error) + error =3D mtx_sleep(tp, &tp->tap_mtx, PCATCH | (PZERO + 1), + "taprd", 0); + if (error) { + mtx_unlock(&tp->tap_mtx); return (error); + } } } while (m =3D=3D NULL); + mtx_unlock(&tp->tap_mtx); =20 /* feed packet to bpf */ BPF_MTAP(ifp, m); @@ -982,14 +963,14 @@ { struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; =2D int s, revents =3D 0; + int revents =3D 0; =20 TAPDEBUG("%s polling, minor =3D %#x\n",=20 ifp->if_xname, dev2unit(dev)); =20 =2D s =3D splimp(); if (events & (POLLIN | POLLRDNORM)) { =2D if (ifp->if_snd.ifq_len > 0) { + IFQ_LOCK(&ifp->if_snd); + if (!IFQ_IS_EMPTY(&ifp->if_snd)) { TAPDEBUG("%s have data in queue. len =3D %d, " \ "minor =3D %#x\n", ifp->if_xname, ifp->if_snd.ifq_len, dev2unit(dev)); @@ -1001,12 +982,12 @@ =20 selrecord(td, &tp->tap_rsel); } + IFQ_UNLOCK(&ifp->if_snd); } =20 if (events & (POLLOUT | POLLWRNORM)) revents |=3D (events & (POLLOUT | POLLWRNORM)); =20 =2D splx(s); return (revents); } /* tappoll */ =20 @@ -1019,11 +1000,9 @@ static int tapkqfilter(struct cdev *dev, struct knote *kn) { =2D int s; struct tap_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D tp->tap_ifp; =20 =2D s =3D splimp(); switch (kn->kn_filter) { case EVFILT_READ: TAPDEBUG("%s kqfilter: EVFILT_READ, minor =3D %#x\n", @@ -1040,13 +1019,11 @@ default: TAPDEBUG("%s kqfilter: invalid filter, minor =3D %#x\n", ifp->if_xname, dev2unit(dev)); =2D splx(s); return (EINVAL); /* NOT REACHED */ } =2D splx(s); =20 =2D kn->kn_hook =3D (caddr_t) dev; + kn->kn_hook =3D tp; knlist_add(&tp->tap_rsel.si_note, kn, 0); =20 return (0); @@ -1061,12 +1038,11 @@ static int tapkqread(struct knote *kn, long hint) { =2D int ret, s; =2D struct cdev *dev =3D (struct cdev *)(kn->kn_hook); =2D struct tap_softc *tp =3D dev->si_drv1; + int ret; + struct tap_softc *tp =3D kn->kn_hook; + struct cdev *dev =3D tp->tap_dev; struct ifnet *ifp =3D tp->tap_ifp; =20 =2D s =3D splimp(); if ((kn->kn_data =3D ifp->if_snd.ifq_len) > 0) { TAPDEBUG("%s have data in queue. len =3D %d, minor =3D %#x\n", ifp->if_xname, ifp->if_snd.ifq_len, dev2unit(dev)); @@ -1076,7 +1052,6 @@ ifp->if_xname, dev2unit(dev)); ret =3D 0; } =2D splx(s); =20 return (ret); } /* tapkqread */ @@ -1090,13 +1065,10 @@ static int tapkqwrite(struct knote *kn, long hint) { =2D int s; =2D struct tap_softc *tp =3D ((struct cdev *) kn->kn_hook)->si_drv1; + struct tap_softc *tp =3D kn->kn_hook; struct ifnet *ifp =3D tp->tap_ifp; =20 =2D s =3D splimp(); kn->kn_data =3D ifp->if_mtu; =2D splx(s); =20 return (1); } /* tapkqwrite */ @@ -1105,7 +1077,7 @@ static void tapkqdetach(struct knote *kn) { =2D struct tap_softc *tp =3D ((struct cdev *) kn->kn_hook)->si_drv1; + struct tap_softc *tp =3D kn->kn_hook; =20 knlist_remove(&tp->tap_rsel.si_note, kn, 0); } /* tapkqdetach */ Index: if_tun.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D-- if_tun.c (revision 212732) +++ if_tun.c (working copy) @@ -165,7 +165,7 @@ =20 static struct cdevsw tun_cdevsw =3D { .d_version =3D D_VERSION, =2D .d_flags =3D D_PSEUDO | D_NEEDGIANT | D_NEEDMINOR, + .d_flags =3D D_PSEUDO | D_NEEDMINOR, .d_open =3D tunopen, .d_close =3D tunclose, .d_read =3D tunread, @@ -344,13 +344,13 @@ tp->tun_flags &=3D ~TUN_RWAIT; wakeup(tp); } + selwakeuppri(&tp->tun_rsel, PZERO + 1); + KNOTE_LOCKED(&tp->tun_rsel.si_note, 0); if (tp->tun_flags & TUN_ASYNC && tp->tun_sigio) { mtx_unlock(&tp->tun_mtx); pgsigio(&tp->tun_sigio, SIGIO, 0); } else mtx_unlock(&tp->tun_mtx); =2D selwakeuppri(&tp->tun_rsel, PZERO + 1); =2D KNOTE_UNLOCKED(&tp->tun_rsel.si_note, 0); } =20 /* XXX: should return an error code so it can fail. */ @@ -385,7 +385,7 @@ IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); ifp->if_snd.ifq_drv_maxlen =3D 0; IFQ_SET_READY(&ifp->if_snd); =2D knlist_init_mtx(&sc->tun_rsel.si_note, NULL); + knlist_init_mtx(&sc->tun_rsel.si_note, &sc->tun_mtx); ifp->if_capabilities |=3D IFCAP_LINKSTATE; ifp->if_capenable |=3D IFCAP_LINKSTATE; =20 @@ -426,10 +426,10 @@ tp->tun_pid =3D td->td_proc->p_pid; =20 tp->tun_flags |=3D TUN_OPEN; =2D mtx_unlock(&tp->tun_mtx); ifp =3D TUN2IFP(tp); if_link_state_change(ifp, LINK_STATE_UP); TUNDEBUG(ifp, "open\n"); + mtx_unlock(&tp->tun_mtx); =20 return (0); } @@ -443,7 +443,6 @@ { struct tun_softc *tp; struct ifnet *ifp; =2D int s; =20 tp =3D dev->si_drv1; ifp =3D TUN2IFP(tp); @@ -451,27 +450,25 @@ mtx_lock(&tp->tun_mtx); tp->tun_flags &=3D ~TUN_OPEN; tp->tun_pid =3D 0; =2D mtx_unlock(&tp->tun_mtx); =20 /* * junk all pending output */ CURVNET_SET(ifp->if_vnet); =2D s =3D splimp(); IFQ_PURGE(&ifp->if_snd); =2D splx(s); =20 if (ifp->if_flags & IFF_UP) { =2D s =3D splimp(); + mtx_unlock(&tp->tun_mtx); if_down(ifp); =2D splx(s); + mtx_lock(&tp->tun_mtx); } =20 /* Delete all addresses and routes which reference this interface. */ if (ifp->if_drv_flags & IFF_DRV_RUNNING) { struct ifaddr *ifa; =20 =2D s =3D splimp(); + ifp->if_drv_flags &=3D ~IFF_DRV_RUNNING; + mtx_unlock(&tp->tun_mtx); TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { /* deal w/IPv4 PtP destination; unlocked read */ if (ifa->ifa_addr->sa_family =3D=3D AF_INET) { @@ -482,16 +479,14 @@ } } if_purgeaddrs(ifp); =2D ifp->if_drv_flags &=3D ~IFF_DRV_RUNNING; =2D splx(s); + mtx_lock(&tp->tun_mtx); } if_link_state_change(ifp, LINK_STATE_DOWN); CURVNET_RESTORE(); =20 =2D mtx_lock(&tp->tun_mtx); funsetown(&tp->tun_sigio); selwakeuppri(&tp->tun_rsel, PZERO + 1); =2D KNOTE_UNLOCKED(&tp->tun_rsel.si_note, 0); + KNOTE_LOCKED(&tp->tun_rsel.si_note, 0); TUNDEBUG (ifp, "closed\n"); =20 cv_broadcast(&tp->tun_cv); @@ -510,6 +505,7 @@ =20 TUNDEBUG(ifp, "tuninit\n"); =20 + mtx_lock(&tp->tun_mtx); ifp->if_flags |=3D IFF_UP; ifp->if_drv_flags |=3D IFF_DRV_RUNNING; getmicrotime(&ifp->if_lastchange); @@ -521,18 +517,17 @@ struct sockaddr_in *si; =20 si =3D (struct sockaddr_in *)ifa->ifa_addr; =2D mtx_lock(&tp->tun_mtx); if (si->sin_addr.s_addr) tp->tun_flags |=3D TUN_IASET; =20 si =3D (struct sockaddr_in *)ifa->ifa_dstaddr; if (si && si->sin_addr.s_addr) tp->tun_flags |=3D TUN_DSTADDR; =2D mtx_unlock(&tp->tun_mtx); } } if_addr_runlock(ifp); #endif + mtx_unlock(&tp->tun_mtx); return (error); } =20 @@ -545,9 +540,8 @@ struct ifreq *ifr =3D (struct ifreq *)data; struct tun_softc *tp =3D ifp->if_softc; struct ifstat *ifs; =2D int error =3D 0, s; + int error =3D 0; =20 =2D s =3D splimp(); switch(cmd) { case SIOCGIFSTATUS: ifs =3D (struct ifstat *)data; @@ -576,7 +570,6 @@ default: error =3D EINVAL; } =2D splx(s); return (error); } =20 @@ -682,7 +675,6 @@ static int tunioctl(struct cdev *dev, u_long cmd, caddr_t data, int flag, struct thre= ad *td) { =2D int s; int error; struct tun_softc *tp =3D dev->si_drv1; struct tuninfo *tunp; @@ -697,15 +689,19 @@ if (error) return (error); } + mtx_lock(&tp->tun_mtx); TUN2IFP(tp)->if_mtu =3D tunp->mtu; TUN2IFP(tp)->if_type =3D tunp->type; TUN2IFP(tp)->if_baudrate =3D tunp->baudrate; + mtx_unlock(&tp->tun_mtx); break; case TUNGIFINFO: tunp =3D (struct tuninfo *)data; + mtx_lock(&tp->tun_mtx); tunp->mtu =3D TUN2IFP(tp)->if_mtu; tunp->type =3D TUN2IFP(tp)->if_type; tunp->baudrate =3D TUN2IFP(tp)->if_baudrate; + mtx_unlock(&tp->tun_mtx); break; case TUNSDEBUG: tundebug =3D *(int *)data; @@ -732,7 +728,6 @@ mtx_unlock(&tp->tun_mtx); break; case TUNGIFHEAD: =2D /* Could be unlocked read? */ mtx_lock(&tp->tun_mtx); *(int *)data =3D (tp->tun_flags & TUN_IFHEAD) ? 1 : 0; mtx_unlock(&tp->tun_mtx); @@ -745,9 +740,11 @@ switch (*(int *)data & ~IFF_MULTICAST) { case IFF_POINTOPOINT: case IFF_BROADCAST: + mtx_lock(&tp->tun_mtx); TUN2IFP(tp)->if_flags &=3D ~(IFF_BROADCAST|IFF_POINTOPOINT|IFF_MULTICAST); TUN2IFP(tp)->if_flags |=3D *(int *)data; + mtx_unlock(&tp->tun_mtx); break; default: return(EINVAL); @@ -769,17 +766,15 @@ mtx_unlock(&tp->tun_mtx); break; case FIONREAD: =2D s =3D splimp(); if (!IFQ_IS_EMPTY(&TUN2IFP(tp)->if_snd)) { struct mbuf *mb; IFQ_LOCK(&TUN2IFP(tp)->if_snd); IFQ_POLL_NOLOCK(&TUN2IFP(tp)->if_snd, mb); =2D for( *(int *)data =3D 0; mb !=3D 0; mb =3D mb->m_next) + for (*(int *)data =3D 0; mb !=3D NULL; mb =3D mb->m_next) *(int *)data +=3D mb->m_len; IFQ_UNLOCK(&TUN2IFP(tp)->if_snd); } else *(int *)data =3D 0; =2D splx(s); break; case FIOSETOWN: return (fsetown(*(int *)data, &tp->tun_sigio)); @@ -813,7 +808,7 @@ struct tun_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D TUN2IFP(tp); struct mbuf *m; =2D int error=3D0, len, s; + int error=3D0, len; =20 TUNDEBUG (ifp, "read\n"); mtx_lock(&tp->tun_mtx); @@ -824,27 +819,24 @@ } =20 tp->tun_flags &=3D ~TUN_RWAIT; =2D mtx_unlock(&tp->tun_mtx); =20 =2D s =3D splimp(); do { IFQ_DEQUEUE(&ifp->if_snd, m); if (m =3D=3D NULL) { if (flag & O_NONBLOCK) { =2D splx(s); + mtx_unlock(&tp->tun_mtx); return (EWOULDBLOCK); } =2D mtx_lock(&tp->tun_mtx); tp->tun_flags |=3D TUN_RWAIT; =2D mtx_unlock(&tp->tun_mtx); =2D if ((error =3D tsleep(tp, PCATCH | (PZERO + 1), =2D "tunread", 0)) !=3D 0) { =2D splx(s); + error =3D mtx_sleep(tp, &tp->tun_mtx, PCATCH | (PZERO + 1), + "tunread", 0); + if (error !=3D 0) { + mtx_unlock(&tp->tun_mtx); return (error); } } } while (m =3D=3D NULL); =2D splx(s); + mtx_unlock(&tp->tun_mtx); =20 while (m && uio->uio_resid > 0 && error =3D=3D 0) { len =3D min(uio->uio_resid, m->m_len); @@ -957,13 +949,11 @@ static int tunpoll(struct cdev *dev, int events, struct thread *td) { =2D int s; struct tun_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D TUN2IFP(tp); int revents =3D 0; struct mbuf *m; =20 =2D s =3D splimp(); TUNDEBUG(ifp, "tunpoll\n"); =20 if (events & (POLLIN | POLLRDNORM)) { @@ -981,7 +971,6 @@ if (events & (POLLOUT | POLLWRNORM)) revents |=3D events & (POLLOUT | POLLWRNORM); =20 =2D splx(s); return (revents); } =20 @@ -991,11 +980,9 @@ static int tunkqfilter(struct cdev *dev, struct knote *kn) { =2D int s; struct tun_softc *tp =3D dev->si_drv1; struct ifnet *ifp =3D TUN2IFP(tp); =20 =2D s =3D splimp(); switch(kn->kn_filter) { case EVFILT_READ: TUNDEBUG(ifp, "%s kqfilter: EVFILT_READ, minor =3D %#x\n", @@ -1012,12 +999,10 @@ default: TUNDEBUG(ifp, "%s kqfilter: invalid filter, minor =3D %#x\n", ifp->if_xname, dev2unit(dev)); =2D splx(s); return(EINVAL); } =2D splx(s); =20 =2D kn->kn_hook =3D (caddr_t) dev; + kn->kn_hook =3D tp; knlist_add(&tp->tun_rsel.si_note, kn, 0); =20 return (0); @@ -1029,12 +1014,11 @@ static int tunkqread(struct knote *kn, long hint) { =2D int ret, s; =2D struct cdev *dev =3D (struct cdev *)(kn->kn_hook); =2D struct tun_softc *tp =3D dev->si_drv1; + int ret; + struct tun_softc *tp =3D kn->kn_hook; + struct cdev *dev =3D tp->tun_dev; struct ifnet *ifp =3D TUN2IFP(tp); =20 =2D s =3D splimp(); if ((kn->kn_data =3D ifp->if_snd.ifq_len) > 0) { TUNDEBUG(ifp, "%s have data in the queue. Len =3D %d, minor =3D %#x\n", @@ -1046,7 +1030,6 @@ dev2unit(dev)); ret =3D 0; } =2D splx(s); =20 return (ret); } @@ -1057,13 +1040,10 @@ static int tunkqwrite(struct knote *kn, long hint) { =2D int s; =2D struct tun_softc *tp =3D ((struct cdev *)kn->kn_hook)->si_drv1; + struct tun_softc *tp =3D kn->kn_hook; struct ifnet *ifp =3D TUN2IFP(tp); =20 =2D s =3D splimp(); kn->kn_data =3D ifp->if_mtu; =2D splx(s); =20 return (1); } @@ -1071,7 +1051,7 @@ static void tunkqdetach(struct knote *kn) { =2D struct tun_softc *tp =3D ((struct cdev *)kn->kn_hook)->si_drv1; + struct tun_softc *tp =3D kn->kn_hook; =20 knlist_remove(&tp->tun_rsel.si_note, kn, 0); } =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 15:31:24 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 078151065675; Fri, 17 Sep 2010 15:31:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id BF0FA8FC0C; Fri, 17 Sep 2010 15:31:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o8HFTAA8019154; Fri, 17 Sep 2010 09:29:10 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 17 Sep 2010 09:29:21 -0600 (MDT) Message-Id: <20100917.092921.741671742025249057.imp@bsdimp.com> To: mav@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <4C911214.7060406@FreeBSD.org> References: <4C911214.7060406@FreeBSD.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Multiple hpet messages during boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 15:31:24 -0000 In message: <4C911214.7060406@FreeBSD.org> Alexander Motin writes: : Joel Dahl wrote: : > I noticed this during boot (HEAD from yesterday): : > : > hpet0: [FILTER] : > hpet0: [FILTER] : > hpet0: [FILTER] : > hpet0: [FILTER] : > hpet0: [FILTER] : > hpet0: [FILTER] : > hpet0: [FILTER] : > hpet0: [FILTER] : > : > Is it really necessary to print this 8 times? : : HPET at present chipsets may use up to 8 IRQs. Driver registers filter : interrupt handlers for them. Interrupt handling code prints this. : : If you boot with verbose, you may see that some network cards prints : alike things for the number of supported MSI/MSI-X interrupts. Is there any reason not to toss all FILTER messages behind bootverbose? Warner From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 15:31:24 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 869701065670; Fri, 17 Sep 2010 15:31:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 43D4D8FC13; Fri, 17 Sep 2010 15:31:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o8HFSdb7019153; Fri, 17 Sep 2010 09:28:39 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 17 Sep 2010 09:28:49 -0600 (MDT) Message-Id: <20100917.092849.584158775148072316.imp@bsdimp.com> To: dougb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <4C91100C.5060502@FreeBSD.org> References: <20100915.082513.802140508206832836.imp@bsdimp.com> <4C91100C.5060502@FreeBSD.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 15:31:24 -0000 In message: <4C91100C.5060502@FreeBSD.org> Doug Barton writes: : > Most of the code is there anyway, and it isn't evolving as fast as : > BIND. : : That is actually a more rational argument, even if I don't agree with : it. FWIW, part of the reason that I don't agree with it is that at : some point, hopefully in the near future, we will want to include the : DHCPv6 client in the mix somewhere; and when we do the code base is : not going to be as stable as we have enjoyed so far with the v4 : dhclient. True, but that still won't change the dynamic that adding a dhcp server is easy give we have most of one already in the tree. Adding v6 support likely will mean a certain amount of code churn, I'll grant you that. But the code/api churn that's happening is within a single program, making it much easier to MFC as necessary to keep up. : > This is analogous: we : > have good opportunity to integrate into the system, and users benefit : > from that integration. : : Given your perspective of wanting more of a complete system in the : base I can certainly see how you would be supportive of this : change. My intent was to make the argument in a general way that this : is the wrong direction to go, and that users would benefit *more* from : a robust modularized system. The fact that the v4 DHCPd might : accidentally be a good candidate for including in the base today : doesn't mean that doing so is the right strategy for the long term. I take a more nuanced view: we have to evaluate each proposed addition to the system on its merits. One of these criteria is long term viability, but others include how useful is it to the users; how much demand will there be; will including it make the project look good?; will not including it make the project look bad?; etc We'd all like to see a more modular base, but until that nut is cracked, we have a balancing act to perform. Warner From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 15:36:29 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E6BC1065675; Fri, 17 Sep 2010 15:36:29 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (www.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id C7A568FC0A; Fri, 17 Sep 2010 15:36:28 +0000 (UTC) Received: from [192.168.0.8] (tumnus.scsiguy.com [192.168.0.8]) (authenticated bits=0) by aslan.scsiguy.com (8.14.4/8.14.4) with ESMTP id o8HFaQCA026818 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 17 Sep 2010 09:36:27 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-ID: <4C938AEE.2080006@scsiguy.com> Date: Fri, 17 Sep 2010 09:36:14 -0600 From: "Justin T. Gibbs" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rui Paulo References: <4C92C815.7070508@scsiguy.com> <1801A881-E1C8-4B41-AD14-940686A37A27@FreeBSD.org> <57D2C852-4A1E-41AC-8074-BBBA8E0E7DCF@FreeBSD.org> In-Reply-To: <57D2C852-4A1E-41AC-8074-BBBA8E0E7DCF@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org Current" , xen@freebsd.org Subject: Re: CFT - Xen infrastructure and block I/O improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 15:36:29 -0000 On 9/17/2010 1:27 AM, Rui Paulo wrote: > On 17 Sep 2010, at 07:55, Rui Paulo wrote: > >> On 17 Sep 2010, at 02:44, Justin T. Gibbs wrote: >> >>> At Spectra Logic, we are using FreeBSD amd64 under Xen to serve storage >>> to other Xen domains. Over the past 9 months, we've made several changes >>> to FreeBSD's Xen support. These include: ... >> Justin, this is quite a big diff (16k lines). I wonder if you can create >> separate diffs (xenstore, blkback, xenbus, etc.) for easier review and >> commenting. > > '... and comment'. The bulk of the patch is due to code reorganization. Unfortunately SVN doesn't reflect the copies properly in a diff, but at least the diff will apply properly even in a non-SVN backed source tree. This original patch should be the best for testers. The following SVN operations were made to the source tree to clean up it's organization and to import functionality from the vendor (1 file): # Does not apply to FreeBSD's NewBus method for dealing with XenBus devices svn delete sys/xen/xenbus/init.txt # Linux version of backend XenBus service routines. Never ported to FreeBSD. # OBE: See xenbusb.c, xenbusb_if.m, xenbusb_front.c xenbusb_back.c svn delete sys/xen/xenbus/xenbus_probe_backend.c # Split XenStore into its own tree. XenBus is a software layer built on top # of XenStore. The old arrangement and the naming of some structures and # functions blurred these lines making it difficult to discern what services # are provided by which layer and what times these services are available # (e.g. during system startup and shutdown). mkdir sys/xen/xenstore svn add sys/xen/xenstore svn move sys/xen/xenbus/xenbus_dev.c sys/xen/xenstore/xenstore_dev.c svn copy sys/xen/xenbus/xenbusvar.h sys/xen/xenstore/xenstorevar.h svn move sys/xen/xenbus/xenbus_xs.c sys/xen/xenstore/xenstore.c # Split up XenBus code into methods available for use by client # drivers (xenbus.c) and code used by the XenBus "bus code" to # enumerate, attach, detach, and service bus drivers. svn move sys/xen/xenbus/xenbus_client.c sys/xen/xenbus/xenbus.c svn move sys/xen/xenbus/xenbus_probe.c sys/xen/xenbus/xenbusb.c svn copy sys/xen/xenbus/xenbusb.c sys/xen/xenbus/xenbusb.h # Merged with xenstore.c svn delete sys/xen/xenbus/xenbus_comms.c svn delete sys/xen/xenbus/xenbus_comms.h # Merged with new XenBus control driver mkdir sys/dev/xen/control svn add sys/dev/xen/control svn move sys/xen/reboot.c sys/dev/xen/control/control.c # New file from Xen vendor with macros and structures used by # a block back driver to service requires from a VM running a # different ABI (e.g. amd64 back with i386 front). svn add sys/xen/blkif.h These alone account for 6k lines of svn diff. A diff against a tree with these operations already made may make more sense to a reviewer. You can download this diff from here: http://people.FreeBSD.org/~gibbs/FreeBSD-head-xen_post-svn-ops_2010-09-17_diffs.txt It isn't much shorter since the additional context has amplified the changes. The bulk is largely caused by refactoring, and comments. It will probably be easier to just review the files in sys/xen/xenstore and sys/xen/xenbus in their entirety, but the comments bellow (boiled down from our SCM system), when coupled with the diffs, should give you enough information to understand the intentions behind the changes. -- Justin sys/conf/files: Adjust kernel build spec for new XenBus/XenStore layout and added Xen functionality. sys/dev/xen/balloon/balloon.c: sys/dev/xen/netfront/netfront.c: sys/dev/xen/blkfront/blkfront.c: sys/xen/xenbus/... sys/xen/xenstore/... o Rename XenStore APIs and structures from xenbus_* to xs_*. o Adjust to use of M_XENBUS and M_XENSTORE malloc types for allocation of objects returned by these APIs. o Adjust for changes in the bus interface for Xen drivers. sys/dev/xen/blkback/blkback.c: Rewrite the Block Back driver to attach properly via newbus, operate correctly in both PV and HVM mode regardless of domain (e.g. can be in a DOM other than 0), and to deal with the latest metadata available in XenStore for block devices. Allow users to specify a file as a backend to blkback, in addition to character devices. Use the namei lookup to figure out whether it's a device node or a file, and use the appropriate interface. One current issue with the file interface is that we're effectively limited to having a single command at a time outstanding. To get around this, we may need to try using the vnode pager more directly, or perhaps coming up with a direct interface into ZFS. (i.e. something similar to zvols, but without the performance issues.) This will impact reads more than writes, because writes are cached but with random reads you have to go all the way down to the disk, so you suffer the full latency of the stack. sys/dev/xen/blkback/blkback.c: sys/xen/interface/io/blkif.h: sys/xen/blkif.h: sys/dev/xen/blkfront/blkfront.c: sys/dev/xen/blkfront/block.h: Extend the Xen blkif API: Negotiable request size and number of requests. This change extends the information recorded in the XenStore allowing block front/back devices to negotiate for optimal I/O parameters. This has been achieved without sacrificing backward compatibility with drivers that are unaware of these protocol enhancements. The extensions center around the connection protocol which now includes these additions: o The back-end device publishes its maximum supported values for, request I/O size, the number of page segments that can be associated with a request, the maximum number of requests that can be concurrently active, and the maximum number of pages that can be in the shared request ring. These values are published before the back-end enters the XenbusStateInitWait state. o The front-end waits for the back-end to enter either the InitWait or Initialize state. At this point, the front end limits it's own capabilities to the lesser of the values it finds published by the backend, it's own maximums, or, should any back-end data be missing in the store, the values supported by the original protocol. It then initializes it's internal data structures including allocation of the shared ring, publishes its maximum capabilities to the XenStore and transitions to the Initialized state. o The back-end waits for the front-end to enter the Initalized state. At this point, the back end limits it's own capabilities to the lesser of the values it finds published by the frontend, it's own maximums, or, should any front-end data be missing in the store, the values supported by the original protocol. It then initializes it's internal data structures, attaches to the shared ring and transitions to the Connected state. o The front-end waits for the back-end to enter the Connnected state, transitions itself to the connected state, and can commence I/O. Although an updated front-end driver must be aware of the back-end's InitWait state, the back-end has been coded such that it can tolerate a front-end that skips this step and transitions directly to the Initialized state without waiting for the back-end. sys/xen/interface/io/blkif.h: o Increase BLKIF_MAX_SEGMENTS_PER_REQUEST to 255. This is the maximum number possible without changing the blkif request header structure (nr_segs is a uint8_t). o Add two new constants: BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK, and BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK. These respectively indicate the number of segments that can fit in the first ring-buffer entry of a request, and for each subsequent (sg element only) ring-buffer entry associated with the "header" ring-buffer entry of the request. o Add the blkif_request_segment_t typedef for segment elements. o Add the BLKRING_GET_SG_REQUEST() macro which wraps the RING_GET_REQUEST() macro and returns a properly cast pointer to an array of blkif_request_segment_ts. o Add the BLKIF_SEGS_TO_BLOCKS() macro which calculates the number of ring entries that will be consumed by a blkif request with the given number of segments. sys/xen/blkif.h: o Update for changes in interface/io/blkif.h macros. o Update the BLKIF_MAX_RING_REQUESTS() macro to take the ring size as an argument to allow this calculation on multi-page rings. o Add a companion macro to BLKIF_MAX_RING_REQUESTS(), BLKIF_RING_PAGES(). This macro determines the number of ring pages required in order to support a ring with the supplied number of request blocks. sys/dev/xen/blkback/blkback.c: sys/dev/xen/blkfront/blkfront.c: sys/dev/xen/blkfront/block.h: o Negotiate with the other-end with the following limits: Reqeust Size: MAXPHYS Max Segments: (MAXPHYS/PAGE_SIZE) + 1 Max Requests: 256 Max Ring Pages: Sufficient to support Max Requests with Max Segments. o Dynamically allocate request pools and segemnts-per-request. o Update ring allocation/attachment code to support a multi-page shared ring. o Update routines that access the shared ring to handle multi-block requests. sys/dev/xen/blkfront/blkfront.c: o Track blkfront allocations in a blkfront driver specific malloc pool. o Strip out XenStore transaction retry logic in the connection code. Transactions only need to be used when the update to multiple XenStore nodes must be atomic. That is not the case here. o Fully disable blkif_resume() until it can be fixed properly (it didn't work before this change). o Destroy bus-dma objects during device instance tear-down. sys/dev/xen/blkback/blkback.c: Advertise support for and implement the BLKIF_OP_WRITE_BARRIER and BLKIF_OP_FLUSH_DISKCACHE blkif opcodes using BIO_FLUSH and the BIO_ORDERED attribute of bios. sys/dev/xen/blkfront/blkfront.c: sys/dev/xen/blkfront/block.h: Fix various bugs in blkfront. blkfront.c: gnttab_alloc_grant_references() returns 0 for success and non-zero for failure. The check for < 0 is a leftover Linuxism. When we negotiate with blkback and have to reduce some of our capabilities, print out the original and reduced capability before changing the local capability. So the user now gets the correct information. Fix blkif_restart_queue_callback() formatting. Make sure we hold the mutex in that function before calling xb_startio(). Fix a couple of KASSERT()s. block.h: Fix a check in the xb_remove_* macro to be a little more specific. sys/dev/xen/control/control.c: Add a XenBus front driver for handling shutdown, reboot, suspend, and resume events published in the XenStore. Move all PV suspend/reboot support from reboot.c into this driver. sys/xen/gnttab.h: sys/xen/gnttab.c: Define GNTTAB_LIST_END as GRANT_REF_INVALID. Get rid of our private definition of GNTTAB_LIST_END. sys/dev/xen/netfront/netfront.c: Use GRANT_REF_INVALID instead of driver private definitions of the same constant. sys/xen/gnttab.h: sys/xen/gnttab.c: Add the gnttab_end_foreign_access_references() API. This API allows a client to batch the release of an array of grant references, instead of coding a private for loop. The implementation takes advantage of this batching to reduce lock overhead to one acquisition and release per-batch instead of per-freed grant reference. While here, reduce the duration the gnttab_list_lock is held during gnttab_free_grant_references() operations. The search to find the tail of the incoming free list does not rely on global state and so can be performed without holding the lock. sys/dev/xen/xenpci/evtchn.c: sys/dev/xen/evtchn/evtchn.c: sys/xen/xen_intr.h: o Implement the bind_interdomain_evtchn_to_irqhandler API for HVM mode. This allows an HVM domain to serve back end devices to other domains. This API is already implemented for PV mode. o Synchronize the API between HVM and PV. sys/dev/xen/xenpci/xenpci.c: o Scan the full region of CPUID space in which the Xen VMM interface may be implemented. On systems using SuSE as a Dom0 where the Viridian API is also exported, the VMM interface is above the region we used to search. o Pass through bus_alloc_resource() calls so that XenBus drivers attaching on an HVM system can allocate unused physical address space from the nexus. The block back driver makes use of this facility. sys/i386/xen/xen_machdep.c: o Use the correct type for accessing the statically mapped xenstore metadata. sys/xen/interface/hvm/params.h: sys/xen/xenstore/xenstore.c: Move hvm_get_parameter() to the correct global header file instead of as a private method to the XenStore. sys/xen/interface/io/protocols.h: Sync with vendor. sys/xeninterface/io/ring.h: Add macro for calculating the number of ring pages needed for an N deep ring. To avoid duplication within the macros, create and use the new __RING_HEADER_SIZE() macro. This macro calculates the size of the ring book keeping struct (producer/consumer indexes, etc.) that resides at the head of the ring. Add the __RING_PAGES() macro which calculates the number of shared ring pages required to support a ring with the given number of requests. These APIs are used to support the multi-page ring version of the Xen block API. sys/xeninterface/io/xenbus.h: Add Comments. sys/xen/xenbus/... Refactor the FreeBSD XenBus support code to allow for both front and backend device attachments. Make use of new config_intr_hook capabilities to allow front and back devices to be probed/attached in parallel. Fix bugs in probe/attach state machine that could cause the system to hang when confronted with a failure either in the local domain or in a remote domain to which one of our driver instances is attaching. Publish all required state to the XenStore on device detach and failure. The majority of the missing functionality was for serving as a back end since the typical "hot-plug" scripts in Dom0 don't handle the case of cleaning up for a "service domain" that is not itself. Add doxygen style comments to the majority of the code. Cleanup types, formatting, etc. sys/xen/xenbus/xenbusb.c: Common code used by both front and back XenBus busses. sys/xen/xenbus/xenbusb_if.m: Method definitions for a XenBus bus. sys/xen/xenbus/xenbusb_front.c: sys/xen/xenbus/xenbusb_back.c: XenBus bus specialization for front and back devices. From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 15:39:21 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 397321065670; Fri, 17 Sep 2010 15:39:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id F02908FC1F; Fri, 17 Sep 2010 15:39:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o8HFW5O7019215; Fri, 17 Sep 2010 09:32:05 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 17 Sep 2010 09:32:15 -0600 (MDT) Message-Id: <20100917.093215.390976035188294401.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <201009160828.35520.jhb@freebsd.org> References: <20100915063233.GE1036@pluto.vnode.local> <201009160828.35520.jhb@freebsd.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, joel@FreeBSD.org Subject: Re: Multiple hpet messages during boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 15:39:21 -0000 In message: <201009160828.35520.jhb@freebsd.org> John Baldwin writes: : On Wednesday, September 15, 2010 2:32:33 am Joel Dahl wrote: : > I noticed this during boot (HEAD from yesterday): : > : > hpet0: [FILTER] : > hpet0: [FILTER] : > hpet0: [FILTER] : > hpet0: [FILTER] : > hpet0: [FILTER] : > hpet0: [FILTER] : > hpet0: [FILTER] : > hpet0: [FILTER] : > : > Is it really necessary to print this 8 times? : : I'd actually like to remove the interrupt messages that say '[FILTER]' or : '[GIANT]', etc. I think in general they only add clutter. [GIANT] is just public shaming of drivers anyway. It has worked to get them all the major ones locked. Well, except for atkbd and psm... I'd be happy to toss them behind a bootverbose :) Warner From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 15:39:21 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B77601065693; Fri, 17 Sep 2010 15:39:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 763828FC20; Fri, 17 Sep 2010 15:39:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o8HFa3RE019284; Fri, 17 Sep 2010 09:36:03 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 17 Sep 2010 09:36:13 -0600 (MDT) Message-Id: <20100917.093613.490009667275365136.imp@bsdimp.com> To: joel@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20100917055953.GF1036@pluto.vnode.local> References: <20100915063233.GE1036@pluto.vnode.local> <201009160828.35520.jhb@freebsd.org> <20100917055953.GF1036@pluto.vnode.local> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, jhb@FreeBSD.org Subject: Re: Multiple hpet messages during boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 15:39:21 -0000 In message: <20100917055953.GF1036@pluto.vnode.local> Joel Dahl writes: : On 16-09-2010 8:28, John Baldwin wrote: : > On Wednesday, September 15, 2010 2:32:33 am Joel Dahl wrote: : > > I noticed this during boot (HEAD from yesterday): : > > : > > hpet0: [FILTER] : > > hpet0: [FILTER] : > > hpet0: [FILTER] : > > hpet0: [FILTER] : > > hpet0: [FILTER] : > > hpet0: [FILTER] : > > hpet0: [FILTER] : > > hpet0: [FILTER] : > > : > > Is it really necessary to print this 8 times? : > : > I'd actually like to remove the interrupt messages that say '[FILTER]' or : > '[GIANT]', etc. I think in general they only add clutter. : : Definitely agreed. Go for it. so is there support for the following: Index: subr_bus.c =================================================================== --- subr_bus.c (revision 212791) +++ subr_bus.c (working copy) @@ -3996,9 +3996,11 @@ arg, cookiep); if (error != 0) return (error); + if (bootverbose == 0) + return (0); if (handler != NULL && !(flags & INTR_MPSAFE)) device_printf(dev, "[GIANT-LOCKED]\n"); - if (bootverbose && (flags & INTR_MPSAFE)) + if (flags & INTR_MPSAFE) device_printf(dev, "[MPSAFE]\n"); if (filter != NULL) { if (handler == NULL) Warner From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 15:57:50 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1FC01065672 for ; Fri, 17 Sep 2010 15:57:50 +0000 (UTC) (envelope-from ale@FreeBSD.org) Received: from andxor.it (relay.andxor.it [195.223.2.3]) by mx1.freebsd.org (Postfix) with SMTP id 143548FC19 for ; Fri, 17 Sep 2010 15:57:49 +0000 (UTC) Received: (qmail 6496 invoked from network); 17 Sep 2010 15:31:08 -0000 Received: from unknown (HELO ale.andxor.it) (192.168.2.5) by andxor.it with SMTP; 17 Sep 2010 15:31:08 -0000 Message-ID: <4C9389BC.7090300@FreeBSD.org> Date: Fri, 17 Sep 2010 17:31:08 +0200 From: Alex Dupre User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Subject: Regarding pciids X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 15:57:50 -0000 I created hackish scripts to generate pci_vendors file from Boemler and Mares (pciids.sf.net) lists. I haven't found the Hart list. The results of the scripts are here: http://www.alexdupre.com/pci_vendors/mares.txt http://www.alexdupre.com/pci_vendors/boemler.txt http://www.alexdupre.com/pci_vendors/mares-boemler.txt http://www.alexdupre.com/pci_vendors/boemler-mares.txt The first two are generated from single lists, the last two are combined, with different preference order. -- Alex Dupre From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 16:08:13 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BF3D1065670 for ; Fri, 17 Sep 2010 16:08:13 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C69218FC0C for ; Fri, 17 Sep 2010 16:08:12 +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 TAA24508; Fri, 17 Sep 2010 19:08:06 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C939265.20507@icyb.net.ua> Date: Fri, 17 Sep 2010 19:08:05 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100909 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: "M. Warner Losh" References: <20100915063233.GE1036@pluto.vnode.local> <201009160828.35520.jhb@freebsd.org> <20100917055953.GF1036@pluto.vnode.local> <20100917.093613.490009667275365136.imp@bsdimp.com> In-Reply-To: <20100917.093613.490009667275365136.imp@bsdimp.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Multiple hpet messages during boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 16:08:13 -0000 on 17/09/2010 18:36 M. Warner Losh said the following: > > so is there support for the following: Aye. > Index: subr_bus.c > =================================================================== > --- subr_bus.c (revision 212791) > +++ subr_bus.c (working copy) > @@ -3996,9 +3996,11 @@ > arg, cookiep); > if (error != 0) > return (error); > + if (bootverbose == 0) > + return (0); > if (handler != NULL && !(flags & INTR_MPSAFE)) > device_printf(dev, "[GIANT-LOCKED]\n"); > - if (bootverbose && (flags & INTR_MPSAFE)) > + if (flags & INTR_MPSAFE) > device_printf(dev, "[MPSAFE]\n"); > if (filter != NULL) { > if (handler == NULL) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 16:07:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A5961065672 for ; Fri, 17 Sep 2010 16:07:22 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 540118FC17 for ; Fri, 17 Sep 2010 16:07:22 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OwdT5-0005ub-Pg for freebsd-current@freebsd.org; Fri, 17 Sep 2010 18:07:19 +0200 Received: from k.saper.info ([91.121.151.35]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Sep 2010 18:07:19 +0200 Received: from saper by k.saper.info with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 17 Sep 2010 18:07:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Marcin Cieslak Date: Fri, 17 Sep 2010 16:07:11 +0000 (UTC) Organization: http://saper.info Lines: 7 Message-ID: References: <201009151749.45038.jhb@freebsd.org> <201009170854.56516.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: k.saper.info User-Agent: slrn/0.9.9p1 (FreeBSD) X-Mailman-Approved-At: Fri, 17 Sep 2010 16:14:29 +0000 Subject: Re: tun(4) in -CURRENT: No buffer space available - race condition patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 16:07:22 -0000 >> John Baldwin wrote: > Oh, yes. I've updated the patch to remove D_NEEDGIANT. So far (last 24 hours) my tun(4) with your patch was very stable. I am updating it to remove D_NEEDGIANT. Thank you! //Marcin From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 20:24:30 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 414181065674; Fri, 17 Sep 2010 20:24:30 +0000 (UTC) (envelope-from nlopes.ml@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 A1B5C8FC1C; Fri, 17 Sep 2010 20:24:29 +0000 (UTC) Received: by wwi17 with SMTP id 17so99147wwi.31 for ; Fri, 17 Sep 2010 13:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type:subject :date:message-id:cc:to:mime-version:x-mailer; bh=WKsOaRx+wAt7+yPonQ8GHqOVeaowm2OviwOYq5knecc=; b=SZ3U9HpfQJYqLUgPgEaG4OfUWfMrC5WZtf+ojej5Zd5x9n9xbwcihTw8Vyy0maAMGu SZAK74JrtjwQdsGNvDC5Fr7BgcN5urnBOoHneWyRq6uYEHlRbyh0GIo/m7jczSBOz0vw mc9WlciiziCbojc5QgFu72RO7A8RfR91Rrrvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:subject:date:message-id:cc:to:mime-version :x-mailer; b=pR79Foi/8P/ASFDJ+6SyRvbF70/icJJWj4b7M8a3FHqpuUTuGVojVHO3dYqo70sW66 IqicPzk+NPhNr1xgVWwTHXpMttQw8GJrbaLwUktl3fHlp2w7TJW+u3X2j8IRl5h5jOYN ys5vQxgn369k9y+ZIovHyUVV8z6o7szNUEBtE= Received: by 10.216.71.132 with SMTP id r4mr1208248wed.102.1284753329809; Fri, 17 Sep 2010 12:55:29 -0700 (PDT) Received: from [192.168.1.51] ([93.5.162.111]) by mx.google.com with ESMTPS id p45sm2967567weq.21.2010.09.17.12.55.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 17 Sep 2010 12:55:28 -0700 (PDT) From: Norberto Lopes Date: Fri, 17 Sep 2010 21:55:26 +0200 Message-Id: <8C5C36F5-A070-4CBA-8B8C-6751F8D636E1@gmail.com> To: freebsd-current@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: netchild@freebsd.org Subject: Extend ktrace/kdump output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 20:24:30 -0000 Hi. I've been taking a look at ktrace and kdump in order to get (1) familiar = with the sources and (2) to finally try to give back something to the = community. So far from what I've seen, and after reading this thread = http://lists.freebsd.org/pipermail/freebsd-arch/2006-April/005107.html = it seems that most of those points got done. To warm up I changed the output of the stat structure in order to = provide me with the device name (something I actually find useful for me = sometimes) Instead of: 22596 cat STRU struct stat {dev=3D89, ino=3D3320836, = mode=3D-r--r--r-- , nlink=3D1, uid=3D0, gid=3D0, atime=3D1284725358, = stime=3D1284485510, ctime=3D1284485510, birthtime=3D1284485509, = size=3D1172220, blksize=3D16384, blocks=3D2336, flags=3D0x20000 } I get this now (including major and minor): 22596 cat STRU struct stat {dev=3D = (/dev/ad4s1a), ino=3D3320836, mode=3D-r--r--r-- , nlink=3D1, uid=3D0, = gid=3D0, atime=3D1284725358, stime=3D1284485510, ctime=3D1284485510, = birthtime=3D1284485509, size=3D1172220, blksize=3D16384, blocks=3D2336, = flags=3D0x20000 } I wouldn't mind having someone help me whenever and if I get stuck on = the technical side (*wink* Alexander Leidinger *wink*) and also to give = me more insight on what the road to help in this should be. P.S.: I'm still going through "man style" hence no patch attached. If = anyone finds this one useful, I'll reply with the patch though.=20 -- Norberto= From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 20:36:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D17A2106567A for ; Fri, 17 Sep 2010 20:36:49 +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 6B5908FC15 for ; Fri, 17 Sep 2010 20:36:49 +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 o8HKajIl096621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Sep 2010 23:36:45 +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 o8HKajLd022048; Fri, 17 Sep 2010 23:36:45 +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 o8HKajCK022047; Fri, 17 Sep 2010 23:36:45 +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: Fri, 17 Sep 2010 23:36:45 +0300 From: Kostik Belousov To: Norberto Lopes Message-ID: <20100917203645.GS2389@deviant.kiev.zoral.com.ua> References: <8C5C36F5-A070-4CBA-8B8C-6751F8D636E1@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uX7BrQs69PbBafpd" Content-Disposition: inline In-Reply-To: <8C5C36F5-A070-4CBA-8B8C-6751F8D636E1@gmail.com> 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=-2.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_20, 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-current@freebsd.org, netchild@freebsd.org Subject: Re: Extend ktrace/kdump output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 20:36:50 -0000 --uX7BrQs69PbBafpd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 17, 2010 at 09:55:26PM +0200, Norberto Lopes wrote: > Hi. > I've been taking a look at ktrace and kdump in order to get (1) familiar = with the sources and (2) to finally try to give back something to the commu= nity. >=20 > So far from what I've seen, and after reading this thread http://lists.fr= eebsd.org/pipermail/freebsd-arch/2006-April/005107.html it seems that most = of those points got done. >=20 > To warm up I changed the output of the stat structure in order to provide= me with the device name (something I actually find useful for me sometimes) >=20 > Instead of: > 22596 cat STRU struct stat {dev=3D89, ino=3D3320836, mode=3D-r--r-= -r-- , nlink=3D1, uid=3D0, gid=3D0, atime=3D1284725358, stime=3D1284485510,= ctime=3D1284485510, birthtime=3D1284485509, size=3D1172220, blksize=3D1638= 4, blocks=3D2336, flags=3D0x20000 } >=20 > I get this now (including major and minor): > 22596 cat STRU struct stat {dev=3D (/dev/ad4= s1a), ino=3D3320836, mode=3D-r--r--r-- , nlink=3D1, uid=3D0, gid=3D0, atime= =3D1284725358, stime=3D1284485510, ctime=3D1284485510, birthtime=3D12844855= 09, size=3D1172220, blksize=3D16384, blocks=3D2336, flags=3D0x20000 } >=20 > I wouldn't mind having someone help me whenever and if I get stuck on the= technical side (*wink* Alexander Leidinger *wink*) and also to give me mor= e insight on what the road to help in this should be. >=20 > P.S.: I'm still going through "man style" hence no patch attached. If any= one finds this one useful, I'll reply with the patch though.=20 >=20 How do you look up the device name by st_dev ? Note that the number is generated by devfs at the moment of cdev creation. It is only valid on the machine where stat(2) is done, and only due to the next reboot. --uX7BrQs69PbBafpd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkyT0VwACgkQC3+MBN1Mb4jDKQCdHprRPpvbNvS/3YP6M9wCnvNB NNIAoJb4mvgdHGu34JuSV5vVmr9Xc61Q =grLI -----END PGP SIGNATURE----- --uX7BrQs69PbBafpd-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 20:48:44 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9366E106566C; Fri, 17 Sep 2010 20:48:44 +0000 (UTC) (envelope-from nlopes.ml@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 2EC028FC18; Fri, 17 Sep 2010 20:48:43 +0000 (UTC) Received: by qyk31 with SMTP id 31so1352088qyk.13 for ; Fri, 17 Sep 2010 13:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BIt9XG2Ma6WoUQjqGtOTheWzRuuHkia1/+Ve0HITpeA=; b=NJeHMv8M9lPC0lBelqdXp3UdQAkFzltg8ln7b48o9FDEHYyT1Wwg24xYRiFIwTvdHv 29es1faH6IihVrYlgjgiFwB8AQlqjFSdNk0hkUzw33Vs4wLmWS28sBrIieuuYoLTybVz PXLNFzspW+j9h0Eqp65RtWQyindgF5P+R3apg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pjHekwGr4bnNQ4hZak3GtpK9RTqlyLCTIXIEzqrfhXwZkDc8z4ot5YIebaQcfgGr9B r74NdxVo8mQldNJF3Eks3ntorXfgNYYOtX+BGfPDbNla5ePShBORMta0HAYJiYWvdZBB T75EAVvASdXRpBvpzJB1fxFUN2N1u2ziFcf2g= MIME-Version: 1.0 Received: by 10.224.54.143 with SMTP id q15mr3757445qag.399.1284756523294; Fri, 17 Sep 2010 13:48:43 -0700 (PDT) Received: by 10.229.236.193 with HTTP; Fri, 17 Sep 2010 13:48:43 -0700 (PDT) In-Reply-To: <20100917203645.GS2389@deviant.kiev.zoral.com.ua> References: <8C5C36F5-A070-4CBA-8B8C-6751F8D636E1@gmail.com> <20100917203645.GS2389@deviant.kiev.zoral.com.ua> Date: Fri, 17 Sep 2010 22:48:43 +0200 Message-ID: From: Norberto Lopes To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, netchild@freebsd.org Subject: Re: Extend ktrace/kdump output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 20:48:44 -0000 On Fri, Sep 17, 2010 at 10:36 PM, Kostik Belousov wro= te: > On Fri, Sep 17, 2010 at 09:55:26PM +0200, Norberto Lopes wrote: >> Hi. >> I've been taking a look at ktrace and kdump in order to get (1) familiar= with the sources and (2) to finally try to give back something to the comm= unity. >> >> So far from what I've seen, and after reading this thread http://lists.f= reebsd.org/pipermail/freebsd-arch/2006-April/005107.html it seems that most= of those points got done. >> >> To warm up I changed the output of the stat structure in order to provid= e me with the device name (something I actually find useful for me sometime= s) >> >> Instead of: >> =C2=A022596 cat =C2=A0 =C2=A0 =C2=A0STRU =C2=A0struct stat {dev=3D89, in= o=3D3320836, mode=3D-r--r--r-- , nlink=3D1, uid=3D0, gid=3D0, atime=3D12847= 25358, stime=3D1284485510, ctime=3D1284485510, birthtime=3D1284485509, size= =3D1172220, blksize=3D16384, blocks=3D2336, flags=3D0x20000 } >> >> I get this now (including major and minor): >> =C2=A022596 cat =C2=A0 =C2=A0 =C2=A0STRU =C2=A0struct stat {dev=3D (/dev/ad4s1a), ino=3D3320836, mode=3D-r--r--r-- , nlink=3D= 1, uid=3D0, gid=3D0, atime=3D1284725358, stime=3D1284485510, ctime=3D128448= 5510, birthtime=3D1284485509, size=3D1172220, blksize=3D16384, blocks=3D233= 6, flags=3D0x20000 } >> >> I wouldn't mind having someone help me whenever and if I get stuck on th= e technical side (*wink* Alexander Leidinger *wink*) and also to give me mo= re insight on what the road to help in this should be. >> >> P.S.: I'm still going through "man style" hence no patch attached. If an= yone finds this one useful, I'll reply with the patch though. >> > How do you look up the device name by st_dev ? Note that the number is > generated by devfs at the moment of cdev creation. It is only valid on > the machine where stat(2) is done, and only due to the next reboot. > Through a really ugly hack... opendir("/dev") readdir("/dev") go through them and find the one... Yes, I know, painful and ugly, but as I usually use kdump with no reboots between analysis (I hardly ever reboot actually), and because I find it exhausting to keep going back to look up the device name, this kept me happy enough. :) From owner-freebsd-current@FreeBSD.ORG Fri Sep 17 23:46:08 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A3AF106564A for ; Fri, 17 Sep 2010 23:46:08 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id D9D248FC0A for ; Fri, 17 Sep 2010 23:46:05 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0629A45D8D; Sat, 18 Sep 2010 01:46:04 +0200 (CEST) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id DC9B545C9B; Sat, 18 Sep 2010 01:45:58 +0200 (CEST) Date: Sat, 18 Sep 2010 01:45:42 +0200 From: Pawel Jakub Dawidek To: freebsd-arch@FreeBSD.org Message-ID: <20100917234542.GE1902@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q8BnQc91gJZX4vDc" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 Cc: freebsd-current@FreeBSD.org Subject: gptboot rewrite, bootonce, etc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 23:46:08 -0000 --Q8BnQc91gJZX4vDc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. My company was in need for functionality similar to nextboot(8), but on boot loader level, so we can have two partitions we boot from where one is known to be good and the other is used for upgrades. We upgrade by dd(1)ing entire partition image onto unused partition, we mark it as try-to-boot-from-it-but-only-once, reboot and if we fail to boot from the new partition, we fall back to the old, good partition. If we succeed on the other hand, we mark the new partition as our boot partition and mark the other one as unused. Well, how hard can it be? After around two weeks of work, I ended up rewriting gptboot in large parts, reorganizing a lot of code, improving and extending gpart a bit and implementing desire functionality. Here is the patch for review and test: http://people.freebsd.org/~pjd/patches/gptboot.patch The list of changes: - Split code shared by almost any boot loader into separate files and clean up most layering violations: sys/boot/i386/common/rbx.h: RBX_* defines OPT_SET() OPT_CHECK() sys/boot/common/util.[ch]: memcpy() memset() memcmp() bcpy() bzero() bcmp() strcmp() strncmp() [new] strcpy() strcat() strchr() strlen() printf() sys/boot/i386/common/cons.[ch]: ioctrl putc() xputc() putchar() getc() xgetc() keyhit() [now takes number of seconds as an argument] getstr() sys/boot/i386/common/drv.[ch]: struct dsk drvread() drvwrite() [new] drvsize() [new] sys/boot/common/crc32.[ch] [new] sys/boot/common/gpt.[ch] [new] - Teach gptboot and gptzfsboot about new files. I haven't touched the rest, but there is still a lot of code duplication to be removed. - Implement full GPT support. Currently we just read primary header and partition table and don't care about checksums, etc. With the patch we verify checksums of primary header and primary partition table and if there is a problem we fall back to backup header and backup partition table. - Clean up most messages to use prefix of boot program, so in case of an error we know where the error comes from, eg.: gptboot: unable to read primary GPT header - If we can't boot, print boot prompt only once and not every five seconds. - Introduce three new GPT attributes: bootme - this is bootable partition bootonce - try to boot from this partition only once bootfailed - we failed to boot from this partition - Extend gpart to allow to manipulate new attributes: gpart set -a bootme -i 3 ada0 gpart set -a bootonce -i 4 ada0 gpart unset -a bootfailed -i 2 ada0 Note, that setting 'bootonce' attribute automatically sets 'bootme' attribute. - Change boot order of gptboot to the following: 1. Try to boot from all the partitions that have both 'bootme' and 'bootonce' attributes one by one. 2. Try to boot from all the partitions that have only 'bootme' attribute one by one. 3. If there are no partitions with 'bootme' attribute, boot from the first UFS partition. - The 'bootonce' functionality is implemented in the following way: 1. Walk through all the partitions and when 'bootonce' attribute is found without 'bootme' attribute, remove 'bootonce' attribute and set 'bootfailed' attribute. 'bootonce' attribute alone means that we tried to boot from this partition, but boot failed after leaving gptboot and machine was restarted. 2. Find partition with both 'bootme' and 'bootonce' attributes. 3. Remove 'bootme' attribute. 4. Try to execute /boot/loader or /boot/kernel/kernel from that partition. If succeeded we stop here. 5. If execution failed, remove 'bootonce' and set 'bootfailed'. 6. Go to 2. If whole boot succeeded there is new /etc/rc.d/gptboot script that will log all partitions that we failed to boot from (the ones with 'bootfailed' attribute) and will remove this attribute. It will also find partition with 'bootonce' attribute - this is the partition we booted from successfully. The script will log success and remove the attribute. All the GPT updates we do here goes to both primary and backup GPT if they are valid. We don't touch headers or partition tables when checksum doesn't match. Any comments or suggestions? Be aware that at this point I'm soo full of boot loaders and I'm not looking for much more work in this area, so small tweaks are fine, but bigger things will have to wait until I can sleep at nights again. Well, there is still dedup support that waits to be implemented in gptzfsboot... --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Q8BnQc91gJZX4vDc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkyT/aUACgkQForvXbEpPzTjJACfWIEFMstjYV+1bPilgCjx90pB Cb8An3XfrBMtepSeQWX0IYnuLJrOIH2i =yKLn -----END PGP SIGNATURE----- --Q8BnQc91gJZX4vDc-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 18 04:16:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B1C31065670; Sat, 18 Sep 2010 04:16:03 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outn.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id 2BEB28FC0A; Sat, 18 Sep 2010 04:16:02 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o8I456jF012205; Fri, 17 Sep 2010 21:05:07 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 1695C2D6010; Fri, 17 Sep 2010 21:05:05 -0700 (PDT) Message-ID: <4C943A94.5020606@freebsd.org> Date: Fri, 17 Sep 2010 21:05:40 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20100917234542.GE1902@garage.freebsd.pl> In-Reply-To: <20100917234542.GE1902@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: Re: gptboot rewrite, bootonce, etc. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 04:16:03 -0000 On 9/17/10 4:45 PM, Pawel Jakub Dawidek wrote: > Hi. > > My company was in need for functionality similar to nextboot(8), but on > boot loader level, so we can have two partitions we boot from where one > is known to be good and the other is used for upgrades. We upgrade by > dd(1)ing entire partition image onto unused partition, we mark it as > try-to-boot-from-it-but-only-once, reboot and if we fail to boot from > the new partition, we fall back to the old, good partition. If we > succeed on the other hand, we mark the new partition as our boot > partition and mark the other one as unused. > > Well, how hard can it be? > > After around two weeks of work, I ended up rewriting gptboot in large > parts, reorganizing a lot of code, improving and extending gpart a bit > and implementing desire functionality. > > Here is the patch for review and test: > > http://people.freebsd.org/~pjd/patches/gptboot.patch > > The list of changes: > > - Split code shared by almost any boot loader into separate files and > clean up most layering violations: > > sys/boot/i386/common/rbx.h: > > RBX_* defines > OPT_SET() > OPT_CHECK() > > sys/boot/common/util.[ch]: > > memcpy() > memset() > memcmp() > bcpy() > bzero() > bcmp() > strcmp() > strncmp() [new] > strcpy() > strcat() > strchr() > strlen() > printf() > > sys/boot/i386/common/cons.[ch]: > > ioctrl > putc() > xputc() > putchar() > getc() > xgetc() > keyhit() [now takes number of seconds as an argument] > getstr() > > sys/boot/i386/common/drv.[ch]: > > struct dsk > drvread() > drvwrite() [new] > drvsize() [new] > > sys/boot/common/crc32.[ch] [new] > > sys/boot/common/gpt.[ch] [new] > > - Teach gptboot and gptzfsboot about new files. I haven't touched the > rest, but there is still a lot of code duplication to be removed. > > - Implement full GPT support. Currently we just read primary header and > partition table and don't care about checksums, etc. With the patch we > verify checksums of primary header and primary partition table and if > there is a problem we fall back to backup header and backup partition > table. > > - Clean up most messages to use prefix of boot program, so in case of an > error we know where the error comes from, eg.: > > gptboot: unable to read primary GPT header > > - If we can't boot, print boot prompt only once and not every five > seconds. > > - Introduce three new GPT attributes: > > bootme - this is bootable partition > bootonce - try to boot from this partition only once > bootfailed - we failed to boot from this partition > > - Extend gpart to allow to manipulate new attributes: > > gpart set -a bootme -i 3 ada0 > gpart set -a bootonce -i 4 ada0 > gpart unset -a bootfailed -i 2 ada0 > > Note, that setting 'bootonce' attribute automatically sets 'bootme' > attribute. > > - Change boot order of gptboot to the following: > > 1. Try to boot from all the partitions that have both 'bootme' > and 'bootonce' attributes one by one. > 2. Try to boot from all the partitions that have only 'bootme' > attribute one by one. > 3. If there are no partitions with 'bootme' attribute, boot from > the first UFS partition. > > - The 'bootonce' functionality is implemented in the following way: > > 1. Walk through all the partitions and when 'bootonce' > attribute is found without 'bootme' attribute, remove > 'bootonce' attribute and set 'bootfailed' attribute. > 'bootonce' attribute alone means that we tried to boot from > this partition, but boot failed after leaving gptboot and > machine was restarted. > 2. Find partition with both 'bootme' and 'bootonce' attributes. > 3. Remove 'bootme' attribute. > 4. Try to execute /boot/loader or /boot/kernel/kernel from that > partition. If succeeded we stop here. > 5. If execution failed, remove 'bootonce' and set 'bootfailed'. > 6. Go to 2. > > If whole boot succeeded there is new /etc/rc.d/gptboot script that > will log all partitions that we failed to boot from (the ones with > 'bootfailed' attribute) and will remove this attribute. It will also > find partition with 'bootonce' attribute - this is the partition we > booted from successfully. The script will log success and remove the > attribute. > > All the GPT updates we do here goes to both primary and backup GPT if > they are valid. We don't touch headers or partition tables when > checksum doesn't match. > > Any comments or suggestions? Be aware that at this point I'm soo full of > boot loaders and I'm not looking for much more work in this area, so > small tweaks are fine, but bigger things will have to wait until I can > sleep at nights again. Well, there is still dedup support that waits to > be implemented in gptzfsboot... nextboot USED to work at the bootloader level, but it got broken^H^H^H^H^H^H^H changed by someone several years ago. Ironport still use the old bootblock for that reason. It used to store the string for boot1 to use in the second block of the disk and boot0 would read it and write it back disabled using a bios command, so that the boot after that would not do it again if it failed. boot0 then passed it to boot1 in the stack to use. I did have a version that kept the boot string in a special partition. (of 1 block) Obviously what you are doing is much more fancy. From owner-freebsd-current@FreeBSD.ORG Sat Sep 18 08:10:15 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7C01106566B; Sat, 18 Sep 2010 08:10:15 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id 6A5A58FC0A; Sat, 18 Sep 2010 08:10:15 +0000 (UTC) Received: from b.earth.lavabit.com (b.earth.lavabit.com [192.168.111.11]) by karen.lavabit.com (Postfix) with ESMTP id A090311B886; Sat, 18 Sep 2010 03:10:14 -0500 (CDT) Received: from rui-macbook.lan (83.144.140.56) by lavabit.com with ESMTP id 0EHP40G978KT; Sat, 18 Sep 2010 03:10:14 -0500 References: <4C92C815.7070508@scsiguy.com> <1801A881-E1C8-4B41-AD14-940686A37A27@FreeBSD.org> <57D2C852-4A1E-41AC-8074-BBBA8E0E7DCF@FreeBSD.org> <4C938AEE.2080006@scsiguy.com> In-Reply-To: <4C938AEE.2080006@scsiguy.com> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <0DB67CB1-B2E3-487D-A7DB-E11D6778C62D@freebsd.org> Content-Transfer-Encoding: quoted-printable From: Rui Paulo Date: Sat, 18 Sep 2010 09:10:11 +0100 To: Justin T. Gibbs X-Mailer: Apple Mail (2.1081) Cc: "current@freebsd.org Current" , xen@freebsd.org Subject: Re: CFT - Xen infrastructure and block I/O improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 08:10:15 -0000 On 17 Sep 2010, at 16:36, Justin T. Gibbs wrote: > On 9/17/2010 1:27 AM, Rui Paulo wrote: >> On 17 Sep 2010, at 07:55, Rui Paulo wrote: >>=20 >>> On 17 Sep 2010, at 02:44, Justin T. Gibbs wrote: >>>=20 >>>> At Spectra Logic, we are using FreeBSD amd64 under Xen to serve = storage >>>> to other Xen domains. Over the past 9 months, we've made several = changes >>>> to FreeBSD's Xen support. These include: >=20 > ... >=20 >>> Justin, this is quite a big diff (16k lines). I wonder if you can = create >>> separate diffs (xenstore, blkback, xenbus, etc.) for easier review = and >>> commenting. >>=20 >> '... and comment'. >=20 > The bulk of the patch is due to code reorganization. Unfortunately = SVN > doesn't reflect the copies properly in a diff, but at least the diff = will > apply properly even in a non-SVN backed source tree. This original = patch > should be the best for testers. >=20 > The following SVN operations were made to the source tree to clean up = it's > organization and to import functionality from the vendor (1 file): >=20 > # Does not apply to FreeBSD's NewBus method for dealing with XenBus = devices > svn delete sys/xen/xenbus/init.txt >=20 > # Linux version of backend XenBus service routines. Never ported to = FreeBSD. > # OBE: See xenbusb.c, xenbusb_if.m, xenbusb_front.c xenbusb_back.c > svn delete sys/xen/xenbus/xenbus_probe_backend.c >=20 > # Split XenStore into its own tree. XenBus is a software layer built = on top > # of XenStore. The old arrangement and the naming of some structures = and > # functions blurred these lines making it difficult to discern what = services > # are provided by which layer and what times these services are = available > # (e.g. during system startup and shutdown). > mkdir sys/xen/xenstore > svn add sys/xen/xenstore > svn move sys/xen/xenbus/xenbus_dev.c sys/xen/xenstore/xenstore_dev.c > svn copy sys/xen/xenbus/xenbusvar.h sys/xen/xenstore/xenstorevar.h > svn move sys/xen/xenbus/xenbus_xs.c sys/xen/xenstore/xenstore.c >=20 > # Split up XenBus code into methods available for use by client > # drivers (xenbus.c) and code used by the XenBus "bus code" to > # enumerate, attach, detach, and service bus drivers. > svn move sys/xen/xenbus/xenbus_client.c sys/xen/xenbus/xenbus.c > svn move sys/xen/xenbus/xenbus_probe.c sys/xen/xenbus/xenbusb.c > svn copy sys/xen/xenbus/xenbusb.c sys/xen/xenbus/xenbusb.h >=20 > # Merged with xenstore.c > svn delete sys/xen/xenbus/xenbus_comms.c > svn delete sys/xen/xenbus/xenbus_comms.h >=20 > # Merged with new XenBus control driver > mkdir sys/dev/xen/control > svn add sys/dev/xen/control > svn move sys/xen/reboot.c sys/dev/xen/control/control.c >=20 > # New file from Xen vendor with macros and structures used by > # a block back driver to service requires from a VM running a > # different ABI (e.g. amd64 back with i386 front). > svn add sys/xen/blkif.h >=20 > These alone account for 6k lines of svn diff. >=20 > A diff against a tree with these operations already made may make more = sense > to a reviewer. You can download this diff from here: >=20 > = http://people.FreeBSD.org/~gibbs/FreeBSD-head-xen_post-svn-ops_2010-09-17_= diffs.txt >=20 > It isn't much shorter since the additional context has amplified the = changes. > The bulk is largely caused by refactoring, and comments. It will > probably be easier to just review the files in sys/xen/xenstore and > sys/xen/xenbus in their entirety, but the comments bellow (boiled down = from > our SCM system), when coupled with the diffs, should give you enough = information > to understand the intentions behind the changes. Oh, IC. It's still pretty large and I don't have the necessary time, but = it appears that this is good to go (am afraid the past people who have = worked on Xen are now gone, no?). -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Sat Sep 18 09:28:02 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BEE11065670; Sat, 18 Sep 2010 09:28:02 +0000 (UTC) (envelope-from nlopes.ml@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 9ED458FC12; Sat, 18 Sep 2010 09:28:01 +0000 (UTC) Received: by qyk31 with SMTP id 31so1679181qyk.13 for ; Sat, 18 Sep 2010 02:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=iM6oMPW8mgF7Ag6q+gGyMZlCdGhRj9ElUkGvWsAppc8=; b=ElkeUS/MEvYFfWK6SCOGLZpXERvjw1XbgSn+qUzd8lKd7Y5IMdRtQSNolgD2VtFzmq DBE+YGqA6qcbkCV8IrY8yRZbi2g1vvUpShM+coI2sKaO0JzX+K05/XvH1lE0AHADSfpq sSngnjVGy4rXDOLeyvWaKyqm6WZDpHp7joecI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wYpxKJb+2REXCaRbbJSeap3VI6EqHEPEPn0BML2o5TgmRyvGQetAf2/gZf1k4RV7tI KETIhFR2MuAZv3qYlwp3IcwJFTcfQeYEQ5ArDkt6XDFhvzOQpoH7KgmbhWo3z3laAt9S 9hOjvSUNki3r7vPPHHXwj86BNVXrKFepqIZH4= MIME-Version: 1.0 Received: by 10.224.106.38 with SMTP id v38mr3896648qao.381.1284802080447; Sat, 18 Sep 2010 02:28:00 -0700 (PDT) Received: by 10.229.235.143 with HTTP; Sat, 18 Sep 2010 02:28:00 -0700 (PDT) In-Reply-To: References: <8C5C36F5-A070-4CBA-8B8C-6751F8D636E1@gmail.com> <20100917203645.GS2389@deviant.kiev.zoral.com.ua> Date: Sat, 18 Sep 2010 11:28:00 +0200 Message-ID: From: Norberto Lopes To: Kostik Belousov Content-Type: multipart/mixed; boundary=00c09f82cc309c9fee0490854b59 Cc: freebsd-current@freebsd.org, netchild@freebsd.org Subject: Re: Extend ktrace/kdump output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 09:28:02 -0000 --00c09f82cc309c9fee0490854b59 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Anyway, attached is the patch. All (constructive) criticism is welcome, even if it has to deal with "how I should do things freebsd way (in case there is one)". On Fri, Sep 17, 2010 at 10:48 PM, Norberto Lopes wrot= e: > On Fri, Sep 17, 2010 at 10:36 PM, Kostik Belousov w= rote: >> On Fri, Sep 17, 2010 at 09:55:26PM +0200, Norberto Lopes wrote: >>> Hi. >>> I've been taking a look at ktrace and kdump in order to get (1) familia= r with the sources and (2) to finally try to give back something to the com= munity. >>> >>> So far from what I've seen, and after reading this thread http://lists.= freebsd.org/pipermail/freebsd-arch/2006-April/005107.html it seems that mos= t of those points got done. >>> >>> To warm up I changed the output of the stat structure in order to provi= de me with the device name (something I actually find useful for me sometim= es) >>> >>> Instead of: >>> =C2=A022596 cat =C2=A0 =C2=A0 =C2=A0STRU =C2=A0struct stat {dev=3D89, i= no=3D3320836, mode=3D-r--r--r-- , nlink=3D1, uid=3D0, gid=3D0, atime=3D1284= 725358, stime=3D1284485510, ctime=3D1284485510, birthtime=3D1284485509, siz= e=3D1172220, blksize=3D16384, blocks=3D2336, flags=3D0x20000 } >>> >>> I get this now (including major and minor): >>> =C2=A022596 cat =C2=A0 =C2=A0 =C2=A0STRU =C2=A0struct stat {dev=3D (/dev/ad4s1a), ino=3D3320836, mode=3D-r--r--r-- , nlink= =3D1, uid=3D0, gid=3D0, atime=3D1284725358, stime=3D1284485510, ctime=3D128= 4485510, birthtime=3D1284485509, size=3D1172220, blksize=3D16384, blocks=3D= 2336, flags=3D0x20000 } >>> >>> I wouldn't mind having someone help me whenever and if I get stuck on t= he technical side (*wink* Alexander Leidinger *wink*) and also to give me m= ore insight on what the road to help in this should be. >>> >>> P.S.: I'm still going through "man style" hence no patch attached. If a= nyone finds this one useful, I'll reply with the patch though. >>> >> How do you look up the device name by st_dev ? Note that the number is >> generated by devfs at the moment of cdev creation. It is only valid on >> the machine where stat(2) is done, and only due to the next reboot. >> > > Through a really ugly hack... > opendir("/dev") > readdir("/dev") > go through them and find the one... > > Yes, I know, painful and ugly, but as I usually use kdump with no > reboots between analysis (I hardly ever reboot actually), and because > I find it exhausting to keep going back to look up the device name, > this kept me happy enough. :) > --00c09f82cc309c9fee0490854b59 Content-Type: application/octet-stream; name="kstat_devname.diff" Content-Disposition: attachment; filename="kstat_devname.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ge89zcwl0 SW5kZXg6IGtkdW1wLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0ga2R1bXAuYwkocmV2aXNpb24gMjEyODIwKQor Kysga2R1bXAuYwkod29ya2luZyBjb3B5KQpAQCAtODIsNiArODIsOCBAQCBleHRlcm4gaW50IGVy cm5vOwogI2luY2x1ZGUgPHRpbWUuaD4KICNpbmNsdWRlIDx1bmlzdGQuaD4KICNpbmNsdWRlIDx2 aXMuaD4KKyNpbmNsdWRlIDxkaXJlbnQuaD4KKyNpbmNsdWRlIDxzdGRib29sLmg+CiAjaW5jbHVk ZSAia3RyYWNlLmgiCiAjaW5jbHVkZSAia2R1bXBfc3Vici5oIgogCkBAIC0xMjQ5LDYgKzEyNTEs MTEgQEAga3Ryc3RhdChzdHJ1Y3Qgc3RhdCAqc3RhdHApCiAJc3RydWN0IHBhc3N3ZCAqcHdkOwog CXN0cnVjdCBncm91cCAgKmdycDsKIAlzdHJ1Y3QgdG0gKnRtOworCURJUiAqb2QgPSBOVUxMOwor CXN0cnVjdCBzdGF0ICpkZXZfc3RhdDsKKwlzdHJ1Y3QgZGlyZW50ICpkZXZfZW50cnk7CisJY2hh ciAqZGV2X25hbWUsICpkZXZfcGF0aD0iL2Rldi8iOworCWJvb2wgZm91bmRfZGV2ID0gZmFsc2U7 CiAKIAkvKgogCSAqIG5vdGU6IGt0cnN0cnVjdCgpIGhhcyBhbHJlYWR5IHZlcmlmaWVkIHRoYXQg c3RhdHAgcG9pbnRzIHRvIGEKQEAgLTEyNTYsOSArMTI2Myw3MyBAQCBrdHJzdGF0KHN0cnVjdCBz dGF0ICpzdGF0cCkKIAkgKi8KIAlwcmludGYoInN0cnVjdCBzdGF0IHsiKTsKIAlzdHJtb2RlKHN0 YXRwLT5zdF9tb2RlLCBtb2RlKTsKLQlwcmludGYoImRldj0lanUsIGlubz0lanUsIG1vZGU9JXMs IG5saW5rPSVqdSwgIiwKLQkJKHVpbnRtYXhfdClzdGF0cC0+c3RfZGV2LCAodWludG1heF90KXN0 YXRwLT5zdF9pbm8sIG1vZGUsCi0JCSh1aW50bWF4X3Qpc3RhdHAtPnN0X25saW5rKTsKKworCWRl dl9zdGF0ID0gKHN0cnVjdCBzdGF0ICopbWFsbG9jKHNpemVvZihzdHJ1Y3Qgc3RhdCkpOworCWlm IChkZXZfc3RhdCA9PSBOVUxMKQorCQllcnJ4KDEsICIlcyIsIHN0cmVycm9yKEVOT01FTSkpOwor CisJLyogY2hlY2sgaWYgd2UgY2FuIHJlYWNoIGl0IGFuZCBvcGVuIGl0ICovCisJaWYgKCFzdGF0 KGRldl9wYXRoLCBkZXZfc3RhdCkgJiYgKG9kID0gb3BlbmRpcihkZXZfcGF0aCkpID09IE5VTEwp CisJCWZyZWUoZGV2X3N0YXQpOworCWVsc2UgeworCQl3aGlsZSAoKGRldl9lbnRyeSA9IHJlYWRk aXIob2QpKSAhPSBOVUxMICYmIGZvdW5kX2RldiA9PSBmYWxzZSkgeworCQkJLyogaWdub3JlICIu IiBhbmQgIi4uIiAqLworCQkJaWYgKChzdHJjbXAoZGV2X2VudHJ5LT5kX25hbWUsICIuIikgPT0g MCkgfHwgCisJCQkgICAgKHN0cmNtcChkZXZfZW50cnktPmRfbmFtZSwgIi4uIikgPT0gMCkpCisJ CQkJY29udGludWU7CisJCQkKKwkJCWRldl9uYW1lID0gKGNoYXIgKiltYWxsb2Moc2l6ZW9mKGNo YXIpKgorCQkJICAgICAgICAoc3RybGVuKGRldl9wYXRoKStzdHJsZW4oZGV2X2VudHJ5LT5kX25h bWUpKSk7CisKKwkJCWlmIChkZXZfbmFtZSA9PSBOVUxMKQorCQkJCWVycngoMSwgIiVzIiwgc3Ry ZXJyb3IoRU5PTUVNKSk7CisJCQkKKwkJCSh2b2lkKXNwcmludGYoZGV2X25hbWUsICIlcyVzIiwg ZGV2X3BhdGgsIAorCQkJICAgICAgICAgICAgICAgIGRldl9lbnRyeS0+ZF9uYW1lKTsKKwkgICAg CisJCQlkZXZfc3RhdCA9IChzdHJ1Y3Qgc3RhdCAqKW1hbGxvYyhzaXplb2Yoc3RydWN0IHN0YXQp KTsKKwkJCWlmIChkZXZfc3RhdCA9PSBOVUxMKQorCQkJCWVycngoMSwgIiVzIiwgc3RyZXJyb3Io RU5PTUVNKSk7CisKKwkJCWlmIChzdGF0KGRldl9uYW1lLCBkZXZfc3RhdCkgPT0gLTEpIHsKKwkJ CQlmcmVlKGRldl9zdGF0KTsKKwkJCQljb250aW51ZTsKKwkJCX0KKworCQkJLyogCisJCQkgKiBJ ZiB0aGUgZmlsZSBkZXZpY2UgbnVtYmVyIGVxdWFscyB0aGUgZGV2aWNlIGlub2RlIAorCQkJICog d2UgaGF2ZSB0aGUgZGV2aWNlIHRoYXQgY29udGFpbnMgdGhlIGZpbGUuCisJCQkgKgorCQkJICog SW4gdGhlIGNoYW5jZSB0aGF0IHdlIGZpbmQgdGhhdCB0aGUgImZpbGUiIGlub2RlCisJCQkgKiBl cXVhbHMgdGhlIGRldmljZSBpbm9kZSwgdGhlbiB0aGV5IGFyZSB0aGUgc2FtZSB0b28uCisJCQkg Ki8KKwkJCWlmICgodWludG1heF90KXN0YXRwLT5zdF9kZXYgPT0gCisJCQkgICAgKHVpbnRtYXhf dClkZXZfc3RhdC0+c3RfaW5vKSB7CisJCQkJZm91bmRfZGV2ID0gdHJ1ZTsKKwkJCQlicmVhazsK KwkJCX0KKwkJCWVsc2UgaWYgKCh1aW50bWF4X3Qpc3RhdHAtPnN0X2lubyA9PSAKKwkJCSAgICAg ICAgKHVpbnRtYXhfdClkZXZfc3RhdC0+c3RfaW5vKSB7CisJCQkJZm91bmRfZGV2ID0gdHJ1ZTsK KwkJCQlicmVhazsKKwkJCX0KKworCQkJZnJlZShkZXZfbmFtZSk7CQkJCisJCQlmcmVlKGRldl9z dGF0KTsKKwkJfQorCX0KKwlpZiAoZm91bmRfZGV2KSB7CisJCXByaW50ZigiZGV2PTxpZD0lanU6 TT0lZDptPSVkPiAoJXMpLCIsIAorCQkgICAgICAgICh1aW50bWF4X3Qpc3RhdHAtPnN0X2Rldiwg bWFqb3Ioc3RhdHAtPnN0X2RldiksCisJCSAgICAgICAgbWlub3Ioc3RhdHAtPnN0X2RldiksIGRl dl9uYW1lKTsKKwkJZnJlZShkZXZfbmFtZSk7CisJfQorCWVsc2UKKwkJcHJpbnRmKCJkZXY9PGlk PSVqdTpNPSVkOm09JWQ+LCIsICh1aW50bWF4X3Qpc3RhdHAtPnN0X2RldiwgCisJCSAgICAgICAg bWFqb3Ioc3RhdHAtPnN0X2RldiksIG1pbm9yKHN0YXRwLT5zdF9kZXYpKTsKKworCXByaW50Zigi IGlubz0lanUsIG1vZGU9JXMsIG5saW5rPSVqdSwgIiwKKwkgICAgICAgICh1aW50bWF4X3Qpc3Rh dHAtPnN0X2lubywgbW9kZSwgKHVpbnRtYXhfdClzdGF0cC0+c3RfbmxpbmspOworCiAJaWYgKHJl c29sdiA9PSAwIHx8IChwd2QgPSBnZXRwd3VpZChzdGF0cC0+c3RfdWlkKSkgPT0gTlVMTCkKIAkJ cHJpbnRmKCJ1aWQ9JWp1LCAiLCAodWludG1heF90KXN0YXRwLT5zdF91aWQpOwogCWVsc2UKQEAg LTEyNjcsNyArMTMzOCwxMSBAQCBrdHJzdGF0KHN0cnVjdCBzdGF0ICpzdGF0cCkKIAkJcHJpbnRm KCJnaWQ9JWp1LCAiLCAodWludG1heF90KXN0YXRwLT5zdF9naWQpOwogCWVsc2UKIAkJcHJpbnRm KCJnaWQ9XCIlc1wiLCAiLCBncnAtPmdyX25hbWUpOworCisJLyogWFhYOiBEbyB3ZSByZWFsbHkg bmVlZCByZGV2IGluIGNhc2UgaXQncyBub3QgY2hhcmFjdGVyIG9yIGJsb2NrPyAqLworCS8qIGlm IChTX0lTQ0hSKHN0YXRwLT5zdF9tb2RlKSB8fCBTX0lTQkxLKHN0YXRwLT5zdF9tb2RlKSkgKi8K IAlwcmludGYoInJkZXY9JWp1LCAiLCAodWludG1heF90KXN0YXRwLT5zdF9yZGV2KTsKKwogCXBy aW50ZigiYXRpbWU9Iik7CiAJaWYgKHJlc29sdiA9PSAwKQogCQlwcmludGYoIiVqZCIsIChpbnRt YXhfdClzdGF0cC0+c3RfYXRpbS50dl9zZWMpOwpAQCAtMTMxNyw4ICsxMzkyLDggQEAga3Ryc3Rh dChzdHJ1Y3Qgc3RhdCAqc3RhdHApCiAJZWxzZQogCQlwcmludGYoIiwgIik7CiAJcHJpbnRmKCJz aXplPSVqZCwgYmxrc2l6ZT0lanUsIGJsb2Nrcz0lamQsIGZsYWdzPTB4JXgiLAotCQkodWludG1h eF90KXN0YXRwLT5zdF9zaXplLCAodWludG1heF90KXN0YXRwLT5zdF9ibGtzaXplLAotCQkoaW50 bWF4X3Qpc3RhdHAtPnN0X2Jsb2Nrcywgc3RhdHAtPnN0X2ZsYWdzKTsKKwkgICAgICAgICh1aW50 bWF4X3Qpc3RhdHAtPnN0X3NpemUsICh1aW50bWF4X3Qpc3RhdHAtPnN0X2Jsa3NpemUsCisJICAg ICAgICAoaW50bWF4X3Qpc3RhdHAtPnN0X2Jsb2Nrcywgc3RhdHAtPnN0X2ZsYWdzKTsKIAlwcmlu dGYoIiB9XG4iKTsKIH0KIAo= --00c09f82cc309c9fee0490854b59-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 18 13:31:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13E41106566B; Sat, 18 Sep 2010 13:31:27 +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 D5B848FC0A; Sat, 18 Sep 2010 13:31:25 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA07210; Sat, 18 Sep 2010 16:31:24 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OwxVk-000D5b-9Y; Sat, 18 Sep 2010 16:31:24 +0300 Message-ID: <4C94BF2B.8050008@freebsd.org> Date: Sat, 18 Sep 2010 16:31:23 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100912 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org, freebsd-stable@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: if_epair as module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 13:31:27 -0000 Anybody uses if_epair compiled as _module_ on any platform other than amd64? If yes, could you please respond to me in private? Big thanks in advance. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Sep 18 13:51:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DF951065673 for ; Sat, 18 Sep 2010 13:51:03 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) by mx1.freebsd.org (Postfix) with ESMTP id A99A58FC12 for ; Sat, 18 Sep 2010 13:51:02 +0000 (UTC) Received: from [87.79.159.189] (helo=r500.local) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Owxoj-0003LH-69 for freebsd-current@freebsd.org; Sat, 18 Sep 2010 15:51:01 +0200 Date: Sat, 18 Sep 2010 15:51:00 +0200 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20100918155100.5b74cdb2@r500.local> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd9.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/CevsasQ3wPex22k0HG9dMOq"; protocol="application/pgp-signature" X-Df-Sender: 775067 Subject: geli boot issues with recent kernels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 13:51:03 -0000 --Sig_/CevsasQ3wPex22k0HG9dMOq Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable My kernel and / are on ada0s1a (UFS) while the rest of the system is on a ZFS pool on ada0s1d.eli, attached on boot. Since a few days ago, booting no longer works reliably for me. Every now and then the system hangs at the time when I'd normaly provide the passphrase. The last times this happened I was in a hurry, so I'm not entirely sure if the prompt for the passphrase is even shown (on my system it's always buried in USB messages anyway). Sometimes keyboard input is ignored completely, sometimes I can still use shift lock or scroll through the kernel messages. When this happened the first time, rebooting the system solved the problem. By "rebooting" I mean shutting down the system by keeping the power button pressed and then powering the system on again. When the system hangs, it doesn't seem to react to the ACPI event that is generated by pressing the power button shortly. Today I rebooted the system three times in a row without getting it to work so I finally unloaded geom_eli from the loader prompt, booted to single-user mode and attached the geli provider from there. When I booted a few hours later with the same kernel it worked right away. I think I experienced the problem the first time with a kernel from last Wednesday, currently I'm using: FreeBSD 9.0-CURRENT Fri Sep 17 18:25:39 CEST 2010 amd64 It definitively didn't happen with a kernel from last Saturday, but then again I seldomly boot the system more than once a day and the problem doesn't always show. I enabled boot_verbose=3D"-v" and kern.geom.eli.visible_passphrase=3D1 and thus expect to be able to provide a more detailed problem description the next time this happens. Has anyone else seen this? Fabian --Sig_/CevsasQ3wPex22k0HG9dMOq Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkyUw8cACgkQBYqIVf93VJ0yZgCfcpmCw6Xd5cJ8sNL8x8mMjOGn DiMAniJaScRmgEJVpxV8qzmmWbU8D1sh =ddFH -----END PGP SIGNATURE----- --Sig_/CevsasQ3wPex22k0HG9dMOq-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 18 16:01:18 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 787401065697 for ; Sat, 18 Sep 2010 16:01:18 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from queueout02-winn.ispmail.ntl.com (queueout02-winn.ispmail.ntl.com [81.103.221.56]) by mx1.freebsd.org (Postfix) with ESMTP id C7A6C8FC26 for ; Sat, 18 Sep 2010 16:01:17 +0000 (UTC) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.3]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100918151524.OXRY3266.mtaout01-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net> for ; Sat, 18 Sep 2010 16:15:24 +0100 Received: from [86.27.35.5] (helo=unknown) by know-smtpout-4.server.virginmedia.net with esmtp (Exim 4.63) (envelope-from ) id 1Owz8O-0004S8-9Z for freebsd-current@freebsd.org; Sat, 18 Sep 2010 16:15:24 +0100 Date: Sat, 18 Sep 2010 16:15:20 +0100 From: Bruce Cran To: freebsd-current@freebsd.org Message-ID: <20100918161520.00001d84@unknown> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=4QByPj+6Iq2k/6L54d+eVKTdgQxdscpRskJJReCfdXo= c=1 sm=0 a=WKZEFjg-AwwA:10 a=kj9zAlcOel0A:10 a=jfq9T_a6Xvc30UsYPhAA:9 a=hUrvIEg3mL3cSHs4o0QA:7 a=2SL_SHg1ZogIB_3lYIa41aN2s4IA:4 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: One-shot timer broken on Xen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 16:01:18 -0000 Hi, I built a new kernel from HEAD on my Xen domU today and found that it hung after the following messages: smist0: on cpu0 device_attach: smist0 attach returned 6 Device configuration finished. procfs registered Timecounter "TSC" frequency 2000118476 Hz quality 800 lapic: Divisor 2, Frequency 50001605 Hz Setting kern.eventtimer.periodic to 1 allows the system to boot. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Sep 18 16:09:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C63F41065670 for ; Sat, 18 Sep 2010 16:09:22 +0000 (UTC) (envelope-from adrian.chadd@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 81DAF8FC12 for ; Sat, 18 Sep 2010 16:09:22 +0000 (UTC) Received: by iwn34 with SMTP id 34so3441613iwn.13 for ; Sat, 18 Sep 2010 09:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=5Quo0wwfDsycUcZUXJ3m3b1krNJQrr3Q9C2iNfaEpzE=; b=mdJYJMxb18UGkVjVvNpRdO0AGdusYsEtx28HhfOKODzEv/06V7S4o8YFnziUAZIjQT tlS5YK7MyAnzowXFxw8N9PBrtF7MFHKBJBZcroKwMIxXy3FmlHhrribP2MR2DIVfryLH 4+l2b+O5KRlBp06JmQwaHltT1dhvNKbhcBr4U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=Nn6VxjZz5isoQ2r9/0/NPSQYrLbYvi8FJGrPzUAz3kt2mGGDit+T2oXF5TjyT836cz VnYCdC9YJNVfviM9CjHswMNolLTFNMgH2CU8bIS0FmLEgVhASE1FqUqoap/NFAJt7p3g EweqvI33dLH+3VnU3w11vXBZ/4mtn39AV4WEM= MIME-Version: 1.0 Received: by 10.231.33.129 with SMTP id h1mr6036219ibd.140.1284826161793; Sat, 18 Sep 2010 09:09:21 -0700 (PDT) Received: by 10.231.156.206 with HTTP; Sat, 18 Sep 2010 09:09:21 -0700 (PDT) Date: Sun, 19 Sep 2010 00:09:21 +0800 Message-ID: From: Adrian Chadd To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mobile@freebsd.org Subject: RFT: if_ath HAL refactoring X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 16:09:22 -0000 Hi all, I've uploaded a snapshot of the if_ath HAL which i've been working on. I've been refactoring out various bits of the AR5416 HAL into something that resembles the ath9k hardware MAC/PHY operations to make it easier to port further ath9k updates over. It also includes the AR9100 support (but it's missing a couple bits of glue needed to use it outside of my GIT tree.) Finally, it includes the probe/attach operations for the AR2427, but I haven't at all tested it yet (and i've explained why it isn't working in a previous email.) It's available for download at http://people.freebsd.org/~adrian/ath/ . There's a diff against src/sys/files/conf and a tarball that just replaces the ath device/module directory. Note you'll need to add "device if_ath_pci" to your kernel configuration file as the PCI bus glue is now not built by default in a static kernel in this HAL. (It's included in the module Makefile by default.) This was done to allow multiple backend bus types - now being PCI and "AHB" for the AR9100 SoC. I'd appreciate testing by AR5416/AR9160/AR9280/AR9285 users. I only currently have easy access to AR5416/AR9160. Please let me know immediately if something doesn't work with this which does work in -head. If you're an AR2427 user, I'd appreciate some brief testing with HAL_DEBUG_ATTACH/HAL_DEBUG_EEPROM enabled (sysctl hw.ath.hal.debug=0x8002.) I doubt it'll work but it should attach and then spit out some computetxtime errors. Let me know if that happens and I'll see about trying to fix that. Adrian From owner-freebsd-current@FreeBSD.ORG Sat Sep 18 16:42:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09B08106566B for ; Sat, 18 Sep 2010 16:42:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 850178FC08 for ; Sat, 18 Sep 2010 16:42:50 +0000 (UTC) Received: by bwz15 with SMTP id 15so4487685bwz.13 for ; Sat, 18 Sep 2010 09:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=aGqx/K8759BPQkGsJ4KU/gKj0oDwigaGjX4G3ZIdF8U=; b=vAsxVkR3/RhTKiif1JWfc1a+NnHWeS4WuFpIJf4SscEpG+Yx5hjgNLPvSxMOmOgfM7 jk9el/1nYzN6wGJ0xlioobfGgolGK71b8ya5v3lc3/Dv2H8nCSNeS8AMFPQNnzysZkvi +ZtZ5YFI9G+22teU6hrHS+FZiMm5upegjJiQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=CcK8NjZXRtq+ps1hOUysaJCfuz3zsjX+YGH7ewWUP1bZIDd3/Br7b5H9Keguh2DTws GVEQXpYdmFYCW3tffJ0qacCaR0Sq6KpXMKB/Mny3d7Yq9lRb/kZqSA3nAVkRW0cLcWRw Nyi0k/i9mn4J3N0zPg012o2R3+03LQgJanYhI= Received: by 10.204.77.212 with SMTP id h20mr5163646bkk.33.1284828168724; Sat, 18 Sep 2010 09:42:48 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 11sm4815976bkj.11.2010.09.18.09.42.46 (version=SSLv3 cipher=RC4-MD5); Sat, 18 Sep 2010 09:42:47 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C94EC05.4070406@FreeBSD.org> Date: Sat, 18 Sep 2010 19:42:45 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Bruce Cran References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: One-shot timer broken on Xen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 16:42:51 -0000 Hi. Bruce Cran wrote: > I built a new kernel from HEAD on my Xen domU today and found that it > hung after the following messages: > > smist0: on cpu0 > device_attach: smist0 attach returned 6 > Device configuration finished. > procfs registered > Timecounter "TSC" frequency 2000118476 Hz quality 800 > lapic: Divisor 2, Frequency 50001605 Hz > > Setting kern.eventtimer.periodic to 1 allows the system to boot. This doesn't tells much. What event timers found by the system there and what of them was used? Looking on kern.eventtimer.periodic support, I assume you are using HVM? PV kernel wasn't refactored yet, but I think it would be nice. May be you could give me an access to some Xen machine? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Sep 18 16:54:15 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28F11106566B for ; Sat, 18 Sep 2010 16:54:15 +0000 (UTC) (envelope-from lists@avioc.org) Received: from mail.avioc.org (mail.ipv6.avioc.org [IPv6:2001:4978:125:a00a::25]) by mx1.freebsd.org (Postfix) with ESMTP id DD3738FC12 for ; Sat, 18 Sep 2010 16:54:14 +0000 (UTC) Received: from mail (mail.internal.avioc.org [192.168.2.252]) by mail.avioc.org (Postfix) with ESMTP id BC0A8221CAC for ; Sat, 18 Sep 2010 11:54:13 -0500 (CDT) X-Virus-Scanned: amavisd-new at avioc.org Received: from mail.avioc.org ([192.168.2.252]) by mail (mail.internal.avioc.org [192.168.2.252]) (amavisd-new, port 10024) with LMTP id MfSUxnufkCO3 for ; Sat, 18 Sep 2010 11:54:11 -0500 (CDT) Received: from [192.168.2.8] (section-8.internal.avioc.org [192.168.2.8]) by mail.avioc.org (Postfix) with ESMTPA id 577EF221CAA for ; Sat, 18 Sep 2010 11:54:11 -0500 (CDT) Message-ID: <4C94EEB2.3040008@avioc.org> Date: Sat, 18 Sep 2010 11:54:10 -0500 From: Brandon Weisz User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100916 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: RFT: if_ath HAL refactoring X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 16:54:15 -0000 On 09/18/2010 11:09 AM, Adrian Chadd wrote: > Hi all, > > I've uploaded a snapshot of the if_ath HAL which i've been working on. > I've been refactoring out various bits of the AR5416 HAL into > something that resembles the ath9k hardware MAC/PHY operations to make > it easier to port further ath9k updates over. It also includes the > AR9100 support (but it's missing a couple bits of glue needed to use > it outside of my GIT tree.) Finally, it includes the probe/attach > operations for the AR2427, but I haven't at all tested it yet (and > i've explained why it isn't working in a previous email.) > > It's available for download at http://people.freebsd.org/~adrian/ath/ > . There's a diff against src/sys/files/conf and a tarball that just > replaces the ath device/module directory. > > Note you'll need to add "device if_ath_pci" to your kernel > configuration file as the PCI bus glue is now not built by default in > a static kernel in this HAL. (It's included in the module Makefile by > default.) This was done to allow multiple backend bus types - now > being PCI and "AHB" for the AR9100 SoC. > > I'd appreciate testing by AR5416/AR9160/AR9280/AR9285 users. I only > currently have easy access to AR5416/AR9160. Please let me know > immediately if something doesn't work with this which does work in > -head. Are there plans for AR9287 support? Unfortunately that is the only ath card I have to test with at the moment. > > If you're an AR2427 user, I'd appreciate some brief testing with > HAL_DEBUG_ATTACH/HAL_DEBUG_EEPROM enabled (sysctl > hw.ath.hal.debug=0x8002.) I doubt it'll work but it should attach and > then spit out some computetxtime errors. Let me know if that happens > and I'll see about trying to fix that. > > > Adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Sep 18 16:54:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE9531065698; Sat, 18 Sep 2010 16:54:58 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by mx1.freebsd.org (Postfix) with ESMTP id 01AAE8FC19; Sat, 18 Sep 2010 16:54:57 +0000 (UTC) Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.3]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20100918165456.IHAG3192.mtaout02-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net>; Sat, 18 Sep 2010 17:54:56 +0100 Received: from [86.27.35.5] (helo=unknown) by know-smtpout-4.server.virginmedia.net with esmtp (Exim 4.63) (envelope-from ) id 1Ox0gi-0000IY-L7; Sat, 18 Sep 2010 17:54:56 +0100 Date: Sat, 18 Sep 2010 17:54:52 +0100 From: Bruce Cran To: Alexander Motin Message-ID: <20100918175452.00003b6f@unknown> In-Reply-To: <4C94EC05.4070406@FreeBSD.org> References: <4C94EC05.4070406@FreeBSD.org> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.16.6; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=4QByPj+6Iq2k/6L54d+eVKTdgQxdscpRskJJReCfdXo= c=1 sm=0 a=3hKMM-ERg8wA:10 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=3UN-ILmPtE4iyNsp15EA:9 a=tVVvfL-UV2JRiOiVEV0A:7 a=WIa4WGfKwUdkB2EXx45Fkwt98_YA:4 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: FreeBSD-Current Subject: Re: One-shot timer broken on Xen X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 16:54:59 -0000 On Sat, 18 Sep 2010 19:42:45 +0300 Alexander Motin wrote: > Bruce Cran wrote: > > I built a new kernel from HEAD on my Xen domU today and found that > > it hung after the following messages: > > > > smist0: on cpu0 > > device_attach: smist0 attach returned 6 > > Device configuration finished. > > procfs registered > > Timecounter "TSC" frequency 2000118476 Hz quality 800 > > lapic: Divisor 2, Frequency 50001605 Hz > > > > Setting kern.eventtimer.periodic to 1 allows the system to boot. > > This doesn't tells much. What event timers found by the system there > and what of them was used? Sorry - here's the kern.eventtimer output: kern.eventtimer.choice: LAPIC(400) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 50001856 kern.eventtimer.et.LAPIC.quality: 400 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.periodic: 1 kern.eventtimer.timer: LAPIC kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 4 > Looking on kern.eventtimer.periodic support, I assume you are using > HVM? PV kernel wasn't refactored yet, but I think it would be nice. Yes, it's an i386 HVM system. > May be you could give me an access to some Xen machine? I'm going to be decomissioning another Xen machine so I can certainly give you access to that one. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Sep 18 17:01:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 909F7106566B for ; Sat, 18 Sep 2010 17:01:58 +0000 (UTC) (envelope-from adrian.chadd@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 558368FC0C for ; Sat, 18 Sep 2010 17:01:58 +0000 (UTC) Received: by iwn34 with SMTP id 34so3479219iwn.13 for ; Sat, 18 Sep 2010 10:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=4kWXYSW1lIhw6criTnMXUWSnXwK/KKIzdzo5P727S84=; b=hTBH46tG1LTfDCuuShM2TK/G0DiTp458dvF5erFdE9vdMthvkfrLqiD+BQd3s2a643 zr32jpDoCnrhDpS51X8V5vgYMdX77IXsCrqbAWTRB0YmAS4++9S3sgkF2KrAnoGtrqRr ve35OzWFAB9IR+kZn5sSpC+fTCxo9YBc0fXTA= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Jb8R4lAzrFAR3kkpidhdGYNNPj+rLddsJSO1nkCpdN+yauESSvJy2L8bbLoBZtW78u 1NJeHUbdU0HOE3Sw4Z9Fss+aLxAo/eQCnAYieqKgPaJuq3OcyxAIuEkkvYphFJzB9qZH GfJgVqVIfd3aKWHzVrfsSrSwdIv+mBBWcwaVk= MIME-Version: 1.0 Received: by 10.231.79.213 with SMTP id q21mr7089727ibk.137.1284829317610; Sat, 18 Sep 2010 10:01:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.231.156.206 with HTTP; Sat, 18 Sep 2010 10:01:57 -0700 (PDT) In-Reply-To: <4C94EEB2.3040008@avioc.org> References: <4C94EEB2.3040008@avioc.org> Date: Sun, 19 Sep 2010 01:01:57 +0800 X-Google-Sender-Auth: ktbh0TeIvYm8Da9kAuoQVUHyzPg Message-ID: From: Adrian Chadd To: Brandon Weisz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: RFT: if_ath HAL refactoring X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 17:01:58 -0000 On 19 September 2010 00:54, Brandon Weisz wrote: >> I'd appreciate testing by AR5416/AR9160/AR9280/AR9285 users. I only >> currently have easy access to AR5416/AR9160. Please let me know >> immediately if something doesn't work with this which does work in >> -head. > > Are there plans for AR9287 support? =A0Unfortunately that is the only ath= card > I have to test with at the moment. At some point, yes. There's a lot of code missing in our driver for ar92xx series chips. I'd rather get the existing stuff updated and tidied up before I look at importing support for others. I'd also like to somehow acquire some hardware to test it against - I only have (very) legacy (pre AR5416), AR5416, AR9160 and AR2427 chips. I don't yet have anything with an AR9280/9285 in it. Adrian From owner-freebsd-current@FreeBSD.ORG Sat Sep 18 17:04:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8C311065672 for ; Sat, 18 Sep 2010 17:04:48 +0000 (UTC) (envelope-from adrian.chadd@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 ACE8C8FC08 for ; Sat, 18 Sep 2010 17:04:48 +0000 (UTC) Received: by iwn34 with SMTP id 34so3481565iwn.13 for ; Sat, 18 Sep 2010 10:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ntNPqMHH+3amAVul0tGEzHgJFf3avW425k76A2uqDyQ=; b=h9ksqBF3UHucQX4LJuwVQoL6Bgoxq1s+V52NvoHNd4aDglxcS12IA+iVsi168jQ710 QAbFbAoyXrmFh/bLX4g3nl5ZlKsFfb28BYGp9IAWRIyNHc4qkHK6PK1W5U0e3HLBjoab VtojDDKKA9SjSGmBNB9IceNcmFfmChKfjyoUw= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=NbJdprblTWJjr17SQzhcySi7znkKGxCDlNJYMZFFoYSKxQOYHDfqc399M80TUioQ0T gcHneIWrcHmwndoos4mBQj91jN7r+WOIiMLNCPhCq2Ozh8uU32AlY0rle4Y1wxCSPcvb 3OsHeCSvNHcZr2aIsHRyOh84M5jH88LMr5DA4= MIME-Version: 1.0 Received: by 10.231.30.68 with SMTP id t4mr7143080ibc.129.1284829488006; Sat, 18 Sep 2010 10:04:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.231.156.206 with HTTP; Sat, 18 Sep 2010 10:04:47 -0700 (PDT) In-Reply-To: References: <4C94EEB2.3040008@avioc.org> Date: Sun, 19 Sep 2010 01:04:47 +0800 X-Google-Sender-Auth: mWkttYkVBn1GfVD7iLmYAKLDnSs Message-ID: From: Adrian Chadd To: Brandon Weisz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: RFT: if_ath HAL refactoring X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 17:04:49 -0000 On 19 September 2010 01:01, Adrian Chadd wrote: >> Are there plans for AR9287 support? =A0Unfortunately that is the only at= h card >> I have to test with at the moment. > > At some point, yes. > > There's a lot of code missing in our driver for ar92xx series chips. > I'd rather get the existing stuff updated and tidied up before I look > at importing support for others. I'd also like to somehow acquire some > hardware to test it against - I only have (very) legacy (pre AR5416), > AR5416, AR9160 and AR2427 chips. I don't yet have anything with an > AR9280/9285 in it. And before anyone asks - no, I won't be looking at the USB NICs, sorry. :-) Adrian From owner-freebsd-current@FreeBSD.ORG Sat Sep 18 22:38:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C48B1065695 for ; Sat, 18 Sep 2010 22:38:14 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id D4E5B8FC18 for ; Sat, 18 Sep 2010 22:38:13 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id E6CCE11B893; Sat, 18 Sep 2010 17:38:12 -0500 (CDT) Received: from 10.0.10.3 (221.163.108.93.rev.vodafone.pt [93.108.163.221]) by lavabit.com with ESMTP id JYPBK4LVBYH9; Sat, 18 Sep 2010 17:38:12 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Sat, 18 Sep 2010 23:38:08 +0100 Content-Transfer-Encoding: 7bit Message-Id: <813E7FEA-2BA9-450C-9826-CE3D799BBDED@FreeBSD.org> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1081) Cc: freebsd-current , freebsd-mobile@freebsd.org Subject: Re: RFT: if_ath HAL refactoring X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2010 22:38:14 -0000 On 18 Sep 2010, at 17:09, Adrian Chadd wrote: > Hi all, > > I've uploaded a snapshot of the if_ath HAL which i've been working on. > I've been refactoring out various bits of the AR5416 HAL into > something that resembles the ath9k hardware MAC/PHY operations to make > it easier to port further ath9k updates over. It also includes the > AR9100 support (but it's missing a couple bits of glue needed to use > it outside of my GIT tree.) Finally, it includes the probe/attach > operations for the AR2427, but I haven't at all tested it yet (and > i've explained why it isn't working in a previous email.) > > It's available for download at http://people.freebsd.org/~adrian/ath/ > . There's a diff against src/sys/files/conf and a tarball that just > replaces the ath device/module directory. > > Note you'll need to add "device if_ath_pci" to your kernel > configuration file as the PCI bus glue is now not built by default in > a static kernel in this HAL. (It's included in the module Makefile by > default.) This was done to allow multiple backend bus types - now > being PCI and "AHB" for the AR9100 SoC. > > I'd appreciate testing by AR5416/AR9160/AR9280/AR9285 users. I only > currently have easy access to AR5416/AR9160. Please let me know > immediately if something doesn't work with this which does work in > -head. > > If you're an AR2427 user, I'd appreciate some brief testing with > HAL_DEBUG_ATTACH/HAL_DEBUG_EEPROM enabled (sysctl > hw.ath.hal.debug=0x8002.) I doubt it'll work but it should attach and > then spit out some computetxtime errors. Let me know if that happens > and I'll see about trying to fix that. Can you also provide a diff against HEAD please? Regards, -- Rui Paulo