From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 07:21:02 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F031816A418 for ; Sun, 14 Oct 2007 07:21:02 +0000 (UTC) (envelope-from zkolic@sbb.co.yu) Received: from smtp4.sbb.co.yu (smtp4.sbb.co.yu [82.117.194.24]) by mx1.freebsd.org (Postfix) with ESMTP id 610C313C447 for ; Sun, 14 Oct 2007 07:21:01 +0000 (UTC) (envelope-from zkolic@sbb.co.yu) Received: from faust.net (cable-89-216-161-240.dynamic.sbb.co.yu [89.216.161.240]) by smtp4.sbb.co.yu (8.14.0/8.14.0) with ESMTP id l9E6lsoA008779 for ; Sun, 14 Oct 2007 08:47:54 +0200 Received: by faust.net (Postfix, from userid 1001) id 1E9341CC1C; Sun, 14 Oct 2007 08:48:44 +0200 (CEST) Date: Sun, 14 Oct 2007 08:48:44 +0200 From: Zoran Kolic To: freebsd-stable@freebsd.org Message-ID: <20071014064844.GA1067@faust.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: 2.9 X-SBB-Spam-Level: XXXXXX Subject: usb stick problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 07:21:03 -0000 Howdy! I encountered something minor to usual problems, people have on this list, but it makes me nervous. I bought brand new usb flash stick and used it to solve the issue on handheld. After putting files on it, I have them in format 8.3. The option to mount -t was msdosfs. It should bring me long file names, but it does not. Mu stupid question would be: did I chose wrong file system? Or is this usb drive preformatted in something strange like fat16? This manner surprised me so much, that I did not believed my eyes. 6.2 on amd64. Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 12:24:35 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1353016A418 for ; Sun, 14 Oct 2007 12:24:35 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE6013C442 for ; Sun, 14 Oct 2007 12:24:34 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1042587nfb for ; Sun, 14 Oct 2007 05:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9O6L2RoHVy6k+LKr/yLgdNH2bv5KHZaHv3F6vMtcszw=; b=o+EXWqndulK30jUaGqxZAkgDq0bula963fTWYmHYtfSw4I/L00ak+aZsI0FiUBp/1iZabFBEnQ6Ia3rYvO8y7OyXv/4x39XDDzQFGCK8E9W1NWHa2BvLsU7xncvE8d5gm+fLJCLnWpIiwj4edGEt94SUO5NODgRmCMvRe16S4gI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nbcjHN780uVSghtC03uRy6Gjki/FxMS2b82VV80UCofT32bejJyTSl1nwH8URI+XfwprKGpO1olY+sEJydFUZSo1NR2Fb8CddsFBLA5V4nrxfPyfqiAicmVxrTMPfgUspuwrWe2aiQe3ue3jeLVQ9BxNHSrHnZuNHwkI/u8FaOA= Received: by 10.86.70.8 with SMTP id s8mr4114032fga.1192364673342; Sun, 14 Oct 2007 05:24:33 -0700 (PDT) Received: by 10.86.2.1 with HTTP; Sun, 14 Oct 2007 05:24:33 -0700 (PDT) Message-ID: <499c70c0710140524n5ade2c39r4ff61dfa5ce9a47@mail.gmail.com> Date: Sun, 14 Oct 2007 15:24:33 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: pyunyh@gmail.com In-Reply-To: <20071011004814.GB58828@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <499c70c0710091846p3e2dd505sb54f18da30802d2d@mail.gmail.com> <20071010033122.GB54946@cdnetworks.co.kr> <499c70c0710100708g30a2912n1d1e72703d099dd0@mail.gmail.com> <20071011004814.GB58828@cdnetworks.co.kr> Cc: FreeBSD Stable List , Pyun YongHyeon Subject: Re: Realtek eth isn't detected in Intel DG31PR mobo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 12:24:35 -0000 On 10/11/07, Pyun YongHyeon wrote: > On Wed, Oct 10, 2007 at 05:08:13PM +0300, Abdullah Ibn Hamad Al-Marri wrote: > > On 10/10/07, Pyun YongHyeon wrote: > > > On Wed, Oct 10, 2007 at 04:46:50AM +0300, Abdullah Ibn Hamad Al-Marri wrote: > > > > Hello Guys, > > > > > > > > Maybe this is in HEAD? I'm not sure. > > > > > > > > intel says "Gigabit (10/100/1000 Mbits/sec) LAN subsystem using the > > > > Realtek* RTL8111-GR Gigabit Ethernet Controller" > > > > > > > > Copyright (c) 1992-2007 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 6.2-STABLE #0: Sat Sep 8 03:21:29 AST 2007 > > > > root@web:/usr/obj/usr/src/sys/WEB > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > > CPU: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz (2666.62-MHz 686-class CPU) > > > > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > > > > Features=0xbfebfbff > > > > Features2=0xe3fd,EST,TM2,,CX16,,> > > > > AMD Features=0x20100000 > > > > AMD Features2=0x1 > > > > Cores per package: 2 > > > > real memory = 3210739712 (3062 MB) > > > > avail memory = 3143385088 (2997 MB) > > > > ACPI APIC Table: > > > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > > > cpu0 (BSP): APIC ID: 0 > > > > cpu1 (AP): APIC ID: 1 > > > > ioapic0 irqs 0-23 on motherboard > > > > acpi0: on motherboard > > > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > > > Timecounter "HPET" frequency 14318180 Hz quality 2000 > > > > acpi0: Power Button (fixed) > > > > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > > > > cpu0: on acpi0 > > > > cpu1: on acpi0 > > > > pcib0: port 0xcf8-0xcff on acpi0 > > > > pci0: on pcib0 > > > > pcib1: irq 16 at device 1.0 on pci0 > > > > pci1: on pcib1 > > > > pci0: at device 2.0 (no driver attached) > > > > pcib2: irq 16 at device 28.0 on pci0 > > > > pci2: on pcib2 > > > > pcib3: irq 17 at device 28.1 on pci0 > > > > pci3: on pcib3 > > > > rl0: port > > > > 0xc000-0xc0ff mem 0xd0020000-0xd0020fff irq 17 at device 0.0 on pci3 > > > > rl0: [GIANT-LOCKED] > > > > version:1.73 > > > > rl0: Ethernet address: 00:19:d1:a7:a4:72 > > > > rl0: Ethernet address: 00:19:d1:a7:a4:72 > > > > pcib4: at device 30.0 on pci0 > > > > pci4: on pcib4 > > > > isab0: at device 31.0 on pci0 > > > > isa0: on isab0 > > > > atapci0: port > > > > 0xd060-0xd067,0xd050-0xd053,0xd040-0xd047,0xd030-0xd033,0xd020-0xd02f > > > > irq 17 at device 31.2 on pci0 > > > > ata2: on atapci0 > > > > ata3: on atapci0 > > > > pci0: at device 31.3 (no driver attached) > > > > acpi_button0: on acpi0 > > > > acpi_button1: on acpi0 > > > > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > > > > atkbd0: irq 1 on atkbdc0 > > > > atkbd0: [GIANT-LOCKED] > > > > ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 > > > > ata1 at port 0x170-0x177,0x376 irq 15 on isa0 > > > > sc0: at flags 0x100 on isa0 > > > > sc0: VGA <16 virtual consoles, flags=0x300> > > > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > > > > Timecounters tick every 1.000 msec > > > > ipfw2 initialized, divert loadable, rule-based forwarding disabled, > > > > default to accept, logging limited to 10000 packets/entry by default > > > > ad4: 238475MB at ata2-master SATA150 > > > > ad6: 238475MB at ata3-master SATA150 > > > > SMP: AP CPU #1 Launched! > > > > Trying to mount root from ufs:/dev/ad4s1a > > > > > > > > rl0@pci3:0:0: class=0x020000 card=0xd6088086 chip=0x816810ec rev=0x01 hdr=0x00 > > > > vendor = 'Realtek Semiconductor' > > > > class = network > > > > subclass = ethernet > > > > > > > > So I used Realtek driver to get it working. > > > > > > > > ================================================================================= > > > > = Realtek 8139C/8139C+/8169S/8169SB/8169SC/8168B/8101E Driver for > > > > FreeBSD v4.x/5.x/6.0 = > > > > ================================================================================= > > > > > > > > shouldn't be re0 instead of rl0? > > > > > > > > Could someone please look into it, Pyun? > > > > > > Try attached patch. > > > I've touched rl(4) too because rl(4) should not attach to > > > unsupported hardwares. > > > > > > -- > > > Regards, > > > Pyun YongHyeon > > > > > > > > > > Hello Pyun, > > > > Thank you for the patch. > > > > FreeBSD didn't know it or detected it as "rl0" too, it got rl0 because > > I used realtek driver from their site. > > > > Stock rl(4)'s probe routine should return ENXIO for devices that > would be served by re(4). Without that rl(4)'s attach routune would > be tried next, it wouldn't attach to the hardware as it doesn't > recognize that hardware revision though. > > > So would this patch make FreeBSD detect it without any need for the > > driver from realtek site? > > > > Yes. I don't have these hardwares so please give it spin and let me > know how re(4) works. > > -- > Regards, > Pyun YongHyeon Pyrun, I hope you are doing well. Thank you for the patch, and your good attempt to help with this issue. I spent 2 hours with the patch it did detect the Ethernet as re0 but the network did not work at all even though it said connected at auto 100 mbps full duplex. The server sent out a packet storm of arp traffic or some kind of traffic which caused a lot of problems in my overall network. I'm not exactly sure what happened but maybe you know about it. So I removed the patch and used the rl0 driver from Realtek again. It's very strange I didn't see anything like it before. -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 12:36:41 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0371716A41B for ; Sun, 14 Oct 2007 12:36:41 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by mx1.freebsd.org (Postfix) with ESMTP id 6620B13C455 for ; Sun, 14 Oct 2007 12:36:39 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so1188508mue for ; Sun, 14 Oct 2007 05:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=8hr0Ax0JFUV71Rq5IXwYmlNt/BoEduGZb2lCLAZ2bKg=; b=Fy0zlcc9+Aiw4rGggcZJdSX92GA9CHGpdQuzYMIr6erV3wYj8bKMOhkqeB7C0GiudTM24C8JBWaSh5lQCx31skGBjN/MNZESI9qI7Ow1f4aRIPxW4wEiHKu/wQIIsscNZVz6RolJ55TortPvZaCbCvfuQhWHHtyhSYCi5UBGCdw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qZxA9RY65mZNKHb2gwt9cYVkdhIqa09hd9sfEmTI9MtnmX4PnMClhQ19G/72Wef3axah7oNboogU3TEeZEuu1V8DwWGUr3738QdDnaPlyhWPFahPZgqZlxPNGTXT6M3vNWD3MzIUtAWnQrKT+1GhqlbJAQLhLXYQiOh5YusNwg0= Received: by 10.86.79.19 with SMTP id c19mr4078257fgb.1192365399167; Sun, 14 Oct 2007 05:36:39 -0700 (PDT) Received: by 10.86.2.1 with HTTP; Sun, 14 Oct 2007 05:36:39 -0700 (PDT) Message-ID: <499c70c0710140536x49624f4x58a80713b244974f@mail.gmail.com> Date: Sun, 14 Oct 2007 15:36:39 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: "Nate Lawson" In-Reply-To: <47100D46.5020601@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <499c70c0710121333q7ba6ab34sff9ce3832ce81347@mail.gmail.com> <470FDF18.9010109@donut.de> <47100D46.5020601@root.org> Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Rolf Witt Subject: Re: FreeBSD 7.0 interrupt storm with irq0: clk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 12:36:41 -0000 On 10/13/07, Nate Lawson wrote: > Rolf Witt wrote: > > Abdullah Ibn Hamad Al-Marri schrieb: > >> Hello, > >> > >> I'm getting interrupt storm lately. > > > > No, you use Polling and the interrupt-rate is 1000HZ (your HZ-Option). > > Thats ok. > > > > > >> IM# vmstat -i > >> interrupt total rate > >> irq0: clk 278426173 1000 > > > >> options DEVICE_POLLING > >> options HZ=1000 > > > > He's right. The above options say "run my clock at 1000 hz and poll". > > -- > Nate Thank you guys. I removed them. But still same issue with irq0: clk but less now. IM# vmstat -i interrupt total rate irq0: clk 37009569 1000 irq4: fxp0 2886384 77 irq8: rtc 4736510 127 irq14: ata0 79714 2 Total 44712177 1208 -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 12:37:26 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 354B316A41A for ; Sun, 14 Oct 2007 12:37:26 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 65FED13C48D; Sun, 14 Oct 2007 12:37:25 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47120D83.1010703@FreeBSD.org> Date: Sun, 14 Oct 2007 14:37:23 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Esa Karkkainen References: <20071004165755.GA1049@pp.htv.fi> In-Reply-To: <20071004165755.GA1049@pp.htv.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 12:37:26 -0000 Esa Karkkainen wrote: > I get "Fatal double fault" error when writing to a filesystem > mounted from NFS server. > > Both NFS server and client are running 6.2-RELEASE-p7. > > I've attached dmesg from client and kernel config from server > and client. > > Both have same these NFS options in /etc/rc.conf > > rpcbind_enable="YES" > nfs_server_enable="YES" > nfs_client_enable="YES" > nfs_reserved_port_only="YES" > rpc_lockd_enable="YES" > rpc_statd_enable="YES" > > I have three kernel crash dumps available. > > The panic message is same in vmcore.0 and .1 > > Fatal double fault: > eip = 0xc0608015 > esp = 0xe3955000 > ebp = 0xe3955020 > panic: double fault > > Panic message in vmcore.2 has different eip and ebp values. > > Fatal double fault: > eip = 0xc063242a > esp = 0xe3955000 > ebp = 0xe3955008 > panic: double fault > > And here is backtrace from vmcore.2, which is identical to > backtrace found in vmcore.0 and vmcore.1. Unfortunately the backtrace contains no information. > # kgdb kernel.debug /home/crash/vmcore.2 > Fatal double fault: > eip = 0xc063242a Can you look up these IPs in the kernel symbol table (see the developers handbook)? This might give at least one clue, although I'm not sure it is relevant. You might also update to RELENG_6, I think there was at least one bug fixed that might have caused such a thing. Also try to rule out memory failure etc. Kris From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 13:31:19 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2233016A469 for ; Sun, 14 Oct 2007 13:31:19 +0000 (UTC) (envelope-from matrix@itlegion.ru) Received: from corpmail.itlegion.ru (corpmail.itlegion.ru [84.21.226.211]) by mx1.freebsd.org (Postfix) with SMTP id 2D9EF13C45A for ; Sun, 14 Oct 2007 13:31:17 +0000 (UTC) (envelope-from matrix@itlegion.ru) Received: (qmail 69060 invoked from network); 14 Oct 2007 17:31:12 +0400 Received: from unknown (HELO Artem) (192.168.0.12) by 84.21.226.211 with SMTP; 14 Oct 2007 17:31:12 +0400 X-AntiVirus: Checked by Dr.Web [version: 4.44, engine: 4.44.0.09170, virus records: 249376, updated: 14.10.2007] Message-ID: <008801c80e66$7be49490$0c00a8c0@Artem> From: "Artem Kuchin" To: Date: Sun, 14 Oct 2007 17:30:55 +0400 Organization: IT Legion MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Question about 'top' values on memory usage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 13:31:19 -0000 Hello! Maybe someone with deeper knowledge of the internals of FreeBSD can clean up something for me (any for many others)^ Here are lines from my top: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 9258 hordelo_ru 1 4 0 40992K 4260K accept 0 0:00 0.00% httpd 9257 hordelo_ru 1 44 0 40992K 4296K select 1 0:00 0.00% httpd 9259 hordelo_ru 1 4 0 40992K 4292K select 1 0:00 0.00% httpd As you see, 'size' is the same for all processes, while RES varies. As i understand, the real memory taken by a process is RES and SIZE include a bunch of shares .so libs, so, if more httpd's started each will take only about 4300K more, so, 100 https will take 430000K to run, right? Another question is that is httpd uses threads (as provided by FreeBSD) starting a new thread will or will not copy executable copy and data? Basically, will a new thread eat another 4300K or just a little bit for its data? All this i need to calculate maximum possible number of https i can run on a box with certain amount of memory and select proper MPM for Apache. Somehow, i could not find any practical info on this regarding FreeBSD. Thank you in advance! -- Regards, Artem Kuchin From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 13:35:03 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BE4D16A41A; Sun, 14 Oct 2007 13:35:03 +0000 (UTC) (envelope-from d_elbracht@ecngs.de) Received: from ecngs.de (mail.ecngs.de [217.73.144.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2F5A013C459; Sun, 14 Oct 2007 13:35:02 +0000 (UTC) (envelope-from d_elbracht@ecngs.de) Received: from EC1a (ec1.elbracht.net [217.73.144.99]) by ecngs.de (SurgeMail 3.8f2) with ESMTP id 1773130-1922481 for multiple; Sun, 14 Oct 2007 15:22:59 +0200 From: "d_elbracht" To: , Date: Sun, 14 Oct 2007 15:22:32 +0200 Message-ID: <008801c80e65$47cbe650$639049d9@EC1a> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgOZUbPq0zqvOG2QwSFpRt2OPaAhw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Cc: Subject: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 13:35:03 -0000 we are trying to diagnose errors seen on 6.2, SMP, amd64, cvsup'ed of 2007-10-09 Mainboard is a Tyan Thunder h2000M (S3992-E) with 16 GB RAM and 2 x Opteron 2216, da3 is on a 3ware 9550-12 we are seeing this error: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 on a 12 GB Hyperdrive the offset changes sometimes, but it is always 81064794xxxxxxxxx and well out the 12GB range. We did have the Hyperdrive connected directly to the mainboards SATA0 (ad4) with similar errors. We used to have a md instead of the hyperdrive before, coming up with similar errors. Blocksize on the partition is 8192 (newsfs -b 8192 ..). We did have a blocksize of 65536 before, but after some hours (sometimes days), the machine will be unresponsible with "newbuf" as a waitmessage in top and has to be hard-reset. Regarding "newbuf", as well as nbufkv and nbufbs, I will write a seperate message to the list. According to systat -vm, da3 does tps > 500 (yes, that's a lot) This leads to an assumption, the error has to do with very high IOs per second on a SMP machine. The system-disk is a RAID1 on an ICP 5805. All other disks (51) are 20 gstripe'd partitions. Any hint to diagnose / fix the problem is well appreciated. Cheers, Dieter From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 13:56:47 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDBD016A41B for ; Sun, 14 Oct 2007 13:56:47 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 3D6C013C478 for ; Sun, 14 Oct 2007 13:56:47 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l9EDtAlH059643; Sun, 14 Oct 2007 07:55:10 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <47121F9F.7050900@samsco.org> Date: Sun, 14 Oct 2007 07:54:39 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: d_elbracht References: <008801c80e65$47cbe650$639049d9@EC1a> In-Reply-To: <008801c80e65$47cbe650$639049d9@EC1a> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Sun, 14 Oct 2007 07:55:10 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: Re: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 13:56:47 -0000 d_elbracht wrote: > we are trying to diagnose errors seen on 6.2, SMP, amd64, cvsup'ed of > 2007-10-09 > > Mainboard is a Tyan Thunder h2000M (S3992-E) with 16 GB RAM and 2 x Opteron > 2216, da3 is on a 3ware 9550-12 > > we are seeing this error: > g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 > on a 12 GB Hyperdrive > > the offset changes sometimes, but it is always 81064794xxxxxxxxx and well > out the 12GB range. > > We did have the Hyperdrive connected directly to the mainboards SATA0 (ad4) > with similar errors. > We used to have a md instead of the hyperdrive before, coming up with > similar errors. > > Blocksize on the partition is 8192 (newsfs -b 8192 ..). > We did have a blocksize of 65536 before, but after some hours (sometimes > days), the machine will be unresponsible with "newbuf" as a waitmessage in > top and has to be hard-reset. > Regarding "newbuf", as well as nbufkv and nbufbs, I will write a seperate > message to the list. > > According to systat -vm, da3 does tps > 500 (yes, that's a lot) > > This leads to an assumption, the error has to do with very high IOs per > second on a SMP machine. > The system-disk is a RAID1 on an ICP 5805. All other disks (51) are 20 > gstripe'd partitions. > > Any hint to diagnose / fix the problem is well appreciated. > > Cheers, > > Dieter > I can geneate 30,000 I/O's per second for hours on end on several types of storage hardware on FreeBSD SMP, and have no problems. Since you're seeing this problem both when connected to a 3ware controller and when connected to a simple ATA/SATA controller (both of which have also been observed to do high amounts of I/O with no problems), I suspect that the problem is with your disk device, not with FreeBSD. I don't know anything about a "hyperdrive" though, so more information might help. Scott From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 14:09:02 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92BDA16A417; Sun, 14 Oct 2007 14:09:02 +0000 (UTC) (envelope-from d_elbracht@ecngs.de) Received: from ecngs.de (mail.ecngs.de [217.73.144.50]) by mx1.freebsd.org (Postfix) with ESMTP id B409413C48E; Sun, 14 Oct 2007 14:09:01 +0000 (UTC) (envelope-from d_elbracht@ecngs.de) Received: from EC1a (ec1.elbracht.net [217.73.144.99]) by ecngs.de (SurgeMail 3.8f2) with ESMTP id 1773204-1922481 for multiple; Sun, 14 Oct 2007 16:09:11 +0200 From: "d_elbracht" To: "'Scott Long'" References: <008801c80e65$47cbe650$639049d9@EC1a> <47121F9F.7050900@samsco.org> Date: Sun, 14 Oct 2007 16:08:44 +0200 Message-ID: <008d01c80e6b$bb95b7e0$639049d9@EC1a> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgOa5ciuX2g50BFT+K6MBnLZJ0DxQAASbtQ In-Reply-To: <47121F9F.7050900@samsco.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Cc: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: AW: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 14:09:02 -0000 > > we are trying to diagnose errors seen on 6.2, SMP, amd64, > cvsup'ed of > > 2007-10-09 > > > > Mainboard is a Tyan Thunder h2000M (S3992-E) with 16 GB RAM and 2 x > > Opteron 2216, da3 is on a 3ware 9550-12 > > > > we are seeing this error: > > g_vfs_done():da3s1a[READ(offset=81064794762854400, > length=8192)]error > > = 5 on a 12 GB Hyperdrive > > > > the offset changes sometimes, but it is always > 81064794xxxxxxxxx and > > well out the 12GB range. > > > > We did have the Hyperdrive connected directly to the > mainboards SATA0 > > (ad4) with similar errors. > > We used to have a md instead of the hyperdrive before, > coming up with > > similar errors. > > > > Blocksize on the partition is 8192 (newsfs -b 8192 ..). > > We did have a blocksize of 65536 before, but after some hours > > (sometimes days), the machine will be unresponsible with > "newbuf" as a > > waitmessage in top and has to be hard-reset. > > Regarding "newbuf", as well as nbufkv and nbufbs, I will write a > > seperate message to the list. > > > > According to systat -vm, da3 does tps > 500 (yes, that's a lot) > > > > This leads to an assumption, the error has to do with very high IOs > > per second on a SMP machine. > > The system-disk is a RAID1 on an ICP 5805. All other disks > (51) are 20 > > gstripe'd partitions. > > > > Any hint to diagnose / fix the problem is well appreciated. > > > > Cheers, > > > > Dieter > > > > I can geneate 30,000 I/O's per second for hours on end on > several types of storage hardware on FreeBSD SMP, and have no > problems. Since you're seeing this problem both when > connected to a 3ware controller and when connected to a > simple ATA/SATA controller (both of which have also been > observed to do high amounts of I/O with no problems), I > suspect that the problem is with your disk device, not with > FreeBSD. I don't know anything about a "hyperdrive" though, > so more information might help. > > Scott Well, how about this: > > We used to have a md instead of the hyperdrive before, > coming up with > > similar errors. here ist some info about the hyperdrive. http://www.hyperossystems.co.uk/ We could go back the the md (memory-disk) to try again. What exactly does the "offset" in the error-message mean ? Isn't that like a seek on the disk ? And what does "error=5" mean ? Sure, the whole thing could be a problem of the application running. It's diablo 5. The history file (dhistory) about 2 GB in size resides on the hyperdrive. Dieter From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 14:42:13 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DA3D16A41A; Sun, 14 Oct 2007 14:42:13 +0000 (UTC) (envelope-from d_elbracht@ecngs.de) Received: from ecngs.de (mail.ecngs.de [217.73.144.50]) by mx1.freebsd.org (Postfix) with ESMTP id EAF7D13C457; Sun, 14 Oct 2007 14:42:11 +0000 (UTC) (envelope-from d_elbracht@ecngs.de) Received: from EC1a (ec1.elbracht.net [217.73.144.99]) by ecngs.de (SurgeMail 3.8f2) with ESMTP id 1773237-1922481 for multiple; Sun, 14 Oct 2007 16:42:32 +0200 From: "d_elbracht" To: , Date: Sun, 14 Oct 2007 16:42:06 +0200 Message-ID: <008e01c80e70$64c92910$639049d9@EC1a> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgOcGQ+rp1Mn0RqSFKuKB0DklKcNw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Cc: Subject: newbuf, nbufkv, nbufbs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 14:42:13 -0000 We have 2 machines involved with this problem. machine1, SMP, i386, 4 GB RAM was recently upgraded from 5.4 to 6.2 cvsup'ed 2007-10-10 a partition of about 2.5 TB (gstripe -s 1048576) was newfs'ed with blocksize of 65536 and fragsize of 8192 On 5.4, this was running for months with no problem. On 6.2 after a few hours of high thruput (network tx and rx 400-500 Mbit each), it became unresponsible with top showing a lot of processes with waitmessage newbuf. So, reset, fsck etc and it run again, only after a few hours, it became unresponsible again, showing processes with nbufkv and nbufbs this time, I did newfs with blocksize of 32768 and fragsize of 4096 and it's running. Thruput is decreased to 300-400 Mbit Note, it did NEVER show the problem on 5.4 machine2, SMP, amd64, 16 GB RAM, 6.2 cvsup'ed 2007-10-09 20 partitions involving 51 disks, all gstripe -s 1048576, newfs -b 65536 -f 8192 1 partion of 12 GB, (da3s1a) newfs -b 65536 -f 8192 after a few hours, top shows newbuf and the machine is unresponsible. tps on da3s1a is > 500, the others are < 100 I did newfs -b 8192 -f 1024 /dev/da3s1a and it's running without the problem (yet) The problem seems to have to do with -b 65536 and lot's of IOPS ond 6.2 Any clue ? e.g. increase BKVASIZE to 131072 and kern.nbuf to 32768 ? Cheers, Dieter From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 15:38:44 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0704016A421 for ; Sun, 14 Oct 2007 15:38:44 +0000 (UTC) (envelope-from lars@larseighner.com) Received: from mail.team1internet.com (mail.team1internet.com [216.110.13.10]) by mx1.freebsd.org (Postfix) with ESMTP id D6F6A13C455 for ; Sun, 14 Oct 2007 15:38:43 +0000 (UTC) (envelope-from lars@larseighner.com) Received: by mail.team1internet.com (Postfix, from userid 12346) id 51A5416B751; Sun, 14 Oct 2007 10:38:43 -0500 (CDT) Received: from larseighner.com (unknown [216.110.13.72]) by mail.team1internet.com (Postfix) with SMTP id 876C116B747; Sun, 14 Oct 2007 10:38:41 -0500 (CDT) Received: by larseighner.com (nbSMTP-1.00) for uid 1001 lars@larseighner.com; Sun, 14 Oct 2007 10:37:39 -0500 (CDT) Date: Sun, 14 Oct 2007 10:37:38 -0500 (CDT) From: Lars Eighner X-X-Sender: lars@debranded.6dollardialup.com To: d_elbracht In-Reply-To: <008801c80e65$47cbe650$639049d9@EC1a> Message-ID: <20071014103129.W19754@qroenaqrq.6qbyyneqvnyhc.pbz> References: <008801c80e65$47cbe650$639049d9@EC1a> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Sanitizer: Anomy and SpamAssassin mail filter - see http://www.6dollardialup.com/support/spaminfo.html X-Spam-Status: No, hits=-3.2 required=10.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,J_CHICKENPOX_52,OACYS_SINGLE, QUOTED_EMAIL_TEXT,REFERENCES,RM_sl_Parens, TO_LOCALPART_EQ_REAL version=2.43 X-Spam-Level: Cc: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: Re: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 15:38:44 -0000 On Sun, 14 Oct 2007, d_elbracht wrote: > we are trying to diagnose errors seen on 6.2, SMP, amd64, cvsup'ed of > 2007-10-09 > > Mainboard is a Tyan Thunder h2000M (S3992-E) with 16 GB RAM and 2 x Opteron > 2216, da3 is on a 3ware 9550-12 > > we are seeing this error: > g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 > on a 12 GB Hyperdrive I trashed a perfectly disk drive before learning that there is a serious bug in g_vfs. Apparently it is one of those things which shows up in some configurations and not others. Although I am told they are unable to isolate the problem, all the reports I've seen were from people using AMD systems. From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 16:09:21 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD3B916A46B; Sun, 14 Oct 2007 16:09:21 +0000 (UTC) (envelope-from d_elbracht@ecngs.de) Received: from ecngs.de (mail.ecngs.de [217.73.144.50]) by mx1.freebsd.org (Postfix) with ESMTP id 144D113C457; Sun, 14 Oct 2007 16:09:20 +0000 (UTC) (envelope-from d_elbracht@ecngs.de) Received: from EC1a (ec1.elbracht.net [217.73.144.99]) by ecngs.de (SurgeMail 3.8f2) with ESMTP id 1773356-1922481 for multiple; Sun, 14 Oct 2007 18:09:25 +0200 From: "d_elbracht" To: =?iso-8859-1?Q?'Arne_W=F6rner'?= , "'Scott Long'" References: <47121F9F.7050900@samsco.org> <847856.24179.qm@web30308.mail.mud.yahoo.com> Date: Sun, 14 Oct 2007 18:08:57 +0200 Message-ID: <008f01c80e7c$876c89b0$639049d9@EC1a> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgOcRU1cBtJiEb5TsWoeT7TKFDfDAACwHKw In-Reply-To: <847856.24179.qm@web30308.mail.mud.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Cc: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: AW: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 16:09:21 -0000 > --- Scott Long wrote: > > I can geneate 30,000 I/O's per second for hours on end on several > > types of storage hardware on FreeBSD SMP, and have no > problems. Since > > you're seeing this problem both when connected to a 3ware > controller > > and when connected to a simple ATA/SATA controller (both of > which have > > also been observed to do high amounts of I/O with no problems), I > > suspect that the problem is with your disk device, not with > FreeBSD. > > I don't know anything about a "hyperdrive" though, so more > information might help. > > > > Scott > > > I would say so, too... > > Especially because errno 5 is EIO: > http://www.freebsd.org/cgi/man.cgi?query=errno&apropos=0&sekti > on=0&manpath=FreeBSD+6.2-RELEASE&format=html > > -Arne I would agree with you on that, if the error (EIO) is NOT because of the READ going wrong in the first place. >From my understanding, the offset 81064794762854400 is NOT within the 12 GB of the drive anymore. Or, does the offset mean something else ? Dieter From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 18:05:17 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19C7A16A481 for ; Sun, 14 Oct 2007 18:05:17 +0000 (UTC) (envelope-from alson+ml@alm.flutnet.org) Received: from smtp20.nijmegen.internl.net (smtp20.nijmegen.internl.net [217.149.192.18]) by mx1.freebsd.org (Postfix) with ESMTP id 321FD13C461 for ; Sun, 14 Oct 2007 18:05:16 +0000 (UTC) (envelope-from alson+ml@alm.flutnet.org) Received: from tafi.alm.flutnet.org (tafi.dsl.alm.flutnet.org [145.99.245.99]) by smtp20.nijmegen.internl.net (8.13.8/2.04) with ESMTP id l9EI5ClG013114 for ; Sun, 14 Oct 2007 20:05:14 +0200 (CEST) Received: from localhost (localhost.alm.flutnet.org [127.0.0.1]) by tafi.alm.flutnet.org (Postfix) with ESMTP id 4BD8611415 for ; Sun, 14 Oct 2007 20:05:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at alm.flutnet.org Received: from tafi.alm.flutnet.org ([127.0.0.1]) by localhost (tafi.alm.flutnet.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxbP7xlInDLE for ; Sun, 14 Oct 2007 20:05:03 +0200 (CEST) Received: by tafi.alm.flutnet.org (Postfix, from userid 1000) id 5B37511414; Sun, 14 Oct 2007 20:05:03 +0200 (CEST) Date: Sun, 14 Oct 2007 20:05:03 +0200 From: Alson van der Meulen To: freebsd-stable@freebsd.org Message-ID: <20071014180503.GA3065@waalsdorp.nl> Mail-Followup-To: freebsd-stable@freebsd.org References: <20071014064844.GA1067@faust.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071014064844.GA1067@faust.net> User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: usb stick problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 18:05:17 -0000 * Zoran Kolic [2007-10-14 08:48]: > I encountered something minor to usual problems, > people have on this list, but it makes me nervous. > I bought brand new usb flash stick and used it to > solve the issue on handheld. After putting files > on it, I have them in format 8.3. The option to > mount -t was msdosfs. It should bring me long file > names, but it does not. Mu stupid question would > be: did I chose wrong file system? Or is this usb > drive preformatted in something strange like fat16? This sounds like the documented behavior if the drive was empty or had no long filenames when you mounted it. From mount_msdosfs(8): "If neither -s nor -l are given, mount_msdosfs searches the root directory of the file system to be mounted for any existing Win'95 long filenames. If no such entries are found, but short DOS filenames are found, -s is the default. Otherwise -l is assumed." -o longnames should do the trick. Alson From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 18:45:29 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 856CF16A41A; Sun, 14 Oct 2007 18:45:29 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id DAAED13C44B; Sun, 14 Oct 2007 18:45:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l9EIFPer060995; Sun, 14 Oct 2007 12:15:25 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <47125C9E.1040109@samsco.org> Date: Sun, 14 Oct 2007 12:14:54 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Lars Eighner References: <008801c80e65$47cbe650$639049d9@EC1a> <20071014103129.W19754@qroenaqrq.6qbyyneqvnyhc.pbz> In-Reply-To: <20071014103129.W19754@qroenaqrq.6qbyyneqvnyhc.pbz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Sun, 14 Oct 2007 12:15:26 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-stable@freebsd.org, d_elbracht , freebsd-geom@freebsd.org Subject: Re: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 18:45:29 -0000 Lars Eighner wrote: > On Sun, 14 Oct 2007, d_elbracht wrote: > >> we are trying to diagnose errors seen on 6.2, SMP, amd64, cvsup'ed of >> 2007-10-09 >> >> Mainboard is a Tyan Thunder h2000M (S3992-E) with 16 GB RAM and 2 x >> Opteron >> 2216, da3 is on a 3ware 9550-12 >> >> we are seeing this error: >> g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 >> on a 12 GB Hyperdrive > > I trashed a perfectly disk drive before learning that there is a serious > bug > in g_vfs. Apparently it is one of those things which shows up in some > configurations and not others. Although I am told they are unable to > isolate the problem, all the reports I've seen were from people using AMD > systems. > Are you talking about problems with ATA controllers, AMD64 (or i386+PAE), and more than 4GB of RAM? Or something else? Scott From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 18:45:58 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C32EB16A496 for ; Sun, 14 Oct 2007 18:45:58 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 861CF13C45D for ; Sun, 14 Oct 2007 18:45:58 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 24138 invoked from network); 14 Oct 2007 18:45:59 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 14 Oct 2007 18:45:59 -0000 Message-ID: <471263DC.8070002@root.org> Date: Sun, 14 Oct 2007 11:45:48 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Abdullah Ibn Hamad Al-Marri References: <499c70c0710121333q7ba6ab34sff9ce3832ce81347@mail.gmail.com> <470FDF18.9010109@donut.de> <47100D46.5020601@root.org> <499c70c0710140536x49624f4x58a80713b244974f@mail.gmail.com> In-Reply-To: <499c70c0710140536x49624f4x58a80713b244974f@mail.gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Rolf Witt Subject: Re: FreeBSD 7.0 interrupt storm with irq0: clk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 18:45:58 -0000 Abdullah Ibn Hamad Al-Marri wrote: > On 10/13/07, Nate Lawson wrote: >> Rolf Witt wrote: >>> Abdullah Ibn Hamad Al-Marri schrieb: >>>> Hello, >>>> >>>> I'm getting interrupt storm lately. >>> No, you use Polling and the interrupt-rate is 1000HZ (your HZ-Option). >>> Thats ok. >>> >>> >>>> IM# vmstat -i >>>> interrupt total rate >>>> irq0: clk 278426173 1000 >>>> options DEVICE_POLLING >>>> options HZ=1000 >> He's right. The above options say "run my clock at 1000 hz and poll". >> >> -- >> Nate > > Thank you guys. > > I removed them. > > But still same issue with irq0: clk but less now. > > IM# vmstat -i > interrupt total rate > irq0: clk 37009569 1000 > irq4: fxp0 2886384 77 > irq8: rtc 4736510 127 > irq14: ata0 79714 2 > Total 44712177 1208 I don't see a storm -- it's coming in at exactly 1000 per second. The above shows your machine probably has been up about 10 hours. -- Nate From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 18:49:27 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AA3D16A46E for ; Sun, 14 Oct 2007 18:49:27 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id 05B3013C474 for ; Sun, 14 Oct 2007 18:49:26 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l9EInOSX017217; Mon, 15 Oct 2007 04:49:24 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l9EInO05017216; Mon, 15 Oct 2007 04:49:24 +1000 (EST) (envelope-from peter) Date: Mon, 15 Oct 2007 04:49:24 +1000 From: Peter Jeremy To: Abdullah Ibn Hamad Al-Marri Message-ID: <20071014184924.GU93545@turion.vk2pj.dyndns.org> References: <499c70c0710121333q7ba6ab34sff9ce3832ce81347@mail.gmail.com> <470FDF18.9010109@donut.de> <47100D46.5020601@root.org> <499c70c0710140536x49624f4x58a80713b244974f@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X+nYw8KZ/oNxZ8JS" Content-Disposition: inline In-Reply-To: <499c70c0710140536x49624f4x58a80713b244974f@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.0 interrupt storm with irq0: clk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 18:49:27 -0000 --X+nYw8KZ/oNxZ8JS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Oct-14 15:36:39 +0300, Abdullah Ibn Hamad Al-Marri wrote: >On 10/13/07, Nate Lawson wrote: >> Rolf Witt wrote: >> > Abdullah Ibn Hamad Al-Marri schrieb: >> >> Hello, >> >> >> >> I'm getting interrupt storm lately. =2E.. >But still same issue with irq0: clk but less now. > >IM# vmstat -i >interrupt total rate >irq0: clk 37009569 1000 So far, you haven't provided any evidence of any "interrupt storm" or how it might be related to acpi. And 7.0 isn't stable yet. The default HZ is 1000 so unless you explicitly change it in your kernel config, you should have 1000 clock interrupts/sec. --=20 Peter Jeremy --X+nYw8KZ/oNxZ8JS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHEmS0/opHv/APuIcRAhYoAKCW9zFF8StyqDm4SSKOrv7n70rrBQCdFkLZ RwZXEqkAF5C3EYBXnYywqqw= =ss0+ -----END PGP SIGNATURE----- --X+nYw8KZ/oNxZ8JS-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 20:30:26 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0EA616A420 for ; Sun, 14 Oct 2007 20:30:26 +0000 (UTC) (envelope-from wearabnet@yahoo.ca) Received: from web33704.mail.mud.yahoo.com (web33704.mail.mud.yahoo.com [68.142.201.201]) by mx1.freebsd.org (Postfix) with SMTP id 81B0F13C468 for ; Sun, 14 Oct 2007 20:30:26 +0000 (UTC) (envelope-from wearabnet@yahoo.ca) Received: (qmail 8712 invoked by uid 60001); 14 Oct 2007 20:03:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=SHvRxJRugdLVDosycZ8a7LoDlrjNldZHVX5AGAP+YorMt3l2zrpyR0S1/+4yNUFrrjpaQ8EsZQrVnO9Fyf0kQiS1amMZe6pD1U0AbF8eMbUSOPsJ+nKvyjV+YrXqlFhK5II2RAWoQw9dh81tbbTEmTyK6zmf118NmTReWNx/hJE=; X-YMail-OSG: VDYNUaAVM1lC1U8qanXXLp5JMHLsdSgUxRLcn1RiKHAz_8rCCRVIr9S0jxdkA6rOnkRoEEginSIuo6p4X2QMOmhzx_Di.7O2ou5O6KjQt32Qg30mRxA- Received: from [87.109.240.68] by web33704.mail.mud.yahoo.com via HTTP; Sun, 14 Oct 2007 13:03:44 PDT X-Mailer: YahooMailRC/814.05 YahooMailWebService/0.7.134.12 Date: Sun, 14 Oct 2007 13:03:44 -0700 (PDT) From: Abdullah Ibn Hamad Al-Marri To: Peter Jeremy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: <58790.8375.qm@web33704.mail.mud.yahoo.com> Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.0 interrupt storm with irq0: clk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 20:30:26 -0000 On 2007-Oct-14 15:36:39 +0300, Abdullah Ibn Hamad Al-Marri=0A wrote:=0A>On 10/13/07, Nate Lawson wrote:=0A>> Rolf= Witt wrote:=0A>> > Abdullah Ibn Hamad Al-Marri schrieb:=0A>> >> Hello,=0A>= > >>=0A>> >> I'm getting interrupt storm lately.=0A...=0A>But still same is= sue with irq0: clk but less now.=0A>=0A>IM# vmstat -i=0A>interrupt = total rate=0A>irq0: clk 370095= 69 1000=0A=0A>So far, you haven't provided any evidence of any "inter= rupt storm" or=0A>how it might be related to acpi. And 7.0 isn't stable ye= t.=0A=0A>The default HZ is 1000 so unless you explicitly change it in your= =0A>kernel config, you should have 1000 clock interrupts/sec.=0A=0A>-- =0A>= Peter Jeremy=0A=0A=0A=0A=0AActually no more interrupt after I added these o= ptions back to my kernel while it's UP not SMP, and vmstat output has chang= ed totally.=0A=0A# To make an SMP kernel, the next two lines are needed=0Ao= ptions SMP # Symmetric MultiProcessor Kernel=0A= device apic # I/O APIC=0A=0AIM# vmstat -i=0Aint= errupt total rate=0Airq14: ata0 = 4837 0=0Airq23: fxp0 2203298 = 86=0Acpu0: timer 50755929 1999=0ATotal = 52964064 2086=0A=0AI even don't see irq0 in vmsta= t at all.=0A=0AAny hints?=0A=0A =0ARegards, =0A-Abdullah Ibn Hamad Al-Marri= =0AArab Portal=0Ahttp://www.WeArab.Net/=0A=0A=0A=0A=0A=0A ____________= ________________________________________________________________________=0A= Tonight's top picks. What will you watch tonight? Preview the hottest shows= on Yahoo! TV.=0Ahttp://tv.yahoo.com/ =0A From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 20:34:23 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51A4516A41B for ; Sun, 14 Oct 2007 20:34:23 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.freebsd.org (Postfix) with ESMTP id 104F013C458 for ; Sun, 14 Oct 2007 20:34:22 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.1/8.14.1) id l9EKYLSR098131; Sun, 14 Oct 2007 15:34:21 -0500 (CDT) (envelope-from dan) Date: Sun, 14 Oct 2007 15:34:20 -0500 From: Dan Nelson To: Artem Kuchin Message-ID: <20071014203420.GB2490@dan.emsphone.com> References: <008801c80e66$7be49490$0c00a8c0@Artem> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008801c80e66$7be49490$0c00a8c0@Artem> X-OS: FreeBSD 7.0-PRERELEASE User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: Question about 'top' values on memory usage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 20:34:23 -0000 In the last episode (Oct 14), Artem Kuchin said: > Maybe someone with deeper knowledge of the internals of FreeBSD can > clean up something for me (any for many others)^ > > Here are lines from my top: > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 9258 hordelo_ru 1 4 0 40992K 4260K accept 0 0:00 0.00% httpd > 9257 hordelo_ru 1 44 0 40992K 4296K select 1 0:00 0.00% httpd > 9259 hordelo_ru 1 4 0 40992K 4292K select 1 0:00 0.00% httpd > > As you see, 'size' is the same for all processes, while RES varies. > > As i understand, the real memory taken by a process is RES and SIZE > include a bunch of shares .so libs, so, if more httpd's started each > will take only about 4300K more, so, 100 https will take 430000K to > run, right? The memory used by a process is SIZE. RES is the amount of that memory that's in memory. The rest would either be still on disk (in the form of executable or mmaped pages that haven't been accessed), in swap, or prezeroed pages that haven't been accessed yet (large blocks of malloc()'ed memory for example). Processes forked from the same parent can share the same pages until one process writes to one (a copy is then made so the other processes still see the right data). Chances are that those three httpd processes are sharing 99% of their pages. I don't know of any easy way of determing exactly how much non-shared memory a particular process has. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 21:06:40 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9AB316A418 for ; Sun, 14 Oct 2007 21:06:40 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 92C5013C47E for ; Sun, 14 Oct 2007 21:06:40 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 32127 invoked from network); 14 Oct 2007 21:06:41 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.0.15?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 14 Oct 2007 21:06:41 -0000 Message-ID: <471284F7.7020503@root.org> Date: Sun, 14 Oct 2007 14:07:03 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Abdullah Ibn Hamad Al-Marri References: <58790.8375.qm@web33704.mail.mud.yahoo.com> In-Reply-To: <58790.8375.qm@web33704.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.0 interrupt storm with irq0: clk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 21:06:40 -0000 Abdullah Ibn Hamad Al-Marri wrote: > On 2007-Oct-14 15:36:39 +0300, Abdullah Ibn Hamad Al-Marri > wrote: >> On 10/13/07, Nate Lawson wrote: >>> Rolf Witt wrote: >>>> Abdullah Ibn Hamad Al-Marri schrieb: >>>>> Hello, >>>>> >>>>> I'm getting interrupt storm lately. > ... >> But still same issue with irq0: clk but less now. >> >> IM# vmstat -i >> interrupt total rate >> irq0: clk 37009569 1000 > >> So far, you haven't provided any evidence of any "interrupt storm" or >> how it might be related to acpi. And 7.0 isn't stable yet. > >> The default HZ is 1000 so unless you explicitly change it in your >> kernel config, you should have 1000 clock interrupts/sec. > > Actually no more interrupt after I added these options back to my kernel while it's UP not SMP, and vmstat output has changed totally. > > # To make an SMP kernel, the next two lines are needed > options SMP # Symmetric MultiProcessor Kernel > device apic # I/O APIC > > IM# vmstat -i > interrupt total rate > irq14: ata0 4837 0 > irq23: fxp0 2203298 86 > cpu0: timer 50755929 1999 > Total 52964064 2086 > > I even don't see irq0 in vmstat at all. > > Any hints? All you did was enable the lapic timer. I'm sorry that I don't have time to explain all the PC stuff to you, just stick with GENERIC and you'll be fine. -- Nate From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 21:14:57 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 576B616A418 for ; Sun, 14 Oct 2007 21:14:57 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id C833913C468 for ; Sun, 14 Oct 2007 21:14:56 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-31-60.bredband.comhem.se ([83.253.31.60]:65256 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1IhAnX-0004IM-8Z for freebsd-stable@freebsd.org; Sun, 14 Oct 2007 23:14:55 +0200 Received: (qmail 47502 invoked from network); 14 Oct 2007 23:14:52 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 14 Oct 2007 23:14:52 +0200 Received: (qmail 72801 invoked by uid 1001); 14 Oct 2007 23:14:52 +0200 Date: Sun, 14 Oct 2007 23:14:52 +0200 From: Erik Trulsson To: Abdullah Ibn Hamad Al-Marri Message-ID: <20071014211452.GA72643@owl.midgard.homeip.net> Mail-Followup-To: Abdullah Ibn Hamad Al-Marri , Peter Jeremy , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org References: <58790.8375.qm@web33704.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58790.8375.qm@web33704.mail.mud.yahoo.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Originating-IP: 83.253.31.60 X-Scan-Result: No virus found in message 1IhAnX-0004IM-8Z. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1IhAnX-0004IM-8Z 3927acbfc6ff83232b01ad20e9760a75 Cc: Peter Jeremy , freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FreeBSD 7.0 interrupt storm with irq0: clk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 21:14:57 -0000 On Sun, Oct 14, 2007 at 01:03:44PM -0700, Abdullah Ibn Hamad Al-Marri wrote: > On 2007-Oct-14 15:36:39 +0300, Abdullah Ibn Hamad Al-Marri > wrote: > >On 10/13/07, Nate Lawson wrote: > >> Rolf Witt wrote: > >> > Abdullah Ibn Hamad Al-Marri schrieb: > >> >> Hello, > >> >> > >> >> I'm getting interrupt storm lately. > ... > >But still same issue with irq0: clk but less now. > > > >IM# vmstat -i > >interrupt total rate > >irq0: clk 37009569 1000 > > >So far, you haven't provided any evidence of any "interrupt storm" or > >how it might be related to acpi. And 7.0 isn't stable yet. > > >The default HZ is 1000 so unless you explicitly change it in your > >kernel config, you should have 1000 clock interrupts/sec. > > >-- > >Peter Jeremy > > > > > Actually no more interrupt after I added these options back to my kernel while it's UP not SMP, and vmstat output has changed totally. > > # To make an SMP kernel, the next two lines are needed > options SMP # Symmetric MultiProcessor Kernel > device apic # I/O APIC > > IM# vmstat -i > interrupt total rate > irq14: ata0 4837 0 > irq23: fxp0 2203298 86 > cpu0: timer 50755929 1999 > Total 52964064 2086 > > I even don't see irq0 in vmstat at all. > > Any hints? It looks like different timecounters are used depending on your kernel options. In the first case you probably used TSC or i8254 as timecounter while in the second (where you get timer interrupts on cpu0 instead of on irq0) you use ACPI as timecounter. The output of 'sysctl kern.timecounter.choice' for both cases might be illuminating. In any case there is still no indication of any interrupt storm. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 22:29:58 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C81EA16A420 for ; Sun, 14 Oct 2007 22:29:58 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4795313C4E8 for ; Sun, 14 Oct 2007 22:29:57 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IhBy3-0001kL-ED for freebsd-stable@freebsd.org; Sun, 14 Oct 2007 22:29:51 +0000 Received: from 78-0-70-24.adsl.net.t-com.hr ([78.0.70.24]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Oct 2007 22:29:51 +0000 Received: from ivoras by 78-0-70-24.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Oct 2007 22:29:51 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 15 Oct 2007 00:29:43 +0200 Lines: 69 Message-ID: References: <008801c80e65$47cbe650$639049d9@EC1a> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig21A4E76CE0AE386C4A722243" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-0-70-24.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) In-Reply-To: <008801c80e65$47cbe650$639049d9@EC1a> X-Enigmail-Version: 0.95.3 Sender: news Cc: freebsd-geom@freebsd.org Subject: Re: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 22:29:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig21A4E76CE0AE386C4A722243 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable d_elbracht wrote: > we are trying to diagnose errors seen on 6.2, SMP, amd64, cvsup'ed of > 2007-10-09 >=20 > Mainboard is a Tyan Thunder h2000M (S3992-E) with 16 GB RAM and 2 x Opt= eron > 2216, da3 is on a 3ware 9550-12 >=20 > we are seeing this error: > g_vfs_done():da3s1a[READ(offset=3D81064794762854400, length=3D8192)]err= or =3D 5 > on a 12 GB Hyperdrive >=20 > the offset changes sometimes, but it is always 81064794xxxxxxxxx and we= ll > out the 12GB range. Yes. > According to systat -vm, da3 does tps > 500 (yes, that's a lot) That's not a lot :) That's actually low for a modern solid state drive. > This leads to an assumption, the error has to do with very high IOs per= > second on a SMP machine. Either that or file system errors. Does fsck run ok or does it say anything unusual? There are several theoretical reasons for such errors that are connected with the fact you use solid state drives, but all are tricky to diagnose if you don't have a certain repeatable test you can try. For example: some SSDs optimize writes to "spread out" the IO on the chips, but some do it by looking into file system structures to determine where it's safe to relocate the write - obviously this works only with a known and supported file system. This is a really wild guess, but maybe the SSD firmware has error somewhere in this area, trying to interpret UFS as it was FAT? If you manage to get a repeatable failure test, you can try formatting the drive as FAT32 and trying it on that. Or maybe it's just a bad drive... > The system-disk is a RAID1 on an ICP 5805. All other disks (51) are 20 > gstripe'd partitions. 51 drives and 20 partitions? --------------enig21A4E76CE0AE386C4A722243 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHEphXldnAQVacBcgRAsQFAJ4l90djOgPaUgrkIRm1lWn9Sx64SQCgx+g+ 4TTenqPgdeJL9f0fdvgDyO0= =A3gv -----END PGP SIGNATURE----- --------------enig21A4E76CE0AE386C4A722243-- From owner-freebsd-stable@FreeBSD.ORG Sun Oct 14 23:22:35 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 629A916A468; Sun, 14 Oct 2007 23:22:35 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 0B32013C50D; Sun, 14 Oct 2007 23:22:34 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l9ENMSTf062135; Sun, 14 Oct 2007 17:22:29 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4712A494.30803@samsco.org> Date: Sun, 14 Oct 2007 17:21:56 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Ivan Voras References: <008801c80e65$47cbe650$639049d9@EC1a> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Sun, 14 Oct 2007 17:22:29 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: Re: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2007 23:22:35 -0000 Ivan Voras wrote: > d_elbracht wrote: >> we are trying to diagnose errors seen on 6.2, SMP, amd64, cvsup'ed of >> 2007-10-09 >> >> Mainboard is a Tyan Thunder h2000M (S3992-E) with 16 GB RAM and 2 x Opteron >> 2216, da3 is on a 3ware 9550-12 >> >> we are seeing this error: >> g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 >> on a 12 GB Hyperdrive >> >> the offset changes sometimes, but it is always 81064794xxxxxxxxx and well >> out the 12GB range. > > Yes. > >> According to systat -vm, da3 does tps > 500 (yes, that's a lot) > > That's not a lot :) That's actually low for a modern solid state drive. > >> This leads to an assumption, the error has to do with very high IOs per >> second on a SMP machine. > > Either that or file system errors. Does fsck run ok or does it say > anything unusual? > No, filesystem corruption has nothing to do with g_vfs_done messages. Scott From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 00:04:57 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3996C16A46D for ; Mon, 15 Oct 2007 00:04:57 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 2752513C481 for ; Mon, 15 Oct 2007 00:04:55 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 90463 invoked from network); 14 Oct 2007 23:38:35 -0000 Received: from midgard.transactionware.com (192.168.1.55) by dm.transactionware.com with SMTP; 14 Oct 2007 23:38:35 -0000 Received: (qmail 20180 invoked by uid 907); 14 Oct 2007 23:38:12 -0000 Received: from [192.168.1.51] (HELO janmxp) (192.168.1.51) by midgard.transactionware.com (qpsmtpd/0.32) with ESMTP; Mon, 15 Oct 2007 09:38:12 +1000 From: "Jan Mikkelsen" To: "'Scott Long'" , "'Ivan Voras'" References: <008801c80e65$47cbe650$639049d9@EC1a> <4712A494.30803@samsco.org> In-Reply-To: <4712A494.30803@samsco.org> Date: Mon, 15 Oct 2007 09:38:12 +1000 Organization: Transactionware Message-ID: <000a01c80ebb$49227f90$db677eb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgOuTwXgPkltFJRQheLCsRVqNf9bwAAU00w Content-Language: en-au Cc: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: RE: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 00:04:57 -0000 Scott Long wrote: > Ivan Voras wrote: > > Either that or file system errors. Does fsck run ok or does > it say > > anything unusual? > > > > No, filesystem corruption has nothing to do with g_vfs_done > messages. Well, perhaps not directly but I think filesystem corruption can indirectly cause g_vfs_done messages. If a filesystem is corrupt, the filesystem might attempt to read an out-of-range block, leading to a g_vfs_done error. This was the case for some of the arcmsr problems last year. In this case, I think the original poster said that the block number was out of range for the device. Regards, Jan Mikkelsen From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 00:14:05 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1199F16A419; Mon, 15 Oct 2007 00:14:05 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id A924A13C455; Mon, 15 Oct 2007 00:14:04 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l9F0DvlP062319; Sun, 14 Oct 2007 18:13:58 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4712B0A6.1050408@samsco.org> Date: Sun, 14 Oct 2007 18:13:26 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Jan Mikkelsen References: <008801c80e65$47cbe650$639049d9@EC1a> <4712A494.30803@samsco.org> <000a01c80ebb$49227f90$db677eb0$@com> In-Reply-To: <000a01c80ebb$49227f90$db677eb0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Sun, 14 Oct 2007 18:13:58 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-stable@freebsd.org, 'Ivan Voras' , freebsd-geom@freebsd.org Subject: Re: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 00:14:05 -0000 Jan Mikkelsen wrote: > Scott Long wrote: >> Ivan Voras wrote: >>> Either that or file system errors. Does fsck run ok or does >> it say >>> anything unusual? >>> >> No, filesystem corruption has nothing to do with g_vfs_done >> messages. > > Well, perhaps not directly but I think filesystem corruption can > indirectly cause g_vfs_done messages. > > If a filesystem is corrupt, the filesystem might attempt to read an > out-of-range block, leading to a g_vfs_done error. This was the > case for some of the arcmsr problems last year. > > In this case, I think the original poster said that the block > number was out of range for the device. > > Regards, > > Jan Mikkelsen > > Yeah, you're right, the block number is absurd, and it could well be caused by a bad block pointer in the filesystem. It sounds like he's getting this problem even on fresh installs, which ordinarily would point to a bad driver. If it's happening with both TWA and ATA, it's hard to blame both of those drivers. Scott From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 01:46:16 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A169C16A46E for ; Mon, 15 Oct 2007 01:46:16 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 535DC13C4BA for ; Mon, 15 Oct 2007 01:46:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1166970rvb for ; Sun, 14 Oct 2007 18:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=La5+HsaOhzHftz1+ln5vjdzVfNH3j7+ZCsD/Yp9yx84=; b=fbSSgCUGLoz6Gvw7QiZslBud0tawJJ8CHCZDzAZHtssdiXQ/S68yFy36JM+xQGx9xwTcfYMVZVPQaidqiQS7iENFU8QY1V7DqVZ81BXbhGfAoRhP7ZjZCe0par7SUAP8eg+hAjKblrO4mWH1tSBuvJ5ymt04mW0ZdAbGmxhNol4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=i7E/vgRQmVd/bKXqNR3o8NqbIdk/AwepLw/VpLimtoC+S9BTdcZLsgk0OnU9Pn9X9D9atTrgRno1VDiWrGrgoShACmCfhDo25KtKm8gjsenCTx37pxMuDZ6+PzgfcdZFCurFa52iA3Zo+VZ/cdan4jZx5ITuYNm5c7JJtS638y8= Received: by 10.114.149.2 with SMTP id w2mr6390395wad.1192412770849; Sun, 14 Oct 2007 18:46:10 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id l36sm6965859waf.2007.10.14.18.46.06 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 14 Oct 2007 18:46:09 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l9F1gRU5075775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Oct 2007 10:42:27 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l9F1gRpV075774; Mon, 15 Oct 2007 10:42:27 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 15 Oct 2007 10:42:27 +0900 From: Pyun YongHyeon To: Abdullah Ibn Hamad Al-Marri Message-ID: <20071015014227.GC75267@cdnetworks.co.kr> References: <499c70c0710091846p3e2dd505sb54f18da30802d2d@mail.gmail.com> <20071010033122.GB54946@cdnetworks.co.kr> <499c70c0710100708g30a2912n1d1e72703d099dd0@mail.gmail.com> <20071011004814.GB58828@cdnetworks.co.kr> <499c70c0710140524n5ade2c39r4ff61dfa5ce9a47@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <499c70c0710140524n5ade2c39r4ff61dfa5ce9a47@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Stable List , Pyun YongHyeon Subject: Re: Realtek eth isn't detected in Intel DG31PR mobo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 01:46:16 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Oct 14, 2007 at 03:24:33PM +0300, Abdullah Ibn Hamad Al-Marri wrote: [...] > Pyrun, > > I hope you are doing well. > > Thank you for the patch, and your good attempt to help with this issue. > > I spent 2 hours with the patch it did detect the Ethernet as re0 but the > network did not work at all even though it said connected at auto 100 mbps > full duplex. The server sent out a packet storm of arp traffic or some kind > of traffic which caused a lot of problems in my overall network. I'm not > exactly sure what happened but maybe you know about it. So I removed the > patch and used the rl0 driver from Realtek again. > > It's very strange I didn't see anything like it before. > Sorry, please try again with attached patch. I guess I've misprogrammed Rx filter. -- Regards, Pyun YongHyeon --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="re.patch2" Index: sys/dev/re/if_re.c =================================================================== RCS file: /home/ncvs/src/sys/dev/re/if_re.c,v retrieving revision 1.95 diff -u -r1.95 if_re.c --- sys/dev/re/if_re.c 14 Aug 2007 02:00:04 -0000 1.95 +++ sys/dev/re/if_re.c 15 Oct 2007 01:43:20 -0000 @@ -180,6 +180,8 @@ "RealTek 8168/8111B PCIe Gigabit Ethernet" }, { RT_VENDORID, RT_DEVICEID_8168, RL_HWREV_8168_SPIN2, "RealTek 8168/8111B PCIe Gigabit Ethernet" }, + { RT_VENDORID, RT_DEVICEID_8168, RL_HWREV_8168_SPIN3, + "RealTek 8168/8111B PCIe Gigabit Ethernet" }, { RT_VENDORID, RT_DEVICEID_8169, RL_HWREV_8169, "RealTek 8169 Gigabit Ethernet" }, { RT_VENDORID, RT_DEVICEID_8169, RL_HWREV_8169S, @@ -221,6 +223,7 @@ { RL_HWREV_8100E, RL_8169, "8100E"}, { RL_HWREV_8101E, RL_8169, "8101E"}, { RL_HWREV_8168_SPIN2, RL_8169, "8168"}, + { RL_HWREV_8168_SPIN3, RL_8169, "8168"}, { 0, 0, NULL } }; @@ -676,14 +679,18 @@ */ hwrev = CSR_READ_4(sc, RL_TXCFG) & RL_TXCFG_HWREV; - - if (hwrev == RL_HWREV_8100E || hwrev == RL_HWREV_8101E || - hwrev == RL_HWREV_8168_SPIN1 || hwrev == RL_HWREV_8168_SPIN2) { + switch (hwrev) { + case RL_HWREV_8100E: + case RL_HWREV_8101E: + case RL_HWREV_8168_SPIN1: + case RL_HWREV_8168_SPIN2: CSR_WRITE_4(sc, RL_MAR0, bswap32(hashes[1])); CSR_WRITE_4(sc, RL_MAR4, bswap32(hashes[0])); - } else { + break; + default: CSR_WRITE_4(sc, RL_MAR0, hashes[0]); CSR_WRITE_4(sc, RL_MAR4, hashes[1]); + break; } } @@ -1314,6 +1321,7 @@ case RL_HWREV_8169_8110SB: case RL_HWREV_8169_8110SC: case RL_HWREV_8168_SPIN2: + case RL_HWREV_8168_SPIN3: re_gmii_writereg(dev, 1, 0x1f, 0); re_gmii_writereg(dev, 1, 0x0e, 0); break; Index: sys/pci/if_rl.c =================================================================== RCS file: /home/ncvs/src/sys/pci/if_rl.c,v retrieving revision 1.170 diff -u -r1.170 if_rl.c --- sys/pci/if_rl.c 24 Jul 2007 01:24:03 -0000 1.170 +++ sys/pci/if_rl.c 15 Oct 2007 01:43:20 -0000 @@ -756,14 +756,31 @@ hwrev = CSR_READ_4(sc, RL_TXCFG) & RL_TXCFG_HWREV; bus_release_resource(dev, RL_RES, RL_RID, sc->rl_res); - /* Don't attach to 8139C+ or 8169/8110 chips. */ - if (hwrev == RL_HWREV_8139CPLUS || - (hwrev == RL_HWREV_8169 && - t->rl_did == RT_DEVICEID_8169) || - hwrev == RL_HWREV_8169S || - hwrev == RL_HWREV_8110S) { + /* + * Don't attach to 8139C+/8169/8169S/8110S/8168 + * 8111/8101E chips. + */ + switch (hwrev) { + case RL_HWREV_8139CPLUS: + case RL_HWREV_8110S: + case RL_HWREV_8169S: + case RL_HWREV_8101: + case RL_HWREV_8100: + case RL_HWREV_8169_8110SB: + case RL_HWREV_8169_8110SC: + case RL_HWREV_8168_SPIN1: + case RL_HWREV_8100E: + case RL_HWREV_8101E: + case RL_HWREV_8168_SPIN2: + case RL_HWREV_8168_SPIN3: t++; continue; + case RL_HWREV_8169: + if (t->rl_did == RT_DEVICEID_8169) { + t++; + continue; + } + break; } device_set_desc(dev, t->rl_name); Index: sys/pci/if_rlreg.h =================================================================== RCS file: /home/ncvs/src/sys/pci/if_rlreg.h,v retrieving revision 1.67 diff -u -r1.67 if_rlreg.h --- sys/pci/if_rlreg.h 24 Jul 2007 01:24:03 -0000 1.67 +++ sys/pci/if_rlreg.h 15 Oct 2007 01:43:20 -0000 @@ -156,6 +156,7 @@ #define RL_HWREV_8100E 0x30800000 #define RL_HWREV_8101E 0x34000000 #define RL_HWREV_8168_SPIN2 0x38000000 +#define RL_HWREV_8168_SPIN3 0x38400000 #define RL_HWREV_8139 0x60000000 #define RL_HWREV_8139A 0x70000000 #define RL_HWREV_8139AG 0x70800000 --qDbXVdCdHGoSgWSk-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 08:21:06 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6461616A46B; Mon, 15 Oct 2007 08:21:06 +0000 (UTC) (envelope-from d_elbracht@ecngs.de) Received: from ecngs.de (mail.ecngs.de [217.73.144.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7547B13C447; Mon, 15 Oct 2007 08:21:04 +0000 (UTC) (envelope-from d_elbracht@ecngs.de) Received: from EC1a (ec1.elbracht.net [217.73.144.99]) by ecngs.de (SurgeMail 3.8f2) with ESMTP id 1774348-1922481 for multiple; Mon, 15 Oct 2007 10:21:26 +0200 From: "d_elbracht" To: "'Ivan Voras'" , References: <008801c80e65$47cbe650$639049d9@EC1a> Date: Mon, 15 Oct 2007 10:20:57 +0200 Message-ID: <00cb01c80f04$50b11ed0$639049d9@EC1a> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgOsevpOahtmKUeQKG7YhTDqm4A3wATlmcA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Cc: freebsd-geom@freebsd.org Subject: AW: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 08:21:06 -0000 > > we are trying to diagnose errors seen on 6.2, SMP, amd64, > cvsup'ed of > > 2007-10-09 > > > > Mainboard is a Tyan Thunder h2000M (S3992-E) with 16 GB RAM and 2 x > > Opteron 2216, da3 is on a 3ware 9550-12 > > > > we are seeing this error: > > g_vfs_done():da3s1a[READ(offset=81064794762854400, > length=8192)]error > > = 5 on a 12 GB Hyperdrive > > > > the offset changes sometimes, but it is always > 81064794xxxxxxxxx and > > well out the 12GB range. > > Yes. > > > According to systat -vm, da3 does tps > 500 (yes, that's a lot) > > That's not a lot :) That's actually low for a modern solid > state drive. > > > This leads to an assumption, the error has to do with very high IOs > > per second on a SMP machine. > > Either that or file system errors. Does fsck run ok or does > it say anything unusual? > > There are several theoretical reasons for such errors that > are connected with the fact you use solid state drives, but > all are tricky to diagnose if you don't have a certain > repeatable test you can try. For example: > some SSDs optimize writes to "spread out" the IO on the > chips, but some do it by looking into file system structures > to determine where it's safe to relocate the write - > obviously this works only with a known and supported file > system. This is a really wild guess, but maybe the SSD > firmware has error somewhere in this area, trying to > interpret UFS as it was FAT? If you manage to get a > repeatable failure test, you can try formatting the drive as > FAT32 and trying it on that. > > Or maybe it's just a bad drive... > > > The system-disk is a RAID1 on an ICP 5805. All other disks > (51) are 20 > > gstripe'd partitions. > > 51 drives and 20 partitions? > According to the manufaturer, the drive handles any filesystem. In other words, it's as transparent as any harddisk would be. Also, as written before, we have seen the error=5 with weird offsets on an md (memory disk) before too. fsck on the disk does NOT show any error. yes, 20 partitions on the other 51 disks (/dev/stripe/data ..datann). That's for hashfeed from diablo. One basic question to ask: where does the value for offset= in g_vfs_done() come from ? >From the time the error shows up in syslog I believe, the error only happens, when a file get's appended. Dieter From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 09:14:36 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3C4D16A419; Mon, 15 Oct 2007 09:14:36 +0000 (UTC) (envelope-from d_elbracht@ecngs.de) Received: from ecngs.de (mail.ecngs.de [217.73.144.50]) by mx1.freebsd.org (Postfix) with ESMTP id E604213C478; Mon, 15 Oct 2007 09:14:35 +0000 (UTC) (envelope-from d_elbracht@ecngs.de) Received: from EC1a (ec1.elbracht.net [217.73.144.99]) by ecngs.de (SurgeMail 3.8f2) with ESMTP id 1774497-1922481 for multiple; Mon, 15 Oct 2007 11:14:57 +0200 From: "d_elbracht" To: "'Ivan Voras'" References: <008801c80e65$47cbe650$639049d9@EC1a> <00cb01c80f04$50b11ed0$639049d9@EC1a> <9bbcef730710150205o7c344432kc8bc828da64bff1f@mail.gmail.com> Date: Mon, 15 Oct 2007 11:14:29 +0200 Message-ID: <00cc01c80f0b$cafa7e50$639049d9@EC1a> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgPCq+WuEiplNxCQ/aZVM3L84OMoQAANokw In-Reply-To: <9bbcef730710150205o7c344432kc8bc828da64bff1f@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Cc: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: AW: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 09:14:36 -0000 > > One basic question to ask: where does the value for offset= in > > g_vfs_done() come from ? > > Either from the file system or from bugs in the code. I don't > remember seeing similar reports before so the probability of > there being bugs in the code is fairly small. > > This is all on raw hardware, not vmware, right? > > > From the time the error shows up in syslog I believe, the > error only > > happens, when a file get's appended. Here is a similar one: http://www.nabble.com/g_vfs_done():mfid1-ERROR-when-writing-to-18TB-MFI-RAID -volume-t4590438.html it's all raw hardware, no vmware Dieter From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 09:32:33 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 748CC16A419 for ; Mon, 15 Oct 2007 09:32:33 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.236]) by mx1.freebsd.org (Postfix) with ESMTP id 3163C13C447 for ; Mon, 15 Oct 2007 09:32:33 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so803111nzf for ; Mon, 15 Oct 2007 02:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=WIClknsSnPfxISdvAzWuHmvEhZq1qoSb1UyLu/2nYo8=; b=XM8x7V1ck80TXgwvNPkcQy4OazVx8cqK8TN4IG+JN9WPYxAlwYcG/SyqUjeQVbSe6Rxze01iY8LCa4tAI4Dt+5mE6XM+GhF01S7HPJiMcHLnmT63Gg1yFcsT5s6ftfB0asn9UQh7S/0ChfPCFNJJrG1zhjSUUsO3rYKLEM86BqM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=oZzwQI0cTs+xE8G+rM1iG2sudtZzb//PZAKxHg10kbytWT7rfOCg/HL7u1192PFP5bSWNyWhNF2hXuHhxYwQwM7+vpT4jKy8o+c+PMQZbMWdiilCVXoHBH+EYabLKTQ/UeRpp3d8Zjun6SnhSG8NoGJzLXRxXnPR9NMy/rLMRBU= Received: by 10.141.15.19 with SMTP id s19mr2574331rvi.1192439154081; Mon, 15 Oct 2007 02:05:54 -0700 (PDT) Received: by 10.141.211.5 with HTTP; Mon, 15 Oct 2007 02:05:54 -0700 (PDT) Message-ID: <9bbcef730710150205o7c344432kc8bc828da64bff1f@mail.gmail.com> Date: Mon, 15 Oct 2007 11:05:54 +0200 From: "Ivan Voras" Sender: ivoras@gmail.com To: d_elbracht In-Reply-To: <00cb01c80f04$50b11ed0$639049d9@EC1a> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <008801c80e65$47cbe650$639049d9@EC1a> <00cb01c80f04$50b11ed0$639049d9@EC1a> X-Google-Sender-Auth: 11c2e076073077f8 Cc: freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: Re: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 09:32:33 -0000 On 15/10/2007, d_elbracht wrote: > One basic question to ask: where does the value for offset= in g_vfs_done() > come from ? Either from the file system or from bugs in the code. I don't remember seeing similar reports before so the probability of there being bugs in the code is fairly small. This is all on raw hardware, not vmware, right? > From the time the error shows up in syslog I believe, the error only > happens, when a file get's appended. From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 13:36:59 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5088F16A419 for ; Mon, 15 Oct 2007 13:36:59 +0000 (UTC) (envelope-from indrajith@adm.sltidc.lk) Received: from adm.sltidc.lk (mail.adm.sltidc.lk [203.94.73.65]) by mx1.freebsd.org (Postfix) with ESMTP id 958BE13C461 for ; Mon, 15 Oct 2007 13:36:57 +0000 (UTC) (envelope-from indrajith@adm.sltidc.lk) Received: from [192.168.1.2] (account indrajith@adm.sltidc.lk) by adm.sltidc.lk (CommuniGate Pro WEBUSER 5.1.12) with HTTP id 931577 for freebsd-stable@freebsd.org; Mon, 15 Oct 2007 18:09:02 +0530 From: "Chaminda Indrajith" To: freebsd-stable@freebsd.org X-Mailer: CommuniGate Pro WebUser v5.1.12 Date: Mon, 15 Oct 2007 18:09:02 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8;format="flowed" Content-Transfer-Encoding: 8bit Subject: Disk Quota Support for FreeBSD Kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 13:36:59 -0000 Dear All, I am new to FreeBSD and I need a help from you all please.. I have installed FreeBSD 6.2-RELEASE and did Binary Security Update from freebsd-update. Then I have tried to rebuild the kernel with Disk Quota support, but kernel source was not available in my new server. I gave a try with sysinstall, but it failed and the following error message was appeared. Warning: Can't find the `6.2-RELEASE-p4' distribution on this FTP server. You may need to visit a different server for the release you are trying to fetch or go to the Options menu and to set the release name to explicitly match what's available on ftp.freebsd.org (or set to "any"). Please help me to install kernel source and rebuild kernel. Regards Chaminda Indrajith From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 13:49:33 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1962916A420 for ; Mon, 15 Oct 2007 13:49:33 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from atl04.ws-e.com (vh00.ws-e.com [69.61.31.90]) by mx1.freebsd.org (Postfix) with ESMTP id C617D13C505 for ; Mon, 15 Oct 2007 13:49:32 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from lilburn.lefebvre.org (ocee.groupsys.com [66.149.10.161]) by atl04.ws-e.com (8.13.8/8.13.8) with ESMTP id l9FDFd91009329 for ; Mon, 15 Oct 2007 09:15:39 -0400 (EDT) (envelope-from bill@lefebvre.org) Received: from [10.88.88.6] (milton.lefebvre.org [10.88.88.6]) by lilburn.lefebvre.org (8.13.8/8.13.8) with ESMTP id l9FDFbHs057015 for ; Mon, 15 Oct 2007 09:15:37 -0400 (EDT) (envelope-from bill@lefebvre.org) Message-ID: <471367F2.7050303@lefebvre.org> Date: Mon, 15 Oct 2007 09:15:30 -0400 From: William LeFebvre User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <008801c80e66$7be49490$0c00a8c0@Artem> In-Reply-To: <008801c80e66$7be49490$0c00a8c0@Artem> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=4.0 tests=ALL_TRUSTED autolearn=failed version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on lilburn.lefebvre.org X-Scanned-By: MIMEDefang 2.57 on 192.168.0.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (atl04.ws-e.com [69.61.31.90]); Mon, 15 Oct 2007 09:15:40 -0400 (EDT) Subject: Re: Question about 'top' values on memory usage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 13:49:33 -0000 Artem Kuchin wrote: > Hello! > > Maybe someone with deeper knowledge of the internals of FreeBSD > can clean up something for me (any for many others)^ > > Here are lines from my top: > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 9258 hordelo_ru 1 4 0 40992K 4260K accept 0 0:00 0.00% httpd > 9257 hordelo_ru 1 44 0 40992K 4296K select 1 0:00 0.00% httpd > 9259 hordelo_ru 1 4 0 40992K 4292K select 1 0:00 0.00% httpd > > As you see, 'size' is the same for all processes, while RES varies. > > As i understand, the real memory taken by a process is RES and SIZE include > a bunch of shares .so libs, so, if more httpd's started each will take > only about 4300K more, so, 100 https will take 430000K to run, right? > > Another question is that is httpd uses threads (as provided by FreeBSD) > starting a new thread will or will not copy executable copy and data? > Basically, > will a new thread eat another 4300K or just a little bit for its data? > SIZE is the total amount of virtual memory that a process has allocated. This includes text, data, and stack. It also includes all the stuff that's shared with other processes (mostly through the use of shared libraries). RES is the amount of physical memory in use by the process and will only include that part of a process's virtual memory space which is currently allocated in physical memory. Unfortunately, freebsd does not appear to track the amount of shared virtual memory for each process. It could be obtained by walking through all the pages in a process's vm map, but that would really slow top down. I don't know of any freebsd utility that would give that information for an individual process. But hey, if it's out there somewhere where it is easy to grab, I would be very happy to add it to top. > All this i need to calculate maximum possible number of https i can run > on a box > with certain amount of memory and select proper MPM for Apache. > Somehow, i could not find any practical info on this regarding FreeBSD. That's because the answer isn't as straightforward as you want it to be. There are actually two things you need to worry about: swap space and physical memory. The amount of swap space will place a hard upper bound on the number of httpd processes you can run before sbrk (and thus malloc) start failing. In order to determine that amount you are going to have to see how much extra swap is gobbled up by each new process. But in actuality that swap is only taken when needed, and if a data page remains untouched by the process then it won't need to allocate swap (backing store) for that page. At least that's my limited understanding of how the freebsd VM model works. But I would argue that long before you hit that hard upper limit you will hit a much more serious practical limit in just how much physical memory is adequate for the environment. And that doesn't really limit the number of processes, rather it limits how many of them can be active at a given time. You're not just going to be able to sit down and plug numbers in to a formula and say "voila!". You will have to observe how httpd performs in your particular environment to see how many page faults per second it generates and decide for yourself the point at which X pf/s is too much. Personally, based on my experience, I would be more concerned with the amount of available cpu cycles than memory. In my experience, once you run out of idle time on a web server you have exceeded its capacity to serve pages. In that situation it doesn't matter how many httpd processes there are, the system is still not able to keep up with demand. And that will probably happen before the system starts thrashing from limited memory. Bill LeFebvre From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 14:17:23 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F217916A41B; Mon, 15 Oct 2007 14:17:23 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id 4C76513C46B; Mon, 15 Oct 2007 14:17:23 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id D7830B096; Mon, 15 Oct 2007 18:17:21 +0400 (MSD) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id B28ADB089; Mon, 15 Oct 2007 18:17:21 +0400 (MSD) Date: Mon, 15 Oct 2007 18:17:14 +0400 From: Igor Sysoev To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Message-ID: <20071015141714.GL24828@rambler-co.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: Subject: 2G+ sysv shm segments X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 14:17:24 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Two years ago Christian S.J. Peron had increased total number of SysV shm pages on 64-bit platform, that allows to create many shm segments more than 2G in sum. However, the patch does not allow to create a single large segment more than 2G. The attached patches against 6.x and 7.x allow to create 2G+ segments. I know that stock 6.x will not have this feature because of compatibility, but I send 6.x patch too because someone may want to use 2G+ shm on 6.x. To install: patch -d < /usr < big_sysvshmX.txt [ rebuild kernel ] cd /usr/src/include/ make obj make make install cd /usr/src/usr.bin/ipcs/ make obj make make install -- Igor Sysoev http://sysoev.ru/en/ --AqsLC8rIMeq19msA Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="big_sysvshm6.txt" --- src/sys/sys/shm.h 2007-09-12 23:33:39.000000000 +0400 +++ src/sys/sys/shm.h 2007-10-15 17:42:38.000000000 +0400 @@ -77,7 +77,7 @@ struct shmid_ds { struct ipc_perm shm_perm; /* operation permission structure */ - int shm_segsz; /* size of segment in bytes */ + size_t shm_segsz; /* size of segment in bytes */ pid_t shm_lpid; /* process ID of last shared memory op */ pid_t shm_cpid; /* process ID of creator */ short shm_nattch; /* number of current attaches */ @@ -94,11 +94,11 @@ * might be of interest to user programs. Do we really want/need this? */ struct shminfo { - int shmmax, /* max shared memory segment size (bytes) */ - shmmin, /* min shared memory segment size (bytes) */ - shmmni, /* max number of shared memory identifiers */ - shmseg, /* max shared memory segments per process */ - shmall; /* max amount of shared memory (pages) */ + u_long shmmax; /* max shared memory segment size (bytes) */ + u_long shmmin; /* max shared memory segment size (bytes) */ + u_long shmmni; /* max number of shared memory identifiers */ + u_long shmseg; /* max shared memory segments per process */ + u_long shmall; /* max amount of shared memory (pages) */ }; /* --- src/sys/kern/sysv_shm.c 2007-09-12 23:33:19.000000000 +0400 +++ src/sys/kern/sysv_shm.c 2007-10-15 17:16:54.000000000 +0400 @@ -181,15 +181,15 @@ static int shm_allow_removed; SYSCTL_DECL(_kern_ipc); -SYSCTL_INT(_kern_ipc, OID_AUTO, shmmax, CTLFLAG_RW, &shminfo.shmmax, 0, +SYSCTL_ULONG(_kern_ipc, OID_AUTO, shmmax, CTLFLAG_RW, &shminfo.shmmax, 0, "Maximum shared memory segment size"); -SYSCTL_INT(_kern_ipc, OID_AUTO, shmmin, CTLFLAG_RW, &shminfo.shmmin, 0, +SYSCTL_ULONG(_kern_ipc, OID_AUTO, shmmin, CTLFLAG_RW, &shminfo.shmmin, 0, "Minimum shared memory segment size"); -SYSCTL_INT(_kern_ipc, OID_AUTO, shmmni, CTLFLAG_RDTUN, &shminfo.shmmni, 0, +SYSCTL_ULONG(_kern_ipc, OID_AUTO, shmmni, CTLFLAG_RDTUN, &shminfo.shmmni, 0, "Number of shared memory identifiers"); -SYSCTL_INT(_kern_ipc, OID_AUTO, shmseg, CTLFLAG_RDTUN, &shminfo.shmseg, 0, +SYSCTL_ULONG(_kern_ipc, OID_AUTO, shmseg, CTLFLAG_RDTUN, &shminfo.shmseg, 0, "Number of segments per process"); -SYSCTL_INT(_kern_ipc, OID_AUTO, shmall, CTLFLAG_RW, &shminfo.shmall, 0, +SYSCTL_ULONG(_kern_ipc, OID_AUTO, shmall, CTLFLAG_RW, &shminfo.shmall, 0, "Maximum number of pages available for shared memory"); SYSCTL_INT(_kern_ipc, OID_AUTO, shm_use_phys, CTLFLAG_RW, &shm_use_phys, 0, "Enable/Disable locking of shared memory pages in core"); @@ -754,7 +754,8 @@ struct shmget_args *uap; int mode; { - int i, segnum, shmid, size; + int i, segnum, shmid; + size_t size; struct ucred *cred = td->td_ucred; struct shmid_kernel *shmseg; vm_object_t shm_object; @@ -967,15 +968,15 @@ { int i; - TUNABLE_INT_FETCH("kern.ipc.shmmaxpgs", &shminfo.shmall); + TUNABLE_ULONG_FETCH("kern.ipc.shmmaxpgs", &shminfo.shmall); for (i = PAGE_SIZE; i > 0; i--) { shminfo.shmmax = shminfo.shmall * i; if (shminfo.shmmax >= shminfo.shmall) break; } - TUNABLE_INT_FETCH("kern.ipc.shmmin", &shminfo.shmmin); - TUNABLE_INT_FETCH("kern.ipc.shmmni", &shminfo.shmmni); - TUNABLE_INT_FETCH("kern.ipc.shmseg", &shminfo.shmseg); + TUNABLE_ULONG_FETCH("kern.ipc.shmmin", &shminfo.shmmin); + TUNABLE_ULONG_FETCH("kern.ipc.shmmni", &shminfo.shmmni); + TUNABLE_ULONG_FETCH("kern.ipc.shmseg", &shminfo.shmseg); TUNABLE_INT_FETCH("kern.ipc.shm_use_phys", &shm_use_phys); shmalloced = shminfo.shmmni; --- src/usr.bin/ipcs/ipcs.c 2007-09-12 23:32:25.000000000 +0400 +++ src/usr.bin/ipcs/ipcs.c 2007-10-15 17:29:06.000000000 +0400 @@ -93,11 +93,11 @@ }; #define SHMINFO_XVEC \ -X(shmmax, sizeof(int)) \ -X(shmmin, sizeof(int)) \ -X(shmmni, sizeof(int)) \ -X(shmseg, sizeof(int)) \ -X(shmall, sizeof(int)) +X(shmmax, sizeof(u_long)) \ +X(shmmin, sizeof(u_long)) \ +X(shmmni, sizeof(u_long)) \ +X(shmseg, sizeof(u_long)) \ +X(shmall, sizeof(u_long)) #define SEMINFO_XVEC \ X(semmap, sizeof(int)) \ @@ -376,15 +376,15 @@ if ((display & (SHMINFO | SHMTOTAL))) { if (display & SHMTOTAL) { printf("shminfo:\n"); - printf("\tshmmax: %12d\t(max shared memory segment size)\n", + printf("\tshmmax: %12ld\t(max shared memory segment size)\n", shminfo.shmmax); - printf("\tshmmin: %12d\t(min shared memory segment size)\n", + printf("\tshmmin: %12ld\t(min shared memory segment size)\n", shminfo.shmmin); - printf("\tshmmni: %12d\t(max number of shared memory identifiers)\n", + printf("\tshmmni: %12ld\t(max number of shared memory identifiers)\n", shminfo.shmmni); - printf("\tshmseg: %12d\t(max shared memory segments per process)\n", + printf("\tshmseg: %12ld\t(max shared memory segments per process)\n", shminfo.shmseg); - printf("\tshmall: %12d\t(max amount of shared memory in pages)\n\n", + printf("\tshmall: %12ld\t(max amount of shared memory in pages)\n\n", shminfo.shmall); } if (display & SHMINFO) { @@ -439,7 +439,7 @@ kshmptr->u.shm_nattch); if (option & BIGGEST) - printf(" %12d", + printf(" %12ld", kshmptr->u.shm_segsz); if (option & PID) --AqsLC8rIMeq19msA Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="big_sysvshm7.txt" --- src/sys/sys/shm.h 2007-09-12 23:33:39.000000000 +0400 +++ src/sys/sys/shm.h 2007-10-15 17:42:38.000000000 +0400 @@ -77,7 +77,7 @@ struct shmid_ds { struct ipc_perm shm_perm; /* operation permission structure */ - int shm_segsz; /* size of segment in bytes */ + size_t shm_segsz; /* size of segment in bytes */ pid_t shm_lpid; /* process ID of last shared memory op */ pid_t shm_cpid; /* process ID of creator */ short shm_nattch; /* number of current attaches */ --- src/sys/kern/sysv_shm.c 2007-09-12 23:33:19.000000000 +0400 +++ src/sys/kern/sysv_shm.c 2007-10-15 17:16:54.000000000 +0400 @@ -717,7 +717,8 @@ struct shmget_args *uap; int mode; { - int i, segnum, shmid, size; + int i, segnum, shmid; + size_t size; struct ucred *cred = td->td_ucred; struct shmid_kernel *shmseg; vm_object_t shm_object; --- src/usr.bin/ipcs/ipcs.c 2007-09-12 23:32:25.000000000 +0400 +++ src/usr.bin/ipcs/ipcs.c 2007-10-15 17:29:06.000000000 +0400 @@ -376,15 +376,15 @@ if ((display & (SHMINFO | SHMTOTAL))) { if (display & SHMTOTAL) { printf("shminfo:\n"); - printf("\tshmmax: %12d\t(max shared memory segment size)\n", + printf("\tshmmax: %12ld\t(max shared memory segment size)\n", shminfo.shmmax); - printf("\tshmmin: %12d\t(min shared memory segment size)\n", + printf("\tshmmin: %12ld\t(min shared memory segment size)\n", shminfo.shmmin); - printf("\tshmmni: %12d\t(max number of shared memory identifiers)\n", + printf("\tshmmni: %12ld\t(max number of shared memory identifiers)\n", shminfo.shmmni); - printf("\tshmseg: %12d\t(max shared memory segments per process)\n", + printf("\tshmseg: %12ld\t(max shared memory segments per process)\n", shminfo.shmseg); - printf("\tshmall: %12d\t(max amount of shared memory in pages)\n\n", + printf("\tshmall: %12ld\t(max amount of shared memory in pages)\n\n", shminfo.shmall); } if (display & SHMINFO) { @@ -439,7 +439,7 @@ kshmptr->u.shm_nattch); if (option & BIGGEST) - printf(" %12d", + printf(" %12ld", kshmptr->u.shm_segsz); if (option & PID) --AqsLC8rIMeq19msA-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 14:30:01 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 504C016A46D for ; Mon, 15 Oct 2007 14:30:01 +0000 (UTC) (envelope-from buki@dev.null.cz) Received: from dev.null.cz (null-gts.ptp-v6.cz.net [IPv6:2001:af0::1:0:d]) by mx1.freebsd.org (Postfix) with ESMTP id B9AEB13C48E for ; Mon, 15 Oct 2007 14:30:00 +0000 (UTC) (envelope-from buki@dev.null.cz) Received: from dev.null.cz (localhost [127.0.0.1]) by dev.null.cz (8.13.1/8.13.1) with ESMTP id l9FETrmm059308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 15 Oct 2007 16:29:58 +0200 (CEST) (envelope-from buki@dev.null.cz) Received: (from buki@localhost) by dev.null.cz (8.13.1/8.13.1/Submit) id l9FETrCE059305 for freebsd-stable@freebsd.org; Mon, 15 Oct 2007 16:29:53 +0200 (CEST) (envelope-from buki) Date: Mon, 15 Oct 2007 16:29:53 +0200 From: Buki To: freebsd-stable@freebsd.org Message-ID: <20071015142953.GH70220@dev.null.cz> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7uYPyRQQ5N0D02nI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on dev.null.cz X-Virus-Status: Clean Subject: Re: Disk Quota Support for FreeBSD Kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 14:30:01 -0000 --7uYPyRQQ5N0D02nI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 15, 2007 at 06:09:02PM +0530, Chaminda Indrajith wrote: >=20 > Dear All, Hi, > I am new to FreeBSD and I need a help from you all please.. >=20 > I have installed FreeBSD 6.2-RELEASE and did Binary Security Update=20 > from freebsd-update. >=20 > Then I have tried to rebuild the kernel with Disk Quota support, but=20 > kernel source was not available in my new server. I gave a try with=20 > sysinstall, but it failed and the following error message was=20 > appeared. >=20 > Warning: Can't find the `6.2-RELEASE-p4' distribution on this FTP=20 > server. You may need to visit a different server for the release you=20 > are trying to fetch or go to the Options menu and to set the release=20 > name to explicitly match what's available on ftp.freebsd.org (or set=20 > to "any"). >=20 > Please help me to install kernel source and rebuild kernel. You may want to read the FreeBSD Handbook, especially the part about building custom kernel: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html Also, you may want to ask such questions in -question from now on. :-) > Regards > Chaminda Indrajith > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Regards, Buki --=20 PGP public key: http://dev.null.cz/buki.asc /"\ \ / ASCII Ribbon Campaign X Against HTML & Outlook Mail / \ http://www.thebackrow.net --7uYPyRQQ5N0D02nI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHE3lhPzhIkpLLm08RAue5AJ0di7d4v+GXEzbv9ldglIwCIdqVXwCdHkfV OQc17Fs8ldP4LG5ixl5mfzg= =7V/9 -----END PGP SIGNATURE----- --7uYPyRQQ5N0D02nI-- From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 15:09:49 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C4E116A419 for ; Mon, 15 Oct 2007 15:09:49 +0000 (UTC) (envelope-from matrix@itlegion.ru) Received: from corpmail.itlegion.ru (corpmail.itlegion.ru [84.21.226.211]) by mx1.freebsd.org (Postfix) with SMTP id E650E13C468 for ; Mon, 15 Oct 2007 15:09:46 +0000 (UTC) (envelope-from matrix@itlegion.ru) Received: (qmail 12481 invoked from network); 15 Oct 2007 19:09:43 +0400 Received: from unknown (HELO Artem) (192.168.0.12) by 84.21.226.211 with SMTP; 15 Oct 2007 19:09:43 +0400 X-AntiVirus: Checked by Dr.Web [version: 4.44, engine: 4.44.0.09170, virus records: 249595, updated: 15.10.2007] Message-ID: <037501c80f3d$69120730$0c00a8c0@Artem> From: "Artem Kuchin" To: "William LeFebvre" , References: <008801c80e66$7be49490$0c00a8c0@Artem> <471367F2.7050303@lefebvre.org> Date: Mon, 15 Oct 2007 19:09:35 +0400 Organization: IT Legion MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: Subject: Re: Question about 'top' values on memory usage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 15:09:49 -0000 William LeFebvre wrote: > Artem Kuchin wrote: >> Hello! >> >> Maybe someone with deeper knowledge of the internals of FreeBSD >> can clean up something for me (any for many others)^ >> >> Here are lines from my top: >> >> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >> COMMAND 9258 hordelo_ru 1 4 0 40992K 4260K accept 0 0:00 >> 0.00% httpd 9257 hordelo_ru 1 44 0 40992K 4296K select 1 >> 0:00 0.00% httpd 9259 hordelo_ru 1 4 0 40992K 4292K select >> 1 0:00 0.00% httpd >> >> As you see, 'size' is the same for all processes, while RES varies. >> >> As i understand, the real memory taken by a process is RES and SIZE >> include a bunch of shares .so libs, so, if more httpd's started each >> will take only about 4300K more, so, 100 https will take 430000K to >> run, right? >> >> Another question is that is httpd uses threads (as provided by >> FreeBSD) starting a new thread will or will not copy executable copy >> and data? Basically, >> will a new thread eat another 4300K or just a little bit for its >> data? >> > > > SIZE is the total amount of virtual memory that a process has > allocated. This includes text, data, and stack. It also includes > all the stuff that's shared with other processes (mostly through the > use of shared libraries). > > RES is the amount of physical memory in use by the process and will > only include that part of a process's virtual memory space which is > currently allocated in physical memory. > > Unfortunately, freebsd does not appear to track the amount of shared > virtual memory for each process. It could be obtained by walking > through all the pages in a process's vm map, but that would really > slow top down. I don't know of any freebsd utility that would give > that information for an individual process. But hey, if it's out > there somewhere where it is easy to grab, I would be very happy to > add it to top. My knowledge of VM system of FReebSD is so low, that even though i can write in C i don't know where to start here. I haven't found anything ready for this. make search in port on 'memory' and 'ram' does not return much. >> All this i need to calculate maximum possible number of https i can >> run on a box >> with certain amount of memory and select proper MPM for Apache. >> Somehow, i could not find any practical info on this regarding >> FreeBSD. > > > limits how many of them can be active at a given time. You're not > just going to be able to sit down and plug numbers in to a formula > and say "voila!". You will have to observe how httpd performs in your > particular environment to see how many page faults per second it > generates and decide for yourself the point at which X pf/s is too > much. Of course, but i need to start with something instead of just pure guess out of the blue. > Personally, based on my experience, I would be more concerned with the > amount of available cpu cycles than memory. CPU is more than just enough in my case. There will a a lot https sitting there but load, i am sure, will be low. Swapping is simply unacceptable, so i am counting only real physical ram. However, noone mentioned anything about threads. DO they give any memory advantage on freebsd? -- Regards, Artem From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 15:47:05 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2524416A418; Mon, 15 Oct 2007 15:47:05 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id 3A2B013C45D; Mon, 15 Oct 2007 15:47:02 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 194160120; Mon, 15 Oct 2007 18:47:05 +0400 Message-ID: <47137D36.1020305@chistydom.ru> Date: Mon, 15 Oct 2007 18:46:14 +0400 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 15:47:05 -0000 Hi. I have 3 Dell 2850 with DELL PERC4 SCSI RAID5 6x300GB running lighttpd serving flash video at around 200Mbit/s. %grep amr /var/run/dmesg.boot amr0: mem 0xf80f0000-0xf80fffff,0xfe9c0000-0xfe9fffff irq 46 at device 14.0 on pci2 amr0: Using 64-bit DMA amr0: delete logical drives supported by controller amr0: Firmware 521X, BIOS H430, 256MB RAM amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 1430400MB (2929459200 sectors) RAID 5 (optimal) Trying to mount root from ufs:/dev/amrd0s1a %uname -a FreeBSD ???.ru 6.2-STABLE FreeBSD 6.2-STABLE #2: Mon Oct 8 16:25:20 MSD 2007 llp@???.ru:/usr/obj/usr/src/sys/SMP-amd64-HWPMC amd64 % After some time of running under high load disk performance become expremely poor. At that periods 'systat -vm 1' shows something like this: Disks amrd0 KB/t 85.39 tps 5 MB/s 0.38 % busy 99 It shows 100% load and just 2-10 tps. There's nothing bad in /var/log/messages or 'netstat -m' or 'vmstat -z' or anywhere else. This continues 15 - 30 minutes or so and everything becomes fine again. After some time - 10 - 12 hours it repeats. Apart of all, I tried to make mutex profiling and here's the results (sorted by the total number of acquisitions): Bad case: 102 223514 273977 0 14689 1651568 /usr/src/sys/vm/uma_core.c:2349 (512) 950 263099 273968 0 15004 14427 /usr/src/sys/vm/uma_core.c:2450 (512) 108 150422 175840 0 10978 22988519 /usr/src/sys/vm/uma_core.c:1888 (mbuf) 352 160635 173663 0 10896 9678 /usr/src/sys/vm/uma_core.c:2209 (mbuf) 110 134910 173575 0 10838 9464 /usr/src/sys/vm/uma_core.c:2104 (mbuf) 1104 1335319 106888 12 27 1259 /usr/src/sys/netinet/tcp_output.c:253 (so_snd) 171 77754 97685 0 176 207 /usr/src/sys/net/pfil.c:71 (pfil_head_mtx) 140 77104 97685 0 151 128 /usr/src/sys/netinet/ip_fw2.c:164 (IPFW static rules) 100 76543 97685 0 146 45450 /usr/src/sys/netinet/ip_fw2.c:156 (IPFW static rules) 82 77149 97685 0 243 141221 /usr/src/sys/net/pfil.c:63 (pfil_head_mtx) 1644 914481 97679 9 739 949977 /usr/src/sys/contrib/ipfilter/netinet/fil.c:2320 (ipf filter load/unload mutex) 1642 556643 97679 5 0 0 /usr/src/sys/contrib/ipfilter/netinet/fil.c:2455 (ipf filter rwlock) 107 89413 97679 0 0 0 /usr/src/sys/contrib/ipfilter/netinet/fil.c:2142 (ipf cache rwlock) 907 148940 81439 1 3 7447 /usr/src/sys/kern/kern_lock.c:168 (lockbuilder mtxpool) 1764 152282 63435 2 438 336763 /usr/src/sys/net/route.c:197 (rtentry) And in the good case: 1738 821795 553033 1 41 284 /usr/src/sys/netinet/tcp_output.c:253 (so_snd) 2770 983643 490815 2 6 54 /usr/src/sys/kern/kern_lock.c:168 (lockbuilder mtxpool) 106 430941 477500 0 5555 4507 /usr/src/sys/netinet/ip_fw2.c:164 (IPFW static rules) 95 423926 477500 0 4412 5645 /usr/src/sys/netinet/ip_fw2.c:156 (IPFW static rules) 94 427239 477500 0 6323 7453 /usr/src/sys/net/pfil.c:63 (pfil_head_mtx) 82 432359 477500 0 5244 5768 /usr/src/sys/net/pfil.c:71 (pfil_head_mtx) 296 4751550 477498 9 20837 23019 /usr/src/sys/contrib/ipfilter/netinet/fil.c:2320 (ipf filter load/unload mutex) 85 2913118 477498 6 0 0 /usr/src/sys/contrib/ipfilter/netinet/fil.c:2455 (ipf filter rwlock) 55 473891 477498 0 0 0 /usr/src/sys/contrib/ipfilter/netinet/fil.c:2142 (ipf cache rwlock) 59 291035 309222 0 0 0 /usr/src/sys/contrib/ipfilter/netinet/fil.c:2169 (ipf cache rwlock) 1627 697811 305094 2 2161 2535 /usr/src/sys/net/route.c:147 (radix node head) 232 804172 305094 2 12193 6500 /usr/src/sys/net/route.c:197 (rtentry) 148 892580 303518 2 594 649 /usr/src/sys/net/route.c:1281 (rtentry) 145 584970 303518 1 13479 11148 /usr/src/sys/net/route.c:1265 (rtentry) 121 282669 303518 0 3529 886 /usr/src/sys/net/if_ethersubr.c:409 (em0) Here you can see that high UMA activity happens in periods of low disk performance. But I'm not sure whether this is a root of the problem, not a consequence. I have similiar servers around doing the same things, and they work fine. Also I had the same problem a year ago with another project and that time nothing helped and i had to install Linux. I can provide additional information regarding this server if needed. What else can I try to solve the problem??? With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 16:39:49 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65C3A16A417 for ; Mon, 15 Oct 2007 16:39:49 +0000 (UTC) (envelope-from zkolic@sbb.co.yu) Received: from smtp2.sbb.co.yu (smtp2.sbb.co.yu [82.117.194.22]) by mx1.freebsd.org (Postfix) with ESMTP id 5FD7E13C44B for ; Mon, 15 Oct 2007 16:39:48 +0000 (UTC) (envelope-from zkolic@sbb.co.yu) Received: from faust.net (cable-89-216-163-221.dynamic.sbb.co.yu [89.216.163.221]) by smtp2.sbb.co.yu (8.13.7/8.13.7) with ESMTP id l9FGafvh028457 for ; Mon, 15 Oct 2007 18:37:05 +0200 Received: by faust.net (Postfix, from userid 1001) id AEB0F1CC1C; Mon, 15 Oct 2007 18:32:36 +0200 (CEST) Date: Mon, 15 Oct 2007 18:32:36 +0200 From: Zoran Kolic To: freebsd-stable@freebsd.org Message-ID: <20071015163236.GA1572@faust.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SMTP-Vilter-Version: 1.3.2 X-SBB-Virus-Status: clean X-SBB-Spam-Score: 1.4 X-SBB-Spam-Level: XXX Subject: Re: usb stick problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 16:39:49 -0000 > From: Alson van der Meulen > This sounds like the documented behavior if the drive was empty or had > no long filenames when you mounted it. From mount_msdosfs(8): > "If neither -s nor -l are given, mount_msdosfs searches the root > directory of the file system to be mounted for any existing > Win'95 long filenames. If no such entries are found, but short > DOS filenames are found, -s is the default. Otherwise -l is > assumed." > -o longnames should do the trick. Thank you, Alson! Works! I forgot how to handle ms things. Even worse, I contacted shop technician and got an information that it was intended to reformat as the very first. He said explicitely it was fat16 formatted. What would you do in this situation? Go as it is now or do something like (I've read manual finaly): newfs_msdos -F 32 /dev/da0 Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 16:43:50 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9861616A41A for ; Mon, 15 Oct 2007 16:43:50 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from atl04.ws-e.com (vh00.ws-e.com [69.61.31.90]) by mx1.freebsd.org (Postfix) with ESMTP id 3E5CC13C45A for ; Mon, 15 Oct 2007 16:43:50 +0000 (UTC) (envelope-from bill@lefebvre.org) Received: from lilburn.lefebvre.org (ocee.groupsys.com [66.149.10.161]) by atl04.ws-e.com (8.13.8/8.13.8) with ESMTP id l9FGhnGk072787 for ; Mon, 15 Oct 2007 12:43:49 -0400 (EDT) (envelope-from bill@lefebvre.org) Received: from [10.88.88.6] (milton.lefebvre.org [10.88.88.6]) by lilburn.lefebvre.org (8.13.8/8.13.8) with ESMTP id l9FGhleg061784 for ; Mon, 15 Oct 2007 12:43:47 -0400 (EDT) (envelope-from bill@lefebvre.org) Message-ID: <471398BB.30405@lefebvre.org> Date: Mon, 15 Oct 2007 12:43:39 -0400 From: William LeFebvre User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <008801c80e66$7be49490$0c00a8c0@Artem> <471367F2.7050303@lefebvre.org> <037501c80f3d$69120730$0c00a8c0@Artem> In-Reply-To: <037501c80f3d$69120730$0c00a8c0@Artem> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=4.0 tests=ALL_TRUSTED autolearn=failed version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on lilburn.lefebvre.org X-Scanned-By: MIMEDefang 2.57 on 192.168.0.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (atl04.ws-e.com [69.61.31.90]); Mon, 15 Oct 2007 12:43:49 -0400 (EDT) Subject: Re: Question about 'top' values on memory usage, now threads X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 16:43:50 -0000 Artem Kuchin wrote: > CPU is more than just enough in my case. There will a a lot https > sitting there but load, i am sure, will be low. If the load is low then you may not need very many processes. > Swapping is simply unacceptable, so i am counting only real physical ram. Whether there is actual swapping going on or not, processes will still need swap space. There needs to be a backing store for every page that's in physical memory. For text pages and untouched data pages, the backing store is the executable file itself. For modified data pages there needs to be some place on disk to put a page when the virtual memory system decides it needs more physical pages. This isn't really swapping: its reclaiming infrequently used physical pages when there is something else with a more immediate need, usually called a "page out". When a modified data page is paged out it has to be written somewhere. That somewhere is the swap area. You can say "swapping is unacceptable" and that's fine. But most systems will have page outs: its just a fact of life with virtual memory systems. You can keep adding physical memory to minimize the number of page outs, and that sounds like what you want to do. And its even possible to have sufficient physical memory to ensure all processes remain memory resident. But without knowing the amount of shared virtual memory there is no easy way to determine the amount of physical memory you will need. > > However, noone mentioned anything about threads. DO they give any memory > advantage on freebsd? Yes, threading within httpd should provide a big advantage. The top output snippet you first posted indicates that you are not using threading yet (THR column is 1). Multiple threads in the same process will share the same text and data pages, but will have their own stacks. There may be some data memory overhead in the pthreads library (and within the program itself) to track all the threads, but I believe it will be small compared to the extra memory that additional processes would use. Of course there will be additional stack space required. Finding this overhead is actually easy. Just compare a process's SIZE when running with one thread and again when running multiple threads. Bill LeFebvre From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 16:44:34 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5733516A419 for ; Mon, 15 Oct 2007 16:44:34 +0000 (UTC) (envelope-from zoran@fooboo.org) Received: from fooboo.org (239.45.broadband3.iol.cz [85.70.45.239]) by mx1.freebsd.org (Postfix) with ESMTP id BBF8713C44B for ; Mon, 15 Oct 2007 16:44:33 +0000 (UTC) (envelope-from zoran@fooboo.org) Received: from blackbox.fooboo.org ([192.168.1.5] verified) by fooboo.org (CommuniGate Pro SMTP 5.1.4 _community_) with ESMTP id 260040 for freebsd-stable@freebsd.org; Mon, 15 Oct 2007 17:45:38 +0200 Received: by blackbox.fooboo.org (Postfix, from userid 1007) id EBA664BF4; Mon, 15 Oct 2007 17:44:28 +0200 (CEST) Date: Mon, 15 Oct 2007 17:44:28 +0200 From: Zoran Kolic To: freebsd-stable@freebsd.org Message-ID: <20071015154428.GA11829@blackbox.fooboo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: usb stick problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 16:44:34 -0000 > From: Alson van der Meulen > This sounds like the documented behavior if the drive was empty or had > no long filenames when you mounted it. From mount_msdosfs(8): > "If neither -s nor -l are given, mount_msdosfs searches the root > directory of the file system to be mounted for any existing > Win'95 long filenames. If no such entries are found, but short > DOS filenames are found, -s is the default. Otherwise -l is > assumed." > -o longnames should do the trick. Thank you, Alson! Works! I forgot how to handle ms things. Even worse, I contacted shop technician and got an information that it was intended to reformat as the very first. He said explicitely it was fat16 formatted. What would you do in this situation? Go as it is now or do something like (I've read manual finaly): newfs_msdos -F 32 /dev/da0 Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 17:36:06 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EA4016A418 for ; Mon, 15 Oct 2007 17:36:06 +0000 (UTC) (envelope-from matrix@itlegion.ru) Received: from corpmail.itlegion.ru (corpmail.itlegion.ru [84.21.226.211]) by mx1.freebsd.org (Postfix) with SMTP id 44E3013C448 for ; Mon, 15 Oct 2007 17:36:04 +0000 (UTC) (envelope-from matrix@itlegion.ru) Received: (qmail 15607 invoked from network); 15 Oct 2007 21:36:03 +0400 Received: from unknown (HELO Artem) (192.168.0.12) by 84.21.226.211 with SMTP; 15 Oct 2007 21:36:03 +0400 X-AntiVirus: Checked by Dr.Web [version: 4.44, engine: 4.44.0.09170, virus records: 249595, updated: 15.10.2007] Message-ID: <03f601c80f51$da2032d0$0c00a8c0@Artem> From: "Artem Kuchin" To: "William LeFebvre" , References: <008801c80e66$7be49490$0c00a8c0@Artem> <471367F2.7050303@lefebvre.org><037501c80f3d$69120730$0c00a8c0@Artem> <471398BB.30405@lefebvre.org> Date: Mon, 15 Oct 2007 21:35:53 +0400 Organization: IT Legion MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: Subject: Re: Question about 'top' values on memory usage, now threads X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 17:36:06 -0000 William LeFebvre wrote: > Artem Kuchin wrote: >> CPU is more than just enough in my case. There will a a lot https >> sitting there but load, i am sure, will be low. > > If the load is low then you may not need very many processes. They belong to different sites ;) so they need to be run constantly and for security reasons each site has its own http. >> Swapping is simply unacceptable, so i am counting only real physical >> ram. > > Whether there is actual swapping going on or not, processes will still > [SNIP] >> >> However, noone mentioned anything about threads. DO they give any >> memory advantage on freebsd? > > Yes, threading within httpd should provide a big advantage. The top > [SNIP] Thank you very much for the answers. You were very helpful! -- Regards, Artem From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 20:09:03 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A92016A419 for ; Mon, 15 Oct 2007 20:09:03 +0000 (UTC) (envelope-from robert.a.chalmers@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by mx1.freebsd.org (Postfix) with ESMTP id 2CCE413C457 for ; Mon, 15 Oct 2007 20:09:01 +0000 (UTC) (envelope-from robert.a.chalmers@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so822074wra for ; Mon, 15 Oct 2007 13:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:to:subject:date:mime-version:content-type:x-priority:x-msmail-priority:importance:x-mailer:x-mimeole:from; bh=wgEtJFoNTBUXl8xsF7giV9SQK/gb5qAeDerMv+qjDZg=; b=dc8v+3OWrNTSOJ7gnGtmRySS4aeGwuvj+RC7HLArHVu/FwSd7hvpMc3D8lpQX6tdLuVRCvmpIjPAzY9YhQaAPmYfPIscs7ll7bKAljmTwU4r8T8J5YmNA68Y12Dgwo8pqnQDH1AOFJ0cvdUOJUqtAo3pQHhtWrDGtvT/MRVZAcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:to:subject:date:mime-version:content-type:x-priority:x-msmail-priority:importance:x-mailer:x-mimeole:from; b=KcfWW2lzTvduJIZXHsEIYATKC0TFKkRyBWglZHAj4Sl+mJvnsYYiJGP9Hl2IBunSJUK7lIOuqFdrGjzRv7CC5/YSHKsuj5BH+a84GPWXI4FHD+b/l9zbM/GqmW6Ld3YPigUVNaIVDmTfoXkXlYWLNTIX2QXyjatlgehN7WCgen0= Received: by 10.114.73.1 with SMTP id v1mr7409854waa.1192477445189; Mon, 15 Oct 2007 12:44:05 -0700 (PDT) Received: from Avalon ( [122.129.133.78]) by mx.google.com with ESMTPS id m40sm8823864wag.2007.10.15.12.43.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Oct 2007 12:44:02 -0700 (PDT) Message-ID: To: Date: Tue, 16 Oct 2007 05:42:13 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1184 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1184 From: Robert Chalmers Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: can I do 6.1-RELEASE to 6.2 via cvsup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 20:09:03 -0000 I should just be able to change the TAG in standard-supfile from 6_1 to 6_2, do a cvsup, and the builds etc to end up with 6.2-RELEASE right? yes? no? ta rob From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 20:26:45 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AFC916A419 for ; Mon, 15 Oct 2007 20:26:45 +0000 (UTC) (envelope-from kometen@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id DEBBD13C455 for ; Mon, 15 Oct 2007 20:26:44 +0000 (UTC) (envelope-from kometen@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1370556nfb for ; Mon, 15 Oct 2007 13:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=RTa5u0WW65Taamy8A1q2wiFCSAhtsfpTWDDf5Tesh9g=; b=BJZ+wefehACNSp6xasNrssXg6R1ORST2H1TCo88SQAmzdPs7/Ufn1t68oQVbcCeY0fipP327tlf+swFxdI/87hYO9TsLOBLIcqSfOzE9nWndKqjgFcrnpPeZehB/peWNioi6utH3s4XR6mcjjDFRP66zpQWuTkav35y4JOqPddc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jkIknGAVOYbosgaUX26dZGXnGghlOrjtAYAVC6BOf++kdgclEKda4QvUft55N/t9/3W1XUE3rWpD0QqHUuVXxZ/UmRbbBmE3+FKajD6OzdBp+UKoMYx6yogZfZqIOUoOl+TR7zuWa8kYhDuXO6TM5LiMgakdSsceZo6hwZHRuo0= Received: by 10.78.193.5 with SMTP id q5mr4300930huf.1192480003236; Mon, 15 Oct 2007 13:26:43 -0700 (PDT) Received: by 10.78.146.10 with HTTP; Mon, 15 Oct 2007 13:26:43 -0700 (PDT) Message-ID: Date: Mon, 15 Oct 2007 22:26:43 +0200 From: "Claus Guttesen" To: "Robert Chalmers" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-stable@freebsd.org Subject: Re: can I do 6.1-RELEASE to 6.2 via cvsup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 20:26:45 -0000 > I should just be able to change the TAG in standard-supfile from 6_1 to 6_2, > do a cvsup, and the builds etc to end up with 6.2-RELEASE right? > yes? no? Yep: 1. make buildworld 2. make buildkernel (add KERNCONF=mykernel to /etc/make.conf) 3. mergemaster -p 4. make installkernel 5. shutdown -r now and boot into single user 6. mount -a (if /usr/src and /usr/obj resides on their own partitions) 7. mergemaster 8. make installworld 9. reboot I usually omit 5 and 6 because most of the time it works fine. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 20:32:05 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 778CA16A418 for ; Mon, 15 Oct 2007 20:32:05 +0000 (UTC) (envelope-from ekarkkai@pp.htv.fi) Received: from smtp5.pp.htv.fi (smtp5.pp.htv.fi [213.243.153.39]) by mx1.freebsd.org (Postfix) with ESMTP id E63FB13C442 for ; Mon, 15 Oct 2007 20:32:04 +0000 (UTC) (envelope-from ekarkkai@pp.htv.fi) Received: from zero.my.domain (cs181095217.pp.htv.fi [82.181.95.217]) by smtp5.pp.htv.fi (Postfix) with ESMTP id A04405BC13D for ; Mon, 15 Oct 2007 23:32:03 +0300 (EEST) Received: from thunderbolt.my.domain (thunderbolt.my.domain [10.192.168.30]) by zero.my.domain (8.13.8/8.13.8) with ESMTP id l9FKW3Cf000342 for ; Mon, 15 Oct 2007 23:32:03 +0300 (EEST) (envelope-from ekarkkai@pp.htv.fi) Received: from thunderbolt.my.domain (localhost [127.0.0.1]) by thunderbolt.my.domain (8.13.8/8.13.8) with ESMTP id l9FKW2kX019963 for ; Mon, 15 Oct 2007 23:32:02 +0300 (EEST) (envelope-from ejk@thunderbolt.my.domain) Received: (from ejk@localhost) by thunderbolt.my.domain (8.13.8/8.13.8/Submit) id l9FKW2E0019962 for stable@freebsd.org; Mon, 15 Oct 2007 23:32:02 +0300 (EEST) (envelope-from ejk) Date: Mon, 15 Oct 2007 23:32:02 +0300 From: Esa Karkkainen To: stable@freebsd.org Message-ID: <20071015203202.GA17964@pp.htv.fi> Mail-Followup-To: Esa Karkkainen , stable@freebsd.org References: <20071004165755.GA1049@pp.htv.fi> <47120D83.1010703@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47120D83.1010703@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 20:32:05 -0000 On Sun, Oct 14, 2007 at 02:37:23PM +0200, Kris Kennaway wrote: > Esa Karkkainen wrote: > > I get "Fatal double fault" error when writing to a filesystem > >mounted from NFS server. I got an offlist reply in which he suggested that the problem might be in nve driver. I installed an additional Intel nic, appropriate lines from dmesg are as follows fxp0: port 0xb000-0xb03f mem 0xe7200000-0xe7200fff,0xe7000000-0xe70fffff irq 11 at device 6.0 on pci1 miibus1: on fxp0 inphy0: on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto After I started to use fxp0, I can dump(8) all the necessary filesystems to the NFS mount, with out panic. When I used nve0 dump(8) or cp(1) managed to write less than megabyte to NFS mount and then machine paniced. It didn't matter if I made dump(8) write to the NFS mount or to a local filesystem and then copied the file to NFS mount, the end result was a panic. > > Both NFS server and client are running 6.2-RELEASE-p7. Both machines have been updated to -p8. > ># kgdb kernel.debug /home/crash/vmcore.2 > >Fatal double fault: > >eip = 0xc063242a > > Can you look up these IPs in the kernel symbol table (see the developers > handbook)? This might give at least one clue, although I'm not sure it > is relevant. I'm sorry, but I need to learn alot more about gdb and debugging in general before I can find that information. IIRC I have written about ten or twenty lines of C in this millenia. I do have matching kernel.debug and vmcore files, but kernel modules etc have been removed before I made new kernel and world. > You might also update to RELENG_6, I think there was at least one bug > fixed that might have caused such a thing. At the moment I don't have any stability problems with this machine, but I can upgrade to RELENG_6 before RELENG_6_3 is branched if that is necessary. > Also try to rule out memory failure etc. This machine has two 512MB DDR333 DIMM's. I installed sysutils/memtest and ran three simultaneously, first two allocated 326 MB each and last one allocated 150 MB of memory, so I'd start to swap. No errors. I know these test are not conclusive, but I don't think DIMM's are faulty. -- "In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." -- Douglas Adams 1952 - 2001 From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 22:32:49 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C806616A41A for ; Mon, 15 Oct 2007 22:32:49 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9AD4D13C448 for ; Mon, 15 Oct 2007 22:32:49 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 3562E1A4D81; Mon, 15 Oct 2007 15:08:36 -0700 (PDT) Date: Mon, 15 Oct 2007 15:08:36 -0700 From: Alfred Perlstein To: William LeFebvre Message-ID: <20071015220836.GO31826@elvis.mu.org> References: <008801c80e66$7be49490$0c00a8c0@Artem> <471367F2.7050303@lefebvre.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <471367F2.7050303@lefebvre.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Question about 'top' values on memory usage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 22:32:49 -0000 * William LeFebvre [071015 06:49] wrote: > > Unfortunately, freebsd does not appear to track the amount of shared > virtual memory for each process. It could be obtained by walking > through all the pages in a process's vm map, but that would really slow > top down. I don't know of any freebsd utility that would give that > information for an individual process. But hey, if it's out there > somewhere where it is easy to grab, I would be very happy to add it to top. Or this could be properly accounted for when the map is updated? > Personally, based on my experience, I would be more concerned with the > amount of available cpu cycles than memory. In my experience, once you > run out of idle time on a web server you have exceeded its capacity to > serve pages. In that situation it doesn't matter how many httpd > processes there are, the system is still not able to keep up with > demand. And that will probably happen before the system starts > thrashing from limited memory. Bill, I would have to differ with you based on personal experience, I've almost never run out of cpu on a webserver, typically it's the RAM that gets blown out. Once the server starts to page, you typically wind up with a cascade failure and the box just goes ... belly up. I would worry about ram. Typically the best way to scale a box is to load it and keep running more httpds until "something happens" or you reach enough httpd to service your load, at that point if "something happens" (ie the box tanks) you add more ram. -- - Alfred Perlstein From owner-freebsd-stable@FreeBSD.ORG Mon Oct 15 23:24:41 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEA5816A41B for ; Mon, 15 Oct 2007 23:24:41 +0000 (UTC) (envelope-from dak.col@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by mx1.freebsd.org (Postfix) with ESMTP id 666DC13C458 for ; Mon, 15 Oct 2007 23:24:41 +0000 (UTC) (envelope-from dak.col@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1544679wxd for ; Mon, 15 Oct 2007 16:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=6sbN/CY3kEmBX2xx1TI05LSDgk/iFkhialkNz+TGAHw=; b=KVuYinD0LpHJM2D1I+QDT10vQNCmycr2O3BhRFrlRxXoNvVVfxKdHJteSXs4NLor5U+gN0ARNt6thviy/rDh1fI44QrpotlnHhTJ1h+Jh9QX7GqFILeJtfvcxQcaluO+XYdl8gISYr7VWwGsCqGNu9QKWtOPDWIspL/hXRyuiQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=LeKpvmizEMzVxVMX8bpgl2rOQMKNKatJO+bu0Jxo840ngFwHnBqsd2ccizLnUPk8OWSw3LU5eTU6rswzcnIgzFPUwaEMtaMdmpBRhuU4qvRLNT+cvCwRu8gv4zAD+8CbGoqsu256jZFkAmoKfMY3hGglTCJwcYMNcVpAFUDUOE4= Received: by 10.70.66.18 with SMTP id o18mr11875394wxa.1192490677052; Mon, 15 Oct 2007 16:24:37 -0700 (PDT) Received: from ?192.168.2.5? ( [200.118.225.15]) by mx.google.com with ESMTPS id h40sm5401604wxd.2007.10.15.16.24.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Oct 2007 16:24:36 -0700 (PDT) Message-ID: <4713F6AC.8020000@gmail.com> Date: Mon, 15 Oct 2007 18:24:28 -0500 From: Diego Arias User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Robert Chalmers References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: can I do 6.1-RELEASE to 6.2 via cvsup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2007 23:24:41 -0000 Robert Chalmers escribió: > I should just be able to change the TAG in standard-supfile from 6_1 to 6_2, > do a cvsup, and the builds etc to end up with 6.2-RELEASE right? > yes? no? > > ta > rob > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > you will have the 6.2 source code. if you want to upgrade, you have to compile and install it. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 00:33:50 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A30E716A421 for ; Tue, 16 Oct 2007 00:33:50 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id DDDF313C480; Tue, 16 Oct 2007 00:33:49 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <471406ED.7000307@FreeBSD.org> Date: Tue, 16 Oct 2007 02:33:49 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Esa Karkkainen , stable@freebsd.org References: <20071004165755.GA1049@pp.htv.fi> <47120D83.1010703@FreeBSD.org> <20071015203202.GA17964@pp.htv.fi> In-Reply-To: <20071015203202.GA17964@pp.htv.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 00:33:50 -0000 Esa Karkkainen wrote: > On Sun, Oct 14, 2007 at 02:37:23PM +0200, Kris Kennaway wrote: >> Esa Karkkainen wrote: >>> I get "Fatal double fault" error when writing to a filesystem >>> mounted from NFS server. > > I got an offlist reply in which he suggested that the problem might be > in nve driver. > > I installed an additional Intel nic, appropriate lines from dmesg are > as follows > > fxp0: port 0xb000-0xb03f mem > 0xe7200000-0xe7200fff,0xe7000000-0xe70fffff irq 11 at device 6.0 on pci1 > miibus1: on fxp0 > inphy0: on miibus1 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > After I started to use fxp0, I can dump(8) all the necessary filesystems > to the NFS mount, with out panic. > > When I used nve0 dump(8) or cp(1) managed to write less than megabyte to NFS > mount and then machine paniced. > > It didn't matter if I made dump(8) write to the NFS mount or to a local > filesystem and then copied the file to NFS mount, the end result was a > panic. > >>> Both NFS server and client are running 6.2-RELEASE-p7. > > Both machines have been updated to -p8. > >>> # kgdb kernel.debug /home/crash/vmcore.2 >>> Fatal double fault: >>> eip = 0xc063242a >> Can you look up these IPs in the kernel symbol table (see the developers >> handbook)? This might give at least one clue, although I'm not sure it >> is relevant. > > I'm sorry, but I need to learn alot more about gdb and debugging in > general before I can find that information. IIRC I have written about > ten or twenty lines of C in this millenia. Well, it's explained in explicit detail in that document. C code is not involved. > I do have matching kernel.debug and vmcore files, but kernel modules etc > have been removed before I made new kernel and world. OK, most likely too late then. >> You might also update to RELENG_6, I think there was at least one bug >> fixed that might have caused such a thing. > > At the moment I don't have any stability problems with this machine, but > I can upgrade to RELENG_6 before RELENG_6_3 is branched if that is > necessary. > >> Also try to rule out memory failure etc. > > This machine has two 512MB DDR333 DIMM's. > > I installed sysutils/memtest and ran three simultaneously, first two > allocated 326 MB each and last one allocated 150 MB of memory, so I'd > start to swap. No errors. Well, as you say, such a limited test doesn't mean much. Anyway, it may well have been nve, so see how you go without it. kris From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 00:42:48 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFAEE16A41B; Tue, 16 Oct 2007 00:42:48 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 4E91C13C458; Tue, 16 Oct 2007 00:42:47 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47140906.2020107@FreeBSD.org> Date: Tue, 16 Oct 2007 02:42:46 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Alexey Popov References: <47137D36.1020305@chistydom.ru> In-Reply-To: <47137D36.1020305@chistydom.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 00:42:49 -0000 Alexey Popov wrote: > After some time of running under high load disk performance become > expremely poor. At that periods 'systat -vm 1' shows something like this: What does "high load" mean? You need to explain the system workload more. > Disks amrd0 > KB/t 85.39 > tps 5 > MB/s 0.38 > % busy 99 > Apart of all, I tried to make mutex profiling and here's the results > (sorted by the total number of acquisitions): > > Bad case: > > 102 223514 273977 0 14689 1651568 /usr/src/sys/vm/uma_core.c:2349 (512) > 950 263099 273968 0 15004 14427 /usr/src/sys/vm/uma_core.c:2450 (512) > 108 150422 175840 0 10978 22988519 /usr/src/sys/vm/uma_core.c:1888 (mbuf) > Here you can see that high UMA activity happens in periods of low disk > performance. But I'm not sure whether this is a root of the problem, not > a consequence. The extremely high contention there does seem to say you have a mbuf starvation problem and not a disk problem. I don't know why this would be happening off-hand. Can you also provide more details about the system hardware and configuration? Kris From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 00:50:24 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6CD216A418 for ; Tue, 16 Oct 2007 00:50:24 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by mx1.freebsd.org (Postfix) with ESMTP id AC3A313C478 for ; Tue, 16 Oct 2007 00:50:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so874402wra for ; Mon, 15 Oct 2007 17:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=0qp7fa3+nbCV5zElwq2yqkssk7lNxI+SZaVj1pt1pdM=; b=dugy7jVp0IJmBGWEDxEMdF9MMoFyoIJeB5O0Vy/X5FBeepFEpdoLiXErg3al24/cfpwMmJL66ISlNk+eLrFpA6nj1p8Ytd39WMszRKOxf3qyQH+eBDkszhNi0fLSlqKNEJ1eiuCaxfbVp0UorKQlXPlmHKtnf0DzqxIOtFGSDIg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=S/ZybLWqe1jbkNSEokYmDCyImn/jbaEKI4KT3U+mZwJpHnUoQIvXdegxRkwtzEVS1eVokqBzyhhCoSoXpdhTO5c/54lR+evBBKcPs0q67jch+ek5dIIQ3J8eg0/2kVq2s2whuVDmhHfRjEuK6T8iAOGsRIHH6kWVU+pbCTGgS/s= Received: by 10.90.118.12 with SMTP id q12mr8086416agc.1192495822590; Mon, 15 Oct 2007 17:50:22 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 8sm2909nzn.2007.10.15.17.50.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 15 Oct 2007 17:50:20 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id l9G0kcRj079602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2007 09:46:38 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id l9G0kbED079601; Tue, 16 Oct 2007 09:46:37 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 16 Oct 2007 09:46:37 +0900 From: Pyun YongHyeon To: Esa Karkkainen , stable@freebsd.org Message-ID: <20071016004637.GA79351@cdnetworks.co.kr> References: <20071004165755.GA1049@pp.htv.fi> <47120D83.1010703@FreeBSD.org> <20071015203202.GA17964@pp.htv.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071015203202.GA17964@pp.htv.fi> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 00:50:25 -0000 On Mon, Oct 15, 2007 at 11:32:02PM +0300, Esa Karkkainen wrote: > On Sun, Oct 14, 2007 at 02:37:23PM +0200, Kris Kennaway wrote: > > Esa Karkkainen wrote: > > > I get "Fatal double fault" error when writing to a filesystem > > >mounted from NFS server. > > I got an offlist reply in which he suggested that the problem might be > in nve driver. > > I installed an additional Intel nic, appropriate lines from dmesg are > as follows > > fxp0: port 0xb000-0xb03f mem > 0xe7200000-0xe7200fff,0xe7000000-0xe70fffff irq 11 at device 6.0 on pci1 > miibus1: on fxp0 > inphy0: on miibus1 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > After I started to use fxp0, I can dump(8) all the necessary filesystems > to the NFS mount, with out panic. > > When I used nve0 dump(8) or cp(1) managed to write less than megabyte to NFS > mount and then machine paniced. > I remember that nve(4) is NOT stable under heavy network loads. I'd like to say use nfe(4) which is believed to be more stable/fast than nve(4). nfe(4) is also default NVIDIA NIC driver for CURRENT/RELENG_7. If you have to use RELENG_6 try nfe(4) at the following URL. http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html > It didn't matter if I made dump(8) write to the NFS mount or to a local > filesystem and then copied the file to NFS mount, the end result was a > panic. > > > > Both NFS server and client are running 6.2-RELEASE-p7. > > Both machines have been updated to -p8. > > > ># kgdb kernel.debug /home/crash/vmcore.2 > > >Fatal double fault: > > >eip = 0xc063242a > > > > Can you look up these IPs in the kernel symbol table (see the developers > > handbook)? This might give at least one clue, although I'm not sure it > > is relevant. > > I'm sorry, but I need to learn alot more about gdb and debugging in > general before I can find that information. IIRC I have written about > ten or twenty lines of C in this millenia. > > I do have matching kernel.debug and vmcore files, but kernel modules etc > have been removed before I made new kernel and world. > > > You might also update to RELENG_6, I think there was at least one bug > > fixed that might have caused such a thing. > > At the moment I don't have any stability problems with this machine, but > I can upgrade to RELENG_6 before RELENG_6_3 is branched if that is > necessary. > > > Also try to rule out memory failure etc. > > This machine has two 512MB DDR333 DIMM's. > > I installed sysutils/memtest and ran three simultaneously, first two > allocated 326 MB each and last one allocated 150 MB of memory, so I'd > start to swap. No errors. > > I know these test are not conclusive, but I don't think DIMM's are > faulty. > > -- -- Regards, Pyun YongHyeon From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 01:13:18 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D973416A41B for ; Tue, 16 Oct 2007 01:13:18 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by mx1.freebsd.org (Postfix) with ESMTP id AE3CC13C481 for ; Tue, 16 Oct 2007 01:13:18 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: by malasada.lava.net (Postfix, from userid 102) id E4A81153882; Mon, 15 Oct 2007 14:48:33 -1000 (HST) Date: Mon, 15 Oct 2007 14:48:33 -1000 From: Clifton Royston To: Alfred Perlstein Message-ID: <20071016004833.GB18975@lava.net> Mail-Followup-To: Alfred Perlstein , William LeFebvre , freebsd-stable@freebsd.org References: <008801c80e66$7be49490$0c00a8c0@Artem> <471367F2.7050303@lefebvre.org> <20071015220836.GO31826@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071015220836.GO31826@elvis.mu.org> User-Agent: Mutt/1.4.2.2i Cc: William LeFebvre , freebsd-stable@freebsd.org Subject: Re: Question about 'top' values on memory usage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 01:13:18 -0000 On Mon, Oct 15, 2007 at 03:08:36PM -0700, Alfred Perlstein wrote: > * William LeFebvre [071015 06:49] wrote: > > > > Unfortunately, freebsd does not appear to track the amount of shared > > virtual memory for each process. It could be obtained by walking > > through all the pages in a process's vm map, but that would really slow > > top down. I don't know of any freebsd utility that would give that > > information for an individual process. But hey, if it's out there > > somewhere where it is easy to grab, I would be very happy to add it to top. > > Or this could be properly accounted for when the map is updated? > > > Personally, based on my experience, I would be more concerned with the > > amount of available cpu cycles than memory. In my experience, once you > > run out of idle time on a web server you have exceeded its capacity to > > serve pages. In that situation it doesn't matter how many httpd > > processes there are, the system is still not able to keep up with > > demand. And that will probably happen before the system starts > > thrashing from limited memory. > > Bill, I would have to differ with you based on personal experience, > I've almost never run out of cpu on a webserver, typically it's the > RAM that gets blown out. Once the server starts to page, you typically > wind up with a cascade failure and the box just goes ... belly up. IME, it really depends mostly what kind of content you're serving; I've seen either one, or disk, be the problem. Serving mostly static pages? Don't worry about CPU, it'll be the RAM. Naive database search, not caching the results? You may get killed on disk I/O. If you're serving some kind of computationally "expensive" content via a CGI and the site gets hit, then it'll run out of CPU. All in all I would guess the latter's much rarer, assuming you're using a well configured webserver built with an appropriate client-connection service model. OTOH, if you can guess the process limits correctly, you can usually set them with a safety margin such that the machine won't hit the number of processes to force it into paging; it'll be unresponsive to clients above its limit, but continue to respond adequately to the clients which succeed in connecting. All IMHO. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 03:39:14 2007 Return-Path: Delivered-To: stable@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 991) id A840916A420; Tue, 16 Oct 2007 03:39:14 +0000 (UTC) Date: Tue, 16 Oct 2007 03:39:14 +0000 From: Mark Linimon To: current@FreeBSD.org, stable@FreeBSD.org Message-ID: <20071016033914.GA82087@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: linimon@FreeBSD.org Subject: [HEADSUP] preparations for ports release for 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 03:39:14 -0000 This is a pointer to the headsup I posted to freebsd-ports@ detailing the switch of portsmon's default build environment from i386-6 to i386-7. This controls such things as determination of whether a port is marked "broken" (e.g. with gcc4.2.) The first set of email reminders based on this have already gone out to maintainers. Not too many ports remain to be fixed with gcc4.2, but some do. If you are interested in helping out, please take a look at the following: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=341967+0+archive/2007/freebsd-ports/20071014.freebsd-ports It also details some new graphs that allow you to see the visual comparison of how well the package builds are doing on each build environment, and also to drill down to a pie chart for each build environment, and a complete list of all ports that do not package for one reason or another for each build environment. If you're considering upgrading to 7.0, or even want to see the comparison between e.g. i386 and amd64, I think you will find this information useful. Note: the reports are still in the alpha state, so you don't need to report bugs to me: I am well aware of them :-/ mcl From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 03:49:44 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFA2F16A417 for ; Tue, 16 Oct 2007 03:49:44 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id A39A213C45B for ; Tue, 16 Oct 2007 03:49:44 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 838161CC06B; Mon, 15 Oct 2007 20:49:44 -0700 (PDT) Date: Mon, 15 Oct 2007 20:49:44 -0700 From: Jeremy Chadwick To: Rick Message-ID: <20071016034944.GA23351@eos.sc1.parodius.com> Mail-Followup-To: Rick , freebsd-stable@freebsd.org References: <20071015172143.GI14791@phantasm.metahusky.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071015172143.GI14791@phantasm.metahusky.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: device_attach: smist0 attach returned 6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 03:49:44 -0000 On Mon, Oct 15, 2007 at 06:21:43PM +0100, Rick wrote: > Oct 15 11:26:20 metahusky kernel: smist0: on cpu0 > Oct 15 11:26:20 metahusky kernel: device_attach: smist0 attach returned 6 > Oct 15 11:26:20 metahusky kernel: smist1: on cpu1 > Oct 15 11:26:20 metahusky kernel: device_attach: smist1 attach returned 6 The same happens (re: attach returned 6) on my AMD X2 3800+ box at home (running RELENG_7) when I *do not* have Cool'n'Quiet enabled in the BIOS. All I had to do was enable the option in the BIOS and the attach worked. > Here is the dmesg on boot: > > FreeBSD 6.2-RELEASE-p5 #0: Sun Jun 24 09:06:35 BST 2007 > xxxx@metahusky.net:/usr/obj/usr/src/sys/SMPKDB62 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel Pentium III (796.54-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x683 Stepping = 3 > Features=0x387fbff > real memory = 1073676288 (1023 MB) > avail memory = 1041498112 (993 MB) > ACPI APIC Table: In your case, your system is using an Intel 440BX, which means it's going to tie in to the PIIX4. I'm voting you need to toggle some BIOS options to get this to work. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 08:02:34 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6523D16A41B; Tue, 16 Oct 2007 08:02:34 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id EDAD613C459; Tue, 16 Oct 2007 08:02:30 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 194309166; Tue, 16 Oct 2007 12:01:44 +0400 Message-ID: <47146FB4.6040306@chistydom.ru> Date: Tue, 16 Oct 2007 12:00:52 +0400 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Kris Kennaway References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> In-Reply-To: <47140906.2020107@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------040306070507060607050303" Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 08:02:34 -0000 This is a multi-part message in MIME format. --------------040306070507060607050303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi. Kris Kennaway wrote: >> After some time of running under high load disk performance become >> expremely poor. At that periods 'systat -vm 1' shows something like >> this: > What does "high load" mean? You need to explain the system workload more. This web service is similiar to YouTube. This server is video store. I have around 200G of *.flv (flash video) files on the server. I run lighttpd as a web server. Disk load is usually around 50%, network output 100Mbit/s, 100 simultaneous connections. CPU is mostly idle. As you can see it is a trivial service - sending files to network via HTTP. > >> Disks amrd0 >> KB/t 85.39 >> tps 5 >> MB/s 0.38 >> % busy 99 > >> Apart of all, I tried to make mutex profiling and here's the results >> (sorted by the total number of acquisitions): >> >> Bad case: >> >> 102 223514 273977 0 14689 1651568 /usr/src/sys/vm/uma_core.c:2349 (512) >> 950 263099 273968 0 15004 14427 /usr/src/sys/vm/uma_core.c:2450 (512) >> 108 150422 175840 0 10978 22988519 /usr/src/sys/vm/uma_core.c:1888 >> (mbuf) > > > Here you can see that high UMA activity happens in periods of low disk > > performance. But I'm not sure whether this is a root of the problem, not > > a consequence. > > The extremely high contention there does seem to say you have a mbuf > starvation problem and not a disk problem. I don't know why this would > be happening off-hand. But there's no mbuf shortage in `netstat -m`. What else can I try to track down the source of the problem? > Can you also provide more details about the system hardware and > configuration? This is Dell 2850 2 x Xeon 3.2, 4Gb RAM, 6x300Gb SCSI RAID5. I'll attach details. With best regards, Alexey Popov --------------040306070507060607050303 Content-Type: text/plain; name="details.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="details.txt" Copyright (c) 1992-2007 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 6.2-STABLE #1: Wed Jul 18 18:12:56 MSD 2007 xxx@xxx.ru:/usr/obj/usr/src/sys/SMP-amd64 module_register: module accf_http already exists! Module accf_http failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3192.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf4a Stepping = 10 Features=0xbfebfbff Features2=0x641d AMD Features=0x20100800 AMD Features2=0x1 real memory = 4831838208 (4608 MB) avail memory = 4133355520 (3941 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0: Changing APIC ID to 7 ioapic1: Changing APIC ID to 8 ioapic1: WARNING: intbase 32 != expected base 24 ioapic2: Changing APIC ID to 9 ioapic2: WARNING: intbase 64 != expected base 56 ioapic3: Changing APIC ID to 10 ioapic3: WARNING: intbase 96 != expected base 88 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard ioapic2 irqs 64-87 on motherboard ioapic3 irqs 96-119 on motherboard module_register_init: MOD_LOAD (accf_http, 0xffffffff80338880, 0xffffffff807a4720) error 17 acpi0: on motherboard acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 2000 acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 amr0: mem 0xf80f0000-0xf80fffff,0xfe9c0000-0xfe9fffff irq 46 at device 14.0 on pci2 amr0: Using 64-bit DMA amr0: delete logical drives supported by controller amr0: Firmware 521X, BIOS H430, 256MB RAM pcib3: at device 0.2 on pci1 pci3: on pcib3 pcib4: at device 4.0 on pci0 pci4: on pcib4 pcib5: at device 5.0 on pci0 pci5: on pcib5 pcib6: at device 0.0 on pci5 pci6: on pcib6 em0: port 0xecc0-0xecff mem 0xfe6e0000-0xfe6fffff irq 64 at device 7.0 on pci6 em0: Ethernet address: 00:13:72:62:51:01 pcib7: at device 0.2 on pci5 pci7: on pcib7 em1: port 0xdcc0-0xdcff mem 0xfe4e0000-0xfe4fffff irq 65 at device 8.0 on pci7 em1: Ethernet address: 00:13:72:62:51:02 pcib8: at device 6.0 on pci0 pci8: on pcib8 pcib9: at device 0.0 on pci8 pci9: on pcib9 pcib10: at device 0.2 on pci8 pci10: on pcib10 uhci0: port 0xbce0-0xbcff irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xbcc0-0xbcdf irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xbca0-0xbcbf irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfeb00000-0xfeb003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered uhub4: vendor 0x413c product 0xa001, class 9/0, rev 2.00/0.00, addr 2 uhub4: multiple transaction translators uhub4: 2 ports with 2 removable, self powered pcib11: at device 30.0 on pci0 pci11: on pcib11 pci11: at device 13.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A orm0: at iomem 0xc0000-0xcafff,0xec000-0xeffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec IP Filter: v4.1.13 initialized. Default = pass all, Logging = enabled ipfw2 initialized, divert enabled, rule-based forwarding disabled, default to accept, logging unlimited acd0: CDRW at ata0-master UDMA33 amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 1430400MB (2929459200 sectors) RAID 5 (optimal) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/amrd0s1a === machine amd64 cpu HAMMER ident SMP-amd64 # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. options SMP #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking #options INET6 # IPv6 communications protocols 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 QUOTA options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT #options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options IPDIVERT options IPFILTER options IPFILTER_LOG options DUMMYNET options TCP_DROP_SYNFIN options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_DEFAULT_TO_ACCEPT options ACCEPT_FILTER_HTTP options DEVICE_POLLING options COMPAT_LINUX32 # Enable Linux ABI emulation options LINPROCFS # Enable the linux-like proc filesystem support options LINSYSFS # Enable the linux-like sys filesystem support # Bus support. device acpi device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices device ahd # AHA39320/29320 and onboard AIC79xx devices device mpt # LSI-Logic MPT-Fusion # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device pass # Passthrough device (direct SCSI access) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers #device aac # Adaptec FSA RAID device mfi # LSI MegaRAID SAS device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device kbdmux device vga # VGA video card driver # syscons is the default console driver, resembling an SCO console device sc # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # PCI Ethernet NICs. device em # Intel PRO/1000 adapter Gigabit Ethernet Card # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device fxp # Intel EtherExpress PRO/100B (82557, 82558) device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ums # Mouse # Pseudo devices. device loop # Network loopback device random # Entropy device #device mem # Memory and kernel memory devices #device io # I/O device device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device bpf # Berkeley packet filter #device snp # Snoop === KERNCONF= SMP-amd64 CFLAGS= -O2 -pipe NO_BLUETOOTH= true NO_DYNAMICROOT= true NO_FORTRAN= true NO_GAMES= true NO_I4B= true NO_INET6= true NO_LPR= true NO_OBJC= true NO_PROFILE= true NO_SENDMAIL= true NO_SHAREDOCS= true PPP_NO_SUID= true MAKE_IDEA= true BOOTWAIT= 3000 WITHOUT_X11= true # added by use.perl 2007-02-22 16:57:09 PERL_VER=5.8.8 PERL_VERSION=5.8.8 === autoboot_delay="1" kern.ipc.nsfbufs="16384" kern.ipc.nmbclusters="32768" kern.ipc.maxsockets="49152" accf_http_load="YES" === # $FreeBSD: src/etc/sysctl.conf,v 1.8 2003/03/13 18:43:50 mux Exp $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 security.jail.allow_raw_sockets=1 kern.coredump=0 net.inet.tcp.sendspace=65536 net.inet.tcp.recvspace=32768 net.inet.tcp.blackhole=1 net.inet.udp.blackhole=1 kern.ipc.somaxconn=4096 kern.maxfiles=65535 kern.maxfilesperproc=24576 net.inet.ip.redirect=0 net.inet.icmp.icmplim=100 vfs.ufs.dirhash_maxmem=33554432 === 2271/519/2790 mbufs in use (current/cache/total) 257/301/558/32768 mbuf clusters in use (current/cache/total/max) 257/62 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 1081K/731K/1813K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 30771023 requests for I/O initiated by sendfile 22841 calls to protocol drain routines === ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 240, 0, 69, 6, 69, 0 UMA Zones: 376, 0, 69, 1, 69, 0 UMA Slabs: 128, 0, 798, 217, 880024, 0 UMA RCntSlabs: 128, 0, 279, 69, 998108, 0 UMA Hash: 256, 0, 4, 11, 7, 0 16 Bucket: 152, 0, 51, 49, 81, 0 32 Bucket: 280, 0, 16, 54, 67, 5 64 Bucket: 536, 0, 27, 43, 83, 70 128 Bucket: 1048, 0, 248, 91, 4519, 105441 VM OBJECT: 224, 0, 9299, 32929, 39998256, 0 MAP: 352, 0, 7, 15, 7, 0 KMAP ENTRY: 112, 90222, 315, 1467, 8013389, 0 MAP ENTRY: 112, 0, 1540, 935, 107991432, 0 PV ENTRY: 48, 2244600, 22626, 34182, 1346881487, 0 DP fakepg: 120, 0, 0, 0, 0, 0 mt_zone: 1024, 0, 170, 6, 170, 0 16: 16, 0, 3591, 4473, 5890279245, 0 32: 32, 0, 1280, 336, 3464783, 0 64: 64, 0, 6325, 731, 23248175, 0 128: 128, 0, 4932, 491, 13839290, 0 256: 256, 0, 617, 238, 38329528, 0 512: 512, 0, 604, 250, 4068843, 0 1024: 1024, 0, 50, 190, 264828, 0 2048: 2048, 0, 24, 170, 749576, 0 4096: 4096, 0, 246, 153, 2359705, 0 Files: 120, 0, 295, 387, 3661062347, 0 PROC: 856, 0, 89, 71, 1409212, 0 THREAD: 608, 0, 165, 9, 153943, 0 KSEGRP: 136, 0, 161, 73, 161, 0 UPCALL: 88, 0, 3, 73, 3, 0 VMSPACE: 544, 0, 42, 70, 1421441, 0 mbuf_packet: 256, 0, 256, 102, 8363723672, 0 mbuf: 256, 0, 2015, 417, 38877957573, 0 mbuf_cluster: 2048, 32768, 358, 200, 7518256274, 0 mbuf_jumbo_pagesize: 4096, 0, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 0, 0, 0, 0, 0 ACL UMA zone: 388, 0, 0, 0, 0, 0 g_bio: 216, 0, 0, 252, 147835491, 0 ata_request: 336, 0, 0, 22, 24, 0 ata_composite: 376, 0, 0, 0, 0, 0 VNODE: 496, 0, 31168, 19000, 2685396, 0 VNODEPOLL: 152, 0, 0, 50, 1, 0 NAMEI: 1024, 0, 0, 260, 3821583922, 0 S VFS Cache: 104, 0, 30561, 11019, 4538003, 0 L VFS Cache: 327, 0, 225, 315, 37256, 0 NFSMOUNT: 584, 0, 2, 5, 2, 0 NFSNODE: 664, 0, 20, 34, 19966, 0 DIRHASH: 1024, 0, 197, 135, 4270, 0 PIPE: 768, 0, 38, 137, 1054660, 0 KNOTE: 120, 0, 92, 280, 6364470113, 0 socket: 616, 49152, 234, 1680, 10545083, 0 ipq: 56, 1071, 0, 63, 40238, 0 udpcb: 304, 49152, 7, 41, 1228853, 0 inpcb: 304, 49152, 219, 1389, 7473636, 0 tcpcb: 752, 49155, 185, 1365, 7473636, 0 tcptw: 80, 8235, 34, 596, 2262193, 0 syncache: 128, 15370, 0, 145, 7427194, 0 hostcache: 136, 15372, 2277, 271, 1587434, 0 tcpreass: 40, 2100, 0, 420, 247314, 0 sackhole: 32, 0, 14, 491, 217222631, 0 ripcb: 304, 49152, 0, 36, 152, 0 unpcb: 200, 49153, 42, 262, 1842437, 0 rtentry: 264, 0, 7, 35, 37, 0 divcb: 304, 49152, 0, 0, 0, 0 IPFW dynamic rule: 120, 0, 170, 264, 760604, 0 SWAPMETA: 288, 116519, 1, 12, 398, 0 Mountpoints: 792, 0, 10, 5, 11, 0 FFS inode: 192, 0, 31101, 3279, 2665061, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 31101, 2169, 2665061, 0 === Type InUse MemUse HighUse Requests Size(s) PCI Link 16 2K - 16 32,128 acpitask 0 0K - 1 64 cdev 23 6K - 23 256 CAM XPT 6 1K - 9 32,128,512 sigio 1 1K - 1 64 file desc 97 59K - 1411126 16,32,64,128,512,1024,2048,4096 kenv 71 11K - 72 16,32,64 kqueue 2 5K - 1206477 512,2048,4096 proc-args 36 3K - 2116546 16,32,64,128,256 zombie 0 0K - 1409124 256 ithread 144 30K - 144 32,128,256 KTRACE 100 13K - 100 128 linker 51 5K - 113 16,32,64,128,512 lockf 7 1K - 1555267 128 temp 150 443K - 2845070 16,32,64,128,256,512,1024,2048,4096 devbuf 8269 17079K - 1580938 16,32,64,128,256,512,1024,2048,4096 module 204 26K - 205 128 mtx_pool 1 12K - 1 subproc 250 437K - 1409374 512,4096 proc 2 16K - 2 session 26 7K - 314145 256 pgrp 29 4K - 314512 128 acpisem 18 3K - 18 128 cred 94 24K - 27113336 256 uidinfo 5 3K - 140192 64,2048 plimit 21 6K - 1095041 256 sysctltmp 0 0K - 19512 16,32,128 sysctloid 2595 127K - 2595 16,32,64,128 sysctl 0 0K - 2276333 16,32,64 umtx 174 22K - 534 128 SWAP 2 277K - 2 64 CAM dev queue 1 1K - 1 128 bus-sc 58 46K - 1318 16,32,64,128,256,512,1024,2048,4096 bus 611 56K - 3534 16,32,64,128,256,1024 devstat 10 21K - 10 32,4096 eventhandler 49 6K - 49 64,256 CAM queue 3 1K - 3 16 kobj 114 456K - 137 4096 ata_generic 1 1K - 1 1024 rman 112 14K - 563 128 ata_dma 2 1K - 2 256 sbuf 0 0K - 334 16,32,64,128,256,512,1024,2048,4096 sleep queues 175 11K - 535 64 taskqueue 11 2K - 11 16,32,256 turnstiles 175 22K - 535 128 Unitno 11 1K - 307567 32,64 iov 0 0K - 7741292 16,64,128,256,4096 ioctlops 1 1K - 12436597 16,32,64,128,256,512,1024,2048,4096 msg 4 30K - 4 2048,4096 sem 4 8K - 4 1024,2048,4096 shm 1 16K - 1 ttys 1272 180K - 25579 128,1024 ptys 4 1K - 4 256 accf 5 1K - 13 32,64 mbextcnt 2012 32K - 5862464123 16 mbuf_tag 0 0K - 6 32 pcb 18 9K - 670683 16,32,64,128,4096 soname 30 4K - 21014900 16,32,128 acd_driver 1 2K - 1 2048 BIO buffer 0 0K - 72459 1024,2048 vfscache 1 1024K - 1 cluster_save buffer 0 0K - 14419 64,128 VFS hash 1 512K - 1 vnodes 4 1K - 8 32,256 vnodemarker 0 0K - 1634474 512 mount 154 7K - 313 16,32,64,128,256,2048 entropy 1024 64K - 1024 64 BPF 3 1K - 3 128 ether_multi 7 1K - 8 16,64 ifaddr 26 9K - 28 32,64,512,4096 ifnet 4 7K - 4 512,2048 clone 3 12K - 3 4096 arpcom 2 1K - 2 32 lo 1 1K - 1 32 USBdev 21 8K - 21 16,128,256,512 routetbl 144 67K - 276339 32,64,128,256,512 in_multi 2 1K - 2 64 IpFw/IpAcct 20 4K - 60 64,128,2048 hostcache 1 48K - 1 USB 76 13K - 76 16,32,64,128,256,512 syncache 1 12K - 1 NFSV3 diroff 0 0K - 34 512 NFS req 0 0K - 241605 128 NFS daemon 1 16K - 1 p1003.1b 1 1K - 1 16 savedino 0 0K - 44215 256 newdirblk 0 0K - 1672 64 dirrem 0 0K - 3253411 64 mkdir 0 0K - 153290 64 diradd 1 1K - 3275432 64 freefile 0 0K - 2076356 64 freeblks 2 1K - 2377275 256 freefrag 2 1K - 162141 64 allocindir 1 1K - 2401831 128 indirdep 1 1K - 119555 64 allocdirect 4 1K - 3102764 256 bmsafemap 4 1K - 134621 128 newblk 1 1K - 5504596 64,512 inodedep 5 513K - 2273914 256 pagedep 2 129K - 93330 128 UFS dirhash 213 39K - 5703 16,32,64,128,512 UFS mount 18 77K - 21 512,2048,4096 UMAHash 3 10K - 9 512,1024,2048,4096 DEVFS1 94 47K - 94 512 DEVFS3 104 26K - 105 256 DEVFS 11 1K - 12 16,256 VM pgdata 2 129K - 2 128 pfs_nodes 165 21K - 165 128 pfs_vncache 1 1K - 169 64 CAM SIM 1 1K - 1 128 memdesc 1 4K - 1 4096 GEOM 98 23K - 567 16,32,64,128,256,512,1024,2048,4096 isadev 8 1K - 8 128 I/O APIC 4 8K - 4 2048 nexusdev 2 1K - 2 16 CAM periph 1 1K - 1 256 acpidev 69 5K - 69 64 atkbddev 1 1K - 1 64 acpica 2245 242K - 19682 16,32,64,128,256,512,1024,4096 linux 15 1K - 15 64 === last pid: 11008; load averages: 0.07, 0.10, 0.08 up 47+08:32:50 11:46:15 38 processes: 1 running, 37 sleeping Mem: 46M Active, 3443M Inact, 246M Wired, 144M Cache, 208M Buf, 5596K Free Swap: 2048M Total, 4K Used, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 56386 root 1 4 0 19856K 10000K kqread 1 115:19 2.88% lighttpd 636 root 1 96 0 18292K 4212K select 0 25:39 0.00% snmpd 784 root 1 96 0 19668K 2072K select 1 2:31 0.00% sshd 680 root 1 96 0 7732K 1384K select 0 1:59 0.00% ntpd 1540 root 1 96 0 35092K 6496K select 0 1:30 0.00% httpd 769 root 4 20 0 14148K 2632K kserel 0 1:04 0.00% bacula-fd 755 root 1 96 0 3852K 1060K select 1 0:22 0.00% master 568 root 1 96 0 3648K 908K select 0 0:18 0.00% syslogd 80663 root 1 8 0 3688K 1016K nanslp 1 0:05 0.00% cron 760 postfix 1 96 0 3944K 1160K select 0 0:04 0.00% qmgr 89776 www 1 20 0 35180K 6684K lockf 0 0:04 0.00% httpd 89763 www 1 20 0 35180K 6684K lockf 0 0:04 0.00% httpd 89774 www 1 20 0 35180K 6684K lockf 0 0:04 0.00% httpd 89775 www 1 96 0 35180K 6684K select 0 0:04 0.00% httpd 699 root 1 20 0 7732K 1388K pause 0 0:03 0.00% ntpd 484 root 1 4 0 652K 220K select 0 0:00 0.00% devd 10904 llp 1 96 0 30616K 3564K select 0 0:00 0.00% sshd 10915 root 1 20 0 3912K 2340K pause 1 0:00 0.00% csh === kern.ostype: FreeBSD kern.osrelease: 6.2-STABLE kern.osrevision: 199506 kern.version: FreeBSD 6.2-STABLE #1: Wed Jul 18 18:12:56 MSD 2007 xxx@xxx.ru:/usr/obj/usr/src/sys/SMP-amd64 kern.maxvnodes: 100000 kern.maxproc: 6164 kern.maxfiles: 65535 kern.argmax: 262144 kern.securelevel: -1 kern.hostname: xxx.ru kern.hostid: 0 kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 } kern.posix1version: 200112 kern.ngroups: 16 kern.job_control: 1 kern.saved_ids: 0 kern.boottime: { sec = 1188429235, usec = 814920 } Thu Aug 30 03:13:55 2007 kern.domainname: kern.osreldate: 602111 kern.bootfile: /boot/kernel.old/kernel kern.maxfilesperproc: 24576 kern.maxprocperuid: 5547 kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.somaxconn: 4096 kern.ipc.max_linkhdr: 16 kern.ipc.max_protohdr: 40 kern.ipc.max_hdr: 56 kern.ipc.max_datalen: 120 kern.ipc.nmbjumbo16: 0 kern.ipc.nmbjumbo9: 0 kern.ipc.nmbjumbop: 0 kern.ipc.nmbclusters: 32768 kern.ipc.piperesizeallowed: 1 kern.ipc.piperesizefail: 0 kern.ipc.pipeallocfail: 0 kern.ipc.pipefragretry: 0 kern.ipc.pipekva: 573440 kern.ipc.pipes: 70 kern.ipc.maxpipekva: 20971520 kern.ipc.msgseg: 2048 kern.ipc.msgssz: 8 kern.ipc.msgtql: 40 kern.ipc.msgmnb: 2048 kern.ipc.msgmni: 40 kern.ipc.msgmax: 16384 kern.ipc.semaem: 16384 kern.ipc.semvmx: 32767 kern.ipc.semusz: 104 kern.ipc.semume: 10 kern.ipc.semopm: 100 kern.ipc.semmsl: 60 kern.ipc.semmnu: 30 kern.ipc.semmns: 60 kern.ipc.semmni: 10 kern.ipc.semmap: 30 kern.ipc.shm_allow_removed: 0 kern.ipc.shm_use_phys: 0 kern.ipc.shmall: 8192 kern.ipc.shmseg: 128 kern.ipc.shmmni: 192 kern.ipc.shmmin: 1 kern.ipc.shmmax: 33554432 kern.ipc.numopensockets: 242 kern.ipc.maxsockets: 49152 kern.ipc.nsfbufsused: 0 kern.ipc.nsfbufspeak: 0 kern.ipc.nsfbufs: 0 kern.dummy: 0 kern.ps_strings: 140737488355296 kern.usrstack: 140737488355328 kern.logsigexit: 1 kern.iov_max: 1024 kern.cam.cam_srch_hi: 0 kern.cam.scsi_delay: 5000 kern.cam.da.da_send_ordered: 1 kern.cam.da.default_timeout: 60 kern.cam.da.retry_count: 4 kern.disks: amrd0 kern.geom.collectstats: 1 kern.geom.debugflags: 0 kern.elf64.fallback_brand: -1 kern.init_shutdown_timeout: 120 kern.init_path: /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall kern.acct_suspended: 0 kern.acct_chkfreq: 15 kern.acct_resume: 4 kern.acct_suspend: 2 kern.cp_time: 3062137 254 19559404 40888455 1023677682 kern.openfiles: 295 kern.kq_calloutmax: 4096 kern.ps_arg_cache_limit: 256 kern.stackprot: 7 kern.randompid: 0 kern.lastpid: 11060 kern.ktrace.request_pool: 100 kern.ktrace.genio_size: 4096 kern.module_path: /boot/kernel;/boot/modules kern.malloc_count: 170 kern.malloc: Type InUse MemUse HighUse Requests Size(s) linux 15 1K - 15 64 acpica 2245 242K - 20942 16,32,64,128,256,512,1024,4096 atkbddev 1 1K - 1 64 acpidev 69 5K - 69 64 CAM periph 1 1K - 1 256 nexusdev 2 1K - 2 16 I/O APIC 4 8K - 4 2048 isadev 8 1K - 8 128 GEOM 98 23K - 599 16,32,64,128,256,512,1024,2048,4096 memdesc 1 4K - 1 4096 CAM SIM 1 1K - 1 128 pfs_vncache 1 1K - 169 64 pfs_nodes 165 21K - 165 128 VM pgdata 2 129K - 2 128 DEVFS 11 1K - 12 16,256 DEVFS3 104 26K - 105 256 DEVFS1 94 47K - 94 512 UMAHash 3 10K - 9 512,1024,2048,4096 UFS mount 18 77K - 21 512,2048,4096 UFS dirhash 216 40K - 5706 16,32,64,128,512 pagedep 1 128K - 93336 128 inodedep 3 513K - 2273934 256 newblk 1 1K - 5505148 64,512 bmsafemap 2 1K - 134644 128 allocdirect 1 1K - 3102854 256 indirdep 1 1K - 119569 64 allocindir 1 1K - 2402293 128 freefrag 0 0K - 162148 64 freeblks 0 0K - 2377280 256 freefile 0 0K - 2076360 64 diradd 0 0K - 3275441 64 mkdir 0 0K - 153292 64 dirrem 0 0K - 3253416 64 newdirblk 0 0K - 1672 64 savedino 0 0K - 44222 256 p1003.1b 1 1K - 1 16 NFS daemon 1 16K - 1 NFS req 0 0K - 241605 128 NFSV3 diroff 0 0K - 34 512 syncache 1 12K - 1 USB 76 13K - 76 16,32,64,128,256,512 hostcache 1 48K - 1 IpFw/IpAcct 20 4K - 60 64,128,2048 in_multi 2 1K - 2 64 routetbl 144 67K - 276361 32,64,128,256,512 USBdev 21 8K - 21 16,128,256,512 lo 1 1K - 1 32 arpcom 2 1K - 2 32 clone 3 12K - 3 4096 ifnet 4 7K - 4 512,2048 ifaddr 26 9K - 28 32,64,512,4096 ether_multi 7 1K - 8 16,64 BPF 3 1K - 3 128 entropy 1024 64K - 1024 64 mount 154 7K - 313 16,32,64,128,256,2048 vnodemarker 0 0K - 1634619 512 vnodes 4 1K - 8 32,256 VFS hash 1 512K - 1 cluster_save buffer 0 0K - 14420 64,128 vfscache 1 1024K - 1 BIO buffer 5 10K - 72464 1024,2048 acd_driver 1 2K - 1 2048 soname 30 4K - 21016379 16,32,128 pcb 18 9K - 670693 16,32,64,128,4096 mbuf_tag 0 0K - 6 32 mbextcnt 2084 33K -5863097811 16 accf 5 1K - 13 32,64 ptys 4 1K - 4 256 ttys 1272 180K - 25579 128,1024 shm 1 16K - 1 sem 4 8K - 4 1024,2048,4096 msg 4 30K - 4 2048,4096 ioctlops 0 0K - 12439705 16,32,64,128,256,512,1024,2048,4096 iov 0 0K - 7742097 16,64,128,256,4096 Unitno 11 1K - 307567 32,64 turnstiles 175 22K - 535 128 taskqueue 11 2K - 11 16,32,256 sleep queues 175 11K - 535 64 sbuf 0 0K - 572 16,32,64,128,256,512,1024,2048,4096 ata_dma 2 1K - 2 256 rman 112 14K - 563 128 ata_generic 1 1K - 1 1024 kobj 114 456K - 137 4096 CAM queue 3 1K - 3 16 eventhandler 49 6K - 49 64,256 devstat 10 21K - 10 32,4096 bus 611 56K - 4458 16,32,64,128,256,1024 bus-sc 58 46K - 1318 16,32,64,128,256,512,1024,2048,4096 CAM dev queue 1 1K - 1 128 SWAP 2 277K - 2 64 umtx 174 22K - 534 128 sysctl 0 0K - 2276639 16,32,64 sysctloid 2595 127K - 2595 16,32,64,128 sysctltmp 0 0K - 19768 16,32,128 plimit 20 5K - 1095118 256 uidinfo 5 3K - 140199 64,2048 cred 93 24K - 27114414 256 acpisem 18 3K - 18 128 pgrp 28 4K - 314540 128 session 25 7K - 314158 256 proc 2 16K - 2 subproc 245 417K - 1409454 512,4096 mtx_pool 1 12K - 1 module 204 26K - 205 128 devbuf 8267 17079K - 1581116 16,32,64,128,256,512,1024,2048,4096 temp 150 291K - 2845308 16,32,64,128,256,512,1024,2048,4096 lockf 7 1K - 1555519 128 linker 51 5K - 113 16,32,64,128,512 KTRACE 100 13K - 100 128 ithread 144 30K - 144 32,128,256 zombie 0 0K - 1409209 256 proc-args 31 2K - 2116635 16,32,64,128,256 kqueue 2 5K - 1206487 512,2048,4096 kenv 71 11K - 72 16,32,64 file desc 92 57K - 1411206 16,32,64,128,512,1024,2048,4096 sigio 1 1K - 1 64 CAM XPT 6 1K - 9 32,128,512 cdev 23 6K - 23 256 acpitask 0 0K - 1 64 PCI Link 16 2K - 16 32,128 kern.fallback_elf_brand: -1 kern.maxusers: 384 kern.ident: SMP-amd64 kern.polling.idlepoll_sleeping: 1 kern.polling.stalled: 0 kern.polling.suspect: 0 kern.polling.phase: 0 kern.polling.enable: 0 kern.polling.handlers: 0 kern.polling.residual_burst: 0 kern.polling.pending_polls: 0 kern.polling.lost_polls: 0 kern.polling.short_ticks: 0 kern.polling.reg_frac: 20 kern.polling.user_frac: 50 kern.polling.idle_poll: 0 kern.polling.each_burst: 5 kern.polling.burst_max: 150 kern.polling.burst: 5 kern.kstack_pages: 4 kern.shutdown.kproc_shutdown_wait: 60 kern.shutdown.poweroff_delay: 5000 kern.sync_on_panic: 0 kern.corefile: %N.core kern.nodump_coredump: 0 kern.coredump: 0 kern.sugid_coredump: 0 kern.fscale: 2048 kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) ACPI-fast(1000) HPET(2000) i8254(0) dummy(-1000000) kern.timecounter.hardware: HPET kern.timecounter.nsetclock: 3 kern.timecounter.ngetmicrotime: 408535457 kern.timecounter.ngetnanotime: 0 kern.timecounter.ngetbintime: 0 kern.timecounter.ngetmicrouptime: 1191179415 kern.timecounter.ngetnanouptime: 1188431 kern.timecounter.ngetbinuptime: 2665117 kern.timecounter.nmicrotime: 2825851990 kern.timecounter.nnanotime: 4427452 kern.timecounter.nbintime: 2830279204 kern.timecounter.nmicrouptime: 1409332 kern.timecounter.nnanouptime: 1395210 kern.timecounter.nbinuptime: 293850150 kern.timecounter.stepwarnings: 0 kern.timecounter.smp_tsc: 0 kern.threads.thr_concurrency: 0 kern.threads.thr_scope: 0 kern.threads.virtual_cpu: 2 kern.threads.max_threads_hits: 0 kern.threads.max_groups_per_proc: 1500 kern.threads.max_threads_per_proc: 1500 kern.threads.debug: 0 kern.ccpu: 1948 kern.sched.runq_fuzz: 1 kern.sched.preemption: 1 kern.sched.kgfollowons: 0 kern.sched.pfollowons: 0 kern.sched.followon: 0 kern.sched.ipiwakeup.htt2: 0 kern.sched.ipiwakeup.onecpu: 0 kern.sched.ipiwakeup.useloop: 0 kern.sched.ipiwakeup.usemask: 1 kern.sched.ipiwakeup.delivered: 61457042 kern.sched.ipiwakeup.requested: 61445760 kern.sched.ipiwakeup.enabled: 1 kern.sched.quantum: 100000 kern.sched.name: 4BSD kern.devstat.version: 6 kern.devstat.generation: 147 kern.devstat.numdevs: 1 kern.kobj_methodcount: 89 kern.log_wakeups_per_second: 5 kern.msgbuf_clear: 0 kern.msgbuf: kern.always_console_output: 0 kern.log_console_output: 1 kern.smp.forward_roundrobin_enabled: 1 kern.smp.forward_signal_enabled: 1 kern.smp.cpus: 2 kern.smp.disabled: 0 kern.smp.active: 1 kern.smp.maxcpus: 16 kern.nselcoll: 346 kern.tty_nout: 12466877 kern.tty_nin: 14015 kern.drainwait: 300 kern.constty_wakeups_per_second: 5 kern.consmsgbuf_size: 8192 kern.consmute: 0 kern.console: consolectl,/ttyd0,consolectl, kern.minvnodes: 25000 kern.metadelay: 28 kern.dirdelay: 29 kern.filedelay: 30 kern.chroot_allow_open_directories: 1 kern.rpc.invalid: 0 kern.rpc.unexpected: 0 kern.rpc.timeouts: 0 kern.rpc.request: 0 kern.rpc.retries: 0 kern.elf32.fallback_brand: -1 kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 192 kern.random.yarrow.slowthresh: 256 kern.random.yarrow.slowoverthresh: 2 kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 kern.random.sys.harvest.interrupt: 1 kern.random.sys.harvest.swi: 0 vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 37) Virtual Memory: (Total: 4464588K, Active 91256K) Real Memory: (Total: 80516K Active 39540K) Shared Virtual Memory: (Total: 33300K Active: 30736K) Shared Real Memory: (Total: 12308K Active: 11012K) Free Memory Pages: 115256K vm.loadavg: { 0.08 0.10 0.08 } vm.v_free_min: 6456 vm.v_free_target: 27223 vm.v_free_reserved: 1399 vm.v_inactive_target: 40834 vm.v_cache_min: 27223 vm.v_cache_max: 54446 vm.v_pageout_free_min: 34 vm.pageout_algorithm: 0 vm.swap_enabled: 1 vm.kmem_size_scale: 3 vm.kmem_size_max: 419430400 vm.kmem_size: 419430400 vm.nswapdev: 1 vm.dmmax: 32 vm.swap_async_max: 4 vm.zone_count: 71 vm.zone: ITEM SIZE LIMIT USED FREE REQUESTS FFS2 dinode: 256, 0, 31153, 2117, 2665117 FFS1 dinode: 128, 0, 0, 0, 0 FFS inode: 192, 0, 31153, 3227, 2665117 Mountpoints: 792, 0, 10, 5, 11 SWAPMETA: 288, 116519, 1, 12, 398 IPFW dynamic: 120, 0, 161, 273, 760623 divcb: 304, 49152, 0, 0, 0 rtentry: 264, 0, 7, 35, 37 unpcb: 200, 49153, 42, 262, 1842480 ripcb: 304, 49152, 0, 36, 152 sackhole: 32, 0, 13, 492, 217243049 tcpreass: 40, 2100, 0, 420, 247314 hostcache: 136, 15372, 2339, 209, 1587635 syncache: 128, 15370, 2, 143, 7427992 tcptw: 80, 8235, 42, 588, 2262469 tcpcb: 752, 49155, 193, 1357, 7474435 inpcb: 304, 49152, 235, 1373, 7474435 udpcb: 304, 49152, 7, 41, 1228897 ipq: 56, 1071, 0, 0, 40238 socket: 616, 49152, 242, 1672, 10545969 KNOTE: 120, 0, 101, 271, 6365204681 PIPE: 768, 0, 35, 110, 1054714 DIRHASH: 1024, 0, 203, 133, 4276 NFSNODE: 664, 0, 20, 34, 19966 NFSMOUNT: 584, 0, 2, 5, 2 L VFS Cache: 327, 0, 226, 314, 37258 S VFS Cache: 104, 0, 30642, 10938, 4538089 NAMEI: 1024, 0, 0, 260, 3822013249 VNODEPOLL: 152, 0, 0, 50, 1 VNODE: 496, 0, 31220, 18948, 2685452 ata_composit: 376, 0, 0, 0, 0 ata_request: 336, 0, 0, 22, 24 g_bio: 216, 0, 4, 266, 147855894 ACL UMA zone: 388, 0, 0, 0, 0 mbuf_jumbo_1: 16384, 0, 0, 0, 0 mbuf_jumbo_9: 9216, 0, 0, 0, 0 mbuf_jumbo_p: 4096, 0, 0, 0, 0 mbuf_cluster: 2048, 32768, 467, 111, 7519060757 mbuf: 256, 0, 2552, 433, 38882139786 mbuf_packet: 256, 0, 2473, 512, 8364630232 VMSPACE: 544, 0, 36, 76, 1421522 UPCALL: 88, 0, 3, 73, 3 KSEGRP: 136, 0, 161, 73, 161 THREAD: 608, 0, 165, 9, 153943 PROC: 856, 0, 83, 77, 1409292 Files: 120, 0, 296, 386, 3661475205 4096: 4096, 0, 240, 235, 2359833 2048: 2048, 0, 29, 161, 749612 1024: 1024, 0, 50, 222, 265791 512: 512, 0, 599, 255, 4069145 256: 256, 0, 609, 261, 38331006 128: 128, 0, 4928, 640, 13840622 64: 64, 0, 6319, 737, 23251477 32: 32, 0, 1279, 337, 3465149 16: 16, 0, 3660, 4404, 5890917059 mt_zone: 1024, 0, 170, 6, 170 DP fakepg: 120, 0, 0, 0, 0 PV ENTRY: 48, 2244600, 20590, 36218, 1346939535 MAP ENTRY: 112, 0, 1439, 1036, 107995821 KMAP ENTRY: 112, 90222, 292, 1490, 8014685 MAP: 352, 0, 7, 15, 7 VM OBJECT: 224, 0, 9271, 32957, 39999957 128 Bucket: 1048, 0, 248, 91, 4519 64 Bucket: 536, 0, 27, 43, 83 32 Bucket: 280, 0, 16, 54, 67 16 Bucket: 152, 0, 51, 49, 81 UMA Hash: 256, 0, 4, 11, 7 UMA RCntSlab: 128, 0, 289, 59, 998251 UMA Slabs: 128, 0, 881, 134, 880304 UMA Zones: 376, 0, 69, 1, 69 UMA Kegs: 240, 0, 69, 6, 69 vm.old_contigmalloc: 0 vm.swap_idle_threshold2: 10 vm.swap_idle_threshold1: 2 vm.exec_map_entries: 16 vm.stats.misc.zero_page_count: 1010 vm.stats.misc.cnt_prezero: 78684204 vm.stats.vm.v_kthreadpages: 0 vm.stats.vm.v_rforkpages: 0 vm.stats.vm.v_vforkpages: 11011007 vm.stats.vm.v_forkpages: 328234200 vm.stats.vm.v_kthreads: 53 vm.stats.vm.v_rforks: 0 vm.stats.vm.v_vforks: 114153 vm.stats.vm.v_forks: 1295086 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_cache_max: 54446 vm.stats.vm.v_cache_min: 27223 vm.stats.vm.v_cache_count: 27329 vm.stats.vm.v_inactive_count: 890787 vm.stats.vm.v_inactive_target: 40834 vm.stats.vm.v_active_count: 11742 vm.stats.vm.v_wire_count: 63202 vm.stats.vm.v_free_count: 1467 vm.stats.vm.v_free_min: 6456 vm.stats.vm.v_free_target: 27223 vm.stats.vm.v_free_reserved: 1399 vm.stats.vm.v_page_count: 1011794 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_tfree: 723316037 vm.stats.vm.v_pfree: 121750948 vm.stats.vm.v_dfree: 121 vm.stats.vm.v_pdpages: 546500114 vm.stats.vm.v_pdwakeups: 19084 vm.stats.vm.v_reactivated: 231346 vm.stats.vm.v_intrans: 3132 vm.stats.vm.v_vnodepgsout: 0 vm.stats.vm.v_vnodepgsin: 82081 vm.stats.vm.v_vnodeout: 0 vm.stats.vm.v_vnodein: 24268 vm.stats.vm.v_swappgsout: 377 vm.stats.vm.v_swappgsin: 339 vm.stats.vm.v_swapout: 374 vm.stats.vm.v_swapin: 335 vm.stats.vm.v_ozfod: 42609991 vm.stats.vm.v_zfod: 84134694 vm.stats.vm.v_cow_optim: 2529 vm.stats.vm.v_cow_faults: 71443486 vm.stats.vm.v_vm_faults: 208731149 vm.stats.sys.v_soft: 8869351 vm.stats.sys.v_intr: 908914123 vm.stats.sys.v_syscall: 1726552299 vm.stats.sys.v_trap: 2945088101 vm.stats.sys.v_swtch: 1463628763 vm.v_free_severe: 3927 vm.max_proc_mmap: 37449 vm.old_msync: 0 vm.msync_flush_flags: 3 vm.boot_pages: 48 vm.pageout_lock_miss: 0 vm.disable_swapspace_pageouts: 0 vm.defer_swapspace_pageouts: 0 vm.swap_idle_enabled: 0 vm.pageout_stats_interval: 5 vm.pageout_full_stats_interval: 20 vm.pageout_stats_max: 27223 vm.max_launder: 32 vm.idlezero_maxrun: 16 vm.idlezero_enable: 1 vm.kvm_free: 1226829824 vm.kvm_size: 2147479552 vfs.nfs.downdelayinitial: 12 vfs.nfs.downdelayinterval: 30 vfs.nfs.nfs3_jukebox_delay: 10 vfs.nfs.reconnects: 0 vfs.nfs.bufpackets: 4 vfs.nfs.realign_count: 0 vfs.nfs.realign_test: 241605 vfs.nfs.defect: 0 vfs.nfs.iodmax: 20 vfs.nfs.iodmin: 0 vfs.nfs.iodmaxidle: 120 vfs.nfs.diskless_rootpath: vfs.nfs.diskless_valid: 0 vfs.nfs.nfs_ip_paranoia: 1 vfs.nfs.nfs_directio_allow_mmap: 1 vfs.nfs.nfs_directio_enable: 0 vfs.nfs.clean_pages_on_close: 1 vfs.nfs.nfsv3_commit_on_close: 0 vfs.nfs.access_cache_timeout: 60 vfs.ufs.dirhash_docheck: 0 vfs.ufs.dirhash_mem: 240482 vfs.ufs.dirhash_maxmem: 33554432 vfs.ufs.dirhash_minsize: 2560 vfs.devfs.rule_depth: 1 vfs.devfs.generation: 94 vfs.nfs4.nfsv3_commit_on_close: 0 vfs.nfs4.access_cache_timeout: 60 vfs.pfs.vncache.misses: 169 vfs.pfs.vncache.hits: 125 vfs.pfs.vncache.maxentries: 96 vfs.pfs.vncache.entries: 1 vfs.flushwithdeps: 0 vfs.getnewbufrestarts: 6850679 vfs.getnewbufcalls: 37407273 vfs.hifreebuffers: 1540 vfs.lofreebuffers: 770 vfs.numfreebuffers: 13754 vfs.dirtybufthresh: 3115 vfs.hidirtybuffers: 3462 vfs.lodirtybuffers: 1731 vfs.numdirtybuffers: 15 vfs.recursiveflushes: 0 vfs.altbufferflushes: 0 vfs.bdwriteskip: 0 vfs.dirtybufferflushes: 0 vfs.hirunningspace: 1048576 vfs.lorunningspace: 524288 vfs.bufdefragcnt: 3064630 vfs.buffreekvacnt: 4676556 vfs.bufreusecnt: 4680388 vfs.hibufspace: 224968704 vfs.lobufspace: 224903168 vfs.maxmallocbufspace: 11248435 vfs.bufmallocspace: 10240 vfs.maxbufspace: 225624064 vfs.bufspace: 217923584 vfs.runningbufspace: 0 vfs.vmiodirenable: 1 vfs.cache.numfullpathfound: 260787 vfs.cache.numfullpathfail4: 0 vfs.cache.numfullpathfail2: 0 vfs.cache.numfullpathfail1: 1 vfs.cache.numfullpathcalls: 260788 vfs.cache.nchstats: 26325721396 33299751 3068375 0 8638501 0 194947 364966 vfs.cache.numneghits: 33299751 vfs.cache.numnegzaps: 857827 vfs.cache.numposhits: 26325721396 vfs.cache.numposzaps: 2210548 vfs.cache.nummisszap: 2757267 vfs.cache.nummiss: 5881234 vfs.cache.numchecks: 31702575347 vfs.cache.dotdothits: 196200 vfs.cache.dothits: 161626 vfs.cache.numcalls: 26371085849 vfs.cache.numcache: 30868 vfs.cache.numneg: 1115 vfs.read_max: 8 vfs.write_behind: 1 vfs.lookup_shared: 0 vfs.usermount: 0 vfs.worklist_len: 5 vfs.timestamp_precision: 0 vfs.reassignbufcalls: 16981143 vfs.freevnodes: 24772 vfs.wantfreevnodes: 25000 vfs.numvnodes: 31220 vfs.nfsrv.nfs_privport: 0 vfs.nfsrv.commit_miss: 0 vfs.nfsrv.commit_blks: 0 vfs.nfsrv.async: 0 vfs.nfsrv.realign_count: 0 vfs.nfsrv.realign_test: 0 vfs.nfsrv.gatherdelay_v3: 0 vfs.nfsrv.gatherdelay: 10000 vfs.ffs.doreallocblks: 1 vfs.ffs.doasyncfree: 1 vfs.ffs.compute_summary_at_mount: 0 net.local.stream.recvspace: 8192 net.local.stream.sendspace: 8192 net.local.dgram.recvspace: 4096 net.local.dgram.maxdgram: 2048 net.local.recycled: 0 net.local.taskcount: 0 net.local.inflight: 0 net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 49152 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.forwarding: 0 net.inet.ip.redirect: 0 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 50 net.inet.ip.intr_queue_drops: 72078 net.inet.ip.accept_sourceroute: 0 net.inet.ip.keepfaith: 0 net.inet.ip.same_prefix_carp_only: 0 net.inet.ip.subnets_are_local: 0 net.inet.ip.dummynet.debug: 0 net.inet.ip.dummynet.tick_lost: 0 net.inet.ip.dummynet.tick_diff: 7104348 net.inet.ip.dummynet.tick_adjustment: 6728079 net.inet.ip.dummynet.tick_delta_sum: 168 net.inet.ip.dummynet.tick_delta: 8 net.inet.ip.dummynet.red_max_pkt_size: 1500 net.inet.ip.dummynet.red_avg_pkt_size: 512 net.inet.ip.dummynet.red_lookup_depth: 256 net.inet.ip.dummynet.max_chain_len: 16 net.inet.ip.dummynet.expire: 1 net.inet.ip.dummynet.search_steps: 0 net.inet.ip.dummynet.searches: 0 net.inet.ip.dummynet.extract_heap: 0 net.inet.ip.dummynet.ready_heap: 0 net.inet.ip.dummynet.curr_time: 4091820365 net.inet.ip.dummynet.hash_size: 64 net.inet.ip.fastforwarding: 0 net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.static_count: 19 net.inet.ip.fw.dyn_max: 4096 net.inet.ip.fw.dyn_count: 161 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_buckets: 256 net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.verbose: 1 net.inet.ip.fw.debug: 1 net.inet.ip.fw.one_pass: 1 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.enable: 1 net.inet.ip.maxfragpackets: 1024 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.fragpackets: 0 net.inet.ip.check_interface: 0 net.inet.ip.random_id: 0 net.inet.ip.sendsourcequench: 0 net.inet.ip.process_options: 1 net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 100 net.inet.icmp.bmcastecho: 0 net.inet.icmp.quotelen: 8 net.inet.icmp.reply_from_interface: 0 net.inet.icmp.reply_src: net.inet.icmp.icmplim_output: 1 net.inet.icmp.log_redirect: 0 net.inet.icmp.drop_redirect: 1 net.inet.icmp.maskfake: 0 net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 65536 net.inet.tcp.recvspace: 32768 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 2339 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.reass.overflows: 0 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 2048 net.inet.tcp.insecure_rst: 0 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.drop_synfin: 1 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 1 net.inet.tcp.log_in_vain: 0 net.inet.tcp.newreno: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.sack.globalholes: 14 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.inflight.stab: 20 net.inet.tcp.inflight.max: 1073725440 net.inet.tcp.inflight.min: 6144 net.inet.tcp.inflight.rttthresh: 10 net.inet.tcp.inflight.debug: 0 net.inet.tcp.inflight.enable: 1 net.inet.tcp.nolocaltimewait: 0 net.inet.tcp.maxtcptw: 8191 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 235 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.minmssoverload: 0 net.inet.tcp.minmss: 216 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 2 net.inet.tcp.syncache.cachelimit: 15359 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies: 1 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 3 net.inet.tcp.msl: 30000 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 41600 net.inet.udp.strict_mcast_mship: 0 net.inet.udp.blackhole: 1 net.inet.udp.log_in_vain: 0 net.inet.carp.allow: 1 net.inet.carp.preempt: 0 net.inet.carp.log: 1 net.inet.carp.arpbalance: 0 net.inet.carp.suppress_preempt: 0 net.inet.raw.recvspace: 9216 net.inet.raw.maxdgram: 9216 net.inet.ipf.fr_minttl: 4 net.inet.ipf.fr_chksrc: 0 net.inet.ipf.fr_defaultauthage: 600 net.inet.ipf.fr_authused: 0 net.inet.ipf.fr_authsize: 32 net.inet.ipf.ipf_hostmap_sz: 2047 net.inet.ipf.ipf_rdrrules_sz: 127 net.inet.ipf.ipf_natrules_sz: 127 net.inet.ipf.ipf_nattable_sz: 2047 net.inet.ipf.fr_statemax: 4013 net.inet.ipf.fr_statesize: 5737 net.inet.ipf.fr_running: 1 net.inet.ipf.fr_ipfrttl: 120 net.inet.ipf.fr_defnatage: 1200 net.inet.ipf.fr_icmptimeout: 120 net.inet.ipf.fr_udpacktimeout: 24 net.inet.ipf.fr_udptimeout: 240 net.inet.ipf.fr_tcpclosed: 120 net.inet.ipf.fr_tcptimeout: 480 net.inet.ipf.fr_tcplastack: 480 net.inet.ipf.fr_tcpclosewait: 480 net.inet.ipf.fr_tcphalfclosed: 14400 net.inet.ipf.fr_tcpidletimeout: 864000 net.inet.ipf.fr_active: 0 net.inet.ipf.fr_pass: 134217730 net.inet.ipf.fr_flags: 0 net.inet.accf.unloadable: 0 net.inet.accf.http.parsehttpversion: 1 net.link.generic.system.ifcount: 3 net.link.ether.inet.log_arp_permanent_modify: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.proxyall: 0 net.link.ether.inet.useloopback: 1 net.link.ether.inet.maxtries: 5 net.link.ether.inet.max_age: 1200 net.link.ether.inet.prune_intvl: 300 net.link.ether.ipfw: 0 net.link.log_link_state_change: 1 net.link.tun.devfs_cloning: 1 net.bpf.maxinsns: 512 net.bpf.maxbufsize: 524288 net.bpf.bufsize: 4096 net.isr.swi_count: 1577955123 net.isr.drop: 0 net.isr.queued: 8308 net.isr.deferred: -261229993 net.isr.directed: 0 net.isr.count: -261229992 net.isr.direct: 0 net.route.netisr_maxqlen: 256 debug.acpi.semaphore_debug: 0 debug.acpi.suspend_bounce: 0 debug.acpi.do_powerstate: 1 debug.acpi.acpi_ca_version: 0x20041119 debug.mddebug: 0 debug.elf64_legacy_coredump: 0 debug.elf64_trace: 0 debug.bootverbose: 0 debug.boothowto: 0 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 debug.sizeof.cdev_priv: 336 debug.sizeof.cdev: 288 debug.sizeof.g_bioq: 96 debug.sizeof.g_consumer: 96 debug.sizeof.g_provider: 136 debug.sizeof.g_geom: 136 debug.sizeof.g_class: 136 debug.sizeof.kinfo_proc: 1088 debug.sizeof.buf: 584 debug.sizeof.bio: 216 debug.sizeof.proc: 856 debug.sizeof.vnode: 496 debug.sizeof.devstat: 288 debug.to_avg_mpcalls: 1209 debug.to_avg_mtxcalls: 0 debug.to_avg_gcalls: 0 debug.to_avg_depth: 1251 debug.kdb.stop_cpus: 1 debug.kdb.enter: 0 debug.kdb.current: debug.kdb.available: debug.rman_debug: 0 debug.ttydebug: 0 debug.disablefullpath: 0 debug.disablecwd: 0 debug.hashstat.nchash: 131072 27468 4 2095 debug.ncsize: 72 debug.vnsize: 496 debug.vfscache: 1 debug.numcachehv: 4757 debug.numcache: 30868 debug.numneg: 1115 debug.ncnegfactor: 16 debug.nchash: 131071 debug.vnlru_nowhere: 0 debug.rush_requests: 0 debug.mpsafevfs: 1 debug.if_tun_debug: 0 debug.mpsafenet: 1 debug.collectsnapstats: 0 debug.snapdebug: 0 debug.dopersistence: 0 debug.dir_entry: 19483 debug.direct_blk_ptrs: 22023 debug.inode_bitmap: 13973 debug.indir_blk_ptrs: 75044 debug.sync_limit_hit: 0 debug.ino_limit_hit: 0 debug.blk_limit_hit: 0 debug.ino_limit_push: 0 debug.blk_limit_push: 0 debug.worklist_push: 0 debug.maxindirdeps: 50 debug.tickdelay: 2 debug.max_softdeps: 400000 debug.dobkgrdwrite: 1 debug.bigcgs: 0 debug.dircheck: 0 debug.nosleepwithlocks: 0 debug.mpsafevm: 1 debug.minidump: 0 debug.fdc.settle: 125 debug.fdc.spec2: 16 debug.fdc.spec1: 175 debug.fdc.retries: 10 debug.fdc.debugflags: 0 debug.fdc.fifo: 8 debug.elf32_legacy_coredump: 0 debug.elf32_trace: 0 hw.machine: amd64 hw.model: Intel(R) Xeon(TM) CPU 3.20GHz hw.ncpu: 2 hw.byteorder: 1234 hw.physmem: 4286275584 hw.usermem: 4027437056 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: amd64 hw.realmem: 4831838208 hw.amr.force_sg32: 0 hw.ata.wc: 1 hw.ata.atapi_dma: 1 hw.ata.ata_dma: 1 hw.bce.msi_enable: 1 hw.bge.allow_asf: 0 hw.bge.fake_autoneg: 0 hw.mfi.event_class: 0 hw.mfi.event_locale: 65535 hw.pci.honor_msi_blacklist: 1 hw.pci.enable_msix: 0 hw.pci.enable_msi: 0 hw.pci.do_power_resume: 1 hw.pci.do_power_nodriver: 0 hw.pci.enable_io_modes: 1 hw.pci.host_mem_start: 2147483648 hw.intr_storm_threshold: 1000 hw.availpages: 1046454 hw.bus.devctl_disable: 0 hw.busdma.total_bpages: 3905 hw.busdma.zone0.total_bpages: 3872 hw.busdma.zone0.free_bpages: 3872 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 0 hw.busdma.zone0.total_bounced: 971252 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.alignment: 1 hw.busdma.zone0.boundary: 0 hw.busdma.zone1.total_bpages: 1 hw.busdma.zone1.free_bpages: 1 hw.busdma.zone1.reserved_bpages: 0 hw.busdma.zone1.active_bpages: 0 hw.busdma.zone1.total_bounced: 0 hw.busdma.zone1.total_deferred: 0 hw.busdma.zone1.lowaddr: 0xffffffff hw.busdma.zone1.alignment: 4096 hw.busdma.zone1.boundary: 0 hw.busdma.zone2.total_bpages: 32 hw.busdma.zone2.free_bpages: 32 hw.busdma.zone2.reserved_bpages: 0 hw.busdma.zone2.active_bpages: 0 hw.busdma.zone2.total_bounced: 0 hw.busdma.zone2.total_deferred: 0 hw.busdma.zone2.lowaddr: 0xffffffff hw.busdma.zone2.alignment: 2 hw.busdma.zone2.boundary: 65536 hw.clockrate: 3192 hw.instruction_sse: 1 hw.apic.enable_extint: 0 hw.kbd.keymap_restrict_change: 0 hw.syscons.kbd_debug: 1 hw.syscons.kbd_reboot: 1 hw.syscons.bell: 1 hw.syscons.saver.keybonly: 1 hw.syscons.sc_no_suspend_vtswitch: 0 hw.acpi.supported_sleep_state: S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S4 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.cpu.cx_lowest: C1 machdep.adjkerntz: -14400 machdep.disable_rtc_set: 0 machdep.wall_cmos_clock: 1 machdep.acpi_timer_freq: 3579545 machdep.acpi_root: 1037744 machdep.disable_mtrrs: 0 machdep.cpu_idle_hlt: 1 machdep.hlt_cpus: 0 machdep.panic_on_nmi: 1 machdep.tsc_freq: 3192012016 machdep.i8254_freq: 1193182 machdep.conspeed: 9600 machdep.gdbspeed: 9600 machdep.conrclk: 1843200 machdep.enable_panic_key: 0 user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: user.bc_base_max: 99 user.bc_dim_max: 2048 user.bc_scale_max: 99 user.bc_string_max: 1000 user.coll_weights_max: 0 user.expr_nest_max: 32 user.line_max: 2048 user.re_dup_max: 255 user.posix2_version: 199212 user.posix2_c_bind: 0 user.posix2_c_dev: 0 user.posix2_char_term: 0 user.posix2_fort_dev: 0 user.posix2_fort_run: 0 user.posix2_localedef: 0 user.posix2_sw_dev: 0 user.posix2_upe: 0 user.stream_max: 20 user.tzname_max: 255 p1003_1b.asynchronous_io: 0 p1003_1b.mapped_files: 1 p1003_1b.memlock: 0 p1003_1b.memlock_range: 0 p1003_1b.memory_protection: 0 p1003_1b.message_passing: 0 p1003_1b.prioritized_io: 0 p1003_1b.priority_scheduling: 1 p1003_1b.realtime_signals: 0 p1003_1b.semaphores: 0 p1003_1b.fsync: 0 p1003_1b.shared_memory_objects: 1 p1003_1b.synchronized_io: 0 p1003_1b.timers: 0 p1003_1b.aio_listio_max: -1 p1003_1b.aio_max: -1 p1003_1b.aio_prio_delta_max: -1 p1003_1b.delaytimer_max: 0 p1003_1b.mq_open_max: 0 p1003_1b.pagesize: 4096 p1003_1b.rtsig_max: 0 p1003_1b.sem_nsems_max: 0 p1003_1b.sem_value_max: 0 p1003_1b.sigqueue_max: 0 p1003_1b.timer_max: 0 security.jail.jailed: 0 security.jail.chflags_allowed: 0 security.jail.allow_raw_sockets: 1 security.jail.enforce_statfs: 2 security.jail.sysvipc_allowed: 0 security.jail.socket_unixiproute_only: 1 security.jail.set_hostname_allowed: 1 security.bsd.unprivileged_proc_debug: 1 security.bsd.conservative_signals: 1 security.bsd.see_other_gids: 1 security.bsd.see_other_uids: 1 security.bsd.suser_enabled: 1 security.bsd.unprivileged_read_msgbuf: 1 security.bsd.hardlink_check_gid: 0 security.bsd.hardlink_check_uid: 0 security.bsd.unprivileged_get_quota: 0 compat.ia32.maxvmem: 0 compat.ia32.maxssiz: 67108864 compat.ia32.maxdsiz: 536870912 compat.linux32.maxvmem: 0 compat.linux32.maxssiz: 67108864 compat.linux32.maxdsiz: 536870912 compat.linux.oss_version: 198144 compat.linux.osrelease: 2.4.2 compat.linux.osname: Linux dev.nexus.0.%driver: nexus dev.nexus.0.%parent: root0 dev.acpi.0.%desc: DELL PE BKC dev.acpi.0.%driver: acpi dev.acpi.0.%parent: nexus0 dev.acpi_hpet.0.%desc: High Precision Event Timer dev.acpi_hpet.0.%driver: acpi_hpet dev.acpi_hpet.0.%location: unknown dev.acpi_hpet.0.%pnpinfo: unknown dev.acpi_hpet.0.%parent: acpi0 dev.acpi_sysresource.0.%desc: System Resource dev.acpi_sysresource.0.%driver: acpi_sysresource dev.acpi_sysresource.0.%location: handle=\_SB_.PCI0.ISA_.MBIO dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C01 _UID=0 dev.acpi_sysresource.0.%parent: acpi0 dev.acpi_sysresource.1.%desc: System Resource dev.acpi_sysresource.1.%driver: acpi_sysresource dev.acpi_sysresource.1.%location: handle=\_SB_.PCI0.ISA_.MBI1 dev.acpi_sysresource.1.%pnpinfo: _HID=PNP0C01 _UID=1 dev.acpi_sysresource.1.%parent: acpi0 dev.acpi_sysresource.2.%desc: System Resource dev.acpi_sysresource.2.%driver: acpi_sysresource dev.acpi_sysresource.2.%location: handle=\_SB_.PCI0.PEHB dev.acpi_sysresource.2.%pnpinfo: _HID=PNP0C02 _UID=0 dev.acpi_sysresource.2.%parent: acpi0 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_timer.0.%parent: acpi0 dev.pci_link.0.%desc: ACPI PCI Link LNKA dev.pci_link.0.%driver: pci_link dev.pci_link.0.%location: handle=\_SB_.LNKA dev.pci_link.0.%pnpinfo: _HID=PNP0C0F _UID=1 dev.pci_link.0.%parent: acpi0 dev.pci_link.1.%desc: ACPI PCI Link LNKB dev.pci_link.1.%driver: pci_link dev.pci_link.1.%location: handle=\_SB_.LNKB dev.pci_link.1.%pnpinfo: _HID=PNP0C0F _UID=2 dev.pci_link.1.%parent: acpi0 dev.pci_link.2.%desc: ACPI PCI Link LNKC dev.pci_link.2.%driver: pci_link dev.pci_link.2.%location: handle=\_SB_.LNKC dev.pci_link.2.%pnpinfo: _HID=PNP0C0F _UID=3 dev.pci_link.2.%parent: acpi0 dev.pci_link.3.%desc: ACPI PCI Link LNKD dev.pci_link.3.%driver: pci_link dev.pci_link.3.%location: handle=\_SB_.LNKD dev.pci_link.3.%pnpinfo: _HID=PNP0C0F _UID=4 dev.pci_link.3.%parent: acpi0 dev.pci_link.4.%desc: ACPI PCI Link LNKE dev.pci_link.4.%driver: pci_link dev.pci_link.4.%location: handle=\_SB_.LNKE dev.pci_link.4.%pnpinfo: _HID=PNP0C0F _UID=5 dev.pci_link.4.%parent: acpi0 dev.pci_link.5.%desc: ACPI PCI Link LNKF dev.pci_link.5.%driver: pci_link dev.pci_link.5.%location: handle=\_SB_.LNKF dev.pci_link.5.%pnpinfo: _HID=PNP0C0F _UID=6 dev.pci_link.5.%parent: acpi0 dev.pci_link.6.%desc: ACPI PCI Link LNKG dev.pci_link.6.%driver: pci_link dev.pci_link.6.%location: handle=\_SB_.LNKG dev.pci_link.6.%pnpinfo: _HID=PNP0C0F _UID=7 dev.pci_link.6.%parent: acpi0 dev.pci_link.7.%desc: ACPI PCI Link LNKH dev.pci_link.7.%driver: pci_link dev.pci_link.7.%location: handle=\_SB_.LNKH dev.pci_link.7.%pnpinfo: _HID=PNP0C0F _UID=8 dev.pci_link.7.%parent: acpi0 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.cx_supported: C1/0 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/0 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% dev.pcib.0.%desc: ACPI Host-PCI bridge dev.pcib.0.%driver: pcib dev.pcib.0.%location: handle=\_SB_.PCI0 dev.pcib.0.%pnpinfo: _HID=PNP0A03 _UID=1 dev.pcib.0.%parent: acpi0 dev.pcib.0.wake: 0 dev.pcib.1.%desc: ACPI PCI-PCI bridge dev.pcib.1.%driver: pcib dev.pcib.1.%location: slot=2 function=0 handle=\_SB_.PCI0.PALO dev.pcib.1.%pnpinfo: vendor=0x8086 device=0x3595 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.1.%parent: pci0 dev.pcib.1.wake: 0 dev.pcib.2.%desc: ACPI PCI-PCI bridge dev.pcib.2.%driver: pcib dev.pcib.2.%location: slot=0 function=0 handle=\_SB_.PCI0.PALO.DOBA dev.pcib.2.%pnpinfo: vendor=0x8086 device=0x0330 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.2.%parent: pci1 dev.pcib.3.%desc: ACPI PCI-PCI bridge dev.pcib.3.%driver: pcib dev.pcib.3.%location: slot=0 function=2 handle=\_SB_.PCI0.PALO.DOBB dev.pcib.3.%pnpinfo: vendor=0x8086 device=0x0332 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.3.%parent: pci1 dev.pcib.4.%desc: ACPI PCI-PCI bridge dev.pcib.4.%driver: pcib dev.pcib.4.%location: slot=4 function=0 handle=\_SB_.PCI0.PBLO dev.pcib.4.%pnpinfo: vendor=0x8086 device=0x3597 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.4.%parent: pci0 dev.pcib.4.wake: 0 dev.pcib.5.%desc: ACPI PCI-PCI bridge dev.pcib.5.%driver: pcib dev.pcib.5.%location: slot=5 function=0 handle=\_SB_.PCI0.PBHI dev.pcib.5.%pnpinfo: vendor=0x8086 device=0x3598 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.5.%parent: pci0 dev.pcib.5.wake: 0 dev.pcib.6.%desc: ACPI PCI-PCI bridge dev.pcib.6.%driver: pcib dev.pcib.6.%location: slot=0 function=0 handle=\_SB_.PCI0.PBHI.PXB1 dev.pcib.6.%pnpinfo: vendor=0x8086 device=0x0329 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.6.%parent: pci5 dev.pcib.7.%desc: ACPI PCI-PCI bridge dev.pcib.7.%driver: pcib dev.pcib.7.%location: slot=0 function=2 handle=\_SB_.PCI0.PBHI.PXB2 dev.pcib.7.%pnpinfo: vendor=0x8086 device=0x032a subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.7.%parent: pci5 dev.pcib.8.%desc: ACPI PCI-PCI bridge dev.pcib.8.%driver: pcib dev.pcib.8.%location: slot=6 function=0 handle=\_SB_.PCI0.VPR1 dev.pcib.8.%pnpinfo: vendor=0x8086 device=0x3599 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.8.%parent: pci0 dev.pcib.8.wake: 0 dev.pcib.9.%desc: ACPI PCI-PCI bridge dev.pcib.9.%driver: pcib dev.pcib.9.%location: slot=0 function=0 handle=\_SB_.PCI0.VPR1.PXC1 dev.pcib.9.%pnpinfo: vendor=0x8086 device=0x0329 subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.9.%parent: pci8 dev.pcib.10.%desc: ACPI PCI-PCI bridge dev.pcib.10.%driver: pcib dev.pcib.10.%location: slot=0 function=2 handle=\_SB_.PCI0.VPR1.PXC2 dev.pcib.10.%pnpinfo: vendor=0x8086 device=0x032a subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.10.%parent: pci8 dev.pcib.11.%desc: ACPI PCI-PCI bridge dev.pcib.11.%driver: pcib dev.pcib.11.%location: slot=30 function=0 handle=\_SB_.PCI0.PICH dev.pcib.11.%pnpinfo: vendor=0x8086 device=0x244e subvendor=0x0000 subdevice=0x0000 class=0x060400 dev.pcib.11.%parent: pci0 dev.pcib.11.wake: 0 dev.pci.0.%desc: ACPI PCI bus dev.pci.0.%driver: pci dev.pci.0.%parent: pcib0 dev.pci.0.wake: 0 dev.pci.1.%desc: ACPI PCI bus dev.pci.1.%driver: pci dev.pci.1.%parent: pcib1 dev.pci.1.wake: 0 dev.pci.2.%desc: ACPI PCI bus dev.pci.2.%driver: pci dev.pci.2.%parent: pcib2 dev.pci.3.%desc: ACPI PCI bus dev.pci.3.%driver: pci dev.pci.3.%parent: pcib3 dev.pci.4.%desc: ACPI PCI bus dev.pci.4.%driver: pci dev.pci.4.%parent: pcib4 dev.pci.4.wake: 0 dev.pci.5.%desc: ACPI PCI bus dev.pci.5.%driver: pci dev.pci.5.%parent: pcib5 dev.pci.5.wake: 0 dev.pci.6.%desc: ACPI PCI bus dev.pci.6.%driver: pci dev.pci.6.%parent: pcib6 dev.pci.7.%desc: ACPI PCI bus dev.pci.7.%driver: pci dev.pci.7.%parent: pcib7 dev.pci.8.%desc: ACPI PCI bus dev.pci.8.%driver: pci dev.pci.8.%parent: pcib8 dev.pci.8.wake: 0 dev.pci.9.%desc: ACPI PCI bus dev.pci.9.%driver: pci dev.pci.9.%parent: pcib9 dev.pci.10.%desc: ACPI PCI bus dev.pci.10.%driver: pci dev.pci.10.%parent: pcib10 dev.pci.11.%desc: ACPI PCI bus dev.pci.11.%driver: pci dev.pci.11.%parent: pcib11 dev.pci.11.wake: 0 dev.hostb.0.%desc: Host to PCI bridge dev.hostb.0.%driver: hostb dev.hostb.0.%location: slot=0 function=0 dev.hostb.0.%pnpinfo: vendor=0x8086 device=0x3590 subvendor=0x1028 subdevice=0x016d class=0x060000 dev.hostb.0.%parent: pci0 dev.amr.0.%desc: LSILogic MegaRAID 1.53 dev.amr.0.%driver: amr dev.amr.0.%location: slot=14 function=0 dev.amr.0.%pnpinfo: vendor=0x1028 device=0x0013 subvendor=0x1028 subdevice=0x016d class=0x010400 dev.amr.0.%parent: pci2 dev.amr.0.allow_volume_configure: 0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.2.9 dev.em.0.%driver: em dev.em.0.%location: slot=7 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x1076 subvendor=0x1028 subdevice=0x016d class=0x020000 dev.em.0.%parent: pci6 dev.em.0.debug_info: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.1.%desc: Intel(R) PRO/1000 Network Connection Version - 6.2.9 dev.em.1.%driver: em dev.em.1.%location: slot=8 function=0 dev.em.1.%pnpinfo: vendor=0x8086 device=0x1076 subvendor=0x1028 subdevice=0x016d class=0x020000 dev.em.1.%parent: pci7 dev.em.1.debug_info: -1 dev.em.1.stats: -1 dev.em.1.rx_int_delay: 0 dev.em.1.tx_int_delay: 66 dev.em.1.rx_abs_int_delay: 66 dev.em.1.tx_abs_int_delay: 66 dev.em.1.rx_processing_limit: 100 dev.uhci.0.%desc: Intel 82801EB (ICH5) USB controller USB-A dev.uhci.0.%driver: uhci dev.uhci.0.%location: slot=29 function=0 dev.uhci.0.%pnpinfo: vendor=0x8086 device=0x24d2 subvendor=0x1028 subdevice=0x016d class=0x0c0300 dev.uhci.0.%parent: pci0 dev.uhci.1.%desc: Intel 82801EB (ICH5) USB controller USB-B dev.uhci.1.%driver: uhci dev.uhci.1.%location: slot=29 function=1 dev.uhci.1.%pnpinfo: vendor=0x8086 device=0x24d4 subvendor=0x1028 subdevice=0x016d class=0x0c0300 dev.uhci.1.%parent: pci0 dev.uhci.2.%desc: Intel 82801EB (ICH5) USB controller USB-C dev.uhci.2.%driver: uhci dev.uhci.2.%location: slot=29 function=2 dev.uhci.2.%pnpinfo: vendor=0x8086 device=0x24d7 subvendor=0x1028 subdevice=0x016d class=0x0c0300 dev.uhci.2.%parent: pci0 dev.usb.0.%desc: Intel 82801EB (ICH5) USB controller USB-A dev.usb.0.%driver: usb dev.usb.0.%parent: uhci0 dev.usb.1.%desc: Intel 82801EB (ICH5) USB controller USB-B dev.usb.1.%driver: usb dev.usb.1.%parent: uhci1 dev.usb.2.%desc: Intel 82801EB (ICH5) USB controller USB-C dev.usb.2.%driver: usb dev.usb.2.%parent: uhci2 dev.usb.3.%desc: Intel 82801EB/R (ICH5) USB 2.0 controller dev.usb.3.%driver: usb dev.usb.3.%parent: ehci0 dev.uhub.0.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.0.%driver: uhub dev.uhub.0.%parent: usb0 dev.uhub.1.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.1.%driver: uhub dev.uhub.1.%parent: usb1 dev.uhub.2.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.2.%driver: uhub dev.uhub.2.%parent: usb2 dev.uhub.3.%desc: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 dev.uhub.3.%driver: uhub dev.uhub.3.%parent: usb3 dev.uhub.4.%desc: vendor 0x413c product 0xa001, class 9/0, rev 2.00/0.00, addr 2 dev.uhub.4.%driver: uhub dev.uhub.4.%location: port=2 dev.uhub.4.%pnpinfo: vendor=0x413c product=0xa001 devclass=0x09 devsubclass=0x00 release=0x0000 sernum="" dev.uhub.4.%parent: uhub3 dev.ehci.0.%desc: Intel 82801EB/R (ICH5) USB 2.0 controller dev.ehci.0.%driver: ehci dev.ehci.0.%location: slot=29 function=7 dev.ehci.0.%pnpinfo: vendor=0x8086 device=0x24dd subvendor=0x1028 subdevice=0x016d class=0x0c0320 dev.ehci.0.%parent: pci0 dev.isab.0.%desc: PCI-ISA bridge dev.isab.0.%driver: isab dev.isab.0.%location: slot=31 function=0 handle=\_SB_.PCI0.ISA_ dev.isab.0.%pnpinfo: vendor=0x8086 device=0x24d0 subvendor=0x0000 subdevice=0x0000 class=0x060100 dev.isab.0.%parent: pci0 dev.isa.0.%desc: ISA bus dev.isa.0.%driver: isa dev.isa.0.%parent: isab0 dev.atapci.0.%desc: Intel ICH5 UDMA100 controller dev.atapci.0.%driver: atapci dev.atapci.0.%location: slot=31 function=1 dev.atapci.0.%pnpinfo: vendor=0x8086 device=0x24db subvendor=0x1028 subdevice=0x016d class=0x01018a dev.atapci.0.%parent: pci0 dev.ata.0.%desc: ATA channel 0 dev.ata.0.%driver: ata dev.ata.0.%parent: atapci0 dev.ata.1.%desc: ATA channel 1 dev.ata.1.%driver: ata dev.ata.1.%parent: atapci0 dev.atdma.0.%desc: AT DMA controller dev.atdma.0.%driver: atdma dev.atdma.0.%location: handle=\_SB_.PCI0.ISA_.DMA_ dev.atdma.0.%pnpinfo: _HID=PNP0200 _UID=0 dev.atdma.0.%parent: acpi0 dev.fpupnp.0.%desc: Legacy ISA coprocessor support dev.fpupnp.0.%driver: fpupnp dev.fpupnp.0.%location: handle=\_SB_.PCI0.ISA_.FPU_ dev.fpupnp.0.%pnpinfo: _HID=PNP0C04 _UID=0 dev.fpupnp.0.%parent: acpi0 dev.attimer.0.%desc: AT realtime clock dev.attimer.0.%driver: attimer dev.attimer.0.%location: handle=\_SB_.PCI0.ISA_.RTC_ dev.attimer.0.%pnpinfo: _HID=PNP0B00 _UID=0 dev.attimer.0.%parent: acpi0 dev.attimer.1.%desc: AT timer dev.attimer.1.%driver: attimer dev.attimer.1.%location: handle=\_SB_.PCI0.ISA_.TMR_ dev.attimer.1.%pnpinfo: _HID=PNP0100 _UID=0 dev.attimer.1.%parent: acpi0 dev.fdc.0.%desc: Enhanced floppy controller dev.fdc.0.%driver: fdc dev.fdc.0.%location: handle=\_SB_.PCI0.ISA_.FDC_ dev.fdc.0.%pnpinfo: _HID=PNP0700 _UID=0 dev.fdc.0.%parent: acpi0 dev.fd.0.%desc: 1440-KB 3.5" drive dev.fd.0.%driver: fd dev.fd.0.%parent: fdc0 dev.sio.0.%desc: 16550A-compatible COM port dev.sio.0.%driver: sio dev.sio.0.%location: handle=\_SB_.PCI0.ISA_.COMA dev.sio.0.%pnpinfo: _HID=PNP0501 _UID=1 dev.sio.0.%parent: acpi0 dev.orm.0.%desc: ISA Option ROMs dev.orm.0.%driver: orm dev.orm.0.%parent: isa0 dev.atkbdc.0.%desc: Keyboard controller (i8042) dev.atkbdc.0.%driver: atkbdc dev.atkbdc.0.%parent: isa0 dev.atkbd.0.%desc: AT Keyboard dev.atkbd.0.%driver: atkbd dev.atkbd.0.%parent: atkbdc0 dev.sc.0.%desc: System console dev.sc.0.%driver: sc dev.sc.0.%parent: isa0 dev.vga.0.%desc: Generic ISA VGA dev.vga.0.%driver: vga dev.vga.0.%parent: isa0 dev.acd.0.%desc: HL-DT-STCD-RW/DVD-ROM GCC-4244N/B101 dev.acd.0.%driver: acd dev.acd.0.%parent: ata0 dev.amrd.0.%desc: LSILogic MegaRAID logical drive dev.amrd.0.%driver: amrd dev.amrd.0.%parent: amr0 --------------040306070507060607050303-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 08:51:40 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A9FD16A419 for ; Tue, 16 Oct 2007 08:51:40 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 0DF5313C455 for ; Tue, 16 Oct 2007 08:51:39 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 7748316BC2; Tue, 16 Oct 2007 11:51:36 +0300 (EEST) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41083-03; Tue, 16 Oct 2007 11:51:34 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 6239E16BBB; Tue, 16 Oct 2007 11:51:34 +0300 (EEST) Message-ID: <47147B95.9040400@bulinfo.net> Date: Tue, 16 Oct 2007 11:51:33 +0300 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.6 (X11/20070927) MIME-Version: 1.0 To: Alexey Popov References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> In-Reply-To: <47146FB4.6040306@chistydom.ru> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: freebsd-hackers@freebsd.org, Kris Kennaway , freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 08:51:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexey Popov wrote: > Hi. > > Kris Kennaway wrote: > >>> After some time of running under high load disk performance become >>> expremely poor. At that periods 'systat -vm 1' shows something like >>> this: >> What does "high load" mean? You need to explain the system workload >> more. > This web service is similiar to YouTube. This server is video store. I > have around 200G of *.flv (flash video) files on the server. > > I run lighttpd as a web server. Disk load is usually around 50%, network > output 100Mbit/s, 100 simultaneous connections. CPU is mostly idle. > > As you can see it is a trivial service - sending files to network via HTTP. > >> >>> Disks amrd0 >>> KB/t 85.39 >>> tps 5 >>> MB/s 0.38 >>> % busy 99 >> >>> Apart of all, I tried to make mutex profiling and here's the results >>> (sorted by the total number of acquisitions): >>> >>> Bad case: >>> >>> 102 223514 273977 0 14689 1651568 /usr/src/sys/vm/uma_core.c:2349 (512) >>> 950 263099 273968 0 15004 14427 /usr/src/sys/vm/uma_core.c:2450 (512) >>> 108 150422 175840 0 10978 22988519 /usr/src/sys/vm/uma_core.c:1888 >>> (mbuf) >> >> > Here you can see that high UMA activity happens in periods of low disk >> > performance. But I'm not sure whether this is a root of the >> problem, not >> > a consequence. >> >> The extremely high contention there does seem to say you have a mbuf >> starvation problem and not a disk problem. I don't know why this >> would be happening off-hand. > But there's no mbuf shortage in `netstat -m`. > > What else can I try to track down the source of the problem? > >> Can you also provide more details about the system hardware and >> configuration? > This is Dell 2850 2 x Xeon 3.2, 4Gb RAM, 6x300Gb SCSI RAID5. I'll attach > details. > > With best regards, > Alexey Popov > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" last pid: 11008; load averages: 0.07, 0.10, 0.08 up 47+08:32:50 11:46:15 38 processes: 1 running, 37 sleeping Mem: 46M Active, 3443M Inact, 246M Wired, 144M Cache, 208M Buf, 5596K Free Swap: 2048M Total, 4K Used, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 56386 root 1 4 0 19856K 10000K kqread 1 115:19 2.88% lighttpd 636 root 1 96 0 18292K 4212K select 0 25:39 0.00% snmpd 784 root 1 96 0 19668K 2072K select 1 2:31 0.00% sshd 680 root 1 96 0 7732K 1384K select 0 1:59 0.00% ntpd 1540 root 1 96 0 35092K 6496K select 0 1:30 0.00% httpd 769 root 4 20 0 14148K 2632K kserel 0 1:04 0.00% bacula-fd 755 root 1 96 0 3852K 1060K select 1 0:22 0.00% master 568 root 1 96 0 3648K 908K select 0 0:18 0.00% syslogd 80663 root 1 8 0 3688K 1016K nanslp 1 0:05 0.00% cron 760 postfix 1 96 0 3944K 1160K select 0 0:04 0.00% qmgr 89776 www 1 20 0 35180K 6684K lockf 0 0:04 0.00% httpd 89763 www 1 20 0 35180K 6684K lockf 0 0:04 0.00% httpd 89774 www 1 20 0 35180K 6684K lockf 0 0:04 0.00% httpd 89775 www 1 96 0 35180K 6684K select 0 0:04 0.00% httpd 699 root 1 20 0 7732K 1388K pause 0 0:03 0.00% ntpd 484 root 1 4 0 652K 220K select 0 0:00 0.00% devd 10904 llp 1 96 0 30616K 3564K select 0 0:00 0.00% sshd 10915 root 1 20 0 3912K 2340K pause 1 0:00 0.00% csh You run apache with mod_perl or php too. How many clients handle this apache server? Also in this light load you have locked files! Check script execution times (/server-status may be useful). When you have hight load check swap usage and haw many processes are in lockf state. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHFHuVxJBWvpalMpkRAnqTAJ9FgURNk98dtD0HYX6xIz17R6sLpQCgh5nJ XBtfOyzJJbkjzVzSF/WfmHc= =oTHZ -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 09:03:07 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD00916A419; Tue, 16 Oct 2007 09:03:07 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id EAA1E13C4C5; Tue, 16 Oct 2007 09:03:06 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47147E49.9020301@FreeBSD.org> Date: Tue, 16 Oct 2007 11:03:05 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Alexey Popov References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> In-Reply-To: <47146FB4.6040306@chistydom.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 09:03:07 -0000 Alexey Popov wrote: > Hi. > > Kris Kennaway wrote: > >>> After some time of running under high load disk performance become >>> expremely poor. At that periods 'systat -vm 1' shows something like >>> this: >> What does "high load" mean? You need to explain the system workload >> more. > This web service is similiar to YouTube. This server is video store. I > have around 200G of *.flv (flash video) files on the server. > > I run lighttpd as a web server. Disk load is usually around 50%, network > output 100Mbit/s, 100 simultaneous connections. CPU is mostly idle. > > As you can see it is a trivial service - sending files to network via HTTP. A couple of comments. Does lighttpd actually use HTTP accept filters? Are you using ipfilter and ipfw? You are paying a performance penalty for having them. You might try increasing BUCKET_MAX in sys/vm/uma_core.c. I don't really understand the code here, but you seem to be hitting a threshold behaviour where you are constantly running out of space in the per CPU caches. This can happen if your workload is unbalanced between the CPUs and you are always allocating on one but freeing on another, but I wouldn't expect it should happen on your workload. Maybe it can also happen if your turnover is high enough. What does vmstat -z show during the good and bad times? Kris From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 09:04:10 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABE9816A421 for ; Tue, 16 Oct 2007 09:04:10 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id 2FB1A13C4C1 for ; Tue, 16 Oct 2007 09:04:09 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l9G947WJ002004; Tue, 16 Oct 2007 19:04:07 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l9G946pp002003; Tue, 16 Oct 2007 19:04:06 +1000 (EST) (envelope-from peter) Date: Tue, 16 Oct 2007 19:04:06 +1000 From: Peter Jeremy To: Artem Kuchin Message-ID: <20071016090406.GL1184@turion.vk2pj.dyndns.org> References: <008801c80e66$7be49490$0c00a8c0@Artem> <20071014203420.GB2490@dan.emsphone.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qjNfmADvan18RZcF" Content-Disposition: inline In-Reply-To: <20071014203420.GB2490@dan.emsphone.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: Question about 'top' values on memory usage X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 09:04:10 -0000 --qjNfmADvan18RZcF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In the last episode (Oct 14), Artem Kuchin said: > Maybe someone with deeper knowledge of the internals of FreeBSD can > clean up something for me (any for many others)^ >=20 > Here are lines from my top: >=20 > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 9258 hordelo_ru 1 4 0 40992K 4260K accept 0 0:00 0.00% httpd > 9257 hordelo_ru 1 44 0 40992K 4296K select 1 0:00 0.00% httpd > 9259 hordelo_ru 1 4 0 40992K 4292K select 1 0:00 0.00% httpd >=20 > As you see, 'size' is the same for all processes, while RES varies. >=20 > As i understand, the real memory taken by a process is RES and SIZE > include a bunch of shares .so libs, so, if more httpd's started each > will take only about 4300K more, so, 100 https will take 430000K to > run, right? Determining the amount of shared vs unshared memory for each process is not totally trivial. All I can suggest is using procfs and reading /proc/<>/map eg: turion% dd if=3D/proc/curproc/map bs=3D256k 0x400000 0x402000 2 0 0xffffff002e4710e0 r-x 1 0 0x0 COW NC vnode /bin/dd 0x502000 0x503000 1 0 0xffffff001c41cd20 rw- 2 0 0x2180 NCOW NNC default - 0x503000 0x505000 2 0 0xffffff001c41cd20 rwx 2 0 0x2180 NCOW NNC default - and so on The columns are: start address, end address, resident pages, private resident pages, vm_object_t address, protection, reference count, shadow count, flags, cow, copy-needed, type, path See for flags This will let you indentify shared vs private space as well as whether it's file or swap backed. --=20 Peter Jeremy --qjNfmADvan18RZcF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHFH6G/opHv/APuIcRAon1AJ4gceMqNrqaWi8o3BpoXaWB9pvAvgCfbe9b QnxXx1y2iNiT5UUudZBXsnc= =XXpU -----END PGP SIGNATURE----- --qjNfmADvan18RZcF-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 09:06:15 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6683116A468; Tue, 16 Oct 2007 09:06:15 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id 872B813C48A; Tue, 16 Oct 2007 09:06:14 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 194327216; Tue, 16 Oct 2007 13:06:20 +0400 Message-ID: <47147ED7.7060806@chistydom.ru> Date: Tue, 16 Oct 2007 13:05:27 +0400 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 Newsgroups: gmane.os.freebsd.stable,gmane.os.freebsd.devel.hackers To: Krassimir Slavchev References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> <47147B95.9040400@bulinfo.net> In-Reply-To: <47147B95.9040400@bulinfo.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Kris Kennaway , freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 09:06:15 -0000 Hi. Krassimir Slavchev wrote: > You run apache with mod_perl or php too. How many clients handle this > apache server? Also in this light load you have locked files! Check > script execution times (/server-status may be useful). > When you have hight load check swap usage and haw many processes are in > lockf state. Apache is not much used here, it is just for kind of content management. It is not exposed to external users. With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 09:42:00 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49B0D16A420 for ; Tue, 16 Oct 2007 09:42:00 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5046513C44B for ; Tue, 16 Oct 2007 09:42:00 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 1DD681CC05C; Tue, 16 Oct 2007 02:42:00 -0700 (PDT) Date: Tue, 16 Oct 2007 02:42:00 -0700 From: Jeremy Chadwick To: Rick Message-ID: <20071016094200.GA33265@eos.sc1.parodius.com> Mail-Followup-To: Rick , freebsd-stable@freebsd.org References: <20071015172143.GI14791@phantasm.metahusky.net> <20071016034944.GA23351@eos.sc1.parodius.com> <20071016090024.GD63617@phantasm.metahusky.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071016090024.GD63617@phantasm.metahusky.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: device_attach: smist0 attach returned 6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 09:42:00 -0000 On Tue, Oct 16, 2007 at 10:00:24AM +0100, Rick wrote: > Thanks for the reply. It's actually a remote machine sat in a colo, so > it will require a visit and reboot to look at the BIOS settings, and > it's a pretty minimal set of options IIRC, so there may not be anything > there, but I'll arrange a visit to have a look. Because this is an older (440BX) system, you may have to adjust settings relating to power/suspend mode and other whatnots. Even after doing so you may not see success (meaning the feature you want may be explicitly disabled/non-configurable). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 09:42:37 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 558CE16A41A for ; Tue, 16 Oct 2007 09:42:37 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id ED9A613C4A7 for ; Tue, 16 Oct 2007 09:42:36 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l9G9gYaE002089; Tue, 16 Oct 2007 19:42:34 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l9G9gYau002088; Tue, 16 Oct 2007 19:42:34 +1000 (EST) (envelope-from peter) Date: Tue, 16 Oct 2007 19:42:34 +1000 From: Peter Jeremy To: William LeFebvre Message-ID: <20071016094234.GM1184@turion.vk2pj.dyndns.org> References: <008801c80e66$7be49490$0c00a8c0@Artem> <471367F2.7050303@lefebvre.org> <037501c80f3d$69120730$0c00a8c0@Artem> <471398BB.30405@lefebvre.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Km1U/tdNT/EmXiR1" Content-Disposition: inline In-Reply-To: <471398BB.30405@lefebvre.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: Question about 'top' values on memory usage, now threads X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 09:42:37 -0000 --Km1U/tdNT/EmXiR1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Oct-15 12:43:39 -0400, William LeFebvre wrote: >Whether there is actual swapping going on or not, processes will still nee= d=20 >swap space. There needs to be a backing store for every page that's in=20 >physical memory. This isn't true for FreeBSD. You can even totally disable paging/swapping with the config option "NO_SWAPPING" if you want. FreeBSD allocates swap space on an "as needed" basis, rather than pre-allocating swap. The advantage is that a process can request virtually unlimited amounts of memory via sbrk(2), mmap(2) or malloc(3). The downside is that a process may be killed without notice when it writes to some previously allocated but unused part of its address space. See the archives for the full bikeshed. --=20 Peter Jeremy --Km1U/tdNT/EmXiR1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHFIeK/opHv/APuIcRAoE2AKCoLsAOgaudTZDIVIgl9L9NNpMx6QCdHf1+ ygC73MLtgKilxCdi2Z2+57c= =eHd/ -----END PGP SIGNATURE----- --Km1U/tdNT/EmXiR1-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 10:05:35 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 598B516A417; Tue, 16 Oct 2007 10:05:35 +0000 (UTC) (envelope-from d_elbracht@ecngs.de) Received: from ecngs.de (mail.ecngs.de [217.73.144.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6FA13C45D; Tue, 16 Oct 2007 10:05:33 +0000 (UTC) (envelope-from d_elbracht@ecngs.de) Received: from EC1a (ec1.elbracht.net [217.73.144.99]) by ecngs.de (SurgeMail 3.8f2) with ESMTP id 1777227-1922481 for multiple; Tue, 16 Oct 2007 12:05:54 +0200 From: "d_elbracht" To: "'Eric Anderson'" References: <008801c80e65$47cbe650$639049d9@EC1a> <00cb01c80f04$50b11ed0$639049d9@EC1a> <47137634.1010703@freebsd.org> Date: Tue, 16 Oct 2007 12:05:23 +0200 Message-ID: <000b01c80fdc$12582f10$639049d9@EC1a> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47137634.1010703@freebsd.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcgPN6GqbK/sjYCaTtGAOMP49/u7+wAo/O0w Cc: freebsd-stable@freebsd.org, 'Ivan Voras' , freebsd-geom@freebsd.org Subject: AW: Re: AW: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 10:05:35 -0000 > > One basic question to ask: where does the value for offset= in > > g_vfs_done() come from ? > >>From the time the error shows up in syslog I believe, the error only > > happens, when a file get's appended. > > I wonder if (wild guess follows) there's a 32/64 bit > conversion problem somewhere, like a 32bit number cast as > 64bit or something. > > I'd like to see a full trace to see what path it takes. > Maybe putting a > panic in the error path would be worth doing. > can you give me some hints please how to do this ? I'm willing to try about everything to get this problem nailed down. Dieter From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 11:23:48 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C90216A418; Tue, 16 Oct 2007 11:23:48 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id 2B4D313C467; Tue, 16 Oct 2007 11:23:45 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 194370688; Tue, 16 Oct 2007 15:21:06 +0400 Message-ID: <47149E6E.9000500@chistydom.ru> Date: Tue, 16 Oct 2007 15:20:14 +0400 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Kris Kennaway References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> <47147E49.9020301@FreeBSD.org> In-Reply-To: <47147E49.9020301@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 11:23:48 -0000 Hi. Kris Kennaway wrote: >>>> After some time of running under high load disk performance become >>>> expremely poor. At that periods 'systat -vm 1' shows something like >>>> this: >>> What does "high load" mean? You need to explain the system workload >>> more. >> This web service is similiar to YouTube. This server is video store. I >> have around 200G of *.flv (flash video) files on the server. >> >> I run lighttpd as a web server. Disk load is usually around 50%, network >> output 100Mbit/s, 100 simultaneous connections. CPU is mostly idle. >> >> As you can see it is a trivial service - sending files to network via >> HTTP. > Does lighttpd actually use HTTP accept filters? Don't know how to make sure, but is seems to run appropriate setsockopt (truss output): setsockopt(0x4,0xffff,0x1000,0x7fffffffe620,0x100) = 0 (0x0) > Are you using ipfilter and ipfw? You are paying a performance penalty > for having them. I'm using ipfw and one of the first rules is to pass all TCP established. ipfilter is not used on this server, but it is present in kernel as it can be used on other servers. I have 95% CPU idle, so I think packet filters does not produce significant load on this server. > You might try increasing BUCKET_MAX in sys/vm/uma_core.c. I don't > really understand the code here, but you seem to be hitting a threshold > behaviour where you are constantly running out of space in the per CPU > caches. Thanks, I'll try this. > This can happen if your workload is unbalanced between the CPUs and you > are always allocating on one but freeing on another, but I wouldn't > expect it should happen on your workload. Maybe it can also happen if > your turnover is high enough. This is very unlikely, because I have 5 another video storage servers of the same hardware and software configurations and they feel good. On the other side, all other servers were put in production before or after problematic servers and were filled with content in the other ways and therefore they could have slightly differerent load pattern. Totally I faced this bug three times: 1. The first time there was AFAIR 5.4-RELEASE on DELL 2850 with the same configuration as now. It was mp3 store and I used thttpd as HTTP server to serve mp3's. That time the problems were not so frequent and also it took too long to get back to normal operation so we had to reboot servers once a week or so. The problems began when we moved to new hardware - Dell 2850. That time we suspected amrd driver and had no time to dig in, bacause all the servers of the project were problematic. Installing Linux helped. 2. The second time it was server for static files of the very popular blog. The http server was nginx and disk contented puctures, mp3's and videos. It was Dell 1850 2x146 SCSI mirror. Linux also solved the problem. 3. The problem we see now. At first glance one can say that problem is in Dell's x850 series or amr(4), but we run this hardware on many other projects and they work well. Also Linux on them works. And few hours ago I received feed back from Andrzej Tobola, he has the same problem on FreeBSD 7 with Promise ATA software mirror: === Subject: Re: amrd disk performance drop after running under high load Date: Tue, 16 Oct 2007 10:59:34 +0200 From: Andrzej Tobola To: Alexey Popov Exactly the same here but on big ata RAID0 with big trafic (~10GB/24h): amper% df -h /ftp/priv Filesystem Size Used Avail Capacity Mounted one /dev/ar0a 744G 679G 4.7G 99% /ftp/priv amper% grep ^ar /var/run/dmesg.boot ar0: 763108MB status: READY ar0: disk0 READY using ad6 at ata3-master ar0: disk1 READY using ad4 at ata2-master amper% uname -a FreeBSD xxx 7.0-CURRENT-200709 FreeBSD 7.0-CURRENT-200709 #0: Tue Sep 11 04:44:48 UTC 2007 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 I am rebooting if I reach this state (approx. a week). It is old bug - a few months ;) cheers, -a === So I can conclude that FreeBSD has a long standing bug in VM that could be triggered when serving large amount of static data (much bigger than memory size) on high rates. Possibly this only applies to large files like mp3 or video. > What does vmstat -z show during the good and bad times? I'll send this data when the bad times will happen next time. With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 14:14:10 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 082E616A419 for ; Tue, 16 Oct 2007 14:14:10 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id B43D613C44B for ; Tue, 16 Oct 2007 14:14:09 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id E8EB9744009; Tue, 16 Oct 2007 17:14:06 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuJ0nV7ZYjJR; Tue, 16 Oct 2007 17:14:06 +0300 (EEST) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 52AFE744008; Tue, 16 Oct 2007 17:14:06 +0300 (EEST) Message-ID: <4714C724.6000809@icyb.net.ua> Date: Tue, 16 Oct 2007 17:13:56 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: d_elbracht References: <1192382586.00813930.1192369201@10.7.7.3> <1192414981.00814129.1192401601@10.7.7.3> <1192447399.00814254.1192437006@10.7.7.3> <1192468999.00814418.1192458001@10.7.7.3> <1192540986.00814865.1192529403@10.7.7.3> In-Reply-To: <1192540986.00814865.1192529403@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org, freebsd-stable@freebsd.org, 'Ivan Voras' , 'Eric Anderson' Subject: Re: AW: Re: AW: g_vfs_done():da3s1a[READ(offset=81064794762854400, length=8192)]error = 5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 14:14:10 -0000 Just a wild shot here: I have seen a similar message recently when I played with my disks. I re-arranged some partitions (and filesystems) within a slice and it so happened (and I almost know why) that there was some discrepancy between on-disk and in-memory label of that slice. I ran newfs on one of the new partitions and apparently it used one label to determine its size, but after the reboot the other label was used. As a result I had a UFS2 filesystem with size larger than a partition that hosted it. And after that I saw the messages similar to the one in the subject. All of the above is a result of my understanding of how these things work, so it may be incorrect. But making sure that disklabels match (that is, there is only one disklabel) and re-newfs-ing the filesystems did help me. So I would compare, just in case, outputs of, say, 'dumpfs -m' near '-s' and disklabel output. Just my 2 bits. P.S. example of the error that I had: g_vfs_done():ad4s1e[READ(offset=20420280320, length=16384)]error = 5 -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 16:58:46 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D39016A417 for ; Tue, 16 Oct 2007 16:58:46 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from spork.qfe3.net (spork.qfe3.net [212.13.207.101]) by mx1.freebsd.org (Postfix) with ESMTP id C6A9C13C45B for ; Tue, 16 Oct 2007 16:58:45 +0000 (UTC) (envelope-from tom.hurst@clara.net) Received: from [81.104.144.87] (helo=voi.aagh.net) by spork.qfe3.net with esmtp (Exim 4.66 (FreeBSD)) (envelope-from ) id 1Ihpki-0000TC-Gp; Tue, 16 Oct 2007 17:58:44 +0100 Received: from freaky by voi.aagh.net with local (Exim 4.67 (FreeBSD)) (envelope-from ) id 1Ihpki-0001yS-9P; Tue, 16 Oct 2007 17:58:44 +0100 Date: Tue, 16 Oct 2007 17:58:44 +0100 From: Thomas Hurst To: freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Message-ID: <20071016165844.GA6566@voi.aagh.net> Mail-Followup-To: freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> <47147E49.9020301@FreeBSD.org> <47149E6E.9000500@chistydom.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47149E6E.9000500@chistydom.ru> Organization: Not much. User-Agent: Mutt/1.5.16 (2007-06-09) Sender: Thomas Hurst Cc: Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 16:58:46 -0000 * Alexey Popov (lol@chistydom.ru) wrote: > So I can conclude that FreeBSD has a long standing bug in VM that > could be triggered when serving large amount of static data (much > bigger than memory size) on high rates. Possibly this only applies to > large files like mp3 or video. I've seen highly dubious VM behavior when reading large files locally; the system ends up swapping out a small but significant amount of various processes, even very small recently active ones like syslogd, for no apparant reason: http://lists.freebsd.org/pipermail/freebsd-stable/2007-September/036956.html I've also seen dubious IO behavior from amr(4), where access to one array will interfere with IO from an independent set of spindles that just happen to be attached to the same card: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/114438 Given the blank looks I've received every time I've mentioned these things I'm guessing they aren't seen by others all that often, but maybe one or both are vaguely relevent to your situation. -- Thomas 'Freaky' Hurst http://hur.st/ From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 17:17:23 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2B9816A46C for ; Tue, 16 Oct 2007 17:17:23 +0000 (UTC) (envelope-from ekarkkai@pp.htv.fi) Received: from smtp5.pp.htv.fi (smtp5.pp.htv.fi [213.243.153.39]) by mx1.freebsd.org (Postfix) with ESMTP id 6BDC113C46A for ; Tue, 16 Oct 2007 17:17:23 +0000 (UTC) (envelope-from ekarkkai@pp.htv.fi) Received: from zero.my.domain (cs181095217.pp.htv.fi [82.181.95.217]) by smtp5.pp.htv.fi (Postfix) with ESMTP id 9F9E95BC06A for ; Tue, 16 Oct 2007 20:17:21 +0300 (EEST) Received: from thunderbolt.my.domain (thunderbolt.my.domain [10.192.168.30]) by zero.my.domain (8.13.8/8.13.8) with ESMTP id l9GHHKiE003709 for ; Tue, 16 Oct 2007 20:17:21 +0300 (EEST) (envelope-from ekarkkai@pp.htv.fi) Received: from thunderbolt.my.domain (localhost [127.0.0.1]) by thunderbolt.my.domain (8.13.8/8.13.8) with ESMTP id l9GHHKQG006152 for ; Tue, 16 Oct 2007 20:17:20 +0300 (EEST) (envelope-from ejk@thunderbolt.my.domain) Received: (from ejk@localhost) by thunderbolt.my.domain (8.13.8/8.13.8/Submit) id l9GHHKse006151 for stable@freebsd.org; Tue, 16 Oct 2007 20:17:20 +0300 (EEST) (envelope-from ejk) Date: Tue, 16 Oct 2007 20:17:20 +0300 From: Esa Karkkainen To: stable@freebsd.org Message-ID: <20071016171720.GA2186@pp.htv.fi> Mail-Followup-To: Esa Karkkainen , stable@freebsd.org References: <20071004165755.GA1049@pp.htv.fi> <47120D83.1010703@FreeBSD.org> <20071015203202.GA17964@pp.htv.fi> <471406ED.7000307@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <471406ED.7000307@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 17:17:23 -0000 On Tue, Oct 16, 2007 at 02:33:49AM +0200, Kris Kennaway wrote: > Esa Karkkainen wrote: > >This machine has two 512MB DDR333 DIMM's. > > > >I installed sysutils/memtest and ran three simultaneously, first two > >allocated 326 MB each and last one allocated 150 MB of memory, so I'd > >start to swap. No errors. > > Well, as you say, such a limited test doesn't mean much. Anyway, it may > well have been nve, so see how you go without it. I downloaded Memtest86+ version 1.70 iso image, burned image to a CD, booted from the CD and then I let memtest running for sixteen hours. Memtest did not find any errors during that time. -- "In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." -- Douglas Adams 1952 - 2001 From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 18:30:56 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED07B16A418; Tue, 16 Oct 2007 18:30:56 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id CC1BF13C46A; Tue, 16 Oct 2007 18:30:55 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4715035D.2090802@FreeBSD.org> Date: Tue, 16 Oct 2007 20:30:53 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Alexey Popov References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> <47147E49.9020301@FreeBSD.org> <47149E6E.9000500@chistydom.ru> In-Reply-To: <47149E6E.9000500@chistydom.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 18:30:57 -0000 Alexey Popov wrote: > Hi. > > Kris Kennaway wrote: > >>>>> After some time of running under high load disk performance become >>>>> expremely poor. At that periods 'systat -vm 1' shows something like >>>>> this: >>>> What does "high load" mean? You need to explain the system workload >>>> more. >>> This web service is similiar to YouTube. This server is video store. I >>> have around 200G of *.flv (flash video) files on the server. >>> >>> I run lighttpd as a web server. Disk load is usually around 50%, network >>> output 100Mbit/s, 100 simultaneous connections. CPU is mostly idle. >>> >>> As you can see it is a trivial service - sending files to network via >>> HTTP. >> Does lighttpd actually use HTTP accept filters? > Don't know how to make sure, but is seems to run appropriate setsockopt > (truss output): > > setsockopt(0x4,0xffff,0x1000,0x7fffffffe620,0x100) = 0 (0x0) OK. >> Are you using ipfilter and ipfw? You are paying a performance penalty >> for having them. > I'm using ipfw and one of the first rules is to pass all TCP > established. ipfilter is not used on this server, but it is present in > kernel as it can be used on other servers. I have 95% CPU idle, so I > think packet filters does not produce significant load on this server. Well, it was not your most serious issue, but from your profiling trace it is definitely burning cycles with every packet processed. >> You might try increasing BUCKET_MAX in sys/vm/uma_core.c. I don't >> really understand the code here, but you seem to be hitting a >> threshold behaviour where you are constantly running out of space in >> the per CPU caches. > Thanks, I'll try this. > >> This can happen if your workload is unbalanced between the CPUs and >> you are always allocating on one but freeing on another, but I >> wouldn't expect it should happen on your workload. Maybe it can also >> happen if your turnover is high enough. > This is very unlikely, because I have 5 another video storage servers of > the same hardware and software configurations and they feel good. Clearly something is different about them, though. If you can characterize exactly what that is then it will help. > On the other side, all other servers were put in production before or > after problematic servers and were filled with content in the other ways > and therefore they could have slightly differerent load pattern. > > Totally I faced this bug three times: > > 1. The first time there was AFAIR 5.4-RELEASE on DELL 2850 with the same > configuration as now. It was mp3 store and I used thttpd as HTTP server > to serve mp3's. That time the problems were not so frequent and also it > took too long to get back to normal operation so we had to reboot > servers once a week or so. > > The problems began when we moved to new hardware - Dell 2850. That time > we suspected amrd driver and had no time to dig in, bacause all the > servers of the project were problematic. Installing Linux helped. > > 2. The second time it was server for static files of the very popular > blog. The http server was nginx and disk contented puctures, mp3's and > videos. It was Dell 1850 2x146 SCSI mirror. Linux also solved the problem. > > 3. The problem we see now. > > At first glance one can say that problem is in Dell's x850 series or > amr(4), but we run this hardware on many other projects and they work > well. Also Linux on them works. OK but there is no evidence in what you posted so far that amr is involved in any way. There is convincing evidence that it is the mbuf issue. > And few hours ago I received feed back from Andrzej Tobola, he has the > same problem on FreeBSD 7 with Promise ATA software mirror: Well, he didnt provide any evidence yet that it is the same problem, so let's not become confused by feelings :) > So I can conclude that FreeBSD has a long standing bug in VM that could > be triggered when serving large amount of static data (much bigger than > memory size) on high rates. Possibly this only applies to large files > like mp3 or video. It is possible, we have further work to do to conclude this though. Kris From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 18:36:26 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06B7916A419 for ; Tue, 16 Oct 2007 18:36:26 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 58A8813C455; Tue, 16 Oct 2007 18:36:25 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <471504A9.4030007@FreeBSD.org> Date: Tue, 16 Oct 2007 20:36:25 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Esa Karkkainen , stable@freebsd.org References: <20071004165755.GA1049@pp.htv.fi> <47120D83.1010703@FreeBSD.org> <20071015203202.GA17964@pp.htv.fi> <471406ED.7000307@FreeBSD.org> <20071016171720.GA2186@pp.htv.fi> In-Reply-To: <20071016171720.GA2186@pp.htv.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 18:36:26 -0000 Esa Karkkainen wrote: > On Tue, Oct 16, 2007 at 02:33:49AM +0200, Kris Kennaway wrote: >> Esa Karkkainen wrote: >>> This machine has two 512MB DDR333 DIMM's. >>> >>> I installed sysutils/memtest and ran three simultaneously, first two >>> allocated 326 MB each and last one allocated 150 MB of memory, so I'd >>> start to swap. No errors. >> Well, as you say, such a limited test doesn't mean much. Anyway, it may >> well have been nve, so see how you go without it. > > I downloaded Memtest86+ version 1.70 iso image, burned image to a CD, > booted from the CD and then I let memtest running for sixteen hours. > > Memtest did not find any errors during that time. OK, higher probability that it is OK, but some memory errors are highly pattern dependent :) Physically replacing the RAM is the only way to be sure when there are lingering problems. Anyway, probably no need to worry about it unless you have further issues. Kris From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 18:41:58 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1CAF16A420 for ; Tue, 16 Oct 2007 18:41:58 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by mx1.freebsd.org (Postfix) with ESMTP id 6C0AF13C4AC for ; Tue, 16 Oct 2007 18:41:58 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so2303967fka for ; Tue, 16 Oct 2007 11:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=tXoCVxMdRehNuT1dDDLsqj+G7NJpg0iMyDc0YEtY8tU=; b=dHfanrVgf0pk26St0DSY3/Ta5F4J/GKozI6ygvrerwhCYNqH1nX3n+xzrO0cuNhr1btQ5QjRjVyOtmXNjIZLNqmHJG24CYbPuGBpYzIx0k9uu2AkJmcuTbqfGUIcaLby1WUIUGhIWjXyC7ln62gNKlRnp6+Z9m/RPCMKPzvTZP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h4w+i1F60N/V1uGyovtoVADdt22qpsduk9sv2YaykJ4UYPAKnaBVDhvfQTwUOUkkFAlyJCbvlhUD9/YIjr1uK+eXK/CYBe3/PSyhKf+tiPXhSifHjwlyL9vRO5q87OVKUhzgxYpAf5nJRRat5NDKnpAzo1QpgYNz12w6sE3um7w= Received: by 10.86.72.15 with SMTP id u15mr6106835fga.1192560116650; Tue, 16 Oct 2007 11:41:56 -0700 (PDT) Received: by 10.86.2.1 with HTTP; Tue, 16 Oct 2007 11:41:56 -0700 (PDT) Message-ID: <499c70c0710161141m9544dd4m13a81b2db941f70d@mail.gmail.com> Date: Tue, 16 Oct 2007 21:41:56 +0300 From: "Abdullah Ibn Hamad Al-Marri" To: pyunyh@gmail.com In-Reply-To: <20071015014227.GC75267@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <499c70c0710091846p3e2dd505sb54f18da30802d2d@mail.gmail.com> <20071010033122.GB54946@cdnetworks.co.kr> <499c70c0710100708g30a2912n1d1e72703d099dd0@mail.gmail.com> <20071011004814.GB58828@cdnetworks.co.kr> <499c70c0710140524n5ade2c39r4ff61dfa5ce9a47@mail.gmail.com> <20071015014227.GC75267@cdnetworks.co.kr> Cc: FreeBSD Stable List , Pyun YongHyeon Subject: Re: Realtek eth isn't detected in Intel DG31PR mobo X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 18:41:59 -0000 On 10/15/07, Pyun YongHyeon wrote: > On Sun, Oct 14, 2007 at 03:24:33PM +0300, Abdullah Ibn Hamad Al-Marri wrote: > > [...] > > Pyrun, > > > > I hope you are doing well. > > > > Thank you for the patch, and your good attempt to help with this issue. > > > > I spent 2 hours with the patch it did detect the Ethernet as re0 but the > > network did not work at all even though it said connected at auto 100 mbps > > full duplex. The server sent out a packet storm of arp traffic or some kind > > of traffic which caused a lot of problems in my overall network. I'm not > > exactly sure what happened but maybe you know about it. So I removed the > > patch and used the rl0 driver from Realtek again. > > > > It's very strange I didn't see anything like it before. > > > > Sorry, please try again with attached patch. > I guess I've misprogrammed Rx filter. > > -- > Regards, > Pyun YongHyeon Hello Pyun, Thanks for the patch, it's the same thing, didn't work, I know it's too hard since you don't have the hw to test it yourself. Do you need me to issue any command after using the patch? -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 18:57:17 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D304016A469 for ; Tue, 16 Oct 2007 18:57:17 +0000 (UTC) (envelope-from ekarkkai@pp.htv.fi) Received: from smtp6.pp.htv.fi (smtp6.pp.htv.fi [213.243.153.40]) by mx1.freebsd.org (Postfix) with ESMTP id 87E0413C4B2 for ; Tue, 16 Oct 2007 18:57:17 +0000 (UTC) (envelope-from ekarkkai@pp.htv.fi) Received: from zero.my.domain (cs181095217.pp.htv.fi [82.181.95.217]) by smtp6.pp.htv.fi (Postfix) with ESMTP id F251F5BC376 for ; Tue, 16 Oct 2007 21:57:15 +0300 (EEST) Received: from thunderbolt.my.domain (thunderbolt.my.domain [10.192.168.30]) by zero.my.domain (8.13.8/8.13.8) with ESMTP id l9GIvFs6003913 for ; Tue, 16 Oct 2007 21:57:15 +0300 (EEST) (envelope-from ekarkkai@pp.htv.fi) Received: from thunderbolt.my.domain (localhost [127.0.0.1]) by thunderbolt.my.domain (8.13.8/8.13.8) with ESMTP id l9GIvEGb008385 for ; Tue, 16 Oct 2007 21:57:14 +0300 (EEST) (envelope-from ejk@thunderbolt.my.domain) Received: (from ejk@localhost) by thunderbolt.my.domain (8.13.8/8.13.8/Submit) id l9GIvECP008384 for stable@freebsd.org; Tue, 16 Oct 2007 21:57:14 +0300 (EEST) (envelope-from ejk) Date: Tue, 16 Oct 2007 21:57:14 +0300 From: Esa Karkkainen To: stable@freebsd.org Message-ID: <20071016185714.GB2186@pp.htv.fi> Mail-Followup-To: Esa Karkkainen , stable@freebsd.org References: <20071004165755.GA1049@pp.htv.fi> <47120D83.1010703@FreeBSD.org> <20071015203202.GA17964@pp.htv.fi> <20071016004637.GA79351@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071016004637.GA79351@cdnetworks.co.kr> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 18:57:17 -0000 On Tue, Oct 16, 2007 at 09:46:37AM +0900, Pyun YongHyeon wrote: > I remember that nve(4) is NOT stable under heavy network loads. Yup, that seems to correct. Usually this machine, ie. home my orkstation, does not have a load, network wise or in general. > I'd like to say use nfe(4) which is believed to be more stable/fast > than nve(4). nfe(4) is also default NVIDIA NIC driver for > CURRENT/RELENG_7. If you have to use RELENG_6 try nfe(4) at the > following URL. Well, I could use -CURRENT or RELENG_7 in this machine, but I made a decision some time a go to use RELENG_6_2, because it's hassle free. -- "In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." -- Douglas Adams 1952 - 2001 From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 19:14:24 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E025A16A418 for ; Tue, 16 Oct 2007 19:14:24 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 4138A13C455 for ; Tue, 16 Oct 2007 19:14:24 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 16 Oct 2007 19:14:22 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp044) with SMTP; 16 Oct 2007 21:14:22 +0200 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX18xCcZ+RQUx/S7oYh2xZObxvIvHFf+M9ojgYBBHHZ cKk99ctyfmv+Ch Message-ID: <47150D87.3070804@gmx.de> Date: Tue, 16 Oct 2007 21:14:15 +0200 From: "[LoN]Kamikaze" User-Agent: Thunderbird 2.0.0.6 (X11/20071015) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: Subject: SCHED_4BSD in RELENG_7 disturbs workflow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 19:14:25 -0000 I know that RELENG_7 is not considered very near-release, but I thought I'd give my 2¢ in the hope that I might have a little influence on the scheduler development to my benefit. The switch from RELENG_6 to RELENG_7 went relatively smooth and apart from ipw causing panics. However there is one thing that's disturbing and this is the scheduler. I only have single core machines, so whatever I say only applies to those. If you think single-core machines are no longer important, feel free to ignore this. In deed, just ignore me however much you like. >From my perspective scheduling on RELENG_6 was way better. Even on a full workload like a portupgrade the focused application (both in X and on the console) always received enough cycles to run smoothly and applications that ran in background like audio players also kept on running fine. Quite the contrary on RELENG_7. During a portupgrade or even worse 'pkgdb -L' (recovering lost dependencies) audio players (both graphical and mplayer) scatter, either because they don't get the hard-disk or CPU-cycles (which one, I don't know) and the focused application also often hangs. It just looks like occasionally (under load) everything freezes for a second and then goes on relatively normal. I've got the impression that things compile a little faster (that might be my imagination, though), but I'd rather have a smooth working experience. This is just my view of the situation and I suppose it is only one of many. I bid you be merciful with us single-core people, who cannot afford a slick multi-core machine, because we worry how to pay for our food at the end of the month. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 19:22:43 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 561D416A468; Tue, 16 Oct 2007 19:22:43 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 8213E13C448; Tue, 16 Oct 2007 19:22:42 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47150F82.9060805@FreeBSD.org> Date: Tue, 16 Oct 2007 21:22:42 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "[LoN]Kamikaze" References: <47150D87.3070804@gmx.de> In-Reply-To: <47150D87.3070804@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCHED_4BSD in RELENG_7 disturbs workflow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 19:22:43 -0000 [LoN]Kamikaze wrote: > I know that RELENG_7 is not considered very near-release, but I thought I'd > give my 2¢ in the hope that I might have a little influence on the scheduler > development to my benefit. > > The switch from RELENG_6 to RELENG_7 went relatively smooth and apart from ipw > causing panics. However there is one thing that's disturbing and this is the > scheduler. I only have single core machines, so whatever I say only applies to > those. If you think single-core machines are no longer important, feel free to > ignore this. In deed, just ignore me however much you like. > >>From my perspective scheduling on RELENG_6 was way better. Even on a full > workload like a portupgrade the focused application (both in X and on the > console) always received enough cycles to run smoothly and applications that > ran in background like audio players also kept on running fine. > > Quite the contrary on RELENG_7. During a portupgrade or even worse 'pkgdb -L' > (recovering lost dependencies) audio players (both graphical and mplayer) > scatter, either because they don't get the hard-disk or CPU-cycles (which one, > I don't know) and the focused application also often hangs. It just looks like > occasionally (under load) everything freezes for a second and then goes on > relatively normal. > > I've got the impression that things compile a little faster (that might be my > imagination, though), but I'd rather have a smooth working experience. > > This is just my view of the situation and I suppose it is only one of many. I > bid you be merciful with us single-core people, who cannot afford a slick > multi-core machine, because we worry how to pay for our food at the end of the > month. Not to say that any problems that might have developed with SCHED_4BSD should not be fixed, but you should give SCHED_ULE a try since it brings benefits even for single CPU systems (e.g. better interactive response). Kris From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 19:38:46 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C017216A41B; Tue, 16 Oct 2007 19:38:46 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id 46FFF13C48E; Tue, 16 Oct 2007 19:38:45 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l9GJciR9046057; Wed, 17 Oct 2007 05:38:44 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l9GJchcM046056; Wed, 17 Oct 2007 05:38:43 +1000 (EST) (envelope-from peter) Date: Wed, 17 Oct 2007 05:38:43 +1000 From: Peter Jeremy To: Igor Sysoev Message-ID: <20071016193843.GD1184@turion.vk2pj.dyndns.org> References: <20071015141714.GL24828@rambler-co.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8S1fMsFYqgBC+BN/" Content-Disposition: inline In-Reply-To: <20071015141714.GL24828@rambler-co.ru> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 2G+ sysv shm segments X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 19:38:46 -0000 --8S1fMsFYqgBC+BN/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Oct-15 18:17:14 +0400, Igor Sysoev wrote: >more than 2G. The attached patches against 6.x and 7.x allow to create 2G+ >segments. Useful, thanks. >--- src/sys/sys/shm.h 2007-09-12 23:33:39.000000000 +0400 >+++ src/sys/sys/shm.h 2007-10-15 17:42:38.000000000 +0400 >@@ -77,7 +77,7 @@ >=20 > struct shmid_ds { > struct ipc_perm shm_perm; /* operation permission structure */ >- int shm_segsz; /* size of segment in bytes */ >+ size_t shm_segsz; /* size of segment in bytes */ =2E.. >--- src/usr.bin/ipcs/ipcs.c 2007-09-12 23:32:25.000000000 +0400 >+++ src/usr.bin/ipcs/ipcs.c 2007-10-15 17:29:06.000000000 +0400 >@@ -439,7 +439,7 @@ > kshmptr->u.shm_nattch); >=20 > if (option & BIGGEST) >- printf(" %12d", >+ printf(" %12ld", > kshmptr->u.shm_segsz); Note that size_t is always 'unsigned' and translates to 'int' rather than 'long' on i386 so this printf will report a warning. I suggest printf(" %12lu", (unsigned long)kshmptr->u.shm_segsz); or similar. --=20 Peter Jeremy --8S1fMsFYqgBC+BN/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHFRND/opHv/APuIcRAqy2AKCRekE1krJFNjtgAlhfr/JbdB1uWQCgmo9K ZHAgQqDVfpN2rWj8jZucB28= =00Gt -----END PGP SIGNATURE----- --8S1fMsFYqgBC+BN/-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 19:53:01 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1644016A417; Tue, 16 Oct 2007 19:53:01 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id C949513C49D; Tue, 16 Oct 2007 19:53:00 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.104] (cpe-66-91-190-165.hawaii.res.rr.com [66.91.190.165]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l9GJqu8k002127 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2007 15:52:58 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 16 Oct 2007 12:55:35 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Kris Kennaway In-Reply-To: <47150F82.9060805@FreeBSD.org> Message-ID: <20071016125400.N598@10.0.0.1> References: <47150D87.3070804@gmx.de> <47150F82.9060805@FreeBSD.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2127808575-1192564535=:598" Cc: "\[LoN\]Kamikaze" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCHED_4BSD in RELENG_7 disturbs workflow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 19:53:01 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2127808575-1192564535=:598 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 16 Oct 2007, Kris Kennaway wrote: > [LoN]Kamikaze wrote: >> I know that RELENG_7 is not considered very near-release, but I thought = I'd >> give my 2=C2=A2 in the hope that I might have a little influence on the= =20 >> scheduler >> development to my benefit. >>=20 >> The switch from RELENG_6 to RELENG_7 went relatively smooth and apart fr= om=20 >> ipw >> causing panics. However there is one thing that's disturbing and this is= =20 >> the >> scheduler. I only have single core machines, so whatever I say only appl= ies=20 >> to >> those. If you think single-core machines are no longer important, feel f= ree=20 >> to >> ignore this. In deed, just ignore me however much you like. >>=20 >>> From my perspective scheduling on RELENG_6 was way better. Even on a fu= ll >> workload like a portupgrade the focused application (both in X and on th= e >> console) always received enough cycles to run smoothly and applications= =20 >> that >> ran in background like audio players also kept on running fine. >>=20 >> Quite the contrary on RELENG_7. During a portupgrade or even worse 'pkgd= b=20 >> -L' >> (recovering lost dependencies) audio players (both graphical and mplayer= ) >> scatter, either because they don't get the hard-disk or CPU-cycles (whic= h=20 >> one, >> I don't know) and the focused application also often hangs. It just look= s=20 >> like >> occasionally (under load) everything freezes for a second and then goes = on >> relatively normal. >>=20 >> I've got the impression that things compile a little faster (that might = be=20 >> my >> imagination, though), but I'd rather have a smooth working experience. >>=20 >> This is just my view of the situation and I suppose it is only one of ma= ny.=20 >> I >> bid you be merciful with us single-core people, who cannot afford a slic= k >> multi-core machine, because we worry how to pay for our food at the end = of=20 >> the >> month. > > Not to say that any problems that might have developed with SCHED_4BSD sh= ould=20 > not be fixed, but you should give SCHED_ULE a try since it brings benefit= s=20 > even for single CPU systems (e.g. better interactive response). It would indeed be good to know if ULE improves things for you. However,= =20 there have been a number of other reports about non-scheduler related=20 regressions with x windows on 7.0. I run 7.0 on a UP laptop without=20 difficulty. I wonder if it has something to do with a particular device=20 or driver. Jeff > > Kris > _______________________________________________ > 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= " > --0-2127808575-1192564535=:598-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 19:53:52 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 536E516A41B; Tue, 16 Oct 2007 19:53:52 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id 11A4C13C469; Tue, 16 Oct 2007 19:53:51 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id DE81F95C1; Tue, 16 Oct 2007 23:53:50 +0400 (MSD) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id BC57C951A; Tue, 16 Oct 2007 23:53:50 +0400 (MSD) Date: Tue, 16 Oct 2007 23:53:43 +0400 From: Igor Sysoev To: Peter Jeremy Message-ID: <20071016195343.GK57989@rambler-co.ru> References: <20071015141714.GL24828@rambler-co.ru> <20071016193843.GD1184@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20071016193843.GD1184@turion.vk2pj.dyndns.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 2G+ sysv shm segments X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 19:53:52 -0000 On Wed, Oct 17, 2007 at 05:38:43AM +1000, Peter Jeremy wrote: > On 2007-Oct-15 18:17:14 +0400, Igor Sysoev wrote: > >more than 2G. The attached patches against 6.x and 7.x allow to create 2G+ > >segments. > > Useful, thanks. > > >--- src/sys/sys/shm.h 2007-09-12 23:33:39.000000000 +0400 > >+++ src/sys/sys/shm.h 2007-10-15 17:42:38.000000000 +0400 > >@@ -77,7 +77,7 @@ > > > > struct shmid_ds { > > struct ipc_perm shm_perm; /* operation permission structure */ > >- int shm_segsz; /* size of segment in bytes */ > >+ size_t shm_segsz; /* size of segment in bytes */ > ... > >--- src/usr.bin/ipcs/ipcs.c 2007-09-12 23:32:25.000000000 +0400 > >+++ src/usr.bin/ipcs/ipcs.c 2007-10-15 17:29:06.000000000 +0400 > >@@ -439,7 +439,7 @@ > > kshmptr->u.shm_nattch); > > > > if (option & BIGGEST) > >- printf(" %12d", > >+ printf(" %12ld", > > kshmptr->u.shm_segsz); > > Note that size_t is always 'unsigned' and translates to 'int' rather > than 'long' on i386 so this printf will report a warning. I suggest > printf(" %12lu", (unsigned long)kshmptr->u.shm_segsz); or similar. Here should be %zu. However, this patch can not be commited even to 7/8, because it does not preserve binary compatibility for shmctl(IPC_STAT). It seems that should be new shmctl syscall. -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 20:00:59 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B12CD16A46C; Tue, 16 Oct 2007 20:00:59 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 9691013C4AC; Tue, 16 Oct 2007 20:00:58 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47151879.50502@FreeBSD.org> Date: Tue, 16 Oct 2007 22:00:57 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Jeff Roberson References: <47150D87.3070804@gmx.de> <47150F82.9060805@FreeBSD.org> <20071016125400.N598@10.0.0.1> In-Reply-To: <20071016125400.N598@10.0.0.1> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "\[LoN\]Kamikaze" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCHED_4BSD in RELENG_7 disturbs workflow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 20:00:59 -0000 Jeff Roberson wrote: > On Tue, 16 Oct 2007, Kris Kennaway wrote: > >> [LoN]Kamikaze wrote: >>> I know that RELENG_7 is not considered very near-release, but I >>> thought I'd >>> give my 2¢ in the hope that I might have a little influence on the >>> scheduler >>> development to my benefit. >>> >>> The switch from RELENG_6 to RELENG_7 went relatively smooth and apart >>> from ipw >>> causing panics. However there is one thing that's disturbing and this >>> is the >>> scheduler. I only have single core machines, so whatever I say only >>> applies to >>> those. If you think single-core machines are no longer important, >>> feel free to >>> ignore this. In deed, just ignore me however much you like. >>> >>>> From my perspective scheduling on RELENG_6 was way better. Even on a >>>> full >>> workload like a portupgrade the focused application (both in X and on >>> the >>> console) always received enough cycles to run smoothly and >>> applications that >>> ran in background like audio players also kept on running fine. >>> >>> Quite the contrary on RELENG_7. During a portupgrade or even worse >>> 'pkgdb -L' >>> (recovering lost dependencies) audio players (both graphical and >>> mplayer) >>> scatter, either because they don't get the hard-disk or CPU-cycles >>> (which one, >>> I don't know) and the focused application also often hangs. It just >>> looks like >>> occasionally (under load) everything freezes for a second and then >>> goes on >>> relatively normal. >>> >>> I've got the impression that things compile a little faster (that >>> might be my >>> imagination, though), but I'd rather have a smooth working experience. >>> >>> This is just my view of the situation and I suppose it is only one of >>> many. I >>> bid you be merciful with us single-core people, who cannot afford a >>> slick >>> multi-core machine, because we worry how to pay for our food at the >>> end of the >>> month. >> >> Not to say that any problems that might have developed with SCHED_4BSD >> should not be fixed, but you should give SCHED_ULE a try since it >> brings benefits even for single CPU systems (e.g. better interactive >> response). > > It would indeed be good to know if ULE improves things for you. > However, there have been a number of other reports about non-scheduler > related regressions with x windows on 7.0. I run 7.0 on a UP laptop > without difficulty. I wonder if it has something to do with a > particular device or driver. Or xorg 7.3 vs 7.2, if this was an older 6.x install. Kris From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 20:02:01 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1921016A41A for ; Tue, 16 Oct 2007 20:02:01 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (mail.1command.com [75.160.109.226]) by mx1.freebsd.org (Postfix) with ESMTP id B96D713C4A8 for ; Tue, 16 Oct 2007 20:02:00 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id l9GK1ka2074849 for ; Tue, 16 Oct 2007 13:01:59 -0700 (PDT) (envelope-from chris#@1command.com) Received: (from www@localhost) by mail.1command.com (8.13.3/8.13.3/Submit) id l9GK1kHD074848 for freebsd-stable@freebsd.org; Tue, 16 Oct 2007 13:01:46 -0700 (PDT) (envelope-from chris#@1command.com) Received: from hitme.hitometer.net (hitme.hitometer.net [75.160.109.235]) by webmail.1command.com (H.R. Communications Messaging System) with HTTP; Tue, 16 Oct 2007 13:01:46 -0700 Message-ID: <20071016130146.pfyan4vs5cwgsoc0@webmail.1command.com> X-Priority: 3 (Normal) Date: Tue, 16 Oct 2007 13:01:46 -0700 From: "Chris H." To: freebsd-stable@freebsd.org References: <20071004165755.GA1049@pp.htv.fi> <47120D83.1010703@FreeBSD.org> <20071015203202.GA17964@pp.htv.fi> <20071016004637.GA79351@cdnetworks.co.kr> <20071016185714.GB2186@pp.htv.fi> In-Reply-To: <20071016185714.GB2186@pp.htv.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: H.R. Communications Internet Messaging System (HCIMS) 4.1 Professional (not for redistribution) / FreeBSD-5.5 Subject: Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 20:02:01 -0000 Quoting Esa Karkkainen : > On Tue, Oct 16, 2007 at 09:46:37AM +0900, Pyun YongHyeon wrote: >> I remember that nve(4) is NOT stable under heavy network loads. > > Yup, that seems to correct. Usually this machine, ie. home my > orkstation, does not have a load, network wise or in general. > >> I'd like to say use nfe(4) which is believed to be more stable/fast >> than nve(4). nfe(4) is also default NVIDIA NIC driver for >> CURRENT/RELENG_7. If you have to use RELENG_6 try nfe(4) at the >> following URL. > > Well, I could use -CURRENT or RELENG_7 in this machine, but I made a > decision some time a go to use RELENG_6_2, because it's hassle free. > Greetings, I had a situation that was exactly the same - excerpt from this list titled: NFS == lock && reboot, that I posted follows: ------8<---SNIP---8<-----SNIP-----8<------- # uname -a FreeBSD host.domain.tld 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 26 16:27:14 PST 2007 Greetings, Does anyone know when NFS and friends will be working again? I haven't been able to /safely/ use it from 4.8 on. I remember some talk on the list sometime ago and then it seemed to be resolved, as the discussion ended. So I thought it was fixed. Seems not. :( My scenario; mount host off root: mount script exec'd follows... #!/bin/sh - mount -t nfs host.domain.tld:/ /host mount -t nfs host.domain.tld:/var /host/var confirm mount... # ls /host .snap COPYRIGHT bin ... usr var tmp OK looks good... # cp /path/to/approx/10Mb/file /host/path/to/dest/dir/ Fatal double fault eis 0x0blah eiblah blah0x panic double fault no dump device defined rebooting in 15sec... Hmmm... that's not good. :( ------8<---SNIP---8<-----SNIP-----8<------- My final solution was to change the lines in /etc/rc.conf from: nfs_client_enable="YES" nfs_reserved_port_only="YES" nfs_server_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" rpcbind_enable="YES" to: nfs_client_enable="YES" nfs_reserved_port_only="YES" nfs_server_enable="YES" #rpc_lockd_enable="YES" #rpc_statd_enable="YES" rpcbind_enable="YES" Making those changes ended the "Fatal double fault && reboot in 15 seconds..." My nic is: ifconfig_nve0 Thanks for reporting the /buggy/ nve driver. So there are no issues with the nfe driver? Thanks again. --Chris -- panic: kernel trap (ignored) From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 20:08:33 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4893416A46B for ; Tue, 16 Oct 2007 20:08:33 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 8A37B13C461 for ; Tue, 16 Oct 2007 20:08:31 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 16 Oct 2007 20:08:30 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp035) with SMTP; 16 Oct 2007 22:08:30 +0200 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX197JPI+tT17OLO7xdRqd3dn14/71yddq0xnfkz7wR cNA5IvXFKe083Q Message-ID: <47151A37.8020301@gmx.de> Date: Tue, 16 Oct 2007 22:08:23 +0200 From: "[LoN]Kamikaze" User-Agent: Thunderbird 2.0.0.6 (X11/20071015) MIME-Version: 1.0 To: Jeff Roberson References: <47150D87.3070804@gmx.de> <47150F82.9060805@FreeBSD.org> <20071016125400.N598@10.0.0.1> In-Reply-To: <20071016125400.N598@10.0.0.1> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: Kris Kennaway , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCHED_4BSD in RELENG_7 disturbs workflow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 20:08:33 -0000 Jeff Roberson wrote: > On Tue, 16 Oct 2007, Kris Kennaway wrote: > >> [LoN]Kamikaze wrote: >>> I know that RELENG_7 is not considered very near-release, but I >>> thought I'd >>> give my 2¢ in the hope that I might have a little influence on the >>> scheduler >>> development to my benefit. >>> >>> The switch from RELENG_6 to RELENG_7 went relatively smooth and apart >>> from ipw >>> causing panics. However there is one thing that's disturbing and this >>> is the >>> scheduler. I only have single core machines, so whatever I say only >>> applies to >>> those. If you think single-core machines are no longer important, >>> feel free to >>> ignore this. In deed, just ignore me however much you like. >>> >>>> From my perspective scheduling on RELENG_6 was way better. Even on a >>>> full >>> workload like a portupgrade the focused application (both in X and on >>> the >>> console) always received enough cycles to run smoothly and >>> applications that >>> ran in background like audio players also kept on running fine. >>> >>> Quite the contrary on RELENG_7. During a portupgrade or even worse >>> 'pkgdb -L' >>> (recovering lost dependencies) audio players (both graphical and >>> mplayer) >>> scatter, either because they don't get the hard-disk or CPU-cycles >>> (which one, >>> I don't know) and the focused application also often hangs. It just >>> looks like >>> occasionally (under load) everything freezes for a second and then >>> goes on >>> relatively normal. >>> >>> I've got the impression that things compile a little faster (that >>> might be my >>> imagination, though), but I'd rather have a smooth working experience. >>> >>> This is just my view of the situation and I suppose it is only one of >>> many. I >>> bid you be merciful with us single-core people, who cannot afford a >>> slick >>> multi-core machine, because we worry how to pay for our food at the >>> end of the >>> month. >> >> Not to say that any problems that might have developed with SCHED_4BSD >> should not be fixed, but you should give SCHED_ULE a try since it >> brings benefits even for single CPU systems (e.g. better interactive >> response). > > It would indeed be good to know if ULE improves things for you. > However, there have been a number of other reports about non-scheduler > related regressions with x windows on 7.0. I run 7.0 on a UP laptop > without difficulty. I wonder if it has something to do with a > particular device or driver. > > Jeff Well, I'll certainly see soon. However I have switched from Xorg 7.2 to 7.3 first and that worked fine. Only after the update RELENG_6 to RELENG_7 did those issues appear. I have now recompiled all my 700+ ports to rule out compatibility problems (I had lots of panics before I did that, now everything is stable, unless I try to use my wireless device) and the performance issue remains. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 20:15:55 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8534216A469 for ; Tue, 16 Oct 2007 20:15:55 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id D7FF213C48A for ; Tue, 16 Oct 2007 20:15:54 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 16 Oct 2007 20:15:53 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp005) with SMTP; 16 Oct 2007 22:15:53 +0200 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX18Qqo9h7MoQks+aLL25dsuY5E5UJ6BF9YcizCbJ6N Pk2W+9WjQPs2QJ Message-ID: <47151BF2.6020103@gmx.de> Date: Tue, 16 Oct 2007 22:15:46 +0200 From: "[LoN]Kamikaze" User-Agent: Thunderbird 2.0.0.6 (X11/20071015) MIME-Version: 1.0 To: josh.carroll@gmail.com References: <47150D87.3070804@gmx.de> <47150F82.9060805@FreeBSD.org> <8cb6106e0710161309o4658f41fse686b637d96be7f1@mail.gmail.com> In-Reply-To: <8cb6106e0710161309o4658f41fse686b637d96be7f1@mail.gmail.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Kris Kennaway , freebsd-stable@freebsd.org Subject: Re: SCHED_4BSD in RELENG_7 disturbs workflow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 20:15:55 -0000 Josh Carroll wrote: >> Not to say that any problems that might have developed with SCHED_4BSD >> should not be fixed, but you should give SCHED_ULE a try since it brings >> benefits even for single CPU systems (e.g. better interactive response). > > For my particular work load, 4BSD is actually faster than ULE in > RELENG_7. Specifically, on a Q6600 running ffmpeg -threads 8 to > transcode some H.264 video, 4BSD is about 5% faster. I took a sample > video and transcoded the first 120 seconds of it, and here are the > results (including a control from 6.2-RELEASE-p7/4BSD scheduler): > > releng_6_2 (4BSD) 1:32.39 > releng_7 (4BSD) 1:32.44 > releng_7 (ULE) 1:37.15 > > This is obviously a different scenario from MySQL. So perhaps ULE > isn't as well tuned for cases like ffmpeg? > > Josh > I suspect that the increased performance is stolen from the process with focus. I don't care much about my calculation being 5% faster if that renders the machine unusable. From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 20:20:15 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D711016A420 for ; Tue, 16 Oct 2007 20:20:15 +0000 (UTC) (envelope-from robert.a.chalmers@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.239]) by mx1.freebsd.org (Postfix) with ESMTP id 8111013C47E for ; Tue, 16 Oct 2007 20:20:15 +0000 (UTC) (envelope-from robert.a.chalmers@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1246023nzf for ; Tue, 16 Oct 2007 13:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:to:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:importance:x-mailer:x-mimeole:from; bh=6/BxuKYOCLKSvuZ6wPG222p76zCh4hJGiOWwaQLDWvw=; b=Zdej6vQSV7jB3HUeo0NPIim0e1sD+8MPN4P1q6k5rbEaqmQOhmzOqqGCWFMeanzLF3vw3Q79wY7OIaoODS6eigQG+zrXwa1FU6pvUy3Q4hqAGkQclmUiXlPNbmD31jTFywiul2wTnvNd6jtxJdLfuxgmhc0SMvvVOTLzLnYgUFk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:to:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:importance:x-mailer:x-mimeole:from; b=LUDUdS+9RJPlaapqpRMxsxk+SlYibLtLLeSppT+uyi6nQ4hOKBWK2dqfX/4keAq3TsRUW6pI/BndTwGZFVulfNdp1Cd7Xx3NWSy9OrcVLVgJbZEWBzhFStsBhBYp2YZg6f2MpwAGOD/Xim4VATbYWIuf/6+YyJRa5fjSU/2dXdE= Received: by 10.115.59.4 with SMTP id m4mr8886717wak.1192566013195; Tue, 16 Oct 2007 13:20:13 -0700 (PDT) Received: from Avalon ( [122.129.133.78]) by mx.google.com with ESMTPS id k24sm11458669waf.2007.10.16.13.19.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Oct 2007 13:20:12 -0700 (PDT) Message-ID: <35A20E3A85224FF6B39A0D3D07438534@Avalon> To: References: <20071016132532.H23320@cbynevgl.hper> Date: Wed, 17 Oct 2007 06:18:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1184 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1184 From: Robert Chalmers Subject: Thanks, done. Re: can I do 6.1-RELEASE to 6.2 via cvsup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 20:20:15 -0000 Thanks guys, All done. Just wasn't sure if I could do the upgrade via cvsup. all done, all working. cool Thanks for everyone's help. rob ----- Original Message ----- From: "CmdLnKid" To: "Robert Chalmers" Cc: Sent: Wednesday, October 17, 2007 1:29 AM Subject: Re: can I do 6.1-RELEASE to 6.2 via cvsup > On Tue, 16 Oct 2007 05:42 +0800, robert.a.chalmers wrote: > >> >> I should just be able to change the TAG in standard-supfile from 6_1 to >> 6_2, >> do a cvsup, and the builds etc to end up with 6.2-RELEASE right? >> yes? no? >> >> ta >> rob >> > > Change that tag and then follow anything thats said in the README > UPDATING & Makefile. > > Specificly follow this after you upgrade your sources. > ( head -n55 /usr/src/Makefile |tail -n13 ) > > -- > > - (2^(N-1)) > From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 20:22:53 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB3AB16A47C for ; Tue, 16 Oct 2007 20:22:53 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by mx1.freebsd.org (Postfix) with ESMTP id 90EBD13C474 for ; Tue, 16 Oct 2007 20:22:53 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: by malasada.lava.net (Postfix, from userid 102) id 9491D153883; Tue, 16 Oct 2007 10:22:52 -1000 (HST) Date: Tue, 16 Oct 2007 10:22:52 -1000 From: Clifton Royston To: "Chris H." Message-ID: <20071016202251.GC4047@lava.net> Mail-Followup-To: "Chris H." , freebsd-stable@freebsd.org References: <20071004165755.GA1049@pp.htv.fi> <47120D83.1010703@FreeBSD.org> <20071015203202.GA17964@pp.htv.fi> <20071016004637.GA79351@cdnetworks.co.kr> <20071016185714.GB2186@pp.htv.fi> <20071016130146.pfyan4vs5cwgsoc0@webmail.1command.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071016130146.pfyan4vs5cwgsoc0@webmail.1command.com> User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org Subject: Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 20:22:53 -0000 On Tue, Oct 16, 2007 at 01:01:46PM -0700, Chris H. wrote: > excerpt from this list titled: NFS == lock && reboot, that I posted follows: > > ------8<---SNIP---8<-----SNIP-----8<------- > # uname -a > FreeBSD host.domain.tld 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 26 > 16:27:14 PST 2007 > > Greetings, > Does anyone know when NFS and friends will be working again? I haven't > been able > to /safely/ use it from 4.8 on. I remember some talk on the list > sometime ago and > then it seemed to be resolved, as the discussion ended. So I thought it was > fixed. Seems not. :( > > My scenario; > mount host off root: > mount script exec'd follows... > > #!/bin/sh - > mount -t nfs host.domain.tld:/ /host > mount -t nfs host.domain.tld:/var /host/var > > confirm mount... > > # ls /host > .snap COPYRIGHT bin > ... > usr var tmp > > OK looks good... > > # cp /path/to/approx/10Mb/file /host/path/to/dest/dir/ > > Fatal double fault > eis 0x0blah > eiblah blah0x > panic double fault > no dump device defined > rebooting in 15sec... > > Hmmm... that's not good. :( > > ------8<---SNIP---8<-----SNIP-----8<------- > > My final solution was to change the lines in /etc/rc.conf > from: > nfs_client_enable="YES" > nfs_reserved_port_only="YES" > nfs_server_enable="YES" > rpc_lockd_enable="YES" > rpc_statd_enable="YES" > rpcbind_enable="YES" > > to: > nfs_client_enable="YES" > nfs_reserved_port_only="YES" > nfs_server_enable="YES" > #rpc_lockd_enable="YES" > #rpc_statd_enable="YES" > rpcbind_enable="YES" > > Making those changes ended the "Fatal double fault && reboot in 15 > seconds..." Thanks for this very timely mention! The cluster of servers I am about to upgrade from 4.8 to 6.2 relies heavily on NFS to an old Netapp. If I have got to disable rpc_lockd and rpc_statd, it's good to know that now! Can I ask, can anybody confirm that they're running 6.2 on NFS successfully *with* lockd and statd? -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 20:27:26 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8838516A417; Tue, 16 Oct 2007 20:27:26 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6051113C48E; Tue, 16 Oct 2007 20:27:26 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.104] (cpe-66-91-190-165.hawaii.res.rr.com [66.91.190.165]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l9GKRMx0012942 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2007 16:27:24 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 16 Oct 2007 13:30:01 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: "[LoN]Kamikaze" In-Reply-To: <47151A37.8020301@gmx.de> Message-ID: <20071016132931.J598@10.0.0.1> References: <47150D87.3070804@gmx.de> <47150F82.9060805@FreeBSD.org> <20071016125400.N598@10.0.0.1> <47151A37.8020301@gmx.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1946227734-1192566601=:598" Cc: Kris Kennaway , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCHED_4BSD in RELENG_7 disturbs workflow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 20:27:26 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1946227734-1192566601=:598 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 16 Oct 2007, [LoN]Kamikaze wrote: > Jeff Roberson wrote: >> On Tue, 16 Oct 2007, Kris Kennaway wrote: >> >>> [LoN]Kamikaze wrote: >>>> I know that RELENG_7 is not considered very near-release, but I >>>> thought I'd >>>> give my 2=C2=A2 in the hope that I might have a little influence on th= e >>>> scheduler >>>> development to my benefit. >>>> >>>> The switch from RELENG_6 to RELENG_7 went relatively smooth and apart >>>> from ipw >>>> causing panics. However there is one thing that's disturbing and this >>>> is the >>>> scheduler. I only have single core machines, so whatever I say only >>>> applies to >>>> those. If you think single-core machines are no longer important, >>>> feel free to >>>> ignore this. In deed, just ignore me however much you like. >>>> >>>>> From my perspective scheduling on RELENG_6 was way better. Even on a >>>>> full >>>> workload like a portupgrade the focused application (both in X and on >>>> the >>>> console) always received enough cycles to run smoothly and >>>> applications that >>>> ran in background like audio players also kept on running fine. >>>> >>>> Quite the contrary on RELENG_7. During a portupgrade or even worse >>>> 'pkgdb -L' >>>> (recovering lost dependencies) audio players (both graphical and >>>> mplayer) >>>> scatter, either because they don't get the hard-disk or CPU-cycles >>>> (which one, >>>> I don't know) and the focused application also often hangs. It just >>>> looks like >>>> occasionally (under load) everything freezes for a second and then >>>> goes on >>>> relatively normal. >>>> >>>> I've got the impression that things compile a little faster (that >>>> might be my >>>> imagination, though), but I'd rather have a smooth working experience. >>>> >>>> This is just my view of the situation and I suppose it is only one of >>>> many. I >>>> bid you be merciful with us single-core people, who cannot afford a >>>> slick >>>> multi-core machine, because we worry how to pay for our food at the >>>> end of the >>>> month. >>> >>> Not to say that any problems that might have developed with SCHED_4BSD >>> should not be fixed, but you should give SCHED_ULE a try since it >>> brings benefits even for single CPU systems (e.g. better interactive >>> response). >> >> It would indeed be good to know if ULE improves things for you. >> However, there have been a number of other reports about non-scheduler >> related regressions with x windows on 7.0. I run 7.0 on a UP laptop >> without difficulty. I wonder if it has something to do with a >> particular device or driver. >> >> Jeff > > Well, I'll certainly see soon. However I have switched from Xorg 7.2 to 7= =2E3 > first and that worked fine. Only after the update RELENG_6 to RELENG_7 di= d > those issues appear. I have now recompiled all my 700+ ports to rule out > compatibility problems (I had lots of panics before I did that, now every= thing > is stable, unless I try to use my wireless device) and the performance is= sue > remains. > Can you give us a full dmesg? Thanks, jeff --0-1946227734-1192566601=:598-- From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 20:32:28 2007 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB57F16A417 for ; Tue, 16 Oct 2007 20:32:28 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id 79A7513C474 for ; Tue, 16 Oct 2007 20:32:28 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l9GJtFZc018002; Tue, 16 Oct 2007 15:55:15 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Tue, 16 Oct 2007 15:55:07 -0400 User-Agent: KMail/1.6.2 References: <20071015141714.GL24828@rambler-co.ru> In-Reply-To: <20071015141714.GL24828@rambler-co.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200710161555.12384.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV version 0.90.2, clamav-milter version 0.90.2 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Peter Jeremy , freebsd-stable@FreeBSD.org Subject: Re: 2G+ sysv shm segments X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 20:32:28 -0000 On Monday 15 October 2007 10:17 am, Igor Sysoev wrote: > Two years ago Christian S.J. Peron had increased total number of > SysV shm pages on 64-bit platform, that allows to create many shm > segments more than 2G in sum. However, the patch does not allow to > create a single large segment more than 2G. The attached patches > against 6.x and 7.x allow to create 2G+ segments. I know that stock > 6.x will not have this feature because of compatibility, but I send > 6.x patch too because someone may want to use 2G+ shm on 6.x. > > To install: > > patch -d < /usr < big_sysvshmX.txt > > [ rebuild kernel ] > > cd /usr/src/include/ > make obj > make > make install > > cd /usr/src/usr.bin/ipcs/ > make obj > make > make install Actually there is a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=113218 Unfortunately it breaks ABI because it increases sizeof(struct shmid_ds). Since the tree is unfrozen, I can commit it, though. ;-) Jung-uk Kim [Note: Peter, thanks for the casting suggestion.] From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 20:32:56 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3C1516A417 for ; Tue, 16 Oct 2007 20:32:56 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id DA69D13C4AA; Tue, 16 Oct 2007 20:32:55 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47151FF7.2080501@FreeBSD.org> Date: Tue, 16 Oct 2007 22:32:55 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "Chris H." , freebsd-stable@freebsd.org References: <20071004165755.GA1049@pp.htv.fi> <47120D83.1010703@FreeBSD.org> <20071015203202.GA17964@pp.htv.fi> <20071016004637.GA79351@cdnetworks.co.kr> <20071016185714.GB2186@pp.htv.fi> <20071016130146.pfyan4vs5cwgsoc0@webmail.1command.com> <20071016202251.GC4047@lava.net> In-Reply-To: <20071016202251.GC4047@lava.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 20:32:56 -0000 Clifton Royston wrote: > On Tue, Oct 16, 2007 at 01:01:46PM -0700, Chris H. wrote: >> excerpt from this list titled: NFS == lock && reboot, that I posted follows: >> >> ------8<---SNIP---8<-----SNIP-----8<------- >> # uname -a >> FreeBSD host.domain.tld 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 26 >> 16:27:14 PST 2007 >> >> Greetings, >> Does anyone know when NFS and friends will be working again? I haven't >> been able >> to /safely/ use it from 4.8 on. I remember some talk on the list >> sometime ago and >> then it seemed to be resolved, as the discussion ended. So I thought it was >> fixed. Seems not. :( >> >> My scenario; >> mount host off root: >> mount script exec'd follows... >> >> #!/bin/sh - >> mount -t nfs host.domain.tld:/ /host >> mount -t nfs host.domain.tld:/var /host/var >> >> confirm mount... >> >> # ls /host >> .snap COPYRIGHT bin >> ... >> usr var tmp >> >> OK looks good... >> >> # cp /path/to/approx/10Mb/file /host/path/to/dest/dir/ >> >> Fatal double fault >> eis 0x0blah >> eiblah blah0x >> panic double fault >> no dump device defined >> rebooting in 15sec... >> >> Hmmm... that's not good. :( >> >> ------8<---SNIP---8<-----SNIP-----8<------- >> >> My final solution was to change the lines in /etc/rc.conf >> from: >> nfs_client_enable="YES" >> nfs_reserved_port_only="YES" >> nfs_server_enable="YES" >> rpc_lockd_enable="YES" >> rpc_statd_enable="YES" >> rpcbind_enable="YES" >> >> to: >> nfs_client_enable="YES" >> nfs_reserved_port_only="YES" >> nfs_server_enable="YES" >> #rpc_lockd_enable="YES" >> #rpc_statd_enable="YES" >> rpcbind_enable="YES" >> >> Making those changes ended the "Fatal double fault && reboot in 15 >> seconds..." > > Thanks for this very timely mention! The cluster of servers I am > about to upgrade from 4.8 to 6.2 relies heavily on > NFS to an old Netapp. If I have got to disable rpc_lockd and > rpc_statd, it's good to know that now! > > Can I ask, can anybody confirm that they're running 6.2 on NFS > successfully *with* lockd and statd? Er, yes, of course it does. The old message he is quoting is bogus on its own, I don't know if he ever was able to provide meaningful traces but it may well be nve as in the upthread discussion. Kris From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 20:35:03 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76CDC16A46C for ; Tue, 16 Oct 2007 20:35:03 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id C127513C4AA for ; Tue, 16 Oct 2007 20:35:02 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 16 Oct 2007 20:35:01 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp020) with SMTP; 16 Oct 2007 22:35:01 +0200 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX1/rWQQ2mAbrxU7GSsIU4DzUeJ/aKDfPxkScwhyQA5 i+PhelfFrnI7Ca Message-ID: <4715206E.50307@gmx.de> Date: Tue, 16 Oct 2007 22:34:54 +0200 From: "[LoN]Kamikaze" User-Agent: Thunderbird 2.0.0.6 (X11/20071015) MIME-Version: 1.0 To: Jeff Roberson References: <47150D87.3070804@gmx.de> <47150F82.9060805@FreeBSD.org> <20071016125400.N598@10.0.0.1> <47151A37.8020301@gmx.de> <20071016132931.J598@10.0.0.1> In-Reply-To: <20071016132931.J598@10.0.0.1> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: Kris Kennaway , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCHED_4BSD in RELENG_7 disturbs workflow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 20:35:03 -0000 Jeff Roberson wrote: > On Tue, 16 Oct 2007, [LoN]Kamikaze wrote: > >> Jeff Roberson wrote: >>> On Tue, 16 Oct 2007, Kris Kennaway wrote: >>> >>>> [LoN]Kamikaze wrote: >>>>> I know that RELENG_7 is not considered very near-release, but I >>>>> thought I'd >>>>> give my 2¢ in the hope that I might have a little influence on the >>>>> scheduler >>>>> development to my benefit. >>>>> >>>>> The switch from RELENG_6 to RELENG_7 went relatively smooth and apart >>>>> from ipw >>>>> causing panics. However there is one thing that's disturbing and this >>>>> is the >>>>> scheduler. I only have single core machines, so whatever I say only >>>>> applies to >>>>> those. If you think single-core machines are no longer important, >>>>> feel free to >>>>> ignore this. In deed, just ignore me however much you like. >>>>> >>>>>> From my perspective scheduling on RELENG_6 was way better. Even on a >>>>>> full >>>>> workload like a portupgrade the focused application (both in X and on >>>>> the >>>>> console) always received enough cycles to run smoothly and >>>>> applications that >>>>> ran in background like audio players also kept on running fine. >>>>> >>>>> Quite the contrary on RELENG_7. During a portupgrade or even worse >>>>> 'pkgdb -L' >>>>> (recovering lost dependencies) audio players (both graphical and >>>>> mplayer) >>>>> scatter, either because they don't get the hard-disk or CPU-cycles >>>>> (which one, >>>>> I don't know) and the focused application also often hangs. It just >>>>> looks like >>>>> occasionally (under load) everything freezes for a second and then >>>>> goes on >>>>> relatively normal. >>>>> >>>>> I've got the impression that things compile a little faster (that >>>>> might be my >>>>> imagination, though), but I'd rather have a smooth working experience. >>>>> >>>>> This is just my view of the situation and I suppose it is only one of >>>>> many. I >>>>> bid you be merciful with us single-core people, who cannot afford a >>>>> slick >>>>> multi-core machine, because we worry how to pay for our food at the >>>>> end of the >>>>> month. >>>> >>>> Not to say that any problems that might have developed with SCHED_4BSD >>>> should not be fixed, but you should give SCHED_ULE a try since it >>>> brings benefits even for single CPU systems (e.g. better interactive >>>> response). >>> >>> It would indeed be good to know if ULE improves things for you. >>> However, there have been a number of other reports about non-scheduler >>> related regressions with x windows on 7.0. I run 7.0 on a UP laptop >>> without difficulty. I wonder if it has something to do with a >>> particular device or driver. >>> >>> Jeff >> >> Well, I'll certainly see soon. However I have switched from Xorg 7.2 >> to 7.3 >> first and that worked fine. Only after the update RELENG_6 to RELENG_7 >> did >> those issues appear. I have now recompiled all my 700+ ports to rule out >> compatibility problems (I had lots of panics before I did that, now >> everything >> is stable, unless I try to use my wireless device) and the performance >> issue >> remains. >> > > Can you give us a full dmesg? > > Thanks, > jeff Ye ask and ye shall receive: Copyright (c) 1992-2007 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 7.0-PRERELEASE #0: Fri Oct 12 16:36:39 CEST 2007 root@homeKamikaze.norad:/usr/obj/TPR40-7/i386/usr/src/sys/TPR40-7 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1300MHz (1295.80-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Features=0xa7e9f9bf Features2=0x180 real memory = 1341521920 (1279 MB) avail memory = 1300160512 (1239 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or length: 0 102C/0 [20070320] acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 4ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x3000-0x30ff mem 0xe0000000-0xe7ffffff,0xc0100000-0xc010ffff irq 11 at device 0.0 on pci1 uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xc0000000-0xc00003ff irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib2: at device 30.0 on pci0 pci2: on pcib2 cbb0: irq 11 at device 0.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] pci2: at device 2.0 (no driver attached) fwohci0: mem 0xc0206000-0xc02067ff,0xc0200000-0xc0203fff irq 11 at device 7.0 on pci2 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:06:1b:00:20:12:aa:75 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1488000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:06:1b:12:aa:75 fwe0: Ethernet address: 02:06:1b:12:aa:75 fwip0: on firewire0 fwip0: Firewire address: 00:06:1b:00:20:12:aa:75 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode fxp0: port 0x8000-0x803f mem 0xc0205000-0xc0205fff irq 11 at device 8.0 on pci2 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:06:1b:e0:e4:eb fxp0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff mem 0xc0000c00-0xc0000dff,0xc0000800-0xc00008ff irq 11 at device 31.5 on pci0 pcm0: [ITHREAD] pcm0: pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Synaptics Touchpad, device ID 0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: port 0x2f8-0x2ff irq 3 drq 3 on acpi0 sio1: type 16550A sio1: [FILTER] battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd1fff,0xdc000-0xdffff,0xe0000-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range Timecounter "TSC" frequency 1295803760 Hz quality 800 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad0: 114473MB at ata0-master UDMA100 acd0: CDRW at ata1-master UDMA33 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 0x00 0x01 cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Trying to mount root from ufs:/dev/ad0s2a ipw0: mem 0xc0204000-0xc0204fff irq 11 at device 2.0 on pci2 ipw0: using obsoleted if_watchdog interface ipw0: Ethernet address: 00:04:23:79:66:68 ipw0: [ITHREAD] ipw0: detached drm0: on vgapci0 info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized radeon 1.25.0 20060524 info: [drm] Setting GART location based on new memory map info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] ipw0: mem 0xc0204000-0xc0204fff irq 11 at device 2.0 on pci2 ipw0: using obsoleted if_watchdog interface ipw0: Ethernet address: 00:04:23:79:66:68 ipw0: [ITHREAD] ipw0: detached info: [drm] Setting GART location based on new memory map info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 20:36:33 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECE0F16A417 for ; Tue, 16 Oct 2007 20:36:33 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by mx1.freebsd.org (Postfix) with ESMTP id AE0E613C468 for ; Tue, 16 Oct 2007 20:36:33 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so108484wra for ; Tue, 16 Oct 2007 13:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=xIx33vVfhXmpHF/+6feJYGnBa76TpbNW/44KBOx03qY=; b=ci0vXnHzhzt8dxysHumSvKXoM35NfHeDeid0pCGo9drc++YEKzXorp81Mr0gfGtcwxwiLNfqN8eIgIpXtOkal5OJgQJWZGeghE9+po4rJKTMQJh23mi8bEuZxnhMyMfxovsPmm0sq1+ETBSDbNp619hJU9Xr9pc1AiObxxVFljM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kXAsx6ql4c6I71tZZahcekD+bNr27ozrKYDziSBkyCmu2kx0qUDqISoJLjmcKhzjmQX5qauqR8Iy4vRMzNu5HbrUqn4mEiRDG4yD6OSfhy9xQVrub8Gh6kfVzhsAFdU6rjsW4JLwxUVReaZH7tsU2Pkdl24xKJXTZWZSEI4GBoI= Received: by 10.90.91.14 with SMTP id o14mr11320652agb.1192565395876; Tue, 16 Oct 2007 13:09:55 -0700 (PDT) Received: by 10.90.29.9 with HTTP; Tue, 16 Oct 2007 13:09:55 -0700 (PDT) Message-ID: <8cb6106e0710161309o4658f41fse686b637d96be7f1@mail.gmail.com> Date: Tue, 16 Oct 2007 16:09:55 -0400 From: "Josh Carroll" To: "Kris Kennaway" In-Reply-To: <47150F82.9060805@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47150D87.3070804@gmx.de> <47150F82.9060805@FreeBSD.org> Cc: "\[LoN\]Kamikaze" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCHED_4BSD in RELENG_7 disturbs workflow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 20:36:34 -0000 > Not to say that any problems that might have developed with SCHED_4BSD > should not be fixed, but you should give SCHED_ULE a try since it brings > benefits even for single CPU systems (e.g. better interactive response). For my particular work load, 4BSD is actually faster than ULE in RELENG_7. Specifically, on a Q6600 running ffmpeg -threads 8 to transcode some H.264 video, 4BSD is about 5% faster. I took a sample video and transcoded the first 120 seconds of it, and here are the results (including a control from 6.2-RELEASE-p7/4BSD scheduler): releng_6_2 (4BSD) 1:32.39 releng_7 (4BSD) 1:32.44 releng_7 (ULE) 1:37.15 This is obviously a different scenario from MySQL. So perhaps ULE isn't as well tuned for cases like ffmpeg? Josh From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 20:43:35 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22B6D16A421; Tue, 16 Oct 2007 20:43:35 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id D8E5513C46A; Tue, 16 Oct 2007 20:43:34 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.104] (cpe-66-91-190-165.hawaii.res.rr.com [66.91.190.165]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l9GKhVpL017432 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2007 16:43:33 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 16 Oct 2007 13:46:10 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Josh Carroll In-Reply-To: <8cb6106e0710161309o4658f41fse686b637d96be7f1@mail.gmail.com> Message-ID: <20071016134426.F598@10.0.0.1> References: <47150D87.3070804@gmx.de> <47150F82.9060805@FreeBSD.org> <8cb6106e0710161309o4658f41fse686b637d96be7f1@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "\[LoN\]Kamikaze" , Kris Kennaway , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCHED_4BSD in RELENG_7 disturbs workflow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 20:43:35 -0000 On Tue, 16 Oct 2007, Josh Carroll wrote: >> Not to say that any problems that might have developed with SCHED_4BSD >> should not be fixed, but you should give SCHED_ULE a try since it brings >> benefits even for single CPU systems (e.g. better interactive response). > > For my particular work load, 4BSD is actually faster than ULE in > RELENG_7. Specifically, on a Q6600 running ffmpeg -threads 8 to > transcode some H.264 video, 4BSD is about 5% faster. I took a sample > video and transcoded the first 120 seconds of it, and here are the > results (including a control from 6.2-RELEASE-p7/4BSD scheduler): > > releng_6_2 (4BSD) 1:32.39 > releng_7 (4BSD) 1:32.44 > releng_7 (ULE) 1:37.15 > > This is obviously a different scenario from MySQL. So perhaps ULE > isn't as well tuned for cases like ffmpeg? Hi Josh, thanks for the report. How many CPUs are in your system? Can you give me the output of 'vmstat 5' over the course of one run on 4BSD and ULE? Or just one of them if you can't spare the time. Thanks, Jeff > > Josh > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 22:05:21 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89D2E16A417 for ; Tue, 16 Oct 2007 22:05:21 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.232]) by mx1.freebsd.org (Postfix) with ESMTP id 4922413C44B for ; Tue, 16 Oct 2007 22:05:21 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1833327wxd for ; Tue, 16 Oct 2007 15:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=APEOXi96j2UKWTUB7xNjKf3Z2pDC0JEe02QeGn7RuMo=; b=U70HnnnZsNFbe6d7DqAXiWJt+7PIh3Cook224RN7QkrsuxZDiVMcV47xqa/ysOHnzaGRWhQI3/hsg3Er1g5ER8q6oGqsQpMgBzKxH3wUyPyc4c62EoFLOLlf+7W4/04UtTUhS9X6Gkp2o8Dz6k66vu5ZuVbZ1dWjA8cxCzmaHcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ym+M2Qo83GJAcVISlveCnAKTxW7U5ShBPDjAVQ1xF7SbAUhd2/fLypEe7UmLnNdA2cKVMsEolG/05XEnHHImTfqvs4kd0x1Us7BYTuWG/eRSPvK+7NcWypF33hW2i69kYsVrAzXOM+amA7rWjc9ywtxIiqv286JF/7yt1xBpg7g= Received: by 10.90.69.8 with SMTP id r8mr11415811aga.1192570630737; Tue, 16 Oct 2007 14:37:10 -0700 (PDT) Received: by 10.90.29.9 with HTTP; Tue, 16 Oct 2007 14:37:10 -0700 (PDT) Message-ID: <8cb6106e0710161437v78957768w1b855da7ba177873@mail.gmail.com> Date: Tue, 16 Oct 2007 17:37:10 -0400 From: "Josh Carroll" To: "Jeff Roberson" In-Reply-To: <20071016134426.F598@10.0.0.1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47150D87.3070804@gmx.de> <47150F82.9060805@FreeBSD.org> <8cb6106e0710161309o4658f41fse686b637d96be7f1@mail.gmail.com> <20071016134426.F598@10.0.0.1> Cc: "\[LoN\]Kamikaze" , Kris Kennaway , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCHED_4BSD in RELENG_7 disturbs workflow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 22:05:21 -0000 > Hi Josh, thanks for the report. How many CPUs are in your system? Can > you give me the output of 'vmstat 5' over the course of one run on 4BSD > and ULE? Or just one of them if you can't spare the time. Hi Jeff, The system has a single quad-core chip, namely an Intel Core 2 Quad Q6600. Below is the requested vmstat output. Please let me know if you need anything else (or if I should start a separate thread on -stable, so as not to hijack this thread). I'm not sure what you wanted to see from the vmstat output, but I do notice that with the ULE scheduler, the idle percentage is higher than for 4BSD. As an aside, -threads 8 seems to be optimal, despite only have 4 cores. Here are the vmstat outputs: 4BSD: procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad6 ad8 in sy cs us sy id 1 1 0 412348 1589544 508 0 0 0 507 0 0 0 22 694 643 3 0 97 3 1 0 754860 1416760 8504 0 0 0 20 0 0 0 15 1339 2092 94 1 5 6 1 0 757940 1402456 565 0 0 0 1 0 0 0 18 1081 944 98 0 2 6 1 0 757940 1396564 188 0 0 0 3 0 15 0 45 1136 1075 96 0 4 7 1 0 757940 1393236 30 0 0 0 1 0 1 0 21 937 851 97 0 3 6 2 0 760192 1390756 60 0 0 1 43 0 5 0 25 1065 902 96 0 3 5 2 0 760192 1390304 3 0 0 0 100 0 0 0 19 1365 1240 98 0 2 4 1 0 758964 1388592 25 0 0 0 16 0 0 0 15 997 869 96 0 4 7 1 0 758964 1386132 3 0 0 0 0 0 0 0 14 810 766 96 0 4 5 1 0 758964 1383608 2 0 0 0 0 0 0 0 28 695 713 99 0 1 4 1 0 758964 1380372 26 0 0 0 1 0 7 0 29 806 842 96 0 3 7 1 0 759992 1377440 11 0 0 0 1 0 1 0 29 810 802 98 0 2 3 1 0 759992 1375412 2 0 0 0 2 0 0 0 20 879 785 97 0 3 4 1 0 759992 1373168 1 0 0 0 1 0 0 0 13 1032 876 95 0 5 5 1 0 759992 1371204 2 0 0 0 0 0 0 0 21 1197 984 85 0 15 5 1 0 759992 1367676 3 0 0 0 0 0 0 0 20 1155 897 98 0 1 4 1 0 759992 1362272 24 0 0 0 0 0 0 0 21 826 719 98 0 2 6 2 0 762244 1359028 58 0 0 0 43 0 1 0 23 1404 1071 96 0 4 procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad6 ad8 in sy cs us sy id 7 2 0 762244 1356036 7 0 0 0 0 0 0 0 21 1236 959 99 0 1 ULE: procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad6 ad8 in sy cs us sy id 0 4 0 283788 1781208 2333 7 17 0 1633 0 0 0 211 4057 1702 1 1 99 6 2 0 631152 1606120 8180 5 23 0 30 0 65 0 157 915 371336 79 0 21 6 2 0 634228 1583908 906 0 0 0 3 0 5 0 32 566 940216 93 0 7 6 2 0 634228 1575052 227 0 0 0 0 0 1 0 96 915 694291 94 0 6 5 2 0 636276 1569768 54 0 0 0 0 0 1 0 79 722 984529 93 0 7 6 2 0 636276 1565184 3 0 0 0 0 0 0 0 56 749 615641 95 0 5 6 2 0 633024 1560904 182 0 0 0 224 0 15 0 64 892 554573 95 0 5 6 2 0 633024 1557648 1 0 0 0 0 0 0 0 21 1046 925070 94 0 6 8 1 0 631800 1553088 27 0 0 0 16 0 0 0 23 773 421820 96 0 3 7 1 0 631800 1548752 3 0 0 0 0 0 0 0 27 552 714116 96 0 4 7 1 0 631800 1543804 20 0 0 0 0 0 0 0 20 541 887702 94 0 6 6 1 0 632824 1537948 15 0 0 0 1 0 1 0 25 590 691248 95 0 5 7 1 0 632824 1533896 1 0 0 0 4 0 1 0 21 676 545389 95 0 5 7 1 0 632824 1528332 2 0 0 0 0 0 0 0 23 787 637327 93 0 7 5 1 0 632824 1525668 1 0 0 0 0 0 0 0 13 893 722130 90 0 10 3 1 0 632824 1520008 3 0 0 0 0 0 0 0 25 897 1216075 81 0 19 6 1 0 632824 1510980 25 0 0 0 0 0 0 0 33 932 1126821 90 0 10 7 1 0 632824 1503956 1 0 0 0 3 0 0 0 29 804 961332 93 0 7 procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad6 ad8 in sy cs us sy id 4 2 0 635076 1498816 59 0 0 0 43 0 0 0 24 1014 1188872 91 0 9 7 2 0 635076 1492764 7 0 0 0 0 0 1 0 28 1283 1085336 88 0 11 Thanks, Josh From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 22:11:42 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FF0616A420 for ; Tue, 16 Oct 2007 22:11:42 +0000 (UTC) (envelope-from miguel@anjos.strangled.net) Received: from mailrly06.isp.novis.pt (mailrly06.isp.novis.pt [195.23.133.216]) by mx1.freebsd.org (Postfix) with ESMTP id 6628613C447 for ; Tue, 16 Oct 2007 22:11:40 +0000 (UTC) (envelope-from miguel@anjos.strangled.net) Received: (qmail 13379 invoked from network); 16 Oct 2007 22:11:38 -0000 Received: from unknown (HELO mailfrt04.isp.novis.pt) ([195.23.133.196]) (envelope-sender ) by mailrly06.isp.novis.pt with compressed SMTP; 16 Oct 2007 22:11:38 -0000 Received: (qmail 22901 invoked from network); 16 Oct 2007 22:11:38 -0000 Received: from unknown (HELO satan.anjos.strangled.net) ([89.180.78.253]) (envelope-sender ) by mailfrt04.isp.novis.pt with SMTP; 16 Oct 2007 22:11:38 -0000 Received: from satan.anjos.strangled.net (localhost [127.0.0.1]) by satan.anjos.strangled.net (8.14.1/8.14.1) with ESMTP id l9GMBRK1014776; Tue, 16 Oct 2007 23:11:27 +0100 (WEST) (envelope-from miguel@satan.anjos.strangled.net) Received: (from miguel@localhost) by satan.anjos.strangled.net (8.14.1/8.14.1/Submit) id l9GMBQEK014775; Tue, 16 Oct 2007 23:11:26 +0100 (WEST) (envelope-from miguel) Date: Tue, 16 Oct 2007 23:11:26 +0100 (WEST) From: Miguel Lopes Santos Ramos Message-Id: <200710162211.l9GMBQEK014775@satan.anjos.strangled.net> To: freebsd-stable@freebsd.org, indrajith@adm.sltidc.lk In-Reply-To: Cc: Subject: Re: Disk Quota Support for FreeBSD Kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 22:11:42 -0000 > From: "Chaminda Indrajith" > > Warning: Can't find the `6.2-RELEASE-p4' distribution on this FTP > server. You may need to visit a different server for the release you > are trying to fetch or go to the Options menu and to set the release > name to explicitly match what's available on ftp.freebsd.org (or set > to "any"). > > Please help me to install kernel source and rebuild kernel. I think this would work, edit /usr/share/examples/cvsup/stable-supfile, or perhaps edit a copy of it in some directory of your own. Make sure you have edit these lines: *default host=CHANGE_THIS.FreeBSD.org *default release=cvs tag=RELENG_6 changing CHANGE_THIS to cvsup or cvsup4 or something near you, and tag=RELENG_6 to tag=RELENG_6_2. Check if you have the command csup installed, if you do, then do: # csup -L 2 stable-supfile If you don't, install the port cvsup and do: # cvsup -g -L 2 stable-supfile I think this will work. The directory /usr/src must already be created. This is for installing the sources for the full system... If you want only the kernel sources manually fetch using FTP the ssys.* files from the src directory of 6.2-RELEASE. Also fetch the install script, install.sh, on the same directory. Then run it :-) Oh... about building... see the handbook, I'm sure to forget some step. Miguel Ramos From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 22:22:22 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60BB116A41A for ; Tue, 16 Oct 2007 22:22:22 +0000 (UTC) (envelope-from jacardenasm@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id 3C2F613C45B for ; Tue, 16 Oct 2007 22:22:22 +0000 (UTC) (envelope-from jacardenasm@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2589147waf for ; Tue, 16 Oct 2007 15:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=ej9AporA+Hc8mtrB8NDjrwLSTjkod49mAdT0cmWa5j0=; b=QbdMO1XHrAFYducAJv8xaKlci0QIecfkT3ev+CZC/BG/ulaTT5Bg3541xJTZawt7U9p2VCevEhDI92XPPpMjMvqZHG6lNmn4NfzcUumd5sxmL+r68oiTyhUqw9CzrNh+yaS/RSHgKYTXnUEWD85H+KvRdJKFju1RSI1YX6d2jK4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=jSCeqVe25wcITbvGPT356JFtAv07WQgb25K93Bhr7TOOiaxGyi51IRCEInb+AYCTKbxnxQCajq68bPRctOLfj0Oz2X6mmINPjuZooYf5Yxr76LWb8D0jPDKwHgmgTan5h0Isi9Xp7FTg5c8El1xUhz0TTquzqhBk+fnVIiOstHc= Received: by 10.114.61.1 with SMTP id j1mr8983641waa.1192571703576; Tue, 16 Oct 2007 14:55:03 -0700 (PDT) Received: by 10.115.16.3 with HTTP; Tue, 16 Oct 2007 14:55:03 -0700 (PDT) Message-ID: <7c58fcfc0710161455t20792d7dqa349ff157674048d@mail.gmail.com> Date: Tue, 16 Oct 2007 16:55:03 -0500 From: "Jose Alonso Cardenas Marquez" Sender: jacardenasm@gmail.com To: stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: b6ae64562902792e Cc: jkh@FreeBSD.org, ache@freebsd.org Subject: Call for Testers: dialog 1.1-20070930 update X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 22:22:22 -0000 Hi everyone :) Currently, we have an older version of libdialog/dialog (0.4) into freebsd base system. I made a patch that update libdialog/dialog to 1.1-20070930 (nowadays maintained by Thomas E. Dickey) You can see lot of changes on current version of libdialog/dialog at: http://invisible-island.net/dialog/CHANGES You can download patch files at: http://people.freebsd.org/~acm/src/dialog/ The current version of dialog (20070930) works fine with ports options, but it has a lot of problem with sysinstall (i think that we must to do a lot of changes on sysinstall source code). I'll try to work on sysinstall problems, but all help always is welcome :) I tested those patch files on my current 6.x box without problems, i expect that it will be to help for everybody. Greetings ACM From owner-freebsd-stable@FreeBSD.ORG Tue Oct 16 22:23:59 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 223FD16A4C1 for ; Tue, 16 Oct 2007 22:23:59 +0000 (UTC) (envelope-from miguel@anjos.strangled.net) Received: from mailrly04.isp.novis.pt (mailrly04.isp.novis.pt [195.23.133.224]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0BB13C504 for ; Tue, 16 Oct 2007 22:23:53 +0000 (UTC) (envelope-from miguel@anjos.strangled.net) Received: (qmail 28806 invoked from network); 16 Oct 2007 21:57:11 -0000 Received: from unknown (HELO mailfrt04.isp.novis.pt) ([195.23.133.196]) (envelope-sender ) by mailrly04.isp.novis.pt with compressed SMTP; 16 Oct 2007 21:57:11 -0000 Received: (qmail 10858 invoked from network); 16 Oct 2007 21:57:11 -0000 Received: from unknown (HELO satan.anjos.strangled.net) ([89.180.78.253]) (envelope-sender ) by mailfrt04.isp.novis.pt with SMTP; 16 Oct 2007 21:57:11 -0000 Received: from satan.anjos.strangled.net (localhost [127.0.0.1]) by satan.anjos.strangled.net (8.14.1/8.14.1) with ESMTP id l9GLuq5D014355; Tue, 16 Oct 2007 22:56:53 +0100 (WEST) (envelope-from miguel@satan.anjos.strangled.net) Received: (from miguel@localhost) by satan.anjos.strangled.net (8.14.1/8.14.1/Submit) id l9GLupgn014354; Tue, 16 Oct 2007 22:56:51 +0100 (WEST) (envelope-from miguel) Date: Tue, 16 Oct 2007 22:56:51 +0100 (WEST) From: Miguel Lopes Santos Ramos Message-Id: <200710162156.l9GLupgn014354@satan.anjos.strangled.net> To: freebsd-stable@freebsd.org, robert.a.chalmers@gmail.com In-Reply-To: Cc: Subject: Re: can I do 6.1-RELEASE to 6.2 via cvsup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 22:23:59 -0000 > From owner-freebsd-stable@freebsd.org Tue Oct 16 22:01:02 2007 > > I should just be able to change the TAG in standard-supfile from 6_1 to 6_2, > do a cvsup, and the builds etc to end up with 6.2-RELEASE right? > yes? no? Right. And back, you can change the tag back to 6_1... Or just RELENG_6 for 6-STABLE. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 01:51:55 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13AA316A421 for ; Wed, 17 Oct 2007 01:51:55 +0000 (UTC) (envelope-from ulrich@pukruppa.net) Received: from pukruppa.net (pukruppa.net [213.146.114.24]) by mx1.freebsd.org (Postfix) with ESMTP id 2DADF13C448 for ; Wed, 17 Oct 2007 01:51:53 +0000 (UTC) (envelope-from ulrich@pukruppa.net) Received: from pukruppa.net (localhost [127.0.0.1]) by pukruppa.net (8.14.1/8.14.1) with ESMTP id l9H1GnD5080948; Wed, 17 Oct 2007 03:16:50 +0200 (CEST) (envelope-from ulrich@pukruppa.net) Received: from localhost (ulrich@localhost) by pukruppa.net (8.14.1/8.14.1/Submit) with ESMTP id l9H1Gn5s080945; Wed, 17 Oct 2007 03:16:49 +0200 (CEST) (envelope-from ulrich@pukruppa.net) Date: Wed, 17 Oct 2007 03:16:49 +0200 (CEST) From: "P.U.Kruppa" X-X-Sender: ulrich@small To: Kris Kennaway In-Reply-To: <47150F82.9060805@FreeBSD.org> Message-ID: <20071017030940.R1559@small> References: <47150D87.3070804@gmx.de> <47150F82.9060805@FreeBSD.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="207141057-945791779-1192583809=:1559" Cc: "\[LoN\]Kamikaze" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCHED_4BSD in RELENG_7 disturbs workflow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 01:51:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --207141057-945791779-1192583809=:1559 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 16 Oct 2007, Kris Kennaway wrote: > [LoN]Kamikaze wrote: >> I know that RELENG_7 is not considered very near-release, but I thought = I'd >> give my 2=A2 in the hope that I might have a little influence on the=20 >> scheduler >> development to my benefit. >>=20 >> The switch from RELENG_6 to RELENG_7 went relatively smooth and apart fr= om=20 >> ipw >> causing panics. However there is one thing that's disturbing and this is= =20 >> the >> scheduler. I only have single core machines, so whatever I say only appl= ies=20 >> to >> those. If you think single-core machines are no longer important, feel f= ree=20 >> to >> ignore this. In deed, just ignore me however much you like. >>=20 >>> From my perspective scheduling on RELENG_6 was way better. Even on a fu= ll >> workload like a portupgrade the focused application (both in X and on th= e >> console) always received enough cycles to run smoothly and applications= =20 >> that >> ran in background like audio players also kept on running fine. >>=20 >> Quite the contrary on RELENG_7. During a portupgrade or even worse 'pkgd= b=20 >> -L' >> (recovering lost dependencies) audio players (both graphical and mplayer= ) >> scatter, either because they don't get the hard-disk or CPU-cycles (whic= h=20 >> one, >> I don't know) and the focused application also often hangs. It just look= s=20 >> like >> occasionally (under load) everything freezes for a second and then goes = on >> relatively normal. >>=20 >> I've got the impression that things compile a little faster (that might = be=20 >> my >> imagination, though), but I'd rather have a smooth working experience. >>=20 >> This is just my view of the situation and I suppose it is only one of ma= ny.=20 >> I >> bid you be merciful with us single-core people, who cannot afford a slic= k >> multi-core machine, because we worry how to pay for our food at the end = of=20 >> the >> month. > > Not to say that any problems that might have developed with SCHED_4BSD sh= ould=20 > not be fixed, but you should give SCHED_ULE a try since it brings benefit= s=20 > even for single CPU systems (e.g. better interactive response). I would like to second that. I have seen the same problems on my=20 single processor system and using SCHED_ULE instead of SCHED_4BSD=20 seems to improve the situation a lot. Uli. > > Kris > _______________________________________________ > 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= " > Peter Ulrich Kruppa Wuppertal Germany --207141057-945791779-1192583809=:1559-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 02:24:32 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F82916A421 for ; Wed, 17 Oct 2007 02:24:32 +0000 (UTC) (envelope-from freebsd@mail.gbch.net) Received: from gw.gbch.net (gw.gbch.net [203.143.238.93]) by mx1.freebsd.org (Postfix) with SMTP id ADFBF13C465 for ; Wed, 17 Oct 2007 02:24:31 +0000 (UTC) (envelope-from freebsd@mail.gbch.net) Received: (qmail 24166 invoked from network); 17 Oct 2007 12:24:29 +1000 Received: from joker.gbch.net (172.16.1.10) by gw.gbch.net with SMTP; 17 Oct 2007 12:24:29 +1000 Received: (qmail 96650 invoked by uid 1001); 17 Oct 2007 12:24:29 +1000 Message-ID: Date: Wed, 17 Oct 2007 12:24:29 +1000 From: Greg Black To: freebsd-stable@freebsd.org References: <20071004165755.GA1049@pp.htv.fi> <47120D83.1010703@FreeBSD.org> <20071015203202.GA17964@pp.htv.fi> <20071016004637.GA79351@cdnetworks.co.kr> <20071016185714.GB2186@pp.htv.fi> <20071016130146.pfyan4vs5cwgsoc0@webmail.1command.com> <20071016202251.GC4047@lava.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071016202251.GC4047@lava.net> User-Agent: Mutt/1.4.2.2i; gjb-muttsend.sh 1.7 2004-10-05 X-Uptime: 64 days X-Operating-System: FreeBSD 6.2-RELEASE-p5 i386 X-Location: Brisbane, Australia; 27.49841S 152.98439E X-URL: http://www.gbch.net/gjb.html X-Blog: http://www.gbch.net/gjb/blog/ X-Image-URL: http://www.gbch.net/gjb/gjb-auug048.gif X-PGP-Key-Fingerprint: EBB2 2A92 A79D 1533 AC00 3C46 5D83 B6FB 4B04 B7D6 X-Request-PGP: http://www.gbch.net/keys/4B04B7D6.asc Subject: Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 02:24:32 -0000 On 2007-10-16, Clifton Royston wrote: > Thanks for this very timely mention! The cluster of servers I am > about to upgrade from 4.8 to 6.2 relies heavily on > NFS to an old Netapp. If I have got to disable rpc_lockd and > rpc_statd, it's good to know that now! > > Can I ask, can anybody confirm that they're running 6.2 on NFS > successfully *with* lockd and statd? I have this combination running without any drama on a couple of networks, so I doubt veery much if that is the fatal combination. Greg From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 04:57:51 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3978116A417 for ; Wed, 17 Oct 2007 04:57:51 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: from malasada.lava.net (malasada.lava.net [64.65.64.17]) by mx1.freebsd.org (Postfix) with ESMTP id 111AA13C474 for ; Wed, 17 Oct 2007 04:57:50 +0000 (UTC) (envelope-from cliftonr@lava.net) Received: by malasada.lava.net (Postfix, from userid 102) id 5F6EF153882; Tue, 16 Oct 2007 18:57:50 -1000 (HST) Date: Tue, 16 Oct 2007 18:57:50 -1000 From: Clifton Royston To: Greg Black Message-ID: <20071017045750.GC2455@lava.net> Mail-Followup-To: Greg Black , freebsd-stable@freebsd.org References: <20071004165755.GA1049@pp.htv.fi> <47120D83.1010703@FreeBSD.org> <20071015203202.GA17964@pp.htv.fi> <20071016004637.GA79351@cdnetworks.co.kr> <20071016185714.GB2186@pp.htv.fi> <20071016130146.pfyan4vs5cwgsoc0@webmail.1command.com> <20071016202251.GC4047@lava.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: freebsd-stable@freebsd.org Subject: Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 04:57:51 -0000 On Wed, Oct 17, 2007 at 12:24:29PM +1000, Greg Black wrote: > On 2007-10-16, Clifton Royston wrote: > > > Thanks for this very timely mention! The cluster of servers I am > > about to upgrade from 4.8 to 6.2 relies heavily on > > NFS to an old Netapp. If I have got to disable rpc_lockd and > > rpc_statd, it's good to know that now! > > > > Can I ask, can anybody confirm that they're running 6.2 on NFS > > successfully *with* lockd and statd? > > I have this combination running without any drama on a couple of > networks, so I doubt veery much if that is the fatal combination. Thanks for the rapid feedback. Glad to hear it was mistaken alarmism. I shall return to my usual state of apathy. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 08:07:46 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A480516A419; Wed, 17 Oct 2007 08:07:46 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from hermes.hw.ru (hermes.hw.ru [80.68.240.91]) by mx1.freebsd.org (Postfix) with ESMTP id 790C513C447; Wed, 17 Oct 2007 08:07:44 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from [80.68.244.40] (account a_popov@rbc.ru [80.68.244.40] verified) by hermes.hw.ru (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 194588927; Wed, 17 Oct 2007 12:07:50 +0400 Message-ID: <4715C297.1020905@chistydom.ru> Date: Wed, 17 Oct 2007 12:06:47 +0400 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Kris Kennaway References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> <47147E49.9020301@FreeBSD.org> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> In-Reply-To: <4715035D.2090802@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 08:07:46 -0000 Hi. Kris Kennaway wrote: >>>>>> After some time of running under high load disk performance become >>>>>> expremely poor. At that periods 'systat -vm 1' shows something like >>>>>> this: >>>> This web service is similiar to YouTube. This server is video store. I >>>> have around 200G of *.flv (flash video) files on the server >>>> I run lighttpd as a web server. Disk load is usually around 50%, >>>> network >>>> output 100Mbit/s, 100 simultaneous connections. CPU is mostly idle. >> This is very unlikely, because I have 5 another video storage servers >> of the same hardware and software configurations and they feel good. > Clearly something is different about them, though. If you can > characterize exactly what that is then it will help. I can't see any difference but a date of installation. Really I compared all parameters and got nothing interesting. >> At first glance one can say that problem is in Dell's x850 series or >> amr(4), but we run this hardware on many other projects and they work >> well. Also Linux on them works. > > OK but there is no evidence in what you posted so far that amr is > involved in any way. There is convincing evidence that it is the mbuf > issue. Why are you sure this is the mbuf issue? For example, if there is a real problem with amr or VM causing disk slowdown, then when it occurs the network subsystem will have another load pattern. Instead of just quick sending large amounts of data, the system will have to accept large amount of sumultaneous connections waiting for data. Can this cause high mbuf contention? > >> And few hours ago I received feed back from Andrzej Tobola, he has the >> same problem on FreeBSD 7 with Promise ATA software mirror: > Well, he didnt provide any evidence yet that it is the same problem, so > let's not become confused by feelings :) I think he is telling about 100% disk busy while processing ~5 transfers/sec. >> So I can conclude that FreeBSD has a long standing bug in VM that >> could be triggered when serving large amount of static data (much >> bigger than memory size) on high rates. Possibly this only applies to >> large files like mp3 or video. > It is possible, we have further work to do to conclude this though. I forgot to mention I have pmc and kgmon profiling for good and bad times. But I have not enough knowledge to interpret it right and not sure if it can help. Also now I run nginx instead of lighttpd on one of the problematic servers. It seems to work much better - sometimes there is a peaks in disk load, but disk does not become very slow and network output does not change. The difference of nginx is that it runs in multiple processes, while lighttpd by default has only one process. Now I configured lighttpd on other server to run in multiple workers. I'll see if it helps. What else can i try? With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 08:20:42 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AEEA16A41B; Wed, 17 Oct 2007 08:20:41 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 6129913C457; Wed, 17 Oct 2007 08:20:39 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4715C5D7.7060806@FreeBSD.org> Date: Wed, 17 Oct 2007 10:20:39 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Alexey Popov References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> <47147E49.9020301@FreeBSD.org> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> In-Reply-To: <4715C297.1020905@chistydom.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 08:20:42 -0000 Alexey Popov wrote: >>> This is very unlikely, because I have 5 another video storage servers >>> of the same hardware and software configurations and they feel good. >> Clearly something is different about them, though. If you can >> characterize exactly what that is then it will help. > I can't see any difference but a date of installation. Really I compared > all parameters and got nothing interesting. > >>> At first glance one can say that problem is in Dell's x850 series or >>> amr(4), but we run this hardware on many other projects and they work >>> well. Also Linux on them works. >> >> OK but there is no evidence in what you posted so far that amr is >> involved in any way. There is convincing evidence that it is the mbuf >> issue. > Why are you sure this is the mbuf issue? Because that is the only problem shown in the data you posted. > For example, if there is a real > problem with amr or VM causing disk slowdown, then when it occurs the > network subsystem will have another load pattern. Instead of just quick > sending large amounts of data, the system will have to accept large > amount of sumultaneous connections waiting for data. Can this cause high > mbuf contention? I'd expect to see evidence of the main problem. >>> And few hours ago I received feed back from Andrzej Tobola, he has >>> the same problem on FreeBSD 7 with Promise ATA software mirror: >> Well, he didnt provide any evidence yet that it is the same problem, >> so let's not become confused by feelings :) > I think he is telling about 100% disk busy while processing ~5 > transfers/sec. "% busy" as reported by gstat doesn't mean what you think it does. What is the I/O response time? That's the meaningful statistic for evaluating I/O load. Also you didnt post about this. >>> So I can conclude that FreeBSD has a long standing bug in VM that >>> could be triggered when serving large amount of static data (much >>> bigger than memory size) on high rates. Possibly this only applies to >>> large files like mp3 or video. >> It is possible, we have further work to do to conclude this though. > I forgot to mention I have pmc and kgmon profiling for good and bad > times. But I have not enough knowledge to interpret it right and not > sure if it can help. pmc would be useful. > Also now I run nginx instead of lighttpd on one of the problematic > servers. It seems to work much better - sometimes there is a peaks in > disk load, but disk does not become very slow and network output does > not change. The difference of nginx is that it runs in multiple > processes, while lighttpd by default has only one process. Now I > configured lighttpd on other server to run in multiple workers. I'll see > if it helps. > > What else can i try? Still waiting on the vmstat -z output. Kris From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 08:46:33 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FB5B16A418; Wed, 17 Oct 2007 08:46:33 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 4D5B513C461; Wed, 17 Oct 2007 08:46:31 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4715CBE6.4020604@FreeBSD.org> Date: Wed, 17 Oct 2007 10:46:30 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Kris Kennaway References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> <47147E49.9020301@FreeBSD.org> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> In-Reply-To: <4715C5D7.7060806@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, Alexey Popov Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 08:46:33 -0000 Kris Kennaway wrote: >> What else can i try? > > Still waiting on the vmstat -z output. Also can you please obtain vmstat -i, netstat -m and 10 seconds of representative vmstat -w output when the problem is and is not occurring? Kris From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 08:57:51 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61B0616A421 for ; Wed, 17 Oct 2007 08:57:51 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from brev.sics.se (brev.sics.se [193.10.64.200]) by mx1.freebsd.org (Postfix) with ESMTP id C5D1B13C459 for ; Wed, 17 Oct 2007 08:57:50 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (ip68.infrahip.net [193.167.187.68]) by brev.sics.se (8.12.8/8.12.8) with ESMTP id l9H8N0VF031173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 17 Oct 2007 10:23:01 +0200 Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.13.8/8.13.8) with ESMTP id l9H8QC9K001379 for ; Wed, 17 Oct 2007 10:26:12 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.13.8/8.13.8/Submit) id l9H8QCVQ001378; Wed, 17 Oct 2007 10:26:12 +0200 (CEST) (envelope-from bengta@P142.sics.se) To: stable@freebsd.org From: Bengt Ahlgren In-Reply-To: <20071015203202.GA17964@pp.htv.fi> (Esa Karkkainen's message of "Mon, 15 Oct 2007 23:32:02 +0300") References: <20071004165755.GA1049@pp.htv.fi> <47120D83.1010703@FreeBSD.org> <20071015203202.GA17964@pp.htv.fi> Date: Wed, 17 Oct 2007 10:26:12 +0200 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Cc: Subject: Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 08:57:51 -0000 Esa Karkkainen writes: > On Sun, Oct 14, 2007 at 02:37:23PM +0200, Kris Kennaway wrote: >> Esa Karkkainen wrote: >> > I get "Fatal double fault" error when writing to a filesystem >> >mounted from NFS server. > > I got an offlist reply in which he suggested that the problem might be > in nve driver. That was me. I indeed got the same fault when running NFS over nve. Switching to nfe solved the problem for me. The on-screen backtrace reveals the true location of the problem. See: http://www.sics.se/~bengta/FBSD/DSC00585.JPG I do have a dump, but for some reason kgdb is not able to show the same information. Regards, Bengt From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 09:01:12 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BBAB16A421 for ; Wed, 17 Oct 2007 09:01:12 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 95FDF13C4A8 for ; Wed, 17 Oct 2007 09:01:11 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 17 Oct 2007 09:01:10 -0000 Received: from vpn-cl-166-173.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [141.3.166.173] by mail.gmx.net (mp053) with SMTP; 17 Oct 2007 11:01:10 +0200 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX1+wzps/reewKox5AkczMydy+f+cuRSQwMbOhTWPWV Gfp7oq8bsHbUvP Message-ID: <4715CF4E.6010203@gmx.de> Date: Wed, 17 Oct 2007 11:01:02 +0200 From: "[LoN]Kamikaze" User-Agent: Thunderbird 2.0.0.6 (X11/20071015) MIME-Version: 1.0 To: Bengt Ahlgren References: <47150D87.3070804@gmx.de> In-Reply-To: X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCHED_4BSD in RELENG_7 disturbs workflow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 09:01:12 -0000 Bengt Ahlgren wrote: > "[LoN]Kamikaze" writes: > >> From my perspective scheduling on RELENG_6 was way better. Even on a full >> workload like a portupgrade the focused application (both in X and on the >> console) always received enough cycles to run smoothly and applications that >> ran in background like audio players also kept on running fine. >> >> Quite the contrary on RELENG_7. During a portupgrade or even worse 'pkgdb -L' >> (recovering lost dependencies) audio players (both graphical and mplayer) >> scatter, either because they don't get the hard-disk or CPU-cycles (which one, >> I don't know) and the focused application also often hangs. It just looks like >> occasionally (under load) everything freezes for a second and then goes on >> relatively normal. > > Do you have ATA write-caching on or off? My experience is that if you > turn caching off (on RELENG_6_x at least, have not tried 7) the > machine often freezes for seconds when you are writing a lot to the > disk. > > Bengt > Write-caching is on on my machines. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 09:58:06 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F7FE16A41A; Wed, 17 Oct 2007 09:58:06 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from brev.sics.se (brev.sics.se [193.10.64.200]) by mx1.freebsd.org (Postfix) with ESMTP id 0EED213C447; Wed, 17 Oct 2007 09:58:05 +0000 (UTC) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (ip68.infrahip.net [193.167.187.68]) by brev.sics.se (8.12.8/8.12.8) with ESMTP id l9H8vqVF032548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Oct 2007 10:57:52 +0200 Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.13.8/8.13.8) with ESMTP id l9H9145g001573; Wed, 17 Oct 2007 11:01:04 +0200 (CEST) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.13.8/8.13.8/Submit) id l9H913vv001572; Wed, 17 Oct 2007 11:01:03 +0200 (CEST) (envelope-from bengta@P142.sics.se) To: "[LoN]Kamikaze" From: Bengt Ahlgren In-Reply-To: <47150D87.3070804@gmx.de> (LoN_Kamikaze@gmx.de's message of "Tue, 16 Oct 2007 21:14:15 +0200") References: <47150D87.3070804@gmx.de> Date: Wed, 17 Oct 2007 11:01:03 +0200 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCHED_4BSD in RELENG_7 disturbs workflow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 09:58:06 -0000 "[LoN]Kamikaze" writes: >>>From my perspective scheduling on RELENG_6 was way better. Even on a full > workload like a portupgrade the focused application (both in X and on the > console) always received enough cycles to run smoothly and applications that > ran in background like audio players also kept on running fine. > > Quite the contrary on RELENG_7. During a portupgrade or even worse 'pkgdb -L' > (recovering lost dependencies) audio players (both graphical and mplayer) > scatter, either because they don't get the hard-disk or CPU-cycles (which one, > I don't know) and the focused application also often hangs. It just looks like > occasionally (under load) everything freezes for a second and then goes on > relatively normal. Do you have ATA write-caching on or off? My experience is that if you turn caching off (on RELENG_6_x at least, have not tried 7) the machine often freezes for seconds when you are writing a lot to the disk. Bengt From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 10:39:21 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4808D16A418; Wed, 17 Oct 2007 10:39:21 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mx1.freebsd.org (Postfix) with ESMTP id C600413C465; Wed, 17 Oct 2007 10:39:20 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l9HAdJSL036303; Wed, 17 Oct 2007 20:39:19 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l9HAdIg7036302; Wed, 17 Oct 2007 20:39:18 +1000 (EST) (envelope-from peter) Date: Wed, 17 Oct 2007 20:39:18 +1000 From: Peter Jeremy To: Igor Sysoev Message-ID: <20071017103918.GL1191@turion.vk2pj.dyndns.org> References: <20071015141714.GL24828@rambler-co.ru> <20071016193843.GD1184@turion.vk2pj.dyndns.org> <20071016195343.GK57989@rambler-co.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8P1HSweYDcXXzwPJ" Content-Disposition: inline In-Reply-To: <20071016195343.GK57989@rambler-co.ru> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 2G+ sysv shm segments X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 10:39:21 -0000 --8P1HSweYDcXXzwPJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Oct-16 23:53:43 +0400, Igor Sysoev wrote: >> printf(" %12lu", (unsigned long)kshmptr->u.shm_segsz); or similar. > >Here should be %zu. You're correct. I wasn't aware of 'z' :-( >However, this patch can not be commited even to 7/8, because it does not >preserve binary compatibility for shmctl(IPC_STAT). > >It seems that should be new shmctl syscall. I don't believe there is a requirement that IPC_STAT be 2 so an alternative approach would be to change the value of IPC_STAT to support the changed shmid_ds size (though this would also affect semctl() and msgctl(). --=20 Peter Jeremy --8P1HSweYDcXXzwPJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHFeZW/opHv/APuIcRAhHCAJ4vJqrDYTci2LCscBjOd/IlOGaVLwCfawHH GoGATHrPINrWuxDizB68/Os= =YzjB -----END PGP SIGNATURE----- --8P1HSweYDcXXzwPJ-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 14:35:50 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C095916A41B for ; Wed, 17 Oct 2007 14:35:50 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 70D2413C48D for ; Wed, 17 Oct 2007 14:35:47 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id C4EC943F7C7; Wed, 17 Oct 2007 17:35:45 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qwJjmeI3z3m; Wed, 17 Oct 2007 17:35:45 +0300 (EEST) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 646F743E9D8; Wed, 17 Oct 2007 17:35:45 +0300 (EEST) Message-ID: <47161DC0.8040807@icyb.net.ua> Date: Wed, 17 Oct 2007 17:35:44 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-doc@freebsd.org Subject: WITHOUT_LIB32 in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 14:35:50 -0000 It seems that WITHOUT_LIB32 is not documented neither in make.conf(5) nor in make.conf under examples in 6.X releases and RELENG_6. It is documented in src.conf(5) of RELENG_7. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 15:10:14 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B56B916A419 for ; Wed, 17 Oct 2007 15:10:14 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 6DD3E13C48E for ; Wed, 17 Oct 2007 15:10:14 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id C467C41C541; Wed, 17 Oct 2007 17:10:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id fB3ER1JaERNF; Wed, 17 Oct 2007 17:10:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 6E9E141C75C; Wed, 17 Oct 2007 17:10: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 992A9444885; Wed, 17 Oct 2007 15:05:39 +0000 (UTC) Date: Wed, 17 Oct 2007 15:05:39 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Andriy Gapon In-Reply-To: <47161DC0.8040807@icyb.net.ua> Message-ID: <20071017150506.J6043@maildrop.int.zabbadoz.net> References: <47161DC0.8040807@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-doc@freebsd.org, freebsd-stable@freebsd.org Subject: Re: WITHOUT_LIB32 in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 15:10:14 -0000 On Wed, 17 Oct 2007, Andriy Gapon wrote: > > It seems that WITHOUT_LIB32 is not documented neither in make.conf(5) > nor in make.conf under examples in 6.X releases and RELENG_6. > It is documented in src.conf(5) of RELENG_7. It is NO_LIB32 in RELENG_6. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 15:12:15 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9049B16A473; Wed, 17 Oct 2007 15:12:15 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 3E6CE13C4BF; Wed, 17 Oct 2007 15:12:15 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id B4B4643FA38; Wed, 17 Oct 2007 18:12:13 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idrFm2qW68-O; Wed, 17 Oct 2007 18:12:13 +0300 (EEST) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 42F2D43F700; Wed, 17 Oct 2007 18:12:13 +0300 (EEST) Message-ID: <4716264C.4050200@icyb.net.ua> Date: Wed, 17 Oct 2007 18:12:12 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <47161DC0.8040807@icyb.net.ua> <20071017150506.J6043@maildrop.int.zabbadoz.net> In-Reply-To: <20071017150506.J6043@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-doc@freebsd.org, freebsd-stable@freebsd.org Subject: Re: WITHOUT_LIB32 in RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 15:12:15 -0000 on 17/10/2007 18:05 Bjoern A. Zeeb said the following: > On Wed, 17 Oct 2007, Andriy Gapon wrote: > >> It seems that WITHOUT_LIB32 is not documented neither in make.conf(5) >> nor in make.conf under examples in 6.X releases and RELENG_6. >> It is documented in src.conf(5) of RELENG_7. > > It is NO_LIB32 in RELENG_6. > Still not documented as I searched for "32" in both cases :-) But thank you for preventing possible confusion! -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 15:45:49 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1773216A420; Wed, 17 Oct 2007 15:45:49 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [63.240.77.82]) by mx1.freebsd.org (Postfix) with ESMTP id B77D513C461; Wed, 17 Oct 2007 15:45:48 +0000 (UTC) (envelope-from nslay@comcast.net) Received: from lightbulb.local (c-68-35-224-189.hsd1.fl.comcast.net[68.35.224.189]) by comcast.net (sccrmhc12) with ESMTP id <20071017153543012009oppke>; Wed, 17 Oct 2007 15:35:44 +0000 Message-ID: <47162BAD.50604@comcast.net> Date: Wed, 17 Oct 2007 11:35:09 -0400 From: Nathan Lay User-Agent: Thunderbird 2.0.0.6 (X11/20070805) MIME-Version: 1.0 To: "P.U.Kruppa" References: <47150D87.3070804@gmx.de> <47150F82.9060805@FreeBSD.org> <20071017030940.R1559@small> In-Reply-To: <20071017030940.R1559@small> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "\[LoN\]Kamikaze" , Kris Kennaway , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCHED_4BSD in RELENG_7 disturbs workflow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 15:45:49 -0000 P.U.Kruppa wrote: > On Tue, 16 Oct 2007, Kris Kennaway wrote: > >> [LoN]Kamikaze wrote: >>> I know that RELENG_7 is not considered very near-release, but I >>> thought I'd >>> give my 2¢ in the hope that I might have a little influence on the >>> scheduler >>> development to my benefit. >>> >>> The switch from RELENG_6 to RELENG_7 went relatively smooth and >>> apart from ipw >>> causing panics. However there is one thing that's disturbing and >>> this is the >>> scheduler. I only have single core machines, so whatever I say only >>> applies to >>> those. If you think single-core machines are no longer important, >>> feel free to >>> ignore this. In deed, just ignore me however much you like. >>> >>>> From my perspective scheduling on RELENG_6 was way better. Even on >>>> a full >>> workload like a portupgrade the focused application (both in X and >>> on the >>> console) always received enough cycles to run smoothly and >>> applications that >>> ran in background like audio players also kept on running fine. >>> >>> Quite the contrary on RELENG_7. During a portupgrade or even worse >>> 'pkgdb -L' >>> (recovering lost dependencies) audio players (both graphical and >>> mplayer) >>> scatter, either because they don't get the hard-disk or CPU-cycles >>> (which one, >>> I don't know) and the focused application also often hangs. It just >>> looks like >>> occasionally (under load) everything freezes for a second and then >>> goes on >>> relatively normal. >>> >>> I've got the impression that things compile a little faster (that >>> might be my >>> imagination, though), but I'd rather have a smooth working experience. >>> >>> This is just my view of the situation and I suppose it is only one >>> of many. I >>> bid you be merciful with us single-core people, who cannot afford a >>> slick >>> multi-core machine, because we worry how to pay for our food at the >>> end of the >>> month. >> >> Not to say that any problems that might have developed with >> SCHED_4BSD should not be fixed, but you should give SCHED_ULE a try >> since it brings benefits even for single CPU systems (e.g. better >> interactive response). > I would like to second that. I have seen the same problems on my > single processor system and using SCHED_ULE instead of SCHED_4BSD > seems to improve the situation a lot. > > Uli. >> >> Kris >> _______________________________________________ >> 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" >> > > > > Peter Ulrich Kruppa > Wuppertal > Germany > ------------------------------------------------------------------------ > > _______________________________________________ > 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" I have this problem too...although I always imagined the cause was WITNESS and various other debug options. Best Regards, Nathan Lay From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 16:11:06 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B9DE16A474 for ; Wed, 17 Oct 2007 16:11:06 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by mx1.freebsd.org (Postfix) with ESMTP id 7443313C4C1 for ; Wed, 17 Oct 2007 16:11:04 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so280209wra for ; Wed, 17 Oct 2007 09:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=dIXm/keScD6cKC2/LDWHnjpxrtvO+yHY4cE6Jej+svg=; b=TQ8MVg9nAPppbIyg23OhMDiLbsExecMhJYcaXuaH1sHtc2e26ouiuAjzpaHKPBqikSCY9CAEXeTE/mqURgc0NQmGjYMg8DFv224pxv42MMmM0suk7UEpDoLG1z29Vq9w+n9T+Vi2gNINowZOmq/NZE1AWXtEJY7q3L/jijV/QRQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=VMtjeZQb0vHTOKBW3th03YXmuT82MZJMzFm7f5SMYzYymb8cMNmDGYIVvmU8R3bklGnKB+H/D1rvPE3hNsE1/RRdkLlgEOejPRkU67DpnypNfGN2Qi7e9FSR13uXWY1qa4swRK8IJbMeXGHLgKEExAKom6+9oBDAoBB5M6cniXw= Received: by 10.90.90.16 with SMTP id n16mr12920506agb.1192637463825; Wed, 17 Oct 2007 09:11:03 -0700 (PDT) Received: by 10.90.29.9 with HTTP; Wed, 17 Oct 2007 09:11:03 -0700 (PDT) Message-ID: <8cb6106e0710170911x77e72e95qb322f51d84a31813@mail.gmail.com> Date: Wed, 17 Oct 2007 12:11:03 -0400 From: "Josh Carroll" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ULE vs. 4BSD in RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 16:11:06 -0000 All, I mentioned this on another thread, but I think it deserves a separate thread. Not only so it will get its own attention, but also so I don't hijack the other thread. I have noticed some performance discrepancies with ULE and 4BSD in RELENG_7, specifically with ffmpeg. I have all the kernel debugging options disabled, and as I understand it, the userland debugging is all off by default in RELENG_7. That said, I'm seeing 5% better performance from the 4BSD scheduler for ffmpeg -threads 8 on a quad-core Intel desktop setup (Q6600 cpu). I am also comparing as a baseline to RELENG_6_2 (I only have 4BSD scheduler numbers for that, though). Here are the run times for the selected benchmark: RELENG_6_2 (4BSD): 1:32.39 RELENG_7 (4BSD): 1:32.44 RELENG_7 (ULE): 1:37.15 Difference (4BSD vs. ULE on 7): 5.095 % Please see below for "backup data" on this (vmstat 5 output during both a 4BSD and ULE run). As an additional data point, I went ahead and wrote a perl script that forks 4 simultaneous ffmpeg processes (without -threads, obviously). Here are the results (much closer, but still 4BSD is faster): RELENG_7 (4BSD): 7:20.81 RELENG_7 (ULE): 7:22.63 This is only a 1% difference, but 4BSD is still faster. So, am I doing something wrong here? Are there additional kernel options/settings I need to tweak ULE properly? Or is this particular workload simply better on 4BSD? Thanks! Josh vmstat 5 output during ULE/4BSD runs with ffmpeg ... -threads 8: 4BSD: procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad6 ad8 in sy cs us sy id 1 1 0 412348 1589544 508 0 0 0 507 0 0 0 22 694 643 3 0 97 3 1 0 754860 1416760 8504 0 0 0 20 0 0 0 15 1339 2092 94 1 5 6 1 0 757940 1402456 565 0 0 0 1 0 0 0 18 1081 944 98 0 2 6 1 0 757940 1396564 188 0 0 0 3 0 15 0 45 1136 1075 96 0 4 7 1 0 757940 1393236 30 0 0 0 1 0 1 0 21 937 851 97 0 3 6 2 0 760192 1390756 60 0 0 1 43 0 5 0 25 1065 902 96 0 3 5 2 0 760192 1390304 3 0 0 0 100 0 0 0 19 1365 1240 98 0 2 4 1 0 758964 1388592 25 0 0 0 16 0 0 0 15 997 869 96 0 4 7 1 0 758964 1386132 3 0 0 0 0 0 0 0 14 810 766 96 0 4 5 1 0 758964 1383608 2 0 0 0 0 0 0 0 28 695 713 99 0 1 4 1 0 758964 1380372 26 0 0 0 1 0 7 0 29 806 842 96 0 3 7 1 0 759992 1377440 11 0 0 0 1 0 1 0 29 810 802 98 0 2 3 1 0 759992 1375412 2 0 0 0 2 0 0 0 20 879 785 97 0 3 4 1 0 759992 1373168 1 0 0 0 1 0 0 0 13 1032 876 95 0 5 5 1 0 759992 1371204 2 0 0 0 0 0 0 0 21 1197 984 85 0 15 5 1 0 759992 1367676 3 0 0 0 0 0 0 0 20 1155 897 98 0 1 4 1 0 759992 1362272 24 0 0 0 0 0 0 0 21 826 719 98 0 2 6 2 0 762244 1359028 58 0 0 0 43 0 1 0 23 1404 1071 96 0 4 procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad6 ad8 in sy cs us sy id 7 2 0 762244 1356036 7 0 0 0 0 0 0 0 21 1236 959 99 0 1 ULE: procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad6 ad8 in sy cs us sy id 0 4 0 283788 1781208 2333 7 17 0 1633 0 0 0 211 4057 1702 1 1 99 6 2 0 631152 1606120 8180 5 23 0 30 0 65 0 157 915 371336 79 0 21 6 2 0 634228 1583908 906 0 0 0 3 0 5 0 32 566 940216 93 0 7 6 2 0 634228 1575052 227 0 0 0 0 0 1 0 96 915 694291 94 0 6 5 2 0 636276 1569768 54 0 0 0 0 0 1 0 79 722 984529 93 0 7 6 2 0 636276 1565184 3 0 0 0 0 0 0 0 56 749 615641 95 0 5 6 2 0 633024 1560904 182 0 0 0 224 0 15 0 64 892 554573 95 0 5 6 2 0 633024 1557648 1 0 0 0 0 0 0 0 21 1046 925070 94 0 6 8 1 0 631800 1553088 27 0 0 0 16 0 0 0 23 773 421820 96 0 3 7 1 0 631800 1548752 3 0 0 0 0 0 0 0 27 552 714116 96 0 4 7 1 0 631800 1543804 20 0 0 0 0 0 0 0 20 541 887702 94 0 6 6 1 0 632824 1537948 15 0 0 0 1 0 1 0 25 590 691248 95 0 5 7 1 0 632824 1533896 1 0 0 0 4 0 1 0 21 676 545389 95 0 5 7 1 0 632824 1528332 2 0 0 0 0 0 0 0 23 787 637327 93 0 7 5 1 0 632824 1525668 1 0 0 0 0 0 0 0 13 893 722130 90 0 10 3 1 0 632824 1520008 3 0 0 0 0 0 0 0 25 897 1216075 81 0 19 6 1 0 632824 1510980 25 0 0 0 0 0 0 0 33 932 1126821 90 0 10 7 1 0 632824 1503956 1 0 0 0 3 0 0 0 29 804 961332 93 0 7 procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad6 ad8 in sy cs us sy id 4 2 0 635076 1498816 59 0 0 0 43 0 0 0 24 1014 1188872 91 0 9 7 2 0 635076 1492764 7 0 0 0 0 0 1 0 28 1283 1085336 88 0 11 From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 16:29:20 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D49C16A421 for ; Wed, 17 Oct 2007 16:29:20 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 454E513C465 for ; Wed, 17 Oct 2007 16:29:18 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 17 Oct 2007 16:29:17 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp027) with SMTP; 17 Oct 2007 18:29:17 +0200 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX1+H7AppoE2HQNwFP8HXo/p1keC1YzygGY1v1xGiZR kG91q0zx/NK3tV Message-ID: <47163859.8050804@gmx.de> Date: Wed, 17 Oct 2007 18:29:13 +0200 From: "[LoN]Kamikaze" User-Agent: Thunderbird 2.0.0.6 (X11/20071015) MIME-Version: 1.0 To: Kris Kennaway References: <47150D87.3070804@gmx.de> <47150F82.9060805@FreeBSD.org> <20071016125400.N598@10.0.0.1> <47151879.50502@FreeBSD.org> In-Reply-To: <47151879.50502@FreeBSD.org> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: Jeff Roberson , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: SCHED_4BSD in RELENG_7 disturbs workflow X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 16:29:20 -0000 Kris Kennaway wrote: > Jeff Roberson wrote: >> On Tue, 16 Oct 2007, Kris Kennaway wrote: >> >>> [LoN]Kamikaze wrote: >>>> I know that RELENG_7 is not considered very near-release, but I >>>> thought I'd >>>> give my 2¢ in the hope that I might have a little influence on the >>>> scheduler >>>> development to my benefit. >>>> >>>> The switch from RELENG_6 to RELENG_7 went relatively smooth and >>>> apart from ipw >>>> causing panics. However there is one thing that's disturbing and >>>> this is the >>>> scheduler. I only have single core machines, so whatever I say only >>>> applies to >>>> those. If you think single-core machines are no longer important, >>>> feel free to >>>> ignore this. In deed, just ignore me however much you like. >>>> >>>>> From my perspective scheduling on RELENG_6 was way better. Even on >>>>> a full >>>> workload like a portupgrade the focused application (both in X and >>>> on the >>>> console) always received enough cycles to run smoothly and >>>> applications that >>>> ran in background like audio players also kept on running fine. >>>> >>>> Quite the contrary on RELENG_7. During a portupgrade or even worse >>>> 'pkgdb -L' >>>> (recovering lost dependencies) audio players (both graphical and >>>> mplayer) >>>> scatter, either because they don't get the hard-disk or CPU-cycles >>>> (which one, >>>> I don't know) and the focused application also often hangs. It just >>>> looks like >>>> occasionally (under load) everything freezes for a second and then >>>> goes on >>>> relatively normal. >>>> >>>> I've got the impression that things compile a little faster (that >>>> might be my >>>> imagination, though), but I'd rather have a smooth working experience. >>>> >>>> This is just my view of the situation and I suppose it is only one >>>> of many. I >>>> bid you be merciful with us single-core people, who cannot afford a >>>> slick >>>> multi-core machine, because we worry how to pay for our food at the >>>> end of the >>>> month. >>> >>> Not to say that any problems that might have developed with >>> SCHED_4BSD should not be fixed, but you should give SCHED_ULE a try >>> since it brings benefits even for single CPU systems (e.g. better >>> interactive response). >> >> It would indeed be good to know if ULE improves things for you. >> However, there have been a number of other reports about non-scheduler >> related regressions with x windows on 7.0. I run 7.0 on a UP laptop >> without difficulty. I wonder if it has something to do with a >> particular device or driver. > > Or xorg 7.3 vs 7.2, if this was an older 6.x install. > > Kris > I was on Xorg 7.3 before I switched to RELENG_7. Now, my problems have been solved, thanks to all your suggestions. It turned out that I actually had 2 problems, which only appeared to be one. The first one was the scheduler. ULE feels much better to me, the system responds fine now. The other problem was the strange occurance that X froze when the mouse was not in movement on one of my machines. The solution was to rebuild x11-drivers/xf86-input-mouse . Now everything seems to run fine. Thanks everyone for all the feedback and suggestions. My next project will be to build my kernel with debugging and produce decent traces for my ipw panics. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 16:52:42 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63EE216A417 for ; Wed, 17 Oct 2007 16:52:42 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.freebsd.org (Postfix) with ESMTP id 1367113C48A for ; Wed, 17 Oct 2007 16:52:41 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (adsl-68-252-59-152.dsl.wotnoh.ameritech.net [68.252.59.152]) (authenticated bits=0) by mail.united-ware.com (8.13.8/8.13.8) with ESMTP id l9HGR1He063649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Oct 2007 12:27:02 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-stable@freebsd.org Date: Wed, 17 Oct 2007 12:28:30 -0400 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5504579.z5PJSXRgDt"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200710171228.39123.mistry.7@osu.edu> Subject: RELENG_7 jerky mouse and skipping sound X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 16:52:42 -0000 --nextPart5504579.z5PJSXRgDt Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I just updated to RELENG_7 from 6.2 and I'm running into some really=20 annoying issues with jerky mouse movement and skipping sound. This=20 seems to be similar to: Re: SCHED_4BSD in RELENG_7 disturbs workflow This happens both with 4BSD and ULE. I seems to happen when I'm compiling ports and a new cc/bzip2/sh=20 process fires off (I'm just watching top), I'll get the=20 skip/freezeup. This behavior is pretty pronounced, as I'm installing gutenprint right=20 now. bigguy# sysctl hw.acpi hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: S3 hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 5 hw.acpi.s4bios: 0 hw.acpi.verbose: 1 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 bigguy# sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=3D\_PR_.CPU1 dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.0.%parent: acpi0 dev.cpu.0.cx_supported: C1/0 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% This didn't happen with 6.2. I'm running UP with Xorg 7.2. http://am-productions.biz/debug/releng_7/BIGGUY http://am-productions.biz/debug/releng_7/vmstat-i.txt http://am-productions.biz/debug/releng_7/dmesg.boot http://am-productions.biz/debug/releng_7/pkg_into.txt Let me know what other information I need to provide. =2D-=20 Anish Mistry --nextPart5504579.z5PJSXRgDt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHFjg3xqA5ziudZT0RAoxWAKDJCkTx2UOzIevCcXn0RqTy1DERIQCbB/sS mLxFvmEuwIphdjDVf8KuyVA= =A+yy -----END PGP SIGNATURE----- --nextPart5504579.z5PJSXRgDt-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 17:04:09 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0690C16A41A for ; Wed, 17 Oct 2007 17:04:09 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 6403813C46B for ; Wed, 17 Oct 2007 17:04:08 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 17 Oct 2007 17:04:07 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp052) with SMTP; 17 Oct 2007 19:04:07 +0200 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX18N78g4UusNQ4oIACgyX6zHM6pmbyEPNnPwAeL2rQ AdS6sLDw1SsiNb Message-ID: <47164086.3080605@gmx.de> Date: Wed, 17 Oct 2007 19:04:06 +0200 From: "[LoN]Kamikaze" User-Agent: Thunderbird 2.0.0.6 (X11/20071015) MIME-Version: 1.0 To: Anish Mistry References: <200710171228.39123.mistry.7@osu.edu> In-Reply-To: <200710171228.39123.mistry.7@osu.edu> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 jerky mouse and skipping sound X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 17:04:09 -0000 Anish Mistry wrote: > I just updated to RELENG_7 from 6.2 and I'm running into some really > annoying issues with jerky mouse movement and skipping sound. This > seems to be similar to: > Re: SCHED_4BSD in RELENG_7 disturbs workflow > This happens both with 4BSD and ULE. > > I seems to happen when I'm compiling ports and a new cc/bzip2/sh > process fires off (I'm just watching top), I'll get the > skip/freezeup. > > This behavior is pretty pronounced, as I'm installing gutenprint right > now. > > bigguy# sysctl hw.acpi > hw.acpi.supported_sleep_state: S1 S3 S4 S5 > hw.acpi.power_button_state: S5 > hw.acpi.sleep_button_state: S1 > hw.acpi.lid_switch_state: S3 > hw.acpi.standby_state: S1 > hw.acpi.suspend_state: S3 > hw.acpi.sleep_delay: 5 > hw.acpi.s4bios: 0 > hw.acpi.verbose: 1 > hw.acpi.disable_on_reboot: 0 > hw.acpi.handle_reboot: 0 > hw.acpi.reset_video: 0 > hw.acpi.cpu.cx_lowest: C1 > bigguy# sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU1 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.cx_supported: C1/0 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% > > This didn't happen with 6.2. I'm running UP with Xorg 7.2. > http://am-productions.biz/debug/releng_7/BIGGUY > http://am-productions.biz/debug/releng_7/vmstat-i.txt > http://am-productions.biz/debug/releng_7/dmesg.boot > http://am-productions.biz/debug/releng_7/pkg_into.txt > > Let me know what other information I need to provide. 2 things fixed it for me: Using SCHED_ULE and rebuilding x11-drivers/xf86-input-mouse. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 17:39:03 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9F6216A41A for ; Wed, 17 Oct 2007 17:39:03 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id AF2D513C469; Wed, 17 Oct 2007 17:39:02 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <471648B6.5020602@FreeBSD.org> Date: Wed, 17 Oct 2007 19:39:02 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Bengt Ahlgren References: <20071004165755.GA1049@pp.htv.fi> <47120D83.1010703@FreeBSD.org> <20071015203202.GA17964@pp.htv.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 17:39:03 -0000 Bengt Ahlgren wrote: > Esa Karkkainen writes: > >> On Sun, Oct 14, 2007 at 02:37:23PM +0200, Kris Kennaway wrote: >>> Esa Karkkainen wrote: >>>> I get "Fatal double fault" error when writing to a filesystem >>>> mounted from NFS server. >> I got an offlist reply in which he suggested that the problem might be >> in nve driver. > > That was me. I indeed got the same fault when running NFS over nve. > Switching to nfe solved the problem for me. The on-screen backtrace > reveals the true location of the problem. See: > > http://www.sics.se/~bengta/FBSD/DSC00585.JPG > > I do have a dump, but for some reason kgdb is not able to show the > same information. If you're using a module you have to do extra (but documented) steps. Or maybe kgdb has forgotten how to decode a double fault. Anyway, this information is indeed definitive, and it's what others seeing this problem need to provide if they still have doubts. Kris From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 19:53:55 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E773016A420; Wed, 17 Oct 2007 19:53:55 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from comtv.ru (comtv.ru [217.10.32.17]) by mx1.freebsd.org (Postfix) with ESMTP id A49AA13C481; Wed, 17 Oct 2007 19:53:54 +0000 (UTC) (envelope-from lol@chistydom.ru) X-UCL: actv Received: from yoda.org.ru ([83.167.98.162] verified) by comtv.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP id 6506471; Wed, 17 Oct 2007 22:53:52 +0400 Received: from [192.168.102.10] (unknown [192.168.102.10]) (Authenticated sender: llp@soekris.ru) by yoda.org.ru (Postfix) with ESMTP id 6622228BD6; Wed, 17 Oct 2007 22:54:00 +0400 (MSD) Message-ID: <47165A01.1030806@chistydom.ru> Date: Wed, 17 Oct 2007 22:52:49 +0400 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Kris Kennaway References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> <47147E49.9020301@FreeBSD.org> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> In-Reply-To: <4715C5D7.7060806@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------040405020607060803010501" Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 19:53:56 -0000 This is a multi-part message in MIME format. --------------040405020607060803010501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Kris Kennaway wrote: >>>> And few hours ago I received feed back from Andrzej Tobola, he has >>>> the same problem on FreeBSD 7 with Promise ATA software mirror: >>> Well, he didnt provide any evidence yet that it is the same problem, >>> so let's not become confused by feelings :) >> I think he is telling about 100% disk busy while processing ~5 >> transfers/sec. > > "% busy" as reported by gstat doesn't mean what you think it does. What > is the I/O response time? That's the meaningful statistic for > evaluating I/O load. Also you didnt post about this. At the problematic time the disk felt to be very slow, processes all were in reading disk state and vmstat proved it by the % numbers. >>>> So I can conclude that FreeBSD has a long standing bug in VM that >>>> could be triggered when serving large amount of static data (much >>>> bigger than memory size) on high rates. Possibly this only applies >>>> to large files like mp3 or video. >>> It is possible, we have further work to do to conclude this though. >> I forgot to mention I have pmc and kgmon profiling for good and bad >> times. But I have not enough knowledge to interpret it right and not >> sure if it can help. > pmc would be useful. Unfortunately i've lost pmc profiling results. I'll try to collect it again later. See vmstats in attach (vmstat -z; netstat -m; vmstat -i; vmstat -w 1 | head -11;). Also you can see kgmon profiling results at: http://83.167.98.162/gprof/ With best regards, Alexey Popov --------------040405020607060803010501 Content-Type: text/plain; name="vmstat-bad.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vmstat-bad.txt" ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 240, 0, 71, 4, 71, 0 UMA Zones: 376, 0, 71, 9, 71, 0 UMA Slabs: 128, 0, 1011, 62, 243081, 0 UMA RCntSlabs: 128, 0, 361, 1205, 363320, 0 UMA Hash: 256, 0, 4, 11, 7, 0 16 Bucket: 152, 0, 45, 30, 72, 0 32 Bucket: 280, 0, 25, 45, 69, 0 64 Bucket: 536, 0, 17, 25, 55, 53 128 Bucket: 1048, 0, 287, 88, 1200, 95423 VM OBJECT: 224, 0, 5536, 23228, 7675004, 0 MAP: 352, 0, 7, 15, 7, 0 KMAP ENTRY: 112, 90222, 283, 1037, 1207524, 0 MAP ENTRY: 112, 0, 1396, 419, 72221561, 0 PV ENTRY: 48, 2244600, 17835, 30261, 768591673, 0 DP fakepg: 120, 0, 0, 31, 10, 0 mt_zone: 1024, 0, 170, 6, 170, 0 16: 16, 0, 3578, 2470, 745206870, 0 32: 32, 0, 1273, 343, 1750850, 0 64: 64, 0, 6147, 1693, 487691440, 0 128: 128, 0, 4659, 387, 1464251, 0 256: 256, 0, 596, 2539, 7208469, 0 512: 512, 0, 608, 253, 791295, 0 1024: 1024, 0, 49, 239, 82867, 0 2048: 2048, 0, 27, 295, 115362, 0 4096: 4096, 0, 240, 278, 564659, 0 Files: 120, 0, 544, 324, 263880246, 0 TURNSTILE: 104, 0, 181, 83, 307, 0 PROC: 856, 0, 82, 82, 308409, 0 THREAD: 608, 0, 169, 11, 24468, 0 KSEGRP: 136, 0, 165, 69, 165, 0 UPCALL: 88, 0, 3, 73, 3, 0 SLEEPQUEUE: 64, 0, 181, 99, 307, 0 VMSPACE: 544, 0, 35, 77, 310929, 0 mbuf_packet: 256, 0, 368, 115, 1331807039, 0 mbuf: 256, 0, 2016, 2331, 5433003167, 0 mbuf_cluster: 2048, 32768, 483, 239, 1236143964, 0 mbuf_jumbo_pagesize: 4096, 0, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 0, 0, 0, 0, 0 ACL UMA zone: 388, 0, 0, 0, 0, 0 g_bio: 216, 0, 4, 410, 48175991, 0 ata_request: 336, 0, 0, 22, 24, 0 ata_composite: 376, 0, 0, 0, 0, 0 VNODE: 496, 0, 28250, 21270, 911708, 0 VNODEPOLL: 152, 0, 0, 0, 0, 0 S VFS Cache: 104, 0, 29153, 9979, 1387950, 0 L VFS Cache: 327, 0, 258, 282, 9423, 0 NAMEI: 1024, 0, 0, 260, 286369405, 0 NFSMOUNT: 584, 0, 1, 6, 1, 0 NFSNODE: 664, 0, 1, 5, 126, 0 DIRHASH: 1024, 0, 278, 122, 1954, 0 PIPE: 768, 0, 35, 335, 253930, 0 KNOTE: 120, 0, 354, 235, 689363256, 0 socket: 616, 49152, 504, 264, 1311349, 0 ipq: 56, 1071, 0, 0, 135, 0 udpcb: 304, 49152, 6, 42, 185368, 0 inpcb: 304, 49152, 384, 192, 903992, 0 tcpcb: 752, 49155, 376, 179, 903992, 0 tcptw: 80, 8235, 8, 487, 211995, 0 syncache: 128, 15370, 0, 145, 890626, 0 hostcache: 136, 15372, 2620, 572, 251887, 0 tcpreass: 40, 2100, 0, 336, 265497, 0 sackhole: 32, 0, 7, 397, 30124600, 0 ripcb: 304, 49152, 0, 36, 64, 0 unpcb: 200, 49153, 40, 340, 221924, 0 rtentry: 264, 0, 6, 36, 26, 0 divcb: 304, 49152, 0, 0, 0, 0 IPFW dynamic rule: 120, 0, 212, 346, 113020, 0 SWAPMETA: 288, 116519, 280, 786, 87016, 0 Mountpoints: 792, 0, 9, 16, 13, 0 FFS inode: 192, 0, 28202, 6158, 911421, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 28202, 5713, 911421, 0 2381/2449/4830 mbufs in use (current/cache/total) 368/354/722/32768 mbuf clusters in use (current/cache/total/max) 368/112 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 1331K/1320K/2651K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 8441913 requests for I/O initiated by sendfile 6263 calls to protocol drain routines interrupt total rate irq6: fdc0 8 0 irq14: ata0 47 0 irq16: uhci0 1464547796 1870 irq18: uhci2 12614009 16 irq23: ehci0 3 0 irq46: amr0 12215890 15 irq64: em0 1463513610 1869 cpu0: timer 1564021008 1997 cpu1: timer 1565552539 1999 Total 6082464910 7768 procs memory page disk faults cpu r b w avm fre flt re pi po fr sr am0 in sy cs us sy id 0 2 0 84568 155760 130 3 3 0 298 193 0 771 3421 2251 0 5 95 0 2 0 84576 155488 18 0 0 0 0 0 9 3167 219 7860 0 2 98 0 2 0 84576 155360 0 0 0 0 0 0 2 3568 155 8485 0 1 99 0 2 0 84576 155296 0 0 0 0 0 0 1 2298 110 6218 0 0 100 0 2 0 84576 155232 0 0 0 0 0 0 1 1288 110 4568 0 0 100 0 2 0 84580 154792 1 0 0 0 0 0 10 1459 896 4830 0 1 99 0 2 0 84580 154664 0 0 0 0 0 0 2 2718 128 6911 0 1 99 0 2 0 84580 154376 0 0 0 0 4 0 8 1436 200 4834 0 0 100 0 2 0 84580 154312 0 0 0 0 0 0 1 1500 110 4938 0 0 100 --------------040405020607060803010501 Content-Type: text/plain; name="vmstat-good.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vmstat-good.txt" ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 240, 0, 71, 4, 71, 0 UMA Zones: 376, 0, 71, 9, 71, 0 UMA Slabs: 128, 0, 1003, 70, 237825, 0 UMA RCntSlabs: 128, 0, 502, 2108, 357019, 0 UMA Hash: 256, 0, 4, 11, 7, 0 16 Bucket: 152, 0, 45, 30, 72, 0 32 Bucket: 280, 0, 25, 45, 69, 0 64 Bucket: 536, 0, 17, 25, 55, 53 128 Bucket: 1048, 0, 304, 80, 1200, 95423 VM OBJECT: 224, 0, 4475, 24289, 7583940, 0 MAP: 352, 0, 7, 15, 7, 0 KMAP ENTRY: 112, 90222, 327, 993, 1178293, 0 MAP ENTRY: 112, 0, 1396, 683, 71990087, 0 PV ENTRY: 48, 2244600, 16841, 31255, 764952854, 0 DP fakepg: 120, 0, 0, 31, 10, 0 mt_zone: 1024, 0, 170, 6, 170, 0 16: 16, 0, 3147, 1725, 721283017, 0 32: 32, 0, 1273, 343, 1378831, 0 64: 64, 0, 6161, 1567, 487602322, 0 128: 128, 0, 4658, 388, 1442320, 0 256: 256, 0, 609, 1836, 7119682, 0 512: 512, 0, 608, 253, 781061, 0 1024: 1024, 0, 49, 239, 81907, 0 2048: 2048, 0, 29, 249, 114521, 0 4096: 4096, 0, 239, 294, 558310, 0 Files: 120, 0, 274, 408, 250373577, 0 TURNSTILE: 104, 0, 181, 83, 307, 0 PROC: 856, 0, 82, 82, 304241, 0 THREAD: 608, 0, 169, 11, 24468, 0 KSEGRP: 136, 0, 165, 69, 165, 0 UPCALL: 88, 0, 3, 73, 3, 0 SLEEPQUEUE: 64, 0, 181, 99, 307, 0 VMSPACE: 544, 0, 35, 77, 306723, 0 mbuf_packet: 256, 0, 619, 207, 1297797817, 0 mbuf: 256, 0, 1584, 1190, 5274774672, 0 mbuf_cluster: 2048, 32768, 826, 178, 1203897447, 0 mbuf_jumbo_pagesize: 4096, 0, 0, 0, 0, 0 mbuf_jumbo_9k: 9216, 0, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 0, 0, 0, 0, 0 ACL UMA zone: 388, 0, 0, 0, 0, 0 g_bio: 216, 0, 0, 270, 47261412, 0 ata_request: 336, 0, 0, 22, 24, 0 ata_composite: 376, 0, 0, 0, 0, 0 VNODE: 496, 0, 26256, 23264, 899305, 0 VNODEPOLL: 152, 0, 0, 0, 0, 0 S VFS Cache: 104, 0, 27155, 11977, 1367768, 0 L VFS Cache: 327, 0, 227, 313, 9350, 0 NAMEI: 1024, 0, 0, 260, 272236181, 0 NFSMOUNT: 584, 0, 1, 6, 1, 0 NFSNODE: 664, 0, 1, 5, 126, 0 DIRHASH: 1024, 0, 278, 122, 1938, 0 PIPE: 768, 0, 35, 335, 250212, 0 KNOTE: 120, 0, 93, 372, 666594974, 0 socket: 616, 49152, 212, 466, 1282315, 0 ipq: 56, 1071, 0, 0, 135, 0 udpcb: 304, 49152, 6, 42, 183757, 0 inpcb: 304, 49152, 225, 351, 877750, 0 tcpcb: 752, 49155, 166, 389, 877750, 0 tcptw: 80, 8235, 59, 436, 204414, 0 syncache: 128, 15370, 0, 145, 864539, 0 hostcache: 136, 15372, 2200, 348, 244865, 0 tcpreass: 40, 2100, 0, 336, 252564, 0 sackhole: 32, 0, 20, 384, 29347536, 0 ripcb: 304, 49152, 0, 36, 64, 0 unpcb: 200, 49153, 40, 340, 220743, 0 rtentry: 264, 0, 6, 36, 26, 0 divcb: 304, 49152, 0, 0, 0, 0 IPFW dynamic rule: 120, 0, 215, 219, 112109, 0 SWAPMETA: 288, 116519, 280, 786, 85846, 0 Mountpoints: 792, 0, 9, 16, 13, 0 FFS inode: 192, 0, 26208, 8152, 899018, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 26208, 7722, 899018, 0 2195/1405/3600 mbufs in use (current/cache/total) 619/385/1004/32768 mbuf clusters in use (current/cache/total/max) 619/127 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 1786K/1121K/2908K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 8233198 requests for I/O initiated by sendfile 6116 calls to protocol drain routines interrupt total rate irq6: fdc0 8 0 irq14: ata0 47 0 irq16: uhci0 1428187319 1851 irq18: uhci2 12374352 16 irq23: ehci0 3 0 irq46: amr0 11983237 15 irq64: em0 1427141755 1850 cpu0: timer 1540896452 1997 cpu1: timer 1542377798 1999 Total 5962960971 7730 procs memory page disk faults cpu r b w avm fre flt re pi po fr sr am0 in sy cs us sy id 0 1 0 80564 117716 131 3 3 0 298 191 0 628 3371 1994 0 5 95 0 1 0 80568 117640 5 0 0 0 2 0 10 10265 7724 20485 1 6 93 0 1 0 80568 117400 0 0 0 0 0 0 3 10589 8031 21145 0 8 92 0 1 0 80568 116888 0 0 0 0 0 0 8 11745 8362 22538 0 12 88 0 1 0 80568 116312 0 0 0 0 0 0 9 12191 10091 23571 1 11 88 0 1 0 80568 116184 0 0 0 0 0 0 2 13182 10350 25259 1 12 87 0 2 0 80568 115928 0 0 0 0 0 0 3 12896 8176 24112 0 10 90 0 1 0 80568 115736 0 0 0 0 33 0 4 9527 5090 18717 0 9 91 0 1 0 80568 115608 0 0 0 0 32 0 2 13953 11915 26066 0 11 89 --------------040405020607060803010501-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 20:11:44 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9B6116A41A for ; Wed, 17 Oct 2007 20:11:44 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 84B7113C461 for ; Wed, 17 Oct 2007 20:11:44 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: by hyperion.scode.org (Postfix, from userid 1001) id 419F723C460; Wed, 17 Oct 2007 22:11:43 +0200 (CEST) Date: Wed, 17 Oct 2007 22:11:43 +0200 From: Peter Schuller To: freebsd-stable@freebsd.org Message-ID: <20071017201142.GA94204@hyperion.scode.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Subject: 'nv' in RELENG_7 does not detect 7900GS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 20:11:44 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, so I just upgraded my desktop to RELENG_7 and suddenly the nv driver is completely unable to detect the presence of my 7900GS. It acts exactly as if the card was not in the machine. driver loads without errors, but does not detect any devices. I tried upgrading to the latest point release of the driver (as available in ports), which did not help. At least one guyon ##freebsd apparantly has the same problem. Does anyone know what's going on? The lack of any kind of error means I pretty much don't know where to look. It could have been triggered by the Xorg upgrade rather than RELENG_7; unfortunately I am not sure which X server I started when I started up my desktop last. --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHFmx+DNor2+l1i30RAv29AKDN06q+B+nizxgyr3yi7wTVQI9POgCg5Al8 yW0q1aIINtv/DYubItfMkDU= =+lqx -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 20:21:51 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 027CA16A418 for ; Wed, 17 Oct 2007 20:21:51 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 8E16A13C461 for ; Wed, 17 Oct 2007 20:21:45 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-066-055-120.pools.arcor-ip.net [88.66.55.120]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1IiFOh0egT-0003pO; Wed, 17 Oct 2007 22:21:43 +0200 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Wed, 17 Oct 2007 22:21:35 +0200 User-Agent: KMail/1.9.7 References: <20071017201142.GA94204@hyperion.scode.org> In-Reply-To: <20071017201142.GA94204@hyperion.scode.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1322834.x5SKfLWVm5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200710172221.41618.max@love2party.net> X-Provags-ID: V01U2FsdGVkX188X9uNHMLson1rWFMXuOcBwuOsTPR5G94QK0m ZGbKclg4tfXaKw8gycPY32T4WnMq+abRrBDzvEjiz0b/Fq28Eu uc2zNHbCMOrP76XonxjvnD9+R177vaQnzGDfHfrwQQ= Cc: Peter Schuller Subject: Re: 'nv' in RELENG_7 does not detect 7900GS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 20:21:51 -0000 --nextPart1322834.x5SKfLWVm5 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 17 October 2007, Peter Schuller wrote: > Hello, > > so I just upgraded my desktop to RELENG_7 and suddenly the nv driver > is completely unable to detect the presence of my 7900GS. It acts > exactly as if the card was not in the machine. driver loads without > errors, but does not detect any devices. > > I tried upgrading to the latest point release of the driver (as > available in ports), which did not help. > > At least one guyon ##freebsd apparantly has the same problem. > > Does anyone know what's going on? The lack of any kind of error means > I pretty much don't know where to look. > > It could have been triggered by the Xorg upgrade rather than RELENG_7; > unfortunately I am not sure which X server I started when I started up > my desktop last. did you do a xorg-server rebuild after (from UPDATING): 20070930: The PCI code has been made aware of PCI domains. This means that the location strings as used by pciconf(8) etc are now in the following format: pci::[:]. It also means that consumers of potentially need to be recompiled; this includes the hal and xorg-server ports. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1322834.x5SKfLWVm5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHFm7VXyyEoT62BG0RAqgiAJwPPehRMsO/a/6UL+lZr5p6UdaK5ACeKpY/ 1w6vjwjI4Qlb1U5UbL6fL+Q= =MvAV -----END PGP SIGNATURE----- --nextPart1322834.x5SKfLWVm5-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 20:28:26 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34FFB16A417 for ; Wed, 17 Oct 2007 20:28:26 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id EE7D213C4A6 for ; Wed, 17 Oct 2007 20:28:25 +0000 (UTC) (envelope-from scode@hyperion.scode.org) Received: by hyperion.scode.org (Postfix, from userid 1001) id 15D6523C460; Wed, 17 Oct 2007 22:28:25 +0200 (CEST) Date: Wed, 17 Oct 2007 22:28:25 +0200 From: Peter Schuller To: Max Laier Message-ID: <20071017202824.GA95318@hyperion.scode.org> References: <20071017201142.GA94204@hyperion.scode.org> <200710172221.41618.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <200710172221.41618.max@love2party.net> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: 'nv' in RELENG_7 does not detect 7900GS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 20:28:26 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > did you do a xorg-server rebuild after (from UPDATING): No, stupid me. I did read the UPDATING entry on the pciio.h changes, but apparantly sifted through a bit two quickly and didn't register that this would affect xorg. Oh well, hopefully the post was not for nothing and the ML archive will help some people. Thanks a lot! --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHFnBoDNor2+l1i30RAhXjAJ9CjAz6D5K95JQ95EVHT1f03wVD4gCaAuzs Djtav4jZkj7zXh1YtXAPUgc= =g+p2 -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 22:15:21 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFDF616A41A for ; Wed, 17 Oct 2007 22:15:21 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 242E613C448 for ; Wed, 17 Oct 2007 22:15:20 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 17 Oct 2007 22:15:19 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp030) with SMTP; 18 Oct 2007 00:15:19 +0200 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX18Bakg4Ar0BFqk7E4U2tUjsm2Yl01sds1oErY/hDa fQhbHDnOfp+a7s Message-ID: <47168971.7070408@gmx.de> Date: Thu, 18 Oct 2007 00:15:13 +0200 From: "[LoN]Kamikaze" User-Agent: Thunderbird 2.0.0.6 (X11/20071015) MIME-Version: 1.0 To: Anish Mistry References: <200710171228.39123.mistry.7@osu.edu> <47164086.3080605@gmx.de> In-Reply-To: <47164086.3080605@gmx.de> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 jerky mouse and skipping sound X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 22:15:21 -0000 [LoN]Kamikaze wrote: > Anish Mistry wrote: >> I just updated to RELENG_7 from 6.2 and I'm running into some really >> annoying issues with jerky mouse movement and skipping sound. This >> seems to be similar to: >> Re: SCHED_4BSD in RELENG_7 disturbs workflow >> This happens both with 4BSD and ULE. >> >> I seems to happen when I'm compiling ports and a new cc/bzip2/sh >> process fires off (I'm just watching top), I'll get the >> skip/freezeup. >> >> This behavior is pretty pronounced, as I'm installing gutenprint right >> now... > > 2 things fixed it for me: > Using SCHED_ULE and rebuilding x11-drivers/xf86-input-mouse. It turned out my report of success was wrong. However I think I cornered the problem. The following lines are two snippets of xev output: KeymapNotify event, serial 28, synthetic NO, window 0x0, keys: 69 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ButtonPress event, serial 28, synthetic NO, window 0xe00001, root 0x145, subw 0x0, time 2952962341, (21,177), root:(1649,206), state 0x0, button 1, same_screen YES Both events are the result of pressing the left mouse button. Sometimes the first, sometimes the second message appears. So it seems that Xorg has trouble with /dev/sysmouse. If I omit moused and configure X to take the mouse from /dev/ums0, everything seems to be fine. The same, if I opperate without a mouse. From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 23:03:24 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E158116A419 for ; Wed, 17 Oct 2007 23:03:24 +0000 (UTC) (envelope-from dyeske@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id 81D0213C45B for ; Wed, 17 Oct 2007 23:03:24 +0000 (UTC) (envelope-from dyeske@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so1977903nfb for ; Wed, 17 Oct 2007 16:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=JbEGrwHx+5RQvKWMHgdClbR3WILqKdxE8HijaTeZU+c=; b=tg2OKT+1TEsX16rX0icKeFVVVe8loCulwwEhPNJB1BGWEC5QWdQEv3KMcgoJ7hICQ0bM9IYbFnK5XZiUnLSC/VBxbXz04FyQtBK85haOPqM/ekkbcfmjJZ5CpIRQuJlzc8YouVjQihBxdWRR+rrIEDt3d8e7ZeLIYB1r9Fb9igk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=fQsFTu5jE2jkSo63/Ms2yGP1v/V4IP6HglkMWFC9PRHuHIvYqOlCDabike6FLnwJbOFTDMMbsgDuynOHN5Ow9KEZNybLtKEeeyTiGH2g/guqdTm6lttuRyJFr5mTADX086olUjfiTw19oUf3fpKCg1LrFWs8WsfbKh1GYPqa23Y= Received: by 10.78.150.7 with SMTP id x7mr5923948hud.1192662202214; Wed, 17 Oct 2007 16:03:22 -0700 (PDT) Received: by 10.78.151.6 with HTTP; Wed, 17 Oct 2007 16:03:22 -0700 (PDT) Message-ID: <85bdae4e0710171603p4a269efbi62710d55e37b733d@mail.gmail.com> Date: Wed, 17 Oct 2007 19:03:22 -0400 From: "David Yeske" To: "FreeBSD Stable List" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: interface speed support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 23:03:25 -0000 Is there a way to determine the supported interface speed of a particular driver? If I have a gigabit ethernet device connected to a 100baseTX switch, how can I determine the interface supports gigabit ethernet? I have tried parsing the following. Is there a cleaner way to do this? sysctl -A | grep phy | grep desc From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 23:09:05 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09E7E16A41A for ; Wed, 17 Oct 2007 23:09:04 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 8137A13C442 for ; Wed, 17 Oct 2007 23:09:04 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-31-60.bredband.comhem.se ([83.253.31.60]:54422 helo=falcon.midgard.homeip.net) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1IiI0d-0006qO-50 for freebsd-stable@freebsd.org; Thu, 18 Oct 2007 01:09:03 +0200 Received: (qmail 74929 invoked from network); 18 Oct 2007 01:09:00 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 18 Oct 2007 01:09:00 +0200 Received: (qmail 29402 invoked by uid 1001); 18 Oct 2007 01:09:00 +0200 Date: Thu, 18 Oct 2007 01:09:00 +0200 From: Erik Trulsson To: David Yeske Message-ID: <20071017230900.GA29380@owl.midgard.homeip.net> Mail-Followup-To: David Yeske , FreeBSD Stable List References: <85bdae4e0710171603p4a269efbi62710d55e37b733d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85bdae4e0710171603p4a269efbi62710d55e37b733d@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Originating-IP: 83.253.31.60 X-Scan-Result: No virus found in message 1IiI0d-0006qO-50. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1IiI0d-0006qO-50 3c35cf30ff24ea46c561b132a2943fa0 Cc: FreeBSD Stable List Subject: Re: interface speed support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 23:09:05 -0000 On Wed, Oct 17, 2007 at 07:03:22PM -0400, David Yeske wrote: > Is there a way to determine the supported interface speed of a > particular driver? If I have a gigabit ethernet device connected to a > 100baseTX switch, how can I determine the interface supports gigabit > ethernet? I have tried parsing the following. Is there a cleaner way > to do this? > > sysctl -A | grep phy | grep desc 'ifconfig -m' might be what you are looking for. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-stable@FreeBSD.ORG Wed Oct 17 23:09:16 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0385816A498 for ; Wed, 17 Oct 2007 23:09:16 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by mx1.freebsd.org (Postfix) with ESMTP id EB2DD13C459 for ; Wed, 17 Oct 2007 23:09:15 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id BA8171573326; Wed, 17 Oct 2007 16:09:15 -0700 (PDT) Received: from relay14.apple.com (unknown [127.0.0.1]) by relay14.apple.com (Symantec Mail Security) with ESMTP id 959802804C; Wed, 17 Oct 2007 16:09:15 -0700 (PDT) X-AuditID: 11807134-a9e9bbb000000861-6e-4716961b74be Received: from [17.214.13.96] (cswiger1.apple.com [17.214.13.96]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay14.apple.com (Apple SCV relay) with ESMTP id 1D170280A6; Wed, 17 Oct 2007 16:09:15 -0700 (PDT) In-Reply-To: <85bdae4e0710171603p4a269efbi62710d55e37b733d@mail.gmail.com> References: <85bdae4e0710171603p4a269efbi62710d55e37b733d@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Wed, 17 Oct 2007 16:09:14 -0700 To: David Yeske X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAA== Cc: FreeBSD Stable List Subject: Re: interface speed support X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 23:09:16 -0000 Hi, David-- On Oct 17, 2007, at 4:03 PM, David Yeske wrote: > Is there a way to determine the supported interface speed of a > particular driver? If I have a gigabit ethernet device connected to a > 100baseTX switch, how can I determine the interface supports gigabit > ethernet? I have tried parsing the following. Is there a cleaner way > to do this? Perhaps you want the "ifconfig -m _interface_" command, as in: # ifconfig -m bge0 bge0: flags=8802 mtu 1500 options=1a capability list: =1a ether 00:b0:d0:e1:92:a1 media: Ethernet autoselect (none) status: no carrier supported media: media autoselect media 1000baseTX mediaopt full-duplex media 1000baseTX media 100baseTX mediaopt full-duplex media 100baseTX media 10baseT/UTP mediaopt full-duplex media 10baseT/UTP media none -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 01:26:17 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1C6B16A417 for ; Thu, 18 Oct 2007 01:26:17 +0000 (UTC) (envelope-from SRS0=2e1007047d295f3d50d8bad3051c5692e5fc470f=491=es.net=oberman@es.net) Received: from postal1.es.net (postal3.es.net [IPv6:2001:400:14:3::8]) by mx1.freebsd.org (Postfix) with ESMTP id 88C5113C442 for ; Thu, 18 Oct 2007 01:26:15 +0000 (UTC) (envelope-from SRS0=2e1007047d295f3d50d8bad3051c5692e5fc470f=491=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id WFE69012; Wed, 17 Oct 2007 14:13:12 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 7EF984500E; Wed, 17 Oct 2007 14:13:12 -0700 (PDT) To: "Claus Guttesen" In-Reply-To: Your message of "Mon, 15 Oct 2007 22:26:43 +0200." Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1192655592_56530P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 17 Oct 2007 14:13:12 -0700 From: "Kevin Oberman" Message-Id: <20071017211312.7EF984500E@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; X-Sender: X-To_Name: Claus Guttesen X-To_Domain: gmail.com X-To: "Claus Guttesen" X-To_Email: kometen@gmail.com X-To_Alias: kometen Cc: Robert Chalmers , freebsd-stable@freebsd.org Subject: Re: can I do 6.1-RELEASE to 6.2 via cvsup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 01:26:17 -0000 --==_Exmh_1192655592_56530P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > > Yep: > > 1. make buildworld > 2. make buildkernel (add KERNCONF=mykernel to /etc/make.conf) > 3. mergemaster -p > 4. make installkernel > 5. shutdown -r now and boot into single user > 6. mount -a (if /usr/src and /usr/obj resides on their own partitions) > 7. mergemaster > 8. make installworld > 9. reboot > > I usually omit 5 and 6 because most of the time it works fine. Please don't recommend skipping 5 and 6. While it almost always works (and I have done it in the past and probably will again), it is very dangerous. You have a new userland and the new kernel won't work. you boot kernel.old. You now have a new userland and an old kernel. This can leave you totally hosed if changes in userland require features in the new kernel and not the old. While this can be recovered, it is time consuming and tedious. If you are not fairly familiar with how things work in FreeBSD, it may be hopeless. Also, the list of things to do is a bit mis-ordered and truncated. The official list is in /usr/src/UPDATING and reads: make buildworld make kernel KERNCONF=YOUR_KERNEL_HERE [1] [3] mergemaster -p [5] make installworld make delete-old mergemaster [4] -- 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 --==_Exmh_1192655592_56530P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFHFnrokn3rs5h7N1ERAmaxAJ9aNpc5lj+xFNv7Ho9XlnbGr7WRoACgq6xG mGS0iO28m991wW+/GtMPb10= =e7/5 -----END PGP SIGNATURE----- --==_Exmh_1192655592_56530P-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 05:16:59 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 137CC16A46B for ; Thu, 18 Oct 2007 05:16:59 +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 SMTP id 9DC0313C45A for ; Thu, 18 Oct 2007 05:16:58 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 16508 invoked by uid 399); 18 Oct 2007 04:50:17 -0000 Received: from localhost (HELO lap.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 18 Oct 2007 04:50:17 -0000 X-Originating-IP: 127.0.0.1 Date: Wed, 17 Oct 2007 21:50:15 -0700 (PDT) From: Doug Barton To: Jose Alonso Cardenas Marquez In-Reply-To: <7c58fcfc0710161455t20792d7dqa349ff157674048d@mail.gmail.com> Message-ID: References: <7c58fcfc0710161455t20792d7dqa349ff157674048d@mail.gmail.com> X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: jkh@FreeBSD.org, stable@freebsd.org, ache@freebsd.org Subject: Re: Call for Testers: dialog 1.1-20070930 update X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 05:16:59 -0000 On Tue, 16 Oct 2007, Jose Alonso Cardenas Marquez wrote: > Hi everyone :) > > Currently, we have an older version of libdialog/dialog (0.4) into > freebsd base system. I made a patch that update libdialog/dialog to > 1.1-20070930 (nowadays maintained by Thomas E. Dickey) This is a great project, thanks for taking this on! I tried to test your patches on my -current box, and they don't apply cleanly: find . -name \*.rej ./libdialog/dialog.3.rej ./libdialog/dialog.h.rej ./Makefile.rej ./inputbox.c.rej find . -name \*.rej ./dialog/dialog.c.rej ./Makefile.rej If you can make some patches against HEAD I'd be glad to give them a try, but I lack the time to integrate them myself right now. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 05:21:59 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7C5216A47F for ; Thu, 18 Oct 2007 05:21:59 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 18AFA13C4B2 for ; Thu, 18 Oct 2007 05:21:58 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 18 Oct 2007 05:21:57 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp055) with SMTP; 18 Oct 2007 07:21:57 +0200 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX1+8lqRpmPe8Mi5PsXwvNuatr3m2SDK9XXDM+n7Eaf eObIMlq0voY8b/ Message-ID: <4716ED74.1050608@gmx.de> Date: Thu, 18 Oct 2007 07:21:56 +0200 From: "[LoN]Kamikaze" User-Agent: Thunderbird 2.0.0.6 (X11/20071015) MIME-Version: 1.0 To: Anish Mistry References: <200710171228.39123.mistry.7@osu.edu> In-Reply-To: <200710171228.39123.mistry.7@osu.edu> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 jerky mouse and skipping sound X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 05:21:59 -0000 I have rebuilt all xorg stuff over night and it didn't help. The only way to avoid the jerkiness is having those lines in /etc/rc.conf: moused_nondefault_enable="NO" moused_enable="NO" I have configured my /usr/local/etc/X11/xorg.conf to contain the following lines in the Mouse section: Option "Protocol" "auto" Option "Device" "/dev/ums0" I'm using a USB mouse. What I think is the most likely cause, is that there's something wrong with moused, so that /dev/sysmouse feeds xorg broken signals that somehow are not handled appropriately. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 05:50:35 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DC5A16A468 for ; Thu, 18 Oct 2007 05:50:35 +0000 (UTC) (envelope-from marc@blackend.org) Received: from abigail.blackend.org (ns0.blackend.org [82.227.222.164]) by mx1.freebsd.org (Postfix) with ESMTP id 0428B13C442 for ; Thu, 18 Oct 2007 05:50:34 +0000 (UTC) (envelope-from marc@blackend.org) Received: from abigail.blackend.org (localhost [127.0.0.1]) by abigail.blackend.org (8.13.4/8.13.3) with ESMTP id l9I5cdwZ025608; Thu, 18 Oct 2007 07:38:40 +0200 (CEST) (envelope-from marc@abigail.blackend.org) Received: (from marc@localhost) by abigail.blackend.org (8.13.4/8.13.3/Submit) id l9I5cdZO025607; Thu, 18 Oct 2007 07:38:39 +0200 (CEST) (envelope-from marc) Date: Thu, 18 Oct 2007 07:38:39 +0200 From: Marc Fonvieille To: Anish Mistry Message-ID: <20071018053839.GA25417@abigail.blackend.org> Mail-Followup-To: Anish Mistry , freebsd-stable@freebsd.org References: <200710171228.39123.mistry.7@osu.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <200710171228.39123.mistry.7@osu.edu> X-Useless-Header: blackend.org X-Operating-System: FreeBSD 4.11-STABLE User-Agent: Mutt/1.5.9i Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 jerky mouse and skipping sound X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 05:50:35 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 17, 2007 at 12:28:30PM -0400, Anish Mistry wrote: > I just updated to RELENG_7 from 6.2 and I'm running into some really=20 > annoying issues with jerky mouse movement and skipping sound. This=20 > seems to be similar to: > Re: SCHED_4BSD in RELENG_7 disturbs workflow > This happens both with 4BSD and ULE. >=20 > I seems to happen when I'm compiling ports and a new cc/bzip2/sh=20 > process fires off (I'm just watching top), I'll get the=20 > skip/freezeup. [...] Using ULE and UP kernel (i.e. without SMP etc.) helped a bit the things but it's still very annoying to use firefox during ports build. I see this lag/freeze on all boxes I use with 7.0, but it's true that with a fast machine people can ignore the problem, it's less obvious than with a 1GHz box for example. --=20 Marc --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFHFvFdzQ9RwE+OdOgRAg5jAJ98x03LZb0x4TFdbc5X4XVaMi1a1ACgygyZ obkwVW7m+hmLYIYoDTPxGA4= =9tD2 -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 09:29:19 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18FFB16A420 for ; Thu, 18 Oct 2007 09:29:19 +0000 (UTC) (envelope-from wangyi6854@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id E136313C4C8 for ; Thu, 18 Oct 2007 09:29:18 +0000 (UTC) (envelope-from wangyi6854@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so135145waf for ; Thu, 18 Oct 2007 02:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=/MDv/ZNH1uiyh4+1vcb2uMVSZk9Jv3/AGUnOqzBD5i8=; b=EQQVi513fdz2Eok3DWdxF4cfCIhJgqWgY4BtLce/zSzenSsqzE7buIKH59oS/TizTI241ivyvVCK8VOw+GSMil6Awjwm9rMMippSOJkrAv+oj190SEPaWouArzf7E2Q3hudR3m5rUplau2CwnWEeygQ6No1SC62A3yzD2wsQwm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ozj4TkoR0et2zfZNJK8RZiyO8+l0ad4Q2KP5Q1FMWDlg+J7RJjQZ5DEUylMfiSjN6dyTwbBHyvA6NNkN1Qvrd653bqUTCClK7pCad/wSBa6PD3LaOAOPj+TQChoFGhGkszNa0r8jvxt2zm5ogRLOYa4MKix+jYAPLtdh+UGS1q0= Received: by 10.115.17.1 with SMTP id u1mr371601wai.1192698109680; Thu, 18 Oct 2007 02:01:49 -0700 (PDT) Received: by 10.114.203.13 with HTTP; Thu, 18 Oct 2007 02:01:49 -0700 (PDT) Message-ID: <5ea5cca50710180201v3b592b1ayc35f0b271b9929ab@mail.gmail.com> Date: Thu, 18 Oct 2007 02:01:49 -0700 From: "Yi Wang" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_261_29948102.1192698109673" Subject: connection timed out on freebsd 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 09:29:19 -0000 ------=_Part_261_29948102.1192698109673 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, My box is running FreeBSD 7.0 ( upgrade from 6-stable using src ). My problem is I can't connect to the network outside the router. eg. www.FreeBSD.org. Neither http nor ftp. But I can ping them. I can assure you that DNS works fine and the firewall is turned off. Here's some diagnostic messages: # uname -a FreeBSD wangyi.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #2: Wed Oct 17 19:19:47 CST 2007 root@wangyi.com:/usr/obj/usr/src/sys/MYKERNEL i386 # ifconfig -a le0: flags=8843 metric 0 mtu 1500 options=8 ether 00:0c:29:3c:47:47 inet 172.20.53.106 netmask 0xffffff00 broadcast 172.20.53.255 inet 192.168.0.106 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect status: active lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 vmnet1: flags=8843 metric 0 mtu 1500 ether 00:bd:e4:45:00:01 inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 PS: This is the result in vmware. I made a dual boot system and run it in vmware using raw disk. Actually, the real interface is nfe0. Sorry for my poor English. Thanks very much! -- Regards, Wang Yi ------=_Part_261_29948102.1192698109673 Content-Type: text/plain; name=dig.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_f7xxrwpj Content-Disposition: attachment; filename=dig.txt CjsgPDw+PiBEaUcgOS40LjEtUDEgPDw+PiB3d3cuZ29vZ2xlLmNvbQo7OyBnbG9iYWwgb3B0aW9u czogIHByaW50Y21kCjs7IEdvdCBhbnN3ZXI6Cjs7IC0+PkhFQURFUjw8LSBvcGNvZGU6IFFVRVJZ LCBzdGF0dXM6IE5PRVJST1IsIGlkOiAyMjE1NQo7OyBmbGFnczogcXIgcmQgcmE7IFFVRVJZOiAx LCBBTlNXRVI6IDMsIEFVVEhPUklUWTogNywgQURESVRJT05BTDogMAoKOzsgUVVFU1RJT04gU0VD VElPTjoKO3d3dy5nb29nbGUuY29tLgkJCUlOCUEKCjs7IEFOU1dFUiBTRUNUSU9OOgp3d3cuZ29v Z2xlLmNvbS4JCTYwNDc4NAlJTglDTkFNRQl3d3cubC5nb29nbGUuY29tLgp3d3cubC5nb29nbGUu Y29tLgk1ODYJSU4JQ05BTUUJd3d3LWNoaW5hLmwuZ29vZ2xlLmNvbS4Kd3d3LWNoaW5hLmwuZ29v Z2xlLmNvbS4JNQlJTglBCTY2LjI0OS44OS4xNDcKCjs7IEFVVEhPUklUWSBTRUNUSU9OOgpsLmdv b2dsZS5jb20uCQk4NjM4NQlJTglOUwlhLmwuZ29vZ2xlLmNvbS4KbC5nb29nbGUuY29tLgkJODYz ODUJSU4JTlMJZi5sLmdvb2dsZS5jb20uCmwuZ29vZ2xlLmNvbS4JCTg2Mzg1CUlOCU5TCWUubC5n b29nbGUuY29tLgpsLmdvb2dsZS5jb20uCQk4NjM4NQlJTglOUwlnLmwuZ29vZ2xlLmNvbS4KbC5n b29nbGUuY29tLgkJODYzODUJSU4JTlMJYy5sLmdvb2dsZS5jb20uCmwuZ29vZ2xlLmNvbS4JCTg2 Mzg1CUlOCU5TCWQubC5nb29nbGUuY29tLgpsLmdvb2dsZS5jb20uCQk4NjM4NQlJTglOUwliLmwu Z29vZ2xlLmNvbS4KCjs7IFF1ZXJ5IHRpbWU6IDYzNiBtc2VjCjs7IFNFUlZFUjogMTI3LjAuMC4x IzUzKDEyNy4wLjAuMSkKOzsgV0hFTjogVGh1IE9jdCAxOCAxNToxODo1NyAyMDA3Cjs7IE1TRyBT SVpFICByY3ZkOiAyMDQKCg== ------=_Part_261_29948102.1192698109673 Content-Type: text/plain; name=dmesg.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_f7xxs8zp Content-Disposition: attachment; filename=dmesg.txt Q29weXJpZ2h0IChjKSAxOTkyLTIwMDcgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA3LjAtUFJFUkVMRUFTRSAjMjogV2VkIE9jdCAxNyAx OToxOTo0NyBDU1QgMjAwNwogICAgcm9vdEB3YW5neWkuY29tOi91c3Ivb2JqL3Vzci9zcmMvc3lz L01ZS0VSTkVMClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0 eSAwCkNQVTogQU1EIFNlbXByb24odG0pIFByb2Nlc3NvciAzMDAwKyAoMTY2My41NC1NSHogNjg2 LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiQXV0aGVudGljQU1EIiAgSWQgPSAweDQwZmYyICBTdGVw cGluZyA9IDIKICBGZWF0dXJlcz0weDc4YmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUs TUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVTSCxNTVgs RlhTUixTU0UsU1NFMj4KICBGZWF0dXJlczI9MHgyMDAxPFNTRTMsQ1gxNj4KICBBTUQgRmVhdHVy ZXM9MHhlYTUwMDgwMDxTWVNDQUxMLE5YLE1NWCssRkZYU1IsUkRUU0NQLExNLDNETm93ISssM0RO b3chPgogIEFNRCBGZWF0dXJlczI9MHgxPExBSEY+CnJlYWwgbWVtb3J5ICA9IDI2ODQzNTQ1NiAo MjU2IE1CKQphdmFpbCBtZW1vcnkgPSAyNDQ2NjIyNzIgKDIzMyBNQikKYWNwaTA6IDxQVExURCAg IFJTRFQ+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBbSVRIUkVBRF0KYWNwaTA6IFBvd2VyIEJ1dHRv biAoZml4ZWQpClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1 YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9y dCAweDEwMDgtMHgxMDBiIG9uIGFjcGkwCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKYWNwaV90 aHJvdHRsZTA6IDxBQ1BJIENQVSBUaHJvdHRsaW5nPiBvbiBjcHUwCnBjaWIwOiA8QUNQSSBIb3N0 LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJIGJ1 cz4gb24gcGNpYjAKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9u IHBjaTAKcGNpMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEKaXNhYjA6IDxQQ0ktSVNBIGJyaWRn ZT4gYXQgZGV2aWNlIDcuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFwY2kw OiA8SW50ZWwgUElJWDQgVURNQTMzIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYs MHgxNzAtMHgxNzcsMHgzNzYsMHgxMDUwLTB4MTA1ZiBhdCBkZXZpY2UgNy4xIG9uIHBjaTAKYXRh MDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTAKYXRhMDogW0lUSFJFQURdCmF0YTE6IDxBVEEg Y2hhbm5lbCAxPiBvbiBhdGFwY2kwCmF0YTE6IFtJVEhSRUFEXQpwY2kwOiA8YnJpZGdlPiBhdCBk ZXZpY2UgNy4zIChubyBkcml2ZXIgYXR0YWNoZWQpCnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBk aXNwbGF5PiBwb3J0IDB4MTA2MC0weDEwNmYgbWVtIDB4ZjAwMDAwMDAtMHhmN2ZmZmZmZiwweGU4 MDAwMDAwLTB4ZTg3ZmZmZmYgYXQgZGV2aWNlIDE1LjAgb24gcGNpMApwY2kwOiA8bWFzcyBzdG9y YWdlLCBTQ1NJPiBhdCBkZXZpY2UgMTYuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpsZTA6IDxBTUQg UENuZXQtUENJPiBwb3J0IDB4MTQwMC0weDE0N2YgaXJxIDExIGF0IGRldmljZSAxNy4wIG9uIHBj aTAKbGUwOiAxNiByZWNlaXZlIGJ1ZmZlcnMsIDQgdHJhbnNtaXQgYnVmZmVycwpsZTA6IEV0aGVy bmV0IGFkZHJlc3M6IDAwOjBjOjI5OjNjOjQ3OjQ3CmxlMDogW0lUSFJFQURdCmFjcGlfYWNhZDA6 IDxBQyBBZGFwdGVyPiBvbiBhY3BpMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgw NDIpPiBwb3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4g aXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmF0 a2JkMDogW0lUSFJFQURdCnBtdGltZXIwIG9uIGlzYTAKb3JtMDogPElTQSBPcHRpb24gUk9Ncz4g YXQgaW9tZW0gMHhjMDAwMC0weGM3ZmZmLDB4YzgwMDAtMHhjOGZmZiwweGRjMDAwLTB4ZGZmZmYs MHhlMDAwMC0weGUzZmZmIHBucGlkIE9STTAwMDAgb24gaXNhMApzYzA6IDxTeXN0ZW0gY29uc29s ZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywg ZmxhZ3M9MHgzMDA+CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYg aW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5 IDE2NjM1NDExNTkgSHogcXVhbGl0eSA4MDAKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAg bXNlYwphZDA6IDc2MjkzTUIgPFZNd2FyZSBWaXJ0dWFsIElERSBIYXJkIERyaXZlIDAwMDAwMDAx PiBhdCBhdGEwLW1hc3RlciBVRE1BMzMKYWNkMDogQ0RST00gPFZNd2FyZSBWaXJ0dWFsIElERSBD RFJPTSBEcml2ZS8wMDAwMDAwMT4gYXQgYXRhMS1tYXN0ZXIgVURNQTMzClRyeWluZyB0byBtb3Vu dCByb290IGZyb20gdWZzOi9kZXYvYWQwczJhCmxpbmtfZWxmOiBzeW1ib2wgbXNsZWVwIHVuZGVm aW5lZAp2bW5ldDE6IEV0aGVybmV0IGFkZHJlc3M6IDAwOmJkOmU0OjQ1OjAwOjAxCmxpbmtfZWxm OiBzeW1ib2wgbXNsZWVwIHVuZGVmaW5lZAo= ------=_Part_261_29948102.1192698109673-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 12:56:57 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97C4F16A41A for ; Thu, 18 Oct 2007 12:56:57 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5ADDC13C459 for ; Thu, 18 Oct 2007 12:56:57 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 7D76E3932A; Thu, 18 Oct 2007 15:56:55 +0300 (EEST) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84433-07; Thu, 18 Oct 2007 15:56:53 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id D6D4C38FF4; Thu, 18 Oct 2007 15:56:53 +0300 (EEST) Message-ID: <47175812.2070300@bulinfo.net> Date: Thu, 18 Oct 2007 15:56:50 +0300 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.6 (X11/20070927) MIME-Version: 1.0 To: Yi Wang References: <5ea5cca50710180201v3b592b1ayc35f0b271b9929ab@mail.gmail.com> In-Reply-To: <5ea5cca50710180201v3b592b1ayc35f0b271b9929ab@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: freebsd-stable@freebsd.org Subject: Re: connection timed out on freebsd 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 12:56:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, try 'sysctl -w net.inet.tcp.rfc1323=0' Yi Wang wrote: > Hi, > > My box is running FreeBSD 7.0 ( upgrade from 6-stable using src ). > > My problem is I can't connect to the network outside the router. eg. > www.FreeBSD.org. Neither http nor ftp. But I can ping them. I can > assure you that DNS works fine and the firewall is turned off. > > Here's some diagnostic messages: > > # uname -a > FreeBSD wangyi.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #2: Wed Oct > 17 19:19:47 CST 2007 root@wangyi.com:/usr/obj/usr/src/sys/MYKERNEL > i386 > > # ifconfig -a > le0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:0c:29:3c:47:47 > inet 172.20.53.106 netmask 0xffffff00 broadcast 172.20.53.255 > inet 192.168.0.106 netmask 0xffffff00 broadcast 192.168.0.255 > media: Ethernet autoselect > status: active > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > vmnet1: flags=8843 metric 0 mtu 1500 > ether 00:bd:e4:45:00:01 > inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 > > PS: This is the result in vmware. I made a dual boot system and run it > in vmware using raw disk. > Actually, the real interface is nfe0. > > Sorry for my poor English. > > Thanks very much! > > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHF1gSxJBWvpalMpkRAoVCAJ4juoD3kby8FNCEbGgkmZuc6RR5PQCgrC9U nXUi2Gp0mEVotL+akuWJ3vc= =DqJH -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 13:27:16 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB9DD16A418 for ; Thu, 18 Oct 2007 13:27:16 +0000 (UTC) (envelope-from hatchan@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id DDE7713C459 for ; Thu, 18 Oct 2007 13:27:15 +0000 (UTC) (envelope-from hatchan@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so199378waf for ; Thu, 18 Oct 2007 06:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=WxlIZmQdTk83kY+CjZ4PxG1t2PaFVlBc5fV+r/nkqzE=; b=PSUixI6iih4qxrTWExd0P12VmchFYqrAIN7kpexMyKY3Biv24j6RcpGZu7DvvIJxnm2nxrqZdUO1SSxT2PD/QpUsCMuJqaNmmxnjb5N4s83Tr5F5Tl2n11SG4fDwOXKvGq0pto8cwLEDoSr+Oaj8SsUOY1lay8vwjSGxRuqHRr0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=jFoaa4YIb6uIRxdldh8hj63cjapj0EvyMDQujNqkMBKKkCo1qHeILxNLbK18c03aYGRcma2WslIsauclx044WKM8JZkGV1NE/DvERabGsW8CNtsNK+otulikCh0IJa30waHJrLBQUSrkvcayCpCNvOjxNBNvx95Pmw9/aFzPzRA= Received: by 10.115.58.1 with SMTP id l1mr594481wak.1192712334653; Thu, 18 Oct 2007 05:58:54 -0700 (PDT) Received: by 10.114.145.15 with HTTP; Thu, 18 Oct 2007 05:58:54 -0700 (PDT) Message-ID: Date: Thu, 18 Oct 2007 14:58:54 +0200 From: Benno Sender: hatchan@gmail.com To: "Yi Wang" In-Reply-To: <5ea5cca50710180201v3b592b1ayc35f0b271b9929ab@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5ea5cca50710180201v3b592b1ayc35f0b271b9929ab@mail.gmail.com> X-Google-Sender-Auth: 1d255a5492ab58c0 Cc: freebsd-stable@freebsd.org Subject: Re: connection timed out on freebsd 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 13:27:16 -0000 On 10/18/07, Yi Wang wrote: > Hi, > > My box is running FreeBSD 7.0 ( upgrade from 6-stable using src ). > > My problem is I can't connect to the network outside the router. eg. > www.FreeBSD.org. Neither http nor ftp. But I can ping them. I can > assure you that DNS works fine and the firewall is turned off. > > Here's some diagnostic messages: > > # uname -a > FreeBSD wangyi.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #2: Wed Oct > 17 19:19:47 CST 2007 root@wangyi.com:/usr/obj/usr/src/sys/MYKERNEL > i386 > > # ifconfig -a > le0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:0c:29:3c:47:47 > inet 172.20.53.106 netmask 0xffffff00 broadcast 172.20.53.255 > inet 192.168.0.106 netmask 0xffffff00 broadcast 192.168.0.255 > media: Ethernet autoselect > status: active > lo0: flags=8049 metric 0 mtu 16384 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet6 ::1 prefixlen 128 > inet 127.0.0.1 netmask 0xff000000 > vmnet1: flags=8843 metric 0 mtu 1500 > ether 00:bd:e4:45:00:01 > inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 > > PS: This is the result in vmware. I made a dual boot system and run it > in vmware using raw disk. > Actually, the real interface is nfe0. > > Sorry for my poor English. > > Thanks very much! > > -- > Regards, > Wang Yi > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > Hi, Have you setup your default route? check 'netstat -r', if you haven't use 'route add default ' -- Benno From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 13:56:48 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 144B416A417 for ; Thu, 18 Oct 2007 13:56:48 +0000 (UTC) (envelope-from decibel@decibel.org) Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by mx1.freebsd.org (Postfix) with ESMTP id B2C5F13C448 for ; Thu, 18 Oct 2007 13:56:47 +0000 (UTC) (envelope-from decibel@decibel.org) Received: from [172.16.31.102] (vpn.cashnetusa.com [38.98.147.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by noel.decibel.org (Postfix) with ESMTP id BF349564B1; Thu, 18 Oct 2007 13:56:44 +0000 (UTC) In-Reply-To: <20071010201049.688b1658.torfinn.ingolfsen@broadpark.no> References: <20071010201049.688b1658.torfinn.ingolfsen@broadpark.no> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Decibel! Date: Thu, 18 Oct 2007 08:56:30 -0500 To: Torfinn Ingolfsen X-Mailer: Apple Mail (2.752.3) Cc: freebsd-stable@freebsd.org Subject: Re: Unable to build devel/viewvc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 13:56:48 -0000 On Oct 10, 2007, at 1:10 PM, Torfinn Ingolfsen wrote: > On Wed, 10 Oct 2007 11:10:48 -0500 > Decibel! wrote: > >> Asked a while ago on -ports with no response... does anyone have any >> ideas on this? >> >> BTW, this is 6.1-RELEASE-p10, and a port checkout as of last night. > > Hard to tell, it compiles and installs here: > root@kg-work# pv | grep viewvc > viewvc-1.0.4 = up-to-date with port > root@kg-work# pv | grep pyth > python25-2.5.1 = up-to-date with port > subversion-python-1.4.4_1 = up-to-date with port > > "Here" is -stable: > root@kg-work# uname -a > FreeBSD kg-work.kg4.no 6.2-STABLE FreeBSD 6.2-STABLE #4: Tue Jun 19 > 17:47:13 CEST 2007 root@kg-work.kg4.no:/usr/obj/usr/src/sys/ > SS51G i386 > > Perhaps you have something in /etc/make.conf that shouldn't be there? The only thing in /etc/make.conf that I could *possibly* see affecting this is: .if ${.CURDIR:M*/devel/subversion*} WITH_APACHE2_APR=YES \ WITH_SVNSERVE_WRAPPER=YES \ WITH_PYTHON=YES \ WITH_PERL=YES .endif BTW, I also can't build viewvc by hand on the machine, so it's not just a ports issue... -- Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 14:07:23 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB3AD16A41A for ; Thu, 18 Oct 2007 14:07:23 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7CBAE13C467 for ; Thu, 18 Oct 2007 14:07:23 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IiW1w-0005cb-EN for freebsd-stable@freebsd.org; Thu, 18 Oct 2007 14:07:20 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Oct 2007 14:07:20 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Oct 2007 14:07:20 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 18 Oct 2007 16:08:09 +0200 Lines: 28 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20070801) Sender: news Subject: Mounting smbfs as user? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 14:07:23 -0000 Hi, I'm trying to implement smbfs mounting by regular non-root users and I can't make any progress. vfs.usermount is set to 1. When I try mounting a remote file system, this is what I get: > mount_smbfs -I server //user@server/pre mt Warning: no cfg file(s) found. mount_smbfs: can not setup kernel iconv table (ISO8859-1:tolower): syserr = Operation not permitted The same command works under root, and the appropriate klds are loaded: > kldstat Id Refs Address Size Name 1 15 0xc0400000 6d599c kernel 2 1 0xc0ad6000 169fc geom_raid3.ko 3 1 0xc0aed000 2464 accf_http.ko 4 1 0xc0af0000 653f4 acpi.ko 5 1 0xc0b56000 972c dummynet.ko 6 1 0xc0b60000 23c64 smbfs.ko 7 3 0xc0b84000 49f4 libiconv.ko 8 3 0xc0b89000 2c2c libmchain.ko 9 1 0xc5107000 4000 nullfs.ko 10 1 0xc5165000 1a000 linux.ko Any ideas? From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 14:17:45 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9A7316A417 for ; Thu, 18 Oct 2007 14:17:45 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 6E55413C448 for ; Thu, 18 Oct 2007 14:17:45 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id AC7D063C0E; Thu, 18 Oct 2007 17:17:43 +0300 (EEST) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91757-07; Thu, 18 Oct 2007 17:17:43 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id DF40663BF1; Thu, 18 Oct 2007 17:17:42 +0300 (EEST) Message-ID: <47176B03.1050402@bulinfo.net> Date: Thu, 18 Oct 2007 17:17:39 +0300 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.6 (X11/20070927) MIME-Version: 1.0 To: Ivan Voras References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: freebsd-stable@freebsd.org Subject: Re: Mounting smbfs as user? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 14:17:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Ivan Voras wrote: > Hi, > > I'm trying to implement smbfs mounting by regular non-root users and I > can't make any progress. vfs.usermount is set to 1. > > When I try mounting a remote file system, this is what I get: > >> mount_smbfs -I server //user@server/pre mt > Warning: no cfg file(s) found. > mount_smbfs: can not setup kernel iconv table (ISO8859-1:tolower): > syserr = Operation not permitted > > The same command works under root, and the appropriate klds are loaded: Only superuser can load modules. If you try to load module by regular user you will get: kldload: can't load xxxx.ko: Operation not permitted > >> kldstat > Id Refs Address Size Name > 1 15 0xc0400000 6d599c kernel > 2 1 0xc0ad6000 169fc geom_raid3.ko > 3 1 0xc0aed000 2464 accf_http.ko > 4 1 0xc0af0000 653f4 acpi.ko > 5 1 0xc0b56000 972c dummynet.ko > 6 1 0xc0b60000 23c64 smbfs.ko > 7 3 0xc0b84000 49f4 libiconv.ko > 8 3 0xc0b89000 2c2c libmchain.ko > 9 1 0xc5107000 4000 nullfs.ko > 10 1 0xc5165000 1a000 linux.ko > > Any ideas? > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHF2sDxJBWvpalMpkRAkoDAJ4vnIc8qx7cxdtBvirv/5y5E+UTPwCfTIlG oYuiOLhWpiX198tgfOSBrsE= =uth8 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 14:28:57 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58B7616A417 for ; Thu, 18 Oct 2007 14:28:57 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 19D7013C45D for ; Thu, 18 Oct 2007 14:28:56 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IiWMi-0000pe-SE for freebsd-stable@freebsd.org; Thu, 18 Oct 2007 14:28:48 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Oct 2007 14:28:48 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Oct 2007 14:28:48 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 18 Oct 2007 16:29:30 +0200 Lines: 14 Message-ID: References: <47176B03.1050402@bulinfo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20070801) In-Reply-To: <47176B03.1050402@bulinfo.net> Sender: news Subject: Re: Mounting smbfs as user? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 14:28:57 -0000 Krassimir Slavchev wrote: > Hi, > > Ivan Voras wrote: >> The same command works under root, and the appropriate klds are loaded: > > Only superuser can load modules. If you try to load module by regular > user you will get: kldload: can't load xxxx.ko: Operation not permitted To clarify: the modules were loaded before I tried either as user or as root. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 15:25:53 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A05B616A49C for ; Thu, 18 Oct 2007 15:25:53 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:1f1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 10C8F13C46E for ; Thu, 18 Oct 2007 15:25:52 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from prawn.unsane.co.uk (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id l9IFQGSZ095198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2007 16:26:17 +0100 (BST) (envelope-from jhary@unsane.co.uk) Message-ID: <47177AFB.6020103@unsane.co.uk> Date: Thu, 18 Oct 2007 16:25:47 +0100 From: Vince User-Agent: Thunderbird 2.0.0.6 (X11/20070816) MIME-Version: 1.0 To: Krassimir Slavchev References: <5ea5cca50710180201v3b592b1ayc35f0b271b9929ab@mail.gmail.com> <47175812.2070300@bulinfo.net> In-Reply-To: <47175812.2070300@bulinfo.net> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Yi Wang , freebsd-stable@freebsd.org Subject: Re: connection timed out on freebsd 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 15:25:53 -0000 Krassimir Slavchev wrote: > Hi, > > try 'sysctl -w net.inet.tcp.rfc1323=0' > Thanks for that, I was having issues connecting to www.freebsd.org from a 7.0-PRERELEASE box and this fixed it for me. Vince > > Yi Wang wrote: >> Hi, > >> My box is running FreeBSD 7.0 ( upgrade from 6-stable using src ). > >> My problem is I can't connect to the network outside the router. eg. >> www.FreeBSD.org. Neither http nor ftp. But I can ping them. I can >> assure you that DNS works fine and the firewall is turned off. > >> Here's some diagnostic messages: > >> # uname -a >> FreeBSD wangyi.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #2: Wed Oct >> 17 19:19:47 CST 2007 root@wangyi.com:/usr/obj/usr/src/sys/MYKERNEL >> i386 > >> # ifconfig -a >> le0: flags=8843 metric 0 mtu 1500 >> options=8 >> ether 00:0c:29:3c:47:47 >> inet 172.20.53.106 netmask 0xffffff00 broadcast 172.20.53.255 >> inet 192.168.0.106 netmask 0xffffff00 broadcast 192.168.0.255 >> media: Ethernet autoselect >> status: active >> lo0: flags=8049 metric 0 mtu 16384 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >> inet6 ::1 prefixlen 128 >> inet 127.0.0.1 netmask 0xff000000 >> vmnet1: flags=8843 metric 0 mtu 1500 >> ether 00:bd:e4:45:00:01 >> inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 > >> PS: This is the result in vmware. I made a dual boot system and run it >> in vmware using raw disk. >> Actually, the real interface is nfe0. > >> Sorry for my poor English. > >> Thanks very much! > > > >> ------------------------------------------------------------------------ > >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 15:28:18 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 095C916A421 for ; Thu, 18 Oct 2007 15:28:18 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.freebsd.org (Postfix) with ESMTP id ACC4C13C468 for ; Thu, 18 Oct 2007 15:28:17 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (adsl-68-252-59-152.dsl.wotnoh.ameritech.net [68.252.59.152]) (authenticated bits=0) by mail.united-ware.com (8.13.8/8.13.8) with ESMTP id l9IFURFp009781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2007 11:30:28 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-stable@freebsd.org Date: Thu, 18 Oct 2007 11:31:52 -0400 User-Agent: KMail/1.9.6 References: <200710171228.39123.mistry.7@osu.edu> <20071018053839.GA25417@abigail.blackend.org> In-Reply-To: <20071018053839.GA25417@abigail.blackend.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2512805.BnsKSZgMUf"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200710181132.00669.mistry.7@osu.edu> Cc: Subject: Re: RELENG_7 jerky mouse and skipping sound X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 15:28:18 -0000 --nextPart2512805.BnsKSZgMUf Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 18 October 2007, Marc Fonvieille wrote: > On Wed, Oct 17, 2007 at 12:28:30PM -0400, Anish Mistry wrote: > > I just updated to RELENG_7 from 6.2 and I'm running into some > > really annoying issues with jerky mouse movement and skipping > > sound. This seems to be similar to: > > Re: SCHED_4BSD in RELENG_7 disturbs workflow > > This happens both with 4BSD and ULE. > > > > I seems to happen when I'm compiling ports and a new cc/bzip2/sh > > process fires off (I'm just watching top), I'll get the > > skip/freezeup. > > [...] > > Using ULE and UP kernel (i.e. without SMP etc.) helped a bit the > things but it's still very annoying to use firefox during ports > build. I see this lag/freeze on all boxes I use with 7.0, but it's > true that with a fast machine people can ignore the problem, it's > less obvious than with a 1GHz box for example. Yeah, I'm still seeing this behavior. Does anyone have suggestions on=20 debugging? Thanks, =2D-=20 Anish Mistry --nextPart2512805.BnsKSZgMUf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHF3xwxqA5ziudZT0RApVbAKCjf6JxWMrina3+OKSzgFmu4GnBPQCgqvZG xvn8OdXlYQ9v24T4Brab7VM= =Fv4D -----END PGP SIGNATURE----- --nextPart2512805.BnsKSZgMUf-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 15:38:12 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2807D16A47C for ; Thu, 18 Oct 2007 15:38:12 +0000 (UTC) (envelope-from jacardenasm@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by mx1.freebsd.org (Postfix) with ESMTP id D7BE013C4BC for ; Thu, 18 Oct 2007 15:38:09 +0000 (UTC) (envelope-from jacardenasm@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so171980wra for ; Thu, 18 Oct 2007 08:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=U44N9oLwk6LTzLc08ZLEol+X0+lkJMr5ZeBwiy0PqME=; b=S3VPOlPq0fNibI0ZBNQyc71J3F0Nnfg9DWRz5mbKOAsSLdMUCixDHzr48ekiblQ64RpyI8FpLnyO326Xo1UEZpsMf35A/FmyT7RkdGljw9orBjmQvewncep/OAhwueoaW/9kD6YzKM/3HfOplfxWjdkYjBNksZ/IsbpzQc9BxN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=T6JfOigYjQWFNC2GM6b38wWp3sPeUQxhpZ/6dhpzsaFdA6HGjvHWJxWuwlK/RgiBDVWPHXAgUIx0NGNs5dcwhjodd+9aqTsCffTvu6XGtrgBsDeHeANnaPMCn81tG/G9QMoOmLZyCHXkgJrVZRF2KUDWAaXWWhKrQvN4V1bGnC4= Received: by 10.114.78.1 with SMTP id a1mr815469wab.1192721887016; Thu, 18 Oct 2007 08:38:07 -0700 (PDT) Received: by 10.115.16.3 with HTTP; Thu, 18 Oct 2007 08:38:01 -0700 (PDT) Message-ID: <7c58fcfc0710180838keb742acv91799d1d68aa5c19@mail.gmail.com> Date: Thu, 18 Oct 2007 10:38:01 -0500 From: "Jose Alonso Cardenas Marquez" To: "Doug Barton" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7c58fcfc0710161455t20792d7dqa349ff157674048d@mail.gmail.com> Cc: jkh@freebsd.org, stable@freebsd.org, ache@freebsd.org Subject: Re: Call for Testers: dialog 1.1-20070930 update X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 15:38:12 -0000 2007/10/17, Doug Barton : > On Tue, 16 Oct 2007, Jose Alonso Cardenas Marquez wrote: > Hi :) > This is a great project, thanks for taking this on! I tried to test your > patches on my -current box, and they don't apply cleanly: > > find . -name \*.rej > ./libdialog/dialog.3.rej > ./libdialog/dialog.h.rej > ./Makefile.rej > ./inputbox.c.rej > > find . -name \*.rej > ./dialog/dialog.c.rej > ./Makefile.rej > > If you can make some patches against HEAD I'd be glad to give them a try, > but I lack the time to integrate them myself right now. > Done, could you see again? Greetings ACM From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 15:54:01 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19A1B16A41A for ; Thu, 18 Oct 2007 15:54:01 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id EDB6313C457 for ; Thu, 18 Oct 2007 15:53:59 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 18 Oct 2007 15:53:58 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp002) with SMTP; 18 Oct 2007 17:53:58 +0200 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX18KgCVo7e4KdKw3XSQbBzpDGAh/eecmu9MTD94tNm uc064NS/n1GLNK Message-ID: <4717818B.5020503@gmx.de> Date: Thu, 18 Oct 2007 17:53:47 +0200 From: "[LoN]Kamikaze" User-Agent: Thunderbird 2.0.0.6 (X11/20071015) MIME-Version: 1.0 To: Anish Mistry References: <200710171228.39123.mistry.7@osu.edu> <20071018053839.GA25417@abigail.blackend.org> <200710181132.00669.mistry.7@osu.edu> In-Reply-To: <200710181132.00669.mistry.7@osu.edu> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 jerky mouse and skipping sound X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 15:54:01 -0000 Anish Mistry wrote: > On Thursday 18 October 2007, Marc Fonvieille wrote: >> On Wed, Oct 17, 2007 at 12:28:30PM -0400, Anish Mistry wrote: >>> I just updated to RELENG_7 from 6.2 and I'm running into some >>> really annoying issues with jerky mouse movement and skipping >>> sound. This seems to be similar to: >>> Re: SCHED_4BSD in RELENG_7 disturbs workflow >>> This happens both with 4BSD and ULE. >>> >>> I seems to happen when I'm compiling ports and a new cc/bzip2/sh >>> process fires off (I'm just watching top), I'll get the >>> skip/freezeup. >> [...] >> >> Using ULE and UP kernel (i.e. without SMP etc.) helped a bit the >> things but it's still very annoying to use firefox during ports >> build. I see this lag/freeze on all boxes I use with 7.0, but it's >> true that with a fast machine people can ignore the problem, it's >> less obvious than with a 1GHz box for example. > Yeah, I'm still seeing this behavior. Does anyone have suggestions on > debugging? > > Thanks, > I did post the solution in this thread. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 16:10:57 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E21816A418 for ; Thu, 18 Oct 2007 16:10:57 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.247]) by mx1.freebsd.org (Postfix) with ESMTP id 3FDF913C442 for ; Thu, 18 Oct 2007 16:10:56 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by ag-out-0708.google.com with SMTP id 35so535996aga for ; Thu, 18 Oct 2007 09:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9kdaaP545Us3j+j3gCkBLU54Q3Ta3cXhME8FxeX+Nic=; b=VxzI5VL76RPfxHt0w7RiXeHEzKfgm6+qBNOqbPylxMRj23lroUn1X3brRzCCjkKRvSN5bhDt5ZMKapRoAA1nrsO/qLSVpjNtL/sp4yBBi2zod14ifudW8iV+DFHx/L93j49ILWf16/Y5XWvvBQw4QJaBF7osB1aHxnlzoH+5E4M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rHB0diF5RmmpdFzcv4N1FIWwds3NfT1yecx+LOAC3EYaZkqvphJyoGkbWifEGyH3XX/Iah4bRHkwqeg6jtPmw2pKiUTFCt43SUZ5rZTMcmB/sZZJngleSLMlbhPCYdpTB8umZ54uM6t8WO0LFwqPznlNSBUoOHWVoepkIIVi+hw= Received: by 10.90.99.20 with SMTP id w20mr1229141agb.1192723856280; Thu, 18 Oct 2007 09:10:56 -0700 (PDT) Received: by 10.90.29.9 with HTTP; Thu, 18 Oct 2007 09:10:56 -0700 (PDT) Message-ID: <8cb6106e0710180910u110a1c58tc18f36460ab74776@mail.gmail.com> Date: Thu, 18 Oct 2007 12:10:56 -0400 From: "Josh Carroll" To: freebsd-stable@freebsd.org In-Reply-To: <8cb6106e0710170911x77e72e95qb322f51d84a31813@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8cb6106e0710170911x77e72e95qb322f51d84a31813@mail.gmail.com> Subject: Re: ULE vs. 4BSD in RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 16:10:57 -0000 > I have noticed some performance discrepancies with ULE and 4BSD in > RELENG_7, specifically with ffmpeg. I have all the kernel debugging > options disabled, and as I understand it, the userland debugging is > all off by default in RELENG_7. Here are a couple of additional benchmarks comparing the schedulers on my system: make -j8 -DNOCLEAN buildkernel 4BSD: 3:25.56 ULE: 3:39.20 Difference: -6.6 % ubench (CPU): 4BSD: 1705258 ULE: 1713510 Difference: +0.48 % super-smack (select-key 10 10000): 4BSD: 55044.38 ULE: 68085.21 Difference: +23.69 % super-smack (update-select 10 10000): 4BSD: 16734.15 ULE: 17631.43 Difference: +5.36 % So at least for the MySQL super-smack benchmark (I know it's a rather contrived benchmark), ULE is significantly faster for select-key and a decent improvement for update-select. ubench is about the same, but building a kernel is also slower with ULE. Was ULE tuned with MySQL in mind, without considering other workloads? Are there other benchmarks for "real" workloads I can run to compare (e.g. Apache benchmarks, etc)? I'd like to help in any way I can, so folks can choose the right scheduler for their usage model. Regards, Josh From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 16:48:39 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BD9816A41B for ; Thu, 18 Oct 2007 16:48:39 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.freebsd.org (Postfix) with ESMTP id 42A3D13C46E for ; Thu, 18 Oct 2007 16:48:38 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (adsl-68-252-59-152.dsl.wotnoh.ameritech.net [68.252.59.152]) (authenticated bits=0) by mail.united-ware.com (8.13.8/8.13.8) with ESMTP id l9IGon3x011123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2007 12:50:50 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: "[LoN]Kamikaze" Date: Thu, 18 Oct 2007 12:52:14 -0400 User-Agent: KMail/1.9.6 References: <200710171228.39123.mistry.7@osu.edu> <200710181132.00669.mistry.7@osu.edu> <4717818B.5020503@gmx.de> In-Reply-To: <4717818B.5020503@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1970840.ppNEKk2AnV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200710181252.21342.mistry.7@osu.edu> Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 jerky mouse and skipping sound X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 16:48:39 -0000 --nextPart1970840.ppNEKk2AnV Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 18 October 2007, [LoN]Kamikaze wrote: > Anish Mistry wrote: > > On Thursday 18 October 2007, Marc Fonvieille wrote: > >> On Wed, Oct 17, 2007 at 12:28:30PM -0400, Anish Mistry wrote: > >>> I just updated to RELENG_7 from 6.2 and I'm running into some > >>> really annoying issues with jerky mouse movement and skipping > >>> sound. This seems to be similar to: > >>> Re: SCHED_4BSD in RELENG_7 disturbs workflow > >>> This happens both with 4BSD and ULE. > >>> > >>> I seems to happen when I'm compiling ports and a new > >>> cc/bzip2/sh process fires off (I'm just watching top), I'll get > >>> the skip/freezeup. > >> > >> [...] > >> > >> Using ULE and UP kernel (i.e. without SMP etc.) helped a bit the > >> things but it's still very annoying to use firefox during ports > >> build. I see this lag/freeze on all boxes I use with 7.0, but > >> it's true that with a fast machine people can ignore the > >> problem, it's less obvious than with a 1GHz box for example. > > > > Yeah, I'm still seeing this behavior. Does anyone have > > suggestions on debugging? > > > > Thanks, > > I did post the solution in this thread. That doesn't solve the problem for me, so it seems that it's=20 unrelated. It's just not mouse and sound, everything freezes up for=20 a bit. =2D-=20 Anish Mistry --nextPart1970840.ppNEKk2AnV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHF49FxqA5ziudZT0RAn0RAJ9ohihKx47rtkp7hkIMOf9IplvJ6wCgrSZh BJY1jWWWV44YsG/Qfi8rA3A= =7MFD -----END PGP SIGNATURE----- --nextPart1970840.ppNEKk2AnV-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 17:14:08 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BE2B16A479 for ; Thu, 18 Oct 2007 17:14:08 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 37FB513C491 for ; Thu, 18 Oct 2007 17:14:06 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 18 Oct 2007 17:14:06 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp042) with SMTP; 18 Oct 2007 19:14:06 +0200 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX1+LET0vVRaLrQaqKsAy+EXZIW1eStCshCai/jDsxD jUsL5QaRc1R8kb Message-ID: <4717945D.1010900@gmx.de> Date: Thu, 18 Oct 2007 19:14:05 +0200 From: "[LoN]Kamikaze" User-Agent: Thunderbird 2.0.0.6 (X11/20071015) MIME-Version: 1.0 To: Anish Mistry References: <200710171228.39123.mistry.7@osu.edu> <200710181132.00669.mistry.7@osu.edu> <4717818B.5020503@gmx.de> <200710181252.21342.mistry.7@osu.edu> In-Reply-To: <200710181252.21342.mistry.7@osu.edu> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 jerky mouse and skipping sound X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 17:14:08 -0000 Anish Mistry wrote: > On Thursday 18 October 2007, [LoN]Kamikaze wrote: >> Anish Mistry wrote: >>> On Thursday 18 October 2007, Marc Fonvieille wrote: >>>> On Wed, Oct 17, 2007 at 12:28:30PM -0400, Anish Mistry wrote: >>>>> I just updated to RELENG_7 from 6.2 and I'm running into some >>>>> really annoying issues with jerky mouse movement and skipping >>>>> sound. This seems to be similar to: >>>>> Re: SCHED_4BSD in RELENG_7 disturbs workflow >>>>> This happens both with 4BSD and ULE. >>>>> >>>>> I seems to happen when I'm compiling ports and a new >>>>> cc/bzip2/sh process fires off (I'm just watching top), I'll get >>>>> the skip/freezeup. >>>> [...] >>>> >>>> Using ULE and UP kernel (i.e. without SMP etc.) helped a bit the >>>> things but it's still very annoying to use firefox during ports >>>> build. I see this lag/freeze on all boxes I use with 7.0, but >>>> it's true that with a fast machine people can ignore the >>>> problem, it's less obvious than with a 1GHz box for example. >>> Yeah, I'm still seeing this behavior. Does anyone have >>> suggestions on debugging? >>> >>> Thanks, >> I did post the solution in this thread. > That doesn't solve the problem for me, so it seems that it's > unrelated. It's just not mouse and sound, everything freezes up for > a bit. > Which suggested solution did you follow. Did you deactivate moused? Did you configure Xorg to use the mouse directly. For me also the whole system froze, but it did so because of the mouse. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 17:14:16 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B630E16A46E for ; Thu, 18 Oct 2007 17:14:16 +0000 (UTC) (envelope-from pj@smo.de) Received: from ilk.de (mx-out13.ilk.de [194.121.104.13]) by mx1.freebsd.org (Postfix) with ESMTP id 3A73F13C442 for ; Thu, 18 Oct 2007 17:14:15 +0000 (UTC) (envelope-from pj@smo.de) Received: from bologna.intern.smo.de (pool27.ka.ilk.net [212.86.194.27]) by ilk.de (8.13.4/8.13.4/ilk-relay) with ESMTP id l9IFj4ka032222 for ; Thu, 18 Oct 2007 17:45:04 +0200 Received: from [192.168.153.208] (herdubreid.intern.smo.de [192.168.153.208]) by bologna.intern.smo.de (8.13.8+Sun/8.13.8) with ESMTP id l9IFfCFP025714 for ; Thu, 18 Oct 2007 17:41:13 +0200 (CEST) Message-ID: <47177F6C.4060600@smo.de> Date: Thu, 18 Oct 2007 17:44:44 +0200 From: Philipp Ost User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070922 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: kldxref: file isn't dynamically-linked -- expected behaviour? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 17:14:16 -0000 Hi list, I'm currently upgrading from 6.2-STABLE (13 Oct. 2007) to RELENG_7. I did the following after csup'ing my sources: # make kernel-toolchain # make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=MYKERNEL # make -DALWAYS_CHECK_MAKE installkernel KERNCONF=MYKERNEL The last thing 'installkernel' reports is: [...] kldxref /boot/kernel kldxref: file isn't dynamically-linked [...] This message is repeated 514 times... ;-) Is this expected behaviour? Before I do a reboot I would like to make sure "everything works" as I rely on that particular machine. If needed I can provide full logs; MYKERNEL is a cut down version of GENERIC with atapicam, drm, radeondrm, sound added ;-) Thanks in advance for any hint/help! Regards, Philipp -- www.familie-ost.info/~pj From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 17:15:28 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C076816A4A0 for ; Thu, 18 Oct 2007 17:15:27 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by mx1.freebsd.org (Postfix) with ESMTP id 5D7DB13C510 for ; Thu, 18 Oct 2007 17:15:27 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from slackbox.xs4all.nl (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id l9IHFPhd066077; Thu, 18 Oct 2007 19:15:26 +0200 (CEST) (envelope-from rsmith@xs4all.nl) Received: by slackbox.xs4all.nl (Postfix, from userid 1001) id 58577B869; Thu, 18 Oct 2007 19:15:25 +0200 (CEST) Date: Thu, 18 Oct 2007 19:15:25 +0200 From: Roland Smith To: Ivan Voras Message-ID: <20071018171525.GA61376@slackbox.xs4all.nl> Mail-Followup-To: Ivan Voras , freebsd-stable@freebsd.org References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: X-GPG-Fingerprint: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 X-GPG-Key: http://www.xs4all.nl/~rsmith/pubkey.txt X-GPG-Notice: If this message is not signed, don't assume I sent it! User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org Subject: Re: Mounting smbfs as user? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 17:15:28 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 18, 2007 at 04:08:09PM +0200, Ivan Voras wrote: > Hi, >=20 > I'm trying to implement smbfs mounting by regular non-root users and I > can't make any progress. vfs.usermount is set to 1. >=20 > When I try mounting a remote file system, this is what I get: >=20 > > mount_smbfs -I server //user@server/pre mt > Warning: no cfg file(s) found. > mount_smbfs: can not setup kernel iconv table (ISO8859-1:tolower): > syserr =3D Operation not permitted >=20 > The same command works under root, and the appropriate klds are loaded: > Any ideas? The user in question probably needs read/write access to the /dev/smbX device in question. An elagant solution is to create a group called e.g. smbusers. All the users who need to mount an smb share should be added to this group. Then you have to add the following rule to your /etc/devfs.rules file; [local_ruleset=3D10] add path 'smb*' mode 0660 group smbusers The following then needs to be set in /etc/rc.conf. devfs_system_ruleset=3D"local_ruleset" Then reboot or re-start devfs and try again. Normally when mounting a drive as a normal user, the user in question needs to _own_ the mount point. I'm not sure if this applies to smb devices, but try it. Roland --=20 R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHF5StEnfvsMMhpyURAqG+AJ9PwB9UYZxgAr5WltKDhpNiG+FDpQCfbzIL CDxdLDW4c7fjV8cjM1Tg2Do= =IujG -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 17:34:58 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E41116A417 for ; Thu, 18 Oct 2007 17:34:58 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.freebsd.org (Postfix) with ESMTP id BD36A13C48D for ; Thu, 18 Oct 2007 17:34:57 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (adsl-68-252-59-152.dsl.wotnoh.ameritech.net [68.252.59.152]) (authenticated bits=0) by mail.united-ware.com (8.13.8/8.13.8) with ESMTP id l9IHatUq012325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2007 13:37:07 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: "[LoN]Kamikaze" Date: Thu, 18 Oct 2007 13:38:02 -0400 User-Agent: KMail/1.9.6 References: <200710171228.39123.mistry.7@osu.edu> <200710181252.21342.mistry.7@osu.edu> <4717945D.1010900@gmx.de> In-Reply-To: <4717945D.1010900@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1761421.ErfAHflSfN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200710181338.21275.mistry.7@osu.edu> Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 jerky mouse and skipping sound X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 17:34:58 -0000 --nextPart1761421.ErfAHflSfN Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 18 October 2007, [LoN]Kamikaze wrote: > Anish Mistry wrote: > > On Thursday 18 October 2007, [LoN]Kamikaze wrote: > >> Anish Mistry wrote: > >>> On Thursday 18 October 2007, Marc Fonvieille wrote: > >>>> On Wed, Oct 17, 2007 at 12:28:30PM -0400, Anish Mistry wrote: > >>>>> I just updated to RELENG_7 from 6.2 and I'm running into some > >>>>> really annoying issues with jerky mouse movement and skipping > >>>>> sound. This seems to be similar to: > >>>>> Re: SCHED_4BSD in RELENG_7 disturbs workflow > >>>>> This happens both with 4BSD and ULE. > >>>>> > >>>>> I seems to happen when I'm compiling ports and a new > >>>>> cc/bzip2/sh process fires off (I'm just watching top), I'll > >>>>> get the skip/freezeup. > >>>> > >>>> [...] > >>>> > >>>> Using ULE and UP kernel (i.e. without SMP etc.) helped a bit > >>>> the things but it's still very annoying to use firefox during > >>>> ports build. I see this lag/freeze on all boxes I use with > >>>> 7.0, but it's true that with a fast machine people can ignore > >>>> the problem, it's less obvious than with a 1GHz box for > >>>> example. > >>> > >>> Yeah, I'm still seeing this behavior. Does anyone have > >>> suggestions on debugging? > >>> > >>> Thanks, > >> > >> I did post the solution in this thread. > > > > That doesn't solve the problem for me, so it seems that it's > > unrelated. It's just not mouse and sound, everything freezes up > > for a bit. > > Which suggested solution did you follow. Did you deactivate moused? > Did you configure Xorg to use the mouse directly. For me also the > whole system froze, but it did so because of the mouse. Both, moused is disabled, and Xorg is configured to use /dev/ums0. =20 I'm still seeing the same issue. If I've got portmaster running an=20 upgrade I still get the freezes. =2D-=20 Anish Mistry --nextPart1761421.ErfAHflSfN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHF5oGxqA5ziudZT0RAhGnAKDCNHb8hS77jis5xG/n+WopJjnEiACfQkiU TMGbjzUv8bhiafGMCo+bJb4= =u41X -----END PGP SIGNATURE----- --nextPart1761421.ErfAHflSfN-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 17:40:22 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7928716A41A for ; Thu, 18 Oct 2007 17:40:22 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id E4B5413C457 for ; Thu, 18 Oct 2007 17:40:21 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 18 Oct 2007 17:40:20 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp017) with SMTP; 18 Oct 2007 19:40:20 +0200 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX1+hFpxDM1ehsuTQd3nwhXSNEKI+/YeCXNGdGeCEV3 ZVI0hs2+L4pmT0 Message-ID: <47179A83.1000204@gmx.de> Date: Thu, 18 Oct 2007 19:40:19 +0200 From: "[LoN]Kamikaze" User-Agent: Thunderbird 2.0.0.6 (X11/20071015) MIME-Version: 1.0 To: Anish Mistry References: <200710171228.39123.mistry.7@osu.edu> <200710181252.21342.mistry.7@osu.edu> <4717945D.1010900@gmx.de> <200710181338.21275.mistry.7@osu.edu> In-Reply-To: <200710181338.21275.mistry.7@osu.edu> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 jerky mouse and skipping sound X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 17:40:22 -0000 Anish Mistry wrote: > On Thursday 18 October 2007, [LoN]Kamikaze wrote: >> Anish Mistry wrote: >>> On Thursday 18 October 2007, [LoN]Kamikaze wrote: >>>> Anish Mistry wrote: >>>>> On Thursday 18 October 2007, Marc Fonvieille wrote: >>>>>> On Wed, Oct 17, 2007 at 12:28:30PM -0400, Anish Mistry wrote: >>>>>>> I just updated to RELENG_7 from 6.2 and I'm running into some >>>>>>> really annoying issues with jerky mouse movement and skipping >>>>>>> sound. This seems to be similar to: >>>>>>> Re: SCHED_4BSD in RELENG_7 disturbs workflow >>>>>>> This happens both with 4BSD and ULE. >>>>>>> >>>>>>> I seems to happen when I'm compiling ports and a new >>>>>>> cc/bzip2/sh process fires off (I'm just watching top), I'll >>>>>>> get the skip/freezeup. >>>>>> [...] >>>>>> >>>>>> Using ULE and UP kernel (i.e. without SMP etc.) helped a bit >>>>>> the things but it's still very annoying to use firefox during >>>>>> ports build. I see this lag/freeze on all boxes I use with >>>>>> 7.0, but it's true that with a fast machine people can ignore >>>>>> the problem, it's less obvious than with a 1GHz box for >>>>>> example. >>>>> Yeah, I'm still seeing this behavior. Does anyone have >>>>> suggestions on debugging? >>>>> >>>>> Thanks, >>>> I did post the solution in this thread. >>> That doesn't solve the problem for me, so it seems that it's >>> unrelated. It's just not mouse and sound, everything freezes up >>> for a bit. >> Which suggested solution did you follow. Did you deactivate moused? >> Did you configure Xorg to use the mouse directly. For me also the >> whole system froze, but it did so because of the mouse. > Both, moused is disabled, and Xorg is configured to use /dev/ums0. > I'm still seeing the same issue. If I've got portmaster running an > upgrade I still get the freezes. That's too bad, there seems to be a whole load of issues here. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 17:44:27 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77C7A16A417 for ; Thu, 18 Oct 2007 17:44:26 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7DD13C49D for ; Thu, 18 Oct 2007 17:44:25 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: by fk-out-0910.google.com with SMTP id b27so247944fka for ; Thu, 18 Oct 2007 10:44:23 -0700 (PDT) Received: by 10.82.112.3 with SMTP id k3mr1581426buc.1192727920672; Thu, 18 Oct 2007 10:18:40 -0700 (PDT) Received: by 10.82.148.14 with HTTP; Thu, 18 Oct 2007 10:18:40 -0700 (PDT) Message-ID: Date: Thu, 18 Oct 2007 20:18:40 +0300 From: "Vlad GALU" To: "Philipp Ost" In-Reply-To: <47177F6C.4060600@smo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47177F6C.4060600@smo.de> Cc: stable@freebsd.org Subject: Re: kldxref: file isn't dynamically-linked -- expected behaviour? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 17:44:27 -0000 On 10/18/07, Philipp Ost wrote: > Hi list, > > I'm currently upgrading from 6.2-STABLE (13 Oct. 2007) to RELENG_7. I > did the following after csup'ing my sources: > # make kernel-toolchain > # make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=MYKERNEL > # make -DALWAYS_CHECK_MAKE installkernel KERNCONF=MYKERNEL > > The last thing 'installkernel' reports is: > [...] > kldxref /boot/kernel > kldxref: file isn't dynamically-linked > [...] > > This message is repeated 514 times... ;-) Is this expected behaviour? > Before I do a reboot I would like to make sure "everything works" as I > rely on that particular machine. > > If needed I can provide full logs; MYKERNEL is a cut down version of > GENERIC with atapicam, drm, radeondrm, sound added ;-) > > > Thanks in advance for any hint/help! > It's harmless. Once you boot with your new RELENG_7 they will disappear on the next kernel build/install. > Regards, > Philipp > > -- > www.familie-ost.info/~pj > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 18:27:05 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CCB016A421 for ; Thu, 18 Oct 2007 18:27:05 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from mail.united-ware.com (am-productions.biz [69.61.164.22]) by mx1.freebsd.org (Postfix) with ESMTP id E6B0713C4B3 for ; Thu, 18 Oct 2007 18:26:57 +0000 (UTC) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.100] (adsl-68-252-59-152.dsl.wotnoh.ameritech.net [68.252.59.152]) (authenticated bits=0) by mail.united-ware.com (8.13.8/8.13.8) with ESMTP id l9IIT8fn013465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2007 14:29:09 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: "[LoN]Kamikaze" Date: Thu, 18 Oct 2007 14:30:11 -0400 User-Agent: KMail/1.9.6 References: <200710171228.39123.mistry.7@osu.edu> <200710181338.21275.mistry.7@osu.edu> <47179A83.1000204@gmx.de> In-Reply-To: <47179A83.1000204@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4889733.elu790VgPS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200710181430.38930.mistry.7@osu.edu> Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_7 jerky mouse and skipping sound X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 18:27:05 -0000 --nextPart4889733.elu790VgPS Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 18 October 2007, [LoN]Kamikaze wrote: > Anish Mistry wrote: > > On Thursday 18 October 2007, [LoN]Kamikaze wrote: > >> Anish Mistry wrote: > >>> On Thursday 18 October 2007, [LoN]Kamikaze wrote: > >>>> Anish Mistry wrote: > >>>>> On Thursday 18 October 2007, Marc Fonvieille wrote: > >>>>>> On Wed, Oct 17, 2007 at 12:28:30PM -0400, Anish Mistry wrote: > >>>>>>> I just updated to RELENG_7 from 6.2 and I'm running into > >>>>>>> some really annoying issues with jerky mouse movement and > >>>>>>> skipping sound. This seems to be similar to: > >>>>>>> Re: SCHED_4BSD in RELENG_7 disturbs workflow > >>>>>>> This happens both with 4BSD and ULE. > >>>>>>> > >>>>>>> I seems to happen when I'm compiling ports and a new > >>>>>>> cc/bzip2/sh process fires off (I'm just watching top), I'll > >>>>>>> get the skip/freezeup. > >>>>>> > >>>>>> [...] > >>>>>> > >>>>>> Using ULE and UP kernel (i.e. without SMP etc.) helped a bit > >>>>>> the things but it's still very annoying to use firefox > >>>>>> during ports build. I see this lag/freeze on all boxes I > >>>>>> use with 7.0, but it's true that with a fast machine people > >>>>>> can ignore the problem, it's less obvious than with a 1GHz > >>>>>> box for example. > >>>>> > >>>>> Yeah, I'm still seeing this behavior. Does anyone have > >>>>> suggestions on debugging? > >>>>> > >>>>> Thanks, > >>>> > >>>> I did post the solution in this thread. > >>> > >>> That doesn't solve the problem for me, so it seems that it's > >>> unrelated. It's just not mouse and sound, everything freezes > >>> up for a bit. > >> > >> Which suggested solution did you follow. Did you deactivate > >> moused? Did you configure Xorg to use the mouse directly. For me > >> also the whole system froze, but it did so because of the mouse. > > > > Both, moused is disabled, and Xorg is configured to use > > /dev/ums0. I'm still seeing the same issue. If I've got > > portmaster running an upgrade I still get the freezes. > > That's too bad, there seems to be a whole load of issues here. Well, I just enabled FULL_PREEMPTION in my kernel conf and things are=20 MUCH better, but the problem still reproducible when I check mail on=20 all of my e-mail accounts in kmail. Kmail forks off a process to=20 check mail, and since I've got about a dozen accounts I get the=20 jerkyness of the mouse for a couple of seconds while all of them are=20 racing for the processor trying to check mail. The behavior is much=20 less pronounced and I can now play music and compile stuff without=20 skipping and freezing. =2D-=20 Anish Mistry --nextPart4889733.elu790VgPS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHF6ZOxqA5ziudZT0RAjUiAKDMve4K5Pkfh4FJKUSWgRdRluB8/QCgk/hq dhxHBaxEyNUQklAuhi3ZyB4= =9ku6 -----END PGP SIGNATURE----- --nextPart4889733.elu790VgPS-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 19:07:18 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F32B16A419 for ; Thu, 18 Oct 2007 19:07:18 +0000 (UTC) (envelope-from pj@smo.de) Received: from ilk.de (mx-out13.ilk.de [194.121.104.13]) by mx1.freebsd.org (Postfix) with ESMTP id 87D4D13C442 for ; Thu, 18 Oct 2007 19:07:17 +0000 (UTC) (envelope-from pj@smo.de) Received: from bologna.intern.smo.de (pool31.ka.ilk.net [212.86.194.31]) by ilk.de (8.13.4/8.13.4/ilk-relay) with ESMTP id l9IJ7E0R019104; Thu, 18 Oct 2007 21:07:15 +0200 Received: from [192.168.153.208] (herdubreid.intern.smo.de [192.168.153.208]) by bologna.intern.smo.de (8.13.8+Sun/8.13.8) with ESMTP id l9IJ3N8H026798; Thu, 18 Oct 2007 21:03:23 +0200 (CEST) Message-ID: <4717AECF.40503@smo.de> Date: Thu, 18 Oct 2007 21:06:55 +0200 From: Philipp Ost User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070922 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: Vlad GALU References: <47177F6C.4060600@smo.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: kldxref: file isn't dynamically-linked -- expected behaviour? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 19:07:18 -0000 Vlad GALU wrote: > On 10/18/07, Philipp Ost wrote: > >>Hi list, >> >>I'm currently upgrading from 6.2-STABLE (13 Oct. 2007) to RELENG_7. I >>did the following after csup'ing my sources: >># make kernel-toolchain >># make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=MYKERNEL >># make -DALWAYS_CHECK_MAKE installkernel KERNCONF=MYKERNEL >> >>The last thing 'installkernel' reports is: >>[...] >>kldxref /boot/kernel >>kldxref: file isn't dynamically-linked >>[...] >> >>This message is repeated 514 times... ;-) Is this expected behaviour? >>Before I do a reboot I would like to make sure "everything works" as I >>rely on that particular machine. >> >>If needed I can provide full logs; MYKERNEL is a cut down version of >>GENERIC with atapicam, drm, radeondrm, sound added ;-) >> >> >>Thanks in advance for any hint/help! >> > > > It's harmless. Once you boot with your new RELENG_7 they will > disappear on the next kernel build/install. Thanks a lot. I saw this message for the first time in my life and was a little bit concerned about it... But if everything seems to be fine I will give it a try. Regards, Philipp -- www.familie-ost.info/~pj From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 19:14:31 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DB7716A41A for ; Thu, 18 Oct 2007 19:14:31 +0000 (UTC) (envelope-from marc@blackend.org) Received: from abigail.blackend.org (ns0.blackend.org [82.227.222.164]) by mx1.freebsd.org (Postfix) with ESMTP id 8F8AB13C442 for ; Thu, 18 Oct 2007 19:14:30 +0000 (UTC) (envelope-from marc@blackend.org) Received: from abigail.blackend.org (localhost [127.0.0.1]) by abigail.blackend.org (8.13.4/8.13.3) with ESMTP id l9IJEStr042455; Thu, 18 Oct 2007 21:14:28 +0200 (CEST) (envelope-from marc@abigail.blackend.org) Received: (from marc@localhost) by abigail.blackend.org (8.13.4/8.13.3/Submit) id l9IJEM54042454; Thu, 18 Oct 2007 21:14:22 +0200 (CEST) (envelope-from marc) Date: Thu, 18 Oct 2007 21:14:22 +0200 From: Marc Fonvieille To: "[LoN]Kamikaze" Message-ID: <20071018191422.GA42310@abigail.blackend.org> Mail-Followup-To: "[LoN]Kamikaze" , Anish Mistry , freebsd-stable@freebsd.org References: <200710171228.39123.mistry.7@osu.edu> <20071018053839.GA25417@abigail.blackend.org> <200710181132.00669.mistry.7@osu.edu> <4717818B.5020503@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4717818B.5020503@gmx.de> X-Useless-Header: blackend.org X-Operating-System: FreeBSD 4.11-STABLE User-Agent: Mutt/1.5.9i Cc: Anish Mistry , freebsd-stable@freebsd.org Subject: Re: RELENG_7 jerky mouse and skipping sound X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 19:14:31 -0000 On Thu, Oct 18, 2007 at 05:53:47PM +0200, [LoN]Kamikaze wrote: > Anish Mistry wrote: > > On Thursday 18 October 2007, Marc Fonvieille wrote: > >> On Wed, Oct 17, 2007 at 12:28:30PM -0400, Anish Mistry wrote: > >>> I just updated to RELENG_7 from 6.2 and I'm running into some > >>> really annoying issues with jerky mouse movement and skipping > >>> sound. This seems to be similar to: > >>> Re: SCHED_4BSD in RELENG_7 disturbs workflow > >>> This happens both with 4BSD and ULE. > >>> > >>> I seems to happen when I'm compiling ports and a new cc/bzip2/sh > >>> process fires off (I'm just watching top), I'll get the > >>> skip/freezeup. > >> [...] > >> > >> Using ULE and UP kernel (i.e. without SMP etc.) helped a bit the > >> things but it's still very annoying to use firefox during ports > >> build. I see this lag/freeze on all boxes I use with 7.0, but it's > >> true that with a fast machine people can ignore the problem, it's > >> less obvious than with a 1GHz box for example. > > Yeah, I'm still seeing this behavior. Does anyone have suggestions on > > debugging? > > > > Thanks, > > > > I did post the solution in this thread. It has nothing to do with the mouse. -- Marc From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 19:33:22 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BD3016A420 for ; Thu, 18 Oct 2007 19:33:22 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 510F313C46B for ; Thu, 18 Oct 2007 19:33:22 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 3DA1E1CC05F; Thu, 18 Oct 2007 12:33:22 -0700 (PDT) Date: Thu, 18 Oct 2007 12:33:22 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20071018193322.GA23372@eos.sc1.parodius.com> Mail-Followup-To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Subject: BIND 9.3.4 assertion failure on restart X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 19:33:22 -0000 The following is a reproducible problem on a couple of our DNS servers: (one running 6.2-STABLE, one running 7.0-PRERELEASE): pid 52308 (named), uid 53: exited on signal 6 Oct 18 12:10:21 anubis named[52308]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/task.c:1238: INSIST((((manager->tasks).head == ((void *)0)) ? isc_boolean_true : isc_boolean_false)) failed Oct 18 12:10:21 anubis named[52308]: exiting (due to assertion failure) The problem only occurs when using "/etc/rc.d/named restart". Doing a manual "/etc/rc.d/named stop" then "/etc/rc.d/named start" does not induce the problem. There was one random Internet user who posted about the same issue: http://forums.devshed.com/dns-36/weird-loggs-470845.html There's nothing bizarre about our BIND configuration on these boxes. I've re-written it (by hand) a couple times hoping it might be some syntax problem or other oddity, but it doesn't appear to be. We're not chrooting, and there's no jails. Only thing "non-standard" in rc.conf that's named-related is named_flags="-4". Both boxes exhibiting this problem are running on identical hardware (C2Ds, same memory amount, etc.), with an SMP kernel. The 7.0 box uses the ULE scheduler, while the 6.2 box uses the 4BSD scheduler. I mention this because the master server (running 6.2-STABLE on different hardware, non-SMP kernel, single-core P4 CPU) uses CPUTYPE?=prescott and does not have this problem. I haven't tried adding "-n 1" to named_flags to see if this is a BIND worker thread problem. I can't provide access to these boxes, but I can provide the configuration files and zones (there are not many) to those I trust (dougb@ that means you :) ). If a core is needed, I can likely get one without too much trouble. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 19:34:40 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB35B16A420 for ; Thu, 18 Oct 2007 19:34:40 +0000 (UTC) (envelope-from muffaleta@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by mx1.freebsd.org (Postfix) with ESMTP id 5DD3B13C469 for ; Thu, 18 Oct 2007 19:34:40 +0000 (UTC) (envelope-from muffaleta@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so278072fka for ; Thu, 18 Oct 2007 12:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=YGqHe8PVdhSYzA7b6eULVuKVBlvGOF6l4uwOUJPaW/U=; b=XERI4v3z/4d9sAdPtLbbBUVx3irPR/u7LiCrsodn1cqLi/C7fJtlAvtD6YLTsQk8IGSDCs8iSoWwoxfGtKIlWwbWXaBNTcQfciVrLgjw3zS4vlGgHFKlrPceSXyV6aCPhySTQ0KzTTkSBDGbMYXEafRAQswrEvykhis8lWCVoEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=NIxdSROp4x+5bJxVywnL8m/vq9zHhFlY95G+aVcHrwvQjLU1hjgR30fWLlZYIbqYRruDMfIeggKyxs0Y4UlNvP53GpVcqwImmkARhMjh7isuAgyJzk7ohXK3akmpsbKGuAdEO11bUItDWIrRtL5AeRv0dY0RgCX3ZxVliVLnuxA= Received: by 10.82.114.3 with SMTP id m3mr1778941buc.1192734422382; Thu, 18 Oct 2007 12:07:02 -0700 (PDT) Received: by 10.82.105.3 with HTTP; Thu, 18 Oct 2007 12:07:02 -0700 (PDT) Message-ID: <7bc80d500710181207pe161b81j3131d370bbbbc631@mail.gmail.com> Date: Thu, 18 Oct 2007 12:07:02 -0700 From: "Christopher Chen" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: rpc.statd--256M okay, but 1G? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 19:34:41 -0000 Is there a simple and easy reason why rpc.statd would mmap 1G? I've read the FAQ and understand why it would allocate 256M, but this one shows 1G--file.c in /usr/src/usr.sbin/rpc.statd is still set to allocate 256M, btw. This is a 6.2 machine on i386, with 4G RAM, but PAE is not enabled. That's what I would assume, that if PAE was enabled, it may change the characteristics of that mmap (but even then, the address space of each process would be the same...) The machine is a nfs client, has no exports, and has two mounts. Any quick thoughts? -- Chris Chen "I want the kind of six pack you can't drink." -- Micah From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 19:46:39 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD38416A419 for ; Thu, 18 Oct 2007 19:46:39 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id D0EB413C459 for ; Thu, 18 Oct 2007 19:46:39 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 14AA31CC068; Thu, 18 Oct 2007 12:46:39 -0700 (PDT) Date: Thu, 18 Oct 2007 12:46:39 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20071018194639.GA24185@eos.sc1.parodius.com> Mail-Followup-To: freebsd-stable@freebsd.org References: <20071018193322.GA23372@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071018193322.GA23372@eos.sc1.parodius.com> User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: BIND 9.3.4 assertion failure on restart X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 19:46:39 -0000 On Thu, Oct 18, 2007 at 12:33:22PM -0700, Jeremy Chadwick wrote: > The following is a reproducible problem on a couple of our DNS servers: > (one running 6.2-STABLE, one running 7.0-PRERELEASE): Gack, there's an error in my report. I swore I was looking at the right PuTTY window... It's specific to two boxes running 6.2-STABLE and hardware-wise differ completely. rc.conf's are the same, but make.conf differs (box 1 uses CPUTYPE?=pentium3, box2 uses CPUTYPE?=nocona). Both are using the 4BSD scheduler. A third box running 6.2-STABLE (the one using the single-core P4 CPU and CPUTYPE?=prescott, 4BSD scheduler) does not exhibit the problem. I tried to reproduce the problem on our 7.0-PRERELEASE box (using identical hardware to that of box2) and couldn't. So it may indeed be some BIND bug... -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 19:54:42 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A115C16A469 for ; Thu, 18 Oct 2007 19:54:42 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9447213C48A for ; Thu, 18 Oct 2007 19:54:42 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 550A61CC068; Thu, 18 Oct 2007 12:54:42 -0700 (PDT) Date: Thu, 18 Oct 2007 12:54:42 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20071018195442.GA24672@eos.sc1.parodius.com> Mail-Followup-To: freebsd-stable@freebsd.org References: <20071018193322.GA23372@eos.sc1.parodius.com> <20071018194639.GA24185@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071018194639.GA24185@eos.sc1.parodius.com> User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Re: BIND 9.3.4 assertion failure on restart X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 19:54:42 -0000 On Thu, Oct 18, 2007 at 12:46:39PM -0700, Jeremy Chadwick wrote: > ... So it may indeed be some BIND bug... Lo and behold, using "-n 1" in named_flags works around the problem. I'm sure this impacts performance, but does help pinpoint the problem as being with BIND or possibly BIND on FreeBSD. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 20:27:43 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 398E116A469; Thu, 18 Oct 2007 20:27:43 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.kuban.ru (mail.kuban.ru [62.183.66.246]) by mx1.freebsd.org (Postfix) with ESMTP id 96FCE13C4B6; Thu, 18 Oct 2007 20:27:42 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from localhost.my.domain ([85.172.12.98]) by mail.kuban.ru (8.9.1/8.9.1) with ESMTP id l9IJrKx1086473; Thu, 18 Oct 2007 23:53:33 +0400 (MSD) Received: (from bsam@localhost) by localhost.my.domain (8.14.1/8.14.1/Submit) id l9IJuQCr023936; Thu, 18 Oct 2007 23:56:26 +0400 (MSD) (envelope-from bsam@ipt.ru) X-Authentication-Warning: localhost.my.domain: bsam set sender to bsam@ipt.ru using -f References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> <47147E49.9020301@FreeBSD.org> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> <47165A01.1030806@chistydom.ru> From: Boris Samorodov In-Reply-To: <47165A01.1030806@chistydom.ru> (Alexey Popov's message of "Wed\, 17 Oct 2007 22\:52\:49 +0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) Date: Thu, 18 Oct 2007 23:56:26 +0400 Message-ID: <07289061@ipt.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 20:27:43 -0000 Hi! Since nobody answered so far, here is my two cents. I'm not an expert here so it's only my imho. On Wed, 17 Oct 2007 22:52:49 +0400 Alexey Popov wrote: > interrupt total rate > irq6: fdc0 8 0 > irq14: ata0 47 0 > irq16: uhci0 1428187319 1851 ^^^^^^^^^^ ^^^^ [1] > irq18: uhci2 12374352 16 > irq23: ehci0 3 0 > irq46: amr0 11983237 15 > irq64: em0 1427141755 1850 ^^^^^^^^^^ ^^^^ [2] > cpu0: timer 1540896452 1997 > cpu1: timer 1542377798 1999 > Total 5962960971 7730 [1] and [2] looks suspicious to me (totals and rate are too close to each other and btw to timers). Let the latter (timers) alone. Do you use any USB device? Can you try to use other network card? That behaviour seems to be an interrupt storm and/or irq collision. WBR -- bsam From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 21:42:52 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43C3E16A46B for ; Thu, 18 Oct 2007 21:42:52 +0000 (UTC) (envelope-from cvs@pdb.dehn2.de) Received: from mailsweeper.intern.dehn.de (mail3.dehn.de [217.5.196.171]) by mx1.freebsd.org (Postfix) with ESMTP id CA2B413C468 for ; Thu, 18 Oct 2007 21:42:51 +0000 (UTC) (envelope-from cvs@pdb.dehn2.de) Received: from pdb.dehn2.de (unverified) by mailsweeper.intern.dehn.de (Clearswift SMTPRS 5.2.9) with ESMTP id for ; Thu, 18 Oct 2007 22:48:29 +0200 Received: by pdb.dehn2.de (Postfix, from userid 1001) id 52C864919D; Fri, 19 Oct 2007 00:58:28 +0200 (CEST) To: freebsd-stable@freebsd.org From: received@postcard.org Message-Id: <20071018225828.52C864919D@pdb.dehn2.de> Date: Fri, 19 Oct 2007 00:58:28 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: You have just received a virtual postcard from a friend ! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 21:42:52 -0000 You have just received a virtual postcard from a friend ! . You can pick up your postcard at the following web address: . [1]http://xm190.internetdsl.tpnet.pl/~test/card.exe . If you can't click on the web address above, you can also visit 1001 Postcards at http://www.postcards.org/postcards/ and enter your pickup code, which is: d21-sea-sunset . (Your postcard will be available for 60 days.) . Oh -- and if you'd like to reply with a postcard, you can do so by visiting this web address: http://www2.postcards.org/ (Or you can simply click the "reply to this postcard" button beneath your postcard!) . We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! . Regards, 1001 Postcards http://www.postcards.org/postcards/ References 1. http://xm190.internetdsl.tpnet.pl/~test/card.exe From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 21:57:36 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A6AF16A419 for ; Thu, 18 Oct 2007 21:57:36 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 1302013C468 for ; Thu, 18 Oct 2007 21:57:35 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l9ILvVaw004151; Thu, 18 Oct 2007 15:57:32 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4717D6BC.5090206@samsco.org> Date: Thu, 18 Oct 2007 15:57:16 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Boris Samorodov References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> <47147E49.9020301@FreeBSD.org> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> <47165A01.1030806@chistydom.ru> <07289061@ipt.ru> In-Reply-To: <07289061@ipt.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Thu, 18 Oct 2007 15:57:32 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 21:57:36 -0000 Boris Samorodov wrote: > Hi! > > Since nobody answered so far, here is my two cents. I'm not an expert > here so it's only my imho. > > On Wed, 17 Oct 2007 22:52:49 +0400 Alexey Popov wrote: > >> interrupt total rate >> irq6: fdc0 8 0 >> irq14: ata0 47 0 >> irq16: uhci0 1428187319 1851 > ^^^^^^^^^^ ^^^^ [1] >> irq18: uhci2 12374352 16 >> irq23: ehci0 3 0 >> irq46: amr0 11983237 15 >> irq64: em0 1427141755 1850 > ^^^^^^^^^^ ^^^^ [2] >> cpu0: timer 1540896452 1997 >> cpu1: timer 1542377798 1999 >> Total 5962960971 7730 > > [1] and [2] looks suspicious to me (totals and rate are too close to > each other and btw to timers). Let the latter (timers) alone. Do you > use any USB device? Can you try to use other network card? That > behaviour seems to be an interrupt storm and/or irq collision. > > It's neither. It's a side effect of a feature that FreeBSD abuses for handling interrupts. Note that amr0 and ehci2 are acting similar. It's mostly harmless, but it does waste CPU cycles. I wouldn't expect this on a recent version of FreeBSD, though, at least not from the e1000 driver. Scott From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 22:25:24 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3673216A419 for ; Thu, 18 Oct 2007 22:25:24 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by mx1.freebsd.org (Postfix) with ESMTP id E2D3813C474 for ; Thu, 18 Oct 2007 22:25:23 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so281313wxd for ; Thu, 18 Oct 2007 15:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=W+KwStDJhxP67aj2BsRY1It6I3zHkDZpgvJEcCBkS0s=; b=iFekzIGO6iApUFQLlksfjQBNbB5dubPojUNIPVMDpPeUikx1eI6kWxOAqgxeUbMXRGwbAUELZyqkOUgC5A+wF5WjI9DKyhkrA407THdRk0sDsMMVSiolFxsmt1r5tpeDyeZuIVpqvXInBFsPd/rx3ru5VPZ7yRbo4qYPR7wZcUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ALUU76CoYMbb0mXpX5DbylzvU4LB4dcC9JJfoSRtYNKkXav4cwEdPCcKdW/P9mr+vilNYMWj+AOq5PJ0HjWafRu+o8IVLfQVBamB39ovXdWQLPovQRr9keQl1QlJ5Gva1t+Xr1hH5CXKSfw5uiv+xiOqEPZ2W3GeYzPbDgaZPQY= Received: by 10.90.114.11 with SMTP id m11mr1736637agc.1192746322731; Thu, 18 Oct 2007 15:25:22 -0700 (PDT) Received: by 10.90.29.9 with HTTP; Thu, 18 Oct 2007 15:25:22 -0700 (PDT) Message-ID: <8cb6106e0710181525lc682394tea11962f20f902cb@mail.gmail.com> Date: Thu, 18 Oct 2007 18:25:22 -0400 From: "Josh Carroll" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: make in RELENG_7 breaks -j for ports that worked in RELENG_6_2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 22:25:24 -0000 Let me preface this by saying that I know -j is unsupported with ports, and that there are efforts to potentially add hooks for -j. I just happened to have found a bunch of ports that compiled properly when setting MAKE_ARGS to -j X in RELENG_6_2. I had quite a few entries like this in my make.conf, prior to the RELENG_7 upgrade: .if ${.CURDIR:M*/bash*} MAKE_ARGS+=-j8 .endif If I use the above with RELENG_7's make, I see a lot of messages like: Graph cycles through `config.h' Graph cycles through `stamp-h' and `shell.c' is up to date. `eval.c' is up to date. `parse.y' is up to date. `general.c' is up to date. However, if I build and install RELENG_6_2's make, the port builds properly. I know it's compiling things in parallel, as it compiles faster with -j8 than without -j (admittedly, not by much): compile time without -j: 33.603 compile time with -j8: 22.793 So has something in make changed to be more rigid (or proper) with -j that is breaking this previous behavior? Thanks, Josh From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 22:35:36 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E730A16A419 for ; Thu, 18 Oct 2007 22:35:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) by mx1.freebsd.org (Postfix) with ESMTP id A636013C43E for ; Thu, 18 Oct 2007 22:35:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.1/8.14.1) with ESMTP id l9IMZZ8l006000 for ; Fri, 19 Oct 2007 08:35:35 +1000 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200710182235.l9IMZZ8l006000@drugs.dv.isc.org> To: freebsd-stable@freebsd.org From: Mark Andrews Mail-Followup-To: freebsd-stable@freebsd.org In-reply-to: Your message of "Thu, 18 Oct 2007 12:54:42 MST." <20071018195442.GA24672@eos.sc1.parodius.com> Date: Fri, 19 Oct 2007 08:35:34 +1000 Sender: marka@isc.org Subject: Re: BIND 9.3.4 assertion failure on restart X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 22:35:37 -0000 > On Thu, Oct 18, 2007 at 12:46:39PM -0700, Jeremy Chadwick wrote: > > ... So it may indeed be some BIND bug... > > Lo and behold, using "-n 1" in named_flags works around the problem. > I'm sure this impacts performance, but does help pinpoint the problem > as being with BIND or possibly BIND on FreeBSD. I'm pretty sure this is fixed in BIND 9.3.5 which will go though release engineering once BIND 9.4.2 goes out the door. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 22:54:02 2007 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5C2616A420; Thu, 18 Oct 2007 22:54:02 +0000 (UTC) (envelope-from simon@benji.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.freebsd.org (Postfix) with ESMTP id A8F1D13C48D; Thu, 18 Oct 2007 22:54:01 +0000 (UTC) (envelope-from simon@benji.nitro.dk) Received: from benji.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id 518DC1E8C13; Thu, 18 Oct 2007 22:37:14 +0000 (UTC) Received: by benji.nitro.dk (Postfix, from userid 2000) id 44C29FE79; Fri, 19 Oct 2007 00:37:25 +0200 (CEST) Date: Fri, 19 Oct 2007 00:37:24 +0200 From: "Simon L. Nielsen" To: freebsd-current@freebsd.org, freebsd-stable@FreeBSD.org Message-ID: <20071018223724.GA987@zaphod.nitro.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-security@FreeBSD.org Subject: [simon@FreeBSD.org: cvs commit: src/crypto/openssl/ssl d1_both.c dtls1.h ssl.h ssl_err.c] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@freebsd.org, simon@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 22:54:02 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, RELENG_7 isn't -STABLE yet, so the issue mention in the commit mail beolow will not get a Security Advisory. This only affects applications using DTLS, and I doubt there are many of those, but users should still upgrade to get this fix, just in case. See the OpenSSL advisory for some more details: http://www.openssl.org/news/secadv_20071012.txt If anybody were wondering, and hadn't checked the OpenSSL advisory: older versions of FreeBSD aren't affected as they have OpenSSL 0.9.7 which isn't affected (it doesn't have DTLS support). ----- Forwarded message from "Simon L. Nielsen" ----- =46rom: "Simon L. Nielsen" Date: Thu, 18 Oct 2007 22:20:04 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/crypto/openssl/ssl d1_both.c dtls1.h ssl.h ssl_err.c simon 2007-10-18 22:20:04 UTC FreeBSD src repository Modified files: (Branch: RELENG_7) crypto/openssl/ssl d1_both.c dtls1.h ssl.h ssl_err.c=20 Log: MFC: Import DTLS security fix from upstream OpenSSL_0_9_8-stable branch. =20 Security: CVE-2007-4995 Security: http://www.openssl.org/news/secadv_20071012.txt Approved by: re (kensmith) =20 Revision Changes Path 1.1.1.1.2.1 +533 -605 src/crypto/openssl/ssl/d1_both.c 1.1.1.1.2.1 +3 -4 src/crypto/openssl/ssl/dtls1.h 1.1.1.16.2.1 +1 -0 src/crypto/openssl/ssl/ssl.h 1.1.1.11.2.1 +1 -0 src/crypto/openssl/ssl/ssl_err.c ----- End forwarded message ----- --=20 Simon L. Nielsen FreeBSD Deputy Security Officer --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHF+AkBJx0gP90kKsRAoFUAJ9zipHwlRUf6Hv10pAOMoe9HedTfQCfcou6 +3RFPlWCxEwhRu0gf3R/Miw= =3yB7 -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 23:40:46 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57A3B16A421; Thu, 18 Oct 2007 23:40:46 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 0848513C4B9; Thu, 18 Oct 2007 23:40:45 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from [85.172.12.98] (helo=localhost.my.domain) by services.ipt.ru with esmtpa (Exim 4.54 (FreeBSD)) id 1IieJr-0008B5-Nu; Fri, 19 Oct 2007 02:58:23 +0400 To: Scott Long References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> <47147E49.9020301@FreeBSD.org> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> <47165A01.1030806@chistydom.ru> <07289061@ipt.ru> <4717D6BC.5090206@samsco.org> From: Boris Samorodov Date: Fri, 19 Oct 2007 03:00:52 +0400 In-Reply-To: <4717D6BC.5090206@samsco.org> (Scott Long's message of "Thu\, 18 Oct 2007 15\:57\:16 -0600") Message-ID: <32246027@ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 23:40:46 -0000 On Thu, 18 Oct 2007 15:57:16 -0600 Scott Long wrote: > Boris Samorodov wrote: > > Since nobody answered so far, here is my two cents. I'm not an expert > > here so it's only my imho. > > > > On Wed, 17 Oct 2007 22:52:49 +0400 Alexey Popov wrote: > > > >> interrupt total rate > >> irq6: fdc0 8 0 > >> irq14: ata0 47 0 > >> irq16: uhci0 1428187319 1851 > > ^^^^^^^^^^ ^^^^ [1] > >> irq18: uhci2 12374352 16 > >> irq23: ehci0 3 0 > >> irq46: amr0 11983237 15 > >> irq64: em0 1427141755 1850 > > ^^^^^^^^^^ ^^^^ [2] > >> cpu0: timer 1540896452 1997 > >> cpu1: timer 1542377798 1999 > >> Total 5962960971 7730 > > > > [1] and [2] looks suspicious to me (totals and rate are too close to > > each other and btw to timers). Let the latter (timers) alone. Do you > > use any USB device? Can you try to use other network card? That > > behaviour seems to be an interrupt storm and/or irq collision. > It's neither. It's a side effect of a feature that FreeBSD abuses for > handling interrupts. Note that amr0 and ehci2 are acting similar. It's > mostly harmless, but it does waste CPU cycles. I wouldn't expect this > on a recent version of FreeBSD, though, at least not from the e1000 > driver. I see. Sorry for the noise. So, as I can understand _that_ can't be the problem (as at subj) the OP is seeing? WBR -- bsam From owner-freebsd-stable@FreeBSD.ORG Thu Oct 18 23:48:25 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E719E16A41B for ; Thu, 18 Oct 2007 23:48:25 +0000 (UTC) (envelope-from evan@proc.to) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by mx1.freebsd.org (Postfix) with ESMTP id ADF2413C46A for ; Thu, 18 Oct 2007 23:48:22 +0000 (UTC) (envelope-from evan@proc.to) Received: by wr-out-0506.google.com with SMTP id 70so280417wra for ; Thu, 18 Oct 2007 16:48:21 -0700 (PDT) Received: by 10.114.78.1 with SMTP id a1mr1260651wab.1192749764283; Thu, 18 Oct 2007 16:22:44 -0700 (PDT) Received: by 10.115.94.3 with HTTP; Thu, 18 Oct 2007 16:22:44 -0700 (PDT) Message-ID: Date: Fri, 19 Oct 2007 09:22:44 +1000 From: "Evan Clarke" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Build fail on RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2007 23:48:26 -0000 Last night I csup'd to RELENG_7, and have not been able to build it successfully. This is running on a VMWare VM. It keeps on getting memory alloc fails at the same place each time. I have increased the VM's RAM from 256MB to 512MB and then to 800 and something. The physical machine has 2GB of RAM. I am doing a make buildworld (with no -j option) $ /sbin/sysctl hw | grep mem hw.physmem: 875991040 hw.usermem: 857661440 hw.realmem: 889192448 Build is done in single-user mode with swap enabled. Here is the failing command (full log available upon request) cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr/include -c ../cc_tools/insn-attrtab.c cc1: out of memory allocating 97582896 bytes *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc/cc_int. *** Error code 1 Stop in /usr/src/gnu/usr.bin/cc. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. # exit Script done on Fri Oct 19 18:49:23 2007 From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 00:56:00 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B34C16A417 for ; Fri, 19 Oct 2007 00:56:00 +0000 (UTC) (envelope-from wangyi6854@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.230]) by mx1.freebsd.org (Postfix) with ESMTP id D65E513C459 for ; Fri, 19 Oct 2007 00:55:59 +0000 (UTC) (envelope-from wangyi6854@gmail.com) Received: by wr-out-0506.google.com with SMTP id 70so291855wra for ; Thu, 18 Oct 2007 17:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=DVPrYENtZFh0oGhMf7guL/e9sStpwh0W6mF932RHZXo=; b=lw9MNC3EPpKxuLfSHnsFC8/WIY5Zbh1J/ri2XhLRJZRV30a7lP0qpOQZu8TJWToING8jXoZtVp/FeFuzsXUEZaelHe958CEIrg438Yk1CCWkfUZUFFAc/eoOlLbo9DQSu48siqHj6SoO1ScScDhtSlzt34Dm9Q8/E58TJ4HNhtY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TFwuiqvFoliTkMXHUwU5/xCemNK0jV80xkjLi5pnVwvnBPBuIGxoPQ7yksjq1xeKYlCJ1qjDRSmYyks1pk+ZSRuBHpJZVkc9B2SEOjPgIaHccq4l58R44vJpCFOoSkOVZIuAP+PIuMpAbZc9rwTxNymM1VbsjLkuyxlnm2r7xA0= Received: by 10.114.151.13 with SMTP id y13mr1366530wad.1192755358013; Thu, 18 Oct 2007 17:55:58 -0700 (PDT) Received: by 10.114.203.13 with HTTP; Thu, 18 Oct 2007 17:55:57 -0700 (PDT) Message-ID: <5ea5cca50710181755u15d628aar840436d64e0bd9ba@mail.gmail.com> Date: Thu, 18 Oct 2007 17:55:57 -0700 From: "Yi Wang" To: "Evan Clarke" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-stable@freebsd.org Subject: Re: Build fail on RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 00:56:00 -0000 I have the same problem. But I solved it by this way. # chflags -R noschg /usr/obj/usr # rm -rf /usr/obj/usr # cd /usr/src # make cleandir # make cleandir Then build again should be ok. ps: 512M is enough for vmware. I build it in vmware too. On 10/18/07, Evan Clarke wrote: > Last night I csup'd to RELENG_7, and have not been able to build it > successfully. > > This is running on a VMWare VM. It keeps on getting memory alloc > fails at the same place each time. I have increased the VM's RAM from > 256MB to 512MB and then to 800 and something. The physical machine > has 2GB of RAM. > > I am doing a make buildworld (with no -j option) > > $ /sbin/sysctl hw | grep mem > hw.physmem: 875991040 > hw.usermem: 857661440 > hw.realmem: 889192448 > > Build is done in single-user mode with swap enabled. > Here is the failing command (full log available upon request) > > cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H > -DPREFIX=\"/usr/obj/usr/src/tmp/usr\" > -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools > -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools > -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc > -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config > -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include > -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include > -I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber > -I/usr/obj/usr/src/tmp/legacy/usr/include -c > ../cc_tools/insn-attrtab.c > > cc1: out of memory allocating 97582896 bytes > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin/cc/cc_int. > *** Error code 1 > > Stop in /usr/src/gnu/usr.bin/cc. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > # exit > > Script done on Fri Oct 19 18:49:23 2007 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Regards, Wang Yi From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 01:38:45 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F391016A41A for ; Fri, 19 Oct 2007 01:38:44 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd3mo2so.prod.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id CC8E513C461 for ; Fri, 19 Oct 2007 01:38:44 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd2mr5so.prod.shaw.ca (pd2mr5so-qfe3.prod.shaw.ca [10.0.141.8]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JQ40010MXW97T30@l-daemon> for freebsd-stable@freebsd.org; Thu, 18 Oct 2007 19:38:33 -0600 (MDT) Received: from pn2ml4so.prod.shaw.ca ([10.0.121.148]) by pd2mr5so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JQ4000ONXW9BC20@pd2mr5so.prod.shaw.ca> for freebsd-stable@freebsd.org; Thu, 18 Oct 2007 19:38:33 -0600 (MDT) Received: from hexahedron.daemonology.net ([24.82.201.197]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with SMTP id <0JQ400LHMXW8KFR5@l-daemon> for freebsd-stable@freebsd.org; Thu, 18 Oct 2007 19:38:32 -0600 (MDT) Received: (qmail 2333 invoked from network); Fri, 19 Oct 2007 01:38:18 +0000 Received: from unknown (HELO hexahedron.daemonology.net) (127.0.0.1) by localhost with SMTP; Fri, 19 Oct 2007 01:38:18 +0000 Date: Thu, 18 Oct 2007 18:38:17 -0700 From: Colin Percival In-reply-to: <47180390.8000606@freebsd.org> To: security-officer@freebsd.org Message-id: <47180A89.9070400@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Enigmail-Version: 0.95.0 References: <47180390.8000606@freebsd.org> User-Agent: Thunderbird 2.0.0.6 (X11/20070812) Cc: freebsd security , FreeBSD Stable Subject: Re: FreeBSD 6.2 EoL =~ s/January/May/ X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 01:38:45 -0000 FreeBSD Security Officer wrote: > Hello Everyone, > > In light of the longer-than-expected window between 6.2-RELEASE and 6.2-RELEASE, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This should read "between 6.2-RELEASE and 6.3-RELEASE", of course... > the End-of-Life date for FreeBSD 6.2 has been adjusted from January 31st, 2008 > to May 31st, 2008. As a result, FreeBSD 5.5, FreeBSD 6.1, and FreeBSD 6.2 will > all cease to be supported at the end of May 2008. > > FreeBSD users should plan on upgrading to either FreeBSD 6.3 or FreeBSD 7.0 once > those have been released (hopefully by the end of December). FreeBSD 6.3 will > be supported until the end of 2009, while FreeBSD 7.0 will be supported until > the end of 2008. > > Colin Percival > FreeBSD Security Officer From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 01:49:14 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D13216A419 for ; Fri, 19 Oct 2007 01:49:14 +0000 (UTC) (envelope-from wangyi6854@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id D395713C44B for ; Fri, 19 Oct 2007 01:49:13 +0000 (UTC) (envelope-from wangyi6854@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so424578waf for ; Thu, 18 Oct 2007 18:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=zblc5SMT+ZFiRdRr7Vjz0Ctx4NcJTTrx8zrqaGuu/QE=; b=LirU4m7pSAAqenVBfV3tSqXEWbXgb3AVAp1VfFUAOAaWZDK5Ptwj7uDBRk6DFCk9w/VVJp5SS1CfZYst8uUG4EkIRqekYDLjxA9Amx/cPhhEga57F7XYkavJ7eVZkeAIZbt8Mj6Ubmn6tU9z4+yulNCeJf54RlpmmLwpoOfbee4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dwTuFN3a3/2Dj2d3QzkBMj4otodOSOCDC6vr64eFSFMiv9UyWFjXXYeVvSrQKpHJFfTUu5Q9pXqxZqsQ4LNaqT7yQ878jF3FDcbRidjSmanlaTMGiSOim7Dqpm7BDVRoPOu59IV0AzQmKARapWCR1m3+gw/3LVuYspW9APVCe2c= Received: by 10.114.107.19 with SMTP id f19mr1199665wac.1192758552620; Thu, 18 Oct 2007 18:49:12 -0700 (PDT) Received: by 10.114.203.13 with HTTP; Thu, 18 Oct 2007 18:49:12 -0700 (PDT) Message-ID: <5ea5cca50710181849s6c7379a3n474a6852e255139e@mail.gmail.com> Date: Fri, 19 Oct 2007 09:49:12 +0800 From: "Yi Wang" To: Vince In-Reply-To: <47177AFB.6020103@unsane.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5ea5cca50710180201v3b592b1ayc35f0b271b9929ab@mail.gmail.com> <47175812.2070300@bulinfo.net> <47177AFB.6020103@unsane.co.uk> Cc: freebsd-stable@freebsd.org Subject: Re: connection timed out on freebsd 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 01:49:14 -0000 Thanks very much. This fixed it for me. BTW, does this have the similar meaning against 'netsh interface tcp set global autotuning=disabled' in Windows Server 2008? On 10/18/07, Vince wrote: > Krassimir Slavchev wrote: > > Hi, > > > > try 'sysctl -w net.inet.tcp.rfc1323=0' > > > > Thanks for that, I was having issues connecting to www.freebsd.org from > a 7.0-PRERELEASE box and this fixed it for me. > > > Vince > > > > > Yi Wang wrote: > >> Hi, > > > >> My box is running FreeBSD 7.0 ( upgrade from 6-stable using src ). > > > >> My problem is I can't connect to the network outside the router. eg. > >> www.FreeBSD.org. Neither http nor ftp. But I can ping them. I can > >> assure you that DNS works fine and the firewall is turned off. > > > >> Here's some diagnostic messages: > > > >> # uname -a > >> FreeBSD wangyi.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #2: Wed Oct > >> 17 19:19:47 CST 2007 root@wangyi.com:/usr/obj/usr/src/sys/MYKERNEL > >> i386 > > > >> # ifconfig -a > >> le0: flags=8843 metric 0 mtu 1500 > >> options=8 > >> ether 00:0c:29:3c:47:47 > >> inet 172.20.53.106 netmask 0xffffff00 broadcast 172.20.53.255 > >> inet 192.168.0.106 netmask 0xffffff00 broadcast 192.168.0.255 > >> media: Ethernet autoselect > >> status: active > >> lo0: flags=8049 metric 0 mtu 16384 > >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > >> inet6 ::1 prefixlen 128 > >> inet 127.0.0.1 netmask 0xff000000 > >> vmnet1: flags=8843 metric 0 mtu 1500 > >> ether 00:bd:e4:45:00:01 > >> inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 > > > >> PS: This is the result in vmware. I made a dual boot system and run it > >> in vmware using raw disk. > >> Actually, the real interface is nfe0. > > > >> Sorry for my poor English. > > > >> Thanks very much! > > > > > > > >> ------------------------------------------------------------------------ > > > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > -- Regards, Wang Yi From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 01:56:16 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAB0416A41A for ; Fri, 19 Oct 2007 01:56:16 +0000 (UTC) (envelope-from wangyi6854@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id B222A13C478 for ; Fri, 19 Oct 2007 01:56:16 +0000 (UTC) (envelope-from wangyi6854@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so426091waf for ; Thu, 18 Oct 2007 18:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=y7iBTLEJNa4+78cWpqq39X+0FmTx8RvmGOSoAwORYIw=; b=j6FIpBwUzKC5x/0TifL5nfbbfF2vUHhJJY8nrYxIh+enBbQBJog4bQz7fqgvRY4++0KAo/A8UVyhFzbO3juYskPhWdrd1I15N60YkpMUVqaBzJ7gqygifs9n/XjZggBuRvWnuJl1ca796In39UfpRFyNhg0cL680erPM9O1DVUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QAv3/LnIn/AhVo/+PKUyC8uRsAc1ftxmgIO0Wxkbw+RazFUH9uPXEYF61VoRlL7dt5Y36kH3lORVRMQZYZwsvdQ4d9PQFX0GYJb/rNgsg3Z0hhUlzTW47lHSC84viVXcBzz7av/gP1LQtlhWR2wSH7QbwaDUHnakQDNjXDQoFAc= Received: by 10.115.108.1 with SMTP id k1mr1391090wam.1192758973863; Thu, 18 Oct 2007 18:56:13 -0700 (PDT) Received: by 10.114.203.13 with HTTP; Thu, 18 Oct 2007 18:56:13 -0700 (PDT) Message-ID: <5ea5cca50710181856n187dfd20g869c67d8a2f84eb3@mail.gmail.com> Date: Fri, 19 Oct 2007 09:56:13 +0800 From: "Yi Wang" To: "Krassimir Slavchev" In-Reply-To: <47175812.2070300@bulinfo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5ea5cca50710180201v3b592b1ayc35f0b271b9929ab@mail.gmail.com> <47175812.2070300@bulinfo.net> Cc: freebsd-stable@freebsd.org Subject: Re: connection timed out on freebsd 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 01:56:16 -0000 Sorry, I made a stupid mistake. I made reply to wrong person by accident. On 10/18/07, Krassimir Slavchev wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > try 'sysctl -w net.inet.tcp.rfc1323=0' > > > Yi Wang wrote: > > Hi, > > > > My box is running FreeBSD 7.0 ( upgrade from 6-stable using src ). > > > > My problem is I can't connect to the network outside the router. eg. > > www.FreeBSD.org. Neither http nor ftp. But I can ping them. I can > > assure you that DNS works fine and the firewall is turned off. > > > > Here's some diagnostic messages: > > > > # uname -a > > FreeBSD wangyi.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #2: Wed Oct > > 17 19:19:47 CST 2007 root@wangyi.com:/usr/obj/usr/src/sys/MYKERNEL > > i386 > > > > # ifconfig -a > > le0: flags=8843 metric 0 mtu 1500 > > options=8 > > ether 00:0c:29:3c:47:47 > > inet 172.20.53.106 netmask 0xffffff00 broadcast 172.20.53.255 > > inet 192.168.0.106 netmask 0xffffff00 broadcast 192.168.0.255 > > media: Ethernet autoselect > > status: active > > lo0: flags=8049 metric 0 mtu 16384 > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > > inet6 ::1 prefixlen 128 > > inet 127.0.0.1 netmask 0xff000000 > > vmnet1: flags=8843 metric 0 mtu 1500 > > ether 00:bd:e4:45:00:01 > > inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 > > > > PS: This is the result in vmware. I made a dual boot system and run it > > in vmware using raw disk. > > Actually, the real interface is nfe0. > > > > Sorry for my poor English. > > > > Thanks very much! > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (FreeBSD) > > iD8DBQFHF1gSxJBWvpalMpkRAoVCAJ4juoD3kby8FNCEbGgkmZuc6RR5PQCgrC9U > nXUi2Gp0mEVotL+akuWJ3vc= > =DqJH > -----END PGP SIGNATURE----- > -- Regards, Wang Yi From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 02:11:20 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12FD616A420 for ; Fri, 19 Oct 2007 02:11:20 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd2mo2so.prod.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id D141313C4A7 for ; Fri, 19 Oct 2007 02:11:18 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd2mr1so.prod.shaw.ca (pd2mr1so-qfe3.prod.shaw.ca [10.0.141.110]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JQ400I30WIOEF20@l-daemon> for freebsd-stable@freebsd.org; Thu, 18 Oct 2007 19:08:48 -0600 (MDT) Received: from pn2ml10so.prod.shaw.ca ([10.0.121.80]) by pd2mr1so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JQ4003DEWIO2H30@pd2mr1so.prod.shaw.ca> for freebsd-stable@freebsd.org; Thu, 18 Oct 2007 19:08:49 -0600 (MDT) Received: from hexahedron.daemonology.net ([24.82.201.197]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with SMTP id <0JQ4003CRWINX610@l-daemon> for freebsd-stable@freebsd.org; Thu, 18 Oct 2007 19:08:47 -0600 (MDT) Received: (qmail 2260 invoked from network); Fri, 19 Oct 2007 01:08:33 +0000 Received: from unknown (HELO hexahedron.daemonology.net) (127.0.0.1) by localhost with SMTP; Fri, 19 Oct 2007 01:08:33 +0000 Date: Thu, 18 Oct 2007 18:08:32 -0700 From: FreeBSD Security Officer To: freebsd security , FreeBSD Stable Message-id: <47180390.8000606@freebsd.org> Organization: FreeBSD Project MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Enigmail-Version: 0.95.0 User-Agent: Thunderbird 2.0.0.6 (X11/20070812) Cc: Subject: FreeBSD 6.2 EoL =~ s/January/May/ X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: security-officer@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 02:11:20 -0000 Hello Everyone, In light of the longer-than-expected window between 6.2-RELEASE and 6.2-RELEASE, the End-of-Life date for FreeBSD 6.2 has been adjusted from January 31st, 2008 to May 31st, 2008. As a result, FreeBSD 5.5, FreeBSD 6.1, and FreeBSD 6.2 will all cease to be supported at the end of May 2008. FreeBSD users should plan on upgrading to either FreeBSD 6.3 or FreeBSD 7.0 once those have been released (hopefully by the end of December). FreeBSD 6.3 will be supported until the end of 2009, while FreeBSD 7.0 will be supported until the end of 2008. Colin Percival FreeBSD Security Officer From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 02:31:36 2007 Return-Path: Delivered-To: freebsd-stable@FREEBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0DB016A419 for ; Fri, 19 Oct 2007 02:31:36 +0000 (UTC) (envelope-from LISTSERV@LISTSERV.VT.EDU) Received: from listserv.vt.edu (listserv.ip6.vt.edu [IPv6:2001:468:c80:2105:211:43ff:feda:d769]) by mx1.freebsd.org (Postfix) with ESMTP id A006413C448 for ; Fri, 19 Oct 2007 02:31:36 +0000 (UTC) (envelope-from LISTSERV@LISTSERV.VT.EDU) Received: from listserv.vt.edu (listserv.vt.edu [127.0.0.1]) by listserv.vt.edu (8.13.1/8.13.1/LISTSERV) with ESMTP id l9IMZQao016262 for ; Thu, 18 Oct 2007 22:31:32 -0400 Date: Thu, 18 Oct 2007 22:31:32 -0400 From: "LISTSERV.VT.EDU LISTSERV Server (14.4)" To: freebsd-stable@FREEBSD.ORG Message-ID: Cc: Subject: Message ("Your message dated Fri, 19 Oct 2007 04:12:28...") X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 02:31:37 -0000 Your message dated Fri, 19 Oct 2007 04:12:28 +0200 with subject "Test" has been submitted to the moderator of the HONORS-L list: Russell Shrader . From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 06:26:30 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 223DE16A417; Fri, 19 Oct 2007 06:26:30 +0000 (UTC) (envelope-from lol@chistydom.ru) Received: from comtv.ru (comtv.ru [217.10.32.17]) by mx1.freebsd.org (Postfix) with ESMTP id 70E8713C455; Fri, 19 Oct 2007 06:26:28 +0000 (UTC) (envelope-from lol@chistydom.ru) X-UCL: actv Received: from yoda.org.ru ([83.167.98.162] verified) by comtv.ru (CommuniGate Pro SMTP 4.1.8) with ESMTP id 7103082; Fri, 19 Oct 2007 10:26:27 +0400 Received: from [80.68.244.40] (adm40.relax.ru [80.68.244.40]) (Authenticated sender: llp@soekris.ru) by yoda.org.ru (Postfix) with ESMTP id 0CE1128BDA; Fri, 19 Oct 2007 10:26:32 +0400 (MSD) Message-ID: <47184DD0.6050704@chistydom.ru> Date: Fri, 19 Oct 2007 10:25:20 +0400 From: Alexey Popov User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Scott Long References: <47137D36.1020305@chistydom.ru> <47140906.2020107@FreeBSD.org> <47146FB4.6040306@chistydom.ru> <47147E49.9020301@FreeBSD.org> <47149E6E.9000500@chistydom.ru> <4715035D.2090802@FreeBSD.org> <4715C297.1020905@chistydom.ru> <4715C5D7.7060806@FreeBSD.org> <47165A01.1030806@chistydom.ru> <07289061@ipt.ru> <4717D6BC.5090206@samsco.org> In-Reply-To: <4717D6BC.5090206@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Boris Samorodov , freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: amrd disk performance drop after running under high load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 06:26:30 -0000 Hi Scott Long wrote: >>> interrupt total rate >>> irq6: fdc0 8 0 >>> irq14: ata0 47 0 >>> irq16: uhci0 1428187319 1851 >> ^^^^^^^^^^ ^^^^ [1] >>> irq18: uhci2 12374352 16 >>> irq23: ehci0 3 0 >>> irq46: amr0 11983237 15 >>> irq64: em0 1427141755 1850 >> ^^^^^^^^^^ ^^^^ [2] >>> cpu0: timer 1540896452 1997 >>> cpu1: timer 1542377798 1999 >>> Total 5962960971 7730 >> >> [1] and [2] looks suspicious to me (totals and rate are too close to >> each other and btw to timers). Let the latter (timers) alone. Do you >> use any USB device? Can you try to use other network card? That >> behaviour seems to be an interrupt storm and/or irq collision. > > It's neither. It's a side effect of a feature that FreeBSD abuses for > handling interrupts. Note that amr0 and ehci2 are acting similar. It's > mostly harmless, but it does waste CPU cycles. I wouldn't expect this > on a recent version of FreeBSD, though, at least not from the e1000 > driver. I have this effect on many servers and I believe it is harmless. At once I was trying to reduce CPU usage on the very loaded server and removed USB from kernel. This effect disappeared, but there was no significant difference in CPU usage. I disagree about your words about recent version. I have this effect on many servers with latest FreeBSD-6-stable and em. Actually I have more servers with this effect than without it. With best regards, Alexey Popov From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 06:32:06 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3352816A420 for ; Fri, 19 Oct 2007 06:32:06 +0000 (UTC) (envelope-from m2chrischou@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id 0F25E13C461 for ; Fri, 19 Oct 2007 06:32:05 +0000 (UTC) (envelope-from m2chrischou@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so317290rvb for ; Thu, 18 Oct 2007 23:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=V+qibey+3/AodQmBQ7rc+ICXNb+ocYMCbXQH9rVbl8A=; b=h9HnFYxN13cgiYTA228PMRw03M9m7fFsxxwhqX9cMd2H2Ka67SGIwyp5f7OwPp6bwNtH+lLO5bBIpE69Nqw69ZuMgQtffc60Onfyrj4zTqgMxbqALKUVIMM7FHfO4OgPpWXnSp8DQHTwL8hcKhBdyKS+oZHbEz346IPAYXGS8Y8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Kb6Unuoxhy7k/RXs04QF1I9FnQPlt0Ob9quVGEYEQdLGm8MYIYrbj5eHgWlT9G1DGqOD9zoVgxMicZkK7v9+MUOksWBZGLsSUlb4f93Uni9j4aWHfJcSlGPOwr7IPTvUoym90bHAXT3I7VQYkl+Cq3YcP33hgfT/DwnJvWdS1PA= Received: by 10.114.152.17 with SMTP id z17mr1620676wad.1192773864154; Thu, 18 Oct 2007 23:04:24 -0700 (PDT) Received: by 10.114.26.15 with HTTP; Thu, 18 Oct 2007 23:04:24 -0700 (PDT) Message-ID: <26b05a0e0710182304q5ad2c57eo3b08c56b842ee3fe@mail.gmail.com> Date: Fri, 19 Oct 2007 14:04:24 +0800 From: "Chris Chou" To: "Philipp Ost" In-Reply-To: <4717AECF.40503@smo.de> MIME-Version: 1.0 References: <47177F6C.4060600@smo.de> <4717AECF.40503@smo.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org, Vlad GALU Subject: Re: kldxref: file isn't dynamically-linked -- expected behaviour? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 06:32:06 -0000 I saw the same message when upgrading from RELENG_6 to RELENG_7, and it disappeared when I re-installed the RELENG_7 kernel. On 10/19/07, Philipp Ost wrote: > > Vlad GALU wrote: > > On 10/18/07, Philipp Ost wrote: > > > >>Hi list, > >> > >>I'm currently upgrading from 6.2-STABLE (13 Oct. 2007) to RELENG_7. I > >>did the following after csup'ing my sources: > >># make kernel-toolchain > >># make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=MYKERNEL > >># make -DALWAYS_CHECK_MAKE installkernel KERNCONF=MYKERNEL > >> > >>The last thing 'installkernel' reports is: > >>[...] > >>kldxref /boot/kernel > >>kldxref: file isn't dynamically-linked > >>[...] > >> > >>This message is repeated 514 times... ;-) Is this expected behaviour? > >>Before I do a reboot I would like to make sure "everything works" as I > >>rely on that particular machine. > >> > >>If needed I can provide full logs; MYKERNEL is a cut down version of > >>GENERIC with atapicam, drm, radeondrm, sound added ;-) > >> > >> > >>Thanks in advance for any hint/help! > >> > > > > > > It's harmless. Once you boot with your new RELENG_7 they will > > disappear on the next kernel build/install. > > Thanks a lot. I saw this message for the first time in my life and was a > little bit concerned about it... But if everything seems to be fine I > will give it a try. > > > Regards, > Philipp > -- > www.familie-ost.info/~pj > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 06:55:52 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AD5916A41B for ; Fri, 19 Oct 2007 06:55:52 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 80BE413C44B for ; Fri, 19 Oct 2007 06:55:50 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 053C16464A; Fri, 19 Oct 2007 09:55:49 +0300 (EEST) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47168-09; Fri, 19 Oct 2007 09:55:44 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 3189A64648; Fri, 19 Oct 2007 09:55:44 +0300 (EEST) Message-ID: <471854EF.3070704@bulinfo.net> Date: Fri, 19 Oct 2007 09:55:43 +0300 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.6 (X11/20070927) MIME-Version: 1.0 To: Yi Wang References: <5ea5cca50710180201v3b592b1ayc35f0b271b9929ab@mail.gmail.com> <47175812.2070300@bulinfo.net> <47177AFB.6020103@unsane.co.uk> <5ea5cca50710181849s6c7379a3n474a6852e255139e@mail.gmail.com> In-Reply-To: <5ea5cca50710181849s6c7379a3n474a6852e255139e@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: Vince , freebsd-stable@freebsd.org Subject: Re: connection timed out on freebsd 7.0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 06:55:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Yi Wang wrote: > Thanks very much. This fixed it for me. > Most probably you have an old router which can't handle the more aggressive tcp window scaling algorithm used in RELENG_7. > BTW, does this have the similar meaning against 'netsh interface tcp > set global autotuning=disabled' in Windows Server 2008?. May be if the effect is the same. > > On 10/18/07, Vince wrote: >> Krassimir Slavchev wrote: >>> Hi, >>> >>> try 'sysctl -w net.inet.tcp.rfc1323=0' >>> >> Thanks for that, I was having issues connecting to www.freebsd.org from >> a 7.0-PRERELEASE box and this fixed it for me. >> >> >> Vince >> >>> Yi Wang wrote: >>>> Hi, >>>> My box is running FreeBSD 7.0 ( upgrade from 6-stable using src ). >>>> My problem is I can't connect to the network outside the router. eg. >>>> www.FreeBSD.org. Neither http nor ftp. But I can ping them. I can >>>> assure you that DNS works fine and the firewall is turned off. >>>> Here's some diagnostic messages: >>>> # uname -a >>>> FreeBSD wangyi.com 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #2: Wed Oct >>>> 17 19:19:47 CST 2007 root@wangyi.com:/usr/obj/usr/src/sys/MYKERNEL >>>> i386 >>>> # ifconfig -a >>>> le0: flags=8843 metric 0 mtu 1500 >>>> options=8 >>>> ether 00:0c:29:3c:47:47 >>>> inet 172.20.53.106 netmask 0xffffff00 broadcast 172.20.53.255 >>>> inet 192.168.0.106 netmask 0xffffff00 broadcast 192.168.0.255 >>>> media: Ethernet autoselect >>>> status: active >>>> lo0: flags=8049 metric 0 mtu 16384 >>>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >>>> inet6 ::1 prefixlen 128 >>>> inet 127.0.0.1 netmask 0xff000000 >>>> vmnet1: flags=8843 metric 0 mtu 1500 >>>> ether 00:bd:e4:45:00:01 >>>> inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 >>>> PS: This is the result in vmware. I made a dual boot system and run it >>>> in vmware using raw disk. >>>> Actually, the real interface is nfe0. >>>> Sorry for my poor English. >>>> Thanks very much! >>> >>> >>>> ------------------------------------------------------------------------ >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHGFTvxJBWvpalMpkRAoQbAJ9allqVR0qStpe5jksOJInyh0y/OACghLvy TYYlQ0elmBR+LcU0lAlUmm0= =+Dtg -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 07:56:33 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AE9B16A419 for ; Fri, 19 Oct 2007 07:56:33 +0000 (UTC) (envelope-from mb@imp.ch) Received: from smtp.imp.ch (mx2-ipv6.imp.ch [IPv6:2001:4060:1:1001:209:6bff:fe89:869e]) by mx1.freebsd.org (Postfix) with ESMTP id C523113C46B for ; Fri, 19 Oct 2007 07:56:32 +0000 (UTC) (envelope-from mb@imp.ch) Received: from godot (godot.imp.ch [157.161.4.8]) by smtp.imp.ch (8.13.8/8.13.8/Submit_imp) with ESMTP id l9J7uTmJ000766; Fri, 19 Oct 2007 09:56:30 +0200 (CEST) (envelope-from mb@imp.ch) Date: Fri, 19 Oct 2007 09:56:29 +0200 (CEST) From: Martin Blapp X-X-Sender: mb@godot To: mimedefang@lists.roaringpenguin.com In-Reply-To: <47178E1A.2010902@roaringpenguin.com> Message-ID: <20071019092619.S67363@godot> References: <20071018161238.GC97661@xs4all.net> <47178E1A.2010902@roaringpenguin.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Mimedefang crashes on FreeBSD 6 STABLE, amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 07:56:33 -0000 Hi everybody, I'm trying to get mimedefang running on amd64. But unfortunatly the threaded milter part ('mimedefang') does segfault after some time, normally 1-2 minutes. pid 2331 (mimedefang), uid 1001: exited on signal 11 (core dumped) gdb /idms/bin/mimedefang mimedefang-2331.core #0 0x000000080066389c in pthread_testcancel () from /lib/libpthread.so.2 [New Thread 0x560000 (runnable)] [New Thread 0x599800 (runnable)] [New Thread 0x546c00 (runnable)] [New Thread 0x5ad400 (runnable)] [New Thread 0x5ad000 (runnable)] [New Thread 0x599c00 (runnable)] [New Thread 0x560800 (runnable)] [New Thread 0x55e800 (runnable)] [New Thread 0x55ec00 (runnable)] [New Thread 0x55e400 (runnable)] [New Thread 0x560c00 (runnable)] [New Thread 0x58fc00 (runnable)] [New Thread 0x57fc00 (runnable)] [New Thread 0x599000 (runnable)] [New Thread 0x52ac00 (runnable)] [New Thread 0x57f800 (runnable)] [New Thread 0x58f000 (runnable)] [New Thread 0x57f400 (runnable)] [New Thread 0x58f800 (runnable)] [New Thread 0x52a800 (runnable)] [New Thread 0x57f000 (runnable)] [New Thread 0x546800 (runnable)] [New Thread 0x52a400 (sleeping)] [New Thread 0x52a000 (LWP 100058)] [New Thread 0x524000 (runnable)] [New LWP 100266] Unfortunaltly the stack trace doesn't seem to be very usable: (gdb) where #0 0x000000080066c3fc in kse_thr_interrupt () at kse_thr_interrupt.S:2 #1 0x000000080065390a in sig_daemon (arg=0x0) at /usr/src/lib/libpthread/thread/thr_sig.c:214 #2 0x0000000800661e2e in kse_sched_single (kmbx=0x521318) at /usr/src/lib/libpthread/thread/thr_kern.c:886 #3 0x0000000000000000 in ?? () Cannot access memory at address 0x7fffffbff000 (gdb) frame 2 #2 0x0000000800661e2e in kse_sched_single (kmbx=0x521318) at /usr/src/lib/libpthread/thread/thr_kern.c:886 886 pthread_exit(curthread->start_routine(curthread->arg)); (gdb) p kmbx $1 = (struct kse_mailbox *) 0x521318 (gdb) p *kmbx $2 = {km_version = 0, km_curthread = 0x0, km_completed = 0x0, km_sigscaught = {__bits = {0, 0, 0, 0}}, km_flags = 19, km_func = 0x800661560 , km_stack = {ss_sp = 0x7fffff9ff000
, ss_size = 2097152, ss_flags = 0}, km_udata = 0x51c600, km_timeofday = {tv_sec = 0, tv_nsec = 0}, km_quantum = 0, km_lwp = 100058, __spare2__ = {0, 0, 0, 0, 0, 0, 0}} I've tried to replace libpthread.so.2 with libc_r.6 or libthr.2, but this doesn't help at all, I get smiliar segfaults. libc_r.6 is a userland threading library, so it's definitly not the kernel which has a problem. Are there known bugs with mimedefang on 64bit architectures ? -- Martin Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 08:13:30 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A52216A41B for ; Fri, 19 Oct 2007 08:13:30 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (mail.1command.com [75.160.109.226]) by mx1.freebsd.org (Postfix) with ESMTP id DDAAE13C44B for ; Fri, 19 Oct 2007 08:13:29 +0000 (UTC) (envelope-from chris#@1command.com) Received: from mail.1command.com (localhost.1command.com [127.0.0.1]) by mail.1command.com (8.13.3/8.13.3) with ESMTP id l9J8DG0c042601 for ; Fri, 19 Oct 2007 01:13:24 -0700 (PDT) (envelope-from chris#@1command.com) Received: (from www@localhost) by mail.1command.com (8.13.3/8.13.3/Submit) id l9J8DGLi042600 for freebsd-stable@freebsd.org; Fri, 19 Oct 2007 01:13:16 -0700 (PDT) (envelope-from chris#@1command.com) Received: from hitme.hitometer.net (hitme.hitometer.net [75.160.109.235]) by webmail.1command.com (H.R. Communications Messaging System) with HTTP; Fri, 19 Oct 2007 01:13:16 -0700 Message-ID: <20071019011316.5ffmycud8g0oggsg@webmail.1command.com> X-Priority: 3 (Normal) Date: Fri, 19 Oct 2007 01:13:16 -0700 From: "Chris H." To: freebsd-stable@freebsd.org References: <20071004165755.GA1049@pp.htv.fi> <47120D83.1010703@FreeBSD.org> <20071015203202.GA17964@pp.htv.fi> <20071016004637.GA79351@cdnetworks.co.kr> <20071016185714.GB2186@pp.htv.fi> <20071016130146.pfyan4vs5cwgsoc0@webmail.1command.com> <20071016202251.GC4047@lava.net> <47151FF7.2080501@FreeBSD.org> In-Reply-To: <47151FF7.2080501@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: H.R. Communications Internet Messaging System (HCIMS) 4.1 Professional (not for redistribution) / FreeBSD-5.5 Subject: Re: Reproducable, possibly NFS related, fatal double fault in 6.2-R-p7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 08:13:30 -0000 Quoting Kris Kennaway : > Clifton Royston wrote: >> On Tue, Oct 16, 2007 at 01:01:46PM -0700, Chris H. wrote: >>> excerpt from this list titled: NFS == lock && reboot, that I posted >>> follows: >>> >>> ------8<---SNIP---8<-----SNIP-----8<------- >>> # uname -a >>> FreeBSD host.domain.tld 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan >>> 26 16:27:14 PST 2007 >>> >>> Greetings, >>> Does anyone know when NFS and friends will be working again? I >>> haven't been able >>> to /safely/ use it from 4.8 on. I remember some talk on the list >>> sometime ago and >>> then it seemed to be resolved, as the discussion ended. So I thought it was >>> fixed. Seems not. :( >>> >>> My scenario; >>> mount host off root: >>> mount script exec'd follows... >>> >>> #!/bin/sh - >>> mount -t nfs host.domain.tld:/ /host >>> mount -t nfs host.domain.tld:/var /host/var >>> >>> confirm mount... >>> >>> # ls /host >>> .snap COPYRIGHT bin >>> ... >>> usr var tmp >>> >>> OK looks good... >>> >>> # cp /path/to/approx/10Mb/file /host/path/to/dest/dir/ >>> >>> Fatal double fault >>> eis 0x0blah >>> eiblah blah0x >>> panic double fault >>> no dump device defined >>> rebooting in 15sec... >>> >>> Hmmm... that's not good. :( >>> >>> ------8<---SNIP---8<-----SNIP-----8<------- >>> >>> My final solution was to change the lines in /etc/rc.conf >>> from: >>> nfs_client_enable="YES" >>> nfs_reserved_port_only="YES" >>> nfs_server_enable="YES" >>> rpc_lockd_enable="YES" >>> rpc_statd_enable="YES" >>> rpcbind_enable="YES" >>> >>> to: >>> nfs_client_enable="YES" >>> nfs_reserved_port_only="YES" >>> nfs_server_enable="YES" >>> #rpc_lockd_enable="YES" >>> #rpc_statd_enable="YES" >>> rpcbind_enable="YES" >>> >>> Making those changes ended the "Fatal double fault && reboot in 15 >>> seconds..." >> >> Thanks for this very timely mention! The cluster of servers I am >> about to upgrade from 4.8 to 6.2 relies heavily on >> NFS to an old Netapp. If I have got to disable rpc_lockd and >> rpc_statd, it's good to know that now! >> Can I ask, can anybody confirm that they're running 6.2 on NFS >> successfully *with* lockd and statd? > > Er, yes, of course it does. The old message he is quoting is bogus > on its own, While I'll grant you that I haven't *yet* found/taken the time to create a dump device and re-enable rpd_lockd && rpc_statd && cp 10Mb file to mount point to produce an *instantaneous* "Fatal double fault". I don't think it's fair to label my original post entirely /bogus/ - especially in light of the recent post I replied to. Which seems to have some very common ground. I should probably mention that since my last posting (my original thread), I have some 20+ RELENG_6_2 boxen that *do* have rpd_lockd + rpc_statd enabled. Yet none of them produce a "Fatal double fault". They are all Tyan SMP boards with dual onboard fxp's - as opposed to the Nvidia UP which has a single onboard nve. They are all inter-connected via NFS. I have a 750Gb drive hanging off the /problematic/ Nvidia board, that I had intended to use for NFS back-up's. But given the NFS issue I had with it, it didn't seem to be the best solution. If anyone felt like throwing me a "cheat sheet" for creating a dump device out of that drive and a "quickie" for producing a backtrace. I'm sure I'd be better able to find the required time to produce the required information. I'm sorry. It's just that I'm a hundred million miles away from that right now. As I've been building several large web applications, and their deadline is fast approaching. FWIW I bounced all the servers today, and therefore have recent /verbose/ dmesg's. Should any of the information they provide, be of any help/use to anyone. Take care. :) --Chris > I don't know if he ever was able to provide meaningful traces but it > may well be nve as in the upthread discussion. > > Kris > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- panic: kernel trap (ignored) From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 08:49:05 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1930716A419; Fri, 19 Oct 2007 08:49:05 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id A4F4413C455; Fri, 19 Oct 2007 08:49:04 +0000 (UTC) (envelope-from max@love2party.net) Received: from amd64.laiers.local (dslb-088-066-001-171.pools.arcor-ip.net [88.66.1.171]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis) id 0ML21M-1IinXT17cX-0002E0; Fri, 19 Oct 2007 10:49:03 +0200 From: Max Laier Organization: FreeBSD To: freebsd-net@freebsd.org Date: Fri, 19 Oct 2007 10:48:52 +0200 User-Agent: KMail/1.9.7 References: <200709302232.34505.max@love2party.net> <200710160401.18429.max@love2party.net> <200710160445.10993.max@love2party.net> In-Reply-To: <200710160445.10993.max@love2party.net> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart20574124.tX2gCCj7zd"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200710191048.58350.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+YtEYTJ+vliaP0yCf3lrLV+FLvaLRG7u+GnXi 2EggaoR3g/x/9LyhxS+zjdD6HvIb9lbrZNZtDgOkdNZxA4Os1X 2eC8Ufd9canT4Nf8/JCS4uhZufRFP4PT17CP4FsZ+0= Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: libpcap/tcpdump update X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 08:49:05 -0000 --nextPart20574124.tX2gCCj7zd Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Okay. libpcap 0.9.8 and tcpdump 3.9.8 are now imported into HEAD and=20 RELENG_7. Is anyone eager to pull it down to RELENG_6 as well, because I=20 don't have the resources available at the moment. The update was crucial=20 to me in HEAD and RELENG_7 to get a working pflog tcpdump, but RELENG_6=20 isn't broken for me ... Any takers? If not I might get round to it eventually, but I'd prefer=20 somebody with genuine interest would step up. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart20574124.tX2gCCj7zd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHGG96XyyEoT62BG0RAh9rAJkBE0NX4lEWzlZAy0MmoszGbp7HUACfechP DNfKc/Hc/WruXfvnIPRFFTY= =Ebx6 -----END PGP SIGNATURE----- --nextPart20574124.tX2gCCj7zd-- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 09:18:15 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AA5516A421; Fri, 19 Oct 2007 09:18:15 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from solow.pil.dk (relay.pil.dk [195.41.47.164]) by mx1.freebsd.org (Postfix) with ESMTP id ACABC13C44B; Fri, 19 Oct 2007 09:17:22 +0000 (UTC) (envelope-from henrik@brixandersen.dk) Received: from tirith.brixandersen.dk (osgiliath.brixandersen.dk [87.53.223.189]) by solow.pil.dk (Postfix) with ESMTP id 0E4F11CC0C5; Fri, 19 Oct 2007 10:58:44 +0200 (CEST) Received: by tirith.brixandersen.dk (Postfix, from userid 1001) id 4172517036; Fri, 19 Oct 2007 10:58:43 +0200 (CEST) Date: Fri, 19 Oct 2007 10:58:42 +0200 From: Henrik Brix Andersen To: Max Laier Message-ID: <20071019085842.GB830@tirith.brixandersen.dk> Mail-Followup-To: Max Laier , freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org References: <200709302232.34505.max@love2party.net> <200710160401.18429.max@love2party.net> <200710160445.10993.max@love2party.net> <200710191048.58350.max@love2party.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <200710191048.58350.max@love2party.net> X-PGP-Key: http://www.brixandersen.dk/files/HenrikBrixAndersen.asc User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: libpcap/tcpdump update X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 09:18:15 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Max, On Fri, Oct 19, 2007 at 10:48:52AM +0200, Max Laier wrote: > Okay. libpcap 0.9.8 and tcpdump 3.9.8 are now imported into HEAD and=20 > RELENG_7. Thank you for updating these two components! Regards, Brix --=20 Henrik Brix Andersen --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: GnuPG signed iD8DBQFHGHHCv+Q4flTiePgRAtTJAJ9LlVtDrdLGqiF2OPk62ECZWtvcUgCePgVc sfhKRPX8gyKZv4ruYX9YR3s= =nCr6 -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 10:00:44 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B3EE16A41B; Fri, 19 Oct 2007 10:00:44 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 493E513C447; Fri, 19 Oct 2007 10:00:43 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id CBD9943C5ED; Fri, 19 Oct 2007 13:00:41 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9Gg3a4QBfL4; Fri, 19 Oct 2007 13:00:41 +0300 (EEST) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 6D5CE43C363; Fri, 19 Oct 2007 13:00:41 +0300 (EEST) Message-ID: <47188041.2040405@icyb.net.ua> Date: Fri, 19 Oct 2007 13:00:33 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: Ivan Voras References: <1192728201.00816051.1192716602@10.7.7.3> <1192728215.00816057.1192717201@10.7.7.3> <1192728219.00816060.1192717802@10.7.7.3> In-Reply-To: <1192728219.00816060.1192717802@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Mounting smbfs as user? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 10:00:44 -0000 on 18/10/2007 17:29 Ivan Voras said the following: > Krassimir Slavchev wrote: >> Hi, >> >> Ivan Voras wrote: > > >>> The same command works under root, and the appropriate klds are loaded: >> Only superuser can load modules. If you try to load module by regular >> user you will get: kldload: can't load xxxx.ko: Operation not permitted > > > To clarify: the modules were loaded before I tried either as user or as > root. > This doesn't seem to be entirely smbfs-specific, but rather specific to internal workings of iconv modules. Here's some information from a while ago: http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031501.html I didn't get any useful information since then and still have to use a workaround of doing any mount as root to get iconv initialized first and then all subsequent user mounts are successful. While on one hand this seems like only a minor annoyance, on the other hand it indicates a problem in iconv internal workings and this should be considered a bug as this breaks a user-mount feature. Probably a PR is due here, I was just too lazy to open it when I first hit the problem. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 10:05:18 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A62E216A419 for ; Fri, 19 Oct 2007 10:05:18 +0000 (UTC) (envelope-from remy.nonnenmacher@activnetworks.com) Received: from mallaury.nerim.net (mallaury.ipv6.nerim.net [IPv6:2001:7a8:1:5::82]) by mx1.freebsd.org (Postfix) with ESMTP id 0C15013C48E for ; Fri, 19 Oct 2007 10:05:18 +0000 (UTC) (envelope-from remy.nonnenmacher@activnetworks.com) Received: from rn.activnetworks.com (anwadmin.net8.nerim.net [213.41.185.85]) by mallaury.nerim.net (Postfix) with ESMTP id 540154F437; Fri, 19 Oct 2007 12:05:10 +0200 (CEST) Message-ID: <4718815C.9050102@activnetworks.com> Date: Fri, 19 Oct 2007 12:05:16 +0200 From: Remy Nonnenmacher User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.4) Gecko/20070709 SeaMonkey/1.1.2 MIME-Version: 1.0 To: josh.carroll@gmail.com References: <8cb6106e0710170911x77e72e95qb322f51d84a31813@mail.gmail.com> <8cb6106e0710180910u110a1c58tc18f36460ab74776@mail.gmail.com> In-Reply-To: <8cb6106e0710180910u110a1c58tc18f36460ab74776@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ULE vs. 4BSD in RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 10:05:18 -0000 Josh Carroll wrote: >> I have noticed some performance discrepancies with ULE and 4BSD in >> RELENG_7, specifically with ffmpeg. I have all the kernel debugging >> options disabled, and as I understand it, the userland debugging is >> all off by default in RELENG_7. > > Here are a couple of additional benchmarks comparing the schedulers on > my system: > > make -j8 -DNOCLEAN buildkernel > 4BSD: 3:25.56 > ULE: 3:39.20 > Difference: -6.6 % > > ubench (CPU): > 4BSD: 1705258 > ULE: 1713510 > Difference: +0.48 % > > super-smack (select-key 10 10000): > 4BSD: 55044.38 > ULE: 68085.21 > Difference: +23.69 % > > super-smack (update-select 10 10000): > 4BSD: 16734.15 > ULE: 17631.43 > Difference: +5.36 % > > So at least for the MySQL super-smack benchmark (I know it's a rather > contrived benchmark), ULE is significantly faster for select-key and a > decent improvement for update-select. ubench is about the same, but > building a kernel is also slower with ULE. > Here are some buildworld measures (extract from a buildaton): i386: 6.2-RELEASE -j4: 746.08 real 1996.38 user 468.91 sys 1535.1 RSA -j6: 595.31 real 1957.31 user 539.24 sys 2304.9 RSA -j8: 534.21 real 1957.76 user 567.06 sys 3068.5 RSA M1000: 492.64 real 1956.58 user 587.41 sys 100: 526.22 real 1936.98 user 559.49 sys 3073.8 RSA M100: 474.26 real 1947.09 user 563.95 sys -j10: 550.18 real 1975.54 user 588.33 sys -j12: 550.23 real 1976.88 user 602.65 sys -j16: 559.22 real 1972.19 user 634.29 sys i386: 7.0-current (as of 10/16/2007) - SCHED_4BSD -j4: 1072.64 real 2880.29 user 561.13 sys 1495.7 RSA -j6: 842.91 real 2813.75 user 638.91 sys 2244.8 RSA -j8: 758.48 real 2824.23 user 704.00 sys 2990.1 RSA M1000: 696.12 real 2820.53 user 706.97 sys 100: 752.58 real 2809.97 user 685.35 sys 2993.2 RSA M100: 666.58 real 2804.72 user 714.01 sys -j10: 763.82 real 2843.44 user 743.77 sys -j12: 785.12 real 2845.11 user 770.31 sys -j16: 805.02 real 2848.06 user 819.53 sys i386: 7.0-current (as of 10/16/2007) - SCHED_ULE -j4: 1047.00 real 2857.59 user 486.93 sys 1494.2 RSA -j6: 831.10 real 2793.94 user 524.58 sys 2242.6 RSA -j8: 803.34 real 2796.46 user 552.56 sys 2991.0 RSA M1000: 709.77 real 2793.20 user 572.27 sys 100: 785.18 real 2765.14 user 545.57 sys 2991.4 RSA M100: 707.09 real 2769.88 user 572.92 sys -j10: 813.36 real 2808.13 user 587.51 sys -j12: 824.23 real 2817.60 user 618.00 sys -j16: 856.11 real 2847.68 user 721.97 sys --------- Conditions: Machine: Intel SR2520 - S5000PAL, 2xE5345 (8 cores, 2.33Ghz), 8G, 1xsata) Generic kernel; /usr/obj/* removed after each run; Runs done after a reboot; softupdates on all fs; RSA = openssl speed -multi rsa1024; M1000 = noatime /usr, kern.hz=1000, tar cf /dev/null /usr/src before run. M100 = idem with kern.hz=100 100 = generic test with kern.hz=100 (To be compared with -j8 line). (M variants to minimize disk contention reading src; Variants measured only on #-core sweetspot (8 here)). --------- Remarks: - There seems to be a loss of efficiency on openssl code. Not scheduler related. An indication of compiler change ? - 6.2 results only for information. RSA left aside, there is no direct equivalence between buildworld workload nor duration/level of parallelism between 6.2 and 7.0. Also, Amdhal's law limits efficiency on increasing cores number. - ULE tends to be more efficient than 4BSD when there are available cores (1.0244 and 1.0142 ratio on -j4 and -j6) but less efficient as load increase (0.9807 to 0.9403 from -j8 to -j16). - ULE seems to be less sensitive to Hz than 4BSD (1.0037 from 1.0443 on M1000/M100 variants ratio). (Beware of side effects on time/delay bandwidth estimator at network level). -- RN. IeM From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 10:08:53 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78B5A16A41B for ; Fri, 19 Oct 2007 10:08:53 +0000 (UTC) (envelope-from mb@imp.ch) Received: from smtp.imp.ch (mx2-ipv6.imp.ch [IPv6:2001:4060:1:1001:209:6bff:fe89:869e]) by mx1.freebsd.org (Postfix) with ESMTP id 200AC13C465 for ; Fri, 19 Oct 2007 10:08:52 +0000 (UTC) (envelope-from mb@imp.ch) Received: from godot (godot.imp.ch [157.161.4.8]) by smtp.imp.ch (8.13.8/8.13.8/Submit_imp) with ESMTP id l9JA8oht071964; Fri, 19 Oct 2007 12:08:51 +0200 (CEST) (envelope-from mb@imp.ch) Date: Fri, 19 Oct 2007 12:08:50 +0200 (CEST) From: Martin Blapp X-X-Sender: mb@godot To: mimedefang@lists.roaringpenguin.com In-Reply-To: <20071019092619.S67363@godot> Message-ID: <20071019115339.M67363@godot> References: <20071018161238.GC97661@xs4all.net> <47178E1A.2010902@roaringpenguin.com> <20071019092619.S67363@godot> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Mimedefang crashes on FreeBSD 6 STABLE, amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 10:08:53 -0000 A kdump output shows always the same output. The file descriptor '108/0x6c' doesn't look very valid .... ------------------------------------------------------------------------------------------------------ 36626 mimedefang RET kse_release 0 36626 mimedefang RET kse_release 0 36626 mimedefang RET fork 0 36626 mimedefang CALL kse_release(0x537f70) 36626 mimedefang RET kse_release 0 36626 mimedefang RET kse_release 0 36626 mimedefang CALL kse_release(0x521f70) 36626 mimedefang CALL gettimeofday(0x7fffff5f8eb0,0) 36626 mimedefang CALL kse_release(0x53ff70) 36626 mimedefang CALL kse_release(0x53bf70) 36626 mimedefang RET kse_release 0 36626 mimedefang RET kse_release 0 36626 mimedefang CALL kse_release(0x521f70) 36626 mimedefang CALL getpid 36626 mimedefang RET getpid 36626/0x8f12 36626 mimedefang CALL sendto(0x3,0x7fffff5f93b0,0x6c,0,0,0) 36626 mimedefang GIO fd 3 wrote 108 bytes "<20>Oct 19 11:55:57 mimedefang[36626]: 5422080 -> 0x540c00: mimedefang.c(1924): EXIT cleanup: SMFIS_CONTINUE" 36626 mimedefang RET sendto 108/0x6c 36626 mimedefang CALL gettimeofday(0x7fffff5f8f10,0) 36626 mimedefang RET gettimeofday 0 36626 mimedefang CALL getpid 36626 mimedefang RET getpid 36626/0x8f12 36626 mimedefang CALL sendto(0x3,0x7fffff5f9410,0x6c,0,0,0) 36626 mimedefang GIO fd 3 wrote 108 bytes "<20>Oct 19 11:55:57 mimedefang[36626]: 5422080 -> 0x540c00: mimedefang.c(1888): EXIT mfclose: SMFIS_CONTINUE" 36626 mimedefang RET sendto 108/0x6c 36626 mimedefang PSIG SIGSEGV SIG_DFL 36626 mimedefang CALL kse_thr_interrupt(0,0x4,0xb) 36626 mimedefang NAMI "/var/core/mimedefang-36626.core" ------------------------------------------------------------------------------------------------------ "<20>Oct 19 11:53:03 mimedefang[33960]: 5422080 -> 0x51de00: mimedefang.c(1922): ENTER cleanup" 33960 mimedefang RET sendto 93/0x5d 33960 mimedefang CALL gettimeofday(0x7fffff5f8eb0,0) 33960 mimedefang RET gettimeofday 0 33960 mimedefang CALL getpid 33960 mimedefang RET getpid 33960/0x84a8 33960 mimedefang CALL sendto(0x3,0x7fffff5f93b0,0x6c,0,0,0) 33960 mimedefang GIO fd 3 wrote 108 bytes "<20>Oct 19 11:53:03 mimedefang[33960]: 5422080 -> 0x51de00: mimedefang.c(1924): EXIT cleanup: SMFIS_CONTINUE" 33960 mimedefang RET sendto 108/0x6c 33960 mimedefang CALL gettimeofday(0x7fffff5f8f10,0) 33960 mimedefang RET gettimeofday 0 33960 mimedefang CALL getpid 33960 mimedefang RET getpid 33960/0x84a8 33960 mimedefang CALL sendto(0x3,0x7fffff5f9410,0x6c,0,0,0) 33960 mimedefang GIO fd 3 wrote 108 bytes "<20>Oct 19 11:53:03 mimedefang[33960]: 5422080 -> 0x51de00: mimedefang.c(1888): EXIT mfclose: SMFIS_CONTINUE" 33960 mimedefang RET sendto 108/0x6c 33960 mimedefang PSIG SIGSEGV SIG_DFL 33960 mimedefang CALL kse_thr_interrupt(0,0x4,0xb) 33960 mimedefang NAMI "/var/core/mimedefang-33960.core" ------------------------------------------------------------------------------------------------------ Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 11:31:31 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDF1D16A420 for ; Fri, 19 Oct 2007 11:31:31 +0000 (UTC) (envelope-from mb@imp.ch) Received: from smtp.imp.ch (mx2-ipv6.imp.ch [IPv6:2001:4060:1:1001:209:6bff:fe89:869e]) by mx1.freebsd.org (Postfix) with ESMTP id 46EB413C46B for ; Fri, 19 Oct 2007 11:31:31 +0000 (UTC) (envelope-from mb@imp.ch) Received: from godot (godot.imp.ch [157.161.4.8]) by smtp.imp.ch (8.13.8/8.13.8/Submit_imp) with ESMTP id l9JBVSLK025929; Fri, 19 Oct 2007 13:31:29 +0200 (CEST) (envelope-from mb@imp.ch) Date: Fri, 19 Oct 2007 13:31:28 +0200 (CEST) From: Martin Blapp X-X-Sender: mb@godot To: mimedefang@lists.roaringpenguin.com In-Reply-To: <20071019115339.M67363@godot> Message-ID: <20071019132946.Y67363@godot> References: <20071018161238.GC97661@xs4all.net> <47178E1A.2010902@roaringpenguin.com> <20071019092619.S67363@godot> <20071019115339.M67363@godot> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: [Mimedefang] Re: Mimedefang crashes on FreeBSD 6 STABLE, amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 11:31:31 -0000 Hi, Looks like I found the problem and it was a local patch - ouch. Some casts that worked in i386 didn't work on amd64 ... sigh. Sorry for the noise. -- Martin From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 12:25:19 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BA2916A419 for ; Fri, 19 Oct 2007 12:25:19 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (mail.ismobile.com [62.119.44.68]) by mx1.freebsd.org (Postfix) with ESMTP id BFEBD13C45A for ; Fri, 19 Oct 2007 12:25:17 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (localhost [127.0.0.1]) by mail.ismobile.com (Postfix) with ESMTP id 2626933C03 for ; Fri, 19 Oct 2007 14:06:14 +0200 (CEST) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=ismobile.com; h=received:date:from:to:subject:message-id:x-mailer:mime-version:content-type; q=dns/txt; s=selector1; bh=zUlZ1lqIhfT44oPas9DDNYpTWcE=; b=MFa+FZsXWazNO0wcG6Mt5PiwDIVdnDQBszRl8uvbhTty5Qn8o4uz+6uz6U7qtjaq0ii/pn42QqUG848y9jcmUKPo/xKi+ZjcN/0xCcHc+8XrpRgd4KRrMd3Z0hOH4W/dAENg9yeMoveuI47Ag3DgdP5rmpXKVD+9zX4qEj4IIcQ= Received: from [172.16.2.129] (viglaf.hq.ismobile.com [172.16.2.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTP id 1545E33C02 for ; Fri, 19 Oct 2007 14:06:14 +0200 (CEST) Date: Fri, 19 Oct 2007 14:06:13 +0200 From: Goran Lowkrantz To: freebsd-stable@freebsd.org Message-ID: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========5CCE4080B8AFC40C1907==========" Subject: em 6.6.6 - watchdog timeout X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 12:25:19 -0000 --==========5CCE4080B8AFC40C1907========== Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, After the update of em to 6.6.6 last, I experience watchdog timeouts on a=20 server running 6-STABLE. I have two identical servers with Intel D915GAV boards. Both have Intel=20 PRO/1000 PCI-Express network cards. Server balder: em0: port=20 0xac00-0xac1f mem 0xff600000-0xff61ffff,0xff620000-0xff63ffff irq 16 at=20 device 0.0 on pci5 em0: Ethernet address: 00:1b:21:00:48:c4 em0: [FAST] # vmstat -i interrupt total rate irq1: atkbd0 3 0 irq4: sio0 2 0 irq6: fdc0 12 0 irq14: ata0 68 0 irq16: em0 uhci3 219828879 450 irq19: uhci1++ 4287947 8 irq22: ahc0 232717293 476 irq23: uhci0 ehci0 1 0 cpu0: timer 976552804 2000 Total 1433387009 2935 # netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs=20 Coll em0 1500 00:1b:21:00:48:c4 209880531 773 206555522 84 = 0 em0 1500 10.255.253/24 balder 215210996 - 212337968 - = - plip0 1500 0 0 0 0=20 0 lo0 16384 12040055 0 12055326 0=20 0 lo0 16384 fe80:3::1 fe80:3::1 0 - 0 -=20 - lo0 16384 localhost ::1 6 - 6 -=20 - lo0 16384 your-net localhost 6249979 - 6249980 -=20 - 00:00.0 Host bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL Memory=20 Controller Hub (rev 04) 00:01.0 PCI bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL PCI Express=20 Root Port (rev 04) 00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL=20 Integrated Graphics Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)=20 PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)=20 PCI Express Port 2 (rev 03) 00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)=20 PCI Express Port 3 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)=20 PCI Express Port 4 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6=20 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6=20 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6=20 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6=20 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6=20 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface = Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6=20 Family) IDE Controller (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA=20 Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus=20 Controller (rev 03) 05:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet=20 Controller (Copper) (rev 06) 06:01.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U (rev = 01) Server midgard: em0: port=20 0xac00-0xac1f mem 0xff500000-0xff51ffff,0xff520000-0xff53ffff irq 16 at=20 device 0.0 on pci5 em0: Ethernet address: 00:15:17:0e:05:f7 admglz@midgard> vmstat -i interrupt total rate irq1: atkbd0 11 0 irq4: sio0 2142746 0 irq6: fdc0 14 0 irq14: ata0 252 0 irq16: em0+ 666640101 164 irq19: atapci1+ 7932757 1 irq22: ahc0 87074425 21 cpu0: timer 3807810138 937 Total 4571600444 1125 admglz@midgard> netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs=20 Coll em0 1500 00:15:17:0e:05:f7 343771280 0 474609731 0 = 0 em0 1500 10.255.253/24 midgard 347467842 - 478700485 - = - plip0 1500 0 0 0 0=20 0 lo0 16384 16821054 0 16947668 0=20 0 lo0 16384 fe80:3::1 fe80:3::1 0 - 0 -=20 - lo0 16384 localhost ::1 2610 - 2610 -=20 - lo0 16384 your-net localhost 12616879 - 12616879 -=20 - lo0 16384 10.255.253.12 appsrv1 0 - 0 -=20 - lo0 16384 10.255.253.10 ca.glz.hidden-pow 0 - 0 -=20 - lo0 16384 10.255.253.11 test 0 - 0 -=20 - lo0 16384 10.255.253.13 secure 0 - 0 -=20 - lo0 16384 10.255.253.18 rscds.hidden-powe 7 - 0 -=20 - midgard# lspci 00:00.0 Host bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL Memory=20 Controller Hub (rev 04) 00:01.0 PCI bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL PCI Express=20 Root Port (rev 04) 00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL=20 Integrated Graphics Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)=20 PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)=20 PCI Express Port 2 (rev 03) 00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)=20 PCI Express Port 3 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)=20 PCI Express Port 4 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6=20 Family) USB UHCI #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6=20 Family) USB UHCI #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6=20 Family) USB UHCI #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6=20 Family) USB UHCI #4 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6=20 Family) USB2 EHCI Controller (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface = Bridge (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6=20 Family) IDE Controller (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA=20 Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus=20 Controller (rev 03) 01:00.0 SCSI storage controller: Triones Technologies, Inc. Unknown device=20 2310 (rev 02) 05:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet=20 Controller (Copper) (rev 06) 06:01.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U (rev = 01) 06:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host=20 Controller (rev 46) When running netstat between servers balder and midgard, server balder get=20 watchdog timeouts and resets the connection for a few seconds. Oct 19 13:12:47 balder kernel: em0: watchdog timeout -- resetting Oct 19 13:12:47 balder kernel: em0: link state changed to DOWN Oct 19 13:12:51 balder kernel: em0: link state changed to UP I have switched the cable between the two servers but get exactly the same=20 problem. The switch is a Netgear GS108T with the latest firmware. The resp. dmesg.boot are attached. Please let me know if there is any other information I can supply to clear=20 this. Best regards, G=F6ran L ................................................... the future isMobile Goran Lowkrantz System Architect, iaMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Lule=E5, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ............................................... --==========5CCE4080B8AFC40C1907========== Content-Type: application/octet-stream; name="balder.dmesg.boot" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="balder.dmesg.boot"; size=7785 V2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgdm5scnUnIHRvIHN0 b3AuLi5kb25lCldhaXRpbmcgKG1heCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYGJ1 ZmRhZW1vbicgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0 ZW0gcHJvY2VzcyBgc3luY2VyJyB0byBzdG9wLi4uClN5bmNpbmcgZGlza3MsIHZub2RlcyByZW1h aW5pbmcuLi4zIDMgMiAyIDAgMCAwIGRvbmUKQWxsIGJ1ZmZlcnMgc3luY2VkLgpHRU9NX01JUlJP UjogRGV2aWNlIGdtMHMxOiBwcm92aWRlciBtaXJyb3IvZ20wczEgZGVzdHJveWVkLgpVcHRpbWU6 IDZtMTdzCkdFT01fTUlSUk9SOiBEZXZpY2UgZ20wczEgZGVzdHJveWVkLgpSZWJvb3RpbmcuLi4K Q29weXJpZ2h0IChjKSAxOTkyLTIwMDcgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA2LjItU1RBQkxFICMyNTogRnJpIE9jdCAxMiAxNDoz NzozOSBDRVNUIDIwMDcKICAgIHJvb3RAbWlkZ2FyZC5nbHouaGlkZGVuLXBvd2Vycy5jb206L3Vz ci9vYmovdXNyL3NyYy9zeXMvQkFMREVSClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDEx OTMxODIgSHogcXVhbGl0eSAwCkNQVTogSW50ZWwoUikgQ2VsZXJvbihSKSBDUFUgMy4yMEdIeiAo MzIwMC4xMS1NSHogNjg2LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQg PSAweGY0OSAgU3RlcHBpbmcgPSA5CiAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBT RSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0Uz NixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+CiAgRmVh dHVyZXMyPTB4NjUxZDxTU0UzLFJTVkQyLE1PTixEU19DUEwsVE0yLENOWFQtSUQsQ1gxNix4VFBS PgogIEFNRCBGZWF0dXJlcz0weDIwMTAwMDAwPE5YLExNPgogIEFNRCBGZWF0dXJlczI9MHgxPExB SEY+CnJlYWwgbWVtb3J5ICA9IDIxMzgyMzg5NzYgKDIwMzkgTUIpCmF2YWlsIG1lbW9yeSA9IDIw ODc0MzIxOTIgKDE5OTAgTUIpCkFDUEkgQVBJQyBUYWJsZTogPElOVEVMICBEOTE1R0FWID4KaW9h cGljMCA8VmVyc2lvbiAyLjA+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZAprYmQxIGF0IGtiZG11 eDAKYWNwaTA6IDxJTlRFTCBEOTE1R0FWPiBvbiBtb3RoZXJib2FyZAphY3BpMDogUG93ZXIgQnV0 dG9uIChmaXhlZCkKVGltZWNvdW50ZXIgIkFDUEktc2FmZSIgZnJlcXVlbmN5IDM1Nzk1NDUgSHog cXVhbGl0eSAxMDAwCmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBw b3J0IDB4NDA4LTB4NDBiIG9uIGFjcGkwCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKcDR0Y2Mw OiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTAKcGNpYjA6IDxBQ1BJIEhv c3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMApwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAxLjAg b24gcGNpMApwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQphZ3AwOiA8SW50ZWwgODI5MTVH ICg5MTVHIEdNQ0gpIFNWR0EgY29udHJvbGxlcj4gcG9ydCAweGVjMDAtMHhlYzA3IG1lbSAweGZm NDgwMDAwLTB4ZmY0ZmZmZmYsMHhkMDAwMDAwMC0weGRmZmZmZmZmLDB4ZmY0NDAwMDAtMHhmZjQ3 ZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDIuMCBvbiBwY2kwCmFncDA6IGRldGVjdGVkIDc5MzJrIHN0 b2xlbiBtZW1vcnkKYWdwMDogYXBlcnR1cmUgc2l6ZSBpcyAyNTZNCnBjaWIyOiA8QUNQSSBQQ0kt UENJIGJyaWRnZT4gYXQgZGV2aWNlIDI4LjAgb24gcGNpMApwY2k1OiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liMgplbTA6IDxJbnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIENvbm5lY3Rpb24gVmVyc2lv biAtIDYuNi42PiBwb3J0IDB4YWMwMC0weGFjMWYgbWVtIDB4ZmY2MDAwMDAtMHhmZjYxZmZmZiww eGZmNjIwMDAwLTB4ZmY2M2ZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpNQplbTA6IEV0 aGVybmV0IGFkZHJlc3M6IDAwOjFiOjIxOjAwOjQ4OmM0CmVtMDogW0ZBU1RdCnBjaWIzOiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDI4LjEgb24gcGNpMApwY2k0OiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liMwpwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyOC4y IG9uIHBjaTAKcGNpMzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjQKcGNpYjU6IDxBQ1BJIFBDSS1Q Q0kgYnJpZGdlPiBhdCBkZXZpY2UgMjguMyBvbiBwY2kwCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWI1CnVoY2kwOiA8SW50ZWwgODI4MDFGQi9GUi9GVy9GUlcgKElDSDYpIFVTQiBjb250cm9s bGVyIFVTQi1BPiBwb3J0IDB4YzgwMC0weGM4MWYgaXJxIDIzIGF0IGRldmljZSAyOS4wIG9uIHBj aTAKdWhjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IDxJbnRlbCA4MjgwMUZCL0ZSL0ZXL0ZSVyAo SUNINikgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IG9uIHVoY2kwCnVzYjA6IFVTQiByZXZpc2lvbiAx LjAKdWh1YjA6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwg YWRkciAxCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aGNp MTogPEludGVsIDgyODAxRkIvRlIvRlcvRlJXIChJQ0g2KSBVU0IgY29udHJvbGxlciBVU0ItQj4g cG9ydCAweGNjMDAtMHhjYzFmIGlycSAxOSBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwCnVoY2kxOiBb R0lBTlQtTE9DS0VEXQp1c2IxOiA8SW50ZWwgODI4MDFGQi9GUi9GVy9GUlcgKElDSDYpIFVTQiBj b250cm9sbGVyIFVTQi1CPiBvbiB1aGNpMQp1c2IxOiBVU0IgcmV2aXNpb24gMS4wCnVodWIxOiBJ bnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQp1aHVi MTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWhjaTI6IDxJbnRlbCA4 MjgwMUZCL0ZSL0ZXL0ZSVyAoSUNINikgVVNCIGNvbnRyb2xsZXIgVVNCLUM+IHBvcnQgMHhkMDAw LTB4ZDAxZiBpcnEgMTggYXQgZGV2aWNlIDI5LjIgb24gcGNpMAp1aGNpMjogW0dJQU5ULUxPQ0tF RF0KdXNiMjogPEludGVsIDgyODAxRkIvRlIvRlcvRlJXIChJQ0g2KSBVU0IgY29udHJvbGxlciBV U0ItQz4gb24gdWhjaTIKdXNiMjogVVNCIHJldmlzaW9uIDEuMAp1aHViMjogSW50ZWwgVUhDSSBy b290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1YjI6IDIgcG9ydHMg d2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnVoY2kzOiA8SW50ZWwgODI4MDFGQi9GUi9G Vy9GUlcgKElDSDYpIFVTQiBjb250cm9sbGVyIFVTQi1EPiBwb3J0IDB4ZDQwMC0weGQ0MWYgaXJx IDE2IGF0IGRldmljZSAyOS4zIG9uIHBjaTAKdWhjaTM6IFtHSUFOVC1MT0NLRURdCnVzYjM6IDxJ bnRlbCA4MjgwMUZCL0ZSL0ZXL0ZSVyAoSUNINikgVVNCIGNvbnRyb2xsZXIgVVNCLUQ+IG9uIHVo Y2kzCnVzYjM6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjM6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNs YXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCnVodWIzOiAyIHBvcnRzIHdpdGggMiByZW1v dmFibGUsIHNlbGYgcG93ZXJlZAplaGNpMDogPEludGVsIDgyODAxRkIgKElDSDYpIFVTQiAyLjAg Y29udHJvbGxlcj4gbWVtIDB4ZmY0M2ZjMDAtMHhmZjQzZmZmZiBpcnEgMjMgYXQgZGV2aWNlIDI5 Ljcgb24gcGNpMAplaGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNiNDogRUhDSSB2ZXJzaW9uIDEuMAp1 c2I0OiBjb21wYW5pb24gY29udHJvbGxlcnMsIDIgcG9ydHMgZWFjaDogdXNiMCB1c2IxIHVzYjIg dXNiMwp1c2I0OiA8SW50ZWwgODI4MDFGQiAoSUNINikgVVNCIDIuMCBjb250cm9sbGVyPiBvbiBl aGNpMAp1c2I0OiBVU0IgcmV2aXNpb24gMi4wCnVodWI0OiBJbnRlbCBFSENJIHJvb3QgaHViLCBj bGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMQp1aHViNDogOCBwb3J0cyB3aXRoIDggcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQKcGNpYjY6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZp Y2UgMzAuMCBvbiBwY2kwCnBjaTY6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI2CmFoYzA6IDxBZGFw dGVjIDI5NDAgVWx0cmEgU0NTSSBhZGFwdGVyPiBwb3J0IDB4YjgwMC0weGI4ZmYgbWVtIDB4ZmY1 MTAwMDAtMHhmZjUxMGZmZiBpcnEgMjIgYXQgZGV2aWNlIDEuMCBvbiBwY2k2CmFoYzA6IFtHSUFO VC1MT0NLRURdCmFpYzc4ODA6IFVsdHJhIFdpZGUgQ2hhbm5lbCBBLCBTQ1NJIElkPTcsIDE2LzI1 MyBTQ0JzCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAzMS4wIG9uIHBjaTAKaXNh MDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTA6IDxJbnRlbCBJQ0g2IFVETUExMDAgY29udHJv bGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweGZmYTAtMHhm ZmFmIGF0IGRldmljZSAzMS4xIG9uIHBjaTAKYXRhMDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBj aTAKYXRhMTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKYXRhcGNpMTogPEludGVsIElDSDYg U0FUQTE1MCBjb250cm9sbGVyPiBwb3J0IDB4ZTgwMC0weGU4MDcsMHhlNDAwLTB4ZTQwMywweGUw MDAtMHhlMDA3LDB4ZGMwMC0weGRjMDMsMHhkODAwLTB4ZDgwZiBpcnEgMTkgYXQgZGV2aWNlIDMx LjIgb24gcGNpMAphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMQphdGEzOiA8QVRBIGNo YW5uZWwgMT4gb24gYXRhcGNpMQppY2hzbWIwOiA8U01CdXMgY29udHJvbGxlcj4gcG9ydCAweGM0 MDAtMHhjNDFmIGlycSAxOSBhdCBkZXZpY2UgMzEuMyBvbiBwY2kwCmljaHNtYjA6IFtHSUFOVC1M T0NLRURdCnNtYnVzMDogPFN5c3RlbSBNYW5hZ2VtZW50IEJ1cz4gb24gaWNoc21iMApzbWIwOiA8 U01CdXMgZ2VuZXJpYyBJL08+IG9uIHNtYnVzMAphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0b24+ IG9uIGFjcGkwCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2 MCwweDY0IGlycSAxIG9uIGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGti ZGMwCmtiZDAgYXQgYXRrYmQwCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KZmRjMDogPGZsb3BweSBk cml2ZSBjb250cm9sbGVyPiBwb3J0IDB4M2YwLTB4M2YxLDB4M2YyLTB4M2YzLDB4M2Y0LTB4M2Y1 LDB4M2Y3IGlycSA2IGRycSAyIG9uIGFjcGkwCmZkYzA6IFtGQVNUXQpmZDA6IDwxNDQwLUtCIDMu NSIgZHJpdmU+IG9uIGZkYzAgZHJpdmUgMApzaW8wOiBjb25maWd1cmVkIGlycSA0IG5vdCBpbiBi aXRtYXAgb2YgcHJvYmVkIGlycXMgMApzaW8wOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZApzaW8w OiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxh Z3MgMHgxMCBvbiBhY3BpMApzaW8wOiB0eXBlIDE2NTUwQQpwcGMwOiA8U3RhbmRhcmQgcGFyYWxs ZWwgcHJpbnRlciBwb3J0PiBwb3J0IDB4Mzc4LTB4MzdmIGlycSA3IG9uIGFjcGkwCnBwYzA6IEdl bmVyaWMgY2hpcHNldCAoRVBQL05JQkJMRSkgaW4gQ09NUEFUSUJMRSBtb2RlCnBwYnVzMDogPFBh cmFsbGVsIHBvcnQgYnVzPiBvbiBwcGMwCnBsaXAwOiA8UExJUCBuZXR3b3JrIGludGVyZmFjZT4g b24gcHBidXMwCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czAKbHB0MDogSW50ZXJydXB0LWRyaXZl biBwb3J0CnBwaTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMApwbXRpbWVyMCBvbiBpc2EwCm9y bTA6IDxJU0EgT3B0aW9uIFJPTT4gYXQgaW9tZW0gMHhjYjAwMC0weGNiN2ZmIG9uIGlzYTAKc2Mw OiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZp cnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPgpzaW8xOiBjb25maWd1cmVkIGlycSAzIG5vdCBp biBiaXRtYXAgb2YgcHJvYmVkIGlycXMgMApzaW8xOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZAp2 Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAt MHhiZmZmZiBvbiBpc2EwCnVodWI1OiB2ZW5kb3IgMHgwNWUzIFVTQiBIdWIsIGNsYXNzIDkvMCwg cmV2IDEuMTAvMy4wNSwgYWRkciAyCnVodWI1OiA0IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNl bGYgcG93ZXJlZAp1Y29tMDogRlRESSBVU0IgRkFTVCBTRVJJQUwgQURBUFRFUiwgcmV2IDEuMTAv NC4wMCwgYWRkciAzCnVjb20xOiBGVERJIFVTQiBGQVNUIFNFUklBTCBBREFQVEVSLCByZXYgMS4x MC80LjAwLCBhZGRyIDQKdWNvbTI6IEZUREkgVVNCIEZBU1QgU0VSSUFMIEFEQVBURVIsIHJldiAx LjEwLzQuMDAsIGFkZHIgNQp1Y29tMzogRlRESSBVU0IgRkFTVCBTRVJJQUwgQURBUFRFUiwgcmV2 IDEuMTAvNC4wMCwgYWRkciA2ClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAzMjAwMTExMjIw IEh6IHF1YWxpdHkgODAwClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKYWNkMDog Q0RST00gPE1BVFNISVRBIENSLTU4NS9aUzE1PiBhdCBhdGEwLW1hc3RlciBQSU8zCmFkNDogNzYz NTFNQiA8U0FNU1VORyBTUDA4MTJDIFNVMTAwLTMwPiBhdCBhdGEyLW1hc3RlciBTQVRBMTUwCmFk NTogNzYzMTlNQiA8U0FNU1VORyBIRDA4MEhKIFpIMTAwLTQ3PiBhdCBhdGEyLXNsYXZlIFNBVEEx NTAKYWQ2OiAyMzg0NzVNQiA8U2VhZ2F0ZSBTVDMyNTA2MjBBUyAzLkFBRT4gYXQgYXRhMy1tYXN0 ZXIgU0FUQTE1MAphZDc6IDIzODQ3NU1CIDxTZWFnYXRlIFNUMzI1MDYyMEFTIDMuQUFFPiBhdCBh dGEzLXNsYXZlIFNBVEExNTAKV2FpdGluZyA1IHNlY29uZHMgZm9yIFNDU0kgZGV2aWNlcyB0byBz ZXR0bGUKR0VPTV9NSVJST1I6IERldmljZSBnbTBzMSBjcmVhdGVkIChpZD0xODE2NTI0MzYyKS4K R0VPTV9NSVJST1I6IERldmljZSBnbTBzMTogcHJvdmlkZXIgYWQ0czEgZGV0ZWN0ZWQuCkdFT01f TUlSUk9SOiBEZXZpY2UgZ20wczE6IHByb3ZpZGVyIGFkNXMxIGRldGVjdGVkLgpHRU9NX01JUlJP UjogRGV2aWNlIGdtMHMxOiBwcm92aWRlciBhZDRzMSBhY3RpdmF0ZWQuCkdFT01fTUlSUk9SOiBE ZXZpY2UgZ20wczE6IHByb3ZpZGVyIGFkNXMxIGFjdGl2YXRlZC4KR0VPTV9NSVJST1I6IERldmlj ZSBnbTBzMTogcHJvdmlkZXIgbWlycm9yL2dtMHMxIGxhdW5jaGVkLgpHRU9NX0xBQkVMOiBMYWJl bCBmb3IgcHJvdmlkZXIgYWQ2czEgaXMgdWZzL2R1bXAxLgpHRU9NX0xBQkVMOiBMYWJlbCBmb3Ig cHJvdmlkZXIgYWQ3czEgaXMgdWZzL2R1bXAyLgpzYTAgYXQgYWhjMCBidXMgMCB0YXJnZXQgMCBs dW4gMApzYTA6IDxIUCBDNTY4M0EgQzkwOD4gUmVtb3ZhYmxlIFNlcXVlbnRpYWwgQWNjZXNzIFND U0ktMiBkZXZpY2UgCnNhMDogNDAuMDAwTUIvcyB0cmFuc2ZlcnMgKDIwLjAwME1Ieiwgb2Zmc2V0 IDgsIDE2Yml0KQpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L21pcnJvci9nbTBz MWEKZW0wOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAK --==========5CCE4080B8AFC40C1907========== Content-Type: application/octet-stream; name="midgard.dmesg.boot" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="midgard.dmesg.boot"; size=7992 V2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0ZW0gcHJvY2VzcyBgdm5scnUnIHRvIHN0 b3AuLi5kb25lCldhaXRpbmcgKG1heCA2MCBzZWNvbmRzKSBmb3Igc3lzdGVtIHByb2Nlc3MgYGJ1 ZmRhZW1vbicgdG8gc3RvcC4uLmRvbmUKV2FpdGluZyAobWF4IDYwIHNlY29uZHMpIGZvciBzeXN0 ZW0gcHJvY2VzcyBgc3luY2VyJyB0byBzdG9wLi4uClN5bmNpbmcgZGlza3MsIHZub2RlcyByZW1h aW5pbmcuLi4zIDMgMyAzIDIgMiAyIDIgMCAwIDAgMCAwIDAgZG9uZQpBbGwgYnVmZmVycyBzeW5j ZWQuCkdFT01fTUlSUk9SOiBEZXZpY2UgZ20xczE6IHByb3ZpZGVyIG1pcnJvci9nbTFzMSBkZXN0 cm95ZWQuCkdFT01fTUlSUk9SOiBEZXZpY2UgZ20xczEgZGVzdHJveWVkLgpHRU9VcHRpbWU6IDIy bTM2cwpNX01JUlJPUjogRGV2aWNlIGdtMHMxOiBwcm92aWRlciBtaXJyb3IvZ20wczEgZGVzdHJv eWVkLgpSZWJvb3RpbmcuLi4KQ29weXJpZ2h0IChjKSAxOTkyLTIwMDcgVGhlIEZyZWVCU0QgUHJv amVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAx OTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBD YWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0 cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA2LjItU1RBQkxFICMx NDogRnJpIEF1ZyAzMSAxMDo1NDo1OCBDRVNUIDIwMDcKICAgIHJvb3RAbWlkZ2FyZC5nbHouaGlk ZGVuLXBvd2Vycy5jb206L3Vzci9vYmovdXNyL3NyYy9zeXMvTUlER0FSRApBQ1BJIEFQSUMgVGFi bGU6IDxJTlRFTCAgRDkxNUdBViA+ClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMx ODIgSHogcXVhbGl0eSAwCkNQVTogSW50ZWwoUikgUGVudGl1bShSKSA0IENQVSAzLjA2R0h6ICgz MDY2LjY4LU1IeiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9 IDB4ZjQ5ICBTdGVwcGluZyA9IDkKICBGZWF0dXJlcz0weGJmZWJmYmZmPEZQVSxWTUUsREUsUFNF LFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2 LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsSFRULFRNLFBCRT4KICBGZWF0 dXJlczI9MHg2NTFkPFNTRTMsUlNWRDIsTU9OLERTX0NQTCxUTTIsQ05UWC1JRCxDWDE2LDxiMTQ+ PgogIEFNRCBGZWF0dXJlcz0weDIwMTAwMDAwPE5YLExNPgogIExvZ2ljYWwgQ1BVcyBwZXIgY29y ZTogMgpyZWFsIG1lbW9yeSAgPSAyMTM4MjM4OTc2ICgyMDM5IE1CKQphdmFpbCBtZW1vcnkgPSAy MDg3NDQwMzg0ICgxOTkwIE1CKQppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1v dGhlcmJvYXJkCmtiZDEgYXQga2JkbXV4MApycjIzMTBfMDA6IFJvY2tldFJBSUQgMjMxeC8yMzB4 IGNvbnRyb2xsZXIgZHJpdmVyIHYyLjAgKE1hciAyMyAyMDA3IDE2OjI1OjU2KQphY3BpMDogPElO VEVMIEQ5MTVHQVY+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpU aW1lY291bnRlciAiQUNQSS1zYWZlIiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEwMDAK YWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg0MDgtMHg0 MGIgb24gYWNwaTAKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApwNHRjYzA6IDxDUFUgRnJlcXVl bmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MApwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdl PiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIw CnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDEuMCBvbiBwY2kwCnBjaTE6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCnJyMjMxMF8wMDA6IDxzeDUwOHg+IHBvcnQgMHg5ODAw LTB4OThmZiBtZW0gMHhmZjkwMDAwMC0weGZmOWZmZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9u IHBjaTEKcnIyMzEwXzAwOiBhZGFwdGVyIGF0IFBDSSAxOjA6MCwgSVJRIDE2CmFncDA6IDxJbnRl bCA4MjkxNUcgKDkxNUcgR01DSCkgU1ZHQSBjb250cm9sbGVyPiBwb3J0IDB4ZWMwMC0weGVjMDcg bWVtIDB4ZmYzODAwMDAtMHhmZjNmZmZmZiwweGQwMDAwMDAwLTB4ZGZmZmZmZmYsMHhmZjM0MDAw MC0weGZmMzdmZmZmIGlycSAxNiBhdCBkZXZpY2UgMi4wIG9uIHBjaTAKYWdwMDogZGV0ZWN0ZWQg NzkzMmsgc3RvbGVuIG1lbW9yeQphZ3AwOiBhcGVydHVyZSBzaXplIGlzIDI1Nk0KcGNpYjI6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMjguMCBvbiBwY2kwCnBjaTU6IDxBQ1BJIFBD SSBidXM+IG9uIHBjaWIyCmVtMDogPEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlv biBWZXJzaW9uIC0gNi4yLjk+IHBvcnQgMHhhYzAwLTB4YWMxZiBtZW0gMHhmZjUwMDAwMC0weGZm NTFmZmZmLDB4ZmY1MjAwMDAtMHhmZjUzZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2k1 CmVtMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MTU6MTc6MGU6MDU6ZjcKcGNpYjM6IDxBQ1BJIFBD SS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMjguMSBvbiBwY2kwCnBjaTQ6IDxBQ1BJIFBDSSBidXM+ IG9uIHBjaWIzCnBjaWI0OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDI4LjIgb24g cGNpMApwY2kzOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNApwY2liNTogPEFDUEkgUENJLVBDSSBi cmlkZ2U+IGF0IGRldmljZSAyOC4zIG9uIHBjaTAKcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNp YjUKcGNpMDogPHNlcmlhbCBidXMsIFVTQj4gYXQgZGV2aWNlIDI5LjAgKG5vIGRyaXZlciBhdHRh Y2hlZCkKcGNpMDogPHNlcmlhbCBidXMsIFVTQj4gYXQgZGV2aWNlIDI5LjEgKG5vIGRyaXZlciBh dHRhY2hlZCkKcGNpMDogPHNlcmlhbCBidXMsIFVTQj4gYXQgZGV2aWNlIDI5LjIgKG5vIGRyaXZl ciBhdHRhY2hlZCkKcGNpMDogPHNlcmlhbCBidXMsIFVTQj4gYXQgZGV2aWNlIDI5LjMgKG5vIGRy aXZlciBhdHRhY2hlZCkKcGNpMDogPHNlcmlhbCBidXMsIFVTQj4gYXQgZGV2aWNlIDI5LjcgKG5v IGRyaXZlciBhdHRhY2hlZCkKcGNpYjY6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2Ug MzAuMCBvbiBwY2kwCnBjaTY6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI2CmFoYzA6IDxBZGFwdGVj IDI5NDAgVWx0cmEgU0NTSSBhZGFwdGVyPiBwb3J0IDB4YjgwMC0weGI4ZmYgbWVtIDB4ZmY0MTAw MDAtMHhmZjQxMGZmZiBpcnEgMjIgYXQgZGV2aWNlIDEuMCBvbiBwY2k2CmFoYzA6IFtHSUFOVC1M T0NLRURdCmFpYzc4ODA6IFVsdHJhIFdpZGUgQ2hhbm5lbCBBLCBTQ1NJIElkPTcsIDE2LzI1MyBT Q0JzCnBjaTY6IDxzZXJpYWwgYnVzLCBGaXJlV2lyZT4gYXQgZGV2aWNlIDIuMCAobm8gZHJpdmVy IGF0dGFjaGVkKQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kw CmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFwY2kwOiA8SW50ZWwgSUNINiBVRE1BMTAwIGNv bnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHhmZmEw LTB4ZmZhZiBhdCBkZXZpY2UgMzEuMSBvbiBwY2kwCmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBh dGFwY2kwCmF0YTE6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCmF0YXBjaTE6IDxJbnRlbCBJ Q0g2IFNBVEExNTAgY29udHJvbGxlcj4gcG9ydCAweGU4MDAtMHhlODA3LDB4ZTQwMC0weGU0MDMs MHhlMDAwLTB4ZTAwNywweGRjMDAtMHhkYzAzLDB4ZDgwMC0weGQ4MGYgaXJxIDE5IGF0IGRldmlj ZSAzMS4yIG9uIHBjaTAKYXRhMjogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTEKYXRhMzogPEFU QSBjaGFubmVsIDE+IG9uIGF0YXBjaTEKaWNoc21iMDogPFNNQnVzIGNvbnRyb2xsZXI+IHBvcnQg MHhjNDAwLTB4YzQxZiBpcnEgMTkgYXQgZGV2aWNlIDMxLjMgb24gcGNpMAppY2hzbWIwOiBbR0lB TlQtTE9DS0VEXQpzbWJ1czA6IDxTeXN0ZW0gTWFuYWdlbWVudCBCdXM+IG9uIGljaHNtYjAKc21i MDogPFNNQnVzIGdlbmVyaWMgSS9PPiBvbiBzbWJ1czAKYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0 dG9uPiBvbiBhY3BpMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0 IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24g YXRrYmRjMAprYmQwIGF0IGF0a2JkMAphdGtiZDA6IFtHSUFOVC1MT0NLRURdCmZkYzA6IDxmbG9w cHkgZHJpdmUgY29udHJvbGxlcj4gcG9ydCAweDNmMC0weDNmMSwweDNmMi0weDNmMywweDNmNC0w eDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBhY3BpMApmZGMwOiBbRkFTVF0KZmQwOiA8MTQ0MC1L QiAzLjUiIGRyaXZlPiBvbiBmZGMwIGRyaXZlIDAKc2lvMDogY29uZmlndXJlZCBpcnEgNCBub3Qg aW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDAKc2lvMDogcG9ydCBtYXkgbm90IGJlIGVuYWJsZWQK c2lvMDogPDE2NTUwQS1jb21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0 IGZsYWdzIDB4MTAgb24gYWNwaTAKc2lvMDogdHlwZSAxNjU1MEEsIGNvbnNvbGUKcHBjMDogPFN0 YW5kYXJkIHBhcmFsbGVsIHByaW50ZXIgcG9ydD4gcG9ydCAweDM3OC0weDM3ZiBpcnEgNyBvbiBh Y3BpMApwcGMwOiBHZW5lcmljIGNoaXBzZXQgKEVQUC9OSUJCTEUpIGluIENPTVBBVElCTEUgbW9k ZQpwcGJ1czA6IDxQYXJhbGxlbCBwb3J0IGJ1cz4gb24gcHBjMApwbGlwMDogPFBMSVAgbmV0d29y ayBpbnRlcmZhY2U+IG9uIHBwYnVzMApscHQwOiA8UHJpbnRlcj4gb24gcHBidXMwCmxwdDA6IElu dGVycnVwdC1kcml2ZW4gcG9ydApwcGkwOiA8UGFyYWxsZWwgSS9PPiBvbiBwcGJ1czAKcG10aW1l cjAgb24gaXNhMApvcm0wOiA8SVNBIE9wdGlvbiBST00+IGF0IGlvbWVtIDB4ZDM4MDAtMHhkN2Zm ZiBvbiBpc2EwCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNj MDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4KdmdhMDogPEdlbmVyaWMg SVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNh MApUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kgMzA2NjY3NjUyNiBIeiBxdWFsaXR5IDgwMApU aW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCnJyMjMxMF8wMDogc3RhcnQgY2hhbm5l bCBbMCwwXQpycjIzMTBfMDA6IHN0YXJ0IGNoYW5uZWwgWzAsMV0KcnIyMzEwXzAwOiBzdGFydCBj aGFubmVsIFswLDJdCnJyMjMxMF8wMDogc3RhcnQgY2hhbm5lbCBbMCwzXQpycjIzMTBfMDA6IGNo YW5uZWwgWzAsMF0gc3RhcnRlZCBzdWNjZXNzZnVsbHkKcnIyMzEwXzAwOiBjaGFubmVsIFswLDFd OiBmYWlsZWQgdG8gcGVyZm9ybSBIYXJkIFJlc2V0CnJyMjMxMF8wMDogY2hhbm5lbCBbMCwyXTog ZmFpbGVkIHRvIHBlcmZvcm0gSGFyZCBSZXNldApycjIzMTBfMDA6IGNoYW5uZWwgWzAsM106IGZh aWxlZCB0byBwZXJmb3JtIEhhcmQgUmVzZXQKcnIyMzEwXzAwMDogW0dJQU5ULUxPQ0tFRF0KV2Fp dGluZyA1IHNlY29uZHMgZm9yIFNDU0kgZGV2aWNlcyB0byBzZXR0bGUKYWNkMDogRFZEUiA8RlJF RUNPTSBEVkQrVy00UiBCIEEvMS4zMD4gYXQgYXRhMC1tYXN0ZXIgVURNQTMzCmFkNDogNzYzMTlN QiA8U2VhZ2F0ZSBTVDM4MDAxM0FTIDMuMDA+IGF0IGF0YTItbWFzdGVyIFNBVEExNTAKZGE0IGF0 IHJyMjMxMF8wMDAgYnVzIDAgdGFyZ2V0IDAgbHVuIDAKZGE0OiA8SFBUIERJU0sgMF8wIDQuMDA+ IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS0wIGRldmljZSAKZGE0OiAxNTI1NzYwTUIgKDMxMjQ3 NTY0ODAgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAxOTQ1MDdDKQpkYTIgYXQgYWhjMCBi dXMgMCB0YXJnZXQgMiBsdW4gMApkYTI6IDxTRUFHQVRFIFNUMzczMjA3TFcgMDAwNT4gRml4ZWQg RGlyZWN0IEFjY2VzcyBTQ1NJLTMgZGV2aWNlIApkYTI6IDIwLjAwME1CL3MgdHJhbnNmZXJzICgx MC4wMDBNSHosIG9mZnNldCA4LCAxNmJpdCksIFRhZ2dlZCBRdWV1ZWluZyBFbmFibGVkCmRhMjog NzAwMDdNQiAoMTQzMzc0NzQ0IDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgODkyNEMpCmRh MyBhdCBhaGMwIGJ1cyAwIHRhcmdldCAzIGx1biAwCmRhMzogPFNFQUdBVEUgU1QzNzMyMDdMVyAw MDA1PiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMyBkZXZpY2UgCmRhMzogMjAuMDAwTUIvcyB0 cmFuc2ZlcnMgKDEwLjAwME1Ieiwgb2Zmc2V0IDgsIDE2Yml0KSwgVGFnZ2VkIFF1ZXVlaW5nIEVu YWJsZWQKZGEzOiA3MDAwN01CICgxNDMzNzQ3NDQgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1Mv VCA4OTI0QykKZGEwIGF0IGFoYzAgYnVzIDAgdGFyZ2V0IDAgbHVuIDAKZGEwOiA8SUJNIERORVMt MzE4MzUwVyBTQTMwPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMyBkZXZpY2UgCmRhMDogMjAu MDAwTUIvcyB0cmFuc2ZlcnMgKDEwLjAwME1Ieiwgb2Zmc2V0IDgsIDE2Yml0KSwgVGFnZ2VkIFF1 ZXVlaW5nIEVuYWJsZWQKZGEwOiAxNzUwMU1CICgzNTg0MzY3MCA1MTIgYnl0ZSBzZWN0b3JzOiAy NTVIIDYzUy9UIDIyMzFDKQpkYTEgYXQgYWhjMCBidXMgMCB0YXJnZXQgMSBsdW4gMApkYTE6IDxJ Qk0gRE5FUy0zMTgzNTBXIFNBMzA+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS0zIGRldmljZSAK ZGExOiAyMC4wMDBNQi9zIHRyYW5zZmVycyAoMTAuMDAwTUh6LCBvZmZzZXQgOCwgMTZiaXQpLCBU YWdnZWQgUXVldWVpbmcgRW5hYmxlZApkYTE6IDE3NTAxTUIgKDM1ODQzNjcwIDUxMiBieXRlIHNl Y3RvcnM6IDI1NUggNjNTL1QgMjIzMUMpCmNkMCBhdCBhdGEwIGJ1cyAwIHRhcmdldCAwIGx1biAw CmNkMDogPEZSRUVDT01fIERWRCsvLVJXNEIgMS4zMD4gUmVtb3ZhYmxlIENELVJPTSBTQ1NJLTAg ZGV2aWNlIApjZDA6IDMzLjAwME1CL3MgdHJhbnNmZXJzCmNkMDogQXR0ZW1wdCB0byBxdWVyeSBk ZXZpY2Ugc2l6ZSBmYWlsZWQ6IE5PVCBSRUFEWSwgTWVkaXVtIG5vdCBwcmVzZW50CkdFT01fTUlS Uk9SOiBEZXZpY2UgZ20wczEgY3JlYXRlZCAoaWQ9NDAwMzQ3MjY1MSkuCkdFT01fTUlSUk9SOiBE ZXZpY2UgZ20wczE6IHByb3ZpZGVyIGRhMHMxIGRldGVjdGVkLgpHRU9NX01JUlJPUjogRGV2aWNl IGdtMHMxOiBwcm92aWRlciBkYTFzMSBkZXRlY3RlZC4KR0VPTV9NSVJST1I6IERldmljZSBnbTBz MTogcHJvdmlkZXIgZGExczEgYWN0aXZhdGVkLgpHRU9NX01JUlJPUjogRGV2aWNlIGdtMHMxOiBw cm92aWRlciBkYTBzMSBhY3RpdmF0ZWQuCkdFT01fTUlSUk9SOiBEZXZpY2UgZ20wczE6IHByb3Zp ZGVyIG1pcnJvci9nbTBzMSBsYXVuY2hlZC4KR0VPTV9NSVJST1I6IERldmljZSBnbTFzMSBjcmVh dGVkIChpZD00MDU4NTA0MjczKS4KR0VPTV9NSVJST1I6IERldmljZSBnbTFzMTogcHJvdmlkZXIg ZGEyczEgZGV0ZWN0ZWQuCkdFT01fTUlSUk9SOiBEZXZpY2UgZ20xczE6IHByb3ZpZGVyIGRhM3Mx IGRldGVjdGVkLgpHRU9NX01JUlJPUjogRGV2aWNlIGdtMXMxOiBwcm92aWRlciBkYTNzMSBhY3Rp dmF0ZWQuCkdFT01fTUlSUk9SOiBEZXZpY2UgZ20xczE6IHByb3ZpZGVyIGRhMnMxIGFjdGl2YXRl ZC4KR0VPTV9NSVJST1I6IERldmljZSBnbTFzMTogcHJvdmlkZXIgbWlycm9yL2dtMXMxIGxhdW5j aGVkLgpHRU9NX0xBQkVMOiBMYWJlbCBmb3IgcHJvdmlkZXIgZGE0czFlIGlzIHVmcy9kYXRhMi4K R0VPTV9MQUJFTDogTGFiZWwgZm9yIHByb3ZpZGVyIGRhNHMxZiBpcyB1ZnMvZGF0YTEuCkdFT01f TEFCRUw6IExhYmVsIGZvciBwcm92aWRlciBkYTRzMWcgaXMgdWZzL2RhdGEwLgpUcnlpbmcgdG8g bW91bnQgcm9vdCBmcm9tIHVmczovZGV2L21pcnJvci9nbTBzMWEKZW0wOiBsaW5rIHN0YXRlIGNo YW5nZWQgdG8gVVAK --==========5CCE4080B8AFC40C1907==========-- From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 14:35:38 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADA8316A46E for ; Fri, 19 Oct 2007 14:35:38 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id EDDA213C45A for ; Fri, 19 Oct 2007 14:35:36 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (dialup9.ach.sch.gr [81.186.70.9]) (authenticated bits=128) by igloo.linux.gr (8.14.1/8.14.1/Debian-9) with ESMTP id l9JELkJO013521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Oct 2007 17:22:07 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l9JELdKS004361; Fri, 19 Oct 2007 17:21:41 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l9JELaIs004360; Fri, 19 Oct 2007 17:21:36 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Fri, 19 Oct 2007 17:21:35 +0300 From: Giorgos Keramidas To: Max Laier Message-ID: <20071019142135.GA4304@kobe.laptop> References: <200709302232.34505.max@love2party.net> <200710160401.18429.max@love2party.net> <200710160445.10993.max@love2party.net> <200710191048.58350.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710191048.58350.max@love2party.net> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.144, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.26, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: libpcap/tcpdump update X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 14:35:38 -0000 On 2007-10-19 10:48, Max Laier wrote: > Okay. libpcap 0.9.8 and tcpdump 3.9.8 are now imported into HEAD and > RELENG_7. Is anyone eager to pull it down to RELENG_6 as well, > because I don't have the resources available at the moment. The > update was crucial to me in HEAD and RELENG_7 to get a working pflog > tcpdump, but RELENG_6 isn't broken for me ... > > Any takers? If not I might get round to it eventually, but I'd prefer > somebody with genuine interest would step up. Hi Max, I can do this. I may need a bit of help with code-style or parts which I am not very familiar with, but if you think you can do a pre-commit review of the RELENG_6 patches (or alternatively help me find another src-committer who can do this), that would be awesome :) From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 14:41:51 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E25416A418 for ; Fri, 19 Oct 2007 14:41:51 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (mail.ismobile.com [62.119.44.68]) by mx1.freebsd.org (Postfix) with ESMTP id 4D91A13C459 for ; Fri, 19 Oct 2007 14:41:46 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (localhost [127.0.0.1]) by mail.ismobile.com (Postfix) with ESMTP id CAACE33C02 for ; Fri, 19 Oct 2007 16:41:44 +0200 (CEST) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=ismobile.com; h=received:date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding:content-disposition; q=dns/txt; s=selector1; bh=ED7gAysQ5Sc6KPNfo6lHUqAVpR4=; b=cDyLG62dk+5BQ3UP0KpLKFQK/rXobLlCuelT5VfN9ZCeKFLftFSzUxF1AbSagUIVEXlTGRRpk4v/uxb+XJy5x0GNyqotDMDEoK7hw4Sw1HzK4Mk394lhsMUjMdTxGsyje7AZIJhyrXS8IRsgRIrBDv03q1F0PxHn/Y0L0++kU2w= Received: from [172.16.2.129] (viglaf.hq.ismobile.com [172.16.2.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTP id BBB2933C01 for ; Fri, 19 Oct 2007 16:41:44 +0200 (CEST) Date: Fri, 19 Oct 2007 16:41:44 +0200 From: Goran Lowkrantz To: freebsd-stable@freebsd.org Message-ID: <06A7A8BB28820654EDC5FC48@viglaf> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: em 6.6.6 - watchdog timeout X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 14:41:51 -0000 wrote: > Hi, snip > > When running netstat between servers balder and midgard, server balder > get watchdog timeouts and resets the connection for a few seconds. > Oct 19 13:12:47 balder kernel: em0: watchdog timeout -- resetting s/netstat/netperf/ ................................................... the future isMobile Goran Lowkrantz System Architect, iaMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Lule=E5, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ............................................... From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 14:55:59 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A79A716A418 for ; Fri, 19 Oct 2007 14:55:59 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (mx1.vega.ru [87.242.77.163]) by mx1.freebsd.org (Postfix) with ESMTP id 5EC0B13C448 for ; Fri, 19 Oct 2007 14:55:59 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=56694 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iisjs-000Gud-1B; Fri, 19 Oct 2007 14:22:12 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.1/8.14.1) with ESMTP id l9JELNFV053621; Fri, 19 Oct 2007 18:21:23 +0400 (MSD) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.1/8.14.1/Submit) id l9JELMYr053620; Fri, 19 Oct 2007 18:21:22 +0400 (MSD) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Fri, 19 Oct 2007 18:21:22 +0400 From: Ruslan Ermilov To: Philipp Ost Message-ID: <20071019142122.GA53214@team.vega.ru> References: <47177F6C.4060600@smo.de> <4717AECF.40503@smo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4717AECF.40503@smo.de> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: stable@freebsd.org, Vlad GALU Subject: Re: kldxref: file isn't dynamically-linked -- expected behaviour? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 14:55:59 -0000 On Thu, Oct 18, 2007 at 09:06:55PM +0200, Philipp Ost wrote: > Vlad GALU wrote: >> On 10/18/07, Philipp Ost wrote: >>> Hi list, >>> >>> I'm currently upgrading from 6.2-STABLE (13 Oct. 2007) to RELENG_7. I >>> did the following after csup'ing my sources: >>> # make kernel-toolchain >>> # make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=MYKERNEL >>> # make -DALWAYS_CHECK_MAKE installkernel KERNCONF=MYKERNEL >>> >>> The last thing 'installkernel' reports is: >>> [...] >>> kldxref /boot/kernel >>> kldxref: file isn't dynamically-linked >>> [...] >>> >>> This message is repeated 514 times... ;-) Is this expected behaviour? >>> Before I do a reboot I would like to make sure "everything works" as I >>> rely on that particular machine. >>> >>> If needed I can provide full logs; MYKERNEL is a cut down version of >>> GENERIC with atapicam, drm, radeondrm, sound added ;-) >>> >>> >>> Thanks in advance for any hint/help! >>> >> It's harmless. Once you boot with your new RELENG_7 they will >> disappear on the next kernel build/install. > > Thanks a lot. I saw this message for the first time in my life and was a > little bit concerned about it... But if everything seems to be fine I will > give it a try. > As others have pointed out, these messages are harmless. It's caused by the old (6.x version) kldxref(8) binary trying to hash the *.symbols files that are installed along with debug versions of kernel and module objects, and that contain symbol information needed for debugging, and aren't dynamically linked ELF files. So the old kldxref(8) ignores these files, but issues a warning. Once you upgrade to 7.x, you'll have also installed the new (7.x version) of kldxref(8) that is aware of .symbols files, so warnings will be gone. Technically, kldxref(8) should be a cross-tool (in the buildworld sense), but last time I tried to convert it to be a cross-tool several years ago it wasn't very easy. It's quite possible it will be easier now that we only support limited upgrade paths. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 15:09:29 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AC7216A419 for ; Fri, 19 Oct 2007 15:09:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4DDAF13C455 for ; Fri, 19 Oct 2007 15:09:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id AF1241A4D87; Fri, 19 Oct 2007 07:47:32 -0700 (PDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 19 Oct 2007 09:58:24 -0400 User-Agent: KMail/1.9.7 References: <45B64469.9020002@palisadesys.com> <2a41acea0701230937p7c0f6400ida76a956fabd9b94@mail.gmail.com> <45B65155.5080304@palisadesys.com> In-Reply-To: <45B65155.5080304@palisadesys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710190958.24912.jhb@freebsd.org> Cc: Guy Helmer , Jack Vogel Subject: Re: Supermicro X7DBR-8+ hang at boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 15:09:29 -0000 On Tuesday 23 January 2007 01:17:57 pm Guy Helmer wrote: > Jack Vogel wrote: > > On 1/23/07, Guy Helmer wrote: > >> Using FreeBSD 6.2, I'm having trouble with the Supermicro X7DBR-8+ > >> motherboard (dual Xeon 5130 CPUs on the Blackford chipset - > >> http://www.supermicro.com/products/motherboard/Xeon1333/5000P/X7DBR-8+.cfm) > >> > >> hanging after printing the "Waiting 5 seconds for SCSI devices to > >> settle" message. The hang doesn't always happen - sometimes we have to > >> go through several reboot cycles for it to happen - but sometimes it > >> happens with every reboot. For those who would suggest that this > >> happens because I'm using Seagate drives, it happens even if we totally > >> remove the SCSI drive (but leave the aic7902 SCSI interfaces enabled) > >> and boot from a SATA disk. Using FreeBSD 6.1, the Intel gigabit > >> ethernet NICs aren't found but the hang doesn't occur. > > ... > > If that isnt it, I would suggest installing using ACPI disabled or > > SAFE if > > needed, and then tweak the kernel after. > hint.apic.0.disabled=1 helped - it hasn't hung yet in several boot > cycles. New dmesg is attached below in case it helps anyone see a > better fix than disabling the APICs. So you got an interrupt storm on IRQ 18 when ahd0 tried to probe and ahd0 got interrupt timeouts. This indicates that ahd0 really lives on IRQ 18, not IRQ 30. Your BIOS is likely busted since ACPI hardcodes these sort of IRQs. You can override the BIOS by doing: set hw.pci5.2.INTA.irq=18 in the loader (or adding a line to loader.conf) and seeing if that fixes the boot with APIC enabled. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 15:13:17 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C875316A41A for ; Fri, 19 Oct 2007 15:13:17 +0000 (UTC) (envelope-from pj@smo.de) Received: from ilk.de (mx-out13.ilk.de [194.121.104.13]) by mx1.freebsd.org (Postfix) with ESMTP id 5F14A13C4B6 for ; Fri, 19 Oct 2007 15:13:16 +0000 (UTC) (envelope-from pj@smo.de) Received: from bologna.intern.smo.de (pool52.ka.ilk.net [212.86.194.52]) by ilk.de (8.13.4/8.13.4/ilk-relay) with ESMTP id l9JFDE17008596; Fri, 19 Oct 2007 17:13:14 +0200 Received: from [192.168.153.209] (askja.intern.smo.de [192.168.153.209]) by bologna.intern.smo.de (8.13.8+Sun/8.13.8) with ESMTP id l9JF9MI8029394; Fri, 19 Oct 2007 17:09:22 +0200 (CEST) Message-ID: <4718C952.5010402@smo.de> Date: Fri, 19 Oct 2007 17:12:18 +0200 From: Philipp Ost User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070527 X-Accept-Language: de-de, en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <47177F6C.4060600@smo.de> <4717AECF.40503@smo.de> <20071019142122.GA53214@team.vega.ru> In-Reply-To: <20071019142122.GA53214@team.vega.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, Vlad GALU Subject: Re: kldxref: file isn't dynamically-linked -- expected behaviour? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 15:13:17 -0000 Ruslan Ermilov wrote: > On Thu, Oct 18, 2007 at 09:06:55PM +0200, Philipp Ost wrote: > >>Vlad GALU wrote: >> >>>On 10/18/07, Philipp Ost wrote: >>> >>>>Hi list, >>>> >>>>I'm currently upgrading from 6.2-STABLE (13 Oct. 2007) to RELENG_7. I >>>>did the following after csup'ing my sources: >>>># make kernel-toolchain >>>># make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=MYKERNEL >>>># make -DALWAYS_CHECK_MAKE installkernel KERNCONF=MYKERNEL >>>> >>>>The last thing 'installkernel' reports is: >>>>[...] >>>>kldxref /boot/kernel >>>>kldxref: file isn't dynamically-linked >>>>[...] >>>> >>>>This message is repeated 514 times... ;-) Is this expected behaviour? >>>>Before I do a reboot I would like to make sure "everything works" as I >>>>rely on that particular machine. >>>> >>>>If needed I can provide full logs; MYKERNEL is a cut down version of >>>>GENERIC with atapicam, drm, radeondrm, sound added ;-) >>>> >>>> >>>>Thanks in advance for any hint/help! >>>> >>> >>> It's harmless. Once you boot with your new RELENG_7 they will >>>disappear on the next kernel build/install. >> >>Thanks a lot. I saw this message for the first time in my life and was a >>little bit concerned about it... But if everything seems to be fine I will >>give it a try. >> > > As others have pointed out, these messages are harmless. It's caused > by the old (6.x version) kldxref(8) binary trying to hash the *.symbols > files that are installed along with debug versions of kernel and module > objects, and that contain symbol information needed for debugging, and > aren't dynamically linked ELF files. So the old kldxref(8) ignores > these files, but issues a warning. Once you upgrade to 7.x, you'll have > also installed the new (7.x version) of kldxref(8) that is aware of > .symbols files, so warnings will be gone. > > Technically, kldxref(8) should be a cross-tool (in the buildworld > sense), but last time I tried to convert it to be a cross-tool > several years ago it wasn't very easy. It's quite possible it > will be easier now that we only support limited upgrade paths. Thanks for the explanation of the technical background. In the meantime I did the upgrade to 7.0 and also rebuilt the kernel -- as pointed out the warnings are gone ;-) Seems like I was a little bit too concernced about some (possible) breakage... Thanks again for all the answers! Cheers, Philipp -- http://www.familie-ost.info/~pj From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 15:17:45 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 490C516A417 for ; Fri, 19 Oct 2007 15:17:45 +0000 (UTC) (envelope-from oleg@vsi.ru) Received: from serv4.vsi.ru (serv4.vsi.ru [80.82.32.19]) by mx1.freebsd.org (Postfix) with ESMTP id C228113C46A for ; Fri, 19 Oct 2007 15:17:44 +0000 (UTC) (envelope-from oleg@vsi.ru) Received: from delloleg (dell-berry.vsi.ru [88.83.197.200]) by serv4.vsi.ru (8.13.8+Sun/8.13.8) with SMTP id l9JETPcx024932 for ; Fri, 19 Oct 2007 18:29:31 +0400 (MSD) Message-ID: <027d01c8125c$73d4db80$c8c55358@delloleg> From: "Oleg Derevenetz" To: Date: Fri, 19 Oct 2007 18:29:21 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: kern/104406: [ufs] Processes get stuck in "ufs" state under persistent CPU load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 15:17:45 -0000 Hi all, Can anyone take a look on PR kern/104406 ? I got repeatable hang situation, but I can't obtain a kernel dump to get result of all show commands from here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html After my break to debugger using Ctrl+Alt+Esc sequence and entering a "panic" command kernel does not wrote a kernel dump but seems to hang. Can anyone describe how to obtain a kernel dump in this situation, or at least say - which output of show commands need in first place to debug this ? Output of all suggested commands is huge and I afraid of making mistake when carrying this output from screen to list of paper and back :-) -- Oleg Derevenetz OOD3-RIPE Phone: +7 4732 539880 Fax: +7 4732 531415 http://www.vsi.ru CenterTelecom Voronezh ISP http://isp.vsi.ru From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 16:55:03 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8943B16A418 for ; Fri, 19 Oct 2007 16:55:03 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [217.77.141.129]) by mx1.freebsd.org (Postfix) with ESMTP id 104C113C457 for ; Fri, 19 Oct 2007 16:54:56 +0000 (UTC) (envelope-from ruben@verweg.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verweg.com; s=verweg; t=1192812113; bh=+11XVPKdPoG54oTlDcOAPYG0S7UliGx0EPHLuTqYe0s=; h=In-Reply-To:References:Mime-Version:X-Gpgmail-State:Content-Type: Message-Id:Cc:Content-Transfer-Encoding:From:Subject:Date:To: X-Mailer:X-Virus-Scanned:X-Virus-Status:X-Spam-Status:X-Spam-Level: X-Spam-Checker-Version; b=SFBePzCFXNdeLuaqduW9KmexEMQvNXAmiEHvMoZs ld66+MhpOVYb1sjjVBNQvPn+ySh2Z7Omo1fnFwGGxwnfD+GLbh8BMkJZzOAfSFEFTXp 6o9/34Ordu4z0DJmridm5BqY5Sb6UkpCzmlN1P9Y6nLdb5FdM0i0iqQZcKkXR5DA= Received: from [IPv6:::1] (chimp.ripe.net [193.0.1.199]) (authenticated bits=0) by erg.verweg.com (8.14.1/8.14.1) with ESMTP id l9JGeufV018074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 19 Oct 2007 16:41:38 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host chimp.ripe.net [193.0.1.199] claimed to be [IPv6:::1] In-Reply-To: <26b05a0e0710182304q5ad2c57eo3b08c56b842ee3fe@mail.gmail.com> References: <47177F6C.4060600@smo.de> <4717AECF.40503@smo.de> <26b05a0e0710182304q5ad2c57eo3b08c56b842ee3fe@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ruben van Staveren Date: Fri, 19 Oct 2007 09:26:09 +0200 To: "Chris Chou" X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on erg.verweg.com X-Virus-Status: Clean X-Spam-Status: No, score=3.8 required=5.0 tests=DATE_IN_FUTURE_24_48, SPF_FAIL autolearn=no version=3.2.3 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on erg.verweg.com X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (erg.verweg.com [217.77.141.129]); Fri, 19 Oct 2007 16:41:53 +0000 (UTC) Cc: Philipp Ost , stable@freebsd.org, Vlad GALU Subject: Re: kldxref: file isn't dynamically-linked -- expected behaviour? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 16:55:03 -0000 On 19 Oct 2007, at 8:04, Chris Chou wrote: > I saw the same message when upgrading from RELENG_6 to RELENG_7, > and it > disappeared when I re-installed the RELENG_7 kernel. Was your user land already upgraded to RELENG_7 ? if concerned, find the version 7 kldxref from /usr/obj and rerun it. apart from that and a few other nits that aren't really worth mentioning as I reused my kernel config from six the upgrade was really smooth. Thanks to all who participated in getting RELENG_7 branched! - Ruben From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 19:56:05 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E8C516A421 for ; Fri, 19 Oct 2007 19:56:05 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from mail.vega.ru (mx1.vega.ru [87.242.77.163]) by mx1.freebsd.org (Postfix) with ESMTP id 107DB13C481 for ; Fri, 19 Oct 2007 19:55:55 +0000 (UTC) (envelope-from rermilov@team.vega.ru) Received: from [87.242.97.68] (port=60378 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IixaO-0005Br-Uu; Fri, 19 Oct 2007 19:32:44 +0000 Received: from edoofus.dev.vega.ru (localhost [127.0.0.1]) by edoofus.dev.vega.ru (8.14.1/8.14.1) with ESMTP id l9JJVufj052664; Fri, 19 Oct 2007 23:31:56 +0400 (MSD) (envelope-from rermilov@team.vega.ru) Received: (from ru@localhost) by edoofus.dev.vega.ru (8.14.1/8.14.1/Submit) id l9JJVt8U052663; Fri, 19 Oct 2007 23:31:55 +0400 (MSD) (envelope-from rermilov@team.vega.ru) X-Authentication-Warning: edoofus.dev.vega.ru: ru set sender to rermilov@team.vega.ru using -f Date: Fri, 19 Oct 2007 23:31:55 +0400 From: Ruslan Ermilov To: Christopher Chen Message-ID: <20071019193155.GA40442@team.vega.ru> References: <7bc80d500710181207pe161b81j3131d370bbbbc631@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7bc80d500710181207pe161b81j3131d370bbbbc631@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: rpc.statd--256M okay, but 1G? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 19:56:05 -0000 On Thu, Oct 18, 2007 at 12:07:02PM -0700, Christopher Chen wrote: > Is there a simple and easy reason why rpc.statd would mmap 1G? I've > read the FAQ and understand why it would allocate 256M, but this one > shows 1G--file.c in /usr/src/usr.sbin/rpc.statd is still set to > allocate 256M, btw. > > This is a 6.2 machine on i386, with 4G RAM, but PAE is not enabled. > That's what I would assume, that if PAE was enabled, it may change the > characteristics of that mmap (but even then, the address space of each > process would be the same...) > > The machine is a nfs client, has no exports, and has two mounts. > > Any quick thoughts? > It has been fixed in RELENG_6 in rev. 1.12.8.2 of statd.c: : revision 1.12.8.2 : date: 2007/08/12 01:46:19; author: truckman; state: Exp; lines: +1 -1 : MFC statd.c 1.15 - : The call to init_file() needs to be moved outside the loop in statd.c, : otherwise mmap() gets called multiple times, which eventually fails due : to address space exhaustion on i386. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 22:05:15 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A1F816A475 for ; Fri, 19 Oct 2007 22:05:15 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 8118D13C459 for ; Fri, 19 Oct 2007 22:05:10 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id E98FE1A4D87; Fri, 19 Oct 2007 15:05:01 -0700 (PDT) Date: Fri, 19 Oct 2007 15:05:01 -0700 From: Alfred Perlstein To: Oleg Derevenetz Message-ID: <20071019220501.GL31826@elvis.mu.org> References: <027d01c8125c$73d4db80$c8c55358@delloleg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <027d01c8125c$73d4db80$c8c55358@delloleg> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: kern/104406: [ufs] Processes get stuck in "ufs" state under persistent CPU load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 22:05:15 -0000 * Oleg Derevenetz [071019 08:17] wrote: > Hi all, > > Can anyone take a look on PR kern/104406 ? I got repeatable hang situation, > but I can't obtain a kernel dump to get result of all show commands from > here: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > After my break to debugger using Ctrl+Alt+Esc sequence and entering a > "panic" command kernel does not wrote a kernel dump but seems to hang. Can > anyone describe how to obtain a kernel dump in this situation, or at least > say - which output of show commands need in first place to debug this ? > Output of all suggested commands is huge and I afraid of making mistake > when carrying this output from screen to list of paper and back :-) Oleg, one thing you can do to make this less painful is to run your machine's console over serial port. First get a crossover serial cable, make sure it works from one box to another, it should be easy to run "tip com1" on both boxes to ensure that it works. Then you just need to add console=comconsole to /boot/loader.conf and your box's console should come over serial. Then on the machine watching the console, you can just do this: % script Script started, output file is typescript % tip com1 ...do ddb stuff now... ...stop tip % exit now you should have everything logged into a file called "typescript" should save you a big headache. As far as getting a dump from ddb, try this: ddb> call doadump I'm completely at a loss why this isn't a base ddb command "dump" but whatever... :) -Alfred From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 22:46:58 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8127B16A41B for ; Fri, 19 Oct 2007 22:46:58 +0000 (UTC) (envelope-from pmurray@nevada.net.nz) Received: from bellagio.open2view.net (bellagio.open2view.net [210.48.79.75]) by mx1.freebsd.org (Postfix) with ESMTP id DBAB413C45A for ; Fri, 19 Oct 2007 22:46:57 +0000 (UTC) (envelope-from pmurray@nevada.net.nz) Received: from [10.0.0.5] (125-237-174-244.jetstream.xtra.co.nz [125.237.174.244]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bellagio.open2view.net (Postfix) with ESMTP id 2B5C46A930B; Sat, 20 Oct 2007 11:21:14 +1300 (NZDT) Message-Id: <5CCABF9E-80DD-4E46-80AA-6E3E1F156645@nevada.net.nz> From: Philip Murray To: Goran Lowkrantz , freebsd-stable@freebsd.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v890.2) Date: Sat, 20 Oct 2007 11:21:10 +1300 References: X-Mailer: Apple Mail (2.890.2) Cc: Subject: Re: em 6.6.6 - watchdog timeout X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 22:46:58 -0000 On 20/10/2007, at 1:06 AM, Goran Lowkrantz wrote: > Hi, > > After the update of em to 6.6.6 last, I experience watchdog timeouts > on a server running 6-STABLE. > "me too" on a Supermicro 5015MT+, although I notice my em0 is also sharing an interrupt with USB (uhci3)... not sure if that's the culprit. [pmurray@chance ~]$ dmesg Copyright (c) 1992-2007 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 6.2-STABLE #0: Tue Oct 9 07:45:50 NZDT 2007 root@chance.open2view.net:/usr/obj/usr/src/sys/GENERIC ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU X3220 @ 2.40GHz (2394.01-MHz 686- class CPU) Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 Features = 0xbfebfbff < FPU ,VME ,DE ,PSE ,TSC ,MSR ,PAE ,MCE ,CX8 ,APIC ,SEP ,MTRR ,PGE ,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 4 real memory = 2146304000 (2046 MB) avail memory = 2095353856 (1998 MB) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 17 at device 28.0 on pci0 pci9: on pcib2 pcib3: at device 0.0 on pci9 pci10: on pcib3 pcib4: at device 1.0 on pci10 pci11: on pcib4 arcmsr0: mem 0xe0200000-0xe0200fff,0xe0800000-0xe0bfffff irq 26 at device 14.0 on pci11 ARECA RAID ADAPTER0: Driver Version 1.20.00.14 2007-2-05 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 pcib5: irq 17 at device 28.4 on pci0 pci13: on pcib5 em0: port 0x4000-0x401f mem 0xe0300000-0xe031ffff irq 16 at device 0.0 on pci13 em0: Ethernet address: 00:30:48:90:48:dc em0: [FAST] pcib6: irq 16 at device 28.5 on pci0 pci14: on pcib6 em1: port 0x5000-0x501f mem 0xe0400000-0xe041ffff irq 17 at device 0.0 on pci14 em1: Ethernet address: 00:30:48:90:48:dd em1: [FAST] uhci0: port 0x3000-0x301f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3020-0x303f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x3040-0x305f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x3060-0x307f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xe0000000-0xe00003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib7: at device 30.0 on pci0 pci15: on pcib7 pci15: at device 0.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcbfff, 0xcc000-0xccfff,0xcd000-0xcdfff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2394010800 Hz quality 800 Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle acd0: CDROM at ata0-master UDMA33 pass2 at arcmsr0 bus 0 target 16 lun 0 pass2: Fixed Processor SCSI-0 device da0 at arcmsr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz, offset 32, 16bit), Tagged Queueing Enabled da0: 28609MB (58592256 512 byte sectors: 255H 63S/T 3647C) da1 at arcmsr0 bus 0 target 0 lun 1 da1: Fixed Direct Access SCSI-5 device da1: 166.666MB/s transfers (83.333MHz, offset 32, 16bit), Tagged Queueing Enabled da1: 2117156MB (4335936000 512 byte sectors: 255H 63S/T 269899C) Trying to mount root from ufs:/dev/da0s1a WARNING: /backup was not properly dismounted em1: link state changed to UP em1: link state changed to DOWN em0: link state changed to UP ums0: Cyclades SUN/PC USB Terminator, rev 1.00/15.00, addr 2, iclass 3/1 ums0: 5 buttons and Z dir. ukbd0: Cyclades SUN/PC USB Terminator, rev 1.00/15.00, addr 2, iclass 3/1 kbd2 at ukbd0 ums0: at uhub0 port 1 (addr 2) disconnected ums0: detached ukbd0: at uhub0 port 1 (addr 2) disconnected ukbd0: detached gif0: promiscuous mode enabled gif0: promiscuous mode disabled gif0: promiscuous mode enabled gif0: promiscuous mode disabled gif0: promiscuous mode enabled gif0: promiscuous mode disabled em0: watchdog timeout -- resetting em0: link state changed to DOWN em0: link state changed to UP pid 38534 (locate.code), uid 65534 inumber 32898 on /tmp: filesystem full em0: watchdog timeout -- resetting em0: link state changed to DOWN em0: link state changed to UP em0: watchdog timeout -- resetting em0: link state changed to DOWN em0: link state changed to UP em0: watchdog timeout -- resetting em0: link state changed to DOWN em0: link state changed to UP em0: watchdog timeout -- resetting em0: link state changed to DOWN em0: link state changed to UP em0: watchdog timeout -- resetting em0: link state changed to DOWN em0: link state changed to UP em0: watchdog timeout -- resetting em0: link state changed to DOWN em0: link state changed to UP em0: watchdog timeout -- resetting em0: link state changed to DOWN em0: link state changed to UP [pmurray@chance ~]$ vmstat -i interrupt total rate irq14: ata0 47 0 irq16: em0 uhci3 9168265 9 irq17: em1 107811254 114 irq18: uhci2 32252905 34 irq23: uhci0 ehci0 738 0 irq26: arcmsr0 33035746 34 cpu0: timer 1889578811 1999 Total 2071847766 2192 [pmurray@chance ~]$ pciconf -lv hostb0@pci0:0:0: class=0x060000 card=0x798015d9 chip=0x27788086 rev=0xc0 hdr=0x00 vendor = 'Intel Corporation' device = 'Server Memory Controller Hub' class = bridge subclass = HOST-PCI pcib1@pci0:1:0: class=0x060400 card=0x798015d9 chip=0x27798086 rev=0xc0 hdr=0x01 vendor = 'Intel Corporation' device = 'PCI Express Root Port' class = bridge subclass = PCI-PCI pcib2@pci0:28:0: class=0x060400 card=0x798015d9 chip=0x27d08086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCI Express Root Port' class = bridge subclass = PCI-PCI pcib5@pci0:28:4: class=0x060400 card=0x798015d9 chip=0x27e08086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801GR/GH/GHM (ICH7 Family) PCI Express Root Port' class = bridge subclass = PCI-PCI pcib6@pci0:28:5: class=0x060400 card=0x798015d9 chip=0x27e28086 rev=0x01 hdr=0x01 vendor = 'Intel Corporation' device = '82801GR/GH/GHM (ICH7 Family) PCI Express Root Port' class = bridge subclass = PCI-PCI uhci0@pci0:29:0: class=0x0c0300 card=0x798015d9 chip=0x27c88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci1@pci0:29:1: class=0x0c0300 card=0x798015d9 chip=0x27c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci2@pci0:29:2: class=0x0c0300 card=0x798015d9 chip=0x27ca8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci3@pci0:29:3: class=0x0c0300 card=0x798015d9 chip=0x27cb8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB ehci0@pci0:29:7: class=0x0c0320 card=0x798015d9 chip=0x27cc8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB pcib7@pci0:30:0: class=0x060401 card=0x798015d9 chip=0x244e8086 rev=0xe1 hdr=0x01 vendor = 'Intel Corporation' device = '82801BA/CA/DB/DBL/EB/ER/FB (ICH2/3/4/4/5/5/6), 6300ESB Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:31:0: class=0x060100 card=0x798015d9 chip=0x27b88086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB/GR (ICH7 Family) LPC Interface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:31:1: class=0x01018a card=0x798015d9 chip=0x27df8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) Ultra ATA Storage Controller' class = mass storage subclass = ATA none0@pci0:31:3: class=0x0c0500 card=0x798015d9 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus pcib3@pci9:0:0: class=0x060400 card=0x00000000 chip=0x032c8086 rev=0x09 hdr=0x01 vendor = 'Intel Corporation' device = '6702PXH PCI Express-to-PCI Express Bridge' class = bridge subclass = PCI-PCI ioapic0@pci9:0:1: class=0x080020 card=0x798015d9 chip=0x03268086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'PCI Bridge Hub I/OxAPIC Interrupt Controller A' class = base peripheral subclass = interrupt controller pcib4@pci10:1:0: class=0x060400 card=0x00000000 chip=0x03358086 rev=0x0a hdr=0x01 vendor = 'Intel Corporation' device = '80331 [Lindsay] I/O processor PCI-X bridge' class = bridge subclass = PCI-PCI arcmsr0@pci11:14:0: class=0x010400 card=0x111017d3 chip=0x111017d3 rev=0x00 hdr=0x00 vendor = 'Areca Technology Corporation' device = 'ARC-1110 4-Port PCI-X to SATA RAID Controller' class = mass storage subclass = RAID em0@pci13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PM' class = network subclass = ethernet em1@pci14:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet none1@pci15:0:0: class=0x030000 card=0x798015d9 chip=0x515e1002 rev=0x02 hdr=0x00 vendor = 'ATI Technologies Inc' class = display subclass = VGA [pmurray@chance ~]$ From owner-freebsd-stable@FreeBSD.ORG Fri Oct 19 23:46:09 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EF6616A468 for ; Fri, 19 Oct 2007 23:46:09 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 589EA13C448 for ; Fri, 19 Oct 2007 23:46:09 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 54C961A4D8D; Fri, 19 Oct 2007 16:28:46 -0700 (PDT) Date: Fri, 19 Oct 2007 16:28:46 -0700 From: Alfred Perlstein To: stable@freebsd.org Message-ID: <20071019232846.GQ31826@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: jhb@freebsd.org Subject: LOCK_PROFILING in -stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2007 23:46:09 -0000 Hey guys, I have LOCK_PROFILING done for a product based on FreeBSD-6, this means I can relatively easily backport LOCK_PROFILING from FreeBSD-7 to FreeBSD-6. Do we want this? I'd like to do it if people want it. -- - Alfred Perlstein From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 00:32:26 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B65F16A468 for ; Sat, 20 Oct 2007 00:32:26 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by mx1.freebsd.org (Postfix) with ESMTP id C8B5513C442 for ; Sat, 20 Oct 2007 00:32:25 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so521928rvb for ; Fri, 19 Oct 2007 17:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=VZBhWmUN3dvJMgKptK1f8OMyyGLA10AEJduDNnRvzwk=; b=cDuxmwo9EmEoR2DpFAm6UwLW1AqciaCEOdWo/NE7qcj4EUNSZ9kNsG3YasgiQlSMjYM2pDxfFJCUJ0ynJflW7Eygcks+AhP8wu1OrO1mh8XtfnigGQEYtTiKPDVyZ/Wj9o1aUHuPa6QLVrjhkmrZpYurJxtwDfAOAsuuhpqPFPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EMdBoSCsBOaAC568lr6yL4EcNlCwzUUL8VLLbM/q7YT8aLn5Ym5It9C4AeFafB5rdEYkeI6c0QI8JrADcCNgj/Tg75MDVr7n4qVxfaGQRmDF9SJWhii4KzMU1bHCqxYw/3J7puB38AHVkWeC1mjk3iNh5bok+PGKp0AUY0KMBxU= Received: by 10.114.150.1 with SMTP id x1mr2644498wad.1192840345492; Fri, 19 Oct 2007 17:32:25 -0700 (PDT) Received: by 10.114.177.13 with HTTP; Fri, 19 Oct 2007 17:32:25 -0700 (PDT) Message-ID: <2a41acea0710191732k2b2b193ag73b5cac12be9fde3@mail.gmail.com> Date: Fri, 19 Oct 2007 17:32:25 -0700 From: "Jack Vogel" To: "Philip Murray" In-Reply-To: <5CCABF9E-80DD-4E46-80AA-6E3E1F156645@nevada.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5CCABF9E-80DD-4E46-80AA-6E3E1F156645@nevada.net.nz> Cc: freebsd-stable@freebsd.org Subject: Re: em 6.6.6 - watchdog timeout X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 00:32:26 -0000 OK, I will look into this as soon as I can. Jack On 10/19/07, Philip Murray wrote: > > On 20/10/2007, at 1:06 AM, Goran Lowkrantz wrote: > > > Hi, > > > > After the update of em to 6.6.6 last, I experience watchdog timeouts > > on a server running 6-STABLE. > > > > "me too" on a Supermicro 5015MT+, although I notice my em0 is also > sharing an interrupt with USB (uhci3)... not sure if that's the culprit. > > > > [pmurray@chance ~]$ dmesg > Copyright (c) 1992-2007 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 6.2-STABLE #0: Tue Oct 9 07:45:50 NZDT 2007 > root@chance.open2view.net:/usr/obj/usr/src/sys/GENERIC > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(R) CPU X3220 @ 2.40GHz (2394.01-MHz 686- > class CPU) > Origin = "GenuineIntel" Id = 0x6f7 Stepping = 7 > > Features > = > 0xbfebfbff > < > FPU > ,VME > ,DE > ,PSE > ,TSC > ,MSR > ,PAE > ,MCE > ,CX8 > ,APIC > ,SEP > ,MTRR > ,PGE > ,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Features2=0xe3bd > AMD Features=0x20100000 > AMD Features2=0x1 > Cores per package: 4 > real memory = 2146304000 (2046 MB) > avail memory = 2095353856 (1998 MB) > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > RF5413) > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > cpu0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci1: on pcib1 > pcib2: irq 17 at device 28.0 on pci0 > pci9: on pcib2 > pcib3: at device 0.0 on pci9 > pci10: on pcib3 > pcib4: at device 1.0 on pci10 > pci11: on pcib4 > arcmsr0: > mem 0xe0200000-0xe0200fff,0xe0800000-0xe0bfffff irq 26 at device > 14.0 on pci11 > ARECA RAID ADAPTER0: Driver Version 1.20.00.14 2007-2-05 > ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 > pcib5: irq 17 at device 28.4 on pci0 > pci13: on pcib5 > em0: port > 0x4000-0x401f mem 0xe0300000-0xe031ffff irq 16 at device 0.0 on pci13 > em0: Ethernet address: 00:30:48:90:48:dc > em0: [FAST] > pcib6: irq 16 at device 28.5 on pci0 > pci14: on pcib6 > em1: port > 0x5000-0x501f mem 0xe0400000-0xe041ffff irq 17 at device 0.0 on pci14 > em1: Ethernet address: 00:30:48:90:48:dd > em1: [FAST] > uhci0: port 0x3000-0x301f irq 23 at > device 29.0 on pci0 > uhci0: [GIANT-LOCKED] > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > uhci1: port 0x3020-0x303f irq 19 at > device 29.1 on pci0 > uhci1: [GIANT-LOCKED] > usb1: on uhci1 > usb1: USB revision 1.0 > uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 2 ports with 2 removable, self powered > uhci2: port 0x3040-0x305f irq 18 at > device 29.2 on pci0 > uhci2: [GIANT-LOCKED] > usb2: on uhci2 > usb2: USB revision 1.0 > uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub2: 2 ports with 2 removable, self powered > uhci3: port 0x3060-0x307f irq 16 at > device 29.3 on pci0 > uhci3: [GIANT-LOCKED] > usb3: on uhci3 > usb3: USB revision 1.0 > uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub3: 2 ports with 2 removable, self powered > ehci0: mem > 0xe0000000-0xe00003ff irq 23 at device 29.7 on pci0 > ehci0: [GIANT-LOCKED] > usb4: EHCI version 1.0 > usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 > usb4: on ehci0 > usb4: USB revision 2.0 > uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 > uhub4: 8 ports with 8 removable, self powered > pcib7: at device 30.0 on pci0 > pci15: on pcib7 > pci15: at device 0.0 (no driver attached) > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 > on acpi0 > sio0: type 16550A > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on > acpi0 > fdc0: [FAST] > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 > drq 3 on acpi0 > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode > ppc0: FIFO with 16/16/9 bytes threshold > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcbfff, > 0xcc000-0xccfff,0xcd000-0xcdfff on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 > Timecounter "TSC" frequency 2394010800 Hz quality 800 > Timecounters tick every 1.000 msec > Waiting 5 seconds for SCSI devices to settle > acd0: CDROM at ata0-master UDMA33 > pass2 at arcmsr0 bus 0 target 16 lun 0 > pass2: Fixed Processor SCSI-0 device > da0 at arcmsr0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 166.666MB/s transfers (83.333MHz, offset 32, 16bit), Tagged > Queueing Enabled > da0: 28609MB (58592256 512 byte sectors: 255H 63S/T 3647C) > da1 at arcmsr0 bus 0 target 0 lun 1 > da1: Fixed Direct Access SCSI-5 device > da1: 166.666MB/s transfers (83.333MHz, offset 32, 16bit), Tagged > Queueing Enabled > da1: 2117156MB (4335936000 512 byte sectors: 255H 63S/T 269899C) > Trying to mount root from ufs:/dev/da0s1a > WARNING: /backup was not properly dismounted > em1: link state changed to UP > em1: link state changed to DOWN > em0: link state changed to UP > ums0: Cyclades SUN/PC USB Terminator, rev 1.00/15.00, addr 2, iclass 3/1 > ums0: 5 buttons and Z dir. > ukbd0: Cyclades SUN/PC USB Terminator, rev 1.00/15.00, addr 2, iclass > 3/1 > kbd2 at ukbd0 > ums0: at uhub0 port 1 (addr 2) disconnected > ums0: detached > ukbd0: at uhub0 port 1 (addr 2) disconnected > ukbd0: detached > gif0: promiscuous mode enabled > gif0: promiscuous mode disabled > gif0: promiscuous mode enabled > gif0: promiscuous mode disabled > gif0: promiscuous mode enabled > gif0: promiscuous mode disabled > em0: watchdog timeout -- resetting > em0: link state changed to DOWN > em0: link state changed to UP > pid 38534 (locate.code), uid 65534 inumber 32898 on /tmp: filesystem > full > em0: watchdog timeout -- resetting > em0: link state changed to DOWN > em0: link state changed to UP > em0: watchdog timeout -- resetting > em0: link state changed to DOWN > em0: link state changed to UP > em0: watchdog timeout -- resetting > em0: link state changed to DOWN > em0: link state changed to UP > em0: watchdog timeout -- resetting > em0: link state changed to DOWN > em0: link state changed to UP > em0: watchdog timeout -- resetting > em0: link state changed to DOWN > em0: link state changed to UP > em0: watchdog timeout -- resetting > em0: link state changed to DOWN > em0: link state changed to UP > em0: watchdog timeout -- resetting > em0: link state changed to DOWN > em0: link state changed to UP > > [pmurray@chance ~]$ vmstat -i > interrupt total rate > irq14: ata0 47 0 > irq16: em0 uhci3 9168265 9 > irq17: em1 107811254 114 > irq18: uhci2 32252905 34 > irq23: uhci0 ehci0 738 0 > irq26: arcmsr0 33035746 34 > cpu0: timer 1889578811 1999 > Total 2071847766 2192 > > > > [pmurray@chance ~]$ pciconf -lv > hostb0@pci0:0:0: class=0x060000 card=0x798015d9 chip=0x27788086 > rev=0xc0 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Server Memory Controller Hub' > class = bridge > subclass = HOST-PCI > pcib1@pci0:1:0: class=0x060400 card=0x798015d9 chip=0x27798086 > rev=0xc0 hdr=0x01 > vendor = 'Intel Corporation' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > pcib2@pci0:28:0: class=0x060400 card=0x798015d9 chip=0x27d08086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) PCI Express Root Port' > class = bridge > subclass = PCI-PCI > pcib5@pci0:28:4: class=0x060400 card=0x798015d9 chip=0x27e08086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801GR/GH/GHM (ICH7 Family) PCI Express Root Port' > class = bridge > subclass = PCI-PCI > pcib6@pci0:28:5: class=0x060400 card=0x798015d9 chip=0x27e28086 > rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801GR/GH/GHM (ICH7 Family) PCI Express Root Port' > class = bridge > subclass = PCI-PCI > uhci0@pci0:29:0: class=0x0c0300 card=0x798015d9 chip=0x27c88086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > uhci1@pci0:29:1: class=0x0c0300 card=0x798015d9 chip=0x27c98086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > uhci2@pci0:29:2: class=0x0c0300 card=0x798015d9 chip=0x27ca8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > uhci3@pci0:29:3: class=0x0c0300 card=0x798015d9 chip=0x27cb8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB Universal Host Controller' > class = serial bus > subclass = USB > ehci0@pci0:29:7: class=0x0c0320 card=0x798015d9 chip=0x27cc8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' > class = serial bus > subclass = USB > pcib7@pci0:30:0: class=0x060401 card=0x798015d9 chip=0x244e8086 > rev=0xe1 hdr=0x01 > vendor = 'Intel Corporation' > device = '82801BA/CA/DB/DBL/EB/ER/FB (ICH2/3/4/4/5/5/6), 6300ESB > Hub Interface to PCI Bridge' > class = bridge > subclass = PCI-PCI > isab0@pci0:31:0: class=0x060100 card=0x798015d9 chip=0x27b88086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801GB/GR (ICH7 Family) LPC Interface Controller' > class = bridge > subclass = PCI-ISA > atapci0@pci0:31:1: class=0x01018a card=0x798015d9 chip=0x27df8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) Ultra ATA Storage Controller' > class = mass storage > subclass = ATA > none0@pci0:31:3: class=0x0c0500 card=0x798015d9 chip=0x27da8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801G (ICH7 Family) SMBus Controller' > class = serial bus > subclass = SMBus > pcib3@pci9:0:0: class=0x060400 card=0x00000000 chip=0x032c8086 > rev=0x09 hdr=0x01 > vendor = 'Intel Corporation' > device = '6702PXH PCI Express-to-PCI Express Bridge' > class = bridge > subclass = PCI-PCI > ioapic0@pci9:0:1: class=0x080020 card=0x798015d9 chip=0x03268086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = 'PCI Bridge Hub I/OxAPIC Interrupt Controller A' > class = base peripheral > subclass = interrupt controller > pcib4@pci10:1:0: class=0x060400 card=0x00000000 chip=0x03358086 > rev=0x0a hdr=0x01 > vendor = 'Intel Corporation' > device = '80331 [Lindsay] I/O processor PCI-X bridge' > class = bridge > subclass = PCI-PCI > arcmsr0@pci11:14:0: class=0x010400 card=0x111017d3 chip=0x111017d3 > rev=0x00 hdr=0x00 > vendor = 'Areca Technology Corporation' > device = 'ARC-1110 4-Port PCI-X to SATA RAID Controller' > class = mass storage > subclass = RAID > em0@pci13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'PRO/1000 PM' > class = network > subclass = ethernet > em1@pci14:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > none1@pci15:0:0: class=0x030000 card=0x798015d9 chip=0x515e1002 > rev=0x02 hdr=0x00 > vendor = 'ATI Technologies Inc' > class = display > subclass = VGA > [pmurray@chance ~]$ > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 03:20:38 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A250516A419 for ; Sat, 20 Oct 2007 03:20:38 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.freebsd.org (Postfix) with ESMTP id 3BCE313C459 for ; Sat, 20 Oct 2007 03:20:37 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so1399423pyb for ; Fri, 19 Oct 2007 20:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=/Hy93UUvPFBv3xuA8In47fEFGJmmzHDoMPO8CkwH1x4=; b=a6e9TRXqe5RmDJciPYzwupr8Fu+ND6FlTsBKt/YGfdNEvp+3olRY+gwY50+1RXTUTpAfCH88NQLWHHd8LPEMrd4x2q2LlrDdcUD0T6RQsrX9kw8lfkbL2fGN4p4UodWNZeqGqs5zaO6lke817Y7ALzhwaybprP7EUCEmBa4LHUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=do5h8SMCtZ0rz9t1E/cwjaoGKFGeUhFgj+Ms/GfoVKmm7yLqMpQXtdVtsUJ1G5yFFy+iwFtWHkAqu5XcFIoZ1BNuQu3avur6Kku+28kjIHl0ibOKB2Rz/62G2XTP5IwVIXmMrieITXhbbMCwttMzviJChbuLmX4/qy4lNiqsa2g= Received: by 10.35.121.12 with SMTP id y12mr2873016pym.1192850436667; Fri, 19 Oct 2007 20:20:36 -0700 (PDT) Received: by 10.35.117.12 with HTTP; Fri, 19 Oct 2007 20:20:36 -0700 (PDT) Message-ID: <8cb6106e0710192020r1b3f3948p41b1b88018a146c6@mail.gmail.com> Date: Fri, 19 Oct 2007 23:20:36 -0400 From: "Josh Carroll" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: em lockups during heavy network I/O on RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 03:20:38 -0000 Hello, I have managed to lock my (amd64, RELENG_7) machine up twice today. In both cases, I was transferring a file to my laptop (in one case over SMB, the other over FTP). Both resulted in a hard lock (no panic). One of the lockups had an "em1: watchdog timeout" message on the console, the other had no abnormal messages on the console. Both transfers were over 100baseTx-FD ethernet over my em card (em1). This is a new occurrence on RELENG_7. The box was stable on 6.2-RELEASE. The hardware is as follows: Asus P5B motherboard (BIOS revison 1405) Intel Core 2 Quad Q6600 Two Intel em cards (em0: internet facing, em1: LAN facing) Further below is my full kernel config, but here are the options I have that GENERIC does not (not necessarily in order, as they were sorted when I was diff'ing with GENERIC): device atapicam device coretemp device if_bridge device pf device pflog device tap ident PFLOG64 machine amd64 makeoptions COPTFLAGS="-O2 -pipe" options ALTQ options ALTQ_CBQ options ALTQ_HFSC options ALTQ_NOPCC options ALTQ_PRIQ options ALTQ_RED options ALTQ_RIO options COMPAT_LINUX32 options HZ=1000 options LIBICONV options LIBMCHAIN options NETSMB options SC_PIXEL_MODE options SMBFS options UDF options VGA_WIDTH90 I plan on removing the HZ, LIBICONV, LIBMCHAIN, SC_PIXEL_MODE, and VGA_WIDTH90 options and seeing if that helps. Do any of the other options look like likely culprits? If the above doesn't help, is there a way to debug hard lockups? I have 15mbit FiOS and have maxed em0 out without causing this. So I'm guessing either I'm not pushing enough packets through em0 to induce this, or the problem is related to em1 sharing an interrupt with a USB controller: interrupt total rate irq1: atkbd0 6 0 irq6: fdc0 10 0 irq17: uhci1+ 91 0 irq19: uhci3+ 924492 32 irq22: em0 85919 3 irq23: em1 uhci2+ 6627 0 cpu0: timer 56950868 1999 cpu1: timer 56950834 1999 cpu2: timer 56950835 1999 cpu3: timer 56950834 1999 Total 228820516 8035 Anyway, here is the full kernel configuration: makeoptions COPTFLAGS="-O2 -pipe" machine amd64 cpu HAMMER ident PFLOG64 options COMPAT_IA32 options COMPAT_LINUX32 ########################################################################## options SMP # Symmetric MultiProcessor Kernel options STOP_NMI options SCHED_4BSD options PREEMPTION options HZ=1000 options INET # InterNETworking 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 options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NETSMB options SMBFS options LIBICONV options LIBMCHAIN options CD9660 # ISO 9660 Filesystem options UDF options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_LABEL # Provides labelization options GEOM_PART_GPT # GUID Partition Tables. options COMPAT_43TTY # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. options AUDIT # Security event auditing # Bus support. Do not remove isa, even if you have no isa slots device pci device acpi # Floppy drives device fdc # coretemp: on-die sensor on Intel Core and newer CPUs device coretemp # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) device atapicam # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver options VGA_WIDTH90 options SC_PIXEL_MODE device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device if_bridge # PCI Ethernet NICs. device em # Intel PRO/1000 adapter Gigabit Ethernet Card # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device tap device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" # 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 pf device pflog # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device ugen # Generic device umass # Disks/Mass storage - Requires scbus and da # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) # altq support options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) options ALTQ_NOPCC # Required for SMP build Thanks! Josh From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 03:24:45 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8572716A419 for ; Sat, 20 Oct 2007 03:24:45 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.freebsd.org (Postfix) with ESMTP id 19EED13C45A for ; Sat, 20 Oct 2007 03:24:44 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so1400685pyb for ; Fri, 19 Oct 2007 20:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=K5v9H5ucuu99/k+hdX8LzVNkc/ss02X/gLc0R7pME5w=; b=ixgtlaukewTPSrHIvklW7kegKPL2RsmJR+iNx25OUiN5tuHZgpASRoVL05BMYux+u0N4zlXhnRX1phv1/BT8k+HzOJi1kAl7+IpQpu4U9INP+/cPvqYTawXmeF/kYwsbZ7rPSXamzlyUW8fLHWg5ssVasSXtM1soVzXAuU8itco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tPLxeEt5A8jVFT0zoVfqS0hucjFVjcaQW5w3QW5jecFPLcmvBxmm+5r/png7f7rdiEPQiDThIsdZJd7RmQjsWJaHnS5XYtSoZ4dTMH/jQ5/SR/Tl4Q0m7y7fj8T+1IFHPOSXs2QjdMb+DpHsEFFCBBvOLnd0RI4P+8ve83FnF/k= Received: by 10.35.30.8 with SMTP id h8mr2879910pyj.1192850684128; Fri, 19 Oct 2007 20:24:44 -0700 (PDT) Received: by 10.35.117.12 with HTTP; Fri, 19 Oct 2007 20:24:44 -0700 (PDT) Message-ID: <8cb6106e0710192024q6292327byf49bce3417e3ec69@mail.gmail.com> Date: Fri, 19 Oct 2007 23:24:44 -0400 From: "Josh Carroll" To: freebsd-stable@freebsd.org In-Reply-To: <8cb6106e0710192020r1b3f3948p41b1b88018a146c6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8cb6106e0710192020r1b3f3948p41b1b88018a146c6@mail.gmail.com> Subject: Re: em lockups during heavy network I/O on RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 03:24:45 -0000 Sorry, I should have also included dmesg output. The "not properly dismounted" errors are obviously from the last crash :) Here is /var/run/dmesg.boot: Copyright (c) 1992-2007 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 7.0-PRERELEASE #4: Tue Oct 16 16:00:16 EDT 2007 root@pflog.net:/usr/obj/usr/src/sys/PFLOG Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (3400.28-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 4 usable memory = 2139217920 (2040 MB) avail memory = 2064588800 (1968 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard netsmb_dev: loaded acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 coretemp0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 cpu2: on acpi0 coretemp2: on cpu2 cpu3: on acpi0 coretemp3: on cpu3 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xfd000000-0xfdffffff,0xc0000000-0xcfffffff,0xfc000000-0xfcffffff irq 16 at device 0.0 on pci1 uhci0: port 0xe000-0xe01f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe080-0xe09f irq 17 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: mem 0xfebff400-0xfebff7ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 4 ports with 4 removable, self powered pcib2: irq 16 at device 28.0 on pci0 pci3: on pcib2 pcib3: irq 16 at device 28.4 on pci0 pci2: on pcib3 atapci0: mem 0xfe8fe000-0xfe8fffff irq 16 at device 0.0 on pci2 atapci0: AHCI Version 01.00 controller with 2 ports detected ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f at device 0.1 on pci2 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] uhci2: port 0xd800-0xd81f irq 23 at device 29.0 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: port 0xd880-0xd89f irq 19 at device 29.1 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xdc00-0xdc1f irq 18 at device 29.2 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0xfebff000-0xfebff3ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 uhub6: 6 ports with 6 removable, self powered pcib4: at device 30.0 on pci0 pci4: on pcib4 em0: port 0xcc00-0xcc3f mem 0xfeae0000-0xfeafffff,0xfeac0000-0xfeadffff irq 22 at device 1.0 on pci4 em0: Ethernet address: 00:0e:0c:6c:b9:16 em0: [FILTER] em1: port 0xc880-0xc8bf mem 0xfea80000-0xfea9ffff,0xfea60000-0xfea7ffff irq 23 at device 2.0 on pci4 em1: Ethernet address: 00:0e:0c:6c:b9:0a em1: [FILTER] isab0: at device 31.0 on pci0 isa0: on isab0 atapci2: port 0xec00-0xec07,0xe880-0xe883,0xe800-0xe807,0xe480-0xe483,0xe400-0xe41f mem 0xfebff800-0xfebfffff irq 19 at device 31.2 on pci0 atapci2: [ITHREAD] atapci2: AHCI Version 01.10 controller with 4 ports detected ata3: on atapci2 ata3: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: port not implemented ata5: [ITHREAD] ata6: on atapci2 ata6: port not implemented ata6: [ITHREAD] ata7: on atapci2 ata7: [ITHREAD] ata8: on atapci2 ata8: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4 orm0: at iomem 0xd2000-0xd2fff,0xd3000-0xd3fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: DVDR at ata2-master UDMA66 ad6: 476940MB at ata3-master SATA300 ad8: 381553MB at ata4-master SATA150 ad14: 476940MB at ata7-master SATA300 SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! Trying to mount root from ufs:/dev/ad6s1a WARNING: / was not properly dismounted acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 cd0 at ata2 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 66.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present WARNING: /tmp was not properly dismounted WARNING: /var was not properly dismounted WARNING: /data/video was not properly dismounted WARNING: /backup was not properly dismounted Thanks, Josh From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 04:03:47 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82CB216A418 for ; Sat, 20 Oct 2007 04:03:47 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5F34013C467 for ; Sat, 20 Oct 2007 04:03:47 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 23BE21CC02E; Fri, 19 Oct 2007 21:03:47 -0700 (PDT) Date: Fri, 19 Oct 2007 21:03:47 -0700 From: Jeremy Chadwick To: Philip Murray Message-ID: <20071020040347.GA71660@eos.sc1.parodius.com> Mail-Followup-To: Philip Murray , Goran Lowkrantz , freebsd-stable@freebsd.org References: <5CCABF9E-80DD-4E46-80AA-6E3E1F156645@nevada.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5CCABF9E-80DD-4E46-80AA-6E3E1F156645@nevada.net.nz> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: em 6.6.6 - watchdog timeout X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 04:03:47 -0000 On Sat, Oct 20, 2007 at 11:21:10AM +1300, Philip Murray wrote: > "me too" on a Supermicro 5015MT+, although I notice my em0 is also sharing > an interrupt with USB (uhci3)... not sure if that's the culprit. I'm not aware of a 5015MT+ model. Maybe you mean 5015M-MT+ or 5015M-T+? We have two 5015M-T+ boxes, one running RELENG_7 and one running RELENG_6, and neither exhibit this problem. Here's relevant em(4) information from both boxes; I do find the vmstat -i IRQ on the 2nd box a little odd, but operationally it seems fine. box1 (RELENG_6) =============== em0: port 0x4000-0x401f mem 0xe0200000-0xe021ffff irq 16 at device 0.0 on pci13 em1: port 0x5000-0x501f mem 0xe0300000-0xe031ffff irq 17 at device 0.0 on pci14 irq16: em0 uhci3 117371806 11 irq17: em1 49605005 4 box2 (RELENG_7) =============== em0: port 0x4000-0x401f mem 0xe8000000-0xe801ffff irq 16 at device 0.0 on pci13 em1: port 0x5000-0x501f mem 0xe8200000-0xe821ffff irq 17 at device 0.0 on pci14 irq256: em0 502854 4 irq257: em1 5438 0 On box2, IRQ 16 is also shared with uhci3 and vgapci0, but vmstat doesn't seem to show that. uhci3: port 0x3060-0x307f irq 16 at device 29.3 on pci0 vgapci0: port 0x6000-0x60ff mem 0xe0000000-0xe7ffffff,0xe8300000-0xe830ffff irq 16 at device 0.0 on pci15 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 04:07:25 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9185816A418 for ; Sat, 20 Oct 2007 04:07:25 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6DBDC13C45A for ; Sat, 20 Oct 2007 04:07:23 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 95BD51CC037; Fri, 19 Oct 2007 21:07:23 -0700 (PDT) Date: Fri, 19 Oct 2007 21:07:23 -0700 From: Jeremy Chadwick To: Josh Carroll Message-ID: <20071020040723.GB71660@eos.sc1.parodius.com> Mail-Followup-To: Josh Carroll , freebsd-stable@freebsd.org References: <8cb6106e0710192020r1b3f3948p41b1b88018a146c6@mail.gmail.com> <8cb6106e0710192024q6292327byf49bce3417e3ec69@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8cb6106e0710192024q6292327byf49bce3417e3ec69@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: em lockups during heavy network I/O on RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 04:07:25 -0000 On Fri, Oct 19, 2007 at 11:24:44PM -0400, Josh Carroll wrote: > Sorry, I should have also included dmesg output. The "not properly > dismounted" errors are obviously from the last crash :) There's another thread on this issue, although that thread seems to apply to a specific version (of em(4) code, or of NIC PROM revision -- I don't know, the dmesg output is somewhat ambiguous). http://lists.freebsd.org/pipermail/freebsd-stable/2007-October/037447.html Jack says he's looking into it. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 04:10:21 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D18316A417 for ; Sat, 20 Oct 2007 04:10:21 +0000 (UTC) (envelope-from pmurray@nevada.net.nz) Received: from bellagio.open2view.net (bellagio.open2view.net [210.48.79.75]) by mx1.freebsd.org (Postfix) with ESMTP id F070413C457 for ; Sat, 20 Oct 2007 04:09:42 +0000 (UTC) (envelope-from pmurray@nevada.net.nz) Received: from [10.0.0.5] (125-237-174-244.jetstream.xtra.co.nz [125.237.174.244]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bellagio.open2view.net (Postfix) with ESMTP id D158995E68A; Sat, 20 Oct 2007 17:09:40 +1300 (NZDT) Message-Id: From: Philip Murray To: Jeremy Chadwick In-Reply-To: <20071020040347.GA71660@eos.sc1.parodius.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v890.2) Date: Sat, 20 Oct 2007 17:09:39 +1300 References: <5CCABF9E-80DD-4E46-80AA-6E3E1F156645@nevada.net.nz> <20071020040347.GA71660@eos.sc1.parodius.com> X-Mailer: Apple Mail (2.890.2) Cc: freebsd-stable@freebsd.org Subject: Re: em 6.6.6 - watchdog timeout X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 04:10:21 -0000 On 20/10/2007, at 5:03 PM, Jeremy Chadwick wrote: > On Sat, Oct 20, 2007 at 11:21:10AM +1300, Philip Murray wrote: >> "me too" on a Supermicro 5015MT+, although I notice my em0 is also >> sharing >> an interrupt with USB (uhci3)... not sure if that's the culprit. > > I'm not aware of a 5015MT+ model. Maybe you mean 5015M-MT+ or > 5015M-T+? > > We have two 5015M-T+ boxes, one running RELENG_7 and one running > RELENG_6, and neither exhibit this problem. Here's relevant em(4) > information from both boxes; I do find the vmstat -i IRQ on the 2nd > box a little odd, but operationally it seems fine. > > box1 (RELENG_6) > =============== > em0: port > 0x4000-0x401f mem 0xe0200000-0xe021ffff irq 16 at device 0.0 on pci13 > em1: port > 0x5000-0x501f mem 0xe0300000-0xe031ffff irq 17 at device 0.0 on pci14 > > irq16: em0 uhci3 117371806 11 > irq17: em1 49605005 4 > > > box2 (RELENG_7) > =============== > em0: port > 0x4000-0x401f mem 0xe8000000-0xe801ffff irq 16 at device 0.0 on pci13 > em1: port > 0x5000-0x501f mem 0xe8200000-0xe821ffff irq 17 at device 0.0 on pci14 > > irq256: em0 502854 4 > irq257: em1 5438 0 > > > On box2, IRQ 16 is also shared with uhci3 and vgapci0, but vmstat > doesn't seem to show that. > > uhci3: port 0x3060-0x307f irq 16 at > device 29.3 on pci0 > vgapci0: port 0x6000-0x60ff mem > 0xe0000000-0xe7ffffff,0xe8300000-0xe830ffff irq 16 at device 0.0 on > pci15 > Hi Jeremy You don't seem to be running the 6.6.6 driver, which is when the watchdog timeouts started occurring. Had no problems with 6.2.9. Cheers Phil From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 04:10:42 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 895FB16A41B for ; Sat, 20 Oct 2007 04:10:42 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 2EC5513C467 for ; Sat, 20 Oct 2007 04:10:30 +0000 (UTC) (envelope-from josh.carroll@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so1414289pyb for ; Fri, 19 Oct 2007 21:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=w17U3dWAmJMIagCQcHakMMPLcp6MXTZ4rG9ITMOnMKI=; b=YJLNdPeOxV8ZEnEFe5B+LZNfGVqPYZ1FjvaeummM3gkXDh3lygNzMBUYJGEfEiN6Bep6sGSOm9Jw9fx/GDSDAzETWaByg3rmT/elOToKb/f3ODJ8Cj1KAVthIra6wWpf9ZmK7Lg5N0mx/2lSMl+ZcmM0vgkj6aZcrg2qA6/IyrQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qdxrDji1Ai2omujrUQ7OFldFbV33vhCT1TZmBzDgQi8b7V5wttr7r9TVKKBSLkqsqUiiWnjMD4Wddz3sVL/2+eXG0ydOSiKNtF6zRzqvuAwE9OzeTRBNSDH0R7bR5SWVF1CdH33vlhVOQ4nY1XbOgu8Fj9czNGdrUXQqZZsraxw= Received: by 10.35.40.10 with SMTP id s10mr2911073pyj.1192853430354; Fri, 19 Oct 2007 21:10:30 -0700 (PDT) Received: by 10.35.117.12 with HTTP; Fri, 19 Oct 2007 21:10:30 -0700 (PDT) Message-ID: <8cb6106e0710192110q13d28949j15ce3947bbec4c01@mail.gmail.com> Date: Sat, 20 Oct 2007 00:10:30 -0400 From: "Josh Carroll" To: freebsd-stable@freebsd.org In-Reply-To: <20071020040723.GB71660@eos.sc1.parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8cb6106e0710192020r1b3f3948p41b1b88018a146c6@mail.gmail.com> <8cb6106e0710192024q6292327byf49bce3417e3ec69@mail.gmail.com> <20071020040723.GB71660@eos.sc1.parodius.com> Subject: Re: em lockups during heavy network I/O on RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: josh.carroll@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 04:10:42 -0000 > There's another thread on this issue, although that thread seems to > apply to a specific version (of em(4) code, or of NIC PROM revision -- I > don't know, the dmesg output is somewhat ambiguous). Ah sorry, I did see that thread, but did notice the em version was different, and that it didn't appear to be causing a hard lock of the machine. I suppose it could be related, though. Should I track/post to that thread, instead? Sorry if this is a duplicate issue, but it seemed the symptoms were different. Thanks, Josh From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 05:08:16 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2D9616A417 for ; Sat, 20 Oct 2007 05:08:16 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id D605F13C45D for ; Sat, 20 Oct 2007 05:08:16 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 6812C1CC02E; Fri, 19 Oct 2007 22:08:16 -0700 (PDT) Date: Fri, 19 Oct 2007 22:08:16 -0700 From: Jeremy Chadwick To: Josh Carroll Message-ID: <20071020050816.GA75590@eos.sc1.parodius.com> Mail-Followup-To: Josh Carroll , freebsd-stable@freebsd.org References: <8cb6106e0710192020r1b3f3948p41b1b88018a146c6@mail.gmail.com> <8cb6106e0710192024q6292327byf49bce3417e3ec69@mail.gmail.com> <20071020040723.GB71660@eos.sc1.parodius.com> <8cb6106e0710192110q13d28949j15ce3947bbec4c01@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8cb6106e0710192110q13d28949j15ce3947bbec4c01@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-stable@freebsd.org Subject: Re: em lockups during heavy network I/O on RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 05:08:17 -0000 On Sat, Oct 20, 2007 at 12:10:30AM -0400, Josh Carroll wrote: > > There's another thread on this issue, although that thread seems to > > apply to a specific version (of em(4) code, or of NIC PROM revision -- I > > don't know, the dmesg output is somewhat ambiguous). > > Ah sorry, I did see that thread, but did notice the em version was > different, and that it didn't appear to be causing a hard lock of the > machine. I suppose it could be related, though. Should I track/post to > that thread, instead? Sorry if this is a duplicate issue, but it > seemed the symptoms were different. My apologies -- after being educated (the version number shown in the device output is actually the driver version and not a PROM version), your issue here is likely separate. The driver revision shown here is 6.5.3. Jack should be able to help track this down though... (I like how I'm volunteering him for more work, haha. :-) ) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 05:19:01 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C9A116A418 for ; Sat, 20 Oct 2007 05:19:01 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (mail.ismobile.com [62.119.44.68]) by mx1.freebsd.org (Postfix) with ESMTP id 8240613C45D for ; Sat, 20 Oct 2007 05:18:59 +0000 (UTC) (envelope-from goran.lowkrantz@ismobile.com) Received: from mail.ismobile.com (localhost [127.0.0.1]) by mail.ismobile.com (Postfix) with ESMTP id E378A33C02 for ; Sat, 20 Oct 2007 07:18:57 +0200 (CEST) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=ismobile.com; h=received:date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding:content-disposition; q=dns/txt; s=selector1; bh=9u4Z+nxDpAA9hehwSyuZVk7e0sI=; b=jMa2UC2ZYhDF6zFDpwsgBB6K92eNeBnmtcOYwdaiRy7adwnk02hjUxvckgAfMxfXD4jSm1CqUAAwP0UodDVa6JMnQXXnEvz5uxnY8O6dzNINe6eXt9UZsL5Nye2irg7RWO0si8sPVbOZetiXaTR6DV+eM4IXgnewF1/GDuDAfds= Received: from [10.255.253.2] (modgunn.iii-norr.com [213.242.135.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ismobile.com (Postfix) with ESMTP id C197E33C01 for ; Sat, 20 Oct 2007 07:18:57 +0200 (CEST) Date: Sat, 20 Oct 2007 07:18:56 +0200 From: Goran Lowkrantz To: freebsd-stable@freebsd.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: em 6.6.6 - watchdog timeout X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 05:19:01 -0000 wrote: > Hi, > > After the update of em to 6.6.6 last, I experience watchdog timeouts on a > server running 6-STABLE. > > I have two identical servers with Intel D915GAV boards. Both have Intel > PRO/1000 PCI-Express network cards. > > Server balder: > em0: port > 0xac00-0xac1f mem 0xff600000-0xff61ffff,0xff620000-0xff63ffff irq 16 at > device 0.0 on pci5 > em0: Ethernet address: 00:1b:21:00:48:c4 > em0: [FAST] > ># vmstat -i > interrupt total rate > irq1: atkbd0 3 0 > irq4: sio0 2 0 > irq6: fdc0 12 0 > irq14: ata0 68 0 > irq16: em0 uhci3 219828879 450 > irq19: uhci1++ 4287947 8 > irq22: ahc0 232717293 476 > irq23: uhci0 ehci0 1 0 > cpu0: timer 976552804 2000 > Total 1433387009 2935 > ># netstat -i > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs > Coll > em0 1500 00:1b:21:00:48:c4 209880531 773 206555522 > 84 0 > em0 1500 10.255.253/24 balder 215210996 - 212337968 > - - > plip0 1500 0 0 0 0 > 0 > lo0 16384 12040055 0 12055326 0 > 0 > lo0 16384 fe80:3::1 fe80:3::1 0 - 0 - > - > lo0 16384 localhost ::1 6 - 6 - > - > lo0 16384 your-net localhost 6249979 - 6249980 - > - > > 00:00.0 Host bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL Memory > Controller Hub (rev 04) > 00:01.0 PCI bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL PCI Express > Root Port (rev 04) > 00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL > Integrated Graphics Controller (rev 04) > 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) > PCI Express Port 1 (rev 03) > 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) > PCI Express Port 2 (rev 03) > 00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) > PCI Express Port 3 (rev 03) > 00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) > PCI Express Port 4 (rev 03) > 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #1 (rev 03) > 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #2 (rev 03) > 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #3 (rev 03) > 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #4 (rev 03) > 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB2 EHCI Controller (rev 03) > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) > 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC > Interface Bridge (rev 03) > 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) IDE Controller (rev 03) > 00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA > Controller (rev 03) > 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) > SMBus Controller (rev 03) > 05:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet > Controller (Copper) (rev 06) > 06:01.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U (rev > 01) > > > Server midgard: > em0: port > 0xac00-0xac1f mem 0xff500000-0xff51ffff,0xff520000-0xff53ffff irq 16 at > device 0.0 on pci5 > em0: Ethernet address: 00:15:17:0e:05:f7 > admglz@midgard> vmstat -i > interrupt total rate > irq1: atkbd0 11 0 > irq4: sio0 2142746 0 > irq6: fdc0 14 0 > irq14: ata0 252 0 > irq16: em0+ 666640101 164 > irq19: atapci1+ 7932757 1 > irq22: ahc0 87074425 21 > cpu0: timer 3807810138 937 > Total 4571600444 1125 > > admglz@midgard> netstat -i > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs > Coll > em0 1500 00:15:17:0e:05:f7 343771280 0 474609731 > 0 0 > em0 1500 10.255.253/24 midgard 347467842 - 478700485 > - - > plip0 1500 0 0 0 0 > 0 > lo0 16384 16821054 0 16947668 0 > 0 > lo0 16384 fe80:3::1 fe80:3::1 0 - 0 - > - > lo0 16384 localhost ::1 2610 - 2610 - > - > lo0 16384 your-net localhost 12616879 - 12616879 - > - > lo0 16384 10.255.253.12 appsrv1 0 - 0 - > - > lo0 16384 10.255.253.10 ca.glz.hidden-pow 0 - 0 - > - > lo0 16384 10.255.253.11 test 0 - 0 - > - > lo0 16384 10.255.253.13 secure 0 - 0 - > - > lo0 16384 10.255.253.18 rscds.hidden-powe 7 - 0 - > - > > midgard# lspci > 00:00.0 Host bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL Memory > Controller Hub (rev 04) > 00:01.0 PCI bridge: Intel Corporation 82915G/P/GV/GL/PL/910GL PCI Express > Root Port (rev 04) > 00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL > Integrated Graphics Controller (rev 04) > 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) > PCI Express Port 1 (rev 03) > 00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) > PCI Express Port 2 (rev 03) > 00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) > PCI Express Port 3 (rev 03) > 00:1c.3 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) > PCI Express Port 4 (rev 03) > 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #1 (rev 03) > 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #2 (rev 03) > 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #3 (rev 03) > 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB UHCI #4 (rev 03) > 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) USB2 EHCI Controller (rev 03) > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3) > 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC > Interface Bridge (rev 03) > 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 > Family) IDE Controller (rev 03) > 00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA > Controller (rev 03) > 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) > SMBus Controller (rev 03) > 01:00.0 SCSI storage controller: Triones Technologies, Inc. Unknown > device 2310 (rev 02) > 05:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet > Controller (Copper) (rev 06) > 06:01.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U (rev > 01) > 06:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host > Controller (rev 46) > > > When running netstat between servers balder and midgard, server balder > get watchdog timeouts and resets the connection for a few seconds. > Oct 19 13:12:47 balder kernel: em0: watchdog timeout -- resetting > Oct 19 13:12:47 balder kernel: em0: link state changed to DOWN > Oct 19 13:12:51 balder kernel: em0: link state changed to UP > > I have switched the cable between the two servers but get exactly the > same problem. The switch is a Netgear GS108T with the latest firmware. > > The resp. dmesg.boot are attached. > > Please let me know if there is any other information I can supply to > clear this. > > Best regards, > G=F6ran L > I have managed to get my performance back in two ways: - Switching to polling. - Build a kernel without USB. So it's the interrupt sharing between the network card and a USB hub that's = the problem. /glz From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 07:15:35 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DEF116A419 for ; Sat, 20 Oct 2007 07:15:35 +0000 (UTC) (envelope-from cmdlnkid@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.freebsd.org (Postfix) with ESMTP id E75CE13C448 for ; Sat, 20 Oct 2007 07:15:34 +0000 (UTC) (envelope-from cmdlnkid@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so1461673pyb for ; Sat, 20 Oct 2007 00:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:reply-to:to:subject:message-id:x-openpgp-key:mime-version:content-type; bh=GdkipOeVFQRERjhn699paPj6DsHKNbNAimvnL/jph80=; b=SKGMzZirs+X3qa7vqDQQuG09Uleem7k9pRDgUKEEkti3knrgneDMgpMms+IZ5mB1BwyL3fUBVmfk+M59uYQfmi9ZHIBJgOgOhPx/kLiEN293KnnSaiZldsh68Kk+badZ4zHeGz2Qi3dj2lq0txi1bvTIXXbr3QO2JiYlAV4TiHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:reply-to:to:subject:message-id:x-openpgp-key:mime-version:content-type; b=n6Bv8w2B4U4snAuQ1q7vOHYizE/uJNIfDK5j+UTfcFbxVq5PK7mk3zbICYIsj4DLF1oESpr2o49/QC6gLiXhTt4UQ8PYMvmRi6UQWJoPQ/tkX6leDdmI35L87Jv0ZhLUNrXjNg3oPpbsVlB9+nQhZM1VmvNfl0bs+lzzSfX0wqk= Received: by 10.64.150.18 with SMTP id x18mr5109508qbd.1192864533609; Sat, 20 Oct 2007 00:15:33 -0700 (PDT) Received: from ppp-21.226.dialinfree.com ( [209.172.21.226]) by mx.google.com with ESMTPS id z21sm855148qbc.2007.10.20.00.15.29 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 20 Oct 2007 00:15:32 -0700 (PDT) Date: Sat, 20 Oct 2007 03:15:18 -0400 From: CmdLnKid To: freebsd-stable@freebsd.org Message-ID: <20071020024955.U6112@cbynevgl.hper> X-OpenPGP-Key: 0xDFFDD218 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: CmdLnKid List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 07:15:35 -0000 _ ._ _ , _ ._ (_ ' ( ` )_ .__) ( ( ( ) `) ) _) (__ (_ (_ . _) _) ,__) `~~`\ ' . /`~~` ,::: ; ; :::, ':::::::::::::::' __________________________________/_ __ \__________________________________ | | | Copyright (c) 1992-2007 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 6.2-STABLE #0: Sat Oct 20 04:58:39 UTC 2007 | | ----- CUT ----- | | acd0: CDRW at ata1-master UDMA33 | | acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 | | acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 | | cd0 at ata1 bus 0 target 0 lun 0 | | cd0: Removable CD-ROM SCSI-0 device | | cd0: 33.000MB/s transfers | | cd0: Attempt to query device size failed: NOT READY, Medium not present | |___________________________________________________________________________| Introduced-From: RELENG_6 (TODAY) Unproduced-With: RELENG_6_2 Questioned: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 I was curious if this is just some debug printf's that were thrown in thrown in the src of {acd?,ata?,pci?} or whatever ?. If not I have been looking in the wrong place for where this is coming from and would appreciate any feedback on this non-issue. The cd burner works just fine like in RELENG_6_2 as well as 4 & 5 but seeing this come up the way it has just raises the question in my mind that possible hardware failure might be eminent in the future. This seems to produce it self with a cd in the drive on boot or without one. Any other info on this non-issue is available on request. [Future thanks forwarded to any generated threads.] Sincerely, The Command Line Kid. -- - (2^(N-1)) From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 07:38:26 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EB9416A418; Sat, 20 Oct 2007 07:38:26 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id DA6CC13C4A5; Sat, 20 Oct 2007 07:38:24 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4719B06F.3000103@FreeBSD.org> Date: Sat, 20 Oct 2007 10:38:23 +0300 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Alfred Perlstein References: <20071019232846.GQ31826@elvis.mu.org> In-Reply-To: <20071019232846.GQ31826@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, jhb@freebsd.org Subject: Re: LOCK_PROFILING in -stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 07:38:26 -0000 Alfred Perlstein wrote: > Hey guys, I have LOCK_PROFILING done for a product based on FreeBSD-6, > this means I can relatively easily backport LOCK_PROFILING from > FreeBSD-7 to FreeBSD-6. > > Do we want this? > > I'd like to do it if people want it. I think it should be done, performance is a lot better than the old 6.x version and it also adds another very useful performance metric (time spent waiting for the lock). The only concern is that it doesn't break ABI support when not compiled in, but I'm pretty sure you've already told me this is OK. Thanks for looking at this. Kris From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 08:15:29 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F36D616A418 for ; Sat, 20 Oct 2007 08:15:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 790EE13C442 for ; Sat, 20 Oct 2007 08:15:13 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l9K8F7uA012957; Sat, 20 Oct 2007 02:15:08 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4719B8FA.6080402@samsco.org> Date: Sat, 20 Oct 2007 02:14:50 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: CmdLnKid References: <20071020024955.U6112@cbynevgl.hper> In-Reply-To: <20071020024955.U6112@cbynevgl.hper> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Sat, 20 Oct 2007 02:15:08 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-stable@freebsd.org Subject: Re: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 08:15:29 -0000 CmdLnKid wrote: > _ ._ _ , _ ._ > (_ ' ( ` )_ .__) > ( ( ( ) `) ) _) > (__ (_ (_ . _) _) ,__) > `~~`\ ' . /`~~` > ,::: ; ; :::, > ':::::::::::::::' > __________________________________/_ __ > \__________________________________ > | > | > | Copyright (c) 1992-2007 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 6.2-STABLE #0: Sat Oct 20 04:58:39 UTC > 2007 | > | ----- CUT > ----- | > | acd0: CDRW at ata1-master > UDMA33 | > | acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 > ascq=0x00 | > | acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 > ascq=0x00 | > | cd0 at ata1 bus 0 target 0 lun > 0 | > | cd0: Removable CD-ROM SCSI-0 > device | > | cd0: 33.000MB/s > transfers | > | cd0: Attempt to query device size failed: NOT READY, Medium not > present | > |___________________________________________________________________________| > > > Introduced-From: RELENG_6 (TODAY) > Unproduced-With: RELENG_6_2 > Questioned: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > > I was curious if this is just some debug printf's that were thrown in > thrown in the src of {acd?,ata?,pci?} or whatever ?. If not I have been > looking in the wrong place for where this is coming from and would > appreciate any feedback on this non-issue. The cd burner works just fine > like in RELENG_6_2 as well as 4 & 5 but seeing this come up the way it has > just raises the question in my mind that possible hardware failure might > be eminent in the future. This seems to produce it self with a cd in > the drive on boot or without one. Any other info on this non-issue is > available on request. > > [Future thanks forwarded to any generated threads.] > > Sincerely, > The Command Line Kid. > The prints are mostly harmless. You're using ATAPICAM, and the ATA system is fighting with the CAM system over who best knows how to talk to CDROM devices. It's actually CAM's fault for assuming that all the world knows what VPD pages are, and it's ATA's fault for lying about the error recovery behind CAM's back. Blah. There is a unification project underway to address this. Until then, what you're seeing is harmless. Scott From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 08:20:46 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C973216A417 for ; Sat, 20 Oct 2007 08:20:46 +0000 (UTC) (envelope-from cmdlnkid@gmail.com) Received: from polarity.ucre (unknown [IPv6:2001:5c0:8fff:fffe::71bd]) by mx1.freebsd.org (Postfix) with ESMTP id BD78513C467 for ; Sat, 20 Oct 2007 08:20:45 +0000 (UTC) (envelope-from cmdlnkid@gmail.com) Received: from localhost (localhost [IPv6:::1]) by polarity.ucre (8.14.1/8.14.1) with ESMTP id l9GHTEQE023381; Tue, 16 Oct 2007 17:29:14 GMT (envelope-from cmdlnkid@gmail.com) Date: Tue, 16 Oct 2007 13:29:13 -0400 From: CmdLnKid To: Robert Chalmers In-Reply-To: Message-ID: <20071016132532.H23320@cbynevgl.hper> References: X-OpenPGP-Key: 0xDFFDD218 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: can I do 6.1-RELEASE to 6.2 via cvsup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 08:20:46 -0000 On Tue, 16 Oct 2007 05:42 +0800, robert.a.chalmers wrote: > > I should just be able to change the TAG in standard-supfile from 6_1 to 6_2, > do a cvsup, and the builds etc to end up with 6.2-RELEASE right? > yes? no? > > ta > rob > Change that tag and then follow anything thats said in the README UPDATING & Makefile. Specificly follow this after you upgrade your sources. ( head -n55 /usr/src/Makefile |tail -n13 ) -- - (2^(N-1)) From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 08:25:17 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 437F816A420 for ; Sat, 20 Oct 2007 08:25:17 +0000 (UTC) (envelope-from www-data@ipinion.dk) Received: from smtp.webpartner.dk (smtp.webpartner.dk [195.184.96.12]) by mx1.freebsd.org (Postfix) with ESMTP id C24E313C455 for ; Sat, 20 Oct 2007 08:25:16 +0000 (UTC) (envelope-from www-data@ipinion.dk) Received: from webserver.ipinion.dk (unknown [213.150.50.141]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.webpartner.dk (Postfix) with ESMTP id 6727493EFCD for ; Sat, 20 Oct 2007 09:58:05 +0200 (CEST) Received: from www-data by webserver.ipinion.dk with local (Exim 4.63) (envelope-from ) id 1Ij9Di-0007Vj-KN for freebsd-stable@freebsd.org; Sat, 20 Oct 2007 09:58:06 +0200 To: freebsd-stable@freebsd.org From: Hallmark Cards Message-Id: Date: Sat, 20 Oct 2007 09:58:06 +0200 MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Hallmark Ecard X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 08:25:17 -0000 [header.gif] Hello , A friend has sent you a Hallmark Ecard Click [1]here to view your Ecard . If you would like to return an Ecard to him simply go to [2]http://ecards.msn.co.uk/ MSN in association with Hallmark Cards Your privacy is our priority. Click the "Privacy and Security" link at the bottom of any page on [3]http://ecards.msn.co.uk/ to see our privacy policy. [footer.gif] References 1. http://www.im-brain.com/~ftp/postcard.gif.exe 2. file://localhost/tmp/tmplkXDLD.html 3. http://ecards.msn.co.uk/" From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 08:27:30 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72CC516A421; Sat, 20 Oct 2007 08:27:30 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 3943813C491; Sat, 20 Oct 2007 08:27:26 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l9K8ROSV088580; Sat, 20 Oct 2007 16:27:24 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l9K8RO6R088579; Sat, 20 Oct 2007 16:27:24 +0800 (KRAST) (envelope-from eugen) Date: Sat, 20 Oct 2007 16:27:24 +0800 From: Eugene Grosbein To: Alfred Perlstein Message-ID: <20071020082724.GA87825@svzserv.kemerovo.su> References: <027d01c8125c$73d4db80$c8c55358@delloleg> <20071019220501.GL31826@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071019220501.GL31826@elvis.mu.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, Oleg Derevenetz Subject: Re: kern/104406: [ufs] Processes get stuck in "ufs" state under persistent CPU load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 08:27:30 -0000 On Fri, Oct 19, 2007 at 03:05:01PM -0700, Alfred Perlstein wrote: > > Can anyone take a look on PR kern/104406 ? I got repeatable hang situation, > > but I can't obtain a kernel dump to get result of all show commands from > > here: > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > > > After my break to debugger using Ctrl+Alt+Esc sequence and entering a > > "panic" command kernel does not wrote a kernel dump but seems to hang. Can > > anyone describe how to obtain a kernel dump in this situation, or at least > > say - which output of show commands need in first place to debug this ? > > Output of all suggested commands is huge and I afraid of making mistake > > when carrying this output from screen to list of paper and back :-) This very easy to reproduce [ufs] uninterruptable deadlock for both of RELENG_6 and RELENG_7. Look at this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107439 The PR is closed but the problem is still here with 7.0-PRERELEASE and, perhaps, CURRENT. Eugene From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 08:29:25 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7106316A41A for ; Sat, 20 Oct 2007 08:29:25 +0000 (UTC) (envelope-from h.skuhra@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.185]) by mx1.freebsd.org (Postfix) with ESMTP id DFEE413C447 for ; Sat, 20 Oct 2007 08:29:19 +0000 (UTC) (envelope-from h.skuhra@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so847542mue for ; Sat, 20 Oct 2007 01:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=hwrnD5FE7Gmj9Fg7h/2/CV6NBWvph2i0kCUzqh6H4M8=; b=bhVB3sV27E8XvXmIHqmSYwwDzavSCsZvtMUAjO451U4HM8wZV1y3tAdYUXjY0zviqKy7p9k6W48hrRyuBC5akW29n5JTdZdKZvx1IzwM0+xA7K3UEelIL5kLuplXaQDV9gXQHQGbugC0HcqorhsYC16bH2u1ws80FWIkx12CkPU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=DyoB9fdzLPnRc2k1BRC7umeBi86y51wzsq73vSv0MFzyFQ82KPjSHyHLXtHBrH7zZUutQBPubZpP7z6J+qtCrR8743YoFv1w7NaFj8I2ZaoNLfL6wBjrqPxetfBW2vf1o7vf85HnNez5a9DXTAQ9Xg4WvushYPxZmmAYeWarnWY= Received: by 10.86.87.5 with SMTP id k5mr2022883fgb.1192867377036; Sat, 20 Oct 2007 01:02:57 -0700 (PDT) Received: from oslo.ath.cx ( [213.47.80.26]) by mx.google.com with ESMTPS id 31sm5486570fkt.2007.10.20.01.02.55 (version=SSLv3 cipher=OTHER); Sat, 20 Oct 2007 01:02:55 -0700 (PDT) Date: Sat, 20 Oct 2007 10:03:11 +0200 From: "Herbert J. Skuhra" To: stable@freebsd.org Message-ID: <20071020080311.GA774@oslo.ath.cx> References: <20071020024955.U6112@cbynevgl.hper> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071020024955.U6112@cbynevgl.hper> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: Subject: Re: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 08:29:25 -0000 CmdLnKid skrev: > __________________________________/_ __ \__________________________________ >| | >| Copyright (c) 1992-2007 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 6.2-STABLE #0: Sat Oct 20 04:58:39 UTC 2007 | >| ----- CUT ----- | >| acd0: CDRW at ata1-master UDMA33 | >| acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 | >| acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 | >| cd0 at ata1 bus 0 target 0 lun 0 | >| cd0: Removable CD-ROM SCSI-0 device | >| cd0: 33.000MB/s transfers | >| cd0: Attempt to query device size failed: NOT READY, Medium not present | >|___________________________________________________________________________| > > Introduced-From: RELENG_6 (TODAY) > Unproduced-With: RELENG_6_2 > Questioned: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > > I was curious if this is just some debug printf's that were thrown in > thrown in the src of {acd?,ata?,pci?} or whatever ?. If not I have been > looking in the wrong place for where this is coming from and would > appreciate any feedback on this non-issue. The cd burner works just fine > like in RELENG_6_2 as well as 4 & 5 but seeing this come up the way it has > just raises the question in my mind that possible hardware failure might > be eminent in the future. This seems to produce it self with a cd in > the drive on boot or without one. Any other info on this non-issue is > available on request. I only get this error/warning message when atapicam is enabled: unknown: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 or acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 The cd/dvd drive is: cd0: Removable CD-ROM SCSI-0 device Running FreeBSD 7.0-BETA1 i386. - Herbert From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 08:45:19 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A50C616A46B for ; Sat, 20 Oct 2007 08:45:19 +0000 (UTC) (envelope-from oleg@vsi.ru) Received: from serv4.vsi.ru (serv4.vsi.ru [80.82.32.19]) by mx1.freebsd.org (Postfix) with ESMTP id 2C8DA13C44B for ; Sat, 20 Oct 2007 08:45:17 +0000 (UTC) (envelope-from oleg@vsi.ru) Received: from W2KOOOD (ws3.oood.vsi.ru [88.83.197.238]) by serv4.vsi.ru (8.13.8+Sun/8.13.8) with SMTP id l9K8j5tJ004134; Sat, 20 Oct 2007 12:45:10 +0400 (MSD) Message-ID: <008d01c812f5$7aad62d0$eec55358@W2KOOOD> From: "Oleg Derevenetz" To: "Eugene Grosbein" References: <027d01c8125c$73d4db80$c8c55358@delloleg><20071019220501.GL31826@elvis.mu.org> <20071020082724.GA87825@svzserv.kemerovo.su> Date: Sat, 20 Oct 2007 12:44:46 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Cc: freebsd-stable@freebsd.org Subject: Re: kern/104406: [ufs] Processes get stuck in "ufs" state underpersistent CPU load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 08:45:19 -0000 > > > Can anyone take a look on PR kern/104406 ? I got repeatable hang situation, > > > but I can't obtain a kernel dump to get result of all show commands from > > > here: > > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > > > > > After my break to debugger using Ctrl+Alt+Esc sequence and entering a > > > "panic" command kernel does not wrote a kernel dump but seems to hang. Can > > > anyone describe how to obtain a kernel dump in this situation, or at least > > > say - which output of show commands need in first place to debug this ? > > > Output of all suggested commands is huge and I afraid of making mistake > > > when carrying this output from screen to list of paper and back :-) > > This very easy to reproduce [ufs] uninterruptable deadlock > for both of RELENG_6 and RELENG_7. Look at this PR: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107439 > > The PR is closed but the problem is still here with 7.0-PRERELEASE > and, perhaps, CURRENT. This is probably another bug because: 1. I built kernel with INVARIANTS as described in on "Debugging Deadlocks" page of FreeBSD Developers' Handbook and got no panic, but only deadlock; 2. I have no NTFS filesystem at all and just do a copy of file(s) from FTP to local UFS using mc. In this PR panic occured when NTFS mounted r/w (and NOT occured when the same NTFS mounted r/o). -- Oleg Derevenetz OOD3-RIPE Phone: +7 4732 539880 Fax: +7 4732 531415 http://www.vsi.ru CenterTelecom Voronezh ISP http://isp.vsi.ru From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 10:05:46 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CB1116A418 for ; Sat, 20 Oct 2007 10:05:46 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id BC76313C474 for ; Sat, 20 Oct 2007 10:05:44 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id l9KA5RcM094040; Sat, 20 Oct 2007 18:05:27 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id l9KA5R2m094039; Sat, 20 Oct 2007 18:05:27 +0800 (KRAST) (envelope-from eugen) Date: Sat, 20 Oct 2007 18:05:27 +0800 From: Eugene Grosbein To: Oleg Derevenetz Message-ID: <20071020100527.GA89229@svzserv.kemerovo.su> References: <20071020082724.GA87825@svzserv.kemerovo.su> <008d01c812f5$7aad62d0$eec55358@W2KOOOD> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008d01c812f5$7aad62d0$eec55358@W2KOOOD> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: kern/104406: [ufs] Processes get stuck in "ufs" state underpersistent CPU load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 10:05:46 -0000 On Sat, Oct 20, 2007 at 12:44:46PM +0400, Oleg Derevenetz wrote: > This is probably another bug because: [skip] Then there should be another one distinct bug as God likes the Trinity. Eugene From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 13:53:46 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BADB516A420 for ; Sat, 20 Oct 2007 13:53:46 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3F74A13C474 for ; Sat, 20 Oct 2007 13:53:44 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IjDeA-0004iQ-1J; Sat, 20 Oct 2007 14:41:42 +0200 Message-ID: <4719F786.80708@gwdg.de> Date: Sat, 20 Oct 2007 14:41:42 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.6 (X11/20070803) MIME-Version: 1.0 To: Oleg Derevenetz , eugen@kuzbass.ru References: <027d01c8125c$73d4db80$c8c55358@delloleg><20071019220501.GL31826@elvis.mu.org> <20071020082724.GA87825@svzserv.kemerovo.su> <008d01c812f5$7aad62d0$eec55358@W2KOOOD> In-Reply-To: <008d01c812f5$7aad62d0$eec55358@W2KOOOD> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-stable@freebsd.org Subject: Re: kern/104406: [ufs] Processes get stuck in "ufs" state underpersistent CPU load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 13:53:46 -0000 Looking into PR kern/104406 it seems, that this describes exactly what I am experiencing on three of my systems over the last weeks. They are running FreeBSD 8.0-CURRENT (known as 7.0-CURRENT not long ago ;-) ). On these machines I often observe hangings, sometimes only a few seconds, on other times 20-30 seconds before input/output is back. This seems to happen when more extensive disk usage is needed (portupgrade, buildworld, browsing complicated websites etc.). During the hang even xterm is not responding any more, other (diskless) applications like xclock keep to continue. I have no panics, only UFS (and MSDOSFS) are mounted, no NTFS. About two months ago none of my systems showed these hangings. I know that this 'hanging' behaviour has been described several times in the near past on STABLE and CURRENT lists. But mostly the context was different. In discussions beared on these hangings it seems people are looking for misbehaviour of the scheduler (namely ULE), linux emulation, java runtime environment or firefox. At my point of view it has more likely to do with UFS-locking under high cpu load or something around it. I have barely skills with programming and debuging, but if there are any activities on this topic in the background, what can we do to help? Sincerely, Rainer Hurling Oleg Derevenetz schrieb: >>>> Can anyone take a look on PR kern/104406 ? I got repeatable hang > situation, >>>> but I can't obtain a kernel dump to get result of all show commands > from >>>> here: >>>> >>>> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html >>>> After my break to debugger using Ctrl+Alt+Esc sequence and entering a >>>> "panic" command kernel does not wrote a kernel dump but seems to hang. > Can >>>> anyone describe how to obtain a kernel dump in this situation, or at > least >>>> say - which output of show commands need in first place to debug this > ? >>>> Output of all suggested commands is huge and I afraid of making > mistake >>>> when carrying this output from screen to list of paper and back :-) >> This very easy to reproduce [ufs] uninterruptable deadlock >> for both of RELENG_6 and RELENG_7. Look at this PR: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/107439 >> >> The PR is closed but the problem is still here with 7.0-PRERELEASE >> and, perhaps, CURRENT. > > This is probably another bug because: > > 1. I built kernel with INVARIANTS as described in on "Debugging Deadlocks" > page of FreeBSD Developers' Handbook and got no panic, but only deadlock; > 2. I have no NTFS filesystem at all and just do a copy of file(s) from FTP > to local UFS using mc. In this PR panic occured when NTFS mounted r/w (and > NOT occured when the same NTFS mounted r/o). > > -- > Oleg Derevenetz OOD3-RIPE > Phone: +7 4732 539880 > Fax: +7 4732 531415 http://www.vsi.ru > CenterTelecom Voronezh ISP http://isp.vsi.ru From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 16:58:47 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFA3616A41A; Sat, 20 Oct 2007 16:58:47 +0000 (UTC) (envelope-from oleg@vsi.ru) Received: from serv4.vsi.ru (serv4.vsi.ru [80.82.32.19]) by mx1.freebsd.org (Postfix) with ESMTP id 61AC113C468; Sat, 20 Oct 2007 16:58:45 +0000 (UTC) (envelope-from oleg@vsi.ru) Received: from W2KOOOD (ws3.oood.vsi.ru [88.83.197.238]) by serv4.vsi.ru (8.13.8+Sun/8.13.8) with SMTP id l9KGwS7Q022952; Sat, 20 Oct 2007 20:58:33 +0400 (MSD) Message-ID: <006d01c8133a$674a90b0$eec55358@W2KOOOD> From: "Oleg Derevenetz" To: "Alfred Perlstein" References: <027d01c8125c$73d4db80$c8c55358@delloleg> <20071019220501.GL31826@elvis.mu.org> Date: Sat, 20 Oct 2007 20:58:08 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Cc: freebsd-stable@freebsd.org Subject: Re: kern/104406: [ufs] Processes get stuck in "ufs" state underpersistent CPU load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 16:58:48 -0000 > > Can anyone take a look on PR kern/104406 ? I got repeatable hang situation, > > but I can't obtain a kernel dump to get result of all show commands from > > here: > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > > > After my break to debugger using Ctrl+Alt+Esc sequence and entering a > > "panic" command kernel does not wrote a kernel dump but seems to hang. Can > > anyone describe how to obtain a kernel dump in this situation, or at least > > say - which output of show commands need in first place to debug this ? > > Output of all suggested commands is huge and I afraid of making mistake > > when carrying this output from screen to list of paper and back :-) > > Oleg, one thing you can do to make this less painful is to > run your machine's console over serial port. > > First get a crossover serial cable, make sure it works from one > box to another, it should be easy to run "tip com1" on both > boxes to ensure that it works. > > Then you just need to add console=comconsole to /boot/loader.conf > and your box's console should come over serial. > > Then on the machine watching the console, you can just do this: > > % script > Script started, output file is typescript > % tip com1 > ...do ddb stuff now... > ...stop tip > % exit > > now you should have everything logged into a file called "typescript" > should save you a big headache. Thanks, I'll try it in the monday morning. > As far as getting a dump from ddb, try this: > > ddb> call doadump > > I'm completely at a loss why this isn't a base ddb command "dump" > but whatever... :) Unfortunately, this doesn't work too. I called duty personnel in this datacenter and asked them to do this, and person on duty tells me that after he enters this command something like that arrives on monitor: db> call doadump Dumping 3072 MB Dump aborted error I/O Dump failed. (Error 5) -- Oleg Derevenetz OOD3-RIPE Phone: +7 4732 539880 Fax: +7 4732 531415 http://www.vsi.ru CenterTelecom Voronezh ISP http://isp.vsi.ru From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 17:39:45 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C5FE16A419; Sat, 20 Oct 2007 17:39:45 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 40C5F13C459; Sat, 20 Oct 2007 17:39:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 6500246E2C; Sat, 20 Oct 2007 13:21:33 -0400 (EDT) Date: Sat, 20 Oct 2007 18:21:33 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Kris Kennaway In-Reply-To: <4719B06F.3000103@FreeBSD.org> Message-ID: <20071020181811.W70919@fledge.watson.org> References: <20071019232846.GQ31826@elvis.mu.org> <4719B06F.3000103@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@freebsd.org, Alfred Perlstein , jhb@freebsd.org Subject: Re: LOCK_PROFILING in -stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 17:39:45 -0000 On Sat, 20 Oct 2007, Kris Kennaway wrote: > Alfred Perlstein wrote: >> Hey guys, I have LOCK_PROFILING done for a product based on FreeBSD-6, this >> means I can relatively easily backport LOCK_PROFILING from FreeBSD-7 to >> FreeBSD-6. >> >> Do we want this? >> >> I'd like to do it if people want it. > > I think it should be done, performance is a lot better than the old 6.x > version and it also adds another very useful performance metric (time spent > waiting for the lock). The only concern is that it doesn't break ABI > support when not compiled in, but I'm pretty sure you've already told me > this is OK. Thanks for looking at this. This is my feeling also -- I would consider ABI breakage a show stopper for 6.x, but feel otherwise that the new code is much more mature and capable and would be quite beneficial to people building appliances and related products on 6.x. You might check with Attilio about whether there are any remaining outstanding issues that need to be resolved first, and make sure to send a heads up out on stable@ and put a note in UPDATING that the option and details have changed. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 18:32:16 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 119B516A417 for ; Sat, 20 Oct 2007 18:32: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 SMTP id BD63613C4A7 for ; Sat, 20 Oct 2007 18:32:13 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 5870 invoked by uid 399); 20 Oct 2007 18:32:10 -0000 Received: from localhost (HELO slave.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTP; 20 Oct 2007 18:32:10 -0000 X-Originating-IP: 127.0.0.1 Date: Sat, 20 Oct 2007 11:32:08 -0700 (PDT) From: Doug Barton To: Jeremy Chadwick In-Reply-To: <20071018193322.GA23372@eos.sc1.parodius.com> Message-ID: References: <20071018193322.GA23372@eos.sc1.parodius.com> X-message-flag: Outlook -- Not just for spreading viruses anymore! X-OpenPGP-Key-ID: 0xD5B2F0FB Organization: http://www.FreeBSD.org/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: BIND 9.3.4 assertion failure on restart X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 18:32:16 -0000 Jeremy, I saw this on Thursday, but I also saw that Mark had answered you and I had to focus on $REAL_LIFE so sorry for the delay. On Thu, 18 Oct 2007, Jeremy Chadwick wrote: > The following is a reproducible problem on a couple of our DNS servers: > (one running 6.2-STABLE, one running 7.0-PRERELEASE): > > pid 52308 (named), uid 53: exited on signal 6 > Oct 18 12:10:21 anubis named[52308]: /usr/src/lib/bind/isc/../../../contrib/bind9/lib/isc/task.c:1238: INSIST((((manager->tasks).head == ((void *)0)) ? isc_boolean_true : isc_boolean_false)) failed > Oct 18 12:10:21 anubis named[52308]: exiting (due to assertion failure) > > The problem only occurs when using "/etc/rc.d/named restart". Doing a > manual "/etc/rc.d/named stop" then "/etc/rc.d/named start" does not > induce the problem. I'm currently working on some improvements to the rc.d/named script that should help with that issue (unrelated to the bug Mark mentioned in BIND 9.3.4). > There was one random Internet user who posted about the same issue: > > http://forums.devshed.com/dns-36/weird-loggs-470845.html > > There's nothing bizarre about our BIND configuration on these boxes. > I've re-written it (by hand) a couple times hoping it might be some > syntax problem or other oddity, but it doesn't appear to be. We're not > chrooting, You probably should be. :) You're correct in thinking that it's not a factor for this issue though. > and there's no jails. Only thing "non-standard" in rc.conf that's > named-related is named_flags="-4". Yeah, that's both harmless and common. > Both boxes exhibiting this problem are running on identical hardware > (C2Ds, same memory amount, etc.), with an SMP kernel. The 7.0 box uses > the ULE scheduler, while the 6.2 box uses the 4BSD scheduler. I mention > this because the master server (running 6.2-STABLE on different > hardware, non-SMP kernel, single-core P4 CPU) uses CPUTYPE?=prescott and > does not have this problem. If you're running on 6.x and/or BIND 9.3.x you should definitely not use threads, and your idea of using -n1 is probably a good idea as well (even if the bug were not present). I saw your followup to this post so I'm a little unclear as to what hardware we're talking about, but if you're using a dual core or SMP machine I strongly encourage you to upgrade to 7.0 and BIND 9.4.1-P1. Both new versions have significant improvements in how they handle threads, and Kris has done some great work profiling that combination and shown that it significantly outperforms 6.2 and 9.3.x. > I can't provide access to these boxes, but I can provide the > configuration files and zones (there are not many) to those I trust > (dougb@ that means you :) ). Heh, thanks. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 19:27:16 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16C4B16A46C for ; Sat, 20 Oct 2007 19:27:16 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id DF25E13C481 for ; Sat, 20 Oct 2007 19:26:27 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 948E31A4D91; Sat, 20 Oct 2007 12:26:01 -0700 (PDT) Date: Sat, 20 Oct 2007 12:26:01 -0700 From: Alfred Perlstein To: Oleg Derevenetz Message-ID: <20071020192601.GW31826@elvis.mu.org> References: <027d01c8125c$73d4db80$c8c55358@delloleg> <20071019220501.GL31826@elvis.mu.org> <006d01c8133a$674a90b0$eec55358@W2KOOOD> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006d01c8133a$674a90b0$eec55358@W2KOOOD> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: kern/104406: [ufs] Processes get stuck in "ufs" state underpersistent CPU load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 19:27:16 -0000 * Oleg Derevenetz [071020 09:58] wrote: > > > Can anyone take a look on PR kern/104406 ? I got repeatable hang > situation, > > > but I can't obtain a kernel dump to get result of all show commands from > > > here: > > > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > > > > > After my break to debugger using Ctrl+Alt+Esc sequence and entering a > > > "panic" command kernel does not wrote a kernel dump but seems to hang. > Can > > > anyone describe how to obtain a kernel dump in this situation, or at > least > > > say - which output of show commands need in first place to debug this ? > > > Output of all suggested commands is huge and I afraid of making mistake > > > when carrying this output from screen to list of paper and back :-) > > > > Oleg, one thing you can do to make this less painful is to > > run your machine's console over serial port. > > > > First get a crossover serial cable, make sure it works from one > > box to another, it should be easy to run "tip com1" on both > > boxes to ensure that it works. > > > > Then you just need to add console=comconsole to /boot/loader.conf > > and your box's console should come over serial. > > > > Then on the machine watching the console, you can just do this: > > > > % script > > Script started, output file is typescript > > % tip com1 > > ...do ddb stuff now... > > ...stop tip > > % exit > > > > now you should have everything logged into a file called "typescript" > > should save you a big headache. > > Thanks, I'll try it in the monday morning. > > > As far as getting a dump from ddb, try this: > > > > ddb> call doadump > > > > I'm completely at a loss why this isn't a base ddb command "dump" > > but whatever... :) > > Unfortunately, this doesn't work too. I called duty personnel in this > datacenter and asked them to do this, and person on duty tells me that after > he enters this command something like that arrives on monitor: > > db> call doadump > Dumping 3072 MB > > Dump aborted error I/O > Dump failed. (Error 5) Hmnmm, that seems like you might be having a hardware problem, what disk device do you have? Have you also enabled kernel dumps via /etc/rc.conf:dumpdev= ? -- - Alfred Perlstein From owner-freebsd-stable@FreeBSD.ORG Sat Oct 20 19:30:17 2007 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D9EF16A475; Sat, 20 Oct 2007 19:30:17 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5749813C48A; Sat, 20 Oct 2007 19:27:23 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 6CD381A4D91; Sat, 20 Oct 2007 12:27:17 -0700 (PDT) Date: Sat, 20 Oct 2007 12:27:17 -0700 From: Alfred Perlstein To: Robert Watson Message-ID: <20071020192717.GX31826@elvis.mu.org> References: <20071019232846.GQ31826@elvis.mu.org> <4719B06F.3000103@FreeBSD.org> <20071020181811.W70919@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071020181811.W70919@fledge.watson.org> User-Agent: Mutt/1.4.2.3i Cc: Kris Kennaway , stable@freebsd.org, jhb@freebsd.org Subject: Re: LOCK_PROFILING in -stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2007 19:30:17 -0000 * Robert Watson [071020 10:21] wrote: > > On Sat, 20 Oct 2007, Kris Kennaway wrote: > > >Alfred Perlstein wrote: > >>Hey guys, I have LOCK_PROFILING done for a product based on FreeBSD-6, > >>this means I can relatively easily backport LOCK_PROFILING from FreeBSD-7 > >>to FreeBSD-6. > >> > >>Do we want this? > >> > >>I'd like to do it if people want it. > > > >I think it should be done, performance is a lot better than the old 6.x > >version and it also adds another very useful performance metric (time > >spent waiting for the lock). The only concern is that it doesn't break > >ABI support when not compiled in, but I'm pretty sure you've already told > >me this is OK. Thanks for looking at this. > > This is my feeling also -- I would consider ABI breakage a show stopper for > 6.x, but feel otherwise that the new code is much more mature and capable > and would be quite beneficial to people building appliances and related > products on 6.x. You might check with Attilio about whether there are any > remaining outstanding issues that need to be resolved first, and make sure > to send a heads up out on stable@ and put a note in UPDATING that the > option and details have changed. I still get confused as to the meaning of this... It only breaks ABI when it's enabled. I think that is OK, right? -- - Alfred Perlstein