From owner-freebsd-stable@FreeBSD.ORG Sun Jul 4 05:55:29 2010 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 4E8D1106564A for ; Sun, 4 Jul 2010 05:55:29 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 023ED8FC14 for ; Sun, 4 Jul 2010 05:55:28 +0000 (UTC) Received: by gxk24 with SMTP id 24so9948gxk.13 for ; Sat, 03 Jul 2010 22:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=xbBwuLpEpS0O84wuZf2OcYuCHziitmGV2rdjlWCbP40=; b=WlWsPyQiBSM+Ki/IbjrcYkRfBVXBRmm8CIe0c18ulyAsutsy6v73I78wQiQwjUVH/r YfIREKxNL9yCNBQfmJu4VzYlEKPCRgqGqN4SxjYzjHI+Xpo9oIwtuWPKVvxGQSy1uiJV nTKB2j1eg7D5iXhGhiPsZzLKwqKdPOjk1Wze4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=FsJMWACUjWkuiEfVl0skdp5v+ZShNSleM/jSgSMnAFFV9CxTkm4Zid8ICOJwdamEuu SXvBh+KxXUn0cEvh5Aty1+JqBt1FbFuKu8TO43Z6G4NDNtiCgOmM3SDnIm2wYz9J15EH bvZk5fWO5cPpJrEyuVOgrluYKX7ygzf5Lwbcc= Received: by 10.100.119.14 with SMTP id r14mr1379811anc.18.1278222921857; Sat, 03 Jul 2010 22:55:21 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-128-180.dsl.klmzmi.sbcglobal.net [99.181.128.180]) by mx.google.com with ESMTPS id r7sm23937393anb.15.2010.07.03.22.55.20 (version=SSLv3 cipher=RC4-MD5); Sat, 03 Jul 2010 22:55:21 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C302248.1020509@dataix.net> Date: Sun, 04 Jul 2010 01:55:20 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100626 Thunderbird MIME-Version: 1.0 To: Kevin Oberman References: <20100703205111.97CF51CC0D@ptavv.es.net> In-Reply-To: <20100703205111.97CF51CC0D@ptavv.es.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Odd behavior of labels on different filesystem types 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, 04 Jul 2010 05:55:29 -0000 On 07/03/2010 16:51, Kevin Oberman wrote: > I have run into an odd behavior in 8-stable that I can't see a reason > for. > > If I have a FAT32 formatted removable drive, I get /dev entries for it > as both /dev/msdosfs/LABEL and /dev/ufsid/ID. When I mount the > filesystem, the /dev/ufsid label is removed, but the other two remain. > > If I have a UFS filesystem on the disk, I have similar devices except > that the LABEL is /dev/ufs/LABEL. But, when the UFS device is mounted, > the /dev/ufsid/ID AND the /dev/ufs/LABEL devs are both deleted. > > I'm not sure which is "right", but I can't see the reason for the > different behavior and it has caused a fair bit of trouble when working > with gnome-mount as I can't unmount a ufs device. When the > /dev/ufs/LABEL device is created again on the umount, gnome-mount sees a > new device and immediately re-mounts it. > > Can this inconsistency be corrected? Can you try to zero out that disk first i.e. dd if=/dev/zero of=/dev/DISK bs=4m Then format your msdos fat part and relabel it. You should not see a dev/ufsid/ label for this anymore. I believe that for some reason the ufsid metadata or whatever you want to call it some how has been left behind and is still being read for whatever reason and can be confirmed by this. As for /dev/ufs/LABEL /dev/ufsid/ID /dev/device when you mount one the others should disapear so this is correct behavior. -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ From owner-freebsd-stable@FreeBSD.ORG Sun Jul 4 11:20:47 2010 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 D04C61065673; Sun, 4 Jul 2010 11:20:47 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (unknown [IPv6:2001:380:e06:127::53]) by mx1.freebsd.org (Postfix) with ESMTP id 8A40C8FC16; Sun, 4 Jul 2010 11:20:47 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id C696A78C4B; Sun, 4 Jul 2010 20:20:43 +0900 (JST) Received: from artemis (unknown [192.168.2.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTP id A73EE78C34; Sun, 4 Jul 2010 20:20:43 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: References: <1931AE1113EC4A8983B8A52A2A1966C2@ad.peach.ne.jp><6BC2B2FBAFFA4C26A46977F121B707E1@ad.peach.ne.jp> In-Reply-To: Date: Sun, 4 Jul 2010 20:01:37 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [Need Help]isboot (iSCSI boot driver) version 0.2.1 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, 04 Jul 2010 11:20:47 -0000 Updated to 0.2.2 I noticed a bug after writing previous mail. sosend was called from XPT_SCSI_IO with locked mutex. It caused "sleeping thread owns a non-sleepable lock". What's new?: add auto sense. add maxio=1m. modify max tags by iSCSI command window. fix locked sleep problem. Download links: http://www.peach.ne.jp/archives/isboot/isboot-0.2.2.tar.gz Download links(for testing purpose only): http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-7.3-RELEASE-amd64-isboot-0.2.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-7.3-RELEASE-i386-isboot-0.2.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-8.1-RC2-amd64-isboot-0.2.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-8.1-RC2-i386-isboot-0.2.2.iso http://www.peach.ne.jp/archives/isboot/demo/unionfs-mkisboot.sh -- Daisuke Aoyama From owner-freebsd-stable@FreeBSD.ORG Sun Jul 4 12:25:09 2010 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 2D791106566C for ; Sun, 4 Jul 2010 12:25:09 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (unknown [IPv6:2001:44b8:7c07:5581:36b8:7bff:fee0:1a08]) by mx1.freebsd.org (Postfix) with ESMTP id 7B9218FC1D for ; Sun, 4 Jul 2010 12:25:08 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-156-127.lns6.adl6.internode.on.net [121.45.156.127]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o64COrOE046102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 4 Jul 2010 21:54:59 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Jul 2010 21:54:52 +0930 To: FreeBSD Stable Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Subject: GEOM/bsdlabel regression in 8.x? 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, 04 Jul 2010 12:25:09 -0000 I was helping a friend as he wanted to add a partition to a new install, = ie he did (effectively) this.. truncate -s 10m /tmp/test mdconfig -a -t vnode -f /tmp/test fdisk -BI /dev/md0 bsdlabel -w /dev/md0s1 bsdlabel -e /dev/md0s1 a: 2048 16 4.2BSD 0 0 0=20 newfs /dev/md0s1a mkdir /mnt/test mount /dev/md0s1a /mnt/test bsdlabel -e /dev/md0s1 Then you get.. "bsdlabel: Class not found" Note that just touching the file bsdlabel is using is enough to cause it = to generate that error. I tried the same steps on a 7.x system and it worked fine. ktrace shows ... 90200 bsdlabel CALL ioctl(0x4,DIOCGMEDIASIZE,0x7fffffffe430) 90200 bsdlabel RET ioctl 0 90200 bsdlabel CALL ioctl(0x4,DIOCGSECTORSIZE,0x7fffffffe434) 90200 bsdlabel RET ioctl 0 90200 bsdlabel CALL ioctl(0x4,DIOCGFWSECTORS,0x7fffffffe454) 90200 bsdlabel RET ioctl 0 90200 bsdlabel CALL ioctl(0x4,DIOCGFWHEADS,0x7fffffffe454) 90200 bsdlabel RET ioctl 0 90200 bsdlabel CALL close(0x4) 90200 = bsdlabel RET close 0 90200 bsdlabel CALL close(0x3) 90200 bsdlabel RET close 0 90200 bsdlabel CALL open(0x800c04040,O_RDWR,0x26ec) 90200 bsdlabel NAMI "/dev/md0s1" 90200 bsdlabel RET open -1 errno 1 Operation not permitted 90200 bsdlabel CALL open(0x800651b5f,O_RDONLY,0) 90200 bsdlabel NAMI "/dev/geom.ctl" 90200 bsdlabel RET open 3 90200 bsdlabel CALL ioctl(0x3,GEOM_CTL,0x800c06040) 90200 bsdlabel RET = ioctl 0 90200 bsdlabel CALL close(0x3) Note that my friend tried it on real hardware and said that after he = rebooted it appeared(!) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Sun Jul 4 13:57:44 2010 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 6F7F21065D8E for ; Sun, 4 Jul 2010 13:57:44 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3222A8FC15 for ; Sun, 4 Jul 2010 13:57:44 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:7153:b6b4:eb9a:638a] (unknown [IPv6:2001:7b8:3a7:0:7153:b6b4:eb9a:638a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3AD7D5C43; Sun, 4 Jul 2010 15:57:41 +0200 (CEST) Message-ID: <4C309359.8000502@andric.com> Date: Sun, 04 Jul 2010 15:57:45 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.8pre) Gecko/20100703 Lanikai/3.1.1pre MIME-Version: 1.0 To: Daniel O'Connor References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: GEOM/bsdlabel regression in 8.x? 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, 04 Jul 2010 13:57:44 -0000 On 2010-07-04 14:24, Daniel O'Connor wrote: ... > mkdir /mnt/test > mount /dev/md0s1a /mnt/test > bsdlabel -e /dev/md0s1 > > Then you get.. > "bsdlabel: Class not found" First unmount /dev/md0s1a, or the device /dev/md0s1 will be in use, and opening it for read/write (as bsdlabel probably does) will fail. Alternatively, you can turn on the "footshooting" debug flag in geom: Protection mechanisms in the geom(4) subsystem might prevent boot0cfg from being able to update the MBR on a mounted disk. Instructions for temporarily disabling these protection mechanisms can be found in the geom(4) manpage. Specifically, do a sysctl kern.geom.debugflags=0x10 to allow writing to the MBR, and restore it to 0 afterwards. and try again. This may not work as expected though. :) From owner-freebsd-stable@FreeBSD.ORG Sun Jul 4 14:27:03 2010 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 E762D106652B for ; Sun, 4 Jul 2010 14:27:03 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (unknown [IPv6:2001:44b8:7c07:5581:36b8:7bff:fee0:1a08]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2958FC0A for ; Sun, 4 Jul 2010 14:27:01 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-156-127.lns6.adl6.internode.on.net [121.45.156.127]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o64EQHTq049205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 4 Jul 2010 23:56:23 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <4C309359.8000502@andric.com> Date: Sun, 4 Jul 2010 23:56:17 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <791316F7-6E16-47D7-9B6C-2881FAAC78AA@gsoft.com.au> References: <4C309359.8000502@andric.com> To: Dimitry Andric X-Mailer: Apple Mail (2.1081) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: FreeBSD Stable Subject: Re: GEOM/bsdlabel regression in 8.x? 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, 04 Jul 2010 14:27:04 -0000 On 04/07/2010, at 23:27, Dimitry Andric wrote: >> Then you get.. >> "bsdlabel: Class not found" >=20 > First unmount /dev/md0s1a, or the device /dev/md0s1 will be in use, = and > opening it for read/write (as bsdlabel probably does) will fail. >=20 > Alternatively, you can turn on the "footshooting" debug flag in geom: >=20 > Protection mechanisms in the geom(4) subsystem might prevent = boot0cfg > from being able to update the MBR on a mounted disk. Instructions = for > temporarily disabling these protection mechanisms can be found in = the > geom(4) manpage. Specifically, do a >=20 > sysctl kern.geom.debugflags=3D0x10 >=20 > to allow writing to the MBR, and restore it to 0 afterwards. >=20 > and try again. This may not work as expected though. :) It doesn't make a difference if you set that flag or not. (The fact you need to set debugflags to modify the MBR is a separate bug = anyway IMO) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Sun Jul 4 15:22:10 2010 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 ADB57106564A for ; Sun, 4 Jul 2010 15:22:10 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id 6A60B8FC17 for ; Sun, 4 Jul 2010 15:22:10 +0000 (UTC) Received: from a91-153-117-195.elisa-laajakaista.fi (a91-153-117-195.elisa-laajakaista.fi [91.153.117.195]) by gw02.mail.saunalahti.fi (Postfix) with SMTP id 71E95139462; Sun, 4 Jul 2010 18:22:05 +0300 (EEST) Date: Sun, 4 Jul 2010 18:22:05 +0300 From: Jaakko Heinonen To: Daniel O'Connor Message-ID: <20100704152205.GA1734@a91-153-117-195.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Stable Subject: Re: GEOM/bsdlabel regression in 8.x? 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, 04 Jul 2010 15:22:10 -0000 On 2010-07-04, Daniel O'Connor wrote: > "bsdlabel: Class not found" This is because GEOM_BSD -> GEOM_PART_BSD change. bsdlabel(8) needs read-write access to the device. If it can't get that, it tries an alternative GEOM based method only supported by GEOM_BSD. The error message "Class not found" is printed because the "BSD" GEOM class doesn't exist. You might be able to do the changes with gpart(8). -- Jaakko From owner-freebsd-stable@FreeBSD.ORG Sun Jul 4 15:37:09 2010 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 CAA26106566B for ; Sun, 4 Jul 2010 15:37:09 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8B4058FC1F for ; Sun, 4 Jul 2010 15:37:09 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:7153:b6b4:eb9a:638a] (unknown [IPv6:2001:7b8:3a7:0:7153:b6b4:eb9a:638a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B742E5C43; Sun, 4 Jul 2010 17:37:08 +0200 (CEST) Message-ID: <4C30AAA8.7010206@andric.com> Date: Sun, 04 Jul 2010 17:37:12 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.8pre) Gecko/20100703 Lanikai/3.1.1pre MIME-Version: 1.0 To: Daniel O'Connor References: <4C309359.8000502@andric.com> <791316F7-6E16-47D7-9B6C-2881FAAC78AA@gsoft.com.au> In-Reply-To: <791316F7-6E16-47D7-9B6C-2881FAAC78AA@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: GEOM/bsdlabel regression in 8.x? 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, 04 Jul 2010 15:37:09 -0000 On 2010-07-04 16:26, Daniel O'Connor wrote: >> First unmount /dev/md0s1a, or the device /dev/md0s1 will be in use, and >> opening it for read/write (as bsdlabel probably does) will fail. >> >> Alternatively, you can turn on the "footshooting" debug flag in geom: ... > It doesn't make a difference if you set that flag or not. > > (The fact you need to set debugflags to modify the MBR is a separate bug anyway IMO) On my 8-stable box, I have tried this sequence of commands: truncate -s 10m /tmp/test mdconfig -a -t vnode -f /tmp/test mdconfig -a -t vnode -f /tmp/test fdisk -BI /dev/md0 bsdlabel -w /dev/md0s1 bsdlabel -e /dev/md0s1 newfs /dev/md0s1a mkdir /mnt/test mount /dev/md0s1a /mnt/test bsdlabel -e /dev/md0s1 The last one indeed fails, because the device is in use. This is expected, but the error message is very misleading, and should be improved. The real 'bug' (although there will probably be loads of bikesheds about it) is probably that if you *do* unmount the filesystem, bsdlabel still fails: umount /mnt/test bsdlabel -e /dev/md0s1 [class not found yada yada] Apparently, unmounting does not properly 'release' whatever underlying geom device is preventing read/write access. However, if you then set the footshooting flag: sysctl -w kern.geom.debugflags=0x10 bsdlabel -e /dev/md0s1 bsdlabel can write without problems, at least on my box. Stranger even, if you subsequently turn off the footshooting flag, it *still* can write to the label. That is, unless you mount and unmount the filesystem, after which is again, sort of 'locked' against writing. All highly confusing. :) From owner-freebsd-stable@FreeBSD.ORG Sun Jul 4 16:16:21 2010 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 47D641065670 for ; Sun, 4 Jul 2010 16:16:21 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id EB8EA8FC21 for ; Sun, 4 Jul 2010 16:16:20 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o64GFS1Q010594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 4 Jul 2010 09:15:29 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 762E21CC0D; Sun, 4 Jul 2010 09:15:28 -0700 (PDT) To: jhell In-reply-to: Your message of "Sun, 04 Jul 2010 01:55:20 EDT." <4C302248.1020509@dataix.net> Date: Sun, 04 Jul 2010 09:15:28 -0700 From: "Kevin Oberman" Message-Id: <20100704161528.762E21CC0D@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-02_03:2010-02-06, 2010-07-02, 2010-07-04 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1007040073 Cc: stable@freebsd.org Subject: Re: Odd behavior of labels on different filesystem types 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, 04 Jul 2010 16:16:21 -0000 > Sender: "J. Hellenthal" > Date: Sun, 04 Jul 2010 01:55:20 -0400 > From: jhell > > On 07/03/2010 16:51, Kevin Oberman wrote: > > I have run into an odd behavior in 8-stable that I can't see a reason > > for. > > > > If I have a FAT32 formatted removable drive, I get /dev entries for it > > as both /dev/msdosfs/LABEL and /dev/ufsid/ID. When I mount the > > filesystem, the /dev/ufsid label is removed, but the other two remain. > > > > If I have a UFS filesystem on the disk, I have similar devices except > > that the LABEL is /dev/ufs/LABEL. But, when the UFS device is mounted, > > the /dev/ufsid/ID AND the /dev/ufs/LABEL devs are both deleted. > > > > I'm not sure which is "right", but I can't see the reason for the > > different behavior and it has caused a fair bit of trouble when working > > with gnome-mount as I can't unmount a ufs device. When the > > /dev/ufs/LABEL device is created again on the umount, gnome-mount sees a > > new device and immediately re-mounts it. > > > > Can this inconsistency be corrected? > > Can you try to zero out that disk first i.e. > dd if=/dev/zero of=/dev/DISK bs=4m > > Then format your msdos fat part and relabel it. You should not see a > dev/ufsid/ label for this anymore. I believe that for some reason the > ufsid metadata or whatever you want to call it some how has been left > behind and is still being read for whatever reason and can be confirmed > by this. > > As for /dev/ufs/LABEL /dev/ufsid/ID /dev/device when you mount one the > others should disapear so this is correct behavior. Thanks for the suggestion. I will try a device which has never had a UFS file system and see if the ufsid device is created. Looks like the former is an issue with geom tasting and it would be nice to get it fixed, but it is not what is causing my problem. It is the latter issue that causes the problems with gnome-mount. The real issue for me is that /dev/ufs/LABEL is removed on a mount while /dev/msdosfs/LABEL remains. hald easily works around ufsid by ignoring it, but the /dev/FS/LABEL has to be acted upon differently depending on which filesystem is involved. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Sun Jul 4 17:58:33 2010 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 9A9351065689 for ; Sun, 4 Jul 2010 17:58:33 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 592978FC30 for ; Sun, 4 Jul 2010 17:58:33 +0000 (UTC) Received: by iwn35 with SMTP id 35so3088875iwn.13 for ; Sun, 04 Jul 2010 10:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=DD2FYYQsMYQJTGphXIkUSG0jPV4fo4BkvbDG8ctY7Z0=; b=KNxoLmWQyqkHmLnGJysfvWN1hy56onM75K+QVImWDX8UPFS3m1Urj0oXZOPxoQG9/2 tB/tkw3Ab4aIuV7S0itwY08QjLbzdrKStoqAmmPLS60myLK6YhRrmfBIYtNra+3clAOo dNeDta+zR/DRewzBao4Qamg5dZ57W9qQ4PbcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=APYRbSs3K62N8TzpdCKwHR1wGGw8N2YoGWWRSMMIuk00I9k8AbQIrDEq5wCVAOrEcx 52Qmqfojwz9cg87xkVoRV+1zpjddc8my+tf8gznlGjvtfGzORzY6KLyDI8YUlzvKWuH4 7kz+nM7PdsNQr0a/6gzfhki442jE2q63vMczA= Received: by 10.231.171.13 with SMTP id f13mr1800697ibz.103.1278266312531; Sun, 04 Jul 2010 10:58:32 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-128-180.dsl.klmzmi.sbcglobal.net [99.181.128.180]) by mx.google.com with ESMTPS id 34sm14291963ibi.0.2010.07.04.10.58.31 (version=SSLv3 cipher=RC4-MD5); Sun, 04 Jul 2010 10:58:31 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C30CBC6.1030507@dataix.net> Date: Sun, 04 Jul 2010 13:58:30 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100626 Thunderbird MIME-Version: 1.0 To: Kevin Oberman References: <20100704161528.762E21CC0D@ptavv.es.net> In-Reply-To: <20100704161528.762E21CC0D@ptavv.es.net> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Odd behavior of labels on different filesystem types 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, 04 Jul 2010 17:58:33 -0000 On 07/04/2010 12:15, Kevin Oberman wrote: >> Sender: "J. Hellenthal" >> Date: Sun, 04 Jul 2010 01:55:20 -0400 >> From: jhell >> >> On 07/03/2010 16:51, Kevin Oberman wrote: >>> I have run into an odd behavior in 8-stable that I can't see a reason >>> for. >>> >>> If I have a FAT32 formatted removable drive, I get /dev entries for it >>> as both /dev/msdosfs/LABEL and /dev/ufsid/ID. When I mount the >>> filesystem, the /dev/ufsid label is removed, but the other two remain. >>> >>> If I have a UFS filesystem on the disk, I have similar devices except >>> that the LABEL is /dev/ufs/LABEL. But, when the UFS device is mounted, >>> the /dev/ufsid/ID AND the /dev/ufs/LABEL devs are both deleted. >>> >>> I'm not sure which is "right", but I can't see the reason for the >>> different behavior and it has caused a fair bit of trouble when working >>> with gnome-mount as I can't unmount a ufs device. When the >>> /dev/ufs/LABEL device is created again on the umount, gnome-mount sees a >>> new device and immediately re-mounts it. >>> >>> Can this inconsistency be corrected? >> >> Can you try to zero out that disk first i.e. >> dd if=/dev/zero of=/dev/DISK bs=4m >> >> Then format your msdos fat part and relabel it. You should not see a >> dev/ufsid/ label for this anymore. I believe that for some reason the >> ufsid metadata or whatever you want to call it some how has been left >> behind and is still being read for whatever reason and can be confirmed >> by this. >> >> As for /dev/ufs/LABEL /dev/ufsid/ID /dev/device when you mount one the >> others should disapear so this is correct behavior. > > Thanks for the suggestion. I will try a device which has never had a UFS > file system and see if the ufsid device is created. Looks like the > former is an issue with geom tasting and it would be nice to get it > fixed, but it is not what is causing my problem. It is the latter issue > that causes the problems with gnome-mount. > > The real issue for me is that /dev/ufs/LABEL is removed on a mount while > /dev/msdosfs/LABEL remains. hald easily works around ufsid by ignoring > it, but the /dev/FS/LABEL has to be acted upon differently depending on > which filesystem is involved. Do you use those labels for anything ? if not, I worked around this while I used gnome for a period with devfs.rules(5) example follows. rc.conf(5) add devfs_system_ruleset="your_system" [your_system=10] add path 'ufsid' hide add path 'msdosfs' hide add path 'ufs' hide add path 'iso9660' hide add path 'reiserfs' hide add path 'ntfs' hide add path 'ext2fs' hide add path 'gpt' hide And you can do the same for the actual devices that you use a label for, so mounting devices like daN can just be done from /dev/label/LABEL. add path 'da0' hide # Do this only after it is labeled. add path 'label/DA0LABEL' mode 0600 user jhell group jhell With a little toying of the above you should get the desired effect you want in gnome. I do find it frustrating having to resort to using only generic labels for situations like this and believe firmly that the generic label should take precedence over all labels except gpt & ufsid and result in the other name-brand labels disappearing not causing this frustration to happen. Having the multiple layers of labels available IMO is cause for confusion. Final note before I stretch this out like the Armstrong figurine ;), there was a case where I was using the module instead of having GEOM_LABEL option built into the kernel, this being loaded after the machine was already booted caused some strange results with the labels that I know of on 7.2-STABLE. I don't know if this still exists but the result from that was multiple labels still being available under /dev while its counterpart label was mounted. That caused Gnome/hald to get pretty confused. Regards & Good luck, -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ From owner-freebsd-stable@FreeBSD.ORG Sun Jul 4 21:15:35 2010 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 007FE1065672 for ; Sun, 4 Jul 2010 21:15:35 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id AB5AB8FC1D for ; Sun, 4 Jul 2010 21:15:34 +0000 (UTC) Received: by qyk7 with SMTP id 7so1631865qyk.13 for ; Sun, 04 Jul 2010 14:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wPk35IhUz8fIe4AOooPqQhSa8SzS7rpkp8XtZhF/KJg=; b=nZ0+xCGei4HFopJ4mGWn9tFYht903KIBO0FPjRn7W4v8twHVxnWGTkRLMRTHOSVuyF GQ2BPy812JOYJh/1KKwjVs/0mvfwRIvemdhmeJoprEafmHor7qmCPnEMV2zHt/dHzOUI 3SS2+ITwStu7hIyCzW8oNYdc7gU/nf1rw4eD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uhWj7Sr3eESDVex925dXcwQ8BI3CIJoZPvVlDeOH4bUC/ygeRffKQMrWG/b3p6z4bG x6zwDtvHYCH3UAw8IlDwvKSDMQXHHGK0QAicROpOvNuQ5ovhIat2c7PpMICcbyeLmIMQ Y5r/3EtO2/14+Z0PK5g5ml4WH7q1DWzLxDl54= MIME-Version: 1.0 Received: by 10.229.246.15 with SMTP id lw15mr952339qcb.284.1278278130744; Sun, 04 Jul 2010 14:15:30 -0700 (PDT) Received: by 10.229.192.201 with HTTP; Sun, 4 Jul 2010 14:15:30 -0700 (PDT) In-Reply-To: <4C30AAA8.7010206@andric.com> References: <4C309359.8000502@andric.com> <791316F7-6E16-47D7-9B6C-2881FAAC78AA@gsoft.com.au> <4C30AAA8.7010206@andric.com> Date: Sun, 4 Jul 2010 14:15:30 -0700 Message-ID: From: Garrett Cooper To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable Subject: Re: GEOM/bsdlabel regression in 8.x? 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, 04 Jul 2010 21:15:35 -0000 On Sun, Jul 4, 2010 at 8:37 AM, Dimitry Andric wrote: > On 2010-07-04 16:26, Daniel O'Connor wrote: >>> First unmount /dev/md0s1a, or the device /dev/md0s1 will be in use, and >>> opening it for read/write (as bsdlabel probably does) will fail. >>> >>> Alternatively, you can turn on the "footshooting" debug flag in geom: > ... >> It doesn't make a difference if you set that flag or not. >> >> (The fact you need to set debugflags to modify the MBR is a separate bug= anyway IMO) > > On my 8-stable box, I have tried this sequence of commands: > > =A0truncate -s 10m /tmp/test > =A0mdconfig -a -t vnode -f /tmp/test > =A0mdconfig -a -t vnode -f /tmp/test > =A0fdisk -BI /dev/md0 > =A0bsdlabel -w /dev/md0s1 > =A0bsdlabel -e /dev/md0s1 > =A0newfs /dev/md0s1a > =A0mkdir /mnt/test > =A0mount /dev/md0s1a /mnt/test > =A0bsdlabel -e /dev/md0s1 > > The last one indeed fails, because the device is in use. =A0This is > expected, but the error message is very misleading, and should be > improved. > > The real 'bug' (although there will probably be loads of bikesheds about > it) is probably that if you *do* unmount the filesystem, bsdlabel still > fails: > > =A0umount /mnt/test > =A0bsdlabel -e /dev/md0s1 > =A0[class not found yada yada] > > Apparently, unmounting does not properly 'release' whatever underlying > geom device is preventing read/write access. =A0However, if you then set > the footshooting flag: > > =A0sysctl -w kern.geom.debugflags=3D0x10 > =A0bsdlabel -e /dev/md0s1 > > bsdlabel can write without problems, at least on my box. =A0Stranger > even, if you subsequently turn off the footshooting flag, it *still* > can write to the label. =A0That is, unless you mount and unmount the > filesystem, after which is again, sort of 'locked' against writing. > > All highly confusing. :) There's a weird ass feature in geom too under 7.x+ that if you have where if you have a dangerously dedicated disk partitioned like so that gets mounted, it automatically hides the slicing: $ dd if=3D/dev/zero of=3Dafile bs=3D10m count=3D5 $ mdconfig -a -t vnode -f afile md1 $ ls /dev/md1* /dev/md1 $ sudo fdisk -BIq /dev/md1 $ bsdlabel -w /dev/md1s1 $ bsdlabel -e /dev/md1s1 # /dev/md1s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 96311 16 unused 0 0 c: 96327 0 unused 0 0 # "raw" part, don't= edit # newfs /dev/md1s1 /dev/md1s1: 47.0MB (96324 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 11.77MB, 753 blks, 1536 inodes. super-block backups (for fsck -b #) at: 160, 24256, 48352, 72448 $ ls /dev/md1* /dev/md1 /dev/md1s1 $ ls /dev/md1* /dev/md1 /dev/md1s1 /dev/md1s1a $ mount /dev/md1s1 /mnt/mem $ ls /dev/md1* /dev/md1 /dev/md1s1 $ umount /mnt/mem $ ls /dev/md1* /dev/md1 /dev/md1s1 /dev/md1s1a It's something that someone noticed at my work. Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Sun Jul 4 23:34:06 2010 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 292B5106564A for ; Sun, 4 Jul 2010 23:34:06 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (unknown [IPv6:2001:44b8:7c07:5581:36b8:7bff:fee0:1a08]) by mx1.freebsd.org (Postfix) with ESMTP id 74DA78FC12 for ; Sun, 4 Jul 2010 23:34:05 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-156-127.lns6.adl6.internode.on.net [121.45.156.127]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o64NXTDS089686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Jul 2010 09:03:35 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <4C30AAA8.7010206@andric.com> Date: Mon, 5 Jul 2010 09:03:29 +0930 Content-Transfer-Encoding: 7bit Message-Id: References: <4C309359.8000502@andric.com> <791316F7-6E16-47D7-9B6C-2881FAAC78AA@gsoft.com.au> <4C30AAA8.7010206@andric.com> To: Dimitry Andric X-Mailer: Apple Mail (2.1081) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: FreeBSD Stable Subject: Re: GEOM/bsdlabel regression in 8.x? 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, 04 Jul 2010 23:34:06 -0000 On 05/07/2010, at 1:07, Dimitry Andric wrote: > bsdlabel -e /dev/md0s1 > > The last one indeed fails, because the device is in use. This is > expected, but the error message is very misleading, and should be > improved. Maybe, I wouldn't call it expected because it used to work :) I agree about the error message though! > The real 'bug' (although there will probably be loads of bikesheds about > it) is probably that if you *do* unmount the filesystem, bsdlabel still > fails: > > umount /mnt/test > bsdlabel -e /dev/md0s1 > [class not found yada yada] > > Apparently, unmounting does not properly 'release' whatever underlying > geom device is preventing read/write access. However, if you then set > the footshooting flag: > > sysctl -w kern.geom.debugflags=0x10 > bsdlabel -e /dev/md0s1 > > bsdlabel can write without problems, at least on my box. Stranger > even, if you subsequently turn off the footshooting flag, it *still* > can write to the label. That is, unless you mount and unmount the > filesystem, after which is again, sort of 'locked' against writing. > > All highly confusing. :) Hmm odd, the sysctl had no effect here.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Sun Jul 4 23:36:51 2010 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 AA6FE106564A; Sun, 4 Jul 2010 23:36:51 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (unknown [IPv6:2001:44b8:7c07:5581:36b8:7bff:fee0:1a08]) by mx1.freebsd.org (Postfix) with ESMTP id DEA1E8FC0C; Sun, 4 Jul 2010 23:36:50 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-156-127.lns6.adl6.internode.on.net [121.45.156.127]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o64NagvM089749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Jul 2010 09:06:48 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <20100704152205.GA1734@a91-153-117-195.elisa-laajakaista.fi> Date: Mon, 5 Jul 2010 09:06:42 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <18DD407F-8776-4401-AA53-D71466219143@gsoft.com.au> References: <20100704152205.GA1734@a91-153-117-195.elisa-laajakaista.fi> To: Jaakko Heinonen X-Mailer: Apple Mail (2.1081) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: FreeBSD Stable Subject: Re: GEOM/bsdlabel regression in 8.x? 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, 04 Jul 2010 23:36:51 -0000 On 05/07/2010, at 24:52, Jaakko Heinonen wrote: > On 2010-07-04, Daniel O'Connor wrote: >> "bsdlabel: Class not found" >=20 > This is because GEOM_BSD -> GEOM_PART_BSD change. bsdlabel(8) needs > read-write access to the device. If it can't get that, it tries an > alternative GEOM based method only supported by GEOM_BSD. The error > message "Class not found" is printed because the "BSD" GEOM class > doesn't exist. >=20 > You might be able to do the changes with gpart(8). Ahh that does work.. midget# gpart add -t freebsd-ufs -i 4 md0s1 md0s1d added midget# newfs /dev/md0s1d /dev/md0s1d: 2.8MB (5744 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 0.70MB, 45 blks, 128 inodes. super-block backups (for fsck -b #) at: 160, 1600, 3040, 4480 mmidget# mount /dev/md0s1d /mnt/test2 midget# mount .. /dev/md0s1a on /mnt/test (ufs, local) /dev/md0s1d on /mnt/test2 (ufs, local) IMO it's still a regression because bsdlabel used to work, although I = can appreciate it might be a rather in depth change to have it work with = the New World Order (tm). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Sun Jul 4 23:42:34 2010 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 A6F64106566C; Sun, 4 Jul 2010 23:42:34 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (unknown [IPv6:2001:44b8:7c07:5581:36b8:7bff:fee0:1a08]) by mx1.freebsd.org (Postfix) with ESMTP id E99168FC19; Sun, 4 Jul 2010 23:42:33 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-156-127.lns6.adl6.internode.on.net [121.45.156.127]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o64NgPq3089903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Jul 2010 09:12:31 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <18DD407F-8776-4401-AA53-D71466219143@gsoft.com.au> Date: Mon, 5 Jul 2010 09:12:24 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <8E10234C-B4C0-4DF5-9AC9-A8C9C14AE010@gsoft.com.au> References: <20100704152205.GA1734@a91-153-117-195.elisa-laajakaista.fi> <18DD407F-8776-4401-AA53-D71466219143@gsoft.com.au> To: "Daniel O'Connor" X-Mailer: Apple Mail (2.1081) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Jaakko Heinonen , FreeBSD Stable Subject: Re: GEOM/bsdlabel regression in 8.x? 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, 04 Jul 2010 23:42:34 -0000 On 05/07/2010, at 9:06, Daniel O'Connor wrote: >=20 > On 05/07/2010, at 24:52, Jaakko Heinonen wrote: >=20 >> On 2010-07-04, Daniel O'Connor wrote: >>> "bsdlabel: Class not found" >>=20 >> This is because GEOM_BSD -> GEOM_PART_BSD change. bsdlabel(8) needs >> read-write access to the device. If it can't get that, it tries an >> alternative GEOM based method only supported by GEOM_BSD. The error >> message "Class not found" is printed because the "BSD" GEOM class >> doesn't exist. >>=20 >> You might be able to do the changes with gpart(8). >=20 > Ahh that does work.. >=20 > midget# gpart add -t freebsd-ufs -i 4 md0s1 > IMO it's still a regression because bsdlabel used to work, although I = can appreciate it might be a rather in depth change to have it work with = the New World Order (tm). So, why didn't it? Shouldn't it DTRT? This is a stock kernel. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Mon Jul 5 01:20:45 2010 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 27F47106566B for ; Mon, 5 Jul 2010 01:20:45 +0000 (UTC) (envelope-from davideugenewarren@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D58328FC12 for ; Mon, 5 Jul 2010 01:20:44 +0000 (UTC) Received: by vws6 with SMTP id 6so5462942vws.13 for ; Sun, 04 Jul 2010 18:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=7RUc/2PVHGGvsUXaLr0bQPh/tgNM696Yex2ZcS7EZnE=; b=Mhtva/B9Rc20oxRjKrw9vqLR7/tyUzGZhiXcBpw0mTHgpnhWOXa0k4NVTiffKhlvGM 743WoxSbT/08Ay/QKKKO5nSwSujGxd5lupiRab/B9rJGs0TnGOG+B5iT4XJsIeN6Q3xg ltDNaCZ/tPcCjKNBitEgJ7sqm3wkeYTowkJG4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=jIAwklJyWtHXOLx+tADjqBAs8Z5hS3uq1++i6ExCc88ztJLfij3osip6DdeQGD8196 ZYVOSkXYLqc+STcPcN6eZziN89hJyIVXhQ+clH8CetV2Dy94KBLghV9ZXMUGpIVQ+dUC 7o0RLt2Cs1YovwJoNRvHLEFiTyoOyijhnp0JA= MIME-Version: 1.0 Received: by 10.220.157.140 with SMTP id b12mr1097115vcx.156.1278291131872; Sun, 04 Jul 2010 17:52:11 -0700 (PDT) Received: by 10.220.190.1 with HTTP; Sun, 4 Jul 2010 17:52:11 -0700 (PDT) Date: Sun, 4 Jul 2010 19:52:11 -0500 Message-ID: From: David Warren To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 8.0 network 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, 05 Jul 2010 01:20:45 -0000 Hi all, I've got a persistent problem with my LAN. I'm running a FreeBSD 8.0 box as a home server performing the following functions for wired and wireless networks: router; firewall; DHCP server; and file server. For what it's worth, I've got ZFS up and running as the main filesystem. The recurring issue is that file transfers from the FreeBSD box to computers on the wired network (gigabit) start out fast and then become agonizingly slow. I'm sharing home directories over Samba, and those transfers work briefly and then tail off to a few kilobytes per second. The failure is somewhat predicatable in that it tends to happen once a few hundred megabytes have been transferred. I've swapped out hardware, I've Googled extensively, and all of the (possibly benign) error messages that I've found have been eliminated. I'm happy to post logs, configs, etc., and I'd appreciate any help with a diagnosis. For the moment: > uname -a FreeBSD EightOh.dew.home 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan 5 21:11:58 UTC 2010 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > ifconfig em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:0e:0c:b7:71:44 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (1000baseT ) status: active ral0: flags=8843 metric 0 mtu 2290 ether 00:1f:1f:3f:76:f3 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running nfe0: flags=8843 metric 0 mtu 1500 options=8 ether 00:01:29:d4:2d:6b inet XXX.XXX.XXX.XXX netmask 0xfffffc00 broadcast 255.255.255.255 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=8810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 wlan0: flags=8843 metric 0 mtu 1500 ether 00:1f:1f:3f:76:f3 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid FreeBSD_AP channel 7 (2442 Mhz 11g) bssid 00:1f:1f:3f:76:f3 country US authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit txpower 0 scanvalid 60 protmode CTS dtimperiod 1 -dfs pflog0: flags=141 metric 0 mtu 33152 Thanks in advance! Dave From owner-freebsd-stable@FreeBSD.ORG Mon Jul 5 01:40:03 2010 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 1369910656C4 for ; Mon, 5 Jul 2010 01:40:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 981B98FC15 for ; Mon, 5 Jul 2010 01:40:02 +0000 (UTC) Received: (qmail 15292 invoked by uid 399); 5 Jul 2010 01:40:01 -0000 Received: from localhost (HELO ?192.168.0.143?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 5 Jul 2010 01:40:01 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Sun, 4 Jul 2010 18:40:00 -0700 (PDT) From: Doug Barton To: David Warren In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: 8.0 network 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, 05 Jul 2010 01:40:03 -0000 On Sun, 4 Jul 2010, David Warren wrote: > Hi all, > > I've got a persistent problem with my LAN. I'm running a FreeBSD 8.0 > box as a home server Is it feasible for you to update to 8.1-RC2 and see if that helps? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-stable@FreeBSD.ORG Mon Jul 5 04:00:47 2010 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 9DC391065672 for ; Mon, 5 Jul 2010 04:00:47 +0000 (UTC) (envelope-from davideugenewarren@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4E11B8FC15 for ; Mon, 5 Jul 2010 04:00:46 +0000 (UTC) Received: by vws6 with SMTP id 6so5579621vws.13 for ; Sun, 04 Jul 2010 21:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Z35R1jPz/J3+g7XttpqYs2hN0PDkRQSZOgGTko6griE=; b=BYnB383ZMg+NrkpbfwVQAsZCE8GDRKKraaITZy4qBJSFWbQKf6DmR7IrSd1HmsolQo keYYWO19EAsQMQSRUdwibVYGFsB34AQ4rY6xwze5BJOZY+FR3fmgQbsEKnR2U5viMVkB AQdDXN7ATWwuu6IGABMfPxivE6YOhMoxiTNxo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hVTxG/Xvy8JkrJqtES9m6c+MxB1VX3ZXOH4SENxn4odHX0JGPnjhCWSuu2y3ATwAdR pQKsL04VWndP54YdOAZaWhacOdomEoP7BtRg1GRd5Makg4wbCtQXbjr64xoYo2z+1+dJ 50xJk4bt2OpyY6bxaokrHCnzMSMNUPl2J4scs= MIME-Version: 1.0 Received: by 10.220.59.202 with SMTP id m10mr1190205vch.59.1278302443355; Sun, 04 Jul 2010 21:00:43 -0700 (PDT) Received: by 10.220.190.1 with HTTP; Sun, 4 Jul 2010 21:00:43 -0700 (PDT) In-Reply-To: References: Date: Sun, 4 Jul 2010 23:00:43 -0500 Message-ID: From: David Warren To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 8.0 network 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, 05 Jul 2010 04:00:47 -0000 Hi Doug, I tried a binary update to 8.1 RC2, and then rebuilt all ports. Unfortunately, I'm still experiencing the same problem. Any thoughts on troubleshooting this? Thanks, Dave On Sun, Jul 4, 2010 at 8:40 PM, Doug Barton wrote: > On Sun, 4 Jul 2010, David Warren wrote: > > Hi all, >> >> I've got a persistent problem with my LAN. I'm running a FreeBSD 8.0 >> box as a home server >> > > Is it feasible for you to update to 8.1-RC2 and see if that helps? > > > Doug > > -- > > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ > > Computers are useless. They can only give you answers. > -- Pablo Picasso > > -- Post-doctoral Fellow Neurology Department University of Iowa Hospitals and Clinics davideugenewarren@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Jul 5 05:26:31 2010 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 4D97E106566B for ; Mon, 5 Jul 2010 05:26:31 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 178608FC15; Mon, 5 Jul 2010 05:26:30 +0000 (UTC) Received: by pxi4 with SMTP id 4so342363pxi.13 for ; Sun, 04 Jul 2010 22:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=UUFmCLVf1eBThCWk8lt1w1Vk7y1nNn3iBxLCqdNL034=; b=ME7uJ7PddafoP1rPsv58uDpDNzBxhElQCTyNHMqkQUFQcbwjtWXohxPpB/QdzHVpZC 1bWdLStgC042/MiFtksqLnL76SJiNA2znMEY6C5BgA+dio44tdmn+0rXc2c25X9I6m+i Z2NAwmeEm6qYjDW/YhXajCcS01sH6dS24oShE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=dUUQjvNO9WCpurfez15idqn6+uBd+vj7GuaOIYq9J329qtG6r3mcxxghACq9Eeo9mo 1dwbwW71dddJjzTs2V9eKLDGttdqn4JZGZpo3Xs8KT54Pr2ayIkILwoKHZd0w5ueWNGP GCkQnd0pYc4bRJ9HJOaT0YvbqIpgudoZxjilg= Received: by 10.142.134.7 with SMTP id h7mr2701213wfd.248.1278306260751; Sun, 04 Jul 2010 22:04:20 -0700 (PDT) Received: from [192.168.0.203] (deviant.freebsdgirl.com [173.8.183.73]) by mx.google.com with ESMTPS id x18sm4110823wfd.20.2010.07.04.22.04.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 04 Jul 2010 22:04:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Garrett Cooper In-Reply-To: Date: Sun, 4 Jul 2010 22:04:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5D34EED0-9560-45A1-ADCF-176C4996E17E@gmail.com> References: To: David Warren X-Mailer: Apple Mail (2.1081) Cc: freebsd-stable@freebsd.org, jvogel@freebsd.org Subject: Re: 8.0 network 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, 05 Jul 2010 05:26:31 -0000 On Jul 4, 2010, at 5:52 PM, David Warren wrote: > Hi all, >=20 > I've got a persistent problem with my LAN. I'm running a FreeBSD = 8.0 > box as a home server performing the following functions for wired and > wireless networks: router; firewall; DHCP server; and file server. = For what > it's worth, I've got ZFS up and running as the main filesystem. The > recurring issue is that file transfers from the FreeBSD box to = computers on > the wired network (gigabit) start out fast and then become agonizingly > slow. I'm sharing home directories over Samba, and those transfers = work > briefly and then tail off to a few kilobytes per second. The failure = is > somewhat predicatable in that it tends to happen once a few hundred > megabytes have been transferred. I've swapped out hardware, I've = Googled > extensively, and all of the (possibly benign) error messages that I've = found > have been eliminated. I'm happy to post logs, configs, etc., and I'd > appreciate any help with a diagnosis. For the moment: Disable rxcsum and txcsum on the cards; see if that does the = trick. Before that, I'd see whether or not Jack Vogel (the current = em(4) maintainer) would some details about your traffic, like a tcpdump = session log. HTH, -Garrett= From owner-freebsd-stable@FreeBSD.ORG Mon Jul 5 05:37:35 2010 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 352A91065674 for ; Mon, 5 Jul 2010 05:37:35 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 846678FC08 for ; Mon, 5 Jul 2010 05:37:34 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id o655bMBg019108 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Jul 2010 06:37:29 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) Message-ID: <4C316F92.10507@infracaninophile.co.uk> Date: Mon, 05 Jul 2010 06:37:22 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: David Warren References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.1 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50,DKIM_ADSP_ALL, SPF_FAIL autolearn=no version=3.3.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-stable@freebsd.org Subject: Re: 8.0 network 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, 05 Jul 2010 05:37:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/07/2010 01:52:11, David Warren wrote: > I've got a persistent problem with my LAN. I'm running a FreeBSD 8.0 > box as a home server performing the following functions for wired and > wireless networks: router; firewall; DHCP server; and file server. For what > it's worth, I've got ZFS up and running as the main filesystem. The > recurring issue is that file transfers from the FreeBSD box to computers on > the wired network (gigabit) start out fast and then become agonizingly > slow. I'm sharing home directories over Samba, and those transfers work > briefly and then tail off to a few kilobytes per second. The failure is > somewhat predicatable in that it tends to happen once a few hundred > megabytes have been transferred. I've swapped out hardware, I've Googled > extensively, and all of the (possibly benign) error messages that I've found > have been eliminated. I'm happy to post logs, configs, etc., and I'd > appreciate any help with a diagnosis. For the moment: Does this affect both wired and wireless LANs? Does this affect specific protocols more severely than other protocols? Does this affect all traffic happening at that point, all traffic on a particular interface or just specific connections? The effect you describe sounds bizarrely like entropy-pool exhaustion, which would kill any traffic over your wireless network, or anything using crypto protocols on either wired or wireless nets. I say "sounds like" because the yarrow entropy pool maintenance code in FreeBSD is extremely good, and I've seen FreeBSD boxes serving HTTPS at Mb/s without anything like what you are experiencing. Also, you're seeing it affect Samba over a wired connection, and that should be minimally affected by that sort of thing. Hmmm... Can you try transferring some large files (DVD .iso images around a few GB in size are handy for this) between systems using: * netcat or HTTP over wired connection * ssh over wired connection * netcat or HTTP over wireless * ssh over wireless Try these in both directions -- this should help show if it's slow disk performance on the receiving side. Also, check the output of 'netstat -i' to see if interface error counters are increasing: Ierrors, Idrop and Oerrors should all ideally be zero. If you see those starting to rise, it means either there's a configuration problem somewhere, like a duplex mismatch [no evidence for that from the ifconfig output you showed though] or perhaps there's still some dodgy hardware somewhere on your network despite all the swapping-out you've been doing. One final thought -- perhaps this isn't to do with the network at all, but it's disk IO performance bottoming out. In which case you should be able to see much the same effect copying files between different zpools, or between your main zpool and say, a USB memory stick. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwxb5IACgkQ8Mjk52CukIz6xQCffeqtaiZ5zc8JDX5EWzGAgdPo 1BoAn0F7Upq4QoTkg2O8mUPBCnYtom/T =EqiV -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 5 05:50:48 2010 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 77C68106566C for ; Mon, 5 Jul 2010 05:50:48 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 2A6828FC17 for ; Mon, 5 Jul 2010 05:50:47 +0000 (UTC) Received: by qyk30 with SMTP id 30so1818369qyk.13 for ; Sun, 04 Jul 2010 22:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Q+pttMuxtLCLMe0mwatmkk9ez6skeijDuWY4mrMbUtw=; b=IFMsniox6X+3urhpvYLMSt9t9CXURH0KVTDiAC44VH8cRB9qwnwpg91kl0G5Ambb3i h3itC7I1+JeqcmsMPY94ZGT/Z1I2opnUhyn4Yhk11n8p6JdU0N/cjfi0M0cbEdYVVr7F acLA6vB8TCf0nmGiq9ah5htlBq/lNtZLpweSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=O02uJnynmxJiUb0+d43mliu8TPieMeF3y1146q2pqO1ik9ux1hYH3OjGmpxB+KsJrT vRcXdLiaOiKOWF1YjqvNIMqsCR/BSsMosN4X+OpHXEbuziN/tMOKLnRUXb+upAvkAbru wZvyQAliE7WJRL5NQ4q7C1ll0Hl2j4isizodU= MIME-Version: 1.0 Received: by 10.229.217.6 with SMTP id hk6mr823399qcb.210.1278309039952; Sun, 04 Jul 2010 22:50:39 -0700 (PDT) Received: by 10.229.86.12 with HTTP; Sun, 4 Jul 2010 22:50:39 -0700 (PDT) In-Reply-To: <4C316F92.10507@infracaninophile.co.uk> References: <4C316F92.10507@infracaninophile.co.uk> Date: Mon, 5 Jul 2010 00:50:39 -0500 Message-ID: From: Adam Vande More To: Matthew Seaman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: David Warren , freebsd-stable@freebsd.org Subject: Re: 8.0 network 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, 05 Jul 2010 05:50:48 -0000 On Mon, Jul 5, 2010 at 12:37 AM, Matthew Seaman < m.seaman@infracaninophile.co.uk> wrote: > > One final thought -- perhaps this isn't to do with the network at all, > but it's disk IO performance bottoming out. In which case you should be > able to see much the same effect copying files between different zpools, > or between your main zpool and say, a USB memory stick. > IIRC, this issue may have been described before and it's ZFS related. I'm pretty sure there was an issue with ZFS transfer's stallling and the original poster was trying to do things like zfs send. I think it was resolved by upgrading to STABLE. If I remember more, I'll post it otherwise check the archive's (fs, general, net) from maybe around 2-3 months ago or even asking there. Skim search had this, http://lists.freebsd.org/pipermail/freebsd-fs/2010-February/007818.html -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Mon Jul 5 05:51:07 2010 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 6104C106566B for ; Mon, 5 Jul 2010 05:51:07 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id 485E08FC08 for ; Mon, 5 Jul 2010 05:51:06 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta10.emeryville.ca.mail.comcast.net with comcast id e5jF1e0010lTkoCAA5r6eE; Mon, 05 Jul 2010 05:51:06 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta04.emeryville.ca.mail.comcast.net with comcast id e5r51e0053S48mS8Q5r6iy; Mon, 05 Jul 2010 05:51:06 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6A13C9B425; Sun, 4 Jul 2010 22:51:05 -0700 (PDT) Date: Sun, 4 Jul 2010 22:51:05 -0700 From: Jeremy Chadwick To: David Warren Message-ID: <20100705055105.GA21681@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: 8.0 network 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, 05 Jul 2010 05:51:07 -0000 On Sun, Jul 04, 2010 at 07:52:11PM -0500, David Warren wrote: > I've got a persistent problem with my LAN. I'm running a FreeBSD 8.0 > box as a home server performing the following functions for wired and > wireless networks: router; firewall; DHCP server; and file server. For what > it's worth, I've got ZFS up and running as the main filesystem. The > recurring issue is that file transfers from the FreeBSD box to computers on > the wired network (gigabit) start out fast and then become agonizingly > slow. I'm sharing home directories over Samba, and those transfers work > briefly and then tail off to a few kilobytes per second. The failure is > somewhat predicatable in that it tends to happen once a few hundred > megabytes have been transferred. Your system has 3 different network interfaces on it (em, ral, nfe), but you don't tell us across which interface the slow transfers happen. You also don't tell us which firewalling stack you're using (ipfw, ipfilter, pf). Let us know. I'm going to make the assumption that based on your "...on the wired network (gigabit)..." statement that the transfers are going across the em0 interface, but again, I'm not sure. Relevant interfaces (wlan0 is tied to ral0): > em0: flags=8843 metric 0 mtu 1500 > options=9b > ether 00:0e:0c:b7:71:44 > inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > media: Ethernet autoselect (1000baseT ) > status: active > ral0: flags=8843 metric 0 mtu 2290 > ether 00:1f:1f:3f:76:f3 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: running > nfe0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:01:29:d4:2d:6b > inet XXX.XXX.XXX.XXX netmask 0xfffffc00 broadcast 255.255.255.255 > media: Ethernet autoselect (100baseTX ) > status: active > [...] > wlan0: flags=8843 metric 0 mtu 1500 > ether 00:1f:1f:3f:76:f3 > inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: running > ssid FreeBSD_AP channel 7 (2442 Mhz 11g) bssid 00:1f:1f:3f:76:f3 > country US authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit > txpower 0 scanvalid 60 protmode CTS dtimperiod 1 -dfs First and foremost: is the problem specific to Samba? Can you reproduce the problem when using the FTP protocol? Are there any indications of problems in "dmesg" when the issue is happening? Can you provide output from "vmstat -i" while the problem is happening? Can you provide output from "pciconf -lvc"? Only interested in the sections relevant to the above devices. Can you provide contents of /etc/make.conf, /etc/sysctl.conf, and /boot/loader.conf? Have you looked at "netstat -I -indb" output during the slow transfers to see if there's any indication of problems, or some sort of "common rate" (transfer, etc.) Does disabling the firewalling stack improve things at all? Can the slowness be reproduced using benchmarks/netperf or only when using something that involves actual disk I/O? (To use netperf you'll need two FreeBSD boxes). If only disk I/O, then ZFS analysis might be needed (there are some performance adjustments that are often required). Focusing more on em0: Have you tried disabling rxcsum and txcsum (using ifconfig) to see if there's any improvement? I don't see TSO used by your interface, so that should rule out any problems with that feature. -- | Jeremy Chadwick jdc@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 Mon Jul 5 16:10:21 2010 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 16028106564A for ; Mon, 5 Jul 2010 16:10:21 +0000 (UTC) (envelope-from mike.jakubik@intertainservices.com) Received: from mail.intertainservices.com (mail.intertainservices.com [38.99.187.35]) by mx1.freebsd.org (Postfix) with ESMTP id DF1968FC15 for ; Mon, 5 Jul 2010 16:10:20 +0000 (UTC) Received: from [172.16.10.199] (unknown [172.16.10.199]) by mail.intertainservices.com (Postfix) with ESMTPA id 4F1C056C49 for ; Mon, 5 Jul 2010 12:10:18 -0400 (EDT) Message-ID: <4C3203E9.7000908@intertainservices.com> Date: Mon, 05 Jul 2010 12:10:17 -0400 From: Mike Jakubik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-intertainservices-MailScanner-Information: Please contact the ISP for more information X-intertainservices-MailScanner-ID: 4F1C056C49.AE9D3 X-intertainservices-MailScanner: Found to be clean X-intertainservices-MailScanner-From: mike.jakubik@intertainservices.com X-Spam-Status: No Subject: Re: 8.0 network 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, 05 Jul 2010 16:10:21 -0000 On 7/4/2010 8:52 PM, David Warren wrote: > Hi all, > > I've got a persistent problem with my LAN. I'm running a FreeBSD 8.0 > box as a home server performing the following functions for wired and > wireless networks: router; firewall; DHCP server; and file server. For what > it's worth, I've got ZFS up and running as the main filesystem. The > recurring issue is that file transfers from the FreeBSD box to computers on > the wired network (gigabit) start out fast and then become agonizingly > slow. I'm sharing home directories over Samba, and those transfers work > briefly and then tail off to a few kilobytes per second. The failure is > I remember having a simmilar issue, back in the early 7.x days. Try the following tunnables. net.inet.tcp.hostcache.expire=1 net.inet.tcp.inflight.enable=0 Thanks. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 5 18:50:29 2010 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 523B41065670 for ; Mon, 5 Jul 2010 18:50:29 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by mx1.freebsd.org (Postfix) with ESMTP id CBAE78FC17 for ; Mon, 5 Jul 2010 18:50:26 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 168F3D4809A; Mon, 5 Jul 2010 20:50:20 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id 016C733DC6; Mon, 5 Jul 2010 18:50:19 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id E0453A10F5; Mon, 5 Jul 2010 18:50:19 +0000 (UTC) Date: Mon, 5 Jul 2010 20:50:19 +0200 From: Jeremie Le Hen To: ed@FreeBSD.org Message-ID: <20100705185019.GB6194@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@FreeBSD.org Subject: Panic in destroy_dev_sched_cb() for tty 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, 05 Jul 2010 18:50:29 -0000 Hi Ed, I've got a panic obviously from the tty layer but I couldn't get the panic string as no remote system was connected using serial console, and I don't know how to print it from DDB. However here is the relevant stuff I could get: db> show pcpu cpuid = 0 dynamic pcpu = 0x5a0600 curthread = 0x87cae240: pid 7701 "screen" curpcb = 0xcb1ebd90 fpcurthread = none idlethread = 0x85544900: pid 11 "idle: cpu0" APIC ID = 0 currentldt = 0x50 db> trace Tracing pid 7701 tid 100302 td 0x87cae240 destroy_dev_sched_cb(0,807137fb,9eff1200,9eff1254) at destroy_dev_sched_cb+0x10 tty_rel_free(9eff1290,0,1,0) at tty_rel_free+0xc7 ttydev_leave(9eff1290,0,0,0,0,...) at ttydev_leave+0x136 ttydev_close(9c756d00,7,2000,87cae240,cb1ebb14,...) at ttydev_close+0xf4 devfs_close(cb1ebb2c,cb1ebb50,80760b10,80a48120,cb1ebb2c,...) at devfs_close+0x3ae VOP_CLOSE_APV(80a48120,cb1ebb2c,809d7133,128,80a84000,...) at VOP_CLOSE_APV+0x44 vn_close(87cee648,7,8a965780,87cae240,80a84300,...) at vn_close+0xd1 vn_closefile(8788f658,87cae240,8788f658,0,cb1ebbe0,...) at vn_closefile+0xfe devfs_close_f(8788f658,87cae240,cb1ebc18,0,1,...) at devfs_close_f+0x27 _fdrop(8788f658,87cae240,8a965780,87cae240,865b7310,...) at _fdrop+0x43 closef(8788f658,87cae240,900fed48,2,876511d0,...) at closef+0x31b kern_close(87cae240,4,cb1ebd2c,8096147c,87cae240,...) at kern_close+0x16d close(87cae240,cb1ebcf8,4,c,c,...) at close+0x1a syscall(cb1ebd38) at syscall+0x320 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x2821b63f, esp = 0x7fbfe1bc, ebp = 0x7fbfe1c8 --- The system is running 8.0-STABLE from around 2009/12/06. Thanks. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche From owner-freebsd-stable@FreeBSD.ORG Mon Jul 5 20:43:01 2010 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 14C0B106564A for ; Mon, 5 Jul 2010 20:43:01 +0000 (UTC) (envelope-from tundra@tundraware.com) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) by mx1.freebsd.org (Postfix) with ESMTP id AFA128FC0A for ; Mon, 5 Jul 2010 20:43:00 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.4/8.14.4) with ESMTP id o65KTUwk018667 (version=TLSv1/SSLv3 cipher=DHE-DSS-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 5 Jul 2010 15:29:30 -0500 (CDT) (envelope-from tundra@tundraware.com) Message-ID: <4C3240A9.9020603@tundraware.com> Date: Mon, 05 Jul 2010 15:29:29 -0500 From: Tim Daneliuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (ozzie.tundraware.com [75.145.138.73]); Mon, 05 Jul 2010 15:29:30 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: o65KTUwk018667 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No Subject: 8.1-PRE Throwing Traps Going Multiuser 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, 05 Jul 2010 20:43:01 -0000 Is this a known problem (I've submitted a PR just in case it is not)? I am seeing this consistently when I try to do a build/installworld/kernel with daily sources from the master tree: http://www.mediafire.com/imageview.php?quickkey=qmhizdtnhyo&thumb=4 The system boots fine single-user. Problem is repeatable with both my kernel AND GENERIC. (My config file at end of this msg.) Attempting to enter multi-user causes the problem. This occurs whether or not anything is enabled in /etc/rc.conf. Falling back to my 6-18-2010 system image makes everything right again. MOBO is an Intel D946GZIS with a single SATA drive and one additional 3Com 3c905 NIC in addition to the onboard Intel NIC. My Kernel Config ============================================================= include GENERIC ident MACHINENAME options IPFIREWALL options IPDIVERT options VESA # System console options options SC_DISABLE_REBOOT # disable reboot key sequence options SC_HISTORY_SIZE=200 # number of history buffer lines options SC_PIXEL_MODE # add support for the raster text mode # The following options will change the default colors of syscons. options SC_NORM_ATTR="(FG_GREEN|BG_BLACK)" options SC_NORM_REV_ATTR="(FG_YELLOW|BG_GREEN)" options SC_KERNEL_CONS_ATTR="(FG_RED|BG_BLACK)" options SC_KERNEL_CONS_REV_ATTR="(FG_BLACK|BG_RED)" -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/ From owner-freebsd-stable@FreeBSD.ORG Mon Jul 5 21:10:26 2010 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 A2E9B1065686 for ; Mon, 5 Jul 2010 21:10:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 4015B8FC08 for ; Mon, 5 Jul 2010 21:10:25 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o65LALCT078346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jul 2010 00:10:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o65LAL88075799; Tue, 6 Jul 2010 00:10:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o65LALK7075798; Tue, 6 Jul 2010 00:10:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 6 Jul 2010 00:10:21 +0300 From: Kostik Belousov To: Tim Daneliuk Message-ID: <20100705211021.GV13238@deviant.kiev.zoral.com.ua> References: <4C3240A9.9020603@tundraware.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wuuVUd7pnaKXXwQq" Content-Disposition: inline In-Reply-To: <4C3240A9.9020603@tundraware.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: 8.1-PRE Throwing Traps Going Multiuser 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, 05 Jul 2010 21:10:26 -0000 --wuuVUd7pnaKXXwQq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 05, 2010 at 03:29:29PM -0500, Tim Daneliuk wrote: > Is this a known problem (I've submitted a PR just in case it is not)? >=20 > I am seeing this consistently when I try to do a build/installworld/kerne= l=20 > with daily sources from the master tree: >=20 > http://www.mediafire.com/imageview.php?quickkey=3Dqmhizdtnhyo&thumb=3D4 >=20 > The system boots fine single-user. Problem is repeatable with both > my kernel AND GENERIC. (My config file at end of this msg.) >=20 > Attempting to enter multi-user causes the problem. This > occurs whether or not anything is enabled in /etc/rc.conf. >=20 > Falling back to my 6-18-2010 system image makes everything right again. >=20 > MOBO is an Intel D946GZIS with a single SATA drive and one additional > 3Com 3c905 NIC in addition to the onboard Intel NIC. >=20 >=20 > My Kernel Config > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > include GENERIC >=20 > ident MACHINENAME >=20 > options IPFIREWALL > options IPDIVERT >=20 > options VESA >=20 > # System console options >=20 > options SC_DISABLE_REBOOT # disable reboot key sequence > options SC_HISTORY_SIZE=3D200 # number of history buffer lines > options SC_PIXEL_MODE # add support for the raster text= mode >=20 > # The following options will change the default colors of syscons. >=20 > options SC_NORM_ATTR=3D"(FG_GREEN|BG_BLACK)" > options SC_NORM_REV_ATTR=3D"(FG_YELLOW|BG_GREEN)" > options SC_KERNEL_CONS_ATTR=3D"(FG_RED|BG_BLACK)" > options SC_KERNEL_CONS_REV_ATTR=3D"(FG_BLACK|BG_RED)" Add DDB to your kernel, or specify the dump device. Then obtain a backtrace for the trap. --wuuVUd7pnaKXXwQq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwySjwACgkQC3+MBN1Mb4ho3QCguYSVGqJz3adDUIDF4d+0+goD zhwAoL9ZFJ7/OM4LEn5PZ+KilpKSoXRk =z/da -----END PGP SIGNATURE----- --wuuVUd7pnaKXXwQq-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 5 22:49:48 2010 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 D6F8B106564A for ; Mon, 5 Jul 2010 22:49:48 +0000 (UTC) (envelope-from davideugenewarren@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 694978FC17 for ; Mon, 5 Jul 2010 22:49:48 +0000 (UTC) Received: by vws6 with SMTP id 6so6820810vws.13 for ; Mon, 05 Jul 2010 15:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=z+SJ+X8Y57LsLLTs3O9oPv/9MRTyvJuECrDCqqenBL8=; b=AVBnba1jNWKdTgFQrqcct+2ePKsElnDcLJxraseGaMOPHCDUoj5uhgv+Jxkc9alpRo yQk7D/neT8OzI1EC8uvogmnd4bwe8tOk0oAU8rlz7iiCSqdRWmTDp9KNiexbk6+8YW8d BeFdE3zQ241bwC77uhYW5ZNsXyEUNpDzLfsBg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Y2LZRpnOKjTO3SawQCyy469N9YUaVFOTCygUwNHRxFPIsN6AaNr2wCtCKoWSzc8pcK SmOAh0SRTh7cnUQ97VCgzfQxBhg+RjGOr67E4yIyRYo6Ow4InmuEt+8hInP1jiSDmfyh rtNS86ApnFJzuBIZCGGF9Bg8QAnISgoOw6DBY= MIME-Version: 1.0 Received: by 10.220.48.90 with SMTP id q26mr1914394vcf.228.1278370178434; Mon, 05 Jul 2010 15:49:38 -0700 (PDT) Received: by 10.220.190.1 with HTTP; Mon, 5 Jul 2010 15:49:38 -0700 (PDT) In-Reply-To: <20100705055105.GA21681@icarus.home.lan> References: <20100705055105.GA21681@icarus.home.lan> Date: Mon, 5 Jul 2010 17:49:38 -0500 Message-ID: From: David Warren To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: 8.0 network 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, 05 Jul 2010 22:49:48 -0000 Hi all, As several people have noted, I should have been more specific about the problem. As far as I can tell, it's limited to the wired portion of my network involving the em0 interface. Samba and scp transfers to and from computers on the ral0 interface seem unaffected. Even at the relatively slow speeds of wireless, those transfers are substantially faster than the degraded speeds I'm seeing on the wired network. I should also have noted that the main computer on the wired network is a Windows box, while I use the wireless with my MacBook. I'm using pf for my firewall on the FreeBSD box, and having tried a bunch of the suggested tests I'm thinking that's the most likely culprit. I'm going to try a few things out to test that idea. However, for completeness, here's are the results of the various tests and diagnostics that were requested. My pciconf output: > pciconf -lvc nfe0@pci0:0:20:0: class=0x068000 card=0x816a1043 chip=0x026910de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Ethernet Controller (2A34103C)' class = bridge cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 em0@pci0:4:8:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction ral0@pci0:4:9:0: class=0x028000 card=0x71281432 chip=0x03011814 rev=0x00 hdr=0x00 vendor = 'Ralink Technology, Corp' device = 'Edimax 54 MBit WLan 802.11g rt 2500 (b8341462)' class = network cap 01[40] = powerspec 2 supports D0 D3 current D0 dmesg isn't reporting anything new when this happens. Disabling rxcsum and txcsum doesn't seem to have an effect. Here's a quick overview of what I've tried: pscp works from .13 to .1 (pscp because I'm using key-based identification). samba fast then slow from .1 to .13 samba fast then slow from .13 to .1 netcat fast then slow from .13 to .1 netcat not working from .1 to .13 (I need to figure out how to get netcat input into the Windows box on .13) While the problem was evident, I collected the following netstat: > netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em0 1500 00:0e:0c:b7:71:44 4840841 0 3791658 0 0 em0 1500 192.168.0.0 192.168.0.1 5496050 - 3687095 - - ral0 2290 00:1f:1f:3f:76:f3 0 0 965271 1156 0 nfe0 1500 00:01:29:d4:2d:6b 349488 0 83833 0 0 nfe0 1500 173.19.224.0/ 173-19-224-254.cl 3260 - 7725 - - plip0 1500 0 0 0 0 0 lo0 16384 758 0 758 0 0 lo0 16384 fe80:5::1 fe80:5::1 0 - 0 - - lo0 16384 localhost ::1 0 - 0 - - lo0 16384 your-net localhost 74 - 758 - - wlan0 1500 00:1f:1f:3f:76:f3 873552 64 950672 7 0 wlan0 1500 192.168.1.0 192.168.1.1 142745 - 937938 - - pflog 33152 0 0 242 0 0 which appears to be free of errors for em0. I also got the following vmstat -i: > vmstat -i interrupt total rate irq1: atkbd0 8 0 irq6: fdc0 7 0 irq15: ata1 144 0 irq16: em0 2456436 52 irq17: ral0 3782116 80 irq20: atapci2 217325 4 irq21: hdac0 ohci0 11 0 irq22: nfe0 ehci0 436597 9 irq23: atapci1 206722 4 cpu0: timer 94022466 2000 cpu1: timer 94022098 2000 Total 195143930 4151 And the following netstat: > sudo netstat -I em0 -indb Name Mtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll Drop em0 1500 00:0e:0c:b7:71:44 5023101 0 3770654334 3978181 0 925661555 0 0 em0 1500 192.168.0.0/2 192.168.0.1 5677843 - 4600314279 3873061 - 739695560 - - After starting a netcat transfer from .13 to .1, .13's system monitor indicates that transfer over the local (outbound) interface starts out very fast for a few seconds and then bottoms out. This iostat captures the same pattern. ad4, ad6, ad8, and ad10 are the four disks sharing the base system (geom mirror) and ZFS bulk filesystem. > iostat -n 5 -w 1 -c 30 tty ad4 ad6 ad8 ad10 da0 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 1 237 27.06 2 0.06 27.06 2 0.06 27.84 2 0.07 28.29 2 0.06 61.23 0 0.03 0 0 1 0 99 0 671 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 7 0 93 0 224 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 2 0 70 0 29 0 224 0.00 0 0.00 0.00 0 0.00 64.00 1 0.06 0.00 0 0.00 0.00 0 0.00 2 0 63 0 36 0 224 64.00 1 0.06 0.00 0 0.00 0.00 0 0.00 64.00 1 0.06 0.00 0 0.00 2 0 57 0 41 0 224 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 3 0 55 0 42 0 224 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 2 0 51 0 48 0 224 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 5 0 50 0 45 0 224 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 4 0 57 0 39 0 224 0.50 14 0.01 0.50 15 0.01 0.50 29 0.01 0.00 0 0.00 0.00 0 0.00 1 0 4 0 95 0 224 1.23 87 0.10 0.50 84 0.04 0.50 158 0.08 0.50 5 0.00 0.00 0 0.00 2 0 7 0 91 0 224 3.18 84 0.26 3.03 89 0.26 1.64 160 0.26 18.33 15 0.27 0.00 0 0.00 2 0 12 1 85 0 224 42.66 1167 48.63 42.70 1198 49.97 42.69 1870 77.96 42.66 1238 51.59 0.00 0 0.00 0 0 46 3 51 0 232 37.66 798 29.36 38.95 737 28.01 1.60 99 0.15 38.41 703 26.35 0.00 0 0.00 1 0 20 1 78 0 224 59.19 13 0.75 58.79 12 0.69 64.00 17 1.06 59.23 13 0.75 0.00 0 0.00 4 0 13 0 82 0 224 45.14 11 0.48 40.94 9 0.36 49.18 14 0.67 46.71 12 0.55 0.00 0 0.00 3 0 17 0 79 0 224 64.00 15 0.94 64.00 20 1.25 64.00 27 1.68 64.00 13 0.81 0.00 0 0.00 1 0 13 0 85 0 224 64.00 18 1.12 64.00 16 1.00 64.00 27 1.68 64.00 14 0.87 0.00 0 0.00 3 0 13 0 84 0 224 64.00 14 0.87 64.00 13 0.81 64.00 21 1.31 64.00 16 1.00 0.00 0 0.00 3 0 6 0 91 0 224 64.00 11 0.69 64.00 16 1.00 64.00 20 1.25 64.00 14 0.87 0.00 0 0.00 2 0 11 0 86 0 224 59.77 15 0.87 56.94 9 0.50 60.83 20 1.19 59.77 15 0.87 0.00 0 0.00 2 0 11 0 87 0 224 64.00 12 0.75 64.00 9 0.56 64.00 15 0.94 64.00 9 0.56 0.00 0 0.00 2 0 14 0 83 0 671 64.00 8 0.50 64.00 8 0.50 64.00 15 0.94 64.00 8 0.50 0.00 0 0.00 2 0 13 0 84 0 224 64.00 12 0.75 64.00 13 0.81 64.00 28 1.75 64.00 14 0.87 0.00 0 0.00 3 0 12 0 85 0 224 64.00 15 0.94 64.00 15 0.94 64.00 26 1.62 64.00 13 0.81 0.00 0 0.00 2 0 12 0 85 0 224 59.42 18 1.04 61.38 8 0.48 59.85 20 1.17 57.04 12 0.67 0.00 0 0.00 3 0 10 0 87 0 224 64.00 16 1.00 64.00 15 0.94 64.00 22 1.37 64.00 14 0.87 0.00 0 0.00 1 0 10 0 89 0 224 64.00 14 0.87 64.00 9 0.56 64.00 28 1.75 64.00 15 0.94 0.00 0 0.00 4 0 10 0 86 0 224 64.00 11 0.69 64.00 6 0.37 64.00 23 1.43 64.00 10 0.62 0.00 0 0.00 2 0 9 0 89 0 224 64.00 11 0.69 64.00 8 0.50 64.00 20 1.25 64.00 11 0.69 0.00 0 0.00 2 0 12 0 86 Here's the iostat output during the transfer of a file from the ZFS volume to an external HDD (da0): > iostat -n 5 -w 1 -c 30 tty ad4 ad6 ad8 ad10 da0 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 1 241 29.20 3 0.08 29.21 3 0.08 30.03 3 0.09 30.35 3 0.08 61.97 1 0.06 0 0 1 0 99 10 2167 64.00 2 0.12 0.00 0 0.00 64.00 1 0.06 0.00 0 0.00 0.00 0 0.00 1 0 7 0 92 0 224 0.00 0 0.00 64.00 2 0.12 0.00 0 0.00 64.00 3 0.19 0.00 0 0.00 2 0 13 0 85 12 961 44.45 144 6.24 43.24 150 6.32 42.81 152 6.34 45.06 143 6.28 62.21 382 23.22 2 0 19 1 78 0 335 45.67 163 7.26 43.89 174 7.44 43.28 175 7.38 46.06 170 7.63 63.07 453 27.91 3 0 32 1 64 0 335 32.70 209 6.66 32.09 213 6.66 32.66 221 7.03 32.85 211 6.75 63.10 398 24.53 6 0 24 2 68 0 335 45.22 167 7.36 43.16 172 7.23 45.68 170 7.57 43.88 176 7.53 63.08 457 28.15 4 0 38 1 57 0 335 45.25 157 6.93 43.95 166 7.11 45.94 163 7.30 43.69 167 7.11 62.88 433 26.61 4 0 35 1 60 0 335 44.04 171 7.34 45.36 174 7.69 46.46 169 7.65 43.66 172 7.32 63.09 462 28.47 2 0 36 3 60 0 335 43.38 179 7.57 44.68 170 7.40 45.68 170 7.57 43.39 178 7.53 63.08 455 28.03 3 0 44 1 52 0 335 43.53 173 7.34 45.01 164 7.19 44.18 169 7.28 44.73 165 7.19 63.10 465 28.66 1 0 24 4 70 0 335 43.26 178 7.50 45.27 172 7.59 43.85 181 7.73 45.40 172 7.61 62.98 468 28.78 7 0 37 1 55 0 335 45.18 170 7.49 44.54 171 7.42 44.66 182 7.92 45.71 175 7.80 62.94 455 27.97 2 0 30 2 66 0 335 44.25 171 7.38 44.52 169 7.33 45.94 174 7.79 43.35 178 7.52 63.07 449 27.66 3 0 37 1 59 0 335 45.77 165 7.36 43.42 171 7.24 45.62 166 7.38 43.86 179 7.65 63.08 458 28.22 4 0 36 1 59 0 349 46.11 99 4.45 43.89 105 4.49 47.30 106 4.89 44.82 109 4.76 63.17 287 17.73 3 0 35 1 61 0 335 64.00 5 0.31 64.00 9 0.56 64.00 8 0.50 64.00 7 0.44 0.00 0 0.00 3 0 29 0 69 0 335 64.00 10 0.62 64.00 3 0.19 64.00 15 0.94 64.00 12 0.75 0.00 0 0.00 3 0 22 0 75 0 335 64.00 2 0.12 64.00 4 0.25 64.00 6 0.37 64.00 6 0.37 0.00 0 0.00 6 0 30 0 64 0 335 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 64.00 1 0.06 0.00 0 0.00 4 0 36 0 60 0 335 64.00 2 0.12 64.00 4 0.25 64.00 10 0.62 64.00 6 0.37 0.00 0 0.00 4 0 20 0 75 and from the external HDD to the ZFS pool: > iostat -n 5 -w 1 -c 40 tty ad4 ad6 ad8 ad10 da0 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 1 241 28.86 3 0.07 28.87 3 0.07 29.70 3 0.08 30.03 3 0.08 61.79 1 0.05 0 0 1 0 99 16 2391 64.00 6 0.37 64.00 7 0.44 64.00 8 0.50 64.00 6 0.37 0.00 0 0.00 2 0 14 0 84 8 277 64.00 2 0.12 0.00 0 0.00 64.00 3 0.19 64.00 2 0.12 58.15 13 0.74 6 0 17 0 76 10 957 30.35 139 4.11 31.93 138 4.29 32.62 141 4.48 32.65 138 4.39 63.03 246 15.17 2 0 13 2 84 0 335 7.17 29 0.20 4.82 31 0.15 10.24 33 0.33 11.64 33 0.37 63.04 248 15.30 2 0 30 0 67 0 335 64.00 7 0.44 64.00 5 0.31 64.00 10 0.62 64.00 8 0.50 63.04 249 15.30 5 0 23 0 72 0 335 43.29 317 13.42 43.22 316 13.35 43.47 323 13.73 43.34 321 13.60 63.00 241 14.80 2 0 31 2 65 0 335 64.00 4 0.25 58.79 12 0.69 58.79 12 0.69 58.79 12 0.69 63.04 250 15.36 5 0 27 0 68 0 335 64.00 5 0.31 64.00 5 0.31 64.00 11 0.69 64.00 8 0.50 63.04 249 15.30 3 0 28 0 69 0 335 64.00 13 0.81 64.00 4 0.25 64.00 14 0.87 64.00 11 0.69 63.27 248 15.29 3 0 24 0 73 0 335 64.00 2 0.12 53.58 6 0.31 55.00 7 0.38 55.00 7 0.38 62.78 250 15.30 6 0 26 0 68 0 335 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 63.04 248 15.30 6 0 29 0 64 0 335 64.00 2 0.12 64.00 2 0.12 64.00 2 0.12 64.00 1 0.06 63.04 250 15.36 6 0 23 0 71 0 335 48.38 4 0.19 64.00 4 0.25 43.00 3 0.13 48.25 4 0.19 63.04 248 15.30 3 0 32 0 65 0 335 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 63.04 250 15.36 5 0 29 0 66 0 335 64.00 1 0.06 64.00 2 0.12 64.00 4 0.25 64.00 3 0.19 63.28 248 15.35 4 0 27 0 68 0 335 64.00 5 0.31 64.00 6 0.37 64.00 6 0.37 64.00 5 0.31 63.04 249 15.30 4 0 29 0 67 0 335 0.00 0 0.00 64.00 1 0.06 64.00 1 0.06 64.00 1 0.06 63.04 250 15.36 2 0 38 0 60 0 335 64.00 1 0.06 0.00 0 0.00 64.00 3 0.19 64.00 2 0.12 62.78 249 15.24 5 0 32 0 62 0 335 21.42 6 0.13 35.61 9 0.31 35.61 9 0.31 32.06 8 0.25 63.04 250 15.36 3 0 34 0 62 0 335 55.07 7 0.38 64.00 1 0.06 56.19 8 0.44 43.17 3 0.13 63.04 248 15.30 6 0 28 0 67 0 335 51.50 10 0.50 64.00 13 0.81 58.32 22 1.25 61.14 22 1.31 63.28 249 15.36 3 0 26 0 71 0 1006 55.91 11 0.60 54.00 15 0.79 59.32 19 1.10 56.50 20 1.10 63.04 250 15.36 4 0 27 0 69 0 335 60.25 10 0.59 61.66 16 0.96 62.46 24 1.46 62.39 23 1.40 63.04 249 15.30 1 0 27 0 72 0 335 57.65 10 0.56 57.65 10 0.56 60.26 17 1.00 60.03 16 0.94 63.04 250 15.36 3 0 24 0 73 0 335 64.00 8 0.50 64.00 7 0.44 64.00 14 0.87 64.00 16 1.00 63.04 249 15.30 3 0 29 0 68 0 335 64.00 10 0.62 64.00 8 0.50 64.00 16 1.00 64.00 15 0.94 62.78 249 15.30 1 0 29 0 70 0 335 64.00 6 0.37 64.00 14 0.87 64.00 21 1.31 64.00 20 1.25 63.28 248 15.35 3 0 25 0 72 0 335 64.00 10 0.62 64.00 8 0.50 64.00 17 1.06 64.00 17 1.06 63.04 250 15.36 1 0 27 0 71 0 335 64.00 9 0.56 64.00 13 0.81 64.00 23 1.43 64.00 22 1.37 63.04 249 15.30 4 0 24 0 71 0 335 64.00 9 0.56 64.00 11 0.69 64.00 20 1.25 64.00 21 1.31 63.04 250 15.36 2 0 25 0 72 0 419 64.00 9 0.56 64.00 7 0.44 64.00 15 0.94 64.00 13 0.81 62.68 197 12.03 3 0 23 0 74 0 335 59.54 14 0.81 64.00 3 0.19 60.32 17 1.00 64.00 18 1.12 0.00 0 0.00 4 0 25 0 71 0 335 44.50 63 2.73 45.35 75 3.31 46.15 76 3.42 44.82 69 3.01 0.00 0 0.00 4 0 48 0 48 0 335 42.74 1560 65.11 42.75 1651 68.93 42.74 2466 102.95 42.74 1634 68.20 0.00 0 0.00 1 0 53 5 40 0 350 42.69 1519 63.32 42.40 1431 59.25 41.90 623 25.48 42.24 1468 60.55 0.00 0 0.00 0 0 27 4 69 0 344 11.20 88 0.96 11.31 67 0.74 18.38 82 1.47 19.02 81 1.50 0.00 0 0.00 3 0 12 0 85 0 335 64.00 7 0.44 64.00 7 0.44 64.00 12 0.75 64.00 11 0.69 0.00 0 0.00 3 0 23 0 73 0 335 64.00 7 0.44 64.00 9 0.56 64.00 14 0.87 64.00 14 0.87 0.00 0 0.00 3 0 23 0 74 0 335 64.00 8 0.50 64.00 6 0.37 64.00 12 0.75 64.00 7 0.44 0.00 0 0.00 2 0 19 1 78 Many thanks for all the ideas, and I'll report back after a bit more testing. Dave On Mon, Jul 5, 2010 at 12:51 AM, Jeremy Chadwick wrote: > On Sun, Jul 04, 2010 at 07:52:11PM -0500, David Warren wrote: > > I've got a persistent problem with my LAN. I'm running a FreeBSD > 8.0 > > box as a home server performing the following functions for wired and > > wireless networks: router; firewall; DHCP server; and file server. For > what > > it's worth, I've got ZFS up and running as the main filesystem. The > > recurring issue is that file transfers from the FreeBSD box to computers > on > > the wired network (gigabit) start out fast and then become agonizingly > > slow. I'm sharing home directories over Samba, and those transfers work > > briefly and then tail off to a few kilobytes per second. The failure is > > somewhat predicatable in that it tends to happen once a few hundred > > megabytes have been transferred. > > Your system has 3 different network interfaces on it (em, ral, nfe), but > you don't tell us across which interface the slow transfers happen. You > also don't tell us which firewalling stack you're using (ipfw, ipfilter, > pf). Let us know. > > I'm going to make the assumption that based on your "...on the wired > network (gigabit)..." statement that the transfers are going across the > em0 interface, but again, I'm not sure. > > Relevant interfaces (wlan0 is tied to ral0): > > > em0: flags=8843 metric 0 mtu 1500 > > options=9b > > ether 00:0e:0c:b7:71:44 > > inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > > media: Ethernet autoselect (1000baseT ) > > status: active > > ral0: flags=8843 metric 0 mtu > 2290 > > ether 00:1f:1f:3f:76:f3 > > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > > status: running > > nfe0: flags=8843 metric 0 mtu > 1500 > > options=8 > > ether 00:01:29:d4:2d:6b > > inet XXX.XXX.XXX.XXX netmask 0xfffffc00 broadcast 255.255.255.255 > > media: Ethernet autoselect (100baseTX ) > > status: active > > [...] > > wlan0: flags=8843 metric 0 mtu > 1500 > > ether 00:1f:1f:3f:76:f3 > > inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 > > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > > status: running > > ssid FreeBSD_AP channel 7 (2442 Mhz 11g) bssid 00:1f:1f:3f:76:f3 > > country US authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit > > txpower 0 scanvalid 60 protmode CTS dtimperiod 1 -dfs > > First and foremost: is the problem specific to Samba? Can you reproduce > the problem when using the FTP protocol? > > Are there any indications of problems in "dmesg" when the issue is > happening? > > Can you provide output from "vmstat -i" while the problem is happening? > > Can you provide output from "pciconf -lvc"? Only interested in the > sections relevant to the above devices. > > Can you provide contents of /etc/make.conf, /etc/sysctl.conf, and > /boot/loader.conf? > > Have you looked at "netstat -I -indb" output during the slow > transfers to see if there's any indication of problems, or some sort of > "common rate" (transfer, etc.) > > Does disabling the firewalling stack improve things at all? > > Can the slowness be reproduced using benchmarks/netperf or only when > using something that involves actual disk I/O? (To use netperf you'll > need two FreeBSD boxes). If only disk I/O, then ZFS analysis might be > needed (there are some performance adjustments that are often required). > > Focusing more on em0: > > Have you tried disabling rxcsum and txcsum (using ifconfig) to see if > there's any improvement? I don't see TSO used by your interface, so > that should rule out any problems with that feature. > > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > -- Post-doctoral Fellow Neurology Department University of Iowa Hospitals and Clinics davideugenewarren@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Jul 5 22:54:37 2010 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 C736D106566B for ; Mon, 5 Jul 2010 22:54:37 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2001:4dd0:ff41::b23f:aa]) by mx1.freebsd.org (Postfix) with ESMTP id 8800B8FC16 for ; Mon, 5 Jul 2010 22:54:37 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id DED5B2A29248; Tue, 6 Jul 2010 00:54:36 +0200 (CEST) Date: Tue, 6 Jul 2010 00:54:36 +0200 From: Ed Schouten To: Jeremie Le Hen Message-ID: <20100705225436.GL2179@hoeg.nl> References: <20100705185019.GB6194@felucia.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xVNRhe5Alm/fDnuT" Content-Disposition: inline In-Reply-To: <20100705185019.GB6194@felucia.tataz.chchile.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@FreeBSD.org Subject: Re: Panic in destroy_dev_sched_cb() for tty 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, 05 Jul 2010 22:54:37 -0000 --xVNRhe5Alm/fDnuT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Jeremie Le Hen wrote: > I've got a panic obviously from the tty layer but I couldn't get the > panic string as no remote system was connected using serial console, and > I don't know how to print it from DDB. Hmmm... This is a tricky one, but I think I do understand what's going on here. If you close and revoke a TTY at the very exact moment, it may call destroy_dev_sched_cb() twice, where the second time it gets called on a null pointer. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/tty.c (revision 209570) +++ sys/kern/tty.c (working copy) @@ -1040,7 +1040,8 @@ tp->t_dev =3D NULL; tty_unlock(tp); =20 - destroy_dev_sched_cb(dev, tty_dealloc, tp); + if (dev !=3D NULL) + destroy_dev_sched_cb(dev, tty_dealloc, tp); } =20 void I guess it's very hard to reproduce, right? If so, I'll just commit it to SVN. Thanks for reporting! --=20 Ed Schouten WWW: http://80386.nl/ --xVNRhe5Alm/fDnuT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkwyYqwACgkQ52SDGA2eCwWLWACbBTNIytx9SKVXHh5rjsrSsY/k QAkAnR2I9ZCNH4pI8tAi/JViACbhKJYt =5eo1 -----END PGP SIGNATURE----- --xVNRhe5Alm/fDnuT-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 5 23:39:46 2010 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 F09F6106566B for ; Mon, 5 Jul 2010 23:39:46 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 7C2698FC12 for ; Mon, 5 Jul 2010 23:39:46 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OVvGL-0006VW-Gu for freebsd-stable@freebsd.org; Tue, 06 Jul 2010 01:39:45 +0200 Received: from cpe-24-210-63-182.columbus.res.rr.com ([24.210.63.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Jul 2010 01:39:45 +0200 Received: from dsamms by cpe-24-210-63-182.columbus.res.rr.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Jul 2010 01:39:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: David Samms Date: Mon, 05 Jul 2010 19:39:36 -0400 Lines: 47 Message-ID: References: <4C3240A9.9020603@tundraware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-24-210-63-182.columbus.res.rr.com User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100626 Thunderbird/3.0.5 In-Reply-To: <4C3240A9.9020603@tundraware.com> Subject: Re: 8.1-PRE Throwing Traps Going Multiuser 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, 05 Jul 2010 23:39:47 -0000 On 07/05/10 16:29, Tim Daneliuk wrote: > Is this a known problem (I've submitted a PR just in case it is not)? > > I am seeing this consistently when I try to do a build/installworld/kernel > with daily sources from the master tree: > > http://www.mediafire.com/imageview.php?quickkey=qmhizdtnhyo&thumb=4 > > The system boots fine single-user. Problem is repeatable with both > my kernel AND GENERIC. (My config file at end of this msg.) > > Attempting to enter multi-user causes the problem. This > occurs whether or not anything is enabled in /etc/rc.conf. > > Falling back to my 6-18-2010 system image makes everything right again. > > MOBO is an Intel D946GZIS with a single SATA drive and one additional > 3Com 3c905 NIC in addition to the onboard Intel NIC. > > > My Kernel Config > ============================================================= > > include GENERIC > > ident MACHINENAME > > options IPFIREWALL > options IPDIVERT > > options VESA > > # System console options > > options SC_DISABLE_REBOOT # disable reboot key sequence > options SC_HISTORY_SIZE=200 # number of history buffer lines > options SC_PIXEL_MODE # add support for the raster text mode > > # The following options will change the default colors of syscons. > > options SC_NORM_ATTR="(FG_GREEN|BG_BLACK)" > options SC_NORM_REV_ATTR="(FG_YELLOW|BG_GREEN)" > options SC_KERNEL_CONS_ATTR="(FG_RED|BG_BLACK)" > options SC_KERNEL_CONS_REV_ATTR="(FG_BLACK|BG_RED)" By chance do you have any modules being loaded in /boot/loader.conf. I had similar issues and it was VirtualBox needing to be recompiled. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 5 23:53:02 2010 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 5705C106566B for ; Mon, 5 Jul 2010 23:53:02 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 05F158FC08 for ; Mon, 5 Jul 2010 23:53:01 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o65Nqecv020655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Jul 2010 16:52:40 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 0CC531CC0D; Mon, 5 Jul 2010 16:52:40 -0700 (PDT) To: jhell In-reply-to: Your message of "Sun, 04 Jul 2010 13:58:30 EDT." <4C30CBC6.1030507@dataix.net> Date: Mon, 05 Jul 2010 16:52:40 -0700 From: "Kevin Oberman" Message-Id: <20100705235240.0CC531CC0D@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-05_06:2010-02-06, 2010-07-05, 2010-07-05 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1007050131 Cc: stable@freebsd.org Subject: Re: Odd behavior of labels on different filesystem types 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, 05 Jul 2010 23:53:02 -0000 > Sender: "J. Hellenthal" > Date: Sun, 04 Jul 2010 13:58:30 -0400 > From: jhell > > On 07/04/2010 12:15, Kevin Oberman wrote: > >> Sender: "J. Hellenthal" > >> Date: Sun, 04 Jul 2010 01:55:20 -0400 > >> From: jhell > >> > >> On 07/03/2010 16:51, Kevin Oberman wrote: > >>> I have run into an odd behavior in 8-stable that I can't see a reason > >>> for. > >>> > >>> If I have a FAT32 formatted removable drive, I get /dev entries for it > >>> as both /dev/msdosfs/LABEL and /dev/ufsid/ID. When I mount the > >>> filesystem, the /dev/ufsid label is removed, but the other two remain. > >>> > >>> If I have a UFS filesystem on the disk, I have similar devices except > >>> that the LABEL is /dev/ufs/LABEL. But, when the UFS device is mounted, > >>> the /dev/ufsid/ID AND the /dev/ufs/LABEL devs are both deleted. > >>> > >>> I'm not sure which is "right", but I can't see the reason for the > >>> different behavior and it has caused a fair bit of trouble when working > >>> with gnome-mount as I can't unmount a ufs device. When the > >>> /dev/ufs/LABEL device is created again on the umount, gnome-mount sees a > >>> new device and immediately re-mounts it. > >>> > >>> Can this inconsistency be corrected? > >> > >> Can you try to zero out that disk first i.e. > >> dd if=/dev/zero of=/dev/DISK bs=4m > >> > >> Then format your msdos fat part and relabel it. You should not see a > >> dev/ufsid/ label for this anymore. I believe that for some reason the > >> ufsid metadata or whatever you want to call it some how has been left > >> behind and is still being read for whatever reason and can be confirmed > >> by this. > >> > >> As for /dev/ufs/LABEL /dev/ufsid/ID /dev/device when you mount one the > >> others should disapear so this is correct behavior. > > > > Thanks for the suggestion. I will try a device which has never had a UFS > > file system and see if the ufsid device is created. Looks like the > > former is an issue with geom tasting and it would be nice to get it > > fixed, but it is not what is causing my problem. It is the latter issue > > that causes the problems with gnome-mount. > > > > The real issue for me is that /dev/ufs/LABEL is removed on a mount while > > /dev/msdosfs/LABEL remains. hald easily works around ufsid by ignoring > > it, but the /dev/FS/LABEL has to be acted upon differently depending on > > which filesystem is involved. > > Do you use those labels for anything ? if not, I worked around this > while I used gnome for a period with devfs.rules(5) example follows. > > rc.conf(5) add devfs_system_ruleset="your_system" > > [your_system=10] > add path 'ufsid' hide > add path 'msdosfs' hide > add path 'ufs' hide > add path 'iso9660' hide > add path 'reiserfs' hide > add path 'ntfs' hide > add path 'ext2fs' hide > add path 'gpt' hide > > And you can do the same for the actual devices that you use a label for, > so mounting devices like daN can just be done from /dev/label/LABEL. > > add path 'da0' hide # Do this only after it is labeled. > add path 'label/DA0LABEL' mode 0600 user jhell group jhell > > With a little toying of the above you should get the desired effect you > want in gnome. I do find it frustrating having to resort to using only > generic labels for situations like this and believe firmly that the > generic label should take precedence over all labels except gpt & ufsid > and result in the other name-brand labels disappearing not causing this > frustration to happen. Having the multiple layers of labels available > IMO is cause for confusion. > > Final note before I stretch this out like the Armstrong figurine ;), > there was a case where I was using the module instead of having > GEOM_LABEL option built into the kernel, this being loaded after the > machine was already booted caused some strange results with the labels > that I know of on 7.2-STABLE. I don't know if this still exists but the > result from that was multiple labels still being available under /dev > while its counterpart label was mounted. That caused Gnome/hald to get > pretty confused. Thanks. It worked...and it didn't help. Something else in Gnome2.30 is triggering this, I guess. The disk now mounts as /dev/da0s1d, just like it should, but it is still re-mounting as soon as I unmount it. This is a problem for ufs disks, but not for FAT. Since most people are probably using this for mounting thumb drives which are almost always FAT, I guess it has not been seen too much. Guess it's time to take this to the gnome list. Thanks again. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Tue Jul 6 03:57:52 2010 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 A6EC21065673 for ; Tue, 6 Jul 2010 03:57:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5A01A8FC0C for ; Tue, 6 Jul 2010 03:57:52 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC5GMkyDaFvG/2dsb2JhbACfenG/FIUlBA X-IronPort-AV: E=Sophos;i="4.53,544,1272859200"; d="scan'208";a="83062330" Received: from amazon.cs.uoguelph.ca ([131.104.91.198]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 05 Jul 2010 23:57:48 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 95A69350170 for ; Mon, 5 Jul 2010 23:57:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at amazon.cs.uoguelph.ca Received: from amazon.cs.uoguelph.ca ([127.0.0.1]) by localhost (amazon.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB7m1NpdyUEJ for ; Mon, 5 Jul 2010 23:57:49 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 9B45235016A for ; Mon, 5 Jul 2010 23:57:49 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o663cTX09083; Mon, 5 Jul 2010 23:38:31 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 5 Jul 2010 23:38:29 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: "Rick C. Petty" In-Reply-To: <20100627221607.GA31646@kay.kiwi-computer.com> Message-ID: References: <20100627221607.GA31646@kay.kiwi-computer.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? 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, 06 Jul 2010 03:57:52 -0000 On Sun, 27 Jun 2010, Rick C. Petty wrote: > First off, many thanks to Rick Macklem for making NFSv4 possible in > FreeBSD! > > I recently updated my NFS server and clients to v4, but have since noticed > significant performance penalties. For instance, when I try "ls a b c" (if > a, b, and c are empty directories) on the client, it takes up to 1.87 > seconds (wall time) whereas before it always finished in under 0.1 seconds. > If I repeat the test, it takes the same amount of time in v4 (in v3, wall > time was always under 0.01 seconds for subsequent requests, as if the > directory listing was cached). > > If I try to play an h264 video file on the filesystem using mplayer, it > often jitters and skipping around in time introduces up to a second or so > pause. With NFSv3 it behaved more like the file was on local disk (no > noticable pauses or jitters). > I just came across a case where things get really slow during testing of some experimental caching stuff. (It was caused by the experimental stuff not in head, but...) It turns out that if numvnodes > desiredvnodes, it sleeps for 1sec before allocating a new vnode. This might explain your approx. 1sec delays. When this happens, "ps axlH" will probably show a process sleeping on "vlruwk" and desiredvnodes can be increased by setting a larger value for kern.maxvnodes. (numvnodes can be seen as vfs.numvnodes) I don't think there is actually a vnode leak, but you might find that the experimental nfs subsystem is a vnode hog. rick From owner-freebsd-stable@FreeBSD.ORG Tue Jul 6 06:06:34 2010 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 6D605106564A for ; Tue, 6 Jul 2010 06:06:34 +0000 (UTC) (envelope-from davideugenewarren@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D1BD68FC08 for ; Tue, 6 Jul 2010 06:06:33 +0000 (UTC) Received: by vws6 with SMTP id 6so7276233vws.13 for ; Mon, 05 Jul 2010 23:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=OUsA5h5ca4+dpWTI7WV/xsDamBkkqLSvocxbivFb/2s=; b=K1rbxFHCuX26k0bqEBdWXXLU9kgPXb/+I+HvIsZtYb9TqM5ifsRntPIVEDdUi5jooP WKAWuMvDuXK08jRTNgoY9n1VIESA4vST2q5ZbzVfdtfzSAqyKnkiuJ7KUZEU5mQhHBYq 8z7jmKAx1LRIjylqEtX6ccbFzbwBPtZR+z9Fo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=kRxo+v4bVAx38n3eBNdEUVuOU/ghW0bBJcFjtVEoOeRRI/fPTDAr/D32tcsIYFL1do nu5aEysfB3H05IZHsPehFqrnUrRGlnYP5GDOhC0n+NoklouCCy7QTpkAW7R4Za7R1OFF oxiS0ggtv2dDRGS0dtKsxHXPBwLV+E+JKxKSg= MIME-Version: 1.0 Received: by 10.220.157.139 with SMTP id b11mr2167738vcx.180.1278396385485; Mon, 05 Jul 2010 23:06:25 -0700 (PDT) Received: by 10.220.190.1 with HTTP; Mon, 5 Jul 2010 23:06:25 -0700 (PDT) In-Reply-To: References: <20100705055105.GA21681@icarus.home.lan> Date: Tue, 6 Jul 2010 01:06:25 -0500 Message-ID: From: David Warren To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: 8.0 network 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: Tue, 06 Jul 2010 06:06:34 -0000 Hi again, Disabling pf definitely makes samba file transfers move faster (the speed varies quite a bit, but everything's faster than the single kilobytes per second I was seeing previously), but I'm perplexed about what's causing the slowdown. There's certainly some cruft in my pf.conf (below), but I'm not sure what might be strangling my LAN. Can anyone set me straight? /etc/pf.conf: # macros int_if = "em0" wifi_if = "wlan0" ext_if = "nfe0" nat_opt = "192.168.0.5" # Windows box nat_cu = "192.168.0.1" # server tcp_services = "{ 22 }" icmp_types = "echoreq" priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }" # options set block-policy return set loginterface $ext_if set skip on lo # scrub scrub in # nat/rdr nat on $ext_if from !($ext_if) -> ($ext_if:0) nat on $ext_if from $wifi_if:network to any -> ($ext_if) rdr on $ext_if proto tcp from any to any port 22 -> $nat_cu rdr on $ext_if proto tcp from any to any port 6881:6999 -> $nat_opt rdr on $ext_if proto tcp from any to any port 34567:34575 -> $nat_cu rdr on $ext_if proto tcp from any to any port 993 -> $nat_opt # filter rules block in log pass out keep state antispoof quick for { lo $int_if } pass in on $ext_if inet proto tcp from any to ($ext_if) port $tcp_services flags S/SA keep state block drop in quick on $ext_if from $priv_nets to any block drop out quick on $ext_if from any to $priv_nets pass in inet proto icmp all icmp-type $icmp_types keep state #pass in on $int_if from $int_if:network to any keep state #pass out on $int_if from any to $int_if:network keep state #pass in on $wifi_if from $wifi_if:network to any keep state #pass out on $wifi_if from any to $wifi_if:network keep state pass in on $ext_if inet proto tcp from any to $nat_cu port $tcp_services flags S/SA synproxy state pass in on $ext_if inet proto tcp from any to $nat_cu port 34567:34575 flags S/SA synproxy state pass in on $ext_if inet proto tcp from any to $nat_opt port 6881:6999 flags S/SA synproxy state pass in on $ext_if inet proto tcp from any to $nat_opt port 993 flags S/SA synproxy state pass in quick on $int_if pass in quick on $wifi_if Many thanks, Dave On Mon, Jul 5, 2010 at 5:49 PM, David Warren wrote: > Hi all, > > As several people have noted, I should have been more specific about > the problem. As far as I can tell, it's limited to the wired portion of my > network involving the em0 interface. Samba and scp transfers to and from > computers on the ral0 interface seem unaffected. Even at the relatively > slow speeds of wireless, those transfers are substantially faster than the > degraded speeds I'm seeing on the wired network. I should also have noted > that the main computer on the wired network is a Windows box, while I use > the wireless with my MacBook. I'm using pf for my firewall on the FreeBSD > box, and having tried a bunch of the suggested tests I'm thinking that's the > most likely culprit. I'm going to try a few things out to test that idea. > However, for completeness, here's are the results of the various tests and > diagnostics that were requested. > > My pciconf output: > > > pciconf -lvc > nfe0@pci0:0:20:0: class=0x068000 card=0x816a1043 chip=0x026910de > rev=0xa3 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP51 Ethernet Controller (2A34103C)' > class = bridge > cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > em0@pci0:4:8:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' > class = network > subclass = ethernet > cap 01[dc] = powerspec 2 supports D0 D3 current D0 > cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction > ral0@pci0:4:9:0: class=0x028000 card=0x71281432 chip=0x03011814 > rev=0x00 hdr=0x00 > vendor = 'Ralink Technology, Corp' > device = 'Edimax 54 MBit WLan 802.11g rt 2500 (b8341462)' > class = network > cap 01[40] = powerspec 2 supports D0 D3 current D0 > > > dmesg isn't reporting anything new when this happens. Disabling > rxcsum and txcsum doesn't seem to have an effect. Here's a quick overview > of what I've tried: > > pscp works from .13 to .1 (pscp because I'm using key-based > identification). > samba fast then slow from .1 to .13 > samba fast then slow from .13 to .1 > netcat fast then slow from .13 to .1 > netcat not working from .1 to .13 (I need to figure out how to get netcat > input into the Windows box on .13) > > While the problem was evident, I collected the following netstat: > > > netstat -i > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs > Coll > em0 1500 00:0e:0c:b7:71:44 4840841 0 3791658 > 0 0 > em0 1500 192.168.0.0 192.168.0.1 5496050 - 3687095 > - - > ral0 2290 00:1f:1f:3f:76:f3 0 0 965271 > 1156 0 > nfe0 1500 00:01:29:d4:2d:6b 349488 0 83833 > 0 0 > nfe0 1500 173.19.224.0/ 173-19-224-254.cl 3260 - 7725 > - - > plip0 1500 0 0 0 > 0 0 > lo0 16384 758 0 758 > 0 0 > lo0 16384 fe80:5::1 fe80:5::1 0 - 0 > - - > lo0 16384 localhost ::1 0 - 0 > - - > lo0 16384 your-net localhost 74 - 758 > - - > wlan0 1500 00:1f:1f:3f:76:f3 873552 64 950672 > 7 0 > wlan0 1500 192.168.1.0 192.168.1.1 142745 - 937938 > - - > pflog 33152 0 0 242 > 0 0 > > which appears to be free of errors for em0. I also got the following > vmstat -i: > > > vmstat -i > interrupt total rate > irq1: atkbd0 8 0 > irq6: fdc0 7 0 > irq15: ata1 144 0 > irq16: em0 2456436 52 > irq17: ral0 3782116 80 > irq20: atapci2 217325 4 > irq21: hdac0 ohci0 11 0 > irq22: nfe0 ehci0 436597 9 > irq23: atapci1 206722 4 > cpu0: timer 94022466 2000 > cpu1: timer 94022098 2000 > Total 195143930 4151 > > And the following netstat: > > > sudo netstat -I em0 -indb > Name Mtu Network Address Ipkts Ierrs Ibytes > Opkts Oerrs Obytes Coll Drop > em0 1500 00:0e:0c:b7:71:44 5023101 0 3770654334 > 3978181 0 925661555 0 0 > em0 1500 192.168.0.0/2 192.168.0.1 5677843 - 4600314279 > 3873061 - 739695560 - - > > After starting a netcat transfer from .13 to .1, .13's system monitor > indicates that transfer over the local (outbound) interface starts out very > fast for a few seconds and then bottoms out. This iostat captures the same > pattern. ad4, ad6, ad8, and ad10 are the four disks sharing the base system > (geom mirror) and ZFS bulk filesystem. > > > iostat -n 5 -w 1 -c 30 > tty ad4 ad6 ad8 > ad10 da0 cpu > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps > MB/s KB/t tps MB/s us ni sy in id > 1 237 27.06 2 0.06 27.06 2 0.06 27.84 2 0.07 28.29 2 > 0.06 61.23 0 0.03 0 0 1 0 99 > 0 671 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 > 0.00 0.00 0 0.00 0 0 7 0 93 > 0 224 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 > 0.00 0.00 0 0.00 2 0 70 0 29 > 0 224 0.00 0 0.00 0.00 0 0.00 64.00 1 0.06 0.00 0 > 0.00 0.00 0 0.00 2 0 63 0 36 > 0 224 64.00 1 0.06 0.00 0 0.00 0.00 0 0.00 64.00 1 > 0.06 0.00 0 0.00 2 0 57 0 41 > 0 224 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 > 0.00 0.00 0 0.00 3 0 55 0 42 > 0 224 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 > 0.00 0.00 0 0.00 2 0 51 0 48 > 0 224 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 > 0.00 0.00 0 0.00 5 0 50 0 45 > 0 224 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 > 0.00 0.00 0 0.00 4 0 57 0 39 > 0 224 0.50 14 0.01 0.50 15 0.01 0.50 29 0.01 0.00 0 > 0.00 0.00 0 0.00 1 0 4 0 95 > 0 224 1.23 87 0.10 0.50 84 0.04 0.50 158 0.08 0.50 5 > 0.00 0.00 0 0.00 2 0 7 0 91 > 0 224 3.18 84 0.26 3.03 89 0.26 1.64 160 0.26 18.33 15 > 0.27 0.00 0 0.00 2 0 12 1 85 > 0 224 42.66 1167 48.63 42.70 1198 49.97 42.69 1870 77.96 42.66 1238 > 51.59 0.00 0 0.00 0 0 46 3 51 > 0 232 37.66 798 29.36 38.95 737 28.01 1.60 99 0.15 38.41 703 > 26.35 0.00 0 0.00 1 0 20 1 78 > 0 224 59.19 13 0.75 58.79 12 0.69 64.00 17 1.06 59.23 13 > 0.75 0.00 0 0.00 4 0 13 0 82 > 0 224 45.14 11 0.48 40.94 9 0.36 49.18 14 0.67 46.71 12 > 0.55 0.00 0 0.00 3 0 17 0 79 > 0 224 64.00 15 0.94 64.00 20 1.25 64.00 27 1.68 64.00 13 > 0.81 0.00 0 0.00 1 0 13 0 85 > 0 224 64.00 18 1.12 64.00 16 1.00 64.00 27 1.68 64.00 14 > 0.87 0.00 0 0.00 3 0 13 0 84 > 0 224 64.00 14 0.87 64.00 13 0.81 64.00 21 1.31 64.00 16 > 1.00 0.00 0 0.00 3 0 6 0 91 > 0 224 64.00 11 0.69 64.00 16 1.00 64.00 20 1.25 64.00 14 > 0.87 0.00 0 0.00 2 0 11 0 86 > 0 224 59.77 15 0.87 56.94 9 0.50 60.83 20 1.19 59.77 15 > 0.87 0.00 0 0.00 2 0 11 0 87 > 0 224 64.00 12 0.75 64.00 9 0.56 64.00 15 0.94 64.00 9 > 0.56 0.00 0 0.00 2 0 14 0 83 > 0 671 64.00 8 0.50 64.00 8 0.50 64.00 15 0.94 64.00 8 > 0.50 0.00 0 0.00 2 0 13 0 84 > 0 224 64.00 12 0.75 64.00 13 0.81 64.00 28 1.75 64.00 14 > 0.87 0.00 0 0.00 3 0 12 0 85 > 0 224 64.00 15 0.94 64.00 15 0.94 64.00 26 1.62 64.00 13 > 0.81 0.00 0 0.00 2 0 12 0 85 > 0 224 59.42 18 1.04 61.38 8 0.48 59.85 20 1.17 57.04 12 > 0.67 0.00 0 0.00 3 0 10 0 87 > 0 224 64.00 16 1.00 64.00 15 0.94 64.00 22 1.37 64.00 14 > 0.87 0.00 0 0.00 1 0 10 0 89 > 0 224 64.00 14 0.87 64.00 9 0.56 64.00 28 1.75 64.00 15 > 0.94 0.00 0 0.00 4 0 10 0 86 > 0 224 64.00 11 0.69 64.00 6 0.37 64.00 23 1.43 64.00 10 > 0.62 0.00 0 0.00 2 0 9 0 89 > 0 224 64.00 11 0.69 64.00 8 0.50 64.00 20 1.25 64.00 11 > 0.69 0.00 0 0.00 2 0 12 0 86 > > > Here's the iostat output during the transfer of a file from the ZFS > volume to an external HDD (da0): > > > iostat -n 5 -w 1 -c 30 > tty ad4 ad6 ad8 > ad10 da0 cpu > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps > MB/s KB/t tps MB/s us ni sy in id > 1 241 29.20 3 0.08 29.21 3 0.08 30.03 3 0.09 30.35 3 > 0.08 61.97 1 0.06 0 0 1 0 99 > 10 2167 64.00 2 0.12 0.00 0 0.00 64.00 1 0.06 0.00 0 > 0.00 0.00 0 0.00 1 0 7 0 92 > 0 224 0.00 0 0.00 64.00 2 0.12 0.00 0 0.00 64.00 3 > 0.19 0.00 0 0.00 2 0 13 0 85 > 12 961 44.45 144 6.24 43.24 150 6.32 42.81 152 6.34 45.06 143 > 6.28 62.21 382 23.22 2 0 19 1 78 > 0 335 45.67 163 7.26 43.89 174 7.44 43.28 175 7.38 46.06 170 > 7.63 63.07 453 27.91 3 0 32 1 64 > 0 335 32.70 209 6.66 32.09 213 6.66 32.66 221 7.03 32.85 211 > 6.75 63.10 398 24.53 6 0 24 2 68 > 0 335 45.22 167 7.36 43.16 172 7.23 45.68 170 7.57 43.88 176 > 7.53 63.08 457 28.15 4 0 38 1 57 > 0 335 45.25 157 6.93 43.95 166 7.11 45.94 163 7.30 43.69 167 > 7.11 62.88 433 26.61 4 0 35 1 60 > 0 335 44.04 171 7.34 45.36 174 7.69 46.46 169 7.65 43.66 172 > 7.32 63.09 462 28.47 2 0 36 3 60 > 0 335 43.38 179 7.57 44.68 170 7.40 45.68 170 7.57 43.39 178 > 7.53 63.08 455 28.03 3 0 44 1 52 > 0 335 43.53 173 7.34 45.01 164 7.19 44.18 169 7.28 44.73 165 > 7.19 63.10 465 28.66 1 0 24 4 70 > 0 335 43.26 178 7.50 45.27 172 7.59 43.85 181 7.73 45.40 172 > 7.61 62.98 468 28.78 7 0 37 1 55 > 0 335 45.18 170 7.49 44.54 171 7.42 44.66 182 7.92 45.71 175 > 7.80 62.94 455 27.97 2 0 30 2 66 > 0 335 44.25 171 7.38 44.52 169 7.33 45.94 174 7.79 43.35 178 > 7.52 63.07 449 27.66 3 0 37 1 59 > 0 335 45.77 165 7.36 43.42 171 7.24 45.62 166 7.38 43.86 179 > 7.65 63.08 458 28.22 4 0 36 1 59 > 0 349 46.11 99 4.45 43.89 105 4.49 47.30 106 4.89 44.82 109 > 4.76 63.17 287 17.73 3 0 35 1 61 > 0 335 64.00 5 0.31 64.00 9 0.56 64.00 8 0.50 64.00 7 > 0.44 0.00 0 0.00 3 0 29 0 69 > 0 335 64.00 10 0.62 64.00 3 0.19 64.00 15 0.94 64.00 12 > 0.75 0.00 0 0.00 3 0 22 0 75 > 0 335 64.00 2 0.12 64.00 4 0.25 64.00 6 0.37 64.00 6 > 0.37 0.00 0 0.00 6 0 30 0 64 > 0 335 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 64.00 1 > 0.06 0.00 0 0.00 4 0 36 0 60 > 0 335 64.00 2 0.12 64.00 4 0.25 64.00 10 0.62 64.00 6 > 0.37 0.00 0 0.00 4 0 20 0 75 > > and from the external HDD to the ZFS pool: > > > iostat -n 5 -w 1 -c 40 > tty ad4 ad6 ad8 > ad10 da0 cpu > tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps > MB/s KB/t tps MB/s us ni sy in id > 1 241 28.86 3 0.07 28.87 3 0.07 29.70 3 0.08 30.03 3 > 0.08 61.79 1 0.05 0 0 1 0 99 > 16 2391 64.00 6 0.37 64.00 7 0.44 64.00 8 0.50 64.00 6 > 0.37 0.00 0 0.00 2 0 14 0 84 > 8 277 64.00 2 0.12 0.00 0 0.00 64.00 3 0.19 64.00 2 > 0.12 58.15 13 0.74 6 0 17 0 76 > 10 957 30.35 139 4.11 31.93 138 4.29 32.62 141 4.48 32.65 138 > 4.39 63.03 246 15.17 2 0 13 2 84 > 0 335 7.17 29 0.20 4.82 31 0.15 10.24 33 0.33 11.64 33 > 0.37 63.04 248 15.30 2 0 30 0 67 > 0 335 64.00 7 0.44 64.00 5 0.31 64.00 10 0.62 64.00 8 > 0.50 63.04 249 15.30 5 0 23 0 72 > 0 335 43.29 317 13.42 43.22 316 13.35 43.47 323 13.73 43.34 321 > 13.60 63.00 241 14.80 2 0 31 2 65 > 0 335 64.00 4 0.25 58.79 12 0.69 58.79 12 0.69 58.79 12 > 0.69 63.04 250 15.36 5 0 27 0 68 > 0 335 64.00 5 0.31 64.00 5 0.31 64.00 11 0.69 64.00 8 > 0.50 63.04 249 15.30 3 0 28 0 69 > 0 335 64.00 13 0.81 64.00 4 0.25 64.00 14 0.87 64.00 11 > 0.69 63.27 248 15.29 3 0 24 0 73 > 0 335 64.00 2 0.12 53.58 6 0.31 55.00 7 0.38 55.00 7 > 0.38 62.78 250 15.30 6 0 26 0 68 > 0 335 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 > 0.00 63.04 248 15.30 6 0 29 0 64 > 0 335 64.00 2 0.12 64.00 2 0.12 64.00 2 0.12 64.00 1 > 0.06 63.04 250 15.36 6 0 23 0 71 > 0 335 48.38 4 0.19 64.00 4 0.25 43.00 3 0.13 48.25 4 > 0.19 63.04 248 15.30 3 0 32 0 65 > 0 335 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 > 0.00 63.04 250 15.36 5 0 29 0 66 > 0 335 64.00 1 0.06 64.00 2 0.12 64.00 4 0.25 64.00 3 > 0.19 63.28 248 15.35 4 0 27 0 68 > 0 335 64.00 5 0.31 64.00 6 0.37 64.00 6 0.37 64.00 5 > 0.31 63.04 249 15.30 4 0 29 0 67 > 0 335 0.00 0 0.00 64.00 1 0.06 64.00 1 0.06 64.00 1 > 0.06 63.04 250 15.36 2 0 38 0 60 > 0 335 64.00 1 0.06 0.00 0 0.00 64.00 3 0.19 64.00 2 > 0.12 62.78 249 15.24 5 0 32 0 62 > 0 335 21.42 6 0.13 35.61 9 0.31 35.61 9 0.31 32.06 8 > 0.25 63.04 250 15.36 3 0 34 0 62 > 0 335 55.07 7 0.38 64.00 1 0.06 56.19 8 0.44 43.17 3 > 0.13 63.04 248 15.30 6 0 28 0 67 > 0 335 51.50 10 0.50 64.00 13 0.81 58.32 22 1.25 61.14 22 > 1.31 63.28 249 15.36 3 0 26 0 71 > 0 1006 55.91 11 0.60 54.00 15 0.79 59.32 19 1.10 56.50 20 > 1.10 63.04 250 15.36 4 0 27 0 69 > 0 335 60.25 10 0.59 61.66 16 0.96 62.46 24 1.46 62.39 23 > 1.40 63.04 249 15.30 1 0 27 0 72 > 0 335 57.65 10 0.56 57.65 10 0.56 60.26 17 1.00 60.03 16 > 0.94 63.04 250 15.36 3 0 24 0 73 > 0 335 64.00 8 0.50 64.00 7 0.44 64.00 14 0.87 64.00 16 > 1.00 63.04 249 15.30 3 0 29 0 68 > 0 335 64.00 10 0.62 64.00 8 0.50 64.00 16 1.00 64.00 15 > 0.94 62.78 249 15.30 1 0 29 0 70 > 0 335 64.00 6 0.37 64.00 14 0.87 64.00 21 1.31 64.00 20 > 1.25 63.28 248 15.35 3 0 25 0 72 > 0 335 64.00 10 0.62 64.00 8 0.50 64.00 17 1.06 64.00 17 > 1.06 63.04 250 15.36 1 0 27 0 71 > 0 335 64.00 9 0.56 64.00 13 0.81 64.00 23 1.43 64.00 22 > 1.37 63.04 249 15.30 4 0 24 0 71 > 0 335 64.00 9 0.56 64.00 11 0.69 64.00 20 1.25 64.00 21 > 1.31 63.04 250 15.36 2 0 25 0 72 > 0 419 64.00 9 0.56 64.00 7 0.44 64.00 15 0.94 64.00 13 > 0.81 62.68 197 12.03 3 0 23 0 74 > 0 335 59.54 14 0.81 64.00 3 0.19 60.32 17 1.00 64.00 18 > 1.12 0.00 0 0.00 4 0 25 0 71 > 0 335 44.50 63 2.73 45.35 75 3.31 46.15 76 3.42 44.82 69 > 3.01 0.00 0 0.00 4 0 48 0 48 > 0 335 42.74 1560 65.11 42.75 1651 68.93 42.74 2466 102.95 42.74 > 1634 68.20 0.00 0 0.00 1 0 53 5 40 > 0 350 42.69 1519 63.32 42.40 1431 59.25 41.90 623 25.48 42.24 1468 > 60.55 0.00 0 0.00 0 0 27 4 69 > 0 344 11.20 88 0.96 11.31 67 0.74 18.38 82 1.47 19.02 81 > 1.50 0.00 0 0.00 3 0 12 0 85 > 0 335 64.00 7 0.44 64.00 7 0.44 64.00 12 0.75 64.00 11 > 0.69 0.00 0 0.00 3 0 23 0 73 > 0 335 64.00 7 0.44 64.00 9 0.56 64.00 14 0.87 64.00 14 > 0.87 0.00 0 0.00 3 0 23 0 74 > 0 335 64.00 8 0.50 64.00 6 0.37 64.00 12 0.75 64.00 7 > 0.44 0.00 0 0.00 2 0 19 1 78 > > Many thanks for all the ideas, and I'll report back after a bit more > testing. > > Dave > > > On Mon, Jul 5, 2010 at 12:51 AM, Jeremy Chadwick > wrote: > >> On Sun, Jul 04, 2010 at 07:52:11PM -0500, David Warren wrote: >> > I've got a persistent problem with my LAN. I'm running a FreeBSD >> 8.0 >> > box as a home server performing the following functions for wired and >> > wireless networks: router; firewall; DHCP server; and file server. For >> what >> > it's worth, I've got ZFS up and running as the main filesystem. The >> > recurring issue is that file transfers from the FreeBSD box to computers >> on >> > the wired network (gigabit) start out fast and then become agonizingly >> > slow. I'm sharing home directories over Samba, and those transfers work >> > briefly and then tail off to a few kilobytes per second. The failure is >> > somewhat predicatable in that it tends to happen once a few hundred >> > megabytes have been transferred. >> >> Your system has 3 different network interfaces on it (em, ral, nfe), but >> you don't tell us across which interface the slow transfers happen. You >> also don't tell us which firewalling stack you're using (ipfw, ipfilter, >> pf). Let us know. >> >> I'm going to make the assumption that based on your "...on the wired >> network (gigabit)..." statement that the transfers are going across the >> em0 interface, but again, I'm not sure. >> >> Relevant interfaces (wlan0 is tied to ral0): >> >> > em0: flags=8843 metric 0 mtu >> 1500 >> > options=9b >> > ether 00:0e:0c:b7:71:44 >> > inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 >> > media: Ethernet autoselect (1000baseT ) >> > status: active >> > ral0: flags=8843 metric 0 mtu >> 2290 >> > ether 00:1f:1f:3f:76:f3 >> > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g >> >> > status: running >> > nfe0: flags=8843 metric 0 mtu >> 1500 >> > options=8 >> > ether 00:01:29:d4:2d:6b >> > inet XXX.XXX.XXX.XXX netmask 0xfffffc00 broadcast >> 255.255.255.255 >> > media: Ethernet autoselect (100baseTX ) >> > status: active >> > [...] >> > wlan0: flags=8843 metric 0 mtu >> 1500 >> > ether 00:1f:1f:3f:76:f3 >> > inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 >> > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g >> >> > status: running >> > ssid FreeBSD_AP channel 7 (2442 Mhz 11g) bssid 00:1f:1f:3f:76:f3 >> > country US authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit >> > txpower 0 scanvalid 60 protmode CTS dtimperiod 1 -dfs >> >> First and foremost: is the problem specific to Samba? Can you reproduce >> the problem when using the FTP protocol? >> >> Are there any indications of problems in "dmesg" when the issue is >> happening? >> >> Can you provide output from "vmstat -i" while the problem is happening? >> >> Can you provide output from "pciconf -lvc"? Only interested in the >> sections relevant to the above devices. >> >> Can you provide contents of /etc/make.conf, /etc/sysctl.conf, and >> /boot/loader.conf? >> >> Have you looked at "netstat -I -indb" output during the slow >> transfers to see if there's any indication of problems, or some sort of >> "common rate" (transfer, etc.) >> >> Does disabling the firewalling stack improve things at all? >> >> Can the slowness be reproduced using benchmarks/netperf or only when >> using something that involves actual disk I/O? (To use netperf you'll >> need two FreeBSD boxes). If only disk I/O, then ZFS analysis might be >> needed (there are some performance adjustments that are often required). >> >> Focusing more on em0: >> >> Have you tried disabling rxcsum and txcsum (using ifconfig) to see if >> there's any improvement? I don't see TSO used by your interface, so >> that should rule out any problems with that feature. >> >> -- >> | Jeremy Chadwick jdc@parodius.com | >> | Parodius Networking http://www.parodius.com/ | >> | UNIX Systems Administrator Mountain View, CA, USA | >> | Making life hard for others since 1977. PGP: 4BD6C0CB | >> >> > > > -- > Post-doctoral Fellow > Neurology Department > University of Iowa Hospitals and Clinics > davideugenewarren@gmail.com > -- Post-doctoral Fellow Neurology Department University of Iowa Hospitals and Clinics davideugenewarren@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Jul 6 08:44:32 2010 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 29B12106566C for ; Tue, 6 Jul 2010 08:44:32 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by mx1.freebsd.org (Postfix) with ESMTP id 926A28FC0A for ; Tue, 6 Jul 2010 08:44:29 +0000 (UTC) Received: from endor.tataz.chchile.org (unknown [82.233.239.98]) by smtp5-g21.free.fr (Postfix) with ESMTP id 42224D4807B; Tue, 6 Jul 2010 10:44:24 +0200 (CEST) Received: from felucia.tataz.chchile.org (felucia.tataz.chchile.org [192.168.1.9]) by endor.tataz.chchile.org (Postfix) with ESMTP id A1D1A33E60; Tue, 6 Jul 2010 08:44:22 +0000 (UTC) Received: by felucia.tataz.chchile.org (Postfix, from userid 1000) id 92EF8A1117; Tue, 6 Jul 2010 08:44:22 +0000 (UTC) Date: Tue, 6 Jul 2010 10:44:22 +0200 From: Jeremie Le Hen To: Ed Schouten Message-ID: <20100706084422.GC6194@felucia.tataz.chchile.org> References: <20100705185019.GB6194@felucia.tataz.chchile.org> <20100705225436.GL2179@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100705225436.GL2179@hoeg.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@FreeBSD.org, Jeremie Le Hen Subject: Re: Panic in destroy_dev_sched_cb() for tty 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, 06 Jul 2010 08:44:32 -0000 On Tue, Jul 06, 2010 at 12:54:36AM +0200, Ed Schouten wrote: > * Jeremie Le Hen wrote: > > I've got a panic obviously from the tty layer but I couldn't get the > > panic string as no remote system was connected using serial console, and > > I don't know how to print it from DDB. > > Hmmm... This is a tricky one, but I think I do understand what's going > on here. If you close and revoke a TTY at the very exact moment, it may > call destroy_dev_sched_cb() twice, where the second time it gets called > on a null pointer. > > =================================================================== > --- sys/kern/tty.c (revision 209570) > +++ sys/kern/tty.c (working copy) > @@ -1040,7 +1040,8 @@ > tp->t_dev = NULL; > tty_unlock(tp); > > - destroy_dev_sched_cb(dev, tty_dealloc, tp); > + if (dev != NULL) > + destroy_dev_sched_cb(dev, tty_dealloc, tp); > } > > void > > I guess it's very hard to reproduce, right? If so, I'll just commit it > to SVN. Thanks for reporting! Sure it is. I use screen heavily and this is the first time I get it. Please go forward, I will update my kernel after it has been MFC and I won't miss informing you if it occurs again. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche From owner-freebsd-stable@FreeBSD.ORG Tue Jul 6 13:55:26 2010 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 3B8CD1065674 for ; Tue, 6 Jul 2010 13:55:26 +0000 (UTC) (envelope-from nickolasbug@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C19F28FC16 for ; Tue, 6 Jul 2010 13:55:25 +0000 (UTC) Received: by bwz12 with SMTP id 12so4236450bwz.13 for ; Tue, 06 Jul 2010 06:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=qReu3Tvr+LbqdWIgYecV5oYvd/3V8adbgrMu8gEZd08=; b=mwQfXixSIOelVo2yB/6nnqVIE2pY4TldqKVchh9TzQhOU5kY89y74LVmf9KYCpDby8 K6DefeFrsKpNDzdIUBUzG1KoAWZOYWOBae+0fkd3CtzQITI2xqPR4np7Ql0M4f8VYs7P PigvOmQ/OBBoAqp8YRHNvZvLPbr/E9s/LzPBI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vOjuj/ppVQSaBN6UA11immGQzixNV1TgjO3vG+Vo3JGJPJs7a6a8orbx8C+FMGTVsU gUK5WX+vVu5+VFOXMAtYaGwR9BLjZVfzqrbttUlfM/00T4kU+9qrTpVuKeZvgu/ZY/Gi CIRBOKl/HmuPjydlHh2yuRWgamCdkqlsNQ1l4= MIME-Version: 1.0 Received: by 10.204.49.196 with SMTP id w4mr3727758bkf.73.1278424515797; Tue, 06 Jul 2010 06:55:15 -0700 (PDT) Received: by 10.204.77.143 with HTTP; Tue, 6 Jul 2010 06:55:15 -0700 (PDT) Date: Tue, 6 Jul 2010 16:55:15 +0300 Message-ID: From: nickolasbug@gmail.com To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: csup: Invalid greeting from server 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, 06 Jul 2010 13:55:26 -0000 Hi all! Is everything OK with cvsup.freebsd.org? I got message "Invalid greeting from server" during last two days: csup -L 2 /etc/supfile Parsing supfile "/etc/supfile" Connecting to cvsup.freebsd.org Connected to 72.233.193.64 Invalid greeting from server My supfile looks like this: *default host=cvsup.freebsd.org *default base=/var/db *default prefix=/usr *default release=cvs *default compress delete use-rel-suffix src-all tag=RELENG_8 ports-all tag=. doc-all tag=. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 6 14:15:56 2010 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 70C7B106564A for ; Tue, 6 Jul 2010 14:15:56 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 1ECFA8FC0A for ; Tue, 6 Jul 2010 14:15:55 +0000 (UTC) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id ebsW1e00416LCl053eFw4B; Tue, 06 Jul 2010 14:15:56 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta06.westchester.pa.mail.comcast.net with comcast id eeFv1e0053S48mS3SeFvhE; Tue, 06 Jul 2010 14:15:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A4FE09B425; Tue, 6 Jul 2010 07:15:53 -0700 (PDT) Date: Tue, 6 Jul 2010 07:15:53 -0700 From: Jeremy Chadwick To: nickolasbug@gmail.com Message-ID: <20100706141553.GA59650@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hubs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: csup: Invalid greeting from server 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, 06 Jul 2010 14:15:56 -0000 On Tue, Jul 06, 2010 at 04:55:15PM +0300, nickolasbug@gmail.com wrote: > Is everything OK with cvsup.freebsd.org? > I got message "Invalid greeting from server" during last two days: > > csup -L 2 /etc/supfile > Parsing supfile "/etc/supfile" > Connecting to cvsup.freebsd.org > Connected to 72.233.193.64 > Invalid greeting from server > > My supfile looks like this: > > *default host=cvsup.freebsd.org > *default base=/var/db > *default prefix=/usr > *default release=cvs > *default compress delete use-rel-suffix > > src-all tag=RELENG_8 > ports-all tag=. > doc-all tag=. This should have been sent to freebsd-hubs. Adding to CC. -- | Jeremy Chadwick jdc@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 Jul 6 16:53:17 2010 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 E170E1065672 for ; Tue, 6 Jul 2010 16:53:17 +0000 (UTC) (envelope-from nickolasbug@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6FC4A8FC1A for ; Tue, 6 Jul 2010 16:53:17 +0000 (UTC) Received: by fxm13 with SMTP id 13so5405097fxm.13 for ; Tue, 06 Jul 2010 09:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qcRYuii30KLps5s4xgQar3qM3SXzHlIgs6uQwrgc+UA=; b=YlqP+ecQ1Ne8qQWBLj2vM4UdYdIBSRQ8Fv6YBD9yQqAW61r3jQ/U7UO0Cq5ZFB+P3S /BjjsppEuvPNX6+PdhSJVgc2qij2jy/NI93FCXgtAqxQ6+RsA6i055eHN+goZqniSbT2 XdDKTxay92LqnRG8vK8s+IUt5D1qyGrc3EpRQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JDGDLqcnOXw0JfL7OCdvdjJiiuHTwyL1GNwhQVdrOvlcVIKruG+bu6rNWXsoPDAuSw wYt85F+yDK2+1UFmf8yW8TjPXdKAi5qVJXwDYWR6vGGvvbTWrS3aZmP//dR4gZfIrNjI gPHu8WQJ6jcpN5RorZUT1j5oNN0qAs8aSgXpQ= MIME-Version: 1.0 Received: by 10.204.104.4 with SMTP id m4mr3813347bko.45.1278435183743; Tue, 06 Jul 2010 09:53:03 -0700 (PDT) Received: by 10.204.77.143 with HTTP; Tue, 6 Jul 2010 09:53:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Jul 2010 19:53:03 +0300 Message-ID: From: nickolasbug@gmail.com To: Alexander Petrovsky Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: csup: Invalid greeting from server 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, 06 Jul 2010 16:53:18 -0000 2010/7/6 Alexander Petrovsky : > Wrong! > http://www.freebsd.org/doc/en/books/handbook/cvsup.html What's wrong? This config file hasn't changed since 8.0 release date and everything was f= ine. So, it's either server or client problem. But it's not config file problem! > 2010/7/6 >> >> Hi all! >> >> Is everything OK with cvsup.freebsd.org? >> I got message "Invalid greeting from server" during last two days: >> >> csup -L 2 /etc/supfile >> Parsing supfile "/etc/supfile" >> Connecting to cvsup.freebsd.org >> Connected to 72.233.193.64 >> Invalid greeting from server >> >> My supfile looks like this: >> >> *default host=3Dcvsup.freebsd.org >> *default base=3D/var/db >> *default prefix=3D/usr >> *default release=3Dcvs >> *default compress delete use-rel-suffix >> >> src-all tag=3DRELENG_8 >> ports-all tag=3D. >> doc-all tag=3D. >> _______________________________________________ >> 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= " > > > > -- > =F0=C5=D4=D2=CF=D7=D3=CB=C9=CA =E1=CC=C5=CB=D3=C1=CE=C4=D2 / Alexander Pe= trovsky, > > ICQ: 350342118 > Jabber: juise@jabber.ru > Phone: +7 914 8 820 815 > From owner-freebsd-stable@FreeBSD.ORG Tue Jul 6 17:06:50 2010 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 41E3D106566B; Tue, 6 Jul 2010 17:06:50 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.re1.yahoo.com (mrout1-b.corp.re1.yahoo.com [69.147.107.20]) by mx1.freebsd.org (Postfix) with ESMTP id F41718FC14; Tue, 6 Jul 2010 17:06:49 +0000 (UTC) Received: from [127.0.0.1] (cheese.corp.yahoo.com [216.145.50.99]) by mrout1-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o66H6Rtt079341; Tue, 6 Jul 2010 10:06:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:reply-to:to:cc:in-reply-to:references: content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=g8Wp22aeTomVG20XZHYg9hH3C6K1Lo9pmqOSsesm6k6wI9wsKyfN6wYlHfdxqLtM From: Sean Bruno To: "pyunyh@gmail.com" In-Reply-To: <20100702193341.GC10862@michelle.cdnetworks.com> References: <1278089690.2469.22.camel@localhost.localdomain> <20100702191110.GA10862@michelle.cdnetworks.com> <1278098663.2469.31.camel@localhost.localdomain> <20100702193341.GC10862@michelle.cdnetworks.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 06 Jul 2010 10:06:27 -0700 Message-ID: <1278435987.2506.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: freebsd-stable , "yongari@freebsd.org" Subject: Re: [stable 7] bge() related panic on an HP dl380g3 (32 bit) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 17:06:50 -0000 On Fri, 2010-07-02 at 12:33 -0700, Pyun YongHyeon wrote: > On Fri, Jul 02, 2010 at 12:24:23PM -0700, Sean Bruno wrote: > > On Fri, 2010-07-02 at 12:11 -0700, Pyun YongHyeon wrote: > > > On Fri, Jul 02, 2010 at 09:54:50AM -0700, Sean Bruno wrote: > > > > Started seeing this panic today from our BSD7 variant here at Yahoo. > > > > Our BGE driver is identical to 7stable at this time. Looks like all of > > > > these boxes are HP DL380G3 models. I have included the panic and > > > > pciconf -lv information. > > > > > > > > > > > > I assume that these machines have a variant of BGE that needs some kind > > > > of exception/quirk that I'm unaware of. > > > > > > > > > > Does your bge(4) driver include r208995? > > > > It did not. I screwed up the report. > > > > The bge(4) driver under test was from r205616 (we built it in April). > > > > Did this panic look like the one fixed by r208995? > > > > Yes. > > > Sean > > Bah, thanks. This seems to have repaired the problem. +1 pointyhat to me. Sean From owner-freebsd-stable@FreeBSD.ORG Tue Jul 6 17:42:00 2010 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 B8F53106564A for ; Tue, 6 Jul 2010 17:42:00 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by mx1.freebsd.org (Postfix) with ESMTP id 675638FC16 for ; Tue, 6 Jul 2010 17:41:56 +0000 (UTC) Received: from slackbox.erewhon.net (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id o66Hftov068747; Tue, 6 Jul 2010 19:41:55 +0200 (CEST) (envelope-from rsmith@xs4all.nl) Received: by slackbox.erewhon.net (Postfix, from userid 1001) id 7DC6DBAB9; Tue, 6 Jul 2010 19:41:55 +0200 (CEST) Date: Tue, 6 Jul 2010 19:41:55 +0200 From: Roland Smith To: David Warren Message-ID: <20100706174155.GA56410@slackbox.erewhon.net> References: <20100705055105.GA21681@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" 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.20 (2009-06-14) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org Subject: Re: 8.0 network 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: Tue, 06 Jul 2010 17:42:00 -0000 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 06, 2010 at 01:06:25AM -0500, David Warren wrote: > Hi again, >=20 > Disabling pf definitely makes samba file transfers move faster (the > speed varies quite a bit, but everything's faster than the single kilobyt= es > per second I was seeing previously), but I'm perplexed about what's causi= ng > the slowdown. There's certainly some cruft in my pf.conf (below), but I'm > not sure what might be strangling my LAN. Can anyone set me straight? In general, check which rules are matched most with 'pfctl -vvs rules|less'. Put the rules that are matched most first in the ruleset, adding the 'quick' keyword where possible. There is a FAQ on the OpenBSD site about pf, but it pertains to a newer version than is available in FreeBSD! > /etc/pf.conf: > # macros > int_if =3D "em0" > wifi_if =3D "wlan0" > ext_if =3D "nfe0" >=20 > nat_opt =3D "192.168.0.5" # Windows box > nat_cu =3D "192.168.0.1" # server >=20 > tcp_services =3D "{ 22 }" > icmp_types =3D "echoreq" =20 > priv_nets =3D "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }" You might want to replace this by a table. It's supposed to be faster; table const { 127/8, 192.168/16, 172.16/12, 10/8 } > # options You could try and use ruleset optimization; set ruleset=E2=80=90optimization profile > set block-policy return > set loginterface $ext_if > set skip on lo >=20 > # scrub > scrub in >=20 > # nat/rdr > nat on $ext_if from !($ext_if) -> ($ext_if:0) > nat on $ext_if from $wifi_if:network to any -> ($ext_if) > rdr on $ext_if proto tcp from any to any port 22 -> $nat_cu > rdr on $ext_if proto tcp from any to any port 6881:6999 -> $nat_opt > rdr on $ext_if proto tcp from any to any port 34567:34575 -> $nat_cu > rdr on $ext_if proto tcp from any to any port 993 -> $nat_opt >=20 > # filter rules > block in log Try block in log label "inblock" Adding labels to your rules aids you in determining which ones are matched, with 'pfctl -vvs labels' > pass out keep state I think keeping state is the default now. > antispoof quick for { lo $int_if } >=20 > pass in on $ext_if inet proto tcp from any to ($ext_if) port $tcp_services > flags S/SA keep state >=20 > block drop in quick on $ext_if from $priv_nets to any > block drop out quick on $ext_if from any to $priv_nets Use table syntax in combination with the table defined above; block drop in quick on $ext_if from to any block drop out quick on $ext_if from any to > pass in inet proto icmp all icmp-type $icmp_types keep state You might want to think about added the "quick" keyword to the following fo= ur rules. > pass in on $ext_if inet proto tcp from any to $nat_cu port $tcp_services > flags S/SA synproxy state > pass in on $ext_if inet proto tcp from any to $nat_cu port 34567:34575 fl= ags > S/SA synproxy state > pass in on $ext_if inet proto tcp from any to $nat_opt port 6881:6999 fla= gs > S/SA synproxy state > pass in on $ext_if inet proto tcp from any to $nat_opt port 993 flags S/SA > synproxy state If you have a lot of traffic on the following two rules, put them at the to= p of the filter rules. Then they will be evaluated first and not the rest of the rules. You might also consider adding them to 'set skip'. > pass in quick on $int_if > pass in quick on $wifi_if Enlarging the buffer sizes for the BPF device might help as well; sysctl net.bpf.bufsize=3D65536 sysctl net.bpf.maxbufsize=3D524288 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) --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkwzauMACgkQEnfvsMMhpyX/egCfdUO+ANCCNLOi7wjL6ePXYPut Pr4AnixsDHlBDacrcxL2tCc142hwRcLZ =XxsZ -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 6 20:32:24 2010 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 72C111065673 for ; Tue, 6 Jul 2010 20:32:24 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 573118FC19 for ; Tue, 6 Jul 2010 20:32:23 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta01.emeryville.ca.mail.comcast.net with comcast id ecb81e0081vN32cA1kYPXQ; Tue, 06 Jul 2010 20:32:23 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta22.emeryville.ca.mail.comcast.net with comcast id ekYN1e00B3S48mS8ikYNBy; Tue, 06 Jul 2010 20:32:23 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5C1B39B425; Tue, 6 Jul 2010 13:32:22 -0700 (PDT) Date: Tue, 6 Jul 2010 13:32:22 -0700 From: Jeremy Chadwick To: Roland Smith Message-ID: <20100706203222.GA68830@icarus.home.lan> References: <20100705055105.GA21681@icarus.home.lan> <20100706174155.GA56410@slackbox.erewhon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100706174155.GA56410@slackbox.erewhon.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Max Laier , David Warren , freebsd-stable@freebsd.org Subject: Re: 8.0 network 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: Tue, 06 Jul 2010 20:32:24 -0000 Adding Max Laier (maintainer of pf) to the CC list. He may have some ideas as to what's causing this. Max, relevant thread details: http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057586.html http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057597.html http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057602.html The last link above indicates the OP gets decent transfer rates with pf disabled, and includes his pf.conf. On Tue, Jul 06, 2010 at 07:41:55PM +0200, Roland Smith wrote: > On Tue, Jul 06, 2010 at 01:06:25AM -0500, David Warren wrote: > > pass out keep state > > I think keeping state is the default now. It is, but it's worth going over the "history" just so people understand. I've been schooled on this in the past, but I'm still going off of memory so if someone knows otherwise please chime in. In 7.2 and earlier (I could have the version numbers wrong, but 7.3-PRERELEASE doesn't require this), you had to explicitly state "keep state flags S/SA" on TCP traffic, and "keep state" on UDP/ICMP traffic. This is because said version(s) use older and newer pf, respectively. So in the OP's case, the above rule on an older OS would cause mayhem (excessive states being created for TCP, and improperly at that (any outbound TCP packet, rather than ones with only SYN set when looking at only SYN & ACK)). In 7.3 and later (including 8.x and onward), the "keep state" parameter isn't needed; it's explicitly applied unless you use "no_state". pf also intelligently figures out when to use "flags S/SA" (e.g. for TCP rules). For example, the following pf.conf rule (notice that there's no protocol defined): pass in quick on em0 inet from any to 1.2.3.4 keep state Gets turned into: pass in quick on em0 inet from any to 1.2.3.4 flags S/SA keep state And "does the right thing" even with UDP/ICMP traffic where there's no stateful flags involves. Meaning, the "flags S/SA" part applies to any inbound TCP, and isn't used for other protocols. Back to the problem at hand: I wonder if it's lack of "quick" on some rules which is causing the problem; hard to say, and I'm not sure how to "benchmark" pf. Furthermore, remember that the OP can move to another NIC and the problem goes away[1]. I know there have been issues in the past reported with em(4) and pf ALTQ, but that isn't in use here. [1]: I assume the OP is updating pf.conf to specify the changed interface and so on; if not, then I imagine it would be as effective as disabling pf (thus "it's fast when I use something other than em0" would be inaccurate). I simply don't know. -- | Jeremy Chadwick jdc@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 Jul 6 20:48:51 2010 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 182E4106566C for ; Tue, 6 Jul 2010 20:48:51 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id 9D4728FC1A for ; Tue, 6 Jul 2010 20:48:50 +0000 (UTC) Received: from f8x64.laiers.local (dslb-088-066-042-254.pools.arcor-ip.net [88.66.42.254]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MHKSt-1OIEZS0BbH-00EBZb; Tue, 06 Jul 2010 22:48:45 +0200 From: Max Laier Organization: FreeBSD To: Jeremy Chadwick Date: Tue, 6 Jul 2010 22:48:42 +0200 User-Agent: KMail/1.13.3 (FreeBSD/8.1-RC2; KDE/4.4.4; amd64; ; ) References: <20100706174155.GA56410@slackbox.erewhon.net> <20100706203222.GA68830@icarus.home.lan> In-Reply-To: <20100706203222.GA68830@icarus.home.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007062248.42720.max@love2party.net> X-Provags-ID: V02:K0:xtIlAx3+7lx0F1KH1jUg4TbnfqEMc4k3EvYBN8OT/xe 7tD8uVghiI1SKm07/0qzWuQv13ZhqddXL6shBrLAIt79GDDZDB XInV+zEEq2jjwZ27izdUUYKGMxFNXvyIfAeBn5DoM2NbaTUipF /vJZiXngwFAreLunc2K2nZ/UVfDjX7EHNEjjnSDawKdSnAJbtG 9zMk+4bn2oe1PmopVUA9g== Cc: Roland Smith , David Warren , freebsd-stable@freebsd.org Subject: Re: 8.0 network 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: Tue, 06 Jul 2010 20:48:51 -0000 On Tuesday 06 July 2010 22:32:22 Jeremy Chadwick wrote: > Adding Max Laier (maintainer of pf) to the CC list. He may have some > ideas as to what's causing this. Max, relevant thread details: > > http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057586.html > http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057597.html > http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057602.html > > The last link above indicates the OP gets decent transfer rates with pf > disabled, and includes his pf.conf. Please check "pfctl -si" esp. "state-mismatch" This is always the first indication that something is wrong. In addition you can set a higher pf debugging level (pfctl -xm) in order to get more information on the issue - if the cause is indeed a state mismatch. > On Tue, Jul 06, 2010 at 07:41:55PM +0200, Roland Smith wrote: > > On Tue, Jul 06, 2010 at 01:06:25AM -0500, David Warren wrote: > > > pass out keep state > > > > I think keeping state is the default now. > > It is, but it's worth going over the "history" just so people > understand. I've been schooled on this in the past, but I'm still going > off of memory so if someone knows otherwise please chime in. > > In 7.2 and earlier (I could have the version numbers wrong, but > 7.3-PRERELEASE doesn't require this), you had to explicitly state "keep > state flags S/SA" on TCP traffic, and "keep state" on UDP/ICMP traffic. > This is because said version(s) use older and newer pf, respectively. > > So in the OP's case, the above rule on an older OS would cause mayhem > (excessive states being created for TCP, and improperly at that (any > outbound TCP packet, rather than ones with only SYN set when looking at > only SYN & ACK)). > > In 7.3 and later (including 8.x and onward), the "keep state" parameter > isn't needed; it's explicitly applied unless you use "no_state". pf > also intelligently figures out when to use "flags S/SA" (e.g. for TCP > rules). For example, the following pf.conf rule (notice that there's no > protocol defined): > > pass in quick on em0 inet from any to 1.2.3.4 keep state > > Gets turned into: > > pass in quick on em0 inet from any to 1.2.3.4 flags S/SA keep state > > And "does the right thing" even with UDP/ICMP traffic where there's no > stateful flags involves. Meaning, the "flags S/SA" part applies to any > inbound TCP, and isn't used for other protocols. > > Back to the problem at hand: > > I wonder if it's lack of "quick" on some rules which is causing the > problem; hard to say, and I'm not sure how to "benchmark" pf. > > Furthermore, remember that the OP can move to another NIC and the > problem goes away[1]. I know there have been issues in the past > reported with em(4) and pf ALTQ, but that isn't in use here. > > > > [1]: I assume the OP is updating pf.conf to specify the changed > interface and so on; if not, then I imagine it would be as effective as > disabling pf (thus "it's fast when I use something other than em0" would > be inaccurate). I simply don't know. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 6 21:28:33 2010 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 93F9F106564A for ; Tue, 6 Jul 2010 21:28:33 +0000 (UTC) (envelope-from rsmith@xs4all.nl) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by mx1.freebsd.org (Postfix) with ESMTP id 249798FC1C for ; Tue, 6 Jul 2010 21:28:32 +0000 (UTC) Received: from slackbox.erewhon.net (slackbox.xs4all.nl [213.84.242.160]) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id o66LSUJk018973; Tue, 6 Jul 2010 23:28:30 +0200 (CEST) (envelope-from rsmith@xs4all.nl) Received: by slackbox.erewhon.net (Postfix, from userid 1001) id 7EC2BBAA4; Tue, 6 Jul 2010 23:28:30 +0200 (CEST) Date: Tue, 6 Jul 2010 23:28:30 +0200 From: Roland Smith To: Jeremy Chadwick Message-ID: <20100706212830.GA63307@slackbox.erewhon.net> References: <20100705055105.GA21681@icarus.home.lan> <20100706174155.GA56410@slackbox.erewhon.net> <20100706203222.GA68830@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: <20100706203222.GA68830@icarus.home.lan> 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.20 (2009-06-14) X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Max Laier , David Warren , freebsd-stable@freebsd.org Subject: Re: 8.0 network 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: Tue, 06 Jul 2010 21:28:33 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 06, 2010 at 01:32:22PM -0700, Jeremy Chadwick wrote: > Back to the problem at hand: >=20 > I wonder if it's lack of "quick" on some rules which is causing the > problem; hard to say,=20 That would stop evaluation of further rules, sure. But it seems most of the rules concern the external interface. _Assuming_ that the samba clients are on the internal interface, it would m= ake sense to put the few rules concerning that interface as early as possible in the list of filter rules, and indeed add the quick keyword. Alternatively, one could consider adding this interface to the list of skip= ped interfaces. This would at least be useful for testing purposes, since it wo= uld preclude pf from processing packages on this interface. If this fixes the problem, there is some problem in the ruleset. > and I'm not sure how to "benchmark" pf. Looking at the output of 'pfctl -vvs rules' would be a start, I think. If t= he rules that are matched most are at the end of the filter rules, all previous rules are evaluated, AFAIK. For more info try 'pfctl -vvs all'. In the past I found it useful to set up a point-to-point connection between two FreeBSD machines, and then do some throughput measusrements using e.g. nc(1). Start with pf disabled, then enhance the ruleset rule-by-rule a= nd see if performance is influenced. A couple of years ago I did this, and IIRC the largest influence I could find was the type of ethernet adapter used. Can't find any notes from that experiment but I could repeat it if is deemed interesting. > Furthermore, remember that the OP can move to another NIC and the > problem goes away[1]. I know there have been issues in the past > reported with em(4) and pf ALTQ, but that isn't in use here. There are lots of other crappy ethernet adapters out there. E.g. re(4) and rl(4) tend to suck in my experience. Of course if the hardware was changed = but not the relevant filter rules, it would default to "pass". :-) 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) --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkwzn/4ACgkQEnfvsMMhpyXs8ACgrI84kATERqep69TTnd4QRYbE dMUAoI3QFzaV3zQiglfpOJuDgPk/+CDF =gizH -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 6 23:05:44 2010 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 920AC106566B for ; Tue, 6 Jul 2010 23:05:44 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1A5B88FC14 for ; Tue, 6 Jul 2010 23:05:43 +0000 (UTC) Received: from ur.dons.net.au (ppp121-45-156-207.lns6.adl6.internode.on.net [121.45.156.207]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o66N5T8s067731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Jul 2010 08:35:35 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Jul 2010 08:35:28 +0930 To: FreeBSD Stable Message-Id: Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Subject: MIMEDefang not starting on reboot 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, 06 Jul 2010 23:05:44 -0000 Does anyone else see this? I have 2 (of 2) amd64 8.x systems which don't start MIMEDefang on reboot = properly, I get this.. Jul 7 06:34:58 cain mimedefang-multiplexor[1747]: Starting slave 3 (pid = 41198) (1 running): Bringing slaves up to minSlaves (2) Jul 7 06:34:58 cain mimedefang-multiplexor[1747]: Slave 3 stderr: Can't = load '/usr/local/lib/perl5/5.10.1/mach/auto/File/Glob/Glob.so' for = module File::Glob: = /usr/local/lib/perl5/5.10.1/mach/auto/File/Glob/Glob.so: mmap of entire = address space failed: Cannot allocate memory at = /usr/local/lib/perl5/5.10.1/mach/XSLoader.pm line 70. at = /usr/local/lib/perl5/5.10.1/mach/File/Glob.pm line 96 Compilation failed = in require at /usr/local/bin/mimedefang.pl line 3239. BEGIN = failed--compilation aborted at /usr/local/bin/mimedefang.pl line 3239. Restarting it manually (ie /usr/local/etc/rc.d/mimedefang.sh restart) = after a reboot fixes it.. Also I think it would be nice if this patch were added to the port.. --- /usr/local/etc/rc.d/mimedefang.sh-dist 2010-04-07 = 10:30:46.586067014 +0930 +++ /usr/local/etc/rc.d/mimedefang.sh 2010-05-01 13:47:47.340517685 = +0930 @@ -316,7 +319,7 @@ rm -f $MX_SOCKET > /dev/null 2>&1 rm -f $SOCKET > /dev/null 2>&1 - if [ "$1" =3D "wait" ] ; then + if [ "wait" =3D "wait" ] ; then printf "Waiting for daemons to exit." WAITPID=3D"" test -f $PID && WAITPID=3D`cat $PID` Otherwise restart is useless because it starts MD without waiting for = the old one to stop and it doesn't work :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Tue Jul 6 23:57:14 2010 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 A86BE106566B; Tue, 6 Jul 2010 23:57:14 +0000 (UTC) (envelope-from cwt@networks.cwu.edu) Received: from nsc0.cwu.edu (nsc0.cwu.edu [72.233.196.16]) by mx1.freebsd.org (Postfix) with ESMTP id 689348FC08; Tue, 6 Jul 2010 23:57:13 +0000 (UTC) Received: from n.cwu.edu (n.cwu.edu [198.104.69.57]) by nsc0.cwu.edu (8.14.3/8.14.3) with ESMTP id o66NUJuq067727; Tue, 6 Jul 2010 16:30:19 -0700 (PDT) (envelope-from cwt@networks.cwu.edu) Received: from n.cwu.edu (localhost [127.0.0.1]) by n.cwu.edu (8.13.3/8.13.3) with ESMTP id o66NUJdI008048; Tue, 6 Jul 2010 16:30:19 -0700 (PDT) (envelope-from cwt@networks.cwu.edu) Received: from localhost (cwt@localhost) by n.cwu.edu (8.13.3/8.13.1/Submit) with ESMTP id o66NUJGP008045; Tue, 6 Jul 2010 16:30:19 -0700 (PDT) (envelope-from cwt@networks.cwu.edu) X-Authentication-Warning: n.cwu.edu: cwt owned process doing -bs Date: Tue, 6 Jul 2010 16:30:19 -0700 (PDT) From: Chris Timmons X-X-Sender: cwt@n.cwu.edu To: Jeremy Chadwick In-Reply-To: <20100706141553.GA59650@icarus.home.lan> Message-ID: <20100706162540.C7567@n.cwu.edu> References: <20100706141553.GA59650@icarus.home.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.0 (nsc0.cwu.edu [72.233.196.16]); Tue, 06 Jul 2010 16:30:20 -0700 (PDT) Cc: freebsd-stable@freebsd.org, freebsd-hubs@freebsd.org, nickolasbug@gmail.com Subject: Re: csup: Invalid greeting from server 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, 06 Jul 2010 23:57:14 -0000 There was a problem with the server. It is updating at this moment and should be up-to-date quickly. Regards, -Chris On Tue, 6 Jul 2010, Jeremy Chadwick wrote: > On Tue, Jul 06, 2010 at 04:55:15PM +0300, nickolasbug@gmail.com wrote: >> Is everything OK with cvsup.freebsd.org? >> I got message "Invalid greeting from server" during last two days: >> >> csup -L 2 /etc/supfile >> Parsing supfile "/etc/supfile" >> Connecting to cvsup.freebsd.org >> Connected to 72.233.193.64 >> Invalid greeting from server >> >> My supfile looks like this: >> >> *default host=cvsup.freebsd.org >> *default base=/var/db >> *default prefix=/usr >> *default release=cvs >> *default compress delete use-rel-suffix >> >> src-all tag=RELENG_8 >> ports-all tag=. >> doc-all tag=. > > This should have been sent to freebsd-hubs. Adding to CC. > > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > _______________________________________________ > freebsd-hubs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hubs > To unsubscribe, send any mail to "freebsd-hubs-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 01:08:03 2010 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 64D8C106564A for ; Wed, 7 Jul 2010 01:08:03 +0000 (UTC) (envelope-from davideugenewarren@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0E2558FC15 for ; Wed, 7 Jul 2010 01:08:02 +0000 (UTC) Received: by vws6 with SMTP id 6so8751840vws.13 for ; Tue, 06 Jul 2010 18:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ECCCc7KlVgP8pyCHUWV2IEKwaYXipREjbd05QvoKYcg=; b=n3NQdwYo0lqwDy7tVs0PVkWA6ANx0ttYc837ujpXfzGO8YsPt7im5cmsYRk2jqpOsa WsFmsYEA+zNjKDxu3uHuaB9ny5p9iWsaby4iMTBT7pCJ+NqoR/1R1OaoS9r5Gvyl4Cku EYaBReFa273YCoo1GHGsLsq/21gG06SSIAbhQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LtKYaSYNm5YX3/exrb8K6hS1m1g0hETbOogX0tEfTzOUy9uz8eqiyMBTIhtRoRbTSj x/K4+fdfbCbGbH2+OENglt3zAMufYf8rJPWl+vrtoeJ9SgkdZ8X9PAzeae/IdoFdo5Pp g/hhxBZwbFYlw8G2r6hD4JHkl1CfykENCniN4= MIME-Version: 1.0 Received: by 10.220.62.72 with SMTP id w8mr2931016vch.209.1278464873424; Tue, 06 Jul 2010 18:07:53 -0700 (PDT) Received: by 10.220.190.1 with HTTP; Tue, 6 Jul 2010 18:07:53 -0700 (PDT) In-Reply-To: <20100706212830.GA63307@slackbox.erewhon.net> References: <20100705055105.GA21681@icarus.home.lan> <20100706174155.GA56410@slackbox.erewhon.net> <20100706203222.GA68830@icarus.home.lan> <20100706212830.GA63307@slackbox.erewhon.net> Date: Tue, 6 Jul 2010 20:07:53 -0500 Message-ID: From: David Warren To: Roland Smith Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Max Laier , freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: 8.0 network 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: Wed, 07 Jul 2010 01:08:03 -0000 Hi all, Max was on to something when he wrote: "Furthermore, remember that the OP can move to another NIC and the problem goes away[1]. I know there have been issues in the past reported with em(4) and pf ALTQ, but that isn't in use here." In fact, when I was testing possible firewall issues I had simply turned off pf rather than switched NICs. Swapping nfe0 and em0 into the int_if and ext_if roles, respectively, seems to have remedied the problem. This means that at least some of the problems that I was encountering stemmed from em's interactions with my Intel NIC, or em in combination with pf, or something along. I'm perplexed about the issue, but I'm satisfied with the network performance that I've got now. Notably, none of the changes to pf when em was still the internal interface had a substantial effect. I'd be happy to run more tests on the original setup if anyone wants to chase down whatever was causing those problems. Let me know, and many thanks to all. Take care, Dave On Tue, Jul 6, 2010 at 4:28 PM, Roland Smith wrote: > On Tue, Jul 06, 2010 at 01:32:22PM -0700, Jeremy Chadwick wrote: > > Back to the problem at hand: > > > > I wonder if it's lack of "quick" on some rules which is causing the > > problem; hard to say, > > That would stop evaluation of further rules, sure. But it seems most of the > rules concern the external interface. > > _Assuming_ that the samba clients are on the internal interface, it would > make > sense to put the few rules concerning that interface as early as possible > in > the list of filter rules, and indeed add the quick keyword. > > Alternatively, one could consider adding this interface to the list of > skipped > interfaces. This would at least be useful for testing purposes, since it > would > preclude pf from processing packages on this interface. If this fixes the > problem, there is some problem in the ruleset. > > > and I'm not sure how to "benchmark" pf. > > Looking at the output of 'pfctl -vvs rules' would be a start, I think. If > the > rules that are matched most are at the end of the filter rules, all > previous > rules are evaluated, AFAIK. For more info try 'pfctl -vvs all'. > > In the past I found it useful to set up a point-to-point connection between > two FreeBSD machines, and then do some throughput measusrements using > e.g. nc(1). Start with pf disabled, then enhance the ruleset rule-by-rule > and > see if performance is influenced. A couple of years ago I did this, and > IIRC > the largest influence I could find was the type of ethernet adapter > used. Can't find any notes from that experiment but I could repeat it if is > deemed interesting. > > > Furthermore, remember that the OP can move to another NIC and the > > problem goes away[1]. I know there have been issues in the past > > reported with em(4) and pf ALTQ, but that isn't in use here. > > There are lots of other crappy ethernet adapters out there. E.g. re(4) and > rl(4) tend to suck in my experience. Of course if the hardware was changed > but > not the relevant filter rules, it would default to "pass". :-) > > Roland > -- > 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) > -- Post-doctoral Fellow Neurology Department University of Iowa Hospitals and Clinics davideugenewarren@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 02:42:21 2010 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 F08721065670 for ; Wed, 7 Jul 2010 02:42:21 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id 85F978FC15 for ; Wed, 7 Jul 2010 02:42:21 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta09.westchester.pa.mail.comcast.net with comcast id eqfd1e00127AodY59qiMUE; Wed, 07 Jul 2010 02:42:21 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta19.westchester.pa.mail.comcast.net with comcast id eqiK1e0093LrwQ23fqiK4m; Wed, 07 Jul 2010 02:42:21 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F41269B425; Tue, 6 Jul 2010 19:42:17 -0700 (PDT) Date: Tue, 6 Jul 2010 19:42:17 -0700 From: Jeremy Chadwick To: Daniel O'Connor Message-ID: <20100707024217.GA77748@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Stable , freebsd-ports@freebsd.org Subject: Re: MIMEDefang not starting on reboot 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, 07 Jul 2010 02:42:22 -0000 On Wed, Jul 07, 2010 at 08:35:28AM +0930, Daniel O'Connor wrote: > Does anyone else see this? > I have 2 (of 2) amd64 8.x systems which don't start MIMEDefang on reboot properly, I get this.. > > Jul 7 06:34:58 cain mimedefang-multiplexor[1747]: Starting slave 3 (pid 41198) (1 running): Bringing slaves up to minSlaves (2) > Jul 7 06:34:58 cain mimedefang-multiplexor[1747]: Slave 3 stderr: Can't load '/usr/local/lib/perl5/5.10.1/mach/auto/File/Glob/Glob.so' for module File::Glob: /usr/local/lib/perl5/5.10.1/mach/auto/File/Glob/Glob.so: mmap of entire address space failed: Cannot allocate memory at /usr/local/lib/perl5/5.10.1/mach/XSLoader.pm line 70. at /usr/local/lib/perl5/5.10.1/mach/File/Glob.pm line 96 Compilation failed in require at /usr/local/bin/mimedefang.pl line 3239. BEGIN failed--compilation aborted at /usr/local/bin/mimedefang.pl line 3239. > > Restarting it manually (ie /usr/local/etc/rc.d/mimedefang.sh restart) after a reboot fixes it.. > > Also I think it would be nice if this patch were added to the port.. > > --- /usr/local/etc/rc.d/mimedefang.sh-dist 2010-04-07 10:30:46.586067014 +0930 > +++ /usr/local/etc/rc.d/mimedefang.sh 2010-05-01 13:47:47.340517685 +0930 > @@ -316,7 +319,7 @@ > rm -f $MX_SOCKET > /dev/null 2>&1 > rm -f $SOCKET > /dev/null 2>&1 > > - if [ "$1" = "wait" ] ; then > + if [ "wait" = "wait" ] ; then > printf "Waiting for daemons to exit." > WAITPID="" > test -f $PID && WAITPID=`cat $PID` > > Otherwise restart is useless because it starts MD without waiting for the old one to stop and it doesn't work :( This should probably go to freebsd-ports not -stable, since both mimedefang and perl are ports things. CC'ing. Also, that patch doesn't look correct, or you got your diff arguments backwards (e.g. change should be fixing the wait=wait comparison to use $1=wait). -- | Jeremy Chadwick jdc@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 Wed Jul 7 02:44:06 2010 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 122651065694; Wed, 7 Jul 2010 02:44:06 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 896818FC0A; Wed, 7 Jul 2010 02:44:05 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.44]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id o672gOSg091432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Jul 2010 12:13:53 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Daniel O'Connor" In-Reply-To: <20100707024217.GA77748@icarus.home.lan> Date: Wed, 7 Jul 2010 12:13:53 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <4BB8A521-E50D-4A0C-AEBA-6883BFD5846B@gsoft.com.au> References: <20100707024217.GA77748@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1081) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: FreeBSD Stable , freebsd-ports@freebsd.org Subject: Re: MIMEDefang not starting on reboot 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, 07 Jul 2010 02:44:06 -0000 On 07/07/2010, at 12:12, Jeremy Chadwick wrote: >> --- /usr/local/etc/rc.d/mimedefang.sh-dist 2010-04-07 = 10:30:46.586067014 +0930 >> +++ /usr/local/etc/rc.d/mimedefang.sh 2010-05-01 13:47:47.340517685 = +0930 >> @@ -316,7 +319,7 @@ >> rm -f $MX_SOCKET > /dev/null 2>&1 >> rm -f $SOCKET > /dev/null 2>&1 >>=20 >> - if [ "$1" =3D "wait" ] ; then >> + if [ "wait" =3D "wait" ] ; then >> printf "Waiting for daemons to exit." >> WAITPID=3D"" >> test -f $PID && WAITPID=3D`cat $PID` >>=20 >> Otherwise restart is useless because it starts MD without waiting for = the old one to stop and it doesn't work :( >=20 > This should probably go to freebsd-ports not -stable, since both > mimedefang and perl are ports things. CC'ing. True. > Also, that patch doesn't look correct, or you got your diff arguments > backwards (e.g. change should be fixing the wait=3Dwait comparison to > use $1=3Dwait). No, really, I want it to always succeed. The optional wait appears to be a Linux thing, however rc.d scripts on = FreeBSD [should] always wait for their daemons to exit, otherwise = restart will try and start it before it has exited. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 03:17:48 2010 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 C62C9106564A for ; Wed, 7 Jul 2010 03:17:48 +0000 (UTC) (envelope-from askjuise@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 234598FC15 for ; Wed, 7 Jul 2010 03:17:47 +0000 (UTC) Received: by vws6 with SMTP id 6so8909997vws.13 for ; Tue, 06 Jul 2010 20:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=oeO0mFeHcdID5DydDVEkYpm6Nxu59oiG2Du89LRWZFU=; b=QuI/q1+wuEzD8xoO/g5zeK3UoStMFzQM7x/zrP302HFkDRyJyTRbbbPMUBhoSyqI7h +1Xs8wt2o9284fb1xtsxMlM2uxWR1uKyOp2awkKHGjvHJh5VVrsj/sUX7nx5APp3l4RL RmpcRNg7On1JS5T1BnvfRvyfHJyKNU6lHcVF0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Qt4lU46m3GiCSlLGgoIwixTjwSLQJW8sz44U/SXfy9tFlcK3H0Iyzhtm5CCOPZS/G9 lL8q4c/mQxSEVx14SgSLXGZT+f2PZNk3zGH4KMz7o4yxOfYr3+XvmUurRUoIcFZgXNVD uPTVZDCn8KfsWU2uV0icCZTa4tSgMs+H91YBA= MIME-Version: 1.0 Received: by 10.229.224.196 with SMTP id ip4mr3314173qcb.138.1278472661460; Tue, 06 Jul 2010 20:17:41 -0700 (PDT) Received: by 10.229.189.212 with HTTP; Tue, 6 Jul 2010 20:17:41 -0700 (PDT) In-Reply-To: References: <20100706141553.GA59650@icarus.home.lan> <20100706162540.C7567@n.cwu.edu> Date: Wed, 7 Jul 2010 11:17:41 +0800 Message-ID: From: Alexander Petrovsky To: freebsd-stable@freebsd.org, freebsd-hubs@freebsd.org, nickolasbug@gmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Fwd: csup: Invalid greeting from server 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, 07 Jul 2010 03:17:48 -0000 May be you should use some thing like this - cvsup.en.freebsd.org? Why you try use root cvs servers? 2010/7/7 Chris Timmons > There was a problem with the server. It is updating at this moment and > should be up-to-date quickly. > > Regards, > -Chris > > On Tue, 6 Jul 2010, Jeremy Chadwick wrote: > > On Tue, Jul 06, 2010 at 04:55:15PM +0300, nickolasbug@gmail.com wrote: >> >>> Is everything OK with cvsup.freebsd.org? >>> I got message "Invalid greeting from server" during last two days: >>> >>> csup -L 2 /etc/supfile >>> Parsing supfile "/etc/supfile" >>> Connecting to cvsup.freebsd.org >>> Connected to 72.233.193.64 >>> Invalid greeting from server >>> >>> My supfile looks like this: >>> >>> *default host=3Dcvsup.freebsd.org >>> *default base=3D/var/db >>> *default prefix=3D/usr >>> *default release=3Dcvs >>> *default compress delete use-rel-suffix >>> >>> src-all tag=3DRELENG_8 >>> ports-all tag=3D. >>> doc-all tag=3D. >>> >> >> This should have been sent to freebsd-hubs. Adding to CC. >> >> -- >> | Jeremy Chadwick jdc@parodius.com | >> | Parodius Networking http://www.parodius.com/ | >> | UNIX Systems Administrator Mountain View, CA, USA | >> | Making life hard for others since 1977. PGP: 4BD6C0CB | >> >> _______________________________________________ >> freebsd-hubs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hubs >> To unsubscribe, send any mail to "freebsd-hubs-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" > --=20 =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2=D1=81=D0=BA=D0=B8=D0=B9 =D0=90=D0=BB= =D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 / Alexander Petrovsky, ICQ: 350342118 Jabber: juise@jabber.ru Phone: +7 914 8 820 815 --=20 =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2=D1=81=D0=BA=D0=B8=D0=B9 =D0=90=D0=BB= =D0=B5=D0=BA=D1=81=D0=B0=D0=BD=D0=B4=D1=80 / Alexander Petrovsky, ICQ: 350342118 Jabber: juise@jabber.ru Phone: +7 914 8 820 815 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 13:04:51 2010 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 5453D106566B for ; Wed, 7 Jul 2010 13:04:51 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailD.acsu.buffalo.edu (localmailD.acsu.buffalo.edu [128.205.5.208]) by mx1.freebsd.org (Postfix) with ESMTP id 233DB8FC13 for ; Wed, 7 Jul 2010 13:04:50 +0000 (UTC) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B3A07EF2B for ; Wed, 7 Jul 2010 09:04:43 -0400 (EDT) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailD.acsu.buffalo.edu (Postfix) with ESMTP id 36F5919ACD for ; Wed, 7 Jul 2010 09:04:43 -0400 (EDT) Received: from mweb2.acsu.buffalo.edu (mweb2.acsu.buffalo.edu [128.205.5.239]) by localmailD.acsu.buffalo.edu (Prefixe) with ESMTP id 3167519A89 for ; Wed, 7 Jul 2010 09:04:43 -0400 (EDT) Received: from [128.205.32.76] (bauer.cse.Buffalo.EDU [128.205.32.76]) by mweb2.acsu.buffalo.edu (Postfix) with ESMTP id 185A34C4006 for ; Wed, 7 Jul 2010 09:04:43 -0400 (EDT) From: Ken Smith To: freebsd-stable In-Reply-To: <1278081504.83414.26.camel@bauer.cse.buffalo.edu> References: <1278081504.83414.26.camel@bauer.cse.buffalo.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-FWG/013sPXzpbyIh6ZGm" Date: Wed, 07 Jul 2010 09:04:42 -0400 Message-ID: <1278507882.46615.6.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Subject: Re: FreeBSD 8.1-RC2 Available... 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, 07 Jul 2010 13:04:51 -0000 --=-FWG/013sPXzpbyIh6ZGm Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Fri, 2010-07-02 at 10:38 -0400, Ken Smith wrote: > At this time DVD images are not available. There was a fairly serious > security issue with the png graphics package. We will generate DVD > images when the rebuilt packages become available, that will be > announced then the images are ready. I just finished uploading the DVD images for amd64 and i386 to the master FTP site. It will take a few hours for them to propagate to the mirrors. Checksums are: MD5 (FreeBSD-8.1-RC2-amd64-dvd1.iso) =3D 9b8f71cdfc8e9b9f7238a843b85cd24d MD5 (FreeBSD-8.1-RC2-i386-dvd1.iso) =3D 15f60953db9940551504193c4433c43f SHA256 (FreeBSD-8.1-RC2-amd64-dvd1.iso) =3D a003d660870602d7aa5c829aa1c450f= 406d09b03af66ba175dd8392523399110 SHA256 (FreeBSD-8.1-RC2-i386-dvd1.iso) =3D 0bfbcd222f45e60be4806f622fd9dbb7= 4a2ebb0bd56612f3fff5bf7db07249e1 --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-FWG/013sPXzpbyIh6ZGm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAkw0e2IACgkQ/G14VSmup/ZPsQCggZ6wghwjNSLWl90Y05XyNKPO L6cAnjPvr15HuoY0wODOti1IrdkcKOhN =m+MO -----END PGP SIGNATURE----- --=-FWG/013sPXzpbyIh6ZGm-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 18:22:24 2010 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 68B5D1065672 for ; Wed, 7 Jul 2010 18:22:24 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id 270708FC1C for ; Wed, 7 Jul 2010 18:22:23 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o67IMM2q011821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jul 2010 14:22:23 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o67IMM55026248; Wed, 7 Jul 2010 14:22:22 -0400 Message-ID: <4C34C5DE.7040007@aldan.algebra.com> Date: Wed, 07 Jul 2010 14:22:22 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, re@freebsd.org, freebsd-usb@freebsd.org, tom@hur.st Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: 8.x grudges 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, 07 Jul 2010 18:22:24 -0000 I'm upgrading several systems these days to the 8.1 (pre-release) and have hit the following troubles... I could file a formal PR for each, I suppose, but, maybe, this way will get the right people's attention sooner. In no particular order: 1. A picture, that one of the systems was displaying at boot (and then used as a screen-saver), stopped showing properly. The colors are right, but the picture is distorted beyond recognition. The relevant part of loader.conf is: splash_pcx_load="YES" vesa_load="YES" bitmap_load="YES" bitmap_name="/boot/187426-9-quokka-dreaming.pcx" the picture file is identified as: PCX 772x551 772x551+0+0 8-bit PseudoClass 256c 454KB 0.039u 0:00.093 2. FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and thus not an "option") -- the kernel-config files, that worked with 7.x, break without this option in them (in addition to all the nuisance, that's documented in UPDATING -- which, somehow, makes the breakage acceptable). config(8) would not warn about this, but kernel build fails. 3. Likewise, having "device ugen" breaks config(8) -- another undocumented incompatibility. 4. The sio(4) is described in UPDATING as "removed", but rouses no complaint from config(8) either. It just breaks the kernel build... It should be an alias for uart, IMHO -- all I want is for my serial ports to be usable, whether their driver is called "Serial Input/Output" or "Universal Asynchronous Receiver and Transmitter". (BTW, about the /dev-entries -- do we /really/ have to change the names of the serial port-devices every couple of years? It is rather painful to reconfigure the fax- and ppp-software, etc.) How does the Microsoft world manage to stay with the COM1, COM2 for decades?) 5. One of the upgraded systems would repeatedly hang at boot, until I disabled the on-board firewire-device through the BIOS... It was not a problem under 7.x, although I don't know, whether the device actually worked. 6. Despite the reported improvements in the USB area, my USB keyboard /still/ does not work during boot. It during POST and then after the booting is complete. But in single-user mode -- no... Had to fish-out the PS2 keyboard... 7. All my "dangerously dedicated" disks lost the "s1" in the subdevice-names after the upgrade: /dev/da1s1d became /dev/da1d, etc. I like the shorter names (and there are, indeed, no "slices" there), but having to fix them manually upon reboot was unpleasant and uncalled for. As with uart/sio, backward-compatibility aliases are a fine idea and really improves user's experience... 8. I tried to do an install on one of the systems via netbooting (pxeload) the disk1-image. It booted, but the sysinstall had to be started manually and, once started, did not act the same as when booted off of CD-ROM. Seems like a simple bit to correct so that setting "init" to /usr/sbin/sysinstall/manually on every boot/ is not necessary... 9. The k8temp utility (installed by sysutils/k8temp ), which worked fine on both of my AMD-machines, no longer works on the Athlon one (still works on the Opteron-based server). I reinstalled the port, but that did not help -- the utility runs, but does not say anything. Requeting debug-info is of little help: *root*@quokka:~ (101) k8temp *root*@quokka:~ (102) k8temp -d CPUID: Vendor: AuthenticAMD, 0x6a0: Model=0a Family=6+0 Stepping=0 Advanced Power Management=0x1 Temperature sensor: Yes Frequency ID control: No Voltage ID control: No THERMTRIP support: No HW Thermal control: No SW Thermal control: No 100MHz multipliers: No HW P-State control: No TSC Invariant: No If any of the above can be corrected or, at least, documented, before release, we stand a little bit better chance of getting the praise otherwise well-deserved by FreeBSD... Thanks. Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 18:30:46 2010 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 462CF106566C for ; Wed, 7 Jul 2010 18:30:46 +0000 (UTC) (envelope-from sektie@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id EE5CD8FC08 for ; Wed, 7 Jul 2010 18:30:45 +0000 (UTC) Received: by vws6 with SMTP id 6so10029344vws.13 for ; Wed, 07 Jul 2010 11:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=jtQw3Cfp1hsKvZI0iZ/waRknjHKh2zdtRpghE9UgfaI=; b=ZIVBhaeO4IOH99ra/5vP/TyAgpmkpGx/cMV4kISWsQclbUzJ7f+gMOprfNNP4DV7Ba nPJGyrZ4Oq5YMdaeuXxmxgDFCaM1fPg7CpKrCULe8nXF1pBZL+WkJ77zhyEsMMGNJdem mBJHD274DmLDSzmiVJnq36Rwf+87nj7LzSWJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=KGEGu6ouKJV0cEFl2XJSwFSscSvATJArthOifM8+Xa8OeNWZm7mVvn1zQp8YbeerJI jzU/N5pBYkffFCDEJmcegPiPunuUa02/QB8fnvLvTKfhHOwGqHYNFh+M/RAAWmlOi5NK 9RRP2cpfNx1A7AfnTTPsobErkROIQL1QxX/l8= MIME-Version: 1.0 Received: by 10.220.60.204 with SMTP id q12mr3591593vch.20.1278527442621; Wed, 07 Jul 2010 11:30:42 -0700 (PDT) Sender: sektie@gmail.com Received: by 10.220.174.42 with HTTP; Wed, 7 Jul 2010 11:30:42 -0700 (PDT) In-Reply-To: <4C34C5DE.7040007@aldan.algebra.com> References: <4C34C5DE.7040007@aldan.algebra.com> Date: Wed, 7 Jul 2010 11:30:42 -0700 X-Google-Sender-Auth: kyosr-ONR7g-jkXuZHgS-bavUHc Message-ID: From: Randi Harper To: "Mikhail T." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: 8.x grudges 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, 07 Jul 2010 18:30:46 -0000 On Wed, Jul 7, 2010 at 11:22 AM, Mikhail T. wro= te: > =A08. > =A0 =A0 I tried to do an install on one of the systems via netbooting > =A0 =A0 (pxeload) the disk1-image. It booted, but the sysinstall had to b= e > =A0 =A0 started manually and, once started, did not act the same as when > =A0 =A0 booted off of CD-ROM. Seems like a simple bit to correct so that > =A0 =A0 setting "init" to /usr/sbin/sysinstall/manually on every boot/ is > =A0 =A0 not necessary... This shouldn't be the case. IIRC, nothing has changed that would cause this. More info on your environment please? From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 18:43:04 2010 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 990561065677 for ; Wed, 7 Jul 2010 18:43:04 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from eterpe-smout.broadpark.no (eterpe-smout.broadpark.no [80.202.8.16]) by mx1.freebsd.org (Postfix) with ESMTP id 546278FC19 for ; Wed, 7 Jul 2010 18:43:03 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ignis-smin.broadpark.no ([unknown] [80.202.8.11]) by eterpe-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-12.01 64bit (built Oct 15 2009)) with ESMTP id <0L5700AA9ANN58C0@eterpe-smout.broadpark.no> for freebsd-stable@freebsd.org; Wed, 07 Jul 2010 20:42:59 +0200 (CEST) Received: from kg-v2.kg4.no ([unknown] [80.203.92.186]) by ignis-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-12.01 64bit (built Oct 15 2009)) with SMTP id <0L5700885ANNGVG0@ignis-smin.broadpark.no> for freebsd-stable@freebsd.org; Wed, 07 Jul 2010 20:42:59 +0200 (CEST) Date: Wed, 07 Jul 2010 20:42:59 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100707204259.6e22c28d.torfinn.ingolfsen@broadpark.no> In-reply-to: <4C34C5DE.7040007@aldan.algebra.com> References: <4C34C5DE.7040007@aldan.algebra.com> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: 8.x grudges 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, 07 Jul 2010 18:43:04 -0000 On Wed, 07 Jul 2010 14:22:22 -0400 "Mikhail T." wrote: > 9. > The k8temp utility (installed by sysutils/k8temp > ), which worked fine on > both of my AMD-machines, no longer works on the Athlon one (still > works on the Opteron-based server). In case you are not aware of it: amdtemp(4) performs the same function (more or less) as k8temp. HTH -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 18:59:31 2010 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 CC1F7106566C for ; Wed, 7 Jul 2010 18:59:31 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 7894E8FC08 for ; Wed, 7 Jul 2010 18:59:31 +0000 (UTC) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta02.westchester.pa.mail.comcast.net with comcast id ezc61e0081wpRvQ526zXKL; Wed, 07 Jul 2010 18:59:31 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta18.westchester.pa.mail.comcast.net with comcast id f6zV1e00Y3LrwQ23e6zWp4; Wed, 07 Jul 2010 18:59:31 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 7111D9B423; Wed, 7 Jul 2010 11:59:28 -0700 (PDT) Date: Wed, 7 Jul 2010 11:59:28 -0700 From: Jeremy Chadwick To: "Mikhail T." Message-ID: <20100707185928.GA16180@icarus.home.lan> References: <4C34C5DE.7040007@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C34C5DE.7040007@aldan.algebra.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: re@freebsd.org, tom@hur.st, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: 8.x grudges 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, 07 Jul 2010 18:59:31 -0000 On Wed, Jul 07, 2010 at 02:22:22PM -0400, Mikhail T. wrote: > I'm upgrading several systems these days to the 8.1 (pre-release) > and have hit the following troubles... I could file a formal PR for > each, I suppose, but, maybe, this way will get the right people's > attention sooner. > > 2. > FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and > thus not an "option") -- the kernel-config files, that worked with > 7.x, break without this option in them (in addition to all the > nuisance, that's documented in UPDATING -- which, somehow, makes > the breakage acceptable). config(8) would not warn about this, but > kernel build fails. We don't use this option (meaning it's removed from our kernels). It's definitely not required. All it does is ensure your kernel can comprehend executables/binaries built on 7.x. > 3. > Likewise, having "device ugen" breaks config(8) -- another > undocumented incompatibility. This sounds like you not including all of the necessary USB/device framework in your kernel configuration. You're not providing enough output for us to help diagnose the problem, though. Be aware that config(8) changed during recent days and requires a rebuild, although the build infrastructure normally instructs you to do this (otherwise kernel won't build). I noticed it when upgrading from an "early" version of RELENG_8 to a more recent version, and it was kind enough to tell me to rebuild it. > 4. > The sio(4) is described in UPDATING as "removed", but rouses no > complaint from config(8) either. It just breaks the kernel > build... It should be an alias for uart, IMHO -- all I want is for > my serial ports to be usable, whether their driver is called > "Serial Input/Output" or "Universal Asynchronous Receiver and > Transmitter". I disagree (re: "it should be an alias"). sio(4) is deprecated (meaning it's not used by default any more), and it's left in the driver tree solely as a fall-back method if someone runs into uart(4) problems. I'm sure it'll eventually be removed, but for now, it remains. The point I'm going to make here is this: sio(4) is different than uart(4). "Aliasing" one to the other will do nothing but confuse folks. If we're going to do that, why not rename all of our Ethernet interfaces "ethX" and so on? ;-) I'll take a moment to point out that your complaints about the kernel configuration file, so far, seem to stem from you not "migrating" your kernel configuration from 7.x to 8.x. Things change -- that's the reality of the situation. The way I do this is, when upgrading major releases (7.x->8.x), to "start fresh" using GENERIC as my base template and then adding/adjusting while comparing against the older kernels' config. Others do it differently, this is just how I do it. > (BTW, about the /dev-entries -- do we /really/ have to change the > names of the serial port-devices every couple of years? It is > rather painful to reconfigure the fax- and ppp-software, etc.) How > does the Microsoft world manage to stay with the COM1, COM2 for > decades?) Like I said: things change. > 5. > One of the upgraded systems would repeatedly hang at boot, until I > disabled the on-board firewire-device through the BIOS... It was > not a problem under 7.x, although I don't know, whether the device > actually worked. This is a commonly-reported problem, assuming "at boot" you mean "while the kernel is starting". Or unless you're using a certain model of Shuttle box, but that turned out to be literally a BIOS bug: http://koitsu.wordpress.com/2009/05/22/shuttle-sg45h7-firewire-bug-in-bios-sg45u10o/ > 6. > Despite the reported improvements in the USB area, my USB keyboard > /still/ does not work during boot. It during POST and then after > the booting is complete. But in single-user mode -- no... Had to > fish-out the PS2 keyboard... This is also a commonly-reported problem (and one I've harped on as well). When you say "during boot": does it work during loader (the screen with the "FreeBSD" logo on it)? If the keyboard works during loader but not once the kernel + kernel USB stack loads (e.g. when booting into single-user), then look at the very bottom of this page for a couple things to try: http://wiki.freebsd.org/BugBusting/Commonly_reported_issues If the keyboard DOES NOT work during loader, then it sounds like your BIOS isn't setting the system up so that USB keyboards get emulated as PS/2 (this setup gets stomped by the kernel later, obviously). Usually BIOSes offer an option like "USB Legacy Enable" or "USB Keyboard Enable" which provides this functionality. It's important to remember that there is no USB stack loaded via the bootstraps, which focus on your system/BIOS. Linux and Solaris have the same problem, as I understand it. Welcome to PC architecture "evolution", if you can call it that. :-) Regardless, this is one of the reasons I still have not made the move to USB keyboards and stick with PS/2 keyboards on FreeBSD. > 7. > All my "dangerously dedicated" disks lost the "s1" in the > subdevice-names after the upgrade: /dev/da1s1d became /dev/da1d, > etc. I like the shorter names (and there are, indeed, no "slices" > there), but having to fix them manually upon reboot was unpleasant > and uncalled for. As with uart/sio, backward-compatibility aliases > are a fine idea and really improves user's experience... Again: things change. "Dangerously dedicated" disks are commonly deprecated at this point (as I understand it folks are trying to get away from them). GEOM takes care of this situation better than it used to. You'll probably find some other situations (using bsdlabel, etc. vs. using gpart (don't confuse this with GPT)) where things may get a little hairy based on your setup. I would have formatted the disk and gone from a clean slate. Re: aliases: see above. > 8. > I tried to do an install on one of the systems via netbooting > (pxeload) the disk1-image. It booted, but the sysinstall had to be > started manually and, once started, did not act the same as when > booted off of CD-ROM. Seems like a simple bit to correct so that > setting "init" to /usr/sbin/sysinstall/manually on every boot/ is > not necessary... Can't reproduce: http://jdc.parodius.com/freebsd/pxeboot_serial_install.html > 9. > The k8temp utility (installed by sysutils/k8temp > ), which worked fine on > both of my AMD-machines, no longer works on the Athlon one (still > works on the Opteron-based server). I reinstalled the port, but > that did not help -- the utility runs, but does not say anything. > Requeting debug-info is of little help: > > *root*@quokka:~ (101) k8temp > *root*@quokka:~ (102) k8temp -d > CPUID: Vendor: AuthenticAMD, 0x6a0: Model=0a Family=6+0 Stepping=0 > Advanced Power Management=0x1 > Temperature sensor: Yes > Frequency ID control: No > Voltage ID control: No > THERMTRIP support: No > HW Thermal control: No > SW Thermal control: No > 100MHz multipliers: No > HW P-State control: No > TSC Invariant: No Try loading the kernel module amdtemp and see if things improve. Be sure to read the man page. Hardware monitoring/thermal monitoring at this point is often implemented into the sysctl tree (Intel CPUs are done this way with coretemp(4), and ACPI thermal zones too). HTH. -- | Jeremy Chadwick jdc@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 Wed Jul 7 19:35:11 2010 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 D852F1065676; Wed, 7 Jul 2010 19:35:11 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 844CC8FC16; Wed, 7 Jul 2010 19:35:11 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o67JYtRG008224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Jul 2010 12:34:55 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 786CD1CC0D; Wed, 7 Jul 2010 12:34:55 -0700 (PDT) To: "Mikhail T." In-reply-to: Your message of "Wed, 07 Jul 2010 14:22:22 EDT." <4C34C5DE.7040007@aldan.algebra.com> Date: Wed, 07 Jul 2010 12:34:55 -0700 From: "Kevin Oberman" Message-Id: <20100707193455.786CD1CC0D@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-07_03:2010-02-06, 2010-07-07, 2010-07-07 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1007070089 Cc: re@freebsd.org, tom@hur.st, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: 8.x grudges 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, 07 Jul 2010 19:35:11 -0000 > Date: Wed, 07 Jul 2010 14:22:22 -0400 > From: "Mikhail T." > Sender: owner-freebsd-stable@freebsd.org > > I'm upgrading several systems these days to the 8.1 (pre-release) and > have hit the following troubles... I could file a formal PR for each, I > suppose, but, maybe, this way will get the right people's attention sooner. > > In no particular order: > > 1. > A picture, that one of the systems was displaying at boot (and > then used as a screen-saver), stopped showing properly. The > colors are right, but the picture is distorted beyond recognition. > The relevant part of loader.conf is: > > splash_pcx_load="YES" > vesa_load="YES" > bitmap_load="YES" > bitmap_name="/boot/187426-9-quokka-dreaming.pcx" > > the picture file is identified as: > > PCX 772x551 772x551+0+0 8-bit PseudoClass 256c 454KB 0.039u > 0:00.093 > > 2. > FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and > thus not an "option") -- the kernel-config files, that worked with > 7.x, break without this option in them (in addition to all the > nuisance, that's documented in UPDATING -- which, somehow, makes > the breakage acceptable). config(8) would not warn about this, but > kernel build fails. FREEBSD_COMPAT7 is certainly an option. I build without it just fine. But "the kernel-config files, that worked with 7.x, break without this option in them" I think points to your real problem. > 3. > Likewise, having "device ugen" breaks config(8) -- another > undocumented incompatibility. It certainly does. ugen is no longer a valid device with the new USB stack in 8. (It is essentially built into the base USB driver.) It seems that you expect to be able to build a kernel for V8 using a V7 configuration file. THIS WILL NOT WORK! You must always re-do customizations when performing a major version upgrade. You should always start with GENERIC for a major version and make the required changes to it. I believe the current recommendation is to "include GENERIC" in your custom kernel configuration and then add or delete options and devices as desired. (This probably works best if your config file is close to GENERIC.) > 4. > The sio(4) is described in UPDATING as "removed", but rouses no > complaint from config(8) either. It just breaks the kernel > build... It should be an alias for uart, IMHO -- all I want is for > my serial ports to be usable, whether their driver is called > "Serial Input/Output" or "Universal Asynchronous Receiver and > Transmitter". > (BTW, about the /dev-entries -- do we /really/ have to change the > names of the serial port-devices every couple of years? It is > rather painful to reconfigure the fax- and ppp-software, etc.) How > does the Microsoft world manage to stay with the COM1, COM2 for > decades?) This would be nice, but the sio and uart drivers have co-existed for quite a while. They could not have the same name. Of course, a it would have been possible to rename the uart driver to sio when sio was removed or make it an alias, but that was not done. I suspect primarily to not break things when people discovered that sio and uart are NOT the same in the way they work. Not an issue for most, since they are close. > 5. > One of the upgraded systems would repeatedly hang at boot, until I > disabled the on-board firewire-device through the BIOS... It was > not a problem under 7.x, although I don't know, whether the device > actually worked. Odd. Sounds like a bug. I don't have a firewire port, so I have no idea about this. > 6. > Despite the reported improvements in the USB area, my USB keyboard > /still/ does not work during boot. It during POST and then after > the booting is complete. But in single-user mode -- no... Had to > fish-out the PS2 keyboard... All I can say is that it works fine for me. It may be tied to your building a V8 kernel with a V7 config. It may also be tied to having libusb from ports installed. Since libusb is now part of the base system, having the ports version around can break lots of USB stuff. > 7. > All my "dangerously dedicated" disks lost the "s1" in the > subdevice-names after the upgrade: /dev/da1s1d became /dev/da1d, > etc. I like the shorter names (and there are, indeed, no "slices" > there), but having to fix them manually upon reboot was unpleasant > and uncalled for. As with uart/sio, backward-compatibility aliases > are a fine idea and really improves user's experience... No, this one is due to a major re-structuring of how disks work in V8. As has been oft noted, "dangerously dedicated" is called that because it IS dangerous. While commonly used, it does not play nicely with standards and is prone to some fairly serious potential issues on upgrade. "dangerously dedicated" has been marked as "use it at your own risk", so you are likely to see issues (in this case a fairly minor one). > 8. > I tried to do an install on one of the systems via netbooting > (pxeload) the disk1-image. It booted, but the sysinstall had to be > started manually and, once started, did not act the same as when > booted off of CD-ROM. Seems like a simple bit to correct so that > setting "init" to /usr/sbin/sysinstall/manually on every boot/ is > not necessary... Have not tried this. > 9. > The k8temp utility (installed by sysutils/k8temp > ), which worked fine on > both of my AMD-machines, no longer works on the Athlon one (still > works on the Opteron-based server). I reinstalled the port, but > that did not help -- the utility runs, but does not say anything. > Requeting debug-info is of little help: > > *root*@quokka:~ (101) k8temp > *root*@quokka:~ (102) k8temp -d > CPUID: Vendor: AuthenticAMD, 0x6a0: Model=0a Family=6+0 Stepping=0 > Advanced Power Management=0x1 > Temperature sensor: Yes > Frequency ID control: No > Voltage ID control: No > THERMTRIP support: No > HW Thermal control: No > SW Thermal control: No > 100MHz multipliers: No > HW P-State control: No > TSC Invariant: No k8temp is for older AMD system running K8 cores. It has been mostly replaced with amdtemp which works on newer cores. I'm not sure if amdtemp will work on K8 cores, though. > If any of the above can be corrected or, at least, documented, before > release, we stand a little bit better chance of getting the praise > otherwise well-deserved by FreeBSD... Thanks. Yours, Documentation in FreeBSD seems quite a bit better than that of other open source projects, but it is not perfect and the handbook, in particular, will always lag a bit. Feel free to contribute suggested changes to the documentation team (doc@). I hope to spend a bit of time in this area after I retire. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 20:00:37 2010 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 78FC5106564A for ; Wed, 7 Jul 2010 20:00:37 +0000 (UTC) (envelope-from sektie@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 191E48FC12 for ; Wed, 7 Jul 2010 20:00:36 +0000 (UTC) Received: by vws6 with SMTP id 6so82541vws.13 for ; Wed, 07 Jul 2010 13:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ofYZRiA8P0S9uzRpJRluyj6l9svx5oXMWFkwAfIHW+4=; b=kbDhzyHIvGpHrTcZjV52B31sMGIpnhykxBeOgHA2W7rleKOtFgcahRODhyMs4R4VM1 TVoxXVylw0it+gQkVbf/Fy8QJ48WdBAwFyk5iBs1N8MQ3cUd3zPzzlv5zOfwgahkl+du 2cVVKVwo2Ig+IrapnZpfodyfBgy1nl3OqHvBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rwrt3ubMwa+U46ceswqtPo99DcdPAT1Wb7yy/KT8r/ndxRtXXKEttEWBljp5AZrQB4 4ybq+b3JQs/8wFevCu8KYXeT+ZyUmaHLSWDxC0XLUPmi4gb4Fsk0ryBqPSmZfbOZqK6Q oYxNsAtQwlkdela337Q+SHT2U0/+mlPoHBJxY= MIME-Version: 1.0 Received: by 10.220.126.166 with SMTP id c38mr3648119vcs.192.1278532832484; Wed, 07 Jul 2010 13:00:32 -0700 (PDT) Sender: sektie@gmail.com Received: by 10.220.174.42 with HTTP; Wed, 7 Jul 2010 13:00:32 -0700 (PDT) In-Reply-To: <4C34CA31.7010804@aldan.algebra.com> References: <4C34C5DE.7040007@aldan.algebra.com> <4C34CA31.7010804@aldan.algebra.com> Date: Wed, 7 Jul 2010 13:00:32 -0700 X-Google-Sender-Auth: 9lkIccVFMgJKLS3rnTSs-jrbAtk Message-ID: From: Randi Harper To: "Mikhail T." Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: net-booting the install disks (Re: 8.x grudges) 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, 07 Jul 2010 20:00:37 -0000 2010/7/7 Mikhail T. : > 07.07.2010 14:30, Randi Harper =CE=C1=D0=C9=D3=C1=D7(=CC=C1): > > =9A8. >> =9A =9A I tried to do an install on one of the systems via netbooting >> =9A =9A (pxeload) the disk1-image. It booted, but the sysinstall had to = be >> =9A =9A started manually and, once started, did not act the same as when >> =9A =9A booted off of CD-ROM. Seems like a simple bit to correct so that >> =9A =9A setting "init" to /usr/sbin/sysinstall/manually on every boot/ i= s >> =9A =9A not necessary... > > > This shouldn't be the case. IIRC, nothing has changed that would cause > this. More info on your environment please? > > > Well, I never tried this part before, so I'm not claiming, there is > regression here. Just lack of progress :-) > > I have the following special entry in the dhcpd.conf: > > subnet 192.168.1.0 netmask 255.255.255.0 { > =9A=9A=9A=9A=9A=9A=9A range dynamic-bootp 192.168.1.150 192.168.1.186; > =9A=9A=9A=9A=9A=9A=9A next-server 192.168.1.140; > =9A=9A=9A=9A=9A=9A=9A option broadcast-address 192.168.1.255; > =9A=9A=9A=9A=9A=9A=9A option routers 192.168.1.1; > =9A=9A=9A=9A=9A=9A=9A option root-path "192.168.1.140:/cdrom"; > =9A=9A=9A=9A=9A=9A=9A filename=9A=9A=9A=9A=9A=9A=9A "pxeboot"; > } > > The filesystem accessible as /cdrom was an md-accessed > FreeBSD-8.1-RC1-i386-disc1.iso (or bootonly). Can't easily recreate this, > because the netbooting machine has now gone back to its owner. > > The problem did not surprise me, because I followed (loosely) the > instructions, where it was mentioned -- along with a work-around. If some > simple logic can be put into the boot-image to allow it to do the right > thing without manual fiddling, it would be great. Thanks! > > -mi > So.... you're complaining that you have to modify the loader.conf? I fail to see the problem. This is by design, and isn't a lack of progress. -- randi From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 20:17:44 2010 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 C2EA3106564A; Wed, 7 Jul 2010 20:17:44 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id 638048FC19; Wed, 7 Jul 2010 20:17:44 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o67KHgdt002213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jul 2010 16:17:43 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o67KHgwY031390; Wed, 7 Jul 2010 16:17:42 -0400 Message-ID: <4C34E0E6.9070801@aldan.algebra.com> Date: Wed, 07 Jul 2010 16:17:42 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jeremy Chadwick References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> In-Reply-To: <20100707185928.GA16180@icarus.home.lan> Content-Type: multipart/mixed; boundary="------------000305090006040403060807" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: re@freebsd.org, tom@hur.st, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: 8.x grudges 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, 07 Jul 2010 20:17:44 -0000 This is a multi-part message in MIME format. --------------000305090006040403060807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 07.07.2010 14:59, Jeremy Chadwick ???????(??): >> FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and >> thus not an "option") -- the kernel-config files, that worked with >> 7.x, break without this option in them (in addition to all the >> nuisance, that's documented in UPDATING -- which, somehow, makes >> the breakage acceptable). config(8) would not warn about this, but >> kernel build fails. >> > We don't use this option (meaning it's removed from our kernels). It's > definitely not required. All it does is ensure your kernel can > comprehend executables/binaries built on 7.x. > Attached is the kernel config-file (i386), that worked fine under 7.x. The kernel-compile will break (some *freebsd7* structs undefined), without the COMPAT_FREEBSD7 option. Try it for yourself... >> 3. Likewise, having "device ugen" breaks config(8) -- another >> undocumented incompatibility. >> > This sounds like you not including all of the necessary USB/device > framework in your kernel configuration. You're not providing enough > output for us to help diagnose the problem, though. > Put "device ugen" back into the attached kernel-config file and see config's error yourself. >> 4. The sio(4) is described in UPDATING as "removed", but rouses no >> complaint from config(8) either. It just breaks the kernel >> build... It should be an alias for uart, IMHO -- all I want is for >> my serial ports to be usable, whether their driver is called >> "Serial Input/Output" or "Universal Asynchronous Receiver and >> Transmitter". >> > I disagree (re: "it should be an alias"). sio(4) is deprecated (meaning > it's not used by default any more), and it's left in the driver tree > solely as a fall-back method if someone runs into uart(4) problems. If it were merely "deprecated" it would've still worked. It does not -- put "device sio" into the attached kernel-config and try building -- you'll get the compile-error. Whether deliberately or through bit-rot, uart /replaced/ sio... > I'll take a moment to point out that your complaints about the kernel > configuration file, so far, seem to stem from you not "migrating" your > kernel configuration from 7.x to 8.x. Things change -- that's the > reality of the situation. > > The way I do this is, when upgrading major releases (7.x->8.x), to > "start fresh" using GENERIC as my base template and then > adding/adjusting while comparing against the older kernels' config. > Others do it differently, this is just how I do it. > Yes, your way is fine. But so is mine. It is perfectly reasonable to expect my method to work just as well -- the 7->8 is not revolutionary, but simply the next step. I read the "UPDATING" file and, though annoyed a little, took care of things mentioned in there... The remaining things are enumerated here... >> (BTW, about the /dev-entries -- do we /really/ have to change the >> names of the serial port-devices every couple of years? It is >> rather painful to reconfigure the fax- and ppp-software, etc.) How >> does the Microsoft world manage to stay with the COM1, COM2 for >> decades?) >> > Like I said: things change. > Well, pardon the political pun, but I don't believe in change for the sake of change. These particular changes are gratuitous. If sio is no longer available -- and replaced by uart, why change the /dev-entries?.. >> 5. One of the upgraded systems would repeatedly hang at boot, until I >> disabled the on-board firewire-device through the BIOS... It was >> not a problem under 7.x, although I don't know, whether the device >> actually worked. >> > This is a commonly-reported problem, assuming "at boot" you mean "while > the kernel is starting". Or unless you're using a certain model of > Shuttle box, but that turned out to be literally a BIOS bug: > > http://koitsu.wordpress.com/2009/05/22/shuttle-sg45h7-firewire-bug-in-bios-sg45u10o/ > No, this is not it /at all/. The link above describes a crash in the BIOS (and no POST), if firewire circuitry is disabled in BIOS. My problem is with FreeBSD kernel hanging on boot, if the firewire circuitry is enabled in BIOS. The boot was fine under 7.x, so this can not be due to a BIOS-bug -- the only thing, that changed, is the OS... > This is also a commonly-reported problem (and one I've harped on as > well). When you say "during boot": does it work during loader (the > screen with the "FreeBSD" logo on it)? > Yes. > If the keyboard works during loader but not once the kernel + kernel USB > stack loads (e.g. when booting into single-user), then look at the very > bottom of this page for a couple things to try: > > http://wiki.freebsd.org/BugBusting/Commonly_reported_issues > Will do, thanks! Still, I was hoping, things will "just work" with 8.1... > Regardless, this is one of the reasons I still have not made the move to > USB keyboards and stick with PS/2 keyboards on FreeBSD. > While renovating the house, I ran USB-, audio-, and video-cables through the walls from "server room" to the office, so I can sit in front of the monitors and keyboard/mouse, while the actual computers are well insulated behind closed door. PS/2 cables can't run the same length, it turns out... >> 7. All my "dangerously dedicated" disks lost the "s1" in the >> subdevice-names after the upgrade: /dev/da1s1d became /dev/da1d, >> etc. I like the shorter names (and there are, indeed, no "slices" >> there), but having to fix them manually upon reboot was unpleasant >> and uncalled for. As with uart/sio, backward-compatibility aliases >> are a fine idea and really improves user's experience... >> > Again: things change. > Again: this particular change seems gratuitous. > "Dangerously dedicated" disks are commonly deprecated at this point (as > I understand it folks are trying to get away from them). GEOM takes > care of this situation better than it used to. Yes, the "taking care" part is fine -- the filesystems all work. But the renaming is unwelcome. > Re: aliases: see above. > The only talk of aliases "above" was regarding sio/uart -- you said, sio is deprecated, but could exist alongside uart. That argument (however flawed it was, in my above-expressed opinion) does not apply here... >> 8. I tried to do an install on one of the systems via netbooting >> (pxeload) the disk1-image. It booted, but the sysinstall had to beclaimed >> started manually and, once started, did not act the same as when >> booted off of CD-ROM. Seems like a simple bit to correct so that >> setting "init" to /usr/sbin/sysinstall/manually on every boot/ is >> not necessary... >> > Can't reproduce: > http://jdc.parodius.com/freebsd/pxeboot_serial_install.html > Yes, you can -- you extract the CD-image there (doubling the storage requirements), and then modify the loader.conf . That modification should not be necessary -- the thing ought to figure the situation out automatically. That it does not (not quite), was my complaint, although I was following a different recipe . > > Try loading the kernel module amdtemp and see if things improve. Be > sure to read the man page. > Loading amdtemp was not necessary on the Opteron system, where the k8temp utility "just works" even after the upgrade. Doing it did not help the Athlon system, where k8temp continues to not work... Yours, -mi --------------000305090006040403060807 Content-Type: text/plain; name="Quokka" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Quokka" # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.474.2.18 2009/06/18 06:03:58 yongari Exp $ #cpu I486_CPU #cpu I586_CPU cpu I686_CPU ident Quokka # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking #options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories #options UFS_GJOURNAL # Enable gjournal-based UFS journaling #options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager #options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework #options GEOM_PART_GPT # GUID Partition Tables. #options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) 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 AUDIT # Security event auditing #options KDTRACE_HOOKS # Kernel DTrace hooks # To make an SMP kernel, the next two lines are needed #options SMP # Symmetric MultiProcessor Kernel #device apic # I/O APIC # CPU frequency control device cpufreq # Bus support. #device eisa 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 #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape 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) # 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 kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Power management support (see NOTES for more options) device apm # Add suspend/resume support for the i8254. device ipmi device smapi device smbios device pmtimer # Adjust system timer at wakeup time device smb device smbus device nfpm device nfsmb # Serial (COM) ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # 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 nfe # nVidia nForce MCP on-board Ethernet device nve # nVidia nForce MCP on-board Ethernet device fxp # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support #device sl # Kernel SLIP #device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" #device gif # IPv6 and IPv4 tunneling #device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # 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 udbp # USB Double Bulk Pipe devices device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) device fwip # IP over FireWire (RFC 2734,3146) device dcons # Dumb console driver device dcons_crom # Configuration ROM for dcons device sound device snd_ich --------------000305090006040403060807-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 20:34:37 2010 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 CE4DA106566C for ; Wed, 7 Jul 2010 20:34:37 +0000 (UTC) (envelope-from sektie@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 500518FC1C for ; Wed, 7 Jul 2010 20:34:37 +0000 (UTC) Received: by mail-vw0-f54.google.com with SMTP id 6so129215vws.13 for ; Wed, 07 Jul 2010 13:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=xc5fmuLDhFlzPLrK5MIEfUUF/cJSIUFGO2Oc+1Jh8+c=; b=h4VIQf6xDRswrShRQzEYBrXGDjYRXeT8Z1ruNpqwezp3nvrpuulvLCvpH65mjFWZXg J2xoQSXiIOaWVLMQ+yKKyQQ/QftjFYz+ENU5yspNJCn1r5fwFNVAEizUe2FX231K03PJ 9Bo2aX0aEjPVvjr5L7tBcl+az2OST+Te2TVng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=N6CXlZb+g7uE62ySbZ+WEN4EXDtv9aC0SgUDDJCpdrhuvKlpzLORdDrenDuip7E0zX YbObEuWe1DKWAmO9K/xmGc1EWH4dm2t4NByDFiTxdwnOyDtab477Hz/lnWTDIhYhkHjx 8fDWecaJ+Gse5pVRaIpjII/6A1ukxnwF8kCac= MIME-Version: 1.0 Received: by 10.220.100.213 with SMTP id z21mr3662817vcn.141.1278534875726; Wed, 07 Jul 2010 13:34:35 -0700 (PDT) Sender: sektie@gmail.com Received: by 10.220.174.42 with HTTP; Wed, 7 Jul 2010 13:34:35 -0700 (PDT) In-Reply-To: <4C34E0E6.9070801@aldan.algebra.com> References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> Date: Wed, 7 Jul 2010 13:34:35 -0700 X-Google-Sender-Auth: 1mNJlCVGkBVZtfSpguasWkxdQpM Message-ID: From: Randi Harper To: "Mikhail T." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tom@hur.st, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org, Jeremy Chadwick Subject: Re: 8.x grudges 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, 07 Jul 2010 20:34:37 -0000 On Wed, Jul 7, 2010 at 1:17 PM, Mikhail T. wrot= e: > 07.07.2010 14:59, Jeremy Chadwick ???????(??): >>> >>> =A0 =A0 =A0FREEBSD_COMPAT7 kernel option is, apparently, a requirement = (and >>> =A0 =A0 =A0thus not an "option") -- the kernel-config files, that worke= d with >>> =A0 =A0 =A07.x, break without this option in them (in addition to all t= he >>> =A0 =A0 =A0nuisance, that's documented in UPDATING -- which, somehow, m= akes >>> =A0 =A0 =A0the breakage acceptable). config(8) would not warn about thi= s, but >>> =A0 =A0 =A0kernel build fails. >>> >> >> We don't use this option (meaning it's removed from our kernels). =A0It'= s >> definitely not required. =A0All it does is ensure your kernel can >> comprehend executables/binaries built on 7.x. >> > > Attached is the kernel config-file (i386), that worked fine under 7.x. Th= e > kernel-compile will break (some *freebsd7* structs undefined), without th= e > COMPAT_FREEBSD7 option. Try it for yourself... Don't use a kernel config from 7. We've already told you this. >>> >>> =A0 3. Likewise, having "device ugen" breaks config(8) -- another >>> =A0 =A0 =A0undocumented incompatibility. >>> >> >> This sounds like you not including all of the necessary USB/device >> framework in your kernel configuration. =A0You're not providing enough >> output for us to help diagnose the problem, though. >> > > Put "device ugen" back into the attached kernel-config file and see confi= g's > error yourself. >>> >>> =A0 4. The sio(4) is described in UPDATING as "removed", but rouses no >>> =A0 =A0 =A0complaint from config(8) either. It just breaks the kernel >>> =A0 =A0 =A0build... It should be an alias for uart, IMHO -- all I want = is for >>> =A0 =A0 =A0my serial ports to be usable, whether their driver is called >>> =A0 =A0 =A0"Serial Input/Output" or "Universal Asynchronous Receiver an= d >>> =A0 =A0 =A0Transmitter". >>> >> >> I disagree (re: "it should be an alias"). =A0sio(4) is deprecated (meani= ng >> it's not used by default any more), and it's left in the driver tree >> solely as a fall-back method if someone runs into uart(4) problems. > > If it were merely "deprecated" it would've still worked. It does not -- p= ut > "device sio" into the attached kernel-config and try building -- you'll g= et > the compile-error. Whether deliberately or through bit-rot, uart /replace= d/ > sio... >> >> I'll take a moment to point out that your complaints about the kernel >> configuration file, so far, seem to stem from you not "migrating" your >> kernel configuration from 7.x to 8.x. =A0Things change -- that's the >> reality of the situation. >> >> The way I do this is, when upgrading major releases (7.x->8.x), to >> "start fresh" using GENERIC as my base template and then >> adding/adjusting while comparing against the older kernels' config. >> Others do it differently, this is just how I do it. >> > > Yes, your way is fine. But so is mine. It is perfectly reasonable to expe= ct > my method to work just as well -- the 7->8 is not revolutionary, but simp= ly > the next step. I read the "UPDATING" file and, though annoyed a little, t= ook > care of things mentioned in there... The remaining things are enumerated > here... Your way clearly isn't fine, as it doesn't work. >>> >>> =A0 =A0 =A0(BTW, about the /dev-entries -- do we /really/ have to chang= e the >>> =A0 =A0 =A0names of the serial port-devices every couple of years? It i= s >>> =A0 =A0 =A0rather painful to reconfigure the fax- and ppp-software, etc= .) How >>> =A0 =A0 =A0does the Microsoft world manage to stay with the COM1, COM2 = for >>> =A0 =A0 =A0decades?) >>> >> >> Like I said: things change. >> > > Well, pardon the political pun, but I don't believe in change for the sak= e > of change. These particular changes are gratuitous. If sio is no longer > available -- and replaced by uart, why change the /dev-entries?.. These changes aren't gratuitous. Did you read the commit messages behind each of the changes? I'm guessing that you haven't. >>> >>> =A0 5. One of the upgraded systems would repeatedly hang at boot, until= I >>> =A0 =A0 =A0disabled the on-board firewire-device through the BIOS... It= was >>> =A0 =A0 =A0not a problem under 7.x, although I don't know, whether the = device >>> =A0 =A0 =A0actually worked. >>> >> >> This is a commonly-reported problem, assuming "at boot" you mean "while >> the kernel is starting". =A0Or unless you're using a certain model of >> Shuttle box, but that turned out to be literally a BIOS bug: >> >> >> http://koitsu.wordpress.com/2009/05/22/shuttle-sg45h7-firewire-bug-in-bi= os-sg45u10o/ >> > > No, this is not it /at all/. The link above describes a crash in the BIOS > (and no POST), if firewire circuitry is disabled in BIOS. My problem is w= ith > FreeBSD kernel hanging on boot, if the firewire circuitry is enabled in > BIOS. The boot was fine under 7.x, so this can not be due to a BIOS-bug -= - > the only thing, that changed, is the OS... Yes. Sometimes there are bugs that exist that aren't triggered until an external influence makes them apparent. >> >> This is also a commonly-reported problem (and one I've harped on as >> well). =A0When you say "during boot": does it work during loader (the >> screen with the "FreeBSD" logo on it)? >> > > Yes. >> >> If the keyboard works during loader but not once the kernel + kernel USB >> stack loads (e.g. when booting into single-user), then look at the very >> bottom of this page for a couple things to try: >> >> http://wiki.freebsd.org/BugBusting/Commonly_reported_issues >> > > Will do, thanks! Still, I was hoping, things will "just work" with 8.1... >> >> Regardless, this is one of the reasons I still have not made the move to >> USB keyboards and stick with PS/2 keyboards on FreeBSD. >> > > While renovating the house, I ran USB-, audio-, and video-cables through = the > walls from "server room" to the office, so I can sit in front of the > monitors and keyboard/mouse, while the actual computers are well insulate= d > behind closed door. PS/2 cables can't run the same length, it turns out..= . >>> >>> =A0 7. All my "dangerously dedicated" disks lost the "s1" in the >>> =A0 =A0 =A0subdevice-names after the upgrade: /dev/da1s1d became /dev/d= a1d, >>> =A0 =A0 =A0etc. I like the shorter names (and there are, indeed, no "sl= ices" >>> =A0 =A0 =A0there), but having to fix them manually upon reboot was unpl= easant >>> =A0 =A0 =A0and uncalled for. As with uart/sio, backward-compatibility a= liases >>> =A0 =A0 =A0are a fine idea and really improves user's experience... >>> >> >> Again: things change. >> > > Again: this particular change seems gratuitous. It's not. You didn't bother researching before complaining. To put it in simple terms, there were changes made to geom, and the way that sysinstall writes out dedicated disks wasn't compatible. Search the mailing list archives. >> >> "Dangerously dedicated" disks are commonly deprecated at this point (as >> I understand it folks are trying to get away from them). =A0GEOM takes >> care of this situation better than it used to. > > Yes, the "taking care" part is fine -- the filesystems all work. But the > renaming is unwelcome. >> >> Re: aliases: see above. >> > > The only talk of aliases "above" was regarding sio/uart -- you said, sio = is > deprecated, but could exist alongside uart. That argument (however flawed= it > was, in my above-expressed opinion) does not apply here... >>> >>> =A0 8. I tried to do an install on one of the systems via netbooting >>> =A0 =A0 =A0(pxeload) the disk1-image. It booted, but the sysinstall had= to >>> beclaimed >>> =A0 =A0 =A0started manually and, once started, did not act the same as = when >>> =A0 =A0 =A0booted off of CD-ROM. Seems like a simple bit to correct so = that >>> =A0 =A0 =A0setting "init" to /usr/sbin/sysinstall/manually on every boo= t/ is >>> =A0 =A0 =A0not necessary... >>> >> >> Can't reproduce: >> http://jdc.parodius.com/freebsd/pxeboot_serial_install.html >> > > Yes, you can -- you extract the CD-image there > > (doubling the storage requirements), and then modify the loader.conf > . Th= at > modification should not be necessary -- the thing ought to figure the > situation out automatically. That it does not (not quite), was my complai= nt, > although I was following a different recipe > . The modification should be necessary. Just because you don't want to make the modification doesn't mean it was made that way by accident. That variable can be set to any number of things. We don't advertise the iso image just working out of the box for pxe booting. In fact, the article about PXE booting on the official freebsd website says nothing about using the ISO. You just found some article that said it was possible (and it is) and complained because you didn't like the process? >> >> Try loading the kernel module amdtemp and see if things improve. =A0Be >> sure to read the man page. >> > > Loading amdtemp was not necessary on the Opteron system, where the k8temp > utility "just works" even after the upgrade. Doing it did not help the > Athlon system, where k8temp continues to not work... Funny. It works just fine in 8.0 on my Athlon. Have you tried updating the port? Also, even if it didn't work, this is an issue you should take up with the author of the port. If you had read the commit logs, you would have seen that the device was renamed because k8temp didn't make sense anymore. >From the man page: The amdtemp driver provides support for the on-die digital thermal sen= sor present in AMD K8, K10 and K11 processors. I am removing re@ from this thread. You might think about emailing the appropriate mailing lists with questions first before doing the equivalent of stomping your feet and asking to speak to the manager of the candy store, especially since many of your complaints are uninformed and bogus. -- randi From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 20:50:50 2010 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 CD8F31065676; Wed, 7 Jul 2010 20:50:50 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id AF10D8FC17; Wed, 7 Jul 2010 20:50:50 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp023.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L5700LUFGK7TI00@asmtp023.mac.com>; Wed, 07 Jul 2010 13:50:32 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1007070094 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2010-07-07_03:2010-02-06, 2010-07-07, 2010-07-07 signatures=0 From: Marcel Moolenaar In-reply-to: Date: Wed, 07 Jul 2010 13:50:30 -0700 Message-id: <779BFD8C-962A-4577-B794-6AE2B946F4DF@mac.com> References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> To: Randi Harper X-Mailer: Apple Mail (2.1081) Cc: "Mikhail T." , Jeremy Chadwick , freebsd-stable@freebsd.org, tom@hur.st, freebsd-usb@freebsd.org Subject: Re: 8.x grudges 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, 07 Jul 2010 20:50:50 -0000 On Jul 7, 2010, at 1:34 PM, Randi Harper wrote: >> Well, pardon the political pun, but I don't believe in change for the sake >> of change. These particular changes are gratuitous. If sio is no longer >> available -- and replaced by uart, why change the /dev-entries?.. > > These changes aren't gratuitous. Did you read the commit messages > behind each of the changes? I'm guessing that you haven't. Not to mention that if you change uart(4) to create dev entries like sio(4) after uart(4) has been in the tree for more than 6 years creating ttyu* entries, you actually introduce a gratuitous change. It's all about perspective... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 20:52:34 2010 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 281D01065678; Wed, 7 Jul 2010 20:52:34 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id CFB0B8FC12; Wed, 7 Jul 2010 20:52:33 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o67KqWXQ008491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jul 2010 16:52:32 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o67KqWtd009492; Wed, 7 Jul 2010 16:52:32 -0400 Message-ID: <4C34E910.5020007@aldan.algebra.com> Date: Wed, 07 Jul 2010 16:52:32 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Randi Harper References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: tom@hur.st, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org, Jeremy Chadwick Subject: Re: 8.x grudges 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, 07 Jul 2010 20:52:34 -0000 07.07.2010 16:34, Randi Harper ???????(??): > >> Attached is the kernel config-file (i386), that worked fine under 7.x. The >> kernel-compile will break (some *freebsd7* structs undefined), without the >> COMPAT_FREEBSD7 option. Try it for yourself... >> > Don't use a kernel config from 7. We've already told you this. > Your "telling" me this is just as valid as warning me against using computer-cases of a particular color. It is a silly requirement. My expecting things, that worked for 7, to work in 8 is reasonable. There may be (documented!) exceptions, but it ought to "just work". >> Yes, your way is fine. But so is mine. It is perfectly reasonable to expect >> my method to work just as well -- the 7->8 is not revolutionary, but simply >> the next step. I read the "UPDATING" file and, though annoyed a little, took >> care of things mentioned in there... The remaining things are enumerated >> here... >> > Your way clearly isn't fine, as it doesn't work. > That's an obviously flawed argument -- this line of thinking can be used against ANY ONE reporting ANY BUG -- if one has a problem, then one's way of doing things "clearly isn't fine". > > These changes aren't gratuitous. Did you read the commit messages > behind each of the changes? I'm guessing that you haven't. > No, and I'm not going to. A commercial OS would've been the laughing stock, if one hand to change C: to 1: between releases, for example... >> >> Again: this particular change seems gratuitous. >> > It's not. You didn't bother researching before complaining. I bothered to type up my list. Presumably, problem-reports are welcome. I've been a Unix-user since 1990, a FreeBSD user since 1993 (or 94?), and a project-member for a decade. If *I* have a problem, then newer users certainly will too. And, guess what, they'll simply go with something, that does not give as much grief... > To put it in simple terms, there were changes made to geom, and the way that > sysinstall writes out dedicated disks wasn't compatible. Search the > mailing list archives. > If this is a known problem, it is even more of an outrage, that some shim was not introduced to keep the users from hitting this particular bump. > > The modification should be necessary. Why? Why should a netboot act differently from a local boot from CD? > Just because you don't want to > make the modification doesn't mean it was made that way by accident. > No, I never claimed this to have been an accident... > That variable can be set to any number of things. We don't advertise > the iso image just working out of the box for pxe booting. You don't. But there is very little, that needs to be added there for it to "just work" over both netboot and local CD, and you should do it, instead of arguing with me here... No, I don't know, what it is exactly, but I'm quite certain, it can't be very much. > In fact, the article about PXE booting on the official freebsd website says > nothing about using the ISO. You just found some article that said it > was possible (and it is) and complained because you didn't like the > process? > Yes, exactly. I didn't like process -- it is needlessly complicated. The same CD-image, /should/ also be usable "out of the box" for netbooting. > > Funny. It works just fine in 8.0 on my Athlon. Have you tried updating > the port? Yes, I have -- and I said so in my very first e-mail on this subject. For someone, who expects people to "research mailing lists", you do a terrible job of following a one-day-old thread... > Also, even if it didn't work, this is an issue you should > take up with the author of the port. Tom -- the maintainer -- is still in CC... > > > From the man page: > > The amdtemp driver provides support for the on-die digital thermal sensor > present in AMD K8, K10 and K11 processors. > I know nothing about the driver. But a utility I regularly used stopped working after upgrade, so I added that to my list of upgrade-related grudges. -mi From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 20:53:54 2010 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 0F7DF106566C for ; Wed, 7 Jul 2010 20:53:54 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D59888FC17 for ; Wed, 7 Jul 2010 20:53:53 +0000 (UTC) Received: by pwj9 with SMTP id 9so41354pwj.13 for ; Wed, 07 Jul 2010 13:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Cb1F+JLt7vhfxuqz5Wvuccjrij2Y6tNSP/EskTxzp9o=; b=eerDtOevwIdIRJ5GkjPgQlsL70GvlMAunx21ASY14oyikkukLHsY+b+1LcEFU+JPda Zx1LQyhmZr/aRstKBVOcliBxO/F/p87paEJrcQGeRhAwM37/qOG1h3elkMFXrAoQ5U+I epz8RMnE6+HKFtkCNQUh0WAqFO120Xt7dOZeE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=opzn7KSiHEpCUQbJlAEa1xf57Z+lTuGtnFkNjN/Q3sTmvySzSoRfae27pXuiMf7SqB jpPqMu7S1FCf1VeTNMApoCC6r7Of2uOKCu6dzxKr2t0OdlZSXdnHXDuqjn9IwJysRjbP HdXrjioGWBv2rCFoiMMTvCC/qrALWbOaWG0OQ= MIME-Version: 1.0 Received: by 10.114.66.10 with SMTP id o10mr8257723waa.169.1278536033009; Wed, 07 Jul 2010 13:53:53 -0700 (PDT) Received: by 10.231.37.11 with HTTP; Wed, 7 Jul 2010 13:53:52 -0700 (PDT) In-Reply-To: <4C34E0E6.9070801@aldan.algebra.com> References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> Date: Wed, 7 Jul 2010 13:53:52 -0700 Message-ID: From: Freddie Cash To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: 8.x grudges 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, 07 Jul 2010 20:53:54 -0000 On Wed, Jul 7, 2010 at 1:17 PM, Mikhail T. wrot= e: > 07.07.2010 14:59, Jeremy Chadwick ???????(??): >>> >>> =C2=A0 =C2=A0 =C2=A0FREEBSD_COMPAT7 kernel option is, apparently, a req= uirement (and >>> =C2=A0 =C2=A0 =C2=A0thus not an "option") -- the kernel-config files, t= hat worked with >>> =C2=A0 =C2=A0 =C2=A07.x, break without this option in them (in addition= to all the >>> =C2=A0 =C2=A0 =C2=A0nuisance, that's documented in UPDATING -- which, s= omehow, makes >>> =C2=A0 =C2=A0 =C2=A0the breakage acceptable). config(8) would not warn = about this, but >>> =C2=A0 =C2=A0 =C2=A0kernel build fails. >>> >> >> We don't use this option (meaning it's removed from our kernels). =C2=A0= It's >> definitely not required. =C2=A0All it does is ensure your kernel can >> comprehend executables/binaries built on 7.x. >> > > Attached is the kernel config-file (i386), that worked fine under 7.x. Th= e > kernel-compile will break (some *freebsd7* structs undefined), without th= e > COMPAT_FREEBSD7 option. Try it for yourself... While you may get lucky sometimes, it's very *VERY* rare to be able to re-use a kernel config file across major version releases, at least unchanged. Going from 4.x to 5.x required a new kernel config file. (4.x was my first real install of FreeBSD that was upgraded.) Going from 5.x to 6.x required a new kernel config file. Going from 6.x to 7.x required a new kernel config file. Why do you think going from 7.x to 8.x would be any different? When doing major version upgrades, always start with GENERIC from the new release, and add build your custom config file from there. This is way things have been for many, many, many years. Minor version upgrades (7.x to 7.y) rarely require a new kernel config file, although it's still a good idea to start with GENERIC for the duration of the upgrade. But major upgrades have pretty much always required it. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 20:56:51 2010 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 C21951065670 for ; Wed, 7 Jul 2010 20:56:51 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8A2708FC0C for ; Wed, 7 Jul 2010 20:56:51 +0000 (UTC) Received: by iwn35 with SMTP id 35so133073iwn.13 for ; Wed, 07 Jul 2010 13:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=S8LHTe1Ko7PboUlxpVZfMafASDNwOYVk8RLELddlJPo=; b=nsyp+eVw/mz2IDlpBKA8yjNUYSbbv9TA/mfiX4vV+e0K9uvPrYMCAC4nj6NzkwXKAk J5R3qK0f132nSlJPIeWYkiNVSyiRvCzEv14TVcCwjEUti7sEhxiLQZdsot6mu9jDgP38 e5kcE/ebMDB5AZk8QDq6w8D8nIqc7t6w/JAys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=vOGRpedTTauUmwpGuHdQ19DGW+5rBSGj5ohvri3vHzcJK1I0dKb7/zD+xBw1yQJuOK A6WObJzY2xR99eTDHCyQLFlMCAALkwCwZAJKuOXZua+SncgqP16tl6ESgOU/Fz7ZokHh UchOgQSKimOWH7AUOHVjSYLSpN8d7JacWTbZM= MIME-Version: 1.0 Received: by 10.231.114.165 with SMTP id e37mr6328388ibq.189.1278536209827; Wed, 07 Jul 2010 13:56:49 -0700 (PDT) Received: by 10.231.37.11 with HTTP; Wed, 7 Jul 2010 13:56:49 -0700 (PDT) In-Reply-To: <4C34E910.5020007@aldan.algebra.com> References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> <4C34E910.5020007@aldan.algebra.com> Date: Wed, 7 Jul 2010 13:56:49 -0700 Message-ID: From: Freddie Cash To: FreeBSD Stable Content-Type: text/plain; charset=UTF-8 Subject: Re: 8.x grudges 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, 07 Jul 2010 20:56:51 -0000 On Wed, Jul 7, 2010 at 1:52 PM, Mikhail T. wrote: > I know nothing about the driver. But a utility I regularly used stopped > working after upgrade, so I added that to my list of upgrade-related > grudges. Was this before or after re-compiling all your installed ports, which is necessary step between major version upgrades? -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 21:39:26 2010 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 9C62D1065673; Wed, 7 Jul 2010 21:39:26 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2F3458FC17; Wed, 7 Jul 2010 21:39:25 +0000 (UTC) Received: by gyd8 with SMTP id 8so84823gyd.13 for ; Wed, 07 Jul 2010 14:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NZp6G3TlAXQwdwZAKzt9MN5Z6RL2/WvuA1bC2iI86qE=; b=WEEbycJZkQAFfLn8qPN8i2x7+M0D9X/QQL85WgPxL31U+cIpDmmfmVXYyfLGTeNRrI XEaG7UkBz7gFaQ5Qd34JD/GdsDa8tyewghbGIC+hugzw2xoxIiC4xHA4faqY1cx8SQUN rJymnVenZ6bS02BWIJHcgyP9cq/sKJ+A85kww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=F/41B7M282H1RnrMv+eLxlRJzvmmU+Orujm70RIyRtjyavDfyHmO08SAdNitTAG00D zPRqejPG+6tE0zwnpB6iFG3oX4QL69w6bZKXNhSIZ+2yfqzGbrwzGfAlgfE3bVZbanDL 3XOBdxg8D+izM6ANUu1J6awcYgG0mj+XFfK80= MIME-Version: 1.0 Received: by 10.229.221.137 with SMTP id ic9mr4257988qcb.209.1278538760208; Wed, 07 Jul 2010 14:39:20 -0700 (PDT) Received: by 10.229.192.201 with HTTP; Wed, 7 Jul 2010 14:39:20 -0700 (PDT) In-Reply-To: <4C34E0E6.9070801@aldan.algebra.com> References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> Date: Wed, 7 Jul 2010 14:39:20 -0700 Message-ID: From: Garrett Cooper To: "Mikhail T." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org, tom@hur.st, re@freebsd.org, freebsd-usb@freebsd.org, Jeremy Chadwick Subject: Re: 8.x grudges 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, 07 Jul 2010 21:39:26 -0000 On Wed, Jul 7, 2010 at 1:17 PM, Mikhail T. wrot= e: > 07.07.2010 14:59, Jeremy Chadwick ???????(??): >>> >>> =A0 =A0 =A0FREEBSD_COMPAT7 kernel option is, apparently, a requirement = (and >>> =A0 =A0 =A0thus not an "option") -- the kernel-config files, that worke= d with >>> =A0 =A0 =A07.x, break without this option in them (in addition to all t= he >>> =A0 =A0 =A0nuisance, that's documented in UPDATING -- which, somehow, m= akes >>> =A0 =A0 =A0the breakage acceptable). config(8) would not warn about thi= s, but >>> =A0 =A0 =A0kernel build fails. >>> >> >> We don't use this option (meaning it's removed from our kernels). =A0It'= s >> definitely not required. =A0All it does is ensure your kernel can >> comprehend executables/binaries built on 7.x. >> > > Attached is the kernel config-file (i386), that worked fine under 7.x. Th= e > kernel-compile will break (some *freebsd7* structs undefined), without th= e > COMPAT_FREEBSD7 option. Try it for yourself... options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores Those require COMPAT_FREEBSD7. This does seem like a bug: static struct syscall_helper_data shm_syscalls[] =3D { SYSCALL_INIT_HELPER(shmat), SYSCALL_INIT_HELPER(shmctl), SYSCALL_INIT_HELPER(shmdt), SYSCALL_INIT_HELPER(shmget), #if defined(COMPAT_FREEBSD4) || defined(COMPAT_FREEBSD5) || \ defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD7) SYSCALL_INIT_HELPER(freebsd7_shmctl), #endif The check should be for COMPAT_FREEBSD7 only I would think. Apart from that, everything else should work without it I would think. Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 21:44:34 2010 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 850511065674; Wed, 7 Jul 2010 21:44:34 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0C9D78FC1A; Wed, 7 Jul 2010 21:44:33 +0000 (UTC) Received: by vws6 with SMTP id 6so222076vws.13 for ; Wed, 07 Jul 2010 14:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Tlnn91VYA6ikRrGZZYv12DJzHdgW11nv6qyc53zoLlU=; b=lBB4TdG5lrkZzFrg/DiDFBrsCB/n/xzCKwUAShOaR19R4oA4pXcXMBzxTAHLm4TGNC yn5+/y3+VxM4DS6lErDYUp8JAajoqiZrKu7HlzzOHepUP5mYTrvBepnqf7MURzx3HLqS VI/EBIKZP0UpE7+TCHS4l7p6Pl5Or6/UI4QLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ejkx52jJKpCHtLgig0l8dycP+CdlMENf7e1BIfm0O5xBRtW0pbgdzSEA+MQ6H4i9IO Y9cq08w/8ZSCsoGUCb9xU9+YNbNa4LSVWZdbfo0UYObXHaZ1sXv3Io4ezcFKdLPQ+d0o RJ4d1B/wAoGK3RBv+krzdvQjihgfRjQST/uUc= MIME-Version: 1.0 Received: by 10.224.103.2 with SMTP id i2mr1861236qao.192.1278539065543; Wed, 07 Jul 2010 14:44:25 -0700 (PDT) Received: by 10.229.192.201 with HTTP; Wed, 7 Jul 2010 14:44:25 -0700 (PDT) In-Reply-To: <4C34E910.5020007@aldan.algebra.com> References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> <4C34E910.5020007@aldan.algebra.com> Date: Wed, 7 Jul 2010 14:44:25 -0700 Message-ID: From: Garrett Cooper To: "Mikhail T." Content-Type: text/plain; charset=ISO-8859-1 Cc: tom@hur.st, Jeremy Chadwick , freebsd-stable@freebsd.org, freebsd-usb@freebsd.org, Randi Harper Subject: Re: 8.x grudges 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, 07 Jul 2010 21:44:34 -0000 On Wed, Jul 7, 2010 at 1:52 PM, Mikhail T. wrote: > 07.07.2010 16:34, Randi Harper ???????(??): >> >>> Attached is the kernel config-file (i386), that worked fine under 7.x. >>> The >>> kernel-compile will break (some *freebsd7* structs undefined), without >>> the >>> COMPAT_FREEBSD7 option. Try it for yourself... >>> >> >> Don't use a kernel config from 7. We've already told you this. >> > > Your "telling" me this is just as valid as warning me against using > computer-cases of a particular color. It is a silly requirement. My > expecting things, that worked for 7, to work in 8 is reasonable. There may > be (documented!) exceptions, but it ought to "just work". >>> >>> Yes, your way is fine. But so is mine. It is perfectly reasonable to >>> expect >>> my method to work just as well -- the 7->8 is not revolutionary, but >>> simply >>> the next step. I read the "UPDATING" file and, though annoyed a little, >>> took >>> care of things mentioned in there... The remaining things are enumerated >>> here... >>> >> >> Your way clearly isn't fine, as it doesn't work. >> > > That's an obviously flawed argument -- this line of thinking can be used > against ANY ONE reporting ANY BUG -- if one has a problem, then one's way of > doing things "clearly isn't fine". >> >> These changes aren't gratuitous. Did you read the commit messages >> behind each of the changes? I'm guessing that you haven't. >> > > No, and I'm not going to. A commercial OS would've been the laughing stock, > if one hand to change C: to 1: between releases, for example... >>> >>> Again: this particular change seems gratuitous. >>> >> >> It's not. You didn't bother researching before complaining. > > I bothered to type up my list. Presumably, problem-reports are welcome. I've > been a Unix-user since 1990, a FreeBSD user since 1993 (or 94?), and a > project-member for a decade. If *I* have a problem, then newer users > certainly will too. And, guess what, they'll simply go with something, that > does not give as much grief... >> >> To put it in simple terms, there were changes made to geom, and the way >> that >> sysinstall writes out dedicated disks wasn't compatible. Search the >> mailing list archives. >> > > If this is a known problem, it is even more of an outrage, that some shim > was not introduced to keep the users from hitting this particular bump. >> >> The modification should be necessary. > > Why? Why should a netboot act differently from a local boot from CD? There's a lot of secret sauce done for detecting whether or not you're booting from CD vs pxebooting in a release image, as well as within the sysinstall application as to what environment its dealing with, as well as what you get after things are done with a vanilla build and a sysinstall install (as I've discovered on my own). Unfortunately assuming both methods to produce the same result is flawed :(... Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 21:48:11 2010 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 1CCEE106567A for ; Wed, 7 Jul 2010 21:48:11 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by mx1.freebsd.org (Postfix) with ESMTP id 0288A8FC1A for ; Wed, 7 Jul 2010 21:48:10 +0000 (UTC) Received: from [127.0.0.1] (cheese.corp.yahoo.com [216.145.50.99]) by mrout2.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o67LlSdw094996; Wed, 7 Jul 2010 14:47:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:reply-to:to:cc:in-reply-to:references: content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=mr1l2JIuvxHgKh9JU4eJFNl07lrdTNyq4+OlIY693ur1XTZKKf6dnv8aMNQEWmN7 From: Sean Bruno To: Jeremy Chadwick In-Reply-To: <20100707185928.GA16180@icarus.home.lan> References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> Content-Type: text/plain; charset="UTF-8" Date: Wed, 07 Jul 2010 14:47:28 -0700 Message-ID: <1278539248.2512.87.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" , "Mikhail T." , "re@freebsd.org" , "tom@hur.st" , "freebsd-usb@freebsd.org" Subject: Re: 8.x grudges X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 21:48:11 -0000 > > > 5. > > One of the upgraded systems would repeatedly hang at boot, until I > > disabled the on-board firewire-device through the BIOS... It was > > not a problem under 7.x, although I don't know, whether the device > > actually worked. > > This is a commonly-reported problem, assuming "at boot" you mean "while > the kernel is starting". Or unless you're using a certain model of > Shuttle box, but that turned out to be literally a BIOS bug: > > http://koitsu.wordpress.com/2009/05/22/shuttle-sg45h7-firewire-bug-in-bios-sg45u10o/ > Looking at this link, it doesn't match the described issue. Mikhail's machine would not boot *until* he disabled the firewire controller in the BIOS. The referenced issue on that Shuttle based machine talks about disabling the firewire controller and *then* it still being alive when the system powers on and crashing the system. I interpret this as a bug. Sean Also, I suck at reply-to. sean From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 21:49:55 2010 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 AF4961065670 for ; Wed, 7 Jul 2010 21:49:55 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id 6B5538FC20 for ; Wed, 7 Jul 2010 21:49:55 +0000 (UTC) Received: from [127.0.0.1] (cheese.corp.yahoo.com [216.145.50.99]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o67LkAQQ091073; Wed, 7 Jul 2010 14:46:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:to:cc:in-reply-to:references:content-type:date: message-id:mime-version:x-mailer:content-transfer-encoding; b=jFKG52iczqSPzvqh1VmtAOgwoxvlMDfmdSGkxN9tgzf3igBsU1+O99gmTseaofXk From: Sean Bruno To: Jeremy Chadwick In-Reply-To: <20100707185928.GA16180@icarus.home.lan> References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> Content-Type: text/plain; charset="UTF-8" Date: Wed, 07 Jul 2010 14:46:10 -0700 Message-ID: <1278539170.2512.86.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" , "Mikhail T." , "re@freebsd.org" , "tom@hur.st" , "freebsd-usb@freebsd.org" Subject: Re: 8.x grudges 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, 07 Jul 2010 21:49:55 -0000 > > > 5. > > One of the upgraded systems would repeatedly hang at boot, until I > > disabled the on-board firewire-device through the BIOS... It was > > not a problem under 7.x, although I don't know, whether the device > > actually worked. > > This is a commonly-reported problem, assuming "at boot" you mean "while > the kernel is starting". Or unless you're using a certain model of > Shuttle box, but that turned out to be literally a BIOS bug: > > http://koitsu.wordpress.com/2009/05/22/shuttle-sg45h7-firewire-bug-in-bios-sg45u10o/ > Looking at this link, it doesn't match the described issue. Mikhail's machine would not boot *until* he disabled the firewire controller in the BIOS. The referenced issue on that Shuttle based machine talks about disabling the firewire controller and *then* it still being alive when the system powers on and crashing the system. I interpret this as a bug. Sean From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 21:51:01 2010 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 E721D1065673; Wed, 7 Jul 2010 21:51:00 +0000 (UTC) (envelope-from sektie@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7EC818FC22; Wed, 7 Jul 2010 21:51:00 +0000 (UTC) Received: by vws6 with SMTP id 6so230804vws.13 for ; Wed, 07 Jul 2010 14:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=Os5sZccNf+1UNum4YDDNO4NE9gZZkkxTWNRlMCMlR/k=; b=ZvqHlY4vCcLTpLOWwhfjit2x0p21AZFXbhU+l1v79USKxwQOiZPq5FTkxErI6o0c6/ PcXmDGlaKinRu0i8i/yklfVkSBEkuVnC8AsV4lrnR2EgYIxX2dP79AaGK2gVnwm5l/Lu CNb5EqH837wOyMRcEs5lhdhhXwtpjDBNH15Q8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=BwrrGHSHaXUv80WLSdLzvOrBMDAGRCeP4LFbO+G6HoSaa1jx2Ib3rV7cLXg2WzM20M kMKZjCENY7oS6BN4SIJtrRYRPeMN2yhndkJSJr4B1hxXLFGM+a5qgkPAHoitFCPcAbP6 Xd3BqyqT3EhjI/olxPXHUixCCcdkCPffAdOnw= MIME-Version: 1.0 Received: by 10.220.88.147 with SMTP id a19mr3668923vcm.259.1278539454989; Wed, 07 Jul 2010 14:50:54 -0700 (PDT) Sender: sektie@gmail.com Received: by 10.220.174.42 with HTTP; Wed, 7 Jul 2010 14:50:54 -0700 (PDT) In-Reply-To: <4C34E910.5020007@aldan.algebra.com> References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> <4C34E910.5020007@aldan.algebra.com> Date: Wed, 7 Jul 2010 14:50:54 -0700 X-Google-Sender-Auth: 4RdDGJmQNXWtZ4RCprfWfwdm9N0 Message-ID: From: Randi Harper To: "Mikhail T." Content-Type: text/plain; charset=ISO-8859-1 Cc: tom@hur.st, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org, Jeremy Chadwick Subject: Re: 8.x grudges 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, 07 Jul 2010 21:51:01 -0000 On Wed, Jul 7, 2010 at 1:52 PM, Mikhail T. wrote: > Your "telling" me this is just as valid as warning me against using > computer-cases of a particular color. It is a silly requirement. My > expecting things, that worked for 7, to work in 8 is reasonable. There may > be (documented!) exceptions, but it ought to "just work". Ok. So I guess that a registry backup from Windows XP should work in Windows 7? We both know the world doesn't work that way. Not only is it ridiculous, it inhibits progress. Do you have any idea how many lines of code we have to deal with to plan for older setups? Even just with the stuff that I work on, it's a constant consideration to plan for existing setups and older hardware. Sometimes changes have to be made. For everything to always be compatible, you'd be overly complicating things that are already complicated enough, just because you think the process is inconvenient. In other words, submit a patch. > > Yes, your way is fine. But so is mine. It is perfectly reasonable to expect > my method to work just as well -- the 7->8 is not revolutionary, but simply > the next step. I read the "UPDATING" file and, though annoyed a little, took > care of things mentioned in there... The remaining things are enumerated > here... > > > Your way clearly isn't fine, as it doesn't work. > > > That's an obviously flawed argument -- this line of thinking can be used > against ANY ONE reporting ANY BUG -- if one has a problem, then one's way of > doing things "clearly isn't fine". I can't boot my computer without power. There must be a bug! If you're doing it wrong, then it's not a bug. Would you expect to be able to use a FreeBSD 2.x kernel config file with 8.x? > > These changes aren't gratuitous. Did you read the commit messages > behind each of the changes? I'm guessing that you haven't. > > > No, and I'm not going to. A commercial OS would've been the laughing stock, > if one hand to change C: to 1: between releases, for example... It's not like this was a minor version bump. You expect to treat it like it is. Most commercial operating systems don't have a simple upgrade path between major versions without other problems, such as application compatibility issues, requiring hardware upgrades, etc. > > Again: this particular change seems gratuitous. > > > It's not. You didn't bother researching before complaining. > > I bothered to type up my list. Presumably, problem-reports are welcome. I've > been a Unix-user since 1990, a FreeBSD user since 1993 (or 94?), and a > project-member for a decade. If I have a problem, then newer users certainly > will too. And, guess what, they'll simply go with something, that does not > give as much grief... PRs are welcome. Not uninformed rants on mailing lists with people that continue to argue because the world didn't start rotating a different direction at their command. I'm surprised you didn't mention your beard length. New users won't be using a FreeBSD 7 kernel config file. They'll be using a FreeBSD 8 kernel config file because they are new. They also won't care that we renamed the serial device between 7.x and 8.x. My logic rocks worlds. > > To put it in simple terms, there were changes made to geom, and the way that > sysinstall writes out dedicated disks wasn't compatible. Search the > mailing list archives. > > > If this is a known problem, it is even more of an outrage, that some shim > was not introduced to keep the users from hitting this particular bump. Yawn. Submit a patch. I dare you. > The modification should be necessary. > > Why? Why should a netboot act differently from a local boot from CD? Because you're booting over a freaking network and not physical media. I am running out of good metaphors for you. Just accept the fact that installing over different media types means the configuration is different. Go look up what that variable means. That might be a good start. > You don't. But there is very little, that needs to be added there for it to > "just work" over both netboot and local CD, and you should do it, instead of > arguing with me here... No, I don't know, what it is exactly, but I'm quite > certain, it can't be very much. So you don't know what the problem is, you don't really know why things have to be done this way, but you're sure that making this change will have no unintended effects. If I made all my commits that way, I'd break the build. Oh, wait... > In fact, the article about PXE booting on the official freebsd website says > nothing about using the ISO. You just found some article that said it > was possible (and it is) and complained because you didn't like the > process? > > > Yes, exactly. I didn't like process -- it is needlessly complicated. The > same CD-image, should also be usable "out of the box" for netbooting. It's obvious you hate process, as you don't file PRs against these problems, you don't search the mailing list, you don't post questions in appropriate places, etc. > Funny. It works just fine in 8.0 on my Athlon. Have you tried updating > the port? > > Yes, I have -- and I said so in my very first e-mail on this subject. For > someone, who expects people to "research mailing lists", you do a terrible > job of following a one-day-old thread... Mine works. Yours doesn't. Maybe you should use portsnap. > Also, even if it didn't work, this is an issue you should > take up with the author of the port. > > Tom -- the maintainer -- is still in CC... Then why didn't you send a separate email to him so he didn't have to wade through this entire post? > > >From the man page: > > The amdtemp driver provides support for the on-die digital thermal > sensor > present in AMD K8, K10 and K11 processors. > > > I know nothing about the driver. Clearly. > But a utility I regularly used stopped > working after upgrade, so I added that to my list of upgrade-related > grudges. I have a grudge as well. I have a grudge against users that abuse developers (oh, you have a reputation, sir), try to use their age (ie: years of experience in being wrong) as an "I know what I'm talking about" point, crosspost unnecessarily long emails, don't file PRs, don't send patches, don't read documentation, and refuse to listen to common sense. No one is agreeing with you. Everyone is telling you that you're wrong. Clearly, it's a conspiracy. -- randi From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 22:21:02 2010 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 28974106566B for ; Wed, 7 Jul 2010 22:21:02 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from eterpe-smout.broadpark.no (eterpe-smout.broadpark.no [80.202.8.16]) by mx1.freebsd.org (Postfix) with ESMTP id D94E38FC15 for ; Wed, 7 Jul 2010 22:21:01 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ignis-smin.broadpark.no ([unknown] [80.202.8.11]) by eterpe-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-12.01 64bit (built Oct 15 2009)) with ESMTP id <0L5700DEVKQW0VC0@eterpe-smout.broadpark.no> for freebsd-stable@freebsd.org; Thu, 08 Jul 2010 00:20:56 +0200 (CEST) Received: from kg-v2.kg4.no ([unknown] [80.203.92.186]) by ignis-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-12.01 64bit (built Oct 15 2009)) with SMTP id <0L5700FZTKQW0PA0@ignis-smin.broadpark.no> for freebsd-stable@freebsd.org; Thu, 08 Jul 2010 00:20:56 +0200 (CEST) Date: Thu, 08 Jul 2010 00:20:56 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100708002056.97f0fef6.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100707193455.786CD1CC0D@ptavv.es.net> References: <4C34C5DE.7040007@aldan.algebra.com> <20100707193455.786CD1CC0D@ptavv.es.net> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: 8.x grudges 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, 07 Jul 2010 22:21:02 -0000 On Wed, 07 Jul 2010 12:34:55 -0700 Kevin Oberman wrote: > k8temp is for older AMD system running K8 cores. It has been mostly > replaced with amdtemp which works on newer cores. I'm not sure if > amdtemp will work on K8 cores, though. It does (amdtemp works on K8s): root@kg-quiet# uname -a FreeBSD kg-quiet.kg4.no 7.3-STABLE FreeBSD 7.3-STABLE #8: Mon Apr 5 21:10:07 CEST 2010 root@kg-quiet.kg4.no:/usr/obj/usr/src/sys/QUIET amd64 root@kg-quiet# sysctl hw.machine hw.machine: amd64 root@kg-quiet# sysctl dev.amdtemp dev.amdtemp.0.%desc: AMD K8 Thermal Sensors dev.amdtemp.0.%driver: amdtemp dev.amdtemp.0.%parent: hostb4 dev.amdtemp.0.sensor0.core0: 45.0C dev.amdtemp.0.sensor0.core1: 46.0C dev.amdtemp.0.sensor1.core0: 46.0C dev.amdtemp.0.sensor1.core1: 46.0C HTH -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 22:22:53 2010 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 C3009106564A for ; Wed, 7 Jul 2010 22:22:53 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from eterpe-smout.broadpark.no (eterpe-smout.broadpark.no [80.202.8.16]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8408FC08 for ; Wed, 7 Jul 2010 22:22:53 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ignis-smin.broadpark.no ([unknown] [80.202.8.11]) by eterpe-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-12.01 64bit (built Oct 15 2009)) with ESMTP id <0L5700DJRKU40VC0@eterpe-smout.broadpark.no> for freebsd-stable@freebsd.org; Thu, 08 Jul 2010 00:22:52 +0200 (CEST) Received: from kg-v2.kg4.no ([unknown] [80.203.92.186]) by ignis-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-12.01 64bit (built Oct 15 2009)) with SMTP id <0L5700ESAKU4IZE0@ignis-smin.broadpark.no> for freebsd-stable@freebsd.org; Thu, 08 Jul 2010 00:22:52 +0200 (CEST) Date: Thu, 08 Jul 2010 00:22:52 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100708002252.0b578eb5.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100708002056.97f0fef6.torfinn.ingolfsen@broadpark.no> References: <4C34C5DE.7040007@aldan.algebra.com> <20100707193455.786CD1CC0D@ptavv.es.net> <20100708002056.97f0fef6.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: 8.x grudges 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, 07 Jul 2010 22:22:53 -0000 On Thu, 08 Jul 2010 00:20:56 +0200 Torfinn Ingolfsen wrote: > On Wed, 07 Jul 2010 12:34:55 -0700 > Kevin Oberman wrote: > > > k8temp is for older AMD system running K8 cores. It has been mostly > > replaced with amdtemp which works on newer cores. I'm not sure if > > amdtemp will work on K8 cores, though. > > It does (amdtemp works on K8s): > root@kg-quiet# uname -a > FreeBSD kg-quiet.kg4.no 7.3-STABLE FreeBSD 7.3-STABLE #8: Mon Apr 5 21:10:07 CEST 2010 root@kg-quiet.kg4.no:/usr/obj/usr/src/sys/QUIET amd64 > root@kg-quiet# sysctl hw.machine > hw.machine: amd64 > root@kg-quiet# sysctl dev.amdtemp > dev.amdtemp.0.%desc: AMD K8 Thermal Sensors > dev.amdtemp.0.%driver: amdtemp > dev.amdtemp.0.%parent: hostb4 > dev.amdtemp.0.sensor0.core0: 45.0C > dev.amdtemp.0.sensor0.core1: 46.0C > dev.amdtemp.0.sensor1.core0: 46.0C > dev.amdtemp.0.sensor1.core1: 46.0C I forgot a part: root@kg-quiet# sysctl hw.model hw.model: AMD Athlon(tm) 64 Processor 3000+ -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 22:40:32 2010 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 8D23C1065672; Wed, 7 Jul 2010 22:40:32 +0000 (UTC) (envelope-from prvs=180478d0fa=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id CE7348FC18; Wed, 7 Jul 2010 22:40:31 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 07 Jul 2010 23:30:18 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 07 Jul 2010 23:30:18 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50010772253.msg; Wed, 07 Jul 2010 23:30:17 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=180478d0fa=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <55392D10B7BA4A3E85835F5B2BBD143B@multiplay.co.uk> From: "Steven Hartland" To: "Randi Harper" , "Mikhail T." References: <4C34C5DE.7040007@aldan.algebra.com><20100707185928.GA16180@icarus.home.lan><4C34E0E6.9070801@aldan.algebra.com><4C34E910.5020007@aldan.algebra.com> Date: Wed, 7 Jul 2010 23:30:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: tom@hur.st, freebsd-stable@freebsd.org, Jeremy Chadwick , freebsd-usb@freebsd.org Subject: Re: 8.x grudges 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, 07 Jul 2010 22:40:32 -0000 For what its worth, we have had good success migrating our kernel configs from 6 -> 7 -> 8 with very few changes, and no real problems. The secret is to create a kernel that is based of GENERIC using include in a "clean" the include that config in top level one which adds the specific additional options you want. It doesn't remove the requirement to check for changes between the versions and act appropriately but it does make this process as simple as diffing the two GENERIC configs and updating our clean and addition configs with the few changes needed. This structure also means kernels compile really quickly :) e.g. [MULTIPLAY] include MULTIPLAY_CLEAN ident MULTIPLAY makeoptions MODULES_OVERRIDE="linux linprocfs acpi nullfs unionfs accf_http if_lagg" options PRINTF_BUFR_SIZE=128 # Fix scrambled output on console options COMPAT_LINUX32 options INCLUDE_CONFIG_FILE options DEVICE_POLLING [/MULTIPLAY] [MULTIPLAY_CLEAN] include GENERIC nooptions INET6 nooptions SCTP nooptions NFS_ROOT nooptions NTFS nooptions MSDOSFS # SCSI Controllers nodevice ahc ... [/MULTIPLAY_CLEAN] Hope this helps. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 02:37:12 2010 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 D8CC2106564A; Thu, 8 Jul 2010 02:37:12 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailD.acsu.buffalo.edu (localmailD.acsu.buffalo.edu [128.205.5.208]) by mx1.freebsd.org (Postfix) with ESMTP id A39E38FC17; Thu, 8 Jul 2010 02:37:12 +0000 (UTC) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B64D3C186F; Wed, 7 Jul 2010 22:37:06 -0400 (EDT) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailD.acsu.buffalo.edu (Postfix) with ESMTP id 9BD69C187C; Wed, 7 Jul 2010 22:37:05 -0400 (EDT) Received: from mweb1.acsu.buffalo.edu (mweb1.acsu.buffalo.edu [128.205.5.238]) by localmailD.acsu.buffalo.edu (Prefixe) with ESMTP id 90992C1860; Wed, 7 Jul 2010 22:37:05 -0400 (EDT) Received: from ken-smiths-macbook-pro.local (cpe-76-180-182-44.buffalo.res.rr.com [76.180.182.44]) by mweb1.acsu.buffalo.edu (Postfix) with ESMTP id 0A5155B0038; Wed, 7 Jul 2010 22:37:04 -0400 (EDT) Message-ID: <4C3539CD.10204@buffalo.edu> Date: Wed, 07 Jul 2010 22:37:01 -0400 From: Ken Smith User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: "Mikhail T." References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> In-Reply-To: <4C34E0E6.9070801@aldan.algebra.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-PM-EL-Spam-Prob: XX: 27% Cc: re@freebsd.org, tom@hur.st, freebsd-stable@freebsd.org, freebsd-usb@freebsd.org, Jeremy Chadwick Subject: Re: 8.x grudges 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, 08 Jul 2010 02:37:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/7/10 4:17 PM, Mikhail T. wrote: > 07.07.2010 14:59, Jeremy Chadwick напиÑав(ла): >>> FREEBSD_COMPAT7 kernel option is, apparently, a requirement (and >>> thus not an "option") -- the kernel-config files, that worked with >>> 7.x, break without this option in them (in addition to all the >>> nuisance, that's documented in UPDATING -- which, somehow, makes >>> the breakage acceptable). config(8) would not warn about this, but >>> kernel build fails. >>> >> We don't use this option (meaning it's removed from our kernels). It's >> definitely not required. All it does is ensure your kernel can >> comprehend executables/binaries built on 7.x. >> > Attached is the kernel config-file (i386), that worked fine under 7.x. > The kernel-compile will break (some *freebsd7* structs undefined), > without the COMPAT_FREEBSD7 option. Try it for yourself... Jeremy is correct. COMPAT_FREEBSD7 means, despite this being FreeBSD 8, set things that have changed up to work in a way that is compatible with FreeBSD 7 *wherever* *possible*. Since you are trying to use a FreeBSD 7 based kernel config file you need that option, but people not trying to hold on to the FreeBSD 7 ways of doing things do not need that option. I'm not quite sure why you find that surprising, though it may have to do with a mis-conception on your part described below. >> The way I do this is, when upgrading major releases (7.x->8.x), to >> "start fresh" using GENERIC as my base template and then >> adding/adjusting while comparing against the older kernels' config. >> Others do it differently, this is just how I do it. >> > Yes, your way is fine. But so is mine. It is perfectly reasonable to > expect my method to work just as well -- the 7->8 is not revolutionary, > but simply the next step. I read the "UPDATING" file and, though annoyed > a little, took care of things mentioned in there... The remaining things > are enumerated here... Actually it's not perfectly reasonable to *expect* your method to work just as well given the general goals of the FreeBSD Project as a whole. Your method *may* work but it's by no means guaranteed, or even a major priority I'm afraid. Your method *may* work. But you can't *expect* it. We like many similar Projects have a wide variety of people involved (both developers and end-users) and an equally wide variety of "needs" those people have. On the one extreme we have developers who feel their hands are tied by not being able to make user-visible changes to stuff - they feel they could make the system better faster if they could change things in incompatible ways faster. On the other extreme we have people who hate change for reasons similar to what you are expressing here - it's a pain in the butt to need to change config files, it sucks if all the old executable files suddenly stop working, etc. So, there has been a long-standing compromise in place. For bumps in *minor* version numbers you can expect to be able to use your old config files, old executables continue to work, etc. This is, for example, moving from 7.2 to 7.3. However for bumps in *major* version numbers there can and likely will be changes made that cause exactly what you are seeing here. A 7.X kernel config file *might* work OK on 8.X but we do not guarantee that. If it does happen to work great, if not sorry. What you call "simply the next step" is a bump in minor version number. Depending on how active the developers have been and what they've focused on major version number bumps *can* qualify as what you call revolutionary. This general mode of operation has been in place for a very long time (it pre-dates my involvement on the Release Engineering Team). - -- Ken Smith - - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw1Oc0ACgkQ/G14VSmup/bEiQCfdtr8UkPp/QRcwUpGTlpRtJ2f RNsAn3+cV4jDuyQ38Wvm5eTiVObJ4DLy =4Bm7 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 10:03:14 2010 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 72E51106564A for ; Thu, 8 Jul 2010 10:03:14 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 2F2BB8FC1E for ; Thu, 8 Jul 2010 10:03:13 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1OWnwm-0005yp-Kq for freebsd-stable@freebsd.org; Thu, 08 Jul 2010 13:03:12 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Jul 2010 13:03:12 +0300 From: Daniel Braniss Message-ID: Subject: problems with 8.1-PRERELEASE 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, 08 Jul 2010 10:03:14 -0000 Hi, I'm running a resent 8.1-Pre (Friday July 2nd), but I've seen this in previous ones too, make buildworld -j will sometimes fail, or even panic. when it failes it's usually some 'internal compiler error' or panic: page fault. The failures I've seen on different hardware, all runing amd64 version, so I doubt it's hardware. Another common point, the all are multicores, both intel and amd. Any one else seeing this? danny From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 10:10:42 2010 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 118441065674 for ; Thu, 8 Jul 2010 10:10:42 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id EEA7D8FC24 for ; Thu, 8 Jul 2010 10:10:41 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta12.emeryville.ca.mail.comcast.net with comcast id fN2i1e0031Y3wxoACNAhth; Thu, 08 Jul 2010 10:10:41 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta15.emeryville.ca.mail.comcast.net with comcast id fNAg1e0023LrwQ28bNAgAg; Thu, 08 Jul 2010 10:10:41 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5AE8D9B423; Thu, 8 Jul 2010 03:10:40 -0700 (PDT) Date: Thu, 8 Jul 2010 03:10:40 -0700 From: Jeremy Chadwick To: Daniel Braniss Message-ID: <20100708101040.GA39197@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: problems with 8.1-PRERELEASE 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, 08 Jul 2010 10:10:42 -0000 On Thu, Jul 08, 2010 at 01:03:12PM +0300, Daniel Braniss wrote: > I'm running a resent 8.1-Pre (Friday July 2nd), but I've seen this in previous > ones too, make buildworld -j will sometimes fail, or even panic. > when it failes it's usually some 'internal compiler error' or > panic: page fault. The failures I've seen on different hardware, all runing > amd64 version, so I doubt it's hardware. Another common point, the all are > multicores, both intel and amd. > > Any one else seeing this? Can you provide a crash dump + ddb trace when the panic happens? -- | Jeremy Chadwick jdc@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 Jul 8 10:15:20 2010 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 3D8561065673 for ; Thu, 8 Jul 2010 10:15:20 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 02FA08FC22 for ; Thu, 8 Jul 2010 10:15:20 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OWo8K-0005Kb-5p; Thu, 08 Jul 2010 11:15:08 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OWo8K-0000g4-4y; Thu, 08 Jul 2010 11:15:08 +0100 Date: Thu, 08 Jul 2010 11:15:08 +0100 Message-Id: To: danny@cs.huji.ac.il, freebsd-stable@freebsd.org In-Reply-To: From: Pete French Cc: Subject: Re: problems with 8.1-PRERELEASE 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, 08 Jul 2010 10:15:20 -0000 > I'm running a resent 8.1-Pre (Friday July 2nd), but I've seen this in previous > ones too, make buildworld -j will sometimes fail, or even panic. > when it failes it's usually some 'internal compiler error' or > panic: page fault. The failures I've seen on different hardware, all runing > amd64 version, so I doubt it's hardware. Another common point, the all are > multicores, both intel and amd. > > Any one else seeing this? I saw this for the first tiem yesterday evening actually - failed a '-j' buildkernel for the fgirst time in years. A subsequent single threaded 'buildworld' + 'buildketnel' worked fine. The machine is a dual core Phenom running 8.1/amd64 -pete. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 10:54:18 2010 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 32293106567A; Thu, 8 Jul 2010 10:54:18 +0000 (UTC) (envelope-from MH@kernel32.de) Received: from crivens.kernel32.de (crivens.asm68k.org [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id A315F8FC1C; Thu, 8 Jul 2010 10:54:17 +0000 (UTC) Received: from thor.mobile.rz (unknown [194.50.70.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by crivens.kernel32.de (Postfix) with ESMTPSA id 85515B03E4; Thu, 8 Jul 2010 12:54:14 +0200 (CEST) Message-ID: <4C35AE56.1040306@kernel32.de> Date: Thu, 08 Jul 2010 12:54:14 +0200 From: Marian Hettwer User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: "Mikhail T." References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> <4C34E910.5020007@aldan.algebra.com> In-Reply-To: <4C34E910.5020007@aldan.algebra.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: tom@hur.st, Jeremy Chadwick , freebsd-stable@freebsd.org, freebsd-usb@freebsd.org, Randi Harper Subject: Re: 8.x grudges 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, 08 Jul 2010 10:54:18 -0000 Am 07.07.10 22:52, schrieb Mikhail T.: > 07.07.2010 16:34, Randi Harper ???????(??): >> >>> Attached is the kernel config-file (i386), that worked fine under >>> 7.x. The >>> kernel-compile will break (some *freebsd7* structs undefined), >>> without the >>> COMPAT_FREEBSD7 option. Try it for yourself... >> Don't use a kernel config from 7. We've already told you this. > Your "telling" me this is just as valid as warning me against using > computer-cases of a particular color. It is a silly requirement. My > expecting things, that worked for 7, to work in 8 is reasonable. There > may be (documented!) exceptions, but it ought to "just work". No. Your expectation is plain wrong. The opposite should be true. If you do a major upgrade (and moving from 7.x to 8 is a major upgrade) you should expect all kinds of changes. What you can expect is, that they're documented in the release notes. This would be a fine gesture of the FreeBSD community. And since I use FreeBSD since 4.0, I can tell, that the documentation of changes is remarkable. If you expect that things continue to work after a major upgrade you really live in some kind of a dreamworld... >> These changes aren't gratuitous. Did you read the commit messages >> behind each of the changes? I'm guessing that you haven't. > No, and I'm not going to. A commercial OS would've been the laughing > stock, if one hand to change C: to 1: between releases, for example... Ah! But changing the $HOME of users of that commercial OS from c:\Documents and Settings\ to c:\Users is okay, right? Wake up man! >>> >>> Again: this particular change seems gratuitous. >> It's not. You didn't bother researching before complaining. > I bothered to type up my list. Presumably, problem-reports are > welcome. I've been a Unix-user since 1990, a FreeBSD user since 1993 > (or 94?), and a project-member for a decade. If *I* have a problem, > then newer users certainly will too. And, guess what, they'll simply > go with something, that does not give as much grief... Then they should do. pfff... I'd like to see them using Linux, which obviously never changes arbitrary... ha. And if you're a unix user since the 1990'ies then you really should know better. >> The modification should be necessary. > Why? Why should a netboot act differently from a local boot from CD? Because it's a completely different type of booting? Oh come one... > You don't. But there is very little, that needs to be added there for > it to "just work" over both netboot and local CD, and you should do > it, instead of arguing with me here... No, I don't know, what it is > exactly, but I'm quite certain, it can't be very much. If it's that important to you, then send in a patch. As a FreeBSD user since 1993 (or 94) you could do your beloved OS a favor, right? >> In fact, the article about PXE booting on the official freebsd >> website says >> nothing about using the ISO. You just found some article that said it >> was possible (and it is) and complained because you didn't like the >> process? > Yes, exactly. I didn't like process -- it is needlessly complicated. > The same CD-image, /should/ also be usable "out of the box" for > netbooting. Then make it work, for f*cks sake! > >> > From the man page: >> >> The amdtemp driver provides support for the on-die digital >> thermal sensor >> present in AMD K8, K10 and K11 processors. > I know nothing about the driver. But a utility I regularly used > stopped working after upgrade, so I added that to my list of > upgrade-related grudges. > As an old fashioned unix guru you should know lots and lots about the driver. Or at least, as a minimum, you should be aware of the available manpage for a utility you're using regularly! Cheers! ./Marian From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 11:41:09 2010 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 51F811065670 for ; Thu, 8 Jul 2010 11:41:09 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id DDB7C8FC19 for ; Thu, 8 Jul 2010 11:41:08 +0000 (UTC) Received: by wwb13 with SMTP id 13so2344769wwb.1 for ; Thu, 08 Jul 2010 04:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=WxrNItAwjxQY826lJiiNIXjVaNDK2PMKg9Z+GphQwyE=; b=nMbIbkr92IARl6Llx4fT3Z+4yYEYCcKkdgVvfZLe5G9Av3bn2GqbI1wthuqQPLT36j 01WOHFhTUU7AJDgAkL1LDIK5iJNG7TphzWaWAg/XvgxqcA6n50hgF8O7/d+50S9nnoGQ RV6qbzCPW/AOjtq+0OUzPW/yU5LKvvNuJbk+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=mQyoNYfeRBqq+Uj4skfmbpsq1yFfAfB6fhAZ2ah6UkUuCkOyF/nbPAfDUL/iX1c6+L LwCCuTnhq+15xjvrpIE5WxzxawNWm91wE7GDuQifZTWUZU5kcxfjuo0l6iBH6vBhhL87 5vjYFVPw/0STE3Zisp9hZDeBflsd632ffekCU= MIME-Version: 1.0 Received: by 10.216.138.65 with SMTP id z43mr2428395wei.12.1278588846343; Thu, 08 Jul 2010 04:34:06 -0700 (PDT) Received: by 10.216.37.68 with HTTP; Thu, 8 Jul 2010 04:34:06 -0700 (PDT) Date: Thu, 8 Jul 2010 15:34:06 +0400 Message-ID: From: pluknet To: freebsd-stable Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: uma_ref_cnt: vm_fault: fault on nofault entry 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, 08 Jul 2010 11:41:09 -0000 Hi. 8.0-RELEASE under xen h/w mode. This is the first time I'm seeing this panic (uptime ~2 weeks). http://img38.imageshack.us/img38/9681/screenshot1mm.png Below is transcribed via OCR from a vnc session. db> bt^M Tracing pid 18908 tid 101404 td 0xc93f9Z40^M kdb_enter(c0c8dceZ,c0c8dceZ,c0cab939,eb0aZ7e4,Z,...) at kdb_entert0x3a panic(c0cab939,cl4b3000,l,eb0aZ914,eb0aZ904,...) at panict0xl36 vm_fault(cl490000,cl4b3000,l,0,c76f3400,...) at vm_fault*0xl97 trap_pfault(80000,eb0aZal0,8538,eb0aZal0,cfeeaaa0,...) at trap_pfaultt0xZ0e trap(eb0aZa30) at trapt0x455 calltrap() at calltrap=E2=95=950x6^M -- trap 0XC, eip =3D 0xc0af336b, esp =3D 0xeb0aZa70, ebp =3D 0xeb0aZa78 = ---^M uma_find_refcnt(cl47a000,c7elc000,3,Z,c7elc000,...) at uma_find_refcntt0x5b mb_ctor_clust(c7elc000,1000,cf87ce00,Z,f8,...) at mb_ctor_clustt0x9c uma_zalloc_arg(cl47a000,cf87ce00,Z,dd0001,c798Z400,...) at uma_zalIoc_argt0= x8a m_getmZ(0,790c,Z,l,0,...) at m_getmZt0xb3 m_uiotombuf(eb0aZc58,Z,790c,0,0,...) at m_uiotombuf^0x77 sosend_generic(cf4c44d4,0,eb0a2c58,0,0,...) at sosend_generic*0x525 sosend(cf4c44d4,0,eb0aZc58,0,0,...) at sosendt0x3f^M soo_write(d004d508,eb0aZc58,cdd4f600,0,c93f9Z40,...) at soo_uritet0x63 dofilewrite(eb0aZc58,ffffffff,ffffffff,0,d004d508,...) at dofilewrite*0x97 kern_writev(c93f9Z40,6,eb0aZc58,eb0aZc78,l,...) at kern_w|titevt0x58 write(c93f9Z40,eb0aZcf8,c,c0890ce8,46,...) at urite*0x4f syscall(eb0aZd38) at syscal+0x3Z5 Xint0x80_syscall() at Xint0x80_syscal+0x20^M --- syscall (4, FreeBSD ELF3Z, urite), eip =3D 0xZ85d4Z53, esp =3D 0xbfbfealc, ebp =3D^M 0xbfbfea38 --- --=20 wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 18:40:51 2010 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 279A21065672 for ; Wed, 7 Jul 2010 18:40:51 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id DD32C8FC13 for ; Wed, 7 Jul 2010 18:40:50 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o67IeovK015465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jul 2010 14:40:50 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o67Ien0D032541; Wed, 7 Jul 2010 14:40:50 -0400 Message-ID: <4C34CA31.7010804@aldan.algebra.com> Date: Wed, 07 Jul 2010 14:40:49 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Randi Harper References: <4C34C5DE.7040007@aldan.algebra.com> In-Reply-To: X-Mailman-Approved-At: Thu, 08 Jul 2010 12:26:13 +0000 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: net-booting the install disks (Re: 8.x grudges) 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, 07 Jul 2010 18:40:51 -0000 07.07.2010 14:30, Randi Harper ÎÁÐÉÓÁ×(ÌÁ): >> 8. >> > I tried to do an install on one of the systems via netbooting >> > (pxeload) the disk1-image. It booted, but the sysinstall had to be >> > started manually and, once started, did not act the same as when >> > booted off of CD-ROM. Seems like a simple bit to correct so that >> > setting "init" to/usr/sbin/sysinstall/manually on every boot/ is >> > not necessary... >> > This shouldn't be the case. IIRC, nothing has changed that would cause > this. More info on your environment please? > Well, I never tried /this/ part before, so I'm not claiming, there is /re/gression here. Just lack of /pro/gress :-) I have the following special entry in the dhcpd.conf: subnet 192.168.1.0 netmask 255.255.255.0 { range dynamic-bootp 192.168.1.150 192.168.1.186; next-server 192.168.1.140; option broadcast-address 192.168.1.255; option routers 192.168.1.1; option root-path "192.168.1.140:/cdrom"; filename "pxeboot"; } The filesystem accessible as /cdrom was an md-accessed FreeBSD-8.1-RC1-i386-disc1.iso (or bootonly). Can't easily recreate this, because the netbooting machine has now gone back to its owner. The problem did not surprise me, because I followed (loosely) the instructions , where it was mentioned -- along with a work-around. If some simple logic can be put into the boot-image to allow it to do the right thing without manual fiddling, it would be great. Thanks! -mi From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 20:29:15 2010 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 A3FE0106566B; Wed, 7 Jul 2010 20:29:15 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id 4E47A8FC0A; Wed, 7 Jul 2010 20:29:14 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o67KTE99003989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jul 2010 16:29:14 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o67KTEsj002084; Wed, 7 Jul 2010 16:29:14 -0400 Message-ID: <4C34E39A.7090905@aldan.algebra.com> Date: Wed, 07 Jul 2010 16:29:14 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Randi Harper References: <4C34C5DE.7040007@aldan.algebra.com> <4C34CA31.7010804@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 08 Jul 2010 12:26:36 +0000 Cc: freebsd-stable@freebsd.org Subject: Re: net-booting the install disks (Re: 8.x grudges) 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, 07 Jul 2010 20:29:15 -0000 07.07.2010 16:00, Randi Harper ÎÁÐÉÓÁ×(ÌÁ): > So.... you're complaining that you have to modify the loader.conf? I > fail to see the problem. This is by design, and isn't a lack of > progress. > Yes, I complain, that I have to modify a loader.conf embedded in a CD-image. If extracting hundreds of mega-bytes of files to make a one-line modification is "by design", then the design is flawed. Especially, when the effect achieved by the one-line modification can be arrived to automatically -- without such modifications. Yours, -mi From owner-freebsd-stable@FreeBSD.ORG Wed Jul 7 20:53:50 2010 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 F0C101065673; Wed, 7 Jul 2010 20:53:50 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id 990A58FC1E; Wed, 7 Jul 2010 20:53:50 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o67KrnL3008690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jul 2010 16:53:50 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o67KrnTm009829; Wed, 7 Jul 2010 16:53:49 -0400 Message-ID: <4C34E95D.5000903@aldan.algebra.com> Date: Wed, 07 Jul 2010 16:53:49 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.10) Gecko/20100512 Lightning/1.0b1 Thunderbird/3.0.5 MIME-Version: 1.0 To: Marcel Moolenaar References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> <779BFD8C-962A-4577-B794-6AE2B946F4DF@mac.com> In-Reply-To: <779BFD8C-962A-4577-B794-6AE2B946F4DF@mac.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 08 Jul 2010 12:26:50 +0000 Cc: tom@hur.st, Jeremy Chadwick , freebsd-stable@freebsd.org, freebsd-usb@freebsd.org, Randi Harper Subject: Re: 8.x grudges 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, 07 Jul 2010 20:53:51 -0000 07.07.2010 16:50, Marcel Moolenaar ÎÁÐÉÓÁ×(ÌÁ): > Not to mention that if you change uart(4) to create dev entries like sio(4) > after uart(4) has been in the tree for more than 6 years creating ttyu* > entries, you actually introduce a gratuitous change. > If sio and uart could co-exist, then you'd be right. But sio no longer builds under 8.x, so some kind of aliasing (either by uart itself or by devfs) would be useful. -mi From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 12:37:33 2010 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 57F501065672 for ; Thu, 8 Jul 2010 12:37:33 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by mx1.freebsd.org (Postfix) with ESMTP id 0B7FD8FC15 for ; Thu, 8 Jul 2010 12:37:32 +0000 (UTC) Received: from dagger.cc.vt.edu (dagger.cc.vt.edu [198.82.163.114]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id o68CasEA007606; Thu, 8 Jul 2010 08:36:54 -0400 Received: from auth3.smtp.vt.edu (EHLO auth3.smtp.vt.edu) ([198.82.161.152]) by dagger.cc.vt.edu (MOS 4.1.8-GA FastPath queued) with ESMTP id KEB73950; Thu, 08 Jul 2010 08:36:53 -0400 (EDT) Received: from gromit.tower.lib.vt.edu (gromit.tower.lib.vt.edu [128.173.51.22]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id o68CarA6002700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Jul 2010 08:36:53 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Paul Mather In-Reply-To: Date: Thu, 8 Jul 2010 08:36:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <02AECC43-87DC-4B16-B3F4-81186CA69073@gromit.dlib.vt.edu> References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> To: Garrett Cooper X-Mailer: Apple Mail (2.1081) X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu paul@gromit.dlib.vt.edu 5 none X-Mirapoint-IP-Reputation: reputation=neutral-1, source=Fixed, refid=n/a, actions=MAILHURDLE SPF TAG X-Junkmail-Status: score=10/50, host=dagger.cc.vt.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A020204.4C35C666.00E8,ss=1,fgs=0, ip=0.0.0.0, so=2009-09-22 00:05:22, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Cc: re@freebsd.org, "Mikhail T." , FreeBSD Stable , tom@hur.st, Jeremy Chadwick Subject: Re: 8.x grudges 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, 08 Jul 2010 12:37:33 -0000 On Jul 7, 2010, at 5:39 PM, Garrett Cooper wrote: > On Wed, Jul 7, 2010 at 1:17 PM, Mikhail T. = wrote: >> 07.07.2010 14:59, Jeremy Chadwick ???????(??): >>>>=20 >>>> FREEBSD_COMPAT7 kernel option is, apparently, a requirement = (and >>>> thus not an "option") -- the kernel-config files, that worked = with >>>> 7.x, break without this option in them (in addition to all the >>>> nuisance, that's documented in UPDATING -- which, somehow, = makes >>>> the breakage acceptable). config(8) would not warn about this, = but >>>> kernel build fails. >>>>=20 >>>=20 >>> We don't use this option (meaning it's removed from our kernels). = It's >>> definitely not required. All it does is ensure your kernel can >>> comprehend executables/binaries built on 7.x. >>>=20 >>=20 >> Attached is the kernel config-file (i386), that worked fine under = 7.x. The >> kernel-compile will break (some *freebsd7* structs undefined), = without the >> COMPAT_FREEBSD7 option. Try it for yourself... >=20 > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores >=20 > Those require COMPAT_FREEBSD7.=20 I have an FreeBSD/amd64 8.1-PRERELEASE system with all COMPAT_FREEBSDx = options except COMPAT_FREEBSD32 commented out in my kernel config file = and it builds fine. So, unless I am misunderstanding you, I don't think = "options SYSV{SHM,MSG,SEM}" requires COMPAT_FREEBSD7. Cheers, Paul. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 12:46:43 2010 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 CD6451065670 for ; Thu, 8 Jul 2010 12:46:43 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7BB2B8FC13 for ; Thu, 8 Jul 2010 12:46:43 +0000 (UTC) Received: by iwn35 with SMTP id 35so1040608iwn.13 for ; Thu, 08 Jul 2010 05:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=mL6aUzraB0vW5WhDG5rcrxycRITq626qHHKSQEnhhbQ=; b=Lw6gwf5Ct59pPmnHaGBgFVWonjyGUE+qG/iWTA57TgAYT29Ex5rFQ3Xt6al+RqQAPq mVVixjKbD735D4hmEsQn0S92B9fuOQK91MYLXstjo59RfiOZPiAinJ0LDKAg9ljdmGAN IGP3enWXksUOZ9qI+ALjRfSnhmmLYdxp2As0Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=pa4WXyUQ58KAKOMYkYUvzRp6F7JU+kwtywxuoOvhDu4yEigyRcwwP3w1Xt9C9KY4G/ gRqo7iRwiH6eI1Fj+xiTHGRDJTWXXpZUI0Ri3ahZdffA0qNIFzPJOdZJBppBxEuhto/X kA9sN5rEWPTSTNdb0WR/bQw9yOcmXNEi9KgT4= Received: by 10.231.139.195 with SMTP id f3mr8394312ibu.139.1278593202521; Thu, 08 Jul 2010 05:46:42 -0700 (PDT) Received: from centel.dataix.local ([99.181.132.254]) by mx.google.com with ESMTPS id e8sm31630376ibb.20.2010.07.08.05.46.41 (version=SSLv3 cipher=RC4-MD5); Thu, 08 Jul 2010 05:46:41 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C35C8AF.3070409@dataix.net> Date: Thu, 08 Jul 2010 08:46:39 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100626 Thunderbird MIME-Version: 1.0 To: Marian Hettwer References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> <4C34E910.5020007@aldan.algebra.com> <4C35AE56.1040306@kernel32.de> In-Reply-To: <4C35AE56.1040306@kernel32.de> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: 8.x grudges 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, 08 Jul 2010 12:46:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/08/2010 06:54, for whatever Marian Hettwer wrote: With any major upgrade or release process comes a commitment from the developers and end-users alike that involves a review, testing & release. The release part on the end-users behalf is simply a commitment to follow through & make needed changes to what has been reviewed and tested & continue with the current use accepting the changes. Taking a guess here, but you are probably a manager in a company that is asking you to cut back your test environment because it is hard for you to maintain with a under staffed under knowledged IT department resulting in a non-efficient budget that could end up in more staff being cut. Personally even if the above is not true I would fire you and keep a few more testbeds, just for wasting a free projects developers time by posting non nonsensical radical & somewhat fascist views on this list. Everyone has a bad day once in a while but using a troll type manor while ranting and raving obnoxiously instead of getting involved appropriately is unacceptable and will not solve your problem. - -- "I say things as they are. Slackers are called slackers, people who can't read manual pages are called losers, and in general, calling things what they are results in developers wasting less time." -- Theo +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBAgAGBQJMNcivAAoJEJBXh4mJ2FR+h68H/1mw7n4/KpDvzDxa8MACUMYI 9lQGKvKIjm2IrOfWlTpnoOAJOYKmsEE2b9fKht0376z1tze/tssNLkFD0CLZt+NK +Vyt7kraqyv6vn85ZQjLU1OD1z8XAOwVI1EMHusGaJi8VfscLerT1rIDplc1hfFt uH5GYnvepyqxKxtB9a2+eXwyjuz/dlfx4Dj8TvhdbfF9Ge5HuzWZcb4xzCIYPeIA KSrqxbOn5bpgiOW4i83hUT88Ntl7ZTw83UfnsiFOPQmtlzfQorc8QOF+gdjGAsG+ k4AuNoo4fBKbu50kSLO4hf+dccIga3Y3a5P2iwS+ANXbsHs9PcSNZ8p35Tk0MM8= =0IA0 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 12:51:04 2010 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 B44C2106566C; Thu, 8 Jul 2010 12:51:04 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 373A18FC12; Thu, 8 Jul 2010 12:51:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o68CosgA069071; Thu, 8 Jul 2010 22:50:55 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 8 Jul 2010 22:50:54 +1000 (EST) From: Ian Smith To: "Mikhail T." In-Reply-To: <4C34E39A.7090905@aldan.algebra.com> Message-ID: <20100708224907.F54166@sola.nimnet.asn.au> References: <4C34C5DE.7040007@aldan.algebra.com> <4C34CA31.7010804@aldan.algebra.com> <4C34E39A.7090905@aldan.algebra.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org, Randi Harper Subject: Re: net-booting the install disks (Re: 8.x grudges) 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, 08 Jul 2010 12:51:04 -0000 On Wed, 7 Jul 2010, Mikhail T. wrote: > 07.07.2010 16:00, Randi Harper ???????(??): > > So.... you're complaining that you have to modify the loader.conf? I > > fail to see the problem. This is by design, and isn't a lack of > > progress. > > > Yes, I complain, that I have to modify a loader.conf embedded in a CD-image. > If extracting hundreds of mega-bytes of files to make a one-line modification > is "by design", then the design is flawed. Especially, when the effect > achieved by the one-line modification can be arrived to automatically -- > without such modifications. There's a hole in the bucket .. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 13:53:55 2010 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 09F3A1065673 for ; Thu, 8 Jul 2010 13:53:55 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id E2C688FC1F for ; Thu, 8 Jul 2010 13:53:54 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta09.emeryville.ca.mail.comcast.net with comcast id fRCJ1e0061HpZEsA9RtutH; Thu, 08 Jul 2010 13:53:54 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta14.emeryville.ca.mail.comcast.net with comcast id fRtt1e0093LrwQ28aRttMM; Thu, 08 Jul 2010 13:53:54 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5ADC19B423; Thu, 8 Jul 2010 06:53:53 -0700 (PDT) Date: Thu, 8 Jul 2010 06:53:53 -0700 From: Jeremy Chadwick To: "Mikhail T." Message-ID: <20100708135353.GA43460@icarus.home.lan> References: <4C34C5DE.7040007@aldan.algebra.com> <4C34CA31.7010804@aldan.algebra.com> <4C34E39A.7090905@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4C34E39A.7090905@aldan.algebra.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Randi Harper Subject: Re: net-booting the install disks (Re: 8.x grudges) 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, 08 Jul 2010 13:53:55 -0000 On Wed, Jul 07, 2010 at 04:29:14PM -0400, Mikhail T. wrote: > 07.07.2010 16:00, Randi Harper напиÑав(ла): > >So.... you're complaining that you have to modify the loader.conf? I > >fail to see the problem. This is by design, and isn't a lack of > >progress. > Yes, I complain, that I have to modify a loader.conf embedded in a > CD-image. If extracting hundreds of mega-bytes of files to make a > one-line modification is "by design", then the design is flawed. > Especially, when the effect achieved by the one-line modification > can be arrived to automatically -- without such modifications. Then don't modify loader.conf. Instead, once the "Welcome to FreeBSD!" portion of loader appears, press "6" to shell to the loader prompt and type: set vfs.root.mountfrom="ufs:/dev/md0" boot If you want me to test/verify that this works, I can do so when I get home in about an hour (I do have a PXE boot environment set up for testing). If it does work (I don't see why it wouldn't), your next question will be "then why doesn't your doc tell me to do it that way?", which I can answer as well: I based a small portion of my written documentation on what others had written. Many of the other docs advocated doing the same, particularly for setting serial port speed, comconsole, blah blah (because there is no /boot.config used in this boot environment, so you can't do something like add "-S115200 -Dh" to that file). I chose to continue using that nomenclature. -- | Jeremy Chadwick jdc@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 Jul 8 14:08:28 2010 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 DCB7C106564A; Thu, 8 Jul 2010 14:08:28 +0000 (UTC) (envelope-from MH@kernel32.de) Received: from crivens.kernel32.de (crivens.asm68k.org [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id 99BCA8FC14; Thu, 8 Jul 2010 14:08:28 +0000 (UTC) Received: from thor.mobile.rz (unknown [194.50.70.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by crivens.kernel32.de (Postfix) with ESMTPSA id 5E44CB03E4; Thu, 8 Jul 2010 16:08:26 +0200 (CEST) Message-ID: <4C35DBDA.4000109@kernel32.de> Date: Thu, 08 Jul 2010 16:08:26 +0200 From: Marian Hettwer User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: jhell References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> <4C34E910.5020007@aldan.algebra.com> <4C35AE56.1040306@kernel32.de> <4C35C8AF.3070409@dataix.net> In-Reply-To: <4C35C8AF.3070409@dataix.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: 8.x grudges 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, 08 Jul 2010 14:08:29 -0000 Hi jhell, ehm... Am 08.07.10 14:46, wrote jhell: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/08/2010 06:54, for whatever Marian Hettwer wrote: > I certainly not wrote the text below. That's what, I guess, you wrote. Your MUA is defect. And honestly, I don't know why that's a reply to my email (which you completely deleted, apart from the "On 07/08/2010 06:54, for whatever Marian Hettwer wrote") thingy.. confused, Marian PS.: I guess your Mail should have been a reply to someone else's mail?! > With any major upgrade or release process comes a commitment from the > developers and end-users alike that involves a review, testing& release. > > The release part on the end-users behalf is simply a commitment to > follow through& make needed changes to what has been reviewed and > tested& continue with the current use accepting the changes. > > Taking a guess here, but you are probably a manager in a company that > is asking you to cut back your test environment because it is hard for > you to maintain with a under staffed under knowledged IT department > resulting in a non-efficient budget that could end up in more staff > being cut. > > Personally even if the above is not true I would fire you and keep a > few more testbeds, just for wasting a free projects developers time by > posting non nonsensical radical& somewhat fascist views on this list. > > Everyone has a bad day once in a while but using a troll type manor > while ranting and raving obnoxiously instead of getting involved > appropriately is unacceptable and will not solve your problem. > > > - -- > > "I say things as they are. Slackers are called slackers, people who > can't read manual pages are called losers, and in general, calling > things what they are results in developers wasting less time." > -- Theo > > > +-+-+-+-+-+ > |j|h|e|l|l| > +-+-+-+-+-+ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.15 (FreeBSD) > > iQEcBAEBAgAGBQJMNcivAAoJEJBXh4mJ2FR+h68H/1mw7n4/KpDvzDxa8MACUMYI > 9lQGKvKIjm2IrOfWlTpnoOAJOYKmsEE2b9fKht0376z1tze/tssNLkFD0CLZt+NK > +Vyt7kraqyv6vn85ZQjLU1OD1z8XAOwVI1EMHusGaJi8VfscLerT1rIDplc1hfFt > uH5GYnvepyqxKxtB9a2+eXwyjuz/dlfx4Dj8TvhdbfF9Ge5HuzWZcb4xzCIYPeIA > KSrqxbOn5bpgiOW4i83hUT88Ntl7ZTw83UfnsiFOPQmtlzfQorc8QOF+gdjGAsG+ > k4AuNoo4fBKbu50kSLO4hf+dccIga3Y3a5P2iwS+ANXbsHs9PcSNZ8p35Tk0MM8= > =0IA0 > -----END PGP SIGNATURE----- > _______________________________________________ > 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 Jul 8 16:40:25 2010 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 82809106566C for ; Thu, 8 Jul 2010 16:40:25 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id 2CF468FC17 for ; Thu, 8 Jul 2010 16:40:24 +0000 (UTC) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta09.westchester.pa.mail.comcast.net with comcast id fPZf1e0020mv7h059UgRzL; Thu, 08 Jul 2010 16:40:25 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta11.westchester.pa.mail.comcast.net with comcast id fUgP1e00R3LrwQ23XUgQK0; Thu, 08 Jul 2010 16:40:25 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A99699B423; Thu, 8 Jul 2010 09:40:22 -0700 (PDT) Date: Thu, 8 Jul 2010 09:40:22 -0700 From: Jeremy Chadwick To: "Mikhail T." Message-ID: <20100708164022.GA46433@icarus.home.lan> References: <4C34C5DE.7040007@aldan.algebra.com> <4C34CA31.7010804@aldan.algebra.com> <4C34E39A.7090905@aldan.algebra.com> <20100708135353.GA43460@icarus.home.lan> <4C35E9D4.8080007@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4C35E9D4.8080007@aldan.algebra.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: net-booting the install disks (Re: 8.x grudges) 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, 08 Jul 2010 16:40:25 -0000 On Thu, Jul 08, 2010 at 11:08:04AM -0400, Mikhail T. wrote: > 08.07.2010 09:53, Jeremy Chadwick напиÑав(ла): > >Then don't modify loader.conf. Instead, once the "Welcome to FreeBSD!" > >portion of loader appears, press "6" to shell to the loader prompt > >and type: > > > >set vfs.root.mountfrom="ufs:/dev/md0" > >boot > Yes, that works... It just should not be necessary. Okay, so let me get this straight. First the complaint was that you had to modify loader.conf, which involved extracting the CD image, editing the file, yadda yadda. Now that you've been shown you don't have to edit loader.conf, the complaint is "it shouldn't be necessary". :-) There's actually quite a bit about FreeBSD that "shouldn't be necessary" (from an administrator's point of view), but that's a completely separate issue when compared to your "when I do thing X in the kernel config, it breaks". Which of those two approaches do you want to focus on? > Red Hat's "kickstart" does not require one to extract CD-images to > fiddle with a couple of lines, and FreeBSD comes tantalizingly close > to offer the same functionality. Just not quite :-( I've PXE booted Ubuntu and Debian. It was easy to accomplish (read: easier than FreeBSD) because they offer pxelinux vs. FreeBSD's pxeboot. pxelinux[1] offers the ability to read a configuration file via TFTP, which configures pxelinux itself. The configuration capabilities are very impressive[2]. FreeBSD folks interested in PXE should really take a look at this thing. I believe the configuration file is read and applied immediately, so things like serial port speed changes happen before pxelinux outputs anything (e.g. no need to rebuild pxelinux just to get a faster rate). That said, given that FreeBSD's pxeboot requires a bunch of extra work (rebuilding for faster serial speed, and a bunch of other stuff -- it's in my doc), I'm a surprised you're not complaining about that. :-) The bottom line: the PXE booting framework in FreeBSD could be improved. Even Randi would agree with this point, I think. But the question then becomes: what can you bring to the table which can help improve the situation? If you have the skills to help improve the situation, please help. By making it better for yourself, you can help make it better for everyone; a win-win situation. Anyway, your list of irritations when upgrading from 7.x to 8.x are mainly opinions -- and that's okay. I don't necessarily have a problem with your opinions, despite some being inaccurate or wrong; nothing wrong with being wrong! I'm not being sarcastic when I say I *do* appreciate the feedback you've provided (the method of approach is similar to how I go about things; I've quite a big list of "WTFs" when it comes to software in general), but you need to be reasonable and focus on a compromise. I think the community wants to help you but you definitely want things a certain way or have a lot of pre-conceived notions regarding what kernel or userland pieces "should or should not change". That's just not a realistic way to approach computing these days. So like I said: things change. It's very hard to keep up with all the changes between major FreeBSD releases. The longevity of your use of FreeBSD doesn't matter -- I go back to the 2.2.x days. The difference between 2.x and 8.x is immense, and I'm talking on *all* levels. I had to adapt too, and it takes time to get familiar with all the changes. So please be a bit flexible and we'll do our best to help you fix what's broken *and* help you understand why things are different. [1]: http://syslinux.zytor.com/wiki/index.php/PXELINUX [2]: http://syslinux.zytor.com/wiki/index.php/SYSLINUX#How_do_I_Configure_SYSLINUX.3F (Not a typo; the pxelinux =~ syslinux, same options. See [1], section "What is PXELINUX" for validation) -- | Jeremy Chadwick jdc@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 Jul 8 19:08:07 2010 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 2C0301065673; Thu, 8 Jul 2010 19:08:07 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id BEBBB8FC17; Thu, 8 Jul 2010 19:08:06 +0000 (UTC) Received: by gwb15 with SMTP id 15so455470gwb.13 for ; Thu, 08 Jul 2010 12:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=bU6BmDNh3vNBfi2ofMPLGCZ+QgnDro8MLDK3RW8ijYA=; b=p34N9n2eQnmvd2/YTPO55NjOBuK+di/7yyTghDhaaYapfDsrAjSjKpZhTROSUDq4wO cCVtqE7VdjdoQBef/1oiMyjaq5EqSo4Ct53vfTDQLNFh3h1qxjvzRSMBkd/GWBSqMeuF bEvp9vFud1HfxnG1z5YAebufN+y7FIn8oaKBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=eu5XBfF3+intJGjUuyTIMcP2YqKHJXA+wSu3CgiVmy47lhdh4iBakFbEsMhH8qwAbN jv+5K4TvTyrSzIXKwuQdEy8w0EzVV5CA6O/0Zhty3OogNw2s6MfbiU4J3zz4aL69RgHP rUxyJBcv5O1E5zkMs1EDkrEUW5gDLFueceteo= Received: by 10.150.242.7 with SMTP id p7mr877254ybh.371.1278616081700; Thu, 08 Jul 2010 12:08:01 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-132-254.dsl.klmzmi.sbcglobal.net [99.181.132.254]) by mx.google.com with ESMTPS id g31sm43351ibh.4.2010.07.08.12.07.59 (version=SSLv3 cipher=RC4-MD5); Thu, 08 Jul 2010 12:07:59 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C36220D.7030100@dataix.net> Date: Thu, 08 Jul 2010 15:07:57 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100626 Thunderbird MIME-Version: 1.0 To: Marian Hettwer References: <4C34C5DE.7040007@aldan.algebra.com> <20100707185928.GA16180@icarus.home.lan> <4C34E0E6.9070801@aldan.algebra.com> <4C34E910.5020007@aldan.algebra.com> <4C35AE56.1040306@kernel32.de> <4C35C8AF.3070409@dataix.net> <4C35DBDA.4000109@kernel32.de> In-Reply-To: <4C35DBDA.4000109@kernel32.de> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, freebsd-usb@freebsd.org Subject: Re: 8.x grudges 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, 08 Jul 2010 19:08:07 -0000 On 07/08/2010 10:08, Marian Hettwer wrote: > Hi jhell, > > ehm... > > Am 08.07.10 14:46, wrote jhell: > On 07/08/2010 06:54, for whatever Marian Hettwer wrote: > >> I certainly not wrote the text below. That's what, I guess, you wrote. >> Your MUA is defect. >> And honestly, I don't know why that's a reply to my email (which you >> completely deleted, apart from the "On 07/08/2010 06:54, for whatever >> Marian Hettwer wrote") thingy.. > >> confused, >> Marian > >> PS.: I guess your Mail should have been a reply to someone else's mail?! > Yeah... that was not intended to go to you. ugh! ;( -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 21:07:33 2010 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 13922106564A for ; Thu, 8 Jul 2010 21:07:33 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id 96C128FC1B for ; Thu, 8 Jul 2010 21:07:32 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c211-30-160-13.belrs4.nsw.optusnet.com.au [211.30.160.13]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o68L7I7q029877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jul 2010 07:07:24 +1000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o68L6H1X034320; Fri, 9 Jul 2010 07:06:17 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o68L6GVY034319; Fri, 9 Jul 2010 07:06:16 +1000 (EST) (envelope-from peter) Date: Fri, 9 Jul 2010 07:06:14 +1000 From: Peter Jeremy To: "Mikhail T." Message-ID: <20100708210611.GA34250@server.vk2pj.dyndns.org> References: <4C34C5DE.7040007@aldan.algebra.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: <4C34C5DE.7040007@aldan.algebra.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: 8.x grudges 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, 08 Jul 2010 21:07:33 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Jul-07 14:22:22 -0400, "Mikhail T." wro= te: >In no particular order: > > 1. > A picture, that one of the systems was displaying at boot (and > then used as a screen-saver), stopped showing properly. The > colors are right, but the picture is distorted beyond recognition. > The relevant part of loader.conf is: > > splash_pcx_load=3D"YES" > vesa_load=3D"YES" > bitmap_load=3D"YES" > bitmap_name=3D"/boot/187426-9-quokka-dreaming.pcx" It's a bit difficult to provide any useful input without some idea of what the picture should and does look like. Can you please post the actual bitmap as well as a picture of your screen showing the problem. > 3. > Likewise, having "device ugen" breaks config(8) -- another > undocumented incompatibility. Can you please advise where it is documented that "device ugen" is valid in a FreeBSD-8 config file? > 5. > One of the upgraded systems would repeatedly hang at boot, until I > disabled the on-board firewire-device through the BIOS... It was > not a problem under 7.x, although I don't know, whether the device > actually worked. I haven't seen this on any of my systems. Can you please provide details of your motherboard, BIOS and the output from a verbose boot up to the hang. Is there a BIOS update available and have you tried installing it? > 6. > Despite the reported improvements in the USB area, my USB keyboard > /still/ does not work during boot. It during POST and then after > the booting is complete. But in single-user mode -- no... Had to > fish-out the PS2 keyboard... I have had similar problems on one of my USB-only desktops. In my case, moving the keyboard to a different USB port solved the problem. All I can suggest is to work your way through all the USB ports you have available and see if they all behavee the same. --=20 Peter Jeremy --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkw2PcIACgkQ/opHv/APuIdmZQCghkru3knpujXaWTLyNmSRUGnz RrcAoLfyHCnHBRSgo25k2jcHhNhULJoD =dElb -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 21:36:27 2010 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 073931065678 for ; Thu, 8 Jul 2010 21:36:27 +0000 (UTC) (envelope-from luke@foolishgames.com) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id D95968FC21 for ; Thu, 8 Jul 2010 21:36:26 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta15.emeryville.ca.mail.comcast.net with comcast id fQug1e00416AWCUAFZcSzT; Thu, 08 Jul 2010 21:36:26 +0000 Received: from stargazer.midnightbsd.org ([70.91.226.201]) by omta06.emeryville.ca.mail.comcast.net with comcast id fZcQ1e00A4MLobJ8SZcR1T; Thu, 08 Jul 2010 21:36:26 +0000 Received: from lholt-desktop.primemediaanalysis.com (75-151-13-201-Michigan.hfc.comcastbusiness.net [75.151.13.201]) (authenticated bits=0) by stargazer.midnightbsd.org (8.14.4/8.14.4) with ESMTP id o68LaJ0w066172 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 8 Jul 2010 17:36:23 -0400 (EDT) (envelope-from luke@foolishgames.com) X-Authentication-Warning: stargazer.midnightbsd.org: Host 75-151-13-201-Michigan.hfc.comcastbusiness.net [75.151.13.201] claimed to be lholt-desktop.primemediaanalysis.com Message-ID: <4C3644D1.6000407@foolishgames.com> Date: Thu, 08 Jul 2010 17:36:17 -0400 From: Lucas Holt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100707 Thunderbird/3.0.5 MIME-Version: 1.0 To: Peter Jeremy References: <4C34C5DE.7040007@aldan.algebra.com> <20100708210611.GA34250@server.vk2pj.dyndns.org> In-Reply-To: <20100708210611.GA34250@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Mikhail T." , freebsd-stable@freebsd.org Subject: Re: 8.x grudges 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, 08 Jul 2010 21:36:27 -0000 On 07/08/10 17:06, Peter Jeremy wrote: > On 2010-Jul-07 14:22:22 -0400, "Mikhail T." wrote: > >> In no particular order: >> >> 1. >> A picture, that one of the systems was displaying at boot (and >> then used as a screen-saver), stopped showing properly. The >> colors are right, but the picture is distorted beyond recognition. >> The relevant part of loader.conf is: >> >> splash_pcx_load="YES" >> vesa_load="YES" >> bitmap_load="YES" >> bitmap_name="/boot/187426-9-quokka-dreaming.pcx" >> > It's a bit difficult to provide any useful input without some idea > of what the picture should and does look like. Can you please post > the actual bitmap as well as a picture of your screen showing the > problem. > > >> 3. >> Likewise, having "device ugen" breaks config(8) -- another >> undocumented incompatibility. >> > Can you please advise where it is documented that "device ugen" > is valid in a FreeBSD-8 config file? > NAME ugen -- USB generic device support SYNOPSIS To compile this driver into the kernel, place the following line in your kernel configuration file: device ugen Alternatively, to load the driver as a module at boot time, place the following line in loader.conf(5): ugen_load="YES" DESCRIPTION The ugen driver provides support for all USB devices that do not have a special driver. It supports access to all parts of the device, but not in a way that is as convenient as a special purpose driver. There can be up to 127 USB devices connected to a USB bus. Each USB device can have up to 16 endpoints. Each of these endpoints will commu- uname -a FreeBSD lholt-desktop.primemediaanalysis.com 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #0: Tue May 25 20:54:11 UTC 2010 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 I'm not going to argue in favor of any points in this rant, but it is in the man page. As someone who's done some release engineering and worked with sysinstall on my own project, I can tell you it's a real pain and developers in the FreeBSD community deserve courtesy. Most of us work on open source for free in our own time, and it's impossible to test every possible configuration before a release. Luke From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 21:46:19 2010 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 8364B1065670 for ; Thu, 8 Jul 2010 21:46:19 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 48DDD8FC18 for ; Thu, 8 Jul 2010 21:46:18 +0000 (UTC) Received: by iwn35 with SMTP id 35so1674828iwn.13 for ; Thu, 08 Jul 2010 14:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=LZUPb3q+IaxTHfHEgDvdEcrHBinqGx4ydmPR+oCrlRI=; b=GZPcM29zhojTLKRQ1meXNmoNXnu+CkaN+bwNY114DGJujdm6lObTARucvq8t0NhgB9 q3Xs0ostN1joupXwfrsgya+5Erw5J77AW9dG3aBmTxbReFSZQIbsCK4iTvIgiKXHANb8 JgUjlqdz79Hl/+5892CCogl6nzB4/bVoNKyWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=EmTJds+cc43MlQyxf2Gn8wyOwhP33mTryeHIzfYaLaRhDSnHbJZxowCFctuqO3D4Go dgiAuJz0q1sCFN3TiKYf2tsskcdLirN6tjD2XFMIV06lGbtyBq+oWID04xN8HxxOZl4K plzDgUVNju0LQWWR4o4e3UaZTdQo4DNsYnelY= MIME-Version: 1.0 Received: by 10.231.167.80 with SMTP id p16mr8715828iby.94.1278625576355; Thu, 08 Jul 2010 14:46:16 -0700 (PDT) Received: by 10.231.37.11 with HTTP; Thu, 8 Jul 2010 14:46:16 -0700 (PDT) In-Reply-To: <4C3644D1.6000407@foolishgames.com> References: <4C34C5DE.7040007@aldan.algebra.com> <20100708210611.GA34250@server.vk2pj.dyndns.org> <4C3644D1.6000407@foolishgames.com> Date: Thu, 8 Jul 2010 14:46:16 -0700 Message-ID: From: Freddie Cash To: FreeBSD Stable Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: 8.x grudges 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, 08 Jul 2010 21:46:19 -0000 On Thu, Jul 8, 2010 at 2:36 PM, Lucas Holt wrote: > On 07/08/10 17:06, Peter Jeremy wrote: >> >> On 2010-Jul-07 14:22:22 -0400, "Mikhail T." >> =C2=A0wrote: >> >>> >>> In no particular order: >>> >>> =C2=A0 1. >>> =C2=A0 =C2=A0 =C2=A0A picture, that one of the systems was displaying a= t boot (and >>> =C2=A0 =C2=A0 =C2=A0then used as a screen-saver), =C2=A0stopped showing= properly. The >>> =C2=A0 =C2=A0 =C2=A0colors are right, but the picture is distorted beyo= nd recognition. >>> =C2=A0 =C2=A0 =C2=A0The relevant part of loader.conf is: >>> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0splash_pcx_load=3D"YES" >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vesa_load=3D"YES" >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bitmap_load=3D"YES" >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bitmap_name=3D"/boot/187426-9-quokka-= dreaming.pcx" >>> >> >> It's a bit difficult to provide any useful input without some idea >> of what the picture should and does look like. =C2=A0Can you please post >> the actual bitmap as well as a picture of your screen showing the >> problem. >> >> >>> >>> =C2=A0 3. >>> =C2=A0 =C2=A0 =C2=A0Likewise, having "device ugen" breaks config(8) -- = another >>> =C2=A0 =C2=A0 =C2=A0undocumented incompatibility. >>> >> >> Can you please advise where it is documented that "device ugen" >> is valid in a FreeBSD-8 config file? >> > NAME > =C2=A0 =C2=A0 ugen -- USB generic device support > > SYNOPSIS > =C2=A0 =C2=A0 To compile this driver into the kernel, place the following= line in your > =C2=A0 =C2=A0 kernel configuration file: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 device ugen > > =C2=A0 =C2=A0 Alternatively, to load the driver as a module at boot time,= place the > =C2=A0 =C2=A0 following line in loader.conf(5): > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ugen_load=3D"YES" > > DESCRIPTION > =C2=A0 =C2=A0 The ugen driver provides support for all USB devices that d= o not have a > =C2=A0 =C2=A0 special driver. =C2=A0It supports access to all parts of th= e device, but not > =C2=A0 =C2=A0 in a way that is as convenient as a special purpose driver. > > =C2=A0 =C2=A0 There can be up to 127 USB devices connected to a USB bus. = =C2=A0Each USB > =C2=A0 =C2=A0 device can have up to 16 endpoints. =C2=A0Each of these end= points will commu- > > > uname -a > FreeBSD lholt-desktop.primemediaanalysis.com 8.0-RELEASE-p3 FreeBSD > 8.0-RELEASE-p3 #0: Tue May 25 20:54:11 UTC 2010 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC =C2=A0amd= 64 > > I'm not going to argue in favor of any points in this rant, but it is in = the > man page. Looks like you found a bug. :) ugen is not listed in any of the NOTES files, and is not a valid device entry for a 8.x kernel config file. Maybe that man page got skipped in the USB stack upgrade? Should definitely add a PR for this man page to be updated for the new USB stack. Maybe even do an audit of the rest of the USB devices to make sure the man pages for those are correct as well. --=20 Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 22:41:08 2010 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 5E4CE106564A for ; Thu, 8 Jul 2010 22:41:08 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 09AAB8FC18 for ; Thu, 8 Jul 2010 22:41:07 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta13.westchester.pa.mail.comcast.net with comcast id fPCa1e0061ap0As5Dah8jW; Thu, 08 Jul 2010 22:41:08 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta22.westchester.pa.mail.comcast.net with comcast id fah71e0023LrwQ23iah7hx; Thu, 08 Jul 2010 22:41:08 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D44E69B423; Thu, 8 Jul 2010 15:41:05 -0700 (PDT) Date: Thu, 8 Jul 2010 15:41:05 -0700 From: Jeremy Chadwick To: Freddie Cash Message-ID: <20100708224105.GA57691@icarus.home.lan> References: <4C34C5DE.7040007@aldan.algebra.com> <20100708210611.GA34250@server.vk2pj.dyndns.org> <4C3644D1.6000407@foolishgames.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Stable Subject: Re: 8.x grudges 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, 08 Jul 2010 22:41:08 -0000 On Thu, Jul 08, 2010 at 02:46:16PM -0700, Freddie Cash wrote: > On Thu, Jul 8, 2010 at 2:36 PM, Lucas Holt wrote: > > On 07/08/10 17:06, Peter Jeremy wrote: > >> > >> On 2010-Jul-07 14:22:22 -0400, "Mikhail T." > >>  wrote: > >> > >>> > >>> In no particular order: > >>> > >>>   1. > >>>      A picture, that one of the systems was displaying at boot (and > >>>      then used as a screen-saver),  stopped showing properly. The > >>>      colors are right, but the picture is distorted beyond recognition. > >>>      The relevant part of loader.conf is: > >>> > >>>          splash_pcx_load="YES" > >>>          vesa_load="YES" > >>>          bitmap_load="YES" > >>>          bitmap_name="/boot/187426-9-quokka-dreaming.pcx" > >>> > >> > >> It's a bit difficult to provide any useful input without some idea > >> of what the picture should and does look like.  Can you please post > >> the actual bitmap as well as a picture of your screen showing the > >> problem. > >> > >> > >>> > >>>   3. > >>>      Likewise, having "device ugen" breaks config(8) -- another > >>>      undocumented incompatibility. > >>> > >> > >> Can you please advise where it is documented that "device ugen" > >> is valid in a FreeBSD-8 config file? > >> > > NAME > >     ugen -- USB generic device support > > > > SYNOPSIS > >     To compile this driver into the kernel, place the following line in your > >     kernel configuration file: > > > >           device ugen > > > >     Alternatively, to load the driver as a module at boot time, place the > >     following line in loader.conf(5): > > > >           ugen_load="YES" > > > > DESCRIPTION > >     The ugen driver provides support for all USB devices that do not have a > >     special driver.  It supports access to all parts of the device, but not > >     in a way that is as convenient as a special purpose driver. > > > >     There can be up to 127 USB devices connected to a USB bus.  Each USB > >     device can have up to 16 endpoints.  Each of these endpoints will commu- > > > > > > uname -a > > FreeBSD lholt-desktop.primemediaanalysis.com 8.0-RELEASE-p3 FreeBSD > > 8.0-RELEASE-p3 #0: Tue May 25 20:54:11 UTC 2010 > > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64 > > > > I'm not going to argue in favor of any points in this rant, but it is in the > > man page. > > Looks like you found a bug. :) > > ugen is not listed in any of the NOTES files, and is not a valid > device entry for a 8.x kernel config file. Maybe that man page got > skipped in the USB stack upgrade? > > Should definitely add a PR for this man page to be updated for the new > USB stack. Maybe even do an audit of the rest of the USB devices to > make sure the man pages for those are correct as well. In this specific case it's a bug -- someone didn't remove ugen.4 from the build tree. But be careful when it comes to relying on "man" to indicate a feature existing. Some older users may remember how catman pages could (can? It may still happen -- though my quick dig through periodic's 330.catman indicates catman(1)'s -r flag is now used, so things SHOULD be in sync at all times now) get out of sync. With regards to "leftover man pages" in /usr/share/man/manX, I believe mergemaster now handles clean-up of those, and probably catX too. Can't remember (I've been up for 22 hours, cut me some slack :-) ). I will take a moment to mention periodic(8)'s "weekly_catman_enable" variable, which is wonderful except for the fact that tons of our man pages don't play nice with "nroff -man" so you'll see tons of warnings every week -- with no filenames emitted to track down the offender. Frustrating! Maybe catman(1)'s -v flag emits the filename it's handing off to nroff? Not sure. Either way, highly frustrating. So for rebuilding catman pages, I recommend folks do it manually. Run /etc/periodic/weekly/330.catman by hand (with the periodic.conf variable set to "yes" of course), enjoy the warnings, then disable the variable in the conf once more. Man pages!!! *shakes fist angrily* -- | Jeremy Chadwick jdc@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 Jul 8 23:05:33 2010 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 8699D106564A for ; Thu, 8 Jul 2010 23:05:33 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 33FA68FC14 for ; Thu, 8 Jul 2010 23:05:33 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o68N5EBf016562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Jul 2010 16:05:15 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id A37BC1CC42; Thu, 8 Jul 2010 16:05:14 -0700 (PDT) To: Lucas Holt In-reply-to: Your message of "Thu, 08 Jul 2010 17:36:17 EDT." <4C3644D1.6000407@foolishgames.com> Date: Thu, 08 Jul 2010 16:05:14 -0700 From: "Kevin Oberman" Message-Id: <20100708230514.A37BC1CC42@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-07-08_02:2010-02-06, 2010-07-08, 2010-07-08 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1007080123 Cc: "Mikhail T." , freebsd-stable@freebsd.org, Peter Jeremy Subject: Re: 8.x grudges 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, 08 Jul 2010 23:05:33 -0000 > Date: Thu, 08 Jul 2010 17:36:17 -0400 > From: Lucas Holt > Sender: owner-freebsd-stable@freebsd.org > > On 07/08/10 17:06, Peter Jeremy wrote: > > On 2010-Jul-07 14:22:22 -0400, "Mikhail T." wrote: > > > >> In no particular order: > >> > >> 1. > >> A picture, that one of the systems was displaying at boot (and > >> then used as a screen-saver), stopped showing properly. The > >> colors are right, but the picture is distorted beyond recognition. > >> The relevant part of loader.conf is: > >> > >> splash_pcx_load="YES" > >> vesa_load="YES" > >> bitmap_load="YES" > >> bitmap_name="/boot/187426-9-quokka-dreaming.pcx" > >> > > It's a bit difficult to provide any useful input without some idea > > of what the picture should and does look like. Can you please post > > the actual bitmap as well as a picture of your screen showing the > > problem. > > > > > >> 3. > >> Likewise, having "device ugen" breaks config(8) -- another > >> undocumented incompatibility. > >> > > Can you please advise where it is documented that "device ugen" > > is valid in a FreeBSD-8 config file? > > > NAME > ugen -- USB generic device support > > SYNOPSIS > To compile this driver into the kernel, place the following line > in your > kernel configuration file: > > device ugen > > Alternatively, to load the driver as a module at boot time, place the > following line in loader.conf(5): > > ugen_load="YES" > > DESCRIPTION > The ugen driver provides support for all USB devices that do not > have a > special driver. It supports access to all parts of the device, > but not > in a way that is as convenient as a special purpose driver. > > There can be up to 127 USB devices connected to a USB bus. Each USB > device can have up to 16 endpoints. Each of these endpoints will > commu- > > > uname -a > FreeBSD lholt-desktop.primemediaanalysis.com 8.0-RELEASE-p3 FreeBSD > 8.0-RELEASE-p3 #0: Tue May 25 20:54:11 UTC 2010 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > I'm not going to argue in favor of any points in this rant, but it is in > the man page. As someone who's done some release engineering and worked > with sysinstall on my own project, I can tell you it's a real pain and > developers in the FreeBSD community deserve courtesy. Most of us work > on open source for free in our own time, and it's impossible to test > every possible configuration before a release. Oops! This one seems to have been left in the V8 sources, but there is no ugen device in version 8. ugen still sort of exists, but it is part of the base USB driver and not a separate device any longer. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 23:21:21 2010 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 4D301106564A for ; Thu, 8 Jul 2010 23:21:21 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id D74A58FC08 for ; Thu, 8 Jul 2010 23:21:20 +0000 (UTC) Received: (qmail 20643 invoked by uid 399); 8 Jul 2010 23:21:19 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 8 Jul 2010 23:21:19 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Thu, 8 Jul 2010 16:21:17 -0700 (PDT) From: Doug Barton To: Jeremy Chadwick In-Reply-To: <20100708224105.GA57691@icarus.home.lan> Message-ID: References: <4C34C5DE.7040007@aldan.algebra.com> <20100708210611.GA34250@server.vk2pj.dyndns.org> <4C3644D1.6000407@foolishgames.com> <20100708224105.GA57691@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Stable Subject: Re: 8.x grudges 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, 08 Jul 2010 23:21:21 -0000 On Thu, 8 Jul 2010, Jeremy Chadwick wrote: > With regards to "leftover man pages" in /usr/share/man/manX, I believe > mergemaster now handles clean-up of those, and probably catX too. Never has, never will. :) What I actually advocate is 'rm -r /usr/share/man' before doing installworld. Been doing that myself for years and years, never have to deal with the out of date man page problem you described so well in your post. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-stable@FreeBSD.ORG Thu Jul 8 23:42:26 2010 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 2C90E106566B for ; Thu, 8 Jul 2010 23:42:26 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D15418FC08 for ; Thu, 8 Jul 2010 23:42:25 +0000 (UTC) Received: by vws6 with SMTP id 6so2150139vws.13 for ; Thu, 08 Jul 2010 16:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=1SnnMe1Tpi+gx0DuW3ozhG2hS1FAM62DYAo5bhn/B2Q=; b=fLXD2y6UyJ0R+FaM7l5fMklV1u1+LDOrcydL0fp++l/6XC0caRY2h/V2DLhLKg3nWI xlsXv9eaTSa6PBasbUWjkbOV9p3a9izFIMjENuZjRtx9cEQifqB2qRnz/ZOJ8MVkegvY KBuBuhbiCY9bsy55FFnb63Utsy67NIbnxsygk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=X20FK012F5YoG97UXWTneOIGZfbFSWaokSAnZJL4wIGpU6bHfST/8HdyscEBVBT51c 4XIknEe+b0VjId03irXkED/jQlBaT3+YJzugISYdoFCV2Fi0H4mEVJC4iDSleMdwGZZy T5MG1yDxR1H2Bz9maTDHlwnVHeHYYmBfBuHzo= Received: by 10.220.167.133 with SMTP id q5mr4778016vcy.114.1278632538539; Thu, 08 Jul 2010 16:42:18 -0700 (PDT) Received: from schism.local (c-71-230-240-241.hsd1.pa.comcast.net [71.230.240.241]) by mx.google.com with ESMTPS id k10sm294299vcj.19.2010.07.08.16.42.16 (version=SSLv3 cipher=RC4-MD5); Thu, 08 Jul 2010 16:42:16 -0700 (PDT) Message-ID: <4C366257.8040201@gmail.com> Date: Thu, 08 Jul 2010 19:42:15 -0400 From: Glen Barber User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: stable@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: sshd logging with key-only authentication 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, 08 Jul 2010 23:42:26 -0000 Hi, I've been seeing quite a bit of ssh bruteforce attacks which appear to be dictionary-based. That's fine; I have proper measures in place, such as key-only access, bruteforce tables for PF, and so on; though some of the attacks are delaying login attempts, bypassing the bruteforce rules, but that isn't the reason for this post. What caught my interest is if I attempt to log in from a machine where I do not have my key or an incorrect key, I see nothing logged in auth.log about a failed login attempt. If I attempt with an invalid username, as expected, I see 'Invalid user ${USER} from ${IP}.' I'm more concerned with ssh login failures with valid user names. Looking at crypto/openssh/auth.c, allowed_user() returns true if the user is not in DenyUsers or DenyGroups, exists in AllowUsers or AllowGroups (if it is not empty), and has an executable shell. I'm no C hacker, but superficially it looks like it can never meet a condition where the user is valid but the key is invalid to trigger a log entry. Is this a bug in openssh, or have I overlooked something in my configuration? Regards, -- Glen Barber From owner-freebsd-stable@FreeBSD.ORG Fri Jul 9 02:29:37 2010 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 A5450106564A for ; Fri, 9 Jul 2010 02:29:37 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 543C18FC20 for ; Fri, 9 Jul 2010 02:29:37 +0000 (UTC) Received: by vws6 with SMTP id 6so2350784vws.13 for ; Thu, 08 Jul 2010 19:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=z/ezla9ztocbI8sBFNiYNyGQaV3gQnPaOWktKJvDOtg=; b=grA9/WccDw6Xcx67rDMJsToviGPovWeHvOkkh2UOaVKBUk6fat3yTnIFcXU9fjgE4j I4fvqunMFtTXiZeC8Kj++yyDNk7atPjpukl5Rzow7w1tPXZdaQqQwGK+ecSZrgJAiEu+ tul9T7FNIQVkj8wCTS1FYis4NMHXtTxJrwYII= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Wmq9+vb2xzLlAfKGhIpHmWMGYsXP3BXWJPCu4k9hju8WOmzcPUAgCQGb2f06+WVr0s Y7JVd/MUrjmrvSEoiMUnHnwZTfhdcSSPNy7v58ov68hOQ/KC0k9htVdwB3dNxxt8cmz/ qnhTDNGeiPaTOdvNg1WE1BS13v4m6mBrGuaDU= Received: by 10.220.126.166 with SMTP id c38mr4794082vcs.192.1278642567538; Thu, 08 Jul 2010 19:29:27 -0700 (PDT) Received: from schism.local (c-71-230-240-241.hsd1.pa.comcast.net [71.230.240.241]) by mx.google.com with ESMTPS id e20sm445157vcm.16.2010.07.08.19.29.24 (version=SSLv3 cipher=RC4-MD5); Thu, 08 Jul 2010 19:29:25 -0700 (PDT) Message-ID: <4C368983.4040100@gmail.com> Date: Thu, 08 Jul 2010 22:29:23 -0400 From: Glen Barber User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: David Adam References: <4C366257.8040201@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org Subject: Re: sshd logging with key-only authentication 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, 09 Jul 2010 02:29:37 -0000 On 7/8/10 10:24 PM, David Adam wrote: > On Thu, 8 Jul 2010, Glen Barber wrote: >> I've been seeing quite a bit of ssh bruteforce attacks which appear to be >> dictionary-based. That's fine; I have proper measures in place, such as >> key-only access, bruteforce tables for PF, and so on; though some of the >> attacks are delaying login attempts, bypassing the bruteforce rules, but that >> isn't the reason for this post. >> >> What caught my interest is if I attempt to log in from a machine where I do >> not have my key or an incorrect key, I see nothing logged in auth.log about a >> failed login attempt. If I attempt with an invalid username, as expected, I >> see 'Invalid user ${USER} from ${IP}.' >> >> I'm more concerned with ssh login failures with valid user names. Looking at >> crypto/openssh/auth.c, allowed_user() returns true if the user is not in >> DenyUsers or DenyGroups, exists in AllowUsers or AllowGroups (if it is not >> empty), and has an executable shell. I'm no C hacker, but superficially it >> looks like it can never meet a condition where the user is valid but the key >> is invalid to trigger a log entry. >> >> Is this a bug in openssh, or have I overlooked something in my configuration? > > With LogLevel VERBOSE, you should get entries like > sshd[88595]: Failed publickey for root from 130.95.13.18 port 41256 ssh2 > > Is that what you're after? > Sort of, but do I really need to set verbose logging to find that valid users are used in SSH attacks? root is an obvious target, which in my scenario is not allowed. I'm concerned about more specific, allowed users. Regards, -- Glen Barber From owner-freebsd-stable@FreeBSD.ORG Fri Jul 9 02:34:57 2010 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 151E9106566C for ; Fri, 9 Jul 2010 02:34:57 +0000 (UTC) (envelope-from zanchey@ucc.gu.uwa.edu.au) Received: from mail-ext-out2.uwa.edu.au (mail-ext-out2.uwa.edu.au [130.95.3.211]) by mx1.freebsd.org (Postfix) with ESMTP id 82A998FC17 for ; Fri, 9 Jul 2010 02:34:56 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAB4lNkyCX4DX/2dsb2JhbAChJrc8iF4FgnkBgiuDew X-IronPort-AV: E=Sophos;i="4.53,561,1272816000"; d="scan'208";a="30801220" Received: from f5-float.net.uwa.edu.au (HELO mooneye.ucc.gu.uwa.edu.au) ([130.95.128.215]) by mail-ext-out2.uwa.edu.au with ESMTP/TLS/ADH-AES256-SHA; 09 Jul 2010 10:24:42 +0800 Received: by mooneye.ucc.gu.uwa.edu.au (Postfix, from userid 801) id A33CD38643; Fri, 9 Jul 2010 10:24:42 +0800 (WST) Received: from martello.ucc.gu.uwa.edu.au (martello.ucc.gu.uwa.edu.au [130.95.13.23]) by mooneye.ucc.gu.uwa.edu.au (Postfix) with ESMTP id 7CF743809E; Fri, 9 Jul 2010 10:24:42 +0800 (WST) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ucc.gu.uwa.edu.au; s=2009-536; t=1278642282; bh=KtJt4EEqRvbjB2gXwRoFjOVs7gA=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=u/aHQZaSWUOT9VtvM8ZAJHfc9s0MtBpwB/8+xnv8T8UI4GPlszqPSlhD3xCuu7e3D otsVh0fAkAuRT4s5aACkTTAKA== Received: by martello.ucc.gu.uwa.edu.au (Postfix, from userid 11251) id 538046C099; Fri, 9 Jul 2010 10:24:42 +0800 (WST) Received: from localhost (localhost [127.0.0.1]) by martello.ucc.gu.uwa.edu.au (Postfix) with ESMTP id 43A636C08A; Fri, 9 Jul 2010 10:24:42 +0800 (WST) Date: Fri, 9 Jul 2010 10:24:42 +0800 (WST) From: David Adam To: Glen Barber In-Reply-To: <4C366257.8040201@gmail.com> Message-ID: References: <4C366257.8040201@gmail.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: stable@FreeBSD.org Subject: Re: sshd logging with key-only authentication 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, 09 Jul 2010 02:34:57 -0000 On Thu, 8 Jul 2010, Glen Barber wrote: > I've been seeing quite a bit of ssh bruteforce attacks which appear to be > dictionary-based. That's fine; I have proper measures in place, such as > key-only access, bruteforce tables for PF, and so on; though some of the > attacks are delaying login attempts, bypassing the bruteforce rules, but that > isn't the reason for this post. > > What caught my interest is if I attempt to log in from a machine where I do > not have my key or an incorrect key, I see nothing logged in auth.log about a > failed login attempt. If I attempt with an invalid username, as expected, I > see 'Invalid user ${USER} from ${IP}.' > > I'm more concerned with ssh login failures with valid user names. Looking at > crypto/openssh/auth.c, allowed_user() returns true if the user is not in > DenyUsers or DenyGroups, exists in AllowUsers or AllowGroups (if it is not > empty), and has an executable shell. I'm no C hacker, but superficially it > looks like it can never meet a condition where the user is valid but the key > is invalid to trigger a log entry. > > Is this a bug in openssh, or have I overlooked something in my configuration? With LogLevel VERBOSE, you should get entries like sshd[88595]: Failed publickey for root from 130.95.13.18 port 41256 ssh2 Is that what you're after? David Adam zanchey@ucc.gu.uwa.edu.au From owner-freebsd-stable@FreeBSD.ORG Fri Jul 9 03:13:29 2010 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 BCB17106566C for ; Fri, 9 Jul 2010 03:13:29 +0000 (UTC) (envelope-from zanchey@ucc.gu.uwa.edu.au) Received: from mail-ext-out2.uwa.edu.au (mail-ext-out2.uwa.edu.au [130.95.3.211]) by mx1.freebsd.org (Postfix) with ESMTP id 34FBF8FC25 for ; Fri, 9 Jul 2010 03:13:28 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEANYwNkyCX4DX/2dsb2JhbAChJ7cUiF4FgnkBBIIng3s X-IronPort-AV: E=Sophos;i="4.53,562,1272816000"; d="scan'208";a="30808425" Received: from f5-float.net.uwa.edu.au (HELO mooneye.ucc.gu.uwa.edu.au) ([130.95.128.215]) by mail-ext-out2.uwa.edu.au with ESMTP/TLS/ADH-AES256-SHA; 09 Jul 2010 11:13:27 +0800 Received: by mooneye.ucc.gu.uwa.edu.au (Postfix, from userid 801) id 1DA8138643; Fri, 9 Jul 2010 11:13:27 +0800 (WST) Received: from martello.ucc.gu.uwa.edu.au (martello.ucc.gu.uwa.edu.au [130.95.13.23]) by mooneye.ucc.gu.uwa.edu.au (Postfix) with ESMTP id ECFCE3809E; Fri, 9 Jul 2010 11:13:26 +0800 (WST) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ucc.gu.uwa.edu.au; s=2009-536; t=1278645206; bh=zjC5zH6gxvVfi+ys2WDjnDJU6Bw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=KOQ2kjenEv+GWHNUfWmkebHjywEk0KgOsqilMMi7Ijp7iD8vdvM9qT6proTIR2vBc NC7oU1cRW2mAOplAQGILgOZXQ== Received: by martello.ucc.gu.uwa.edu.au (Postfix, from userid 11251) id CD71D6C099; Fri, 9 Jul 2010 11:13:26 +0800 (WST) Received: from localhost (localhost [127.0.0.1]) by martello.ucc.gu.uwa.edu.au (Postfix) with ESMTP id C9FE66C096; Fri, 9 Jul 2010 11:13:26 +0800 (WST) Date: Fri, 9 Jul 2010 11:13:26 +0800 (WST) From: David Adam To: Glen Barber In-Reply-To: <4C368983.4040100@gmail.com> Message-ID: References: <4C366257.8040201@gmail.com> <4C368983.4040100@gmail.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: stable@FreeBSD.org Subject: Re: sshd logging with key-only authentication 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, 09 Jul 2010 03:13:29 -0000 On Thu, 8 Jul 2010, Glen Barber wrote: > On 7/8/10 10:24 PM, David Adam wrote: > > On Thu, 8 Jul 2010, Glen Barber wrote: > > > What caught my interest is if I attempt to log in from a machine > > > where I do not have my key or an incorrect key, I see nothing logged > > > in auth.log about a failed login attempt. If I attempt with an > > > invalid username, as expected, I see 'Invalid user ${USER} from > > > ${IP}.' > > > > > > I'm more concerned with ssh login failures with valid user names. > > > Looking at crypto/openssh/auth.c, allowed_user() returns true if the > > > user is not in DenyUsers or DenyGroups, exists in AllowUsers or > > > AllowGroups (if it is not empty), and has an executable shell. I'm > > > no C hacker, but superficially it looks like it can never meet a > > > condition where the user is valid but the key is invalid to trigger > > > a log entry. > > > > > > Is this a bug in openssh, or have I overlooked something in my > > > configuration? > > > > With LogLevel VERBOSE, you should get entries like > > sshd[88595]: Failed publickey for root from 130.95.13.18 port 41256 ssh2 > > > > Is that what you're after? > > Sort of, but do I really need to set verbose logging to find that valid users > are used in SSH attacks? root is an obvious target, which in my scenario is > not allowed. I'm concerned about more specific, allowed users. It's just an example I pulled out of the logs. You won't get that message for users listed in DenyUsers, although you will get spaff if the denied user attempts password authentication. To me, verbose SSH logging doesn't seem like too big a burden, particularly if coupled with tools like sshit/sshdeny or logwatch. I encourage you to experiment; you could even try patching sshd to emit the relevant log lines at a lower debug level if you want. David Adam UCC Wheel Group zanchey@ucc.gu.uwa.edu.au From owner-freebsd-stable@FreeBSD.ORG Fri Jul 9 04:09:38 2010 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 DFAB6106564A for ; Fri, 9 Jul 2010 04:09:38 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 8C2D38FC19 for ; Fri, 9 Jul 2010 04:09:37 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.4/8.14.4) with ESMTP id o693X5WT000269; Thu, 8 Jul 2010 20:33:05 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.4/8.14.4/Submit) id o693X3jP000268; Thu, 8 Jul 2010 20:33:03 -0700 (PDT) (envelope-from david) Date: Thu, 8 Jul 2010 20:33:03 -0700 From: David Wolfskill To: Glen Barber Message-ID: <20100709033303.GU90096@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Glen Barber , stable@freebsd.org References: <4C366257.8040201@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uJNQuIR499bBFtzc" Content-Disposition: inline In-Reply-To: <4C366257.8040201@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: stable@freebsd.org Subject: Re: sshd logging with key-only authentication 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, 09 Jul 2010 04:09:39 -0000 --uJNQuIR499bBFtzc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 08, 2010 at 07:42:15PM -0400, Glen Barber wrote: > ...=20 > What caught my interest is if I attempt to log in from a machine where I= =20 > do not have my key or an incorrect key, I see nothing logged in auth.log= =20 > about a failed login attempt. If I attempt with an invalid username, as= =20 > expected, I see 'Invalid user ${USER} from ${IP}.' >=20 > I'm more concerned with ssh login failures with valid user names.=20 > Looking at crypto/openssh/auth.c, allowed_user() returns true if the=20 > user is not in DenyUsers or DenyGroups, exists in AllowUsers or=20 > AllowGroups (if it is not empty), and has an executable shell. I'm no C= =20 > hacker, but superficially it looks like it can never meet a condition=20 > where the user is valid but the key is invalid to trigger a log entry. >=20 > Is this a bug in openssh, or have I overlooked something in my=20 > configuration? What I do is configure IPFW to log all attempted session-initiation packets on 22/tcp, and correlate /var/log/auth.log & /var/log/security. It's rather interesting to see how many entries show up in the latter that have no corresponding entry in the former. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --uJNQuIR499bBFtzc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkw2mG8ACgkQmprOCmdXAD00gQCdHh/PqQDbfIfuVNOgWHwy6Su2 TW8AnRw/vYPlwRyj04jupXe7OhZd6eoU =EKMy -----END PGP SIGNATURE----- --uJNQuIR499bBFtzc-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 9 05:11:22 2010 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 EBE641065673 for ; Fri, 9 Jul 2010 05:11:21 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id B9F798FC1F for ; Fri, 9 Jul 2010 05:11:21 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.3/8.14.3) with ESMTP id o695BK07047349 for ; Thu, 8 Jul 2010 23:11:20 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.3/8.14.3/Submit) with ESMTP id o695BKNc047346 for ; Thu, 8 Jul 2010 23:11:20 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Thu, 8 Jul 2010 23:11:20 -0600 (MDT) From: Warren Block To: stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.5 (wonkity.com [127.0.0.1]); Thu, 08 Jul 2010 23:11:21 -0600 (MDT) Cc: Subject: bsdtar weirdness 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, 09 Jul 2010 05:11:22 -0000 bsdtar is acting differently on a 7.2-stable and 8-stable system. Test file FreeBSD-8.1-RC2-i386-livefs.iso from ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/8.1/ Downloaded onto 8-stable, copied to 7.2-stable machine. 7.2-stable: # md5 /tmp/FreeBSD-8.1-RC2-i386-livefs.iso MD5 (/tmp/FreeBSD-8.1-RC2-i386-livefs.iso) = 9ec3b7901f377c643b8060b71c75ef25 # mkdir /tmp/freebsd # bsdtar xpf /tmp/FreeBSD-8.1-RC2-i386-livefs.iso -C /tmp/freebsd/ # du -hd0 /tmp/freebsd 237M /tmp/freebsd A little weird on 8-stable: # md5 /tmp/FreeBSD-8.1-RC2-i386-livefs.iso MD5 (/tmp/FreeBSD-8.1-RC2-i386-livefs.iso) = 9ec3b7901f377c643b8060b71c75ef25 # mkdir /tmp/freebsd # bsdtar xpf /tmp/FreeBSD-8.1-RC2-i386-livefs.iso -C /tmp/freebsd/ bsdtar: Ignoring out-of-order file @340a9980 (usr/include/c++/4.2/ext/pb_ds/detail/basic_tree_policy) 4876288 < 5138432 bsdtar: Ignoring out-of-order file @340a9a80 (usr/include/c++/4.2/ext/pb_ds/detail/bin_search_tree_) 4878336 < 5138432 bsdtar: Ignoring out-of-order file @340a9b00 (usr/include/c++/4.2/ext/pb_ds/detail/binary_heap_) 4880384 < 5138432 bsdtar: Ignoring out-of-order file @340a9b80 (usr/include/c++/4.2/ext/pb_ds/detail/binomial_heap_) 4882432 < 5138432 bsdtar: Ignoring out-of-order file @340a9c00 (usr/include/c++/4.2/ext/pb_ds/detail/binomial_heap_base_) 4884480 < 5138432 bsdtar: Ignoring out-of-order file @340a9c80 (usr/include/c++/4.2/ext/pb_ds/detail/cc_hash_table_map_) 4886528 < 5138432 bsdtar: Ignoring out-of-order file @340a9e80 (usr/include/c++/4.2/ext/pb_ds/detail/eq_fn) 4890624 < 5138432 bsdtar: Ignoring out-of-order file @340a9f00 (usr/include/c++/4.2/ext/pb_ds/detail/gp_hash_table_map_) 4892672 < 5138432 bsdtar: Ignoring out-of-order file @340a9f80 (usr/include/c++/4.2/ext/pb_ds/detail/hash_fn) 4896768 < 5138432 bsdtar: Ignoring out-of-order file @340aa000 (usr/include/c++/4.2/ext/pb_ds/detail/left_child_next_sibling_heap_) 4898816 < 5138432 bsdtar: Ignoring out-of-order file @340aa080 (usr/include/c++/4.2/ext/pb_ds/detail/list_update_map_) 4900864 < 5138432 bsdtar: Ignoring out-of-order file @340aa100 (usr/include/c++/4.2/ext/pb_ds/detail/list_update_policy) 4902912 < 5138432 bsdtar: Ignoring out-of-order file @340aa200 (usr/include/c++/4.2/ext/pb_ds/detail/ov_tree_map_) 4904960 < 5138432 bsdtar: Ignoring out-of-order file @340aa280 (usr/include/c++/4.2/ext/pb_ds/detail/pairing_heap_) 4907008 < 5138432 bsdtar: Ignoring out-of-order file @340aa300 (usr/include/c++/4.2/ext/pb_ds/detail/pat_trie_) 4909056 < 5138432 bsdtar: Ignoring out-of-order file @340aa400 (usr/include/c++/4.2/ext/pb_ds/detail/rb_tree_map_) 4911104 < 5138432 bsdtar: Ignoring out-of-order file @340aa480 (usr/include/c++/4.2/ext/pb_ds/detail/rc_binomial_heap_) 4913152 < 5138432 bsdtar: Ignoring out-of-order file @340aa500 (usr/include/c++/4.2/ext/pb_ds/detail/resize_policy) 4915200 < 5138432 bsdtar: Ignoring out-of-order file @340aa580 (usr/include/c++/4.2/ext/pb_ds/detail/splay_tree_) 4917248 < 5138432 bsdtar: Ignoring out-of-order file @340aa680 (usr/include/c++/4.2/ext/pb_ds/detail/thin_heap_) 4919296 < 5138432 bsdtar: Ignoring out-of-order file @340aa700 (usr/include/c++/4.2/ext/pb_ds/detail/tree_policy) 4921344 < 5138432 bsdtar: Ignoring out-of-order file @340aa800 (usr/include/c++/4.2/ext/pb_ds/detail/trie_policy) 4923392 < 5138432 bsdtar: Ignoring out-of-order file @340aa980 (usr/include/c++/4.2/ext/pb_ds/detail/unordered_iterator) 4925440 < 5138432 bsdtar: Error exit delayed from previous errors. # du -hd0 /tmp/freebsd 246M /tmp/freebsd The 8-stable system has "CPUTYPE?=core2" in /etc/make.conf and uses ccache for system builds. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 9 06:27:24 2010 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 4E27A106567C for ; Fri, 9 Jul 2010 06:27:24 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id F3A4F8FC15 for ; Fri, 9 Jul 2010 06:27:23 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1OX73R-000HfX-Vs; Fri, 09 Jul 2010 09:27:22 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Jeremy Chadwick In-reply-to: <20100708164022.GA46433@icarus.home.lan> References: <4C34C5DE.7040007@aldan.algebra.com> <4C34CA31.7010804@aldan.algebra.com> <4C34E39A.7090905@aldan.algebra.com> <20100708135353.GA43460@icarus.home.lan> <4C35E9D4.8080007@aldan.algebra.com> <20100708164022.GA46433@icarus.home.lan> Comments: In-reply-to Jeremy Chadwick message dated "Thu, 08 Jul 2010 09:40:22 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 09 Jul 2010 09:27:21 +0300 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: net-booting the install disks (Re: 8.x grudges) 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, 09 Jul 2010 06:27:24 -0000 > On Thu, Jul 08, 2010 at 11:08:04AM -0400, Mikhail T. wrote: > > 08.07.2010 09:53, Jeremy Chadwick =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0= =B0=D0=3D=B2(=D0=BB=D0=B0): > > >Then don't modify loader.conf. Instead, once the =22Welcome to Free= BSD=21=3D=22 > > >portion of loader appears, press =226=22 to shell to the loader prom= pt > > >and type: > > > > > >set vfs.root.mountfrom=3D=22ufs:/dev/md0=22 > > >boot > > Yes, that works... It just should not be necessary. >=20 > Okay, so let me get this straight. First the complaint was that you ha= d > to modify loader.conf, which involved extracting the CD image, editing > the file, yadda yadda. Now that you've been shown you don't have to > edit loader.conf, the complaint is =22it shouldn't be necessary=22. :-= ) >=20 > There's actually quite a bit about FreeBSD that =22shouldn't be> necess= ary=22 (from an administrator's point of view), but that's a > completely separate issue when compared to your =22when I do thing X in= > the kernel config, it breaks=22. Which of those two approaches do you > want to focus on? > > > Red Hat's =22kickstart=22 does not require one to extract CD-images= to > > fiddle with a couple of lines, and FreeBSD comes tantalizingly close > > to offer the same functionality. Just not quite :-( > > I've PXE booted Ubuntu and Debian. It was easy to accomplish (read: > easier than FreeBSD) because they offer pxelinux vs. FreeBSD's pxeboot.= > > pxelinux=5B1=5D offers the ability to read a configuration file via T= FTP, > which configures pxelinux itself. The configuration capabilities are > very impressive=5B2=5D. FreeBSD folks interested in PXE should really = take > a look at this thing. I believe the configuration file is read and > applied immediately, so things like serial port speed changes happen > before pxelinux outputs anything (e.g. no need to rebuild pxelinux just= > to get a faster rate). >=20 > That said, given that FreeBSD's pxeboot requires a bunch of extra work > (rebuilding for faster serial speed, and a bunch of other stuff -- it's= > in my doc), I'm a surprised you're not complaining about that. :-) >=20 > The bottom line: the PXE booting framework in FreeBSD could be improved= . It has been improved, though not the documentation :-( you can configure most of the stuff via DHCP, take a look at src/lib/libstand/bootp.c example lines from dhcpd.conf: option FBSD.ind0 =22hint.uart.0.flags=3D0x10=22 option FBSD.ind1 =22kern.ipc.semmni=3D256=22 option FBSD.ind2 =22kern.ipc.semmns=3D2048=22 and with this code in rc.initdiskless: confpath=3D=60kenv conf-path=60 if =5B -n =22=24confpath=22 =5D ; then if =5B =22=60expr =24confpath : '=5C(.*=5C):'=60=22 =5D ; then echo Mounting =24confpath on /conf mount_nfs =24confpath /conf chkerr =24? =22mount_nfs =24confpath /conf=22 to_umount=3D=22=24=7Bto_umount=7D =24confpath=22 fi fi eval =60kenv =7C sed -n 's/=5Erc=5C.//p'=60 rm -f /etc/rc.conf /etc/rc.conf.local for fc in =24conf0 =24conf1 =24conf2 =24conf3 =24conf4 =24conf5 =24conf6 = =24conf7 =24conf8=20 =24conf9 rc.conf.=24hostname do ho=3D=60expr =24fc : '=5C(.*=5C):'=60 fl=3D=60expr =24fc : '.*/=5C(.*=5C)'=60 if =5B =22=24=7Bho=7D=22 =21=3D =22=22 =5D; then mp=3D=60expr =24fc : '=5C(.*=5C)/.*'=60 mount_nfs =24mp /mnt > /dev/null 2>&1 if =5B -f /mnt/=24fl =5D; then echo =22=23 from =24fc /mnt/=24fl=22 >> /etc/rc.conf cat /mnt/=24fl >> /etc/rc.conf fi umount /mnt > /dev/null 2>&1 elif =5B -e /conf/=24fc =5D ; then echo =22=23 from /conf/=24fc=22 >> /etc/rc.conf cat /conf/=24fc >> /etc/rc.conf fi done and these lines in dhcpd.conf option FBSD.conf-path=3D=22fr-01:/vol/system/share/conf=22 option FBSD.rc-conf3 =22rc.ws8=22 ... will generate a 'personalized' rc.conf danny PS: this is not the first time I have posted this. =5B...=5D From owner-freebsd-stable@FreeBSD.ORG Fri Jul 9 09:49:20 2010 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 2A298106566B for ; Fri, 9 Jul 2010 09:49:20 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id AD0B38FC20 for ; Fri, 9 Jul 2010 09:49:19 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c211-30-160-13.belrs4.nsw.optusnet.com.au [211.30.160.13]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o699nAcx011262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jul 2010 19:49:11 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.4/8.14.4) with ESMTP id o699n8t9046207; Fri, 9 Jul 2010 19:49:08 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.4/8.14.4/Submit) id o699n8q5046206; Fri, 9 Jul 2010 19:49:08 +1000 (EST) (envelope-from peter) Date: Fri, 9 Jul 2010 19:49:08 +1000 From: Peter Jeremy To: "Mikhail T." Message-ID: <20100709094907.GA45560@server.vk2pj.dyndns.org> References: <4C34C5DE.7040007@aldan.algebra.com> <20100708210611.GA34250@server.vk2pj.dyndns.org> <4C364CE8.6050104@aldan.algebra.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <4C364CE8.6050104@aldan.algebra.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: 8.x grudges 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, 09 Jul 2010 09:49:20 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Jul-08 18:10:48 -0400, "Mikhail T." wro= te: >08.07.2010 17:06, Peter Jeremy =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2(= =D0=BB=D0=B0): >> On 2010-Jul-07 14:22:22 -0400, "Mikhail T." = wrote>>> 1. A picture, that one of the systems was displaying at boot (a= nd >>> then used as a screen-saver), stopped showing properly. The >>> colors are right, but the picture is distorted beyond recognition. =2E... >I don't want to post it publicly for copyright reasons. I can e-mail it=20 >to you (or anyone else) directly, though. I doubt I'm personally in a position to debug this and don't personally use splash screens. Can you reproduce it using an image that you can re-distribute? >>> 3. Likewise, having "device ugen" breaks config(8) -- another >>> undocumented incompatibility. >It was a valid device for FreeBSD-7. The UPDATING-file enumerates a=20 >number of things, that need to be changed, when updating to 8, but the=20 >removal of "ugen" is not mentioned there. Well, the definitive list is sys/conf/NOTES and sys/$(uname -m)/conf/NOTES but I agree that the ugen(4) man page is incorrect and a case could be made for having better details of USB2 in UPDATING. How would you like to write up patches and submit a PR? >>> 5. One of the upgraded systems would repeatedly hang at boot, until I >>> disabled the on-board firewire-device through the BIOS... It was >No BIOS updates :-( I can e-mail boot's output to you directly (please,=20 >confirm interest). It would be with the device disabled though, because=20 >the boot never completes, if it is enabled. That's why I asked for the output up to the hang - which might show where the problem is. If you don't have a serial console, take a photo and put it up on the web. >>> 6. Despite the reported improvements in the USB area, my USB keyboard >>> /still/ does not work during boot. It during POST and then after >> I have had similar problems on one of my USB-only desktops. In my >> case, moving the keyboard to a different USB port solved the problem. >> All I can suggest is to work your way through all the USB ports you >> have available and see if they all behavee the same. >> =20 >I'll try that next time I reboot this system. Thanks, I'm not sure if you can actually move the keyboard and have it re-probe until the system is fully up. You might have to reset after you move the keyboard. BTW, in all writing you've done, you've never mentioned what FreeBSD version you are running beyond a vague "8.1 prerelease", what motherboard you have (despite my request for this) and only indirectly given the architecture (via the config file you posted). --=20 Peter Jeremy --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkw28JMACgkQ/opHv/APuIee9gCaA78LfhWOFMwbw5NVL0Aq9+b6 bqYAoIM3gknijGPivtG3x1IglzcHqV4p =ljEv -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 9 12:19:24 2010 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 323F9106564A for ; Fri, 9 Jul 2010 12:19:24 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D4CBA8FC0C for ; Fri, 9 Jul 2010 12:19:23 +0000 (UTC) Received: by vws6 with SMTP id 6so3053097vws.13 for ; Fri, 09 Jul 2010 05:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=vrGnbbc8tc5+RcVsb44fGtgB7hAAWfRlpUHs/klTa3A=; b=dvaPWvxQAnpIcV9E/9RNOP8uR3T6kzczB11cvUHTTl0//Bu4/Itkiqw7pbv6JuHvsN y57xzNnL11Bm5Zkq8vwbc0ZZ+zV81Y9NtpfB3YTq6eY4YsDcvENi+x+/TXD+y4Zyjmn7 N8y3cg1bfixeqBRhSlZmEHHWj/Llrd2wZT2CM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=gMTeMvNx45zcWnymgVBST9IK+a/0vrVeWgo1j2nGTHy5G3+TLMj38YsxXdb1yJt7pi xcO678K3QEcZtT6TNkLKTAz6LqMM9B+AC8yCYU2F+IQ99GFA06RGrJm+yP3uJ804mXsv qIb/QfdAK0+iWnPSFKI7yDltxWmRd6oO1wNEo= Received: by 10.220.121.144 with SMTP id h16mr5156937vcr.19.1278677951074; Fri, 09 Jul 2010 05:19:11 -0700 (PDT) Received: from schism.local (173-161-130-225-Philadelphia.hfc.comcastbusiness.net [173.161.130.225]) by mx.google.com with ESMTPS id b5sm934784vcy.33.2010.07.09.05.19.08 (version=SSLv3 cipher=RC4-MD5); Fri, 09 Jul 2010 05:19:09 -0700 (PDT) Message-ID: <4C3713BC.2050603@gmail.com> Date: Fri, 09 Jul 2010 08:19:08 -0400 From: Glen Barber User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: David Adam References: <4C366257.8040201@gmail.com> <4C368983.4040100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org Subject: Re: sshd logging with key-only authentication 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, 09 Jul 2010 12:19:24 -0000 On 7/8/10 11:13 PM, David Adam wrote: > On Thu, 8 Jul 2010, Glen Barber wrote: > >> On 7/8/10 10:24 PM, David Adam wrote: >>> On Thu, 8 Jul 2010, Glen Barber wrote: >>>> What caught my interest is if I attempt to log in from a machine >>>> where I do not have my key or an incorrect key, I see nothing logged >>>> in auth.log about a failed login attempt. If I attempt with an >>>> invalid username, as expected, I see 'Invalid user ${USER} from >>>> ${IP}.' >>>> >>>> I'm more concerned with ssh login failures with valid user names. >>>> Looking at crypto/openssh/auth.c, allowed_user() returns true if the >>>> user is not in DenyUsers or DenyGroups, exists in AllowUsers or >>>> AllowGroups (if it is not empty), and has an executable shell. I'm >>>> no C hacker, but superficially it looks like it can never meet a >>>> condition where the user is valid but the key is invalid to trigger >>>> a log entry. >>>> >>>> Is this a bug in openssh, or have I overlooked something in my >>>> configuration? >>> >>> With LogLevel VERBOSE, you should get entries like >>> sshd[88595]: Failed publickey for root from 130.95.13.18 port 41256 ssh2 >>> >>> Is that what you're after? >> >> Sort of, but do I really need to set verbose logging to find that valid users >> are used in SSH attacks? root is an obvious target, which in my scenario is >> not allowed. I'm concerned about more specific, allowed users. > > It's just an example I pulled out of the logs. You won't get that message > for users listed in DenyUsers, although you will get spaff if the denied > user attempts password authentication. > Right. Though, password authentication is not allowed, which brings me back to my original point. > To me, verbose SSH logging doesn't seem like too big a burden, It does to me, especially if, by default, sshd does not log failed logins from valid users. I believe *that* should be default. > particularly if coupled with tools like sshit/sshdeny or logwatch. I > encourage you to experiment; you could even try patching sshd to emit the > relevant log lines at a lower debug level if you want. > I am fully aware of these utilities. They don't address the real problem, however. Logwatch, in this scenario, is useless unless verbose logging is enabled for sshd, which I believe should not be necessary. Regards, -- Glen Barber From owner-freebsd-stable@FreeBSD.ORG Fri Jul 9 15:41:11 2010 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 5A7C71065673 for ; Fri, 9 Jul 2010 15:41:11 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id 91D978FC12 for ; Fri, 9 Jul 2010 15:41:10 +0000 (UTC) Received: from 77-58-137-22.dclient.hispeed.ch ([77.58.137.22]:39046 helo=[172.16.1.3]) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OXFSl-0000Mp-RO for freebsd-stable@freebsd.org; Fri, 09 Jul 2010 17:26:04 +0200 From: Markus Gebert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Jul 2010 17:26:00 +0200 Message-Id: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> To: freebsd-stable Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? 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, 09 Jul 2010 15:41:11 -0000 Hi Summary: With FreeBSD 8.1-RC2 we get an MCE (fatal trap 28) on a Sun X4100M2 when = putting load on mpt and em. Initially thinking of a hardware problem, = and after many tests, we're able to avoid the panic by not compiling the = usb stack into the kernel. We cannot reproduce the problem on 6.x, 7.x = or, as it seems right now, even CURRENT. long story: We're in the process of testing FreeBSD 8.1-RC2 for future deployment on = our servers. When testing on a Sun X4100M2 we have encountered strange = behavior: Under medium load, the test machine would reboot itself = (hardware-triggered) without panic and spit out errors like = "hypertransport sync flood error on last boot" during POST (or complain = about fatal PCI errors). Thinking our test machine could have bad = hardware, we replaced RAM, which didn't help. We've also put the same = load on a second X4100M2, getting the same results. Both test machines = had been in production before, happily running 6.4. We have at least 35 = X4100M2 running on 6.4 in production, and another 15 running on 7.2, all = of them not showing this problem at all. So we started thinking this = problem could be software-related or at least triggered by software. After altering a BIOS setting to not reboot in case of a hypertransport = flood, we finally managed to get an MCE reported by MCA and a fatal trap = 28: -- MCA: Bank 4, Status 0xb400004000030c2b MCA: Global Cap 0x0000000000000105, Status 0x0000000000000007 MCA: Vendor "AuthenticAMD", ID 0x40f13, APIC ID 2 MCA: CPU 2 UNCOR BUSLG Observer WR I/O MCA: Address 0xfd00000000 Fatal trap 28: machine check trap while in kernel mode cpuid =3D 2; apic id =3D 02 instruction pointer =3D 0x20:0xffffffff80876506 stack pointer =3D 0x28:0xffffff800004ab50 frame pointer =3D 0x28:0xffffff800004ab60 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, IOPL =3D 0 current process =3D 11 (idle: cpu2) trap number =3D 28 panic: machine check trap cpuid =3D 2 Uptime: 3m9s -- Still, this may suggest a hardware problem. A 8.1 kernel with debug = options didn't bring any more information. When WITNESS kicked in, it = seemed random and to be symptom rather than cause. The same goes for DDB = backtraces, random and most probably worthless. I guess that's expected = with this kind of panic. So we fell back on trial&error and ruling out = stuff that is new in FreeBSD 8. What we've learned so far: - we cannot reproduce with 6.x, 7.x - upgrading system firmware and lsi logic raidcontroller firmware did = not help - disabling superpages does not help - disabling MCA does not help - although zfs scrub is part of a good way to reproduce the panic, we = can also reproduce it with UFS, so zfs seems to be off the hook - best way to reproduce: put load on em (wget a large file) AND mpt (cp = a large file, or run zpool scrub), panic within less than a minute - only putting load on em OR mpt does not reliably reproduce the panic - putting load on nfe and mpt does not reliably reproduce the panic - buildkernel with -j8 always runs through just fine - em and mpt sit on the same pci bus - so far, we couldn't reproduce the panic on CURRENT At this point we thought of a bug in either em, mpt or pci code, but = weren't able to find anything in the svn commit logs that could explain = what we were seeing. It's hard though to find something so unspecific... Out of despair, we tried to rule out the new usb stack. We kicked = everything usb-related out of our kernel config, and with this usb-less = kernel, the MCEs disappered! So, although the way to reproduce is to put = load on load em and mpt, the real trigger seems to be usb, which gets no = load at all. The only devices there are the iLOM virtual mouse and = keyboard and we did not use the graphical remote console during our = tests (iLOM serial console only). We tried to break this down further = and learned: - not 100% sure, but loading the necessary usb modules (ohci, ehci, = ukbd, ums) after boot (manually with kldload) seems fine, no panic so = far when trying to reproduce like this - a kernel with only ohci, ukbd and ums compiled-in is fine - a kernel with only ehci compiled-in makes us able to reproduce the = panic - so ehci being there on kernel boot seems to have some kind of = relevance - we see no changes to the ehci code from 8.1 to CURRENT that could make = the problem go away, so the cause could be elsewhere (pci code?) and = ehci is just a trigger At this point we're stuck and need help from someone with more insight. = The test system will be available for a while, so if you need us to run = more tests, we're happy to do that. We maybe could also provide remote = access to such a system if necessary. Although we have workaround now, = that works for us, it would still be great to see this fixed. I guess = we're not the only ones out there using X4100M2s with FreeBSD. About the test setup: - Sun X4100M2 - tested with 4 and 16 GB RAM - two PCIe nfe interfaces - two PCI-X em interfaces - one PCI-X mpt controller, non-raid mode, two disks (da), = gpt-partioned, zfs mirror, boot from zfs - one OHCI controller with iLOM virtual keyboard and virtual mouse = attached - one EHCI controller with nothing attached More information about the system below. Any help appreciated. Markus # uname -a FreeBSD XX.hostpoint.ch 8.1-RC2 FreeBSD 8.1-RC2 #4: Fri Jul 9 16:53:56 = CEST 2010 root@XX.hostpoint.ch:/usr/obj/usr/src/sys/YY amd64 # cpuinfo Machine class: amd64 CPU Model: Dual-Core AMD Opteron(tm) Processor 2220 Number of CPUs: 4 # usbconfig ugen0.1: at usbus0, cfg=3D0 md=3DHOST spd=3DFULL = (12Mbps) pwr=3DON ugen1.1: at usbus1, cfg=3D0 md=3DHOST spd=3DHIGH = (480Mbps) pwr=3DON ugen0.2: at = usbus0, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON # pciconf -lv none0@pci0:0:0:0: class=3D0x058000 card=3D0x00000000 = chip=3D0x005e10de rev=3D0xa3 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 Memory Controller' class =3D memory isab0@pci0:0:1:0: class=3D0x060100 card=3D0xcb8410de = chip=3D0x005110de rev=3D0xf3 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 ISA Bridge' class =3D bridge subclass =3D PCI-ISA none1@pci0:0:1:1: class=3D0x0c0500 card=3D0xcb8410de = chip=3D0x005210de rev=3D0xa2 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 SMBus' class =3D serial bus subclass =3D SMBus ohci0@pci0:0:2:0: class=3D0x0c0310 card=3D0xcb84108e = chip=3D0x005a10de rev=3D0xa2 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 USB Controller' class =3D serial bus subclass =3D USB ehci0@pci0:0:2:1: class=3D0x0c0320 card=3D0xcb84108e = chip=3D0x005b10de rev=3D0xa3 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 USB 2.0 Controller' class =3D serial bus subclass =3D USB atapci0@pci0:0:6:0: class=3D0x01018a card=3D0xcb8410de = chip=3D0x005310de rev=3D0xf2 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 Parallel ATA Controller' class =3D mass storage subclass =3D ATA pcib1@pci0:0:9:0: class=3D0x060401 card=3D0x00000000 = chip=3D0x005c10de rev=3D0xf2 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCI Bridge' class =3D bridge subclass =3D PCI-PCI nfe0@pci0:0:10:0: class=3D0x068000 card=3D0xcb8410de = chip=3D0x005710de rev=3D0xf3 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'NVIDIA Network Bus Enumerator (CK804)' class =3D bridge pcib2@pci0:0:11:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x005d10de rev=3D0xf3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCIe Bridge' class =3D bridge subclass =3D PCI-PCI pcib3@pci0:0:12:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x005d10de rev=3D0xf3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCIe Bridge' class =3D bridge subclass =3D PCI-PCI pcib4@pci0:0:13:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x005d10de rev=3D0xf3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCIe Bridge' class =3D bridge subclass =3D PCI-PCI pcib5@pci0:0:14:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x005d10de rev=3D0xa3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCIe Bridge' class =3D bridge subclass =3D PCI-PCI hostb0@pci0:0:24:0: class=3D0x060000 card=3D0x00000000 = chip=3D0x11001022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) HyperTransport = Technology Configuration' class =3D bridge subclass =3D HOST-PCI hostb1@pci0:0:24:1: class=3D0x060000 card=3D0x00000000 = chip=3D0x11011022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) Address Map' class =3D bridge subclass =3D HOST-PCI hostb2@pci0:0:24:2: class=3D0x060000 card=3D0x00000000 = chip=3D0x11021022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) DRAM = Controller' class =3D bridge subclass =3D HOST-PCI hostb3@pci0:0:24:3: class=3D0x060000 card=3D0x00000000 = chip=3D0x11031022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) Miscellaneous = Control' class =3D bridge subclass =3D HOST-PCI hostb4@pci0:0:25:0: class=3D0x060000 card=3D0x00000000 = chip=3D0x11001022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) HyperTransport = Technology Configuration' class =3D bridge subclass =3D HOST-PCI hostb5@pci0:0:25:1: class=3D0x060000 card=3D0x00000000 = chip=3D0x11011022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) Address Map' class =3D bridge subclass =3D HOST-PCI hostb6@pci0:0:25:2: class=3D0x060000 card=3D0x00000000 = chip=3D0x11021022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) DRAM = Controller' class =3D bridge subclass =3D HOST-PCI hostb7@pci0:0:25:3: class=3D0x060000 card=3D0x00000000 = chip=3D0x11031022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) Miscellaneous = Control' class =3D bridge subclass =3D HOST-PCI vgapci0@pci0:1:3:0: class=3D0x030000 card=3D0x80081002 = chip=3D0x47521002 rev=3D0x27 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, = Inc.' device =3D 'ATI On-Board VGA for HP Proliant 350 G3 (Rage XL = PCI)' class =3D display subclass =3D VGA none2@pci0:128:0:0: class=3D0x058000 card=3D0x00000000 = chip=3D0x005e10de rev=3D0xa3 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 Memory Controller' class =3D memory none3@pci0:128:1:0: class=3D0x058000 card=3D0xcb8410de = chip=3D0x00d310de rev=3D0xf3 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 Memory Controller' class =3D memory nfe1@pci0:128:10:0: class=3D0x068000 card=3D0xcb8410de = chip=3D0x005710de rev=3D0xf3 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'NVIDIA Network Bus Enumerator (CK804)' class =3D bridge pcib7@pci0:128:11:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x005d10de rev=3D0xf3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCIe Bridge' class =3D bridge subclass =3D PCI-PCI pcib8@pci0:128:12:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x005d10de rev=3D0xf3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCIe Bridge' class =3D bridge subclass =3D PCI-PCI pcib9@pci0:128:13:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x005d10de rev=3D0xf3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCIe Bridge' class =3D bridge subclass =3D PCI-PCI pcib10@pci0:128:14:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x005d10de rev=3D0xa3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCIe Bridge' class =3D bridge subclass =3D PCI-PCI pcib11@pci0:128:16:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x74581022 rev=3D0x12 hdr=3D0x01 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'PCI-X Bridge (AMD-8132)' class =3D bridge subclass =3D PCI-PCI ioapic0@pci0:128:16:1: class=3D0x080010 card=3D0x74591022 = chip=3D0x74591022 rev=3D0x12 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'PCI-X IOAPIC (AMD-8132)' class =3D base peripheral subclass =3D interrupt controller pcib12@pci0:128:17:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x74581022 rev=3D0x12 hdr=3D0x01 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'PCI-X Bridge (AMD-8132)' class =3D bridge subclass =3D PCI-PCI ioapic1@pci0:128:17:1: class=3D0x080010 card=3D0x74591022 = chip=3D0x74591022 rev=3D0x12 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'PCI-X IOAPIC (AMD-8132)' class =3D base peripheral subclass =3D interrupt controller em0@pci0:134:1:0: class=3D0x020000 card=3D0x10118086 = chip=3D0x10108086 rev=3D0x03 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Dual Port Gigabit Ethernet Controller (Copper) = (82546EB)' class =3D network subclass =3D ethernet em1@pci0:134:1:1: class=3D0x020000 card=3D0x10118086 = chip=3D0x10108086 rev=3D0x03 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Dual Port Gigabit Ethernet Controller (Copper) = (82546EB)' class =3D network subclass =3D ethernet mpt0@pci0:134:2:0: class=3D0x010000 card=3D0x30601000 = chip=3D0x00501000 rev=3D0x02 hdr=3D0x00 vendor =3D 'LSI Logic (Was: Symbios Logic, NCR)' device =3D 'SAS 3000 series, 4-port with 1064 -StorPort' class =3D mass storage subclass =3D SCSI # cat /usr/src/sys/amd64/conf/YY include GENERIC ident YY options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=3D5 options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options KDB # Enable kernel debugger = support. options DDB # Support DDB. options GDB # Support remote GDB. options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity = checking options INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS options WITNESS # Enable checks to detect = deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed (other version with no usb or no ehci could be provided if necessary) verbose boot: GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=3D01 base=3D0000000000000000 len=3D000000000009bc00 SMAP type=3D02 base=3D000000000009bc00 len=3D0000000000004400 SMAP type=3D02 base=3D00000000000e6000 len=3D000000000001a000 SMAP type=3D01 base=3D0000000000100000 len=3D00000000dbea0000 SMAP type=3D01 base=3D00000000dbfae000 len=3D0000000000002000 SMAP type=3D03 base=3D00000000dbfb0000 len=3D000000000000e000 SMAP type=3D04 base=3D00000000dbfbe000 len=3D0000000000032000 SMAP type=3D02 base=3D00000000dbff0000 len=3D0000000000010000 SMAP type=3D02 base=3D00000000e0000000 len=3D0000000010000000 SMAP type=3D02 base=3D00000000fec00000 len=3D0000000000001000 SMAP type=3D02 base=3D00000000fee00000 len=3D0000000000001000 SMAP type=3D02 base=3D00000000ff700000 len=3D0000000000900000 SMAP type=3D01 base=3D0000000100000000 len=3D0000000324000000 Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-RC2 #4: Fri Jul 9 16:53:56 CEST 2010 root@XX.hostpoint.ch:/usr/obj/usr/src/sys/YY amd64 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81204000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff81204250. Preloaded elf obj module "/boot/kernel/opensolaris.ko" at = 0xffffffff812048f8. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at = 0xffffffff81204f28. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2792595272 Hz CPU: Dual-Core AMD Opteron(tm) Processor 2220 (2792.60-MHz K8-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x40f13 Family =3D f Model =3D 41 = Stepping =3D 3 = Features=3D0x178bfbff Features2=3D0x2001 AMD = Features=3D0xea500800 AMD Features2=3D0x1f L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way = associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way = associative real memory =3D 17179869184 (16384 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000097fff, 618496 bytes (151 pages) 0x000000000123f000 - 0x00000000dbf9ffff, 3671461888 bytes (896353 pages) 0x00000000dbfae000 - 0x00000000dbfaffff, 8192 bytes (2 pages) 0x0000000100000000 - 0x0000000404dd5fff, 12966518784 bytes (3165654 = pages) avail memory =3D 16551731200 (15784 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 2 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 x86bios: IVT 0x000000-0x0004ff at 0xffffff0000000000 x86bios: SSEG 0x010000-0x01ffff at 0xffffff800004a000 x86bios: EBDA 0x09b000-0x09ffff at 0xffffff000009b000 x86bios: ROM 0x0a0000-0x0effff at 0xffffff00000a0000 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xfa040 00024 (v2 SUN ) ACPI: XSDT 0xdbfb0100 00094 (v1 SUN X4200 M2 00000104 MSFT 00000097) ACPI: FACP 0xdbfb0290 000F4 (v3 SUN X4200 M2 00000104 MSFT 00000097) ACPI: DSDT 0xdbfb0510 0702A (v1 SUN X4200 M2 00000104 INTL 20050624) ACPI: FACS 0xdbfbe000 00040 ACPI: APIC 0xdbfb0390 000B0 (v1 SUN X4200 M2 00000104 MSFT 00000097) ACPI: SPCR 0xdbfb0440 00050 (v1 SUN X4200 M2 00000104 MSFT 00000097) ACPI: SLIT 0xdbfb0490 00030 (v1 SUN X4200 M2 00000104 MSFT 00000097) ACPI: SPMI 0xdbfb04c0 00041 (v5 SUN OEMSPMI 00000104 MSFT 00000097) ACPI: OEMB 0xdbfbe040 00063 (v1 SUN X4200 M2 00000104 MSFT 00000097) ACPI: SRAT 0xdbfb7540 00110 (v1 AMD FAM_F_10 00000002 AMD 00000001) ACPI: HPET 0xdbfb7650 00038 (v1 SUN OEMHPET0 00000104 MSFT 00000097) ACPI: IPET 0xdbfb7690 00038 (v1 SUN OEMHPET1 00000104 MSFT 00000097) ACPI: EINJ 0xdbfb76d0 00130 (v1 AMIER AMI_EINJ 04000909 MSFT 00000097) ACPI: BERT 0xdbfb7860 00030 (v1 AMIER AMI_BERT 04000909 MSFT 00000097) ACPI: ERST 0xdbfb7890 001B0 (v1 AMIER AMI_ERST 04000909 MSFT 00000097) ACPI: HEST 0xdbfb7a40 000A8 (v1 AMIER AMI_HEST 04000909 MSFT 00000097) ACPI: SSDT 0xdbfb7af0 00574 (v1 A M I POWERNOW 00000001 AMD 00000001) MADT: Found IO APIC ID 15, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 16, Interrupt 48 at 0xfeafd000 ioapic1: Changing APIC ID to 16 ioapic1: WARNING: intbase 48 !=3D expected base 24 MADT: Found IO APIC ID 17, Interrupt 56 at 0xfeafc000 ioapic2: Changing APIC ID to 17 ioapic2: WARNING: intbase 56 !=3D expected base 55 MADT: Found IO APIC ID 14, Interrupt 24 at 0xfeaff000 ioapic3: WARNING: intbase 24 !=3D expected base 63 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic3 irqs 24-47 on motherboard ioapic0 irqs 0-23 on motherboard ioapic1 irqs 48-54 on motherboard ioapic2 irqs 56-62 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 wlan: <802.11 Link Layer> kbd: new array size 4 kbd1 at kbdmux0 mem: nfslock: pseudo-device null: random: io: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) acpi0: wakeup code va 0xffffff8000031000 pa 0x4000 AcpiOsDerivePciId: \_SB_.PCI0.MAP0.CFG_ -> bus 0 dev 24 func 1 unknown: I/O range not supported AcpiOsDerivePciId: \_SB_.PCI0.SBRG.BAR0 -> bus 0 dev 1 func 0 AcpiOsDerivePciId: \_SB_.PCIB.IO84.BAR1 -> bus 128 dev 1 func 0 AcpiOsDerivePciId: \_SB_.PCIC.IO42.BAR2 -> bus 255 dev 1 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, dbf00000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x2008-0x200b on acpi0 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 Validation 0 255 N 0 16 17 18 19 After Disable 0 255 N 0 16 17 18 19 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link8: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link9: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link10: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link11: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link12: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link13: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link14: Index IRQ Rtd Ref IRQs Initial Probe 0 14 N 0 20 21 22 Validation 0 255 N 0 20 21 22 After Disable 0 255 N 0 20 21 22 pci_link15: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 40 41 42 43 Validation 0 255 N 0 40 41 42 43 After Disable 0 255 N 0 40 41 42 43 pci_link16: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 40 41 42 43 Validation 0 255 N 0 40 41 42 43 After Disable 0 255 N 0 40 41 42 43 pci_link17: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 40 41 42 43 Validation 0 255 N 0 40 41 42 43 After Disable 0 255 N 0 40 41 42 43 pci_link18: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 40 41 42 43 Validation 0 255 N 0 40 41 42 43 After Disable 0 255 N 0 40 41 42 43 pci_link19: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 40 41 42 43 Validation 0 255 N 0 40 41 42 43 After Disable 0 255 N 0 40 41 42 43 pci_link20: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 40 41 42 43 Validation 0 255 N 0 40 41 42 43 After Disable 0 255 N 0 40 41 42 43 pci_link21: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 40 41 42 43 Validation 0 255 N 0 40 41 42 43 After Disable 0 255 N 0 40 41 42 43 pci_link22: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 40 41 42 43 Validation 0 255 N 0 40 41 42 43 After Disable 0 255 N 0 40 41 42 43 pci_link23: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 44 45 46 47 Validation 0 255 N 0 44 45 46 47 After Disable 0 255 N 0 44 45 46 47 pci_link24: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 44 45 46 47 Validation 0 255 N 0 44 45 46 47 After Disable 0 255 N 0 44 45 46 47 pci_link25: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 44 45 46 47 Validation 0 255 N 0 44 45 46 47 After Disable 0 255 N 0 44 45 46 47 pci_link26: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 44 45 46 47 Validation 0 255 N 0 44 45 46 47 After Disable 0 255 N 0 44 45 46 47 acpi_hpet0: iomem 0xfed00000-0xfed003ff on = acpi0 acpi_hpet0: vend: 0x10de rev: 0x1 num: 3 hz: 25000000 opts: legacy_route Timecounter "HPET" frequency 25000000 Hz quality 900 pcib0: on acpi0 pci0: on pcib0 pci0: domain=3D0, physical bus=3D0 found-> vendor=3D0x10de, dev=3D0x005e, revid=3D0xa3 domain=3D0, bus=3D0, slot=3D0, func=3D0 class=3D05-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x00b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x10de, dev=3D0x0051, revid=3D0xf3 domain=3D0, bus=3D0, slot=3D1, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x000f, statreg=3D0x00a0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x10de, dev=3D0x0052, revid=3D0xa2 domain=3D0, bus=3D0, slot=3D1, func=3D1 class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0001, statreg=3D0x00b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x03 (750 ns), maxlat=3D0x01 = (250 ns) intpin=3Da, irq=3D255 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x9200, size 5, enabled map[20]: type I/O Port, range 32, base 0x400, size 6, enabled map[24]: type I/O Port, range 32, base 0x440, size 6, enabled found-> vendor=3D0x10de, dev=3D0x005a, revid=3D0xa2 domain=3D0, bus=3D0, slot=3D2, func=3D0 class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x00b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x03 (750 ns), maxlat=3D0x01 = (250 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe3ff000, size 12, = enabled pcib0: matched entry for 0.2.INTA (src \_SB_.LUS0:0) pci_link5: Picked IRQ 20 with weight 0 pcib0: slot 2 INTA routed to irq 20 via \_SB_.LUS0 found-> vendor=3D0x10de, dev=3D0x005b, revid=3D0xa3 domain=3D0, bus=3D0, slot=3D2, func=3D1 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0006, statreg=3D0x00b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x03 (750 ns), maxlat=3D0x01 = (250 ns) intpin=3Db, irq=3D5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe3fec00, size 8, = enabled pcib0: matched entry for 0.2.INTB (src \_SB_.LUS2:0) pci_link7: Picked IRQ 21 with weight 0 pcib0: slot 2 INTB routed to irq 21 via \_SB_.LUS2 found-> vendor=3D0x10de, dev=3D0x0053, revid=3D0xf2 domain=3D0, bus=3D0, slot=3D6, func=3D0 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x00b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x03 (750 ns), maxlat=3D0x01 = (250 ns) powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0x9100, size 4, enabled found-> vendor=3D0x10de, dev=3D0x005c, revid=3D0xf2 domain=3D0, bus=3D0, slot=3D9, func=3D0 class=3D06-04-01, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x00a0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x0b (2750 ns), maxlat=3D0x02 = (500 ns) found-> vendor=3D0x10de, dev=3D0x0057, revid=3D0xf3 domain=3D0, bus=3D0, slot=3D10, func=3D0 class=3D06-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x00b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x01 (250 ns), maxlat=3D0x14 = (5000 ns) intpin=3Da, irq=3D15 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe3fd000, size 12, = enabled map[14]: type I/O Port, range 32, base 0xdc00, size 3, enabled pcib0: matched entry for 0.10.INTA (src \_SB_.LKLN:0) pci_link8: Picked IRQ 22 with weight 0 pcib0: slot 10 INTA routed to irq 22 via \_SB_.LKLN found-> vendor=3D0x10de, dev=3D0x005d, revid=3D0xf3 domain=3D0, bus=3D0, slot=3D11, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0046, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=3D0x10de, dev=3D0x005d, revid=3D0xf3 domain=3D0, bus=3D0, slot=3D12, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0046, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=3D0x10de, dev=3D0x005d, revid=3D0xf3 domain=3D0, bus=3D0, slot=3D13, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0046, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=3D0x10de, dev=3D0x005d, revid=3D0xa3 domain=3D0, bus=3D0, slot=3D14, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0046, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=3D0x1022, dev=3D0x1100, revid=3D0x00 domain=3D0, bus=3D0, slot=3D24, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x1022, dev=3D0x1101, revid=3D0x00 domain=3D0, bus=3D0, slot=3D24, func=3D1 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x1022, dev=3D0x1102, revid=3D0x00 domain=3D0, bus=3D0, slot=3D24, func=3D2 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x1022, dev=3D0x1103, revid=3D0x00 domain=3D0, bus=3D0, slot=3D24, func=3D3 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x1022, dev=3D0x1100, revid=3D0x00 domain=3D0, bus=3D0, slot=3D25, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x1022, dev=3D0x1101, revid=3D0x00 domain=3D0, bus=3D0, slot=3D25, func=3D1 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x1022, dev=3D0x1102, revid=3D0x00 domain=3D0, bus=3D0, slot=3D25, func=3D2 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x1022, dev=3D0x1103, revid=3D0x00 domain=3D0, bus=3D0, slot=3D25, func=3D3 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xfe3ff000-0xfe3fffff irq 20 = at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe3ff000 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 49 ohci0: [MPSAFE] ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xfe3fec00-0xfe3fecff irq = 21 at device 2.1 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe3fec00 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 50 ehci0: [MPSAFE] ehci0: [ITHREAD] ehci0: Doorbell workaround enabled usbus1: EHCI version 1.0 usbus1: on ehci0 atapci0: port = 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x9100-0x910f at device 6.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x9100 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata0: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata0: stat1=3D0x00 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata0: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x10000 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 51 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=3D00 ostat0=3Dff ostat1=3Dff ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 52 ata1: [MPSAFE] ata1: [ITHREAD] pcib1: at device 9.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xc000-0xcfff pcib1: memory decode 0xfc200000-0xfe2fffff pcib1: no prefetched decode pcib1: Subtractively decoded bridge. pci1: on pcib1 pci1: domain=3D0, physical bus=3D1 found-> vendor=3D0x1002, dev=3D0x4752, revid=3D0x27 domain=3D0, bus=3D1, slot=3D3, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0087, statreg=3D0x0290, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x00 = (0 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfd000000, size 24, = enabled pcib1: requested memory range 0xfd000000-0xfdffffff: good map[14]: type I/O Port, range 32, base 0xc800, size 8, enabled pcib1: requested I/O range 0xc800-0xc8ff: in range map[18]: type Memory, range 32, base 0xfe2ff000, size 12, = enabled pcib1: requested memory range 0xfe2ff000-0xfe2fffff: good pcib1: matched entry for 1.3.INTA (src \_SB_.LNKA:0) pci_link0: Picked IRQ 16 with weight 0 pcib1: slot 3 INTA routed to irq 16 via \_SB_.LNKA vgapci0: port 0xc800-0xc8ff mem = 0xfd000000-0xfdffffff,0xfe2ff000-0xfe2fffff irq 16 at device 3.0 on pci1 nfe0: port 0xdc00-0xdc07 = mem 0xfe3fd000-0xfe3fdfff irq 22 at device 10.0 on pci0 nfe0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe3fd000 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX, = 1000baseSX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: bpf attached nfe0: Ethernet address: 00:14:4f:8d:fe:ea ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 53 nfe0: [MPSAFE] nfe0: [FILTER] pcib2: at device 11.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x0-0x0 pcib2: no prefetched decode pcib2: could not get PCI interrupt routing table for \_SB_.PCI0.P0P2 - = AE_NOT_FOUND pci2: on pcib2 pci2: domain=3D0, physical bus=3D2 pcib3: at device 12.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x0-0x0 pcib3: no prefetched decode pcib3: could not get PCI interrupt routing table for \_SB_.PCI0.P0P3 - = AE_NOT_FOUND pci3: on pcib3 pci3: domain=3D0, physical bus=3D3 pcib4: at device 13.0 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x0-0x0 pcib4: no prefetched decode pci4: on pcib4 pci4: domain=3D0, physical bus=3D4 pcib5: at device 14.0 on pci0 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0x0-0x0 pcib5: no prefetched decode pci5: on pcib5 pci5: domain=3D0, physical bus=3D5 pcib6: on acpi0 pci128: on pcib6 pci128: domain=3D0, physical bus=3D128 found-> vendor=3D0x10de, dev=3D0x005e, revid=3D0xa3 domain=3D0, bus=3D128, slot=3D0, func=3D0 class=3D05-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x00b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x10de, dev=3D0x00d3, revid=3D0xf3 domain=3D0, bus=3D128, slot=3D1, func=3D0 class=3D05-80-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x000f, statreg=3D0x00a0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) map[14]: type Memory, range 32, base 0xfeaff000, size 12, = enabled found-> vendor=3D0x10de, dev=3D0x0057, revid=3D0xf3 domain=3D0, bus=3D128, slot=3D10, func=3D0 class=3D06-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x00b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x01 (250 ns), maxlat=3D0x14 = (5000 ns) intpin=3Da, irq=3D7 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfeafe000, size 12, = enabled map[14]: type I/O Port, range 32, base 0xfc00, size 3, enabled pcib6: matched entry for 128.10.INTA (src \_SB_.LK2N:0) pci_link23: Picked IRQ 44 with weight 0 pcib6: slot 10 INTA routed to irq 44 via \_SB_.LK2N found-> vendor=3D0x10de, dev=3D0x005d, revid=3D0xf3 domain=3D0, bus=3D128, slot=3D11, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0046, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=3D0x10de, dev=3D0x005d, revid=3D0xf3 domain=3D0, bus=3D128, slot=3D12, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0046, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=3D0x10de, dev=3D0x005d, revid=3D0xf3 domain=3D0, bus=3D128, slot=3D13, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0046, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=3D0x10de, dev=3D0x005d, revid=3D0xa3 domain=3D0, bus=3D128, slot=3D14, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0046, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=3D0x1022, dev=3D0x7458, revid=3D0x12 domain=3D0, bus=3D128, slot=3D16, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 cmdreg=3D0x0156, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) found-> vendor=3D0x1022, dev=3D0x7459, revid=3D0x12 domain=3D0, bus=3D128, slot=3D16, func=3D1 class=3D08-00-10, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) map[10]: type Memory, range 64, base 0xfeafd000, size 12, = enabled found-> vendor=3D0x1022, dev=3D0x7458, revid=3D0x12 domain=3D0, bus=3D128, slot=3D17, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 cmdreg=3D0x0157, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) found-> vendor=3D0x1022, dev=3D0x7459, revid=3D0x12 domain=3D0, bus=3D128, slot=3D17, func=3D1 class=3D08-00-10, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) map[10]: type Memory, range 64, base 0xfeafc000, size 12, = enabled pci128: at device 0.0 (no driver attached) pci128: at device 1.0 (no driver attached) nfe1: port 0xfc00-0xfc07 = mem 0xfeafe000-0xfeafefff irq 44 at device 10.0 on pci128 nfe1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfeafe000 miibus1: on nfe1 e1000phy1: PHY 1 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseSX, = 1000baseSX-FDX, 1000baseT, 1000baseT-FDX, auto nfe1: bpf attached nfe1: Ethernet address: 00:14:4f:8d:fe:eb ioapic3: routing intpin 20 (PCI IRQ 44) to lapic 0 vector 54 nfe1: [MPSAFE] nfe1: [FILTER] pcib7: at device 11.0 on pci128 pcib7: domain 0 pcib7: secondary bus 129 pcib7: subordinate bus 129 pcib7: I/O decode 0x0-0x0 pcib7: no prefetched decode pcib7: could not get PCI interrupt routing table for \_SB_.PCIB.BR5B - = AE_NOT_FOUND pci129: on pcib7 pci129: domain=3D0, physical bus=3D129 pcib8: at device 12.0 on pci128 pcib8: domain 0 pcib8: secondary bus 130 pcib8: subordinate bus 130 pcib8: I/O decode 0x0-0x0 pcib8: no prefetched decode pcib8: could not get PCI interrupt routing table for \_SB_.PCIB.BR5C - = AE_NOT_FOUND pci130: on pcib8 pci130: domain=3D0, physical bus=3D130 pcib9: at device 13.0 on pci128 pcib9: domain 0 pcib9: secondary bus 131 pcib9: subordinate bus 131 pcib9: I/O decode 0x0-0x0 pcib9: no prefetched decode pci131: on pcib9 pci131: domain=3D0, physical bus=3D131 pcib10: at device 14.0 on pci128 pcib10: domain 0 pcib10: secondary bus 132 pcib10: subordinate bus 132 pcib10: I/O decode 0x0-0x0 pcib10: no prefetched decode pci132: on pcib10 pci132: domain=3D0, physical bus=3D132 pcib11: at device 16.0 on pci128 pcib11: domain 0 pcib11: secondary bus 133 pcib11: subordinate bus 133 pcib11: I/O decode 0x0-0x0 pcib11: no prefetched decode pci133: on pcib11 pci133: domain=3D0, physical bus=3D133 pcib12: at device 17.0 on pci128 pcib12: domain 0 pcib12: secondary bus 134 pcib12: subordinate bus 134 pcib12: I/O decode 0xe000-0xefff pcib12: memory decode 0xfe500000-0xfe9fffff pcib12: no prefetched decode pci134: on pcib12 pci134: domain=3D0, physical bus=3D134 found-> vendor=3D0x8086, dev=3D0x1010, revid=3D0x03 domain=3D0, bus=3D134, slot=3D1, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0157, statreg=3D0x0230, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0xff (63750 ns), maxlat=3D0x00= (0 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfe9e0000, size 17, = enabled pcib12: requested memory range 0xfe9e0000-0xfe9fffff: good map[20]: type I/O Port, range 32, base 0xec00, size 6, enabled pcib12: requested I/O range 0xec00-0xec3f: in range pcib12: matched entry for 134.1.INTA pcib12: slot 1 INTA hardwired to IRQ 56 found-> vendor=3D0x8086, dev=3D0x1010, revid=3D0x03 domain=3D0, bus=3D134, slot=3D1, func=3D1 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0157, statreg=3D0x0230, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0xff (63750 ns), maxlat=3D0x00= (0 ns) intpin=3Db, irq=3D6 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfe9c0000, size 17, = enabled pcib12: requested memory range 0xfe9c0000-0xfe9dffff: good map[20]: type I/O Port, range 32, base 0xe800, size 6, enabled pcib12: requested I/O range 0xe800-0xe83f: in range pcib12: matched entry for 134.1.INTB pcib12: slot 1 INTB hardwired to IRQ 57 found-> vendor=3D0x1000, dev=3D0x0050, revid=3D0x02 domain=3D0, bus=3D134, slot=3D2, func=3D0 class=3D01-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0157, statreg=3D0x0230, cachelnsz=3D16 (dwords) lattimer=3D0x48 (2160 ns), mingnt=3D0x40 (16000 ns), maxlat=3D0x0a= (2500 ns) intpin=3Da, irq=3D7 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 1 message in map 0x14 map[10]: type I/O Port, range 32, base 0xe400, size 8, enabled pcib12: requested I/O range 0xe400-0xe4ff: in range map[14]: type Memory, range 64, base 0xfe9bc000, size 14, = enabled pcib12: requested memory range 0xfe9bc000-0xfe9bffff: good map[1c]: type Memory, range 64, base 0xfe9a0000, size 16, = enabled pcib12: requested memory range 0xfe9a0000-0xfe9affff: good pcib12: matched entry for 134.2.INTA pcib12: slot 2 INTA hardwired to IRQ 58 em0: port = 0xec00-0xec3f mem 0xfe9e0000-0xfe9fffff irq 56 at device 1.0 on pci134 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfe9e0000 em0: Reserved 0x40 bytes for rid 0x20 type 4 at 0xec00 ioapic2: routing intpin 0 (PCI IRQ 56) to lapic 0 vector 55 em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:14:4f:8d:fe:ec em1: port = 0xe800-0xe83f mem 0xfe9c0000-0xfe9dffff irq 57 at device 1.1 on pci134 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfe9c0000 em1: Reserved 0x40 bytes for rid 0x20 type 4 at 0xe800 ioapic2: routing intpin 1 (PCI IRQ 57) to lapic 0 vector 56 em1: [FILTER] em1: bpf attached em1: Ethernet address: 00:14:4f:8d:fe:ed mpt0: port 0xe400-0xe4ff mem = 0xfe9bc000-0xfe9bffff,0xfe9a0000-0xfe9affff irq 58 at device 2.0 on = pci134 mpt0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe400 mpt0: Reserved 0x4000 bytes for rid 0x14 type 3 at 0xfe9bc000 ioapic2: routing intpin 2 (PCI IRQ 58) to lapic 0 vector 57 mpt0: [MPSAFE] mpt0: [ITHREAD] mpt0: MPI Version=3D1.5.20.0 mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not = required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not = required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not = required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not = required). mpt0: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not = required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not = required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not = required). mpt0: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not = required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not = required). mpt0: No Handlers For Any Event Notify Frames. Event 0xf (ACK not = required). mpt0: No Handlers For Any Event Notify Frames. Event 0xf (ACK not = required). mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 0 Active Volumes (2 Max) mpt0: 0 Hidden Drive Members (14 Max) mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not = required). acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 58 uart0: [FILTER] uart0: fast interrupt uart0: console (9600,n,8,1) ex_isa_identify() ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed isa_probe_children: disabling PnP devices atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem = 0xc0000-0xc9fff,0xca000-0xcb7ff,0xcb800-0xcc7ff,0xcc800-0xcd7ff,0xd3800-0x= d47ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 59 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0065 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices powernow0: on cpu0 powernow1: on cpu1 powernow2: on cpu2 powernow3: on cpu3 Device configuration finished. Reducing kern.maxvnodes 1031944 -> 100000 procfs registered ZFS filesystem version 3 ZFS storage pool version 14 lapic: Divisor 2, Frequency 99735545 Hz Timecounter "TSC" frequency 2792595272 Hz quality -100 Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining ipfw2 (+ipv6) initialized, divert enabled, nat loadable, rule-based = forwarding disabled, default to accept, logging disabled ipfw0: bpf attached lo0: bpf attached hptrr: no controller detected. ata0: Identifying devices: 00010000 ata0: New devices: 00010000 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ata0-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA33 cable=3D40 wire acd0: setting UDMA33 ugen0.1: at usbus0 uhub0: on = usbus0 ugen1.1: at usbus1 uhub1: on = usbus1 acd0: CDRW drive at ata0 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 1654KB buffer, = UDMA33=20 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, test write acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable caddy, unlocked acd0: Medium: no/blank disc ata1: Identifying devices: 00000000 ata1: New devices: 00000000 uhub0: 7 ports with 7 removable, self powered uhub1: 7 ports with 7 removable, self powered (probe71:mpt0:1:8:0): Error 22, Unretryable error (probe72:mpt0:1:9:0): Error 22, Unretryable error (probe73:mpt0:1:10:0): Error 22, Unretryable error (probe74:mpt0:1:11:0): Error 22, Unretryable error (probe75:mpt0:1:12:0): Error 22, Unretryable error (probe76:mpt0:1:13:0): Error 22, Unretryable error (probe63:mpt0:1:0:0): Error 22, Unretryable error (probe64:mpt0:1:1:0): Error 22, Unretryable error (probe65:mpt0:1:2:0): Error 22, Unretryable error (probe66:mpt0:1:3:0): Error 22, Unretryable error (probe67:mpt0:1:4:0): Error 22, Unretryable error (probe68:mpt0:1:5:0): Error 22, Unretryable error (probe69:mpt0:1:6:0): Error 22, Unretryable error (probe70:mpt0:1:7:0): Error 22, Unretryable error pass0 at mpt0 bus 0 scbus0 target 2 lun 0 pass0: Fixed Direct Access SCSI-5 device=20= pass0: Serial Number 18216LAX 3NP16LAX pass0: 300.000MB/s transfers pass0: Command Queueing enabled da0 at mpt0 bus 0 scbus0 target 2 lun 0 da0: Fixed Direct Access SCSI-5 device=20 da0: Serial Number 18216LAX 3NP16LAX da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da1 at mpt0 bus 0 scbus0 target 3 lun 0 da1: Fixed Direct Access SCSI-5 device=20 da1: Serial Number 16216D68 3NP16D68 da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) GEOM: new disk da0 GEOM: new disk da1 pass1 at mpt0 bus 0 scbus0 target 3 lun 0 pass1: Fixed Direct Access SCSI-5 device=20= pass1: Serial Number 16216D68 3NP16D68 pass1: 300.000MB/s transfers pass1: Command Queueing enabled ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 (folaopwitca0b:l er oculteiannge ri nsttpairnt e4d=20 ISA IRQ 4) to lapic 1 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 2 vector 48 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 3 vector 48 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 1 vector 49 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 2 vector 49 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 3 vector 49 ioapic2: routing intpin 0 (PCI IRQ 56) to lapic 1 vector 50 ioapic2: routing intpin 1 (PCI IRQ 57) to lapic 2 vector 50 ioapic2: routing intpin 2 (PCI IRQ 58) to lapic 3 vector 50 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from zfs:zroot= From owner-freebsd-stable@FreeBSD.ORG Fri Jul 9 15:56:17 2010 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 E9783106564A for ; Fri, 9 Jul 2010 15:56:17 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id D1D9C8FC08 for ; Fri, 9 Jul 2010 15:56:17 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta15.emeryville.ca.mail.comcast.net with comcast id frHa1e0041zF43QAFrwHdD; Fri, 09 Jul 2010 15:56:17 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta24.emeryville.ca.mail.comcast.net with comcast id frwG1e00B3LrwQ28krwGrt; Fri, 09 Jul 2010 15:56:17 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2B0EF9B423; Fri, 9 Jul 2010 08:56:16 -0700 (PDT) Date: Fri, 9 Jul 2010 08:56:16 -0700 From: Jeremy Chadwick To: Markus Gebert Message-ID: <20100709155616.GA20986@icarus.home.lan> References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? 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, 09 Jul 2010 15:56:18 -0000 On Fri, Jul 09, 2010 at 05:26:00PM +0200, Markus Gebert wrote: > # pciconf -lv Can you re-run this with "-lvc" instead? Thanks. Also "vmstat -i" would be useful. That's all I can think of off the top of my head. -- | Jeremy Chadwick jdc@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 Fri Jul 9 16:04:54 2010 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 1FC06106564A for ; Fri, 9 Jul 2010 16:04:54 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id D08EA8FC08 for ; Fri, 9 Jul 2010 16:04:53 +0000 (UTC) Received: from 77-58-137-22.dclient.hispeed.ch ([77.58.137.22]:47109 helo=[172.16.1.3]) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OXG4K-0002Cv-BU; Fri, 09 Jul 2010 18:04:52 +0200 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Markus Gebert In-Reply-To: <20100709155616.GA20986@icarus.home.lan> Date: Fri, 9 Jul 2010 18:04:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5B47E0A5-A302-40EC-9B52-02620D361B0B@hostpoint.ch> References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <20100709155616.GA20986@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1078) Cc: freebsd-stable Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? 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, 09 Jul 2010 16:04:54 -0000 Am 09.07.2010 um 17:56 schrieb Jeremy Chadwick: > Can you re-run this with "-lvc" instead? Thanks. Also "vmstat -i" > would be useful. That's all I can think of off the top of my head. Sure. # pciconf -lvc none0@pci0:0:0:0: class=3D0x058000 card=3D0x00000000 = chip=3D0x005e10de rev=3D0xa3 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 Memory Controller' class =3D memory cap 08[44] =3D HT slave cap 08[e0] =3D HT MSI address window enabled at 0xfee00000 isab0@pci0:0:1:0: class=3D0x060100 card=3D0xcb8410de = chip=3D0x005110de rev=3D0xf3 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 ISA Bridge' class =3D bridge subclass =3D PCI-ISA none1@pci0:0:1:1: class=3D0x0c0500 card=3D0xcb8410de = chip=3D0x005210de rev=3D0xa2 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 SMBus' class =3D serial bus subclass =3D SMBus cap 01[44] =3D powerspec 2 supports D0 D3 current D0 ohci0@pci0:0:2:0: class=3D0x0c0310 card=3D0xcb84108e = chip=3D0x005a10de rev=3D0xa2 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 USB Controller' class =3D serial bus subclass =3D USB cap 01[44] =3D powerspec 2 supports D0 D1 D2 D3 current D0 ehci0@pci0:0:2:1: class=3D0x0c0320 card=3D0xcb84108e = chip=3D0x005b10de rev=3D0xa3 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 USB 2.0 Controller' class =3D serial bus subclass =3D USB cap 0a[44] =3D EHCI Debug Port at offset 0x98 in map 0x14 cap 01[80] =3D powerspec 2 supports D0 D1 D2 D3 current D0 atapci0@pci0:0:6:0: class=3D0x01018a card=3D0xcb8410de = chip=3D0x005310de rev=3D0xf2 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 Parallel ATA Controller' class =3D mass storage subclass =3D ATA cap 01[44] =3D powerspec 2 supports D0 D3 current D0 pcib1@pci0:0:9:0: class=3D0x060401 card=3D0x00000000 = chip=3D0x005c10de rev=3D0xf2 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCI Bridge' class =3D bridge subclass =3D PCI-PCI nfe0@pci0:0:10:0: class=3D0x068000 card=3D0xcb8410de = chip=3D0x005710de rev=3D0xf3 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'NVIDIA Network Bus Enumerator (CK804)' class =3D bridge cap 01[44] =3D powerspec 2 supports D0 D1 D2 D3 current D0 pcib2@pci0:0:11:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x005d10de rev=3D0xf3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCIe Bridge' class =3D bridge subclass =3D PCI-PCI cap 01[40] =3D powerspec 2 supports D0 D3 current D0 cap 05[48] =3D MSI supports 2 messages, 64 bit=20 cap 08[58] =3D HT MSI address window disabled at 0xfee00000 cap 10[80] =3D PCI-Express 1 root port max data 128(128) link x4(x0) pcib3@pci0:0:12:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x005d10de rev=3D0xf3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCIe Bridge' class =3D bridge subclass =3D PCI-PCI cap 01[40] =3D powerspec 2 supports D0 D3 current D0 cap 05[48] =3D MSI supports 2 messages, 64 bit=20 cap 08[58] =3D HT MSI address window disabled at 0xfee00000 cap 10[80] =3D PCI-Express 1 root port max data 128(128) link x4(x4) pcib4@pci0:0:13:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x005d10de rev=3D0xf3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCIe Bridge' class =3D bridge subclass =3D PCI-PCI cap 01[40] =3D powerspec 2 supports D0 D3 current D0 cap 05[48] =3D MSI supports 2 messages, 64 bit=20 cap 08[58] =3D HT MSI address window disabled at 0xfee00000 cap 10[80] =3D PCI-Express 1 root port max data 128(128) link x8(x8) pcib5@pci0:0:14:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x005d10de rev=3D0xa3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCIe Bridge' class =3D bridge subclass =3D PCI-PCI cap 01[40] =3D powerspec 2 supports D0 D3 current D0 cap 05[48] =3D MSI supports 2 messages, 64 bit=20 cap 08[58] =3D HT MSI address window disabled at 0xfee00000 cap 10[80] =3D PCI-Express 1 root port max data 128(128) link = x16(x8) hostb0@pci0:0:24:0: class=3D0x060000 card=3D0x00000000 = chip=3D0x11001022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) HyperTransport = Technology Configuration' class =3D bridge subclass =3D HOST-PCI cap 08[80] =3D HT host cap 08[a0] =3D HT host cap 08[c0] =3D HT host hostb1@pci0:0:24:1: class=3D0x060000 card=3D0x00000000 = chip=3D0x11011022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) Address Map' class =3D bridge subclass =3D HOST-PCI hostb2@pci0:0:24:2: class=3D0x060000 card=3D0x00000000 = chip=3D0x11021022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) DRAM = Controller' class =3D bridge subclass =3D HOST-PCI hostb3@pci0:0:24:3: class=3D0x060000 card=3D0x00000000 = chip=3D0x11031022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) Miscellaneous = Control' class =3D bridge subclass =3D HOST-PCI cap 0f[f0] =3D unknown hostb4@pci0:0:25:0: class=3D0x060000 card=3D0x00000000 = chip=3D0x11001022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) HyperTransport = Technology Configuration' class =3D bridge subclass =3D HOST-PCI cap 08[80] =3D HT host cap 08[a0] =3D HT host cap 08[c0] =3D HT host hostb5@pci0:0:25:1: class=3D0x060000 card=3D0x00000000 = chip=3D0x11011022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) Address Map' class =3D bridge subclass =3D HOST-PCI hostb6@pci0:0:25:2: class=3D0x060000 card=3D0x00000000 = chip=3D0x11021022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) DRAM = Controller' class =3D bridge subclass =3D HOST-PCI hostb7@pci0:0:25:3: class=3D0x060000 card=3D0x00000000 = chip=3D0x11031022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) Miscellaneous = Control' class =3D bridge subclass =3D HOST-PCI cap 0f[f0] =3D unknown vgapci0@pci0:1:3:0: class=3D0x030000 card=3D0x80081002 = chip=3D0x47521002 rev=3D0x27 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, = Inc.' device =3D 'ATI On-Board VGA for HP Proliant 350 G3 (Rage XL = PCI)' class =3D display subclass =3D VGA cap 01[5c] =3D powerspec 2 supports D0 D1 D2 D3 current D0 none2@pci0:128:0:0: class=3D0x058000 card=3D0x00000000 = chip=3D0x005e10de rev=3D0xa3 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 Memory Controller' class =3D memory cap 08[44] =3D HT slave cap 08[e0] =3D HT MSI address window enabled at 0xfee00000 none3@pci0:128:1:0: class=3D0x058000 card=3D0xcb8410de = chip=3D0x00d310de rev=3D0xf3 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 Memory Controller' class =3D memory nfe1@pci0:128:10:0: class=3D0x068000 card=3D0xcb8410de = chip=3D0x005710de rev=3D0xf3 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'NVIDIA Network Bus Enumerator (CK804)' class =3D bridge cap 01[44] =3D powerspec 2 supports D0 D1 D2 D3 current D0 pcib7@pci0:128:11:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x005d10de rev=3D0xf3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCIe Bridge' class =3D bridge subclass =3D PCI-PCI cap 01[40] =3D powerspec 2 supports D0 D3 current D0 cap 05[48] =3D MSI supports 2 messages, 64 bit=20 cap 08[58] =3D HT MSI address window disabled at 0xfee00000 cap 10[80] =3D PCI-Express 1 root port max data 128(128) link x4(x0) pcib8@pci0:128:12:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x005d10de rev=3D0xf3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCIe Bridge' class =3D bridge subclass =3D PCI-PCI cap 01[40] =3D powerspec 2 supports D0 D3 current D0 cap 05[48] =3D MSI supports 2 messages, 64 bit=20 cap 08[58] =3D HT MSI address window disabled at 0xfee00000 cap 10[80] =3D PCI-Express 1 root port max data 128(128) link x4(x4) pcib9@pci0:128:13:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x005d10de rev=3D0xf3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCIe Bridge' class =3D bridge subclass =3D PCI-PCI cap 01[40] =3D powerspec 2 supports D0 D3 current D0 cap 05[48] =3D MSI supports 2 messages, 64 bit=20 cap 08[58] =3D HT MSI address window disabled at 0xfee00000 cap 10[80] =3D PCI-Express 1 root port max data 128(128) link x8(x8) pcib10@pci0:128:14:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x005d10de rev=3D0xa3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce4 PCIe Bridge' class =3D bridge subclass =3D PCI-PCI cap 01[40] =3D powerspec 2 supports D0 D3 current D0 cap 05[48] =3D MSI supports 2 messages, 64 bit=20 cap 08[58] =3D HT MSI address window disabled at 0xfee00000 cap 10[80] =3D PCI-Express 1 root port max data 128(128) link = x16(x8) pcib11@pci0:128:16:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x74581022 rev=3D0x12 hdr=3D0x01 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'PCI-X Bridge (AMD-8132)' class =3D bridge subclass =3D PCI-PCI cap 07[60] =3D PCI-X 64-bit bridge supports 133MHz cap 08[b8] =3D HT interrupt cap 08[c0] =3D HT slave cap 08[f4] =3D HT MSI address window enabled at 0xfee00000 ioapic0@pci0:128:16:1: class=3D0x080010 card=3D0x74591022 = chip=3D0x74591022 rev=3D0x12 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'PCI-X IOAPIC (AMD-8132)' class =3D base peripheral subclass =3D interrupt controller pcib12@pci0:128:17:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x74581022 rev=3D0x12 hdr=3D0x01 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'PCI-X Bridge (AMD-8132)' class =3D bridge subclass =3D PCI-PCI cap 07[60] =3D PCI-X 64-bit bridge supports 133MHz cap 08[b8] =3D HT interrupt cap 08[c0] =3D HT revision ID cap 08[f4] =3D HT MSI address window enabled at 0xfee00000 ioapic1@pci0:128:17:1: class=3D0x080010 card=3D0x74591022 = chip=3D0x74591022 rev=3D0x12 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'PCI-X IOAPIC (AMD-8132)' class =3D base peripheral subclass =3D interrupt controller em0@pci0:134:1:0: class=3D0x020000 card=3D0x10118086 = chip=3D0x10108086 rev=3D0x03 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Dual Port Gigabit Ethernet Controller (Copper) = (82546EB)' class =3D network subclass =3D ethernet cap 01[dc] =3D powerspec 2 supports D0 D3 current D0 cap 07[e4] =3D PCI-X 64-bit supports 133MHz, 2048 burst read, 1 = split transaction cap 05[f0] =3D MSI supports 1 message, 64 bit=20 em1@pci0:134:1:1: class=3D0x020000 card=3D0x10118086 = chip=3D0x10108086 rev=3D0x03 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Dual Port Gigabit Ethernet Controller (Copper) = (82546EB)' class =3D network subclass =3D ethernet cap 01[dc] =3D powerspec 2 supports D0 D3 current D0 cap 07[e4] =3D PCI-X 64-bit supports 133MHz, 2048 burst read, 1 = split transaction cap 05[f0] =3D MSI supports 1 message, 64 bit=20 mpt0@pci0:134:2:0: class=3D0x010000 card=3D0x30601000 = chip=3D0x00501000 rev=3D0x02 hdr=3D0x00 vendor =3D 'LSI Logic (Was: Symbios Logic, NCR)' device =3D 'SAS 3000 series, 4-port with 1064 -StorPort' class =3D mass storage subclass =3D SCSI cap 01[50] =3D powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[98] =3D MSI supports 1 message, 64 bit=20 cap 07[68] =3D PCI-X 64-bit supports 133MHz, 2048 burst read, 16 = split transactions cap 11[b0] =3D MSI-X supports 1 message in map 0x14 # vmstat -i (before MCE) interrupt total rate irq4: uart0 2970 1 irq14: ata0 35 0 irq20: ohci0 30 0 irq21: ehci0 2 0 irq56: em0 3261 1 irq57: em1 7972 2 irq58: mpt0 18559 6 cpu0: timer 5687239 1996 cpu1: timer 5680379 1993 cpu3: timer 5681941 1994 cpu2: timer 5679343 1993 Total 22761731 7989 # vmstat -i (after MCE, with load put on em0 and mpt0) interrupt total rate irq4: uart0 3715 1 irq14: ata0 35 0 irq20: ohci0 30 0 irq21: ehci0 2 0 irq56: em0 378769 123 irq57: em1 8585 2 irq58: mpt0 137919 45 cpu0: timer 6098660 1995 cpu1: timer 6092044 1993 cpu3: timer 6093758 1994 cpu2: timer 6089526 1992 Total 24903043 8148 Thanks for looking at it. Markus= From owner-freebsd-stable@FreeBSD.ORG Fri Jul 9 20:03:45 2010 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 D2B10106564A for ; Fri, 9 Jul 2010 20:03:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A3B548FC16 for ; Fri, 9 Jul 2010 20:03:45 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 41D5446B86; Fri, 9 Jul 2010 16:03:45 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CE6298A03C; Fri, 9 Jul 2010 16:03:32 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Fri, 9 Jul 2010 16:03:31 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> In-Reply-To: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007091603.31843.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 09 Jul 2010 16:03:32 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Markus Gebert Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? 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, 09 Jul 2010 20:03:45 -0000 On Friday, July 09, 2010 11:26:00 am Markus Gebert wrote: > -- > MCA: Bank 4, Status 0xb400004000030c2b > MCA: Global Cap 0x0000000000000105, Status 0x0000000000000007 > MCA: Vendor "AuthenticAMD", ID 0x40f13, APIC ID 2 > MCA: CPU 2 UNCOR BUSLG Observer WR I/O > MCA: Address 0xfd00000000 Using my local port of mcelog this is what I get for this check: CPU 2 4 northbridge ADDR fd00000000 Northbridge Master abort link number = 4 bit61 = error uncorrected bus error 'local node observed, request didn't time out generic write mem transaction i/o access, level generic' STATUS b400004000030c2b MCGSTATUS 7 MCGCAP 105 APICID 2 SOCKETID 0 CPUID Vendor AMD Family 15 Model 65 I don't know what to tell you off hand. Did you buy this hardware from Sun directly? If so, I would try bugging them about this, especially given the error that the BIOS is logging. It does sound like a hardware issue, but in the chipset, not in the RAM, so you might need to swap out the main board rather than the RAM. I'm curious if disabling USB legacy support in the BIOS causes it to still die even with ehci not loaded. If so, then the SMI# for the ehci controller must somehow prevent the issue, perhaps by triggering frequently enough to slow the rate of I/O requests down? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jul 9 23:53:42 2010 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 0182A106564A for ; Fri, 9 Jul 2010 23:53:42 +0000 (UTC) (envelope-from markus.gebert@hostpoint.ch) Received: from mail.adm.hostpoint.ch (mail.adm.hostpoint.ch [217.26.48.124]) by mx1.freebsd.org (Postfix) with ESMTP id BA7608FC0A for ; Fri, 9 Jul 2010 23:53:41 +0000 (UTC) Received: from 77-58-137-22.dclient.hispeed.ch ([77.58.137.22]:36576 helo=[172.16.1.3]) by mail.adm.hostpoint.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OXNO0-000Cpj-E0; Sat, 10 Jul 2010 01:53:40 +0200 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Markus Gebert In-Reply-To: <201007091603.31843.jhb@freebsd.org> Date: Sat, 10 Jul 2010 01:53:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08562D52-02AA-46CF-BFCD-00D0A3C4DC34@hostpoint.ch> References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <201007091603.31843.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1078) Cc: freebsd-stable@freebsd.org Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? 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, 09 Jul 2010 23:53:42 -0000 Hi John Am 09.07.2010 um 22:03 schrieb John Baldwin: > On Friday, July 09, 2010 11:26:00 am Markus Gebert wrote: >> -- >> MCA: Bank 4, Status 0xb400004000030c2b >> MCA: Global Cap 0x0000000000000105, Status 0x0000000000000007 >> MCA: Vendor "AuthenticAMD", ID 0x40f13, APIC ID 2 >> MCA: CPU 2 UNCOR BUSLG Observer WR I/O >> MCA: Address 0xfd00000000 >=20 > Using my local port of mcelog this is what I get for this check: >=20 > CPU 2 4 northbridge=20 > ADDR fd00000000=20 > Northbridge Master abort > link number =3D 4 > bit61 =3D error uncorrected > bus error 'local node observed, request didn't time out > generic write mem transaction > i/o access, level generic' > STATUS b400004000030c2b MCGSTATUS 7 > MCGCAP 105 APICID 2 SOCKETID 0=20 > CPUID Vendor AMD Family 15 Model 65 >=20 > I don't know what to tell you off hand. Did you buy this hardware = from Sun=20 > directly? If so, I would try bugging them about this, especially = given the=20 > error that the BIOS is logging. Yes, this hardware comes from Sun directly, but getting Sun (/Oracle) = support for this issue is gonna be tough. FreeBSD is unsupported, and in = a short test we couldn't reproduce the problem with a Linux kernel. = While I agree that a hardware issue has always been and still is a = possibility to be considered, the fact that we tested this on two = machines remains as well as the fact that 6.x, 7.x do not show the = behavior. Another possibility is of course, that the X4100 is prone to = such issues and somehow 6.x and 7.x have workarounds we're not aware of = or just do something different in way so that this issue does not get = triggered. > It does sound like a hardware issue, but in=20 > the chipset, not in the RAM, so you might need to swap out the main = board=20 > rather than the RAM. Yep. The MCA report does not indicate RAM problems, and the MCE itself = was not our only reason to replace RAM. We found a Sun document about = the X4200 series getting hypertransport errors when RAM of a certain = vendor is installed, so we swapped RAM to rule this one out. We did not replace the mainboard though, but testing on a second X4100 = should do about the same. > I'm curious if disabling USB legacy support in the BIOS causes it to = still die=20 > even with ehci not loaded. If so, then the SMI# for the ehci = controller must=20 > somehow prevent the issue, perhaps by triggering frequently enough to = slow the=20 > rate of I/O requests down? I disabled usb legacy support in the BIOS and booted a kernel with = usb+ohci+ukbd+ums but without ehci. Unfortunately, I cannot reproduce = the MCE. Just to get you right: your theory is that when we don't load the ehci = driver, then the ehci-controller isn't taken over during boot and = therefore handled through SMM so that SMIs might occur often enough to = throttle the system just enough to not let the problem appear? I'm not = very familiar with usb legacy support and SMM, but why would ehci be = handled through SMM when the only usb devices (the virtual keyboard and = mouse) actually sit on ohci? And why would disabling legacy support help = getting more SMIs to throttle the system? As I unterstand this, and I = might be terribly wrong, legacy support is what would cause SMIs in the = first place. Markus From owner-freebsd-stable@FreeBSD.ORG Sat Jul 10 07:17:37 2010 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 AD88C106564A for ; Sat, 10 Jul 2010 07:17:37 +0000 (UTC) (envelope-from flo@smeets.im) Received: from mail.solomo.de (mail.solomo.de [IPv6:2a01:238:43fa:7100::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3E23A8FC0A for ; Sat, 10 Jul 2010 07:17:37 +0000 (UTC) Received: from mail.solomo.de (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 8938B61C4D for ; Sat, 10 Jul 2010 09:17:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at vistream.de Received: from mail.solomo.de ([127.0.0.1]) by mail.solomo.de (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WIUH77FWY5tm for ; Sat, 10 Jul 2010 09:17:32 +0200 (CEST) Received: from [192.168.0.122] (p50915AFC.dip.t-dialin.net [80.145.90.252]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id 4A89261C4E for ; Sat, 10 Jul 2010 09:17:32 +0200 (CEST) Message-ID: <4C381E8A.4050504@smeets.im> Date: Sat, 10 Jul 2010 09:17:30 +0200 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:2.0b2pre) Gecko/20100701 Shredder/3.2a1pre MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: 8.1-RC2: mvs/ZFS Fatal trap 19: non-maskable interrupt trap while in kernel mode 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, 10 Jul 2010 07:17:37 -0000 Hi, a few days ago i installed a server with the latest RC. It has an mvs based controller, attached to it are 6 disks in a RAIDZ, the server has 8GB of RAM and is running amd64. The CPU is a single core Xeon with HT turned on. This morning it hanged for the 2nd time, this time i managed to capture the panic massage: Fatal trap 19: non-maskable interrupt trap while in kernel mode Fatal trap 19: non-maskable interrupt trap while in kernel mode cpuid = 1; cpuid = 0; apic id = 01 apic id = 00 instruction pointer = 0x20:0xffffffff80e75c65 instruction pointer = 0x20:0xffffffff80870f94 stack pointer = 0x28:0xffffff8000022fe0 stack pointer = 0x28:0xffffffff80ca9740 frame pointer = 0x28:0xffffff80000abb40 frame pointer = 0x28:0xffffff80ee2108b0 code segment = base 0x0, limit 0xfffff, type 0x1b code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = processor eflags = interrupt enabled, IOPL = 0 IOPL = 0 current process = current process = 0 (spa_zio) 12 (irq48: mvs0) trap number = 19 trap number = 19 panic: non-maskable interrupt trap cpuid = 0 Here are some details about the controller. mvs0@pci0:6:1:0: class=0x010000 card=0x11ab11ab chip=0x608111ab rev=0x09 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = 'MV88SX6081 8-port SATA II PCI-X Controller' class = mass storage subclass = SCSI After the panic the server just hangs, so i was not able to get a dump or get a backtrace. I'm just building a custom kernel with debugging turned on. Anything i could do in the meantime? Thanks, Florian From owner-freebsd-stable@FreeBSD.ORG Sat Jul 10 17:09:14 2010 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 D063C106566C; Sat, 10 Jul 2010 17:09:14 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4D60D8FC14; Sat, 10 Jul 2010 17:09:13 +0000 (UTC) Received: by wyb34 with SMTP id 34so2902534wyb.13 for ; Sat, 10 Jul 2010 10:09:05 -0700 (PDT) Received: by 10.216.132.86 with SMTP id n64mr1312925wei.11.1278781745233; Sat, 10 Jul 2010 10:09:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.80.147 with HTTP; Sat, 10 Jul 2010 10:08:45 -0700 (PDT) In-Reply-To: <4B7AD495.30900@FreeBSD.org> References: <4B79297D.9080403@FreeBSD.org> <4B79205B.619A0A1A@verizon.net> <4B7A38F5.3090404@FreeBSD.org> <4B7A7D2C.9040200@quip.cz> <4B7AD495.30900@FreeBSD.org> From: Vlad Galu Date: Sat, 10 Jul 2010 19:08:45 +0200 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: Sudden mbuf demand increase and shortage under the 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, 10 Jul 2010 17:09:14 -0000 On Tue, Feb 16, 2010 at 7:23 PM, Maxim Sobolev wrote: > Miroslav Lachman wrote: >> >> Can it be related to this issue somehow? >> >> http://lists.freebsd.org/pipermail/freebsd-current/2009-August/011013.html >> http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010740.html >> >> It was tested on FreeBSD 8 and high UDP traffic on igb interfaces emits >> messages "GET BUF: dmamap load failure - 12" and later results in kernel >> panic. >> We have not received any response to this report. > > Could be the issue, however in our case there is no panic, just that all > userland activity in the system ceases for 2 minutes after it reaches > certain network load level. Sorry for digging into this old thread, but I'm seeing similar symptoms with today's RELENG_8 and bge(4) attached to BCM5721, on an UP system. kern.ipc.nmbclusters is 65536, but what strikes me odd is this: 0/115446003/57722999 requests for mbufs denied (mbufs/clusters/mbuf+clusters) vmstat -i shows a rate of 1100 for the adapter. The machine runs a fairly small PF configuration, but I've already ruled it out, the symptoms appear when PF is disabled as well. I'll happily provide more info. Regards, Vlad -- Good, fast & cheap. Pick any two. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 10 17:37:24 2010 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 9DCEF1065672; Sat, 10 Jul 2010 17:37:24 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3F2578FC08; Sat, 10 Jul 2010 17:37:23 +0000 (UTC) Received: by qwg5 with SMTP id 5so1012365qwg.13 for ; Sat, 10 Jul 2010 10:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=UPwC87nX0oeLWamrGMGsRfCgmmJctXFUQyyLNLP8nAE=; b=YlR0r0x+snzU+PUZoEd2AQKiZ6XvdgGb7HetaHnUQr4f6GSIXkNgRW1YBfHPF+Tkpu 74Dc7P/x5JmMSqX6LE1BaSKm0Gzkg0ruJEyx3mLpO6SQ9tNXFDfAXzbhAeT+CQBUK3Tx o0gzC70RzgnE1Jmlo+HzDZ890EXY/o0b9O2hg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=Y7ZRWt//C/H0IdNTlsEANU0MqY1RXiPQ7H0Abunnq/kI+fAvAVMqyWr+PVZ6KD0iqQ Tepru/RoMuhtyYcrLeAg565kBaVIKy8VjIDkpAnoRZEE4qdZG/WA8ukbKY7C8NWOH1eB Ri0OW1tN7D7NWkEeM9t2xH4np67YdEOiVMaR8= MIME-Version: 1.0 Received: by 10.224.28.23 with SMTP id k23mr859365qac.99.1278783432844; Sat, 10 Jul 2010 10:37:12 -0700 (PDT) Received: by 10.229.239.5 with HTTP; Sat, 10 Jul 2010 10:37:12 -0700 (PDT) In-Reply-To: <08562D52-02AA-46CF-BFCD-00D0A3C4DC34@hostpoint.ch> References: <6B57591F-9FA2-45EB-825F-1DB025C0635D@hostpoint.ch> <201007091603.31843.jhb@freebsd.org> <08562D52-02AA-46CF-BFCD-00D0A3C4DC34@hostpoint.ch> Date: Sat, 10 Jul 2010 12:37:12 -0500 Message-ID: From: Alan Cox To: Markus Gebert Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: 8.1-RC2 - PCI fatal error or MCE triggered by USB/ehci on Sun X4100M2? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jul 2010 17:37:24 -0000 On Fri, Jul 9, 2010 at 6:53 PM, Markus Gebert wrote: [snip] > > Yes, this hardware comes from Sun directly, but getting Sun (/Oracle) > support for this issue is gonna be tough. FreeBSD is unsupported, and in a > short test we couldn't reproduce the problem with a Linux kernel. While I > agree that a hardware issue has always been and still is a possibility to be > considered, the fact that we tested this on two machines remains as well as > the fact that 6.x, 7.x do not show the behavior. Another possibility is of > course, that the X4100 is prone to such issues and somehow 6.x and 7.x have > workarounds we're not aware of or just do something different in way so that > this issue does not get triggered. > > 8.1 is our first release to have the driver for configuring and reporting machine check exceptions enabled by default. Prior to 8.1, you had to explicitly enable the driver at boot time. Alan From owner-freebsd-stable@FreeBSD.ORG Sat Jul 10 18:45:00 2010 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 B85D6106566B for ; Sat, 10 Jul 2010 18:45:00 +0000 (UTC) (envelope-from tundra@tundraware.com) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) by mx1.freebsd.org (Postfix) with ESMTP id 5A2F88FC14 for ; Sat, 10 Jul 2010 18:45:00 +0000 (UTC) Received: from [192.168.0.2] (viper.tundraware.com [192.168.0.2]) (authenticated bits=0) by ozzie.tundraware.com (8.14.4/8.14.4) with ESMTP id o6AIirw9008555 (version=TLSv1/SSLv3 cipher=DHE-DSS-CAMELLIA256-SHA bits=256 verify=NO); Sat, 10 Jul 2010 13:44:53 -0500 (CDT) (envelope-from tundra@tundraware.com) Message-ID: <4C38BFA5.8000605@tundraware.com> Date: Sat, 10 Jul 2010 13:44:53 -0500 From: Tim Daneliuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Kostik Belousov References: <4C3240A9.9020603@tundraware.com> <20100705211021.GV13238@deviant.kiev.zoral.com.ua> In-Reply-To: <20100705211021.GV13238@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (ozzie.tundraware.com [75.145.138.73]); Sat, 10 Jul 2010 13:44:53 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: o6AIirw9008555 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No Cc: freebsd-stable@freebsd.org Subject: Re: 8.1-PRE Throwing Traps Going Multiuser 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, 10 Jul 2010 18:45:00 -0000 On 7/5/2010 4:10 PM, Kostik Belousov wrote: > On Mon, Jul 05, 2010 at 03:29:29PM -0500, Tim Daneliuk wrote: >> Is this a known problem (I've submitted a PR just in case it is not)? >> >> I am seeing this consistently when I try to do a build/installworld/kernel >> with daily sources from the master tree: >> >> http://www.mediafire.com/imageview.php?quickkey=qmhizdtnhyo&thumb=4 >> >> The system boots fine single-user. Problem is repeatable with both >> my kernel AND GENERIC. (My config file at end of this msg.) >> >> Attempting to enter multi-user causes the problem. This >> occurs whether or not anything is enabled in /etc/rc.conf. >> >> Falling back to my 6-18-2010 system image makes everything right again. >> >> MOBO is an Intel D946GZIS with a single SATA drive and one additional >> 3Com 3c905 NIC in addition to the onboard Intel NIC. >> >> >> My Kernel Config >> ============================================================= >> >> include GENERIC >> >> ident MACHINENAME >> >> options IPFIREWALL >> options IPDIVERT >> >> options VESA >> >> # System console options >> >> options SC_DISABLE_REBOOT # disable reboot key sequence >> options SC_HISTORY_SIZE=200 # number of history buffer lines >> options SC_PIXEL_MODE # add support for the raster text mode >> >> # The following options will change the default colors of syscons. >> >> options SC_NORM_ATTR="(FG_GREEN|BG_BLACK)" >> options SC_NORM_REV_ATTR="(FG_YELLOW|BG_GREEN)" >> options SC_KERNEL_CONS_ATTR="(FG_RED|BG_BLACK)" >> options SC_KERNEL_CONS_REV_ATTR="(FG_BLACK|BG_RED)" > > Add DDB to your kernel, or specify the dump device. Then obtain a > backtrace for the trap. As of this morning's build (0700 CDT) this problem seems resolved. -- ---------------------------------------------------------------------------- Tim Daneliuk tundra@tundraware.com PGP Key: http://www.tundraware.com/PGP/