From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 03:55:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D92A4106566C for ; Sun, 26 Feb 2012 03:55:18 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id B28CC8FC08 for ; Sun, 26 Feb 2012 03:55:18 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q1Q3t1fX026804; Sat, 25 Feb 2012 20:55:04 -0700 From: Erich Dollansky To: freebsd-stable@freebsd.org Date: Sun, 26 Feb 2012 10:54:56 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <201202251027.q1PARURH021975@mp.cs.niu.edu> In-Reply-To: <201202251027.q1PARURH021975@mp.cs.niu.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201202261054.56403.erichfreebsdlist@ovitrap.com> Cc: Scott Bennett Subject: Re: random problem with 8.3 from yesterday X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 03:55:19 -0000 Hi, On Saturday 25 February 2012 17:27:30 Scott Bennett wrote: > On Wed, 22 Feb 2012 13:34:36 +0700 Erich Dollansky > wrote: > > >I got a new thumb drive which was FAT formatted. I use this script to change this: > > > >!/bin/tcsh > ># > ># This script format a thumb drive connected to USB as da0. > ># > >printf "You have to run this script as 'root' to succeed.\n" > >printf "Warning this script will delete all your data from /dev/da0. Continue? > " > >set Eingabe = $< > >if ("$Eingabe" == "y") then > > printf "\nDeleting the device " > > dd if=/dev/zero of=/dev/da0 bs=1k count=1 > > printf "\nWriting the BSD label " > > bsdlabel -Bw da0 auto > > Hmmm...so no MBR and no GPT either? Just the bare device? I guess > I haven't tried that, so I don't know what that would do. it works since years with all other and even with hard disks. Only the system disk has to be done 'properly'. > > > > >I then call manually > > > >tunefs -L NewDeviceName /dev/da0a > > Just out of curiosity, I'd like to know why you run tunefs manually, Historical reasons. It is an old script and I never updated it. > rather than using "-L NewDeviceName" on the newfs command, given that your > script is clearing the physical device and then creating an empty file > system. > > > >Either this call or the mount command does not work randomly. > > > >When I then try to mount the device on /dev/da0a it does not work always. > > What do you mean when you write "mount the device on /dev/da0a"? > Normally one mounts a filesystem onto a "device", e.g., I mean the device connected to /dev/da0a just to make clear that I did not use /dev/da0. > > or some similar thing. Also, why do you refer to /dev/da0a at all if you > labeled the file system? The whole point of labeling the file system is > supposed to be so that you can mount it independently of the physical > device name, e.g., It is a chicken egg problem. As long as fstab is not updated with the name of the new device, it does not work the other way. > > mount /dev/ufs/NewDeviceName /thumbfs > > which allows you to have an entry in /etc/fstab for mounting the file > system that doesn't need to be edited every time you reboot the system or > move devices around. I do the editing later. It is just a matter of work sequence. > > > >I do not know what this causes, I am only randomly able to reproduce it. > > > >It might be affected by removing the device or keeping it plugged in. > > Well, yes, that's what you label partitions/devices to avoid having > to deal with manually, right? Do not forget, that this step does not happen always. > > > >uname says: > > > >FreeBSD AMD620.ovitrap.com 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #28: Tue Feb 21 17:15:07 WIT 2012 erich@AMD620.ovitrap.com:/usr/obj/usr/src/sys/AsusAMD620 amd64 > > > >dmesg says: > > > >ugen1.2: at usbus1 > >umass0: on usbus1 > >umass0: SCSI over Bulk-Only; quirks = 0x4001 > >umass0:2:0:-1: Attached to scbus2 > >da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 > >da0: < USB FLASH DRIVE PMAP> Removable Direct Access SCSI-0 device > >da0: 40.000MB/s transfers > >da0: 15272MB (31277056 512 byte sectors: 255H 63S/T 1946C) > > > >It is not an urgent problem. > > > It most likely is not a problem at all. See > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-glabel.html#AEN27470 > It does not explain to me why the device could not be mounted. I did not have this problem anymore since then. It might be the case that the problem only appears when the drive has a fresh file system or a new label. I will check this later. Erich From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 04:04:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE33C106566B for ; Sun, 26 Feb 2012 04:04:32 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id C73198FC1A for ; Sun, 26 Feb 2012 04:04:32 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q1Q44CvL028870; Sat, 25 Feb 2012 21:04:19 -0700 From: Erich Dollansky To: freebsd-stable@freebsd.org Date: Sun, 26 Feb 2012 11:04:10 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <201202251717.q1PHHeXD024464@mp.cs.niu.edu> In-Reply-To: <201202251717.q1PHHeXD024464@mp.cs.niu.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201202261104.11000.erichfreebsdlist@ovitrap.com> Cc: Scott Bennett Subject: Re: random problem with 8.3 from yesterday X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 04:04:33 -0000 Hi, On Sunday 26 February 2012 00:17:40 Scott Bennett wrote: > On Sat, 25 Feb 2012 08:56:24 -0800 Kevin Oberman > wrote: > >On Sat, Feb 25, 2012 at 2:27 AM, Scott Bennett wrote: > >> =A0 =A0 On Wed, 22 Feb 2012 13:34:36 +0700 Erich Dollansky > >> wrote: > >> > >>>I got a new thumb drive which was FAT formatted. I use this script to cha= > >nge this: > >>> > >>>!/bin/tcsh > >>># > >>># This script format a thumb drive connected to USB as da0. > >>># > >>>printf "You have to run this script as 'root' to succeed.\n" > >>>printf "Warning this script will delete all your data from /dev/da0. Cont= > >inue? > " > >>>set Eingabe =3D $< > >>>if ("$Eingabe" =3D=3D "y") then > >>> =A0 printf "\nDeleting the device " > >>> =A0 dd if=3D/dev/zero of=3D/dev/da0 bs=3D1k count=3D1 > >>> =A0 printf "\nWriting the BSD label " > >>> =A0 bsdlabel -Bw da0 auto > >> > >> =A0 =A0 Hmmm...so no MBR and no GPT either? =A0Just the bare device? =A0I= > > guess > >> I haven't tried that, so I don't know what that would do. > > > >Call me a bit confused, but I thought -B did write an MBR. It always > >has seemed to do so for me, at any rate. From man bsdlabel: > >"Installing Bootstraps > > If the -B option is specified, bootstrap code will be read from the fi= > >le > > /boot/boot and written to the disk." > >Or am I not understanding something? > it looks like that I have left the -B option by mistake for many years in there. > I guess I understand the part that you quoted above as meaning that > the bootstrap code would be copied to the bootstrap sectors. However, as > I interpret it, the bsdlabel command does not write a MBR, which would > include the slice map for the device. Further, Erich's later commands did > not specify a slice number. In short, it looks to me as though he may have > ended up with the initial boot code where it belonged at the start of the > device, but the boot code looks for the slice map, which isn't there, so > it should not be possible to boot a kernel because the bootstrap code There is also no kernel, no binary, nothing what could be started on the device. > would not be able to find it. But as far as simply mounting a file system, > I really don't know whether it should work to have a BSD label written to > a bare device with neither a MBR nor a GPT to find that label. IOW, would > the device node to be used in the mount operation have been created? > Note to Erich: did you look in /dev and /dev/ufs to see whether all > of the device files that you expected to be there were, in fact, present > before you attempted the mount? It was there. I extra checked. As I said before, since I got the file system onto the device, the device can be used as expected. Erich From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 04:06:36 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 888B3106564A for ; Sun, 26 Feb 2012 04:06:36 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id 3FAC08FC08 for ; Sun, 26 Feb 2012 04:06:36 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q1Q46KDX029345; Sat, 25 Feb 2012 21:06:22 -0700 From: Erich Dollansky To: freebsd-stable@freebsd.org Date: Sun, 26 Feb 2012 11:06:19 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <201202251717.q1PHHeXD024464@mp.cs.niu.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202261106.19487.erichfreebsdlist@ovitrap.com> Cc: Scott Bennett Subject: Re: random problem with 8.3 from yesterday X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 04:06:36 -0000 Hi, On Sunday 26 February 2012 00:55:46 Kevin Oberman wrote: > I thought he was creating a "monolithic" device...what was called > "dangerously dedicated". No slices at all. Not only are DD volumes yes, I remember this term. And Windows machines get confused but they do not damage the media. > mountable, they are bootable. It's been years since I created a DD > disk as the slight space savings are irrelevant on modern hundreds of > gigabyte disks, so I may have forgotten how it works. It might still > make sense on a small thumb drive, bootable or not. Never break a winning team. The script doing the job works since a long time. This is the simple reason behind. Erich From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 08:58:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83854106566C for ; Sun, 26 Feb 2012 08:58:08 +0000 (UTC) (envelope-from hm@hm.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [187.95.0.181]) by mx1.freebsd.org (Postfix) with ESMTP id C515B8FC0C for ; Sun, 26 Feb 2012 08:58:07 +0000 (UTC) Received: from pop1.hm.net.br (pop1.hm.net.br [186.222.209.53]) by msrv.matik.com.br (8.14.5/8.14.5) with ESMTP id q1Q8tH8c093287; Sun, 26 Feb 2012 05:55:17 -0300 (BRT) (envelope-from hm@hm.net.br) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at msrv.matik.com.br X-DKIM: OpenDKIM Filter v2.4.3 msrv.matik.com.br q1Q8tH8c093287 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hm.net.br; s=racoon; t=1330246525; bh=m35Tq/stXkKw2X/8ZD80/6LPU0+bbzU22eCL2jl5ZDk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=IhglngZv5FZ5gHQGz/MpjdSxOwFQ82F65Bysv6JE4JwniJeeRVprp5CsghafjinMe 4anwX+PSldAj/dZnIGKGYGspkuAJvwL53U5wU6EqQH0f2xHQIrXcd0WD2qPN6GmhfP OhVeY0xomgTHVLGkJZpdiaqRc/zVUHgovihE5Dck= Authentication-Results: msrv.matik.com.br; sender-id=pass header.from=hm@hm.net.br; spf=pass smtp.mfrom=hm@hm.net.br Message-ID: <4F49F375.5000002@hm.net.br> Date: Sun, 26 Feb 2012 05:55:17 -0300 From: H User-Agent: Mozilla/5.0 MIME-Version: 1.0 To: Mark Felder References: <4F46847D.4010908@my.gd> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL, BAYES_00, T_DKIM_INVALID, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2-hm_201202.c X-Spam-Checker-Version: SpamAssassin 3.3.2-hm_201202.c (2011-06-06) on msrv.matik.com.br Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 08:58:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Felder wrote: > On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot > wrote: > >> >> Now, I find the number of problem reports regarding 9.0-RELEASE >> alarming and I'm growing more and more fearful towards it. > > Then stick with the 8.x train until it's no longer supported. > Also, don't you know the rule about running .0 releases in > production? :) > > 9.0 had LOTS of changes. They were very important. It's going to > take a while for the community to fully absorb them and bugs to be > worked out. We don't have enough testers of -CURRENT to prevent > this. Everything seemed stable (ie, no release blockers) for the > people running -CURRENT and -PRERELEASE, BETAs, and RCs, so it was > released. > > But as always, TEST TEST TEST and please have a proper > staging/test environment before you throw your production into > 9.x. > that is all understandable but the point should not be forgotten ... I mean certainly -RELEASE __is__ the production release so, few testers is no excuse, still more when that is a known issue, so a bigger time frame would be the solution until the var _seemed_stable change into _is_stable of course, that is not always so easy but also think of side effects, few_testers could change into still_less when FreeBSD prove to have unstable releases - -- H -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9J83UACgkQvKVfg5xjCDw7ggCfTpMhHuGqetRHUbKmBmCfRMwn d04An3f8UIdfvtee47NYCS+EjqCk+1t7 =fJbU -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 09:31:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E596106564A for ; Sun, 26 Feb 2012 09:31:29 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id 012238FC16 for ; Sun, 26 Feb 2012 09:31:28 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q1Q9V0Cd006617; Sun, 26 Feb 2012 02:31:03 -0700 From: Erich Dollansky To: freebsd-stable@freebsd.org Date: Sun, 26 Feb 2012 16:30:57 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <4F46847D.4010908@my.gd> <4F49F375.5000002@hm.net.br> In-Reply-To: <4F49F375.5000002@hm.net.br> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201202261630.57372.erichfreebsdlist@ovitrap.com> Cc: H , Mark Felder Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 09:31:29 -0000 Hi, On Sunday 26 February 2012 15:55:17 H wrote: > Mark Felder wrote: > > On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot > > wrote: > > that is all understandable but the point should not be forgotten ... > > I mean certainly -RELEASE __is__ the production release there is not the production release here. There are always at least two. > > so, few testers is no excuse, still more when that is a known issue, > so a bigger time frame would be the solution until the var > _seemed_stable change into _is_stable Stable has here a different meaning. It just means that nothing will change at the interfaces anymore as long the error is not hidden there. 5.2 and 5.21 was such an example if I remember right. > > of course, that is not always so easy but also think of side effects, > few_testers could change into still_less when FreeBSD prove to have > unstable releases No matter what effort you put into testing, you can never achieve the robustness of an older release. I still have 7.4 running on one. This can stay until next year. So, why do you want to run the latest release on an important machine? You can, but you are not in a position to complain then. Erich From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 10:17:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0311106564A for ; Sun, 26 Feb 2012 10:17:14 +0000 (UTC) (envelope-from hm@hm.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [187.95.0.181]) by mx1.freebsd.org (Postfix) with ESMTP id 0AFC28FC0A for ; Sun, 26 Feb 2012 10:17:13 +0000 (UTC) Received: from pop1.hm.net.br (pop1.hm.net.br [186.222.209.53]) by msrv.matik.com.br (8.14.5/8.14.5) with ESMTP id q1QAGhP3012409; Sun, 26 Feb 2012 07:16:43 -0300 (BRT) (envelope-from hm@hm.net.br) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at msrv.matik.com.br X-DKIM: OpenDKIM Filter v2.4.3 msrv.matik.com.br q1QAGhP3012409 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hm.net.br; s=racoon; t=1330251409; bh=Ml5STO+/XPIqraLG9OQUb4TsYKhj8Uw0eQmbqAJoCT4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Rnvj39rjUHQdtKi/2xU2nOvF3hQnb/e8nVJQiN7AwiNy9m3e1tqfPUZnsgy7jZtqv JA7Z1UJ/ZmIMLoM4VafSfGBN3xDo/h9amaI5UXjau8ntPOTfVgmmWc8Z9tMXOntaOb +ahIMYcDg4gQaJGAeUlVlWwjI6X9uikViAUjfPMA= Authentication-Results: msrv.matik.com.br; sender-id=pass header.from=hm@hm.net.br; spf=pass smtp.mfrom=hm@hm.net.br Message-ID: <4F4A068B.2090807@hm.net.br> Date: Sun, 26 Feb 2012 07:16:43 -0300 From: H User-Agent: Mozilla/5.0 MIME-Version: 1.0 To: Erich Dollansky References: <4F46847D.4010908@my.gd> <4F49F375.5000002@hm.net.br> <201202261630.57372.erichfreebsdlist@ovitrap.com> In-Reply-To: <201202261630.57372.erichfreebsdlist@ovitrap.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL, BAYES_00, T_DKIM_INVALID, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2-hm_201202.c X-Spam-Checker-Version: SpamAssassin 3.3.2-hm_201202.c (2011-06-06) on msrv.matik.com.br Cc: Mark Felder , freebsd-stable@freebsd.org Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 10:17:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erich Dollansky wrote: > Hi, > > On Sunday 26 February 2012 15:55:17 H wrote: >> Mark Felder wrote: >>> On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot >>> wrote: >> >> that is all understandable but the point should not be forgotten >> ... >> >> I mean certainly -RELEASE __is__ the production release > > there is not the production release here. There are always at least > two. whatever, the question is not the how many, it is the word BETA or PRE change to RELEASE and we should not turn this into some word-fiddling important is maintain the understanding for that word, because there are lot of not_developer_people out what seems forgotten is what is here in the second part: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/lessons-learned.html what developers understand, mean or think does not matter, the _user_ should be able to understand and believe in this word RELEASE, what IMO is pretty clear so please do not argument with me or anybody else, it is merely a pretty fair and neutral opinion about RELEASE meaning backed on what is stated on the page above, it seems to be the procedure, which eventually needs revision, because we humans always will fail somewhere H >> >> so, few testers is no excuse, still more when that is a known >> issue, so a bigger time frame would be the solution until the >> var _seemed_stable change into _is_stable > > Stable has here a different meaning. It just means that nothing > will change at the interfaces anymore as long the error is not > hidden there. 5.2 and 5.21 was such an example if I remember > right. >> >> of course, that is not always so easy but also think of side >> effects, few_testers could change into still_less when FreeBSD >> prove to have unstable releases > > No matter what effort you put into testing, you can never achieve > the robustness of an older release. I still have 7.4 running on > one. This can stay until next year. > > So, why do you want to run the latest release on an important > machine? You can, but you are not in a position to complain then. > > Erich - -- H -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9KBosACgkQvKVfg5xjCDz/6QCglZ7CI24iBYcicY7X1Qsffdwt 3T8AnA5SVaESL7m3TYCuznJAu2usw9nW =x/DV -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 10:19:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2F4C106564A for ; Sun, 26 Feb 2012 10:19:48 +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 10FE68FC14 for ; Sun, 26 Feb 2012 10:19:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q1QAIiNS090805; Sun, 26 Feb 2012 21:18:44 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 26 Feb 2012 21:18:44 +1100 (EST) From: Ian Smith To: vermaden In-Reply-To: Message-ID: <20120226203949.H89643@sola.nimnet.asn.au> References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org, lars.engels@0x20.net, Hans Petter Selasky Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 10:19:48 -0000 Ccs mightily trimmed to avoid not-subscribed bounces; readd as desired: On Mon, 20 Feb 2012 09:43:59 +0100, vermaden wrote: > To: freebsd-hackers@freebsd.org > Cc: matt , gleb.kurtsou@gmail.com, > freebsd-stable@freebsd.org, uffe@uffe.org, joe.culler@gmail.com, > Hans Petter Selasky , freebsd-current@freebsd.org, > lars.engels@0x20.net > > Hi, > > new version with new features (and BUGs ;p) [..] Well, I was busy composing this reply a few days ago when this system was taken out by a very near lightning strike .. losing the ADSL modem (blown into 4 pieces scattered about the room :), 2 scorched switches, the old xe pccard interface feeding the ADSL (its dongle also blown into several pieces), and a good deal of travelling - I was 80km remote at the time - but very fortunately not the server box itself .. close call! > Added 'noatime' as a default mount option when possible. Good idea for many use cases, but could that be optional? [..] > Added config file to be used from /usr/local/etc/automount.conf file, possible options are (these are defaults): > MNTPREFIX="/media" > LOG="/var/log/automount.log" > STATE="/var/run/automount.state" > ENCODING="en_US.ISO8859-1" > CODEPAGE="cp437" > DATEFMT="%Y-%m-%d %H:%M:%S" > USERUMOUNT="NO" > > Mine config currently has only these: > ENCODING="pl_PL.ISO8859-2" > CODEPAGE="cp852" > USERUMOUNT="YES" > > The USERMOUNT otions if set to YES (default to NO) will 'chmod +s /sbin/umount', > so You can click the ^ button on the devices list in NAUTILUS. Someone might explain why I needn't feel a bit uncomfortable about that chmod, even though it is optional, and even though I've been guilty myself of a 'chown root:nobody /sbin/tc' on a linux firewall box .. > These newly mounted devices appear on NAUTILUS sidebar (only with /media prefix). I wonder how it goes with KDE4? (still 3.5 here, which wouldn't count) [..] > /usr/local/sbin/automount.sh > ------------------------------------------------------------------------------- [..] > [ "${USERUMOUNT}" = "YES" ] && chmod u+s /sbin/umount # /* WHEEL group member */ > > __create_mount_point() { # /* 1=DEV */ > MNT="${MNTPREFIX}/$( basename ${1} )" > mkdir -p ${MNT} > chown 1000 ${MNT} > } Er, who's user 1000 ? Another config item perhaps? Or should that be the particular user currently invoking the script via devd (if that can be determined?)? Also, are you using sysctl vfs.usermount=1 ? > case ${2} in > (attach) > for I in /dev/${1}* > do [..] > (*Unix\ Fast\ File*) > __create_mount_point ${I} > fsck_ufs -y ${I} Mmm, fsck on every attachment? Maybe running fsck should be optional? We might be attaching, perhaps, a 2TB backup HD? .. > __check_already_mounted ${MNT} > mount -o noatime ${I} ${MNT} Again, I'd rather see that optional in an intended system tool, although it's an option I'd tend to use myself. > __log "${I}:mount (ufs)" > ;; [..] > (detach) > MOUNT=$( mount ) > __state_lock > grep ${1} ${STATE} \ > | while read DEV PROVIDER MNT > do > TARGET=$( echo "${MOUNT}" | grep -E "^${PROVIDER} " | awk '{print $3}' ) > [ -z ${TARGET} ] && { > __state_remove ${MNT} ${STATE} ${LINE} > continue > } > umount -f ${TARGET} & > unset TARGET > __state_remove ${MNT} ${STATE} ${LINE} > __log "${DEV}:umount" > done > __state_unlock > __log "/dev/${1}:detach" > find ${MNTPREFIX} -type d -empty -delete I don't see the need to remove all empty subdirs of, say, /media - this tool may not be the only thing wanting to manage that space? Removing directories that were added by this tool itself makes sense of course. Looks like a neat gadget, don't mind me picking up on a few aspects :) cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 11:32:28 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 276FB106564A; Sun, 26 Feb 2012 11:32:28 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id CBE9E8FC08; Sun, 26 Feb 2012 11:32:27 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q1QBWJ9n020592; Sun, 26 Feb 2012 04:32:25 -0700 From: Erich Dollansky To: Chris Rees Date: Sun, 26 Feb 2012 18:32:17 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <4F46847D.4010908@my.gd> <201202240835.32041.erichfreebsdlist@ovitrap.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202261832.17793.erichfreebsdlist@ovitrap.com> Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 11:32:28 -0000 Hi, On Sunday 26 February 2012 18:16:53 Chris Rees wrote: > On 24 February 2012 01:35, Erich Dollansky wrote: > > > > On Friday 24 February 2012 01:25:01 Damien Fleuriot wrote: > >> > >> This is NOT a troll. > >> This is NOT a flame. > >> Do NOT hijack this thread to troll/flame. > >> > > allow them some fun too. > >> > >> > >> Now, I find the number of problem reports regarding 9.0-RELEASE alarming > >> and I'm growing more and more fearful towards it. > >> > >> In the current state of things, I have *absolutely* no wish to run it in > >> production :( > >> > > Did you read deeply into the strategy behind the releases? If I remember right, the odd numbers are a little bit more experimental compared to the even numbers. For myself, I try to stick with even numbers whenever possible. If I install FreeBSD on a serious machine, I never use x.0. It must be at least x.1. > > There's no such odd/even number policy with FreeBSD-- I think you're > thinking of another OS ;) > maybe something got stuck in my head with the move from 4 to 5. How easy was the move to 6 then? Independent of this, it is still true that there is always the older branch available when a new one opens at .0. > You're right that x.0 is slightly more experimental in general though > (by its nature, it must be). And has nothing to do with FreeBSD as such. Erich From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 11:35:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC260106564A for ; Sun, 26 Feb 2012 11:35:09 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id 808B18FC0C for ; Sun, 26 Feb 2012 11:35:09 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q1QB0HrF023623; Sun, 26 Feb 2012 04:00:20 -0700 From: Erich Dollansky To: H Date: Sun, 26 Feb 2012 18:00:16 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <4F46847D.4010908@my.gd> <201202261630.57372.erichfreebsdlist@ovitrap.com> <4F4A068B.2090807@hm.net.br> In-Reply-To: <4F4A068B.2090807@hm.net.br> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201202261800.16269.erichfreebsdlist@ovitrap.com> Cc: Mark Felder , freebsd-stable@freebsd.org Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 11:35:09 -0000 Hi, On Sunday 26 February 2012 17:16:43 H wrote: > Erich Dollansky wrote: > > > > On Sunday 26 February 2012 15:55:17 H wrote: > >> Mark Felder wrote: > >> > >> I mean certainly -RELEASE __is__ the production release > > > > there is not the production release here. There are always at least > > two. > > whatever, the question is not the how many, it is the word BETA or PRE > change to RELEASE and we should not turn this into some word-fiddling > it is just logic. 10 is currently ALPHA, 8.3 is currently BETA, there might be soon a RC1 and the release. > important is maintain the understanding for that word, because there > are lot of not_developer_people out What should developer do after no errors have been reported anymore in an RC? I would suggest that they release their stuff. > > what seems forgotten is what is here in the second part: > > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/lessons-learned.html > > what developers understand, mean or think does not matter, the _user_ > should be able to understand and believe in this word RELEASE, what > IMO is pretty clear > Release means that developers either state the errors in the README or believe that there are no known errors. It does not mean that there are no more errors in there. > so please do not argument with me or anybody else, it is merely a > pretty fair and neutral opinion about RELEASE meaning > > backed on what is stated on the page above, it seems to be the > procedure, which eventually needs revision, because we humans always > will fail somewhere You can do the same as I do. I run currently a 8.3 BETA. You can encourage people to do so too to make it easier for the developers to spot as many errors as possible before the release. Still, FreeBSD has always at least one more release out there which was hardened in real life. If then take into account that odd numbers are known to have a higher risk of errors plus the fact that 9.0 was the first release of the new branch, I do not see a need to change much to the advantage except of putting more load onto the people who actually make it happen. Erich From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 11:48:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D78A106564A for ; Sun, 26 Feb 2012 11:48:59 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 001898FC12 for ; Sun, 26 Feb 2012 11:48:58 +0000 (UTC) Received: by iaeo4 with SMTP id o4so6523499iae.13 for ; Sun, 26 Feb 2012 03:48:58 -0800 (PST) Received-SPF: pass (google.com: domain of utisoft@gmail.com designates 10.50.156.194 as permitted sender) client-ip=10.50.156.194; Authentication-Results: mr.google.com; spf=pass (google.com: domain of utisoft@gmail.com designates 10.50.156.194 as permitted sender) smtp.mail=utisoft@gmail.com; dkim=pass header.i=utisoft@gmail.com Received: from mr.google.com ([10.50.156.194]) by 10.50.156.194 with SMTP id wg2mr12554278igb.18.1330256938543 (num_hops = 1); Sun, 26 Feb 2012 03:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=8gy8est8kSot3t7qJKT6uqtp3MZzztpHPCOunX+AO+E=; b=culyor/54NxlSF0T+4g0Od3ZZADbnkrs9DOgDlRcPI8j7dJjXMgBuHaNZfSbO3yVjY vSXVh+u5z5Gq38b5tvb0iDbd/2LApcGV5PSswSrnFbhaV0j8ajVzl4y/vI4Wy+eZILq8 wgb8OA3S1qfvTmxIgcQK33Qa4RKawHsTgKtc4= Received: by 10.50.156.194 with SMTP id wg2mr10070203igb.18.1330255043275; Sun, 26 Feb 2012 03:17:23 -0800 (PST) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.231.155.20 with HTTP; Sun, 26 Feb 2012 03:16:53 -0800 (PST) In-Reply-To: <201202240835.32041.erichfreebsdlist@ovitrap.com> References: <4F46847D.4010908@my.gd> <201202240835.32041.erichfreebsdlist@ovitrap.com> From: Chris Rees Date: Sun, 26 Feb 2012 11:16:53 +0000 X-Google-Sender-Auth: ExRzKQAPuMIKtdT6AnWpGUC5X9I Message-ID: To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 11:48:59 -0000 On 24 February 2012 01:35, Erich Dollansky w= rote: > Hi, > > On Friday 24 February 2012 01:25:01 Damien Fleuriot wrote: >> >> This is NOT a troll. >> This is NOT a flame. >> Do NOT hijack this thread to troll/flame. >> > allow them some fun too. >> >> >> Now, I find the number of problem reports regarding 9.0-RELEASE alarming >> and I'm growing more and more fearful towards it. >> >> In the current state of things, I have *absolutely* no wish to run it in >> production :( >> > Did you read deeply into the strategy behind the releases? If I remember = right, the odd numbers are a little bit more experimental compared to the e= ven numbers. For myself, I try to stick with even numbers whenever possible= . If I install FreeBSD on a serious machine, I never use x.0. It must be at= least x.1. There's no such odd/even number policy with FreeBSD-- I think you're thinking of another OS ;) You're right that x.0 is slightly more experimental in general though (by its nature, it must be). Chris From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 12:05:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CF01106564A for ; Sun, 26 Feb 2012 12:05:12 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id C15128FC19 for ; Sun, 26 Feb 2012 12:05:11 +0000 (UTC) Received: by iaeo4 with SMTP id o4so6534331iae.13 for ; Sun, 26 Feb 2012 04:05:11 -0800 (PST) Received-SPF: pass (google.com: domain of utisoft@gmail.com designates 10.50.76.130 as permitted sender) client-ip=10.50.76.130; Authentication-Results: mr.google.com; spf=pass (google.com: domain of utisoft@gmail.com designates 10.50.76.130 as permitted sender) smtp.mail=utisoft@gmail.com; dkim=pass header.i=utisoft@gmail.com Received: from mr.google.com ([10.50.76.130]) by 10.50.76.130 with SMTP id k2mr12571276igw.22.1330257911301 (num_hops = 1); Sun, 26 Feb 2012 04:05:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=T+n5oExfFOVfGN1ccRUS6G2IrVCkCzNs6bzOHFjX5g0=; b=pEjG3Nqxyk1TXJB4vYakSL7JFscxQmVHM+D6hqMSMHoMSVoyNAOlknjoe4UNef/Gv5 w6NRjItOHRDTnpr3LrBGf2Y2iU06gH/EvPkM4k4Ebznzw0NOr4Z2QPFT7itrey3mv0Z1 9a2ksXyHVBTm9o7Npv9vQ+w0iDtWzGLnUTLTY= Received: by 10.50.76.130 with SMTP id k2mr10180679igw.22.1330257911262; Sun, 26 Feb 2012 04:05:11 -0800 (PST) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.231.155.20 with HTTP; Sun, 26 Feb 2012 04:04:41 -0800 (PST) In-Reply-To: <201202261832.17793.erichfreebsdlist@ovitrap.com> References: <4F46847D.4010908@my.gd> <201202240835.32041.erichfreebsdlist@ovitrap.com> <201202261832.17793.erichfreebsdlist@ovitrap.com> From: Chris Rees Date: Sun, 26 Feb 2012 12:04:41 +0000 X-Google-Sender-Auth: gbPx7cY6IMfCUhBnKmySqkpTcbY Message-ID: To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 12:05:12 -0000 On 26 February 2012 11:32, Erich Dollansky w= rote: > Hi, > > On Sunday 26 February 2012 18:16:53 Chris Rees wrote: >> On 24 February 2012 01:35, Erich Dollansky wrote: >> > >> > On Friday 24 February 2012 01:25:01 Damien Fleuriot wrote: >> >> >> >> This is NOT a troll. >> >> This is NOT a flame. >> >> Do NOT hijack this thread to troll/flame. >> >> >> > allow them some fun too. >> >> >> >> >> >> Now, I find the number of problem reports regarding 9.0-RELEASE alarm= ing >> >> and I'm growing more and more fearful towards it. >> >> >> >> In the current state of things, I have *absolutely* no wish to run it= in >> >> production :( >> >> >> > Did you read deeply into the strategy behind the releases? If I rememb= er right, the odd numbers are a little bit more experimental compared to th= e even numbers. For myself, I try to stick with even numbers whenever possi= ble. If I install FreeBSD on a serious machine, I never use x.0. It must be= at least x.1. >> >> There's no such odd/even number policy with FreeBSD-- I think you're >> thinking of another OS ;) >> > maybe something got stuck in my head with the move from 4 to 5. 4 to 5 was SMP-related, and when the Project decided to move to time-based rather than feature-based releases -- pure coincidence that 5 was odd. > How easy was the move to 6 then? _Just_ before my time I'm afraid ;) > Independent of this, it is still true that there is always the older bran= ch available when a new one opens at .0. > >> You're right that x.0 is slightly more experimental in general though >> (by its nature, it must be). > > And has nothing to do with FreeBSD as such. > Exactly :) Chris From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 12:28:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BEFC106564A for ; Sun, 26 Feb 2012 12:28:33 +0000 (UTC) (envelope-from hm@hm.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [187.95.0.181]) by mx1.freebsd.org (Postfix) with ESMTP id CA4B78FC13 for ; Sun, 26 Feb 2012 12:28:32 +0000 (UTC) Received: from pop1.hm.net.br (pop1.hm.net.br [186.222.209.53]) by msrv.matik.com.br (8.14.5/8.14.5) with ESMTP id q1QCRwBp017674; Sun, 26 Feb 2012 09:27:58 -0300 (BRT) (envelope-from hm@hm.net.br) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at msrv.matik.com.br X-DKIM: OpenDKIM Filter v2.4.3 msrv.matik.com.br q1QCRwBp017674 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hm.net.br; s=racoon; t=1330259278; bh=XWEZ7WR75V3vBGn1bR8ZBUNInCobYH4KqzzJWIbxWjg=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=h5Z4E0zKrWTPL/Wjd0KVmkOXJTV2VIp0gb0pIvNK+19E0Lk0GCctaXdTOVzWYksxq GFtKlZNIkYk3GdssqZ4bckeNQmU+9795VWgaHPN7HTKQmKJ0YWkavU3itN7kWYnaqU i3SHPYrlm9DXAxLq2PZyYtJZAI2SovQaE+nQ65xg= Authentication-Results: msrv.matik.com.br; sender-id=pass header.from=hm@hm.net.br; spf=pass smtp.mfrom=hm@hm.net.br Message-ID: <4F4A254E.60200@hm.net.br> Date: Sun, 26 Feb 2012 09:27:58 -0300 From: H User-Agent: Mozilla/5.0 MIME-Version: 1.0 To: Erich Dollansky References: <4F46847D.4010908@my.gd> <201202261630.57372.erichfreebsdlist@ovitrap.com> <4F4A068B.2090807@hm.net.br> <201202261800.16269.erichfreebsdlist@ovitrap.com> In-Reply-To: <201202261800.16269.erichfreebsdlist@ovitrap.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL, BAYES_00, T_DKIM_INVALID, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2-hm_201202.c X-Spam-Checker-Version: SpamAssassin 3.3.2-hm_201202.c (2011-06-06) on msrv.matik.com.br Cc: Mark Felder , freebsd-stable@freebsd.org Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 12:28:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erich Dollansky wrote: > Hi, > > On Sunday 26 February 2012 17:16:43 H wrote: >> Erich Dollansky wrote: >>> >>> On Sunday 26 February 2012 15:55:17 H wrote: >>>> Mark Felder wrote: >>>> >>>> I mean certainly -RELEASE __is__ the production release >>> >>> there is not the production release here. There are always at >>> least two. >> >> whatever, the question is not the how many, it is the word BETA >> or PRE change to RELEASE and we should not turn this into some >> word-fiddling >> > it is just logic. 10 is currently ALPHA, 8.3 is currently BETA, > there might be soon a RC1 and the release. > this is going into the wrong direction and I should hold my peace but will say my piece this is about 9.0-RELEASE only and wishfully about future releases, not beta, rc or pre- -current or - -stable ... H >> important is maintain the understanding for that word, because >> there are lot of not_developer_people out > > What should developer do after no errors have been reported anymore > in an RC? I would suggest that they release their stuff. why do you ask? it is very easy to answer: nothing! it is release engineering who could establish a little bit more time between code-freeze and RELEASE as in practice we can see 2-3 month or so would be something reasonable >> >> what seems forgotten is what is here in the second part: >> >> http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/lessons-learned.html >> >> >> what developers understand, mean or think does not matter, the _user_ >> should be able to understand and believe in this word RELEASE, >> what IMO is pretty clear >> > Release means that developers either state the errors in the README > or believe that there are no known errors. It does not mean that > there are no more errors in there. > >> so please do not argument with me or anybody else, it is merely >> a pretty fair and neutral opinion about RELEASE meaning >> >> backed on what is stated on the page above, it seems to be the >> procedure, which eventually needs revision, because we humans >> always will fail somewhere > > You can do the same as I do. I run currently a 8.3 BETA. You can > encourage people to do so too to make it easier for the developers > to spot as many errors as possible before the release. > it is not about you and me it is about FreeBSD and the meaning, importance and reliability of - -RELEASE for all people the word -RELEASE is what encourage people :) > Still, FreeBSD has always at least one more release out there which > was hardened in real life. > > If then take into account that odd numbers are known to have a > higher risk of errors plus the fact that 9.0 was the first release > of the new branch, I do not see a need to change much to the > advantage except of putting more load onto the people who actually > make it happen. > > Erich - -- H -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9KJU4ACgkQvKVfg5xjCDzxXQCgoNRlf3pjOjQ2ZzjQBbFJtMby KEwAmwahSUftP5LT8EPei9Q7oZsc9ddE =GBIW -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 12:45:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46BDE1065678 for ; Sun, 26 Feb 2012 12:45:05 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 020B48FC13 for ; Sun, 26 Feb 2012 12:45:04 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S1dTL-0001fw-Hm for freebsd-stable@freebsd.org; Sun, 26 Feb 2012 13:45:03 +0100 Received: from np-19-75.prenet.pl ([np-19-75.prenet.pl]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 Feb 2012 13:45:03 +0100 Received: from jb.1234abcd by np-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 Feb 2012 13:45:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Date: Sun, 26 Feb 2012 12:42:55 +0000 (UTC) Lines: 24 Message-ID: References: <4F46847D.4010908@my.gd> <201202261630.57372.erichfreebsdlist@ovitrap.com> <4F4A068B.2090807@hm.net.br> <201202261800.16269.erichfreebsdlist@ovitrap.com> <4F4A254E.60200@hm.net.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; FreeBSD i386; rv:9.0.1) Gecko/20100101 Firefox/9.0.1) Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 12:45:05 -0000 H hm.net.br> writes: > ... > it is about FreeBSD and the meaning, importance and reliability of > -RELEASE for all people > ... > > Still, FreeBSD has always at least one more release out there which > > was hardened in real life. > > ... Hi, I think you have a point. There was a very interesting discussion on "FreeBSD and release engineering". http://lwn.net/Articles/478663/ There were some proposals made, but in my view this is the most important one. There are too many "production releases" - at present including versions 7.4, 8.2, and 9.0 . Cutting one would refocus devs and users on the remainig two, with obvious benefits to FreeBSD product. jb From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 13:08:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 590BA106566B for ; Sun, 26 Feb 2012 13:08:25 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id 11E768FC08 for ; Sun, 26 Feb 2012 13:08:24 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q1QD8E80007853; Sun, 26 Feb 2012 06:08:17 -0700 From: Erich Dollansky To: freebsd-stable@freebsd.org Date: Sun, 26 Feb 2012 20:08:13 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <4F46847D.4010908@my.gd> <4F4A254E.60200@hm.net.br> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202262008.13877.erichfreebsdlist@ovitrap.com> Cc: jb Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 13:08:25 -0000 Hi, On Sunday 26 February 2012 19:42:55 jb wrote: > H hm.net.br> writes: > > > ... > > it is about FreeBSD and the meaning, importance and reliability of > > -RELEASE for all people > > ... > > > Still, FreeBSD has always at least one more release out there which > > > was hardened in real life. > > > ... > > Hi, > I think you have a point. > > There was a very interesting discussion on "FreeBSD and release engineering". > http://lwn.net/Articles/478663/ > I will read soon. > There were some proposals made, but in my view this is the most important one. > There are too many "production releases" - at present including versions > 7.4, 8.2, and 9.0 . 7.4 will be gone soon. Normally when 8.3 goes out, 7.4 will go. > Cutting one would refocus devs and users on the remainig two, with obvious > benefits to FreeBSD product. Three is not normal. Shouldn't it have disappeared with 9.0? Two is normal. 7.4 will be maintained until February next year or so anyway. So, nothing was wasted here. Erich From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 13:40:13 2012 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 451CE1065670 for ; Sun, 26 Feb 2012 13:40:13 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id CD9878FC08 for ; Sun, 26 Feb 2012 13:40:12 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id CE3EF153437 for ; Sun, 26 Feb 2012 14:40:11 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1EWRywRE4m6 for ; Sun, 26 Feb 2012 14:40:11 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id 53698153435 for ; Sun, 26 Feb 2012 14:40:11 +0100 (CET) Message-ID: <4F4A3639.2080408@digiware.nl> Date: Sun, 26 Feb 2012 14:40:09 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "stable@freebsd.org" References: <201202250747.q1P7ldaJ005410@zfs.digiware.nl> In-Reply-To: <201202250747.q1P7ldaJ005410@zfs.digiware.nl> X-Forwarded-Message-Id: <201202250747.q1P7ldaJ005410@zfs.digiware.nl> Content-Type: multipart/mixed; boundary="------------090702000604050304040308" Cc: Subject: A problem with MAXPATHLEN on a back X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 13:40:13 -0000 This is a multi-part message in MIME format. --------------090702000604050304040308 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I'm running into this on a backup-backupserver. (8.2-STABLE #134: Wed Feb 1 15:05:59 CET 2012 amd64) Haven't checked which paths are too long. But is there any "easy" way out? Like making MAXPATHLEN 2048 and rebuilding locate. Or is that going to propagate and major impact all and everything. Regards, --WjW -------- Original Message -------- Rebuilding locate database: locate: integer out of +-MAXPATHLEN (1024): 1031 locate: integer out of +-MAXPATHLEN (1024): 1031 -- End of weekly output -- --------------090702000604050304040308 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" --------------090702000604050304040308-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 18:48:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17E3A106564A for ; Sun, 26 Feb 2012 18:48:48 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8C8168FC0A for ; Sun, 26 Feb 2012 18:48:46 +0000 (UTC) Received: by werl4 with SMTP id l4so239008wer.13 for ; Sun, 26 Feb 2012 10:48:45 -0800 (PST) Received-SPF: pass (google.com: domain of kob6558@gmail.com designates 10.180.99.7 as permitted sender) client-ip=10.180.99.7; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kob6558@gmail.com designates 10.180.99.7 as permitted sender) smtp.mail=kob6558@gmail.com; dkim=pass header.i=kob6558@gmail.com Received: from mr.google.com ([10.180.99.7]) by 10.180.99.7 with SMTP id em7mr21665557wib.7.1330282125675 (num_hops = 1); Sun, 26 Feb 2012 10:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0UYRrPNN+iUZbhKq3xi5h0g1ajYK2/yEY4CYKcFvNdA=; b=s0i+m4OW+mAM4uxE1l7qHWYpa064ys1g0cW8J6BxdDcN143OndSlMLt5O2fDksmxfw uzpH8M4PbjC4w9NzCDjMnF6o+z/j3XvYEnvooEvslga191iau3xn0vhr7OIotU1mw1B+ NJmyqaSlTGO08UjVgq7YkxEIHrhpwD9MndJ0U= MIME-Version: 1.0 Received: by 10.180.99.7 with SMTP id em7mr17273693wib.7.1330282125574; Sun, 26 Feb 2012 10:48:45 -0800 (PST) Received: by 10.223.16.82 with HTTP; Sun, 26 Feb 2012 10:48:45 -0800 (PST) In-Reply-To: <20120226203949.H89643@sola.nimnet.asn.au> References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> Date: Sun, 26 Feb 2012 10:48:45 -0800 Message-ID: From: Kevin Oberman To: Ian Smith Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vermaden , freebsd-stable@freebsd.org, lars.engels@0x20.net, Hans Petter Selasky Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 18:48:48 -0000 On Sun, Feb 26, 2012 at 2:18 AM, Ian Smith wrote: > Ccs mightily trimmed to avoid not-subscribed bounces; readd as desired: > > On Mon, 20 Feb 2012 09:43:59 +0100, vermaden wrote: > =A0> To: freebsd-hackers@freebsd.org > =A0> Cc: matt , gleb.kurtsou@gmail.com, > =A0> =A0 =A0 freebsd-stable@freebsd.org, uffe@uffe.org, joe.culler@gmail.= com, > =A0> =A0 =A0 Hans Petter Selasky , freebsd-current@free= bsd.org, > =A0> =A0 =A0 lars.engels@0x20.net > =A0> > =A0> Hi, > =A0> > =A0> new version with new features (and BUGs ;p) > [..] > > Well, I was busy composing this reply a few days ago when this system > was taken out by a very near lightning strike .. losing the ADSL modem > (blown into 4 pieces scattered about the room :), 2 scorched switches, > the old xe pccard interface feeding the ADSL (its dongle also blown into > several pieces), and a good deal of travelling - I was 80km remote at > the time - but very fortunately not the server box itself .. close call! Wow! Glad you were 80 km away. At least you were not blown into 4 pieces! > =A0> Added 'noatime' as a default mount option when possible. > > Good idea for many use cases, but could that be optional? Please make this optional. I have one volume where I depend on atime for regular operations. Of course, I can deal with this myself, but atime is default for a reason, even though its overhead and frequent lack of use makes me question that, as well. > [..] > =A0> Added config file to be used from /usr/local/etc/automount.conf file= , possible options are (these are defaults): > =A0> =A0 MNTPREFIX=3D"/media" > =A0> =A0 LOG=3D"/var/log/automount.log" > =A0> =A0 STATE=3D"/var/run/automount.state" > =A0> =A0 ENCODING=3D"en_US.ISO8859-1" > =A0> =A0 CODEPAGE=3D"cp437" > =A0> =A0 DATEFMT=3D"%Y-%m-%d %H:%M:%S" > =A0> =A0 USERUMOUNT=3D"NO" > =A0> > =A0> Mine config currently has only these: > =A0> =A0 ENCODING=3D"pl_PL.ISO8859-2" > =A0> =A0 CODEPAGE=3D"cp852" > =A0> =A0 USERUMOUNT=3D"YES" > =A0> > =A0> The USERMOUNT otions if set to YES (default to NO) will 'chmod +s /s= bin/umount', > =A0> so You can click the ^ button on the devices list in NAUTILUS. > > Someone might explain why I needn't feel a bit uncomfortable about that > chmod, even though it is optional, and even though I've been guilty > myself of a 'chown root:nobody /sbin/tc' on a linux firewall box .. policykit does the same sort of thing in gnome, but it is VERY fine grained. It can limit unmounting to certain devices while this give any user the ability to do `umount \usr'. Rather frightening as a default. Of course, most desktop systems are single user. And it is only efective if the system has USERMOUNT enabled. > > =A0> These newly mounted devices appear on NAUTILUS sidebar (only with /m= edia prefix). > > I wonder how it goes with KDE4? (still 3.5 here, which wouldn't count) > > [..] > =A0> /usr/local/sbin/automount.sh > =A0> --------------------------------------------------------------------= ----------- > [..] > =A0> [ "${USERUMOUNT}" =3D "YES" ] && chmod u+s /sbin/umount # /* WHEEL g= roup member */ > =A0> > =A0> __create_mount_point() { # /* 1=3DDEV */ > =A0> =A0 MNT=3D"${MNTPREFIX}/$( basename ${1} )" > =A0> =A0 mkdir -p ${MNT} > =A0> =A0 chown 1000 ${MNT} > =A0> } > > Er, who's user 1000 ? =A0Another config item perhaps? =A0Or should that b= e > the particular user currently invoking the script via devd (if that can > be determined?)? =A0Also, are you using sysctl vfs.usermount=3D1 ? > > =A0> case ${2} in > =A0> =A0 (attach) > =A0> =A0 =A0 for I in /dev/${1}* > =A0> =A0 =A0 do > [..] > =A0> =A0 =A0 =A0 =A0 (*Unix\ Fast\ File*) > =A0> =A0 =A0 =A0 =A0 =A0 __create_mount_point ${I} > =A0> =A0 =A0 =A0 =A0 =A0 fsck_ufs -y ${I} > > Mmm, fsck on every attachment? =A0Maybe running fsck should be optional? > We might be attaching, perhaps, a 2TB backup HD? .. Ouch! I agree. Why not just fsck_ufs -p. (I realize this is done to fix systems that were unplugged rather than umounted, but it's a pretty expensive operation when not needed. > > =A0> =A0 =A0 =A0 =A0 =A0 __check_already_mounted ${MNT} > =A0> =A0 =A0 =A0 =A0 =A0 mount -o noatime ${I} ${MNT} > > Again, I'd rather see that optional in an intended system tool, although > it's an option I'd tend to use myself. > > =A0> =A0 =A0 =A0 =A0 =A0 __log "${I}:mount (ufs)" > =A0> =A0 =A0 =A0 =A0 =A0 ;; > [..] > =A0> =A0 (detach) > =A0> =A0 =A0 MOUNT=3D$( mount ) > =A0> =A0 =A0 __state_lock > =A0> =A0 =A0 grep ${1} ${STATE} \ > =A0> =A0 =A0 =A0 | while read DEV PROVIDER MNT > =A0> =A0 =A0 =A0 =A0 do > =A0> =A0 =A0 =A0 =A0 =A0 TARGET=3D$( echo "${MOUNT}" | grep -E "^${PROVID= ER} " | awk '{print $3}' ) > =A0> =A0 =A0 =A0 =A0 =A0 [ -z ${TARGET} ] && { > =A0> =A0 =A0 =A0 =A0 =A0 =A0 __state_remove ${MNT} ${STATE} ${LINE} > =A0> =A0 =A0 =A0 =A0 =A0 =A0 continue > =A0> =A0 =A0 =A0 =A0 =A0 } > =A0> =A0 =A0 =A0 =A0 =A0 umount -f ${TARGET} & > =A0> =A0 =A0 =A0 =A0 =A0 unset TARGET > =A0> =A0 =A0 =A0 =A0 =A0 __state_remove ${MNT} ${STATE} ${LINE} > =A0> =A0 =A0 =A0 =A0 =A0 __log "${DEV}:umount" > =A0> =A0 =A0 =A0 =A0 done > =A0> =A0 =A0 __state_unlock > =A0> =A0 =A0 __log "/dev/${1}:detach" > =A0> =A0 =A0 find ${MNTPREFIX} -type d -empty -delete > > I don't see the need to remove all empty subdirs of, say, /media - this > tool may not be the only thing wanting to manage that space? =A0Removing > directories that were added by this tool itself makes sense of course. This is an interesting one. Gnome and hald have a problem here that have caused me to add sudo /bin/rmdir /media/* to.xinitrc to work around. It's just too easy for 'junk' directories to live on when the system does not exit everything cleanly and, while hald tries to keep track, it is very hard to do in the real world. I suspect it is really needed. And what else is creating directories in /media? -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 19:51:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B26441065674 for ; Sun, 26 Feb 2012 19:51:17 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8EAA38FC15 for ; Sun, 26 Feb 2012 19:51:17 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 30E1656236; Sun, 26 Feb 2012 13:43:31 -0600 (CST) Date: Sun, 26 Feb 2012 13:43:31 -0600 From: Mark Linimon To: Erich Dollansky Message-ID: <20120226194331.GC31385@lonesome.com> References: <4F46847D.4010908@my.gd> <201202240835.32041.erichfreebsdlist@ovitrap.com> <201202261832.17793.erichfreebsdlist@ovitrap.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201202261832.17793.erichfreebsdlist@ovitrap.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Chris Rees , freebsd-stable@freebsd.org Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 19:51:17 -0000 On Sun, Feb 26, 2012 at 06:32:17PM +0700, Erich Dollansky wrote: > > There's no such odd/even number policy with FreeBSD-- I think you're > > thinking of another OS ;) > > > maybe something got stuck in my head with the move from 4 to 5. Yes, 5 was the Great Leap where true SMP was introduced. In the many-year-long development cycle, so many other things (IIRC geom and suspend/resume, among others) that the change from 4 to 5 was completely disruptive. We resolved to release more often so as to never be in that situation again. (Granted, probably no architectural change will ever be that sweeping again.) There is no meaning to odd/even release numbering in FreeBSD. > How easy was the move to 6 then? An order of magnitude easier than the move to 5. Although as needs to happen with each major release, some code that had been deprecated was dropped, and some subsystems which no one stepped up to do the maintenance necessary for other re-architecting were dropped as well. Each of the subsequent moves has been much the same -- a few gotchas, but nothing like the move to 5. This has been purely intentional. mcl From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 19:53:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F259F1065673 for ; Sun, 26 Feb 2012 19:53:01 +0000 (UTC) (envelope-from kob6558@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 BD8C28FC0C for ; Sun, 26 Feb 2012 19:53:01 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so4864391pbc.13 for ; Sun, 26 Feb 2012 11:53:01 -0800 (PST) Received-SPF: pass (google.com: domain of kob6558@gmail.com designates 10.68.218.228 as permitted sender) client-ip=10.68.218.228; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kob6558@gmail.com designates 10.68.218.228 as permitted sender) smtp.mail=kob6558@gmail.com; dkim=pass header.i=kob6558@gmail.com Received: from mr.google.com ([10.68.218.228]) by 10.68.218.228 with SMTP id pj4mr32355261pbc.167.1330285981523 (num_hops = 1); Sun, 26 Feb 2012 11:53:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xK0PAoBXFOPgiHTBFzu13T0FpYYOe90Ho2l0zcc0wZk=; b=eboColPyTqOnQfIiPjB8JT9UflH/Ie/yuFie+XN4zpjjz9HzS2I5oagdj7XnIMUt2f M6kISGhvu6sjfAjcZjZZji1yV4ePU9yhScNa29Eg5v0iytzYup7w11NRYJyZQMp13/iJ SEIX2Pu9gYnld4iOX47g+676w1NEe4PBVVc8k= MIME-Version: 1.0 Received: by 10.68.218.228 with SMTP id pj4mr27573827pbc.167.1330285981299; Sun, 26 Feb 2012 11:53:01 -0800 (PST) Received: by 10.68.44.100 with HTTP; Sun, 26 Feb 2012 11:53:01 -0800 (PST) In-Reply-To: <201202262008.13877.erichfreebsdlist@ovitrap.com> References: <4F46847D.4010908@my.gd> <4F4A254E.60200@hm.net.br> <201202262008.13877.erichfreebsdlist@ovitrap.com> Date: Sun, 26 Feb 2012 11:53:01 -0800 Message-ID: From: Kevin Oberman To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: jb , freebsd-stable@freebsd.org Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 19:53:02 -0000 On Sun, Feb 26, 2012 at 5:08 AM, Erich Dollansky wrote: > Hi, > > On Sunday 26 February 2012 19:42:55 jb wrote: >> H hm.net.br> writes: >> >> > ... >> > it is about FreeBSD and the meaning, importance and reliability =A0of >> > -RELEASE for all people >> > ... >> > > Still, FreeBSD has always at least one more release out there which >> > > was hardened in real life. >> > > ... >> >> Hi, >> I think you have a point. >> >> There was a very interesting discussion on "FreeBSD and release engineer= ing". >> http://lwn.net/Articles/478663/ >> > I will read soon. > >> There were some proposals made, but in my view this is the most importan= t one. >> There are too many "production releases" - at present including versions >> 7.4, 8.2, and 9.0 . > > 7.4 will be gone soon. Normally when 8.3 goes out, 7.4 will go. > >> Cutting one would refocus devs and users on the remainig two, with obvio= us >> benefits to FreeBSD product. > > Three is not normal. Shouldn't it have disappeared with 9.0? Two is norma= l. 7.4 will be maintained until February next year or so anyway. So, nothin= g was wasted here. OK. As someone who has been running FreeBSD for a while (though I am not an old-timer as I never ran V2), I can tell you that 5 to 6 was a very smooth upgrade from a fairly broken version (5 had a huge number of serious issues that could not be fixed without ABI changes) to a pretty good release that, because it came fairly close to 5.2 (the first production release of 5), it was still mostly fixes and not new features. .0 releases of any large project where version bumps are really significant are always something to use in production only with great care. This has been true for years and for almost all operating systems. It was true with VMS, RSX-11M, IOS (the Cisco one, not the Apple one), JunOS (Juniper's router OS), Linux distributions and, until 3.0, Linux kernels. Recently more and more products have moved from the traditional model where major version bumps meant major changes, so this is not true with Firefox, Chrome, Linux kernels, etc., but it is still true for FreeBSD. And that means that there is a real .0 that will only get significantly broad use after a release. Staying in BETA for long intervals leaves important features from getting to a large number of users, so RE has to draw a line somewhere and say, "We are doing a release". It is now more or less time based, but it is still when ABIs and APIs can change which is the key to getting new features out to a broad audience. It simply as to be done. No one really likes it, but no one has come up with a better way. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 19:56:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CB36106566B for ; Sun, 26 Feb 2012 19:56:17 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 692BC8FC13 for ; Sun, 26 Feb 2012 19:56:17 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 84A8E5620E; Sun, 26 Feb 2012 13:38:16 -0600 (CST) Date: Sun, 26 Feb 2012 13:38:16 -0600 From: Mark Linimon To: H Message-ID: <20120226193816.GB31385@lonesome.com> References: <4F46847D.4010908@my.gd> <201202261630.57372.erichfreebsdlist@ovitrap.com> <4F4A068B.2090807@hm.net.br> <201202261800.16269.erichfreebsdlist@ovitrap.com> <4F4A254E.60200@hm.net.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F4A254E.60200@hm.net.br> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Erich Dollansky , Mark Felder , freebsd-stable@freebsd.org Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 19:56:17 -0000 On Sun, Feb 26, 2012 at 09:27:58AM -0300, H wrote: > it is release engineering who could establish a little bit more time > between code-freeze and RELEASE As you will see from the (very) long discussion that you are about to read, there has to be a compromise. As it was, the release process was too long, not too short. Yes, we would like to get more testers pre-release, but that seems to be more easily said than done. Ideas appreciated. You will also see in the thread that: - it is not possible to release bug-free code, and in fact - it is not possible to release code with no regressions whatsoever if you are to ever release anything at all. To summarize: yes, we do care: and yes, these are classical software engineering problems that can only be dealt with, not solved completely. mcl From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 20:03:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EC97106564A; Sun, 26 Feb 2012 20:03:10 +0000 (UTC) (envelope-from kob6558@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 1C5368FC0A; Sun, 26 Feb 2012 20:03:10 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so4870286pbc.13 for ; Sun, 26 Feb 2012 12:03:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zfDKCHrnBhjbz4UvuKrHzgUoG4NUX5pK31K6WNFrxoI=; b=A9akmUfs1SM/fp4gnRCnD9wm0+1BxYOOqI6L6/PNE32YVQHqKqX8SzCBklwuKxHoy9 3bhMs0Ky/5yud+yITau4dIiz+HqZIm9ci7UZSlvN8HgKmEFjlBnxTcho3H1uNPfQgTEn SpbA9Ub+oNlxHTLritexAYNDtItpaF+Ui1SK8= MIME-Version: 1.0 Received: by 10.68.230.170 with SMTP id sz10mr27346028pbc.62.1330286589748; Sun, 26 Feb 2012 12:03:09 -0800 (PST) Received: by 10.68.44.100 with HTTP; Sun, 26 Feb 2012 12:03:09 -0800 (PST) In-Reply-To: <20120226194331.GC31385@lonesome.com> References: <4F46847D.4010908@my.gd> <201202240835.32041.erichfreebsdlist@ovitrap.com> <201202261832.17793.erichfreebsdlist@ovitrap.com> <20120226194331.GC31385@lonesome.com> Date: Sun, 26 Feb 2012 12:03:09 -0800 Message-ID: From: Kevin Oberman To: Mark Linimon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Erich Dollansky , Chris Rees , freebsd-stable@freebsd.org Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 20:03:10 -0000 On Sun, Feb 26, 2012 at 11:43 AM, Mark Linimon wrote= : > On Sun, Feb 26, 2012 at 06:32:17PM +0700, Erich Dollansky wrote: >> > There's no such odd/even number policy with FreeBSD-- I think you're >> > thinking of another OS ;) >> > >> maybe something got stuck in my head with the move from 4 to 5. > > Yes, 5 was the Great Leap where true SMP was introduced. =A0In the > many-year-long development cycle, so many other things (IIRC geom > and suspend/resume, among others) that the change from 4 to 5 was > completely disruptive. =A0We resolved to release more often so as to > never be in that situation again. =A0(Granted, probably no architectural > change will ever be that sweeping again.) Minor correction. Suspend/resume was around in late 3 and 4, though the Nomad code in 3 was a bit unstable. It worked well in 4, but was dependent on APM which was already being replaced by ACPI. By the time 5.2 was actually released, many systems were being shipped without APM, so could not run FreeBSD. (APM was fairly optional, but ACPI systems really need ACPI support.) ACPI was one of several things that forced 5.0 to be released even though RE and everyone running current knew it had big problems. It i also why 5.0 and 5.1 were clearly marked as "development" releases not for production. I really hope to never see a release as ugly as 5. 9.0 may have issues as did 7.0 and 8.0, but for most, it works quite well. I m happily running it on a couple of systems. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 22:54:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5E29106566C for ; Sun, 26 Feb 2012 22:54:45 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 62BF78FC08 for ; Sun, 26 Feb 2012 22:54:45 +0000 (UTC) Received: by werl4 with SMTP id l4so322570wer.13 for ; Sun, 26 Feb 2012 14:54:44 -0800 (PST) Received-SPF: pass (google.com: domain of ml@my.gd designates 10.180.24.166 as permitted sender) client-ip=10.180.24.166; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ml@my.gd designates 10.180.24.166 as permitted sender) smtp.mail=ml@my.gd Received: from mr.google.com ([10.180.24.166]) by 10.180.24.166 with SMTP id v6mr13292080wif.10.1330296884640 (num_hops = 1); Sun, 26 Feb 2012 14:54:44 -0800 (PST) Received: by 10.180.24.166 with SMTP id v6mr10510022wif.10.1330296884563; Sun, 26 Feb 2012 14:54:44 -0800 (PST) Received: from [192.168.0.12] (did75-17-88-165-130-96.fbx.proxad.net. [88.165.130.96]) by mx.google.com with ESMTPS id gd8sm18127498wib.2.2012.02.26.14.54.42 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 26 Feb 2012 14:54:43 -0800 (PST) References: <201202251717.q1PHHeXD024464@mp.cs.niu.edu> <201202261106.19487.erichfreebsdlist@ovitrap.com> In-Reply-To: <201202261106.19487.erichfreebsdlist@ovitrap.com> Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8J2) From: Damien Fleuriot Date: Sun, 26 Feb 2012 23:53:59 +0100 To: Erich Dollansky X-Gm-Message-State: ALoCoQkkarSBnRdjTurQiOqmx4sIFRNyk2aSizBqndZcfFQM4O+K1Br9fG3PGRwUsYAkxy5rKPF4 Cc: Scott Bennett , "freebsd-stable@freebsd.org" Subject: Re: random problem with 8.3 from yesterday X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 22:54:45 -0000 On 26 Feb 2012, at 05:06, Erich Dollansky wro= te: > Hi, >=20 > On Sunday 26 February 2012 00:55:46 Kevin Oberman wrote: >=20 >> I thought he was creating a "monolithic" device...what was called >> "dangerously dedicated". No slices at all. Not only are DD volumes >=20 > yes, I remember this term. And Windows machines get confused but they do n= ot damage the media. >=20 >> mountable, they are bootable. It's been years since I created a DD >> disk as the slight space savings are irrelevant on modern hundreds of >> gigabyte disks, so I may have forgotten how it works. It might still >> make sense on a small thumb drive, bootable or not. >=20 > Never break a winning team. The script doing the job works since a long ti= me. This is the simple reason behind. >=20 Ok so since nobody mentioned it, does the problem happen for ALL your media h= andled in the same fashion, or just the one drive ? What I'm saying is don't blame the software so readily when it might be hard= ware. Get a SMART report on your disk. Also try with another media.= From owner-freebsd-stable@FreeBSD.ORG Sun Feb 26 22:58:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D9011065675 for ; Sun, 26 Feb 2012 22:58:31 +0000 (UTC) (envelope-from garrett.groesbeck@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 D25208FC0C for ; Sun, 26 Feb 2012 22:58:30 +0000 (UTC) Received: by qao25 with SMTP id 25so1179810qao.13 for ; Sun, 26 Feb 2012 14:58:30 -0800 (PST) Received-SPF: pass (google.com: domain of garrett.groesbeck@gmail.com designates 10.224.30.206 as permitted sender) client-ip=10.224.30.206; Authentication-Results: mr.google.com; spf=pass (google.com: domain of garrett.groesbeck@gmail.com designates 10.224.30.206 as permitted sender) smtp.mail=garrett.groesbeck@gmail.com; dkim=pass header.i=garrett.groesbeck@gmail.com Received: from mr.google.com ([10.224.30.206]) by 10.224.30.206 with SMTP id v14mr8871273qac.18.1330297110316 (num_hops = 1); Sun, 26 Feb 2012 14:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=cLvDJ53v972S8bJNhvV3TnxvV+lUaZ+IcP/31F66z4s=; b=aziUGakwC+C6hrO0AASXCSeDoC7fktqpmCXDkalIlqL8o/aPQEkiR/zLQ8y8Q8mUro DtqexDWDkv1C8MCXrk/QBZ2sGf9eRGD1VHk/nm9lrOt+eU/ya3AgonXpl3g4zLaNO1pH pQd/qiWWm3viOuUm4DjxFoVfW1emSQYPy0Yf0= Received: by 10.224.30.206 with SMTP id v14mr7446057qac.18.1330295500589; Sun, 26 Feb 2012 14:31:40 -0800 (PST) Received: from bighouse (c-68-81-175-174.hsd1.pa.comcast.net. [68.81.175.174]) by mx.google.com with ESMTPS id bf2sm32066481qab.20.2012.02.26.14.31.39 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 26 Feb 2012 14:31:39 -0800 (PST) From: "Garrett R. Groesbeck" To: Date: Sun, 26 Feb 2012 17:31:35 -0500 Message-ID: <000001ccf4d6$66513b00$32f3b100$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acz01mVTxvIq91kaQ9GE+8Wycy8r6A== Content-Language: en-us Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD 9.0-RELEASE - Trouble Booting on SPARC64 - kmem_suballoc error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Feb 2012 22:58:31 -0000 Hello, I hope you are well. I've been working on a Sun Blade 2000 with FreeBSD 9.0 (sparc64) installed. There's trouble with /boot/loader.conf when you try to boot the install disc (and even after the install when I try to boot up): panic: kmem_suballoc: bad status return of 3 cpuid = 0 KDB: stack backtrace: #0 0xc079841c at ??+0 #1 0xc04ca59c at ??+0 #2 0xc0487f90 at ??+0 #3 0xc0098028 at ??+0 So when it gives me the chance to enter a boot command, I enter the following: OK set hw.physmem=1048576000 OK boot That seems to do the trick. And I've since added it to loader.conf so I don't have to enter the command each time I boot up. Please let me know if there's anything I can do as I'd like my machine to be able to utilize the full memory capabilities. Thank you, Garrett Groesbeck garrett.groesbeck@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 07:19:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 752C6106564A for ; Mon, 27 Feb 2012 07:19:07 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id DED2D8FC18 for ; Mon, 27 Feb 2012 07:19:06 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7fc]) by elf.hq.norma.perm.ru (8.14.4/8.14.4) with ESMTP id q1R57F34005208 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 27 Feb 2012 10:07:32 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4F4B0F83.4090600@norma.perm.ru> Date: Mon, 27 Feb 2012 11:07:15 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20111001 Thunderbird/7.0 MIME-Version: 1.0 To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Mon, 27 Feb 2012 10:07:32 +0500 (YEKT) X-Spam-Status: No hits=-98.5 bayes=0.5 testhits RDNS_NONE=0.793, SPF_SOFTFAIL=0.665,USER_IN_WHITELIST=-100 autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Subject: zfs, 1 gig of RAM and periodic weekly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 07:19:07 -0000 Hi. I'm haunted by a weird bug. Some of my servers (IBM x3250) hang periodically. And this is always saturday morning. Different servers in different cities, all with zfs and one gig of RAM. And yeah, it's periodic weekly. I can say more - it's repeatable. 25 minutes ago I typed 'periodic weekly', and 5 minutes ago I lost this machine from the network (even stopped answering to ICMP). This can be solved by any of two methods - either increase RAM, or turning off periodic weekly. loader.conf (doesn't help): zfs_load="YES" vfs.root.mountfrom="zfs:zfsroot" ng_iface_load="YES" ng_ether_load="YES" vm.kmem_size="330M" vm.kmem_size_max="330M" vfs.zfs.arc_max="30M" This is 8.2-RELEASE/amd64. The most important question - what to report and how to report this ? Thanks. Eugene. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 07:39:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96AF41065672 for ; Mon, 27 Feb 2012 07:39:23 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 5B3D88FC16 for ; Mon, 27 Feb 2012 07:39:23 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id A7E2B6F272 for ; Mon, 27 Feb 2012 07:39:21 +0000 (UTC) From: Stefan Bethke Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Feb 2012 08:39:20 +0100 Message-Id: To: "freebsd-stable@freebsd.org List" Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: panic: GPF in kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 07:39:23 -0000 Setting up new hardware (i5 CPU, 16 GB RAM) and doing a burn-in test = running make buildworld in a loop. After a couple of hours, I got this = panic. 8-stable is from January, ZFS root. Does this correlate with any recently fixed bugs, or is this likely a = hardware issue? # uname -a FreeBSD dhcp62.lassitu.de 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Feb 24 = 23:22:57 UTC 2012 = root@dhcp62.lassitu.de:/usr/obj/freebsd/checkout/src/sys/EISENBOOT = amd64 Fatal trap 9: general protection fault while in kernel mode cpuid =3D 3; apic id =3D 06 instruction pointer =3D 0x20:0xffffffff805460c5 stack pointer =3D 0x28:0xffffff84830119d0 frame pointer =3D 0x28:0xffffff8483011a60 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, resume, IOPL =3D 0 current process =3D 38198 (cc1) trap number =3D 9 panic: general protection fault cpuid =3D 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 trap_fatal() at trap_fatal+0x290 trap() at trap+0x180 calltrap() at calltrap+0x8 --- trap 0x9, rip =3D 0xffffffff805460c5, rsp =3D 0xffffff84830119d0, = rbp =3D 0xffffff8483011a60 --- pmap_remove_pages() at pmap_remove_pages+0x275 vmspace_exit() at vmspace_exit+0x9a exit1() at exit1+0x3b3 sys_exit() at sys_exit+0xe amd64_syscall() at amd64_syscall+0x24f Xfast_syscall() at Xfast_syscall+0xfc --- syscall (1, FreeBSD ELF64, sys_exit), rip =3D 0x84ba3c, rsp =3D = 0x7fffffffdf68, rbp =3D 0x7fffffffdfa0 --- (kgdb) bt #0 doadump () at /freebsd/checkout/src/sys/kern/kern_shutdown.c:263 #1 0xffffffff802eab00 in boot (howto=3D260) at /freebsd/checkout/src/sys/kern/kern_shutdown.c:441 #2 0xffffffff802eafa1 in panic (fmt=3DVariable "fmt" is not available. ) at /freebsd/checkout/src/sys/kern/kern_shutdown.c:614 #3 0xffffffff8054dc80 in trap_fatal (frame=3D0x9, eva=3DVariable "eva" = is not available. ) at /freebsd/checkout/src/sys/amd64/amd64/trap.c:825 #4 0xffffffff8054e2a0 in trap (frame=3D0xffffff8483011920) at /freebsd/checkout/src/sys/amd64/amd64/trap.c:621 #5 0xffffffff80534cb8 in calltrap () at /freebsd/checkout/src/sys/amd64/amd64/exception.S:228 #6 0xffffffff805460c5 in pmap_remove_pages (pmap=3D0xffffff01982838d8) at /freebsd/checkout/src/sys/amd64/amd64/pmap.c:4087 #7 0xffffffff8051a61a in vmspace_exit (td=3D0xffffff017efca8a0) at /freebsd/checkout/src/sys/vm/vm_map.c:405 #8 0xffffffff802b93d3 in exit1 (td=3D0xffffff017efca8a0, rv=3DVariable = "rv" is not available. ) at /freebsd/checkout/src/sys/kern/kern_exit.c:298 #9 0xffffffff802ba61e in sys_exit (td=3DVariable "td" is not available. ) at /freebsd/checkout/src/sys/kern/kern_exit.c:106 #10 0xffffffff8054d1ff in amd64_syscall (td=3D0xffffff017efca8a0, = traced=3D0) at subr_syscall.c:114 #11 0xffffffff80534fac in Xfast_syscall () at /freebsd/checkout/src/sys/amd64/amd64/exception.S:387 #12 0x000000000084ba3c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb)=20 --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 07:40:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A26A106568D for ; Mon, 27 Feb 2012 07:40:35 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 976F58FC23 for ; Mon, 27 Feb 2012 07:40:34 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MZ9Wi-1RjIuz0wUW-00Ktid; Mon, 27 Feb 2012 08:40:33 +0100 Message-ID: <4F4B3370.7020302@brockmann-consult.de> Date: Mon, 27 Feb 2012 08:40:32 +0100 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F4B0F83.4090600@norma.perm.ru> In-Reply-To: <4F4B0F83.4090600@norma.perm.ru> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:+yDMWWpxzaevNY2ymi2409l9LDZp6p+bnZJScEyWJCf v//ThD7oXlLHDrPfZdqdjod+F8w9p/tK7OBj4DQsvEU9bATJ05 jsFPiuLqf2rNYaIXWd/aIGSFPxfA9mujMsKDafG1hK0JbYLPUt 9o/jEcT7oC6STWNcwy4R8HbGmn3sEt01yRwBSLvO5oZjtSNf4B 6C29mfWMlbwGEbMkI4s1HFcbuNMLdr11eqTVAreErt1XXGFVfj rRGpzhEvP/WBogcOIebD/wDSPJgbY/WI6ioFscnVfpnbeukuBF xku2Z3oITUgEqbfI9IGm/IKEd0J/yoyEDRwUr7M0Yf2z5eVIoZ UYtv4A0S179whDY/Db4lOZ+8NmWzonCZhpcXTlXa5 Subject: Re: zfs, 1 gig of RAM and periodic weekly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 07:40:35 -0000 On 02/27/2012 06:07 AM, Eugene M. Zheganin wrote: > Hi. > > I'm haunted by a weird bug. > Some of my servers (IBM x3250) hang periodically. And this is always > saturday morning. Different servers in different cities, all with zfs > and one gig of RAM. And yeah, it's periodic weekly. I can say more - > it's repeatable. 25 minutes ago I typed 'periodic weekly', and 5 > minutes ago I lost this machine from the network (even stopped > answering to ICMP). This can be solved by any of two methods - either > increase RAM, or turning off periodic weekly. > > loader.conf (doesn't help): > > zfs_load="YES" > vfs.root.mountfrom="zfs:zfsroot" > ng_iface_load="YES" > ng_ether_load="YES" > vm.kmem_size="330M" > vm.kmem_size_max="330M" > vfs.zfs.arc_max="30M" > > This is 8.2-RELEASE/amd64. 8.2-RELEASE is highly unstable with ZFS in my opinion. For example, my system with 48 GB of RAM would hang or crash for no apparent reason in random intervals. Upgrading in September fixed most of it, except 1 random hang possibly related to NFS, and a hang when renaming snapshots with zvols [new problem after 8.2-RELEASE, PR 161968]. The renaming snapshot with zvols hang seems fixed since update again in February. Still unresolved though is that restarting nfsd makes nfsd hang until reboot. I don't know if 8.2-RELEASE had that problem. You should consider an update with csup. Make sure you test and monitor after the upgrade, in case some other funny issues come up, like my restarting nfsd issue. But of course I chose that over random hangs and panics. And one word of advice: If you want to upgrade your pools to v28, I think you should consider recreating your pools as v28 rather than upgrading. There are some side effects to upgrading, such as logs that can't be removed. > > The most important question - what to report and how to report this ? > > Thanks. > Eugene. > _______________________________________________ > 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" -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 08:20:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61A77106564A for ; Mon, 27 Feb 2012 08:20:58 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 108BB8FC0C for ; Mon, 27 Feb 2012 08:20:57 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7fc]) by elf.hq.norma.perm.ru (8.14.4/8.14.4) with ESMTP id q1R8KfBE027803 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 27 Feb 2012 13:20:49 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4F4B3CD9.9060704@norma.perm.ru> Date: Mon, 27 Feb 2012 14:20:41 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20111001 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F4B0F83.4090600@norma.perm.ru> <4F4B3370.7020302@brockmann-consult.de> In-Reply-To: <4F4B3370.7020302@brockmann-consult.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Mon, 27 Feb 2012 13:20:49 +0500 (YEKT) X-Spam-Status: No hits=-98.5 bayes=0.5 testhits RDNS_NONE=0.793, SPF_SOFTFAIL=0.665,TO_NO_BRKTS_NORDNS=0.001,USER_IN_WHITELIST=-100 autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Subject: Re: zfs, 1 gig of RAM and periodic weekly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 08:20:58 -0000 Hi. On 27.02.2012 13:40, Peter Maloney wrote: > 8.2-RELEASE is highly unstable with ZFS in my opinion. For example, my > system with 48 GB of RAM would hang or crash for no apparent reason in > random intervals. Upgrading in September fixed most of it, except 1 > random hang possibly related to NFS, and a hang when renaming snapshots > with zvols [new problem after 8.2-RELEASE, PR 161968]. The renaming > snapshot with zvols hang seems fixed since update again in February. > > Still unresolved though is that restarting nfsd makes nfsd hang until > reboot. I don't know if 8.2-RELEASE had that problem. > > You should consider an update with csup. Make sure you test and monitor > after the upgrade, in case some other funny issues come up, like my > restarting nfsd issue. But of course I chose that over random hangs and > panics. > > And one word of advice: If you want to upgrade your pools to v28, I > think you should consider recreating your pools as v28 rather than > upgrading. There are some side effects to upgrading, such as logs that > can't be removed. Well... I upgraded one machine and got kern/164400 immidiately. So it looks like I'm stuck. Eugene. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 09:13:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2F441065670 for ; Mon, 27 Feb 2012 09:13:09 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 594048FC0C for ; Mon, 27 Feb 2012 09:13:09 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so1042826bkc.13 for ; Mon, 27 Feb 2012 01:13:08 -0800 (PST) Received-SPF: pass (google.com: domain of ml@my.gd designates 10.204.154.211 as permitted sender) client-ip=10.204.154.211; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ml@my.gd designates 10.204.154.211 as permitted sender) smtp.mail=ml@my.gd Received: from mr.google.com ([10.204.154.211]) by 10.204.154.211 with SMTP id p19mr6416776bkw.130.1330333988391 (num_hops = 1); Mon, 27 Feb 2012 01:13:08 -0800 (PST) Received: by 10.204.154.211 with SMTP id p19mr5175258bkw.130.1330333988193; Mon, 27 Feb 2012 01:13:08 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id y9sm23390465bkw.5.2012.02.27.01.13.05 (version=SSLv3 cipher=OTHER); Mon, 27 Feb 2012 01:13:06 -0800 (PST) Message-ID: <4F4B4920.9030508@my.gd> Date: Mon, 27 Feb 2012 10:13:04 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F46847D.4010908@my.gd> <4F49F375.5000002@hm.net.br> <201202261630.57372.erichfreebsdlist@ovitrap.com> In-Reply-To: <201202261630.57372.erichfreebsdlist@ovitrap.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk3CeiiVanDKdVJZPF9UlO0rZ3ePlOFnFNV8PSEprxMONhrB9dOopQsKAc8GvR0uH0KD0DF Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 09:13:09 -0000 On 2/26/12 10:30 AM, Erich Dollansky wrote: > No matter what effort you put into testing, you can never achieve the robustness of an older release. I still have 7.4 running on one. This can stay until next year. > > So, why do you want to run the latest release on an important machine? You can, but you are not in a position to complain then. > > Erich Do you not see this as a *huge* problem ? This means even fewer testers, again ! This weekend I replaced a server, moved it from 6.4-STABLE to 8.3-PRERELEASE. Hell, as far as I'm concerned it could have stayed on 6.4-STABLE to be honest, but I needed to replace the hardware which was getting old. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 09:34:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15781106564A for ; Mon, 27 Feb 2012 09:34:38 +0000 (UTC) (envelope-from hm@hm.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [187.95.0.181]) by mx1.freebsd.org (Postfix) with ESMTP id 913918FC0A for ; Mon, 27 Feb 2012 09:34:37 +0000 (UTC) Received: from pop1.hm.net.br (pop1.hm.net.br [186.222.208.55]) by msrv.matik.com.br (8.14.5/8.14.5) with ESMTP id q1R9Y2GO019802; Mon, 27 Feb 2012 06:34:04 -0300 (BRT) (envelope-from hm@hm.net.br) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at msrv.matik.com.br X-DKIM: OpenDKIM Filter v2.4.3 msrv.matik.com.br q1R9Y2GO019802 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hm.net.br; s=racoon; t=1330335252; bh=awRlItF+hlHBDjgWxRjLgLJuf0MWnit8TgiwWZUIaJ4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Jr/JjU+bJD4tQTe3AY0CCng5CsZf2QDz5N8MwD8lnW0YWtvBnMPclpIRb++/WsDy8 NLOBQkHsvMinpGJ52fQjmMUps5efnTo4VaStHzCnwvX2ocdJXhJv3Ur6DCB+fF5/EX eW7dj357/OjssoSmBprQan0wFh9AA+yRhBxoDUAk= Authentication-Results: msrv.matik.com.br; sender-id=pass header.from=hm@hm.net.br; spf=pass smtp.mfrom=hm@hm.net.br Message-ID: <4F4B4E0A.5010009@hm.net.br> Date: Mon, 27 Feb 2012 06:34:02 -0300 From: H User-Agent: Mozilla/5.0 MIME-Version: 1.0 To: Mark Linimon References: <4F46847D.4010908@my.gd> <201202261630.57372.erichfreebsdlist@ovitrap.com> <4F4A068B.2090807@hm.net.br> <201202261800.16269.erichfreebsdlist@ovitrap.com> <4F4A254E.60200@hm.net.br> <20120226193816.GB31385@lonesome.com> In-Reply-To: <20120226193816.GB31385@lonesome.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL, BAYES_00, T_DKIM_INVALID, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2-hm_201202.c X-Spam-Checker-Version: SpamAssassin 3.3.2-hm_201202.c (2011-06-06) on msrv.matik.com.br Cc: Erich Dollansky , Mark Felder , freebsd-stable@freebsd.org Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 09:34:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Linimon wrote: > On Sun, Feb 26, 2012 at 09:27:58AM -0300, H wrote: >> it is release engineering who could establish a little bit more >> time between code-freeze and RELEASE > > As you will see from the (very) long discussion that you are about > to read, there has to be a compromise. As it was, the release > process was too long, not too short. > > Yes, we would like to get more testers pre-release, but that seems > to be more easily said than done. Ideas appreciated. > > You will also see in the thread that: > > - it is not possible to release bug-free code, and in fact > > - it is not possible to release code with no regressions > whatsoever > > if you are to ever release anything at all. > > To summarize: yes, we do care: and yes, these are classical > software engineering problems that can only be dealt with, not > solved completely. > well said, of course a dead-line is necessary, as well as pursuing perfection is dangerous matter :) anyway, this thread brought little suggestion or possible solutions but lots of declaration of facts and personal interest on the table IMO such a discussion should be strictly FreeBSD oriented and so I see a or the missing point, a declaration of FreeBSD, what is it, for whom is it and what does it, this statement is nonexistent, or not clear enough. This miss affect not only users opinion but also developers work. furthermore, plans or schedules may be perfect within it's own restrictions, but only as good as the outcome so the outcome must be controlled How? ... setting the goal are you interested in bumping the version number up or do you want to come up with something better than the former version? If yes, what is it? Without goal nobody can deliver predictable and defined results steeling a good comparison from that thread you mentioned, I would say, with the right goal you _CAN_ herd cats, instead of pied pipers put some mice on the street :) again IMO the version number race is suspicious and could(should) be changed into a goal-race, then, when the goal is achieved, the the version number may go up with goal the outcome can be controlled, without it is loose end it should exist a dead-line, but goal-oriented and so should be extendable in case of failure Resuming, I would do - [re]define FreeBSD - setting the next release goal - scheduling - go then accompanying the ongoing work (control), assuring that the sub-projects are within the limits, new ideas only can go into the next schedule, a no-matter-what position of engineering is important of course we deal with FreeBSD source, ports is a different matter and can not be merged tester? I would say it could be easier to have more of them, eventual they are already there, but they are unknown, quiet for certain reasons, language, skills, etc when a problem appears, point of sight is often missing, the user who pops up has a problem, he has no interest in blaming somebody or whatever, he like to solve the problem, so giving advices as RTFM or similar does not help a bit, neither how to use, how to write, how to spell or whatever other personal issue are arising. Most do not come back after RTFM or do not even post because they heard it already once so I would say, it does not matter how wired the PR arrives, it should be handled by same criteria as above. What is the goal? Finding problems in the FreeBSD code. So it does not matter which language the guy talks, if he knows C+/- or whatever bothers you, be smart and find out what the problem is there are several related issues, I would start by splitting the mailing list page on FreeBSD. Confusing for a user, he wouldn't know which list. Directing people on first sight to a general mailing list, perhaps no developers in it, or who has people-skills only and drain the results you want ... under any cost of selfishness before the bullets fly, I am not criticizing anybody, the tech-syndrome is natural, techs and users do not speak the same language, techs always will classify users as stupid and users always will classify techs as arrogant, or at least friction is natural. That is a global unchangeable fact and we have to live with it. So mix it up or separate it in prole of better results. It is very easy, with machines we do it already, we write drivers ... As above, what do you want? More PRs? ok, then again it is answered by the goal you set. Well treated a lot of testers will appear. - -- H -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9LTgoACgkQvKVfg5xjCDw8tgCfSU/IsV7S22d5AaNKiLYYwh7Z W40An1OKxF2T275x3pMwZBXTFpGYzuBQ =2ucy -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 09:37:25 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21F26106566C for ; Mon, 27 Feb 2012 09:37:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7AA8FC1A for ; Mon, 27 Feb 2012 09:37:24 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA03829; Mon, 27 Feb 2012 11:37:21 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1S1x1E-00020C-Hp; Mon, 27 Feb 2012 11:37:20 +0200 Message-ID: <4F4B4ECD.8080108@FreeBSD.org> Date: Mon, 27 Feb 2012 11:37:17 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: Stefan Bethke References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org List" Subject: Re: panic: GPF in kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 09:37:25 -0000 on 27/02/2012 09:39 Stefan Bethke said the following: > Setting up new hardware (i5 CPU, 16 GB RAM) and doing a burn-in test running make buildworld in a loop. After a couple of hours, I got this panic. 8-stable is from January, ZFS root. > > Does this correlate with any recently fixed bugs, or is this likely a hardware issue? The latter seems more likely. > # uname -a > FreeBSD dhcp62.lassitu.de 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Feb 24 23:22:57 UTC 2012 root@dhcp62.lassitu.de:/usr/obj/freebsd/checkout/src/sys/EISENBOOT amd64 > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 3; apic id = 06 > instruction pointer = 0x20:0xffffffff805460c5 > stack pointer = 0x28:0xffffff84830119d0 > frame pointer = 0x28:0xffffff8483011a60 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 38198 (cc1) > trap number = 9 > panic: general protection fault > cpuid = 3 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > kdb_backtrace() at kdb_backtrace+0x37 > panic() at panic+0x187 > trap_fatal() at trap_fatal+0x290 > trap() at trap+0x180 > calltrap() at calltrap+0x8 > --- trap 0x9, rip = 0xffffffff805460c5, rsp = 0xffffff84830119d0, rbp = 0xffffff8483011a60 --- > pmap_remove_pages() at pmap_remove_pages+0x275 > vmspace_exit() at vmspace_exit+0x9a > exit1() at exit1+0x3b3 > sys_exit() at sys_exit+0xe > amd64_syscall() at amd64_syscall+0x24f > Xfast_syscall() at Xfast_syscall+0xfc > --- syscall (1, FreeBSD ELF64, sys_exit), rip = 0x84ba3c, rsp = 0x7fffffffdf68, rbp = 0x7fffffffdfa0 --- > > > > (kgdb) bt > #0 doadump () at /freebsd/checkout/src/sys/kern/kern_shutdown.c:263 > #1 0xffffffff802eab00 in boot (howto=260) > at /freebsd/checkout/src/sys/kern/kern_shutdown.c:441 > #2 0xffffffff802eafa1 in panic (fmt=Variable "fmt" is not available. > ) > at /freebsd/checkout/src/sys/kern/kern_shutdown.c:614 > #3 0xffffffff8054dc80 in trap_fatal (frame=0x9, eva=Variable "eva" is not available. > ) > at /freebsd/checkout/src/sys/amd64/amd64/trap.c:825 > #4 0xffffffff8054e2a0 in trap (frame=0xffffff8483011920) > at /freebsd/checkout/src/sys/amd64/amd64/trap.c:621 > #5 0xffffffff80534cb8 in calltrap () > at /freebsd/checkout/src/sys/amd64/amd64/exception.S:228 > #6 0xffffffff805460c5 in pmap_remove_pages (pmap=0xffffff01982838d8) > at /freebsd/checkout/src/sys/amd64/amd64/pmap.c:4087 > #7 0xffffffff8051a61a in vmspace_exit (td=0xffffff017efca8a0) > at /freebsd/checkout/src/sys/vm/vm_map.c:405 > #8 0xffffffff802b93d3 in exit1 (td=0xffffff017efca8a0, rv=Variable "rv" is not available. > ) > at /freebsd/checkout/src/sys/kern/kern_exit.c:298 > #9 0xffffffff802ba61e in sys_exit (td=Variable "td" is not available. > ) > at /freebsd/checkout/src/sys/kern/kern_exit.c:106 > #10 0xffffffff8054d1ff in amd64_syscall (td=0xffffff017efca8a0, traced=0) > at subr_syscall.c:114 > #11 0xffffffff80534fac in Xfast_syscall () > at /freebsd/checkout/src/sys/amd64/amd64/exception.S:387 > #12 0x000000000084ba3c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 11:07:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FC7C1065673 for ; Mon, 27 Feb 2012 11:07:43 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1A0008FC1E for ; Mon, 27 Feb 2012 11:07:42 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 3D4D8153434; Mon, 27 Feb 2012 12:07:41 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmNKdjiilC8S; Mon, 27 Feb 2012 12:07:40 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id BF3D0153433; Mon, 27 Feb 2012 12:07:40 +0100 (CET) Message-ID: <4F4B63F9.2030208@digiware.nl> Date: Mon, 27 Feb 2012 12:07:37 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Peter Maloney References: <4F4B0F83.4090600@norma.perm.ru> <4F4B3370.7020302@brockmann-consult.de> In-Reply-To: <4F4B3370.7020302@brockmann-consult.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: ZFS version upgrading..... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 11:07:43 -0000 On 2012-02-27 8:40, Peter Maloney wrote: > And one word of advice: If you want to upgrade your pools to v28, I > think you should consider recreating your pools as v28 rather than > upgrading. There are some side effects to upgrading, such as logs that > can't be removed. Hi Peter, Although your advise is a sensible one.... It does not work if the ZFS system is full of data, and it's hard/impossible to rebuild. I have experience the other way around. My ZFS raidz2 is pretty old, probably even from the 7.x times... And I've upgraded it regulary to new versions. I even upgraded to v28, to be able to remove log's that we on USB sticks and all. No problem at all. And I do have removed logs quite a few times to look at different configs with my SSDs. Again: if you have te possibility to rebuild, why not. --WjW From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 12:34:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 226741065672 for ; Mon, 27 Feb 2012 12:34:43 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E12B58FC0A for ; Mon, 27 Feb 2012 12:34:42 +0000 (UTC) Received: by mail-iy0-f182.google.com with SMTP id e16so316629iaa.13 for ; Mon, 27 Feb 2012 04:34:42 -0800 (PST) Received-SPF: pass (google.com: domain of cpghost@cordula.ws designates 10.50.179.106 as permitted sender) client-ip=10.50.179.106; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cpghost@cordula.ws designates 10.50.179.106 as permitted sender) smtp.mail=cpghost@cordula.ws Received: from mr.google.com ([10.50.179.106]) by 10.50.179.106 with SMTP id df10mr17152867igc.6.1330346082820 (num_hops = 1); Mon, 27 Feb 2012 04:34:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.179.106 with SMTP id df10mr13786278igc.6.1330344324223; Mon, 27 Feb 2012 04:05:24 -0800 (PST) Received: by 10.231.8.30 with HTTP; Mon, 27 Feb 2012 04:05:24 -0800 (PST) X-Originating-IP: [93.221.183.23] In-Reply-To: <000001ccf4d6$66513b00$32f3b100$@gmail.com> References: <000001ccf4d6$66513b00$32f3b100$@gmail.com> Date: Mon, 27 Feb 2012 13:05:24 +0100 Message-ID: From: "C. P. Ghost" To: "Garrett R. Groesbeck" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnhWQOcllLsXxTjwTY6y0yWMF/eNb/pwm0aoQ5VUUiLajTCQIS1XlUJi8M1OKbNHcJ0hJBw Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.0-RELEASE - Trouble Booting on SPARC64 - kmem_suballoc error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 12:34:43 -0000 On Sun, Feb 26, 2012 at 11:31 PM, Garrett R. Groesbeck wrote: > I hope you are well. I've been working on a Sun Blade 2000 with FreeBSD 9= .0 > (sparc64) installed. > (... snip ...) > > panic: kmem_suballoc: bad status return of 3 > cpuid =3D 0 > KDB: stack backtrace: > =A0#0 0xc079841c at ??+0 > =A0#1 0xc04ca59c at ??+0 > =A0#2 0xc0487f90 at ??+0 > =A0#3 0xc0098028 at ??+0 > (... snip ...) > > Please let me know if there's anything I can do as I'd like my machine to= be > able to utilize the full memory capabilities. Please try the following patch in sparc64/164227: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dsparc%2F164227&cat=3D > Thank you, > > Garrett Groesbeck > > garrett.groesbeck@gmail.com Regards, -cpghost. --=20 Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 13:41:39 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEDD21065677 for ; Mon, 27 Feb 2012 13:41:39 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.226.44]) by mx1.freebsd.org (Postfix) with ESMTP id 68AC98FC14 for ; Mon, 27 Feb 2012 13:41:39 +0000 (UTC) Received: from amd620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q1RDfQbI019707; Mon, 27 Feb 2012 06:41:28 -0700 From: Erich Dollansky To: freebsd-stable@freebsd.org Date: Mon, 27 Feb 2012 20:41:18 +0700 User-Agent: KMail/1.13.7 (FreeBSD/8.3-PRERELEASE; KDE/4.7.4; amd64; ; ) References: <4F46847D.4010908@my.gd> <20120226193816.GB31385@lonesome.com> <4F4B4E0A.5010009@hm.net.br> In-Reply-To: <4F4B4E0A.5010009@hm.net.br> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202272041.18922.erichfreebsdlist@ovitrap.com> Cc: H , Mark Felder , Mark Linimon Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 13:41:39 -0000 Hi, On Monday 27 February 2012 16:34:02 H wrote: > Mark Linimon wrote: > > On Sun, Feb 26, 2012 at 09:27:58AM -0300, H wrote: > > furthermore, plans or schedules may be perfect within it's own > restrictions, but only as good as the outcome > > so the outcome must be controlled > > How? ... setting the goal > could it be that you want to replace them? http://www.freebsdfoundation.org/ Erich From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 14:24:02 2012 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 7BA021065674 for ; Mon, 27 Feb 2012 14:24:02 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (r2b9.nsu.ru [212.192.164.39]) by mx1.freebsd.org (Postfix) with ESMTP id 228818FC13 for ; Mon, 27 Feb 2012 14:24:01 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1S21Tz-0007JJ-8P; Mon, 27 Feb 2012 21:23:19 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q1RESfWn092931; Mon, 27 Feb 2012 21:28:41 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q1RESFlA092878; Mon, 27 Feb 2012 21:28:16 +0700 (NOVT) (envelope-from danfe) Date: Mon, 27 Feb 2012 21:28:15 +0700 From: Alexey Dokuchaev To: stable@freebsd.org Message-ID: <20120227142815.GA86253@regency.nsu.ru> References: <20120223025713.GA65874@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120223025713.GA65874@regency.nsu.ru> User-Agent: Mutt/1.4.2.1i Cc: rmacklem@freebsd.org Subject: Re: Resume broken in 8.3-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: Mon, 27 Feb 2012 14:24:02 -0000 On Thu, Feb 23, 2012 at 09:57:14AM +0700, Alexey Dokuchaev wrote: > Yesterday I've updated my laptop to the latest RELENG_8, it booted just > fine, however, after coming out of suspend, keyboard does not work (well, > almost: I can switch between consoles, Caps Lock works, but I cannot type > anything, login, etc., break into debugger with Ctrl-Alt-Esc). Network > does not work as well, and since fans are going up very fast, CPU > consumption must be around 100%. Kernel from Jan 17th does not exhibit > this problem. This is plain console, no X11. I was mistaken, the latest kernel with working resume is from Jan 4 00:00 UTC, kernel from Jan 4 01:00 UTC does not allow my laptop to come back from zzz(8) successfully. It seems that offending change is rev. 1.9.2.5 of sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450). To be sure, I've reverted just this change in the latest RELENG_8 sources -- and the problem goes away. Rick, how can I help you to debug this issue? I must admit I am confused how can NFS-related change break power-saving code path (suspend/resume). ./danfe From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 14:42:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74168106564A for ; Mon, 27 Feb 2012 14:42:35 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 314F08FC13 for ; Mon, 27 Feb 2012 14:42:35 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S21mW-0003zy-SC for freebsd-stable@freebsd.org; Mon, 27 Feb 2012 15:42:28 +0100 Received: from dyn1192-131.wlan.ic.ac.uk ([129.31.192.131]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Feb 2012 15:42:28 +0100 Received: from johannes by dyn1192-131.wlan.ic.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Feb 2012 15:42:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Johannes Totz Date: Mon, 27 Feb 2012 14:42:15 +0000 Lines: 39 Message-ID: References: <4F4B0F83.4090600@norma.perm.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dyn1192-131.wlan.ic.ac.uk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 In-Reply-To: <4F4B0F83.4090600@norma.perm.ru> Subject: Re: zfs, 1 gig of RAM and periodic weekly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 14:42:35 -0000 On 27/02/2012 05:07, Eugene M. Zheganin wrote: > Hi. > > I'm haunted by a weird bug. > Some of my servers (IBM x3250) hang periodically. And this is always > saturday morning. Different servers in different cities, all with zfs > and one gig of RAM. And yeah, it's periodic weekly. I can say more - > it's repeatable. 25 minutes ago I typed 'periodic weekly', and 5 > minutes ago I lost this machine from the network (even stopped answering > to ICMP). This can be solved by any of two methods - either increase > RAM, or turning off periodic weekly. You could try to narrow it down to one specific script. My first guess is that 310.locate brings the machine down as it traverses the whole tree. > > loader.conf (doesn't help): > > zfs_load="YES" > vfs.root.mountfrom="zfs:zfsroot" > ng_iface_load="YES" > ng_ether_load="YES" > vm.kmem_size="330M" > vm.kmem_size_max="330M" > vfs.zfs.arc_max="30M" > > This is 8.2-RELEASE/amd64. > > The most important question - what to report and how to report this ? > > Thanks. > Eugene. > _______________________________________________ > 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 Mon Feb 27 15:11:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C882106564A for ; Mon, 27 Feb 2012 15:11:46 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 5745A8FC0A for ; Mon, 27 Feb 2012 15:11:46 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-stable@freebsd.org with esmtp (envelope-from ) id <1S21xV-0000K3-3I>; Mon, 27 Feb 2012 15:53:49 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-stable@freebsd.org with esmtpsa (envelope-from ) id <1S21xU-0002Uy-Vm>; Mon, 27 Feb 2012 15:53:49 +0100 Message-ID: <4F4B98FC.6080705@mail.zedat.fu-berlin.de> Date: Mon, 27 Feb 2012 15:53:48 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120224 Thunderbird/10.0.2 MIME-Version: 1.0 To: FreeBSD Stable Mailing List X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAE4D4BCC8AB29FCFBA906AC4" X-Originating-IP: 130.133.86.198 Subject: netstat: no namelist X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 15:11:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAE4D4BCC8AB29FCFBA906AC4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On FreeBSD 9.0-STABLE/amd64 (recent build today, r232207), issuing "netstat on console or in terminal doesn't give the usual netstat as expected, instead I receive netstat: no namelist What's wrong? Regards, Oliver --------------enigAE4D4BCC8AB29FCFBA906AC4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJPS5j8AAoJEOgBcD7A/5N87ccH/1RdxLBWAC0J72YZmon2/RZy cJWrvJLGZbCuz5jwCu337JW9eecjfLNQzVq0RaHyk+LQ5sLxhFA6Bp4ovpzRDXgP 8Yz588KGjXx5uBG1u7cMHYIAfSXljAahgb0zW3s8LFUwPgKJIICvfYl2zl8UoiWx UQpIdk2FMkC9bJ/GRXfhOkIXOKLkJdu+Vlpe0WIe4b65Zdlr46EScljwHdEvhjI2 JJmI95FtYf6uc3eQLLZ8cYIzFgbZAW+A8ttB68KHhdEqsQmCZYcZ5by6fxf+nQgv ftePn9KelNQJh9fufYbefAoVTMdJA08gRiwnjIKlj0elOlmQzekCCyvmcbepZ6A= =TE1h -----END PGP SIGNATURE----- --------------enigAE4D4BCC8AB29FCFBA906AC4-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 15:17:40 2012 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 1E9A3106564A; Mon, 27 Feb 2012 15:17:40 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (r2b9.nsu.ru [212.192.164.39]) by mx1.freebsd.org (Postfix) with ESMTP id B35B08FC08; Mon, 27 Feb 2012 15:17:39 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1S22KG-0002ef-Mz; Mon, 27 Feb 2012 22:17:20 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q1RFMhlw005261; Mon, 27 Feb 2012 22:22:43 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q1RFMc7H005221; Mon, 27 Feb 2012 22:22:38 +0700 (NOVT) (envelope-from danfe) Date: Mon, 27 Feb 2012 22:22:38 +0700 From: Alexey Dokuchaev To: stable@freebsd.org Message-ID: <20120227152238.GA2940@regency.nsu.ru> References: <20120223025713.GA65874@regency.nsu.ru> <20120227142815.GA86253@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120227142815.GA86253@regency.nsu.ru> User-Agent: Mutt/1.4.2.1i Cc: rmacklem@freebsd.org Subject: Re: Resume broken in 8.3-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: Mon, 27 Feb 2012 15:17:40 -0000 On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev wrote: > I was mistaken, the latest kernel with working resume is from Jan 4 00:00 > UTC, kernel from Jan 4 01:00 UTC does not allow my laptop to come back from > zzz(8) successfully. It seems that offending change is rev. 1.9.2.5 of > sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450). To be sure, I've > reverted just this change in the latest RELENG_8 sources -- and the problem > goes away. Hmm, apparently the problem lies deeply/earlier. Backing out SVN rev 229450 allows me to resume twice, but third time it fails with the same symptoms as before (no keyboard while VTY switching works and screensaver fires, no network but ping(8) works, fans are bursting up). Stay tuned while I investigate more... ./danfe From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 15:19:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34CA11065687 for ; Mon, 27 Feb 2012 15:19:34 +0000 (UTC) (envelope-from hm@hm.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [187.95.0.181]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6A58FC15 for ; Mon, 27 Feb 2012 15:19:33 +0000 (UTC) Received: from pop1.hm.net.br (pop1.hm.net.br [186.222.208.55]) by msrv.matik.com.br (8.14.5/8.14.5) with ESMTP id q1RFIoxO046775; Mon, 27 Feb 2012 12:18:51 -0300 (BRT) (envelope-from hm@hm.net.br) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at msrv.matik.com.br X-DKIM: OpenDKIM Filter v2.4.3 msrv.matik.com.br q1RFIoxO046775 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hm.net.br; s=racoon; t=1330355936; bh=peeJjBfGnamiA5DRB3T1+USPLHl9J8nNfuVydjcc9uM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=bACYnXcEAh8Ay8fb/+Qb5drDJvHSyvb1Sc+nXl1cyoIZIHci+aTqIpRIyseS58qHj ULqSupeeU0xvr1chnp1LU/mX0Niqtu8cT0/gKl5xuFQvjIh+aEOJG1e35XttV3XRDP N6qlSVXQ8sTfULyS1sO6yt9ifNNdbsgpcFEhL5H8= Authentication-Results: msrv.matik.com.br; sender-id=pass header.from=hm@hm.net.br; spf=pass smtp.mfrom=hm@hm.net.br Message-ID: <4F4B9ECE.2000902@hm.net.br> Date: Mon, 27 Feb 2012 12:18:38 -0300 From: H User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: Erich Dollansky References: <4F46847D.4010908@my.gd> <20120226193816.GB31385@lonesome.com> <4F4B4E0A.5010009@hm.net.br> <201202272041.18922.erichfreebsdlist@ovitrap.com> In-Reply-To: <201202272041.18922.erichfreebsdlist@ovitrap.com> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF2FB28CB82407D3CCEC36F29" X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL, BAYES_00, T_DKIM_INVALID, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2-hm_201202.c X-Spam-Checker-Version: SpamAssassin 3.3.2-hm_201202.c (2011-06-06) on msrv.matik.com.br Cc: Mark Linimon , Mark Felder , freebsd-stable@freebsd.org Subject: Re: FreeBSD9 and the sheer number of problem reports X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 15:19:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF2FB28CB82407D3CCEC36F29 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02/27/12 10:41, Erich Dollansky wrote: > Hi, > > On Monday 27 February 2012 16:34:02 H wrote: >> Mark Linimon wrote: >>> On Sun, Feb 26, 2012 at 09:27:58AM -0300, H wrote: >> furthermore, plans or schedules may be perfect within it's own >> restrictions, but only as good as the outcome >> >> so the outcome must be controlled >> >> How? ... setting the goal >> > could it be that you want to replace them? > > http://www.freebsdfoundation.org/ > > Erich I know it is not polite answering with a question, so I beg your pardon and do it anyway do you really believe somebody (user, future user, curious) go to this site when looking for freebsd description, download and install? further, where is it? we all are working with software, we know very well what we do with grey-zone-matter ... it is 0|1 ... all between is >/dev/null ... or exit =2E.. so do not assume that people do like guessing very much, they find it by banging their head on it or they go home --=20 H --------------enigF2FB28CB82407D3CCEC36F29 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9LntkACgkQvKVfg5xjCDyyYgCglq6U/UFeMLzIOBzpH7Pqvdvd h4kAn1L1ai2BwF972myd5UyouvufrHLt =40mQ -----END PGP SIGNATURE----- --------------enigF2FB28CB82407D3CCEC36F29-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 15:33:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45E811065670 for ; Mon, 27 Feb 2012 15:33:57 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C82D48FC13 for ; Mon, 27 Feb 2012 15:33:56 +0000 (UTC) Received: by werl4 with SMTP id l4so850654wer.13 for ; Mon, 27 Feb 2012 07:33:55 -0800 (PST) Received-SPF: pass (google.com: domain of lacombar@gmail.com designates 10.216.132.32 as permitted sender) client-ip=10.216.132.32; Authentication-Results: mr.google.com; spf=pass (google.com: domain of lacombar@gmail.com designates 10.216.132.32 as permitted sender) smtp.mail=lacombar@gmail.com; dkim=pass header.i=lacombar@gmail.com Received: from mr.google.com ([10.216.132.32]) by 10.216.132.32 with SMTP id n32mr7418591wei.12.1330356835836 (num_hops = 1); Mon, 27 Feb 2012 07:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=9eOthBCTuOJyG7AlfLRHapAvWcQNpdsHZwtHRdpZP90=; b=CVGw1pkXc0gYLUU8i4ZEUY56AxEW7z3Xnshv+nJCPas6EwsJ54MHvPRSlz1S/J8kHl BiG8R6J+oyB4Uye+VimfoqxQJTLFnPW4tlx02DSIl+m8rrvRImvziPYGL1maUAYCBsQg F0lYAqnVcRXoGm9T2paZt773gY2R9hfb8xEHA= MIME-Version: 1.0 Received: by 10.216.132.32 with SMTP id n32mr5885295wei.12.1330356835705; Mon, 27 Feb 2012 07:33:55 -0800 (PST) Received: by 10.216.166.11 with HTTP; Mon, 27 Feb 2012 07:33:55 -0800 (PST) In-Reply-To: References: Date: Mon, 27 Feb 2012 10:33:55 -0500 Message-ID: From: Arnaud Lacombe To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Complete hang on 9.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 15:33:57 -0000 Hi, On Tue, Feb 14, 2012 at 11:41 AM, Arnaud Lacombe wrote= : > Hi folks, > > For the records, I was running some tests yesterday on top of a > 9.0-RELEASE, amd64, kernel when the box hanged. At the time of the > hang, the box was running a process with about 2800 threads with heavy > IPC between 1400 writers and 1400 readers. The box was in single user > mode (/bin/sh coming from FreeBSD 7.4-STABLE). Here is the beginning > of the dmesg: > This happened a second time, now with FreeBSD 8.2-RELEASE. Complete machine hang. The machine was running about 4000 threads in a single process, all the other condition are the same. - Arnaud > Copyright (c) 1992-2012 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > =A0 =A0 =A0 =A0The Regents of the University of California. All rights re= served. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-RELEASE #0: Tue Jan =A03 07:46:30 UTC 2012 > =A0 =A0root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > CPU: Intel(R) Atom(TM) CPU D510 =A0 @ 1.66GHz (1666.70-MHz K8-class CPU) > =A0Origin =3D "GenuineIntel" =A0Id =3D 0x106ca =A0Family =3D 6 =A0Model = =3D 1c =A0Stepping =3D 10 > =A0Features=3D0xbfebfbff > =A0Features2=3D0x40e31d > =A0AMD Features=3D0x20000800 > =A0AMD Features2=3D0x1 > =A0TSC: P-state invariant, performance statistics > real memory =A0=3D 2137587712 (2038 MB) > avail memory =3D 2037841920 (1943 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: <070611 APIC1125> > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 HTT threads > =A0cpu0 (BSP): APIC ID: =A00 > =A0cpu1 (AP/HT): APIC ID: =A01 > =A0cpu2 (AP): APIC ID: =A02 > =A0cpu3 (AP/HT): APIC ID: =A03 > > I will restart the test and see if this happens again. > > regards, > =A0- Arnaud From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 15:36:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CC46106564A for ; Mon, 27 Feb 2012 15:36:53 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 06AD08FC13 for ; Mon, 27 Feb 2012 15:36:52 +0000 (UTC) Received: by lagz14 with SMTP id z14so7854233lag.13 for ; Mon, 27 Feb 2012 07:36:51 -0800 (PST) Received-SPF: pass (google.com: domain of asmrookie@gmail.com designates 10.152.130.234 as permitted sender) client-ip=10.152.130.234; Authentication-Results: mr.google.com; spf=pass (google.com: domain of asmrookie@gmail.com designates 10.152.130.234 as permitted sender) smtp.mail=asmrookie@gmail.com; dkim=pass header.i=asmrookie@gmail.com Received: from mr.google.com ([10.152.130.234]) by 10.152.130.234 with SMTP id oh10mr12883132lab.35.1330357011721 (num_hops = 1); Mon, 27 Feb 2012 07:36:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ILHLUvy4usdkZDdIlf9DgWt7+NPF82ViJPTdZZisrSc=; b=bV4rMH2jiEcUJLetKkJCwQXV9M1xPmhoNJ9GExfMpd5jNhO6Oy9n5dWOvM1WDbNxNv r3G5waEoht458Ppj+vSly3Qz6LQxqcoboQW35rrgo6Vnn5mrZTRGlQ52kYQrXulCYC/7 rVwUn/o8XekNX76o4NtnhuGGj3FC6HXHTi/Zo= MIME-Version: 1.0 Received: by 10.152.130.234 with SMTP id oh10mr10761455lab.35.1330357011664; Mon, 27 Feb 2012 07:36:51 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.41.5 with HTTP; Mon, 27 Feb 2012 07:36:51 -0800 (PST) In-Reply-To: References: Date: Mon, 27 Feb 2012 15:36:51 +0000 X-Google-Sender-Auth: IBEhfWzfjYR6MFzyXR4CC8fU4ko Message-ID: From: Attilio Rao To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable Subject: Re: Complete hang on 9.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 15:36:53 -0000 2012/2/27, Arnaud Lacombe : > Hi, > > On Tue, Feb 14, 2012 at 11:41 AM, Arnaud Lacombe wrote: >> Hi folks, >> >> For the records, I was running some tests yesterday on top of a >> 9.0-RELEASE, amd64, kernel when the box hanged. At the time of the >> hang, the box was running a process with about 2800 threads with heavy >> IPC between 1400 writers and 1400 readers. The box was in single user >> mode (/bin/sh coming from FreeBSD 7.4-STABLE). Here is the beginning >> of the dmesg: >> > This happened a second time, now with FreeBSD 8.2-RELEASE. Complete > machine hang. The machine was running about 4000 threads in a single > process, all the other condition are the same. Arnaud, can you please break in your kernel via KDB, collect the following informations from the DDB prompt: - ps - alltrace - show allpcpu - possibly get a coredump with 'call doadump' and in the end provide all those along with kernel binary and possibly sources somewhere? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 15:44:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14775106566C for ; Mon, 27 Feb 2012 15:44:15 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-iy0-f196.google.com (mail-iy0-f196.google.com [209.85.210.196]) by mx1.freebsd.org (Postfix) with ESMTP id C26BD8FC12 for ; Mon, 27 Feb 2012 15:44:14 +0000 (UTC) Received: by iaeh11 with SMTP id h11so124041iae.7 for ; Mon, 27 Feb 2012 07:44:14 -0800 (PST) Received-SPF: pass (google.com: domain of jhellenthal@dataix.net designates 10.50.34.202 as permitted sender) client-ip=10.50.34.202; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jhellenthal@dataix.net designates 10.50.34.202 as permitted sender) smtp.mail=jhellenthal@dataix.net; dkim=pass header.i=jhellenthal@dataix.net Received: from mr.google.com ([10.50.34.202]) by 10.50.34.202 with SMTP id b10mr18375361igj.2.1330357454378 (num_hops = 1); Mon, 27 Feb 2012 07:44:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=nsiUlkgEkRGUG+2BUzyiBGfMYNt8OwJzdw0O92Jwc5U=; b=F8RuYlAlE0RnTChP///944MvWZveiK07vAjnpw2VC1tvknDwqqwML1i8axM3gEtplj In/6qzgjO7S4Pep2cjKEpRX4G2c1VEvqn34OoRA+BE3VDwk2mF2j5Zig67krFH9YNw7j qELG+cAVtOvtdQSl+e2WMqCeLp2AyUFPG+g68= Received: by 10.50.34.202 with SMTP id b10mr14777890igj.2.1330356600874; Mon, 27 Feb 2012 07:30:00 -0800 (PST) Received: from DataIX.net (adsl-99-181-135-127.dsl.klmzmi.sbcglobal.net. [99.181.135.127]) by mx.google.com with ESMTPS id mq3sm2747601ibb.9.2012.02.27.07.29.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Feb 2012 07:30:00 -0800 (PST) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q1RFTvwk038762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2012 10:29:58 -0500 (EST) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q1RFTvMX038549; Mon, 27 Feb 2012 10:29:57 -0500 (EST) (envelope-from jhellenthal@DataIX.net) Date: Mon, 27 Feb 2012 10:29:57 -0500 From: Jason Hellenthal To: "O. Hartmann" Message-ID: <20120227152957.GB64523@DataIX.net> References: <4F4B98FC.6080705@mail.zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F4B98FC.6080705@mail.zedat.fu-berlin.de> X-Gm-Message-State: ALoCoQkzQvz+VdHsq2k65dnRrVzsMUjdocJi7fxjDNCC0MkAYOM7h9O0vA53wLmpASMb5K3VljWZ Cc: FreeBSD Stable Mailing List Subject: Re: netstat: no namelist X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 15:44:15 -0000 On Mon, Feb 27, 2012 at 03:53:48PM +0100, O. Hartmann wrote: > On FreeBSD 9.0-STABLE/amd64 (recent build today, r232207), issuing > "netstat on console or in terminal doesn't give the usual netstat as > expected, instead I receive > > netstat: no namelist > > What's wrong? > This usually happens when kernel and world are built out of sync. Attempt to rebuild ( kernel first & then world ) follow the steps near /usr/src/UPDATING -- ;s =; From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 15:47:51 2012 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 C7039106566C; Mon, 27 Feb 2012 15:47:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6CFA48FC14; Mon, 27 Feb 2012 15:47:50 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EADGlS0+DaFvO/2dsb2JhbABDhSevBoFzAQEBBAEBASArIAsbDgoCAg0ZAikBCSYGCAcEARwEh2ULpXqSBoEviEqDBBMLARACAgUCCgEGBAcCBgcVCwYDAoREAQI6UAeCOoEWBIhPikaCKJMMgTYJBg X-IronPort-AV: E=Sophos;i="4.73,491,1325480400"; d="scan'208";a="161148892" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 27 Feb 2012 10:47:49 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id BC255B3F57; Mon, 27 Feb 2012 10:47:49 -0500 (EST) Date: Mon, 27 Feb 2012 10:47:49 -0500 (EST) From: Rick Macklem To: Alexey Dokuchaev Message-ID: <134870242.175249.1330357669745.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120227152238.GA2940@regency.nsu.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: rmacklem@freebsd.org, stable@freebsd.org Subject: Re: Resume broken in 8.3-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: Mon, 27 Feb 2012 15:47:51 -0000 Alexey Dokuchaev wrote: > On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev wrote: > > I was mistaken, the latest kernel with working resume is from Jan 4 > > 00:00 > > UTC, kernel from Jan 4 01:00 UTC does not allow my laptop to come > > back from > > zzz(8) successfully. It seems that offending change is rev. 1.9.2.5 > > of > > sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450). To be sure, > > I've > > reverted just this change in the latest RELENG_8 sources -- and the > > problem > > goes away. > > Hmm, apparently the problem lies deeply/earlier. Backing out SVN rev > 229450 allows me to resume twice, but third time it fails with the > same > symptoms as before (no keyboard while VTY switching works and > screensaver > fires, no network but ping(8) works, fans are bursting up). Stay tuned > while I investigate more... > Yes, I can't think of how r229450 would affect "resume". All it does is clear the high order bit in an error reply from an NFS server, since that bit should never be set in an NFS error reply and, if set, it results in an mbuf list being free'd twice. The bit is erroneously set by "amd" sometimes. If you are using "amd", that might be related to the resume problem? rick ps: I suspect you saw it, but there was a recent thread related to known suspend/resume issues and discussed how they might be fixed in the future. Sorry, I don't remember which list or the exact subject line. > ./danfe > _______________________________________________ > 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 Mon Feb 27 15:52:46 2012 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 660141065670 for ; Mon, 27 Feb 2012 15:52:46 +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 11E898FC0C for ; Mon, 27 Feb 2012 15:52:45 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q1RFqjl3065523 for ; Mon, 27 Feb 2012 08:52:45 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q1RFqj0Z065520 for ; Mon, 27 Feb 2012 08:52:45 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Mon, 27 Feb 2012 08:52:45 -0700 (MST) 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.7 (wonkity.com [127.0.0.1]); Mon, 27 Feb 2012 08:52:45 -0700 (MST) Cc: Subject: sendmail and smarthost X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 15:52:46 -0000 In 8.3-PRERELEASE, sendmail is now happily ignoring a smarthost unless DONT_PROBE_INTERFACES is set. That used to be unnecessary. That machine rarely sends email, but a bug followup sent on Feb 25 went through. Maybe not significant since it was outside the local domain. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 15:53:49 2012 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 8D3A71065672; Mon, 27 Feb 2012 15:53:49 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from bijou.wasikowski.net (bijou.wasikowski.net [IPv6:2001:808:10f::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3E2518FC18; Mon, 27 Feb 2012 15:53:49 +0000 (UTC) Received: from bijou.wasikowski.net (localhost [127.0.0.1]) by bijou.wasikowski.net (Postfix) with ESMTP id B0E795C08F; Mon, 27 Feb 2012 16:53:47 +0100 (CET) X-Virus-Scanned: amavisd-new at wasikowski.net Received: from bijou.wasikowski.net ([127.0.0.1]) by bijou.wasikowski.net (bijou.wasikowski.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEh7trjqF8MM; Mon, 27 Feb 2012 16:53:44 +0100 (CET) Received: from [192.168.138.150] (cadera.waw.pl [62.121.127.119]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by bijou.wasikowski.net (Postfix) with ESMTPSA id 7EF8D5C01A; Mon, 27 Feb 2012 16:53:44 +0100 (CET) Message-ID: <4F4BA707.5070608@wasikowski.net> Date: Mon, 27 Feb 2012 16:53:43 +0100 From: =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , stable@FreeBSD.org, current@FreeBSD.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 15:53:49 -0000 W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze: > You cannot ship that on by default for non-tecnical reasons in a kernel. Please do not commit a kernel config that can be booted (no LINT cannot be booted) with these on without consulting appropriate hats upfront. > > >> - ALTQ >> - SW_WATCHDOG >> - QUOTA >> - IPSTEALTH (disabled in loader.conf) >> - IPFIREWALL_FORWARD (touches every packet, power users which need >> a bigger PPS but not this feature can recompile the kernel, >> discussed with julian@) >> - FLOWTABLE (disabled in loader.conf) > Which is not the same as it's not 100% disabled and will still allocate memory. FLOWTABLE on 8.x crashed BGP routers (kern/144917). I don't know if it is fixed by now, but this kind of potential problematic features should not be enabled by default. -- best regards, Lukasz Wasikowski From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 16:42:52 2012 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 04577106567D; Mon, 27 Feb 2012 16:42:52 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (r2b9.nsu.ru [212.192.164.39]) by mx1.freebsd.org (Postfix) with ESMTP id C28778FC14; Mon, 27 Feb 2012 16:42:50 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1S23eS-0007vr-QC; Mon, 27 Feb 2012 23:42:16 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q1RGld2d017105; Mon, 27 Feb 2012 23:47:39 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q1RGlYw2017015; Mon, 27 Feb 2012 23:47:34 +0700 (NOVT) (envelope-from danfe) Date: Mon, 27 Feb 2012 23:47:34 +0700 From: Alexey Dokuchaev To: Rick Macklem Message-ID: <20120227164733.GA12679@regency.nsu.ru> References: <20120227152238.GA2940@regency.nsu.ru> <134870242.175249.1330357669745.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <134870242.175249.1330357669745.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.1i Cc: rmacklem@freebsd.org, stable@freebsd.org Subject: Re: Resume broken in 8.3-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: Mon, 27 Feb 2012 16:42:52 -0000 On Mon, Feb 27, 2012 at 10:47:49AM -0500, Rick Macklem wrote: > Yes, I can't think of how r229450 would affect "resume". All it does is > clear the high order bit in an error reply from an NFS server, since that > bit should never be set in an NFS error reply and, if set, it results in > an mbuf list being free'd twice. True, although even if it helps triggering the real underlying bug, it's still weird. > The bit is erroneously set by "amd" sometimes. If you are using "amd", > that might be related to the resume problem? No, I don't; I've deliberately disabled almost everything. > ps: I suspect you saw it, but there was a recent thread related to known > suspend/resume issues and discussed how they might be fixed in the > future. Sorry, I don't remember which list or the exact subject line. Yes, I know what are you talking about. However, I don't recall if any one was experiencing the same symptoms as I do. ./danfe From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 17:46:22 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 8D0CB106566B; Mon, 27 Feb 2012 17:46:21 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Alexey Dokuchaev Date: Mon, 27 Feb 2012 12:46:07 -0500 User-Agent: KMail/1.6.2 References: <20120227152238.GA2940@regency.nsu.ru> <134870242.175249.1330357669745.JavaMail.root@erie.cs.uoguelph.ca> <20120227164733.GA12679@regency.nsu.ru> In-Reply-To: <20120227164733.GA12679@regency.nsu.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202271246.09674.jkim@FreeBSD.org> Cc: "rmacklem@freebsd.org" , Rick Macklem , freebsd-stable@FreeBSD.org Subject: Re: Resume broken in 8.3-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: Mon, 27 Feb 2012 17:46:22 -0000 On Monday 27 February 2012 11:47 am, Alexey Dokuchaev wrote: > On Mon, Feb 27, 2012 at 10:47:49AM -0500, Rick Macklem wrote: > > Yes, I can't think of how r229450 would affect "resume". All it > > does is clear the high order bit in an error reply from an NFS > > server, since that bit should never be set in an NFS error reply > > and, if set, it results in an mbuf list being free'd twice. > > True, although even if it helps triggering the real underlying bug, > it's still weird. > > > The bit is erroneously set by "amd" sometimes. If you are using > > "amd", that might be related to the resume problem? > > No, I don't; I've deliberately disabled almost everything. > > > ps: I suspect you saw it, but there was a recent thread related > > to known suspend/resume issues and discussed how they might be > > fixed in the future. Sorry, I don't remember which list or the > > exact subject line. > > Yes, I know what are you talking about. However, I don't recall if > any one was experiencing the same symptoms as I do. Can you please try head and/or stable/9? FYI, Linux people found that some BIOSes can corrupt low 64KB between suspend/resume, which may cause strangeness like this. I worked around it in head (r231781) and stable/9 (r232088). Thanks, Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 17:47:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 000EE1065676; Mon, 27 Feb 2012 17:47:15 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by mx1.freebsd.org (Postfix) with ESMTP id 0A1978FC22; Mon, 27 Feb 2012 17:47:14 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKT0vBogM8vjOnFIKfu5dDdXBhRqFruvrn@postini.com; Mon, 27 Feb 2012 09:47:15 PST Received: from PALCAS01.lsi.com (128.94.213.117) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 27 Feb 2012 12:51:50 -0500 Received: from inbexch02.lsi.com (135.36.98.40) by PALCAS01.lsi.com (128.94.213.117) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 27 Feb 2012 12:47:13 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Mon, 27 Feb 2012 23:17:09 +0530 From: "Desai, Kashyap" To: John Baldwin , "freebsd-stable@freebsd.org" Date: Mon, 27 Feb 2012 23:17:07 +0530 Thread-Topic: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited Thread-Index: AczzHWYQfkAel5RkSQGjugGiKVUEJQCWlyqQ Message-ID: References: <20120223092457.GB55074@deviant.kiev.zoral.com.ua> <201202230958.05667.jhb@freebsd.org> In-Reply-To: <201202230958.05667.jhb@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Konstantin Belousov , "freebsd-scsi@freebsd.org" , "Justin T. Gibbs" , "Kenneth D. Merry" , "McConnell, Stephen" Subject: RE: mpslsi0 : Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 17:47:16 -0000 > -----Original Message----- > From: John Baldwin [mailto:jhb@freebsd.org] > Sent: Thursday, February 23, 2012 8:28 PM > To: freebsd-stable@freebsd.org > Cc: Desai, Kashyap; Konstantin Belousov; freebsd-scsi@freebsd.org; > Kenneth D. Merry; Justin T. Gibbs; McConnell, Stephen > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping > prohibited >=20 > On Thursday, February 23, 2012 8:22:07 am Desai, Kashyap wrote: > > > > > -----Original Message----- > > > From: Konstantin Belousov [mailto:kostikbel@gmail.com] > > > Sent: Thursday, February 23, 2012 2:55 PM > > > To: Desai, Kashyap > > > Cc: freebsd-scsi@freebsd.org; freebsd-stable; Justin T. Gibbs; > Kenneth > > > D. Merry; McConnell, Stephen > > > Subject: Re: mpslsi0 : Trying sleep, but thread marked as sleeping > > > prohibited > > > > > > On Thu, Feb 23, 2012 at 05:52:12AM +0530, Desai, Kashyap wrote: > > > > > > > > > > > > > -----Original Message----- > > > > > From: Konstantin Belousov [mailto:kostikbel@gmail.com] > > > > > Sent: Thursday, February 23, 2012 12:45 AM > > > > > To: Desai, Kashyap > > > > > Cc: freebsd-scsi@freebsd.org; freebsd-stable; Justin T. Gibbs; > > > > > Kenneth D. Merry; McConnell, Stephen > > > > > Subject: Re: mpslsi0 : Trying sleep, but thread marked as > sleeping > > > > > prohibited > > > > > > > > > > On Wed, Feb 22, 2012 at 07:36:42PM +0530, Desai, Kashyap wrote: > > > > > > Hi, > > > > > > > > > > > > I am doing some code changes in mps dirver. While working on > those > > > > > changes, I come to know about something which is new to me. > > > > > > Some expert help is required to clarify my doubt. > > > > > > > > > > > > 1. When any irq is register with FreeBSD OS, it sets " > > > TDP_NOSLEEPING" > > > > > > pflag. It means though irq in freebsd is treated as thread, We > > > > > > cannot > > > > > sleep in IRQ because of " "TDP_NOSLEEPING " set. > > > > > > 2. In mps driver we have below code snippet in ISR routine. > > > > > > > > > > > > > > > > > > mps_dprint(sc, MPS_TRACE, "%s\n", __func__); > > > > > > mps_lock(sc); > > > > > > mps_intr_locked(data); > > > > > > mps_unlock(sc); > > > > > > > > > > > > I wonder why there is no issue with above code ? Theoretical > we > > > > > > cannot sleep in ISR. (as explained in #1) Any thoughts ? > > > > > > > > > > > > > > > > > > 3. I recently added few place msleep() instead of DELAY in ISR > > > > > > context and I see " Trying sleep, but thread marked as > sleeping > > > prohibited". > > > > > > > > > > > FreeBSD has several basic ways to prevent a thread from > executing on > > > > > CPU. > > > > > They mostly fall into two categories: bounded sleep, sometimes > > > > > called blocking, and unbounded sleep, usually abbreviated as > sleep. > > > > > The bounded there refers to amount of code executed by other > thread > > > > > that hold resource preventing blocked thread from making a > progress. > > > > > > > > > > Examples of the blocking primitives are mutexes, rw locks and rm > > > locks. > > > > > The blocking is not counted as sleeping, so interrupt threads, > which > > > > > are designated as non-sleeping, still can lock mutexes. > > > > Thanks for the tech help. . > > > > > > > > As per you comment, So now I understood as "TDP_NOSLEEPING" is > only > > > > for unbounded sleep restriction. Just curious to know, What is a > > > > reason that thread can do blocking sleep but can't do unbounded > sleep > > > > ? Since technically we introduced sleeping restriction on > interrupt > > > > thread is to avoid starvation and that can be fit with either of > the > > > > sleep type. Is this not true ? > > > No, not to avoid starvation. > > > > > > The intent of the blocking primitives is to acquire resources for > > > limited amount of time. In other words, you never take a mutex for > > > undefinitely long computation process. On the other hand, msleep > sleep > > > usually has no limitations. > > > > I got same reply from Ed Schouten. I agree and understood your note. > Thanks > for poring knowledge on this area. > > _but_ only query is when thread take mutex, we don't know when it will > release. So holding time of mutex is really not known. > > In case of some bad code, where thread took mutex and not release > within > short time. This can eventually match upto msleep restriction as well. > > Do we have any checks that thread took long time holding mutext ? > Similar > to linux where spinlock has been not release in some specific time, they > dump > warnings with backtrace. >=20 > We don't allow code to do unbounded sleeps while holding mutexes either, > and > WITNESS warns about doing so. That ensures that barring an infinite > loop-type > bug, mutexes should be held for a bounded amount of time. Thanks. I understood this concept now. Really helpful conversation. >=20 > -- > John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 17:48:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 117461065674 for ; Mon, 27 Feb 2012 17:48:37 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 712298FC26 for ; Mon, 27 Feb 2012 17:48:36 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so1148944wgb.31 for ; Mon, 27 Feb 2012 09:48:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oF4BgFyUhKT78ONKpDnqFLIG2p0O04x+7g6EPQHkI/M=; b=wJMzwUafYec37931nlXMSsfEJYd4l98Bbe08HppDzvyiCEHMoxvkmeZKRGKz068Dmk sczJW2ZyVWrqb7N2BRdAfXLKpXispYu0mFHQr9m1bEaBzp/9pxQdpTQ2ONk50pJI5v3s GjpePtW3rZQPy1z4wA4SI7OPF7u+zXOqzsH3Q= MIME-Version: 1.0 Received: by 10.180.92.227 with SMTP id cp3mr24254018wib.13.1330364915258; Mon, 27 Feb 2012 09:48:35 -0800 (PST) Received: by 10.216.166.11 with HTTP; Mon, 27 Feb 2012 09:48:35 -0800 (PST) In-Reply-To: References: Date: Mon, 27 Feb 2012 12:48:35 -0500 Message-ID: From: Arnaud Lacombe To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable Subject: Re: Complete hang on 9.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 17:48:37 -0000 Hi, On Mon, Feb 27, 2012 at 10:36 AM, Attilio Rao wrote: > 2012/2/27, Arnaud Lacombe : >> Hi, >> >> On Tue, Feb 14, 2012 at 11:41 AM, Arnaud Lacombe wrote: >>> Hi folks, >>> >>> For the records, I was running some tests yesterday on top of a >>> 9.0-RELEASE, amd64, kernel when the box hanged. At the time of the >>> hang, the box was running a process with about 2800 threads with heavy >>> IPC between 1400 writers and 1400 readers. The box was in single user >>> mode (/bin/sh coming from FreeBSD 7.4-STABLE). Here is the beginning >>> of the dmesg: >>> >> This happened a second time, now with FreeBSD 8.2-RELEASE. Complete >> machine hang. The machine was running about 4000 threads in a single >> process, all the other condition are the same. > > Arnaud, > can you please break in your kernel via KDB, collect the following > informations from the DDB prompt: > - ps > - alltrace > - show allpcpu > - possibly get a coredump with 'call doadump' > Will do, but I'll need to rebuild a kernel to include DDB. > and in the end provide all those along with kernel binary and possibly > sources somewhere? > I'll be testing a bare `release/8.2.0' with the following patch: diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC index c3e0095..7bd997f 100644 --- a/sys/amd64/conf/GENERIC +++ b/sys/amd64/conf/GENERIC @@ -79,6 +79,10 @@ options INCLUDE_CONFIG_FILE # Include this file in kernel options KDB # Kernel debugger related code options KDB_TRACE # Print a stack trace for a panic +options DDB +options BREAK_TO_DEBUGGER +options ALT_BREAK_TO_DEBUGGER # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel - Arnaud > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 18:10:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E07DB1065677 for ; Mon, 27 Feb 2012 18:10:25 +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 B6BEF8FC12 for ; Mon, 27 Feb 2012 18:10:25 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 6D76F46B43; Mon, 27 Feb 2012 13:10:25 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C655BB990; Mon, 27 Feb 2012 13:10:24 -0500 (EST) From: John Baldwin To: pyunyh@gmail.com Date: Mon, 27 Feb 2012 11:25:10 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201202230946.20471.jhb@freebsd.org> <20120225221301.GA3718@michelle.cdnetworks.com> In-Reply-To: <20120225221301.GA3718@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201202271125.10969.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 27 Feb 2012 13:10:24 -0500 (EST) Cc: freebsd-stable@freebsd.org Subject: Re: Regression in 8.2-STABLE bge code (from 7.4-STABLE) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 18:10:26 -0000 On Saturday, February 25, 2012 5:13:01 pm YongHyeon PYUN wrote: > On Thu, Feb 23, 2012 at 09:46:20AM -0500, John Baldwin wrote: > > On Tuesday, February 14, 2012 7:56:00 pm YongHyeon PYUN wrote: > > > On Sat, Jan 28, 2012 at 09:24:53PM -0500, Michael L. Squires wrote: > > > > > > Sorry for late reply. Had been busy due to relocation. > > > > > > > There is a bug in the Tyan S4881/S4882 PCI-X bridges that was fixed with a > > > > patch in 7.x (thank you very much). This patch is not present in the > > > > 8.2-STABLE code and the symptoms (watchdog timeouts) have recurred. > > > > > > > > > > Hmm, I thought the mailbox reordering bug was avoided by limiting > > > DMA address space to 32bits but it seems it was not right workaround > > > for AMD 8131 PCI-X Bridge. > > > > > > > The watchdog timeouts do not appear to be present after I switched to an > > > > Intel gigabit PCI-X card. > > > > > > > > I did a brute-force patch of the 8.2-STABLE bge code using the patches for > > > > 7.4-STABLE; the resulting code compiled and, other than odd behavior at > > > > startup, seems to be working normally. > > > > > > > > This is using FreeBSD 8.2-STABLE amd64; I don't know what happens with > > > > i386. > > > > > > > > Given the age of the boards it may be easier if I just continue using the > > > > Intel gigabit card but am happy to test anything that comes my way. > > > > > > > > > > Try attached patch and let me know how it goes. > > > I didn't enable 64bit DMA addressing though. I think the AMD-8131 > > > PCI-X bridge needs both workarounds. > > > > Eh, please don't do the thing where you walk all pcib devices. Instead, walk > > up the tree like so: > > > > static int > > bge_mbox_reorder(struct bge_softc *sc) > > { > > devclass_t pcib, pci; > > device_t dev, bus; > > > > pci = devclass_find("pci"); > > pcib = devclass_find("pcib"); > > dev = sc->dev; > > bus = device_get_parent(dev); > > for (;;) { > > dev = device_get_parent(bus); > > bus = device_get_parent(dev); > > if (device_get_devclass(dev) != pcib_devclass || > > device_get_devclass(bus) != pci_devclass) > > break; > > /* Probe device ID. */ > > } > > return (0); > > } > > > > It is not safe to use pci_get_vendor() with non-PCI devices (you may get > > random junk, and Host-PCI bridges are not PCI devices). Also, this will only > > apply the quirk if a relevant bridge is in the bge device's path. > > > > Thanks for reviewing and suggestion. > Would you review updated one? Looks good, thanks! I wish there was some way to mark this quirk in the PCI-PCI bridge driver so bge didn't have to walk up its tree, but I can't really think of a better way. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 18:14:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBF951065679; Mon, 27 Feb 2012 18:14:44 +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 5F57A8FC19; Mon, 27 Feb 2012 18:14:44 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1RIEelK028699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Feb 2012 05:14:41 +1100 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.5/8.14.4) with ESMTP id q1RIEddh052643; Tue, 28 Feb 2012 05:14:39 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id q1RIEbNO052642; Tue, 28 Feb 2012 05:14:37 +1100 (EST) (envelope-from peter) Date: Tue, 28 Feb 2012 05:14:37 +1100 From: Peter Jeremy To: Luke Marsden Message-ID: <20120227181436.GA49667@server.vk2pj.dyndns.org> References: <1330081612.13430.39.camel@pow> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <1330081612.13430.39.camel@pow> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org, team@hybrid-logic.co.uk, "freebsd-stable@freebsd.org" Subject: Re: Another ZFS ARC memory question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 18:14:45 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Feb-24 11:06:52 +0000, Luke Marsden = wrote: >We're running 8.2-RELEASE v15 in production on 24GB RAM amd64 machines >but have been having trouble with short spikes in application memory >usage resulting in huge amounts of swapping, bringing the whole machine >to its knees and crashing it hard. I suspect this is because when there >is a sudden spike in memory usage the zfs arc reclaim thread is unable >to free system memory fast enough. There were a large number of fairly serious ZFS bugs that have been fixed since 8.2-RELEASE and I would suggest you look at upgrading. That said, I haven't seen the specific problem you are reporting. > * is this a known problem? I'm unaware of it specifically as it relates to ZFS. You don't mention how big the memory usage spike is but unless there is sufficient free+ cache available to cope with a usage spike then you will have problems whether it's UFS or ZFS (though it's possibly worse with ZFS). FreeBSD is known not to cope well with running out of memory. > * what is the community's advice for production machines running > ZFS on FreeBSD, is manually limiting the ARC cache (to ensure > that there's enough actually free memory to handle a spike in > application memory usage) the best solution to this > spike-in-memory-means-crash problem? Are you swapping onto a ZFS vdev? If so, change back to a raw (or geom) device - swapping to ZFS is known to be problematic. If you have very spiky memory requirements, increasing vm.v_cache_min and/or vm.v_free_reserved might give you better results. > * has FreeBSD 9.0 / ZFS v28 solved this problem? The ZFS code is the same in 9.0 and 8.3. Since 8.3 is less of a jump, I'd recommend that you try 8.3-prerelease in a test box and see how it handles your load. Note that there's no need to upgrade your pools =66rom v15 to v28 unless you want the ZFS features - the actual ZFS code is independent of pool version. > * rather than setting a hard limit on the ARC cache size, is it > possible to adjust the auto-tuning variables to leave more free > memory for spiky memory situations? e.g. set the auto-tuning to > make arc eat 80% of memory instead of ~95% like it is at > present? Memory spikes are absorbed by vm.v_cache_min and vm.v_free_reserved in the first instance. The current vfs.zfs.arc_max default may be a bit high for some workloads but at this point in time, you will need to tune it manually. --=20 Peter Jeremy --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9LyAwACgkQ/opHv/APuIfByQCePnYTXe8GrzcA4RoQTJvLjqOW kRMAoMR9D6Lh6qtHKSqF48Px6HU02Iy2 =u09I -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 18:33:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5580106566C for ; Mon, 27 Feb 2012 18:33:13 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by mx1.freebsd.org (Postfix) with ESMTP id AC30A8FC18 for ; Mon, 27 Feb 2012 18:33:13 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp020.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0M02007NCE724540@asmtp020.mac.com> for freebsd-stable@freebsd.org; Mon, 27 Feb 2012 18:33:03 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-02-27_04:2012-02-27, 2012-02-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1202270189 From: Chuck Swiger In-reply-to: <4F4B0F83.4090600@norma.perm.ru> Date: Mon, 27 Feb 2012 10:33:01 -0800 Message-id: References: <4F4B0F83.4090600@norma.perm.ru> To: "Eugene M. Zheganin" X-Mailer: Apple Mail (2.1084) Cc: "freebsd-stable@freebsd.org" Subject: Re: zfs, 1 gig of RAM and periodic weekly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 18:33:13 -0000 Hi-- On Feb 26, 2012, at 9:07 PM, Eugene M. Zheganin wrote: [ ... ] > all with zfs and one gig of RAM. This isn't a sensible combination; I wouldn't try to run ZFS on anything less than 4GB... Regards, -- -Chuck From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 19:49:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECD551065676 for ; Mon, 27 Feb 2012 19:49:44 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 55A7D8FC1B for ; Mon, 27 Feb 2012 19:49:44 +0000 (UTC) Date: Mon, 27 Feb 2012 20:49:42 +0100 From: vermaden To: Kevin Oberman , smithi@nimnet.asn.au X-Mailer: interia.pl/pf09 In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> X-Originating-IP: 85.89.187.172 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1330372182; bh=PQmv4aaopkZO9/8F9Wr/vcOj2K+QVulhFO7DpLhWg5A=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=g3l36NMHaMlNqza1QEYNHbBwOugtFlvlldDzOZ8UALNFU77pP209Sv7zTgUTgFBeD Pf/ykRzk+wfn0Gf32xm99Xdj8XozajG2noSD2ZlrKNQi4Pij9uDCd/kMna8uIwxaem kSXvqeH1NublfqSq5MFa3ks6gOR9TnT40xXrracw= Cc: Hans Petter Selasky , freebsd-stable@freebsd.org, Ian Smith , lars.engels@0x20.net Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 19:49:45 -0000 Hi, I have been pretty busy lately because of boring things work/life stuff, but here is the new version, with more options of course and some bugs fixed, it now displays help when triggered as 'automount --help', at least a substitute of a man page ;) I have a quastion, which devd(8) events should I 'catch' to enable CD automount? Is there an event for a CD being entered into the CD-ROM at devd(8)? Second question, how to commit a port? I have a working port if I put all needed files when they need to be, but its PITA to install it that way ... Of course latest version is available here: https://github.com/vermaden/automount/ An example usage display: % automount --help =20 AUTOMOUNT is a devd(8) based automounter for FreeBSD. It supports following file systems: UFS/FAT/exFAT/NTFS/EXT2/EXT3/EXT4 It needs these ports to mount NTFS/exFAT/EXT4 respectively: o sysutils/fusefs-ntfs o sysutils/fusefs-exfat o sysutils/fusefs-ext4fuse By default it mounts/unmounts all removable media but it is possible to set some additional options at the /usr/local/etc/automount.conf config file. Below is a list of possible options with description. MNTPREFIX (set to /media by default) With this options You can alter the default root for mounting the removable media, for example to the /mnt directory. example: MNTPREFIX=3D"/media" ENCODING (set to en_US.ISO8859-1 by default) Only used with FAT32 mounts, specifies which encoding to use at the mount. example: ENCODING=3D"pl_PL.ISO8859-2" CODEPAGE (set to cp437 by default) Only used with FAT32 mounts, specifies which code page to use at the mount. example: CODEPAGE=3D"cp852" USER (unset by default) If set to some username, the mount command will chown(1) the mount directory with the user and its primary user group. If used with FM option allows to launch the specified file manager after a successful mount. example: USER=3D"vermaden" FM (unset by default) If set to file manager command, the mount will launch the specified command after successful mount. Works only if USER parameter is also set. example: FM=3D"nautilus --browser --no-desktop" USERUMOUNT (set to NO by default) When set to YES it will 'chmod +s /sbin/umount' which would allow an USER to unmount the file system with their selected file manager. example: USERUMOUNT=3D"YES" ATIME (set to YES by default) When set to NO it will mount filesystems with noatime options when possible. example: ATIME=3D"NO" REMOVEDIRS (set to NO by default) When set to YES it will remove empty directories under the used after device detach. example: REMOVEDIRS=3D"YES" Now for the questions ... >> Added 'noatime' as a default mount option when possible. > Good idea for many use cases, but could that be optional? Its optional now, then ATIME option. >> The USERMOUNT otions if set to YES (default to NO) >> will 'chmod +s /sbin/umount', so You can click the ^ >> button on the devices list in NAUTILUS. > Someone might explain why I needn't feel a bit > uncomfortable about that chmod, even though it is > optional, and even though I've been guilty myself of > a 'chown root:nobody /sbin/tc' on a linux firewall box Well, its optional, You do not have to use it ;) >> These newly mounted devices appear on NAUTILUS >> sidebar (only with /media prefix). > I wonder how it goes with KDE4? (still 3.5 here) Freddie Cash reported that they also appear at Konqueror and Dolphin, both KDE 3.x and 4.x. > Er, who's user 1000 ? Another config item perhaps? > Or should that be the particular user currently > invoking the script via devd (if that can be determined?)? It was 'development' branch ;) I tried many things then, its now a configurable option as USER. > Also, are you using sysctl vfs.usermount=3D1? No, its not needed, the mount is done by root and umount even by user with USERUMOUNT=3DYES does not require the vfs.usermount=3D1 option. > Mmm, fsck on every attachment? Maybe running > fsck should be optional? We might be attaching, > perhaps, a 2TB backup HD? .. > Ouch! I agree. Why not just fsck_ufs -p. (I realize > this is done to fix systems that were unplugged > rather than umounted, but it's a pretty expensive > operation when not needed. I have added -C option to fsck for UFS, so it will onlt check filesystem if clean flag is not set. >> mount -o noatime ${I} ${MNT} > Again, I'd rather see that optional in an intended > system tool, although it's an option I'd tend to use myself. Its optional now with ATIME option. >> find ${MNTPREFIX} -type d -empty -delete > I don't see the need to remove all empty subdirs > of, say, /media - this tool may not be the only > thing wanting to manage that space? Removing=20 > directories that were added by this tool itself > makes sense of course. It only removed EMPTY directories, which was mostly harmless, but I made it to not delete them by default and added an option to enable that as well. > Looks like a neat gadget, don't mind me picking > up on a few aspects :) Thanks mate, try latest version ;) >> I don't see the need to remove all empty subdirs >> of, say, /media - this tool may not be the only >> thing wanting to manage that space? =C2=A0Removing >> directories that were added by this tool itself >> makes sense of course. =20 > This is an interesting one. Gnome and hald have > a problem here that have caused me to add sudo > /bin/rmdir /media/* to.xinitrc to work around. > It's just too easy for 'junk' directories to live on > when the system does not exit everything cleanly > and, while hald tries to keep track, it is very hard > to do in the real world. I suspect it is really > needed. And what else is creating directories in > /media? I made it configurable via option if someone has a habbit to put other things over there ;) Thanks for interesting input mates, king regards, vermaden ... From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 20:06:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 939B2106564A for ; Mon, 27 Feb 2012 20:06:34 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) by mx1.freebsd.org (Postfix) with ESMTP id 089AC8FC12 for ; Mon, 27 Feb 2012 20:06:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=cAsFTh73g/SZKpNDNjRxK47WP1k7kzBKRBBNioL+bXA=; b=ODrZvELTBlAAdMyF0b/fcmepCwJIgnJIGk+kVLYT4xR5vpVWt139tZeF1JiatI1ZK2rvCNj5PYBnrguhDFgkiRMreXH46DXM13AzxyIB5i6qtqUJl3QUTenpVPpok6dJ5V9TnV/dLcrT+LrV/au6ukDfyu9NzxUym//OGjxRgOI=; Received: from [178.137.138.140] (helo=nonamehost.) by fsm1.ukr.net with esmtpsa ID 1S26pi-0006Rj-Lt ; Mon, 27 Feb 2012 22:06:06 +0200 Date: Mon, 27 Feb 2012 22:06:05 +0200 From: Ivan Klymenko To: vermaden Message-ID: <20120227220605.57dc1639@nonamehost.> In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, lars.engels@0x20.net, Selasky , Hans, smithi@nimnet.asn.au Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 20:06:34 -0000 > Hi, > > I have been pretty busy lately because of boring things > work/life stuff, but here is the new version, with more > options of course and some bugs fixed, it now displays > help when triggered as 'automount --help', at least a > substitute of a man page ;) > > I have a quastion, which devd(8) events should I 'catch' > to enable CD automount? Is there an event for a CD being > entered into the CD-ROM at devd(8)? > Unfortunately, I spent a few days that would have to understand how it is possible to detect the inserted CD-ROM with devd; but alas - the only thing that detects changes in the drive CD-ROM - a : sysctl kern.geom.conftxt before inserting the disc: kern.geom.conftxt: 0 DISK cd0 0 2048 hd 0 sc 0 ... after inserting the disc: kern.geom.conftxt: 0 DISK cd0 4700372992 2048 hd 0 sc 0 ... From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 20:07:39 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1073106566C for ; Mon, 27 Feb 2012 20:07:39 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 39D368FC25 for ; Mon, 27 Feb 2012 20:07:38 +0000 (UTC) Received: by werl4 with SMTP id l4so1077987wer.13 for ; Mon, 27 Feb 2012 12:07:38 -0800 (PST) Received-SPF: pass (google.com: domain of kob6558@gmail.com designates 10.180.80.40 as permitted sender) client-ip=10.180.80.40; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kob6558@gmail.com designates 10.180.80.40 as permitted sender) smtp.mail=kob6558@gmail.com; dkim=pass header.i=kob6558@gmail.com Received: from mr.google.com ([10.180.80.40]) by 10.180.80.40 with SMTP id o8mr30811007wix.10.1330373258113 (num_hops = 1); Mon, 27 Feb 2012 12:07:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c9p1Je5ngVcw2b+k14Xq9khLZmU3l1WI7koDBO3Dpz4=; b=dD9Hh8b7gEy/Z+tfOl1IWl8OwBVz34Txh1/oS6T7bWQk8/8uPxPXqhGnsi6eetfUlw qh8cYCW1piH7Xq5yn+5frAOyOtw2dHkTQcwMZXRt7/YaglseKLfK3pHqs8cWJFoyHGpD L9A1jmLpNkz3FcEjnyW3DK0p0ClAtJ0/jqDXQ= MIME-Version: 1.0 Received: by 10.180.80.40 with SMTP id o8mr24381304wix.10.1330373257994; Mon, 27 Feb 2012 12:07:37 -0800 (PST) Received: by 10.223.16.82 with HTTP; Mon, 27 Feb 2012 12:07:37 -0800 (PST) In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> Date: Mon, 27 Feb 2012 12:07:37 -0800 Message-ID: From: Kevin Oberman To: vermaden Content-Type: text/plain; charset=ISO-8859-1 Cc: Hans Petter Selasky , freebsd-stable@freebsd.org, smithi@nimnet.asn.au, lars.engels@0x20.net Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 20:07:39 -0000 On Mon, Feb 27, 2012 at 11:49 AM, vermaden wrote: > Hi, > > I have been pretty busy lately because of boring things > work/life stuff, but here is the new version, with more > options of course and some bugs fixed, it now displays > help when triggered as 'automount --help', at least a > substitute of a man page ;) > Second question, how to commit a port? I have a working > port if I put all needed files when they need to be, but > its PITA to install it that way ... Have you read the Porter's Handbook (http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook)? It tells you how to make a good port, how to test it (though I don't think it has anything on redports, yet), and how to submit it. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 20:36:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64EAC106567A for ; Mon, 27 Feb 2012 20:36:47 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 0D9808FC17 for ; Mon, 27 Feb 2012 20:36:46 +0000 (UTC) Date: Mon, 27 Feb 2012 21:36:46 +0100 From: vermaden To: Kevin Oberman , fidaj@ukr.net X-Mailer: interia.pl/pf09 In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> X-Originating-IP: 85.89.187.172 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1330375006; bh=GdcMR2JFhpg/jA5fEdD2GJwE6nvsTX10bo7z35kPbiI=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=uQtnOIuDrfhOMr5hJPon0EfOxuwoUg1xNRypcjPoiRXZp9/hcLbq5brK1TCpFkmOT D4bEfY2giiZUgnX7Pn0PAANdnB3eJxmJGY/TRR2ReBNI6x13rV3qjWScEcE0fABt+v GfH9CeTABF2jG5ejDxUcmVv6rdgl+V3/D5e+4gRw= Cc: Hans Petter Selasky , freebsd-stable@freebsd.org, smithi@nimnet.asn.au, lars.engels@0x20.net Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 20:36:47 -0000 > Have you read the Porter's Handbook > (http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook)? > It tells you how to make a good port, > how to test it (though I don't think > it has anything on redports, yet), and > how to submit it. I have tried both developers and porters handbooks but havent found info what to do to 'commit' this as a port, should I just submit a PR? > Unfortunately, I spent a few days that would > have to understand how it is possible to > detect the inserted CD-ROM with devd; but > alas - the only thing that detects changes > in the drive CD-ROM - a :sysctl kern.geom.conftxt >=20 > before inserting the disc: > kern.geom.conftxt: 0 DISK cd0 0 2048 hd 0 sc 0 > ... >=20 > after inserting the disc: > kern.geom.conftxt: 0 DISK cd0 4700372992 2048 hd 0 sc 0 Thanks, at least we have 'something' we can cepend on. I can create an 'active wait' daemon for that, like the skel below: while sleep 3 do case $( sysctl -n kern.geom.conftxt ) in (0 DISK cd0 0 2048 hd 0 sc 0) echo "No CD in the drive ..." # umount procedure ... ;; (0 DISK cd0 * * hd 0 sc 0) echo "We have CD here!" # do something about it lile mount_cd9660 ;; esac done But a devd(8) event would be far better, maybe some somple commit to devd(8= ) would help here? My knowledge does not allow me to add these bits to devd= (8). Regards, vermaden From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 20:52:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEED21065753 for ; Mon, 27 Feb 2012 20:52:33 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) by mx1.freebsd.org (Postfix) with ESMTP id 76D108FC0C for ; Mon, 27 Feb 2012 20:52:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=jpDuR2OdCCarM2D54VtrcK5P//Vf3LFuXFClH8Xl7ZY=; b=K1uEOAKPBQVlY7ol8c6Ghyen8XG5cQhIb4dU/54upR6fKgIX6BtBNbQgTeOK4221KfUsBrxlSy5Mko5rNvXiDIqsHvseKQL1KWz7jnuisFQYwWxrYjWXhcmlNhHyia9T6qY8zYmy/KdQjM7YhtVdbqb2LpKa9p/xTipIJkQCBVY=; Received: from [178.137.138.140] (helo=nonamehost.) by fsm1.ukr.net with esmtpsa ID 1S27YM-000Elh-Mx ; Mon, 27 Feb 2012 22:52:14 +0200 Date: Mon, 27 Feb 2012 22:52:13 +0200 From: Ivan Klymenko To: vermaden Message-ID: <20120227225213.426e64da@nonamehost.> In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Hans Petter Selasky , freebsd-stable@freebsd.org, smithi@nimnet.asn.au, lars.engels@0x20.net Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 20:52:33 -0000 > > Unfortunately, I spent a few days that would > > have to understand how it is possible to > > detect the inserted CD-ROM with devd; but > > alas - the only thing that detects changes > > in the drive CD-ROM - a :sysctl kern.geom.conftxt > > > > before inserting the disc: > > kern.geom.conftxt: 0 DISK cd0 0 2048 hd 0 sc 0 > > ... > > > > after inserting the disc: > > kern.geom.conftxt: 0 DISK cd0 4700372992 2048 hd 0 sc 0 > > Thanks, at least we have 'something' we can cepend on. > > I can create an 'active wait' daemon for that, like the skel below: > > while sleep 3 > do > case $( sysctl -n kern.geom.conftxt ) in > (0 DISK cd0 0 2048 hd 0 sc 0) > echo "No CD in the drive ..." > # umount procedure ... > ;; > (0 DISK cd0 * * hd 0 sc 0) > echo "We have CD here!" > # do something about it lile mount_cd9660 > ;; > esac > done > unfortunately it will not work properly because the value will only change, but will never be equal to "0" after inserting the first CD-ROM drive. :( > But a devd(8) event would be far better, certainly > maybe some somple commit to > devd(8) would help here? My knowledge does not allow me to add these > bits to devd(8). > From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 22:41:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0BDC1065675 for ; Mon, 27 Feb 2012 22:41:47 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id 846D48FC08 for ; Mon, 27 Feb 2012 22:41:47 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 25B241CC71; Mon, 27 Feb 2012 16:02:27 -0300 (BRT) Received: from 189.125.47.37 (proxying for 10.12.1.211, 10.12.0.102, 10.30.1.12) (SquirrelMail authenticated user matheus) by 109.169.62.232 with HTTP; Mon, 27 Feb 2012 16:02:27 -0300 Message-ID: <977febd5710ecac8cd9ea374ca0193f4.squirrel@109.169.62.232> In-Reply-To: References: <4F4B0F83.4090600@norma.perm.ru> Date: Mon, 27 Feb 2012 16:02:27 -0300 From: "Nenhum_de_Nos" Cc: "freebsd-stable@freebsd.org" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: zfs, 1 gig of RAM and periodic weekly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 22:41:47 -0000 On Mon, February 27, 2012 15:33, Chuck Swiger wrote: > Hi-- > > On Feb 26, 2012, at 9:07 PM, Eugene M. Zheganin wrote: > [ ... ] >> all with zfs and one gig of RAM. > > This isn't a sensible combination; I wouldn't try to run ZFS on anything less than 4GB... regardless of the pool size ? I was planning on making an atom board a file server for my home, and I have two options: soekris net6501 2GB RAM and intel board powered by the 330 atom (says 2GB limited as well). My plans are to use from 4 up to 8 disks, and they should be 2TB at least. As its for home use, some p2p software and mostly music listening and sometimes movie streaming. should 2GB be that bad, that I should drop it and use UFS instead ? I may run any version of FreeBSD on it, was planning on 9-STABLE or 9.1. thanks, matheus -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 22:48:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FF141065672 for ; Mon, 27 Feb 2012 22:48:06 +0000 (UTC) (envelope-from fjwcash@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 E2E378FC14 for ; Mon, 27 Feb 2012 22:48:05 +0000 (UTC) Received: by vbmv11 with SMTP id v11so1499492vbm.13 for ; Mon, 27 Feb 2012 14:48:05 -0800 (PST) Received-SPF: pass (google.com: domain of fjwcash@gmail.com designates 10.52.176.130 as permitted sender) client-ip=10.52.176.130; Authentication-Results: mr.google.com; spf=pass (google.com: domain of fjwcash@gmail.com designates 10.52.176.130 as permitted sender) smtp.mail=fjwcash@gmail.com; dkim=pass header.i=fjwcash@gmail.com Received: from mr.google.com ([10.52.176.130]) by 10.52.176.130 with SMTP id ci2mr9086090vdc.33.1330382885406 (num_hops = 1); Mon, 27 Feb 2012 14:48:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MqMl5XUPxRAEHpSHpoj0YkBYayhc6KJUucimiZti1wE=; b=pJso2Xnjqc//U7J2q6FTI/fCSCBIEIn3mqaO1xqjZY6gjjbzFdZcEsaeQozEIV4Mp6 W7Cvpgnf754ZI1TNe5P68VpBJ5+/NC3LlFv/PApPG6QQ7W6t1nBAoeDWaNAOoiZeoRWY O+9eCAYavc+aMWoO6gpbC98oqN8XSPGctE2MU= MIME-Version: 1.0 Received: by 10.52.176.130 with SMTP id ci2mr7451478vdc.33.1330382885100; Mon, 27 Feb 2012 14:48:05 -0800 (PST) Received: by 10.220.178.74 with HTTP; Mon, 27 Feb 2012 14:48:05 -0800 (PST) In-Reply-To: <977febd5710ecac8cd9ea374ca0193f4.squirrel@109.169.62.232> References: <4F4B0F83.4090600@norma.perm.ru> <977febd5710ecac8cd9ea374ca0193f4.squirrel@109.169.62.232> Date: Mon, 27 Feb 2012 14:48:05 -0800 Message-ID: From: Freddie Cash To: Nenhum_de_Nos Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-stable@freebsd.org" Subject: Re: zfs, 1 gig of RAM and periodic weekly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 22:48:06 -0000 On Mon, Feb 27, 2012 at 11:02 AM, Nenhum_de_Nos wrote: > On Mon, February 27, 2012 15:33, Chuck Swiger wrote: >> On Feb 26, 2012, at 9:07 PM, Eugene M. Zheganin wrote: >> [ ... ] >>> all with zfs and one gig of RAM. >> >> This isn't a sensible combination; I wouldn't try to run ZFS on anything less than 4GB... > > regardless of the pool size ? > > I was planning on making an atom board a file server for my home, and I have two options: soekris > net6501 2GB RAM and intel board powered by the 330 atom (says 2GB limited as well). My plans are > to use from 4 up to 8 disks, and they should be 2TB at least. > > As its for home use, some p2p software and mostly music listening and sometimes movie streaming. > > should 2GB be that bad, that I should drop it and use UFS instead ? > > I may run any version of FreeBSD on it, was planning on 9-STABLE or 9.1. You can get away with 2 GB of RAM, if you spend a lot of time manually tuning things to prevent kmem exhaustion and prevent ZFS ARC from starving the rest of the system (especially on the network side of things). Definitely go with a 64-bit install. Even with less than 4 GB of RAM, you'll benefit from the large kmem size and better auto-tuning. Do not, under any circumstances, enable dedupe on a system with less than 16 GB of RAM. :) If at all possible, find a motherboard that will let you use more RAM. 2 GB is usable. But 4 GB is the sweet spot for a simple file server. And 16 GB is best for a system with over 10 TB of storage in the pool. My home media server is a 32-bit install of FreeBSD 8-STABLE (Dec 2011 vintage) with only 2 GB of RAM, using 4x 500 GB SATA drives in 2 mirror vdevs (boot off USB stick). Every couple of weeks it'll lock up, usually under heavy torrent load. Prior to doing a bunch of "tune loader.conf; reboot; crash; repeat" cycles, the box was very unstable. 2 GB is barely enough for ZFS + NFS + Samba + torrents + whatever. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Feb 27 23:40:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E271106566B for ; Mon, 27 Feb 2012 23:40:46 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id E2F498FC13 for ; Mon, 27 Feb 2012 23:40:45 +0000 (UTC) Received: (qmail 95677 invoked by uid 0); 27 Feb 2012 23:40:45 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Feb 2012 23:40:45 -0000 Received: (qmail 95665 invoked by uid 90); 27 Feb 2012 23:40:44 -0000 Received: from unknown (HELO ?10.3.2.40?) (spork@96.57.144.66) by smtp.bway.net with (AES128-SHA encrypted) SMTP; 27 Feb 2012 23:40:44 -0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Charles Sprickman In-Reply-To: Date: Mon, 27 Feb 2012 18:40:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F4B0F83.4090600@norma.perm.ru> <977febd5710ecac8cd9ea374ca0193f4.squirrel@109.169.62.232> To: Freddie Cash X-Mailer: Apple Mail (2.1084) Cc: "freebsd-stable@freebsd.org" , Nenhum_de_Nos Subject: Re: zfs, 1 gig of RAM and periodic weekly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Feb 2012 23:40:46 -0000 On Feb 27, 2012, at 5:48 PM, Freddie Cash wrote: > On Mon, Feb 27, 2012 at 11:02 AM, Nenhum_de_Nos > wrote: >> On Mon, February 27, 2012 15:33, Chuck Swiger wrote: >>> On Feb 26, 2012, at 9:07 PM, Eugene M. Zheganin wrote: >>> [ ... ] >>>> all with zfs and one gig of RAM. >>>=20 >>> This isn't a sensible combination; I wouldn't try to run ZFS on = anything less than 4GB... >>=20 >> regardless of the pool size ? >>=20 >> I was planning on making an atom board a file server for my home, and = I have two options: soekris >> net6501 2GB RAM and intel board powered by the 330 atom (says 2GB = limited as well). My plans are >> to use from 4 up to 8 disks, and they should be 2TB at least. >>=20 >> As its for home use, some p2p software and mostly music listening and = sometimes movie streaming. >>=20 >> should 2GB be that bad, that I should drop it and use UFS instead ? >>=20 >> I may run any version of FreeBSD on it, was planning on 9-STABLE or = 9.1. >=20 > You can get away with 2 GB of RAM, if you spend a lot of time manually > tuning things to prevent kmem exhaustion and prevent ZFS ARC from > starving the rest of the system (especially on the network side of > things). >=20 > Definitely go with a 64-bit install. Even with less than 4 GB of RAM, > you'll benefit from the large kmem size and better auto-tuning. >=20 > Do not, under any circumstances, enable dedupe on a system with less > than 16 GB of RAM. :) >=20 > If at all possible, find a motherboard that will let you use more RAM. > 2 GB is usable. But 4 GB is the sweet spot for a simple file server. > And 16 GB is best for a system with over 10 TB of storage in the > pool. >=20 > My home media server is a 32-bit install of FreeBSD 8-STABLE (Dec 2011 > vintage) with only 2 GB of RAM, using 4x 500 GB SATA drives in 2 > mirror vdevs (boot off USB stick). Every couple of weeks it'll lock > up, usually under heavy torrent load. Prior to doing a bunch of "tune > loader.conf; reboot; crash; repeat" cycles, the box was very unstable. > 2 GB is barely enough for ZFS + NFS + Samba + torrents + whatever. Sounds very familiar. Substitute afp for samba and torrents for sabnzbd furiously unpacking things and we're probably doing much the same. 3 = 1TB Samsungs (+1 spare), 2 gmirror'd CF cards for boot. [spork@media ~]$ uptime 6:41PM up 60 days, 8:36, 1 user, load averages: 0.00, 0.02, 0.00 [spork@media ~]$ zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT tank1 2.72T 1.89T 850G 69% ONLINE - [spork@media ~]$ grep avail /var/run/dmesg.boot=20 avail memory =3D 2087931904 (1991 MB) [spork@media ~]$ uname -a FreeBSD media..com 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Tue Feb 22 = 04:44:55 EST 2011 spork@media..com:/usr/obj/usr/src/sys/MEDIA i386 Just in case I've hit on some special sauce in the loader.conf, here you go: [spork@media ~]$ cat /boot/loader.conf=20 zfs_load=3D"YES" #vfs.root.mountfrom=3D"zfs:zroot" vm.kmem_size_max=3D"1000M" vm.kmem_size=3D"1000M" vfs.zfs.arc_max=3D"200M" I used to be able to panic it regularly, but I just kept stepping the=20 kmem up and the arc down until it behaved. The uptime would be longer if my power wasn't as flakey. Charles >=20 > --=20 > Freddie Cash > fjwcash@gmail.com > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 01:38:48 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10D14106564A; Tue, 28 Feb 2012 01:38:48 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (r2b9.nsu.ru [212.192.164.39]) by mx1.freebsd.org (Postfix) with ESMTP id 9F96C8FC12; Tue, 28 Feb 2012 01:38:47 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1S2Bkq-0004D4-Vz; Tue, 28 Feb 2012 08:21:25 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q1S1QlV0026879; Tue, 28 Feb 2012 08:26:47 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q1S1QDe3026850; Tue, 28 Feb 2012 08:26:14 +0700 (NOVT) (envelope-from danfe) Date: Tue, 28 Feb 2012 08:26:13 +0700 From: Alexey Dokuchaev To: Jung-uk Kim Message-ID: <20120228012613.GA24712@regency.nsu.ru> References: <20120227152238.GA2940@regency.nsu.ru> <134870242.175249.1330357669745.JavaMail.root@erie.cs.uoguelph.ca> <20120227164733.GA12679@regency.nsu.ru> <201202271246.09674.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201202271246.09674.jkim@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@FreeBSD.org Subject: Re: Resume broken in 8.3-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: Tue, 28 Feb 2012 01:38:48 -0000 On Mon, Feb 27, 2012 at 12:46:07PM -0500, Jung-uk Kim wrote: > Can you please try head and/or stable/9? FYI, Linux people found that > some BIOSes can corrupt low 64KB between suspend/resume, which may > cause strangeness like this. I worked around it in head (r231781) > and stable/9 (r232088). Frankly speaking, last time I tried next stable to my running branch (not to mention head) I've gained more problems than solutions. :-) For example, when this laptop of mine was running stable/7 suspend/resume was working for months. I only (reluctantly) switched to stable/8 as I've noticed it's getting more attention that 7.x series, and annoying people with "please MFC it to 7.x!" calls does not look particularly nice. I remember that commit of your, though. I will try to backport at and report of the results, thanks! ./danfe From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 02:46:03 2012 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 BAF9F106566C; Tue, 28 Feb 2012 02:46:03 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (unknown [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b2]) by mx1.freebsd.org (Postfix) with ESMTP id 59B0D8FC0A; Tue, 28 Feb 2012 02:46:03 +0000 (UTC) Received: from meatwad.mouf.net (cpe-024-162-230-236.nc.res.rr.com [24.162.230.236]) (authenticated bits=0) by mouf.net (8.14.4/8.14.4) with ESMTP id q1S2jxLk051404 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 27 Feb 2012 21:46:00 -0500 (EST) (envelope-from swills@FreeBSD.org) Message-ID: <4F4C3FE7.3040802@FreeBSD.org> Date: Mon, 27 Feb 2012 21:45:59 -0500 From: Steve Wills User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111228 Thunderbird/9.0 MIME-Version: 1.0 To: =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> In-Reply-To: <4F4BA707.5070608@wasikowski.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mouf.net [204.109.58.86]); Mon, 27 Feb 2012 21:46:02 -0500 (EST) X-Virus-Scanned: clamav-milter 0.97.2 at mouf.net X-Virus-Status: Clean Cc: "Bjoern A. Zeeb" , stable@FreeBSD.org, current@FreeBSD.org, Alexander Leidinger Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 02:46:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/27/12 10:53, Åukasz WÄ…sikowski wrote: > W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze: > >> You cannot ship that on by default for non-tecnical reasons in a >> kernel. Please do not commit a kernel config that can be booted >> (no LINT cannot be booted) with these on without consulting >> appropriate hats upfront. >> >> >>> - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in >>> loader.conf) - IPFIREWALL_FORWARD (touches every packet, power >>> users which need a bigger PPS but not this feature can >>> recompile the kernel, discussed with julian@) - FLOWTABLE >>> (disabled in loader.conf) >> Which is not the same as it's not 100% disabled and will still >> allocate memory. > > FLOWTABLE on 8.x crashed BGP routers (kern/144917). I don't know if > it is fixed by now, but this kind of potential problematic features > should not be enabled by default. > Agree, I've run into problems with FLOWTABLE (with just the features that were enabled by default in 8.0) when routers changed MAC addresses. As far as I understand it, FLOWTABLE is both broken and abandoned (but if I'm wrong, please let me know). So, IMHO, not only should it not be enabled by default, but given that it was disabled complete in 8.x after 8.0 (too lazy to look at exactly when right now), I think it shouldn't even be included, since that might encourage users to try it out only to encounter problems with it. Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJPTD/nAAoJEPXPYrMgexuhvWAH/iPa0N32GJXdyL7OdqFNNuEN R/Z0tOqTCCmAm4WsbAbN3m5poBKNctRtQxG40XoqmvZAWlomwYCwpS2xgCX60NZO XhspUEpQ7cHQpt6ZOW12x3G6FZJ4DzFX0+mDPYxE/7YmwtsjZFeTFGVEPezeKQwr Khar5jWYqETmM1+mFvAFXnfTUiBwnqErDfYmHQAE93wKQd9CyzrFmDfooNTiMUB6 yW+piexN/SzXz6nftQesJbFOWUW6fvhxe9TYcK8+b9zCo2GxPuUrRV60PKQX0apd nlKWtj49znLVzmpTYboQnvmqmk+yik8wL2wszUaZ4jAjieCjWOhJwCWOvkQ9yIg= =SBbK -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 04:10:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C258106566B for ; Tue, 28 Feb 2012 04:10:41 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id B9EC48FC0A for ; Tue, 28 Feb 2012 04:10:40 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7fc]) by elf.hq.norma.perm.ru (8.14.4/8.14.4) with ESMTP id q1S4AUwn002988 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 28 Feb 2012 09:10:30 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4F4C53B6.6060909@norma.perm.ru> Date: Tue, 28 Feb 2012 10:10:30 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20111001 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F4B0F83.4090600@norma.perm.ru> <977febd5710ecac8cd9ea374ca0193f4.squirrel@109.169.62.232> In-Reply-To: <977febd5710ecac8cd9ea374ca0193f4.squirrel@109.169.62.232> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Tue, 28 Feb 2012 09:10:30 +0500 (YEKT) X-Spam-Status: No hits=-98.5 bayes=0.5 testhits RDNS_NONE=0.793, SPF_SOFTFAIL=0.665,TO_NO_BRKTS_NORDNS=0.001,USER_IN_WHITELIST=-100 autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Subject: Re: zfs, 1 gig of RAM and periodic weekly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 04:10:41 -0000 Hi. On 28.02.2012 01:02, Nenhum_de_Nos wrote: > regardless of the pool size ? > > I was planning on making an atom board a file server for my home, and I have two options: soekris > net6501 2GB RAM and intel board powered by the 330 atom (says 2GB limited as well). My plans are > to use from 4 up to 8 disks, and they should be 2TB at least. > > As its for home use, some p2p software and mostly music listening and sometimes movie streaming. > > should 2GB be that bad, that I should drop it and use UFS instead ? > > I may run any version of FreeBSD on it, was planning on 9-STABLE or 9.1. > In the same time I have a couple of hosts successfully running zfs on 768 Megs and on 1 Gig of RAM. Both i386. And they aren't affected by the periodic weekly for some reason. And they are used only as fileservers. So when I see all these advices to add a gazillion gigabytes of RAM to use zfs - I don't see the connection. Eugene. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 04:26:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C19541065675 for ; Tue, 28 Feb 2012 04:26:22 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id 970838FC23 for ; Tue, 28 Feb 2012 04:26:22 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 07DD21CC71; Tue, 28 Feb 2012 01:26:20 -0300 (BRT) Received: from 177.99.66.86 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Tue, 28 Feb 2012 01:26:20 -0300 Message-ID: <38504ab18af5ef1502c8cccba656c72c.squirrel@eternamente.info> Date: Tue, 28 Feb 2012 01:26:20 -0300 From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: zfs, 1 gig of RAM and periodic weekly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 04:26:22 -0000 On Tue, February 28, 2012 01:10, Eugene M. Zheganin wrote: > Hi. > > On 28.02.2012 01:02, Nenhum_de_Nos wrote: >> regardless of the pool size ? >> >> I was planning on making an atom board a file server for my home, and I have two options: soekris >> net6501 2GB RAM and intel board powered by the 330 atom (says 2GB limited as well). My plans are to use from 4 up to 8 disks, and they should be 2TB at least. >> >> As its for home use, some p2p software and mostly music listening and sometimes movie streaming. >> >> should 2GB be that bad, that I should drop it and use UFS instead ? >> >> I may run any version of FreeBSD on it, was planning on 9-STABLE or 9.1. >> > In the same time I have a couple of hosts successfully running zfs on 768 Megs and on 1 Gig of RAM. Both i386. > And they aren't affected by the periodic weekly for some reason. And they are used only as fileservers. > > So when I see all these advices to add a gazillion gigabytes of RAM to use zfs - I don't see the connection. Eugene, what's the pool size ? I'd like to use one using 4x 2TB disks (may be 3TB). and other using random disks that may evolve to that same amount. matheus -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 04:28:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03B341065675 for ; Tue, 28 Feb 2012 04:28:00 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 774658FC08 for ; Tue, 28 Feb 2012 04:27:59 +0000 (UTC) Received: by werl4 with SMTP id l4so1312370wer.13 for ; Mon, 27 Feb 2012 20:27:58 -0800 (PST) Received-SPF: pass (google.com: domain of kob6558@gmail.com designates 10.180.99.7 as permitted sender) client-ip=10.180.99.7; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kob6558@gmail.com designates 10.180.99.7 as permitted sender) smtp.mail=kob6558@gmail.com; dkim=pass header.i=kob6558@gmail.com Received: from mr.google.com ([10.180.99.7]) by 10.180.99.7 with SMTP id em7mr34593502wib.7.1330403278403 (num_hops = 1); Mon, 27 Feb 2012 20:27:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P7kQm3BNfjGHuTEBsp+PiXX5NUKVJNUU7PRapbmDDc8=; b=cEr3aRn/8kvh6PuRgo9JyPpeSyr0BQKVdtw1ToapIJ1rtnRubPe7DOQcn3qmRTpRRZ cRY4GjAD0ZvkJDdBZ9LAZPKZvfru2YcYXgVviqT8b2n0i74TEaAA+1qUTKE0sLOcmFGV lsYJly136LWqC5rdXYZklnEpxGueULXkrwvsQ= MIME-Version: 1.0 Received: by 10.180.99.7 with SMTP id em7mr27393729wib.7.1330403278310; Mon, 27 Feb 2012 20:27:58 -0800 (PST) Received: by 10.223.16.82 with HTTP; Mon, 27 Feb 2012 20:27:58 -0800 (PST) In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> Date: Mon, 27 Feb 2012 20:27:58 -0800 Message-ID: From: Kevin Oberman To: vermaden Content-Type: text/plain; charset=ISO-8859-1 Cc: fidaj@ukr.net, Hans Petter Selasky , freebsd-stable@freebsd.org, smithi@nimnet.asn.au, lars.engels@0x20.net Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 04:28:00 -0000 On Mon, Feb 27, 2012 at 12:36 PM, vermaden wrote: >> Have you read the Porter's Handbook >> (http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook)? >> It tells you how to make a good port, >> how to test it (though I don't think >> it has anything on redports, yet), and >> how to submit it. > > I have tried both developers and porters handbooks > but havent found info what to do to 'commit' this > as a port, should I just submit a PR? 3.6 Submitting the New Port You submit the port to he ports team and, after review by a ports committer, the port will be added. The cited section describes exactly how to go about it. Be sure that it passes portlint(1) before you submit. Thanks for you work on this. I'm looking forward to seeing it as a port. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 04:38:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE255106564A for ; Tue, 28 Feb 2012 04:38:14 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 326A08FC08 for ; Tue, 28 Feb 2012 04:38:13 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7fc]) by elf.hq.norma.perm.ru (8.14.4/8.14.4) with ESMTP id q1S4c31S005202 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 28 Feb 2012 09:38:10 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4F4C5A2B.1040004@norma.perm.ru> Date: Tue, 28 Feb 2012 10:38:03 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20111001 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F4B0F83.4090600@norma.perm.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Tue, 28 Feb 2012 09:38:12 +0500 (YEKT) X-Spam-Status: No hits=-98.5 bayes=0.5 testhits RDNS_NONE=0.793, SPF_SOFTFAIL=0.665,TO_NO_BRKTS_NORDNS=0.001,USER_IN_WHITELIST=-100 autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Subject: Re: zfs, 1 gig of RAM and periodic weekly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 04:38:14 -0000 Hi. On 27.02.2012 20:42, Johannes Totz wrote: > You could try to narrow it down to one specific script. My first guess > is that 310.locate brings the machine down as it traverses the whole tree. > You're absolutely right. Eugene. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 07:19:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5ED961065670 for ; Tue, 28 Feb 2012 07:19:01 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 0E0068FC13 for ; Tue, 28 Feb 2012 07:19:00 +0000 (UTC) Date: Tue, 28 Feb 2012 08:18:59 +0100 From: vermaden To: Kevin Oberman X-Mailer: interia.pl/pf09 In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> X-Originating-IP: 194.0.181.128 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1330413539; bh=mUPN+UiS8KBe/huT640vzpV4RNu6QLtv+qDPEDbk5WY=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=laZJV0BVfX+Bi7L8Fp4/qCQ+MIo0yvMJcSRaV7q1wO1h7udWlT1BcT/zOq5SDVx9S pl/KBtsPt9g1LfaemWN5fRAOSg+gVY/jjgRLn4RtECW1c1HBqbjrfTDdaeNlCRqtsx 34fvuv7LQ460xdcfbF1eYBrthr6mNdeRUxFQzCYU= Cc: fidaj@ukr.net, Hans Petter Selasky , freebsd-stable@freebsd.org, smithi@nimnet.asn.au, lars.engels@0x20.net Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 07:19:01 -0000 > 3.6 Submitting the New Port > You submit the port to he ports team and, after review by a ports > committer, the port will be added. The cited section describes exactly > how to go about it. Be sure that it passes portlint(1) before you > submit. It seems that I was little to tired to figure that out yesterday :( > Thanks for you work on this. I'm looking forward to seeing it as a port. Welcome, I finally submited the port, here is the PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/165522 Regards, vermaden ... From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 08:22:54 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84C0E106566C for ; Tue, 28 Feb 2012 08:22:54 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.freebsd.org (Postfix) with ESMTP id EE0218FC14 for ; Tue, 28 Feb 2012 08:22:53 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1S8MiMv025615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Feb 2012 19:22:44 +1100 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.5/8.14.4) with ESMTP id q1S8MiYb063811; Tue, 28 Feb 2012 19:22:44 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id q1S8Mgr5063810; Tue, 28 Feb 2012 19:22:42 +1100 (EST) (envelope-from peter) Date: Tue, 28 Feb 2012 19:22:42 +1100 From: Peter Jeremy To: Freddie Cash Message-ID: <20120228082242.GC62432@server.vk2pj.dyndns.org> References: <4F4B0F83.4090600@norma.perm.ru> <977febd5710ecac8cd9ea374ca0193f4.squirrel@109.169.62.232> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org" , Nenhum_de_Nos Subject: Re: zfs, 1 gig of RAM and periodic weekly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 08:22:54 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Feb-27 14:48:05 -0800, Freddie Cash wrote: >You can get away with 2 GB of RAM, if you spend a lot of time manually >tuning things to prevent kmem exhaustion and prevent ZFS ARC from >starving the rest of the system (especially on the network side of >things). I run a system with ZFS and 2GB RAM (though only 40GB disk) without any major tuning (AFAIR, I've only adjusted vfs.zfs.arc_max). That said, more RAM would be better. >Definitely go with a 64-bit install. Even with less than 4 GB of RAM, >you'll benefit from the large kmem size and better auto-tuning. I'd strongly recommend against running ZFS on i386 as anything other than an experiment. --=20 Peter Jeremy --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9MjtIACgkQ/opHv/APuIcJOwCePTlCTPdUmnSSmVPJPAlzcJYN 0xwAn0AVrIp6etH/fNzxQHmALZdxYUd+ =/L4X -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 10:01:32 2012 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 D83361065670; Tue, 28 Feb 2012 10:01:32 +0000 (UTC) (envelope-from slackbie@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8A77C8FC17; Tue, 28 Feb 2012 10:01:32 +0000 (UTC) Received: by iahk25 with SMTP id k25so73476iah.13 for ; Tue, 28 Feb 2012 02:01:31 -0800 (PST) Received-SPF: pass (google.com: domain of slackbie@gmail.com designates 10.50.153.166 as permitted sender) client-ip=10.50.153.166; Authentication-Results: mr.google.com; spf=pass (google.com: domain of slackbie@gmail.com designates 10.50.153.166 as permitted sender) smtp.mail=slackbie@gmail.com; dkim=pass header.i=slackbie@gmail.com Received: from mr.google.com ([10.50.153.166]) by 10.50.153.166 with SMTP id vh6mr1910886igb.44.1330423291970 (num_hops = 1); Tue, 28 Feb 2012 02:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Hj8kxyjlJmYrbCBjh6b5yzO1kDmU+GbC00FoNv6hd+A=; b=pT7AEkk+RKZga+NPGXTVO+FBuMlPxyV5YbHOPiSkxNhU6wLUNPJqplyz+8uaVB7KQo 034hfegpmOtIiwDr50MZeLkU3tuRsokeC9304M4Z3M742c+hGrzdvngFwRAvg+05g+wN j003lRePhI58+DxQWQLaXe4WecMcxNAjLLDzk= MIME-Version: 1.0 Received: by 10.50.153.166 with SMTP id vh6mr1568693igb.44.1330421923930; Tue, 28 Feb 2012 01:38:43 -0800 (PST) Received: by 10.42.1.68 with HTTP; Tue, 28 Feb 2012 01:38:43 -0800 (PST) In-Reply-To: <4F4C3FE7.3040802@FreeBSD.org> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> Date: Tue, 28 Feb 2012 16:38:43 +0700 Message-ID: From: "~Lst" To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 10:01:32 -0000 2012/2/28 Steve Wills : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/27/12 10:53, =C5=81ukasz W=C4=85sikowski wrote: >> W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze: >> >>> You cannot ship that on by default for non-tecnical reasons in a >>> kernel. =C2=A0Please do not commit a kernel config that can be booted >>> (no LINT cannot be booted) with these on without consulting >>> appropriate hats upfront. >>> >>> >>>> - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in >>>> loader.conf) - IPFIREWALL_FORWARD (touches every packet, power >>>> users which need a bigger PPS but not this feature can >>>> recompile the kernel, discussed with julian@) - FLOWTABLE >>>> (disabled in loader.conf) >>> Which is not the same as it's not 100% disabled and will still >>> allocate memory. >> >> FLOWTABLE on 8.x crashed BGP routers (kern/144917). I don't know if >> it is fixed by now, but this kind of potential problematic features >> should not be enabled by default. >> > > Agree, I've run into problems with FLOWTABLE (with just the features > that were enabled by default in 8.0) when routers changed MAC > addresses. As far as I understand it, FLOWTABLE is both broken and > abandoned (but if I'm wrong, please let me know). > > So, IMHO, not only should it not be enabled by default, but given that > it was disabled complete in 8.x after 8.0 (too lazy to look at exactly > when right now), I think it shouldn't even be included, since that > might encourage users to try it out only to encounter problems with it. > > Steve > Definitely yes, I'd some problems too with FLOWTABLE running for router. So I have to disabled in kernel and sysctl. Rgds, -- Lasta Yani From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 11:10:03 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7D4A106566B for ; Tue, 28 Feb 2012 11:10:03 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 91C018FC14 for ; Tue, 28 Feb 2012 11:10:03 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1S2KwU-0008Dn-KD>; Tue, 28 Feb 2012 12:10:02 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1S2KwU-0007PL-GY>; Tue, 28 Feb 2012 12:10:02 +0100 Message-ID: <4F4CB604.7060902@mail.zedat.fu-berlin.de> Date: Tue, 28 Feb 2012 12:09:56 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120224 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jason Hellenthal References: <4F4B98FC.6080705@mail.zedat.fu-berlin.de> <20120227152957.GB64523@DataIX.net> In-Reply-To: <20120227152957.GB64523@DataIX.net> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4F07F8B26D520A89CB6E0304" X-Originating-IP: 130.133.86.198 Cc: FreeBSD Stable Mailing List Subject: Re: netstat: no namelist X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 11:10:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4F07F8B26D520A89CB6E0304 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02/27/12 16:29, Jason Hellenthal wrote: >=20 >=20 > On Mon, Feb 27, 2012 at 03:53:48PM +0100, O. Hartmann wrote: >> On FreeBSD 9.0-STABLE/amd64 (recent build today, r232207), issuing >> "netstat on console or in terminal doesn't give the usual netstat as >> expected, instead I receive >> >> netstat: no namelist >> >> What's wrong? >> >=20 > This usually happens when kernel and world are built out of sync. > Attempt to rebuild ( kernel first & then world ) follow the steps near > /usr/src/UPDATING >=20 >=20 I did. Three times now. When building, I build everything, world AND kernel. I delete /usr/obj/ as well. Strange ... Oliver --------------enig4F07F8B26D520A89CB6E0304 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJPTLYKAAoJEOgBcD7A/5N87pkIAIuSzbjN/bUQxiB8YAoxcua1 70GqzWDT45hLVTLZB6Yh2lE0zUBKvlVUcU3rG10ZFA2eM10s4cJq4nWPm5IFEx0D TvrPrwB8CTSB7twCMZoJd1+AZZG44v/w60McjFWhB4XydXwkxqBS62nW8xqjehiV F4AIEYrT3fKCRH2NOcjS29vXXZb/N+8qJeJMb7U/ciKmg61O3jmaDz0iS9PPN5kg UGSxncPNN0IPzud4rJ5lRYZAaXkJ1q1N86+s+ILjIroTACCvtsGf/q+tgDSsaiS2 5PdhrjR/0jWNC4PIEOLkkE4UFoytLEphB5iK7rBvQQG7PACqsXshx1eLuO/loKU= =uxhQ -----END PGP SIGNATURE----- --------------enig4F07F8B26D520A89CB6E0304-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 11:10:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B81011065675 for ; Tue, 28 Feb 2012 11:10:38 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 6E98D8FC1F for ; Tue, 28 Feb 2012 11:10:38 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1S2Kx3-0008LH-IR>; Tue, 28 Feb 2012 12:10:37 +0100 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1S2Kx3-0007QZ-EM>; Tue, 28 Feb 2012 12:10:37 +0100 Message-ID: <4F4CB62D.6020404@mail.zedat.fu-berlin.de> Date: Tue, 28 Feb 2012 12:10:37 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120224 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jason Hellenthal References: <4F4B98FC.6080705@mail.zedat.fu-berlin.de> <20120227152957.GB64523@DataIX.net> In-Reply-To: <20120227152957.GB64523@DataIX.net> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0D66AD10D2E0A0A610D44FEC" X-Originating-IP: 130.133.86.198 Cc: FreeBSD Stable Mailing List Subject: Re: netstat: no namelist X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 11:10:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0D66AD10D2E0A0A610D44FEC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02/27/12 16:29, Jason Hellenthal wrote: >=20 >=20 > On Mon, Feb 27, 2012 at 03:53:48PM +0100, O. Hartmann wrote: >> On FreeBSD 9.0-STABLE/amd64 (recent build today, r232207), issuing >> "netstat on console or in terminal doesn't give the usual netstat as >> expected, instead I receive >> >> netstat: no namelist >> >> What's wrong? >> >=20 > This usually happens when kernel and world are built out of sync. > Attempt to rebuild ( kernel first & then world ) follow the steps near > /usr/src/UPDATING >=20 >=20 =2E.. and by the way: I build kernel and world with CLANG by default. oh --------------enig0D66AD10D2E0A0A610D44FEC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJPTLYtAAoJEOgBcD7A/5N8P48H/jdOgDRR1CgEQ84ccA26AfNw kpolRvPOv0SdWGzknwx9kvngmSIMfPqUXciYYByH1ldVfKIDzQj9OJ4mMJIeCGhe ec5EgySzb717g8VVqgE3Y79wvyd6aFb/BNYwd7jDnQrCzhSd1kKT7RHA2LbF+12i I8NSGblzzxK7lNRw7j+p+w/iN3RhKy51izVJ3JgNNKTJB2N0GbB1XRis8fnQmk/Z kcAw5++XJJs859Beojr8QOG9usbZlQYK3nnTiaZxR/CTaUQ7U9COXEYkRISIwPsR Glxom4CNXG9SoFKf3+XmePST6LjH7kOqQT0/udDQGJo5I3zk5c6Y8sztkNxRxlo= =ICFB -----END PGP SIGNATURE----- --------------enig0D66AD10D2E0A0A610D44FEC-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 13:09:37 2012 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 839FB106564A; Tue, 28 Feb 2012 13:09:37 +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 BB2878FC18; Tue, 28 Feb 2012 13:09:36 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1SD8dVR042167; Tue, 28 Feb 2012 15:08:39 +0200 (EET) (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.5/8.14.5) with ESMTP id q1SD8den086437; Tue, 28 Feb 2012 15:08:39 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1SD8cKH086436; Tue, 28 Feb 2012 15:08:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 28 Feb 2012 15:08:38 +0200 From: Konstantin Belousov To: Hiroki Sato Message-ID: <20120228130838.GN55074@deviant.kiev.zoral.com.ua> References: <20120223.234558.1101656075598772176.hrs@allbsd.org> <20120224143336.GS55074@deviant.kiev.zoral.com.ua> <20120224150259.GV55074@deviant.kiev.zoral.com.ua> <20120225.025828.128418237042325597.hrs@allbsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sEASj6BbPXAOAu+u" Content-Disposition: inline In-Reply-To: <20120225.025828.128418237042325597.hrs@allbsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: stable@freebsd.org Subject: Re: another panic in 8.3-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: Tue, 28 Feb 2012 13:09:37 -0000 --sEASj6BbPXAOAu+u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 25, 2012 at 02:58:28AM +0900, Hiroki Sato wrote: > Konstantin Belousov wrote > in <20120224150259.GV55074@deviant.kiev.zoral.com.ua>: >=20 > ko> > > #19 0x0000000800abecfc in ?? () > ko> > > Previous frame inner to this frame (corrupt stack?) > ko> > > (kgdb) > ko> > Can you, please, print out the content of *td, e.g. from the frame = 16 ? > ko>=20 > ko> And *req from the frame 11, please. >=20 > Here: >=20 > (kgdb) f 16 > #16 0xffffffff80675e3a in __sysctl (td=3D0xffffff0396ec5460,=20 > uap=3D0xffffff86c6389bc0) at /usr/src/sys/kern/kern_sysctl.c:1491 > 1491 error =3D userland_sysctl(td, name, uap->namelen, > (kgdb) print *td > $2 =3D {td_lock =3D 0xffffffff80d7f540, td_proc =3D 0xffffff03969bf470, t= d_plist =3D { > tqe_next =3D 0x0, tqe_prev =3D 0xffffff03969bf480}, td_runq =3D {tqe_= next =3D 0x0,=20 > tqe_prev =3D 0xffffffff80d7f788}, td_slpq =3D {tqe_next =3D 0x0,=20 > tqe_prev =3D 0xffffff0396ebe800}, td_lockq =3D {tqe_next =3D 0x0,=20 > tqe_prev =3D 0xffffff86c57b48a0}, td_cpuset =3D 0xffffff0005789dc8,= =20 > td_sel =3D 0xffffff01b5dd0500, td_sleepqueue =3D 0xffffff0396ebe800,=20 > td_turnstile =3D 0xffffff01334cf600, td_umtxq =3D 0xffffff0396ec3a80,= =20 > td_tid =3D 100763, td_sigqueue =3D {sq_signals =3D {__bits =3D {0, 0, 0= , 0}},=20 > sq_kill =3D {__bits =3D {0, 0, 0, 0}}, sq_list =3D {tqh_first =3D 0x0= ,=20 > tqh_last =3D 0xffffff0396ec5500}, sq_proc =3D 0xffffff03969bf470,= =20 > sq_flags =3D 1}, td_flags =3D 65540, td_inhibitors =3D 0, td_pflags = =3D 0,=20 > td_dupfd =3D 0, td_sqqueue =3D 0, td_wchan =3D 0x0, td_wmesg =3D 0x0,= =20 > td_lastcpu =3D 4 '\004', td_oncpu =3D 4 '\004', td_owepreempt =3D 0 '\0= ',=20 > td_tsqueue =3D 255 '?', td_locks =3D 4, td_rw_rlocks =3D 0, td_lk_slock= s =3D 0,=20 > td_blocked =3D 0x0, td_lockname =3D 0x0, td_contested =3D {lh_first =3D= 0x0},=20 > td_sleeplocks =3D 0xffffffff80ecebf0, td_intr_nesting_level =3D 0,=20 > td_pinned =3D 0, td_ucred =3D 0xffffff007d537b00, td_estcpu =3D 0, td_s= lptick =3D 0,=20 > td_blktick =3D 0, td_ru =3D {ru_utime =3D {tv_sec =3D 0, tv_usec =3D 0}= , ru_stime =3D { > tv_sec =3D 0, tv_usec =3D 0}, ru_maxrss =3D 1864, ru_ixrss =3D 6628= 8,=20 > ru_idrss =3D 1347856, ru_isrss =3D 176768, ru_minflt =3D 263901, ru_m= ajflt =3D 10,=20 > ru_nswap =3D 0, ru_inblock =3D 0, ru_oublock =3D 0, ru_msgsnd =3D 0,= =20 > ru_msgrcv =3D 0, ru_nsignals =3D 0, ru_nvcsw =3D 14937, ru_nivcsw =3D= 3286},=20 > td_incruntime =3D 0, td_runtime =3D 15204044088, td_pticks =3D 15, td_s= ticks =3D 15,=20 > td_iticks =3D 0, td_uticks =3D 0, td_intrval =3D 0, td_oldsigmask =3D {= __bits =3D {0,=20 > 0, 0, 0}}, td_sigmask =3D {__bits =3D {0, 0, 0, 0}}, td_generation = =3D 18223,=20 > td_sigstk =3D {ss_sp =3D 0x0, ss_size =3D 0, ss_flags =3D 4}, td_xsig = =3D 0,=20 > td_profil_addr =3D 0, td_profil_ticks =3D 0,=20 > td_name =3D "top", '\0' , td_fpop =3D 0x0, td_dbgflag= s =3D 0,=20 > td_dbgksi =3D {ksi_link =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, ksi_i= nfo =3D { > si_signo =3D 0, si_errno =3D 0, si_code =3D 0, si_pid =3D 0, si_uid= =3D 0,=20 > si_status =3D 0, si_addr =3D 0x0, si_value =3D {sival_int =3D 0,=20 > sival_ptr =3D 0x0, sigval_int =3D 0, sigval_ptr =3D 0x0}, _reason= =3D { > _fault =3D {_trapno =3D 0}, _timer =3D {_timerid =3D 0, _overrun = =3D 0},=20 > _mesgq =3D {_mqd =3D 0}, _poll =3D {_band =3D 0}, __spare__ =3D {= __spare1__ =3D 0,=20 > __spare2__ =3D {0, 0, 0, 0, 0, 0, 0}}}}, ksi_flags =3D 0,=20 > ksi_sigq =3D 0x0}, td_ng_outbound =3D 0, td_osd =3D {osd_nslots =3D 0= ,=20 > osd_slots =3D 0x0, osd_next =3D {le_next =3D 0x0, le_prev =3D 0x0}},= =20 > td_rqindex =3D 32 ' ', td_base_pri =3D 128 '\200', td_priority =3D 128 = '\200',=20 > td_pri_class =3D 3 '\003', td_user_pri =3D 129 '\201',=20 > td_base_user_pri =3D 129 '\201', td_pcb =3D 0xffffff86c6389d10,=20 > td_state =3D TDS_RUNNING, td_retval =3D {0, 34375032832}, td_slpcallout= =3D { > c_links =3D {sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_next =3D 0x0,= =20 > tqe_prev =3D 0xffffff800042ccd0}}, c_time =3D 51568077,=20 > c_arg =3D 0xffffff0396ec5460, c_func =3D 0xffffffff806a84c0 ,=20 > c_lock =3D 0x0, c_flags =3D 18, c_cpu =3D 4}, td_frame =3D 0xffffff86= c6389c50,=20 > td_kstack_obj =3D 0xffffff03410b20d8, td_kstack =3D 1844674355304912486= 4,=20 > td_kstack_pages =3D 4, td_unused1 =3D 0x0, td_unused2 =3D 0, td_unused3= =3D 0,=20 > td_critnest =3D 0, td_md =3D {md_spinlock_count =3D 0, md_saved_flags = =3D 70},=20 > td_sched =3D 0xffffff0396ec5890, td_ar =3D 0x0, td_syscalls =3D 469926,= =20 > td_lprof =3D {{lh_first =3D 0x0}, {lh_first =3D 0x0}}, td_dtrace =3D 0x= 0,=20 > td_errno =3D 0, td_vnet =3D 0x0, td_vnet_lpush =3D 0x0, td_rux =3D { > rux_runtime =3D 15204044088, rux_uticks =3D 226, rux_sticks =3D 1140,= =20 > rux_iticks =3D 0, rux_uu =3D 0, rux_su =3D 0, rux_tu =3D 0},=20 > td_map_def_user =3D 0x0, td_dbg_forked =3D 0} > (kgdb) f 11 > #11 0xffffffff8065f6a6 in sysctl_out_proc_copyout (ki=3D0xffffff86c638947= 0,=20 > req=3D0xffffff86c63899c0) at /usr/src/sys/kern/kern_proc.c:1085 > 1085 error =3D SYSCTL_OUT(req, ki, sizeof(struct kinfo_proc)); > (kgdb) print *req > $3 =3D {td =3D 0xffffff0396ec5460, lock =3D 2, oldptr =3D 0x800e96000, ol= dlen =3D 68217,=20 > oldidx =3D 1088, oldfunc =3D 0xffffffff80675e80 , newp= tr =3D 0x0,=20 > newlen =3D 0, newidx =3D 0, newfunc =3D 0xffffffff80675d10 ,=20 > validlen =3D 68217, flags =3D 0} > (kgdb) quit >=20 > -- Hiroki I can see the race in how the wiring of the sysctl buffers is done, but the race can only realize for the multithreaded process. Can you, please, further show me two things: - the p/x *(td->td_pcb) - (this is somewhat laborous) Please find the vm map entry in the process vm_map which covers the range [0x800e96000, 0x800ea6a79) and print it out. You need to walk the td->td_proc->p_vmspace.vm_map.header list using the next link, looking for the entry start/end values. --sEASj6BbPXAOAu+u Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9M0dYACgkQC3+MBN1Mb4i6LACcDG0tVBwEKUVuW19H7LVlPDXx uxsAoLa6r2njpLUhYaUbhhrHc3eiQ9UE =VBMZ -----END PGP SIGNATURE----- --sEASj6BbPXAOAu+u-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 15:08:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CA571065670 for ; Tue, 28 Feb 2012 15:08:16 +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 189178FC13 for ; Tue, 28 Feb 2012 15:08:15 +0000 (UTC) Received: from zidane.cc.vt.edu (zidane.cc.vt.edu [198.82.163.227]) by lennier.cc.vt.edu (8.13.8/8.13.8) with ESMTP id q1SEsk3s013078; Tue, 28 Feb 2012 09:54:46 -0500 Received: from auth3.smtp.vt.edu (EHLO auth3.smtp.vt.edu) ([198.82.161.152]) by zidane.cc.vt.edu (MOS 4.3.3-GA FastPath queued) with ESMTP id SEA47338; Tue, 28 Feb 2012 09:54:46 -0500 (EST) Received: from pmather.tower.lib.vt.edu (pmather.tower.lib.vt.edu [128.173.51.28]) (authenticated bits=0) by auth3.smtp.vt.edu (8.13.8/8.13.8) with ESMTP id q1SEsjhT004022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Feb 2012 09:54:46 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Mather In-Reply-To: <4F4C53B6.6060909@norma.perm.ru> Date: Tue, 28 Feb 2012 09:54:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <93DCA53D-B71F-4B67-8CEF-CDECF3829C6D@gromit.dlib.vt.edu> References: <4F4B0F83.4090600@norma.perm.ru> <977febd5710ecac8cd9ea374ca0193f4.squirrel@109.169.62.232> <4F4C53B6.6060909@norma.perm.ru> To: "Eugene M. Zheganin" X-Mailer: Apple Mail (2.1084) X-Mirapoint-Received-SPF: 198.82.161.152 auth3.smtp.vt.edu paul@gromit.dlib.vt.edu 5 none X-Junkmail-Status: score=10/50, host=zidane.cc.vt.edu X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A020203.4F4CEAB6.00A6,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=single engine X-Junkmail-IWF: false Cc: freebsd-stable@freebsd.org Subject: Re: zfs, 1 gig of RAM and periodic weekly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 15:08:16 -0000 On Feb 27, 2012, at 11:10 PM, Eugene M. Zheganin wrote: > Hi. >=20 > On 28.02.2012 01:02, Nenhum_de_Nos wrote: >> regardless of the pool size ? >>=20 >> I was planning on making an atom board a file server for my home, and = I have two options: soekris >> net6501 2GB RAM and intel board powered by the 330 atom (says 2GB = limited as well). My plans are >> to use from 4 up to 8 disks, and they should be 2TB at least. >>=20 >> As its for home use, some p2p software and mostly music listening and = sometimes movie streaming. >>=20 >> should 2GB be that bad, that I should drop it and use UFS instead ? >>=20 >> I may run any version of FreeBSD on it, was planning on 9-STABLE or = 9.1. >>=20 > In the same time I have a couple of hosts successfully running zfs on = 768 Megs and on 1 Gig of RAM. Both i386. > And they aren't affected by the periodic weekly for some reason. And = they are used only as fileservers. Basically the same story here: I am using a FreeBSD/i386 system with 768 = MB of RAM running RELENG_8 with 4 x 1 TB drives arranged as a RAIDZ1 = vdev. It is used as a Bacula server, backing up to the ZFS pool (with = ZFS compression enabled). It has been rock solid, and I've had no = problems with any of the periodic jobs. Here are the ZFS-related tunings I have in /boot/loader.conf: vm.kmem_size=3D"640M" vm.kmem_size_max=3D"640M" vfs.zfs.arc_max=3D"512M" vfs.zfs.txg.timeout=3D"5" If you are planning on using P2P a lot, I had heard that large files = fetched via Bittorrent can become very fragmented under ZFS (due to the = COW nature of ZFS and the way Bittorrent fetches files), especially if = the pool is very full, and so ZFS might not be the best thing to use if = you are also planning on streaming these files, especially on modest = hardware. UFS might be preferable in these circumstances. Cheers, Paul. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 15:27:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20E94106564A for ; Tue, 28 Feb 2012 15:27:01 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id A91FF8FC0C for ; Tue, 28 Feb 2012 15:27:00 +0000 (UTC) Received: from outgoing.leidinger.net (p5796C834.dip.t-dialin.net [87.150.200.52]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 869BE844C52; Tue, 28 Feb 2012 16:26:44 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id C7CF411EF; Tue, 28 Feb 2012 16:26:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1330442801; bh=K+vll7s572TX7NzUgADs6iJUyyU7HgdKLfm72SOM0T8=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=fjO35UtUTO5pfVzglI4nuRNGJhTC7mdchzN/xA2IMYSz6p7QqfgGt4OtnyVQoC8A3 +x8ciAkL2VOgKRAeOzofLTStzEDYTW/yBHJ7XaIYOTJxXMzMSzjzceh20Gsevc1fm2 oipDChxSIsltiWMQoQaxy7JxAQQXr2cGKe9mOQgNOqBCRd4Tcw/+hrYtUh71147KX8 mgolMVEaFDx8L0+L9FsczQb2SKrBw0i1hExEfwNd89HqHNPe/E3gTXv/4h7oH3I+U9 L5ncpt8tX1L1RCrcYAhEsJ0aG3LIQJnnfYMkLJEdVwyTj7wJfTxoPr0KVHqjV2O/dv Uzs269XYp3GeQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1SFQavP036149; Tue, 28 Feb 2012 16:26:36 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 28 Feb 2012 16:26:36 +0100 Date: Tue, 28 Feb 2012 16:26:36 +0100 Message-ID: <20120228162636.Horde.JgORKJjmRSRPTPIsGKfo0uA@webmail.leidinger.net> From: Alexander Leidinger To: vermaden References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 869BE844C52.A189F X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.518, required 6, autolearn=disabled, AWL -0.41, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1331047605.80459@qpVYR2aywm6gu1sPj2k/xA X-EBL-Spam-Status: No Cc: fidaj@ukr.net, freebsd-stable@freebsd.org, lars.engels@0x20.net, Hans Petter Selasky , smithi@nimnet.asn.au Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 15:27:01 -0000 Quoting vermaden (from Mon, 27 Feb 2012 21:36:46 +0100): >> Unfortunately, I spent a few days that would >> have to understand how it is possible to >> detect the inserted CD-ROM with devd; but >> alas - the only thing that detects changes >> in the drive CD-ROM - a :sysctl kern.geom.conftxt >> >> before inserting the disc: >> kern.geom.conftxt: 0 DISK cd0 0 2048 hd 0 sc 0 >> ... >> >> after inserting the disc: >> kern.geom.conftxt: 0 DISK cd0 4700372992 2048 hd 0 sc 0 > > Thanks, at least we have 'something' we can cepend on. > > I can create an 'active wait' daemon for that, like the skel below: > > while sleep 3 > do > case $( sysctl -n kern.geom.conftxt ) in > (0 DISK cd0 0 2048 hd 0 sc 0) > echo "No CD in the drive ..." > # umount procedure ... > ;; > (0 DISK cd0 * * hd 0 sc 0) > echo "We have CD here!" > # do something about it lile mount_cd9660 > ;; > esac > done > > But a devd(8) event would be far better, maybe some somple commit to > devd(8) would help here? My knowledge does not allow me to add these > bits to devd(8). The kernel does not poll for CD changes, and the people guarding the relevant CD code where against something like this in the kernel everytime this came up in the past. So no devd event for this. Bye, Alexander. -- Back when I was a boy, it was 40 miles to everywhere, uphill both ways and it was always snowing. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 15:33:24 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30C18106564A for ; Tue, 28 Feb 2012 15:33:24 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id B39DD8FC13 for ; Tue, 28 Feb 2012 15:33:23 +0000 (UTC) Received: from outgoing.leidinger.net (p5796C834.dip.t-dialin.net [87.150.200.52]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 698EB844C52; Tue, 28 Feb 2012 16:33:08 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id B105111F1; Tue, 28 Feb 2012 16:33:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1330443185; bh=W3itPZvYo9gFc83my9V0McGDkrk19zRiCNJM9kNiQmY=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=VT92rUNzOBE4Dbo2eX7MjT3dQZnI869ZVEclbO1DuFwlAWEf5Xs/9vKGVtv8yB3BT 5rbUDnrKyGf+TzcSUDxJN1Sy9Mn7ysmosLIJIkGEdFFp+gqhSrQDyMbhcMetc60VHt kiuiNt89k7n1r8OY59bXvyXLDuaa2DSJn//ddMHGho0+9zvP7w3cyAQyXOgB7VG0fW t+4fvrtQg3Pl4PoVfI++KyPCeGuQ9mCa0qNRxLoxWEoxglIsJnEQxILV0dhFXMQLMn TFUnQaeUzM1YbI8wA3C52F0AlIR7KxfE0+5lc7uMH/k7tYaoks47JTZ/YMQGURha1R ZEN3es1Z3qMMQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1SFX4aG036517; Tue, 28 Feb 2012 16:33:04 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 28 Feb 2012 16:33:04 +0100 Date: Tue, 28 Feb 2012 16:33:04 +0100 Message-ID: <20120228163304.Horde.ocr9EJjmRSRPTPOw0ffYu5A@webmail.leidinger.net> From: Alexander Leidinger To: "Eugene M. Zheganin" References: <4F4B0F83.4090600@norma.perm.ru> <977febd5710ecac8cd9ea374ca0193f4.squirrel@109.169.62.232> <4F4C53B6.6060909@norma.perm.ru> In-Reply-To: <4F4C53B6.6060909@norma.perm.ru> User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 698EB844C52.A0CD2 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.496, required 6, autolearn=disabled, AWL -0.46, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, TW_ZF 0.08, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1331047991.33546@m8z6VU36Gxhr2uWoATuB2w X-EBL-Spam-Status: No Cc: freebsd-stable@freebsd.org Subject: Re: zfs, 1 gig of RAM and periodic weekly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 15:33:24 -0000 Quoting "Eugene M. Zheganin" (from Tue, 28 Feb 2012 10:10:30 +0600): > Hi. > > On 28.02.2012 01:02, Nenhum_de_Nos wrote: >> regardless of the pool size ? >> >> I was planning on making an atom board a file server for my home, >> and I have two options: soekris >> net6501 2GB RAM and intel board powered by the 330 atom (says 2GB >> limited as well). My plans are >> to use from 4 up to 8 disks, and they should be 2TB at least. >> >> As its for home use, some p2p software and mostly music listening >> and sometimes movie streaming. >> >> should 2GB be that bad, that I should drop it and use UFS instead ? >> >> I may run any version of FreeBSD on it, was planning on 9-STABLE or 9.1. >> > In the same time I have a couple of hosts successfully running zfs > on 768 Megs and on 1 Gig of RAM. Both i386. > And they aren't affected by the periodic weekly for some reason. And > they are used only as fileservers. > > So when I see all these advices to add a gazillion gigabytes of RAM > to use zfs - I don't see the connection. The connection is performance and/or lack of tuning. At home I haven't a problem to run a system with ZFS and 768MB and 1GB (well, the 1GB system has hardware problems, so it is degraded to a toybox to test things now, but ZFS is still rock solid on it). At a place where more than a handfull of people would access such a system in a way where the performance of big file transfers matter (not streaming, not just watching a movie on one system, ...), I would also recommend more RAM. Bye, Alexander. -- Michelle: You expect me to live in a tiny little hole? Fry: It'd be deeper, but I'm standing on a gopher. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 15:38:00 2012 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 2459C1065690; Tue, 28 Feb 2012 15:38:00 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id ABA9A8FC0A; Tue, 28 Feb 2012 15:37:59 +0000 (UTC) Received: from outgoing.leidinger.net (p5796C834.dip.t-dialin.net [87.150.200.52]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 9B31A844C51; Tue, 28 Feb 2012 16:37:43 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id E586A11F2; Tue, 28 Feb 2012 16:37:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1330443461; bh=CbfwLWupr8NdOPXx1ZXqQxvUFOo5tY//APyx786ptC4=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version:Content-Transfer-Encoding; b=C0dBkluk/q5FRQlfe+ErYrQx/I7OuLOo5Q3ygdvc3JgasaO0czbD8Edr4MJJ+IaE4 tnbjvuZHIlXZq95ZM4UjP/sx45PLEX6Ua8MsA781f9Zt91knl+raPxIv3wzjoNte+E FnfHX1fBTrUsUxrCP3uZ7HCtx7SNYcy0hkgbqipKibbpka28ISPptgIu6vskN+u2yN qKQQAJunAE6fNXXQGfv2iUMQSbCTPB4adgxdlmd4E9TzJJGShESW/LmtnyN1VqjoZ3 6/znVPMUcs+ehIdF7Jzzr7qtUL79GSfVJP5n8GRO+WnhatHc9bq2HFxACyNIp2f7/x 5rAeutdKMzFqw== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1SFbeKu036673; Tue, 28 Feb 2012 16:37:40 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 28 Feb 2012 16:37:40 +0100 Date: Tue, 28 Feb 2012 16:37:40 +0100 Message-ID: <20120228163740.Horde.-AvCD5jmRSRPTPTEkzY476A@webmail.leidinger.net> From: Alexander Leidinger To: ~Lst References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 9B31A844C51.AFD56 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.549, required 6, autolearn=disabled, AWL -0.44, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1331048266.9265@LAiGz8Pt0JvM5yZ0hI5caw X-EBL-Spam-Status: No Cc: stable@freebsd.org, current@freebsd.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 15:38:00 -0000 Quoting ~Lst (from Tue, 28 Feb 2012 16:38:43 +0700): > 2012/2/28 Steve Wills : >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 02/27/12 10:53, =C5=81ukasz W=C4=85sikowski wrote: >>> W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze: >>> >>>> You cannot ship that on by default for non-tecnical reasons in a >>>> kernel. =C2=A0Please do not commit a kernel config that can be booted >>>> (no LINT cannot be booted) with these on without consulting >>>> appropriate hats upfront. >>>> >>>> >>>>> - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in >>>>> loader.conf) - IPFIREWALL_FORWARD (touches every packet, power >>>>> users which need a bigger PPS but not this feature can >>>>> recompile the kernel, discussed with julian@) - FLOWTABLE >>>>> (disabled in loader.conf) >>>> Which is not the same as it's not 100% disabled and will still >>>> allocate memory. >>> >>> FLOWTABLE on 8.x crashed BGP routers (kern/144917). I don't know if >>> it is fixed by now, but this kind of potential problematic features >>> should not be enabled by default. >>> >> >> Agree, I've run into problems with FLOWTABLE (with just the features >> that were enabled by default in 8.0) when routers changed MAC >> addresses. As far as I understand it, FLOWTABLE is both broken and >> abandoned (but if I'm wrong, please let me know). >> >> So, IMHO, not only should it not be enabled by default, but given that >> it was disabled complete in 8.x after 8.0 (too lazy to look at exactly >> when right now), I think it shouldn't even be included, since that >> might encourage users to try it out only to encounter problems with it. >> >> Steve >> > > Definitely yes, I'd some problems too with FLOWTABLE running for router. > So I have to disabled in kernel and sysctl. To make sure I understand you correctly: Did you disabled it with the sysctl/loader-tunable and everything was OK again, or did you had to remove it from the kernel config (disabling via sysctl was not enough) to resolve the issue? I have one report where a person has issue with FLOWTABLE, but disabling it via the sysctl/loader-tunable was enough to address his concerns. Bye, Alexander. -- The light at the end of the tunnel is the headlamp of an oncoming train. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 16:36:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7F46106566B for ; Tue, 28 Feb 2012 16:36:37 +0000 (UTC) (envelope-from jason@wohlford.org) Received: from montgomery.al (wohlfordcompany.com [184.106.215.246]) by mx1.freebsd.org (Postfix) with ESMTP id B6F118FC14 for ; Tue, 28 Feb 2012 16:36:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wohlford.org; s=mail; t=1330445956; bh=7vRAWYt5xWAimt+6dlXlrRAog1HrlL/5co0qrtREaNY=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=yo7HcSQfpYC7Gd5eQMu9fSqwTjBMzrTV0lwucdI6K2qggdZ9J7X98fXj9nt1Sn7OJ 14m/rXyqOZsyeKu12wOH5srsWeoMSQhPfhmXZ5O3e1hZTJh5D91VhleD3XhuDghZTC bHnQd8PFUu8MSMYQNtsM4gz3Zy70ifle2Tth2qYQ= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Jason Wohlford In-Reply-To: <4F4B0F83.4090600@norma.perm.ru> Date: Tue, 28 Feb 2012 10:19:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3574BC12-5027-4532-98EA-C614696695BE@wohlford.org> References: <4F4B0F83.4090600@norma.perm.ru> To: Eugene M. Zheganin X-Mailer: Apple Mail (2.1257) Cc: freebsd-stable Subject: Re: zfs, 1 gig of RAM and periodic weekly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 16:36:37 -0000 On Feb 26, 2012, at 11:07 PM, Eugene M. Zheganin wrote: > I'm haunted by a weird bug. > Some of my servers (IBM x3250) hang periodically. And this is always = saturday morning. Different servers in different cities, all with zfs = and one gig of RAM. And yeah, it's periodic weekly. I can say more - = it's repeatable. 25 minutes ago I typed 'periodic weekly', and 5 = minutes ago I lost this machine from the network (even stopped answering = to ICMP). This can be solved by any of two methods - either increase = RAM, or turning off periodic weekly. What is the output from 'swapinfo'? --=20 Jason Wohlford @wohlford From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 17:30:14 2012 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 B7F451065672 for ; Tue, 28 Feb 2012 17:30:14 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 390F98FC1A for ; Tue, 28 Feb 2012 17:30:13 +0000 (UTC) Received: from alph.allbsd.org (p1012-ipbf2105funabasi.chiba.ocn.ne.jp [114.148.160.12]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q1SHToQZ080776; Wed, 29 Feb 2012 02:30:01 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q1SHTnRq041807; Wed, 29 Feb 2012 02:29:50 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 29 Feb 2012 02:26:51 +0900 (JST) Message-Id: <20120229.022651.1585266709145027511.hrs@allbsd.org> To: kostikbel@gmail.com From: Hiroki Sato In-Reply-To: <20120228130838.GN55074@deviant.kiev.zoral.com.ua> References: <20120224150259.GV55074@deviant.kiev.zoral.com.ua> <20120225.025828.128418237042325597.hrs@allbsd.org> <20120228130838.GN55074@deviant.kiev.zoral.com.ua> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Wed_Feb_29_02_26_51_2012_049)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Wed, 29 Feb 2012 02:30:06 +0900 (JST) X-Spam-Status: No, score=-99.8 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, FAKEDWORD_ONE, FAKEDWORD_VERTICALLINE, RCVD_IN_PBL, RCVD_IN_RP_RNBL, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: stable@FreeBSD.org Subject: Re: another panic in 8.3-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: Tue, 28 Feb 2012 17:30:14 -0000 ----Security_Multipart0(Wed_Feb_29_02_26_51_2012_049)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Feb_29_02_26_51_2012_369)--" Content-Transfer-Encoding: 7bit ----Next_Part(Wed_Feb_29_02_26_51_2012_369)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Konstantin Belousov wrote in <20120228130838.GN55074@deviant.kiev.zoral.com.ua>: ko> I can see the race in how the wiring of the sysctl buffers is done, but the ko> race can only realize for the multithreaded process. ko> ko> Can you, please, further show me two things: ko> - the p/x *(td->td_pcb) ko> - (this is somewhat laborous) Please find the vm map entry in the process ko> vm_map which covers the range [0x800e96000, 0x800ea6a79) and print it out. ko> You need to walk the td->td_proc->p_vmspace.vm_map.header list using ko> the next link, looking for the entry start/end values. The results and gdb commands I used are attached. In the linked-list there seem two entries that covers the range. -- Hiroki ----Next_Part(Wed_Feb_29_02_26_51_2012_369)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="result.txt" GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x800e96000 fault code = supervisor write data, protection violation instruction pointer = 0x20:0xffffffff809440cb stack pointer = 0x28:0xffffff86c63890b0 frame pointer = 0x28:0xffffff86c6389100 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 47211 (top) lock order reversal: (Giant after non-sleepable) 1st 0xffffff0244b85568 process lock (process lock) @ /usr/src/sys/kern/kern_proc.c:1211 2nd 0xffffffff80d74c80 Giant (Giant) @ /usr/src/sys/dev/usb/input/ukbd.c:2018 KDB: stack backtrace: Dumping 23903 out of 24550 MB:..1%..11%..21%..31% (CTRL-C to abort) (CTRL-C to abort) ..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/kernel/ipfw.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipfw.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:263 263 if (textdump_pending) #16 0xffffffff80675e3a in __sysctl (td=0xffffff0396ec5460, uap=0xffffff86c6389bc0) at /usr/src/sys/kern/kern_sysctl.c:1491 1491 error = userland_sysctl(td, name, uap->namelen, -------- p/x *(td->td_pcb): $1 = {pcb_r15 = 0xffffff03969bf470, pcb_r14 = 0x0, pcb_r13 = 0xffffffff80d7f540, pcb_r12 = 0xffffff00057a18c0, pcb_rbp = 0xffffff86c6389700, pcb_rsp = 0xffffff86c63896a8, pcb_rbx = 0xffffff0396ec5460, pcb_rip = 0xffffffff80691367, pcb_fsbase = 0x800542398, pcb_gsbase = 0x0, pcb_kgsbase = 0x0, pcb_cr0 = 0x0, pcb_cr2 = 0x0, pcb_cr3 = 0x6793f000, pcb_cr4 = 0x0, pcb_dr0 = 0x0, pcb_dr1 = 0x0, pcb_dr2 = 0x0, pcb_dr3 = 0x0, pcb_dr6 = 0x0, pcb_dr7 = 0x0, pcb_gdt = {rd_limit = 0x0, rd_base = 0x0}, pcb_idt = { rd_limit = 0x0, rd_base = 0x0}, pcb_ldt = {rd_limit = 0x0, rd_base = 0x0}, pcb_tr = 0x0, pcb_flags = 0x18, pcb_initial_fpucw = 0x37f, pcb_onfault = 0xffffffff809440f0, pcb_gs32sd = {sd_lolimit = 0x0, sd_lobase = 0x0, sd_type = 0x0, sd_dpl = 0x0, sd_p = 0x0, sd_hilimit = 0x0, sd_xx = 0x0, sd_long = 0x0, sd_def32 = 0x0, sd_gran = 0x0, sd_hibase = 0x0}, pcb_tssp = 0x0, pcb_save = 0xffffff86c6389e00, pcb_user_save = {sv_env = {en_cw = 0x37f, en_sw = 0x0, en_tw = 0x0, en_zero = 0x0, en_opcode = 0x0, en_rip = 0x0, en_rdp = 0x0, en_mxcsr = 0x1fa4, en_mxcsr_mask = 0xffff}, sv_fp = {{ fp_acc = {fp_bytes = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, fp_pad = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, {fp_acc = { fp_bytes = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, fp_pad = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, {fp_acc = {fp_bytes = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, fp_pad = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, {fp_acc = {fp_bytes = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, fp_pad = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, {fp_acc = {fp_bytes = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, fp_pad = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, { fp_acc = {fp_bytes = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, fp_pad = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, {fp_acc = { fp_bytes = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, fp_pad = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, {fp_acc = {fp_bytes = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, fp_pad = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}}, sv_xmm = {{xmm_bytes = { 0x0 }}, {xmm_bytes = {0x0 }}, { xmm_bytes = {0x0 }}, {xmm_bytes = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xe0, 0x3f, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}, {xmm_bytes = {0x0 }} }, sv_pad = { 0x0 }}} -------- #11 0xffffffff8065f6a6 in sysctl_out_proc_copyout (ki=0xffffff86c6389470, req=0xffffff86c63899c0) at /usr/src/sys/kern/kern_proc.c:1085 1085 error = SYSCTL_OUT(req, ki, sizeof(struct kinfo_proc)); -------- range start: $2 = 0x800e96000 range end: $3 = 0x800ea6a79 -------- #16 0xffffffff80675e3a in __sysctl (td=0xffffff0396ec5460, uap=0xffffff86c6389bc0) at /usr/src/sys/kern/kern_sysctl.c:1491 1491 error = userland_sysctl(td, name, uap->namelen, -------- td->td_proc->p_vmspace.vm_map.header: $4 = 0xffffff03d98bedc8 ::start $5 = 0x1000 ::end $6 = 0x800000000000 -------- -------- next: $7 = 0xffffff01f943bb40 ::start $8 = 0x400000 ::end $9 = 0x40c000 -------- -------- next: $10 = 0xffffff01f94cb780 ::start $11 = 0x50c000 ::end $12 = 0x50d000 -------- -------- next: $13 = 0xffffff01f9452690 ::start $14 = 0x50d000 ::end $15 = 0x600000 -------- -------- next: $16 = 0xffffff01f9452ca8 ::start $17 = 0x80050c000 ::end $18 = 0x80053c000 -------- -------- next: $19 = 0xffffff007d349ca8 ::start $20 = 0x80053c000 ::end $21 = 0x800544000 -------- -------- next: $22 = 0xffffff007d3295a0 ::start $23 = 0x80063c000 ::end $24 = 0x800644000 -------- -------- next: $25 = 0xffffff000cf09ac8 ::start $26 = 0x800644000 ::end $27 = 0x800653000 -------- -------- next: $28 = 0xffffff01f9581348 ::start $29 = 0x800653000 ::end $30 = 0x800697000 -------- -------- next: $31 = 0xffffff04d28094b0 ::start $32 = 0x800697000 ::end $33 = 0x800796000 -------- -------- next: $34 = 0xffffff01f9698708 ::start $35 = 0x800796000 ::end $36 = 0x8007a0000 -------- -------- next: $37 = 0xffffff01f94cb708 ::start $38 = 0x8007a0000 ::end $39 = 0x8007be000 -------- -------- next: $40 = 0xffffff012beda348 ::start $41 = 0x8007be000 ::end $42 = 0x8008be000 -------- -------- next: $43 = 0xffffff01f94cc780 ::start $44 = 0x8008be000 ::end $45 = 0x8008c0000 -------- -------- next: $46 = 0xffffff007d330528 ::start $47 = 0x8008c0000 ::end $48 = 0x8008c8000 -------- -------- next: $49 = 0xffffff03f03347f8 ::start $50 = 0x8008c8000 ::end $51 = 0x8009c8000 -------- -------- next: $52 = 0xffffff012beda960 ::start $53 = 0x8009c8000 ::end $54 = 0x8009c9000 -------- -------- next: $55 = 0xffffff01f94b2348 ::start $56 = 0x8009c9000 ::end $57 = 0x800ad2000 -------- -------- next: $58 = 0xffffff052b8144b0 ::start $59 = 0x800ad2000 ::end $60 = 0x800bd1000 -------- -------- next: $61 = 0xffffff007d349d20 ::start $62 = 0x800bd1000 ::end $63 = 0x800bf0000 -------- -------- next: $64 = 0xffffff01f94b2ca8 ::start $65 = 0x800bf0000 ::end $66 = 0x800c0b000 -------- -------- next: $67 = 0xffffff01f943b1e0 ::start $68 = 0x800e00000 ::end $69 = 0x800e96000 ::this entry covers the range $70 = {prev = 0xffffff01f94b2ca8, next = 0xffffff00054f7960, left = 0xffffff01f94b2ca8, right = 0x0, start = 0x800e00000, end = 0x800e96000, avail_ssize = 0x0, adj_free = 0x0, max_free = 0x7fff0c000, object = {vm_object = 0xffffff0342935000, sub_map = 0xffffff0342935000}, offset = 0x210000, eflags = 0x0, protection = 0x3, max_protection = 0x7, inheritance = 0x1, wired_count = 0x0, lastr = 0x2c2, uip = 0x0} -------- -------- next: $71 = 0xffffff00054f7960 ::start $72 = 0x800e96000 ::end $73 = 0x800ea7000 ::this entry covers the range $74 = {prev = 0xffffff01f943b1e0, next = 0xffffff056f97b690, left = 0xffffff01f943b1e0, right = 0xffffff056f97b690, start = 0x800e96000, end = 0x800ea7000, avail_ssize = 0x0, adj_free = 0x0, max_free = 0x7ff7fefe0000, object = {vm_object = 0xffffff0342935000, sub_map = 0xffffff0342935000}, offset = 0x2a6000, eflags = 0x0, protection = 0x3, max_protection = 0x7, inheritance = 0x1, wired_count = 0x1, lastr = 0x2c2, uip = 0x0} -------- -------- next: $75 = 0xffffff056f97b690 ::start $76 = 0x800ea7000 ::end $77 = 0x801000000 -------- -------- next: $78 = 0xffffff01f94cc8e8 ::start $79 = 0x7ffffffe0000 ::end $80 = 0x800000000000 -------- ----Next_Part(Wed_Feb_29_02_26_51_2012_369)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gdb.cmd" set height 0 f 16 echo --------\n echo p/x *(td->td_pcb):\n p/x *(td->td_pcb) echo --------\n f 11 set $start = req->oldptr set $end = $start + req->oldlen echo --------\n echo range start:\n p/x $start echo range end:\n p/x $end echo --------\n f 16 set $h = &td->td_proc->p_vmspace.vm_map.header set $p = $h set $x = 1 echo --------\n echo td->td_proc->p_vmspace.vm_map.header:\n p/x $h echo ::start\n p/x $h->start echo ::end\n p/x $h->end set $map = 0 if ($p->start >= $start) if ($p->start < $end) set $map = 1 end end if ($p->end >= $start) if ($p->end < $end) set $map = 1 end end if ($map > 0) echo ::this entry covers the range\n p/x *$p set $map = 0 end echo --------\n set $p = $p->next while ($x > 0) echo --------\n echo next:\n p/x $p echo ::start\n p/x $p->start echo ::end\n p/x $p->end set $map = 0 if ($p->start >= $start) if ($p->start < $end) set $map = 1 end end if ($p->end >= $start) if ($p->end < $end) set $map = 1 end end if ($map > 0) echo ::this entry covers the range\n p/x *$p set $map = 0 end set $p = $p->next if ($p == $h) set $x = 0 end echo --------\n end quit ----Next_Part(Wed_Feb_29_02_26_51_2012_369)---- ----Security_Multipart0(Wed_Feb_29_02_26_51_2012_049)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk9NDlsACgkQTyzT2CeTzy3TZgCfdpFiMmQ+aaD2XhQMs69Zcd4d 8K0An1HF6L/sW5MbZ/J5o2+929h3WvtB =FQ1R -----END PGP SIGNATURE----- ----Security_Multipart0(Wed_Feb_29_02_26_51_2012_049)---- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 19:03:02 2012 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 5853F106566C; Tue, 28 Feb 2012 19:03:02 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id B28F58FC14; Tue, 28 Feb 2012 19:03:01 +0000 (UTC) Received: by wibhn6 with SMTP id hn6so2373523wib.13 for ; Tue, 28 Feb 2012 11:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0rmRi4545jtd2Xot3mRajgm6aJzJF2NbJRgX3/jKQvE=; b=d5A/BsW5+SqzXInxzTxHblXbEwIt64ND9ji5JAsvvbhsmFtPmfZEpR7b1vFuQMMUnv zmSoFVi8jnZcabBCSohw7WBX4dF9/1/UaCl2oWPcU3w/WyZiFkU//8SBqrsBWB4KpFKV 2zgI/cX5t9XrZre2cXbMY0aQdqII5tL4Ix8rY= MIME-Version: 1.0 Received: by 10.180.92.227 with SMTP id cp3mr33202232wib.13.1330455339795; Tue, 28 Feb 2012 10:55:39 -0800 (PST) Received: by 10.216.166.11 with HTTP; Tue, 28 Feb 2012 10:55:39 -0800 (PST) In-Reply-To: <4F4BA707.5070608@wasikowski.net> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> Date: Tue, 28 Feb 2012 13:55:39 -0500 Message-ID: From: Arnaud Lacombe To: =?ISO-8859-2?Q?=A3ukasz_W=B1sikowski?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , stable@freebsd.org, current@freebsd.org, Alexander Leidinger Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 19:03:02 -0000 Hi, 2012/2/27 =C5=81ukasz W=C4=85sikowski : > W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze: > >> You cannot ship that on by default for non-tecnical reasons in a kernel.= =C2=A0Please do not commit a kernel config that can be booted (no LINT can= not be booted) with these on without consulting appropriate hats upfront. >> >> >>> - ALTQ >>> - SW_WATCHDOG >>> - QUOTA >>> - IPSTEALTH (disabled in loader.conf) >>> - IPFIREWALL_FORWARD (touches every packet, power users which need >>> =C2=A0 a bigger PPS but not this feature can recompile the kernel, >>> =C2=A0 discussed with julian@) >>> - FLOWTABLE (disabled in loader.conf) >> Which is not the same as it's not 100% disabled and will still allocate = memory. > > FLOWTABLE on 8.x crashed BGP routers (kern/144917). > no crash dump, no backtrace, no follow-up whatsoever after 1 year and 2 years, what's your points ? You could really have chosen a better PR to back up your argument... - Arnaud From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 19:13:34 2012 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 6DC271065670; Tue, 28 Feb 2012 19:13:34 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8FDCA8FC19; Tue, 28 Feb 2012 19:13:32 +0000 (UTC) Received: by werl4 with SMTP id l4so1945391wer.13 for ; Tue, 28 Feb 2012 11:13:31 -0800 (PST) Received-SPF: pass (google.com: domain of lacombar@gmail.com designates 10.180.86.230 as permitted sender) client-ip=10.180.86.230; Authentication-Results: mr.google.com; spf=pass (google.com: domain of lacombar@gmail.com designates 10.180.86.230 as permitted sender) smtp.mail=lacombar@gmail.com; dkim=pass header.i=lacombar@gmail.com Received: from mr.google.com ([10.180.86.230]) by 10.180.86.230 with SMTP id s6mr10531410wiz.16.1330456411672 (num_hops = 1); Tue, 28 Feb 2012 11:13:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cLeMyPtN9Dyx33g1RaHqLSo/qMXqO7LyxMpyArghIBw=; b=sDAifRJLYpLhfrDCuV0RhpwK3Yg/GMrq+B3quszU1pkqTzDY3e0M41kxyKzPjT9soF 9zt9Re143RgxTwFJQBWPwRx+ix+L2DM5/1+e+uwKKC0c9BMuxFHxzVVNu8bjDTfSuL9G Wwo4J8tSx9P8ga6O9RH8jLNF+/Bhk1+BaocgI= MIME-Version: 1.0 Received: by 10.180.86.230 with SMTP id s6mr8212317wiz.16.1330454912996; Tue, 28 Feb 2012 10:48:32 -0800 (PST) Received: by 10.216.166.11 with HTTP; Tue, 28 Feb 2012 10:48:32 -0800 (PST) In-Reply-To: <4F4C3FE7.3040802@FreeBSD.org> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> Date: Tue, 28 Feb 2012 13:48:32 -0500 Message-ID: From: Arnaud Lacombe To: Steve Wills Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , stable@freebsd.org, =?ISO-8859-2?Q?=A3ukasz_W=B1sikowski?= , current@freebsd.org, Alexander Leidinger Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 19:13:34 -0000 Hi, 2012/2/27 Steve Wills : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02/27/12 10:53, =C5=81ukasz W=C4=85sikowski wrote: >> W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze: >> >>> You cannot ship that on by default for non-tecnical reasons in a >>> kernel. =C2=A0Please do not commit a kernel config that can be booted >>> (no LINT cannot be booted) with these on without consulting >>> appropriate hats upfront. >>> >>> >>>> - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in >>>> loader.conf) - IPFIREWALL_FORWARD (touches every packet, power >>>> users which need a bigger PPS but not this feature can >>>> recompile the kernel, discussed with julian@) - FLOWTABLE >>>> (disabled in loader.conf) >>> Which is not the same as it's not 100% disabled and will still >>> allocate memory. >> >> FLOWTABLE on 8.x crashed BGP routers (kern/144917). I don't know if >> it is fixed by now, but this kind of potential problematic features >> should not be enabled by default. >> > > Agree, I've run into problems with FLOWTABLE (with just the features > that were enabled by default in 8.0) when routers changed MAC > addresses. As far as I understand it, FLOWTABLE is both broken and > abandoned (but if I'm wrong, please let me know). > You will sure go really far with this kind of "It is broken ? Let's not fix it and disable it instead" mentality, even more when coming from a committer. As long as there will be these kind of comments around here, FreeBSD will deserve nothing but to keep dying piece by piece, and it will be deserved. - Arnaud > So, IMHO, not only should it not be enabled by default, but given that > it was disabled complete in 8.x after 8.0 (too lazy to look at exactly > when right now), I think it shouldn't even be included, since that > might encourage users to try it out only to encounter problems with it. > > Steve > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.18 (FreeBSD) > > iQEcBAEBAgAGBQJPTD/nAAoJEPXPYrMgexuhvWAH/iPa0N32GJXdyL7OdqFNNuEN > R/Z0tOqTCCmAm4WsbAbN3m5poBKNctRtQxG40XoqmvZAWlomwYCwpS2xgCX60NZO > XhspUEpQ7cHQpt6ZOW12x3G6FZJ4DzFX0+mDPYxE/7YmwtsjZFeTFGVEPezeKQwr > Khar5jWYqETmM1+mFvAFXnfTUiBwnqErDfYmHQAE93wKQd9CyzrFmDfooNTiMUB6 > yW+piexN/SzXz6nftQesJbFOWUW6fvhxe9TYcK8+b9zCo2GxPuUrRV60PKQX0apd > nlKWtj49znLVzmpTYboQnvmqmk+yik8wL2wszUaZ4jAjieCjWOhJwCWOvkQ9yIg=3D > =3DSBbK > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 19:39:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDA0A106564A for ; Tue, 28 Feb 2012 19:39:27 +0000 (UTC) (envelope-from harry@yewbarrow.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8B6048FC15 for ; Tue, 28 Feb 2012 19:39:27 +0000 (UTC) Received: by iahk25 with SMTP id k25so874501iah.13 for ; Tue, 28 Feb 2012 11:39:26 -0800 (PST) Received-SPF: pass (google.com: domain of harry@yewbarrow.net designates 10.50.46.194 as permitted sender) client-ip=10.50.46.194; Authentication-Results: mr.google.com; spf=pass (google.com: domain of harry@yewbarrow.net designates 10.50.46.194 as permitted sender) smtp.mail=harry@yewbarrow.net Received: from mr.google.com ([10.50.46.194]) by 10.50.46.194 with SMTP id x2mr4064705igm.60.1330457966962 (num_hops = 1); Tue, 28 Feb 2012 11:39:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.46.194 with SMTP id x2mr3292590igm.60.1330456554096; Tue, 28 Feb 2012 11:15:54 -0800 (PST) Sender: harry@yewbarrow.net Received: by 10.50.173.2 with HTTP; Tue, 28 Feb 2012 11:15:54 -0800 (PST) Date: Tue, 28 Feb 2012 19:15:54 +0000 X-Google-Sender-Auth: Tc4sNhrTZSNCXlC0mP2WenXJeVQ Message-ID: From: Harry Newton To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkPzZtbFvJ8QFrRFIpt+UctNR/Q6oBN7VzXrw9xnA4/zvPe0PiMqhpmWTQpZWiDS5eHaIzO Subject: Regression between 9-RELEASE and 9-STABLE [PCIB ?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 19:39:27 -0000 9-RELEASE works fine. csup to 9-STABLE and make buildworld kernel etc gives a system the hangs during the boot process. There are no error messages during the part boot, and no panic. Last messages before hang are: pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 I am stumped about how to diagnose this, and would be _very_ grateful for any suggestions. When it's hung I can't force a break to debugger (BREAK_TO_DEBUGGER) in kern conf: I imagine I'm too early in the boot sequence. - Harry -- Harry Newton From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 19:58:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B79D106564A for ; Tue, 28 Feb 2012 19:58:26 +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 002D68FC0A for ; Tue, 28 Feb 2012 19:58:25 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q1SJlRps009744; Tue, 28 Feb 2012 11:47:27 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q1SJlRfT009743; Tue, 28 Feb 2012 11:47:27 -0800 (PST) (envelope-from david) Date: Tue, 28 Feb 2012 11:47:27 -0800 From: David Wolfskill To: Harry Newton Message-ID: <20120228194727.GF1548@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , Harry Newton , freebsd-stable@freebsd.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vA66WO2vHvL/CRSR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Regression between 9-RELEASE and 9-STABLE [PCIB ?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 19:58:26 -0000 --vA66WO2vHvL/CRSR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 28, 2012 at 07:15:54PM +0000, Harry Newton wrote: > 9-RELEASE works fine. csup to 9-STABLE and make buildworld kernel etc > gives a system the hangs during the boot process. There are no error > messages during the part boot, and no panic. Last messages before hang > are: >=20 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 >=20 > I am stumped about how to diagnose this, and would be _very_ grateful > for any suggestions. > .... I've been tracking stable/9 daily since it was branched; most recent: FreeBSD g1-227.catwhisker.org 9.0-STABLE FreeBSD 9.0-STABLE #92 232249M: Tu= e Feb 28 04:20:55 PST 2012 root@g1-227.catwhisker.org:/usr/obj/usr/src/= sys/CANARY i386 I have not seen anything like what you report. Above uname is from my laptop; I've also been tracking stable/9 on my home "build" machine. (For that matter, I've also been tracking it nearly weekly on my desktop at work.) 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. --vA66WO2vHvL/CRSR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9NL04ACgkQmprOCmdXAD0bKgCcDEMQQIN+mgKHnZrwDtuT7uKQ 2kcAn0S2u3fk3rn0cs6sZGQAIAxqUP71 =VPke -----END PGP SIGNATURE----- --vA66WO2vHvL/CRSR-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 20:08:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D6AA10656D2 for ; Tue, 28 Feb 2012 20:08:45 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 2345D8FC0C for ; Tue, 28 Feb 2012 20:08:44 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta05.emeryville.ca.mail.comcast.net with comcast id fXKc1i00516AWCUA5Y8kXv; Tue, 28 Feb 2012 20:08:44 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta06.emeryville.ca.mail.comcast.net with comcast id fY8j1i00K4NgCEG8SY8jNh; Tue, 28 Feb 2012 20:08:44 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q1SK8fD1006538; Tue, 28 Feb 2012 13:08:41 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Harry Newton In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Feb 2012 13:08:41 -0700 Message-ID: <1330459721.1023.15.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Regression between 9-RELEASE and 9-STABLE [PCIB ?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 20:08:45 -0000 On Tue, 2012-02-28 at 19:15 +0000, Harry Newton wrote: > 9-RELEASE works fine. csup to 9-STABLE and make buildworld kernel etc > gives a system the hangs during the boot process. There are no error > messages during the part boot, and no panic. Last messages before hang > are: > > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > > I am stumped about how to diagnose this, and would be _very_ grateful > for any suggestions. > > When it's hung I can't force a break to debugger (BREAK_TO_DEBUGGER) > in kern conf: I imagine I'm too early in the boot sequence. > > - Harry > I assume booting verbose doesn't provide any more clues? I've sometimes gotten an extra clue from a hang during boot by building with option BUS_DEBUG. Even if you don't suspect the newbus routines as directly being the problem, sometimes you get a bit more info about what was happening at the time of lockup. -- Ian From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 20:09:31 2012 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 19D831065674; Tue, 28 Feb 2012 20:09:31 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from bijou.wasikowski.net (bijou.wasikowski.net [IPv6:2001:808:10f::1]) by mx1.freebsd.org (Postfix) with ESMTP id B693D8FC14; Tue, 28 Feb 2012 20:09:30 +0000 (UTC) Received: from bijou.wasikowski.net (localhost [127.0.0.1]) by bijou.wasikowski.net (Postfix) with ESMTP id 5B24B5C081; Tue, 28 Feb 2012 21:09:29 +0100 (CET) X-Virus-Scanned: amavisd-new at wasikowski.net Received: from bijou.wasikowski.net ([127.0.0.1]) by bijou.wasikowski.net (bijou.wasikowski.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSR17B2-_tmM; Tue, 28 Feb 2012 21:09:26 +0100 (CET) Received: from [192.168.168.2] (leeloo.unixgroup.pl [62.121.126.31]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by bijou.wasikowski.net (Postfix) with ESMTPSA id 17E185C061; Tue, 28 Feb 2012 21:09:25 +0100 (CET) Message-ID: <4F4D3476.7070803@wasikowski.net> Date: Tue, 28 Feb 2012 21:09:26 +0100 From: =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Arnaud Lacombe References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , stable@freebsd.org, current@freebsd.org, Alexander Leidinger Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 20:09:31 -0000 W dniu 2012-02-28 19:55, Arnaud Lacombe pisze: >> FLOWTABLE on 8.x crashed BGP routers (kern/144917). >> > no crash dump, no backtrace, no follow-up whatsoever after 1 year and > 2 years, what's your points ? You could really have chosen a better PR > to back up your argument... Sorry, but I don't want to bug trace this issue, simply because lack of time, resources and interest in this feature. I've run into this bug on production box, went through hell because of it and turned off flowtable which I do not use and not need. If this problem is still alive (it might be, the PR I've mentioned is still open) then it's not a good idea to turn on this feature by default. If you're interested in using this feature then feel free to debug and test. -- best regards, Lukasz Wasikowski From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 20:59:57 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEB8D106564A for ; Tue, 28 Feb 2012 20:59:57 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 08CCC8FC08 for ; Tue, 28 Feb 2012 20:59:56 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA04447; Tue, 28 Feb 2012 22:59:36 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1S2U91-0005tc-OR; Tue, 28 Feb 2012 22:59:35 +0200 Message-ID: <4F4D403E.2030703@FreeBSD.org> Date: Tue, 28 Feb 2012 22:59:42 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: Alexander Leidinger References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> <20120228162636.Horde.JgORKJjmRSRPTPIsGKfo0uA@webmail.leidinger.net> In-Reply-To: <20120228162636.Horde.JgORKJjmRSRPTPIsGKfo0uA@webmail.leidinger.net> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: fidaj@ukr.net, freebsd-stable@FreeBSD.org, lars.engels@0x20.net, Hans Petter Selasky , vermaden , smithi@nimnet.asn.au Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 20:59:57 -0000 on 28/02/2012 17:26 Alexander Leidinger said the following: > The kernel does not poll for CD changes, and the people guarding the relevant CD > code where against something like this in the kernel everytime this came up in > the past. So no devd event for this. My impression was that lately people were asking for it (and nobody actually "guarded" the code), but there is no good design on how to do it. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 21:05:27 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F4E2106566B for ; Tue, 28 Feb 2012 21:05:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C3D408FC13 for ; Tue, 28 Feb 2012 21:05:26 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA04519; Tue, 28 Feb 2012 23:05:22 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1S2UEc-0005tr-5l; Tue, 28 Feb 2012 23:05:22 +0200 Message-ID: <4F4D4199.2000806@FreeBSD.org> Date: Tue, 28 Feb 2012 23:05:29 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Eugene M. Zheganin" References: <4F4B0F83.4090600@norma.perm.ru> In-Reply-To: <4F4B0F83.4090600@norma.perm.ru> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: zfs, 1 gig of RAM and periodic weekly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 21:05:27 -0000 on 27/02/2012 07:07 Eugene M. Zheganin said the following: > vfs.zfs.arc_max="30M" I am not much of an expert in tuning ZFS, and for low-end systems in particular... But it seems to me that with this setting you are actually stress ("torture") testing ZFS rather than using it. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 21:08:36 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5C8D106566C for ; Tue, 28 Feb 2012 21:08:36 +0000 (UTC) (envelope-from gorshkov.pavel@gmail.com) Received: from imp03.mtu.ru (imp03.mtu.ru [62.5.255.20]) by mx1.freebsd.org (Postfix) with ESMTP id 3F3D88FC16 for ; Tue, 28 Feb 2012 21:08:35 +0000 (UTC) Received: from imp01.mtu.ru ([62.5.255.10]) by imp03.mtu.ru with bizsmtp id fZ0P1i0020EE5t201Z0PBa; Wed, 29 Feb 2012 01:00:23 +0400 Received: from localhost.my.domain ([91.79.89.204]) by imp01.mtu.ru with bizsmtp id fYyP1i00C4QYEkj01YyP0m; Wed, 29 Feb 2012 00:58:23 +0400 Received: from localhost (localhost [127.0.0.1]) by localhost.my.domain (8.14.5/8.14.5) with ESMTP id q1SL3TbS002749 for ; Wed, 29 Feb 2012 01:03:29 +0400 (MSK) (envelope-from gorshkov.pavel@gmail.com) Date: Wed, 29 Feb 2012 01:03:29 +0400 From: Pavel Gorshkov To: freebsd-stable@freebsd.org Message-ID: <20120228210329.GA2741@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: msk0: interrupt storm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 21:08:36 -0000 My laptop running 9.0-RELEASE/amd64/GENERIC freezes and (sometimes) unfreezes intermittently, logging the following: Feb 28 23:07:36 lifebook kernel: interrupt storm detected on "irq259:"; throttling interrupt source $ vmstat -i ... irq259: mskc0 11669511 3456 Looks very similar to this: http://www.freebsd.org/cgi/query-pr.cgi?pr=164569 Any suggestions? From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 21:22:15 2012 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 3ADA21065670; Tue, 28 Feb 2012 21:22:15 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 908938FC14; Tue, 28 Feb 2012 21:22:14 +0000 (UTC) Received: by werl4 with SMTP id l4so2042383wer.13 for ; Tue, 28 Feb 2012 13:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hoSM0CBFVjxbNg4+kQSB9MqwTshFdeQu1h3Tk9QS/uw=; b=mqtoTvoXJIeIBSO2e1Ti6hHGecY0f3/A1n+BUcwkpzxXpW+PnnQPbkGs/KJZEDPD45 TwCJyKnl1TACvpchWJApidDhjIB9EXLQJI+QY00td2J0yOyx2jUrKUAAmodN9DubZ5Og n1HV63CNgXrZi8wj8CPZibFBKeLjzLRaba3zo= MIME-Version: 1.0 Received: by 10.180.92.227 with SMTP id cp3mr33976243wib.13.1330464133524; Tue, 28 Feb 2012 13:22:13 -0800 (PST) Received: by 10.216.166.11 with HTTP; Tue, 28 Feb 2012 13:22:13 -0800 (PST) In-Reply-To: <4F4D3476.7070803@wasikowski.net> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4D3476.7070803@wasikowski.net> Date: Tue, 28 Feb 2012 16:22:13 -0500 Message-ID: From: Arnaud Lacombe To: =?ISO-8859-2?Q?=A3ukasz_W=B1sikowski?= Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , stable@freebsd.org, current@freebsd.org, Alexander Leidinger Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 21:22:15 -0000 Hi, 2012/2/28 =A3ukasz W=B1sikowski : > W dniu 2012-02-28 19:55, Arnaud Lacombe pisze: > >>> FLOWTABLE on 8.x crashed BGP routers (kern/144917). >>> >> no crash dump, no backtrace, no follow-up whatsoever after 1 year and >> 2 years, what's your points ? You could really have chosen a better PR >> to back up your argument... > > Sorry, but I don't want to bug trace this issue, simply because lack of > time, resources and interest in this feature. I've run into this bug on > production box, went through hell because of it and turned off flowtable > which I do not use and not need. If this problem is still alive (it > might be, the PR I've mentioned is still open) then it's not a good idea > to turn on this feature by default. If you're interested in using this > feature then feel free to debug and test. > Give me a deterministic way to reproduce the issue and I will. - Arnaud From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 21:56:33 2012 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 A0CB31065670; Tue, 28 Feb 2012 21:56:33 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from bijou.wasikowski.net (bijou.wasikowski.net [IPv6:2001:808:10f::1]) by mx1.freebsd.org (Postfix) with ESMTP id 48B368FC15; Tue, 28 Feb 2012 21:56:33 +0000 (UTC) Received: from bijou.wasikowski.net (localhost [127.0.0.1]) by bijou.wasikowski.net (Postfix) with ESMTP id F047F5C082; Tue, 28 Feb 2012 22:56:31 +0100 (CET) X-Virus-Scanned: amavisd-new at wasikowski.net Received: from bijou.wasikowski.net ([127.0.0.1]) by bijou.wasikowski.net (bijou.wasikowski.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PN3JaArPdY3; Tue, 28 Feb 2012 22:56:25 +0100 (CET) Received: from [192.168.168.2] (leeloo.unixgroup.pl [62.121.126.31]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by bijou.wasikowski.net (Postfix) with ESMTPSA id 909475C081; Tue, 28 Feb 2012 22:56:24 +0100 (CET) Message-ID: <4F4D4D88.8040500@wasikowski.net> Date: Tue, 28 Feb 2012 22:56:24 +0100 From: =?ISO-8859-2?Q?=A3ukasz_W=B1sikowski?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Arnaud Lacombe References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4D3476.7070803@wasikowski.net> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , stable@freebsd.org, current@freebsd.org, Alexander Leidinger Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 21:56:33 -0000 W dniu 2012-02-28 22:22, Arnaud Lacombe pisze: >>>> FLOWTABLE on 8.x crashed BGP routers (kern/144917). >>>> >>> no crash dump, no backtrace, no follow-up whatsoever after 1 year and >>> 2 years, what's your points ? You could really have chosen a better PR >>> to back up your argument... >> >> Sorry, but I don't want to bug trace this issue, simply because lack of >> time, resources and interest in this feature. I've run into this bug on >> production box, went through hell because of it and turned off flowtable >> which I do not use and not need. If this problem is still alive (it >> might be, the PR I've mentioned is still open) then it's not a good idea >> to turn on this feature by default. If you're interested in using this >> feature then feel free to debug and test. >> > Give me a deterministic way to reproduce the issue and I will. Enable FLOWTABLES in kernel and setup BGP4+ router (with net/quagga). You need three peers sending you full Internet routing table (3x400k prefixes). Some people got it with only two peers. After a short while your CPU should stuck in 100% busy. -- best regards, Lukasz Wasikowski From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 22:04:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40D6C106564A; Tue, 28 Feb 2012 22:04:25 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id E68548FC08; Tue, 28 Feb 2012 22:04:24 +0000 (UTC) Date: Tue, 28 Feb 2012 23:04:23 +0100 From: vermaden To: Andriy Gapon X-Mailer: interia.pl/pf09 In-Reply-To: <4F4D403E.2030703@FreeBSD.org> References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> <20120228162636.Horde.JgORKJjmRSRPTPIsGKfo0uA@webmail.leidinger.net> <4F4D403E.2030703@FreeBSD.org> X-Originating-IP: 85.89.187.172 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1330466663; bh=UqMCdTk6D0n9t+iIQ9VZ8/rcIX30ExeebxmMaRyJHS8=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=D+mB1Jeu6S5dtawPotZqyScXYC6iQGaRULFl/V7QP8iwwQN2xj4n/UBuBoH0PmBB/ Fq9U6aR6FMmbAkgCRCpTyaRTOGVBDSIxExJwqKGiSOT44Pa2v+GYuneOkOcKSVY9Ay ufZ3ZFwHXowpJ6+gMBla7Z7YxI00uBSH0b+ZZgNo= Cc: fidaj@ukr.net, freebsd-stable@FreeBSD.org, lars.engels@0x20.net, Hans Petter Selasky , Alexander Leidinger , smithi@nimnet.asn.au Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 22:04:25 -0000 "Andriy Gapon" said: > on 28/02/2012 17:26 Alexander Leidinger said the following: > > The kernel does not poll for CD changes, and the people guarding the re= levant CD > > code where against something like this in the kernel everytime this cam= e up in > > the past. So no devd event for this. >=20 > My impression was that lately people were asking for it (and nobody actua= lly > "guarded" the code), but there is no good design on how to do it. The mentioned earlier sysctl OID changes whenever CD is in the drive or not, something changes that ... so adding appreciate events like "MEDIA INSERTED" and "MEDIA REMOVED" to cd* class should be enought to handle them and mount/umount the medium with script like mine with appreciate devd(8) config. Regards, vermaden ... From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 22:11:49 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4520E106566B for ; Tue, 28 Feb 2012 22:11:49 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 86EF48FC12 for ; Tue, 28 Feb 2012 22:11:48 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA05260; Wed, 29 Feb 2012 00:11:20 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1S2VGS-0005xE-7J; Wed, 29 Feb 2012 00:11:20 +0200 Message-ID: <4F4D510E.60206@FreeBSD.org> Date: Wed, 29 Feb 2012 00:11:26 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: vermaden References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> <20120228162636.Horde.JgORKJjmRSRPTPIsGKfo0uA@webmail.leidinger.net> <4F4D403E.2030703@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: fidaj@ukr.net, freebsd-stable@FreeBSD.org, lars.engels@0x20.net, Hans Petter Selasky , Alexander Leidinger , smithi@nimnet.asn.au Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 22:11:49 -0000 on 29/02/2012 00:04 vermaden said the following: > "Andriy Gapon" said: >> on 28/02/2012 17:26 Alexander Leidinger said the following: >>> The kernel does not poll for CD changes, and the people guarding the relevant CD >>> code where against something like this in the kernel everytime this came up in >>> the past. So no devd event for this. >> >> My impression was that lately people were asking for it (and nobody actually >> "guarded" the code), but there is no good design on how to do it. > > The mentioned earlier sysctl OID changes whenever CD is in the > drive or not, something changes that ... so adding appreciate > events like "MEDIA INSERTED" and "MEDIA REMOVED" to cd* class > should be enought to handle them and mount/umount the > medium with script like mine with appreciate devd(8) config. I don't think that there is any kernel component that pro-actively changes that value. Most likely you have something like hald running or otherwise tried to access the device before the change was noted. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 22:13:14 2012 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 9C0CB1065675; Tue, 28 Feb 2012 22:13:14 +0000 (UTC) (envelope-from lukasz@wasikowski.net) Received: from bijou.wasikowski.net (bijou.wasikowski.net [IPv6:2001:808:10f::1]) by mx1.freebsd.org (Postfix) with ESMTP id 43C428FC17; Tue, 28 Feb 2012 22:13:14 +0000 (UTC) Received: from bijou.wasikowski.net (localhost [127.0.0.1]) by bijou.wasikowski.net (Postfix) with ESMTP id 7F59C5C082; Tue, 28 Feb 2012 23:13:13 +0100 (CET) X-Virus-Scanned: amavisd-new at wasikowski.net Received: from bijou.wasikowski.net ([127.0.0.1]) by bijou.wasikowski.net (bijou.wasikowski.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDkv5Ch9v7AG; Tue, 28 Feb 2012 23:13:11 +0100 (CET) Received: from [192.168.168.2] (leeloo.unixgroup.pl [62.121.126.31]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by bijou.wasikowski.net (Postfix) with ESMTPSA id CC81D5C081; Tue, 28 Feb 2012 23:13:11 +0100 (CET) Message-ID: <4F4D5178.9080904@wasikowski.net> Date: Tue, 28 Feb 2012 23:13:12 +0100 From: =?ISO-8859-2?Q?=A3ukasz_W=B1sikowski?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Arnaud Lacombe References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4D3476.7070803@wasikowski.net> <4F4D4D88.8040500@wasikowski.net> In-Reply-To: <4F4D4D88.8040500@wasikowski.net> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Cc: "Bjoern A. Zeeb" , stable@freebsd.org, current@freebsd.org, Alexander Leidinger Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 22:13:14 -0000 W dniu 2012-02-28 22:56, £ukasz W±sikowski pisze: >>>>> FLOWTABLE on 8.x crashed BGP routers (kern/144917). >>>>> >>>> no crash dump, no backtrace, no follow-up whatsoever after 1 year and >>>> 2 years, what's your points ? You could really have chosen a better PR >>>> to back up your argument... >>> >>> Sorry, but I don't want to bug trace this issue, simply because lack of >>> time, resources and interest in this feature. I've run into this bug on >>> production box, went through hell because of it and turned off flowtable >>> which I do not use and not need. If this problem is still alive (it >>> might be, the PR I've mentioned is still open) then it's not a good idea >>> to turn on this feature by default. If you're interested in using this >>> feature then feel free to debug and test. >>> >> Give me a deterministic way to reproduce the issue and I will. > > Enable FLOWTABLES in kernel and setup BGP4+ router (with net/quagga). > You need three peers sending you full Internet routing table (3x400k > prefixes). Some people got it with only two peers. After a short while > your CPU should stuck in 100% busy. I forgot one thing which may be important. IP addresses used for BGP sessions was heartbeated. So you first need to use those addresses on another box, then move them to flowtable box and run quagga with BGP on it. -- best regards, Lukasz Wasikowski From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 22:15:14 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 1D03F1065673; Tue, 28 Feb 2012 22:15:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B9EFC163578; Tue, 28 Feb 2012 22:14:35 +0000 (UTC) Message-ID: <4F4D51CB.2010508@FreeBSD.org> Date: Tue, 28 Feb 2012 14:14:35 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Arnaud Lacombe References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, current@freebsd.org, Steve Wills , =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= , "Bjoern A. Zeeb" , Alexander Leidinger Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 22:15:14 -0000 On 2/28/2012 10:48 AM, Arnaud Lacombe wrote: > You will sure go really far with this kind of "It is broken ? Let's > not fix it and disable it instead" mentality, even more when coming > from a committer. > > As long as there will be these kind of comments around here, FreeBSD > will deserve nothing but to keep dying piece by piece, and it will be > deserved. In general, I tend to agree with you, but in this case it's useful to know the history of the flowtable option. 1. It was introduced in -current 2. It received fairly good testing, was pronounced good and useful, and MFC'ed. 3. Several releases happened with flowtable. 4. Users started to report problems that were ultimately tracked down to flowtable. 5. Ultimately it was decided that flowtable was not a universal good. 6. The developer of the option agreed that it should be disabled by default until such time as it can be fixed. 7. The fixing hasn't happened yet. While generally fixing things is the right solution, if the fix is complex (or worse, unknown AND complex) then disabling by default is a reasonable answer. Doug -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 22:24:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93061106566C; Tue, 28 Feb 2012 22:24:06 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 45EFE8FC15; Tue, 28 Feb 2012 22:24:06 +0000 (UTC) Date: Tue, 28 Feb 2012 23:24:05 +0100 From: vermaden To: Andriy Gapon X-Mailer: interia.pl/pf09 In-Reply-To: <4F4D510E.60206@FreeBSD.org> References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> <20120228162636.Horde.JgORKJjmRSRPTPIsGKfo0uA@webmail.leidinger.net> <4F4D403E.2030703@FreeBSD.org> <4F4D510E.60206@FreeBSD.org> X-Originating-IP: 85.89.187.172 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1330467845; bh=PYe118ZXvSihh3opR0V/uh4ICWzBLbXwsshR4lj4hDo=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=tql6yCOKGZuuE7gTyHCu8/UlfE14k8HaU7K8qfFvCfiVB4PVxvFP3UF1rdTksF/vb MugCJRTrjbbyfSOZEzwwB9AuhH2RRq2bGGcAr8vtHxgLAc3j/bQRKd4eR1o9N0pOFR ivC3o2E9e2Kyl2twsI5fQIoH11uN60FG/F4bdOg0= Cc: fidaj@ukr.net, freebsd-stable@FreeBSD.org, lars.engels@0x20.net, Hans Petter Selasky , Alexander Leidinger , smithi@nimnet.asn.au Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 22:24:06 -0000 "Andriy Gapon" pisze: > on 29/02/2012 00:04 vermaden said the following: > > "Andriy Gapon" said: > >> on 28/02/2012 17:26 Alexander Leidinger said the following: > >>> The kernel does not poll for CD changes, and the people guarding the = relevant CD > >>> code where against something like this in the kernel everytime this c= ame up in > >>> the past. So no devd event for this. > >> > >> My impression was that lately people were asking for it (and nobody ac= tually > >> "guarded" the code), but there is no good design on how to do it. > >=20 > > The mentioned earlier sysctl OID changes whenever CD is in the > > drive or not, something changes that ... so adding appreciate > > events like "MEDIA INSERTED" and "MEDIA REMOVED" to cd* class > > should be enought to handle them and mount/umount the > > medium with script like mine with appreciate devd(8) config. >=20 > I don't think that there is any kernel component that pro-actively change= s that > value. Most likely you have something like hald running or otherwise tri= ed to > access the device before the change was noted. I do not even have working CD drive in my laptop, so I cant tell ;) Ivan Klymenko sent this earlier in that thread: NO CD: > kern.geom.conftxt: 0 DISK cd0 0 2048 hd 0 sc 0 CD IN: > kern.geom.conftxt: 0 DISK cd0 4700372992 2048 hd 0 sc 0 Regards, vermaden ... From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 22:26:28 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F798106566B for ; Tue, 28 Feb 2012 22:26:28 +0000 (UTC) (envelope-from harry@yewbarrow.net) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1C6768FC0A for ; Tue, 28 Feb 2012 22:26:26 +0000 (UTC) Received: by yenq7 with SMTP id q7so1298002yen.13 for ; Tue, 28 Feb 2012 14:26:25 -0800 (PST) Received-SPF: pass (google.com: domain of harry@yewbarrow.net designates 10.50.191.163 as permitted sender) client-ip=10.50.191.163; Authentication-Results: mr.google.com; spf=pass (google.com: domain of harry@yewbarrow.net designates 10.50.191.163 as permitted sender) smtp.mail=harry@yewbarrow.net Received: from mr.google.com ([10.50.191.163]) by 10.50.191.163 with SMTP id gz3mr4580241igc.60.1330467985763 (num_hops = 1); Tue, 28 Feb 2012 14:26:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.191.163 with SMTP id gz3mr3798023igc.60.1330467985681; Tue, 28 Feb 2012 14:26:25 -0800 (PST) Sender: harry@yewbarrow.net Received: by 10.50.173.2 with HTTP; Tue, 28 Feb 2012 14:26:25 -0800 (PST) In-Reply-To: <1330459721.1023.15.camel@revolution.hippie.lan> References: <1330459721.1023.15.camel@revolution.hippie.lan> Date: Tue, 28 Feb 2012 22:26:25 +0000 X-Google-Sender-Auth: 0bP3ItUQhM2nube_wUT3jL4H5zI Message-ID: From: Harry Newton To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnogfsJUw7l8DKm9Mn5ulHfGfPlNmFNrcx1qyeFxdEP9ez7+rBbSwsaRh/ox+4ofp6CawhG Cc: freebsd-stable@freebsd.org Subject: Re: Regression between 9-RELEASE and 9-STABLE [PCIB ?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 22:26:28 -0000 Not really. Verbose suggests it completes the scan of the PCI to LPC Bridge and PCI to PCI bridge. Comparing with a working verbose boot, the next stage, which isn't reached, is HyperTransport Technology Configuration. Trying BUS_DEBUG, I got a lot of this: device_add_child_ordered: 1813: (null) at pci with orer 0 as unit -1 make_device: 1698: (null) at pci as unit -1 I neglected to say before: the machine's been running FreeBSD 7-STABLE quite happily with no problems. - Harry On 28 February 2012 20:08, Ian Lepore wrote= : > On Tue, 2012-02-28 at 19:15 +0000, Harry Newton wrote: >> 9-RELEASE works fine. csup to 9-STABLE and make buildworld kernel etc >> gives a system the hangs during the boot process. There are no error >> messages during the part boot, and no panic. Last messages before hang >> are: >> >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> >> I am stumped about how to diagnose this, and would be _very_ grateful >> for any suggestions. >> >> When it's hung I can't force a break to debugger (BREAK_TO_DEBUGGER) >> in kern conf: I imagine I'm too early in the boot sequence. >> >> - Harry >> > > I assume booting verbose doesn't provide any more clues? =A0I've sometime= s > gotten an extra clue from a hang during boot by building with option > BUS_DEBUG. =A0Even if you don't suspect the newbus routines as directly > being the problem, sometimes you get a bit more info about what was > happening at the time of lockup. > > -- Ian > > --=20 Harry Newton From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 23:04:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3AB2106566C for ; Tue, 28 Feb 2012 23:04:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 675258FC0A for ; Tue, 28 Feb 2012 23:04:56 +0000 (UTC) Received: by wibhn6 with SMTP id hn6so2531873wib.13 for ; Tue, 28 Feb 2012 15:04:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SNj4TPcjX/lzSrAxIHGpCXRdfozkrFFa3p7Ba98JKNA=; b=FdspC3vwrGZhsCIv3UNB3/fkOUEWOSqV/pe4idjikuGcBfG4iZLKXGMV4/VrCUwk0q y3yv2IRJrYNNfKfmo+gHNcEh3pw4e1dw5SsFk/0n2KkuZBg2ogKdFlgaDouota5WQUry EhRkOOvR2FzjTmtJgv3h5j6V2JZxtjLxXLqF0= MIME-Version: 1.0 Received: by 10.181.11.227 with SMTP id el3mr34014996wid.18.1330470295524; Tue, 28 Feb 2012 15:04:55 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.198.81 with HTTP; Tue, 28 Feb 2012 15:04:55 -0800 (PST) In-Reply-To: References: <1330459721.1023.15.camel@revolution.hippie.lan> Date: Tue, 28 Feb 2012 15:04:55 -0800 X-Google-Sender-Auth: 4TOlNpk46j84WMckmAh91QWKKaA Message-ID: From: Adrian Chadd To: Harry Newton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ian Lepore , freebsd-stable@freebsd.org, jhb@freebsd.org Subject: Re: Regression between 9-RELEASE and 9-STABLE [PCIB ?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 23:04:58 -0000 A lot of the PCI bus enumeration and configuration code has changed. John's likely the best person to bring into this. He's been doing a lot of the PCI bus hacking and has found/fixed quite a few regressions. Good luck! Adrian On 28 February 2012 14:26, Harry Newton wrote: > Not really. Verbose suggests it completes the scan of the PCI to LPC > Bridge and PCI to PCI bridge. Comparing with a working verbose boot, > the next stage, which isn't reached, is HyperTransport Technology > Configuration. > > Trying BUS_DEBUG, I got a lot of this: > > device_add_child_ordered: 1813: (null) at pci with orer 0 as unit -1 > make_device: 1698: (null) at pci as unit -1 > > I neglected to say before: the machine's been running FreeBSD 7-STABLE > quite happily with no problems. > > - Harry > > > On 28 February 2012 20:08, Ian Lepore wro= te: >> On Tue, 2012-02-28 at 19:15 +0000, Harry Newton wrote: >>> 9-RELEASE works fine. csup to 9-STABLE and make buildworld kernel etc >>> gives a system the hangs during the boot process. There are no error >>> messages during the part boot, and no panic. Last messages before hang >>> are: >>> >>> pcib0: port 0xcf8-0xcff on acpi0 >>> pci0: on pcib0 >>> >>> I am stumped about how to diagnose this, and would be _very_ grateful >>> for any suggestions. >>> >>> When it's hung I can't force a break to debugger (BREAK_TO_DEBUGGER) >>> in kern conf: I imagine I'm too early in the boot sequence. >>> >>> - Harry >>> >> >> I assume booting verbose doesn't provide any more clues? =A0I've sometim= es >> gotten an extra clue from a hang during boot by building with option >> BUS_DEBUG. =A0Even if you don't suspect the newbus routines as directly >> being the problem, sometimes you get a bit more info about what was >> happening at the time of lockup. >> >> -- Ian >> >> > > > > -- > Harry Newton > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 23:08:18 2012 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 D0552106564A; Tue, 28 Feb 2012 23:08:18 +0000 (UTC) (envelope-from flo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9839B8FC08; Tue, 28 Feb 2012 23:08:18 +0000 (UTC) Received: from nibbler-wlan.fritz.box (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1SN8ELo040638; Tue, 28 Feb 2012 23:08:15 GMT (envelope-from flo@FreeBSD.org) Message-ID: <4F4D5E5D.9040302@FreeBSD.org> Date: Wed, 29 Feb 2012 00:08:13 +0100 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120222 Thunderbird/11.0 MIME-Version: 1.0 To: Doug Barton References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> In-Reply-To: <4F4D51CB.2010508@FreeBSD.org> X-Enigmail-Version: 1.4a1pre Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFF6DB0873B17E8CFCEC0B443" Cc: stable@FreeBSD.org, current@FreeBSD.org, Steve Wills , =?UTF-8?B?eiBXxIVzaWtvd3NraQ==?= , Arnaud Lacombe , Alexander Leidinger , "Bjoern A. Zeeb" , =?UTF-8?B?xYF1a2Fz?= Subject: flowtable usable or not (was: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 23:08:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFF6DB0873B17E8CFCEC0B443 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 28.02.12 23:14, Doug Barton wrote: > On 2/28/2012 10:48 AM, Arnaud Lacombe wrote: >> You will sure go really far with this kind of "It is broken ? Let's >> not fix it and disable it instead" mentality, even more when coming >> from a committer. >> >> As long as there will be these kind of comments around here, FreeBSD >> will deserve nothing but to keep dying piece by piece, and it will be >> deserved. >=20 > In general, I tend to agree with you, but in this case it's useful to > know the history of the flowtable option. >=20 > 1. It was introduced in -current > 2. It received fairly good testing, was pronounced good and useful, and= > MFC'ed. > 3. Several releases happened with flowtable. > 4. Users started to report problems that were ultimately tracked down t= o > flowtable. > 5. Ultimately it was decided that flowtable was not a universal good. > 6. The developer of the option agreed that it should be disabled by > default until such time as it can be fixed. > 7. The fixing hasn't happened yet. >=20 I talked to Kip Macy, who implemented flowtable, about this. He thinks that the problem was caused by inappropriate default setting of net.inet.ip.output_flowtable_size. This should have been fixed by r205488 which was MFC'd to 8 and should be part of 8.2 and of course 9.0. However nobody who experienced the problem wanted to try any of these releases with flowtable enabled, so we still don't know if it's fixed or not. Should anyone try this it could certainly be the case that net.inet.ip.output_flowtable_size needs to be tuned even more. Florian --------------enigFF6DB0873B17E8CFCEC0B443 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk9NXl4ACgkQapo8P8lCvwmVJACggwmUsmUEH8dfi/1tY+k3JGUu ATIAnR+lR8pRo+kQNGeXpX/mdmcHKS4C =+h1y -----END PGP SIGNATURE----- --------------enigFF6DB0873B17E8CFCEC0B443-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 28 23:10:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEAF0106566B for ; Tue, 28 Feb 2012 23:10:52 +0000 (UTC) (envelope-from harry@yewbarrow.net) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 67E838FC15 for ; Tue, 28 Feb 2012 23:10:52 +0000 (UTC) Received: by yenq7 with SMTP id q7so1315423yen.13 for ; Tue, 28 Feb 2012 15:10:51 -0800 (PST) Received-SPF: pass (google.com: domain of harry@yewbarrow.net designates 10.50.195.131 as permitted sender) client-ip=10.50.195.131; Authentication-Results: mr.google.com; spf=pass (google.com: domain of harry@yewbarrow.net designates 10.50.195.131 as permitted sender) smtp.mail=harry@yewbarrow.net Received: from mr.google.com ([10.50.195.131]) by 10.50.195.131 with SMTP id ie3mr4740630igc.52.1330470651401 (num_hops = 1); Tue, 28 Feb 2012 15:10:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.195.131 with SMTP id ie3mr3934904igc.52.1330470651327; Tue, 28 Feb 2012 15:10:51 -0800 (PST) Sender: harry@yewbarrow.net Received: by 10.50.173.2 with HTTP; Tue, 28 Feb 2012 15:10:51 -0800 (PST) In-Reply-To: References: <1330459721.1023.15.camel@revolution.hippie.lan> Date: Tue, 28 Feb 2012 23:10:51 +0000 X-Google-Sender-Auth: hAs1cw2q0tRWUpOL4VbDhe1DyNw Message-ID: From: Harry Newton To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmeO2oJcWvQVpx81qNHsR9HHmeMaEL0Y9x2DrsOZoe8PyRpEDGSD3Z3CZJqGNlAffBwxpH9 Cc: Ian Lepore , freebsd-stable@freebsd.org, jhb@freebsd.org Subject: Re: Regression between 9-RELEASE and 9-STABLE [PCIB ?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Feb 2012 23:10:52 -0000 Adrian - thanks ! John, if you write me a shopping list of what information you think useful, assuming you have time and inclination, I'll do my best provide it. On 28 February 2012 23:04, Adrian Chadd wrote: > A lot of the PCI bus enumeration and configuration code has changed. > > John's likely the best person to bring into this. He's been doing a > lot of the PCI bus hacking and has found/fixed quite a few > regressions. > > Good luck! > > > > Adrian > > > On 28 February 2012 14:26, Harry Newton wrote: >> Not really. Verbose suggests it completes the scan of the PCI to LPC >> Bridge and PCI to PCI bridge. Comparing with a working verbose boot, >> the next stage, which isn't reached, is HyperTransport Technology >> Configuration. >> >> Trying BUS_DEBUG, I got a lot of this: >> >> device_add_child_ordered: 1813: (null) at pci with orer 0 as unit -1 >> make_device: 1698: (null) at pci as unit -1 >> >> I neglected to say before: the machine's been running FreeBSD 7-STABLE >> quite happily with no problems. >> >> - Harry >> >> >> On 28 February 2012 20:08, Ian Lepore wr= ote: >>> On Tue, 2012-02-28 at 19:15 +0000, Harry Newton wrote: >>>> 9-RELEASE works fine. csup to 9-STABLE and make buildworld kernel etc >>>> gives a system the hangs during the boot process. There are no error >>>> messages during the part boot, and no panic. Last messages before hang >>>> are: >>>> >>>> pcib0: port 0xcf8-0xcff on acpi0 >>>> pci0: on pcib0 >>>> >>>> I am stumped about how to diagnose this, and would be _very_ grateful >>>> for any suggestions. >>>> >>>> When it's hung I can't force a break to debugger (BREAK_TO_DEBUGGER) >>>> in kern conf: I imagine I'm too early in the boot sequence. >>>> >>>> - Harry >>>> >>> >>> I assume booting verbose doesn't provide any more clues? =A0I've someti= mes >>> gotten an extra clue from a hang during boot by building with option >>> BUS_DEBUG. =A0Even if you don't suspect the newbus routines as directly >>> being the problem, sometimes you get a bit more info about what was >>> happening at the time of lockup. >>> >>> -- Ian >>> >>> >> >> >> >> -- >> Harry Newton >> _______________________________________________ >> 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 Harry Newton From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 06:16:25 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F498106564A for ; Wed, 29 Feb 2012 06:16:25 +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 632948FC0C for ; Wed, 29 Feb 2012 06:16:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q1T6Fcrx008022; Wed, 29 Feb 2012 17:15:38 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 29 Feb 2012 17:15:38 +1100 (EST) From: Ian Smith To: vermaden In-Reply-To: Message-ID: <20120229163223.L80360@sola.nimnet.asn.au> References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> <20120228162636.Horde.JgORKJjmRSRPTPIsGKfo0uA@webmail.leidinger.net> <4F4D403E.2030703@FreeBSD.org> <4F4D510E.60206@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: fidaj@ukr.net, freebsd-stable@FreeBSD.org, lars.engels@0x20.net, Andriy Gapon , Hans Petter Selasky , Alexander Leidinger Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 06:16:25 -0000 On Tue, 28 Feb 2012, vermaden wrote: > "Andriy Gapon" pisze: > > on 29/02/2012 00:04 vermaden said the following: > > > "Andriy Gapon" said: > > >> on 28/02/2012 17:26 Alexander Leidinger said the following: > > >>> The kernel does not poll for CD changes, and the people guarding the relevant CD > > >>> code where against something like this in the kernel everytime this came up in > > >>> the past. So no devd event for this. > > >> > > >> My impression was that lately people were asking for it (and nobody actually > > >> "guarded" the code), but there is no good design on how to do it. > > > > > > The mentioned earlier sysctl OID changes whenever CD is in the > > > drive or not, something changes that ... so adding appreciate > > > events like "MEDIA INSERTED" and "MEDIA REMOVED" to cd* class > > > should be enought to handle them and mount/umount the > > > medium with script like mine with appreciate devd(8) config. > > > > I don't think that there is any kernel component that pro-actively changes that > > value. Most likely you have something like hald running or otherwise tried to > > access the device before the change was noted. > > I do not even have working CD drive in my laptop, so I cant tell ;) > > Ivan Klymenko sent this earlier in that thread: > > NO CD: > > kern.geom.conftxt: 0 DISK cd0 0 2048 hd 0 sc 0 > > CD IN: > > kern.geom.conftxt: 0 DISK cd0 4700372992 2048 hd 0 sc 0 That looks like a DVD, I only have a CDRW in this .. but inserting either a music or a data CD has no effect whatsoever on that sysctl here, on 8.2-RELEASE anyway, which still has /dev/acd0 as well. Further, it's not so easy to parse: t23# sysctl kern.geom.conftxt t23# ie nothing, but no 'unknown oid' either, huh? t23# sysctl -d kern.geom.conftxt kern.geom.conftxt: Dump the GEOM config in txt Hmm, checking sysctl(8), only the -b switch seems to dump it: t23# sysctl -b kern.geom.conftxt 0 DISK cd0 534181888 2048 hd 0 sc 0 0 DISK ad0 120034123776 512 hd 16 sc 63 1 PART ad0s4 34143137280 512 i 4 o 85888373760 ty freebsd xs MBR xt 165 [.. partitions on slices s4, s3, s2 and DOS slice s1 shown, omitted ..] but: t23# sysctl -b kern.geom.conftxt | grep cd0 Binary file (standard input) matches Note also that the above entry for cd0 does NOT change after inserting various different data CDs, all different sizes, nor after mounting one, so that 534181888 entry is from some time before, perhaps the first CD inserted after boot, not sure? Also the sizes are bytes, regardless of sector size (DVD above, while ad0s4 is a 32GiB slice on a 120GB disk). Doesn't look like this one is going to fly. cheers, Ian (meanwhile other progress is looking good, maybe I'll get some time next month to play with it, still behind due to aforesaid near-disaster :) From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 07:23:55 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 45A21106564A; Wed, 29 Feb 2012 07:23:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-197-151.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 22B1417755D; Wed, 29 Feb 2012 07:23:53 +0000 (UTC) Message-ID: <4F4DD288.5060106@FreeBSD.org> Date: Tue, 28 Feb 2012 23:23:52 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: Florian Smeets References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> In-Reply-To: <4F4D5E5D.9040302@FreeBSD.org> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org, current@FreeBSD.org, Steve Wills , =?UTF-8?B?eiBXxIVzaWtvd3NraQ==?= , Arnaud Lacombe , Alexander Leidinger , "Bjoern A. Zeeb" , =?UTF-8?B?xYF1a2Fz?= Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 07:23:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/28/2012 15:08, Florian Smeets wrote: > I talked to Kip Macy, who implemented flowtable, about this. He > thinks that the problem was caused by inappropriate default setting > of net.inet.ip.output_flowtable_size. This should have been fixed > by r205488 which was MFC'd to 8 and should be part of 8.2 and of > course 9.0. However nobody who experienced the problem wanted to > try any of these releases with flowtable enabled, so we still don't > know if it's fixed or not. > > Should anyone try this it could certainly be the case that > net.inet.ip.output_flowtable_size needs to be tuned even more. I tried it, on both FreeBSD routers, web systems, and database servers; all on 8.2+. It still causes massive instability. Disabling the sysctl, and/or removing it from the kernel solved the problems. Doug - -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPTdKIAAoJEFzGhvEaGryEHksH/1Hg6TIXLuXf9fUrwsr2Wru3 0qY4MyB6Z0jgXZYqK3QtVd+zzo3LjCbhlN2qUJE/j5eLdROwev+vqdmmKgHRmU5+ lbqIw8t3W9ICobzTxlKmOjJlgBMgrPcX1Dbz0h1+kj26EIJEzThv/l4dxwElm1OT W6bNvYIsrs/fR7MoYnJAp+frTMiuAx3QACx8YeKDLevKtUK8VmQxRJzZ7f6dFSNm qtucCnfDyawIomnoRFbWLvA88RoK8gEZ3sYytXb97qB2D0oLkCu3aX6LkaDzFVR5 LrZwtY8gFzSueGEIaxdxZjgEcHMeyXeq3b6MXvxSBGd0QQ0F15ZpDxhBI4jjEI0= =He/W -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 07:40:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DDE71065677 for ; Wed, 29 Feb 2012 07:40:26 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 14DB28FC0C for ; Wed, 29 Feb 2012 07:40:25 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1S2e9B-0007Kz-FY for freebsd-stable@freebsd.org; Tue, 28 Feb 2012 23:40:25 -0800 Date: Tue, 28 Feb 2012 23:40:25 -0800 (PST) From: timp To: freebsd-stable@freebsd.org Message-ID: <1330501225474-5524279.post@n5.nabble.com> In-Reply-To: <20120222140308.Horde.RjSecpjmRSRPROeM24KCgsA@webmail.leidinger.net> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <1329890164178-5504219.post@n5.nabble.com> <20120222140308.Horde.RjSecpjmRSRPROeM24KCgsA@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 07:40:26 -0000 Excuse me, why don't you add geom_part_gpt_load="YES" and geom_label_load="YES" to your sample (i386|amd64)_SMALL_loader.conf? GENERIC has these options. And kernel can't mount filesystems from default partitioned disk without it. -- View this message in context: http://freebsd.1045724.n5.nabble.com/CFT-modular-kernel-config-tp5502195p5524279.html Sent from the freebsd-stable mailing list archive at Nabble.com. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 08:02:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D85B106564A; Wed, 29 Feb 2012 08:02:17 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 752848FC17; Wed, 29 Feb 2012 08:02:16 +0000 (UTC) Date: Wed, 29 Feb 2012 09:02:15 +0100 From: vermaden To: Ian Smith X-Mailer: interia.pl/pf09 In-Reply-To: <20120229163223.L80360@sola.nimnet.asn.au> References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> <20120228162636.Horde.JgORKJjmRSRPTPIsGKfo0uA@webmail.leidinger.net> <4F4D403E.2030703@FreeBSD.org> <4F4D510E.60206@FreeBSD.org> <20120229163223.L80360@sola.nimnet.asn.au> X-Originating-IP: 194.0.181.128 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1330502535; bh=DMjgg9eSpFR7sbLDF4nof+LwwaTEf7+ta3lICwMIdPY=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=TrASWBcJiQlIbx55ALrvhiVNUxdOFeLMgvNwUl5V59UOz6msHPfmqHg35tEVYLTSH 6qEe/wCQ/V64ChipK26BeQxpuDHZcvMkQtmjracQCATHzEOTyooc57TCxShEJt9lVz JAEv2s0GURUXIju38/hMJ3IzliDdJgUnNG/m2SSI= Cc: fidaj@ukr.net, freebsd-stable@FreeBSD.org, lars.engels@0x20.net, Andriy Gapon , Hans Petter Selasky , Alexander Leidinger Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 08:02:17 -0000 "Ian Smith" pisze: > On Tue, 28 Feb 2012, vermaden wrote: > > "Andriy Gapon" pisze: > > > on 29/02/2012 00:04 vermaden said the following: > > > > "Andriy Gapon" said: > > > >> on 28/02/2012 17:26 Alexander Leidinger said the following: > > > >>> The kernel does not poll for CD changes, and the people guarding= the relevant CD > > > >>> code where against something like this in the kernel everytime t= his came up in > > > >>> the past. So no devd event for this. > > > >> > > > >> My impression was that lately people were asking for it (and nobo= dy actually > > > >> "guarded" the code), but there is no good design on how to do it. > > > >=20 > > > > The mentioned earlier sysctl OID changes whenever CD is in the > > > > drive or not, something changes that ... so adding appreciate > > > > events like "MEDIA INSERTED" and "MEDIA REMOVED" to cd* class > > > > should be enought to handle them and mount/umount the > > > > medium with script like mine with appreciate devd(8) config. > > >=20 > > > I don't think that there is any kernel component that pro-actively c= hanges that > > > value. Most likely you have something like hald running or otherwis= e tried to > > > access the device before the change was noted. > >=20 > > I do not even have working CD drive in my laptop, so I cant tell ;) > >=20 > > Ivan Klymenko sent this earlier in that thread: > >=20 > > NO CD: > > > kern.geom.conftxt: 0 DISK cd0 0 2048 hd 0 sc 0 > >=20 > > CD IN: > > > kern.geom.conftxt: 0 DISK cd0 4700372992 2048 hd 0 sc 0 >=20 > That looks like a DVD, I only have a CDRW in this .. but inserting=20 > either a music or a data CD has no effect whatsoever on that sysctl=20 > here, on 8.2-RELEASE anyway, which still has /dev/acd0 as well. >=20 > Further, it's not so easy to parse: >=20 > t23# sysctl kern.geom.conftxt > t23# >=20 > ie nothing, but no 'unknown oid' either, huh? >=20 > t23# sysctl -d kern.geom.conftxt > kern.geom.conftxt: Dump the GEOM config in txt >=20 > Hmm, checking sysctl(8), only the -b switch seems to dump it: >=20 > t23# sysctl -b kern.geom.conftxt > 0 DISK cd0 534181888 2048 hd 0 sc 0 > 0 DISK ad0 120034123776 512 hd 16 sc 63 > 1 PART ad0s4 34143137280 512 i 4 o 85888373760 ty freebsd xs MBR xt 165 > [.. partitions on slices s4, s3, s2 and DOS slice s1 shown, omitted ..] >=20 > but: >=20 > t23# sysctl -b kern.geom.conftxt | grep cd0 > Binary file (standard input) matches >=20 > Note also that the above entry for cd0 does NOT change after inserting=20 > various different data CDs, all different sizes, nor after mounting one,=20 > so that 534181888 entry is from some time before, perhaps the first CD=20 > inserted after boot, not sure? Also the sizes are bytes, regardless of=20 > sector size (DVD above, while ad0s4 is a 32GiB slice on a 120GB disk). >=20 > Doesn't look like this one is going to fly. Ok, so at least we have a confirmation that its not currently possible, thank You for clarification. > (meanwhile other progress is looking good, maybe I'll get some time > next month to play with it, still behind due to aforesaid near-disaster := ) Sure, have fun! ;) Regards, vermaden ... From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 09:12:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 954EE1065674; Wed, 29 Feb 2012 09:12:07 +0000 (UTC) (envelope-from admin@govital.net) Received: from mail.govital.net (mail.govital.net [209.183.5.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3AA628FC0A; Wed, 29 Feb 2012 09:12:06 +0000 (UTC) Received: from govital.net (localhost [127.0.0.1]) by mail.govital.net (Postfix) with ESMTP id A51704BD55; Wed, 29 Feb 2012 03:54:02 -0500 (EST) From: "Chris Demers" To: Harry Newton ,Adrian Chadd Date: Wed, 29 Feb 2012 03:54:02 -0500 Message-Id: <20120229084249.M5878@govital.net> In-Reply-To: References: <1330459721.1023.15.camel@revolution.hippie.lan> X-Mailer: OpenWebMail 2.53 20080403 301 X-OriginatingIP: 216.8.180.103 (admin) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-govital-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: A51704BD55.A37BA X-govital-MailScanner: Found to be clean X-govital-MailScanner-From: admin@govital.net X-Spam-Status: No Cc: Ian Lepore , freebsd-stable@freebsd.org, jhb@freebsd.org Subject: Re: Regression between 9-RELEASE and 9-STABLE [PCIB ?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 09:12:07 -0000 Greetings Everyone, Along this same topic, I have also had a problem with 9-STABLE being unstable. I have been experiencing random kernel core dumps on a machine. I know the machine is fine, if i switch back to a set of disks running my previous 8-stable everything is fine. But with a current 9-STABLE as of last night even I get kernel panics. Can provide more details tomorrow, machine is currently panicked in the data center and need to go there in the morning to reboot. Hoping it gets fixed soon, want to start bringing the machine into production slowly, don't want to have to roll back to 9-release would rather see this fixed. But i believe it is a variation of the exact same problem that has been brought up here. Last panic it created a core file, hopefully it did again so i can debug it. On Tue, 28 Feb 2012 23:10:51 +0000, Harry Newton wrote > Adrian - thanks ! > > John, if you write me a shopping list of what information you think > useful, assuming you have time and inclination, I'll do my best > provide it. > > On 28 February 2012 23:04, Adrian Chadd wrote: > > A lot of the PCI bus enumeration and configuration code has changed. > > > > John's likely the best person to bring into this. He's been doing a > > lot of the PCI bus hacking and has found/fixed quite a few > > regressions. > > > > Good luck! > > > > > > > > Adrian > > > > > > On 28 February 2012 14:26, Harry Newton wrote: > >> Not really. Verbose suggests it completes the scan of the PCI to LPC > >> Bridge and PCI to PCI bridge. Comparing with a working verbose boot, > >> the next stage, which isn't reached, is HyperTransport Technology > >> Configuration. > >> > >> Trying BUS_DEBUG, I got a lot of this: > >> > >> device_add_child_ordered: 1813: (null) at pci with orer 0 as unit -1 > >> make_device: 1698: (null) at pci as unit -1 > >> > >> I neglected to say before: the machine's been running FreeBSD 7-STABLE > >> quite happily with no problems. > >> > >> - Harry > >> > >> > >> On 28 February 2012 20:08, Ian Lepore wrote: > >>> On Tue, 2012-02-28 at 19:15 +0000, Harry Newton wrote: > >>>> 9-RELEASE works fine. csup to 9-STABLE and make buildworld kernel etc > >>>> gives a system the hangs during the boot process. There are no error > >>>> messages during the part boot, and no panic. Last messages before hang > >>>> are: > >>>> > >>>> pcib0: port 0xcf8-0xcff on acpi0 > >>>> pci0: on pcib0 > >>>> > >>>> I am stumped about how to diagnose this, and would be _very_ grateful > >>>> for any suggestions. > >>>> > >>>> When it's hung I can't force a break to debugger (BREAK_TO_DEBUGGER) > >>>> in kern conf: I imagine I'm too early in the boot sequence. > >>>> > >>>> - Harry > >>>> > >>> > >>> I assume booting verbose doesn't provide any more clues?  I've sometimes > >>> gotten an extra clue from a hang during boot by building with option > >>> BUS_DEBUG.  Even if you don't suspect the newbus routines as directly > >>> being the problem, sometimes you get a bit more info about what was > >>> happening at the time of lockup. > >>> > >>> -- Ian > >>> > >>> > >> > >> > >> > >> -- > >> Harry Newton > >> _______________________________________________ > >> 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" > > -- > Harry Newton > _______________________________________________ > 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" > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. -- Chris Demers admin@govital.net www.govital.net -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 09:35:32 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6FED106566C for ; Wed, 29 Feb 2012 09:35:32 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm1.ukr.net (fsm1.ukr.net [195.214.192.120]) by mx1.freebsd.org (Postfix) with ESMTP id 8AD188FC13 for ; Wed, 29 Feb 2012 09:35:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=9rFJJG/ls55kNo5y8BRZcb39auTk3/j/zQbzmW1jG4Q=; b=ok7OdX8FAZ0GnXJ9wgaKRFopFjHjvW9QtF6Eoz94x6GFgNqEv+jHnmW+xJBA++qpERtBNW7ev9UD3pLegyF4dFlMzgQJ/Ld24FbgZBsalgc7L2HAdUhEhyfV5oNJbHDDagVagbEKOBY0oTsRstFScFOmDtO6OsNQP+2x6WIsscY=; Received: from [178.137.138.140] (helo=nonamehost.) by fsm1.ukr.net with esmtpsa ID 1S2fwB-000EmL-NM ; Wed, 29 Feb 2012 11:35:08 +0200 Date: Wed, 29 Feb 2012 11:35:05 +0200 From: Ivan Klymenko To: Ian Smith Message-ID: <20120229113505.2a5a3d47@nonamehost.> In-Reply-To: <20120229163223.L80360@sola.nimnet.asn.au> References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> <20120228162636.Horde.JgORKJjmRSRPTPIsGKfo0uA@webmail.leidinger.net> <4F4D403E.2030703@FreeBSD.org> <4F4D510E.60206@FreeBSD.org> <20120229163223.L80360@sola.nimnet.asn.au> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, lars.engels@0x20.net, Andriy Gapon , Hans Petter Selasky , Alexander Leidinger , vermaden Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 09:35:33 -0000 > > Note also that the above entry for cd0 does NOT change after > inserting various different data CDs, all different sizes, nor after > mounting one, so that 534181888 entry is from some time before, > perhaps the first CD inserted after boot, not sure? Also the sizes > are bytes, regardless of sector size (DVD above, while ad0s4 is a > 32GiB slice on a 120GB disk). > > Doesn't look like this one is going to fly. I talked about this, that current version be non-working. but if you make some changes in the cam/scsi|ata/atapi - it will work ... From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 11:51:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C0429106564A for ; Wed, 29 Feb 2012 11:51:35 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 35F408FC1B for ; Wed, 29 Feb 2012 11:51:35 +0000 (UTC) Received: by mail-lpp01m010-f54.google.com with SMTP id v3so490337lag.13 for ; Wed, 29 Feb 2012 03:51:34 -0800 (PST) Received-SPF: pass (google.com: domain of timp87@gmail.com designates 10.152.124.77 as permitted sender) client-ip=10.152.124.77; Authentication-Results: mr.google.com; spf=pass (google.com: domain of timp87@gmail.com designates 10.152.124.77 as permitted sender) smtp.mail=timp87@gmail.com; dkim=pass header.i=timp87@gmail.com Received: from mr.google.com ([10.152.124.77]) by 10.152.124.77 with SMTP id mg13mr33835lab.4.1330516294915 (num_hops = 1); Wed, 29 Feb 2012 03:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=21145NU5oJlV76aJTW4HRq2PLoLGrmbSM7cFwRe8oJU=; b=nThMqGohDa1EPndme0KuZI5tzi89RvdwR4DiUl7r4HAecINVX1LdH8uBhYjyLdMEBD BEDZYcMG3oS/f1uJ5XUlJ6Tbgnjr1HFOXmfaC6eJmwVpRsbdGdpaOVsONRmmeiRhzVcJ 2kxk5vHBbU0mpM+v7tCJLAWC3ACPwTl74ZyUI= MIME-Version: 1.0 Received: by 10.152.124.77 with SMTP id mg13mr16523447lab.4.1330514589087; Wed, 29 Feb 2012 03:23:09 -0800 (PST) Received: by 10.152.28.201 with HTTP; Wed, 29 Feb 2012 03:23:09 -0800 (PST) In-Reply-To: <20120229110106.Horde.57mdQpjmRSRPTfdiZgvhTsA@webmail.leidinger.net> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <1329890164178-5504219.post@n5.nabble.com> <20120222140308.Horde.RjSecpjmRSRPROeM24KCgsA@webmail.leidinger.net> <1330501225474-5524279.post@n5.nabble.com> <20120229110106.Horde.57mdQpjmRSRPTfdiZgvhTsA@webmail.leidinger.net> Date: Wed, 29 Feb 2012 15:23:09 +0400 Message-ID: From: Pavel Timofeev To: Alexander Leidinger Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 11:51:35 -0000 Please, remove geom_part_bsd_load=3D"YES" geom_part_ebr_load=3D"YES" geom_part_mbr_load=3D"YES" from loader.conf, it makes panic my machine. See /usr/src/sys/(amd64|i386)/conf/DEFAULTS it has already set as default options. 29 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2012=C2=A0=D0=B3. 14:01 =D0= =BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Alexa= nder Leidinger =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > Quoting timp (from Tue, 28 Feb 2012 23:40:25 -0800 > (PST)): > >> Excuse me, why don't you add geom_part_gpt_load=3D"YES" and >> geom_label_load=3D"YES" to your sample (i386|amd64)_SMALL_loader.conf? > > > I didn't had time to add them as I had to have a look at the collateral > damage of a DDoS. I added now some GEOM modules (not only the two above) = to > the loader.conf, and I also added the additional resource control/account= ing > options to the kernel. > > Bye, > Alexander. > > -- > We can defeat gravity. =C2=A0The problem is the paperwork involved. > > > http://www.Leidinger.net =C2=A0 =C2=A0Alexander @ Leidinger.net: PGP ID = =3D B0063FE7 > http://www.FreeBSD.org =C2=A0 =C2=A0 =C2=A0 netchild @ FreeBSD.org =C2=A0= : PGP ID =3D 72077137 > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 10:01:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC2F6106566B for ; Wed, 29 Feb 2012 10:01:41 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 908708FC12 for ; Wed, 29 Feb 2012 10:01:41 +0000 (UTC) Received: from outgoing.leidinger.net (p5796D1E1.dip.t-dialin.net [87.150.209.225]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 7D8B3844754; Wed, 29 Feb 2012 11:01:11 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id B2BFF129F; Wed, 29 Feb 2012 11:01:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1330509668; bh=+CCX6m5iJgKSPfVmGW0QO3IFZxhSIktxKXlfnat7OPU=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=l07erqlaYLs8xl6maBOceIipy57kF0ghbahMJ5ew5L5q7NySixhQzQAb5ORU+T7nc 9SPQUKeuxG8w/1X17Boa1asNjn1cGtLYMrE59vLFRRtWSkMgAdxfcoBBVO9O9xJD5B XUkQtpkIRw1da3QUwkDRRmQPFVY/fRBmvB0haPZwA2s/fY4h6DOTp/z8s/lhKtG0O0 QyRTXg/YAc424+alzIOE1DZ8uzHLOtUWjn43Bbxb/nHg+D8IwkCYJdpF+7rQb4eNrm EQvyCBX+EVBm4pheC7R2K5Jr7duHmA+xjEKX5QLBKF4Hshh7bw+YYTJhBFnBtOi/qt plSKkwJJM4nPA== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1TA16Cx087337; Wed, 29 Feb 2012 11:01:06 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 29 Feb 2012 11:01:06 +0100 Date: Wed, 29 Feb 2012 11:01:06 +0100 Message-ID: <20120229110106.Horde.57mdQpjmRSRPTfdiZgvhTsA@webmail.leidinger.net> From: Alexander Leidinger To: timp References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <1329890164178-5504219.post@n5.nabble.com> <20120222140308.Horde.RjSecpjmRSRPROeM24KCgsA@webmail.leidinger.net> <1330501225474-5524279.post@n5.nabble.com> In-Reply-To: <1330501225474-5524279.post@n5.nabble.com> User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 7D8B3844754.AFC27 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.039, required 6, autolearn=disabled, AWL -1.10, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, RCVD_IN_BL_SPAMCOP_NET 1.25, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1331114474.84311@rnmdlnBFe1435evyBn1Qmw X-EBL-Spam-Status: No X-Mailman-Approved-At: Wed, 29 Feb 2012 12:21:46 +0000 Cc: freebsd-stable@freebsd.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 10:01:42 -0000 Quoting timp (from Tue, 28 Feb 2012 23:40:25 -0800 (PST)): > Excuse me, why don't you add geom_part_gpt_load="YES" and > geom_label_load="YES" to your sample (i386|amd64)_SMALL_loader.conf? I didn't had time to add them as I had to have a look at the collateral damage of a DDoS. I added now some GEOM modules (not only the two above) to the loader.conf, and I also added the additional resource control/accounting options to the kernel. Bye, Alexander. -- We can defeat gravity. The problem is the paperwork involved. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 12:24:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 899551065678; Wed, 29 Feb 2012 12:24:19 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.207]) by mx1.freebsd.org (Postfix) with ESMTP id 339A88FC14; Wed, 29 Feb 2012 12:24:18 +0000 (UTC) Date: Wed, 29 Feb 2012 13:24:17 +0100 From: vermaden To: Ivan Klymenko X-Mailer: interia.pl/pf09 In-Reply-To: <20120229113505.2a5a3d47@nonamehost> References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> <20120228162636.Horde.JgORKJjmRSRPTPIsGKfo0uA@webmail.leidinger.net> <4F4D403E.2030703@FreeBSD.org> <4F4D510E.60206@FreeBSD.org> <20120229163223.L80360@sola.nimnet.asn.au> <20120229113505.2a5a3d47@nonamehost> X-Originating-IP: 194.0.181.128 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1330518257; bh=3cHiZC5N9caeIWLfqjqZO3nz56n9c+LWG3v4GYziP/8=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: X-Originating-IP:Message-Id:MIME-Version:Content-Type: Content-Transfer-Encoding; b=kruigtMUR3jo9nOKcQGDpWF56qh+1VHHmSKn5Vium2m7scMe9K7xrpazSvDOo5njH 1YGERsMy+9xO1//U2Mqu9uSVg0R8QTWDeKlMLkS/5WQ9oB58mWHNW+cwvKwEgsCZeJ 0DloOFgkk7ZS17cGmwziz27BQQX1R93goFeJyKy8= Cc: freebsd-stable@FreeBSD.org, Ian Smith , Andriy Gapon , Hans Petter Selasky , Alexander Leidinger , lars.engels@0x20.net Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 12:24:19 -0000 "Ivan Klymenko" pisze: > >=20 > > Note also that the above entry for cd0 does NOT change after > > inserting various different data CDs, all different sizes, nor after > > mounting one, so that 534181888 entry is from some time before, > > perhaps the first CD inserted after boot, not sure? Also the sizes > > are bytes, regardless of sector size (DVD above, while ad0s4 is a > > 32GiB slice on a 120GB disk). > >=20 > > Doesn't look like this one is going to fly. >=20 > I talked about this, that current version be non-working. but if you > make some changes in the cam/scsi|ata/atapi - it will work ... I would love to, but I have absolutely no idea how to do that ;) Regards, vermaden ... From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 12:32:58 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE5601065672; Wed, 29 Feb 2012 12:32:58 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm2.ukr.net (fsm2.ukr.net [195.214.192.121]) by mx1.freebsd.org (Postfix) with ESMTP id 520668FC13; Wed, 29 Feb 2012 12:32:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=POrMJhBTiXpBsqKgDwquX2j/dfT33Rm2Kpc2/65+DdE=; b=gdgeZtmUwIaWxQUgHlwVxG5CZB/rNxKWbqXS2S1bTPRqvX3cFh3OwuB6bswJ3oCbdjYTmP6njN3qfQeiYX+x/O53YMnX1pk5oVuNc+A5/T/fsM4F4Hk0K5BuWopvIM2OFyuPxt03ZULm2FvmZotQ2FCePcKlDlcaajY7r3hkyBk=; Received: from [178.137.138.140] (helo=nonamehost.) by fsm2.ukr.net with esmtpsa ID 1S2ihu-0004K1-7k ; Wed, 29 Feb 2012 14:32:34 +0200 Date: Wed, 29 Feb 2012 14:32:33 +0200 From: Ivan Klymenko To: vermaden Message-ID: <20120229143233.156b1959@nonamehost.> In-Reply-To: References: <4F3EE186.4020801@gmail.com> <201202181409.08859.hselasky@c2i.net> <20120226203949.H89643@sola.nimnet.asn.au> <20120228162636.Horde.JgORKJjmRSRPTPIsGKfo0uA@webmail.leidinger.net> <4F4D403E.2030703@FreeBSD.org> <4F4D510E.60206@FreeBSD.org> <20120229163223.L80360@sola.nimnet.asn.au> <20120229113505.2a5a3d47@nonamehost> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@FreeBSD.org, Ian Smith , Andriy Gapon , Hans Petter Selasky , Alexander Leidinger , lars.engels@0x20.net Subject: Re: devd based AUTOMOUNTER X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 12:32:58 -0000 =D0=92 Wed, 29 Feb 2012 13:24:17 +0100 vermaden =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > "Ivan Klymenko" pisze: > > >=20 > > > Note also that the above entry for cd0 does NOT change after > > > inserting various different data CDs, all different sizes, nor > > > after mounting one, so that 534181888 entry is from some time > > > before, perhaps the first CD inserted after boot, not sure? Also > > > the sizes are bytes, regardless of sector size (DVD above, while > > > ad0s4 is a 32GiB slice on a 120GB disk). > > >=20 > > > Doesn't look like this one is going to fly. > >=20 > > I talked about this, that current version be non-working. but if you > > make some changes in the cam/scsi|ata/atapi - it will work ... >=20 > I would love to, but I have absolutely no idea how to do that ;) >=20 I'm now trying to understand this ... From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 12:37:29 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 954481065672 for ; Wed, 29 Feb 2012 12:37:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DB7018FC08 for ; Wed, 29 Feb 2012 12:37:28 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA19653; Wed, 29 Feb 2012 14:37:26 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1S2imc-0008zO-Hm; Wed, 29 Feb 2012 14:37:26 +0200 Message-ID: <4F4E1C0D.9060101@FreeBSD.org> Date: Wed, 29 Feb 2012 14:37:33 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: Pavel Timofeev References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <1329890164178-5504219.post@n5.nabble.com> <20120222140308.Horde.RjSecpjmRSRPROeM24KCgsA@webmail.leidinger.net> <1330501225474-5524279.post@n5.nabble.com> <20120229110106.Horde.57mdQpjmRSRPTfdiZgvhTsA@webmail.leidinger.net> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 12:37:29 -0000 on 29/02/2012 13:23 Pavel Timofeev said the following: > Please, remove > geom_part_bsd_load="YES" > geom_part_ebr_load="YES" > geom_part_mbr_load="YES" > from loader.conf, it makes panic my machine. Please report the panic too. Preferably in a new thread. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 13:16:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 449CB106564A for ; Wed, 29 Feb 2012 13:16:47 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id C89908FC19 for ; Wed, 29 Feb 2012 13:16:46 +0000 (UTC) Received: from outgoing.leidinger.net (p5796D1E1.dip.t-dialin.net [87.150.209.225]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 15C8C844752; Wed, 29 Feb 2012 14:16:32 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 63EF012B3; Wed, 29 Feb 2012 14:16:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1330521389; bh=l2ZWmlOqF9GQ4x/niN02xJCwp677EUzD3ilUmq/qs+U=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version:Content-Transfer-Encoding; b=A1eqYl0e+G0wlPxPns7u8cOjg105IwOCPgcSEMTB6RheUHX/wbsraVJIbDXs1404+ fSJIYbQ5Q4KGV5Ue3gpQc8lgWK+4P18w8d6n63fcmXfqmP0YmgPuUAhDGGGN7UT2Pa MNrZ+7oCPI0yoIPZlfZSauNTiTUHwVGVGoqQTeicfA25JlXmdr/1B3w4lXAaO5qQ0r Jg5DaOB2K5OrxuWThmzwDidddIfDTgVDd84Hz2M1f3lBVtVomHupGyNpSFvVErQGGk t99tIaYZs5Y93VkTrHDdX3shCrYrpLDCiJqp/mWEof0vhNjrWaAMYGPOiEtau3kQ3C LOesO4BfWmL7Q== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q1TDGTab096802; Wed, 29 Feb 2012 14:16:29 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.21 ([85.94.224.21]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 29 Feb 2012 14:16:29 +0100 Date: Wed, 29 Feb 2012 14:16:28 +0100 Message-ID: <20120229141628.Horde.dEOYCZjmRSRPTiUs4NvBeec@webmail.leidinger.net> From: Alexander Leidinger To: Pavel Timofeev References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <1329890164178-5504219.post@n5.nabble.com> <20120222140308.Horde.RjSecpjmRSRPROeM24KCgsA@webmail.leidinger.net> <1330501225474-5524279.post@n5.nabble.com> <20120229110106.Horde.57mdQpjmRSRPTfdiZgvhTsA@webmail.leidinger.net> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 15C8C844752.A20D9 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.586, required 6, autolearn=disabled, AWL -0.48, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1331126193.04301@rAcbqnmAfqqj5I2+97HWkw X-EBL-Spam-Status: No Cc: freebsd-stable@freebsd.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 13:16:47 -0000 Quoting Pavel Timofeev (from Wed, 29 Feb 2012 15:23:09 +0400): > Please, remove > geom_part_bsd_load=3D"YES" > geom_part_ebr_load=3D"YES" > geom_part_mbr_load=3D"YES" > from loader.conf, it makes panic my machine. Ooops, fixed. Thanks for testing! Bye, Alexander. > See /usr/src/sys/(amd64|i386)/conf/DEFAULTS > it has already set as default options. > > > > 29 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2012=C2=A0=D0=B3. 14:01 =D0= =BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Alexa= nder Leidinger > =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: >> Quoting timp (from Tue, 28 Feb 2012 23:40:25 -0800 >> (PST)): >> >>> Excuse me, why don't you add geom_part_gpt_load=3D"YES" and >>> geom_label_load=3D"YES" to your sample (i386|amd64)_SMALL_loader.conf? >> >> >> I didn't had time to add them as I had to have a look at the collateral >> damage of a DDoS. I added now some GEOM modules (not only the two above)= to >> the loader.conf, and I also added the additional resource control/accoun= ting >> options to the kernel. >> >> Bye, >> Alexander. >> >> -- >> We can defeat gravity. =C2=A0The problem is the paperwork involved. >> >> >> http://www.Leidinger.net =C2=A0 =C2=A0Alexander @ Leidinger.net: PGP ID = =3D B0063FE7 >> http://www.FreeBSD.org =C2=A0 =C2=A0 =C2=A0 netchild @ FreeBSD.org =C2= =A0: PGP ID =3D 72077137 >> -- The first time is for love. The next time is 0. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 13:28:51 2012 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 099861065672; Wed, 29 Feb 2012 13:28:51 +0000 (UTC) (envelope-from slackbie@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9CB228FC14; Wed, 29 Feb 2012 13:28:50 +0000 (UTC) Received: by yenq7 with SMTP id q7so1525998yen.13 for ; Wed, 29 Feb 2012 05:28:50 -0800 (PST) Received-SPF: pass (google.com: domain of slackbie@gmail.com designates 10.50.37.236 as permitted sender) client-ip=10.50.37.236; Authentication-Results: mr.google.com; spf=pass (google.com: domain of slackbie@gmail.com designates 10.50.37.236 as permitted sender) smtp.mail=slackbie@gmail.com; dkim=pass header.i=slackbie@gmail.com Received: from mr.google.com ([10.50.37.236]) by 10.50.37.236 with SMTP id b12mr277765igk.36.1330522129997 (num_hops = 1); Wed, 29 Feb 2012 05:28:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=H0cd2kwjZXoEWXO+7XhwLyJ1O/BJviJR1QRGu475CT0=; b=H7hR2lOLItLdDBh6Iojc+Bzjns6n6iaBoQI2APUuJ1cAv+73jRxVSOZv04akMy5wpw zjz94q8hMozOfY9y4GQJhRjqqVG/iro3TRU+wPnLiB1nEPVN4X0vwGwBYfspVYTEMmL7 qjAKb1Yf2euN75O4fGPYDE+76EUd5K2Dyg37A= MIME-Version: 1.0 Received: by 10.50.37.236 with SMTP id b12mr232181igk.36.1330522129939; Wed, 29 Feb 2012 05:28:49 -0800 (PST) Received: by 10.42.1.68 with HTTP; Wed, 29 Feb 2012 05:28:49 -0800 (PST) In-Reply-To: <20120228163740.Horde.-AvCD5jmRSRPTPTEkzY476A@webmail.leidinger.net> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <20120228163740.Horde.-AvCD5jmRSRPTPTEkzY476A@webmail.leidinger.net> Date: Wed, 29 Feb 2012 20:28:49 +0700 Message-ID: From: "~Lst" To: Alexander Leidinger Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, current@freebsd.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 13:28:51 -0000 On Tue, Feb 28, 2012 at 10:37 PM, Alexander Leidinger wrote: > Quoting ~Lst (from Tue, 28 Feb 2012 16:38:43 +0700): > >> 2012/2/28 Steve Wills : >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 02/27/12 10:53, =A3ukasz W=B1sikowski wrote: >>>> >>>> W dniu 2012-02-22 23:31, Bjoern A. Zeeb pisze: >>>> >>>>> You cannot ship that on by default for non-tecnical reasons in a >>>>> kernel. =A0Please do not commit a kernel config that can be booted >>>>> (no LINT cannot be booted) with these on without consulting >>>>> appropriate hats upfront. >>>>> >>>>> >>>>>> - ALTQ - SW_WATCHDOG - QUOTA - IPSTEALTH (disabled in >>>>>> loader.conf) - IPFIREWALL_FORWARD (touches every packet, power >>>>>> users which need a bigger PPS but not this feature can >>>>>> recompile the kernel, discussed with julian@) - FLOWTABLE >>>>>> (disabled in loader.conf) >>>>> >>>>> Which is not the same as it's not 100% disabled and will still >>>>> allocate memory. >>>> >>>> >>>> FLOWTABLE on 8.x crashed BGP routers (kern/144917). I don't know if >>>> it is fixed by now, but this kind of potential problematic features >>>> should not be enabled by default. >>>> >>> >>> Agree, I've run into problems with FLOWTABLE (with just the features >>> that were enabled by default in 8.0) when routers changed MAC >>> addresses. As far as I understand it, FLOWTABLE is both broken and >>> abandoned (but if I'm wrong, please let me know). >>> >>> So, IMHO, not only should it not be enabled by default, but given that >>> it was disabled complete in 8.x after 8.0 (too lazy to look at exactly >>> when right now), I think it shouldn't even be included, since that >>> might encourage users to try it out only to encounter problems with it. >>> >>> Steve >>> >> >> Definitely yes, I'd some problems too with FLOWTABLE running for router. >> So I have to disabled in kernel and sysctl. > > > To make sure I understand you correctly: Did you disabled it with the > sysctl/loader-tunable and everything was OK again, or did you had to remo= ve > it from the kernel config (disabling via sysctl was not enough) to resolv= e > the issue? > > I have one report where a person has issue with FLOWTABLE, but disabling = it > via the sysctl/loader-tunable was enough to address his concerns. > > Bye, > Alexander. > I had to remove it from the kernel config and in my cased disabling via sysctl was not enough to resolve the issue Rgds, -- Lasta Yani From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 13:30:39 2012 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 5582C1065690; Wed, 29 Feb 2012 13:30:39 +0000 (UTC) (envelope-from slackbie@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 03E838FC26; Wed, 29 Feb 2012 13:30:38 +0000 (UTC) Received: by iahk25 with SMTP id k25so2293197iah.13 for ; Wed, 29 Feb 2012 05:30:38 -0800 (PST) Received-SPF: pass (google.com: domain of slackbie@gmail.com designates 10.50.191.233 as permitted sender) client-ip=10.50.191.233; Authentication-Results: mr.google.com; spf=pass (google.com: domain of slackbie@gmail.com designates 10.50.191.233 as permitted sender) smtp.mail=slackbie@gmail.com; dkim=pass header.i=slackbie@gmail.com Received: from mr.google.com ([10.50.191.233]) by 10.50.191.233 with SMTP id hb9mr258499igc.44.1330522238698 (num_hops = 1); Wed, 29 Feb 2012 05:30:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NReVZdc0Rlz4FBwIhU7QzhikANLmWbOuOwGSVyxxu4A=; b=N4ORW2RRM/H9lO1aPC7zITfALV7Ss8gqKsY/nObnPIBkVFw1YRFyBAp6IsvYdRRlj7 S5VZa88UklWiRxD3mUIzOLNQhS2w/VyTi2ure3SOy63S2q710fjHQ92TZWykX0DEEG44 o651DTZpD7iUvMp+kmOtBQyXGLeO6YXgsVNyU= MIME-Version: 1.0 Received: by 10.50.191.233 with SMTP id hb9mr217805igc.44.1330522238601; Wed, 29 Feb 2012 05:30:38 -0800 (PST) Received: by 10.42.1.68 with HTTP; Wed, 29 Feb 2012 05:30:38 -0800 (PST) In-Reply-To: <4F4D4D88.8040500@wasikowski.net> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4D3476.7070803@wasikowski.net> <4F4D4D88.8040500@wasikowski.net> Date: Wed, 29 Feb 2012 20:30:38 +0700 Message-ID: From: "~Lst" To: =?ISO-8859-2?Q?=A3ukasz_W=B1sikowski?= Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , stable@freebsd.org, current@freebsd.org, Arnaud Lacombe , Alexander Leidinger Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 13:30:39 -0000 2012/2/29 =A3ukasz W=B1sikowski : > W dniu 2012-02-28 22:22, Arnaud Lacombe pisze: > >>>>> FLOWTABLE on 8.x crashed BGP routers (kern/144917). >>>>> >>>> no crash dump, no backtrace, no follow-up whatsoever after 1 year and >>>> 2 years, what's your points ? You could really have chosen a better PR >>>> to back up your argument... >>> >>> Sorry, but I don't want to bug trace this issue, simply because lack of >>> time, resources and interest in this feature. I've run into this bug on >>> production box, went through hell because of it and turned off flowtabl= e >>> which I do not use and not need. If this problem is still alive (it >>> might be, the PR I've mentioned is still open) then it's not a good ide= a >>> to turn on this feature by default. If you're interested in using this >>> feature then feel free to debug and test. >>> >> Give me a deterministic way to reproduce the issue and I will. > > Enable FLOWTABLES in kernel and setup BGP4+ router (with net/quagga). > You need three peers sending you full Internet routing table (3x400k > prefixes). Some people got it with only two peers. After a short while > your CPU should stuck in 100% busy. > > -- > best regards, > Lukasz Wasikowski > In my cased, I used OpenBGPD. Rgds, -- Lasta Yani From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 14:20:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B140E106567D; Wed, 29 Feb 2012 14:20:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1431E8FC21; Wed, 29 Feb 2012 14:20:08 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id C018D46B2D; Wed, 29 Feb 2012 09:20:07 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 25B39B940; Wed, 29 Feb 2012 09:20:07 -0500 (EST) From: John Baldwin To: "Chris Demers" Date: Wed, 29 Feb 2012 09:06:08 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <20120229084249.M5878@govital.net> In-Reply-To: <20120229084249.M5878@govital.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202290906.08723.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 29 Feb 2012 09:20:07 -0500 (EST) Cc: Harry Newton , Adrian Chadd , freebsd-stable@freebsd.org, Ian Lepore Subject: Re: Regression between 9-RELEASE and 9-STABLE [PCIB ?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 14:20:10 -0000 On Wednesday, February 29, 2012 3:54:02 am Chris Demers wrote: > Greetings Everyone, > > Along this same topic, I have also had a problem with 9-STABLE being unstable. > I have been experiencing random kernel core dumps on a machine. I know the > machine is fine, if i switch back to a set of disks running my previous > 8-stable everything is fine. But with a current 9-STABLE as of last night > even I get kernel panics. Can provide more details tomorrow, machine is > currently panicked in the data center and need to go there in the morning to > reboot. Hoping it gets fixed soon, want to start bringing the machine into > production slowly, don't want to have to roll back to 9-release would rather > see this fixed. But i believe it is a variation of the exact same problem > that has been brought up here. Last panic it created a core file, hopefully > it did again so i can debug it. The problem discussed below can only result in boot-time hangs, not in crashes at runtime, so it is completely different. That said, if you are seeing crashes and have core dumps, we would certainly like to see some details such as a backtrace from the dump. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 14:20:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B210C106567F; Wed, 29 Feb 2012 14:20:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BA53C8FC0A; Wed, 29 Feb 2012 14:20:08 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 6FE2446B39; Wed, 29 Feb 2012 09:20:08 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D38F1B96E; Wed, 29 Feb 2012 09:20:07 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 29 Feb 2012 09:12:13 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202290912.14012.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 29 Feb 2012 09:20:07 -0500 (EST) Cc: Harry Newton , Adrian Chadd , Ian Lepore Subject: Re: Regression between 9-RELEASE and 9-STABLE [PCIB ?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 14:20:10 -0000 On Tuesday, February 28, 2012 6:10:51 pm Harry Newton wrote: > Adrian - thanks ! > > John, if you write me a shopping list of what information you think > useful, assuming you have time and inclination, I'll do my best > provide it. Mostly a verbose boot of 9.0-RELEASE and what you see now. If anything the only changes I can think of since the release are to make some of the PCI code more lenient. You could also try to narrow down exactly which revision causes the hang using a binary search of 9.0-STABLE since the release. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 17:59:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE531106564A; Wed, 29 Feb 2012 17:59:55 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 247128FC16; Wed, 29 Feb 2012 17:59:54 +0000 (UTC) Received: by werl4 with SMTP id l4so2809950wer.13 for ; Wed, 29 Feb 2012 09:59:54 -0800 (PST) Received-SPF: pass (google.com: domain of lacombar@gmail.com designates 10.180.86.230 as permitted sender) client-ip=10.180.86.230; Authentication-Results: mr.google.com; spf=pass (google.com: domain of lacombar@gmail.com designates 10.180.86.230 as permitted sender) smtp.mail=lacombar@gmail.com; dkim=pass header.i=lacombar@gmail.com Received: from mr.google.com ([10.180.86.230]) by 10.180.86.230 with SMTP id s6mr19691730wiz.16.1330538394227 (num_hops = 1); Wed, 29 Feb 2012 09:59:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cONjesBBvGwYwM3mww00kmgm71pZ78KXkL08Yh4wP+A=; b=q0WgTXn03W9qUwhws+vSxlDl/iHF/85zY5WAyZuvCDOYWtNIRJNWcC701dsKK7vZw8 n91ySkCoMBibo+M+isN1FFEr8XUs5n7nfVQP1Vk1Rrcf4oRqyYys2rjJVTM//Q7gy2ON KgGUj9epik1q6Qm3jQlPZxKe1rmh1DfqeIMYs= MIME-Version: 1.0 Received: by 10.180.86.230 with SMTP id s6mr15699078wiz.16.1330538394134; Wed, 29 Feb 2012 09:59:54 -0800 (PST) Received: by 10.216.166.11 with HTTP; Wed, 29 Feb 2012 09:59:54 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Feb 2012 12:59:54 -0500 Message-ID: From: Arnaud Lacombe To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable Subject: Re: Complete hang on 9.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 17:59:55 -0000 Hi, On Mon, Feb 27, 2012 at 12:48 PM, Arnaud Lacombe wrote= : > Hi, > > On Mon, Feb 27, 2012 at 10:36 AM, Attilio Rao wrote= : >> 2012/2/27, Arnaud Lacombe : >>> Hi, >>> >>> On Tue, Feb 14, 2012 at 11:41 AM, Arnaud Lacombe w= rote: >>>> Hi folks, >>>> >>>> For the records, I was running some tests yesterday on top of a >>>> 9.0-RELEASE, amd64, kernel when the box hanged. At the time of the >>>> hang, the box was running a process with about 2800 threads with heavy >>>> IPC between 1400 writers and 1400 readers. The box was in single user >>>> mode (/bin/sh coming from FreeBSD 7.4-STABLE). Here is the beginning >>>> of the dmesg: >>>> >>> This happened a second time, now with FreeBSD 8.2-RELEASE. Complete >>> machine hang. The machine was running about 4000 threads in a single >>> process, all the other condition are the same. >> >> Arnaud, >> can you please break in your kernel via KDB, collect the following >> informations from the DDB prompt: >> - ps >> - alltrace >> - show allpcpu >> - possibly get a coredump with 'call doadump' >> > Will do, but I'll need to rebuild a kernel to include DDB. > >> and in the end provide all those along with kernel binary and possibly >> sources somewhere? >> > I'll be testing a bare `release/8.2.0' with the following patch: > > diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC > index c3e0095..7bd997f 100644 > --- a/sys/amd64/conf/GENERIC > +++ b/sys/amd64/conf/GENERIC > @@ -79,6 +79,10 @@ options =A0 =A0 =A0INCLUDE_CONFIG_FILE =A0 =A0 # Inclu= de this > file in kernel > > =A0options =A0 =A0 =A0 =A0KDB =A0 =A0 =A0 =A0 =A0 # Kernel debugger relat= ed code > =A0options =A0 =A0 =A0 =A0KDB_TRACE =A0 =A0 # Print a stack trace for a p= anic > +options =A0 =A0 =A0 =A0DDB > +options =A0 =A0 =A0 =A0BREAK_TO_DEBUGGER > +options =A0 =A0 =A0 =A0ALT_BREAK_TO_DEBUGGER > > =A0# Make an SMP-capable kernel by default > =A0options =A0 =A0 =A0 =A0SMP =A0 =A0 =A0 =A0 =A0 # Symmetric MultiProces= sor Kernel > ok, it happened again after 2 days, the process was running about 3200 threads. I'm trying to break into DDB and let you know, I'm not that successful for now... - Arnaud > =A0- Arnaud > >> Thanks, >> Attilio >> >> >> -- >> Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 18:32:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8FB5106567A; Wed, 29 Feb 2012 18:32:57 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3D8728FC1A; Wed, 29 Feb 2012 18:32:56 +0000 (UTC) Received: by wibhn6 with SMTP id hn6so3272180wib.13 for ; Wed, 29 Feb 2012 10:32:56 -0800 (PST) Received-SPF: pass (google.com: domain of lacombar@gmail.com designates 10.180.14.73 as permitted sender) client-ip=10.180.14.73; Authentication-Results: mr.google.com; spf=pass (google.com: domain of lacombar@gmail.com designates 10.180.14.73 as permitted sender) smtp.mail=lacombar@gmail.com; dkim=pass header.i=lacombar@gmail.com Received: from mr.google.com ([10.180.14.73]) by 10.180.14.73 with SMTP id n9mr3277684wic.16.1330540376296 (num_hops = 1); Wed, 29 Feb 2012 10:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8xjfcVauObQeiwE5k9rt4J0cjSj5IfyZTRp2WXR/KFU=; b=hlk+6/y7JTj5ufAoVqARFH+WPXuXI5AaPCrsTVTXZM9PD7xTeNxk9r2+3ZoN7VtmKr qsMU1nf0M7vX9EMi7IN6FNFMd1222leKNlKxU3Eco4CfTcUM87Srf2o0SBXI+QluVRNa JJX/9YoMoVLfL4zT9d/s454HKdZvs57cA3XxM= MIME-Version: 1.0 Received: by 10.180.14.73 with SMTP id n9mr2629786wic.16.1330540376146; Wed, 29 Feb 2012 10:32:56 -0800 (PST) Received: by 10.216.166.11 with HTTP; Wed, 29 Feb 2012 10:32:56 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Feb 2012 13:32:56 -0500 Message-ID: From: Arnaud Lacombe To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable Subject: Re: Complete hang on 9.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 18:32:58 -0000 Hi, On Wed, Feb 29, 2012 at 12:59 PM, Arnaud Lacombe wrote= : > Hi, > > On Mon, Feb 27, 2012 at 12:48 PM, Arnaud Lacombe wro= te: >> Hi, >> >> On Mon, Feb 27, 2012 at 10:36 AM, Attilio Rao wrot= e: >>> 2012/2/27, Arnaud Lacombe : >>>> Hi, >>>> >>>> On Tue, Feb 14, 2012 at 11:41 AM, Arnaud Lacombe = wrote: >>>>> Hi folks, >>>>> >>>>> For the records, I was running some tests yesterday on top of a >>>>> 9.0-RELEASE, amd64, kernel when the box hanged. At the time of the >>>>> hang, the box was running a process with about 2800 threads with heav= y >>>>> IPC between 1400 writers and 1400 readers. The box was in single user >>>>> mode (/bin/sh coming from FreeBSD 7.4-STABLE). Here is the beginning >>>>> of the dmesg: >>>>> >>>> This happened a second time, now with FreeBSD 8.2-RELEASE. Complete >>>> machine hang. The machine was running about 4000 threads in a single >>>> process, all the other condition are the same. >>> >>> Arnaud, >>> can you please break in your kernel via KDB, collect the following >>> informations from the DDB prompt: >>> - ps >>> - alltrace >>> - show allpcpu >>> - possibly get a coredump with 'call doadump' >>> >> Will do, but I'll need to rebuild a kernel to include DDB. >> >>> and in the end provide all those along with kernel binary and possibly >>> sources somewhere? >>> >> I'll be testing a bare `release/8.2.0' with the following patch: >> >> diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC >> index c3e0095..7bd997f 100644 >> --- a/sys/amd64/conf/GENERIC >> +++ b/sys/amd64/conf/GENERIC >> @@ -79,6 +79,10 @@ options =A0 =A0 =A0INCLUDE_CONFIG_FILE =A0 =A0 # Incl= ude this >> file in kernel >> >> =A0options =A0 =A0 =A0 =A0KDB =A0 =A0 =A0 =A0 =A0 # Kernel debugger rela= ted code >> =A0options =A0 =A0 =A0 =A0KDB_TRACE =A0 =A0 # Print a stack trace for a = panic >> +options =A0 =A0 =A0 =A0DDB >> +options =A0 =A0 =A0 =A0BREAK_TO_DEBUGGER >> +options =A0 =A0 =A0 =A0ALT_BREAK_TO_DEBUGGER >> >> =A0# Make an SMP-capable kernel by default >> =A0options =A0 =A0 =A0 =A0SMP =A0 =A0 =A0 =A0 =A0 # Symmetric MultiProce= ssor Kernel >> > ok, it happened again after 2 days, the process was running about 3200 > threads. I'm trying to break into DDB and let you know, I'm not that > successful for now... > No luck. None of BREAK or ALT_BREAK are responding. I will not touch the system in the next few hours if you want me to test something on it. In the event of 8.2-RELEASE or 9.0-RELEASE are not meant to work reliably on top of a 7.4-RELEASE userland, I will re-setup the test to occurs on a clean 9.0-RELEASE system and re-try. - Arnaud From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 18:44:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3A76106566B for ; Wed, 29 Feb 2012 18:44:46 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 395AB8FC0C for ; Wed, 29 Feb 2012 18:44:45 +0000 (UTC) Received: by lagv3 with SMTP id v3so1082856lag.13 for ; Wed, 29 Feb 2012 10:44:45 -0800 (PST) Received-SPF: pass (google.com: domain of asmrookie@gmail.com designates 10.152.147.202 as permitted sender) client-ip=10.152.147.202; Authentication-Results: mr.google.com; spf=pass (google.com: domain of asmrookie@gmail.com designates 10.152.147.202 as permitted sender) smtp.mail=asmrookie@gmail.com; dkim=pass header.i=asmrookie@gmail.com Received: from mr.google.com ([10.152.147.202]) by 10.152.147.202 with SMTP id tm10mr1454928lab.49.1330541085014 (num_hops = 1); Wed, 29 Feb 2012 10:44:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0eabDbWdRlKImrZCEe6BtJFFmXaBO8+wKSWEYRyDmvc=; b=A7TTWkHHOxlgFhxlqj4VKEAAOr3UHD/nGQG4Qg9BlZCtXEw/fh5h7fFnBl7w3G+BEv c8yEWGzgByA8dgt6HKhGg5xs1pF7cDg7qKtqMd8mEwxn5d7kPtQ9cUi4H0iDDtNzES6/ RsZwgNCpC1Md3PnFdTYNmmppj7Zs9VPgv/FAs= MIME-Version: 1.0 Received: by 10.152.147.202 with SMTP id tm10mr1181407lab.49.1330541084874; Wed, 29 Feb 2012 10:44:44 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.41.5 with HTTP; Wed, 29 Feb 2012 10:44:44 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Feb 2012 18:44:44 +0000 X-Google-Sender-Auth: MI5vDSHXSxtimRwqxHzBqWMrCXM Message-ID: From: Attilio Rao To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable Subject: Re: Complete hang on 9.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 18:44:46 -0000 2012/2/29, Arnaud Lacombe : > Hi, > > On Wed, Feb 29, 2012 at 12:59 PM, Arnaud Lacombe wrote: >> Hi, >> >> On Mon, Feb 27, 2012 at 12:48 PM, Arnaud Lacombe >> wrote: >>> Hi, >>> >>> On Mon, Feb 27, 2012 at 10:36 AM, Attilio Rao >>> wrote: >>>> 2012/2/27, Arnaud Lacombe : >>>>> Hi, >>>>> >>>>> On Tue, Feb 14, 2012 at 11:41 AM, Arnaud Lacombe >>>>> wrote: >>>>>> Hi folks, >>>>>> >>>>>> For the records, I was running some tests yesterday on top of a >>>>>> 9.0-RELEASE, amd64, kernel when the box hanged. At the time of the >>>>>> hang, the box was running a process with about 2800 threads with heavy >>>>>> IPC between 1400 writers and 1400 readers. The box was in single user >>>>>> mode (/bin/sh coming from FreeBSD 7.4-STABLE). Here is the beginning >>>>>> of the dmesg: >>>>>> >>>>> This happened a second time, now with FreeBSD 8.2-RELEASE. Complete >>>>> machine hang. The machine was running about 4000 threads in a single >>>>> process, all the other condition are the same. >>>> >>>> Arnaud, >>>> can you please break in your kernel via KDB, collect the following >>>> informations from the DDB prompt: >>>> - ps >>>> - alltrace >>>> - show allpcpu >>>> - possibly get a coredump with 'call doadump' >>>> >>> Will do, but I'll need to rebuild a kernel to include DDB. >>> >>>> and in the end provide all those along with kernel binary and possibly >>>> sources somewhere? >>>> >>> I'll be testing a bare `release/8.2.0' with the following patch: >>> >>> diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC >>> index c3e0095..7bd997f 100644 >>> --- a/sys/amd64/conf/GENERIC >>> +++ b/sys/amd64/conf/GENERIC >>> @@ -79,6 +79,10 @@ options INCLUDE_CONFIG_FILE # Include this >>> file in kernel >>> >>> options KDB # Kernel debugger related code >>> options KDB_TRACE # Print a stack trace for a panic >>> +options DDB >>> +options BREAK_TO_DEBUGGER >>> +options ALT_BREAK_TO_DEBUGGER >>> >>> # Make an SMP-capable kernel by default >>> options SMP # Symmetric MultiProcessor Kernel >>> >> ok, it happened again after 2 days, the process was running about 3200 >> threads. I'm trying to break into DDB and let you know, I'm not that >> successful for now... >> > No luck. None of BREAK or ALT_BREAK are responding. I will not touch > the system in the next few hours if you want me to test something on > it. In the event of 8.2-RELEASE or 9.0-RELEASE are not meant to work > reliably on top of a 7.4-RELEASE userland, I will re-setup the test to > occurs on a clean 9.0-RELEASE system and re-try. We allow to break KBI when new releases happens, thus this may cause a breakage for you, even if a deadlock is really not something you want. Can you try enabling SW_WATCHDOG, DEADLKRES and possibly arm your ichwd? if the breakage involves clocks or interrupt sources there are still chances they will be able to catch it though. However, it doesn't seem you are setup with a proper serial console? If this is the case, you need to go with a textdump in order to collect DDB output. Or if you have it you might try with sending a serial break and kernel should break in DDB. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 18:46:37 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E3337106566C; Wed, 29 Feb 2012 18:46:37 +0000 (UTC) (envelope-from kmacybsd@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 57DB78FC17; Wed, 29 Feb 2012 18:46:37 +0000 (UTC) Received: by ggnk4 with SMTP id k4so2571300ggn.13 for ; Wed, 29 Feb 2012 10:46:36 -0800 (PST) Received-SPF: pass (google.com: domain of kmacybsd@gmail.com designates 10.50.216.201 as permitted sender) client-ip=10.50.216.201; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kmacybsd@gmail.com designates 10.50.216.201 as permitted sender) smtp.mail=kmacybsd@gmail.com; dkim=pass header.i=kmacybsd@gmail.com Received: from mr.google.com ([10.50.216.201]) by 10.50.216.201 with SMTP id os9mr1788630igc.22.1330541196571 (num_hops = 1); Wed, 29 Feb 2012 10:46:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=X4fryGwHzWdcYJ+hZ29aGGUr81Z57DjRqNqIApQtJjw=; b=vtHYE0Gcj9MgZlY3nf6WYaPDM23VX3gQuxmjJiKb1maNQ/07ouKZFAJiUCRqG6XikK kLQ1GEJSKIYzwWTBt8LrpSpEIaE3IegorwolyWW/1mJ2udvqI6QcpE8flLrWvOzcBCa4 eV12hU6EsJlpVYdQG+C7xKqHFDm4ska5kov+8= MIME-Version: 1.0 Received: by 10.50.216.201 with SMTP id os9mr1364608igc.22.1330539436909; Wed, 29 Feb 2012 10:17:16 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.50.134.106 with HTTP; Wed, 29 Feb 2012 10:17:16 -0800 (PST) In-Reply-To: <4F4DD288.5060106@FreeBSD.org> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> Date: Wed, 29 Feb 2012 19:17:16 +0100 X-Google-Sender-Auth: IfrJnwTH-_7gjmGO9UfRi8xXhv0 Message-ID: From: "K. Macy" To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, Florian Smeets , current@freebsd.org, Steve Wills , =?ISO-8859-2?Q?z_W=B1sikowski?= , Arnaud Lacombe , "Bjoern A. Zeeb" , Alexander Leidinger Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 18:46:38 -0000 . > > I tried it, on both FreeBSD routers, web systems, and database > servers; all on 8.2+. It still causes massive instability. Disabling > the sysctl, and/or removing it from the kernel solved the problems. Routing I can believe, but I'm wondering how close attention you paid to the workload. There are CDN networks with high uptimes and shipping firewall products that use flowtable, so your mention of web systems forces makes me ask for specifics. Thanks From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 19:20:39 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DA02106566C; Wed, 29 Feb 2012 19:20:39 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id D7C228FC1F; Wed, 29 Feb 2012 19:20:38 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so3220683wgb.31 for ; Wed, 29 Feb 2012 11:20:37 -0800 (PST) Received-SPF: pass (google.com: domain of lacombar@gmail.com designates 10.216.132.32 as permitted sender) client-ip=10.216.132.32; Authentication-Results: mr.google.com; spf=pass (google.com: domain of lacombar@gmail.com designates 10.216.132.32 as permitted sender) smtp.mail=lacombar@gmail.com; dkim=pass header.i=lacombar@gmail.com Received: from mr.google.com ([10.216.132.32]) by 10.216.132.32 with SMTP id n32mr919700wei.12.1330543237823 (num_hops = 1); Wed, 29 Feb 2012 11:20:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SkfpNZF9BiZaaawHdH4nKYyGzZuAbxadffMJVUgHRu4=; b=KmyCzXyYvv6iMHYC8w03Atqdw4J3p/55KJnWmWq0PtvKAXIu9od7XWop8YCWmAkA+1 jbPlfFmjHm3Z9JYghkzAKjGpULfWz6DnIvk4HymIaimSidBhBqw4ej+53dIk48RXCF0k hA/tQa+9pgkA8Er5KAA+FigW1OmUyE6D0dP70= MIME-Version: 1.0 Received: by 10.216.132.32 with SMTP id n32mr740877wei.12.1330543237694; Wed, 29 Feb 2012 11:20:37 -0800 (PST) Received: by 10.216.166.11 with HTTP; Wed, 29 Feb 2012 11:20:37 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Feb 2012 14:20:37 -0500 Message-ID: From: Arnaud Lacombe To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable Subject: Re: Complete hang on 9.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 19:20:39 -0000 Hi, On Wed, Feb 29, 2012 at 1:44 PM, Attilio Rao wrote: > 2012/2/29, Arnaud Lacombe : >> Hi, >> >> On Wed, Feb 29, 2012 at 12:59 PM, Arnaud Lacombe wr= ote: >>> Hi, >>> >>> On Mon, Feb 27, 2012 at 12:48 PM, Arnaud Lacombe >>> wrote: >>>> Hi, >>>> >>>> On Mon, Feb 27, 2012 at 10:36 AM, Attilio Rao >>>> wrote: >>>>> 2012/2/27, Arnaud Lacombe : >>>>>> Hi, >>>>>> >>>>>> On Tue, Feb 14, 2012 at 11:41 AM, Arnaud Lacombe >>>>>> wrote: >>>>>>> Hi folks, >>>>>>> >>>>>>> For the records, I was running some tests yesterday on top of a >>>>>>> 9.0-RELEASE, amd64, kernel when the box hanged. At the time of the >>>>>>> hang, the box was running a process with about 2800 threads with he= avy >>>>>>> IPC between 1400 writers and 1400 readers. The box was in single us= er >>>>>>> mode (/bin/sh coming from FreeBSD 7.4-STABLE). Here is the beginnin= g >>>>>>> of the dmesg: >>>>>>> >>>>>> This happened a second time, now with FreeBSD 8.2-RELEASE. Complete >>>>>> machine hang. The machine was running about 4000 threads in a single >>>>>> process, all the other condition are the same. >>>>> >>>>> Arnaud, >>>>> can you please break in your kernel via KDB, collect the following >>>>> informations from the DDB prompt: >>>>> - ps >>>>> - alltrace >>>>> - show allpcpu >>>>> - possibly get a coredump with 'call doadump' >>>>> >>>> Will do, but I'll need to rebuild a kernel to include DDB. >>>> >>>>> and in the end provide all those along with kernel binary and possibl= y >>>>> sources somewhere? >>>>> >>>> I'll be testing a bare `release/8.2.0' with the following patch: >>>> >>>> diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC >>>> index c3e0095..7bd997f 100644 >>>> --- a/sys/amd64/conf/GENERIC >>>> +++ b/sys/amd64/conf/GENERIC >>>> @@ -79,6 +79,10 @@ options =A0 =A0 =A0INCLUDE_CONFIG_FILE =A0 =A0 # In= clude this >>>> file in kernel >>>> >>>> =A0options =A0 =A0 =A0 =A0KDB =A0 =A0 =A0 =A0 =A0 # Kernel debugger re= lated code >>>> =A0options =A0 =A0 =A0 =A0KDB_TRACE =A0 =A0 # Print a stack trace for = a panic >>>> +options =A0 =A0 =A0 =A0DDB >>>> +options =A0 =A0 =A0 =A0BREAK_TO_DEBUGGER >>>> +options =A0 =A0 =A0 =A0ALT_BREAK_TO_DEBUGGER >>>> >>>> =A0# Make an SMP-capable kernel by default >>>> =A0options =A0 =A0 =A0 =A0SMP =A0 =A0 =A0 =A0 =A0 # Symmetric MultiPro= cessor Kernel >>>> >>> ok, it happened again after 2 days, the process was running about 3200 >>> threads. I'm trying to break into DDB and let you know, I'm not that >>> successful for now... >>> >> No luck. None of BREAK or ALT_BREAK are responding. I will not touch >> the system in the next few hours if you want me to test something on >> it. In the event of 8.2-RELEASE or 9.0-RELEASE are =A0not meant to work >> reliably on top of a 7.4-RELEASE userland, I will re-setup the test to >> occurs on a clean 9.0-RELEASE system and re-try. > > We allow to break KBI when new releases happens, thus this may cause a > breakage for you, even if a deadlock is really not something you want. > > Can you try enabling SW_WATCHDOG, DEADLKRES and possibly arm your ichwd? > if the breakage involves clocks or interrupt sources there are still > chances they will be able to catch it though. > > However, it doesn't seem you are setup with a proper serial console? The serial console is working definitively fine. I can break into DDB at will when the test is running. I did not test with ALT_BREAK per-se, but BREAK does work. - Arnaud > If this is the case, you need to go with a textdump in order to > collect DDB output. > Or if you have it you might try with sending a serial break and kernel > should break in DDB. > > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 19:22:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B53ED10656D7 for ; Wed, 29 Feb 2012 19:22:41 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3ED2F8FC12 for ; Wed, 29 Feb 2012 19:22:40 +0000 (UTC) Received: by eekd17 with SMTP id d17so2494894eek.13 for ; Wed, 29 Feb 2012 11:22:40 -0800 (PST) Received-SPF: pass (google.com: domain of asmrookie@gmail.com designates 10.112.27.199 as permitted sender) client-ip=10.112.27.199; Authentication-Results: mr.google.com; spf=pass (google.com: domain of asmrookie@gmail.com designates 10.112.27.199 as permitted sender) smtp.mail=asmrookie@gmail.com; dkim=pass header.i=asmrookie@gmail.com Received: from mr.google.com ([10.112.27.199]) by 10.112.27.199 with SMTP id v7mr794248lbg.36.1330543360176 (num_hops = 1); Wed, 29 Feb 2012 11:22:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kQrFIrj9louqc/wEfbdNbDMbjXQx8NV7eQ+Y/K0i0Zs=; b=EWe+0aQbBs502yfOE5u9SzAb+uOvAzJCk6RC6WZIU4DLnKOawy1itAL9BzR+uy2H+v l87TAyUQtyzfzAzsQtYF9qDHOKmoyVxIZ5EMvCSY7BDU47ac5NbP4BsuaI3E9rKlf2tQ YhWzG54W8oanBc3tAcDrPYxQiyE2F7PWW1MiA= MIME-Version: 1.0 Received: by 10.112.27.199 with SMTP id v7mr649443lbg.36.1330543360061; Wed, 29 Feb 2012 11:22:40 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.41.5 with HTTP; Wed, 29 Feb 2012 11:22:40 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Feb 2012 19:22:40 +0000 X-Google-Sender-Auth: xvyIBXxBvgl-xvspiNN8Eh8xInU Message-ID: From: Attilio Rao To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable Subject: Re: Complete hang on 9.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 19:22:41 -0000 2012/2/29, Arnaud Lacombe : > Hi, > > On Wed, Feb 29, 2012 at 1:44 PM, Attilio Rao wrote: >> 2012/2/29, Arnaud Lacombe : >>> Hi, >>> >>> On Wed, Feb 29, 2012 at 12:59 PM, Arnaud Lacombe >>> wrote: >>>> Hi, >>>> >>>> On Mon, Feb 27, 2012 at 12:48 PM, Arnaud Lacombe >>>> wrote: >>>>> Hi, >>>>> >>>>> On Mon, Feb 27, 2012 at 10:36 AM, Attilio Rao >>>>> wrote: >>>>>> 2012/2/27, Arnaud Lacombe : >>>>>>> Hi, >>>>>>> >>>>>>> On Tue, Feb 14, 2012 at 11:41 AM, Arnaud Lacombe >>>>>>> wrote: >>>>>>>> Hi folks, >>>>>>>> >>>>>>>> For the records, I was running some tests yesterday on top of a >>>>>>>> 9.0-RELEASE, amd64, kernel when the box hanged. At the time of the >>>>>>>> hang, the box was running a process with about 2800 threads with >>>>>>>> heavy >>>>>>>> IPC between 1400 writers and 1400 readers. The box was in single >>>>>>>> user >>>>>>>> mode (/bin/sh coming from FreeBSD 7.4-STABLE). Here is the beginning >>>>>>>> of the dmesg: >>>>>>>> >>>>>>> This happened a second time, now with FreeBSD 8.2-RELEASE. Complete >>>>>>> machine hang. The machine was running about 4000 threads in a single >>>>>>> process, all the other condition are the same. >>>>>> >>>>>> Arnaud, >>>>>> can you please break in your kernel via KDB, collect the following >>>>>> informations from the DDB prompt: >>>>>> - ps >>>>>> - alltrace >>>>>> - show allpcpu >>>>>> - possibly get a coredump with 'call doadump' >>>>>> >>>>> Will do, but I'll need to rebuild a kernel to include DDB. >>>>> >>>>>> and in the end provide all those along with kernel binary and possibly >>>>>> sources somewhere? >>>>>> >>>>> I'll be testing a bare `release/8.2.0' with the following patch: >>>>> >>>>> diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC >>>>> index c3e0095..7bd997f 100644 >>>>> --- a/sys/amd64/conf/GENERIC >>>>> +++ b/sys/amd64/conf/GENERIC >>>>> @@ -79,6 +79,10 @@ options INCLUDE_CONFIG_FILE # Include this >>>>> file in kernel >>>>> >>>>> options KDB # Kernel debugger related code >>>>> options KDB_TRACE # Print a stack trace for a panic >>>>> +options DDB >>>>> +options BREAK_TO_DEBUGGER >>>>> +options ALT_BREAK_TO_DEBUGGER >>>>> >>>>> # Make an SMP-capable kernel by default >>>>> options SMP # Symmetric MultiProcessor Kernel >>>>> >>>> ok, it happened again after 2 days, the process was running about 3200 >>>> threads. I'm trying to break into DDB and let you know, I'm not that >>>> successful for now... >>>> >>> No luck. None of BREAK or ALT_BREAK are responding. I will not touch >>> the system in the next few hours if you want me to test something on >>> it. In the event of 8.2-RELEASE or 9.0-RELEASE are not meant to work >>> reliably on top of a 7.4-RELEASE userland, I will re-setup the test to >>> occurs on a clean 9.0-RELEASE system and re-try. >> >> We allow to break KBI when new releases happens, thus this may cause a >> breakage for you, even if a deadlock is really not something you want. >> >> Can you try enabling SW_WATCHDOG, DEADLKRES and possibly arm your ichwd? >> if the breakage involves clocks or interrupt sources there are still >> chances they will be able to catch it though. >> >> However, it doesn't seem you are setup with a proper serial console? > The serial console is working definitively fine. I can break into DDB > at will when the test is running. I did not test with ALT_BREAK > per-se, but BREAK does work. So if you try to break in DDB via serial break it doesn't work? That is definitively very bad... Can you try with the options I mentioned earlier and see if something changes? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 19:31:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 402B41065672; Wed, 29 Feb 2012 19:31:41 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 880508FC17; Wed, 29 Feb 2012 19:31:40 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so3229627wgb.31 for ; Wed, 29 Feb 2012 11:31:39 -0800 (PST) Received-SPF: pass (google.com: domain of lacombar@gmail.com designates 10.180.14.73 as permitted sender) client-ip=10.180.14.73; Authentication-Results: mr.google.com; spf=pass (google.com: domain of lacombar@gmail.com designates 10.180.14.73 as permitted sender) smtp.mail=lacombar@gmail.com; dkim=pass header.i=lacombar@gmail.com Received: from mr.google.com ([10.180.14.73]) by 10.180.14.73 with SMTP id n9mr3679732wic.16.1330543899515 (num_hops = 1); Wed, 29 Feb 2012 11:31:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=s0BlvUbLokN0CGEXvmPR/bn7mZyqv7ulaiGPHp2gM3Y=; b=oG9SDtyzeOVoR2Yc/9t+n1zmV8pKyv1IQRcF+mVLhcuuCHmIkRFHVbf8lDvedKj0Vy /vpfz98mWWJtDiJpvBm7W4W5/VTnScWEe11J6rVSrG52tCP6LXJkSZuPhifJBvKT34O9 q1vMFTnw/SNCRGVu8jsy/PQ36AMFGVjCAjOO4= MIME-Version: 1.0 Received: by 10.180.14.73 with SMTP id n9mr2951198wic.16.1330543899467; Wed, 29 Feb 2012 11:31:39 -0800 (PST) Received: by 10.216.166.11 with HTTP; Wed, 29 Feb 2012 11:31:39 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Feb 2012 14:31:39 -0500 Message-ID: From: Arnaud Lacombe To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable Subject: Re: Complete hang on 9.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 19:31:41 -0000 Hi, On Wed, Feb 29, 2012 at 2:22 PM, Attilio Rao wrote: > 2012/2/29, Arnaud Lacombe : >> Hi, >> >> On Wed, Feb 29, 2012 at 1:44 PM, Attilio Rao wrote= : >>> 2012/2/29, Arnaud Lacombe : >>>> Hi, >>>> >>>> On Wed, Feb 29, 2012 at 12:59 PM, Arnaud Lacombe >>>> wrote: >>>>> Hi, >>>>> >>>>> On Mon, Feb 27, 2012 at 12:48 PM, Arnaud Lacombe >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> On Mon, Feb 27, 2012 at 10:36 AM, Attilio Rao >>>>>> wrote: >>>>>>> 2012/2/27, Arnaud Lacombe : >>>>>>>> Hi, >>>>>>>> >>>>>>>> On Tue, Feb 14, 2012 at 11:41 AM, Arnaud Lacombe >>>>>>>> wrote: >>>>>>>>> Hi folks, >>>>>>>>> >>>>>>>>> For the records, I was running some tests yesterday on top of a >>>>>>>>> 9.0-RELEASE, amd64, kernel when the box hanged. At the time of th= e >>>>>>>>> hang, the box was running a process with about 2800 threads with >>>>>>>>> heavy >>>>>>>>> IPC between 1400 writers and 1400 readers. The box was in single >>>>>>>>> user >>>>>>>>> mode (/bin/sh coming from FreeBSD 7.4-STABLE). Here is the beginn= ing >>>>>>>>> of the dmesg: >>>>>>>>> >>>>>>>> This happened a second time, now with FreeBSD 8.2-RELEASE. Complet= e >>>>>>>> machine hang. The machine was running about 4000 threads in a sing= le >>>>>>>> process, all the other condition are the same. >>>>>>> >>>>>>> Arnaud, >>>>>>> can you please break in your kernel via KDB, collect the following >>>>>>> informations from the DDB prompt: >>>>>>> - ps >>>>>>> - alltrace >>>>>>> - show allpcpu >>>>>>> - possibly get a coredump with 'call doadump' >>>>>>> >>>>>> Will do, but I'll need to rebuild a kernel to include DDB. >>>>>> >>>>>>> and in the end provide all those along with kernel binary and possi= bly >>>>>>> sources somewhere? >>>>>>> >>>>>> I'll be testing a bare `release/8.2.0' with the following patch: >>>>>> >>>>>> diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC >>>>>> index c3e0095..7bd997f 100644 >>>>>> --- a/sys/amd64/conf/GENERIC >>>>>> +++ b/sys/amd64/conf/GENERIC >>>>>> @@ -79,6 +79,10 @@ options =A0 =A0 =A0INCLUDE_CONFIG_FILE =A0 =A0 # = Include this >>>>>> file in kernel >>>>>> >>>>>> =A0options =A0 =A0 =A0 =A0KDB =A0 =A0 =A0 =A0 =A0 # Kernel debugger = related code >>>>>> =A0options =A0 =A0 =A0 =A0KDB_TRACE =A0 =A0 # Print a stack trace fo= r a panic >>>>>> +options =A0 =A0 =A0 =A0DDB >>>>>> +options =A0 =A0 =A0 =A0BREAK_TO_DEBUGGER >>>>>> +options =A0 =A0 =A0 =A0ALT_BREAK_TO_DEBUGGER >>>>>> >>>>>> =A0# Make an SMP-capable kernel by default >>>>>> =A0options =A0 =A0 =A0 =A0SMP =A0 =A0 =A0 =A0 =A0 # Symmetric MultiP= rocessor Kernel >>>>>> >>>>> ok, it happened again after 2 days, the process was running about 320= 0 >>>>> threads. I'm trying to break into DDB and let you know, I'm not that >>>>> successful for now... >>>>> >>>> No luck. None of BREAK or ALT_BREAK are responding. I will not touch >>>> the system in the next few hours if you want me to test something on >>>> it. In the event of 8.2-RELEASE or 9.0-RELEASE are =A0not meant to wor= k >>>> reliably on top of a 7.4-RELEASE userland, I will re-setup the test to >>>> occurs on a clean 9.0-RELEASE system and re-try. >>> >>> We allow to break KBI when new releases happens, thus this may cause a >>> breakage for you, even if a deadlock is really not something you want. >>> >>> Can you try enabling SW_WATCHDOG, DEADLKRES and possibly arm your ichwd= ? >>> if the breakage involves clocks or interrupt sources there are still >>> chances they will be able to catch it though. >>> >>> However, it doesn't seem you are setup with a proper serial console? >> The serial console is working definitively fine. I can break into DDB >> at will when the test is running. I did not test with ALT_BREAK >> per-se, but BREAK does work. > > So if you try to break in DDB via serial break it doesn't work? > That is definitively very bad... > just to be sure, I rebooted the system and I could break into DDB at the first attempt with ALT_BREAK, BREAK was a bit more reluctant but worked too. So yes, this does not taste good :/ > Can you try with the options I mentioned earlier and see if something cha= nges? > will do, but I will first attempt to reproduce this on 9.0-RELEASE. - Arnaud > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 20:41:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 237A1106566B for ; Wed, 29 Feb 2012 20:41:33 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id B17CF8FC17 for ; Wed, 29 Feb 2012 20:41:32 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q1TKfU1m061524; Wed, 29 Feb 2012 21:41:31 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q1TKfUK9061523; Wed, 29 Feb 2012 21:41:30 +0100 (CET) (envelope-from marius) Date: Wed, 29 Feb 2012 21:41:30 +0100 From: Marius Strobl To: "Garrett R. Groesbeck" Message-ID: <20120229204130.GA61509@alchemy.franken.de> References: <000001ccf4d6$66513b00$32f3b100$@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001ccf4d6$66513b00$32f3b100$@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.0-RELEASE - Trouble Booting on SPARC64 - kmem_suballoc error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 20:41:33 -0000 On Sun, Feb 26, 2012 at 05:31:35PM -0500, Garrett R. Groesbeck wrote: > Hello, > > I hope you are well. I've been working on a Sun Blade 2000 with FreeBSD 9.0 > (sparc64) installed. > > There's trouble with /boot/loader.conf when you try to boot the install disc > (and even after the install when I try to boot up): > > panic: kmem_suballoc: bad status return of 3 > > So when it gives me the chance to enter a boot command, I enter the > following: > > OK set hw.physmem=1048576000 > That apparently is a bug in the MI part of the VM triggered by the highly fragment physical memory of b1k and b2k with 2 GB of RAM. You can work around it by setting the vm.kmem_size_scale tunable to 2 without sacrificing physical memory. The latter meanwhile is also the default set by the MD part, awaiting further clues from alc@. Marius From owner-freebsd-stable@FreeBSD.ORG Wed Feb 29 20:48:47 2012 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 C4664106566C for ; Wed, 29 Feb 2012 20:48:47 +0000 (UTC) (envelope-from markiyan.kushnir@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4A9528FC1C for ; Wed, 29 Feb 2012 20:48:45 +0000 (UTC) Received: by eekd17 with SMTP id d17so2524497eek.13 for ; Wed, 29 Feb 2012 12:48:44 -0800 (PST) Received-SPF: pass (google.com: domain of markiyan.kushnir@gmail.com designates 10.213.114.9 as permitted sender) client-ip=10.213.114.9; Authentication-Results: mr.google.com; spf=pass (google.com: domain of markiyan.kushnir@gmail.com designates 10.213.114.9 as permitted sender) smtp.mail=markiyan.kushnir@gmail.com; dkim=pass header.i=markiyan.kushnir@gmail.com Received: from mr.google.com ([10.213.114.9]) by 10.213.114.9 with SMTP id c9mr1144006ebq.56.1330548524423 (num_hops = 1); Wed, 29 Feb 2012 12:48:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TXMzFABZreTtJwO4y3hAFIPd47+7t1D8phyfLmuO4BA=; b=eTfMYZ2Aqxt1JSvYjY8PcSwzl6JQDLkfNa07z8JV9qN9jC3Sm9XAlkoDcjutxfTRtY i45VKFHN3JW0UF8XSHfwExtJwp/5gjO7Sn7m2Qu5/LtC41gYC4t016GvOWnDDh+eMYy/ XD+s/6pD+u4H93LRvVsa4rf0JocQ5E1KOAFSQ= Received: by 10.213.114.9 with SMTP id c9mr913982ebq.56.1330548524262; Wed, 29 Feb 2012 12:48:44 -0800 (PST) Received: from mkushnir.zapto.org (128-49-124-91.pool.ukrtel.net. [91.124.49.128]) by mx.google.com with ESMTPS id o49sm86840648eeb.7.2012.02.29.12.48.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 12:48:43 -0800 (PST) Message-ID: <4F4E8F28.4070401@gmail.com> Date: Wed, 29 Feb 2012 22:48:40 +0200 From: Markiyan Kushnir User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120222 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sergey Kandaurov References: <4F3B745A.4010509@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: RELENG_8 panic caused by urtw? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Feb 2012 20:48:47 -0000 A related thread (for the record): http://lists.freebsd.org/pipermail/freebsd-virtualization/2011-February/000648.html Markiyan. On 15.02.2012 12:34, Markiyan Kushnir wrote: > Here it is: > > (kgdb) bt > #0 doadump () at /usr/RELENG_8/src/sys/kern/kern_shutdown.c:263 > #1 0xffffffff8036da50 in boot (howto=260) at > /usr/RELENG_8/src/sys/kern/kern_shutdown.c:441 > #2 0xffffffff8036def1 in panic (fmt=Variable "fmt" is not available. > ) at /usr/RELENG_8/src/sys/kern/kern_shutdown.c:614 > #3 0xffffffff80567240 in trap_fatal (frame=0xc, eva=Variable "eva" is > not available. > ) at /usr/RELENG_8/src/sys/amd64/amd64/trap.c:825 > #4 0xffffffff80567591 in trap_pfault (frame=0xffffff807dd4b8a0, > usermode=0) at /usr/RELENG_8/src/sys/amd64/amd64/trap.c:741 > #5 0xffffffff80567a4f in trap (frame=0xffffff807dd4b8a0) at > /usr/RELENG_8/src/sys/amd64/amd64/trap.c:478 > #6 0xffffffff8054e584 in calltrap () at > /usr/RELENG_8/src/sys/amd64/amd64/exception.S:228 > #7 0xffffffff804237f5 in ifindex_alloc_locked > (idxp=0xffffff807dd4b99e) at /usr/RELENG_8/src/sys/net/if.c:285 > #8 0xffffffff804286e1 in if_alloc (type=71 'G') at > /usr/RELENG_8/src/sys/net/if.c:453 > #9 0xffffffff81e2f07e in urtw_attach (dev=Variable "dev" is not available. > ) at /usr/RELENG_8/src/sys/modules/usb/urtw/../../../dev/usb/wlan/if_urtw.c:856 > #10 0xffffffff8039aef9 in device_attach (dev=0xffffff0016fca600) at > device_if.h:178 > #11 0xffffffff80272649 in usb_probe_and_attach > (udev=0xffffff0016e3c800, iface_index=Variable "iface_index" is not > available. > ) at /usr/RELENG_8/src/sys/dev/usb/usb_device.c:1195 > #12 0xffffffff8027aaa1 in uhub_explore (udev=0xffffff0016d98000) at > /usr/RELENG_8/src/sys/dev/usb/usb_hub.c:269 > #13 0xffffffff802653ec in usb_bus_explore (pm=Variable "pm" is not available. > ) at /usr/RELENG_8/src/sys/dev/usb/controller/usb_controller.c:349 > #14 0xffffffff8027ead5 in usb_process (arg=Variable "arg" is not available. > ) at /usr/RELENG_8/src/sys/dev/usb/usb_process.c:174 > #15 0xffffffff803413af in fork_exit (callout=0xffffffff8027ea00 > , arg=0xffffff80003f7db0, frame=0xffffff807dd4bc50) at > /usr/RELENG_8/src/sys/kern/kern_fork.c:876 > #16 0xffffffff8054eace in fork_trampoline () at > /usr/RELENG_8/src/sys/amd64/amd64/exception.S:602 > #17 0x0000000000000000 in ?? () > #18 0x0000000000000000 in ?? () > #19 0x0000000000000001 in ?? () > #20 0x0000000000000000 in ?? () > #21 0x0000000000000000 in ?? () > #22 0x0000000000000000 in ?? () > #23 0x0000000000000000 in ?? () > #24 0x0000000000000000 in ?? () > #25 0x0000000000000000 in ?? () > #26 0x0000000000000000 in ?? () > #27 0x0000000000000000 in ?? () > #28 0x0000000000000000 in ?? () > #29 0x0000000000000000 in ?? () > #30 0x0000000000000000 in ?? () > #31 0x0000000000000000 in ?? () > #32 0x0000000000000000 in ?? () > #33 0x0000000000000000 in ?? () > #34 0x0000000000000000 in ?? () > #35 0x0000000000000000 in ?? () > #36 0x0000000000000000 in ?? () > #37 0x0000000000000000 in ?? () > #38 0x0000000000000000 in ?? () > #39 0x0000000000000000 in ?? () > #40 0x0000000000000000 in ?? () > #41 0xffffffff808287e8 in sleepq_chains () > #42 0xffffff0002904cf0 in ?? () > #43 0x0000000000000000 in ?? () > #44 0xffffff00029048c0 in ?? () > #45 0xffffff807dd4b730 in ?? () > #46 0xffffff807dd4b6d8 in ?? () > #47 0xffffff000252e000 in ?? () > #48 0xffffffff80394462 in sched_switch (td=0xffffffff8027ea00, > newtd=0xffffff80003f7db0, flags=dwarf2_read_address: Corrupted DWARF > expression. > ) at /usr/RELENG_8/src/sys/kern/sched_ule.c:1861 > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > > 2012/2/15 Sergey Kandaurov: >> On 15 February 2012 13:01, Markiyan Kushnir wrote: >>> Hello, >>> >>> [First seen on RELENG_9,] then (trying to get back to 8) on RELENG_8, both >>> csup'ed around Feb. 10. >>> >>> Now worked around by turning the RTL8187L off in the BIOS. >>> >>> %uname -a >>> FreeBSD mkushnir.zapto.org 8.2-STABLE FreeBSD 8.2-STABLE #0: Sat Feb 11 >>> 19:39:29 EET 2012 >>> root@mkushnir.zapto.org:/usr/obj/usr/RELENG_8/src/sys/MAREK amd64 >>> >>> >>> Below are the panic info and the full dmesg preceding the panic. Please let >>> me know if there is anything more I could provide. >>> >>> [From my quick source code analysis, it looks like the driver fails to >>> recognize the device in if_urtw.c, urtw_get_rfchip(), although later >>> proceeds with the attach, which seems not quite logical... Correct behavior >>> would probably be to not attach at all.] >>> >>> >>> crash info: >>> ----------- >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 0; apic id = 00 >>> fault virtual address = 0x28 >>> fault code = supervisor read data, page not present >>> instruction pointer = 0x20:0xffffffff803eff25 >>> stack pointer = 0x28:0xffffff807df08950 >>> frame pointer = 0x28:0xffffff807df08980 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 14 (usbus3) >>> trap number = 12 >>> panic: page fault >>> cpuid = 0 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >>> kdb_backtrace() at kdb_backtrace+0x37 >>> panic() at panic+0x187 >>> trap_fatal() at trap_fatal+0x290 >>> trap_pfault() at trap_pfault+0x201 >>> trap() at trap+0x3df >>> calltrap() at calltrap+0x8 >>> --- trap 0xc, rip = 0xffffffff803eff25, rsp = 0xffffff807df08950, rbp = >>> 0xffffff807df08980 --- >>> ifindex_alloc_locked() at ifindex_alloc_locked+0x25 >>> if_alloc() at if_alloc+0x71 >>> urtw_attach() at urtw_attach+0x63e >>> device_attach() at device_attach+0x69 >>> usb_probe_and_attach() at usb_probe_and_attach+0x1f9 >>> uhub_explore() at uhub_explore+0x4a1 >>> usb_bus_explore() at usb_bus_explore+0xdc >>> usb_process() at usb_process+0xd5 >>> fork_exit() at fork_exit+0x11f >>> fork_trampoline() at fork_trampoline+0xe >>> --- trap 0, rip = 0, rsp = 0xffffff807df08d00, rbp = 0 --- >>> Uptime: 9s >>> Dumping 441 out of 8179 MB:..4%..11%..22%..33%..44%..51%..62%..73%..84%..91% >>> >> [..] >>> WARNING: VIMAGE (virtualized network stack) is a highly experimental >> [..] >>> savecore: reboot after panic: page fault >>> Feb 10 22:33:21 mkushnir savecore: reboot after panic: page fault >>> savecore: writing core to vmcore.7 >> >> Something tells me that the problem may lie in VIMAGE. >> >> Can you issue the following command: kgdb -n 7 >> then in gdb menu run this command: bt >> to resolve source lines. >> >> [ anticipating hte response, I will try to lookup if_alloc+0x71 >> for my system built around the same date (w/o vimage though): >> 0xffffffff80698211 is in if_alloc (/usr/src/sys/net/if.c:283). >> 278 retry: >> 279 /* >> 280 * Try to find an empty slot below V_if_index. If we >> fail, take the >> 281 * next slot. >> 282 */ >> 283 for (idx = 1; idx<= V_if_index; idx++) { >> 284 if (V_ifindex_table[idx].ife_ifnet == NULL) >> 285 break; >> 286 } >> 287 >> ] >> >> -- >> wbr, >> pluknet From owner-freebsd-stable@FreeBSD.ORG Thu Mar 1 02:01:55 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC802106564A; Thu, 1 Mar 2012 02:01:55 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (unknown [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b2]) by mx1.freebsd.org (Postfix) with ESMTP id 82B0A8FC0A; Thu, 1 Mar 2012 02:01:55 +0000 (UTC) Received: from meatwad.mouf.net (cpe-024-162-230-236.nc.res.rr.com [24.162.230.236]) (authenticated bits=0) by mouf.net (8.14.4/8.14.4) with ESMTP id q2121j0s074156 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 29 Feb 2012 21:01:45 -0500 (EST) (envelope-from swills@FreeBSD.org) Message-ID: <4F4ED889.2070608@FreeBSD.org> Date: Wed, 29 Feb 2012 21:01:45 -0500 From: Steve Wills User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111228 Thunderbird/9.0 MIME-Version: 1.0 To: "K. Macy" References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mouf.net [204.109.58.86]); Wed, 29 Feb 2012 21:01:47 -0500 (EST) X-Virus-Scanned: clamav-milter 0.97.2 at mouf.net X-Virus-Status: Clean Cc: stable@FreeBSD.org, Doug Barton , current@FreeBSD.org, =?UTF-8?B?eiBXxIVzaWtvd3NraQ==?= , Arnaud Lacombe , Alexander Leidinger , "Bjoern A. Zeeb" Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Mar 2012 02:01:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/29/12 13:17, K. Macy wrote: > . >> >> I tried it, on both FreeBSD routers, web systems, and database >> servers; all on 8.2+. It still causes massive instability. >> Disabling the sysctl, and/or removing it from the kernel solved >> the problems. > > Routing I can believe, but I'm wondering how close attention you > paid to the workload. There are CDN networks with high uptimes and > shipping firewall products that use flowtable, so your mention of > web systems forces makes me ask for specifics. > The failure I experienced was with web servers running 8.0 behind a F5 load balancer in an HA setup. Whenever the failover happened, the web servers would continue sending to the wrong MAC address, despite the arp table updating. Disabling flowtable via the sysctl solved the problem. Maybe Doug's failure was similar, maybe not, but I thought I'd throw my $0.02 in. Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJPTtiJAAoJEPXPYrMgexuhp8EIAKGGtZzcxgQ4zVO5SKy1jAOH DXLRLYfdm8NJB9hYEvtUa9/nltAE35zQMp7FU4AlZ2L2ol/J7W9aODiN0gw9AFEr dxBYyQliDKvVwLgah9a5PaXNM3kpx9ZvZGM3lBQGQbZaEV+ERwjBXkfIqjEB4Ei5 bBd7841jQm22s1xJOuJTdMGrpnY1DMUPdPCFOAtyQmTAhWpoELgtQBvP9kGYNKv2 3NAPnjFuooe9fdze9VSO8TWFJSb82DVbRsz6JiR0998oHXPApCh4I5y1rNcg2qA/ 1x2EdFlivXpgjC4nKUgFjhohmdGv20FrLfex4eOq6dSMF0Baje86PJcc8EZ1DK0= =NUft -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Mar 1 02:17:33 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AEFA8106564A; Thu, 1 Mar 2012 02:17:33 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 830A58FC13; Thu, 1 Mar 2012 02:17:32 +0000 (UTC) Received: by eaaf13 with SMTP id f13so24328eaa.13 for ; Wed, 29 Feb 2012 18:17:31 -0800 (PST) Received-SPF: pass (google.com: domain of kmacybsd@gmail.com designates 10.213.102.12 as permitted sender) client-ip=10.213.102.12; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kmacybsd@gmail.com designates 10.213.102.12 as permitted sender) smtp.mail=kmacybsd@gmail.com; dkim=pass header.i=kmacybsd@gmail.com Received: from mr.google.com ([10.213.102.12]) by 10.213.102.12 with SMTP id e12mr1467971ebo.5.1330568251539 (num_hops = 1); Wed, 29 Feb 2012 18:17:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=8lZeJ+Tz71H13Jh6TmyGRlAzmjNgyloN32MZfAZ+h54=; b=Zs0QiAsw5uF1kpQWJLPVGpHaRWJLjc/I6kolHrKN3ctQUlZbl2ZcJtmkOwKOPhzK9+ KAzD44K+keZsRj6XObeS83m/K68AejMVhr2hl57+xAGfdhDcsCDxO3OCTHQbyaejCQwd TsI7YQ9mFtjDjVK1SwPCFk6/UV+eU96Z2GO9Y= Received: by 10.213.102.12 with SMTP id e12mr1169599ebo.5.1330568250081; Wed, 29 Feb 2012 18:17:30 -0800 (PST) Received: from [192.168.0.100] (host15-203-dynamic.42-79-r.retail.telecomitalia.it. [79.42.203.15]) by mx.google.com with ESMTPS id o49sm1409686eeb.7.2012.02.29.18.17.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 18:17:28 -0800 (PST) References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> In-Reply-To: <4F4ED889.2070608@FreeBSD.org> Mime-Version: 1.0 (1.0) Message-Id: X-Mailer: iPad Mail (9A405) From: K Macy Date: Thu, 1 Mar 2012 03:17:29 +0100 To: Steve Wills Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "stable@FreeBSD.org" , Doug Barton , "K. Macy" , =?utf-8?Q?z_W=C4=85sikowski?= , Arnaud Lacombe , "BjoernA. Zeeb" , Alexander Leidinger , "current@FreeBSD.org" Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Mar 2012 02:17:33 -0000 Inviato da iPad Il giorno 01/mar/2012, alle ore 03:01, Steve Wills ha s= critto: >=20 > The failure I experienced was with web servers running 8.0 behind a F5 > load balancer in an HA setup. Whenever the failover happened, the web > servers would continue sending to the wrong MAC address, despite the > arp table updating. Disabling flowtable via the sysctl solved the > problem. Maybe Doug's failure was similar, maybe not, but I thought > I'd throw my $0.02 in. >=20 Thanks. I just committed a change recently for 8 - HEAD to address that. I w= ould like to know if it solves the problem. > Steve > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.18 (FreeBSD) >=20 > iQEcBAEBAgAGBQJPTtiJAAoJEPXPYrMgexuhp8EIAKGGtZzcxgQ4zVO5SKy1jAOH > DXLRLYfdm8NJB9hYEvtUa9/nltAE35zQMp7FU4AlZ2L2ol/J7W9aODiN0gw9AFEr > dxBYyQliDKvVwLgah9a5PaXNM3kpx9ZvZGM3lBQGQbZaEV+ERwjBXkfIqjEB4Ei5 > bBd7841jQm22s1xJOuJTdMGrpnY1DMUPdPCFOAtyQmTAhWpoELgtQBvP9kGYNKv2 > 3NAPnjFuooe9fdze9VSO8TWFJSb82DVbRsz6JiR0998oHXPApCh4I5y1rNcg2qA/ > 1x2EdFlivXpgjC4nKUgFjhohmdGv20FrLfex4eOq6dSMF0Baje86PJcc8EZ1DK0=3D > =3DNUft > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"= From owner-freebsd-stable@FreeBSD.ORG Thu Mar 1 06:35:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C4D5E106564A for ; Thu, 1 Mar 2012 06:35:19 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 337998FC1A for ; Thu, 1 Mar 2012 06:35:18 +0000 (UTC) Received: by lagv3 with SMTP id v3so453742lag.13 for ; Wed, 29 Feb 2012 22:35:17 -0800 (PST) Received-SPF: pass (google.com: domain of timp87@gmail.com designates 10.112.8.129 as permitted sender) client-ip=10.112.8.129; Authentication-Results: mr.google.com; spf=pass (google.com: domain of timp87@gmail.com designates 10.112.8.129 as permitted sender) smtp.mail=timp87@gmail.com; dkim=pass header.i=timp87@gmail.com Received: from mr.google.com ([10.112.8.129]) by 10.112.8.129 with SMTP id r1mr1691305lba.38.1330583717926 (num_hops = 1); Wed, 29 Feb 2012 22:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OykZgpAgxv3eE+epkvI0h9wlO16BR+GnB+QvJrz41Kg=; b=CaFqFT+OTdeQtXlBNtIak55f6pDVUDxAjPAsXvAWqq1od+THIGQdJjU3c8BOqPuBgc uygbiNTRpzg0LZ17x6gGUpHXFUvG5IBau8IZ6ryL7iJpNUYpCpdhQigqRXgK+a/OjRbv U+xskQfM8qhmMSnsL/Ya9NXDqwacGoV13TCvo= MIME-Version: 1.0 Received: by 10.112.8.129 with SMTP id r1mr1385142lba.38.1330583717842; Wed, 29 Feb 2012 22:35:17 -0800 (PST) Received: by 10.152.28.201 with HTTP; Wed, 29 Feb 2012 22:35:17 -0800 (PST) In-Reply-To: <20120229141628.Horde.dEOYCZjmRSRPTiUs4NvBeec@webmail.leidinger.net> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <1329890164178-5504219.post@n5.nabble.com> <20120222140308.Horde.RjSecpjmRSRPROeM24KCgsA@webmail.leidinger.net> <1330501225474-5524279.post@n5.nabble.com> <20120229110106.Horde.57mdQpjmRSRPTfdiZgvhTsA@webmail.leidinger.net> <20120229141628.Horde.dEOYCZjmRSRPTiUs4NvBeec@webmail.leidinger.net> Date: Thu, 1 Mar 2012 10:35:17 +0400 Message-ID: From: Pavel Timofeev To: Alexander Leidinger Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Mar 2012 06:35:19 -0000 I have just tried lastest configs and see following messages while kernel b= oot: Copyright (c) 1992-2012 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 10.0-CURRENT #0: Wed Feb 29 22:47:35 MSK 2012 mox@rock:/usr/obj/usr/src/sys/SMALL amd64 WARNING: WITNESS option enabled, expect reduced performance. link_elf_obj: symbol xpt_create_path undefined KLD file hptiop.ko - could not finalize loading link_elf_obj: symbol firmware_get undefined KLD file isp.ko - could not finalize loading link_elf_obj: symbol xpt_freeze_simq undefined KLD file mps.ko - could not finalize loading link_elf_obj: symbol cam_simq_alloc undefined KLD file hptmv.ko - could not finalize loading CPU: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz (2906.39-MHz K8-class = CPU) Don't you know why do I get it? 29 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2012=C2=A0=D0=B3. 17:16 =D0= =BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Alexa= nder Leidinger =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: > Quoting Pavel Timofeev (from Wed, 29 Feb 2012 15:23:09 > +0400): > >> Please, remove >> geom_part_bsd_load=3D"YES" >> geom_part_ebr_load=3D"YES" >> geom_part_mbr_load=3D"YES" >> from loader.conf, it makes panic my machine. > > > Ooops, fixed. Thanks for testing! > > Bye, > Alexander. > > >> See /usr/src/sys/(amd64|i386)/conf/DEFAULTS >> it has already set as default options. >> >> >> >> 29 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2012=C2=A0=D0=B3. 14:01 = =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Al= exander Leidinger >> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB: >>> >>> Quoting timp (from Tue, 28 Feb 2012 23:40:25 -0800 >>> (PST)): >>> >>>> Excuse me, why don't you add geom_part_gpt_load=3D"YES" and >>>> geom_label_load=3D"YES" to your sample (i386|amd64)_SMALL_loader.conf? >>> >>> >>> >>> I didn't had time to add them as I had to have a look at the collateral >>> damage of a DDoS. I added now some GEOM modules (not only the two above= ) >>> to >>> the loader.conf, and I also added the additional resource >>> control/accounting >>> options to the kernel. >>> >>> Bye, >>> Alexander. >>> >>> -- >>> We can defeat gravity. =C2=A0The problem is the paperwork involved. >>> >>> >>> http://www.Leidinger.net =C2=A0 =C2=A0Alexander @ Leidinger.net: PGP ID= =3D B0063FE7 >>> http://www.FreeBSD.org =C2=A0 =C2=A0 =C2=A0 netchild @ FreeBSD.org =C2= =A0: PGP ID =3D 72077137 >>> > > -- > The first time is for love. > The next time is 0. > > > http://www.Leidinger.net =C2=A0 =C2=A0Alexander @ Leidinger.net: PGP ID = =3D B0063FE7 > http://www.FreeBSD.org =C2=A0 =C2=A0 =C2=A0 netchild @ FreeBSD.org =C2=A0= : PGP ID =3D 72077137 > From owner-freebsd-stable@FreeBSD.ORG Thu Mar 1 08:29:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C037106566B for ; Thu, 1 Mar 2012 08:29:59 +0000 (UTC) (envelope-from pyunyh@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 269B88FC0C for ; Thu, 1 Mar 2012 08:29:58 +0000 (UTC) Received: by pbcwy7 with SMTP id wy7so646627pbc.13 for ; Thu, 01 Mar 2012 00:29:58 -0800 (PST) Received-SPF: pass (google.com: domain of pyunyh@gmail.com designates 10.68.229.5 as permitted sender) client-ip=10.68.229.5; Authentication-Results: mr.google.com; spf=pass (google.com: domain of pyunyh@gmail.com designates 10.68.229.5 as permitted sender) smtp.mail=pyunyh@gmail.com; dkim=pass header.i=pyunyh@gmail.com Received: from mr.google.com ([10.68.229.5]) by 10.68.229.5 with SMTP id sm5mr16454542pbc.82.1330590598801 (num_hops = 1); Thu, 01 Mar 2012 00:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ejtGn85rooQRJqna0UCj1nMksiN1L4kxIoT8ka5QQjw=; b=DCyCicAHjOBpCg8PkPey3oT+BjuBMw+8nmCqlSVaHZIAv3kCBHE1zERdIZ611SZjBA WzthngneQuBIq77MhUBNKkFOcn83TSvlFkqdzhSQFnxcI9yruLHtyhlD2nrKqdixRbDl 1MzAEuA4tG3Bg9UQeTKMAXiylTRrlb4lHqLq8= Received: by 10.68.229.5 with SMTP id sm5mr13662605pbc.82.1330590598750; Thu, 01 Mar 2012 00:29:58 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id l1sm1487451pbe.54.2012.03.01.00.29.56 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Mar 2012 00:29:58 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 01 Mar 2012 17:29:55 -0800 From: YongHyeon PYUN Date: Thu, 1 Mar 2012 17:29:55 -0800 To: Pavel Gorshkov Message-ID: <20120302012955.GC1685@michelle.cdnetworks.com> References: <20120228210329.GA2741@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120228210329.GA2741@localhost> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: msk0: interrupt storm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 08:29:59 -0000 On Wed, Feb 29, 2012 at 01:03:29AM +0400, Pavel Gorshkov wrote: > My laptop running 9.0-RELEASE/amd64/GENERIC freezes and > (sometimes) unfreezes intermittently, logging the following: > > Feb 28 23:07:36 lifebook kernel: interrupt storm detected on "irq259:"; throttling interrupt source > > $ vmstat -i > ... > irq259: mskc0 11669511 3456 > > > Looks very similar to this: > http://www.freebsd.org/cgi/query-pr.cgi?pr=164569 > > Any suggestions? Try disabling MSI and see whether that makes any difference. From owner-freebsd-stable@FreeBSD.ORG Thu Mar 1 10:57:31 2012 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 C44221065670; Thu, 1 Mar 2012 10:57:31 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2215B8FC12; Thu, 1 Mar 2012 10:57:30 +0000 (UTC) Received: by eaaf13 with SMTP id f13so140197eaa.13 for ; Thu, 01 Mar 2012 02:57:30 -0800 (PST) Received-SPF: pass (google.com: domain of ndenev@gmail.com designates 10.14.96.6 as permitted sender) client-ip=10.14.96.6; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ndenev@gmail.com designates 10.14.96.6 as permitted sender) smtp.mail=ndenev@gmail.com; dkim=pass header.i=ndenev@gmail.com Received: from mr.google.com ([10.14.96.6]) by 10.14.96.6 with SMTP id q6mr2833632eef.6.1330599450306 (num_hops = 1); Thu, 01 Mar 2012 02:57:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=y3znwjrq87CPeQvSPlm1r7YW+NJXPlMOCyEdkkCJSaw=; b=fgoF4/B12ILFKDYS0UCpAosbfPbqx7giYrE6Z56LR6chdwadwMHj017BbaQHk6iimg ZHTr3JFUq5T6aXRD8xb6AVQdePvdn9udH9LVEzSqvdKbFy3RC+ezf5KKJtKmuzt8tuzg eHt6xiDQjURQo/anZ0gw3wA2NAz6fRy91DwUE= Received: by 10.14.96.6 with SMTP id q6mr2128248eef.6.1330597624665; Thu, 01 Mar 2012 02:27:04 -0800 (PST) Received: from ndenevsa.sf.moneybookers.net (g1.moneybookers.com. [217.18.249.148]) by mx.google.com with ESMTPS id v51sm5776823eef.2.2012.03.01.02.27.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Mar 2012 02:27:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> Date: Thu, 1 Mar 2012 12:27:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2F3C6FA2-4045-4022-A317-42CF616A84A8@gmail.com> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> To: Alexander Leidinger X-Mailer: Apple Mail (2.1257) Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Mar 2012 10:57:31 -0000 On Feb 21, 2012, at 3:35 PM, Alexander Leidinger wrote: > Hi, >=20 > I created a kernel config for i386/amd64 (should work on -current and = 9.x) and a suitable loader.conf which: > - tries to provide as much features as GENERIC (I lost one or two disk > controllers, they are not available as a module... or I didn't find > them) > - incorporates some more features based upon a poll on stable@ > (see below) > - loads as much as possible as a module >=20 > I've compile-tested them on i386 and amd64, but I didn't had time yet = to give it a try on a spare machine. I may get some time next week to = test (i386 only). It would be nice if someone could help testing: > - compile the kernel > - make _sure_ you have a way to recover the system in case > the new kernel+loader.conf fails > - verify that the example loader.conf contains all devices > which are important for you > - copy the example loader.conf to /boot/loader.conf > - give it a try >=20 > You can download from > http://www.Leidinger.net/FreeBSD/current-patches/ > The files are > - i386_SMALL > - i386_SMALL_loader.conf > - amd64_SMALL > - amd64_SMALL_loader.conf > I didn't provide direct links for eqch one on purpose. If you do not = know how to recover a system with an unsuitable loader.conf, don't give = this a try (you could check a diff between GENERIC and SMALL, and make = sure all removed devices which are imporant for you are in the = loader.conf). They should work on -current and on 9.x, for 8.x I'm not = sure if it woll work without removing some stuff (GENERIC on 8.x comes = without some more debugging options, make sure you don't get surprised = by them, but those may not be the only differences). >=20 > I didn't use the name MODULAR on purpose, I've chosen a name where the = first letter does not yet exist in the kernel config directory, to make = tab-completion more easy. If you are not happy with the name, keep your = opinion for yourself please, until after you tested this on a (maybe = virtual) system. >=20 > The loader.conf was generated with a script from a diff between = GENERIC and SMALL, if there's a name mismatch between the config-name = and the module-name, the script may have missed the module (I added some = missing sound modules, but I may have overlooked something). You better = double-check before giving it a try. The loader.conf is also supposed to = disable some features (at the end of the file) which are new compared to = what is in GENERIC, if the particular feature could cause a change in = behavior. >=20 > The new stuff in the kernel config compared to GENERIC is (in order of = number of requests from users): > - IPSEC (+ device enc + IPSEC_NAT_T) > - ALTQ > - SW_WATCHDOG > - QUOTA > - IPSTEALTH (disabled in loader.conf) > - IPFIREWALL_FORWARD (touches every packet, power users which need > a bigger PPS but not this feature can recompile the kernel, > discussed with julian@) > - FLOWTABLE (disabled in loader.conf) > - BPF_JITTER >=20 > In the poll there where some more options requested, but most of them = can be handled via the loader or sysctl (e.g. the firewalls can be = loaded as modules). For some of them I added some comments at the end of = the SMALL config to make it more easy to find the correct way of = configuring them. Doc-committers may want to have a look, maybe there's = an opportunity to improve existing documentation. >=20 > I'm interested in success reports, failure reports, and reports about = missing stuff in loader.conf (mainly compared to the devices available = in GENERIC, but missing stuff which could help getting a system = installed and booted is welcome even if what you propose is not in = GENERIC). >=20 > Bye, > Alexander. >=20 > --=20 >=20 > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D = 72077137 >=20 Just an idea : Ship FreeBSD with all the kernel object files (even compile different versions of them, let's say networking with = IPFORWARD and networking without), and then let the user relink the kernel with some shell script. This way freebsd-update can binary update the object files,=20 and then relink the users's kernel. This of course will probably need some infrastructure work to make it = possible. P.S.: As I said, just an idea off the top of my head :) From owner-freebsd-stable@FreeBSD.ORG Thu Mar 1 14:28:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A5DE1065674 for ; Thu, 1 Mar 2012 14:28:08 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1ED9A8FC12 for ; Thu, 1 Mar 2012 14:28:07 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1S36za-000AsG-RR; Thu, 01 Mar 2012 18:28:26 +0400 Date: Thu, 1 Mar 2012 18:28:26 +0400 From: Slawa Olhovchenkov To: Peter Jeremy Message-ID: <20120301142826.GG97848@zxy.spb.ru> References: <1330081612.13430.39.camel@pow> <20120227181436.GA49667@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120227181436.GA49667@server.vk2pj.dyndns.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-fs@freebsd.org, Luke Marsden , "freebsd-stable@freebsd.org" , team@hybrid-logic.co.uk Subject: Re: Another ZFS ARC memory question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 14:28:08 -0000 On Tue, Feb 28, 2012 at 05:14:37AM +1100, Peter Jeremy wrote: > > * what is the community's advice for production machines running > > ZFS on FreeBSD, is manually limiting the ARC cache (to ensure > > that there's enough actually free memory to handle a spike in > > application memory usage) the best solution to this > > spike-in-memory-means-crash problem? > > Are you swapping onto a ZFS vdev? If so, change back to a raw (or > geom) device - swapping to ZFS is known to be problematic. If you I see kernel stuck when swapping to ZFS. This is only known problem? From owner-freebsd-stable@FreeBSD.ORG Thu Mar 1 15:38:00 2012 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 C1519106566B; Thu, 1 Mar 2012 15:38:00 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 76BE78FC16; Thu, 1 Mar 2012 15:38:00 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1S37Sl-000BLi-0K; Thu, 01 Mar 2012 18:58:35 +0400 Date: Thu, 1 Mar 2012 18:58:34 +0400 From: Slawa Olhovchenkov To: Alexander Leidinger Message-ID: <20120301145834.GH97848@zxy.spb.ru> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Mar 2012 15:38:00 -0000 On Tue, Feb 21, 2012 at 02:35:37PM +0100, Alexander Leidinger wrote: > You can download from > http://www.Leidinger.net/FreeBSD/current-patches/ > The files are > - i386_SMALL > - i386_SMALL_loader.conf > - amd64_SMALL > - amd64_SMALL_loader.conf Where SCSI disk/etc? From owner-freebsd-stable@FreeBSD.ORG Thu Mar 1 17:12:40 2012 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 37DCB106564A for ; Thu, 1 Mar 2012 17:12:40 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (r2b9.nsu.ru [212.192.164.39]) by mx1.freebsd.org (Postfix) with ESMTP id C724F8FC15 for ; Thu, 1 Mar 2012 17:12:39 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1S39Xi-0004Wh-4t; Fri, 02 Mar 2012 00:11:50 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q21HBxkO069309; Fri, 2 Mar 2012 00:11:59 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q21HBQYT069280; Fri, 2 Mar 2012 00:11:26 +0700 (NOVT) (envelope-from danfe) Date: Fri, 2 Mar 2012 00:11:25 +0700 From: Alexey Dokuchaev To: stable@freebsd.org Message-ID: <20120301171125.GA61435@regency.nsu.ru> References: <20120223025713.GA65874@regency.nsu.ru> <20120227142815.GA86253@regency.nsu.ru> <20120227152238.GA2940@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120227152238.GA2940@regency.nsu.ru> User-Agent: Mutt/1.4.2.1i Cc: hselasky@freebsd.org Subject: Re: Resume broken in 8.3-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, 01 Mar 2012 17:12:40 -0000 On Mon, Feb 27, 2012 at 10:22:38PM +0700, Alexey Dokuchaev wrote: > On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev wrote: > > I was mistaken, the latest kernel with working resume is from Jan 4 00:00 > > UTC, kernel from Jan 4 01:00 UTC does not allow my laptop to come back > > from zzz(8) successfully. It seems that offending change is rev. 1.9.2.5 > > of sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450). I've redone my bisecting, now suspending/resuming around at least ten times in console with zzz(8). I must apologize to rmacklem@, his commit has nothing to do with it. Apparently, the culprit is SVN rev 229370 on 2012-01-03 09:15:54Z by hselasky@, which (ironically enough) supposed to bring better support for USB controller suspend and resume. Kernel csuped and built before this date resumes just fine for me. However, the problem might lay deeper: disabling all USB modules (I traditionally run slim kernels with everything down to io/mem offloaded into modules) does not fix the hang, see below. Selectively disabling UHCI or EHCI does not make any difference either. Debugging of this issue is, however, complicated by the fact that doing "call doadump" results in "Dumping 68M:" message (similar problem was reported[1] by glebius@ back in 2004), and then nothing happens except for IDE led light-up and frozen debugger, which makes post-mortem analysis with kgdb(1) impossible. Setting up serial console (since it's a laptop, the only possibility for me right now is to use some noname USB adapter via uftdi(4)) works, but kernel GDB does not like it. Perhaps I'm just not passing 0x80 flag correctly, but hint.uftdi.0.flags="0x80" does not work. Is GDB backend impossible with USB serial adapters, or I am just doing it wrong? What strikes me most is that even with plain kbdmux(4) or atkdb(4) I still cannot resume, even on previous (before r229370) kernels (the earliest I've tried is from Jan 1 00:00 UTC). Any debugging hints or patches to try are highly appreciated. Thus far, the latest kernel where resume works (with USB stuff enabled) is from Jan 3 19:15 UTC. Hans Petter, do you have any ideas about it? ./danfe [1] http://lists.freebsd.org/pipermail/freebsd-current/2004-May/027732.html From owner-freebsd-stable@FreeBSD.ORG Thu Mar 1 19:05:36 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3094106566B for ; Thu, 1 Mar 2012 19:05:36 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.c2i.net [212.247.154.226]) by mx1.freebsd.org (Postfix) with ESMTP id 2BB308FC08 for ; Thu, 1 Mar 2012 19:05:35 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe08.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 247024289; Thu, 01 Mar 2012 19:55:32 +0100 From: Hans Petter Selasky To: Alexey Dokuchaev Date: Thu, 1 Mar 2012 19:53:52 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.3-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <20120227152238.GA2940@regency.nsu.ru> <20120301171125.GA61435@regency.nsu.ru> In-Reply-To: <20120301171125.GA61435@regency.nsu.ru> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <201203011953.52600.hselasky@c2i.net> Cc: "stable@freebsd.org" Subject: Re: Resume broken in 8.3-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, 01 Mar 2012 19:05:36 -0000 On Thursday 01 March 2012 18:11:25 Alexey Dokuchaev wrote: > On Mon, Feb 27, 2012 at 10:22:38PM +0700, Alexey Dokuchaev wrote: > > On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev wrote: > > > I was mistaken, the latest kernel with working resume is from Jan 4 > > > 00:00 UTC, kernel from Jan 4 01:00 UTC does not allow my laptop to > > > come back from zzz(8) successfully. It seems that offending change is > > > rev. 1.9.2.5 of sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev > > > 229450). > > I've redone my bisecting, now suspending/resuming around at least ten > times in console with zzz(8). I must apologize to rmacklem@, his commit > has nothing to do with it. Apparently, the culprit is SVN rev 229370 on > 2012-01-03 09:15:54Z by hselasky@, which (ironically enough) supposed to > bring better support for USB controller suspend and resume. Kernel csuped > and built before this date resumes just fine for me. However, the problem > might lay deeper: disabling all USB modules (I traditionally run slim > kernels with everything down to io/mem offloaded into modules) does not fix > the hang, see below. Selectively disabling UHCI or EHCI does not make any > difference either. > > Debugging of this issue is, however, complicated by the fact that doing > "call doadump" results in "Dumping 68M:" message (similar problem was > reported[1] by glebius@ back in 2004), and then nothing happens except for > IDE led light-up and frozen debugger, which makes post-mortem analysis > with kgdb(1) impossible. Setting up serial console (since it's a laptop, > the only possibility for me right now is to use some noname USB adapter > via uftdi(4)) works, but kernel GDB does not like it. Perhaps I'm just > not passing 0x80 flag correctly, but hint.uftdi.0.flags="0x80" does not > work. Is GDB backend impossible with USB serial adapters, or I am just > doing it wrong? > > What strikes me most is that even with plain kbdmux(4) or atkdb(4) I still > cannot resume, even on previous (before r229370) kernels (the earliest > I've tried is from Jan 1 00:00 UTC). Any debugging hints or patches to > try are highly appreciated. > > Thus far, the latest kernel where resume works (with USB stuff enabled) is > from Jan 3 19:15 UTC. Hans Petter, do you have any ideas about it? > Hi, The USB controllers should be reset after resume. Suspend is currently ASYNC. This might be one problem. Resume is also ASYNC, because we cannot block in the device_resume() callback. Make sure no serial port adapters have open devices and are blocking suspend and resume. What is output from usbconfig as root, before and after suspend/resume ? --HPS From owner-freebsd-stable@FreeBSD.ORG Thu Mar 1 19:42:48 2012 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 3C918106564A for ; Thu, 1 Mar 2012 19:42:48 +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 F214B8FC14 for ; Thu, 1 Mar 2012 19:42:47 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q21Jgkav099821 for ; Thu, 1 Mar 2012 12:42:46 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q21JgkRq099818 for ; Thu, 1 Mar 2012 12:42:46 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 1 Mar 2012 12:42:46 -0700 (MST) From: Warren Block To: stable@freebsd.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 01 Mar 2012 12:42:47 -0700 (MST) Cc: Subject: Re: sendmail and smarthost X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Mar 2012 19:42:48 -0000 On Mon, 27 Feb 2012, Warren Block wrote: > In 8.3-PRERELEASE, sendmail is now happily ignoring a smarthost unless > DONT_PROBE_INTERFACES is set. That used to be unnecessary. > > That machine rarely sends email, but a bug followup sent on Feb 25 went > through. Maybe not significant since it was outside the local domain. Adding an IPv6 entry for the hostname to /etc/hosts prevents the problem without requiring DONT_PROBE_INTERFACES. (Thanks to George Shapiro!) This brings up the question of why an IPv6 hosts entry is needed on an IPv4-only system, but that's for another thread. From owner-freebsd-stable@FreeBSD.ORG Thu Mar 1 19:59:44 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1CDA41065675 for ; Thu, 1 Mar 2012 19:59:44 +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 B9D558FC1E for ; Thu, 1 Mar 2012 19:59:43 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q21JxhDq099997 for ; Thu, 1 Mar 2012 12:59:43 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q21Jxh40099994 for ; Thu, 1 Mar 2012 12:59:43 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 1 Mar 2012 12:59:42 -0700 (MST) From: Warren Block To: stable@freebsd.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 01 Mar 2012 12:59:43 -0700 (MST) Cc: Subject: Re: sendmail and smarthost X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Mar 2012 19:59:44 -0000 On Thu, 1 Mar 2012, Warren Block wrote: > Adding an IPv6 entry for the hostname to /etc/hosts prevents the problem > without requiring DONT_PROBE_INTERFACES. (Thanks to George Shapiro!) Make that "Greg", not George. He now gets to call me "Wally". From owner-freebsd-stable@FreeBSD.ORG Thu Mar 1 20:28:13 2012 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 1CB66106564A for ; Thu, 1 Mar 2012 20:28:13 +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 D13FF8FC0C for ; Thu, 1 Mar 2012 20:28:12 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q21KSCTF000318 for ; Thu, 1 Mar 2012 13:28:12 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q21KSCwG000315 for ; Thu, 1 Mar 2012 13:28:12 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Thu, 1 Mar 2012 13:28:12 -0700 (MST) From: Warren Block To: stable@freebsd.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Thu, 01 Mar 2012 13:28:12 -0700 (MST) Cc: Subject: Re: sendmail and smarthost X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Mar 2012 20:28:13 -0000 On Thu, 1 Mar 2012, Warren Block wrote: > On Mon, 27 Feb 2012, Warren Block wrote: > >> In 8.3-PRERELEASE, sendmail is now happily ignoring a smarthost unless >> DONT_PROBE_INTERFACES is set. That used to be unnecessary. >> >> That machine rarely sends email, but a bug followup sent on Feb 25 went >> through. Maybe not significant since it was outside the local domain. > > Adding an IPv6 entry for the hostname to /etc/hosts prevents the problem > without requiring DONT_PROBE_INTERFACES. (Thanks to George Shapiro!) > > This brings up the question of why an IPv6 hosts entry is needed on an > IPv4-only system, but that's for another thread. Or not, updating and rebuilding seems to have everything back to normal. Most likely I built a GENERIC kernel with IPv6 instead of a custom one without. From owner-freebsd-stable@FreeBSD.ORG Thu Mar 1 21:14:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4035F106566C for ; Thu, 1 Mar 2012 21:14:02 +0000 (UTC) (envelope-from gorshkov.pavel@gmail.com) Received: from imp01.mtu.ru (imp01.mtu.ru [62.5.255.10]) by mx1.freebsd.org (Postfix) with ESMTP id BE3268FC1B for ; Thu, 1 Mar 2012 21:14:01 +0000 (UTC) Received: from localhost.my.domain ([91.79.72.109]) by imp01.mtu.ru with bizsmtp id gMDz1i00u2MUDAr01ME0YK; Fri, 02 Mar 2012 01:14:00 +0400 Received: from localhost (localhost [127.0.0.1]) by localhost.my.domain (8.14.5/8.14.5) with ESMTP id q21LDuwT002684; Fri, 2 Mar 2012 01:13:56 +0400 (MSK) (envelope-from gorshkov.pavel@gmail.com) Date: Fri, 2 Mar 2012 01:13:56 +0400 From: Pavel Gorshkov To: YongHyeon PYUN Message-ID: <20120301211356.GA2603@localhost> References: <20120228210329.GA2741@localhost> <20120302012955.GC1685@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120302012955.GC1685@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: msk0: interrupt storm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Mar 2012 21:14:02 -0000 On Thu, Mar 01, 2012 at 05:29:55PM -0800, YongHyeon PYUN wrote: > On Wed, Feb 29, 2012 at 01:03:29AM +0400, Pavel Gorshkov wrote: > > My laptop running 9.0-RELEASE/amd64/GENERIC freezes and > > (sometimes) unfreezes intermittently, logging the following: > > > > Feb 28 23:07:36 lifebook kernel: interrupt storm detected on "irq259:"; throttling interrupt source > > > > $ vmstat -i > > ... > > irq259: mskc0 11669511 3456 > > > > > > Looks very similar to this: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=164569 > > > > Any suggestions? > > Try disabling MSI and see whether that makes any difference. hw.msk.msi_disable is not recognized as a valid sysctl variable and I'm not sure about it having any effect whatsoever, but putting hw.msk.msi_disable=1 into /boot/loader.conf seems to have resulted in this: irq16: mskc0 uhci0 355402 884 that is, msk0 is now on irq16, but the freezes are still there: Mar 1 23:55:12 lifebook kernel: interrupt storm detected on "irq16:"; throttling interrupt source From owner-freebsd-stable@FreeBSD.ORG Thu Mar 1 21:55:23 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id D11EC106566B; Thu, 1 Mar 2012 21:55:22 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Thu, 1 Mar 2012 16:55:03 -0500 User-Agent: KMail/1.6.2 References: <20120227152238.GA2940@regency.nsu.ru> <20120301171125.GA61435@regency.nsu.ru> <201203011953.52600.hselasky@c2i.net> In-Reply-To: <201203011953.52600.hselasky@c2i.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203011655.05964.jkim@FreeBSD.org> Cc: Alexey Dokuchaev , Hans Petter Selasky Subject: Re: Resume broken in 8.3-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, 01 Mar 2012 21:55:23 -0000 On Thursday 01 March 2012 01:53 pm, Hans Petter Selasky wrote: > On Thursday 01 March 2012 18:11:25 Alexey Dokuchaev wrote: > > On Mon, Feb 27, 2012 at 10:22:38PM +0700, Alexey Dokuchaev wrote: > > > On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev wrote: > > > > I was mistaken, the latest kernel with working resume is from > > > > Jan 4 00:00 UTC, kernel from Jan 4 01:00 UTC does not allow > > > > my laptop to come back from zzz(8) successfully. It seems > > > > that offending change is rev. 1.9.2.5 of > > > > sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450). > > > > I've redone my bisecting, now suspending/resuming around at least > > ten times in console with zzz(8). I must apologize to rmacklem@, > > his commit has nothing to do with it. Apparently, the culprit is > > SVN rev 229370 on 2012-01-03 09:15:54Z by hselasky@, which > > (ironically enough) supposed to bring better support for USB > > controller suspend and resume. Kernel csuped and built before > > this date resumes just fine for me. However, the problem might > > lay deeper: disabling all USB modules (I traditionally run slim > > kernels with everything down to io/mem offloaded into modules) > > does not fix the hang, see below. Selectively disabling UHCI or > > EHCI does not make any difference either. > > > > Debugging of this issue is, however, complicated by the fact that > > doing "call doadump" results in "Dumping 68M:" message (similar > > problem was reported[1] by glebius@ back in 2004), and then > > nothing happens except for IDE led light-up and frozen debugger, > > which makes post-mortem analysis with kgdb(1) impossible. > > Setting up serial console (since it's a laptop, the only > > possibility for me right now is to use some noname USB adapter > > via uftdi(4)) works, but kernel GDB does not like it. Perhaps > > I'm just not passing 0x80 flag correctly, but > > hint.uftdi.0.flags="0x80" does not work. Is GDB backend > > impossible with USB serial adapters, or I am just doing it wrong? > > > > What strikes me most is that even with plain kbdmux(4) or > > atkdb(4) I still cannot resume, even on previous (before r229370) > > kernels (the earliest I've tried is from Jan 1 00:00 UTC). Any > > debugging hints or patches to try are highly appreciated. > > > > Thus far, the latest kernel where resume works (with USB stuff > > enabled) is from Jan 3 19:15 UTC. Hans Petter, do you have any > > ideas about it? > > Hi, > > The USB controllers should be reset after resume. > > Suspend is currently ASYNC. This might be one problem. > > Resume is also ASYNC, because we cannot block in the > device_resume() callback. > > Make sure no serial port adapters have open devices and are > blocking suspend and resume. > > What is output from usbconfig as root, before and after > suspend/resume ? It does not make a difference for me (i.e., usb suspend/resume still broken) but I think I found a typo: Index: sys/dev/usb/controller/usb_controller.c =================================================================== --- sys/dev/usb/controller/usb_controller.c (revision 232365) +++ sys/dev/usb/controller/usb_controller.c (working copy) @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm) USB_BUS_UNLOCK(bus); - bus_generic_shutdown(bus->bdev); + bus_generic_suspend(bus->bdev); usbd_enum_lock(udev); Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Thu Mar 1 23:52:29 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 68A17106564A; Thu, 1 Mar 2012 23:52:29 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 00CC31509EA; Thu, 1 Mar 2012 23:52:28 +0000 (UTC) Message-ID: <4F500BB9.4040307@FreeBSD.org> Date: Thu, 01 Mar 2012 15:52:25 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Steve Wills References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> In-Reply-To: <4F4ED889.2070608@FreeBSD.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org, "K. Macy" , =?UTF-8?B?eiBXxIVzaWtvd3NraQ==?= , Arnaud Lacombe , Alexander Leidinger , "Bjoern A. Zeeb" , current@FreeBSD.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Mar 2012 23:52:29 -0000 On 2/29/2012 6:01 PM, Steve Wills wrote: > On 02/29/12 13:17, K. Macy wrote: >> . >>> >>> I tried it, on both FreeBSD routers, web systems, and database >>> servers; all on 8.2+. It still causes massive instability. >>> Disabling the sysctl, and/or removing it from the kernel solved >>> the problems. > >> Routing I can believe, but I'm wondering how close attention you >> paid to the workload. There are CDN networks with high uptimes and >> shipping firewall products that use flowtable, so your mention of >> web systems forces makes me ask for specifics. > > > The failure I experienced was with web servers running 8.0 behind a F5 > load balancer in an HA setup. Whenever the failover happened, the web > servers would continue sending to the wrong MAC address, despite the > arp table updating. Disabling flowtable via the sysctl solved the > problem. Maybe Doug's failure was similar, maybe not, but I thought > I'd throw my $0.02 in. Yes, that was part of it. On the web and db systems we had what I can only describe as "general wackiness" with systems suddenly becoming unreachable, etc. This was with a moderately complex network setup with a combination of different VLANs, multiple interfaces, etc. The FreeBSD routers would just plain panic on a semi-regular interval. Removing flowtable made all this go away, and we've been quite stable since then. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 00:03:51 2012 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 4564F1065673; Fri, 2 Mar 2012 00:03:51 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id CAE4E8FC08; Fri, 2 Mar 2012 00:03:50 +0000 (UTC) Received: by iahk25 with SMTP id k25so1929969iah.13 for ; Thu, 01 Mar 2012 16:03:50 -0800 (PST) Received-SPF: pass (google.com: domain of kmacybsd@gmail.com designates 10.50.76.130 as permitted sender) client-ip=10.50.76.130; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kmacybsd@gmail.com designates 10.50.76.130 as permitted sender) smtp.mail=kmacybsd@gmail.com; dkim=pass header.i=kmacybsd@gmail.com Received: from mr.google.com ([10.50.76.130]) by 10.50.76.130 with SMTP id k2mr6773748igw.22.1330646630369 (num_hops = 1); Thu, 01 Mar 2012 16:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kzTX++I0LTVg7SOToLhoHX9nWX3wU21PLqx78FbMsGU=; b=GeE9uf+uUiMnfqezw/mC/NTv4GacfHhul5+8PbCFssgi0NYdyOquZYknGOybSJFPjs /ImVISabj+8WmFSCxvosGjbgq3ulXTl/q/tr1T8uEKs5HwKFw280Yby5CMpkRH2edRUx X3hOByP50W6FG8RzQMzeWKVEfpCPXPex2a+IIVB7K5ArmoH/jcvENZ8TFoldklnIl2eV RQdq59NYwrQCdSywKd4T+6+qTUs7Q3RQOMJtoET5G+6veE/hsKnM2YYY+gER8lF+7TCi iOBfsZeIYf/kqcW5pDRfDSGTpyYFcTE7gp69tDd9Yqe6fou4whkXcgHOR7M/jiRLvzBU jlaQ== MIME-Version: 1.0 Received: by 10.50.76.130 with SMTP id k2mr5550140igw.22.1330646630305; Thu, 01 Mar 2012 16:03:50 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.50.134.106 with HTTP; Thu, 1 Mar 2012 16:03:50 -0800 (PST) In-Reply-To: <4F500BB9.4040307@FreeBSD.org> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> Date: Fri, 2 Mar 2012 01:03:50 +0100 X-Google-Sender-Auth: mxpvkgaL8LsVi87RMzQ2xVdcHzE Message-ID: From: "K. Macy" To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, current@freebsd.org, Steve Wills , =?ISO-8859-2?Q?z_W=B1sikowski?= , Arnaud Lacombe , Alexander Leidinger , "Bjoern A. Zeeb" Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 00:03:51 -0000 > Yes, that was part of it. On the web and db systems we had what I can > only describe as "general wackiness" with systems suddenly becoming > unreachable, etc. This was with a moderately complex network setup with > a combination of different VLANs, multiple interfaces, etc. The FreeBSD > routers would just plain panic on a semi-regular interval. Removing > flowtable made all this go away, and we've been quite stable since then. > I understand the switch. Uptime is important in any production network. However, it seems like it may have been too easy to turn it off because no one has made any effort to help me debug the issues. By analogy your guidance for ports usability problems would be to install Ubuntu. Cheers From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 00:12:43 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8F441065672; Fri, 2 Mar 2012 00:12:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 508C18FC16; Fri, 2 Mar 2012 00:12:42 +0000 (UTC) Received: by wibhn6 with SMTP id hn6so367609wib.13 for ; Thu, 01 Mar 2012 16:12:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=O2wMNq81BkXpFRG0pCcmTDHAhwYcroxZMisQ3GFZ7cU=; b=uIMr6sWexbCE4M4jHBiRjCnvAYB4OhxBvHGT2q+PDGhr2+lMrXdXE16BTKksVrvDL2 E4/2y4j5X/1yg0cV5FDFODcFKFnU41yoQVcLw1+/Qs8BqacU2/4LiUkBX2Re9L2zJzjn 32WTHEFb67UJBftastHl9dqO0YBrfweG3sXm2CXQvwPz07rSyzIu/yo9tV/JVTaioO/J tc0xj4poNBjDK0LbTpUY/8QWnFEMQXIxJ5ggiUqPH0k2CEcI66GWDHnte2rF99OvHYW7 w2I2OrE3ykcjHH+JQo1H6nwDkR5mS9whla6bUSF73BPhpYJqXXpVPWr1q00RjqR7IVBD a6oQ== MIME-Version: 1.0 Received: by 10.180.96.8 with SMTP id do8mr31950wib.21.1330647162270; Thu, 01 Mar 2012 16:12:42 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.198.81 with HTTP; Thu, 1 Mar 2012 16:12:42 -0800 (PST) In-Reply-To: <2F3C6FA2-4045-4022-A317-42CF616A84A8@gmail.com> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <2F3C6FA2-4045-4022-A317-42CF616A84A8@gmail.com> Date: Thu, 1 Mar 2012 16:12:42 -0800 X-Google-Sender-Auth: 0u3V_zw9pidgyjjxL09VlI8H1ZE Message-ID: From: Adrian Chadd To: Nikolay Denev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Leidinger , stable@freebsd.org, current@freebsd.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 00:12:44 -0000 SunOS 4.x users will love you. :-) Adrian On 1 March 2012 02:27, Nikolay Denev wrote: > On Feb 21, 2012, at 3:35 PM, Alexander Leidinger wrote: > >> Hi, >> >> I created a kernel config for i386/amd64 (should work on -current and 9.= x) and a suitable loader.conf which: >> - tries to provide as much features as GENERIC (I lost one or two disk >> =A0 controllers, they are not available as a module... or I didn't find >> =A0 them) >> - incorporates some more features based upon a poll on stable@ >> =A0 (see below) >> - loads as much as possible as a module >> >> I've compile-tested them on i386 and amd64, but I didn't had time yet to= give it a try on a spare machine. I may get some time next week to test (i= 386 only). It would be nice if someone could help testing: >> - compile the kernel >> - make _sure_ you have a way to recover the system in case >> =A0 the new kernel+loader.conf fails >> - verify that the example loader.conf contains all devices >> =A0 which are important for you >> - copy the example loader.conf to /boot/loader.conf >> - give it a try >> >> You can download from >> =A0http://www.Leidinger.net/FreeBSD/current-patches/ >> The files are >> =A0- i386_SMALL >> =A0- i386_SMALL_loader.conf >> =A0- amd64_SMALL >> =A0- amd64_SMALL_loader.conf >> I didn't provide direct links for eqch one on purpose. If you do not kno= w how to recover a system with an unsuitable loader.conf, don't give this a= try (you could check a diff between GENERIC and SMALL, and make sure all r= emoved devices which are imporant for you are in the loader.conf). They sho= uld work on -current and on 9.x, for 8.x I'm not sure if it woll work witho= ut removing some stuff (GENERIC on 8.x comes without some more debugging op= tions, make sure you don't get surprised by them, but those may not be the = only differences). >> >> I didn't use the name MODULAR on purpose, I've chosen a name where the f= irst letter does not yet exist in the kernel config directory, to make tab-= completion more easy. If you are not happy with the name, keep your opinion= for yourself please, until after you tested this on a (maybe virtual) syst= em. >> >> The loader.conf was generated with a script from a diff between GENERIC = and SMALL, if there's a name mismatch between the config-name and the modul= e-name, the script may have missed the module (I added some missing sound m= odules, but I may have overlooked something). You better double-check befor= e giving it a try. The loader.conf is also supposed to disable some feature= s (at the end of the file) which are new compared to what is in GENERIC, if= the particular feature could cause a change in behavior. >> >> The new stuff in the kernel config compared to GENERIC is (in order of n= umber of requests from users): >> - IPSEC (+ device enc + IPSEC_NAT_T) >> - ALTQ >> - SW_WATCHDOG >> - QUOTA >> - IPSTEALTH (disabled in loader.conf) >> - IPFIREWALL_FORWARD (touches every packet, power users which need >> =A0 a bigger PPS but not this feature can recompile the kernel, >> =A0 discussed with julian@) >> - FLOWTABLE (disabled in loader.conf) >> - BPF_JITTER >> >> In the poll there where some more options requested, but most of them ca= n be handled via the loader or sysctl (e.g. the firewalls can be loaded as = modules). For some of them I added some comments at the end of the SMALL co= nfig to make it more easy to find the correct way of configuring them. Doc-= committers may want to have a look, maybe there's an opportunity to improve= existing documentation. >> >> I'm interested in success reports, failure reports, and reports about mi= ssing stuff in loader.conf (mainly compared to the devices available in GEN= ERIC, but missing stuff which could help getting a system installed and boo= ted is welcome even if what you propose is not in GENERIC). >> >> Bye, >> Alexander. >> >> -- >> >> http://www.Leidinger.net =A0 =A0Alexander @ Leidinger.net: PGP ID =3D B0= 063FE7 >> http://www.FreeBSD.org =A0 =A0 =A0 netchild @ FreeBSD.org =A0: PGP ID = =3D 72077137 >> > > > Just an idea : Ship FreeBSD with all the kernel object files > (even compile different versions of them, let's say networking with IPFOR= WARD and networking without), > and then let the user relink the kernel with some shell script. > This way freebsd-update can binary update the object files, > and then relink the users's kernel. > This of course will probably need some infrastructure work to make it pos= sible. > > P.S.: As I said, just an idea off the top of my head :) > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 01:05:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BACAA106564A for ; Fri, 2 Mar 2012 01:05:58 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 857DC8FC16 for ; Fri, 2 Mar 2012 01:05:58 +0000 (UTC) Received: by daec6 with SMTP id c6so1482411dae.13 for ; Thu, 01 Mar 2012 17:05:58 -0800 (PST) Received-SPF: pass (google.com: domain of pyunyh@gmail.com designates 10.68.220.197 as permitted sender) client-ip=10.68.220.197; Authentication-Results: mr.google.com; spf=pass (google.com: domain of pyunyh@gmail.com designates 10.68.220.197 as permitted sender) smtp.mail=pyunyh@gmail.com; dkim=pass header.i=pyunyh@gmail.com Received: from mr.google.com ([10.68.220.197]) by 10.68.220.197 with SMTP id py5mr9547621pbc.93.1330650358238 (num_hops = 1); Thu, 01 Mar 2012 17:05:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=QGCaZwQKLgcD9/MRbLA8iEufr4Xkh5WPgg8yqEmUii4=; b=I4trHhsj01BVQcWTTHY9YX1NpXjxdXeeYGrcHaE2oUmejpcNVck+i+f6DpD/WGksg0 aqIsE5R76xdr/gKeDSs9fYEcfEeaOz8f0Sxhk5JJmLEa62JGvIL1VsP0ls0agFWMseMI S2GV+u+BXWvx+r3UBcWYCSJxA4aIrflOv7B8IMz16F4tkAJfZ1xBuF6wQfuIj7wcvyqa 54QhiC1QJ6hbrg9GqWKk56vT6damW2f/87X4c7hGli1QSxBMHtjKmHa7rz/cJI/BzzeI U57OxcQhmkTza2TZi5J8JMuDG6eWGumSg5rcVaOIcAPuDCAkx13UAJFR86+7msdVTS9b n6GA== Received: by 10.68.220.197 with SMTP id py5mr7871632pbc.93.1330650358139; Thu, 01 Mar 2012 17:05:58 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id z10sm3446296pbq.55.2012.03.01.17.05.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Mar 2012 17:05:57 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 02 Mar 2012 10:05:54 -0800 From: YongHyeon PYUN Date: Fri, 2 Mar 2012 10:05:54 -0800 To: Pavel Gorshkov Message-ID: <20120302180554.GA1632@michelle.cdnetworks.com> References: <20120228210329.GA2741@localhost> <20120302012955.GC1685@michelle.cdnetworks.com> <20120301211356.GA2603@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120301211356.GA2603@localhost> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: msk0: interrupt storm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 01:05:58 -0000 On Fri, Mar 02, 2012 at 01:13:56AM +0400, Pavel Gorshkov wrote: > On Thu, Mar 01, 2012 at 05:29:55PM -0800, YongHyeon PYUN wrote: > > On Wed, Feb 29, 2012 at 01:03:29AM +0400, Pavel Gorshkov wrote: > > > My laptop running 9.0-RELEASE/amd64/GENERIC freezes and > > > (sometimes) unfreezes intermittently, logging the following: > > > > > > Feb 28 23:07:36 lifebook kernel: interrupt storm detected on "irq259:"; throttling interrupt source > > > > > > $ vmstat -i > > > ... > > > irq259: mskc0 11669511 3456 > > > > > > > > > Looks very similar to this: > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=164569 > > > > > > Any suggestions? > > > > Try disabling MSI and see whether that makes any difference. > > hw.msk.msi_disable is not recognized as a valid sysctl variable > and I'm not sure about it having any effect whatsoever, but hw.msk.msk_disable is a loader tunable so it can't be set after boot. See msk(4) for more information. > putting hw.msk.msi_disable=1 into /boot/loader.conf seems to have > resulted in this: > > irq16: mskc0 uhci0 355402 884 > > that is, msk0 is now on irq16, but the freezes are still there: > > Mar 1 23:55:12 lifebook kernel: interrupt storm detected on "irq16:"; throttling interrupt source Still have no idea. Would you post dmesg output? If you know how to reproduce the issue, let me know. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 07:50:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8B87106564A for ; Fri, 2 Mar 2012 07:50:02 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1FF8FC08 for ; Fri, 2 Mar 2012 07:50:01 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 243783121; Fri, 02 Mar 2012 08:49:58 +0100 From: Hans Petter Selasky To: "Jung-uk Kim" Date: Fri, 2 Mar 2012 08:48:13 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.3-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <20120227152238.GA2940@regency.nsu.ru> <201203011953.52600.hselasky@c2i.net> <201203011655.05964.jkim@FreeBSD.org> In-Reply-To: <201203011655.05964.jkim@FreeBSD.org> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203020848.13410.hselasky@c2i.net> Cc: Alexey Dokuchaev , freebsd-stable@freebsd.org Subject: Re: Resume broken in 8.3-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: Fri, 02 Mar 2012 07:50:03 -0000 On Thursday 01 March 2012 22:55:03 Jung-uk Kim wrote: > On Thursday 01 March 2012 01:53 pm, Hans Petter Selasky wrote: > > On Thursday 01 March 2012 18:11:25 Alexey Dokuchaev wrote: > > > On Mon, Feb 27, 2012 at 10:22:38PM +0700, Alexey Dokuchaev wrote: > > > > On Mon, Feb 27, 2012 at 09:28:15PM +0700, Alexey Dokuchaev > > wrote: > > > > > I was mistaken, the latest kernel with working resume is from > > > > > Jan 4 00:00 UTC, kernel from Jan 4 01:00 UTC does not allow > > > > > my laptop to come back from zzz(8) successfully. It seems > > > > > that offending change is rev. 1.9.2.5 of > > > > > sys/nfsclient/nfs_krpc.c by rmacklem@ (SVN rev 229450). > > > > > > I've redone my bisecting, now suspending/resuming around at least > > > ten times in console with zzz(8). I must apologize to rmacklem@, > > > his commit has nothing to do with it. Apparently, the culprit is > > > SVN rev 229370 on 2012-01-03 09:15:54Z by hselasky@, which > > > (ironically enough) supposed to bring better support for USB > > > controller suspend and resume. Kernel csuped and built before > > > this date resumes just fine for me. However, the problem might > > > lay deeper: disabling all USB modules (I traditionally run slim > > > kernels with everything down to io/mem offloaded into modules) > > > does not fix the hang, see below. Selectively disabling UHCI or > > > EHCI does not make any difference either. > > > > > > Debugging of this issue is, however, complicated by the fact that > > > doing "call doadump" results in "Dumping 68M:" message (similar > > > problem was reported[1] by glebius@ back in 2004), and then > > > nothing happens except for IDE led light-up and frozen debugger, > > > which makes post-mortem analysis with kgdb(1) impossible. > > > Setting up serial console (since it's a laptop, the only > > > possibility for me right now is to use some noname USB adapter > > > via uftdi(4)) works, but kernel GDB does not like it. Perhaps > > > I'm just not passing 0x80 flag correctly, but > > > hint.uftdi.0.flags="0x80" does not work. Is GDB backend > > > impossible with USB serial adapters, or I am just doing it wrong? > > > > > > What strikes me most is that even with plain kbdmux(4) or > > > atkdb(4) I still cannot resume, even on previous (before r229370) > > > kernels (the earliest I've tried is from Jan 1 00:00 UTC). Any > > > debugging hints or patches to try are highly appreciated. > > > > > > Thus far, the latest kernel where resume works (with USB stuff > > > enabled) is from Jan 3 19:15 UTC. Hans Petter, do you have any > > > ideas about it? > > > > Hi, > > > > The USB controllers should be reset after resume. > > > > Suspend is currently ASYNC. This might be one problem. > > > > Resume is also ASYNC, because we cannot block in the > > device_resume() callback. > > > > Make sure no serial port adapters have open devices and are > > blocking suspend and resume. > > > > What is output from usbconfig as root, before and after > > suspend/resume ? > > It does not make a difference for me (i.e., usb suspend/resume still > broken) but I think I found a typo: > > Index: sys/dev/usb/controller/usb_controller.c > =================================================================== > --- sys/dev/usb/controller/usb_controller.c (revision 232365) > +++ sys/dev/usb/controller/usb_controller.c (working copy) > @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm) > > USB_BUS_UNLOCK(bus); > > - bus_generic_shutdown(bus->bdev); > + bus_generic_suspend(bus->bdev); > > usbd_enum_lock(udev); > > Jung-uk Kim Hi, It should be shutdown, because suspend in this case is something else. USB suspend resume works like this: At suspend we reset and stop all controllers. At resume we reset and start all controllers again. If the reset doesn't work, then try to enable hw.usb.uhub.debug=15 and see what port change events are coming. If cfg=255 in usbconfig, then something is wrong. Currently suspend and resume is ASYNC, so that means we are not waiting for the actual HC reset to complete. --HPS From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 08:46:03 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 82F25106566B; Fri, 2 Mar 2012 08:46:03 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-197-151.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 162A31509DD; Fri, 2 Mar 2012 08:46:03 +0000 (UTC) Message-ID: <4F5088CA.1090108@FreeBSD.org> Date: Fri, 02 Mar 2012 00:46:02 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120224 Thunderbird/10.0.2 MIME-Version: 1.0 To: "K. Macy" References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, current@freebsd.org, Steve Wills , =?UTF-8?B?eiBXxIVzaWtvd3NraQ==?= , Arnaud Lacombe , Alexander Leidinger , "Bjoern A. Zeeb" Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 08:46:03 -0000 On 03/01/2012 16:03, K. Macy wrote: > I understand the switch. Uptime is important in any production > network. However, it seems like it may have been too easy to turn it > off because no one has made any effort to help me debug the issues. By > analogy your guidance for ports usability problems would be to install > Ubuntu. Apparently you've missed all the times that I've given that exact advice. :) But your analogy is severely flawed. Flowtable was an experimental feature that theoretically might have increased performance for some work flows, but turned out to be fatally flawed. The ports system is an essential part of the FreeBSD operating *system*, depended on by virtually 100% of FreeBSD users. Users don't have any obligation to help us debug new/experimental features. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 08:50:01 2012 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 B29331065672 for ; Fri, 2 Mar 2012 08:50:01 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2B1D98FC1D for ; Fri, 2 Mar 2012 08:50:01 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 36993153434 for ; Fri, 2 Mar 2012 09:50:00 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtjjMeIL5lIj for ; Fri, 2 Mar 2012 09:49:59 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id 54C57153433 for ; Fri, 2 Mar 2012 09:49:59 +0100 (CET) Message-ID: <4F5089B7.2070103@withagen.nl> Date: Fri, 02 Mar 2012 09:49:59 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "stable@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Disk disconnects, with immediate reconnect X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 08:50:01 -0000 On my ZFS server: (info on: http://www.tegenbosch28.nl/FreeBSD/systems/ZFS/ ) +ahcich4: Timeout on slot 23 port 0 +ahcich4: is 00000000 cs 00800000 ss 00000000 rs 00800000 tfd c0 serr 00000000 cmd 0004d717 +(ada3:ahcich4:0:0:0): lost device +(ada3:ahcich4:0:0:0): removing device entry +ada3 at ahcich4 bus 0 scbus5 target 0 lun 0 +ada3: ATA-8 SATA 2.x device +ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) +ada3: Command Queueing enabled +ada3: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) The reconnect occurs immediately after the disconnect. I had some discussions with Jeremy Chadwick, so below are the smartctl stats. The system was not particularly busy at that moment. Is this disk failure, or why other did it disconnect. --WjW Smartctl output: [~wjw] root@zfs.digiware.nl# smartctl -A /dev/ada3 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 117 099 006 Pre-fail Always - 167678942 3 Spin_Up_Time 0x0003 100 100 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 35 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 13 7 Seek_Error_Rate 0x000f 087 060 030 Pre-fail Always - 523895462 9 Power_On_Hours 0x0032 085 085 000 Old_age Always - 13172 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 35 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 1 189 High_Fly_Writes 0x003a 071 071 000 Old_age Always - 29 190 Airflow_Temperature_Cel 0x0022 067 047 045 Old_age Always - 33 (Min/Max 32/33) 194 Temperature_Celsius 0x0022 033 053 000 Old_age Always - 33 (0 17 0 0 0) 195 Hardware_ECC_Recovered 0x001a 048 035 000 Old_age Always - 167678942 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 3 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 3 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 95747705942900 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 656030587 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 2585367414 [~wjw] root@zfs.digiware.nl# smartctl -l devstat /dev/ada3 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net Device Statistics (GP Log 0x04) not supported [~wjw] root@zfs.digiware.nl# smartctl -l sataphy /dev/ada3 smartctl 5.42 2011-10-20 r3458 [FreeBSD 8.2-STABLE amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 0x000a 2 1 Device-to-host register FISes sent due to a COMRESET 0x0001 2 0 Command failed due to ICRC error 0x0003 2 0 R_ERR response for device-to-host data FIS 0x0004 2 0 R_ERR response for host-to-device data FIS 0x0006 2 0 R_ERR response for device-to-host non-data FIS 0x0007 2 0 R_ERR response for host-to-device non-data FIS From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 08:51:01 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F5EB1065686; Fri, 2 Mar 2012 08:51:01 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (r2b9.nsu.ru [212.192.164.39]) by mx1.freebsd.org (Postfix) with ESMTP id 26B018FC15; Fri, 2 Mar 2012 08:51:00 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1S3OBk-0007qM-Ah; Fri, 02 Mar 2012 15:50:08 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q228oIq9041819; Fri, 2 Mar 2012 15:50:18 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q228oDUZ041790; Fri, 2 Mar 2012 15:50:13 +0700 (NOVT) (envelope-from danfe) Date: Fri, 2 Mar 2012 15:50:12 +0700 From: Alexey Dokuchaev To: Jung-uk Kim Message-ID: <20120302085012.GA25811@regency.nsu.ru> References: <20120227152238.GA2940@regency.nsu.ru> <20120301171125.GA61435@regency.nsu.ru> <201203011953.52600.hselasky@c2i.net> <201203011655.05964.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201203011655.05964.jkim@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@FreeBSD.org, Hans Petter Selasky Subject: Re: Resume broken in 8.3-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: Fri, 02 Mar 2012 08:51:01 -0000 On Thu, Mar 01, 2012 at 04:55:03PM -0500, Jung-uk Kim wrote: > On Thursday 01 March 2012 01:53 pm, Hans Petter Selasky wrote: > > What is output from usbconfig as root, before and after > > suspend/resume ? Before suspend (just after reboot, this output is identical to pre/post SVN r229370): ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.2: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON After resume (kernel from Jan 1): all lines are the same, except that last two lines are swapped (ugen3.2 is listed before ugen0.2). Presence of US232B does not affect behavior; ugen3.2 is built-in finger print scanner, and since in USB2 there is no separate ugen(4), I don't know how to selectively disable it. Man page for ugen(4) however exists. :-) > It does not make a difference for me (i.e., usb suspend/resume still > broken) but I think I found a typo: > > --- sys/dev/usb/controller/usb_controller.c (revision 232365) > +++ sys/dev/usb/controller/usb_controller.c (working copy) > @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm) > > USB_BUS_UNLOCK(bus); > > - bus_generic_shutdown(bus->bdev); > + bus_generic_suspend(bus->bdev); > > usbd_enum_lock(udev); Same thing here, does not seem to improve anything. It might suspend, resume (with keyboard working), then die on next suspend completely. Or it may die on the first suspend (without suspending -- fans are spinning, screen is black and no response to anything except hard power-off), this actually happens more often. ./danfe P.S. Also, doing "ps" in debugger shows that acpiconf(8) is running in the userland upon resume (and hang). Not sure if it helps or not though. From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 08:57:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 132231065673 for ; Fri, 2 Mar 2012 08:57:30 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (r2b9.nsu.ru [212.192.164.39]) by mx1.freebsd.org (Postfix) with ESMTP id A14658FC1A for ; Fri, 2 Mar 2012 08:57:29 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1S3OIo-0000MP-4l; Fri, 02 Mar 2012 15:57:26 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q228vaqm044430; Fri, 2 Mar 2012 15:57:36 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q228v3C5044348; Fri, 2 Mar 2012 15:57:03 +0700 (NOVT) (envelope-from danfe) Date: Fri, 2 Mar 2012 15:57:03 +0700 From: Alexey Dokuchaev To: Hans Petter Selasky Message-ID: <20120302085702.GA42866@regency.nsu.ru> References: <20120227152238.GA2940@regency.nsu.ru> <201203011953.52600.hselasky@c2i.net> <201203011655.05964.jkim@FreeBSD.org> <201203020848.13410.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201203020848.13410.hselasky@c2i.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: Resume broken in 8.3-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: Fri, 02 Mar 2012 08:57:30 -0000 On Fri, Mar 02, 2012 at 08:48:13AM +0100, Hans Petter Selasky wrote: > If the reset doesn't work, then try to enable hw.usb.uhub.debug=15 and see > what port change events are coming. I don't see such oid hw.usb.uhub.debug. Perhaps it should be hw.usb.debug? > If cfg=255 in usbconfig, then something is wrong. It seems they are all zeros, per the output I've sent earlier. ./danfe From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 09:09:46 2012 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 329A31065677; Fri, 2 Mar 2012 09:09:46 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id CD8768FC0C; Fri, 2 Mar 2012 09:09:45 +0000 (UTC) Received: from outgoing.leidinger.net (p5796C459.dip.t-dialin.net [87.150.196.89]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 356A4844752; Fri, 2 Mar 2012 10:09:28 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 788991496; Fri, 2 Mar 2012 10:09:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1330679365; bh=zQNIFlsistGcmecdBt6mC9IpPPEA08rQRcecGDstFJs=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=dciQtq/bpykH06KTnmTkrRZ3qB8nRBL3Zi7JUKQdXzWe20wpivZHpqgoHRUhna1n2 x+SrqG4tBDvp1iVF848FeHeq4LNKv2wI0L81KchTyLh6QidWAHzbahgz+kGsSIqi27 WD/WHiCvf7bJSZI0E1RYSKDugmMf3MBnKh62zUXE69weVFAjPivx59atcouV3CpHFx Qo2CupYP+EBYseZ4hvrJ6mSjBOEluNqANg3G1c1Bk2gc9VOrpkJL8+Jirz+7y8Mw8C K275eu6TB2ExPsaLYZ1PHXtf5IyH/XLAF4Nn6s3DbMBXYQfp6RAJkNRsyb6JNQXqZP RjTvZsX+MksXQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q2299O7m029742; Fri, 2 Mar 2012 10:09:24 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 02 Mar 2012 10:09:24 +0100 Date: Fri, 02 Mar 2012 10:09:24 +0100 Message-ID: <20120302100924.Horde.vnzeDZjmRSRPUI5EsjnnPZA@webmail.leidinger.net> From: Alexander Leidinger To: Slawa Olhovchenkov References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <20120301145834.GH97848@zxy.spb.ru> In-Reply-To: <20120301145834.GH97848@zxy.spb.ru> User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 356A4844752.AED6C X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.599, required 6, autolearn=disabled, AWL -0.49, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1331284170.16736@fM9LpbdC4+Au0DoTo5O7+g X-EBL-Spam-Status: No Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 09:09:46 -0000 Quoting Slawa Olhovchenkov (from Thu, 1 Mar 2012 18:58:34 +0400): > On Tue, Feb 21, 2012 at 02:35:37PM +0100, Alexander Leidinger wrote: > >> You can download from >> http://www.Leidinger.net/FreeBSD/current-patches/ >> The files are >> - i386_SMALL >> - i386_SMALL_loader.conf >> - amd64_SMALL >> - amd64_SMALL_loader.conf > > Where SCSI disk/etc? CAM and ATA are loaded as modules in the loader.conf (except for two SCSI controllers, which are not available as modules). I may have missed to load a module, or I may not load in the correct order (which would be a bug of missing/wrong dependencies in some modules). I'm investigating a corresponding report with error messages. Bye, Alexander. -- If you analyse anything, you destroy it. -- Arthur Miller http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 09:23:39 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48671106566B; Fri, 2 Mar 2012 09:23:39 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id F17E58FC24; Fri, 2 Mar 2012 09:23:38 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1S3OiX-0007I0-7O; Fri, 02 Mar 2012 13:24:01 +0400 Date: Fri, 2 Mar 2012 13:24:01 +0400 From: Slawa Olhovchenkov To: Alexander Leidinger Message-ID: <20120302092401.GP52973@zxy.spb.ru> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <20120301145834.GH97848@zxy.spb.ru> <20120302100924.Horde.vnzeDZjmRSRPUI5EsjnnPZA@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120302100924.Horde.vnzeDZjmRSRPUI5EsjnnPZA@webmail.leidinger.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 09:23:39 -0000 On Fri, Mar 02, 2012 at 10:09:24AM +0100, Alexander Leidinger wrote: > Quoting Slawa Olhovchenkov (from Thu, 1 Mar 2012 > 18:58:34 +0400): > > > On Tue, Feb 21, 2012 at 02:35:37PM +0100, Alexander Leidinger wrote: > > > >> You can download from > >> http://www.Leidinger.net/FreeBSD/current-patches/ > >> The files are > >> - i386_SMALL > >> - i386_SMALL_loader.conf > >> - amd64_SMALL > >> - amd64_SMALL_loader.conf > > > > Where SCSI disk/etc? > > CAM and ATA are loaded as modules in the loader.conf (except for two > SCSI controllers, which are not available as modules). I may have > missed to load a module, or I may not load in the correct order (which > would be a bug of missing/wrong dependencies in some modules). I'm > investigating a corresponding report with error messages. Not controllers, peripherals: disk/tape/etc device scbus # SCSI bus (required for ATA/SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct ATA/SCSI access) device ses # SCSI Environmental Services (and SAF-TE) From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 09:25:32 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 335451065679 for ; Fri, 2 Mar 2012 09:25:32 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id B87C68FC08 for ; Fri, 2 Mar 2012 09:25:31 +0000 (UTC) Received: from outgoing.leidinger.net (p5796C459.dip.t-dialin.net [87.150.196.89]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 30511844754; Fri, 2 Mar 2012 10:25:17 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 6409E1499; Fri, 2 Mar 2012 10:25:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1330680314; bh=5QyKGocFBu/2XKhkfJ4/E8j3NM6lYfhPLHjD+SsgpSQ=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=FyCEmMVWETd0dg2fsmf6DKAsi/ftsw/56fWc9HYHOwjThkqYyqkq+Z41OSsrGF3Gt WnLvycrl1hZH0GDkOE0RDxRJ8VAsp83rqe+17Wyeg1L2WvqMV9VLsbHwbZYfaOFn0n CqQqPrMZlcauw4SP2AL+jBRAjcN//6CK1Smk8S8SyxH7eTFe//BwxGtk3aSK82Ixxh OI47pVx6yXGFmRI3NnBlTNb5ilIwwekkoJTT4/5oNx+2eyyaOhDdBtI+yf73k7Awge bq1Vvopo4JPHaVrL9XuIWZD4YWKYWweNaYS45zh87j9lF3BLK4io4FG7/gGSsOmmdC y67haqUhmodnw== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q229P9sF030600; Fri, 2 Mar 2012 10:25:09 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 02 Mar 2012 10:25:09 +0100 Date: Fri, 02 Mar 2012 10:25:09 +0100 Message-ID: <20120302102509.Horde.6uPSdpjmRSRPUJH1lHEHc3A@webmail.leidinger.net> From: Alexander Leidinger To: Slawa Olhovchenkov References: <1330081612.13430.39.camel@pow> <20120227181436.GA49667@server.vk2pj.dyndns.org> <20120301142826.GG97848@zxy.spb.ru> In-Reply-To: <20120301142826.GG97848@zxy.spb.ru> User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 30511844754.AF00A X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.63, required 6, autolearn=disabled, AWL -0.52, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1331285118.98985@gGJ43yjbyPyQdVSP2GBu5Q X-EBL-Spam-Status: No Cc: freebsd-fs@freebsd.org, team@hybrid-logic.co.uk, Luke Marsden , "freebsd-stable@freebsd.org" , Peter Jeremy Subject: Re: Another ZFS ARC memory question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 09:25:32 -0000 Quoting Slawa Olhovchenkov (from Thu, 1 Mar 2012 18:28:26 +0400): > On Tue, Feb 28, 2012 at 05:14:37AM +1100, Peter Jeremy wrote: > >> > * what is the community's advice for production machines running >> > ZFS on FreeBSD, is manually limiting the ARC cache (to ensure >> > that there's enough actually free memory to handle a spike in >> > application memory usage) the best solution to this >> > spike-in-memory-means-crash problem? >> >> Are you swapping onto a ZFS vdev? If so, change back to a raw (or >> geom) device - swapping to ZFS is known to be problematic. If you > > I see kernel stuck when swapping to ZFS. This is only known problem? This is a known problem. Don't use swap on a zpool. If you want fault tollerance use gmirror for the swap paritions instead (make sure the swap partition does end _before_ the last sector of the disk in this case). Bye, Alexander. -- As of next Thursday, UNIX will be flushed in favor of TOPS-10. Please update your programs. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 10:16:20 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5811C1065672; Fri, 2 Mar 2012 10:16:20 +0000 (UTC) (envelope-from luke-lists@hybrid-logic.co.uk) Received: from hybrid-sites.com (ns226322.hybrid-sites.com [176.31.229.137]) by mx1.freebsd.org (Postfix) with ESMTP id 009AE8FC18; Fri, 2 Mar 2012 10:16:19 +0000 (UTC) Received: from [127.0.0.1] (helo=ewes) by hybrid-sites.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1S3PWz-000LoP-Mg; Fri, 02 Mar 2012 10:16:15 +0000 Received: from [176.31.225.127] (helo=ewes by ns226322.hybrid-sites.com with esmtp (Hybrid Web Cluster distributed mail proxy) (envelope-from ); Fri, 02 Mar 2012 10:16:09 -0000 Received: from [78.105.122.99] (helo=[192.168.1.23] by ns225413.hybrid-sites.com with esmtp (Hybrid Web Cluster distributed mail proxy) (envelope-from ); Fri, 02 Mar 2012 10:16:09 -0000 From: Luke Marsden To: Alexander Leidinger In-Reply-To: <20120302102509.Horde.6uPSdpjmRSRPUJH1lHEHc3A@webmail.leidinger.net> References: <1330081612.13430.39.camel@pow> <20120227181436.GA49667@server.vk2pj.dyndns.org> <20120301142826.GG97848@zxy.spb.ru> <20120302102509.Horde.6uPSdpjmRSRPUJH1lHEHc3A@webmail.leidinger.net> Content-Type: text/plain; charset="UTF-8" Date: Fri, 02 Mar 2012 10:16:06 +0000 Message-ID: <1330683366.3819.20.camel@pow> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Spam-bar: + Cc: freebsd-fs@freebsd.org, team@hybrid-logic.co.uk, "freebsd-stable@freebsd.org" , Peter Jeremy , Slawa Olhovchenkov Subject: Re: Another ZFS ARC memory question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 10:16:20 -0000 On Fri, 2012-03-02 at 10:25 +0100, Alexander Leidinger wrote: > Quoting Slawa Olhovchenkov (from Thu, 1 Mar 2012 > 18:28:26 +0400): > > > On Tue, Feb 28, 2012 at 05:14:37AM +1100, Peter Jeremy wrote: > > > >> > * what is the community's advice for production machines running > >> > ZFS on FreeBSD, is manually limiting the ARC cache (to ensure > >> > that there's enough actually free memory to handle a spike in > >> > application memory usage) the best solution to this > >> > spike-in-memory-means-crash problem? > >> > >> Are you swapping onto a ZFS vdev? We are not swapping onto a ZFS vdev (we've been down that road and know it's a bad idea). Our issue is primarily with ARC cache eviction not happening fast enough or at all when there is a spike in memory usage, causing machines to hang. We are presently working around it by limiting arc_max to 4G on our 24G RAM production boxes (which seems like a massive waste of performance) and by doing very careful/aggressive application level management of memory usage to ensure stability (limits.conf didn't work for us, so we rolled our own). A better solution would be welcome, though, so that we can utilise all the free memory we're presently keeping around as a safety margin - ideally it would be used as ARC cache. Two more questions, again wrt 8.2-RELEASE: 1. Is it expected that with a 4G limited arc_max value that we should see wired memory usage around 7-8G? I understand that the kernel has to use some memory, but really 3-4G of non-ARC data? 2. We have some development machines with only 3G of RAM. Previously they had no arc_max set and were left to tune themselves. They were quite unstable. Now we've set arc_max to 256M but things have got worse: we've seen a disk i/o big performance hit (untarring a ports tarball now takes 20 minutes), and wired memory usage is up around 2.5GB, the machines are swapping a lot, and crashing more frequently. Follows is arc_summary.pl from one of the troubled dev machines showing the ARC using 500% of the memory it should be. Also uname follows. My second question is: have there been fixes between 8.2-RELEASE and 8.3-BETA1 or 9.0-RELEASE which solve this ARC over-usage problem? hybrid@node5:~$ ./arc_summary.pl ------------------------------------------------------------------------ ZFS Subsystem Report Fri Mar 2 09:55:00 2012 ------------------------------------------------------------------------ System Memory: 8.92% 264.89 MiB Active, 6.43% 190.75 MiB Inact 80.91% 2.35 GiB Wired, 1.97% 58.46 MiB Cache 1.74% 51.70 MiB Free, 0.03% 864.00 KiB Gap Real Installed: 3.00 GiB Real Available: 99.56% 2.99 GiB Real Managed: 97.04% 2.90 GiB Logical Total: 3.00 GiB Logical Used: 90.20% 2.71 GiB Logical Free: 9.80% 300.91 MiB Kernel Memory: 1.08 GiB Data: 98.75% 1.06 GiB Text: 1.25% 13.76 MiB Kernel Memory Map: 2.83 GiB Size: 26.80% 775.56 MiB Free: 73.20% 2.07 GiB Page: 1 ------------------------------------------------------------------------ ARC Summary: (THROTTLED) Storage pool Version: 15 Filesystem Version: 4 Memory Throttle Count: 53.77m ARC Misc: Deleted: 1.99m Recycle Misses: 6.84m Mutex Misses: 6.96k Evict Skips: 6.96k ARC Size: 552.16% 1.38 GiB Target Size: (Adaptive) 100.00% 256.00 MiB Min Size (Hard Limit): 36.23% 92.75 MiB Max Size (High Water): 2:1 256.00 MiB ARC Size Breakdown: Recently Used Cache Size: 16.97% 239.90 MiB Frequently Used Cache Size: 83.03% 1.15 GiB ARC Hash Breakdown: Elements Max: 83.19k Elements Current: 84.72% 70.48k Collisions: 2.53m Chain Max: 9 Chains: 18.94k Page: 2 ------------------------------------------------------------------------ ARC Efficiency: 126.65m Cache Hit Ratio: 95.07% 120.41m Cache Miss Ratio: 4.93% 6.24m Actual Hit Ratio: 95.07% 120.41m Data Demand Efficiency: 99.45% 111.87m Data Prefetch Efficiency: 0.00% 235.34k CACHE HITS BY CACHE LIST: Most Recently Used: 4.14% 4.99m Most Frequently Used: 95.85% 115.42m Most Recently Used Ghost: 0.24% 292.53k Most Frequently Used Ghost: 3.73% 4.50m CACHE HITS BY DATA TYPE: Demand Data: 92.40% 111.26m Prefetch Data: 0.00% 0 Demand Metadata: 7.60% 9.15m Prefetch Metadata: 0.00% 2.73k CACHE MISSES BY DATA TYPE: Demand Data: 9.79% 610.82k Prefetch Data: 3.77% 235.34k Demand Metadata: 85.67% 5.35m Prefetch Metadata: 0.78% 48.47k Page: 3 ------------------------------------------------------------------------ VDEV Cache Summary: 5.33m Hit Ratio: 91.14% 4.86m Miss Ratio: 8.59% 458.07k Delegations: 0.27% 14.34k Page: 6 ------------------------------------------------------------------------ ZFS Tunable (sysctl): kern.maxusers 384 vm.kmem_size 3112275968 vm.kmem_size_scale 1 vm.kmem_size_min 0 vm.kmem_size_max 329853485875 vfs.zfs.l2c_only_size 0 vfs.zfs.mfu_ghost_data_lsize 4866048 vfs.zfs.mfu_ghost_metadata_lsize 185315328 vfs.zfs.mfu_ghost_size 190181376 vfs.zfs.mfu_data_lsize 4608 vfs.zfs.mfu_metadata_lsize 3072 vfs.zfs.mfu_size 254041600 vfs.zfs.mru_ghost_data_lsize 0 vfs.zfs.mru_ghost_metadata_lsize 0 vfs.zfs.mru_ghost_size 0 vfs.zfs.mru_data_lsize 0 vfs.zfs.mru_metadata_lsize 0 vfs.zfs.mru_size 520685568 vfs.zfs.anon_data_lsize 0 vfs.zfs.anon_metadata_lsize 0 vfs.zfs.anon_size 20846592 vfs.zfs.l2arc_norw 1 vfs.zfs.l2arc_feed_again 1 vfs.zfs.l2arc_noprefetch 0 vfs.zfs.l2arc_feed_min_ms 200 vfs.zfs.l2arc_feed_secs 1 vfs.zfs.l2arc_headroom 2 vfs.zfs.l2arc_write_boost 8388608 vfs.zfs.l2arc_write_max 8388608 vfs.zfs.arc_meta_limit 67108864 vfs.zfs.arc_meta_used 1479184192 vfs.zfs.mdcomp_disable 0 vfs.zfs.arc_min 97258624 vfs.zfs.arc_max 268435456 vfs.zfs.zfetch.array_rd_sz 1048576 vfs.zfs.zfetch.block_cap 256 vfs.zfs.zfetch.min_sec_reap 2 vfs.zfs.zfetch.max_streams 8 vfs.zfs.prefetch_disable 1 vfs.zfs.check_hostid 1 vfs.zfs.recover 0 vfs.zfs.txg.write_limit_override 0 vfs.zfs.txg.synctime 5 vfs.zfs.txg.timeout 30 vfs.zfs.scrub_limit 10 vfs.zfs.vdev.cache.bshift 16 vfs.zfs.vdev.cache.size 10485760 vfs.zfs.vdev.cache.max 16384 vfs.zfs.vdev.aggregation_limit 131072 vfs.zfs.vdev.ramp_rate 2 vfs.zfs.vdev.time_shift 6 vfs.zfs.vdev.min_pending 4 vfs.zfs.vdev.max_pending 10 vfs.zfs.cache_flush_disable 0 vfs.zfs.zil_disable 0 vfs.zfs.zio.use_uma 0 vfs.zfs.version.zpl 4 vfs.zfs.version.spa 15 vfs.zfs.version.dmu_backup_stream 1 vfs.zfs.version.dmu_backup_header 2 vfs.zfs.version.acl 1 vfs.zfs.debug 0 vfs.zfs.super_owner 0 Page: 7 ------------------------------------------------------------------------ hybrid@node5:~$ uname -a FreeBSD node5.hybridlogiclabs.com 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Thanks! Luke Marsden -- CTO, Hybrid Logic +447791750420 | +1-415-449-1165 | www.hybrid-cluster.com From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 11:25:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B515B106566B for ; Fri, 2 Mar 2012 11:25:01 +0000 (UTC) (envelope-from prvs=0408e3a959=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 407698FC0A for ; Fri, 2 Mar 2012 11:25:01 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S3Qba-0002xm-1V for freebsd-stable@freebsd.org; Fri, 02 Mar 2012 12:24:58 +0100 Date: Fri, 2 Mar 2012 12:24:57 +0100 From: Oliver Brandmueller To: freebsd-stable@freebsd.org Message-ID: <20120302112457.GB6032@e-Gitt.NET> Mail-Followup-To: freebsd-stable@freebsd.org References: <4F5089B7.2070103@withagen.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F5089B7.2070103@withagen.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Oliver Brandmueller Subject: Re: Disk disconnects, with immediate reconnect X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 11:25:01 -0000 Hi, On Fri, Mar 02, 2012 at 09:49:59AM +0100, Willem Jan Withagen wrote: > On my ZFS server: > (info on: http://www.tegenbosch28.nl/FreeBSD/systems/ZFS/ ) > > +ahcich4: Timeout on slot 23 port 0 > +ahcich4: is 00000000 cs 00800000 ss 00000000 rs 00800000 tfd c0 serr > 00000000 cmd 0004d717 > +(ada3:ahcich4:0:0:0): lost device > +(ada3:ahcich4:0:0:0): removing device entry > +ada3 at ahcich4 bus 0 scbus5 target 0 lun 0 > +ada3: ATA-8 SATA 2.x device > +ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > +ada3: Command Queueing enabled > +ada3: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) > > The reconnect occurs immediately after the disconnect. > > I had some discussions with Jeremy Chadwick, so below are the smartctl > stats. > > The system was not particularly busy at that moment. > Is this disk failure, or why other did it disconnect. I suggest changing the disk: > 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail > Always - 13 I guess, this growing soon and fast ... > 197 Current_Pending_Sector 0x0012 100 100 000 Old_age > Always - 3 > 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age > Offline - 3 Doesn't look too promising. - Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 11:44:55 2012 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 25A771065674; Fri, 2 Mar 2012 11:44:55 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id ACF448FC12; Fri, 2 Mar 2012 11:44:54 +0000 (UTC) Received: by iahk25 with SMTP id k25so2841845iah.13 for ; Fri, 02 Mar 2012 03:44:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nyExwKb6ucUgbYPlzejNJV7GQYUbmtQjg09KsnuhDUI=; b=zSrbbYmorTDVjRR9FkE8AvxHjrb9oOd/UtGscHLVcVuA+NZew18eeRO5A7dmYUyGOi EQgezHxxMawXg1zUkl9CmqWCVo12DHikTchl3n1NrRccYBrNEI1oqD78TiiFJBZd9dFL zSwociE2cJP0bQmIdkWU6OI2Pq0j/0RnjN1Rqsqda2Rr1NjRboMcLW41a8y+O8IRAVMr IJzVMVa7r3+AUESbh6LpLaJ9DExxpWYoPpi8ZF8mT7SMQ8FYH3hn3uSEFXMIFCeHLKdw xLU2Cksr0R22GGXCyX637eb5p0qxRB2iiyUmJg5KBtv0CSxh/nvTvk2hEfNXTQBJevGr fKvA== MIME-Version: 1.0 Received: by 10.50.140.2 with SMTP id rc2mr1180220igb.22.1330688694146; Fri, 02 Mar 2012 03:44:54 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.50.134.106 with HTTP; Fri, 2 Mar 2012 03:44:54 -0800 (PST) In-Reply-To: <4F5088CA.1090108@FreeBSD.org> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> Date: Fri, 2 Mar 2012 12:44:54 +0100 X-Google-Sender-Auth: BGzEuE3oH5tFRWJveDZjpVsejio Message-ID: From: "K. Macy" To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, current@freebsd.org, Steve Wills , =?ISO-8859-2?Q?z_W=B1sikowski?= , Arnaud Lacombe , Alexander Leidinger , "Bjoern A. Zeeb" Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 11:44:55 -0000 > Apparently you've missed all the times that I've given that exact advice. :) > > But your analogy is severely flawed. Flowtable was an experimental > feature that theoretically might have increased performance for some > work flows, but turned out to be fatally flawed. The ports system is an > essential part of the FreeBSD operating *system*, depended on by > virtually 100% of FreeBSD users. Certainly fatally flawed without any user support. Just as many new features have been. > Users don't have any obligation to help us debug new/experimental features. Correct. However, I'm not sure the analogy is flawed. I am, to some degree, guilty of the same sin. I now run Ubuntu and have never had a single problem keeping my package system up date, in stark contrast to my experiences of slow and nightmarishly error-ridden port updates. I know there are users who have operated without such problems. It is entirely possible that they're simply smarter than I am. I similarly feel no compunction to use a FreeBSD feature (the ports system) that I can't rely on. Cheers From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 13:12:36 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2067106566B; Fri, 2 Mar 2012 13:12:36 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 577FD8FC08; Fri, 2 Mar 2012 13:12:36 +0000 (UTC) Received: from outgoing.leidinger.net (p5796C459.dip.t-dialin.net [87.150.196.89]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 61A72844754; Fri, 2 Mar 2012 14:12:22 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id AD48A14B2; Fri, 2 Mar 2012 14:12:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1330693939; bh=CpoAYICi9d1elPG3JpQoeSxIbCzrvCMWgt/eM/LcF4M=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=c4NoVG2aSXyLEuY/s60mEY4F88r8ZxB5qvDmWq7O058qH/lrXW0arECrM9KNrvzSu 5K8qcMsuz8zFCoLcFcEVqkC1jDoHsvRtTIReTeKdhLpwQX6EoRO7wMnYOP9kGENSFQ J6qvRIjYRA54OeHe3I5RM2nTew7KpcEMBgQFCPuE8VimAwmv3rRimnFkGar4cpsXlm MJucSHb7/ibmNIXyfEgkzhtEWHbw9ecHE56DsACD1ntkfTSk7Wneuxs09/l3FMB5Mk OQCwTSnkhgoS+ZoGbHgC7x9uu21+k1bDBsUO9m2bEG2j0UxDibKjLDhCrSai/uRZ56 rSWvccg2MB2Tw== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q22DCHIs045389; Fri, 2 Mar 2012 14:12:17 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 02 Mar 2012 14:12:17 +0100 Date: Fri, 02 Mar 2012 14:12:15 +0100 Message-ID: <20120302141215.Horde._8y4bZjmRSRPUMcvyarq5BA@webmail.leidinger.net> From: Alexander Leidinger To: Slawa Olhovchenkov References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <20120301145834.GH97848@zxy.spb.ru> <20120302100924.Horde.vnzeDZjmRSRPUI5EsjnnPZA@webmail.leidinger.net> <20120302092401.GP52973@zxy.spb.ru> In-Reply-To: <20120302092401.GP52973@zxy.spb.ru> User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 61A72844754.AF8C6 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-0.671, required 6, autolearn=disabled, AWL -0.56, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1331298742.94172@5KY0Su4Kf3XJaympNhkwOQ X-EBL-Spam-Status: No Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 13:12:36 -0000 Quoting Slawa Olhovchenkov (from Fri, 2 Mar 2012 13:24:01 +0400): > On Fri, Mar 02, 2012 at 10:09:24AM +0100, Alexander Leidinger wrote: > >> Quoting Slawa Olhovchenkov (from Thu, 1 Mar 2012 >> 18:58:34 +0400): >> >> > On Tue, Feb 21, 2012 at 02:35:37PM +0100, Alexander Leidinger wrote: >> > >> >> You can download from >> >> http://www.Leidinger.net/FreeBSD/current-patches/ >> >> The files are >> >> - i386_SMALL >> >> - i386_SMALL_loader.conf >> >> - amd64_SMALL >> >> - amd64_SMALL_loader.conf >> > >> > Where SCSI disk/etc? >> >> CAM and ATA are loaded as modules in the loader.conf (except for two >> SCSI controllers, which are not available as modules). I may have >> missed to load a module, or I may not load in the correct order (which >> would be a bug of missing/wrong dependencies in some modules). I'm >> investigating a corresponding report with error messages. > > Not controllers, peripherals: disk/tape/etc > > device scbus # SCSI bus (required for ATA/SCSI) > device ch # SCSI media changers > device da # Direct Access (disks) > device sa # Sequential Access (tape etc) > device cd # CD > device pass # Passthrough device (direct ATA/SCSI access) > device ses # SCSI Environmental Services (and SAF-TE) They should be all in the cam module, they don't exist as separate modules. If something is missing, it's a bug or omitted on purpose (but then there's hopefully a comment somewhere explaining why). Bye, Alexander. -- BOFH excuse #418: Sysadmins busy fighting SPAM http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 13:33:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA9AF106564A for ; Fri, 2 Mar 2012 13:33:37 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 7BACE8FC12 for ; Fri, 2 Mar 2012 13:33:37 +0000 (UTC) Received: from outgoing.leidinger.net (p5796C459.dip.t-dialin.net [87.150.196.89]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 0EE3E844754; Fri, 2 Mar 2012 14:33:23 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::3:102]) by outgoing.leidinger.net (Postfix) with ESMTPS id 58CE914B5; Fri, 2 Mar 2012 14:33:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1330695200; bh=H62x8F5G3loDaJWWTjHK8oyJpSjyvLketjgjcKMqepA=; h=Date:Message-ID:From:To:Cc:Subject:References:In-Reply-To: Content-Type:MIME-Version; b=V7pQ2ReyqlwQgn0XT1/WWeoKeO39ykC9EekJ663TWBRaWbIXGWBIJfr+Ds4KIuZ0p mNW8h6h4Ljhut70FbWo1zMnIKiOc/m6L415Llll6ODBGSd8eA2ztxT8DxYyxO4haSX JBawd2VfiimTAdYGlhbdQZbf+AQzSxDcF78YmQlRkZ1wECQthnSNSN11/Fr2i3ZLrk xIyHhOsL2r9UR3lLyRZ121dC3P1N7p1LKCQcmKZOyZhsQHzF0OVMeQlZjhCyEg7Rr/ 5W8rO26jwv3cR5RARJYiQaX6Jn0WKqDKeYb2nTqZs3h1YAQvrF6hr4qth8iJrYHhP+ GcT1FBadnn1UQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.5/8.14.4/Submit) id q22DXHsq046778; Fri, 2 Mar 2012 14:33:17 +0100 (CET) (envelope-from Alexander@Leidinger.net) X-Authentication-Warning: webmail.leidinger.net: www set sender to Alexander@Leidinger.net using -f Received: from 85.94.224.19 ([85.94.224.19]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 02 Mar 2012 14:33:17 +0100 Date: Fri, 02 Mar 2012 14:33:17 +0100 Message-ID: <20120302143317.Horde.sAWpfZjmRSRPUMwdU70rHcA@webmail.leidinger.net> From: Alexander Leidinger To: Pavel Timofeev References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <1329890164178-5504219.post@n5.nabble.com> <20120222140308.Horde.RjSecpjmRSRPROeM24KCgsA@webmail.leidinger.net> <1330501225474-5524279.post@n5.nabble.com> <20120229110106.Horde.57mdQpjmRSRPTfdiZgvhTsA@webmail.leidinger.net> <20120229141628.Horde.dEOYCZjmRSRPTiUs4NvBeec@webmail.leidinger.net> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H4 (5.0.18) Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 0EE3E844754.A2FFA X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.202, required 6, autolearn=disabled, AWL -1.49, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, J_CHICKENPOX_32 0.60, J_CHICKENPOX_52 0.60, J_CHICKENPOX_62 0.60, T_RP_MATCHES_RCVD -0.01) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1331300004.88942@QjFmiT1LumA8YmyOilMVBw X-EBL-Spam-Status: No Cc: freebsd-stable@freebsd.org Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 13:33:37 -0000 Quoting Pavel Timofeev (from Thu, 1 Mar 2012 10:35:17 +0400): > I have just tried lastest configs and see following messages while > kernel boot: > > Copyright (c) 1992-2012 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 10.0-CURRENT #0: Wed Feb 29 22:47:35 MSK 2012 > mox@rock:/usr/obj/usr/src/sys/SMALL amd64 > WARNING: WITNESS option enabled, expect reduced performance. > link_elf_obj: symbol xpt_create_path undefined > KLD file hptiop.ko - could not finalize loading > link_elf_obj: symbol firmware_get undefined > KLD file isp.ko - could not finalize loading > link_elf_obj: symbol xpt_freeze_simq undefined > KLD file mps.ko - could not finalize loading > link_elf_obj: symbol cam_simq_alloc undefined > KLD file hptmv.ko - could not finalize loading > CPU: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz (2906.39-MHz > K8-class CPU) > > Don't you know why do I get it? The xpt_* symbols are all in the cam module. If you downloaded the loader.conf the cam module should be surely there (except you lost it). Without the cam module I can understand the messages about xpt_*, with the cam module I can't (I speicied cam before hptiop/mps/hptmv). Regarding the firmware_get module I changed the order of module loading in the loader.conf, I've put the firmware_load to the front to load it before a lot of other modules. Theoretically this should solve the isse. Bye, Alexander. -- I THINK MAN INVENTED THE CAR by instinct. -- Jack Handey, "The New Mexican" (1988) http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 14:03:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D60F1065672 for ; Fri, 2 Mar 2012 14:03:41 +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 1F2598FC08 for ; Fri, 2 Mar 2012 14:03:39 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q22E3ZH1032085; Fri, 2 Mar 2012 16:03:35 +0200 (EET) (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.5/8.14.5) with ESMTP id q22E3ZMb083056; Fri, 2 Mar 2012 16:03:35 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q22E3Y9s083055; Fri, 2 Mar 2012 16:03:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 2 Mar 2012 16:03:34 +0200 From: Konstantin Belousov To: Alexander Leidinger Message-ID: <20120302140334.GJ75778@deviant.kiev.zoral.com.ua> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <1329890164178-5504219.post@n5.nabble.com> <20120222140308.Horde.RjSecpjmRSRPROeM24KCgsA@webmail.leidinger.net> <1330501225474-5524279.post@n5.nabble.com> <20120229110106.Horde.57mdQpjmRSRPTfdiZgvhTsA@webmail.leidinger.net> <20120229141628.Horde.dEOYCZjmRSRPTiUs4NvBeec@webmail.leidinger.net> <20120302143317.Horde.sAWpfZjmRSRPUMwdU70rHcA@webmail.leidinger.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x0KprKst+ZOYEj2z" Content-Disposition: inline In-Reply-To: <20120302143317.Horde.sAWpfZjmRSRPUMwdU70rHcA@webmail.leidinger.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Pavel Timofeev , freebsd-stable@freebsd.org, "Desai, Kashyap" Subject: Re: [CFT] modular kernel config X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 14:03:41 -0000 --x0KprKst+ZOYEj2z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 02, 2012 at 02:33:17PM +0100, Alexander Leidinger wrote: > Quoting Pavel Timofeev (from Thu, 1 Mar 2012 =20 > 10:35:17 +0400): >=20 > >I have just tried lastest configs and see following messages while =20 > >kernel boot: > > > >Copyright (c) 1992-2012 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 10.0-CURRENT #0: Wed Feb 29 22:47:35 MSK 2012 > > mox@rock:/usr/obj/usr/src/sys/SMALL amd64 > >WARNING: WITNESS option enabled, expect reduced performance. > >link_elf_obj: symbol xpt_create_path undefined > >KLD file hptiop.ko - could not finalize loading > >link_elf_obj: symbol firmware_get undefined > >KLD file isp.ko - could not finalize loading > >link_elf_obj: symbol xpt_freeze_simq undefined > >KLD file mps.ko - could not finalize loading > >link_elf_obj: symbol cam_simq_alloc undefined > >KLD file hptmv.ko - could not finalize loading > >CPU: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz (2906.39-MHz =20 > >K8-class CPU) > > > >Don't you know why do I get it? >=20 > The xpt_* symbols are all in the cam module. If you downloaded the =20 > loader.conf the cam module should be surely there (except you lost =20 > it). Without the cam module I can understand the messages about xpt_*, = =20 > with the cam module I can't (I speicied cam before hptiop/mps/hptmv). >=20 > Regarding the firmware_get module I changed the order of module =20 > loading in the loader.conf, I've put the firmware_load to the front to = =20 > load it before a lot of other modules. Theoretically this should solve = =20 > the isse. The issue there, at least with mps(4), is that the driver erronously lacks the line MODULE_DEPEND(mps, cam, 1, 1, 1); somewhere in mps_pci.c to record dependency on the cam(4). Never looked at the other drivers, but I suspect that the problem is same. --x0KprKst+ZOYEj2z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9Q0zYACgkQC3+MBN1Mb4ghFgCfUeht3d2FZ02Z4D9G+CdOeGfV qZMAn3H2DXzM0F341/2YvnzRgWU1qX/7 =7FCy -----END PGP SIGNATURE----- --x0KprKst+ZOYEj2z-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 14:54:55 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A396106566B for ; Fri, 2 Mar 2012 14:54:55 +0000 (UTC) (envelope-from remailer@dizum.com) Received: from smtp.zedz.net (outpost.zedz.net [194.109.206.210]) by mx1.freebsd.org (Postfix) with ESMTP id 8038A8FC16 for ; Fri, 2 Mar 2012 14:54:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.zedz.net (Postfix) with ESMTP id C850E1AA255 for ; Fri, 2 Mar 2012 15:35:36 +0100 (CET) Received: from smtp.zedz.net ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlS0nHB47PHf for ; Fri, 2 Mar 2012 15:35:31 +0100 (CET) Received: by smtp.zedz.net (Postfix, from userid 1003) id 03DFE1AA110; Fri, 2 Mar 2012 15:35:24 +0100 (CET) From: Nomen Nescio Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at . To: stable@freebsd.org X-Invalid: 6Gn_zPzxz5tLuzPOW=kK9Yxq mrLTyitvGfAPhrkbw__13836.2677921124$1330688838$gmane$org@mail.gmail.com> Message-ID: <18c325310044439cbc4d03c7e0bbec52@dizum.com> Date: Fri, 2 Mar 2012 15:35:24 +0100 (CET) Cc: Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 14:54:55 -0000 > my experiences of slow and nightmarishly error-ridden port updates I have no intention to bash FreeBSD or ports but ports is certainly not without problems. It's annoying but not a reason to use Ubuntu! Get a grip, man! ;-) > I know there are users who have operated without such problems I think if you use the i386 architecture and the common ports you are less likely to find something before somebody else finds it and it gets fixed. If you use any other platform you are likely to find problems with ports and this gets amplified if you use nonstandard (read stuff not everybody uses) ports. I have found several ports broken for many releases in a row. Other ports aren't supported on certain target architectures but the build doesn't tell you that until after it has run for a couple of hours downloading huge source tarballs and compiling them only to give you a nastygram "Sorry this port is not available on AMD64" of something like that. I understand not every port maintainer can test on every arch but come on, for stuff that you know doesn't work can't you check at the beginning and stop rather than put out a message when the build breaks? From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 15:15:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9FEA1065672 for ; Fri, 2 Mar 2012 15:15:52 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id 48DC38FC14 for ; Fri, 2 Mar 2012 15:15:52 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 243972198; Fri, 02 Mar 2012 16:15:50 +0100 From: Hans Petter Selasky To: Alexey Dokuchaev Date: Fri, 2 Mar 2012 16:14:08 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.3-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <20120227152238.GA2940@regency.nsu.ru> <201203020848.13410.hselasky@c2i.net> <20120302085702.GA42866@regency.nsu.ru> In-Reply-To: <20120302085702.GA42866@regency.nsu.ru> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203021614.08678.hselasky@c2i.net> Cc: freebsd-stable@freebsd.org Subject: Re: Resume broken in 8.3-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: Fri, 02 Mar 2012 15:15:52 -0000 On Friday 02 March 2012 09:57:03 Alexey Dokuchaev wrote: > On Fri, Mar 02, 2012 at 08:48:13AM +0100, Hans Petter Selasky wrote: > > If the reset doesn't work, then try to enable hw.usb.uhub.debug=15 and > > see what port change events are coming. > > I don't see such oid hw.usb.uhub.debug. Perhaps it should be hw.usb.debug? > > > If cfg=255 in usbconfig, then something is wrong. > > It seems they are all zeros, per the output I've sent earlier. If they are all zeros, then everything is working like it should. If you can dump the device and configuration descriptors, then there is no USB problem. I'm thinking it might be some MICROCODE issue that causes the problem. Maybe we shouldn't reset the OHCI and EHCI and UHCI and XHCI before handing over to the MICROCODE suspend handler? Have a look in /sys/dev/usb/controller/xhci/ehci/ohci/uhci and search for suspend. --HPS From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 15:56:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13C8A1065670 for ; Fri, 2 Mar 2012 15:56:38 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (r2b9.nsu.ru [212.192.164.39]) by mx1.freebsd.org (Postfix) with ESMTP id A0D7A8FC0C for ; Fri, 2 Mar 2012 15:56:37 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1S3Upg-0004os-8L; Fri, 02 Mar 2012 22:55:48 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q22Fu01Q002527; Fri, 2 Mar 2012 22:56:00 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q22FttQP002468; Fri, 2 Mar 2012 22:55:55 +0700 (NOVT) (envelope-from danfe) Date: Fri, 2 Mar 2012 22:55:54 +0700 From: Alexey Dokuchaev To: Hans Petter Selasky Message-ID: <20120302155554.GA1011@regency.nsu.ru> References: <20120227152238.GA2940@regency.nsu.ru> <201203020848.13410.hselasky@c2i.net> <20120302085702.GA42866@regency.nsu.ru> <201203021614.08678.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201203021614.08678.hselasky@c2i.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: Resume broken in 8.3-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: Fri, 02 Mar 2012 15:56:38 -0000 On Fri, Mar 02, 2012 at 04:14:08PM +0100, Hans Petter Selasky wrote: > On Friday 02 March 2012 09:57:03 Alexey Dokuchaev wrote: > > On Fri, Mar 02, 2012 at 08:48:13AM +0100, Hans Petter Selasky wrote: > > > If the reset doesn't work, then try to enable hw.usb.uhub.debug=15 and > > > see what port change events are coming. > > > > I don't see such oid hw.usb.uhub.debug. Perhaps it should be hw.usb.debug? What about this? I've did hw.usb.debug=15, but didn't see anything new on the console. > > > If cfg=255 in usbconfig, then something is wrong. > > > > It seems they are all zeros, per the output I've sent earlier. > > If they are all zeros, then everything is working like it should. If you can > dump the device and configuration descriptors, then there is no USB problem. I can only dump this information *before* suspend, after "resume" I cannot do almost anything except breaking into debugger (but not being able to "call doadump"). I had to revert to earlier revision to call usbconfig(8) after resume. > I'm thinking it might be some MICROCODE issue that causes the problem. Maybe > we shouldn't reset the OHCI and EHCI and UHCI and XHCI before handing over to > the MICROCODE suspend handler? > > Have a look in /sys/dev/usb/controller/xhci/ehci/ohci/uhci and search for > suspend. OK, I will try and report back, thanks. ./danfe From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 16:02:59 2012 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 85D94106566B for ; Fri, 2 Mar 2012 16:02:59 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id E76E28FC16 for ; Fri, 2 Mar 2012 16:02:58 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) (authenticated bits=0) by vergina.eng.auth.gr (8.14.4/8.14.3) with ESMTP id q22FckQO021467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Mar 2012 17:38:46 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4F50E986.5040406@eng.auth.gr> Date: Fri, 02 Mar 2012 17:38:46 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120217 Thunderbird/10.0.2 MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (vergina.eng.auth.gr [192.168.18.7]); Fri, 02 Mar 2012 17:38:46 +0200 (EET) Cc: Subject: audit in jail X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 16:02:59 -0000 Hello everybody, has anyone started auditd inside a jail successfully? I allowed audit and auditpipe from devfs inside the jails (I have confirmed their existence in the jails as well...:-) ), but when I run auditd I am getting this message in my logs: Mar 2 15:20:29 myhost auditd[89494]: auditd_prevent_audit() could not set active audit session state: Function not implemented Mar 2 15:20:29 myhost mamalos: audit warning: nostart I googled it, but didn't find much. I checked the code and after some searching, I found that the problem was occurring when the setaudit system call is being called. I checked the code of audit_syscalls and found that: 584: if (jailed(td->td_ucred)) 585: return (ENOSYS); in the sys_setaudit() context...which is somewhat clear as to what it means :-). Is there anything I have omitted, or is it that clear that audit does not run in jails? And if so, are there any thoughts on implementing in the near future? Thank you all for your help and time in advance. -- George Mamalakis IT and Security Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 16:17:38 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 50355106564A for ; Fri, 2 Mar 2012 16:17:38 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id BA4C88FC08 for ; Fri, 2 Mar 2012 16:17:37 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) (authenticated bits=0) by vergina.eng.auth.gr (8.14.4/8.14.3) with ESMTP id q22GHaWH063472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Mar 2012 18:17:36 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4F50F2A0.40401@eng.auth.gr> Date: Fri, 02 Mar 2012 18:17:36 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120217 Thunderbird/10.0.2 MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (vergina.eng.auth.gr [192.168.18.7]); Fri, 02 Mar 2012 18:17:36 +0200 (EET) Cc: Subject: RE: audit in jail X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 16:17:38 -0000 Ah! And one more thing with respect to this issue. Since I realized that probably I won't be able to run audit within a jail, I tried to continue with my work from outside the jail. What I need is to audit some system users (like www) inside my jails and do stuff with their audit trails. In order to be able to audit www's actions, I downloaded setaudit from http://www.freebsd.org/~csjp/setaudit.c which allows this functionality. setaudit works fine from outside my jails, but when I run it from within a jail, I get the following error again: [root@in-jail] # setaudit -awww -mfr /bin/ls setaudit: setaudit_addr: Function not implemented Is there, at least, some easy/secure/not-whole-system-configuration-changing way to start apache from within a jail to be able to audit his actions from outside the jail? Thank you all in advance, once more. -- George Mamalakis IT and Security Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 16:50:38 2012 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 DB5751065670 for ; Fri, 2 Mar 2012 16:50:38 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [187.95.0.181]) by mx1.freebsd.org (Postfix) with ESMTP id 649988FC12 for ; Fri, 2 Mar 2012 16:50:37 +0000 (UTC) Received: from msrv.matik.com.br (localhost.matik.com.br [127.0.0.1]) by msrv.matik.com.br (8.14.5/8.14.5) with ESMTP id q22GVsdT090689; Fri, 2 Mar 2012 13:31:55 -0300 (BRT) (envelope-from joao@matik.com.br) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at msrv.matik.com.br X-DKIM: OpenDKIM Filter v2.4.3 msrv.matik.com.br q22GVsdT090689 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=matik.com.br; s=racoon; t=1330705915; bh=ys0DurjShaS+NFGR7/7AzI43cWmYkXQ8uUXOADVZwio=; h=Message-ID:In-Reply-To:References:Date:Subject:From:To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Qt3aJpSQDgoQlTL3nR7p1SEwsUr3bIjQh7+scDYOKm+y0VwXklJQ8uMBrvZhsVjKa 9IOsCFEgUJmWZlZw3qk3MBrhpwTBtkg2OXs+26vb4mHi+gBPZwagZ7Mfr9u39HzXc2 E6qCT3a3cL4/0AtOFr61QDIXI4hIcrev5yCjrr6U= Received: (from www@localhost) by msrv.matik.com.br (8.14.5/8.14.4/Submit) id q22GVmrT090688; Fri, 2 Mar 2012 13:31:48 -0300 (BRT) (envelope-from joao@matik.com.br) X-Authentication-Warning: msrv.matik.com.br: www set sender to joao@matik.com.br using -f Received: from 186.222.208.104 (SquirrelMail authenticated user joao) by wm.matik.com.br with HTTP; Fri, 2 Mar 2012 13:31:48 -0300 Message-ID: <710f84e85948db9ea902d91c00293aee.squirrel@wm.matik.com.br> In-Reply-To: <18c325310044439cbc4d03c7e0bbec52@dizum.com> References: <18c325310044439cbc4d03c7e0bbec52@dizum.com> Date: Fri, 2 Mar 2012 13:31:48 -0300 From: "JoaoBR" To: "Nomen Nescio" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: stable@freebsd.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 16:50:38 -0000 Em Sex, Março 2, 2012 11:35, Nomen Nescio escreveu: >> my experiences of slow and nightmarishly error-ridden port updates > > I have no intention to bash FreeBSD or ports but ports is certainly not > without problems. It's annoying but not a reason to use Ubuntu! Get a > grip, man! ;-) > >> I know there are users who have operated without such problems >> > > I think if you use the i386 architecture and the common ports you are > less likely to find something before somebody else finds it and it gets > fixed. If you use any other platform you are likely to find problems with > ports and this gets amplified if you use nonstandard (read stuff not > everybody uses) ports. with some good luck may be ... ports need some kind of disaster management for example, certain ports depending on perl, install or upgrade fine when using portupgrade or portinstall and are satisfied with let's say perl-8.9 then you use pkg_add, or -P[P] switch and the same port looks for perl.12.4 and bumps it into the system careless, not even checking if there is another perl already no way using batch on ports today unless you like to get screwed and never turn your eyes away from screen .... I do not need to say more, you all know that and I can understand the frustration of whom is gotten caught by this mess > I have found several ports broken for many releases > in a row. Other ports aren't supported on certain target architectures but > the build doesn't tell you that until after it has run for a couple of > hours downloading huge source tarballs and compiling them only to give you > a nastygram "Sorry this port is not available on AMD64" of something like > that. I understand not every port maintainer can test on every arch but come on, then the port should not be there for this architecture ... or it is and works or it is not or do we have new standards now as 0|0.5|1 or is it still 0|1 ? > come on, for stuff that you know doesn't work can't you check at the > beginning and stop rather than put out a message when the build breaks? some fine ports are compiling fine, go through the whole process and screw all up at the install process, they already run pkg_delete, do not find the dependency, do some stuff and bail out, at the end portupgrade confirm success but they do not got installed but de-installed, as present some dependencies are messed up ... :) so as it is, better grab the original sources and compile your stuff on your own and stay "far" away from ports -- João Martins (JoaoBR) Infomatik Development Team http://wipserver.matik.com.br +55 11 4249.2222 From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 17:01:17 2012 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 B035A1065673 for ; Fri, 2 Mar 2012 17:01:17 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 905FC8FC17 for ; Fri, 2 Mar 2012 17:01:17 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id AAD845620E; Fri, 2 Mar 2012 10:45:05 -0600 (CST) Date: Fri, 2 Mar 2012 10:45:05 -0600 From: Mark Linimon To: Nomen Nescio Message-ID: <20120302164505.GA1500@lonesome.com> References: <18c325310044439cbc4d03c7e0bbec52@dizum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18c325310044439cbc4d03c7e0bbec52@dizum.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@freebsd.org Subject: Re: ports usable or not [was: flowtable usable or not] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 17:01:17 -0000 On Fri, Mar 02, 2012 at 03:35:24PM +0100, Nomen Nescio wrote: > If you use [!i386] you are likely to find problems with ports and > this gets amplified if you use nonstandard (read stuff not everybody uses) > ports. Fair enough. > I have found several ports broken for many releases in a row. These are bugs. Please report them via PRs. > Other ports aren't supported on certain target architectures but the build > doesn't tell you that until after it has run for a couple of hours Those are also bugs. Please send PRs for those, as well. I am particularly concerned about amd64 in this regard (although I am actually only myself doing the package runs for sparc64 and powerpc). We continually try to adjust the metadata for ports to indicate where they will and will not run, based on the output of pointyhat runs. (OTOH pointyhat runs the src tree from "the oldest supported minor release on each branch", so this may be a clue .) For those interested in investigating the metadata as seen by these package build runs, they are available. For instance: http://pointyhat.freebsd.org/errorlogs/amd64-9-latest/duds.verbose Substitute {i386|sparc64|powerpc} for "amd64" and {7|8} for "9" to look at the others. Note that I haven't done any ia64 builds in quite a long time. Also note that for sparc64 and powerpc, I no longer try to do 7. Finally, we haven't done many runs on 10 yet. You can see the overall state of the various package builds at: http://pointyhat.freebsd.org/errorlogs/packagestats.html whose "skipped" links will take you to the duds.verbose files. mcl From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 17:02:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E51381065670 for ; Fri, 2 Mar 2012 17:02:59 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5252F8FC18 for ; Fri, 2 Mar 2012 17:02:58 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) (authenticated bits=0) by vergina.eng.auth.gr (8.14.4/8.14.3) with ESMTP id q22Gnmfx075730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 2 Mar 2012 18:49:49 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4F50FA2D.9020801@eng.auth.gr> Date: Fri, 02 Mar 2012 18:49:49 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120217 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4F50F2A0.40401@eng.auth.gr> In-Reply-To: <4F50F2A0.40401@eng.auth.gr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (vergina.eng.auth.gr [192.168.18.7]); Fri, 02 Mar 2012 18:49:49 +0200 (EET) Subject: Re: audit in jail X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 17:03:00 -0000 On 03/02/12 18:17, George Mamalakis wrote: > Ah! > > And one more thing with respect to this issue. Since I realized that > probably I won't be able to run audit within a jail, I tried to > continue with my work from outside the jail. What I need is to audit > some system users (like www) inside my jails and do stuff with their > audit trails. In order to be able to audit www's actions, I downloaded > setaudit from http://www.freebsd.org/~csjp/setaudit.c which allows > this functionality. setaudit works fine from outside my jails, but > when I run it from within a jail, I get the following error again: > > [root@in-jail] # setaudit -awww -mfr /bin/ls > setaudit: setaudit_addr: Function not implemented > > Is there, at least, some > easy/secure/not-whole-system-configuration-changing way to start > apache from within a jail to be able to audit his actions from outside > the jail? > > Thank you all in advance, once more. > OK, found it! I am running: [root@out-of-jail] setaudit -awww -m fr,fw,fa,fm,fc,fd,cl jexec 6 /usr/local/bin/sudo -u www /usr/local/sbin/apachectl startssl from outside the jails and it works like a charm! Nasty, but at least it's working... Thank you all anyway! -- George Mamalakis IT and Security Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 18:16:46 2012 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 9C9141065670 for ; Fri, 2 Mar 2012 18:16:46 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5A8238FC1C for ; Fri, 2 Mar 2012 18:16:45 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1S3X2R-000IYa-KU for stable@freebsd.org; Fri, 02 Mar 2012 22:17:07 +0400 Date: Fri, 2 Mar 2012 22:17:07 +0400 From: Slawa Olhovchenkov To: stable@freebsd.org Message-ID: <20120302181707.GI97848@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Subject: Long delay on boot 9.0R on vmware+zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 18:16:46 -0000 ZFSRoot installation, FreeBSD 9.0R. GPT partition. VmWare ESXi 4.1. Long delay (more 30 seconds) on loader disk detect. Debug print pointed to zfs/zfs.c:zfs_dev_init. This function found disk0 and walked over 128 potencial slices, trying 'p' slice and 's' slice. Each attempt -- 1/4s (and nothing found). How to speed up boot? From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 18:22:59 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 33DF810656D8; Fri, 2 Mar 2012 18:22:59 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 1390914F000; Fri, 2 Mar 2012 18:21:50 +0000 (UTC) Message-ID: <4F510FBD.50008@FreeBSD.org> Date: Fri, 02 Mar 2012 10:21:49 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120224 Thunderbird/10.0.2 MIME-Version: 1.0 To: "K. Macy" References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, current@freebsd.org, =?UTF-8?B?eiBXxIVzaWtvd3NraQ==?= , Arnaud Lacombe , Alexander Leidinger , "Bjoern A. Zeeb" Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 18:22:59 -0000 On 03/02/2012 03:44, K. Macy wrote: >> Apparently you've missed all the times that I've given that exact advice. :) >> >> But your analogy is severely flawed. Flowtable was an experimental >> feature that theoretically might have increased performance for some >> work flows, but turned out to be fatally flawed. The ports system is an >> essential part of the FreeBSD operating *system*, depended on by >> virtually 100% of FreeBSD users. > > Certainly fatally flawed without any user support. Just as many new > features have been. Right, but what's your point? "I have this cool new thing, and you have to risk your network stability in order to help me debug it on a production network?" That's not how the world works man. >> Users don't have any obligation to help us debug new/experimental features. > > Correct. However, I'm not sure the analogy is flawed. I am, to some > degree, guilty of the same sin. I now run Ubuntu and have never had a > single problem keeping my package system up date, in stark contrast to > my experiences of slow and nightmarishly error-ridden port updates. So first of all, apples and oranges (Ubuntu packages vs. our ports), but yeah, I get it. I use both, and have had the same user experience you have, on both systems. I work with the ports infrastructure quite a bit, and I know it's flaws intimately. That's one reason that I wrote portmaster. > I > know there are users who have operated without such problems. It is > entirely possible that they're simply smarter than I am. Not necessarily. I have said many times that the ports system has some really bad fundamental design principles that make users' lives harder, and unfortunately there is a lot of inertia that prevents change. Some of this is improving, a lot of it is not. But, at the same time, a lot of work is going into improving usability, and I think the situation is better now than it was even just a few years ago. > I similarly > feel no compunction to use a FreeBSD feature (the ports system) that I > can't rely on. ... and here is the crux of the problem. The vast majority of our developers don't use FreeBSD as their regular workstation. So it has increasingly become an OS where changes are being lobbed over the wall by developers who don't run systems that those changes affect. That's no way to run a railroad. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 18:25:25 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E9851065676 for ; Fri, 2 Mar 2012 18:25:25 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1752A8FC18 for ; Fri, 2 Mar 2012 18:25:24 +0000 (UTC) Received: by wibhn6 with SMTP id hn6so1030666wib.13 for ; Fri, 02 Mar 2012 10:25:24 -0800 (PST) Received-SPF: pass (google.com: domain of amvandemore@gmail.com designates 10.180.80.40 as permitted sender) client-ip=10.180.80.40; Authentication-Results: mr.google.com; spf=pass (google.com: domain of amvandemore@gmail.com designates 10.180.80.40 as permitted sender) smtp.mail=amvandemore@gmail.com; dkim=pass header.i=amvandemore@gmail.com Received: from mr.google.com ([10.180.80.40]) by 10.180.80.40 with SMTP id o8mr7740724wix.10.1330712724348 (num_hops = 1); Fri, 02 Mar 2012 10:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J2Y9v/NK5WPkwfVsi+gReSjiPGRYpV5yjEl1LKSAhno=; b=izX9ILLA6LsgHIicrucpNjFXCZ09ahD40Ga4LSenmbnktS4ZkFu3qhlOLEZL0OklSS N6nX5kQXoqYhVSbUtH3lCci37QqBAuhIRKYlKELAwrfyumWW9SAKIpLD+7/yomeGN7Xq ISUdV7Ca+x1ZovBY9EAg8fJvD7XRje713NT0oI/la7sMafPUPRJ8e/8nWDmXz9myIfpw 3qvlrhFjKoi6A2Ug03xf4FOzN7wtXTWyYDEhc/D00e5ejwUNJ+nFkhtjx58SYdwVJNS8 G7Sa8ZZT4rdC/atsQIXsDaPkIR2b1eKdtXrcbBCGAGB2Jipvyf4wahZldo0kFQKfBsCr tDCA== MIME-Version: 1.0 Received: by 10.180.80.40 with SMTP id o8mr6199000wix.10.1330712724173; Fri, 02 Mar 2012 10:25:24 -0800 (PST) Received: by 10.223.93.138 with HTTP; Fri, 2 Mar 2012 10:25:24 -0800 (PST) In-Reply-To: <20120302181707.GI97848@zxy.spb.ru> References: <20120302181707.GI97848@zxy.spb.ru> Date: Fri, 2 Mar 2012 12:25:24 -0600 Message-ID: From: Adam Vande More To: Slawa Olhovchenkov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org Subject: Re: Long delay on boot 9.0R on vmware+zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 18:25:25 -0000 On Fri, Mar 2, 2012 at 12:17 PM, Slawa Olhovchenkov wrote: > Long delay (more 30 seconds) on loader disk detect. > Debug print pointed to zfs/zfs.c:zfs_dev_init. > This function found disk0 and walked over 128 potencial slices, trying > 'p' slice and 's' slice. Each attempt -- 1/4s (and nothing found). > > How to speed up boot? > Sounds quite similar to this: http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 18:29:46 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E6438106564A for ; Fri, 2 Mar 2012 18:29:46 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 4FF008FC0A for ; Fri, 2 Mar 2012 18:29:46 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q22ITgjJ034592 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 2 Mar 2012 18:29:42 GMT (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.4.3 smtp.infracaninophile.co.uk q22ITgjJ034592 Authentication-Results: smtp.infracaninophile.co.uk/q22ITgjJ034592; dkim=none (no signature); dkim-adsp=none Message-ID: <4F51118B.40800@FreeBSD.org> Date: Fri, 02 Mar 2012 18:29:31 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org References: <18c325310044439cbc4d03c7e0bbec52@dizum.com> <20120302164505.GA1500@lonesome.com> In-Reply-To: <20120302164505.GA1500@lonesome.com> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBBE465E22FAD6DBECECD682A" X-Virus-Scanned: clamav-milter 0.97.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: Subject: Re: ports usable or not [was: flowtable usable or not] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 18:29:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBBE465E22FAD6DBECECD682A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02/03/2012 16:45, Mark Linimon wrote: >> Other ports aren't supported on certain target architectures but the b= uild >> > doesn't tell you that until after it has run for a couple of hours > Those are also bugs. Please send PRs for those, as well. I am particu= larly > concerned about amd64 in this regard (although I am actually only mysel= f > doing the package runs for sparc64 and powerpc). We continually try to= > adjust the metadata for ports to indicate where they will and will not > run, based on the output of pointyhat runs. (OTOH pointyhat runs the > src tree from "the oldest supported minor release on each branch", so > this may be a clue .) Which reminds me about this: ports/164638 I've kind of taken my eye of progress on that, being distracted by other things. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enigBBE465E22FAD6DBECECD682A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9REZUACgkQ8Mjk52CukIwLOACdGTJhuNVT593LbhbA/I1h3MOa 9LoAnjrmHsmI51f5scR4lJBZTLf4/kQb =iR4R -----END PGP SIGNATURE----- --------------enigBBE465E22FAD6DBECECD682A-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 18:46:50 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E2BF1065675; Fri, 2 Mar 2012 18:46:50 +0000 (UTC) (envelope-from kmacybsd@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 CAA108FC14; Fri, 2 Mar 2012 18:46:49 +0000 (UTC) Received: by vbmv11 with SMTP id v11so2197988vbm.13 for ; Fri, 02 Mar 2012 10:46:49 -0800 (PST) Received-SPF: pass (google.com: domain of kmacybsd@gmail.com designates 10.52.22.46 as permitted sender) client-ip=10.52.22.46; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kmacybsd@gmail.com designates 10.52.22.46 as permitted sender) smtp.mail=kmacybsd@gmail.com; dkim=pass header.i=kmacybsd@gmail.com Received: from mr.google.com ([10.52.22.46]) by 10.52.22.46 with SMTP id a14mr18539051vdf.27.1330714009357 (num_hops = 1); Fri, 02 Mar 2012 10:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ST5G6+6AM999KBxQR2xhHqkkRhKBreVwnO8l7xcdkq4=; b=FYTDFiOCbtF3LcOQLa08rJX5KHhg+1EayyXhcCC52Even4TdF90fqy+bLK8msDaXQh SEervqA1WLiKsxavBDECI/LfSya5/jTTWA1cPdi/kIHnrPnW/r0h1SZjiKlU0B1FU8Bz Ki6CftbKJ7Aks2H9VdwgQbQcK+EjhWmXIes4Ddnd4m/a0jd5B0TeuFrTc5M5Z9ji7CoH bFpFNMxLvOQRNUqFBb/jemvgBxpm4sBRs6V/i78NlUJezKfcTlwX1Q+bh7/MckL8JC/0 7E72JXAnHFpi27sPzaeLNkCotb25jI1ETmSrf2ZJjbIK/nf7MrCwd+V5jyHCzjXnZ+vj lUqA== MIME-Version: 1.0 Received: by 10.52.22.46 with SMTP id a14mr15822263vdf.27.1330714009284; Fri, 02 Mar 2012 10:46:49 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.220.183.3 with HTTP; Fri, 2 Mar 2012 10:46:49 -0800 (PST) In-Reply-To: <4F510FBD.50008@FreeBSD.org> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> Date: Fri, 2 Mar 2012 19:46:49 +0100 X-Google-Sender-Auth: BmZawqdBf3TVju5j33h9YTRfDw4 Message-ID: From: "K. Macy" To: Doug Barton Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, current@freebsd.org, =?ISO-8859-2?Q?z_W=B1sikowski?= , Arnaud Lacombe , Alexander Leidinger , "Bjoern A. Zeeb" Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 18:46:50 -0000 > > ... and here is the crux of the problem. The vast majority of our > developers don't use FreeBSD as their regular workstation. So it has > increasingly become an OS where changes are being lobbed over the wall > by developers who don't run systems that those changes affect. That's no > way to run a railroad. You understand my point but then fail to or choose not to see how it applies to you when it creates problems for you personally. In essence my point was that "It was broken so I turned it off, end of story." does not constitute constructive feedback and does not contribute to the development of FreeBSD. It isn't your responsibility to help me debug my code just as it isn't my responsibility to contribute to the maintenance of ports by dealing with a port management that for me has been virtually unusable in coping with dependencies. I'm not eating the ports dog food because it is broken for me and you're not fully eating the sys dog food because it is broken for you are perfectly reasonable courses of action taken in isolation. However, our respective actions cumulatively don't contribute to the welfare of FreeBSD and my response was simply voicing frustration with such conduct. If you do not see the parallels between the two then there really isn't anything further to discuss about how we engage with the community. -Kip > > > Doug > > -- > > =A0 =A0This .signature sanitized for your protection --=20 =A0 =A0=93The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don=92t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won=92t take measure of their own strength, for fear of antagonizing their own weakness. Those who don=92t like to make waves=97or enemies. =A0 =A0Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It=92s the reductionist approach to life: if you keep it small, you=92ll keep it under control. If you don=92t make any noise, the bogeyman won=92t find you. =A0 =A0But it=92s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! >From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. =A0 =A0I choose my own way to burn.=94 =A0 =A0Sophie Scholl From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 18:55:38 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 08AB31065784; Fri, 2 Mar 2012 18:55:38 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 806B4162818; Fri, 2 Mar 2012 18:55:34 +0000 (UTC) Message-ID: <4F5117A6.2030003@FreeBSD.org> Date: Fri, 02 Mar 2012 10:55:34 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120224 Thunderbird/10.0.2 MIME-Version: 1.0 To: "K. Macy" References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, current@freebsd.org, =?UTF-8?B?eiBXxIVzaWtvd3NraQ==?= , Arnaud Lacombe , Alexander Leidinger , "Bjoern A. Zeeb" Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 18:55:38 -0000 On 03/02/2012 10:46, K. Macy wrote: > You understand my point but then fail to or choose not to see how it > applies to you when it creates problems for you personally. No, I already pointed out the distinction between "new, experimental features;" and "essential components of the FreeBSD operating system." It's Ok for you to disagree with that distinction, or with its importance. But what you're suggesting is that if users don't help developers debug "cool new feature X" then we won't have "cool new feature X." By implication you're saying that if we don't continue to develop cool new features then at some point down the road we wither and die. What I have tried ever-so-delicately to avoid saying is that lack of user help with debugging "cool new feature X" is generally a sign of lack of user demand for "cool new feature X." Not all cool new ideas are good ones. :) OTOH, if we don't fix the fundamental problems with ports, and other key areas of the operating system, we're just not going to have users, period. Given that most of the developers (like you) have stopped using FreeBSD on a day-to-day basis, who can blame them? Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 19:18:47 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5D33106566B; Fri, 2 Mar 2012 19:18:47 +0000 (UTC) (envelope-from kmacybsd@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 293228FC15; Fri, 2 Mar 2012 19:18:47 +0000 (UTC) Received: by vbmv11 with SMTP id v11so2232917vbm.13 for ; Fri, 02 Mar 2012 11:18:46 -0800 (PST) Received-SPF: pass (google.com: domain of kmacybsd@gmail.com designates 10.52.178.35 as permitted sender) client-ip=10.52.178.35; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kmacybsd@gmail.com designates 10.52.178.35 as permitted sender) smtp.mail=kmacybsd@gmail.com; dkim=pass header.i=kmacybsd@gmail.com Received: from mr.google.com ([10.52.178.35]) by 10.52.178.35 with SMTP id cv3mr18828124vdc.44.1330715926647 (num_hops = 1); Fri, 02 Mar 2012 11:18:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Y4i4Oq0WX6s2+cfxeul4SVQ5mdltZOX+/5fY369rxdo=; b=OZK/9sCMQQs0hg4+lgsHwB5GKZAn9CHNcBzO010FE7hB/vwwzEvfULakVsbIZXUnp4 x1kLw6gk3/BPtm7eycFEAgtaYsj5hx6X8eg/XxitNxeK6i87/nkYBRHppxTy6fyraBfo S7qwm32qtAiZ+LSguBz5QkILt13rJSVX2exX3a8ukUt5exxf0OZS0w9PZzr3FPAMghh/ C0oLrdnRv2uQgzgkKcfjE+fdz26hos2EoEELBBMiyoc91Sq/O2LwNN4BgmpEnbVTinBP EYofdTL++9q+ZeeY8p0bZJy2GMSvMCyOiN0mWfu2XxylBFKWsVi41Or4eP8DSWK8WWwn gsDg== MIME-Version: 1.0 Received: by 10.52.178.35 with SMTP id cv3mr16057262vdc.44.1330715926479; Fri, 02 Mar 2012 11:18:46 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.220.183.3 with HTTP; Fri, 2 Mar 2012 11:18:46 -0800 (PST) In-Reply-To: <4F5117A6.2030003@FreeBSD.org> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F5117A6.2030003@FreeBSD.org> Date: Fri, 2 Mar 2012 20:18:46 +0100 X-Google-Sender-Auth: NFsYILuGTwk1DVV1zyWeZV7Qn-g Message-ID: From: "K. Macy" To: Doug Barton Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org, current@freebsd.org, =?ISO-8859-2?Q?z_W=B1sikowski?= , Arnaud Lacombe , Alexander Leidinger , "Bjoern A. Zeeb" Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 19:18:47 -0000 > No, I already pointed out the distinction between "new, experimental > features;" and "essential components of the FreeBSD operating system." > It's Ok for you to disagree with that distinction, or with its > importance. But what you're suggesting is that if users don't help > developers debug "cool new feature X" then we won't have "cool new > feature X." By implication you're saying that if we don't continue to > develop cool new features then at some point down the road we wither and > die. What I have tried ever-so-delicately to avoid saying is that lack > of user help with debugging "cool new feature X" is generally a sign of > lack of user demand for "cool new feature X." Not all cool new ideas are > good ones. :) Considering there are firewall vendors and CDNs making consistent use of it because it dramatically increases the sustainable data rates it is a bit cavalier to say that there is a "lack of demand." It doesn't show up directly as a lack of demand when FreeBSD drastically underperforms linux in a high bandwidth environment. The solution is for the user to simply switch to linux how is a user to know (parodying Star Trek technobabble) "Darn it, if only FreeBSD provided an exponential phase inverter on the warp core in the network stack." All he or she will see is it is slow. Or another very concrete example is iX keeps losing sales because ZFS doesn't perform adequately. ZFS doesn't perform adequately largely because the VM system can't map and can't recycle pages fast enough because of locking limitations. It has nothing to do with the storage stack itself. However, most developers themselves are not familiar with the issues much less users. So if I were to make further locking changes I would initially inevitably break some things. Your response would be that it isn't something users want. You're absolutely right, because current users with higher performance demands DON'T USE FreeBSD. Now you may wish to cut hairs by saying well ... locking we need flowtable we don't. However, the gist of that would be that things that you don't understand, that don't solve anyone's immediate problems "user's don't want." For many prospective server class users the current performance profile is a bigger deterrent than the fact that Cairo took tons of hand-wringing to build and so I spent hours just getting a broken chat client to install and once I did OTR support didn't work. Taken collectively the "cool new feature X"s are every bit as important to FreeBSD as ports. > OTOH, if we don't fix the fundamental problems with ports, and other key > areas of the operating system, we're just not going to have users, > period. Given that most of the developers (like you) have stopped using > FreeBSD on a day-to-day basis, who can blame them? Not necessarily. Most big shops don't really use ports as is. Particularly appliance vendors don't care about how package management is handled. But yes, in principle we could end up with no desktop users. > Doug > > -- > > =A0 =A0This .signature sanitized for your protection --=20 =A0 =A0=93The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don=92t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won=92t take measure of their own strength, for fear of antagonizing their own weakness. Those who don=92t like to make waves=97or enemies. =A0 =A0Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It=92s the reductionist approach to life: if you keep it small, you=92ll keep it under control. If you don=92t make any noise, the bogeyman won=92t find you. =A0 =A0But it=92s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! >From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. =A0 =A0I choose my own way to burn.=94 =A0 =A0Sophie Scholl From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 19:25:46 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 948CE106564A; Fri, 2 Mar 2012 19:25:44 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Fri, 2 Mar 2012 14:25:32 -0500 User-Agent: KMail/1.6.2 References: <20120227152238.GA2940@regency.nsu.ru> <201203011655.05964.jkim@FreeBSD.org> <20120302085012.GA25811@regency.nsu.ru> In-Reply-To: <20120302085012.GA25811@regency.nsu.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_u6RUPjiXMRgeD5V" Message-Id: <201203021425.34456.jkim@FreeBSD.org> Cc: Alexey Dokuchaev , Hans Petter Selasky Subject: Re: Resume broken in 8.3-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: Fri, 02 Mar 2012 19:25:46 -0000 --Boundary-00=_u6RUPjiXMRgeD5V Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Friday 02 March 2012 03:50 am, Alexey Dokuchaev wrote: > On Thu, Mar 01, 2012 at 04:55:03PM -0500, Jung-uk Kim wrote: > > It does not make a difference for me (i.e., usb suspend/resume > > still broken) but I think I found a typo: > > > > --- sys/dev/usb/controller/usb_controller.c (revision 232365) > > +++ sys/dev/usb/controller/usb_controller.c (working copy) > > @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm) > > > > USB_BUS_UNLOCK(bus); > > > > - bus_generic_shutdown(bus->bdev); > > + bus_generic_suspend(bus->bdev); > > > > usbd_enum_lock(udev); > > Same thing here, does not seem to improve anything. It might > suspend, resume (with keyboard working), then die on next suspend > completely. Or it may die on the first suspend (without suspending > -- fans are spinning, screen is black and no response to anything > except hard power-off), this actually happens more often. Try the attached patch. At least, it fixed my problem. > ./danfe > > P.S. Also, doing "ps" in debugger shows that acpiconf(8) is > running in the userland upon resume (and hang). Not sure if it > helps or not though. It usually means a device driver couldn't resume (and hang). Jung-uk Kim --Boundary-00=_u6RUPjiXMRgeD5V Content-Type: text/plain; charset="iso-8859-1"; name="usb.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="usb.diff" Index: sys/dev/usb/controller/usb_controller.c =================================================================== --- sys/dev/usb/controller/usb_controller.c (revision 232401) +++ sys/dev/usb/controller/usb_controller.c (working copy) @@ -89,10 +89,15 @@ TUNABLE_INT("hw.usb.no_boot_wait", &usb_no_boot_wa SYSCTL_INT(_hw_usb, OID_AUTO, no_boot_wait, CTLFLAG_RDTUN, &usb_no_boot_wait, 0, "No USB device enumerate waiting at boot."); +static int usb_no_suspend_wait = 0; +TUNABLE_INT("hw.usb.no_suspend_wait", &usb_no_suspend_wait); +SYSCTL_INT(_hw_usb, OID_AUTO, no_suspend_wait, CTLFLAG_RW|CTLFLAG_TUN, + &usb_no_suspend_wait, 0, "No USB device waiting at system suspend."); + static int usb_no_shutdown_wait = 0; TUNABLE_INT("hw.usb.no_shutdown_wait", &usb_no_shutdown_wait); -SYSCTL_INT(_hw_usb, OID_AUTO, no_shutdown_wait, CTLFLAG_RW|CTLFLAG_TUN, &usb_no_shutdown_wait, 0, - "No USB device waiting at system shutdown."); +SYSCTL_INT(_hw_usb, OID_AUTO, no_shutdown_wait, CTLFLAG_RW|CTLFLAG_TUN, + &usb_no_shutdown_wait, 0, "No USB device waiting at system shutdown."); static devclass_t usb_devclass; @@ -240,6 +245,11 @@ usb_suspend(device_t dev) USB_BUS_LOCK(bus); usb_proc_msignal(&bus->explore_proc, &bus->suspend_msg[0], &bus->suspend_msg[1]); + if (usb_no_suspend_wait == 0) { + /* wait for suspend callback to be executed */ + usb_proc_mwait(&bus->explore_proc, + &bus->suspend_msg[0], &bus->suspend_msg[1]); + } USB_BUS_UNLOCK(bus); return (0); @@ -407,7 +417,7 @@ usb_bus_suspend(struct usb_proc_msg *pm) USB_BUS_UNLOCK(bus); - bus_generic_shutdown(bus->bdev); + bus_generic_suspend(bus->bdev); usbd_enum_lock(udev); --Boundary-00=_u6RUPjiXMRgeD5V-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 19:32:50 2012 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 B7E79106566C for ; Fri, 2 Mar 2012 19:32:50 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 717828FC12 for ; Fri, 2 Mar 2012 19:32:50 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1S3YE2-000JlZ-5H; Fri, 02 Mar 2012 23:33:10 +0400 Date: Fri, 2 Mar 2012 23:33:10 +0400 From: Slawa Olhovchenkov To: Adam Vande More Message-ID: <20120302193310.GB52973@zxy.spb.ru> References: <20120302181707.GI97848@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: stable@freebsd.org Subject: Re: Long delay on boot 9.0R on vmware+zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 19:32:50 -0000 On Fri, Mar 02, 2012 at 12:25:24PM -0600, Adam Vande More wrote: > On Fri, Mar 2, 2012 at 12:17 PM, Slawa Olhovchenkov wrote: > > > Long delay (more 30 seconds) on loader disk detect. > > Debug print pointed to zfs/zfs.c:zfs_dev_init. > > This function found disk0 and walked over 128 potencial slices, trying > > 'p' slice and 's' slice. Each attempt -- 1/4s (and nothing found). > > > > How to speed up boot? > > > > Sounds quite similar to this: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 Need to re-open? From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 19:44:54 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADD391065673 for ; Fri, 2 Mar 2012 19:44:54 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 81DFC8FC22 for ; Fri, 2 Mar 2012 19:44:54 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 01FB25635E; Fri, 2 Mar 2012 13:44:54 -0600 (CST) Date: Fri, 2 Mar 2012 13:44:53 -0600 From: Mark Linimon To: Matthew Seaman Message-ID: <20120302194453.GA27078@lonesome.com> References: <18c325310044439cbc4d03c7e0bbec52@dizum.com> <20120302164505.GA1500@lonesome.com> <4F51118B.40800@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F51118B.40800@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@FreeBSD.org Subject: Re: ports usable or not [was: flowtable usable or not] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 19:44:54 -0000 Yeah, I've been trying to prioritize some -exps that are blocking other people right now. I know there's many more :-) mcl From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 19:50:50 2012 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 053201065675; Fri, 2 Mar 2012 19:50:50 +0000 (UTC) (envelope-from hm@hm.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [187.95.0.181]) by mx1.freebsd.org (Postfix) with ESMTP id 9BCB78FC16; Fri, 2 Mar 2012 19:50:48 +0000 (UTC) Received: from pop1.hm.net.br (pop1.hm.net.br [186.222.208.104]) by msrv.matik.com.br (8.14.5/8.14.5) with ESMTP id q22IgauI001171; Fri, 2 Mar 2012 15:42:36 -0300 (BRT) (envelope-from hm@hm.net.br) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at msrv.matik.com.br X-DKIM: OpenDKIM Filter v2.4.3 msrv.matik.com.br q22IgauI001171 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hm.net.br; s=racoon; t=1330713757; bh=iNFYJMaLAV+vSqaoF8tpWS/U5jt+SlUKxyZkK034ZSc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=JDpbl4BdPu+HGznHRlynwfcbpE25xuBU704+x7YLfpxr3cmD+G0WdeJzu8YOFsjMO dsiqph2x8w8DaJQ1gpqOPGAWG4JkklNgIohbMF82uxxIxwXfRdSu8r7P9/CQpq2XLK Ae7t17ai0GT32ePOzUz0A3rowtQg80MHPZodXmig= Authentication-Results: msrv.matik.com.br; sender-id=pass header.from=hm@hm.net.br; spf=pass smtp.mfrom=hm@hm.net.br Message-ID: <4F511496.50106@hm.net.br> Date: Fri, 02 Mar 2012 15:42:30 -0300 From: H User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Firefox/10.0.2 SeaMonkey/2.7.2 MIME-Version: 1.0 To: Doug Barton References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> In-Reply-To: <4F510FBD.50008@FreeBSD.org> X-Enigmail-Version: 1.3.5 OpenPGP: id=9C63083C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEB9B2FD118953C31FB313F98" X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL, BAYES_00, T_DKIM_INVALID, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2-hm_201202.c X-Spam-Checker-Version: SpamAssassin 3.3.2-hm_201202.c (2011-06-06) on msrv.matik.com.br Cc: stable@freebsd.org, "K. Macy" , =?UTF-8?B?eiBXxIVzaWtvd3NraQ==?= , Arnaud Lacombe , "Bjoern A. Zeeb" , Alexander Leidinger , current@freebsd.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 19:50:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEB9B2FD118953C31FB313F98 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Doug Barton wrote: > ... and here is the crux of the problem. The vast majority of our > developers don't use FreeBSD as their regular workstation. So it has > increasingly become an OS where changes are being lobbed over the wall > by developers who don't run systems that those changes affect. That's > no way to run a railroad. Doug=20 wow since it is not April 1st it must be revelation's day ...:) is this then the bottomline ? if [ $using_ports=3DYES ]; get_screwed($big_time); fi --=20 H --------------enigEB9B2FD118953C31FB313F98 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9RFJYACgkQvKVfg5xjCDwXLACeNB7JfZtzY7IdkmRujP01UhOr g6sAoI1QU8OaWuOWFv4TiYxu0Q/BESbh =aelT -----END PGP SIGNATURE----- --------------enigEB9B2FD118953C31FB313F98-- From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 21:27:03 2012 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 D5C23106566B; Fri, 2 Mar 2012 21:27:03 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B2AFA8FC08; Fri, 2 Mar 2012 21:27:02 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA29220; Fri, 02 Mar 2012 23:27:00 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1S3a0C-000GDI-6n; Fri, 02 Mar 2012 23:27:00 +0200 Message-ID: <4F513B2D.6010809@FreeBSD.org> Date: Fri, 02 Mar 2012 23:27:09 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: Doug Barton References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> In-Reply-To: <4F510FBD.50008@FreeBSD.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 21:27:03 -0000 on 02/03/2012 20:21 Doug Barton said the following: > ... and here is the crux of the problem. The vast majority of our > developers don't use FreeBSD as their regular workstation. Do you care to back this up with facts? Or are you going beyond constructive in your [self-]criticism of FreeBSD [OS, developers, procedures, community, etc]? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 21:28:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D6F91065670 for ; Fri, 2 Mar 2012 21:28:07 +0000 (UTC) (envelope-from gallasch@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) by mx1.freebsd.org (Postfix) with ESMTP id 47D008FC0A for ; Fri, 2 Mar 2012 21:28:05 +0000 (UTC) Received: (qmail 74319 invoked from network); 2 Mar 2012 22:01:23 +0100 Received: from smtp.free.de (HELO orwell.free.de) (gallasch@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 2 Mar 2012 22:01:23 +0100 From: Kai Gallasch Content-Type: text/plain; charset=us-ascii Message-Id: <719F8E0E-F88D-48E7-B2B7-ABA44B4F4163@free.de> Date: Fri, 2 Mar 2012 22:01:23 +0100 To: freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: FreeBSD 9.0 release - memstick installation fails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 21:28:07 -0000 Hi list. Trying to install 9.0 release with a USB stick. I use FreeBSD-9.0-RELEASE-amd64-memstick.img At first the bootup looks promising, but in the end it stops with "Root = mount waiting for: usbus2 usbus1 usbus" To single out a bad USB stick I tried = FreeBSD-8.3-BETA1-amd64-memstick.img with the same stick and there are = no problems. The hardware is an older HP/Compaq DL145-G3, but why toss it in the = trash? How can I debug this further? Any hints? Kai. ---- snip ---- SMAP type=3D01 base=3D0000000000000000 len=3D000000000009c000 SMAP type=3D02 base=3D000000000009c000 len=3D0000000000004000 SMAP type=3D02 base=3D00000000000ce000 len=3D0000000000032000 SMAP type=3D01 base=3D0000000000100000 len=3D00000000dbe60000 SMAP type=3D03 base=3D00000000dbf60000 len=3D0000000000007000 SMAP type=3D04 base=3D00000000dbf67000 len=3D0000000000019000 SMAP type=3D02 base=3D00000000dbf80000 len=3D0000000000080000 SMAP type=3D02 base=3D00000000e0000000 len=3D0000000010000000 SMAP type=3D02 base=3D00000000fec00000 len=3D0000000000003000 SMAP type=3D02 base=3D00000000fee00000 len=3D0000000000001000 SMAP type=3D02 base=3D00000000fff80000 len=3D0000000000080000 SMAP type=3D01 base=3D0000000100000000 len=3D0000000124000000 Table 'FACP' at 0xdbf62be7 Table 'SPMI' at 0xdbf66bf5 Table 'SSDT' at 0xdbf66c35 Table 'HPET' at 0xdbf66e7d Table 'SSDT' at 0xdbf66eb5 Table 'MCFG' at 0xdbf66efe Table 'SPCR' at 0xdbf66f3a Table 'APIC' at 0xdbf66f8a APIC: Found table at 0xdbf66f8a APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Table 'FACP' at 0xdbf62be7 Table 'SPMI' at 0xdbf66bf5 Table 'SSDT' at 0xdbf66c35 Table 'HPET' at 0xdbf66e7d Table 'SSDT' at 0xdbf66eb5 Table 'MCFG' at 0xdbf66efe Table 'SPCR' at 0xdbf66f3a Table 'APIC' at 0xdbf66f8a ACPI: No SRAT table found Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff813cf000. Calibrating TSC clock ... TSC clock: 2394059007 Hz CPU: Dual-Core AMD Opteron(tm) Processor 2216 HE (2394.06-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 8589934592 (8192 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000097fff, 618496 bytes (151 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x0000000001403000 - 0x00000000dbf5ffff, 3669348352 bytes (895837 pages) 0x0000000100000000 - 0x0000000213e45fff, 4628701184 bytes (1130054 = pages) avail memory =3D 8244486144 (7862 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x001000-0x001fff at 0xffffff8000220000 x86bios: EBDA 0x09c000-0x09ffff at 0xfffffe000009c000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xf8510 00024 (v02 PTLTD ) ACPI: XSDT 0xdbf62b83 00064 (v01 PTLTD ? XSDT 06040000 LTP 00000000) ACPI: FACP 0xdbf62be7 00084 (v02 HP TREX 06040000 MSFT 02000001) ACPI: DSDT 0xdbf62c6b 03F8A (v01 HP TREX 06040000 MSFT 02000002) ACPI: FACS 0xdbf6ffc0 00040 ACPI: SPMI 0xdbf66bf5 00040 (v05 HP TREX 06040000 PTL 00000001) ACPI: SSDT 0xdbf66c35 00248 (v01 PTLTD POWERNOW 06040000 LTP 00000001) ACPI: HPET 0xdbf66e7d 00038 (v01 BRCM EXPLOSN 06040000 BRCM 02000001) ACPI: SSDT 0xdbf66eb5 00049 (v01 PTLTD SSDT 06040000 AMD 02000001) ACPI: MCFG 0xdbf66efe 0003C (v01 PTLTD MCFG 06040000 AMD 02000001) ACPI: SPCR 0xdbf66f3a 00050 (v01 PTLTD $UCRTBL$ 06040000 PTL 00000001) ACPI: APIC 0xdbf66f8a 00076 (v01 PTLTD APIC 06040000 LTP 00000000) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 3, Interrupt 16 at 0xfec01000 MADT: Found IO APIC ID 4, Interrupt 32 at 0xfec02000 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high MADT: Forcing active-low polarity and level trigger for SCI ioapic0: intpin 9 polarity: low ioapic0: intpin 9 trigger: level ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard ioapic2 irqs 32-47 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 snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff = [1024] feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D5 = feeder_rate_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 wlan: <802.11 Link Layer> random: kbd: new array size 4 kbd1 at kbdmux0 nfslock: pseudo-device mem: io: null: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: Power Button (fixed) unknown: I/O range not supported ACPI timer: 0/4 1/3 1/3 1/3 0/4 1/3 0/4 1/3 1/3 0/4 -> 6 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 10 11 Validation 0 10 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 10 11 Validation 0 255 N 0 10 11 After Disable 0 255 N 0 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 11 Validation 0 255 N 0 5 7 11 After Disable 0 255 N 0 5 7 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link8: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link9: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link10: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 7 11 12 14 15 Validation 0 5 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link11: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link12: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link13: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link14: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link15: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link16: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link17: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link18: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link19: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 5 7 11 12 14 15 Validation 0 7 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link20: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link21: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link22: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link23: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 7 11 12 14 15 Validation 0 5 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link24: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link25: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link26: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link27: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link28: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link29: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link30: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link31: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link32: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link33: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 11 12 14 15 Validation 0 11 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 pci_link34: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 Validation 0 255 N 0 3 4 5 7 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 11 12 14 15 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 hpet0: vendor 0x1166, rev 0x1, 14318180Hz 64bit, 3 timers, legacy route hpet0: t0: irqs 0xffffffff (0), periodic hpet0: t1: irqs 0xffffffff (0), periodic hpet0: t2: irqs 0xffffffff (0), periodic Timecounter "HPET" frequency 14318180 Hz quality 950 ioapic1: routing intpin 0 (PCI IRQ 16) to lapic 0 vector 49 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 450 Event timer "HPET2" frequency 14318180 Hz quality 450 pcib0: on acpi0 pcib0: decoding 4 range 0-0x3af pcib0: decoding 4 range 0x3e0-0xfff pcib0: decoding 4 range 0x3b0-0x3df pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 4 range 0x1000-0x2fff pcib0: decoding 4 range 0x3000-0xffff pcib0: decoding 3 range 0xdf000000-0xdfcfffff pcib0: decoding 3 range 0xde000000-0xdeffffff pcib0: decoding 3 range 0xfe000000-0xfebfffff pcib0: decoding 3 range 0xfec04000-0xfecfffff pcib0: decoding 3 range 0xfed00400-0xfed07fff pcib0: decoding 3 range 0xfed08008-0xfedfffff pcib0: decoding 3 range 0xfee01000-0xffffffff ACPI: Found matching pin for 0.3.INTA at func 0: 10 pci0: on pcib0 pci0: domain=3D0, physical bus=3D0 found-> vendor=3D0x1166, dev=3D0x0036, revid=3D0x00 domain=3D0, bus=3D0, slot=3D1, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0147, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) found-> vendor=3D0x1166, dev=3D0x0205, revid=3D0x00 domain=3D0, bus=3D0, slot=3D2, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0147, statreg=3D0x0200, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) found-> vendor=3D0x1166, dev=3D0x0214, revid=3D0x00 domain=3D0, bus=3D0, slot=3D2, func=3D1 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0155, statreg=3D0x0210, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) powerspec 2 supports D0 D3 current D0 pcib0: allocated type 4 (0x1f0-0x1f7) for rid 10 of pci0:0:2:1 pcib0: allocated type 4 (0x3f6-0x3f6) for rid 14 of pci0:0:2:1 pcib0: allocated type 4 (0x170-0x177) for rid 18 of pci0:0:2:1 pcib0: allocated type 4 (0x376-0x376) for rid 1c of pci0:0:2:1 map[20]: type I/O Port, range 32, base 0x1c00, size 4, enabled pcib0: allocated type 4 (0x1c00-0x1c0f) for rid 20 of pci0:0:2:1 found-> vendor=3D0x1166, dev=3D0x0234, revid=3D0x00 domain=3D0, bus=3D0, slot=3D2, func=3D2 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0147, statreg=3D0x0200, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) found-> vendor=3D0x1166, dev=3D0x0223, revid=3D0x01 domain=3D0, bus=3D0, slot=3D3, func=3D0 class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0157, statreg=3D0x02b0, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xdfc05000, size 12, = enabled pcib0: allocated type 3 (0xdfc05000-0xdfc05fff) for rid 10 of pci0:0:3:0 map[14]: type I/O Port, range 32, base 0x1000, size 8, enabled pcib0: allocated type 4 (0x1000-0x10ff) for rid 14 of pci0:0:3:0 pcib0: matched entry for 0.3.INTA (src \_SB_.LNKU:0) ioapic0: Changing trigger for pin 10 to level ioapic0: Changing polarity for pin 10 to low pcib0: slot 3 INTA routed to irq 10 via \_SB_.LNKU found-> vendor=3D0x1166, dev=3D0x0223, revid=3D0x01 domain=3D0, bus=3D0, slot=3D3, func=3D1 class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0157, statreg=3D0x02b0, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xdfc06000, size 12, = enabled pcib0: allocated type 3 (0xdfc06000-0xdfc06fff) for rid 10 of pci0:0:3:1 map[14]: type I/O Port, range 32, base 0x1400, size 8, enabled pcib0: allocated type 4 (0x1400-0x14ff) for rid 14 of pci0:0:3:1 pcib0: matched entry for 0.3.INTA (src \_SB_.LNKU:0) pcib0: slot 3 INTA routed to irq 10 via \_SB_.LNKU found-> vendor=3D0x1166, dev=3D0x0223, revid=3D0x01 domain=3D0, bus=3D0, slot=3D3, func=3D2 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0117, statreg=3D0x02b0, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 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 0xdfc07000, size 12, = enabled pcib0: allocated type 3 (0xdfc07000-0xdfc07fff) for rid 10 of pci0:0:3:2 map[14]: type I/O Port, range 32, base 0x1800, size 8, enabled pcib0: allocated type 4 (0x1800-0x18ff) for rid 14 of pci0:0:3:2 pcib0: matched entry for 0.3.INTA (src \_SB_.LNKU:0) pcib0: slot 3 INTA routed to irq 10 via \_SB_.LNKU found-> vendor=3D0x102b, dev=3D0x0522, revid=3D0x02 domain=3D0, bus=3D0, slot=3D4, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D16 (dwords) lattimer=3D0x80 (3840 ns), mingnt=3D0x10 (4000 ns), maxlat=3D0x20 = (8000 ns) intpin=3Da, irq=3D5 powerspec 1 supports D0 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xde000000, = size 24, enabled pcib0: allocated type 3 (0xde000000-0xdeffffff) for rid 10 of pci0:0:4:0 map[14]: type Memory, range 32, base 0xdfc00000, size 14, = enabled pcib0: allocated type 3 (0xdfc00000-0xdfc03fff) for rid 14 of pci0:0:4:0 map[18]: type Memory, range 32, base 0xdf000000, size 23, = enabled pcib0: allocated type 3 (0xdf000000-0xdf7fffff) for rid 18 of pci0:0:4:0 pcib0: matched entry for 0.4.INTA pcib0: slot 4 INTA hardwired to IRQ 23 found-> vendor=3D0x1166, dev=3D0x0140, revid=3D0xa2 domain=3D0, bus=3D0, slot=3D6, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0147, statreg=3D0x4010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) intpin=3Da, irq=3D11 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, 64 bit pcib0: matched entry for 0.6.INTA pcib0: slot 6 INTA hardwired to IRQ 32 found-> vendor=3D0x1166, dev=3D0x0142, revid=3D0xa2 domain=3D0, bus=3D0, slot=3D7, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0147, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) intpin=3Da, irq=3D11 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, 64 bit pcib0: matched entry for 0.7.INTA pcib0: slot 7 INTA hardwired to IRQ 32 found-> vendor=3D0x1166, dev=3D0x0144, revid=3D0xa2 domain=3D0, bus=3D0, slot=3D8, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0147, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) intpin=3Da, irq=3D11 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, 64 bit pcib0: matched entry for 0.8.INTA pcib0: slot 8 INTA hardwired to IRQ 32 found-> vendor=3D0x1166, dev=3D0x0142, revid=3D0xa2 domain=3D0, bus=3D0, slot=3D9, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0147, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) intpin=3Da, irq=3D11 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, 64 bit pcib0: matched entry for 0.9.INTA pcib0: slot 9 INTA hardwired to IRQ 32 found-> vendor=3D0x1166, dev=3D0x0144, revid=3D0xa2 domain=3D0, bus=3D0, slot=3D10, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0147, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) intpin=3Da, irq=3D11 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, 64 bit pcib0: matched entry for 0.10.INTA pcib0: slot 10 INTA hardwired to IRQ 32 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) pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 2 pcib1: no prefetched decode pci1: on pcib1 pci1: domain=3D0, physical bus=3D1 found-> vendor=3D0x1166, dev=3D0x0104, revid=3D0xc0 domain=3D0, bus=3D1, slot=3D13, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0157, statreg=3D0x0230, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x02 = (500 ns) pcib2: at device 13.0 on pci1 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: no prefetched decode pci2: on pcib2 pci2: domain=3D0, physical bus=3D2 atapci0: port = 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1c00-0x1c0f at device 2.1 on pci0 ata0: on atapci0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 50 ata1: on atapci0 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 51 isab0: at device 2.2 on pci0 isa0: on isab0 ohci0: port 0x1000-0x10ff mem = 0xdfc05000-0xdfc05fff irq 10 at device 3.0 on pci0 ohci0: (New OHCI DeviceId=3D0x02231166) ioapic0: routing intpin 10 (ISA IRQ 10) to lapic 0 vector 52 usbus0: on ohci0 usbus0: bpf attached ohci0: usbpf: Attached ohci1: port 0x1400-0x14ff mem = 0xdfc06000-0xdfc06fff irq 10 at device 3.1 on pci0 ohci1: (New OHCI DeviceId=3D0x02231166) usbus1: on ohci1 usbus1: bpf attached ohci1: usbpf: Attached ehci0: port 0x1800-0x18ff mem = 0xdfc07000-0xdfc07fff irq 10 at device 3.2 on pci0 ehci0: (New EHCI DeviceId=3D0x02231166) usbus2: EHCI version 1.0 usbus2: on ehci0 usbus2: bpf attached ehci0: usbpf: Attached vgapci0: mem = 0xde000000-0xdeffffff,0xdfc00000-0xdfc03fff,0xdf000000-0xdf7fffff irq 23 = at device 4.0 on pci0 pcib3: irq 32 at device 6.0 on pci0 pcib0: allocated type 4 (0x2000-0x2fff) for rid 1c of pcib3 pcib0: allocated type 3 (0xdfa00000-0xdfafffff) for rid 20 of pcib3 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x2000-0x2fff pcib3: memory decode 0xdfa00000-0xdfafffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=3D0, physical bus=3D3 found-> vendor=3D0x1000, dev=3D0x0058, revid=3D0x08 domain=3D0, bus=3D3, slot=3D0, func=3D0 class=3D01-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0147, statreg=3D0x4010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = 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 0x2000, size 8, enabled pcib3: allocated I/O port range (0x2000-0x20ff) for rid 10 of pci0:3:0:0 map[14]: type Memory, range 64, base 0xdfa10000, size 14, = enabled pcib3: allocated memory range (0xdfa10000-0xdfa13fff) for rid 14 of = pci0:3:0:0 map[1c]: type Memory, range 64, base 0xdfa00000, size 16, = enabled pcib3: allocated memory range (0xdfa00000-0xdfa0ffff) for rid 1c of = pci0:3:0:0 pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 32 mpt0: port 0x2000-0x20ff mem = 0xdfa10000-0xdfa13fff,0xdfa00000-0xdfa0ffff irq 32 at device 0.0 on pci3 mpt0: attempting to allocate 1 MSI-X vectors (1 supported) msi: routing MSI-X IRQ 256 to local APIC 0 vector 53 mpt0: using IRQ 256 for MSI-X mpt0: MPI Version=3D1.5.20.0 mpt0: chain depth limited to 34 (from 2040) mpt0: Maximum Segment Count: 306, Maximum CAM Segment Count: 33 mpt0: MsgLength=3D20 IOCNumber =3D 0 mpt0: IOCFACTS: GlobalCredits=3D483 BlockSize=3D8 bytes Request Frame = Size 128 bytes Max Chain Depth 34 mpt0: IOCFACTS: Num Ports 1, FWImageSize 0, Flags=3D0x2 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 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 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: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not = required). mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not = required). pcib4: irq 32 at device 7.0 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: no prefetched decode pci4: on pcib4 pci4: domain=3D0, physical bus=3D4 pcib5: irq 32 at device 8.0 on pci0 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: no prefetched decode pci5: on pcib5 pci5: domain=3D0, physical bus=3D5 pcib6: irq 32 at device 9.0 on pci0 pcib6: domain 0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: no prefetched decode pci6: on pcib6 pci6: domain=3D0, physical bus=3D6 pcib7: irq 32 at device 10.0 on pci0 pcib0: allocated type 3 (0xdfb00000-0xdfbfffff) for rid 20 of pcib7 pcib7: domain 0 pcib7: secondary bus 7 pcib7: subordinate bus 8 pcib7: memory decode 0xdfb00000-0xdfbfffff pcib7: no prefetched decode pcib7: could not get PCI interrupt routing table for \_SB_.PCI0.EXB4 - = AE_NOT_FOUND pci7: on pcib7 pci7: domain=3D0, physical bus=3D7 found-> vendor=3D0x1166, dev=3D0x0103, revid=3D0xb5 domain=3D0, bus=3D7, slot=3D0, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0147, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) powerspec 2 supports D0 D3 current D0 pcib8: at device 0.0 on pci7 pcib7: allocated memory range (0xdfb00000-0xdfbfffff) for rid 20 of = pcib8 pcib8: domain 0 pcib8: secondary bus 8 pcib8: subordinate bus 8 pcib8: memory decode 0xdfb00000-0xdfbfffff pcib8: no prefetched decode pci8: on pcib8 pci8: domain=3D0, physical bus=3D8 found-> vendor=3D0x14e4, dev=3D0x1678, revid=3D0xa3 domain=3D0, bus=3D8, slot=3D4, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0156, statreg=3D0x02b0, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x40 (16000 ns), maxlat=3D0x00= (0 ns) intpin=3Da, irq=3D5 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type Memory, range 64, base 0xdfb10000, size 16, = enabled pcib8: allocated memory range (0xdfb10000-0xdfb1ffff) for rid 10 of = pci0:8:4:0 map[18]: type Memory, range 64, base 0xdfb00000, size 16, = enabled pcib8: allocated memory range (0xdfb00000-0xdfb0ffff) for rid 18 of = pci0:8:4:0 pcib8: matched entry for 8.4.INTA pcib8: slot 4 INTA hardwired to IRQ 36 found-> vendor=3D0x14e4, dev=3D0x1678, revid=3D0xa3 domain=3D0, bus=3D8, slot=3D4, func=3D1 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0156, statreg=3D0x02b0, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x40 (16000 ns), maxlat=3D0x00= (0 ns) intpin=3Db, irq=3D5 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type Memory, range 64, base 0xdfb30000, size 16, = enabled pcib8: allocated memory range (0xdfb30000-0xdfb3ffff) for rid 10 of = pci0:8:4:1 map[18]: type Memory, range 64, base 0xdfb20000, size 16, = enabled pcib8: allocated memory range (0xdfb20000-0xdfb2ffff) for rid 18 of = pci0:8:4:1 pcib8: matched entry for 8.4.INTB pcib8: slot 4 INTB hardwired to IRQ 36 bge0: mem 0xdfb10000-0xdfb1ffff,0xdfb00000-0xdfb0ffff irq 36 at = device 4.0 on pci8 bge0: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 54 bge0: using IRQ 257 for MSI bge0: CHIP ID 0x00009003; ASIC REV 0x09; CHIP REV 0x90; PCI-X miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x001018, model 0x0034, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: 00:18:71:87:0f:ac bge1: mem 0xdfb30000-0xdfb3ffff,0xdfb20000-0xdfb2ffff irq 36 at = device 4.1 on pci8 bge1: attempting to allocate 1 MSI vectors (8 supported) msi: routing MSI IRQ 258 to local APIC 0 vector 55 bge1: using IRQ 258 for MSI bge1: CHIP ID 0x00009003; ASIC REV 0x09; CHIP REV 0x90; PCI-X miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: OUI 0x001018, model 0x0034, rev. 0 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: bpf attached bge1: Ethernet address: 00:18:71:87:64:f6 atrtc0: port 0x70-0x71,0x72-0x73 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, = adjustment 0.500000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 56 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 57 Event timer "i8254" frequency 1193182 Hz quality 100 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0xffffffff (1) kbdc: RESET_KBD return code:00fe kbdc: RESET_KBD return code:00fe kbdc: RESET_KBD return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 atkbd: failed to reset the keyboard. kbd0 at atkbd0 kbd0: atkbd0, AT 84 (1), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 58 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 59 uart0: fast interrupt uart0: console (9600,n,8,1) acpi0: wakeup code va 0xffffff8233373000 pa 0x4000 ex_isa_identify() ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 1: ioport 0x1c00 alloc failed ahc_isa_probe 2: ioport 0x2c00 alloc failed ahc_isa_probe 3: ioport 0x3c00 alloc failed ahc_isa_probe 4: ioport 0x4c00 alloc failed ahc_isa_probe 5: ioport 0x5c00 alloc failed ahc_isa_probe 6: ioport 0x6c00 alloc failed ahc_isa_probe 7: ioport 0x7c00 alloc failed ahc_isa_probe 8: ioport 0x8c00 alloc failed ahc_isa_probe 9: ioport 0x9c00 alloc failed ahc_isa_probe 10: ioport 0xac00 alloc failed ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 12: ioport 0xcc00 alloc failed ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices 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 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 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 pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices powernow0: on cpu0 powernow1: on cpu1 Device configuration finished. procfs registered Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached hptrr: no controller detected. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ata0: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D7f ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata0: stat1=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata0: reset tp2 stat0=3Dff stat1=3Dff devices=3D0x0 ata1: reset tp1 mask=3D00 ostat0=3Dff ostat1=3Dff ugen0.1: <0x1166> at usbus0 uhub0: <0x1166 OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on = usbus0 ugen1.1: <0x1166> at usbus1 uhub1: <0x1166 OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on = usbus1 ugen2.1: <0x1166> at usbus2 uhub2: <0x1166 EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on = usbus2 pass0 at mpt0 bus 0 scbus2 target 17 lun 0 pass0: Fixed Direct Access SCSI-5 device pass0: Serial Number 3QQ254BL000090107KK2 pass0: 300.000MB/s transfers pass0: Command Queueing enabled pass1 at mpt0 bus 0 scbus2 target 18 lun 0 pass1: Fixed Direct Access SCSI-5 device pass1: Serial Number 3QQ25C8600009010SDER pass1: 300.000MB/s transfers pass1: Command Queueing enabled da0 at mpt0 bus 0 scbus2 target 17 lun 0 da0: Fixed Direct Access SCSI-5 device da0: Serial Number 3QQ254BL000090107KK2 da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 429247MB (879097968 512 byte sectors: 255H 63S/T 54721C) da1 at mpt0 bus 0 scbus2 target 18 lun 0 da1: Fixed Direct Access SCSI-5 device da1: Serial Number 3QQ25C8600009010SDER da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 429247MB (879097968 512 byte sectors: 255H 63S/T 54721C) SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 TSC timecounter discards lower 8 bit(s) GEOM: new disk da0 Timecounter "TSC-low" frequency 9351792 Hz quality -100 GEOM: new disk da1 Root mount waiting for: usbus2 usbus1 usbus0 From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 22:01:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37CAB1065677 for ; Fri, 2 Mar 2012 22:01:40 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id BAD048FC18 for ; Fri, 2 Mar 2012 22:01:39 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q22LoJpD064930; Fri, 2 Mar 2012 13:50:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1330725020; bh=5AgksalaAGDMpxXztffquK2QNbf/5BKYkjxsqxuandM=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=NNY/BO1cc/ZuwJx016ULoRoh5Q2c8cut0u0Gsi3FfFIZSZONDt4CftFZDVbKQhoXM sBo1sD83s9K+BKqDAGX6OWTJM479C+ImlvCAHfSobJlCrdkL6KKh+FEJ42aPBUvXCs XRbM3NIWpBLHBM95NNHXIe1iVdo+hGGgcTE67lp0= From: Sean Bruno To: Kai Gallasch In-Reply-To: <719F8E0E-F88D-48E7-B2B7-ABA44B4F4163@free.de> References: <719F8E0E-F88D-48E7-B2B7-ABA44B4F4163@free.de> Content-Type: text/plain; charset="UTF-8" Date: Fri, 02 Mar 2012 13:50:18 -0800 Message-ID: <1330725018.5391.5.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-stable@freebsd.org" Subject: Re: FreeBSD 9.0 release - memstick installation fails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 22:01:40 -0000 You may want to try playing around with BIOS settings regarding USB. Sean On Fri, 2012-03-02 at 13:01 -0800, Kai Gallasch wrote: > Hi list. > > Trying to install 9.0 release with a USB stick. > I use FreeBSD-9.0-RELEASE-amd64-memstick.img > > At first the bootup looks promising, but in the end it stops with "Root mount waiting for: usbus2 usbus1 usbus" > > To single out a bad USB stick I tried FreeBSD-8.3-BETA1-amd64-memstick.img with the same stick and there are no problems. > > The hardware is an older HP/Compaq DL145-G3, but why toss it in the trash? > > How can I debug this further? > Any hints? > > Kai. > > > ---- snip ---- > > SMAP type=01 base=0000000000000000 len=000000000009c000 > SMAP type=02 base=000000000009c000 len=0000000000004000 > SMAP type=02 base=00000000000ce000 len=0000000000032000 > SMAP type=01 base=0000000000100000 len=00000000dbe60000 > SMAP type=03 base=00000000dbf60000 len=0000000000007000 > SMAP type=04 base=00000000dbf67000 len=0000000000019000 > SMAP type=02 base=00000000dbf80000 len=0000000000080000 > SMAP type=02 base=00000000e0000000 len=0000000010000000 > SMAP type=02 base=00000000fec00000 len=0000000000003000 > SMAP type=02 base=00000000fee00000 len=0000000000001000 > SMAP type=02 base=00000000fff80000 len=0000000000080000 > SMAP type=01 base=0000000100000000 len=0000000124000000 > Table 'FACP' at 0xdbf62be7 > Table 'SPMI' at 0xdbf66bf5 > Table 'SSDT' at 0xdbf66c35 > Table 'HPET' at 0xdbf66e7d > Table 'SSDT' at 0xdbf66eb5 > Table 'MCFG' at 0xdbf66efe > Table 'SPCR' at 0xdbf66f3a > Table 'APIC' at 0xdbf66f8a > APIC: Found table at 0xdbf66f8a > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 0: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 1 ACPI ID 1: enabled > SMP: Added CPU 1 (AP) > Copyright (c) 1992-2012 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 > root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > Table 'FACP' at 0xdbf62be7 > Table 'SPMI' at 0xdbf66bf5 > Table 'SSDT' at 0xdbf66c35 > Table 'HPET' at 0xdbf66e7d > Table 'SSDT' at 0xdbf66eb5 > Table 'MCFG' at 0xdbf66efe > Table 'SPCR' at 0xdbf66f3a > Table 'APIC' at 0xdbf66f8a > ACPI: No SRAT table found > Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff813cf000. > Calibrating TSC clock ... TSC clock: 2394059007 Hz > CPU: Dual-Core AMD Opteron(tm) Processor 2216 HE (2394.06-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x40f13 Family = f Model = 41 Stepping = 3 > Features=0x178bfbff > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x1f > 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 = 8589934592 (8192 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x0000000000097fff, 618496 bytes (151 pages) > 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) > 0x0000000001403000 - 0x00000000dbf5ffff, 3669348352 bytes (895837 pages) > 0x0000000100000000 - 0x0000000213e45fff, 4628701184 bytes (1130054 pages) > avail memory = 8244486144 (7862 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > INTR: Adding local APIC 1 as a target > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 > x86bios: SSEG 0x001000-0x001fff at 0xffffff8000220000 > x86bios: EBDA 0x09c000-0x09ffff at 0xfffffe000009c000 > x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 > APIC: CPU 0 has ACPI ID 0 > APIC: CPU 1 has ACPI ID 1 > ULE: setup cpu 0 > ULE: setup cpu 1 > ACPI: RSDP 0xf8510 00024 (v02 PTLTD ) > ACPI: XSDT 0xdbf62b83 00064 (v01 PTLTD ? XSDT 06040000 LTP 00000000) > ACPI: FACP 0xdbf62be7 00084 (v02 HP TREX 06040000 MSFT 02000001) > ACPI: DSDT 0xdbf62c6b 03F8A (v01 HP TREX 06040000 MSFT 02000002) > ACPI: FACS 0xdbf6ffc0 00040 > ACPI: SPMI 0xdbf66bf5 00040 (v05 HP TREX 06040000 PTL 00000001) > ACPI: SSDT 0xdbf66c35 00248 (v01 PTLTD POWERNOW 06040000 LTP 00000001) > ACPI: HPET 0xdbf66e7d 00038 (v01 BRCM EXPLOSN 06040000 BRCM 02000001) > ACPI: SSDT 0xdbf66eb5 00049 (v01 PTLTD SSDT 06040000 AMD 02000001) > ACPI: MCFG 0xdbf66efe 0003C (v01 PTLTD MCFG 06040000 AMD 02000001) > ACPI: SPCR 0xdbf66f3a 00050 (v01 PTLTD $UCRTBL$ 06040000 PTL 00000001) > ACPI: APIC 0xdbf66f8a 00076 (v01 PTLTD APIC 06040000 LTP 00000000) > MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 > ioapic0: Routing external 8259A's -> intpin 0 > MADT: Found IO APIC ID 3, Interrupt 16 at 0xfec01000 > MADT: Found IO APIC ID 4, Interrupt 32 at 0xfec02000 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > lapic0: Routing NMI -> LINT1 > lapic0: LINT1 trigger: edge > lapic0: LINT1 polarity: high > lapic1: Routing NMI -> LINT1 > lapic1: LINT1 trigger: edge > lapic1: LINT1 polarity: high > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0: intpin 9 polarity: low > ioapic0: intpin 9 trigger: level > ioapic0 irqs 0-15 on motherboard > ioapic1 irqs 16-31 on motherboard > ioapic2 irqs 32-47 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 > snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] > feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 > wlan: <802.11 Link Layer> > random: > kbd: new array size 4 > kbd1 at kbdmux0 > nfslock: pseudo-device > mem: > io: > null: > hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 > acpi0: on motherboard > PCIe: Memory Mapped configuration base @ 0xe0000000 > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > acpi0: Power Button (fixed) > unknown: I/O range not supported > ACPI timer: 0/4 1/3 1/3 1/3 0/4 1/3 0/4 1/3 1/3 0/4 -> 6 > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 > cpu0: on acpi0 > cpu0: switching to generic Cx mode > cpu1: on acpi0 > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 10 N 0 10 11 > Validation 0 10 N 0 10 11 > After Disable 0 255 N 0 10 11 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 10 11 > Validation 0 255 N 0 10 11 > After Disable 0 255 N 0 10 11 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 5 7 11 > Validation 0 255 N 0 5 7 11 > After Disable 0 255 N 0 5 7 11 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link4: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link5: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link6: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link7: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link8: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link9: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link10: Index IRQ Rtd Ref IRQs > Initial Probe 0 5 N 0 3 4 5 7 11 12 14 15 > Validation 0 5 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link11: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link12: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link13: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link14: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link15: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link16: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link17: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link18: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link19: Index IRQ Rtd Ref IRQs > Initial Probe 0 7 N 0 3 4 5 7 11 12 14 15 > Validation 0 7 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link20: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link21: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link22: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link23: Index IRQ Rtd Ref IRQs > Initial Probe 0 5 N 0 3 4 5 7 11 12 14 15 > Validation 0 5 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link24: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link25: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link26: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link27: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link28: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link29: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link30: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link31: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link32: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link33: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 5 7 11 12 14 15 > Validation 0 11 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > pci_link34: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 > Validation 0 255 N 0 3 4 5 7 11 12 14 15 > After Disable 0 255 N 0 3 4 5 7 11 12 14 15 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > hpet0: vendor 0x1166, rev 0x1, 14318180Hz 64bit, 3 timers, legacy route > hpet0: t0: irqs 0xffffffff (0), periodic > hpet0: t1: irqs 0xffffffff (0), periodic > hpet0: t2: irqs 0xffffffff (0), periodic > Timecounter "HPET" frequency 14318180 Hz quality 950 > ioapic1: routing intpin 0 (PCI IRQ 16) to lapic 0 vector 49 > Event timer "HPET" frequency 14318180 Hz quality 450 > Event timer "HPET1" frequency 14318180 Hz quality 450 > Event timer "HPET2" frequency 14318180 Hz quality 450 > pcib0: on acpi0 > pcib0: decoding 4 range 0-0x3af > pcib0: decoding 4 range 0x3e0-0xfff > pcib0: decoding 4 range 0x3b0-0x3df > pcib0: decoding 3 range 0xa0000-0xbffff > pcib0: decoding 4 range 0x1000-0x2fff > pcib0: decoding 4 range 0x3000-0xffff > pcib0: decoding 3 range 0xdf000000-0xdfcfffff > pcib0: decoding 3 range 0xde000000-0xdeffffff > pcib0: decoding 3 range 0xfe000000-0xfebfffff > pcib0: decoding 3 range 0xfec04000-0xfecfffff > pcib0: decoding 3 range 0xfed00400-0xfed07fff > pcib0: decoding 3 range 0xfed08008-0xfedfffff > pcib0: decoding 3 range 0xfee01000-0xffffffff > ACPI: Found matching pin for 0.3.INTA at func 0: 10 > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found-> vendor=0x1166, dev=0x0036, revid=0x00 > domain=0, bus=0, slot=1, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0147, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1166, dev=0x0205, revid=0x00 > domain=0, bus=0, slot=2, func=0 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0147, statreg=0x0200, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1166, dev=0x0214, revid=0x00 > domain=0, bus=0, slot=2, func=1 > class=01-01-8a, hdrtype=0x00, mfdev=1 > cmdreg=0x0155, statreg=0x0210, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > powerspec 2 supports D0 D3 current D0 > pcib0: allocated type 4 (0x1f0-0x1f7) for rid 10 of pci0:0:2:1 > pcib0: allocated type 4 (0x3f6-0x3f6) for rid 14 of pci0:0:2:1 > pcib0: allocated type 4 (0x170-0x177) for rid 18 of pci0:0:2:1 > pcib0: allocated type 4 (0x376-0x376) for rid 1c of pci0:0:2:1 > map[20]: type I/O Port, range 32, base 0x1c00, size 4, enabled > pcib0: allocated type 4 (0x1c00-0x1c0f) for rid 20 of pci0:0:2:1 > found-> vendor=0x1166, dev=0x0234, revid=0x00 > domain=0, bus=0, slot=2, func=2 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0147, statreg=0x0200, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1166, dev=0x0223, revid=0x01 > domain=0, bus=0, slot=3, func=0 > class=0c-03-10, hdrtype=0x00, mfdev=1 > cmdreg=0x0157, statreg=0x02b0, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xdfc05000, size 12, enabled > pcib0: allocated type 3 (0xdfc05000-0xdfc05fff) for rid 10 of pci0:0:3:0 > map[14]: type I/O Port, range 32, base 0x1000, size 8, enabled > pcib0: allocated type 4 (0x1000-0x10ff) for rid 14 of pci0:0:3:0 > pcib0: matched entry for 0.3.INTA (src \_SB_.LNKU:0) > ioapic0: Changing trigger for pin 10 to level > ioapic0: Changing polarity for pin 10 to low > pcib0: slot 3 INTA routed to irq 10 via \_SB_.LNKU > found-> vendor=0x1166, dev=0x0223, revid=0x01 > domain=0, bus=0, slot=3, func=1 > class=0c-03-10, hdrtype=0x00, mfdev=0 > cmdreg=0x0157, statreg=0x02b0, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xdfc06000, size 12, enabled > pcib0: allocated type 3 (0xdfc06000-0xdfc06fff) for rid 10 of pci0:0:3:1 > map[14]: type I/O Port, range 32, base 0x1400, size 8, enabled > pcib0: allocated type 4 (0x1400-0x14ff) for rid 14 of pci0:0:3:1 > pcib0: matched entry for 0.3.INTA (src \_SB_.LNKU:0) > pcib0: slot 3 INTA routed to irq 10 via \_SB_.LNKU > found-> vendor=0x1166, dev=0x0223, revid=0x01 > domain=0, bus=0, slot=3, func=2 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0117, statreg=0x02b0, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xdfc07000, size 12, enabled > pcib0: allocated type 3 (0xdfc07000-0xdfc07fff) for rid 10 of pci0:0:3:2 > map[14]: type I/O Port, range 32, base 0x1800, size 8, enabled > pcib0: allocated type 4 (0x1800-0x18ff) for rid 14 of pci0:0:3:2 > pcib0: matched entry for 0.3.INTA (src \_SB_.LNKU:0) > pcib0: slot 3 INTA routed to irq 10 via \_SB_.LNKU > found-> vendor=0x102b, dev=0x0522, revid=0x02 > domain=0, bus=0, slot=4, func=0 > class=03-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0290, cachelnsz=16 (dwords) > lattimer=0x80 (3840 ns), mingnt=0x10 (4000 ns), maxlat=0x20 (8000 ns) > intpin=a, irq=5 > powerspec 1 supports D0 D3 current D0 > map[10]: type Prefetchable Memory, range 32, base 0xde000000, size 24, enabled > pcib0: allocated type 3 (0xde000000-0xdeffffff) for rid 10 of pci0:0:4:0 > map[14]: type Memory, range 32, base 0xdfc00000, size 14, enabled > pcib0: allocated type 3 (0xdfc00000-0xdfc03fff) for rid 14 of pci0:0:4:0 > map[18]: type Memory, range 32, base 0xdf000000, size 23, enabled > pcib0: allocated type 3 (0xdf000000-0xdf7fffff) for rid 18 of pci0:0:4:0 > pcib0: matched entry for 0.4.INTA > pcib0: slot 4 INTA hardwired to IRQ 23 > found-> vendor=0x1166, dev=0x0140, revid=0xa2 > domain=0, bus=0, slot=6, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0147, statreg=0x4010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 3 supports D0 D3 current D0 > MSI supports 2 messages, 64 bit > pcib0: matched entry for 0.6.INTA > pcib0: slot 6 INTA hardwired to IRQ 32 > found-> vendor=0x1166, dev=0x0142, revid=0xa2 > domain=0, bus=0, slot=7, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 3 supports D0 D3 current D0 > MSI supports 2 messages, 64 bit > pcib0: matched entry for 0.7.INTA > pcib0: slot 7 INTA hardwired to IRQ 32 > found-> vendor=0x1166, dev=0x0144, revid=0xa2 > domain=0, bus=0, slot=8, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 3 supports D0 D3 current D0 > MSI supports 2 messages, 64 bit > pcib0: matched entry for 0.8.INTA > pcib0: slot 8 INTA hardwired to IRQ 32 > found-> vendor=0x1166, dev=0x0142, revid=0xa2 > domain=0, bus=0, slot=9, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 3 supports D0 D3 current D0 > MSI supports 2 messages, 64 bit > pcib0: matched entry for 0.9.INTA > pcib0: slot 9 INTA hardwired to IRQ 32 > found-> vendor=0x1166, dev=0x0144, revid=0xa2 > domain=0, bus=0, slot=10, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 3 supports D0 D3 current D0 > MSI supports 2 messages, 64 bit > pcib0: matched entry for 0.10.INTA > pcib0: slot 10 INTA hardwired to IRQ 32 > found-> vendor=0x1022, dev=0x1100, revid=0x00 > domain=0, bus=0, slot=24, func=0 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1101, revid=0x00 > domain=0, bus=0, slot=24, func=1 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1102, revid=0x00 > domain=0, bus=0, slot=24, func=2 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1103, revid=0x00 > domain=0, bus=0, slot=24, func=3 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > pcib1: at device 1.0 on pci0 > pcib1: domain 0 > pcib1: secondary bus 1 > pcib1: subordinate bus 2 > pcib1: no prefetched decode > pci1: on pcib1 > pci1: domain=0, physical bus=1 > found-> vendor=0x1166, dev=0x0104, revid=0xc0 > domain=0, bus=1, slot=13, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0157, statreg=0x0230, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x07 (1750 ns), maxlat=0x02 (500 ns) > pcib2: at device 13.0 on pci1 > pcib2: domain 0 > pcib2: secondary bus 2 > pcib2: subordinate bus 2 > pcib2: no prefetched decode > pci2: on pcib2 > pci2: domain=0, physical bus=2 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1c00-0x1c0f at device 2.1 on pci0 > ata0: on atapci0 > ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 50 > ata1: on atapci0 > ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 51 > isab0: at device 2.2 on pci0 > isa0: on isab0 > ohci0: port 0x1000-0x10ff mem 0xdfc05000-0xdfc05fff irq 10 at device 3.0 on pci0 > ohci0: (New OHCI DeviceId=0x02231166) > ioapic0: routing intpin 10 (ISA IRQ 10) to lapic 0 vector 52 > usbus0: on ohci0 > usbus0: bpf attached > ohci0: usbpf: Attached > ohci1: port 0x1400-0x14ff mem 0xdfc06000-0xdfc06fff irq 10 at device 3.1 on pci0 > ohci1: (New OHCI DeviceId=0x02231166) > usbus1: on ohci1 > usbus1: bpf attached > ohci1: usbpf: Attached > ehci0: port 0x1800-0x18ff mem 0xdfc07000-0xdfc07fff irq 10 at device 3.2 on pci0 > ehci0: (New EHCI DeviceId=0x02231166) > usbus2: EHCI version 1.0 > usbus2: on ehci0 > usbus2: bpf attached > ehci0: usbpf: Attached > vgapci0: mem 0xde000000-0xdeffffff,0xdfc00000-0xdfc03fff,0xdf000000-0xdf7fffff irq 23 at device 4.0 on pci0 > pcib3: irq 32 at device 6.0 on pci0 > pcib0: allocated type 4 (0x2000-0x2fff) for rid 1c of pcib3 > pcib0: allocated type 3 (0xdfa00000-0xdfafffff) for rid 20 of pcib3 > pcib3: domain 0 > pcib3: secondary bus 3 > pcib3: subordinate bus 3 > pcib3: I/O decode 0x2000-0x2fff > pcib3: memory decode 0xdfa00000-0xdfafffff > pcib3: no prefetched decode > pci3: on pcib3 > pci3: domain=0, physical bus=3 > found-> vendor=0x1000, dev=0x0058, revid=0x08 > domain=0, bus=3, slot=0, func=0 > class=01-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0147, statreg=0x4010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=7 > 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 0x2000, size 8, enabled > pcib3: allocated I/O port range (0x2000-0x20ff) for rid 10 of pci0:3:0:0 > map[14]: type Memory, range 64, base 0xdfa10000, size 14, enabled > pcib3: allocated memory range (0xdfa10000-0xdfa13fff) for rid 14 of pci0:3:0:0 > map[1c]: type Memory, range 64, base 0xdfa00000, size 16, enabled > pcib3: allocated memory range (0xdfa00000-0xdfa0ffff) for rid 1c of pci0:3:0:0 > pcib3: matched entry for 3.0.INTA > pcib3: slot 0 INTA hardwired to IRQ 32 > mpt0: port 0x2000-0x20ff mem 0xdfa10000-0xdfa13fff,0xdfa00000-0xdfa0ffff irq 32 at device 0.0 on pci3 > mpt0: attempting to allocate 1 MSI-X vectors (1 supported) > msi: routing MSI-X IRQ 256 to local APIC 0 vector 53 > mpt0: using IRQ 256 for MSI-X > mpt0: MPI Version=1.5.20.0 > mpt0: chain depth limited to 34 (from 2040) > mpt0: Maximum Segment Count: 306, Maximum CAM Segment Count: 33 > mpt0: MsgLength=20 IOCNumber = 0 > mpt0: IOCFACTS: GlobalCredits=483 BlockSize=8 bytes Request Frame Size 128 bytes Max Chain Depth 34 > mpt0: IOCFACTS: Num Ports 1, FWImageSize 0, Flags=0x2 > 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 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 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: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). > mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). > pcib4: irq 32 at device 7.0 on pci0 > pcib4: domain 0 > pcib4: secondary bus 4 > pcib4: subordinate bus 4 > pcib4: no prefetched decode > pci4: on pcib4 > pci4: domain=0, physical bus=4 > pcib5: irq 32 at device 8.0 on pci0 > pcib5: domain 0 > pcib5: secondary bus 5 > pcib5: subordinate bus 5 > pcib5: no prefetched decode > pci5: on pcib5 > pci5: domain=0, physical bus=5 > pcib6: irq 32 at device 9.0 on pci0 > pcib6: domain 0 > pcib6: secondary bus 6 > pcib6: subordinate bus 6 > pcib6: no prefetched decode > pci6: on pcib6 > pci6: domain=0, physical bus=6 > pcib7: irq 32 at device 10.0 on pci0 > pcib0: allocated type 3 (0xdfb00000-0xdfbfffff) for rid 20 of pcib7 > pcib7: domain 0 > pcib7: secondary bus 7 > pcib7: subordinate bus 8 > pcib7: memory decode 0xdfb00000-0xdfbfffff > pcib7: no prefetched decode > pcib7: could not get PCI interrupt routing table for \_SB_.PCI0.EXB4 - AE_NOT_FOUND > pci7: on pcib7 > pci7: domain=0, physical bus=7 > found-> vendor=0x1166, dev=0x0103, revid=0xb5 > domain=0, bus=7, slot=0, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) > powerspec 2 supports D0 D3 current D0 > pcib8: at device 0.0 on pci7 > pcib7: allocated memory range (0xdfb00000-0xdfbfffff) for rid 20 of pcib8 > pcib8: domain 0 > pcib8: secondary bus 8 > pcib8: subordinate bus 8 > pcib8: memory decode 0xdfb00000-0xdfbfffff > pcib8: no prefetched decode > pci8: on pcib8 > pci8: domain=0, physical bus=8 > found-> vendor=0x14e4, dev=0x1678, revid=0xa3 > domain=0, bus=8, slot=4, func=0 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0156, statreg=0x02b0, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) > intpin=a, irq=5 > powerspec 2 supports D0 D3 current D0 > MSI supports 8 messages, 64 bit > map[10]: type Memory, range 64, base 0xdfb10000, size 16, enabled > pcib8: allocated memory range (0xdfb10000-0xdfb1ffff) for rid 10 of pci0:8:4:0 > map[18]: type Memory, range 64, base 0xdfb00000, size 16, enabled > pcib8: allocated memory range (0xdfb00000-0xdfb0ffff) for rid 18 of pci0:8:4:0 > pcib8: matched entry for 8.4.INTA > pcib8: slot 4 INTA hardwired to IRQ 36 > found-> vendor=0x14e4, dev=0x1678, revid=0xa3 > domain=0, bus=8, slot=4, func=1 > class=02-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0156, statreg=0x02b0, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) > intpin=b, irq=5 > powerspec 2 supports D0 D3 current D0 > MSI supports 8 messages, 64 bit > map[10]: type Memory, range 64, base 0xdfb30000, size 16, enabled > pcib8: allocated memory range (0xdfb30000-0xdfb3ffff) for rid 10 of pci0:8:4:1 > map[18]: type Memory, range 64, base 0xdfb20000, size 16, enabled > pcib8: allocated memory range (0xdfb20000-0xdfb2ffff) for rid 18 of pci0:8:4:1 > pcib8: matched entry for 8.4.INTB > pcib8: slot 4 INTB hardwired to IRQ 36 > bge0: mem 0xdfb10000-0xdfb1ffff,0xdfb00000-0xdfb0ffff irq 36 at device 4.0 on pci8 > bge0: attempting to allocate 1 MSI vectors (8 supported) > msi: routing MSI IRQ 257 to local APIC 0 vector 54 > bge0: using IRQ 257 for MSI > bge0: CHIP ID 0x00009003; ASIC REV 0x09; CHIP REV 0x90; PCI-X > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: OUI 0x001018, model 0x0034, rev. 0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge0: bpf attached > bge0: Ethernet address: 00:18:71:87:0f:ac > bge1: mem 0xdfb30000-0xdfb3ffff,0xdfb20000-0xdfb2ffff irq 36 at device 4.1 on pci8 > bge1: attempting to allocate 1 MSI vectors (8 supported) > msi: routing MSI IRQ 258 to local APIC 0 vector 55 > bge1: using IRQ 258 for MSI > bge1: CHIP ID 0x00009003; ASIC REV 0x09; CHIP REV 0x90; PCI-X > miibus1: on bge1 > brgphy1: PHY 1 on miibus1 > brgphy1: OUI 0x001018, model 0x0034, rev. 0 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow > bge1: bpf attached > bge1: Ethernet address: 00:18:71:87:64:f6 > atrtc0: port 0x70-0x71,0x72-0x73 on acpi0 > atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) > ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 56 > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 57 > Event timer "i8254" frequency 1193182 Hz quality 100 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0047 > atkbd: keyboard ID 0xffffffff (1) > kbdc: RESET_KBD return code:00fe > kbdc: RESET_KBD return code:00fe > kbdc: RESET_KBD return code:00fe > kbdc: DIAGNOSE status:0055 > kbdc: TEST_KBD_PORT status:0000 > atkbd: failed to reset the keyboard. > kbd0 at atkbd0 > kbd0: atkbd0, AT 84 (1), config:0x0, flags:0x3d0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 58 > atkbd0: [GIANT-LOCKED] > psm0: unable to allocate IRQ > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 59 > uart0: fast interrupt > uart0: console (9600,n,8,1) > acpi0: wakeup code va 0xffffff8233373000 pa 0x4000 > ex_isa_identify() > ahc_isa_probe 0: ioport 0xc00 alloc failed > ahc_isa_probe 1: ioport 0x1c00 alloc failed > ahc_isa_probe 2: ioport 0x2c00 alloc failed > ahc_isa_probe 3: ioport 0x3c00 alloc failed > ahc_isa_probe 4: ioport 0x4c00 alloc failed > ahc_isa_probe 5: ioport 0x5c00 alloc failed > ahc_isa_probe 6: ioport 0x6c00 alloc failed > ahc_isa_probe 7: ioport 0x7c00 alloc failed > ahc_isa_probe 8: ioport 0x8c00 alloc failed > ahc_isa_probe 9: ioport 0x9c00 alloc failed > ahc_isa_probe 10: ioport 0xac00 alloc failed > ahc_isa_probe 11: ioport 0xbc00 alloc failed > ahc_isa_probe 12: ioport 0xcc00 alloc failed > ahc_isa_probe 13: ioport 0xdc00 alloc failed > ahc_isa_probe 14: ioport 0xec00 alloc failed > pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 > pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 > pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 > isa_probe_children: disabling PnP devices > atkbdc: atkbdc0 already exists; skipping it > atrtc: atrtc0 already exists; skipping it > attimer: attimer0 already exists; skipping it > sc: sc0 already exists; skipping it > uart: uart0 already exists; skipping it > isa_probe_children: probing non-PnP devices > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 > pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 > pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 > pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 > 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 > pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 > uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > isa_probe_children: probing PnP devices > powernow0: on cpu0 > powernow1: on cpu1 > Device configuration finished. > procfs registered > Timecounters tick every 1.000 msec > vlan: initialized, using hash tables with chaining > lo0: bpf attached > hptrr: no controller detected. > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 480Mbps High Speed USB v2.0 > ata0: reset tp1 mask=03 ostat0=7f ostat1=7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: reset tp2 stat0=ff stat1=ff devices=0x0 > ata1: reset tp1 mask=00 ostat0=ff ostat1=ff > ugen0.1: <0x1166> at usbus0 > uhub0: <0x1166 OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 > ugen1.1: <0x1166> at usbus1 > uhub1: <0x1166 OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1 > ugen2.1: <0x1166> at usbus2 > uhub2: <0x1166 EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2 > pass0 at mpt0 bus 0 scbus2 target 17 lun 0 > pass0: Fixed Direct Access SCSI-5 device > pass0: Serial Number 3QQ254BL000090107KK2 > pass0: 300.000MB/s transfers > pass0: Command Queueing enabled > pass1 at mpt0 bus 0 scbus2 target 18 lun 0 > pass1: Fixed Direct Access SCSI-5 device > pass1: Serial Number 3QQ25C8600009010SDER > pass1: 300.000MB/s transfers > pass1: Command Queueing enabled > da0 at mpt0 bus 0 scbus2 target 17 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: Serial Number 3QQ254BL000090107KK2 > da0: 300.000MB/s transfers > da0: Command Queueing enabled > da0: 429247MB (879097968 512 byte sectors: 255H 63S/T 54721C) > da1 at mpt0 bus 0 scbus2 target 18 lun 0 > da1: Fixed Direct Access SCSI-5 device > da1: Serial Number 3QQ25C8600009010SDER > da1: 300.000MB/s transfers > da1: Command Queueing enabled > da1: 429247MB (879097968 512 byte sectors: 255H 63S/T 54721C) > SMP: AP CPU #1 Launched! > cpu1 AP: > ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > TSC timecounter discards lower 8 bit(s) > GEOM: new disk da0 > Timecounter "TSC-low" frequency 9351792 Hz quality -100 > GEOM: new disk da1 > Root mount waiting for: usbus2 usbus1 usbus0 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 22:24:41 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 45C53106566B; Fri, 2 Mar 2012 22:24:41 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id AFD2014FFA2; Fri, 2 Mar 2012 22:24:39 +0000 (UTC) Message-ID: <4F5148A7.4080408@FreeBSD.org> Date: Fri, 02 Mar 2012 14:24:39 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Andriy Gapon References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F513B2D.6010809@FreeBSD.org> In-Reply-To: <4F513B2D.6010809@FreeBSD.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 22:24:41 -0000 On 3/2/2012 1:27 PM, Andriy Gapon wrote: > on 02/03/2012 20:21 Doug Barton said the following: >> ... and here is the crux of the problem. The vast majority of our >> developers don't use FreeBSD as their regular workstation. > > Do you care to back this up with facts? You mean other than the very few hands that go up whenever we discuss "who is actually using FreeBSD as their desktop?" If that doesn't work for you, look around at the next developer's summit and take note of the overwhelming preponderance of fruit logos. Just looking at the committers, of which we have over 300, only a couple dozen at most have ever identified as actually using FreeBSD as a desktop at my count. Taking the larger development community into account I think the numbers are a little better, but not much. Sure, our strength is servers, and that is not going to change. But how many real-life bugs have I personally uncovered in -current as a result of actually running it (mostly) daily? I'm not the only one, certainly, but if the numbers were flipped and the vast majority of our developers *did* use FreeBSD routinely, how much better off would we be? And before anyone bothers to point it out, yes, I happen to be using Windows at this exact moment. I have some layer 9 work to get done and I need tools that are only available to me in Windows (more's the pity). The sad thing is, judging by the activity on the -ports@ list, the traffic in #bsdports, and just talking to/interacting with FreeBSD users, a lot of *them* are not only interested in FreeBSD as a desktop OS, they are actually doing it. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 22:31:50 2012 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 A4EAA1065796; Fri, 2 Mar 2012 22:31:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 84A9F8FC13; Fri, 2 Mar 2012 22:31:49 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA29759; Sat, 03 Mar 2012 00:31:48 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1S3b0t-000GGh-Rh; Sat, 03 Mar 2012 00:31:47 +0200 Message-ID: <4F514A5E.5040105@FreeBSD.org> Date: Sat, 03 Mar 2012 00:31:58 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: Doug Barton References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F513B2D.6010809@FreeBSD.org> <4F5148A7.4080408@FreeBSD.org> In-Reply-To: <4F5148A7.4080408@FreeBSD.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 22:31:50 -0000 on 03/03/2012 00:24 Doug Barton said the following: > On 3/2/2012 1:27 PM, Andriy Gapon wrote: >> on 02/03/2012 20:21 Doug Barton said the following: >>> ... and here is the crux of the problem. The vast majority of our >>> developers don't use FreeBSD as their regular workstation. >> >> Do you care to back this up with facts? > > You mean other than the very few hands that go up whenever we discuss > "who is actually using FreeBSD as their desktop?" If that doesn't work > for you, look around at the next developer's summit and take note of the > overwhelming preponderance of fruit logos. > > Just looking at the committers, of which we have over 300, only a couple > dozen at most have ever identified as actually using FreeBSD as a > desktop at my count. Taking the larger development community into > account I think the numbers are a little better, but not much. OK, I agree that anyone can have his own impressions and now I realize that you stated your own impression based on your observations. It's just that it sounded like you stated a fact. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Mar 2 23:09:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E3741065672 for ; Fri, 2 Mar 2012 23:09:53 +0000 (UTC) (envelope-from gallasch@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) by mx1.freebsd.org (Postfix) with ESMTP id E65268FC1C for ; Fri, 2 Mar 2012 23:09:51 +0000 (UTC) Received: (qmail 54528 invoked from network); 3 Mar 2012 00:09:46 +0100 Received: from smtp.free.de (HELO orwell.free.de) (gallasch@free.de@[91.204.4.103]) (envelope-sender ) by smtp.free.de (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 3 Mar 2012 00:09:46 +0100 References: <719F8E0E-F88D-48E7-B2B7-ABA44B4F4163@free.de> <1330725018.5391.5.camel@powernoodle-l7.corp.yahoo.com> In-Reply-To: <1330725018.5391.5.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <8ED114DA-CE74-4011-AC06-5731268E3659@free.de> Content-Transfer-Encoding: quoted-printable From: Kai Gallasch Date: Sat, 3 Mar 2012 00:09:43 +0100 To: Sean Bruno X-Mailer: Apple Mail (2.1084) Cc: "freebsd-stable@freebsd.org" Subject: Re: FreeBSD 9.0 release - memstick installation fails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Mar 2012 23:09:53 -0000 On Fri, 2012-03-02 Sean Bruno wrote: > You may want to try playing around with BIOS settings regarding USB. I'd happily do so, but unfortunately this BIOS.. PhoenixBIOS 4.0 Release 6.1 HP System BIOS - O09 (07/19/2007) HP FEATURES VERSION : 1.08.00 has no USB knobs to turn. Kai. > On Fri, 2012-03-02 at 13:01 -0800, Kai Gallasch wrote: >> Hi list. >>=20 >> Trying to install 9.0 release with a USB stick. >> I use FreeBSD-9.0-RELEASE-amd64-memstick.img >>=20 >> At first the bootup looks promising, but in the end it stops with = "Root mount waiting for: usbus2 usbus1 usbus" >>=20 >> To single out a bad USB stick I tried = FreeBSD-8.3-BETA1-amd64-memstick.img with the same stick and there are = no problems. >>=20 >> The hardware is an older HP/Compaq DL145-G3, but why toss it in the = trash? >>=20 >> How can I debug this further? >> Any hints? >>=20 >> Kai. >>=20 >>=20 >> ---- snip ---- >>=20 >> SMAP type=3D01 base=3D0000000000000000 len=3D000000000009c000 >> SMAP type=3D02 base=3D000000000009c000 len=3D0000000000004000 >> SMAP type=3D02 base=3D00000000000ce000 len=3D0000000000032000 >> SMAP type=3D01 base=3D0000000000100000 len=3D00000000dbe60000 >> SMAP type=3D03 base=3D00000000dbf60000 len=3D0000000000007000 >> SMAP type=3D04 base=3D00000000dbf67000 len=3D0000000000019000 >> SMAP type=3D02 base=3D00000000dbf80000 len=3D0000000000080000 >> SMAP type=3D02 base=3D00000000e0000000 len=3D0000000010000000 >> SMAP type=3D02 base=3D00000000fec00000 len=3D0000000000003000 >> SMAP type=3D02 base=3D00000000fee00000 len=3D0000000000001000 >> SMAP type=3D02 base=3D00000000fff80000 len=3D0000000000080000 >> SMAP type=3D01 base=3D0000000100000000 len=3D0000000124000000 >> Table 'FACP' at 0xdbf62be7 >> Table 'SPMI' at 0xdbf66bf5 >> Table 'SSDT' at 0xdbf66c35 >> Table 'HPET' at 0xdbf66e7d >> Table 'SSDT' at 0xdbf66eb5 >> Table 'MCFG' at 0xdbf66efe >> Table 'SPCR' at 0xdbf66f3a >> Table 'APIC' at 0xdbf66f8a >> APIC: Found table at 0xdbf66f8a >> APIC: Using the MADT enumerator. >> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled >> SMP: Added CPU 0 (AP) >> MADT: Found CPU APIC ID 1 ACPI ID 1: enabled >> SMP: Added CPU 1 (AP) >> Copyright (c) 1992-2012 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >> The Regents of the University of California. All rights = reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 >> root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >> Table 'FACP' at 0xdbf62be7 >> Table 'SPMI' at 0xdbf66bf5 >> Table 'SSDT' at 0xdbf66c35 >> Table 'HPET' at 0xdbf66e7d >> Table 'SSDT' at 0xdbf66eb5 >> Table 'MCFG' at 0xdbf66efe >> Table 'SPCR' at 0xdbf66f3a >> Table 'APIC' at 0xdbf66f8a >> ACPI: No SRAT table found >> Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff813cf000. >> Calibrating TSC clock ... TSC clock: 2394059007 Hz >> CPU: Dual-Core AMD Opteron(tm) Processor 2216 HE (2394.06-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 8589934592 (8192 MB) >> Physical memory chunk(s): >> 0x0000000000001000 - 0x0000000000097fff, 618496 bytes (151 pages) >> 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) >> 0x0000000001403000 - 0x00000000dbf5ffff, 3669348352 bytes (895837 = pages) >> 0x0000000100000000 - 0x0000000213e45fff, 4628701184 bytes (1130054 = pages) >> avail memory =3D 8244486144 (7862 MB) >> Event timer "LAPIC" quality 400 >> ACPI APIC Table: >> INTR: Adding local APIC 1 as a target >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> FreeBSD/SMP: 1 package(s) x 2 core(s) >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 >> x86bios: SSEG 0x001000-0x001fff at 0xffffff8000220000 >> x86bios: EBDA 0x09c000-0x09ffff at 0xfffffe000009c000 >> x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 >> APIC: CPU 0 has ACPI ID 0 >> APIC: CPU 1 has ACPI ID 1 >> ULE: setup cpu 0 >> ULE: setup cpu 1 >> ACPI: RSDP 0xf8510 00024 (v02 PTLTD ) >> ACPI: XSDT 0xdbf62b83 00064 (v01 PTLTD ? XSDT 06040000 LTP = 00000000) >> ACPI: FACP 0xdbf62be7 00084 (v02 HP TREX 06040000 MSFT = 02000001) >> ACPI: DSDT 0xdbf62c6b 03F8A (v01 HP TREX 06040000 MSFT = 02000002) >> ACPI: FACS 0xdbf6ffc0 00040 >> ACPI: SPMI 0xdbf66bf5 00040 (v05 HP TREX 06040000 PTL = 00000001) >> ACPI: SSDT 0xdbf66c35 00248 (v01 PTLTD POWERNOW 06040000 LTP = 00000001) >> ACPI: HPET 0xdbf66e7d 00038 (v01 BRCM EXPLOSN 06040000 BRCM = 02000001) >> ACPI: SSDT 0xdbf66eb5 00049 (v01 PTLTD SSDT 06040000 AMD = 02000001) >> ACPI: MCFG 0xdbf66efe 0003C (v01 PTLTD MCFG 06040000 AMD = 02000001) >> ACPI: SPCR 0xdbf66f3a 00050 (v01 PTLTD $UCRTBL$ 06040000 PTL = 00000001) >> ACPI: APIC 0xdbf66f8a 00076 (v01 PTLTD APIC 06040000 LTP = 00000000) >> MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 >> ioapic0: Routing external 8259A's -> intpin 0 >> MADT: Found IO APIC ID 3, Interrupt 16 at 0xfec01000 >> MADT: Found IO APIC ID 4, Interrupt 32 at 0xfec02000 >> MADT: Interrupt override: source 0, irq 2 >> ioapic0: Routing IRQ 0 -> intpin 2 >> lapic0: Routing NMI -> LINT1 >> lapic0: LINT1 trigger: edge >> lapic0: LINT1 polarity: high >> lapic1: Routing NMI -> LINT1 >> lapic1: LINT1 trigger: edge >> lapic1: LINT1 polarity: high >> MADT: Forcing active-low polarity and level trigger for SCI >> ioapic0: intpin 9 polarity: low >> ioapic0: intpin 9 trigger: level >> ioapic0 irqs 0-15 on motherboard >> ioapic1 irqs 16-31 on motherboard >> ioapic2 irqs 32-47 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 >> snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff= [1024] >> feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D5 = feeder_rate_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 >> wlan: <802.11 Link Layer> >> random: >> kbd: new array size 4 >> kbd1 at kbdmux0 >> nfslock: pseudo-device >> mem: >> io: >> null: >> hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 >> acpi0: on motherboard >> PCIe: Memory Mapped configuration base @ 0xe0000000 >> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 >> acpi0: Power Button (fixed) >> unknown: I/O range not supported >> ACPI timer: 0/4 1/3 1/3 1/3 0/4 1/3 0/4 1/3 1/3 0/4 -> 6 >> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 >> cpu0: on acpi0 >> cpu0: switching to generic Cx mode >> cpu1: on acpi0 >> pci_link0: Index IRQ Rtd Ref IRQs >> Initial Probe 0 10 N 0 10 11 >> Validation 0 10 N 0 10 11 >> After Disable 0 255 N 0 10 11 >> pci_link1: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 10 11 >> Validation 0 255 N 0 10 11 >> After Disable 0 255 N 0 10 11 >> pci_link2: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 5 7 11 >> Validation 0 255 N 0 5 7 11 >> After Disable 0 255 N 0 5 7 11 >> pci_link3: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link4: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link5: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link6: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link7: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link8: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link9: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link10: Index IRQ Rtd Ref IRQs >> Initial Probe 0 5 N 0 3 4 5 7 11 12 14 15 >> Validation 0 5 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link11: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link12: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link13: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link14: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link15: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link16: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link17: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link18: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link19: Index IRQ Rtd Ref IRQs >> Initial Probe 0 7 N 0 3 4 5 7 11 12 14 15 >> Validation 0 7 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link20: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link21: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link22: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link23: Index IRQ Rtd Ref IRQs >> Initial Probe 0 5 N 0 3 4 5 7 11 12 14 15 >> Validation 0 5 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link24: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link25: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link26: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link27: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link28: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link29: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link30: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link31: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link32: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link33: Index IRQ Rtd Ref IRQs >> Initial Probe 0 11 N 0 3 4 5 7 11 12 14 15 >> Validation 0 11 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> pci_link34: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 5 7 11 12 14 15 >> Validation 0 255 N 0 3 4 5 7 11 12 14 15 >> After Disable 0 255 N 0 3 4 5 7 11 12 14 15 >> hpet0: iomem 0xfed00000-0xfed003ff on = acpi0 >> hpet0: vendor 0x1166, rev 0x1, 14318180Hz 64bit, 3 timers, legacy = route >> hpet0: t0: irqs 0xffffffff (0), periodic >> hpet0: t1: irqs 0xffffffff (0), periodic >> hpet0: t2: irqs 0xffffffff (0), periodic >> Timecounter "HPET" frequency 14318180 Hz quality 950 >> ioapic1: routing intpin 0 (PCI IRQ 16) to lapic 0 vector 49 >> Event timer "HPET" frequency 14318180 Hz quality 450 >> Event timer "HPET1" frequency 14318180 Hz quality 450 >> Event timer "HPET2" frequency 14318180 Hz quality 450 >> pcib0: on acpi0 >> pcib0: decoding 4 range 0-0x3af >> pcib0: decoding 4 range 0x3e0-0xfff >> pcib0: decoding 4 range 0x3b0-0x3df >> pcib0: decoding 3 range 0xa0000-0xbffff >> pcib0: decoding 4 range 0x1000-0x2fff >> pcib0: decoding 4 range 0x3000-0xffff >> pcib0: decoding 3 range 0xdf000000-0xdfcfffff >> pcib0: decoding 3 range 0xde000000-0xdeffffff >> pcib0: decoding 3 range 0xfe000000-0xfebfffff >> pcib0: decoding 3 range 0xfec04000-0xfecfffff >> pcib0: decoding 3 range 0xfed00400-0xfed07fff >> pcib0: decoding 3 range 0xfed08008-0xfedfffff >> pcib0: decoding 3 range 0xfee01000-0xffffffff >> ACPI: Found matching pin for 0.3.INTA at func 0: 10 >> pci0: on pcib0 >> pci0: domain=3D0, physical bus=3D0 >> found-> vendor=3D0x1166, dev=3D0x0036, revid=3D0x00 >> domain=3D0, bus=3D0, slot=3D1, func=3D0 >> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 >> cmdreg=3D0x0147, statreg=3D0x0010, cachelnsz=3D0 (dwords) >> lattimer=3D0x40 (1920 ns), mingnt=3D0x07 (1750 ns), = maxlat=3D0x00 (0 ns) >> found-> vendor=3D0x1166, dev=3D0x0205, revid=3D0x00 >> domain=3D0, bus=3D0, slot=3D2, func=3D0 >> class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 >> cmdreg=3D0x0147, statreg=3D0x0200, cachelnsz=3D0 (dwords) >> lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) >> found-> vendor=3D0x1166, dev=3D0x0214, revid=3D0x00 >> domain=3D0, bus=3D0, slot=3D2, func=3D1 >> class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D1 >> cmdreg=3D0x0155, statreg=3D0x0210, cachelnsz=3D16 (dwords) >> lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) >> powerspec 2 supports D0 D3 current D0 >> pcib0: allocated type 4 (0x1f0-0x1f7) for rid 10 of pci0:0:2:1 >> pcib0: allocated type 4 (0x3f6-0x3f6) for rid 14 of pci0:0:2:1 >> pcib0: allocated type 4 (0x170-0x177) for rid 18 of pci0:0:2:1 >> pcib0: allocated type 4 (0x376-0x376) for rid 1c of pci0:0:2:1 >> map[20]: type I/O Port, range 32, base 0x1c00, size 4, = enabled >> pcib0: allocated type 4 (0x1c00-0x1c0f) for rid 20 of pci0:0:2:1 >> found-> vendor=3D0x1166, dev=3D0x0234, revid=3D0x00 >> domain=3D0, bus=3D0, slot=3D2, func=3D2 >> class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 >> cmdreg=3D0x0147, statreg=3D0x0200, cachelnsz=3D0 (dwords) >> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = ns) >> found-> vendor=3D0x1166, dev=3D0x0223, revid=3D0x01 >> domain=3D0, bus=3D0, slot=3D3, func=3D0 >> class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D1 >> cmdreg=3D0x0157, statreg=3D0x02b0, cachelnsz=3D16 (dwords) >> lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) >> intpin=3Da, irq=3D10 >> powerspec 2 supports D0 D3 current D0 >> map[10]: type Memory, range 32, base 0xdfc05000, size 12, = enabled >> pcib0: allocated type 3 (0xdfc05000-0xdfc05fff) for rid 10 of = pci0:0:3:0 >> map[14]: type I/O Port, range 32, base 0x1000, size 8, = enabled >> pcib0: allocated type 4 (0x1000-0x10ff) for rid 14 of pci0:0:3:0 >> pcib0: matched entry for 0.3.INTA (src \_SB_.LNKU:0) >> ioapic0: Changing trigger for pin 10 to level >> ioapic0: Changing polarity for pin 10 to low >> pcib0: slot 3 INTA routed to irq 10 via \_SB_.LNKU >> found-> vendor=3D0x1166, dev=3D0x0223, revid=3D0x01 >> domain=3D0, bus=3D0, slot=3D3, func=3D1 >> class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 >> cmdreg=3D0x0157, statreg=3D0x02b0, cachelnsz=3D16 (dwords) >> lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 = (0 ns) >> intpin=3Da, irq=3D10 >> powerspec 2 supports D0 D3 current D0 >> map[10]: type Memory, range 32, base 0xdfc06000, size 12, = enabled >> pcib0: allocated type 3 (0xdfc06000-0xdfc06fff) for rid 10 of = pci0:0:3:1 >> map[14]: type I/O Port, range 32, base 0x1400, size 8, = enabled >> pcib0: allocated type 4 (0x1400-0x14ff) for rid 14 of pci0:0:3:1 >> pcib0: matched entry for 0.3.INTA (src \_SB_.LNKU:0) >> pcib0: slot 3 INTA routed to irq 10 via \_SB_.LNKU >> found-> vendor=3D0x1166, dev=3D0x0223, revid=3D0x01 >> domain=3D0, bus=3D0, slot=3D3, func=3D2 >> class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 >> cmdreg=3D0x0117, statreg=3D0x02b0, cachelnsz=3D16 (dwords) >> lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 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 0xdfc07000, size 12, = enabled >> pcib0: allocated type 3 (0xdfc07000-0xdfc07fff) for rid 10 of = pci0:0:3:2 >> map[14]: type I/O Port, range 32, base 0x1800, size 8, = enabled >> pcib0: allocated type 4 (0x1800-0x18ff) for rid 14 of pci0:0:3:2 >> pcib0: matched entry for 0.3.INTA (src \_SB_.LNKU:0) >> pcib0: slot 3 INTA routed to irq 10 via \_SB_.LNKU >> found-> vendor=3D0x102b, dev=3D0x0522, revid=3D0x02 >> domain=3D0, bus=3D0, slot=3D4, func=3D0 >> class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 >> cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D16 (dwords) >> lattimer=3D0x80 (3840 ns), mingnt=3D0x10 (4000 ns), = maxlat=3D0x20 (8000 ns) >> intpin=3Da, irq=3D5 >> powerspec 1 supports D0 D3 current D0 >> map[10]: type Prefetchable Memory, range 32, base 0xde000000, = size 24, enabled >> pcib0: allocated type 3 (0xde000000-0xdeffffff) for rid 10 of = pci0:0:4:0 >> map[14]: type Memory, range 32, base 0xdfc00000, size 14, = enabled >> pcib0: allocated type 3 (0xdfc00000-0xdfc03fff) for rid 14 of = pci0:0:4:0 >> map[18]: type Memory, range 32, base 0xdf000000, size 23, = enabled >> pcib0: allocated type 3 (0xdf000000-0xdf7fffff) for rid 18 of = pci0:0:4:0 >> pcib0: matched entry for 0.4.INTA >> pcib0: slot 4 INTA hardwired to IRQ 23 >> found-> vendor=3D0x1166, dev=3D0x0140, revid=3D0xa2 >> domain=3D0, bus=3D0, slot=3D6, func=3D0 >> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 >> cmdreg=3D0x0147, statreg=3D0x4010, cachelnsz=3D16 (dwords) >> lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) >> intpin=3Da, irq=3D11 >> powerspec 3 supports D0 D3 current D0 >> MSI supports 2 messages, 64 bit >> pcib0: matched entry for 0.6.INTA >> pcib0: slot 6 INTA hardwired to IRQ 32 >> found-> vendor=3D0x1166, dev=3D0x0142, revid=3D0xa2 >> domain=3D0, bus=3D0, slot=3D7, func=3D0 >> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 >> cmdreg=3D0x0147, statreg=3D0x0010, cachelnsz=3D16 (dwords) >> lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) >> intpin=3Da, irq=3D11 >> powerspec 3 supports D0 D3 current D0 >> MSI supports 2 messages, 64 bit >> pcib0: matched entry for 0.7.INTA >> pcib0: slot 7 INTA hardwired to IRQ 32 >> found-> vendor=3D0x1166, dev=3D0x0144, revid=3D0xa2 >> domain=3D0, bus=3D0, slot=3D8, func=3D0 >> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 >> cmdreg=3D0x0147, statreg=3D0x0010, cachelnsz=3D16 (dwords) >> lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) >> intpin=3Da, irq=3D11 >> powerspec 3 supports D0 D3 current D0 >> MSI supports 2 messages, 64 bit >> pcib0: matched entry for 0.8.INTA >> pcib0: slot 8 INTA hardwired to IRQ 32 >> found-> vendor=3D0x1166, dev=3D0x0142, revid=3D0xa2 >> domain=3D0, bus=3D0, slot=3D9, func=3D0 >> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 >> cmdreg=3D0x0147, statreg=3D0x0010, cachelnsz=3D16 (dwords) >> lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) >> intpin=3Da, irq=3D11 >> powerspec 3 supports D0 D3 current D0 >> MSI supports 2 messages, 64 bit >> pcib0: matched entry for 0.9.INTA >> pcib0: slot 9 INTA hardwired to IRQ 32 >> found-> vendor=3D0x1166, dev=3D0x0144, revid=3D0xa2 >> domain=3D0, bus=3D0, slot=3D10, func=3D0 >> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 >> cmdreg=3D0x0147, statreg=3D0x0010, cachelnsz=3D16 (dwords) >> lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) >> intpin=3Da, irq=3D11 >> powerspec 3 supports D0 D3 current D0 >> MSI supports 2 messages, 64 bit >> pcib0: matched entry for 0.10.INTA >> pcib0: slot 10 INTA hardwired to IRQ 32 >> 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) >> pcib1: at device 1.0 on pci0 >> pcib1: domain 0 >> pcib1: secondary bus 1 >> pcib1: subordinate bus 2 >> pcib1: no prefetched decode >> pci1: on pcib1 >> pci1: domain=3D0, physical bus=3D1 >> found-> vendor=3D0x1166, dev=3D0x0104, revid=3D0xc0 >> domain=3D0, bus=3D1, slot=3D13, func=3D0 >> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 >> cmdreg=3D0x0157, statreg=3D0x0230, cachelnsz=3D16 (dwords) >> lattimer=3D0x40 (1920 ns), mingnt=3D0x07 (1750 ns), = maxlat=3D0x02 (500 ns) >> pcib2: at device 13.0 on pci1 >> pcib2: domain 0 >> pcib2: secondary bus 2 >> pcib2: subordinate bus 2 >> pcib2: no prefetched decode >> pci2: on pcib2 >> pci2: domain=3D0, physical bus=3D2 >> atapci0: port = 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1c00-0x1c0f at device 2.1 on pci0 >> ata0: on atapci0 >> ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 50 >> ata1: on atapci0 >> ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 51 >> isab0: at device 2.2 on pci0 >> isa0: on isab0 >> ohci0: port 0x1000-0x10ff mem = 0xdfc05000-0xdfc05fff irq 10 at device 3.0 on pci0 >> ohci0: (New OHCI DeviceId=3D0x02231166) >> ioapic0: routing intpin 10 (ISA IRQ 10) to lapic 0 vector 52 >> usbus0: on ohci0 >> usbus0: bpf attached >> ohci0: usbpf: Attached >> ohci1: port 0x1400-0x14ff mem = 0xdfc06000-0xdfc06fff irq 10 at device 3.1 on pci0 >> ohci1: (New OHCI DeviceId=3D0x02231166) >> usbus1: on ohci1 >> usbus1: bpf attached >> ohci1: usbpf: Attached >> ehci0: port 0x1800-0x18ff mem = 0xdfc07000-0xdfc07fff irq 10 at device 3.2 on pci0 >> ehci0: (New EHCI DeviceId=3D0x02231166) >> usbus2: EHCI version 1.0 >> usbus2: on ehci0 >> usbus2: bpf attached >> ehci0: usbpf: Attached >> vgapci0: mem = 0xde000000-0xdeffffff,0xdfc00000-0xdfc03fff,0xdf000000-0xdf7fffff irq 23 = at device 4.0 on pci0 >> pcib3: irq 32 at device 6.0 on pci0 >> pcib0: allocated type 4 (0x2000-0x2fff) for rid 1c of pcib3 >> pcib0: allocated type 3 (0xdfa00000-0xdfafffff) for rid 20 of pcib3 >> pcib3: domain 0 >> pcib3: secondary bus 3 >> pcib3: subordinate bus 3 >> pcib3: I/O decode 0x2000-0x2fff >> pcib3: memory decode 0xdfa00000-0xdfafffff >> pcib3: no prefetched decode >> pci3: on pcib3 >> pci3: domain=3D0, physical bus=3D3 >> found-> vendor=3D0x1000, dev=3D0x0058, revid=3D0x08 >> domain=3D0, bus=3D3, slot=3D0, func=3D0 >> class=3D01-00-00, hdrtype=3D0x00, mfdev=3D0 >> cmdreg=3D0x0147, statreg=3D0x4010, cachelnsz=3D16 (dwords) >> lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 = 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 0x2000, size 8, = enabled >> pcib3: allocated I/O port range (0x2000-0x20ff) for rid 10 of = pci0:3:0:0 >> map[14]: type Memory, range 64, base 0xdfa10000, size 14, = enabled >> pcib3: allocated memory range (0xdfa10000-0xdfa13fff) for rid 14 of = pci0:3:0:0 >> map[1c]: type Memory, range 64, base 0xdfa00000, size 16, = enabled >> pcib3: allocated memory range (0xdfa00000-0xdfa0ffff) for rid 1c of = pci0:3:0:0 >> pcib3: matched entry for 3.0.INTA >> pcib3: slot 0 INTA hardwired to IRQ 32 >> mpt0: port 0x2000-0x20ff mem = 0xdfa10000-0xdfa13fff,0xdfa00000-0xdfa0ffff irq 32 at device 0.0 on pci3 >> mpt0: attempting to allocate 1 MSI-X vectors (1 supported) >> msi: routing MSI-X IRQ 256 to local APIC 0 vector 53 >> mpt0: using IRQ 256 for MSI-X >> mpt0: MPI Version=3D1.5.20.0 >> mpt0: chain depth limited to 34 (from 2040) >> mpt0: Maximum Segment Count: 306, Maximum CAM Segment Count: 33 >> mpt0: MsgLength=3D20 IOCNumber =3D 0 >> mpt0: IOCFACTS: GlobalCredits=3D483 BlockSize=3D8 bytes Request Frame = Size 128 bytes Max Chain Depth 34 >> mpt0: IOCFACTS: Num Ports 1, FWImageSize 0, Flags=3D0x2 >> 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 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 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: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not = required). >> mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not = required). >> pcib4: irq 32 at device 7.0 on pci0 >> pcib4: domain 0 >> pcib4: secondary bus 4 >> pcib4: subordinate bus 4 >> pcib4: no prefetched decode >> pci4: on pcib4 >> pci4: domain=3D0, physical bus=3D4 >> pcib5: irq 32 at device 8.0 on pci0 >> pcib5: domain 0 >> pcib5: secondary bus 5 >> pcib5: subordinate bus 5 >> pcib5: no prefetched decode >> pci5: on pcib5 >> pci5: domain=3D0, physical bus=3D5 >> pcib6: irq 32 at device 9.0 on pci0 >> pcib6: domain 0 >> pcib6: secondary bus 6 >> pcib6: subordinate bus 6 >> pcib6: no prefetched decode >> pci6: on pcib6 >> pci6: domain=3D0, physical bus=3D6 >> pcib7: irq 32 at device 10.0 on pci0 >> pcib0: allocated type 3 (0xdfb00000-0xdfbfffff) for rid 20 of pcib7 >> pcib7: domain 0 >> pcib7: secondary bus 7 >> pcib7: subordinate bus 8 >> pcib7: memory decode 0xdfb00000-0xdfbfffff >> pcib7: no prefetched decode >> pcib7: could not get PCI interrupt routing table for \_SB_.PCI0.EXB4 = - AE_NOT_FOUND >> pci7: on pcib7 >> pci7: domain=3D0, physical bus=3D7 >> found-> vendor=3D0x1166, dev=3D0x0103, revid=3D0xb5 >> domain=3D0, bus=3D7, slot=3D0, func=3D0 >> class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 >> cmdreg=3D0x0147, statreg=3D0x0010, cachelnsz=3D16 (dwords) >> lattimer=3D0x00 (0 ns), mingnt=3D0x07 (1750 ns), maxlat=3D0x00 = (0 ns) >> powerspec 2 supports D0 D3 current D0 >> pcib8: at device 0.0 on pci7 >> pcib7: allocated memory range (0xdfb00000-0xdfbfffff) for rid 20 of = pcib8 >> pcib8: domain 0 >> pcib8: secondary bus 8 >> pcib8: subordinate bus 8 >> pcib8: memory decode 0xdfb00000-0xdfbfffff >> pcib8: no prefetched decode >> pci8: on pcib8 >> pci8: domain=3D0, physical bus=3D8 >> found-> vendor=3D0x14e4, dev=3D0x1678, revid=3D0xa3 >> domain=3D0, bus=3D8, slot=3D4, func=3D0 >> class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 >> cmdreg=3D0x0156, statreg=3D0x02b0, cachelnsz=3D16 (dwords) >> lattimer=3D0x40 (1920 ns), mingnt=3D0x40 (16000 ns), = maxlat=3D0x00 (0 ns) >> intpin=3Da, irq=3D5 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 8 messages, 64 bit >> map[10]: type Memory, range 64, base 0xdfb10000, size 16, = enabled >> pcib8: allocated memory range (0xdfb10000-0xdfb1ffff) for rid 10 of = pci0:8:4:0 >> map[18]: type Memory, range 64, base 0xdfb00000, size 16, = enabled >> pcib8: allocated memory range (0xdfb00000-0xdfb0ffff) for rid 18 of = pci0:8:4:0 >> pcib8: matched entry for 8.4.INTA >> pcib8: slot 4 INTA hardwired to IRQ 36 >> found-> vendor=3D0x14e4, dev=3D0x1678, revid=3D0xa3 >> domain=3D0, bus=3D8, slot=3D4, func=3D1 >> class=3D02-00-00, hdrtype=3D0x00, mfdev=3D1 >> cmdreg=3D0x0156, statreg=3D0x02b0, cachelnsz=3D16 (dwords) >> lattimer=3D0x40 (1920 ns), mingnt=3D0x40 (16000 ns), = maxlat=3D0x00 (0 ns) >> intpin=3Db, irq=3D5 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 8 messages, 64 bit >> map[10]: type Memory, range 64, base 0xdfb30000, size 16, = enabled >> pcib8: allocated memory range (0xdfb30000-0xdfb3ffff) for rid 10 of = pci0:8:4:1 >> map[18]: type Memory, range 64, base 0xdfb20000, size 16, = enabled >> pcib8: allocated memory range (0xdfb20000-0xdfb2ffff) for rid 18 of = pci0:8:4:1 >> pcib8: matched entry for 8.4.INTB >> pcib8: slot 4 INTB hardwired to IRQ 36 >> bge0: mem 0xdfb10000-0xdfb1ffff,0xdfb00000-0xdfb0ffff irq 36 at = device 4.0 on pci8 >> bge0: attempting to allocate 1 MSI vectors (8 supported) >> msi: routing MSI IRQ 257 to local APIC 0 vector 54 >> bge0: using IRQ 257 for MSI >> bge0: CHIP ID 0x00009003; ASIC REV 0x09; CHIP REV 0x90; PCI-X >> miibus0: on bge0 >> brgphy0: PHY 1 on miibus0 >> brgphy0: OUI 0x001018, model 0x0034, rev. 0 >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >> bge0: bpf attached >> bge0: Ethernet address: 00:18:71:87:0f:ac >> bge1: mem 0xdfb30000-0xdfb3ffff,0xdfb20000-0xdfb2ffff irq 36 at = device 4.1 on pci8 >> bge1: attempting to allocate 1 MSI vectors (8 supported) >> msi: routing MSI IRQ 258 to local APIC 0 vector 55 >> bge1: using IRQ 258 for MSI >> bge1: CHIP ID 0x00009003; ASIC REV 0x09; CHIP REV 0x90; PCI-X >> miibus1: on bge1 >> brgphy1: PHY 1 on miibus1 >> brgphy1: OUI 0x001018, model 0x0034, rev. 0 >> brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow >> bge1: bpf attached >> bge1: Ethernet address: 00:18:71:87:64:f6 >> atrtc0: port 0x70-0x71,0x72-0x73 on acpi0 >> atrtc0: registered as a time-of-day clock (resolution 1000000us, = adjustment 0.500000000s) >> ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 56 >> Event timer "RTC" frequency 32768 Hz quality 0 >> attimer0: port 0x40-0x43 on acpi0 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 57 >> Event timer "i8254" frequency 1193182 Hz quality 100 >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> atkbd: the current kbd controller command byte 0047 >> atkbd: keyboard ID 0xffffffff (1) >> kbdc: RESET_KBD return code:00fe >> kbdc: RESET_KBD return code:00fe >> kbdc: RESET_KBD return code:00fe >> kbdc: DIAGNOSE status:0055 >> kbdc: TEST_KBD_PORT status:0000 >> atkbd: failed to reset the keyboard. >> kbd0 at atkbd0 >> kbd0: atkbd0, AT 84 (1), config:0x0, flags:0x3d0000 >> ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 58 >> atkbd0: [GIANT-LOCKED] >> psm0: unable to allocate IRQ >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on = acpi0 >> ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 59 >> uart0: fast interrupt >> uart0: console (9600,n,8,1) >> acpi0: wakeup code va 0xffffff8233373000 pa 0x4000 >> ex_isa_identify() >> ahc_isa_probe 0: ioport 0xc00 alloc failed >> ahc_isa_probe 1: ioport 0x1c00 alloc failed >> ahc_isa_probe 2: ioport 0x2c00 alloc failed >> ahc_isa_probe 3: ioport 0x3c00 alloc failed >> ahc_isa_probe 4: ioport 0x4c00 alloc failed >> ahc_isa_probe 5: ioport 0x5c00 alloc failed >> ahc_isa_probe 6: ioport 0x6c00 alloc failed >> ahc_isa_probe 7: ioport 0x7c00 alloc failed >> ahc_isa_probe 8: ioport 0x8c00 alloc failed >> ahc_isa_probe 9: ioport 0x9c00 alloc failed >> ahc_isa_probe 10: ioport 0xac00 alloc failed >> ahc_isa_probe 11: ioport 0xbc00 alloc failed >> ahc_isa_probe 12: ioport 0xcc00 alloc failed >> ahc_isa_probe 13: ioport 0xdc00 alloc failed >> ahc_isa_probe 14: ioport 0xec00 alloc failed >> pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 >> pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 >> isa_probe_children: disabling PnP devices >> atkbdc: atkbdc0 already exists; skipping it >> atrtc: atrtc0 already exists; skipping it >> attimer: attimer0 already exists; skipping it >> sc: sc0 already exists; skipping it >> uart: uart0 already exists; skipping it >> isa_probe_children: probing non-PnP devices >> 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 >> pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 >> pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 >> pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 >> pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 >> 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 >> pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 >> uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 >> isa_probe_children: probing PnP devices >> powernow0: on cpu0 >> powernow1: on cpu1 >> Device configuration finished. >> procfs registered >> Timecounters tick every 1.000 msec >> vlan: initialized, using hash tables with chaining >> lo0: bpf attached >> hptrr: no controller detected. >> usbus0: 12Mbps Full Speed USB v1.0 >> usbus1: 12Mbps Full Speed USB v1.0 >> usbus2: 480Mbps High Speed USB v2.0 >> ata0: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D7f >> ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f >> ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f >> ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f >> ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f >> ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f >> ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f >> ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f >> ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f >> ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f >> ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f >> ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f >> ata0: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f >> ata0: stat1=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f >> ata0: reset tp2 stat0=3Dff stat1=3Dff devices=3D0x0 >> ata1: reset tp1 mask=3D00 ostat0=3Dff ostat1=3Dff >> ugen0.1: <0x1166> at usbus0 >> uhub0: <0x1166 OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on = usbus0 >> ugen1.1: <0x1166> at usbus1 >> uhub1: <0x1166 OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on = usbus1 >> ugen2.1: <0x1166> at usbus2 >> uhub2: <0x1166 EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on = usbus2 >> pass0 at mpt0 bus 0 scbus2 target 17 lun 0 >> pass0: Fixed Direct Access SCSI-5 device >> pass0: Serial Number 3QQ254BL000090107KK2 >> pass0: 300.000MB/s transfers >> pass0: Command Queueing enabled >> pass1 at mpt0 bus 0 scbus2 target 18 lun 0 >> pass1: Fixed Direct Access SCSI-5 device >> pass1: Serial Number 3QQ25C8600009010SDER >> pass1: 300.000MB/s transfers >> pass1: Command Queueing enabled >> da0 at mpt0 bus 0 scbus2 target 17 lun 0 >> da0: Fixed Direct Access SCSI-5 device >> da0: Serial Number 3QQ254BL000090107KK2 >> da0: 300.000MB/s transfers >> da0: Command Queueing enabled >> da0: 429247MB (879097968 512 byte sectors: 255H 63S/T 54721C) >> da1 at mpt0 bus 0 scbus2 target 18 lun 0 >> da1: Fixed Direct Access SCSI-5 device >> da1: Serial Number 3QQ25C8600009010SDER >> da1: 300.000MB/s transfers >> da1: Command Queueing enabled >> da1: 429247MB (879097968 512 byte sectors: 255H 63S/T 54721C) >> SMP: AP CPU #1 Launched! >> cpu1 AP: >> ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff >> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff >> timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 >> TSC timecounter discards lower 8 bit(s) >> GEOM: new disk da0 >> Timecounter "TSC-low" frequency 9351792 Hz quality -100 >> GEOM: new disk da1 >> Root mount waiting for: usbus2 usbus1 usbus0 >> _______________________________________________ >> 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 >=20 -- "I'm tryin' to think but nothin happens" - Curly From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 00:05:34 2012 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 E863C1065674; Sat, 3 Mar 2012 00:05:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id EB1128FC13; Sat, 3 Mar 2012 00:05:33 +0000 (UTC) Received: by wibhn6 with SMTP id hn6so1206200wib.13 for ; Fri, 02 Mar 2012 16:05:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SfmPZqkIyJCjYQ6uHKbFLgHCYuPrB5t0q4/sfi9GlXw=; b=rc6jzprusTAOJE4NpS6qJ9hd+BNVsjMs8lZYIMTQdKxV8S/JrVfH0vT0lwYMu+QhOU MGmJzjRAGksCe5P9cAXnr5otyFnuyCAsOZgvio8S7TKNytWgXQVm0byS3QHbWMcdnEya 39JNLhlYFUosPbF2/k844dAF51WOyMP6nc0Qs/sZscdOu8S8eSXPzZ3Zg3Sxa5pdpZcy aPgCE0ifIG2oa47183wkNXDG0RHwHiLCijyczeRRJ2K+dQZERDmNO4+/irawoXKjoORn gbTwFJD5CxRCeLfUfJ0rJbXvMFjUkCgyMBtz28wikuSzJrbBEe1fvi4ou0lZrGlrZShh bceg== MIME-Version: 1.0 Received: by 10.180.78.6 with SMTP id x6mr559918wiw.18.1330733132920; Fri, 02 Mar 2012 16:05:32 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.198.81 with HTTP; Fri, 2 Mar 2012 16:05:32 -0800 (PST) In-Reply-To: References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F5117A6.2030003@FreeBSD.org> Date: Fri, 2 Mar 2012 16:05:32 -0800 X-Google-Sender-Auth: gALs1Y7QuN0ChbnB304RivKdlig Message-ID: From: Adrian Chadd To: "K. Macy" Content-Type: text/plain; charset=ISO-8859-1 Cc: stable@freebsd.org, Doug Barton , current@freebsd.org, =?ISO-8859-2?Q?z_W=B1sikowski?= , Arnaud Lacombe , "Bjoern A. Zeeb" , Alexander Leidinger Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 00:05:35 -0000 I've had the same problem with wireless. For some users, wireless works flawlessly. For other users, it's completely unusable. Trying to get any kind of useful feedback from people has been impossible at best. I've even had FreeBSD developers, sitting in the developers IRC channel, say wifi is so broken on FreeBSD they have to boot into windows to get anything done. Yet I still haven't seen any PRs about this. This is why I've been pushing people to keep filing PRs. I can't even begin to investigate what I don't know is broken and if the _developers_ don't use FreeBSD because supported wifi stuff is broken, then .. well, no hope, etc. The honest truth is this: for any system to work, there needs to be: * sufficient users reporting issues; * sufficient developers (and/or companies) wanting it to work and keeping the bug fixes coming; * a healthy cycle between the above two. If _either_ there are no developers or there is no feedback to the developer(s), the cycle breaks, and things rot in very annoying ways. Then you have the next problem, which is: * if it doesn't work, noone will use it * if noone uses it, noone will work on it. Try breaking that cycle. 2c, Adrian From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 02:01:13 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77CCB106564A for ; Sat, 3 Mar 2012 02:01:13 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2F9888FC15 for ; Sat, 3 Mar 2012 02:01:13 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1S3eHv-0005rK-2u; Sat, 03 Mar 2012 06:01:35 +0400 Date: Sat, 3 Mar 2012 06:01:35 +0400 From: Slawa Olhovchenkov To: Adam Vande More Message-ID: <20120303020134.GJ97848@zxy.spb.ru> References: <20120302181707.GI97848@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: stable@freebsd.org Subject: Re: Long delay on boot 9.0R on vmware+zfs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 02:01:13 -0000 On Fri, Mar 02, 2012 at 12:25:24PM -0600, Adam Vande More wrote: > On Fri, Mar 2, 2012 at 12:17 PM, Slawa Olhovchenkov wrote: > > > Long delay (more 30 seconds) on loader disk detect. > > Debug print pointed to zfs/zfs.c:zfs_dev_init. > > This function found disk0 and walked over 128 potencial slices, trying > > 'p' slice and 's' slice. Each attempt -- 1/4s (and nothing found). > > > > How to speed up boot? > > > > Sounds quite similar to this: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 I think no delayed in bd_open_gpt. From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 02:50:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06470106566B for ; Sat, 3 Mar 2012 02:50:12 +0000 (UTC) (envelope-from harry@yewbarrow.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id C70C98FC08 for ; Sat, 3 Mar 2012 02:50:11 +0000 (UTC) Received: by iahk25 with SMTP id k25so4084421iah.13 for ; Fri, 02 Mar 2012 18:50:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.47.228 with SMTP id g4mr432319ign.60.1330743011058; Fri, 02 Mar 2012 18:50:11 -0800 (PST) Sender: harry@yewbarrow.net Received: by 10.50.173.2 with HTTP; Fri, 2 Mar 2012 18:50:11 -0800 (PST) In-Reply-To: <201202290912.14012.jhb@freebsd.org> References: <201202290912.14012.jhb@freebsd.org> Date: Sat, 3 Mar 2012 02:50:11 +0000 X-Google-Sender-Auth: Zx8poZeH6J_JEp7fOddFRrpAd04 Message-ID: From: Harry Newton To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmZAZ6ANY8FI5d8b1ytXfQJqcHQmu6yT704REcjBFsQcmonB/BjMmXDIjs+lCy6dySizZTY Cc: Ian Lepore , Adrian Chadd , freebsd-stable@freebsd.org Subject: Re: Regression between 9-RELEASE and 9-STABLE [PCIB ?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 02:50:12 -0000 John, investigations shew bug introduced between 2012.02.23.22.26.00 and 2012.02.23.22.26.30 in these files: Edit src/sys/dev/acpica/acpi.c Add delta 1.305.2.4 2012.02.23.22.26.14 jkim Edit src/sys/dev/acpica/acpi_ec.c Add delta 1.95.2.2 2012.02.23.22.26.14 jkim Edit src/sys/dev/acpica/acpi_hpet.c Add delta 1.38.2.2 2012.02.23.22.26.14 jkim Edit src/sys/dev/acpica/acpi_timer.c Add delta 1.50.2.3 2012.02.23.22.26.14 jkim Edit src/sys/dev/acpica/acpivar.h Add delta 1.125.2.4 2012.02.23.22.26.14 jkim More details below. Let me know if I can do anything else. - H * dmesg Table 'FACP' at 0x77fd0200 Table 'APIC' at 0x77fd0390 APIC: Found table at 0x77fd0390 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-STABLE #19: Fri Mar 2 22:28:14 GMT 2012 toor@hydra.yewbarrow.net:/usr/obj/usr/src/sys/HYDRA amd64 WARNING: DIAGNOSTIC option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel.old/kernel" at 0xffffffff80b6f000. Calibrating TSC clock ... TSC clock: 2194794720 Hz CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2194.79-MHz K8-class C= PU) Origin =3D "AuthenticAMD" Id =3D 0x40fb2 Family =3D f Model =3D 4b St= epping =3D 2 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 associat= ive 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: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associativ= e real memory =3D 2147483648 (2048 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x0000000000b9e000 - 0x0000000074722fff, 1941458944 bytes (473989 pages) avail memory =3D 1926897664 (1837 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <030107 APIC1519> INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 x86bios: SSEG 0x001000-0x001fff at 0xffffff800020d000 x86bios: EBDA 0x09f000-0x09ffff at 0xfffffe000009f000 x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xf96d0 00014 (v00 ACPIAM) ACPI: RSDT 0x77fd0000 00038 (v01 030107 RSDT1519 20070301 MSFT 00000097) ACPI: FACP 0x77fd0200 00084 (v02 030107 FACP1519 20070301 MSFT 00000097) ACPI: DSDT 0x77fd0430 044A0 (v01 1ADNC 1ADNCB33 00000B33 INTL 20051117) ACPI: FACS 0x77fde000 00040 ACPI: APIC 0x77fd0390 0005C (v01 030107 APIC1519 20070301 MSFT 00000097) ACPI: MCFG 0x77fd03f0 0003C (v01 030107 OEMMCFG 20070301 MSFT 00000097) ACPI: OEMB 0x77fde040 00071 (v01 030107 OEMB1519 20070301 MSFT 00000097) ACPI: HPET 0x77fd48d0 00038 (v01 030107 OEMHPET 20070301 MSFT 00000097) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low ioapic0 irqs 0-23 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 null: random: io: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: acpi0: <030107 RSDT1519> on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 ACPI: Executed 3 blocks of module-level executable AML code acpi0: Power Button (fixed) acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of ffb80000, 80000 (3) failed acpi0: reservation of fff80000, 80000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 77f00000 (3) failed ACPI timer: 1/1 1/2 0/3 1/2 1/2 1/2 1/3 1/2 1/2 1/2 -> 9 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 7 10 11 12 14 15 Validation 0 3 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 4 N 0 3 4 5 7 10 11 12 14 15 Validation 0 4 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 7 10 11 12 14 15 Validation 0 255 N 0 3 4 5 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 7 10 11 12 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=3D0, physical bus=3D0 found-> vendor=3D0x1002, dev=3D0x7910, revid=3D0x00 domain=3D0, bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x2220, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x1002, dev=3D0x7912, revid=3D0x00 domain=3D0, bus=3D0, slot=3D1, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x0230, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x1a (6500 ns), maxlat=3D0x00 (= 0 ns) found-> vendor=3D0x1002, dev=3D0x7917, revid=3D0x00 domain=3D0, bus=3D0, slot=3D7, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x4010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x03 (750 ns), maxlat=3D0x00 (0 ns= ) powerspec 3 supports D0 D3 current D0 MSI supports 1 message found-> vendor=3D0x1002, dev=3D0x4380, revid=3D0x00 domain=3D0, bus=3D0, slot=3D18, func=3D0 class=3D01-06-01, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x0230, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 n= s) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xb000, size 3, enabled map[14]: type I/O Port, range 32, base 0xa000, size 2, enabled map[18]: type I/O Port, range 32, base 0x9000, size 3, enabled map[1c]: type I/O Port, range 32, base 0x8000, size 2, enabled map[20]: type I/O Port, range 32, base 0x7000, size 4, enabled map[24]: type Memory, range 32, base 0xfe7ff800, size 10, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 22 found-> vendor=3D0x1002, dev=3D0x4387, revid=3D0x00 domain=3D0, bus=3D0, slot=3D19, func=3D0 class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0517, statreg=3D0x02a0, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 n= s) intpin=3Da, irq=3D5 map[10]: type Memory, range 32, base 0xfe7fe000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 16 ohci early: SMM active, request owner change found-> vendor=3D0x1002, dev=3D0x4388, revid=3D0x00 domain=3D0, bus=3D0, slot=3D19, func=3D1 class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0117, statreg=3D0x02a0, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 n= s) intpin=3Db, irq=3D3 map[10]: type Memory, range 32, base 0xfe7fd000, size 12, enabled pcib0: matched entry for 0.19.INTB pcib0: slot 19 INTB hardwired to IRQ 17 ohci early: SMM active, request owner change found-> vendor=3D0x1002, dev=3D0x4389, revid=3D0x00 domain=3D0, bus=3D0, slot=3D19, func=3D2 class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0117, statreg=3D0x02a0, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 n= s) intpin=3Dc, irq=3D10 map[10]: type Memory, range 32, base 0xfe7fc000, size 12, enabled pcib0: matched entry for 0.19.INTC pcib0: slot 19 INTC hardwired to IRQ 18 ohci early: SMM active, request owner change found-> vendor=3D0x1002, dev=3D0x438a, revid=3D0x00 domain=3D0, bus=3D0, slot=3D19, func=3D3 class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0117, statreg=3D0x02a0, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 n= s) intpin=3Db, irq=3D3 map[10]: type Memory, range 32, base 0xfe7fb000, size 12, enabled pcib0: matched entry for 0.19.INTB pcib0: slot 19 INTB hardwired to IRQ 17 ohci early: SMM active, request owner change found-> vendor=3D0x1002, dev=3D0x438b, revid=3D0x00 domain=3D0, bus=3D0, slot=3D19, func=3D4 class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0117, statreg=3D0x02a0, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 n= s) intpin=3Dc, irq=3D10 map[10]: type Memory, range 32, base 0xfe7fa000, size 12, enabled pcib0: matched entry for 0.19.INTC pcib0: slot 19 INTC hardwired to IRQ 18 ohci early: SMM active, request owner change found-> vendor=3D0x1002, dev=3D0x4386, revid=3D0x00 domain=3D0, bus=3D0, slot=3D19, func=3D5 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0117, statreg=3D0x02b0, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 n= s) intpin=3Dd, irq=3D10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe7ff000, size 8, enabled pcib0: matched entry for 0.19.INTD pcib0: slot 19 INTD hardwired to IRQ 19 found-> vendor=3D0x1002, dev=3D0x4385, revid=3D0x13 domain=3D0, bus=3D0, slot=3D20, func=3D0 class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0403, statreg=3D0x0230, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) map[10]: type I/O Port, range 32, base 0xb00, size 4, enabled map[14]: type Memory, range 32, base 0xfed00000, size 10, enabled found-> vendor=3D0x1002, dev=3D0x438c, revid=3D0x00 domain=3D0, bus=3D0, slot=3D20, func=3D1 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0230, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D255 MSI supports 1 message map[20]: type I/O Port, range 32, base 0xff00, size 4, enabled found-> vendor=3D0x1002, dev=3D0x4383, revid=3D0x00 domain=3D0, bus=3D0, slot=3D20, func=3D2 class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0410, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 n= s) intpin=3Da, irq=3D5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfe7f4000, size 14, enabled pcib0: matched entry for 0.20.INTA pcib0: slot 20 INTA hardwired to IRQ 16 found-> vendor=3D0x1002, dev=3D0x438d, revid=3D0x00 domain=3D0, bus=3D0, slot=3D20, func=3D3 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x000f, statreg=3D0x0220, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x1002, dev=3D0x4384, revid=3D0x00 domain=3D0, bus=3D0, slot=3D20, func=3D4 class=3D06-04-01, hdrtype=3D0x01, mfdev=3D1 cmdreg=3D0x0107, statreg=3D0x02a0, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x03 (750 ns), maxlat=3D0x00 (0= ns) 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) pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xc000-0xcfff pcib1: memory decode 0xfe800000-0xfe9fffff pcib1: prefetched decode 0xf0000000-0xf7ffffff pci1: on pcib1 pci1: domain=3D0, physical bus=3D1 found-> vendor=3D0x1002, dev=3D0x791e, revid=3D0x00 domain=3D0, bus=3D1, slot=3D5, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0107, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 n= s) intpin=3Da, irq=3D10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xf0000000, size = 27, e nabled pcib1: requested memory range 0xf0000000-0xf7ffffff: good map[18]: type Memory, range 64, base 0xfe9f0000, size 16, enabled pcib1: requested memory range 0xfe9f0000-0xfe9fffff: good map[20]: type I/O Port, range 32, base 0xc000, size 8, enabled pcib1: requested I/O range 0xc000-0xc0ff: in range map[24]: type Memory, range 32, base 0xfe800000, size 20, enabled pcib1: requested memory range 0xfe800000-0xfe8fffff: good pcib1: matched entry for 1.5.INTA pcib1: slot 5 INTA hardwired to IRQ 18 found-> vendor=3D0x1002, dev=3D0x7919, revid=3D0x00 domain=3D0, bus=3D1, slot=3D5, func=3D2 class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 n= s) intpin=3Db, irq=3D10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfe9e8000, size 14, enabled pcib1: requested memory range 0xfe9e8000-0xfe9ebfff: good pcib1: matched entry for 1.5.INTB pcib1: slot 5 INTB hardwired to IRQ 19 vgapci0: port 0xc000-0xc0ff mem 0xf0000000-0xf7fff= fff,0 xfe9f0000-0xfe9fffff,0xfe800000-0xfe8fffff irq 18 at device 5.0 on pci1 pci1: at device 5.2 (no driver attached) pcib2: at device 7.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xfea00000-0xfeafffff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=3D0, physical bus=3D2 found-> vendor=3D0x10ec, dev=3D0x8168, revid=3D0x01 domain=3D0, bus=3D2, slot=3D0, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x4010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type I/O Port, range 32, base 0xd800, size 8, enabled pcib2: requested I/O range 0xd800-0xd8ff: in range map[18]: type Memory, range 64, base 0xfeaff000, size 12, enabled pcib2: requested memory range 0xfeaff000-0xfeafffff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 19 re0: port 0xd800-= 0xd8f f mem 0xfeaff000-0xfeafffff irq 19 at device 0.0 on pci2 re0: MSI count : 2 re0: MSI-X count : 0 re0: attempting to allocate 1 MSI vectors (2 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 49 re0: using IRQ 256 for MSI re0: Using 1 MSI message re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: OUI 0x00e04c, model 0x0011, rev. 2 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseT= X-FDX , 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT= -FDX- master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: bpf attached re0: Ethernet address: 00:19:db:63:76:3e ahci0: port 0xb000-0xb007,0xa000-0xa003,0= x9000 -0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe7ff800-0xfe7ffbff irq 22 at dev= ice 1 8.0 on pci0 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 50 ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier supported ahci0: Caps: 64bit NCQ SNTF MPS AL CLO 3Gbps PM PMD 32cmd CCC 4ports ahci0: Caps2: ahcich0: at channel 0 on ahci0 ahcich0: Caps: HPCP ahcich1: at channel 1 on ahci0 ahcich1: Caps: HPCP ahcich2: at channel 2 on ahci0 ahcich2: Caps: HPCP ahcich3: at channel 3 on ahci0 ahcich3: Caps: HPCP ohci0: mem 0xfe7fe000-0xfe7fefff irq 16 at = devic e 19.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 51 usbus0: on ohci0 usbus0: bpf attached ohci0: usbpf: Attached ohci1: mem 0xfe7fd000-0xfe7fdfff irq 17 at = devic e 19.1 on pci0 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 52 usbus1: on ohci1 usbus1: bpf attached ohci1: usbpf: Attached ohci2: mem 0xfe7fc000-0xfe7fcfff irq 18 at = devic e 19.2 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 53 usbus2: on ohci2 usbus2: bpf attached ohci2: usbpf: Attached ohci3: mem 0xfe7fb000-0xfe7fbfff irq 17 at = devic e 19.3 on pci0 usbus3: on ohci3 usbus3: bpf attached ohci3: usbpf: Attached ohci4: mem 0xfe7fa000-0xfe7fafff irq 18 at = devic e 19.4 on pci0 usbus4: on ohci4 usbus4: bpf attached ohci4: usbpf: Attached ehci0: mem 0xfe7ff000-0xfe7ff0ff irq 19= at d evice 19.5 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 54 ehci0: AMD SB600/700 quirk applied ehci0: Dropped interrupts workaround enabled usbus5: EHCI version 1.0 usbus5: on ehci0 usbus5: bpf attached ehci0: usbpf: Attached pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x37 6,0xff00-0xff0f at device 20.1 on pci0 ata0: at channel 0 on atapci0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 55 pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xe000-0xefff pcib3: memory decode 0xfeb00000-0xfebfffff pcib3: no prefetched decode pcib3: Subtractively decoded bridge. pci3: on pcib3 pci3: domain=3D0, physical bus=3D3 found-> vendor=3D0x1106, dev=3D0x3044, revid=3D0xc0 domain=3D0, bus=3D3, slot=3D0, func=3D0 class=3D0c-00-10, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0117, statreg=3D0x0210, cachelnsz=3D16 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x20 (800= 0 ns) intpin=3Da, irq=3D4 powerspec 2 supports D0 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfebff800, size 11, enabled pcib3: requested memory range 0xfebff800-0xfebfffff: good map[14]: type I/O Port, range 32, base 0xe800, size 7, enabled pcib3: requested I/O range 0xe800-0xe87f: in range pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 20 pci3: at device 0.0 (no driver attached) acpi_button0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 56 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment= 0.50 0000000s) ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 57 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 device_attach: hpet0 attach returned 12 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 58 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ acpi0: wakeup code va 0xffffff8087fae000 pa 0x4000 isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xcd800-0xce7ff 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 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 isa_probe_children: probing PnP devices acpi_throttle0: on cpu0 acpi_throttle0: CLK_VAL field overlaps THT_EN bit device_attach: acpi_throttle0 attach returned 6 powernow0: on cpu0 powernow0: STATUS: 0x310a120c0a0e020e powernow0: STATUS: maxfid: 0x0e powernow0: STATUS: maxvid: 0x0a device_attach: powernow0 attach returned 6 powernow1: on cpu1 powernow1: STATUS: 0x310a120c0a0e020e powernow1: STATUS: maxfid: 0x0e powernow1: STATUS: maxvid: 0x0a device_attach: powernow1 attach returned 6 Device configuration finished. procfs registered lapic: Divisor 2, Frequency 99761963 Hz Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 ahcich0: AHCI reset... ahcich0: SATA connect time=3D100us status=3D00000123 ahcich0: AHCI reset: device found ahcich1: AHCI reset... ahcich1: SATA connect time=3D100us status=3D00000123 ahcich1: AHCI reset: device found ahcich2: AHCI reset... ahcich2: SATA connect time=3D100us status=3D00000123 ahcich2: AHCI reset: device found ahcich3: AHCI reset... ahcich3: SATA connect time=3D100us status=3D00000123 ahcich3: AHCI reset: device found ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 ahcich0: AHCI reset: device ready after 100ms Expensive timeout(9) function: 0xffffffff802db3d0(0xfffffe00015abb00) 0.054= 21135 9 s (aprobe0:ahcich0:0:15:0): Command timed out (aprobe0:ahcich0:0:15:0): Error 5, Retries exhausted (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 ahcich1: AHCI reset: device ready after 100ms (aprobe1:ahcich1:0:15:0): Command timed out (aprobe1:ahcich1:0:15:0): Error 5, Retries exhausted (aprobe0:ahcich1:0:0:0): SIGNATURE: 0000 ahcich2: AHCI reset: device ready after 100ms (aprobe2:ahcich2:0:15:0): Command timed out (aprobe2:ahcich2:0:15:0): Error 5, Retries exhausted (aprobe0:ahcich2:0:0:0): SIGNATURE: 0000 ahcich3: AHCI reset: device ready after 100ms (aprobe3:ahcich3:0:15:0): Command timed out (aprobe3:ahcich3:0:15:0): Error 5, Retries exhausted (aprobe0:ahcich3:0:0:0): SIGNATURE: 0000 ata0: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata0: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x30000 (aprobe1:ata0:0:0:0): SIGNATURE: eb14 (aprobe0:ata0:0:1:0): SIGNATURE: eb14 pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 pass0: ATA-7 SATA 2.x device pass0: Serial Number 6QF0W6RN GEOM: new disk cd0 GEOM: new disk cd1 pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) pass0: Command Queueing enabled (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd0:ata0:0:0:0): Error 6, Unretryable error cd0 at ata0 bus 0 scbus4 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: Serial Number 2005082900 cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 pass1: ATA-8 SATA 3.x device pass1: Serial Number W24044SM pass1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) pass1: Command Queueing enabled pass2 at ahcich2 bus 0 scbus2 target 0 lun 0 (cd1:ata0:0:1:0): SCSI status error (cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd1:ata0:0:1:0): CAM status: SCSI Status Error (cd1:ata0:0:1:0): SCSI status: Check Condition (cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray= clos ed) (cd1:ata0:0:1:0): Error 6, Unretryable error cd1 at ata0 bus 0 scbus4 target 1 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd1: Attempt to query device size failed: NOT READY, Medium not present - t= ray c losed pass2: ATA-7 SATA 2.x device pass2: Serial Number 6QF0ZTQM pass2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) pass2: Command Queueing enabled pass3 at ahcich3 bus 0 scbus3 target 0 lun 0 pass3: ATA-8 SATA 3.x device pass3: Serial Number W240643V pass3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) pass3: Command Queueing enabled pass4 at ata0 bus 0 scbus4 target 0 lun 0 pass4: Removable CD-ROM SCSI-0 device pass4: Serial Number 2005082900 pass4: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd0:ata0:0:0:0): Error 6, Unretryable error pass5 at ata0 bus 0 scbus4 target 1 lun 0 pass5: Removable CD-ROM SCSI-0 device pass5: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 SATA 2.x device ada0: Serial Number 6QF0W6RN ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-8 SATA 3.x device ada1: Serial Number W24044SM (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd0:ata0:0:0:0): Error 6, Unretryable error ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad6 ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 ada2: ATA-7 SATA 2.x device ada2: Serial Number 6QF0ZTQM ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 ada3: ATA-8 SATA 3.x device (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (cd0:ata0:0:0:0): Error 6, Unretryable error ada3: Serial Number W240643V ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad10 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 TSC timecounter discards lower 8 bit(s) Timecounter "TSC-low" frequency 8573416 Hz quality -100 WARNING: DIAGNOSTIC option enabled, expect reduced performance. (cd1:ata0:0:1:0): SCSI status error (cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd1:ata0:0:1:0): CAM status: SCSI Status Error (cd1:ata0:0:1:0): SCSI status: Check Condition (cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray= clos ed) (cd1:ata0:0:1:0): Error 6, Unretryable error (cd1:ata0:0:1:0): SCSI status error (cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd1:ata0:0:1:0): CAM status: SCSI Status Error (cd1:ata0:0:1:0): SCSI status: Check Condition (cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray= clos ed) (cd1:ata0:0:1:0): Error 6, Unretryable error (cd1:ata0:0:1:0): SCSI status error (cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd1:ata0:0:1:0): CAM status: SCSI Status Error (cd1:ata0:0:1:0): SCSI status: Check Condition (cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray= clos ed) (cd1:ata0:0:1:0): Error 6, Unretryable error GEOM: new disk ada0 GEOM: new disk ada1 GEOM: new disk ada2 GEOM: new disk ada3 GEOM: ada2s1: geometry does not match label (255h,63s !=3D 16h,63s). GEOM: ada2s1: media size does not match label. Root mount waiting for: usbus5 Root mount waiting for: usbus5 Root mount waiting for: usbus5 uhub5: 10 ports with 10 removable, self powered Root mount waiting for: usbus5 Trying to mount root from ufs:/dev/ada0p2 [rw]... start_init: trying /sbin/init ugen1.2: at usbus1 ums0: on usbus1 ums0: 5 buttons and [XYZ] coordinates ID=3D0 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is pres= ent; to enable, add "vfs.zfs.prefetch_disable=3D0" to /boot/loader.c= onf. ZFS filesystem version 5 ZFS storage pool version 28 * csup -------------------------------------------------------------- >>> Running /usr/bin/csup -------------------------------------------------------------- Parsing supfile "/root/csup/date-supfile" Connecting to cvsup.uk.freebsd.org Cannot connect to 2001:630:212:8:20e:cff:fe09:a69c: Protocol not supported Connected to 131.111.8.41 Server software version: SNAP_16_1h MD5 authentication started MD5 authentication successful Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs Edit src/sys/dev/acpica/acpi.c Add delta 1.305.2.4 2012.02.23.22.26.14 jkim Edit src/sys/dev/acpica/acpi_ec.c Add delta 1.95.2.2 2012.02.23.22.26.14 jkim Edit src/sys/dev/acpica/acpi_hpet.c Add delta 1.38.2.2 2012.02.23.22.26.14 jkim Edit src/sys/dev/acpica/acpi_timer.c Add delta 1.50.2.3 2012.02.23.22.26.14 jkim Edit src/sys/dev/acpica/acpivar.h Add delta 1.125.2.4 2012.02.23.22.26.14 jkim Shutting down connection to server Finished successfully * supfil *default host=3Dcvsup.uk.freebsd.org *default base=3D/var/db *default prefix=3D/usr *default release=3Dcvs tag=3DRELENG_9 # ok: # *default date=3D2012.02.23.22.26.00 # fail: *default date=3D2012.02.23.22.26.30 *default delete use-rel-suffix *default compress src-all * pciconf -lvb hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x79101002 chip=3D0x7910100= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'RS690 Host Bridge' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:0:1:0: class=3D0x060400 card=3D0x79121002 chip=3D0x7912100= 2 rev=3D0x00 hdr=3D0x01 vendor =3D 'ATI Technologies Inc' device =3D 'RS690 PCI to PCI Bridge (Internal gfx)' class =3D bridge subclass =3D PCI-PCI pcib2@pci0:0:7:0: class=3D0x060400 card=3D0x79101002 chip=3D0x7917100= 2 rev=3D0x00 hdr=3D0x01 vendor =3D 'ATI Technologies Inc' device =3D 'RS690 PCI to PCI Bridge (PCI Express Port 3)' class =3D bridge subclass =3D PCI-PCI ahci0@pci0:0:18:0: class=3D0x010601 card=3D0x73291462 chip=3D0x4380100= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB600 Non-Raid-5 SATA' class =3D mass storage subclass =3D SATA bar [10] =3D type I/O Port, range 32, base 0xb000, size 8, enabled bar [14] =3D type I/O Port, range 32, base 0xa000, size 4, enabled bar [18] =3D type I/O Port, range 32, base 0x9000, size 8, enabled bar [1c] =3D type I/O Port, range 32, base 0x8000, size 4, enabled bar [20] =3D type I/O Port, range 32, base 0x7000, size 16, enabled bar [24] =3D type Memory, range 32, base 0xfe7ff800, size 1024, enabl= ed ohci0@pci0:0:19:0: class=3D0x0c0310 card=3D0x73271462 chip=3D0x4387100= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB600 USB (OHCI0)' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 32, base 0xfe7fe000, size 4096, enabl= ed ohci1@pci0:0:19:1: class=3D0x0c0310 card=3D0x73271462 chip=3D0x4388100= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB600 USB (OHCI1)' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 32, base 0xfe7fd000, size 4096, enabl= ed ohci2@pci0:0:19:2: class=3D0x0c0310 card=3D0x73271462 chip=3D0x4389100= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB600 USB (OHCI2)' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 32, base 0xfe7fc000, size 4096, enabl= ed ohci3@pci0:0:19:3: class=3D0x0c0310 card=3D0x73271462 chip=3D0x438a100= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB600 USB (OHCI3)' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 32, base 0xfe7fb000, size 4096, enabl= ed ohci4@pci0:0:19:4: class=3D0x0c0310 card=3D0x73271462 chip=3D0x438b100= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB600 USB (OHCI4)' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 32, base 0xfe7fa000, size 4096, enabl= ed ehci0@pci0:0:19:5: class=3D0x0c0320 card=3D0x73271462 chip=3D0x4386100= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB600 USB Controller (EHCI)' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 32, base 0xfe7ff000, size 256, enable= d none0@pci0:0:20:0: class=3D0x0c0500 card=3D0x73271462 chip=3D0x4385100= 2 rev=3D0x13 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SBx00 SMBus Controller' class =3D serial bus subclass =3D SMBus bar [10] =3D type I/O Port, range 32, base 0xb00, size 16, enabled bar [14] =3D type Memory, range 32, base 0xfed00000, size 1024, enabl= ed atapci0@pci0:0:20:1: class=3D0x01018a card=3D0x73271462 chip=3D0x438c100= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB600 IDE' class =3D mass storage subclass =3D ATA bar [20] =3D type I/O Port, range 32, base 0xff00, size 16, enabled none1@pci0:0:20:2: class=3D0x040300 card=3D0x73271462 chip=3D0x4383100= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SBx00 Azalia (Intel HDA)' class =3D multimedia subclass =3D HDA bar [10] =3D type Memory, range 64, base 0xfe7f4000, size 16384, enab= led isab0@pci0:0:20:3: class=3D0x060100 card=3D0x73271462 chip=3D0x438d100= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'SB600 PCI to LPC Bridge' class =3D bridge subclass =3D PCI-ISA pcib3@pci0:0:20:4: class=3D0x060401 card=3D0x00000000 chip=3D0x4384100= 2 rev=3D0x00 hdr=3D0x01 vendor =3D 'ATI Technologies Inc' device =3D 'SBx00 PCI to PCI Bridge' class =3D bridge subclass =3D PCI-PCI hostb1@pci0:0:24:0: class=3D0x060000 card=3D0x00000000 chip=3D0x1100102= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices [AMD]' device =3D 'K8 [Athlon64/Opteron] HyperTransport Technology Configu= ration' class =3D bridge subclass =3D HOST-PCI hostb2@pci0:0:24:1: class=3D0x060000 card=3D0x00000000 chip=3D0x1101102= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices [AMD]' device =3D 'K8 [Athlon64/Opteron] Address Map' class =3D bridge subclass =3D HOST-PCI hostb3@pci0:0:24:2: class=3D0x060000 card=3D0x00000000 chip=3D0x1102102= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices [AMD]' device =3D 'K8 [Athlon64/Opteron] DRAM Controller' class =3D bridge subclass =3D HOST-PCI hostb4@pci0:0:24:3: class=3D0x060000 card=3D0x00000000 chip=3D0x1103102= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices [AMD]' device =3D 'K8 [Athlon64/Opteron] Miscellaneous Control' class =3D bridge subclass =3D HOST-PCI vgapci0@pci0:1:5:0: class=3D0x030000 card=3D0x73271462 chip=3D0x791e100= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'RS690 [Radeon X1200 Series]' class =3D display subclass =3D VGA bar [10] =3D type Prefetchable Memory, range 64, base 0xf0000000, siz= e 13421 7728, enabled bar [18] =3D type Memory, range 64, base 0xfe9f0000, size 65536, enab= led bar [20] =3D type I/O Port, range 32, base 0xc000, size 256, enabled bar [24] =3D type Memory, range 32, base 0xfe800000, size 1048576, en= abled none2@pci0:1:5:2: class=3D0x040300 card=3D0x79191002 chip=3D0x7919100= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'Radeon X1200 Series Audio Controller' class =3D multimedia subclass =3D HDA bar [10] =3D type Memory, range 64, base 0xfe9e8000, size 16384, enab= led re0@pci0:2:0:0: class=3D0x020000 card=3D0x327c1462 chip=3D0x816810ec rev=3D= 0x01 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class =3D network subclass =3D ethernet bar [10] =3D type I/O Port, range 32, base 0xd800, size 256, enabled bar [18] =3D type Memory, range 64, base 0xfeaff000, size 4096, enabl= ed none3@pci0:3:0:0: class=3D0x0c0010 card=3D0x086c0574 chip=3D0x3044110= 6 rev=3D0xc0 hdr=3D0x00 vendor =3D 'VIA Technologies, Inc.' device =3D 'VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller' class =3D serial bus subclass =3D FireWire bar [10] =3D type Memory, range 32, base 0xfebff800, size 2048, enabl= ed bar [14] =3D type I/O Port, range 32, base 0xe800, size 128, enabled On 29 February 2012 14:12, John Baldwin wrote: > On Tuesday, February 28, 2012 6:10:51 pm Harry Newton wrote: >> Adrian - thanks ! >> >> John, if you write me a shopping list of what information you think >> useful, assuming you have time and inclination, I'll do my best >> provide it. > > Mostly a verbose boot of 9.0-RELEASE and what you see now. =A0If anything= the > only changes I can think of since the release are to make some of the PCI= code > more lenient. =A0You could also try to narrow down exactly which revision= causes > the hang using a binary search of 9.0-STABLE since the release. > > -- > John Baldwin --=20 Harry Newton From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 03:32:34 2012 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 2B508106564A for ; Sat, 3 Mar 2012 03:32:34 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id A98C58FC15 for ; Sat, 3 Mar 2012 03:32:33 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.4/8.14.4) with ESMTP id q233WVwD043495 for ; Fri, 2 Mar 2012 22:32:31 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.4/8.14.4/Submit) id q233WVsI043494; Fri, 2 Mar 2012 22:32:31 -0500 (EST) (envelope-from wollman) Date: Fri, 2 Mar 2012 22:32:31 -0500 (EST) From: Garrett Wollman Message-Id: <201203030332.q233WVsI043494@hergotha.csail.mit.edu> To: stable@freebsd.org X-Newsgroups: mit.lcs.mail.freebsd-stable In-Reply-To: <719F8E0E-F88D-48E7-B2B7-ABA44B4F4163@free.de> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Fri, 02 Mar 2012 22:32:32 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: Subject: Re: FreeBSD 9.0 release - memstick installation fails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 03:32:34 -0000 In article <719F8E0E-F88D-48E7-B2B7-ABA44B4F4163@free.de>, gallasch@free.de wrote: >Trying to install 9.0 release with a USB stick. >I use FreeBSD-9.0-RELEASE-amd64-memstick.img > >At first the bootup looks promising, but in the end it stops with "Root >mount waiting for: usbus2 usbus1 usbus" The 9.0 memstick image worked (nearly[1]) flawlessly for me, albeit on a different kind of device. It would be really nice if it supported installing directly onto ZFS, though, so that I could avoid doing the install-on-UFS, copy-to-ZFS, pull-boot-drive-and-reboot, reinsert-boot-drive-and-add-to-mirror business. Getting /boot/zfs/zpool.cache is really tricky with the new livefs architecture -- I was able to install on a ZFS pool just fine, but I wasted three hours trying to make it bootable before giving up and doing it the old-fashioned way. (That machine is now being tested as an NFS fileserver[2], getting the snot beat out of it by our most abusive users.) -GAWollman [1] The mps driver in 9.0 is no good, and would not allow the system to boot while even one drive shelf was hooked up. Booting with external drives disconnected, then connecting them in multiuser mode, works fine, although it didn't see one of the SES targets. After cherry-picking the new LSI-supported driver from 9-stable, it boots fine and sees all of the SES devices. [2] wollman@zfsnfs(9)$ uptime 10:17PM up 4 days, 13:07, 2 users, load averages: 8.54, 8.49, 8.72 wollman@zfsnfs(10)$ zpool status export pool: export state: ONLINE scan: scrub canceled on Thu Mar 1 15:22:42 2012 config: NAME STATE READ WRITE CKSUM export ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 multipath/disk2 ONLINE 0 0 0 multipath/disk3 ONLINE 0 0 0 multipath/disk4 ONLINE 0 0 0 multipath/disk5 ONLINE 0 0 0 multipath/disk6 ONLINE 0 0 0 multipath/disk7 ONLINE 0 0 0 multipath/disk8 ONLINE 0 0 0 multipath/disk9 ONLINE 0 0 0 multipath/disk10 ONLINE 0 0 0 multipath/disk11 ONLINE 0 0 0 multipath/disk12 ONLINE 0 0 0 raidz2-1 ONLINE 0 0 0 multipath/disk14 ONLINE 0 0 0 multipath/disk16 ONLINE 0 0 0 multipath/disk17 ONLINE 0 0 0 multipath/disk19 ONLINE 0 0 0 multipath/disk20 ONLINE 0 0 0 multipath/disk21 ONLINE 0 0 0 multipath/disk22 ONLINE 0 0 0 multipath/disk23 ONLINE 0 0 0 multipath/disk24 ONLINE 0 0 0 multipath/disk25 ONLINE 0 0 0 multipath/disk26 ONLINE 0 0 0 raidz2-2 ONLINE 0 0 0 multipath/disk27 ONLINE 0 0 0 multipath/disk28 ONLINE 0 0 0 multipath/disk29 ONLINE 0 0 0 multipath/disk30 ONLINE 0 0 0 multipath/disk31 ONLINE 0 0 0 multipath/disk32 ONLINE 0 0 0 multipath/disk33 ONLINE 0 0 0 multipath/disk34 ONLINE 0 0 0 multipath/disk35 ONLINE 0 0 0 multipath/disk36 ONLINE 0 0 0 multipath/disk37 ONLINE 0 0 0 raidz2-3 ONLINE 0 0 0 multipath/disk38 ONLINE 0 0 0 multipath/disk39 ONLINE 0 0 0 multipath/disk40 ONLINE 0 0 0 multipath/disk41 ONLINE 0 0 0 multipath/disk42 ONLINE 0 0 0 multipath/disk43 ONLINE 0 0 0 multipath/disk44 ONLINE 0 0 0 multipath/disk45 ONLINE 0 0 0 multipath/disk46 ONLINE 0 0 0 multipath/disk47 ONLINE 0 0 0 multipath/disk48 ONLINE 0 0 0 raidz2-4 ONLINE 0 0 0 multipath/disk49 ONLINE 0 0 0 multipath/disk50 ONLINE 0 0 0 multipath/disk52 ONLINE 0 0 0 multipath/disk53 ONLINE 0 0 0 multipath/disk54 ONLINE 0 0 0 multipath/disk55 ONLINE 0 0 0 multipath/disk56 ONLINE 0 0 0 multipath/disk57 ONLINE 0 0 0 multipath/disk58 ONLINE 0 0 0 multipath/disk59 ONLINE 0 0 0 multipath/disk60 ONLINE 0 0 0 raidz2-5 ONLINE 0 0 0 multipath/disk61 ONLINE 0 0 0 multipath/disk62 ONLINE 0 0 0 multipath/disk63 ONLINE 0 0 0 multipath/disk64 ONLINE 0 0 0 multipath/disk65 ONLINE 0 0 0 multipath/disk66 ONLINE 0 0 0 multipath/disk67 ONLINE 0 0 0 multipath/disk68 ONLINE 0 0 0 multipath/disk69 ONLINE 0 0 0 multipath/disk70 ONLINE 0 0 0 multipath/disk71 ONLINE 0 0 0 raidz2-6 ONLINE 0 0 0 multipath/disk72 ONLINE 0 0 0 multipath/disk73 ONLINE 0 0 0 multipath/disk76 ONLINE 0 0 0 multipath/disk77 ONLINE 0 0 0 multipath/disk78 ONLINE 0 0 0 multipath/disk79 ONLINE 0 0 0 multipath/disk80 ONLINE 0 0 0 multipath/disk81 ONLINE 0 0 0 multipath/disk82 ONLINE 0 0 0 multipath/disk83 ONLINE 0 0 0 multipath/disk84 ONLINE 0 0 0 raidz2-7 ONLINE 0 0 0 multipath/disk85 ONLINE 0 0 0 multipath/disk86 ONLINE 0 0 0 multipath/disk87 ONLINE 0 0 0 multipath/disk88 ONLINE 0 0 0 multipath/disk89 ONLINE 0 0 0 multipath/disk90 ONLINE 0 0 0 multipath/disk91 ONLINE 0 0 0 multipath/disk92 ONLINE 0 0 0 multipath/disk93 ONLINE 0 0 0 multipath/disk94 ONLINE 0 0 0 multipath/disk95 ONLINE 0 0 0 logs mirror-8 ONLINE 0 0 0 multipath/ssd0 ONLINE 0 0 0 multipath/ssd2 ONLINE 0 0 0 cache multipath/ssd1 ONLINE 0 0 0 multipath/ssd3 ONLINE 0 0 0 spares multipath/disk13 AVAIL multipath/disk96 AVAIL multipath/disk51 AVAIL errors: No known data errors wollman@zfsnfs(11)$ zpool list export NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT export 160T 5.84T 154T 3% 1.61x ONLINE - From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 03:35:56 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38376106566B; Sat, 3 Mar 2012 03:35:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5E5D18FC12; Sat, 3 Mar 2012 03:35:54 +0000 (UTC) Received: by wibhn6 with SMTP id hn6so1266703wib.13 for ; Fri, 02 Mar 2012 19:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3wuShRLAg7WyJy+DUCyrpCDWO/XsBhNTa7jxfyIflPc=; b=z+v5b9Gfue/X6eEeFYrJAifmL8P50Q2SK43NuTXZ8LvG34CR6yURNvutvHrrggxnSB naQEKc+taQ131h7/UMZYu6kI4p0mZCPM/GuD48aiX+kg42Yj3Ssfl5GpGqNqzd9P7L3e A25PhIbumZ4bsURuN0/VMkS+adoTB9MKtU53L433hsWv+xGb54tj6U96uNxF9ov6NJLG vX3hq1YVYVxiha/nDcHEDyNNhFUmLcgtREo1PCMK/voSc7rnqPLK/1V08+c2RkwfPXi0 0xQld1XdZr+mHrqH8C/aJUGDveDIc84aLpF/Vx9RrnUi0yEAsfFRrnVWrjVkH7M8t+2T q9Gg== MIME-Version: 1.0 Received: by 10.180.92.165 with SMTP id cn5mr1475213wib.1.1330745754123; Fri, 02 Mar 2012 19:35:54 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.198.81 with HTTP; Fri, 2 Mar 2012 19:35:54 -0800 (PST) In-Reply-To: References: <201202290912.14012.jhb@freebsd.org> Date: Fri, 2 Mar 2012 19:35:54 -0800 X-Google-Sender-Auth: z6bocj7kSrYpa5xyjcBePqe5YvA Message-ID: From: Adrian Chadd To: Harry Newton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ian Lepore , freebsd-stable@freebsd.org, John Baldwin Subject: Re: Regression between 9-RELEASE and 9-STABLE [PCIB ?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 03:35:56 -0000 Hi! You now officially have enough information to fill out a PR! Thankyou so very much for finding out which particular commit/commits caused this regression for you! http://www.freebsd.org/send-pr.html Would you mind doing this? :) Thanks! Adrian On 2 March 2012 18:50, Harry Newton wrote: > John, investigations shew bug introduced between 2012.02.23.22.26.00 > and 2012.02.23.22.26.30 in these files: > > =A0Edit src/sys/dev/acpica/acpi.c > =A0Add delta 1.305.2.4 2012.02.23.22.26.14 jkim > =A0Edit src/sys/dev/acpica/acpi_ec.c > =A0Add delta 1.95.2.2 2012.02.23.22.26.14 jkim > =A0Edit src/sys/dev/acpica/acpi_hpet.c > =A0Add delta 1.38.2.2 2012.02.23.22.26.14 jkim > =A0Edit src/sys/dev/acpica/acpi_timer.c > =A0Add delta 1.50.2.3 2012.02.23.22.26.14 jkim > =A0Edit src/sys/dev/acpica/acpivar.h > =A0Add delta 1.125.2.4 2012.02.23.22.26.14 jkim > > More details below. Let me know if I can do anything else. - H > > * dmesg > Table 'FACP' at 0x77fd0200 > Table 'APIC' at 0x77fd0390 > APIC: Found table at 0x77fd0390 > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 1: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 1 ACPI ID 2: enabled > SMP: Added CPU 1 (AP) > Copyright (c) 1992-2012 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > =A0 =A0 =A0 =A0The Regents of the University of California. All rights re= served. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-STABLE #19: Fri Mar =A02 22:28:14 GMT 2012 > =A0 =A0toor@hydra.yewbarrow.net:/usr/obj/usr/src/sys/HYDRA amd64 > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > Preloaded elf kernel "/boot/kernel.old/kernel" at 0xffffffff80b6f000. > Calibrating TSC clock ... TSC clock: 2194794720 Hz > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2194.79-MHz K8-class= CPU) > =A0Origin =3D "AuthenticAMD" =A0Id =3D 0x40fb2 =A0Family =3D f =A0Model = =3D 4b =A0Stepping =3D 2 > =A0Features=3D0x178bfbff MOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> > =A0Features2=3D0x2001 > =A0AMD Features=3D0xea500800 > =A0AMD 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 associ= ative > 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: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associat= ive > real memory =A0=3D 2147483648 (2048 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) > 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) > 0x0000000000b9e000 - 0x0000000074722fff, 1941458944 bytes (473989 pages) > avail memory =3D 1926897664 (1837 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: <030107 APIC1519> > INTR: Adding local APIC 1 as a target > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > =A0cpu0 (BSP): APIC ID: =A00 > =A0cpu1 (AP): APIC ID: =A01 > x86bios: =A0IVT 0x000000-0x0004ff at 0xfffffe0000000000 > x86bios: SSEG 0x001000-0x001fff at 0xffffff800020d000 > x86bios: EBDA 0x09f000-0x09ffff at 0xfffffe000009f000 > x86bios: =A0ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 > APIC: CPU 0 has ACPI ID 1 > APIC: CPU 1 has ACPI ID 2 > ULE: setup cpu 0 > ULE: setup cpu 1 > ACPI: RSDP 0xf96d0 00014 (v00 ACPIAM) > ACPI: RSDT 0x77fd0000 00038 (v01 030107 RSDT1519 20070301 MSFT 00000097) > ACPI: FACP 0x77fd0200 00084 (v02 030107 FACP1519 20070301 MSFT 00000097) > ACPI: DSDT 0x77fd0430 044A0 (v01 =A01ADNC 1ADNCB33 00000B33 INTL 20051117= ) > ACPI: FACS 0x77fde000 00040 > ACPI: APIC 0x77fd0390 0005C (v01 030107 APIC1519 20070301 MSFT 00000097) > ACPI: MCFG 0x77fd03f0 0003C (v01 030107 OEMMCFG =A020070301 MSFT 00000097= ) > ACPI: OEMB 0x77fde040 00071 (v01 030107 OEMB1519 20070301 MSFT 00000097) > ACPI: HPET 0x77fd48d0 00038 (v01 030107 OEMHPET =A020070301 MSFT 00000097= ) > MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 > ioapic0: Routing external 8259A's -> intpin 0 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > MADT: Interrupt override: source 9, irq 9 > ioapic0: intpin 9 trigger: level > ioapic0: intpin 9 polarity: low > ioapic0 irqs 0-23 on motherboard > cpu0 BSP: > =A0 =A0 ID: 0x00000000 =A0 VER: 0x80050010 LDR: 0x00000000 DFR: 0xfffffff= f > =A0lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > =A0timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > null: > random: > io: > nfslock: pseudo-device > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > acpi0: <030107 RSDT1519> on motherboard > PCIe: Memory Mapped configuration base @ 0xe0000000 > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > ACPI: Executed 3 blocks of module-level executable AML code > acpi0: Power Button (fixed) > acpi0: reservation of fee00000, 1000 (3) failed > acpi0: reservation of ffb80000, 80000 (3) failed > acpi0: reservation of fff80000, 80000 (3) failed > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 77f00000 (3) failed > ACPI timer: 1/1 1/2 0/3 1/2 1/2 1/2 1/3 1/2 1/2 1/2 -> 9 > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > cpu0: on acpi0 > cpu0: switching to generic Cx mode > cpu1: on acpi0 > pci_link0: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs > =A0Initial Probe =A0 =A0 =A0 0 =A0 =A05 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 = 12 14 15 > =A0Validation =A0 =A0 =A0 =A0 =A00 =A0 =A05 =A0 N =A0 =A0 0 =A03 4 5 7 10= 11 12 14 15 > =A0After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 12= 14 15 > pci_link1: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs > =A0Initial Probe =A0 =A0 =A0 0 =A0 =A03 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 = 12 14 15 > =A0Validation =A0 =A0 =A0 =A0 =A00 =A0 =A03 =A0 N =A0 =A0 0 =A03 4 5 7 10= 11 12 14 15 > =A0After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 12= 14 15 > pci_link2: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs > =A0Initial Probe =A0 =A0 =A0 0 =A0 10 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 12= 14 15 > =A0Validation =A0 =A0 =A0 =A0 =A00 =A0 10 =A0 N =A0 =A0 0 =A03 4 5 7 10 1= 1 12 14 15 > =A0After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 12= 14 15 > pci_link3: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs > =A0Initial Probe =A0 =A0 =A0 0 =A0 10 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 12= 14 15 > =A0Validation =A0 =A0 =A0 =A0 =A00 =A0 10 =A0 N =A0 =A0 0 =A03 4 5 7 10 1= 1 12 14 15 > =A0After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 12= 14 15 > pci_link4: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs > =A0Initial Probe =A0 =A0 =A0 0 =A0 =A04 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 = 12 14 15 > =A0Validation =A0 =A0 =A0 =A0 =A00 =A0 =A04 =A0 N =A0 =A0 0 =A03 4 5 7 10= 11 12 14 15 > =A0After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 12= 14 15 > pci_link5: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs > =A0Initial Probe =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 12= 14 15 > =A0Validation =A0 =A0 =A0 =A0 =A00 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 1= 1 12 14 15 > =A0After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 12= 14 15 > pci_link6: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs > =A0Initial Probe =A0 =A0 =A0 0 =A0 11 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 12= 14 15 > =A0Validation =A0 =A0 =A0 =A0 =A00 =A0 11 =A0 N =A0 =A0 0 =A03 4 5 7 10 1= 1 12 14 15 > =A0After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 12= 14 15 > pci_link7: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs > =A0Initial Probe =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 12= 14 15 > =A0Validation =A0 =A0 =A0 =A0 =A00 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 1= 1 12 14 15 > =A0After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 12= 14 15 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: domain=3D0, physical bus=3D0 > found-> vendor=3D0x1002, dev=3D0x7910, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D0, func=3D0 > =A0 =A0 =A0 =A0class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 > =A0 =A0 =A0 =A0cmdreg=3D0x0006, statreg=3D0x2220, cachelnsz=3D0 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x0= 0 (0 ns) > found-> vendor=3D0x1002, dev=3D0x7912, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D1, func=3D0 > =A0 =A0 =A0 =A0class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > =A0 =A0 =A0 =A0cmdreg=3D0x0107, statreg=3D0x0230, cachelnsz=3D0 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x1a (6500 ns), maxlat= =3D0x00 (0 ns) > found-> vendor=3D0x1002, dev=3D0x7917, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D7, func=3D0 > =A0 =A0 =A0 =A0class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 > =A0 =A0 =A0 =A0cmdreg=3D0x0107, statreg=3D0x4010, cachelnsz=3D16 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x03 (750 ns), maxlat=3D0= x00 (0 ns) > =A0 =A0 =A0 =A0powerspec 3 =A0supports D0 D3 =A0current D0 > =A0 =A0 =A0 =A0MSI supports 1 message > found-> vendor=3D0x1002, dev=3D0x4380, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D18, func=3D0 > =A0 =A0 =A0 =A0class=3D01-06-01, hdrtype=3D0x00, mfdev=3D0 > =A0 =A0 =A0 =A0cmdreg=3D0x0107, statreg=3D0x0230, cachelnsz=3D16 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) > =A0 =A0 =A0 =A0intpin=3Da, irq=3D11 > =A0 =A0 =A0 =A0powerspec 2 =A0supports D0 D3 =A0current D0 > =A0 =A0 =A0 =A0map[10]: type I/O Port, range 32, base 0xb000, size =A03, = enabled > =A0 =A0 =A0 =A0map[14]: type I/O Port, range 32, base 0xa000, size =A02, = enabled > =A0 =A0 =A0 =A0map[18]: type I/O Port, range 32, base 0x9000, size =A03, = enabled > =A0 =A0 =A0 =A0map[1c]: type I/O Port, range 32, base 0x8000, size =A02, = enabled > =A0 =A0 =A0 =A0map[20]: type I/O Port, range 32, base 0x7000, size =A04, = enabled > =A0 =A0 =A0 =A0map[24]: type Memory, range 32, base 0xfe7ff800, size 10, = enabled > pcib0: matched entry for 0.18.INTA > pcib0: slot 18 INTA hardwired to IRQ 22 > found-> vendor=3D0x1002, dev=3D0x4387, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D19, func=3D0 > =A0 =A0 =A0 =A0class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D1 > =A0 =A0 =A0 =A0cmdreg=3D0x0517, statreg=3D0x02a0, cachelnsz=3D16 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) > =A0 =A0 =A0 =A0intpin=3Da, irq=3D5 > =A0 =A0 =A0 =A0map[10]: type Memory, range 32, base 0xfe7fe000, size 12, = enabled > pcib0: matched entry for 0.19.INTA > pcib0: slot 19 INTA hardwired to IRQ 16 > ohci early: SMM active, request owner change > found-> vendor=3D0x1002, dev=3D0x4388, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D19, func=3D1 > =A0 =A0 =A0 =A0class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 > =A0 =A0 =A0 =A0cmdreg=3D0x0117, statreg=3D0x02a0, cachelnsz=3D16 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) > =A0 =A0 =A0 =A0intpin=3Db, irq=3D3 > =A0 =A0 =A0 =A0map[10]: type Memory, range 32, base 0xfe7fd000, size 12, = enabled > pcib0: matched entry for 0.19.INTB > pcib0: slot 19 INTB hardwired to IRQ 17 > ohci early: SMM active, request owner change > found-> vendor=3D0x1002, dev=3D0x4389, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D19, func=3D2 > =A0 =A0 =A0 =A0class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 > =A0 =A0 =A0 =A0cmdreg=3D0x0117, statreg=3D0x02a0, cachelnsz=3D16 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) > =A0 =A0 =A0 =A0intpin=3Dc, irq=3D10 > =A0 =A0 =A0 =A0map[10]: type Memory, range 32, base 0xfe7fc000, size 12, = enabled > pcib0: matched entry for 0.19.INTC > pcib0: slot 19 INTC hardwired to IRQ 18 > ohci early: SMM active, request owner change > found-> vendor=3D0x1002, dev=3D0x438a, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D19, func=3D3 > =A0 =A0 =A0 =A0class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 > =A0 =A0 =A0 =A0cmdreg=3D0x0117, statreg=3D0x02a0, cachelnsz=3D16 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) > =A0 =A0 =A0 =A0intpin=3Db, irq=3D3 > =A0 =A0 =A0 =A0map[10]: type Memory, range 32, base 0xfe7fb000, size 12, = enabled > pcib0: matched entry for 0.19.INTB > pcib0: slot 19 INTB hardwired to IRQ 17 > ohci early: SMM active, request owner change > found-> vendor=3D0x1002, dev=3D0x438b, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D19, func=3D4 > =A0 =A0 =A0 =A0class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 > =A0 =A0 =A0 =A0cmdreg=3D0x0117, statreg=3D0x02a0, cachelnsz=3D16 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) > =A0 =A0 =A0 =A0intpin=3Dc, irq=3D10 > =A0 =A0 =A0 =A0map[10]: type Memory, range 32, base 0xfe7fa000, size 12, = enabled > pcib0: matched entry for 0.19.INTC > pcib0: slot 19 INTC hardwired to IRQ 18 > ohci early: SMM active, request owner change > found-> vendor=3D0x1002, dev=3D0x4386, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D19, func=3D5 > =A0 =A0 =A0 =A0class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 > =A0 =A0 =A0 =A0cmdreg=3D0x0117, statreg=3D0x02b0, cachelnsz=3D16 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) > =A0 =A0 =A0 =A0intpin=3Dd, irq=3D10 > =A0 =A0 =A0 =A0powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 > =A0 =A0 =A0 =A0map[10]: type Memory, range 32, base 0xfe7ff000, size =A08= , enabled > pcib0: matched entry for 0.19.INTD > pcib0: slot 19 INTD hardwired to IRQ 19 > found-> vendor=3D0x1002, dev=3D0x4385, revid=3D0x13 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D20, func=3D0 > =A0 =A0 =A0 =A0class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D1 > =A0 =A0 =A0 =A0cmdreg=3D0x0403, statreg=3D0x0230, cachelnsz=3D0 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x0= 0 (0 ns) > =A0 =A0 =A0 =A0map[10]: type I/O Port, range 32, base 0xb00, size =A04, e= nabled > =A0 =A0 =A0 =A0map[14]: type Memory, range 32, base 0xfed00000, size 10, = enabled > found-> vendor=3D0x1002, dev=3D0x438c, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D20, func=3D1 > =A0 =A0 =A0 =A0class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 > =A0 =A0 =A0 =A0cmdreg=3D0x0005, statreg=3D0x0230, cachelnsz=3D0 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x0= 0 (0 ns) > =A0 =A0 =A0 =A0intpin=3Da, irq=3D255 > =A0 =A0 =A0 =A0MSI supports 1 message > =A0 =A0 =A0 =A0map[20]: type I/O Port, range 32, base 0xff00, size =A04, = enabled > found-> vendor=3D0x1002, dev=3D0x4383, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D20, func=3D2 > =A0 =A0 =A0 =A0class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0 > =A0 =A0 =A0 =A0cmdreg=3D0x0006, statreg=3D0x0410, cachelnsz=3D16 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) > =A0 =A0 =A0 =A0intpin=3Da, irq=3D5 > =A0 =A0 =A0 =A0powerspec 2 =A0supports D0 D3 =A0current D0 > =A0 =A0 =A0 =A0MSI supports 1 message, 64 bit > =A0 =A0 =A0 =A0map[10]: type Memory, range 64, base 0xfe7f4000, size 14, = enabled > pcib0: matched entry for 0.20.INTA > pcib0: slot 20 INTA hardwired to IRQ 16 > found-> vendor=3D0x1002, dev=3D0x438d, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D20, func=3D3 > =A0 =A0 =A0 =A0class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 > =A0 =A0 =A0 =A0cmdreg=3D0x000f, statreg=3D0x0220, cachelnsz=3D0 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x0= 0 (0 ns) > found-> vendor=3D0x1002, dev=3D0x4384, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D20, func=3D4 > =A0 =A0 =A0 =A0class=3D06-04-01, hdrtype=3D0x01, mfdev=3D1 > =A0 =A0 =A0 =A0cmdreg=3D0x0107, statreg=3D0x02a0, cachelnsz=3D0 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x03 (750 ns), maxlat= =3D0x00 (0 ns) > found-> vendor=3D0x1022, dev=3D0x1100, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D24, func=3D0 > =A0 =A0 =A0 =A0class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > =A0 =A0 =A0 =A0cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x0= 0 (0 ns) > found-> vendor=3D0x1022, dev=3D0x1101, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D24, func=3D1 > =A0 =A0 =A0 =A0class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > =A0 =A0 =A0 =A0cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x0= 0 (0 ns) > found-> vendor=3D0x1022, dev=3D0x1102, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D24, func=3D2 > =A0 =A0 =A0 =A0class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > =A0 =A0 =A0 =A0cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x0= 0 (0 ns) > found-> vendor=3D0x1022, dev=3D0x1103, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D24, func=3D3 > =A0 =A0 =A0 =A0class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 > =A0 =A0 =A0 =A0cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x0= 0 (0 ns) > pcib1: at device 1.0 on pci0 > pcib1: =A0 domain =A0 =A0 =A0 =A0 =A0 =A00 > pcib1: =A0 secondary bus =A0 =A0 1 > pcib1: =A0 subordinate bus =A0 1 > pcib1: =A0 I/O decode =A0 =A0 =A0 =A00xc000-0xcfff > pcib1: =A0 memory decode =A0 =A0 0xfe800000-0xfe9fffff > pcib1: =A0 prefetched decode 0xf0000000-0xf7ffffff > pci1: on pcib1 > pci1: domain=3D0, physical bus=3D1 > found-> vendor=3D0x1002, dev=3D0x791e, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D1, slot=3D5, func=3D0 > =A0 =A0 =A0 =A0class=3D03-00-00, hdrtype=3D0x00, mfdev=3D1 > =A0 =A0 =A0 =A0cmdreg=3D0x0107, statreg=3D0x0010, cachelnsz=3D16 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) > =A0 =A0 =A0 =A0intpin=3Da, irq=3D10 > =A0 =A0 =A0 =A0powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 > =A0 =A0 =A0 =A0MSI supports 1 message, 64 bit > =A0 =A0 =A0 =A0map[10]: type Prefetchable Memory, range 64, base 0xf00000= 00, size 27, e > nabled > pcib1: requested memory range 0xf0000000-0xf7ffffff: good > =A0 =A0 =A0 =A0map[18]: type Memory, range 64, base 0xfe9f0000, size 16, = enabled > pcib1: requested memory range 0xfe9f0000-0xfe9fffff: good > =A0 =A0 =A0 =A0map[20]: type I/O Port, range 32, base 0xc000, size =A08, = enabled > pcib1: requested I/O range 0xc000-0xc0ff: in range > =A0 =A0 =A0 =A0map[24]: type Memory, range 32, base 0xfe800000, size 20, = enabled > pcib1: requested memory range 0xfe800000-0xfe8fffff: good > pcib1: matched entry for 1.5.INTA > pcib1: slot 5 INTA hardwired to IRQ 18 > found-> vendor=3D0x1002, dev=3D0x7919, revid=3D0x00 > =A0 =A0 =A0 =A0domain=3D0, bus=3D1, slot=3D5, func=3D2 > =A0 =A0 =A0 =A0class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0 > =A0 =A0 =A0 =A0cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) > =A0 =A0 =A0 =A0intpin=3Db, irq=3D10 > =A0 =A0 =A0 =A0powerspec 2 =A0supports D0 D3 =A0current D0 > =A0 =A0 =A0 =A0MSI supports 1 message, 64 bit > =A0 =A0 =A0 =A0map[10]: type Memory, range 64, base 0xfe9e8000, size 14, = enabled > pcib1: requested memory range 0xfe9e8000-0xfe9ebfff: good > pcib1: matched entry for 1.5.INTB > pcib1: slot 5 INTB hardwired to IRQ 19 > vgapci0: port 0xc000-0xc0ff mem 0xf0000000-0xf7f= fffff,0 > xfe9f0000-0xfe9fffff,0xfe800000-0xfe8fffff irq 18 at device 5.0 on pci1 > pci1: at device 5.2 (no driver attached) > pcib2: at device 7.0 on pci0 > pcib2: =A0 domain =A0 =A0 =A0 =A0 =A0 =A00 > pcib2: =A0 secondary bus =A0 =A0 2 > pcib2: =A0 subordinate bus =A0 2 > pcib2: =A0 I/O decode =A0 =A0 =A0 =A00xd000-0xdfff > pcib2: =A0 memory decode =A0 =A0 0xfea00000-0xfeafffff > pcib2: =A0 no prefetched decode > pci2: on pcib2 > pci2: domain=3D0, physical bus=3D2 > found-> vendor=3D0x10ec, dev=3D0x8168, revid=3D0x01 > =A0 =A0 =A0 =A0domain=3D0, bus=3D2, slot=3D0, func=3D0 > =A0 =A0 =A0 =A0class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > =A0 =A0 =A0 =A0cmdreg=3D0x0107, statreg=3D0x4010, cachelnsz=3D16 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x0= 0 (0 ns) > =A0 =A0 =A0 =A0intpin=3Da, irq=3D10 > =A0 =A0 =A0 =A0powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 > =A0 =A0 =A0 =A0MSI supports 2 messages, 64 bit > =A0 =A0 =A0 =A0map[10]: type I/O Port, range 32, base 0xd800, size =A08, = enabled > pcib2: requested I/O range 0xd800-0xd8ff: in range > =A0 =A0 =A0 =A0map[18]: type Memory, range 64, base 0xfeaff000, size 12, = enabled > pcib2: requested memory range 0xfeaff000-0xfeafffff: good > pcib2: matched entry for 2.0.INTA > pcib2: slot 0 INTA hardwired to IRQ 19 > re0: port 0xd80= 0-0xd8f > f mem 0xfeaff000-0xfeafffff irq 19 at device 0.0 on pci2 > re0: MSI count : 2 > re0: MSI-X count : 0 > re0: attempting to allocate 1 MSI vectors (2 supported) > msi: routing MSI IRQ 256 to local APIC 0 vector 49 > re0: using IRQ 256 for MSI > re0: Using 1 MSI message > re0: Chip rev. 0x38000000 > re0: MAC rev. 0x00000000 > miibus0: on re0 > rgephy0: PHY 1 on miibus= 0 > rgephy0: OUI 0x00e04c, model 0x0011, rev. 2 > rgephy0: =A0none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100b= aseTX-FDX > , 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000bas= eT-FDX- > master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > re0: bpf attached > re0: Ethernet address: 00:19:db:63:76:3e > ahci0: port 0xb000-0xb007,0xa000-0xa003= ,0x9000 > -0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe7ff800-0xfe7ffbff irq 22 at d= evice 1 > 8.0 on pci0 > ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 50 > ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier supported > ahci0: Caps: 64bit NCQ SNTF MPS AL CLO 3Gbps PM PMD 32cmd CCC 4ports > ahci0: Caps2: > ahcich0: at channel 0 on ahci0 > ahcich0: Caps: HPCP > ahcich1: at channel 1 on ahci0 > ahcich1: Caps: HPCP > ahcich2: at channel 2 on ahci0 > ahcich2: Caps: HPCP > ahcich3: at channel 3 on ahci0 > ahcich3: Caps: HPCP > ohci0: mem 0xfe7fe000-0xfe7fefff irq 16 a= t devic > e 19.0 on pci0 > ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 51 > usbus0: on ohci0 > usbus0: bpf attached > ohci0: usbpf: Attached > ohci1: mem 0xfe7fd000-0xfe7fdfff irq 17 a= t devic > e 19.1 on pci0 > ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 52 > usbus1: on ohci1 > usbus1: bpf attached > ohci1: usbpf: Attached > ohci2: mem 0xfe7fc000-0xfe7fcfff irq 18 a= t devic > e 19.2 on pci0 > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 53 > usbus2: on ohci2 > usbus2: bpf attached > ohci2: usbpf: Attached > ohci3: mem 0xfe7fb000-0xfe7fbfff irq 17 a= t devic > e 19.3 on pci0 > usbus3: on ohci3 > usbus3: bpf attached > ohci3: usbpf: Attached > ohci4: mem 0xfe7fa000-0xfe7fafff irq 18 a= t devic > e 19.4 on pci0 > usbus4: on ohci4 > usbus4: bpf attached > ohci4: usbpf: Attached > ehci0: mem 0xfe7ff000-0xfe7ff0ff irq = 19 at d > evice 19.5 on pci0 > ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 54 > ehci0: AMD SB600/700 quirk applied > ehci0: Dropped interrupts workaround enabled > usbus5: EHCI version 1.0 > usbus5: on ehci0 > usbus5: bpf attached > ehci0: usbpf: Attached > pci0: at device 20.0 (no driver attached) > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x1= 77,0x37 > 6,0xff00-0xff0f at device 20.1 on pci0 > ata0: at channel 0 on atapci0 > ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 55 > pci0: at device 20.2 (no driver attached) > isab0: at device 20.3 on pci0 > isa0: on isab0 > pcib3: at device 20.4 on pci0 > pcib3: =A0 domain =A0 =A0 =A0 =A0 =A0 =A00 > pcib3: =A0 secondary bus =A0 =A0 3 > pcib3: =A0 subordinate bus =A0 3 > pcib3: =A0 I/O decode =A0 =A0 =A0 =A00xe000-0xefff > pcib3: =A0 memory decode =A0 =A0 0xfeb00000-0xfebfffff > pcib3: =A0 no prefetched decode > pcib3: =A0 Subtractively decoded bridge. > pci3: on pcib3 > pci3: domain=3D0, physical bus=3D3 > found-> vendor=3D0x1106, dev=3D0x3044, revid=3D0xc0 > =A0 =A0 =A0 =A0domain=3D0, bus=3D3, slot=3D0, func=3D0 > =A0 =A0 =A0 =A0class=3D0c-00-10, hdrtype=3D0x00, mfdev=3D0 > =A0 =A0 =A0 =A0cmdreg=3D0x0117, statreg=3D0x0210, cachelnsz=3D16 (dwords) > =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x20 (8000 ns) > =A0 =A0 =A0 =A0intpin=3Da, irq=3D4 > =A0 =A0 =A0 =A0powerspec 2 =A0supports D0 D2 D3 =A0current D0 > =A0 =A0 =A0 =A0map[10]: type Memory, range 32, base 0xfebff800, size 11, = enabled > pcib3: requested memory range 0xfebff800-0xfebfffff: good > =A0 =A0 =A0 =A0map[14]: type I/O Port, range 32, base 0xe800, size =A07, = enabled > pcib3: requested I/O range 0xe800-0xe87f: in range > pcib3: matched entry for 3.0.INTA > pcib3: slot 0 INTA hardwired to IRQ 20 > pci3: at device 0.0 (no driver attached) > acpi_button0: on acpi0 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 56 > Event timer "i8254" frequency 1193182 Hz quality 100 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustme= nt 0.50 > 0000000s) > ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 57 > Event timer "RTC" frequency 32768 Hz quality 0 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > device_attach: hpet0 attach returned 12 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0065 > atkbd: keyboard ID 0x41ab (2) > kbd0 at atkbd0 > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 58 > atkbd0: [GIANT-LOCKED] > psm0: unable to allocate IRQ > acpi0: wakeup code va 0xffffff8087fae000 pa 0x4000 > isa_probe_children: disabling PnP devices > atkbdc: atkbdc0 already exists; skipping it > atrtc: atrtc0 already exists; skipping it > attimer: attimer0 already exists; skipping it > sc: sc0 already exists; skipping it > isa_probe_children: probing non-PnP devices > orm0: at iomem 0xcd800-0xce7ff 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 > fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 > ppc0 failed to probe at irq 7 on isa0 > uart0 failed to probe at port 0x3f8 irq 4 on isa0 > uart1 failed to probe at port 0x2f8 irq 3 on isa0 > isa_probe_children: probing PnP devices > acpi_throttle0: on cpu0 > acpi_throttle0: CLK_VAL field overlaps THT_EN bit > device_attach: acpi_throttle0 attach returned 6 > powernow0: on cpu0 > powernow0: STATUS: 0x310a120c0a0e020e > powernow0: STATUS: maxfid: 0x0e > powernow0: STATUS: maxvid: 0x0a > device_attach: powernow0 attach returned 6 > powernow1: on cpu1 > powernow1: STATUS: 0x310a120c0a0e020e > powernow1: STATUS: maxfid: 0x0e > powernow1: STATUS: maxvid: 0x0a > device_attach: powernow1 attach returned 6 > Device configuration finished. > procfs registered > lapic: Divisor 2, Frequency 99761963 Hz > Timecounters tick every 1.000 msec > vlan: initialized, using hash tables with chaining > lo0: bpf attached > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 12Mbps Full Speed USB v1.0 > usbus4: 12Mbps Full Speed USB v1.0 > usbus5: 480Mbps High Speed USB v2.0 > ahcich0: AHCI reset... > ahcich0: SATA connect time=3D100us status=3D00000123 > ahcich0: AHCI reset: device found > ahcich1: AHCI reset... > ahcich1: SATA connect time=3D100us status=3D00000123 > ahcich1: AHCI reset: device found > ahcich2: AHCI reset... > ahcich2: SATA connect time=3D100us status=3D00000123 > ahcich2: AHCI reset: device found > ahcich3: AHCI reset... > ahcich3: SATA connect time=3D100us status=3D00000123 > ahcich3: AHCI reset: device found > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > ugen4.1: at usbus4 > uhub4: on usbus4 > ugen5.1: at usbus5 > uhub5: on usbus5 > ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 > ahcich0: AHCI reset: device ready after 100ms > Expensive timeout(9) function: 0xffffffff802db3d0(0xfffffe00015abb00) 0.0= 5421135 > 9 s > (aprobe0:ahcich0:0:15:0): Command timed out > (aprobe0:ahcich0:0:15:0): Error 5, Retries exhausted > (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 > ahcich1: AHCI reset: device ready after 100ms > (aprobe1:ahcich1:0:15:0): Command timed out > (aprobe1:ahcich1:0:15:0): Error 5, Retries exhausted > (aprobe0:ahcich1:0:0:0): SIGNATURE: 0000 > ahcich2: AHCI reset: device ready after 100ms > (aprobe2:ahcich2:0:15:0): Command timed out > (aprobe2:ahcich2:0:15:0): Error 5, Retries exhausted > (aprobe0:ahcich2:0:0:0): SIGNATURE: 0000 > ahcich3: AHCI reset: device ready after 100ms > (aprobe3:ahcich3:0:15:0): Command timed out > (aprobe3:ahcich3:0:15:0): Error 5, Retries exhausted > (aprobe0:ahcich3:0:0:0): SIGNATURE: 0000 > ata0: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb > ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb > ata0: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x30000 > (aprobe1:ata0:0:0:0): SIGNATURE: eb14 > (aprobe0:ata0:0:1:0): SIGNATURE: eb14 > pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 > pass0: ATA-7 SATA 2.x device > pass0: Serial Number 6QF0W6RN > GEOM: new disk cd0 > GEOM: new disk cd1 > pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > pass0: Command Queueing enabled > (cd0:ata0:0:0:0): SCSI status error > (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd0:ata0:0:0:0): CAM status: SCSI Status Error > (cd0:ata0:0:0:0): SCSI status: Check Condition > (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) > (cd0:ata0:0:0:0): Error 6, Unretryable error > cd0 at ata0 bus 0 scbus4 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: Serial Number 2005082900 > cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present > pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 > pass1: ATA-8 SATA 3.x device > pass1: Serial Number W24044SM > pass1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > pass1: Command Queueing enabled > pass2 at ahcich2 bus 0 scbus2 target 0 lun 0 > (cd1:ata0:0:1:0): SCSI status error > (cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd1:ata0:0:1:0): CAM status: SCSI Status Error > (cd1:ata0:0:1:0): SCSI status: Check Condition > (cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tr= ay clos > ed) > (cd1:ata0:0:1:0): Error 6, Unretryable error > cd1 at ata0 bus 0 scbus4 target 1 lun 0 > cd1: Removable CD-ROM SCSI-0 device > cd1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > cd1: Attempt to query device size failed: NOT READY, Medium not present -= tray c > losed > pass2: ATA-7 SATA 2.x device > pass2: Serial Number 6QF0ZTQM > pass2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > pass2: Command Queueing enabled > pass3 at ahcich3 bus 0 scbus3 target 0 lun 0 > pass3: ATA-8 SATA 3.x device > pass3: Serial Number W240643V > pass3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > pass3: Command Queueing enabled > pass4 at ata0 bus 0 scbus4 target 0 lun 0 > pass4: Removable CD-ROM SCSI-0 device > pass4: Serial Number 2005082900 > pass4: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > (cd0:ata0:0:0:0): SCSI status error > (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd0:ata0:0:0:0): CAM status: SCSI Status Error > (cd0:ata0:0:0:0): SCSI status: Check Condition > (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) > (cd0:ata0:0:0:0): Error 6, Unretryable error > pass5 at ata0 bus 0 scbus4 target 1 lun 0 > pass5: Removable CD-ROM SCSI-0 device > pass5: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-7 SATA 2.x device > ada0: Serial Number 6QF0W6RN > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad4 > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > ada1: ATA-8 SATA 3.x device > ada1: Serial Number W24044SM > (cd0:ata0:0:0:0): SCSI status error > (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd0:ata0:0:0:0): CAM status: SCSI Status Error > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub3: 2 ports with 2 removable, self powered > uhub4: 2 ports with 2 removable, self powered > (cd0:ata0:0:0:0): SCSI status: Check Condition > (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) > (cd0:ata0:0:0:0): Error 6, Unretryable error > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada1: Previously was known as ad6 > ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 > ada2: ATA-7 SATA 2.x device > ada2: Serial Number 6QF0ZTQM > ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada2: Command Queueing enabled > ada2: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) > ada2: Previously was known as ad8 > ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 > ada3: ATA-8 SATA 3.x device > (cd0:ata0:0:0:0): SCSI status error > (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd0:ata0:0:0:0): CAM status: SCSI Status Error > (cd0:ata0:0:0:0): SCSI status: Check Condition > (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) > (cd0:ata0:0:0:0): Error 6, Unretryable error > ada3: Serial Number W240643V > ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada3: Command Queueing enabled > ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) > ada3: Previously was known as ad10 > SMP: AP CPU #1 Launched! > cpu1 AP: > =A0 =A0 ID: 0x01000000 =A0 VER: 0x80050010 LDR: 0x00000000 DFR: 0xfffffff= f > =A0lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > =A0timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 > TSC timecounter discards lower 8 bit(s) > Timecounter "TSC-low" frequency 8573416 Hz quality -100 > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > (cd1:ata0:0:1:0): SCSI status error > (cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd1:ata0:0:1:0): CAM status: SCSI Status Error > (cd1:ata0:0:1:0): SCSI status: Check Condition > (cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tr= ay clos > ed) > (cd1:ata0:0:1:0): Error 6, Unretryable error > (cd1:ata0:0:1:0): SCSI status error > (cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd1:ata0:0:1:0): CAM status: SCSI Status Error > (cd1:ata0:0:1:0): SCSI status: Check Condition > (cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tr= ay clos > ed) > (cd1:ata0:0:1:0): Error 6, Unretryable error > (cd1:ata0:0:1:0): SCSI status error > (cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (cd1:ata0:0:1:0): CAM status: SCSI Status Error > (cd1:ata0:0:1:0): SCSI status: Check Condition > (cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tr= ay clos > ed) > (cd1:ata0:0:1:0): Error 6, Unretryable error > GEOM: new disk ada0 > GEOM: new disk ada1 > GEOM: new disk ada2 > GEOM: new disk ada3 > GEOM: ada2s1: geometry does not match label (255h,63s !=3D 16h,63s). > GEOM: ada2s1: media size does not match label. > Root mount waiting for: usbus5 > Root mount waiting for: usbus5 > Root mount waiting for: usbus5 > uhub5: 10 ports with 10 removable, self powered > Root mount waiting for: usbus5 > Trying to mount root from ufs:/dev/ada0p2 [rw]... > start_init: trying /sbin/init > ugen1.2: at usbus1 > ums0: 2> on usbus1 > ums0: 5 buttons and [XYZ] coordinates ID=3D0 > ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is pr= esent; > =A0 =A0 =A0 =A0 =A0 =A0to enable, add "vfs.zfs.prefetch_disable=3D0" to /= boot/loader.conf. > ZFS filesystem version 5 > ZFS storage pool version 28 > * csup > -------------------------------------------------------------- >>>> Running /usr/bin/csup > -------------------------------------------------------------- > Parsing supfile "/root/csup/date-supfile" > Connecting to cvsup.uk.freebsd.org > Cannot connect to 2001:630:212:8:20e:cff:fe09:a69c: Protocol not supporte= d > Connected to 131.111.8.41 > Server software version: SNAP_16_1h > MD5 authentication started > MD5 authentication successful > Negotiating file attribute support > Exchanging collection information > Establishing multiplexed-mode data connection > Running > Updating collection src-all/cvs > =A0Edit src/sys/dev/acpica/acpi.c > =A0Add delta 1.305.2.4 2012.02.23.22.26.14 jkim > =A0Edit src/sys/dev/acpica/acpi_ec.c > =A0Add delta 1.95.2.2 2012.02.23.22.26.14 jkim > =A0Edit src/sys/dev/acpica/acpi_hpet.c > =A0Add delta 1.38.2.2 2012.02.23.22.26.14 jkim > =A0Edit src/sys/dev/acpica/acpi_timer.c > =A0Add delta 1.50.2.3 2012.02.23.22.26.14 jkim > =A0Edit src/sys/dev/acpica/acpivar.h > =A0Add delta 1.125.2.4 2012.02.23.22.26.14 jkim > Shutting down connection to server > Finished successfully > * supfil > *default host=3Dcvsup.uk.freebsd.org > *default base=3D/var/db > *default prefix=3D/usr > *default release=3Dcvs tag=3DRELENG_9 > > # ok: > # *default date=3D2012.02.23.22.26.00 > # fail: > *default date=3D2012.02.23.22.26.30 > > *default delete use-rel-suffix > *default compress > src-all > * pciconf -lvb > hostb0@pci0:0:0:0: =A0 =A0 =A0class=3D0x060000 card=3D0x79101002 chip=3D0= x79101002 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'RS690 Host Bridge' > =A0 =A0class =A0 =A0 =A0=3D bridge > =A0 =A0subclass =A0 =3D HOST-PCI > pcib1@pci0:0:1:0: =A0 =A0 =A0 class=3D0x060400 card=3D0x79121002 chip=3D0= x79121002 rev=3D0x00 > hdr=3D0x01 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'RS690 PCI to PCI Bridge (Internal gfx)' > =A0 =A0class =A0 =A0 =A0=3D bridge > =A0 =A0subclass =A0 =3D PCI-PCI > pcib2@pci0:0:7:0: =A0 =A0 =A0 class=3D0x060400 card=3D0x79101002 chip=3D0= x79171002 rev=3D0x00 > hdr=3D0x01 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'RS690 PCI to PCI Bridge (PCI Express Port 3)' > =A0 =A0class =A0 =A0 =A0=3D bridge > =A0 =A0subclass =A0 =3D PCI-PCI > ahci0@pci0:0:18:0: =A0 =A0 =A0class=3D0x010601 card=3D0x73291462 chip=3D0= x43801002 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'SB600 Non-Raid-5 SATA' > =A0 =A0class =A0 =A0 =A0=3D mass storage > =A0 =A0subclass =A0 =3D SATA > =A0 =A0bar =A0 [10] =3D type I/O Port, range 32, base 0xb000, size =A08, = enabled > =A0 =A0bar =A0 [14] =3D type I/O Port, range 32, base 0xa000, size =A04, = enabled > =A0 =A0bar =A0 [18] =3D type I/O Port, range 32, base 0x9000, size =A08, = enabled > =A0 =A0bar =A0 [1c] =3D type I/O Port, range 32, base 0x8000, size =A04, = enabled > =A0 =A0bar =A0 [20] =3D type I/O Port, range 32, base 0x7000, size 16, en= abled > =A0 =A0bar =A0 [24] =3D type Memory, range 32, base 0xfe7ff800, size 1024= , enabled > ohci0@pci0:0:19:0: =A0 =A0 =A0class=3D0x0c0310 card=3D0x73271462 chip=3D0= x43871002 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'SB600 USB (OHCI0)' > =A0 =A0class =A0 =A0 =A0=3D serial bus > =A0 =A0subclass =A0 =3D USB > =A0 =A0bar =A0 [10] =3D type Memory, range 32, base 0xfe7fe000, size 4096= , enabled > ohci1@pci0:0:19:1: =A0 =A0 =A0class=3D0x0c0310 card=3D0x73271462 chip=3D0= x43881002 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'SB600 USB (OHCI1)' > =A0 =A0class =A0 =A0 =A0=3D serial bus > =A0 =A0subclass =A0 =3D USB > =A0 =A0bar =A0 [10] =3D type Memory, range 32, base 0xfe7fd000, size 4096= , enabled > ohci2@pci0:0:19:2: =A0 =A0 =A0class=3D0x0c0310 card=3D0x73271462 chip=3D0= x43891002 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'SB600 USB (OHCI2)' > =A0 =A0class =A0 =A0 =A0=3D serial bus > =A0 =A0subclass =A0 =3D USB > =A0 =A0bar =A0 [10] =3D type Memory, range 32, base 0xfe7fc000, size 4096= , enabled > ohci3@pci0:0:19:3: =A0 =A0 =A0class=3D0x0c0310 card=3D0x73271462 chip=3D0= x438a1002 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'SB600 USB (OHCI3)' > =A0 =A0class =A0 =A0 =A0=3D serial bus > =A0 =A0subclass =A0 =3D USB > =A0 =A0bar =A0 [10] =3D type Memory, range 32, base 0xfe7fb000, size 4096= , enabled > ohci4@pci0:0:19:4: =A0 =A0 =A0class=3D0x0c0310 card=3D0x73271462 chip=3D0= x438b1002 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'SB600 USB (OHCI4)' > =A0 =A0class =A0 =A0 =A0=3D serial bus > =A0 =A0subclass =A0 =3D USB > =A0 =A0bar =A0 [10] =3D type Memory, range 32, base 0xfe7fa000, size 4096= , enabled > ehci0@pci0:0:19:5: =A0 =A0 =A0class=3D0x0c0320 card=3D0x73271462 chip=3D0= x43861002 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'SB600 USB Controller (EHCI)' > =A0 =A0class =A0 =A0 =A0=3D serial bus > =A0 =A0subclass =A0 =3D USB > =A0 =A0bar =A0 [10] =3D type Memory, range 32, base 0xfe7ff000, size 256,= enabled > none0@pci0:0:20:0: =A0 =A0 =A0class=3D0x0c0500 card=3D0x73271462 chip=3D0= x43851002 rev=3D0x13 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'SBx00 SMBus Controller' > =A0 =A0class =A0 =A0 =A0=3D serial bus > =A0 =A0subclass =A0 =3D SMBus > =A0 =A0bar =A0 [10] =3D type I/O Port, range 32, base 0xb00, size 16, ena= bled > =A0 =A0bar =A0 [14] =3D type Memory, range 32, base 0xfed00000, size 1024= , enabled > atapci0@pci0:0:20:1: =A0 =A0class=3D0x01018a card=3D0x73271462 chip=3D0x4= 38c1002 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'SB600 IDE' > =A0 =A0class =A0 =A0 =A0=3D mass storage > =A0 =A0subclass =A0 =3D ATA > =A0 =A0bar =A0 [20] =3D type I/O Port, range 32, base 0xff00, size 16, en= abled > none1@pci0:0:20:2: =A0 =A0 =A0class=3D0x040300 card=3D0x73271462 chip=3D0= x43831002 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'SBx00 Azalia (Intel HDA)' > =A0 =A0class =A0 =A0 =A0=3D multimedia > =A0 =A0subclass =A0 =3D HDA > =A0 =A0bar =A0 [10] =3D type Memory, range 64, base 0xfe7f4000, size 1638= 4, enabled > isab0@pci0:0:20:3: =A0 =A0 =A0class=3D0x060100 card=3D0x73271462 chip=3D0= x438d1002 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'SB600 PCI to LPC Bridge' > =A0 =A0class =A0 =A0 =A0=3D bridge > =A0 =A0subclass =A0 =3D PCI-ISA > pcib3@pci0:0:20:4: =A0 =A0 =A0class=3D0x060401 card=3D0x00000000 chip=3D0= x43841002 rev=3D0x00 > hdr=3D0x01 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'SBx00 PCI to PCI Bridge' > =A0 =A0class =A0 =A0 =A0=3D bridge > =A0 =A0subclass =A0 =3D PCI-PCI > hostb1@pci0:0:24:0: =A0 =A0 class=3D0x060000 card=3D0x00000000 chip=3D0x1= 1001022 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'Advanced Micro Devices [AMD]' > =A0 =A0device =A0 =A0 =3D 'K8 [Athlon64/Opteron] HyperTransport Technolog= y Configuration' > > =A0 =A0class =A0 =A0 =A0=3D bridge > =A0 =A0subclass =A0 =3D HOST-PCI > hostb2@pci0:0:24:1: =A0 =A0 class=3D0x060000 card=3D0x00000000 chip=3D0x1= 1011022 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'Advanced Micro Devices [AMD]' > =A0 =A0device =A0 =A0 =3D 'K8 [Athlon64/Opteron] Address Map' > =A0 =A0class =A0 =A0 =A0=3D bridge > =A0 =A0subclass =A0 =3D HOST-PCI > hostb3@pci0:0:24:2: =A0 =A0 class=3D0x060000 card=3D0x00000000 chip=3D0x1= 1021022 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'Advanced Micro Devices [AMD]' > =A0 =A0device =A0 =A0 =3D 'K8 [Athlon64/Opteron] DRAM Controller' > =A0 =A0class =A0 =A0 =A0=3D bridge > =A0 =A0subclass =A0 =3D HOST-PCI > hostb4@pci0:0:24:3: =A0 =A0 class=3D0x060000 card=3D0x00000000 chip=3D0x1= 1031022 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'Advanced Micro Devices [AMD]' > =A0 =A0device =A0 =A0 =3D 'K8 [Athlon64/Opteron] Miscellaneous Control' > =A0 =A0class =A0 =A0 =A0=3D bridge > =A0 =A0subclass =A0 =3D HOST-PCI > vgapci0@pci0:1:5:0: =A0 =A0 class=3D0x030000 card=3D0x73271462 chip=3D0x7= 91e1002 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'RS690 [Radeon X1200 Series]' > =A0 =A0class =A0 =A0 =A0=3D display > =A0 =A0subclass =A0 =3D VGA > =A0 =A0bar =A0 [10] =3D type Prefetchable Memory, range 64, base 0xf00000= 00, size 13421 > 7728, enabled > =A0 =A0bar =A0 [18] =3D type Memory, range 64, base 0xfe9f0000, size 6553= 6, enabled > =A0 =A0bar =A0 [20] =3D type I/O Port, range 32, base 0xc000, size 256, e= nabled > =A0 =A0bar =A0 [24] =3D type Memory, range 32, base 0xfe800000, size 1048= 576, enabled > none2@pci0:1:5:2: =A0 =A0 =A0 class=3D0x040300 card=3D0x79191002 chip=3D0= x79191002 rev=3D0x00 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' > =A0 =A0device =A0 =A0 =3D 'Radeon X1200 Series Audio Controller' > =A0 =A0class =A0 =A0 =A0=3D multimedia > =A0 =A0subclass =A0 =3D HDA > =A0 =A0bar =A0 [10] =3D type Memory, range 64, base 0xfe9e8000, size 1638= 4, enabled > re0@pci0:2:0:0: class=3D0x020000 card=3D0x327c1462 chip=3D0x816810ec rev= =3D0x01 hdr=3D0x00 > > =A0 =A0vendor =A0 =A0 =3D 'Realtek Semiconductor Co., Ltd.' > =A0 =A0device =A0 =A0 =3D 'RTL8111/8168B PCI Express Gigabit Ethernet con= troller' > =A0 =A0class =A0 =A0 =A0=3D network > =A0 =A0subclass =A0 =3D ethernet > =A0 =A0bar =A0 [10] =3D type I/O Port, range 32, base 0xd800, size 256, e= nabled > =A0 =A0bar =A0 [18] =3D type Memory, range 64, base 0xfeaff000, size 4096= , enabled > none3@pci0:3:0:0: =A0 =A0 =A0 class=3D0x0c0010 card=3D0x086c0574 chip=3D0= x30441106 rev=3D0xc0 > hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'VIA Technologies, Inc.' > =A0 =A0device =A0 =A0 =3D 'VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Control= ler' > =A0 =A0class =A0 =A0 =A0=3D serial bus > =A0 =A0subclass =A0 =3D FireWire > =A0 =A0bar =A0 [10] =3D type Memory, range 32, base 0xfebff800, size 2048= , enabled > =A0 =A0bar =A0 [14] =3D type I/O Port, range 32, base 0xe800, size 128, e= nabled > > > > On 29 February 2012 14:12, John Baldwin wrote: >> On Tuesday, February 28, 2012 6:10:51 pm Harry Newton wrote: >>> Adrian - thanks ! >>> >>> John, if you write me a shopping list of what information you think >>> useful, assuming you have time and inclination, I'll do my best >>> provide it. >> >> Mostly a verbose boot of 9.0-RELEASE and what you see now. =A0If anythin= g the >> only changes I can think of since the release are to make some of the PC= I code >> more lenient. =A0You could also try to narrow down exactly which revisio= n causes >> the hang using a binary search of 9.0-STABLE since the release. >> >> -- >> John Baldwin > > > > -- > Harry Newton From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 03:42:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 894E4106564A for ; Sat, 3 Mar 2012 03:42:59 +0000 (UTC) (envelope-from harry@yewbarrow.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4B2058FC0A for ; Sat, 3 Mar 2012 03:42:59 +0000 (UTC) Received: by iahk25 with SMTP id k25so4129902iah.13 for ; Fri, 02 Mar 2012 19:42:58 -0800 (PST) Received-SPF: pass (google.com: domain of harry@yewbarrow.net designates 10.50.46.194 as permitted sender) client-ip=10.50.46.194; Authentication-Results: mr.google.com; spf=pass (google.com: domain of harry@yewbarrow.net designates 10.50.46.194 as permitted sender) smtp.mail=harry@yewbarrow.net Received: from mr.google.com ([10.50.46.194]) by 10.50.46.194 with SMTP id x2mr589701igm.60.1330746178883 (num_hops = 1); Fri, 02 Mar 2012 19:42:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.46.194 with SMTP id x2mr495965igm.60.1330746178735; Fri, 02 Mar 2012 19:42:58 -0800 (PST) Sender: harry@yewbarrow.net Received: by 10.50.173.2 with HTTP; Fri, 2 Mar 2012 19:42:58 -0800 (PST) In-Reply-To: References: <201202290912.14012.jhb@freebsd.org> Date: Sat, 3 Mar 2012 03:42:58 +0000 X-Google-Sender-Auth: V6kJ-9CDlrcUeM1ONteYvqYAoGs Message-ID: From: Harry Newton To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmFEwSKaWWJqIma5wj6SQT9eH8rOYlYHra6V/iIqRqQdmyRzISrsQa7HzErh5edLk7fpoRn Cc: Ian Lepore , freebsd-stable@freebsd.org, John Baldwin Subject: Re: Regression between 9-RELEASE and 9-STABLE [PCIB ?] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 03:42:59 -0000 Wilco ! Anything else I could usefully add ? - H On 3 March 2012 03:35, Adrian Chadd wrote: > Hi! > > You now officially have enough information to fill out a PR! Thankyou > so very much for finding out which particular commit/commits caused > this regression for you! > > http://www.freebsd.org/send-pr.html > > Would you mind doing this? :) > > Thanks! > > > Adrian > > On 2 March 2012 18:50, Harry Newton wrote: >> John, investigations shew bug introduced between 2012.02.23.22.26.00 >> and 2012.02.23.22.26.30 in these files: >> >> =A0Edit src/sys/dev/acpica/acpi.c >> =A0Add delta 1.305.2.4 2012.02.23.22.26.14 jkim >> =A0Edit src/sys/dev/acpica/acpi_ec.c >> =A0Add delta 1.95.2.2 2012.02.23.22.26.14 jkim >> =A0Edit src/sys/dev/acpica/acpi_hpet.c >> =A0Add delta 1.38.2.2 2012.02.23.22.26.14 jkim >> =A0Edit src/sys/dev/acpica/acpi_timer.c >> =A0Add delta 1.50.2.3 2012.02.23.22.26.14 jkim >> =A0Edit src/sys/dev/acpica/acpivar.h >> =A0Add delta 1.125.2.4 2012.02.23.22.26.14 jkim >> >> More details below. Let me know if I can do anything else. - H >> >> * dmesg >> Table 'FACP' at 0x77fd0200 >> Table 'APIC' at 0x77fd0390 >> APIC: Found table at 0x77fd0390 >> APIC: Using the MADT enumerator. >> MADT: Found CPU APIC ID 0 ACPI ID 1: enabled >> SMP: Added CPU 0 (AP) >> MADT: Found CPU APIC ID 1 ACPI ID 2: enabled >> SMP: Added CPU 1 (AP) >> Copyright (c) 1992-2012 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> =A0 =A0 =A0 =A0The Regents of the University of California. All rights r= eserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 9.0-STABLE #19: Fri Mar =A02 22:28:14 GMT 2012 >> =A0 =A0toor@hydra.yewbarrow.net:/usr/obj/usr/src/sys/HYDRA amd64 >> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >> Preloaded elf kernel "/boot/kernel.old/kernel" at 0xffffffff80b6f000. >> Calibrating TSC clock ... TSC clock: 2194794720 Hz >> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2194.79-MHz K8-clas= s CPU) >> =A0Origin =3D "AuthenticAMD" =A0Id =3D 0x40fb2 =A0Family =3D f =A0Model = =3D 4b =A0Stepping =3D 2 >> =A0Features=3D0x178bfbff> MOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT> >> =A0Features2=3D0x2001 >> =A0AMD Features=3D0xea500800 >> =A0AMD 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 assoc= iative >> 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: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associa= tive >> real memory =A0=3D 2147483648 (2048 MB) >> Physical memory chunk(s): >> 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) >> 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) >> 0x0000000000b9e000 - 0x0000000074722fff, 1941458944 bytes (473989 pages) >> avail memory =3D 1926897664 (1837 MB) >> Event timer "LAPIC" quality 400 >> ACPI APIC Table: <030107 APIC1519> >> INTR: Adding local APIC 1 as a target >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> FreeBSD/SMP: 1 package(s) x 2 core(s) >> =A0cpu0 (BSP): APIC ID: =A00 >> =A0cpu1 (AP): APIC ID: =A01 >> x86bios: =A0IVT 0x000000-0x0004ff at 0xfffffe0000000000 >> x86bios: SSEG 0x001000-0x001fff at 0xffffff800020d000 >> x86bios: EBDA 0x09f000-0x09ffff at 0xfffffe000009f000 >> x86bios: =A0ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 >> APIC: CPU 0 has ACPI ID 1 >> APIC: CPU 1 has ACPI ID 2 >> ULE: setup cpu 0 >> ULE: setup cpu 1 >> ACPI: RSDP 0xf96d0 00014 (v00 ACPIAM) >> ACPI: RSDT 0x77fd0000 00038 (v01 030107 RSDT1519 20070301 MSFT 00000097) >> ACPI: FACP 0x77fd0200 00084 (v02 030107 FACP1519 20070301 MSFT 00000097) >> ACPI: DSDT 0x77fd0430 044A0 (v01 =A01ADNC 1ADNCB33 00000B33 INTL 2005111= 7) >> ACPI: FACS 0x77fde000 00040 >> ACPI: APIC 0x77fd0390 0005C (v01 030107 APIC1519 20070301 MSFT 00000097) >> ACPI: MCFG 0x77fd03f0 0003C (v01 030107 OEMMCFG =A020070301 MSFT 0000009= 7) >> ACPI: OEMB 0x77fde040 00071 (v01 030107 OEMB1519 20070301 MSFT 00000097) >> ACPI: HPET 0x77fd48d0 00038 (v01 030107 OEMHPET =A020070301 MSFT 0000009= 7) >> MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 >> ioapic0: Routing external 8259A's -> intpin 0 >> MADT: Interrupt override: source 0, irq 2 >> ioapic0: Routing IRQ 0 -> intpin 2 >> MADT: Interrupt override: source 9, irq 9 >> ioapic0: intpin 9 trigger: level >> ioapic0: intpin 9 polarity: low >> ioapic0 irqs 0-23 on motherboard >> cpu0 BSP: >> =A0 =A0 ID: 0x00000000 =A0 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffff= ff >> =A0lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff >> =A0timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 >> null: >> random: >> io: >> nfslock: pseudo-device >> kbd: new array size 4 >> kbd1 at kbdmux0 >> mem: >> acpi0: <030107 RSDT1519> on motherboard >> PCIe: Memory Mapped configuration base @ 0xe0000000 >> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 >> ACPI: Executed 3 blocks of module-level executable AML code >> acpi0: Power Button (fixed) >> acpi0: reservation of fee00000, 1000 (3) failed >> acpi0: reservation of ffb80000, 80000 (3) failed >> acpi0: reservation of fff80000, 80000 (3) failed >> acpi0: reservation of 0, a0000 (3) failed >> acpi0: reservation of 100000, 77f00000 (3) failed >> ACPI timer: 1/1 1/2 0/3 1/2 1/2 1/2 1/3 1/2 1/2 1/2 -> 9 >> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 >> cpu0: on acpi0 >> cpu0: switching to generic Cx mode >> cpu1: on acpi0 >> pci_link0: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >> =A0Initial Probe =A0 =A0 =A0 0 =A0 =A05 =A0 N =A0 =A0 0 =A03 4 5 7 10 11= 12 14 15 >> =A0Validation =A0 =A0 =A0 =A0 =A00 =A0 =A05 =A0 N =A0 =A0 0 =A03 4 5 7 1= 0 11 12 14 15 >> =A0After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 1= 2 14 15 >> pci_link1: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >> =A0Initial Probe =A0 =A0 =A0 0 =A0 =A03 =A0 N =A0 =A0 0 =A03 4 5 7 10 11= 12 14 15 >> =A0Validation =A0 =A0 =A0 =A0 =A00 =A0 =A03 =A0 N =A0 =A0 0 =A03 4 5 7 1= 0 11 12 14 15 >> =A0After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 1= 2 14 15 >> pci_link2: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >> =A0Initial Probe =A0 =A0 =A0 0 =A0 10 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 1= 2 14 15 >> =A0Validation =A0 =A0 =A0 =A0 =A00 =A0 10 =A0 N =A0 =A0 0 =A03 4 5 7 10 = 11 12 14 15 >> =A0After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 1= 2 14 15 >> pci_link3: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >> =A0Initial Probe =A0 =A0 =A0 0 =A0 10 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 1= 2 14 15 >> =A0Validation =A0 =A0 =A0 =A0 =A00 =A0 10 =A0 N =A0 =A0 0 =A03 4 5 7 10 = 11 12 14 15 >> =A0After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 1= 2 14 15 >> pci_link4: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >> =A0Initial Probe =A0 =A0 =A0 0 =A0 =A04 =A0 N =A0 =A0 0 =A03 4 5 7 10 11= 12 14 15 >> =A0Validation =A0 =A0 =A0 =A0 =A00 =A0 =A04 =A0 N =A0 =A0 0 =A03 4 5 7 1= 0 11 12 14 15 >> =A0After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 1= 2 14 15 >> pci_link5: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >> =A0Initial Probe =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 1= 2 14 15 >> =A0Validation =A0 =A0 =A0 =A0 =A00 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 = 11 12 14 15 >> =A0After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 1= 2 14 15 >> pci_link6: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >> =A0Initial Probe =A0 =A0 =A0 0 =A0 11 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 1= 2 14 15 >> =A0Validation =A0 =A0 =A0 =A0 =A00 =A0 11 =A0 N =A0 =A0 0 =A03 4 5 7 10 = 11 12 14 15 >> =A0After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 1= 2 14 15 >> pci_link7: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >> =A0Initial Probe =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 1= 2 14 15 >> =A0Validation =A0 =A0 =A0 =A0 =A00 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 = 11 12 14 15 >> =A0After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 5 7 10 11 1= 2 14 15 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pci0: domain=3D0, physical bus=3D0 >> found-> vendor=3D0x1002, dev=3D0x7910, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D0, func=3D0 >> =A0 =A0 =A0 =A0class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >> =A0 =A0 =A0 =A0cmdreg=3D0x0006, statreg=3D0x2220, cachelnsz=3D0 (dwords) >> =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x= 00 (0 ns) >> found-> vendor=3D0x1002, dev=3D0x7912, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D1, func=3D0 >> =A0 =A0 =A0 =A0class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 >> =A0 =A0 =A0 =A0cmdreg=3D0x0107, statreg=3D0x0230, cachelnsz=3D0 (dwords) >> =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x1a (6500 ns), maxla= t=3D0x00 (0 ns) >> found-> vendor=3D0x1002, dev=3D0x7917, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D7, func=3D0 >> =A0 =A0 =A0 =A0class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 >> =A0 =A0 =A0 =A0cmdreg=3D0x0107, statreg=3D0x4010, cachelnsz=3D16 (dwords= ) >> =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x03 (750 ns), maxlat=3D= 0x00 (0 ns) >> =A0 =A0 =A0 =A0powerspec 3 =A0supports D0 D3 =A0current D0 >> =A0 =A0 =A0 =A0MSI supports 1 message >> found-> vendor=3D0x1002, dev=3D0x4380, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D18, func=3D0 >> =A0 =A0 =A0 =A0class=3D01-06-01, hdrtype=3D0x00, mfdev=3D0 >> =A0 =A0 =A0 =A0cmdreg=3D0x0107, statreg=3D0x0230, cachelnsz=3D16 (dwords= ) >> =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >> =A0 =A0 =A0 =A0intpin=3Da, irq=3D11 >> =A0 =A0 =A0 =A0powerspec 2 =A0supports D0 D3 =A0current D0 >> =A0 =A0 =A0 =A0map[10]: type I/O Port, range 32, base 0xb000, size =A03,= enabled >> =A0 =A0 =A0 =A0map[14]: type I/O Port, range 32, base 0xa000, size =A02,= enabled >> =A0 =A0 =A0 =A0map[18]: type I/O Port, range 32, base 0x9000, size =A03,= enabled >> =A0 =A0 =A0 =A0map[1c]: type I/O Port, range 32, base 0x8000, size =A02,= enabled >> =A0 =A0 =A0 =A0map[20]: type I/O Port, range 32, base 0x7000, size =A04,= enabled >> =A0 =A0 =A0 =A0map[24]: type Memory, range 32, base 0xfe7ff800, size 10,= enabled >> pcib0: matched entry for 0.18.INTA >> pcib0: slot 18 INTA hardwired to IRQ 22 >> found-> vendor=3D0x1002, dev=3D0x4387, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D19, func=3D0 >> =A0 =A0 =A0 =A0class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D1 >> =A0 =A0 =A0 =A0cmdreg=3D0x0517, statreg=3D0x02a0, cachelnsz=3D16 (dwords= ) >> =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >> =A0 =A0 =A0 =A0intpin=3Da, irq=3D5 >> =A0 =A0 =A0 =A0map[10]: type Memory, range 32, base 0xfe7fe000, size 12,= enabled >> pcib0: matched entry for 0.19.INTA >> pcib0: slot 19 INTA hardwired to IRQ 16 >> ohci early: SMM active, request owner change >> found-> vendor=3D0x1002, dev=3D0x4388, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D19, func=3D1 >> =A0 =A0 =A0 =A0class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 >> =A0 =A0 =A0 =A0cmdreg=3D0x0117, statreg=3D0x02a0, cachelnsz=3D16 (dwords= ) >> =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >> =A0 =A0 =A0 =A0intpin=3Db, irq=3D3 >> =A0 =A0 =A0 =A0map[10]: type Memory, range 32, base 0xfe7fd000, size 12,= enabled >> pcib0: matched entry for 0.19.INTB >> pcib0: slot 19 INTB hardwired to IRQ 17 >> ohci early: SMM active, request owner change >> found-> vendor=3D0x1002, dev=3D0x4389, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D19, func=3D2 >> =A0 =A0 =A0 =A0class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 >> =A0 =A0 =A0 =A0cmdreg=3D0x0117, statreg=3D0x02a0, cachelnsz=3D16 (dwords= ) >> =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >> =A0 =A0 =A0 =A0intpin=3Dc, irq=3D10 >> =A0 =A0 =A0 =A0map[10]: type Memory, range 32, base 0xfe7fc000, size 12,= enabled >> pcib0: matched entry for 0.19.INTC >> pcib0: slot 19 INTC hardwired to IRQ 18 >> ohci early: SMM active, request owner change >> found-> vendor=3D0x1002, dev=3D0x438a, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D19, func=3D3 >> =A0 =A0 =A0 =A0class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 >> =A0 =A0 =A0 =A0cmdreg=3D0x0117, statreg=3D0x02a0, cachelnsz=3D16 (dwords= ) >> =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >> =A0 =A0 =A0 =A0intpin=3Db, irq=3D3 >> =A0 =A0 =A0 =A0map[10]: type Memory, range 32, base 0xfe7fb000, size 12,= enabled >> pcib0: matched entry for 0.19.INTB >> pcib0: slot 19 INTB hardwired to IRQ 17 >> ohci early: SMM active, request owner change >> found-> vendor=3D0x1002, dev=3D0x438b, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D19, func=3D4 >> =A0 =A0 =A0 =A0class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 >> =A0 =A0 =A0 =A0cmdreg=3D0x0117, statreg=3D0x02a0, cachelnsz=3D16 (dwords= ) >> =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >> =A0 =A0 =A0 =A0intpin=3Dc, irq=3D10 >> =A0 =A0 =A0 =A0map[10]: type Memory, range 32, base 0xfe7fa000, size 12,= enabled >> pcib0: matched entry for 0.19.INTC >> pcib0: slot 19 INTC hardwired to IRQ 18 >> ohci early: SMM active, request owner change >> found-> vendor=3D0x1002, dev=3D0x4386, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D19, func=3D5 >> =A0 =A0 =A0 =A0class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 >> =A0 =A0 =A0 =A0cmdreg=3D0x0117, statreg=3D0x02b0, cachelnsz=3D16 (dwords= ) >> =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >> =A0 =A0 =A0 =A0intpin=3Dd, irq=3D10 >> =A0 =A0 =A0 =A0powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >> =A0 =A0 =A0 =A0map[10]: type Memory, range 32, base 0xfe7ff000, size =A0= 8, enabled >> pcib0: matched entry for 0.19.INTD >> pcib0: slot 19 INTD hardwired to IRQ 19 >> found-> vendor=3D0x1002, dev=3D0x4385, revid=3D0x13 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D20, func=3D0 >> =A0 =A0 =A0 =A0class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D1 >> =A0 =A0 =A0 =A0cmdreg=3D0x0403, statreg=3D0x0230, cachelnsz=3D0 (dwords) >> =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x= 00 (0 ns) >> =A0 =A0 =A0 =A0map[10]: type I/O Port, range 32, base 0xb00, size =A04, = enabled >> =A0 =A0 =A0 =A0map[14]: type Memory, range 32, base 0xfed00000, size 10,= enabled >> found-> vendor=3D0x1002, dev=3D0x438c, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D20, func=3D1 >> =A0 =A0 =A0 =A0class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 >> =A0 =A0 =A0 =A0cmdreg=3D0x0005, statreg=3D0x0230, cachelnsz=3D0 (dwords) >> =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x= 00 (0 ns) >> =A0 =A0 =A0 =A0intpin=3Da, irq=3D255 >> =A0 =A0 =A0 =A0MSI supports 1 message >> =A0 =A0 =A0 =A0map[20]: type I/O Port, range 32, base 0xff00, size =A04,= enabled >> found-> vendor=3D0x1002, dev=3D0x4383, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D20, func=3D2 >> =A0 =A0 =A0 =A0class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0 >> =A0 =A0 =A0 =A0cmdreg=3D0x0006, statreg=3D0x0410, cachelnsz=3D16 (dwords= ) >> =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >> =A0 =A0 =A0 =A0intpin=3Da, irq=3D5 >> =A0 =A0 =A0 =A0powerspec 2 =A0supports D0 D3 =A0current D0 >> =A0 =A0 =A0 =A0MSI supports 1 message, 64 bit >> =A0 =A0 =A0 =A0map[10]: type Memory, range 64, base 0xfe7f4000, size 14,= enabled >> pcib0: matched entry for 0.20.INTA >> pcib0: slot 20 INTA hardwired to IRQ 16 >> found-> vendor=3D0x1002, dev=3D0x438d, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D20, func=3D3 >> =A0 =A0 =A0 =A0class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 >> =A0 =A0 =A0 =A0cmdreg=3D0x000f, statreg=3D0x0220, cachelnsz=3D0 (dwords) >> =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x= 00 (0 ns) >> found-> vendor=3D0x1002, dev=3D0x4384, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D20, func=3D4 >> =A0 =A0 =A0 =A0class=3D06-04-01, hdrtype=3D0x01, mfdev=3D1 >> =A0 =A0 =A0 =A0cmdreg=3D0x0107, statreg=3D0x02a0, cachelnsz=3D0 (dwords) >> =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x03 (750 ns), maxlat= =3D0x00 (0 ns) >> found-> vendor=3D0x1022, dev=3D0x1100, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D24, func=3D0 >> =A0 =A0 =A0 =A0class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 >> =A0 =A0 =A0 =A0cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) >> =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x= 00 (0 ns) >> found-> vendor=3D0x1022, dev=3D0x1101, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D24, func=3D1 >> =A0 =A0 =A0 =A0class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 >> =A0 =A0 =A0 =A0cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) >> =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x= 00 (0 ns) >> found-> vendor=3D0x1022, dev=3D0x1102, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D24, func=3D2 >> =A0 =A0 =A0 =A0class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 >> =A0 =A0 =A0 =A0cmdreg=3D0x0000, statreg=3D0x0000, cachelnsz=3D0 (dwords) >> =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x= 00 (0 ns) >> found-> vendor=3D0x1022, dev=3D0x1103, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D0, slot=3D24, func=3D3 >> =A0 =A0 =A0 =A0class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 >> =A0 =A0 =A0 =A0cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D0 (dwords) >> =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x= 00 (0 ns) >> pcib1: at device 1.0 on pci0 >> pcib1: =A0 domain =A0 =A0 =A0 =A0 =A0 =A00 >> pcib1: =A0 secondary bus =A0 =A0 1 >> pcib1: =A0 subordinate bus =A0 1 >> pcib1: =A0 I/O decode =A0 =A0 =A0 =A00xc000-0xcfff >> pcib1: =A0 memory decode =A0 =A0 0xfe800000-0xfe9fffff >> pcib1: =A0 prefetched decode 0xf0000000-0xf7ffffff >> pci1: on pcib1 >> pci1: domain=3D0, physical bus=3D1 >> found-> vendor=3D0x1002, dev=3D0x791e, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D1, slot=3D5, func=3D0 >> =A0 =A0 =A0 =A0class=3D03-00-00, hdrtype=3D0x00, mfdev=3D1 >> =A0 =A0 =A0 =A0cmdreg=3D0x0107, statreg=3D0x0010, cachelnsz=3D16 (dwords= ) >> =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >> =A0 =A0 =A0 =A0intpin=3Da, irq=3D10 >> =A0 =A0 =A0 =A0powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >> =A0 =A0 =A0 =A0MSI supports 1 message, 64 bit >> =A0 =A0 =A0 =A0map[10]: type Prefetchable Memory, range 64, base 0xf0000= 000, size 27, e >> nabled >> pcib1: requested memory range 0xf0000000-0xf7ffffff: good >> =A0 =A0 =A0 =A0map[18]: type Memory, range 64, base 0xfe9f0000, size 16,= enabled >> pcib1: requested memory range 0xfe9f0000-0xfe9fffff: good >> =A0 =A0 =A0 =A0map[20]: type I/O Port, range 32, base 0xc000, size =A08,= enabled >> pcib1: requested I/O range 0xc000-0xc0ff: in range >> =A0 =A0 =A0 =A0map[24]: type Memory, range 32, base 0xfe800000, size 20,= enabled >> pcib1: requested memory range 0xfe800000-0xfe8fffff: good >> pcib1: matched entry for 1.5.INTA >> pcib1: slot 5 INTA hardwired to IRQ 18 >> found-> vendor=3D0x1002, dev=3D0x7919, revid=3D0x00 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D1, slot=3D5, func=3D2 >> =A0 =A0 =A0 =A0class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0 >> =A0 =A0 =A0 =A0cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords= ) >> =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >> =A0 =A0 =A0 =A0intpin=3Db, irq=3D10 >> =A0 =A0 =A0 =A0powerspec 2 =A0supports D0 D3 =A0current D0 >> =A0 =A0 =A0 =A0MSI supports 1 message, 64 bit >> =A0 =A0 =A0 =A0map[10]: type Memory, range 64, base 0xfe9e8000, size 14,= enabled >> pcib1: requested memory range 0xfe9e8000-0xfe9ebfff: good >> pcib1: matched entry for 1.5.INTB >> pcib1: slot 5 INTB hardwired to IRQ 19 >> vgapci0: port 0xc000-0xc0ff mem 0xf0000000-0xf7= ffffff,0 >> xfe9f0000-0xfe9fffff,0xfe800000-0xfe8fffff irq 18 at device 5.0 on pci1 >> pci1: at device 5.2 (no driver attached) >> pcib2: at device 7.0 on pci0 >> pcib2: =A0 domain =A0 =A0 =A0 =A0 =A0 =A00 >> pcib2: =A0 secondary bus =A0 =A0 2 >> pcib2: =A0 subordinate bus =A0 2 >> pcib2: =A0 I/O decode =A0 =A0 =A0 =A00xd000-0xdfff >> pcib2: =A0 memory decode =A0 =A0 0xfea00000-0xfeafffff >> pcib2: =A0 no prefetched decode >> pci2: on pcib2 >> pci2: domain=3D0, physical bus=3D2 >> found-> vendor=3D0x10ec, dev=3D0x8168, revid=3D0x01 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D2, slot=3D0, func=3D0 >> =A0 =A0 =A0 =A0class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 >> =A0 =A0 =A0 =A0cmdreg=3D0x0107, statreg=3D0x4010, cachelnsz=3D16 (dwords= ) >> =A0 =A0 =A0 =A0lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x= 00 (0 ns) >> =A0 =A0 =A0 =A0intpin=3Da, irq=3D10 >> =A0 =A0 =A0 =A0powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >> =A0 =A0 =A0 =A0MSI supports 2 messages, 64 bit >> =A0 =A0 =A0 =A0map[10]: type I/O Port, range 32, base 0xd800, size =A08,= enabled >> pcib2: requested I/O range 0xd800-0xd8ff: in range >> =A0 =A0 =A0 =A0map[18]: type Memory, range 64, base 0xfeaff000, size 12,= enabled >> pcib2: requested memory range 0xfeaff000-0xfeafffff: good >> pcib2: matched entry for 2.0.INTA >> pcib2: slot 0 INTA hardwired to IRQ 19 >> re0: port 0xd8= 00-0xd8f >> f mem 0xfeaff000-0xfeafffff irq 19 at device 0.0 on pci2 >> re0: MSI count : 2 >> re0: MSI-X count : 0 >> re0: attempting to allocate 1 MSI vectors (2 supported) >> msi: routing MSI IRQ 256 to local APIC 0 vector 49 >> re0: using IRQ 256 for MSI >> re0: Using 1 MSI message >> re0: Chip rev. 0x38000000 >> re0: MAC rev. 0x00000000 >> miibus0: on re0 >> rgephy0: PHY 1 on miibu= s0 >> rgephy0: OUI 0x00e04c, model 0x0011, rev. 2 >> rgephy0: =A0none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100= baseTX-FDX >> , 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000ba= seT-FDX- >> master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow >> re0: bpf attached >> re0: Ethernet address: 00:19:db:63:76:3e >> ahci0: port 0xb000-0xb007,0xa000-0xa00= 3,0x9000 >> -0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe7ff800-0xfe7ffbff irq 22 at = device 1 >> 8.0 on pci0 >> ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 50 >> ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier supported >> ahci0: Caps: 64bit NCQ SNTF MPS AL CLO 3Gbps PM PMD 32cmd CCC 4ports >> ahci0: Caps2: >> ahcich0: at channel 0 on ahci0 >> ahcich0: Caps: HPCP >> ahcich1: at channel 1 on ahci0 >> ahcich1: Caps: HPCP >> ahcich2: at channel 2 on ahci0 >> ahcich2: Caps: HPCP >> ahcich3: at channel 3 on ahci0 >> ahcich3: Caps: HPCP >> ohci0: mem 0xfe7fe000-0xfe7fefff irq 16 = at devic >> e 19.0 on pci0 >> ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 51 >> usbus0: on ohci0 >> usbus0: bpf attached >> ohci0: usbpf: Attached >> ohci1: mem 0xfe7fd000-0xfe7fdfff irq 17 = at devic >> e 19.1 on pci0 >> ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 52 >> usbus1: on ohci1 >> usbus1: bpf attached >> ohci1: usbpf: Attached >> ohci2: mem 0xfe7fc000-0xfe7fcfff irq 18 = at devic >> e 19.2 on pci0 >> ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 53 >> usbus2: on ohci2 >> usbus2: bpf attached >> ohci2: usbpf: Attached >> ohci3: mem 0xfe7fb000-0xfe7fbfff irq 17 = at devic >> e 19.3 on pci0 >> usbus3: on ohci3 >> usbus3: bpf attached >> ohci3: usbpf: Attached >> ohci4: mem 0xfe7fa000-0xfe7fafff irq 18 = at devic >> e 19.4 on pci0 >> usbus4: on ohci4 >> usbus4: bpf attached >> ohci4: usbpf: Attached >> ehci0: mem 0xfe7ff000-0xfe7ff0ff irq= 19 at d >> evice 19.5 on pci0 >> ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 54 >> ehci0: AMD SB600/700 quirk applied >> ehci0: Dropped interrupts workaround enabled >> usbus5: EHCI version 1.0 >> usbus5: on ehci0 >> usbus5: bpf attached >> ehci0: usbpf: Attached >> pci0: at device 20.0 (no driver attached) >> atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x= 177,0x37 >> 6,0xff00-0xff0f at device 20.1 on pci0 >> ata0: at channel 0 on atapci0 >> ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 55 >> pci0: at device 20.2 (no driver attached) >> isab0: at device 20.3 on pci0 >> isa0: on isab0 >> pcib3: at device 20.4 on pci0 >> pcib3: =A0 domain =A0 =A0 =A0 =A0 =A0 =A00 >> pcib3: =A0 secondary bus =A0 =A0 3 >> pcib3: =A0 subordinate bus =A0 3 >> pcib3: =A0 I/O decode =A0 =A0 =A0 =A00xe000-0xefff >> pcib3: =A0 memory decode =A0 =A0 0xfeb00000-0xfebfffff >> pcib3: =A0 no prefetched decode >> pcib3: =A0 Subtractively decoded bridge. >> pci3: on pcib3 >> pci3: domain=3D0, physical bus=3D3 >> found-> vendor=3D0x1106, dev=3D0x3044, revid=3D0xc0 >> =A0 =A0 =A0 =A0domain=3D0, bus=3D3, slot=3D0, func=3D0 >> =A0 =A0 =A0 =A0class=3D0c-00-10, hdrtype=3D0x00, mfdev=3D0 >> =A0 =A0 =A0 =A0cmdreg=3D0x0117, statreg=3D0x0210, cachelnsz=3D16 (dwords= ) >> =A0 =A0 =A0 =A0lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x20 (8000 ns) >> =A0 =A0 =A0 =A0intpin=3Da, irq=3D4 >> =A0 =A0 =A0 =A0powerspec 2 =A0supports D0 D2 D3 =A0current D0 >> =A0 =A0 =A0 =A0map[10]: type Memory, range 32, base 0xfebff800, size 11,= enabled >> pcib3: requested memory range 0xfebff800-0xfebfffff: good >> =A0 =A0 =A0 =A0map[14]: type I/O Port, range 32, base 0xe800, size =A07,= enabled >> pcib3: requested I/O range 0xe800-0xe87f: in range >> pcib3: matched entry for 3.0.INTA >> pcib3: slot 0 INTA hardwired to IRQ 20 >> pci3: at device 0.0 (no driver attached) >> acpi_button0: on acpi0 >> attimer0: port 0x40-0x43 irq 0 on acpi0 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 56 >> Event timer "i8254" frequency 1193182 Hz quality 100 >> atrtc0: port 0x70-0x71 irq 8 on acpi0 >> atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustm= ent 0.50 >> 0000000s) >> ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 57 >> Event timer "RTC" frequency 32768 Hz quality 0 >> hpet0: iomem 0xfed00000-0xfed003ff on acpi0 >> device_attach: hpet0 attach returned 12 >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> atkbd: the current kbd controller command byte 0065 >> atkbd: keyboard ID 0x41ab (2) >> kbd0 at atkbd0 >> kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 >> ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 58 >> atkbd0: [GIANT-LOCKED] >> psm0: unable to allocate IRQ >> acpi0: wakeup code va 0xffffff8087fae000 pa 0x4000 >> isa_probe_children: disabling PnP devices >> atkbdc: atkbdc0 already exists; skipping it >> atrtc: atrtc0 already exists; skipping it >> attimer: attimer0 already exists; skipping it >> sc: sc0 already exists; skipping it >> isa_probe_children: probing non-PnP devices >> orm0: at iomem 0xcd800-0xce7ff 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 isa= 0 >> fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 >> ppc0 failed to probe at irq 7 on isa0 >> uart0 failed to probe at port 0x3f8 irq 4 on isa0 >> uart1 failed to probe at port 0x2f8 irq 3 on isa0 >> isa_probe_children: probing PnP devices >> acpi_throttle0: on cpu0 >> acpi_throttle0: CLK_VAL field overlaps THT_EN bit >> device_attach: acpi_throttle0 attach returned 6 >> powernow0: on cpu0 >> powernow0: STATUS: 0x310a120c0a0e020e >> powernow0: STATUS: maxfid: 0x0e >> powernow0: STATUS: maxvid: 0x0a >> device_attach: powernow0 attach returned 6 >> powernow1: on cpu1 >> powernow1: STATUS: 0x310a120c0a0e020e >> powernow1: STATUS: maxfid: 0x0e >> powernow1: STATUS: maxvid: 0x0a >> device_attach: powernow1 attach returned 6 >> Device configuration finished. >> procfs registered >> lapic: Divisor 2, Frequency 99761963 Hz >> Timecounters tick every 1.000 msec >> vlan: initialized, using hash tables with chaining >> lo0: bpf attached >> usbus0: 12Mbps Full Speed USB v1.0 >> usbus1: 12Mbps Full Speed USB v1.0 >> usbus2: 12Mbps Full Speed USB v1.0 >> usbus3: 12Mbps Full Speed USB v1.0 >> usbus4: 12Mbps Full Speed USB v1.0 >> usbus5: 480Mbps High Speed USB v2.0 >> ahcich0: AHCI reset... >> ahcich0: SATA connect time=3D100us status=3D00000123 >> ahcich0: AHCI reset: device found >> ahcich1: AHCI reset... >> ahcich1: SATA connect time=3D100us status=3D00000123 >> ahcich1: AHCI reset: device found >> ahcich2: AHCI reset... >> ahcich2: SATA connect time=3D100us status=3D00000123 >> ahcich2: AHCI reset: device found >> ahcich3: AHCI reset... >> ahcich3: SATA connect time=3D100us status=3D00000123 >> ahcich3: AHCI reset: device found >> ugen0.1: at usbus0 >> uhub0: on usbus0 >> ugen1.1: at usbus1 >> uhub1: on usbus1 >> ugen2.1: at usbus2 >> uhub2: on usbus2 >> ugen3.1: at usbus3 >> uhub3: on usbus3 >> ugen4.1: at usbus4 >> uhub4: on usbus4 >> ugen5.1: at usbus5 >> uhub5: on usbus5 >> ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D50 >> ahcich0: AHCI reset: device ready after 100ms >> Expensive timeout(9) function: 0xffffffff802db3d0(0xfffffe00015abb00) 0.= 05421135 >> 9 s >> (aprobe0:ahcich0:0:15:0): Command timed out >> (aprobe0:ahcich0:0:15:0): Error 5, Retries exhausted >> (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 >> ahcich1: AHCI reset: device ready after 100ms >> (aprobe1:ahcich1:0:15:0): Command timed out >> (aprobe1:ahcich1:0:15:0): Error 5, Retries exhausted >> (aprobe0:ahcich1:0:0:0): SIGNATURE: 0000 >> ahcich2: AHCI reset: device ready after 100ms >> (aprobe2:ahcich2:0:15:0): Command timed out >> (aprobe2:ahcich2:0:15:0): Error 5, Retries exhausted >> (aprobe0:ahcich2:0:0:0): SIGNATURE: 0000 >> ahcich3: AHCI reset: device ready after 100ms >> (aprobe3:ahcich3:0:15:0): Command timed out >> (aprobe3:ahcich3:0:15:0): Error 5, Retries exhausted >> (aprobe0:ahcich3:0:0:0): SIGNATURE: 0000 >> ata0: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb >> ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb >> ata0: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x30000 >> (aprobe1:ata0:0:0:0): SIGNATURE: eb14 >> (aprobe0:ata0:0:1:0): SIGNATURE: eb14 >> pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> pass0: ATA-7 SATA 2.x device >> pass0: Serial Number 6QF0W6RN >> GEOM: new disk cd0 >> GEOM: new disk cd1 >> pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> pass0: Command Queueing enabled >> (cd0:ata0:0:0:0): SCSI status error >> (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 >> (cd0:ata0:0:0:0): CAM status: SCSI Status Error >> (cd0:ata0:0:0:0): SCSI status: Check Condition >> (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) >> (cd0:ata0:0:0:0): Error 6, Unretryable error >> cd0 at ata0 bus 0 scbus4 target 0 lun 0 >> cd0: Removable CD-ROM SCSI-0 device >> cd0: Serial Number 2005082900 >> cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >> cd0: Attempt to query device size failed: NOT READY, Medium not present >> pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 >> pass1: ATA-8 SATA 3.x device >> pass1: Serial Number W24044SM >> pass1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> pass1: Command Queueing enabled >> pass2 at ahcich2 bus 0 scbus2 target 0 lun 0 >> (cd1:ata0:0:1:0): SCSI status error >> (cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 >> (cd1:ata0:0:1:0): CAM status: SCSI Status Error >> (cd1:ata0:0:1:0): SCSI status: Check Condition >> (cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - t= ray clos >> ed) >> (cd1:ata0:0:1:0): Error 6, Unretryable error >> cd1 at ata0 bus 0 scbus4 target 1 lun 0 >> cd1: Removable CD-ROM SCSI-0 device >> cd1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >> cd1: Attempt to query device size failed: NOT READY, Medium not present = - tray c >> losed >> pass2: ATA-7 SATA 2.x device >> pass2: Serial Number 6QF0ZTQM >> pass2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> pass2: Command Queueing enabled >> pass3 at ahcich3 bus 0 scbus3 target 0 lun 0 >> pass3: ATA-8 SATA 3.x device >> pass3: Serial Number W240643V >> pass3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> pass3: Command Queueing enabled >> pass4 at ata0 bus 0 scbus4 target 0 lun 0 >> pass4: Removable CD-ROM SCSI-0 device >> pass4: Serial Number 2005082900 >> pass4: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >> (cd0:ata0:0:0:0): SCSI status error >> (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 >> (cd0:ata0:0:0:0): CAM status: SCSI Status Error >> (cd0:ata0:0:0:0): SCSI status: Check Condition >> (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) >> (cd0:ata0:0:0:0): Error 6, Unretryable error >> pass5 at ata0 bus 0 scbus4 target 1 lun 0 >> pass5: Removable CD-ROM SCSI-0 device >> pass5: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) >> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> ada0: ATA-7 SATA 2.x device >> ada0: Serial Number 6QF0W6RN >> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada0: Command Queueing enabled >> ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) >> ada0: Previously was known as ad4 >> ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 >> ada1: ATA-8 SATA 3.x device >> ada1: Serial Number W24044SM >> (cd0:ata0:0:0:0): SCSI status error >> (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 >> (cd0:ata0:0:0:0): CAM status: SCSI Status Error >> uhub0: 2 ports with 2 removable, self powered >> uhub1: 2 ports with 2 removable, self powered >> uhub2: 2 ports with 2 removable, self powered >> uhub3: 2 ports with 2 removable, self powered >> uhub4: 2 ports with 2 removable, self powered >> (cd0:ata0:0:0:0): SCSI status: Check Condition >> (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) >> (cd0:ata0:0:0:0): Error 6, Unretryable error >> ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada1: Command Queueing enabled >> ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) >> ada1: Previously was known as ad6 >> ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 >> ada2: ATA-7 SATA 2.x device >> ada2: Serial Number 6QF0ZTQM >> ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada2: Command Queueing enabled >> ada2: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) >> ada2: Previously was known as ad8 >> ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 >> ada3: ATA-8 SATA 3.x device >> (cd0:ata0:0:0:0): SCSI status error >> (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 >> (cd0:ata0:0:0:0): CAM status: SCSI Status Error >> (cd0:ata0:0:0:0): SCSI status: Check Condition >> (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) >> (cd0:ata0:0:0:0): Error 6, Unretryable error >> ada3: Serial Number W240643V >> ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada3: Command Queueing enabled >> ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) >> ada3: Previously was known as ad10 >> SMP: AP CPU #1 Launched! >> cpu1 AP: >> =A0 =A0 ID: 0x01000000 =A0 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffff= ff >> =A0lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff >> =A0timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 >> TSC timecounter discards lower 8 bit(s) >> Timecounter "TSC-low" frequency 8573416 Hz quality -100 >> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >> (cd1:ata0:0:1:0): SCSI status error >> (cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 >> (cd1:ata0:0:1:0): CAM status: SCSI Status Error >> (cd1:ata0:0:1:0): SCSI status: Check Condition >> (cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - t= ray clos >> ed) >> (cd1:ata0:0:1:0): Error 6, Unretryable error >> (cd1:ata0:0:1:0): SCSI status error >> (cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 >> (cd1:ata0:0:1:0): CAM status: SCSI Status Error >> (cd1:ata0:0:1:0): SCSI status: Check Condition >> (cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - t= ray clos >> ed) >> (cd1:ata0:0:1:0): Error 6, Unretryable error >> (cd1:ata0:0:1:0): SCSI status error >> (cd1:ata0:0:1:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 >> (cd1:ata0:0:1:0): CAM status: SCSI Status Error >> (cd1:ata0:0:1:0): SCSI status: Check Condition >> (cd1:ata0:0:1:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - t= ray clos >> ed) >> (cd1:ata0:0:1:0): Error 6, Unretryable error >> GEOM: new disk ada0 >> GEOM: new disk ada1 >> GEOM: new disk ada2 >> GEOM: new disk ada3 >> GEOM: ada2s1: geometry does not match label (255h,63s !=3D 16h,63s). >> GEOM: ada2s1: media size does not match label. >> Root mount waiting for: usbus5 >> Root mount waiting for: usbus5 >> Root mount waiting for: usbus5 >> uhub5: 10 ports with 10 removable, self powered >> Root mount waiting for: usbus5 >> Trying to mount root from ufs:/dev/ada0p2 [rw]... >> start_init: trying /sbin/init >> ugen1.2: at usbus1 >> ums0: > 2> on usbus1 >> ums0: 5 buttons and [XYZ] coordinates ID=3D0 >> ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is p= resent; >> =A0 =A0 =A0 =A0 =A0 =A0to enable, add "vfs.zfs.prefetch_disable=3D0" to = /boot/loader.conf. >> ZFS filesystem version 5 >> ZFS storage pool version 28 >> * csup >> -------------------------------------------------------------- >>>>> Running /usr/bin/csup >> -------------------------------------------------------------- >> Parsing supfile "/root/csup/date-supfile" >> Connecting to cvsup.uk.freebsd.org >> Cannot connect to 2001:630:212:8:20e:cff:fe09:a69c: Protocol not support= ed >> Connected to 131.111.8.41 >> Server software version: SNAP_16_1h >> MD5 authentication started >> MD5 authentication successful >> Negotiating file attribute support >> Exchanging collection information >> Establishing multiplexed-mode data connection >> Running >> Updating collection src-all/cvs >> =A0Edit src/sys/dev/acpica/acpi.c >> =A0Add delta 1.305.2.4 2012.02.23.22.26.14 jkim >> =A0Edit src/sys/dev/acpica/acpi_ec.c >> =A0Add delta 1.95.2.2 2012.02.23.22.26.14 jkim >> =A0Edit src/sys/dev/acpica/acpi_hpet.c >> =A0Add delta 1.38.2.2 2012.02.23.22.26.14 jkim >> =A0Edit src/sys/dev/acpica/acpi_timer.c >> =A0Add delta 1.50.2.3 2012.02.23.22.26.14 jkim >> =A0Edit src/sys/dev/acpica/acpivar.h >> =A0Add delta 1.125.2.4 2012.02.23.22.26.14 jkim >> Shutting down connection to server >> Finished successfully >> * supfil >> *default host=3Dcvsup.uk.freebsd.org >> *default base=3D/var/db >> *default prefix=3D/usr >> *default release=3Dcvs tag=3DRELENG_9 >> >> # ok: >> # *default date=3D2012.02.23.22.26.00 >> # fail: >> *default date=3D2012.02.23.22.26.30 >> >> *default delete use-rel-suffix >> *default compress >> src-all >> * pciconf -lvb >> hostb0@pci0:0:0:0: =A0 =A0 =A0class=3D0x060000 card=3D0x79101002 chip=3D= 0x79101002 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'RS690 Host Bridge' >> =A0 =A0class =A0 =A0 =A0=3D bridge >> =A0 =A0subclass =A0 =3D HOST-PCI >> pcib1@pci0:0:1:0: =A0 =A0 =A0 class=3D0x060400 card=3D0x79121002 chip=3D= 0x79121002 rev=3D0x00 >> hdr=3D0x01 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'RS690 PCI to PCI Bridge (Internal gfx)' >> =A0 =A0class =A0 =A0 =A0=3D bridge >> =A0 =A0subclass =A0 =3D PCI-PCI >> pcib2@pci0:0:7:0: =A0 =A0 =A0 class=3D0x060400 card=3D0x79101002 chip=3D= 0x79171002 rev=3D0x00 >> hdr=3D0x01 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'RS690 PCI to PCI Bridge (PCI Express Port 3)' >> =A0 =A0class =A0 =A0 =A0=3D bridge >> =A0 =A0subclass =A0 =3D PCI-PCI >> ahci0@pci0:0:18:0: =A0 =A0 =A0class=3D0x010601 card=3D0x73291462 chip=3D= 0x43801002 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'SB600 Non-Raid-5 SATA' >> =A0 =A0class =A0 =A0 =A0=3D mass storage >> =A0 =A0subclass =A0 =3D SATA >> =A0 =A0bar =A0 [10] =3D type I/O Port, range 32, base 0xb000, size =A08,= enabled >> =A0 =A0bar =A0 [14] =3D type I/O Port, range 32, base 0xa000, size =A04,= enabled >> =A0 =A0bar =A0 [18] =3D type I/O Port, range 32, base 0x9000, size =A08,= enabled >> =A0 =A0bar =A0 [1c] =3D type I/O Port, range 32, base 0x8000, size =A04,= enabled >> =A0 =A0bar =A0 [20] =3D type I/O Port, range 32, base 0x7000, size 16, e= nabled >> =A0 =A0bar =A0 [24] =3D type Memory, range 32, base 0xfe7ff800, size 102= 4, enabled >> ohci0@pci0:0:19:0: =A0 =A0 =A0class=3D0x0c0310 card=3D0x73271462 chip=3D= 0x43871002 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'SB600 USB (OHCI0)' >> =A0 =A0class =A0 =A0 =A0=3D serial bus >> =A0 =A0subclass =A0 =3D USB >> =A0 =A0bar =A0 [10] =3D type Memory, range 32, base 0xfe7fe000, size 409= 6, enabled >> ohci1@pci0:0:19:1: =A0 =A0 =A0class=3D0x0c0310 card=3D0x73271462 chip=3D= 0x43881002 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'SB600 USB (OHCI1)' >> =A0 =A0class =A0 =A0 =A0=3D serial bus >> =A0 =A0subclass =A0 =3D USB >> =A0 =A0bar =A0 [10] =3D type Memory, range 32, base 0xfe7fd000, size 409= 6, enabled >> ohci2@pci0:0:19:2: =A0 =A0 =A0class=3D0x0c0310 card=3D0x73271462 chip=3D= 0x43891002 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'SB600 USB (OHCI2)' >> =A0 =A0class =A0 =A0 =A0=3D serial bus >> =A0 =A0subclass =A0 =3D USB >> =A0 =A0bar =A0 [10] =3D type Memory, range 32, base 0xfe7fc000, size 409= 6, enabled >> ohci3@pci0:0:19:3: =A0 =A0 =A0class=3D0x0c0310 card=3D0x73271462 chip=3D= 0x438a1002 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'SB600 USB (OHCI3)' >> =A0 =A0class =A0 =A0 =A0=3D serial bus >> =A0 =A0subclass =A0 =3D USB >> =A0 =A0bar =A0 [10] =3D type Memory, range 32, base 0xfe7fb000, size 409= 6, enabled >> ohci4@pci0:0:19:4: =A0 =A0 =A0class=3D0x0c0310 card=3D0x73271462 chip=3D= 0x438b1002 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'SB600 USB (OHCI4)' >> =A0 =A0class =A0 =A0 =A0=3D serial bus >> =A0 =A0subclass =A0 =3D USB >> =A0 =A0bar =A0 [10] =3D type Memory, range 32, base 0xfe7fa000, size 409= 6, enabled >> ehci0@pci0:0:19:5: =A0 =A0 =A0class=3D0x0c0320 card=3D0x73271462 chip=3D= 0x43861002 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'SB600 USB Controller (EHCI)' >> =A0 =A0class =A0 =A0 =A0=3D serial bus >> =A0 =A0subclass =A0 =3D USB >> =A0 =A0bar =A0 [10] =3D type Memory, range 32, base 0xfe7ff000, size 256= , enabled >> none0@pci0:0:20:0: =A0 =A0 =A0class=3D0x0c0500 card=3D0x73271462 chip=3D= 0x43851002 rev=3D0x13 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'SBx00 SMBus Controller' >> =A0 =A0class =A0 =A0 =A0=3D serial bus >> =A0 =A0subclass =A0 =3D SMBus >> =A0 =A0bar =A0 [10] =3D type I/O Port, range 32, base 0xb00, size 16, en= abled >> =A0 =A0bar =A0 [14] =3D type Memory, range 32, base 0xfed00000, size 102= 4, enabled >> atapci0@pci0:0:20:1: =A0 =A0class=3D0x01018a card=3D0x73271462 chip=3D0x= 438c1002 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'SB600 IDE' >> =A0 =A0class =A0 =A0 =A0=3D mass storage >> =A0 =A0subclass =A0 =3D ATA >> =A0 =A0bar =A0 [20] =3D type I/O Port, range 32, base 0xff00, size 16, e= nabled >> none1@pci0:0:20:2: =A0 =A0 =A0class=3D0x040300 card=3D0x73271462 chip=3D= 0x43831002 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'SBx00 Azalia (Intel HDA)' >> =A0 =A0class =A0 =A0 =A0=3D multimedia >> =A0 =A0subclass =A0 =3D HDA >> =A0 =A0bar =A0 [10] =3D type Memory, range 64, base 0xfe7f4000, size 163= 84, enabled >> isab0@pci0:0:20:3: =A0 =A0 =A0class=3D0x060100 card=3D0x73271462 chip=3D= 0x438d1002 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'SB600 PCI to LPC Bridge' >> =A0 =A0class =A0 =A0 =A0=3D bridge >> =A0 =A0subclass =A0 =3D PCI-ISA >> pcib3@pci0:0:20:4: =A0 =A0 =A0class=3D0x060401 card=3D0x00000000 chip=3D= 0x43841002 rev=3D0x00 >> hdr=3D0x01 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'SBx00 PCI to PCI Bridge' >> =A0 =A0class =A0 =A0 =A0=3D bridge >> =A0 =A0subclass =A0 =3D PCI-PCI >> hostb1@pci0:0:24:0: =A0 =A0 class=3D0x060000 card=3D0x00000000 chip=3D0x= 11001022 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'Advanced Micro Devices [AMD]' >> =A0 =A0device =A0 =A0 =3D 'K8 [Athlon64/Opteron] HyperTransport Technolo= gy Configuration' >> >> =A0 =A0class =A0 =A0 =A0=3D bridge >> =A0 =A0subclass =A0 =3D HOST-PCI >> hostb2@pci0:0:24:1: =A0 =A0 class=3D0x060000 card=3D0x00000000 chip=3D0x= 11011022 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'Advanced Micro Devices [AMD]' >> =A0 =A0device =A0 =A0 =3D 'K8 [Athlon64/Opteron] Address Map' >> =A0 =A0class =A0 =A0 =A0=3D bridge >> =A0 =A0subclass =A0 =3D HOST-PCI >> hostb3@pci0:0:24:2: =A0 =A0 class=3D0x060000 card=3D0x00000000 chip=3D0x= 11021022 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'Advanced Micro Devices [AMD]' >> =A0 =A0device =A0 =A0 =3D 'K8 [Athlon64/Opteron] DRAM Controller' >> =A0 =A0class =A0 =A0 =A0=3D bridge >> =A0 =A0subclass =A0 =3D HOST-PCI >> hostb4@pci0:0:24:3: =A0 =A0 class=3D0x060000 card=3D0x00000000 chip=3D0x= 11031022 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'Advanced Micro Devices [AMD]' >> =A0 =A0device =A0 =A0 =3D 'K8 [Athlon64/Opteron] Miscellaneous Control' >> =A0 =A0class =A0 =A0 =A0=3D bridge >> =A0 =A0subclass =A0 =3D HOST-PCI >> vgapci0@pci0:1:5:0: =A0 =A0 class=3D0x030000 card=3D0x73271462 chip=3D0x= 791e1002 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'RS690 [Radeon X1200 Series]' >> =A0 =A0class =A0 =A0 =A0=3D display >> =A0 =A0subclass =A0 =3D VGA >> =A0 =A0bar =A0 [10] =3D type Prefetchable Memory, range 64, base 0xf0000= 000, size 13421 >> 7728, enabled >> =A0 =A0bar =A0 [18] =3D type Memory, range 64, base 0xfe9f0000, size 655= 36, enabled >> =A0 =A0bar =A0 [20] =3D type I/O Port, range 32, base 0xc000, size 256, = enabled >> =A0 =A0bar =A0 [24] =3D type Memory, range 32, base 0xfe800000, size 104= 8576, enabled >> none2@pci0:1:5:2: =A0 =A0 =A0 class=3D0x040300 card=3D0x79191002 chip=3D= 0x79191002 rev=3D0x00 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'ATI Technologies Inc' >> =A0 =A0device =A0 =A0 =3D 'Radeon X1200 Series Audio Controller' >> =A0 =A0class =A0 =A0 =A0=3D multimedia >> =A0 =A0subclass =A0 =3D HDA >> =A0 =A0bar =A0 [10] =3D type Memory, range 64, base 0xfe9e8000, size 163= 84, enabled >> re0@pci0:2:0:0: class=3D0x020000 card=3D0x327c1462 chip=3D0x816810ec rev= =3D0x01 hdr=3D0x00 >> >> =A0 =A0vendor =A0 =A0 =3D 'Realtek Semiconductor Co., Ltd.' >> =A0 =A0device =A0 =A0 =3D 'RTL8111/8168B PCI Express Gigabit Ethernet co= ntroller' >> =A0 =A0class =A0 =A0 =A0=3D network >> =A0 =A0subclass =A0 =3D ethernet >> =A0 =A0bar =A0 [10] =3D type I/O Port, range 32, base 0xd800, size 256, = enabled >> =A0 =A0bar =A0 [18] =3D type Memory, range 64, base 0xfeaff000, size 409= 6, enabled >> none3@pci0:3:0:0: =A0 =A0 =A0 class=3D0x0c0010 card=3D0x086c0574 chip=3D= 0x30441106 rev=3D0xc0 >> hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'VIA Technologies, Inc.' >> =A0 =A0device =A0 =A0 =3D 'VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Contro= ller' >> =A0 =A0class =A0 =A0 =A0=3D serial bus >> =A0 =A0subclass =A0 =3D FireWire >> =A0 =A0bar =A0 [10] =3D type Memory, range 32, base 0xfebff800, size 204= 8, enabled >> =A0 =A0bar =A0 [14] =3D type I/O Port, range 32, base 0xe800, size 128, = enabled >> >> >> >> On 29 February 2012 14:12, John Baldwin wrote: >>> On Tuesday, February 28, 2012 6:10:51 pm Harry Newton wrote: >>>> Adrian - thanks ! >>>> >>>> John, if you write me a shopping list of what information you think >>>> useful, assuming you have time and inclination, I'll do my best >>>> provide it. >>> >>> Mostly a verbose boot of 9.0-RELEASE and what you see now. =A0If anythi= ng the >>> only changes I can think of since the release are to make some of the P= CI code >>> more lenient. =A0You could also try to narrow down exactly which revisi= on causes >>> the hang using a binary search of 9.0-STABLE since the release. >>> >>> -- >>> John Baldwin >> >> >> >> -- >> Harry Newton --=20 Harry Newton From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 06:45:10 2012 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 45752106566C; Sat, 3 Mar 2012 06:45:10 +0000 (UTC) (envelope-from hm@hm.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [187.95.0.181]) by mx1.freebsd.org (Postfix) with ESMTP id A9E508FC1C; Sat, 3 Mar 2012 06:45:09 +0000 (UTC) Received: from pop1.hm.net.br (pop1.hm.net.br [186.222.211.22]) by msrv.matik.com.br (8.14.5/8.14.5) with ESMTP id q236imXr060678; Sat, 3 Mar 2012 03:44:48 -0300 (BRT) (envelope-from hm@hm.net.br) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at msrv.matik.com.br X-DKIM: OpenDKIM Filter v2.4.3 msrv.matik.com.br q236imXr060678 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hm.net.br; s=racoon; t=1330757089; bh=1noH2iqsNY2B9o8ypNvmDRUV+ROrZKAs1Q77Mc090pE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=XPUzq0wDGcS5Lsv0Yb7Ys9XPf5Aw0a+gdPu7xfV0eaZLtLBjQyFmi9I1R97iMYPr5 cOK/pU0LSWbeEMqRuOI/mK8yFwHlmfQWL4lmmMEredu+RwbTxyZnTobZTTxCJaHM9w 7ZInzwnu38ALSoKKkuZ2qH7Oj7BcE0M+B2BoEmfI= Authentication-Results: msrv.matik.com.br; sender-id=pass header.from=hm@hm.net.br; spf=pass smtp.mfrom=hm@hm.net.br Message-ID: <4F51BDDA.3020602@hm.net.br> Date: Sat, 03 Mar 2012 03:44:42 -0300 From: H User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Firefox/10.0.2 SeaMonkey/2.7.2 MIME-Version: 1.0 To: Doug Barton References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F513B2D.6010809@FreeBSD.org> <4F5148A7.4080408@FreeBSD.org> In-Reply-To: <4F5148A7.4080408@FreeBSD.org> X-Enigmail-Version: 1.3.5 OpenPGP: id=9C63083C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4DB5391CF233C881E02D79E3" X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL, BAYES_00, J_CHICKENPOX_83, T_DKIM_INVALID, T_RP_MATCHES_RCVD autolearn=no version=3.3.2-hm_201202.c X-Spam-Checker-Version: SpamAssassin 3.3.2-hm_201202.c (2011-06-06) on msrv.matik.com.br Cc: stable@freebsd.org, Andriy Gapon Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 06:45:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4DB5391CF233C881E02D79E3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Doug Barton wrote: > Just looking at the committers, of which we have over 300, only a > couple dozen at most have ever identified as actually using FreeBSD as > a desktop at my count. Taking the larger development community into > account I think the numbers are a little better, but not much. Sure, > our strength is servers, and that is not going to change.=20 eventually that could be a good starting point, good question is, why not= ? > But how many real-life bugs have I personally uncovered in -current as > a result of actually running it (mostly) daily? I'm not the only one, > certainly, but if the numbers were flipped and the vast majority of > our developers *did* use FreeBSD routinely, how much better off would > we be?=20 again, why? let's face some reality. Forever installing FreeBSD Desktop, either KDE or Gnome, was a nightmare process, or better, to make it appear on screen was a nightmare. Even if somebody got all packages into his system (by miracle?), it still did not popped up. Without some special knowledge _no_chance_. who knows, the guys who created and battled on area51 knew why they chose this name :) Still now, kde4, hours of install, missing packages, compiling and still nothing, somewhere over the process, flies over the screen please set kdm4_enable=3D"YES" ... I guess that will not be noticed by any user Even if some smart guy figures out that he needs xorg-server, the port or package do not select all it needs for running, its own drivers and so. How a user should know that? There is a windeco which installs hundreds of deps, even sound what do not work on FreeBSD, but xorg do not have deps for its functionality? goooood ... ohhh I forgot, that has nothing to do with the desktop itself , sorry for mentioning ... Anybody can tell how somebody can find all this out? Don't say by reading because we need to look at the real facts and that is nobody want to read, they want a desktop nothing else, something silly and easy to read email and write docs and surf on the net, listen to a CD, they need to put a cd into the drive, running install process, reboot, using, nothing else and such a thing ... we do not have so where this potential users should come from? Only from heaven ... > And before anyone bothers to point it out, yes, I happen to be using > Windows at this exact moment. I have some layer 9 work to get done and > I need tools that are only available to me in Windows (more's the > pity). The sad thing is, judging by the activity on the -ports@ list, > the traffic in #bsdports, and just talking to/interacting with FreeBSD > users, a lot of *them* are not only interested in FreeBSD as a desktop > OS, they are actually doing it. IMO the weakest point is that we do not have the packages ready. Even if lots of you do not like it to hear, fact is that we must look around and see how others do it. Windows, whatever it is, it is easy to install for everybody. Same for Fedora, in order to stay with a Unix system, package handling, update with YUM on Fedora hardly fails. ALL packages are compiled, you never need to compile anything. Even if you need 800MB of packages, yum picks them all, installs them all, and all is fine up top date. Such a process is where we need to get orientation from. If it was my decision, it should be go to ports=3Dno_no, packages=3DYES I mean, as long as the packages are not complete and ready, no new port version should be released or announced So who dares,understand and can or like adventures, compiles from ports Such a decision would help FreeBSD in all means and would help the users as well, in any case it will create more users Why somebody should chose FreeBSD as his daily desktop, oh man, only some die-hard-guys like you and me, but you know, that is not hours of work, that is days, weeks and constant setbacks for whatever reasons ... that is not for anybody. And you are right, no traffic on the specific lists, why? because the three on the list, two can help themselves (you and me) and the other is the moderator ... :) not even the port maintainer/packager is on that list ... :) ps. the last statement might be exaggerated and might not be valid in all cases, so please do not shoot --=20 H --------------enig4DB5391CF233C881E02D79E3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9RvdoACgkQvKVfg5xjCDw3pwCgl6VpArMASV7UMlPTKNaawlXX 7oAAoJuJqYb8oD1wbN7PaYXvoHcMExos =hOUp -----END PGP SIGNATURE----- --------------enig4DB5391CF233C881E02D79E3-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 07:19:20 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 28278106564A; Sat, 3 Mar 2012 07:19:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id DC2788FC0C; Sat, 3 Mar 2012 07:19:19 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q237JJQp086334; Sat, 3 Mar 2012 07:19:19 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q237JJ4N086333; Sat, 3 Mar 2012 07:19:19 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 3 Mar 2012 07:19:19 GMT Message-Id: <201203030719.q237JJ4N086333@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 07:19:20 -0000 TB --- 2012-03-03 04:27:54 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-03-03 04:27:54 - starting RELENG_9 tinderbox run for powerpc64/powerpc TB --- 2012-03-03 04:27:54 - cleaning the object tree TB --- 2012-03-03 04:27:54 - cvsupping the source tree TB --- 2012-03-03 04:27:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/powerpc64/powerpc/supfile TB --- 2012-03-03 04:28:25 - building world TB --- 2012-03-03 04:28:25 - CROSS_BUILD_TESTING=YES TB --- 2012-03-03 04:28:25 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-03 04:28:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-03 04:28:25 - SRCCONF=/dev/null TB --- 2012-03-03 04:28:25 - TARGET=powerpc TB --- 2012-03-03 04:28:25 - TARGET_ARCH=powerpc64 TB --- 2012-03-03 04:28:25 - TZ=UTC TB --- 2012-03-03 04:28:25 - __MAKE_CONF=/dev/null TB --- 2012-03-03 04:28:25 - cd /src TB --- 2012-03-03 04:28:25 - /usr/bin/make -B buildworld >>> World build started on Sat Mar 3 04:28:26 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sat Mar 3 07:16:52 UTC 2012 TB --- 2012-03-03 07:16:52 - generating LINT kernel config TB --- 2012-03-03 07:16:52 - cd /src/sys/powerpc/conf TB --- 2012-03-03 07:16:52 - /usr/bin/make -B LINT TB --- 2012-03-03 07:16:52 - cd /src/sys/powerpc/conf TB --- 2012-03-03 07:16:52 - /usr/sbin/config -m LINT TB --- 2012-03-03 07:16:52 - building LINT kernel TB --- 2012-03-03 07:16:52 - CROSS_BUILD_TESTING=YES TB --- 2012-03-03 07:16:52 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-03 07:16:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-03 07:16:52 - SRCCONF=/dev/null TB --- 2012-03-03 07:16:52 - TARGET=powerpc TB --- 2012-03-03 07:16:52 - TARGET_ARCH=powerpc64 TB --- 2012-03-03 07:16:52 - TZ=UTC TB --- 2012-03-03 07:16:52 - __MAKE_CONF=/dev/null TB --- 2012-03-03 07:16:52 - cd /src TB --- 2012-03-03 07:16:52 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Mar 3 07:16:52 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything -------------------------------------------------------------- cd /obj/powerpc.powerpc64/src/sys/LINT; MAKEOBJDIRPREFIX=/obj/powerpc.powerpc64 MACHINE_ARCH=powerpc64 MACHINE=powerpc CPUTYPE= GROFF_BIN_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/powerpc.powerpc64/src/tmp VERSION="FreeBSD 8.2-STABLE amd64 802512" INSTALL="sh /src/tools/install.sh" PATH=/obj/powerpc.powerpc64/src/tmp/legacy/usr/sbin:/obj/powerpc.powerpc64/src/tmp/legacy/usr/bin:/obj/powerpc.powerpc64/src/tmp/legacy/usr/games:/obj/powerpc.powerpc64/src/tmp/usr/sbin:/obj/powerpc.powerpc64/src/tmp/usr/bin:/obj/powerpc.powerpc64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/make KERNEL=kernel all -DNO_MODULES_OBJ cc -c -x assembler-with-cpp -DLOCORE -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -mcall-aixdesc -ffreestanding -fstack-protector -Werror /src/sys/powerpc/aim/locore.S /src/sys/powerpc/aim/trap_subr64.S: Assembler messages: /src/sys/powerpc/aim/trap_subr64.S:421: Error: unsupported relocation against PC_SLBSTACK *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-03-03 07:19:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-03-03 07:19:19 - ERROR: failed to build LINT kernel TB --- 2012-03-03 07:19:19 - 7303.24 user 1070.76 system 10284.22 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-powerpc64-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 07:20:41 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A5D04106566C; Sat, 3 Mar 2012 07:20:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4218FC1A; Sat, 3 Mar 2012 07:20:41 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q236mxXc025976 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 2 Mar 2012 22:49:00 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F51BEE0.7090108@freebsd.org> Date: Fri, 02 Mar 2012 22:49:04 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Doug Barton References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> In-Reply-To: <4F510FBD.50008@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, "K. Macy" , =?UTF-8?B?eiBXxIVzaWtvd3NraQ==?= , Arnaud Lacombe , "Bjoern A. Zeeb" , Alexander Leidinger , current@freebsd.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 07:20:41 -0000 On 3/2/12 10:21 AM, Doug Barton wrote: > On 03/02/2012 03:44, K. Macy wrote: > not sure who wrote: >> Correct. However, I'm not sure the analogy is flawed. I am, to some >> degree, guilty of the same sin. I now run Ubuntu and have never had a >> single problem keeping my package system up date, in stark contrast to >> my experiences of slow and nightmarishly error-ridden port updates. > but I use the PBIs from pcbsd.. you REALLY don't have this problem with them. > Doug > From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 08:13:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B6A01065670; Sat, 3 Mar 2012 08:13:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.c2i.net [212.247.155.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6ABD08FC0A; Sat, 3 Mar 2012 08:13:16 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe09.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 72186650; Sat, 03 Mar 2012 09:13:08 +0100 From: Hans Petter Selasky To: "Jung-uk Kim" , freebsd-usb@freebsd.org Date: Sat, 3 Mar 2012 09:11:29 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.3-PRERELEASE; KDE/4.4.5; amd64; ; ) References: <20120227152238.GA2940@regency.nsu.ru> <20120302085012.GA25811@regency.nsu.ru> <201203021425.34456.jkim@FreeBSD.org> In-Reply-To: <201203021425.34456.jkim@FreeBSD.org> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201203030911.29633.hselasky@c2i.net> Cc: Alexey Dokuchaev , freebsd-stable@freebsd.org Subject: Re: Resume broken in 8.3-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: Sat, 03 Mar 2012 08:13:17 -0000 On Friday 02 March 2012 20:25:32 Jung-uk Kim wrote: > On Friday 02 March 2012 03:50 am, Alexey Dokuchaev wrote: > > On Thu, Mar 01, 2012 at 04:55:03PM -0500, Jung-uk Kim wrote: > > > It does not make a difference for me (i.e., usb suspend/resume > > > still broken) but I think I found a typo: > > > > > > --- sys/dev/usb/controller/usb_controller.c (revision 232365) > > > +++ sys/dev/usb/controller/usb_controller.c (working copy) > > > @@ -407,7 +407,7 @@ usb_bus_suspend(struct usb_proc_msg *pm) > > > > > > USB_BUS_UNLOCK(bus); > > > > > > - bus_generic_shutdown(bus->bdev); > > > + bus_generic_suspend(bus->bdev); > > > > > > usbd_enum_lock(udev); > > > > Same thing here, does not seem to improve anything. It might > > suspend, resume (with keyboard working), then die on next suspend > > completely. Or it may die on the first suspend (without suspending > > -- fans are spinning, screen is black and no response to anything > > except hard power-off), this actually happens more often. > > Try the attached patch. At least, it fixed my problem. Hi, I've committed your patch with some minor modifications. http://svn.freebsd.org/changeset/base/232448 Will you take care of the MFC to 8.3-RC + 8-stable? --HPS From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 08:37:06 2012 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 AC0D3106567B for ; Sat, 3 Mar 2012 08:37:06 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id ECD648FC17 for ; Sat, 3 Mar 2012 08:37:05 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA04656; Sat, 03 Mar 2012 10:37:02 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1S3kSc-000Jv1-2B; Sat, 03 Mar 2012 10:37:02 +0200 Message-ID: <4F51D839.0@FreeBSD.org> Date: Sat, 03 Mar 2012 10:37:13 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: H References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F513B2D.6010809@FreeBSD.org> <4F5148A7.4080408@FreeBSD.org> <4F51BDDA.3020602@hm.net.br> In-Reply-To: <4F51BDDA.3020602@hm.net.br> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 08:37:06 -0000 on 03/03/2012 08:44 H said the following: > let's face some reality. Let's do that. > Forever installing FreeBSD Desktop, either KDE or Gnome, was a nightmare > process, or better, to make it appear on screen was a nightmare. This has not been my experience (reality). -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 08:56:31 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90260106564A; Sat, 3 Mar 2012 08:56:31 +0000 (UTC) (envelope-from hm@hm.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [187.95.0.181]) by mx1.freebsd.org (Postfix) with ESMTP id 05E418FC08; Sat, 3 Mar 2012 08:56:30 +0000 (UTC) Received: from pop1.hm.net.br (pop1.hm.net.br [186.222.211.22]) by msrv.matik.com.br (8.14.5/8.14.5) with ESMTP id q238u1sT072153; Sat, 3 Mar 2012 05:56:11 -0300 (BRT) (envelope-from hm@hm.net.br) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at msrv.matik.com.br X-DKIM: OpenDKIM Filter v2.4.3 msrv.matik.com.br q238u1sT072153 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hm.net.br; s=racoon; t=1330764971; bh=+9qJJpO9XRgo5Hb4OfP/csOunTnMjYbplljn01LBFaQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=RIDnDGtVeHIdr2WA+oCPTIFs2zOwTi6B7a/tkwC1YjK6idIdaj1hRMDxc0K/hMUTF c/+cOiVcE8wXFUvhN8aMZjAdVsGZZU7+/4GHHH5LaJRuELw0I4QBAT8aiHBrbcPTpQ hgFgQ2e4vTe/o1vTrgziCAquv2s2LaF6FlxZjUv0= Authentication-Results: msrv.matik.com.br; sender-id=pass header.from=hm@hm.net.br; spf=pass smtp.mfrom=hm@hm.net.br Message-ID: <4F51DC96.1050508@hm.net.br> Date: Sat, 03 Mar 2012 05:55:50 -0300 From: H User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Firefox/10.0.2 SeaMonkey/2.7.2 MIME-Version: 1.0 To: Andriy Gapon References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F513B2D.6010809@FreeBSD.org> <4F5148A7.4080408@FreeBSD.org> <4F51BDDA.3020602@hm.net.br> <4F51D839.0@FreeBSD.org> In-Reply-To: <4F51D839.0@FreeBSD.org> X-Enigmail-Version: 1.3.5 OpenPGP: id=9C63083C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE15A637438C22395C1E909B7" X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL, BAYES_00, T_DKIM_INVALID, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2-hm_201202.c X-Spam-Checker-Version: SpamAssassin 3.3.2-hm_201202.c (2011-06-06) on msrv.matik.com.br Cc: stable@freebsd.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 08:56:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE15A637438C22395C1E909B7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > on 03/03/2012 08:44 H said the following: >> let's face some reality. > Let's do that. > >> Forever installing FreeBSD Desktop, either KDE or Gnome, was a nightma= re >> process, or better, to make it appear on screen was a nightmare. > This has not been my experience (reality). > of course not! but you do not count as well other developers and insiders do not, this kind of people we have a lot, BTW very capable people, if not the best ..= =2E but it depends on the angle of view and the question to be answered ... why we do not have more desktops out, why normal technicians and administrator do prefer Linux or Windows Workstations/server? because we do not attract them, it is to hard for them to find their way through so it is their eyes we have to look with --=20 H --------------enigE15A637438C22395C1E909B7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9R3JwACgkQvKVfg5xjCDzANQCgkQWwErKgvlSW4yyD4A4owmr3 aecAniV/TnDLuON0+uiBbRbkxi/JqUTv =L1+u -----END PGP SIGNATURE----- --------------enigE15A637438C22395C1E909B7-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 09:18:45 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5DDF106566C for ; Sat, 3 Mar 2012 09:18:45 +0000 (UTC) (envelope-from hm@hm.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [187.95.0.181]) by mx1.freebsd.org (Postfix) with ESMTP id 1D7B18FC14 for ; Sat, 3 Mar 2012 09:18:44 +0000 (UTC) Received: from pop1.hm.net.br (pop1.hm.net.br [186.222.211.22]) by msrv.matik.com.br (8.14.5/8.14.5) with ESMTP id q239IZOl073802; Sat, 3 Mar 2012 06:18:35 -0300 (BRT) (envelope-from hm@hm.net.br) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at msrv.matik.com.br X-DKIM: OpenDKIM Filter v2.4.3 msrv.matik.com.br q239IZOl073802 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hm.net.br; s=racoon; t=1330766315; bh=nNzm2WtD74sKd7gVCcW+mec8ypzGnWcKHHlLuiveNrQ=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=rI67IRMElCpTOaKCtG3a/NOtSlAc2Fy+wTGBytLqd9ulchll14pa1K7tZg1SaJjIA oWi9uaRPo2OlXp0glHnpNLzYl+IE5RnehwuXfbKXNFdLVUYNXDSrTx90ovbqOPcTJ/ 0qdwzDUeJv6xqzCfj9w5JqFx8kjeVwdCQWnR1+Hw= Authentication-Results: msrv.matik.com.br; sender-id=pass header.from=hm@hm.net.br; spf=pass smtp.mfrom=hm@hm.net.br Message-ID: <4F51E1E5.3000202@hm.net.br> Date: Sat, 03 Mar 2012 06:18:29 -0300 From: H User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Firefox/10.0.2 SeaMonkey/2.7.2 MIME-Version: 1.0 To: Bas Smeelen , freebsd-stable@FreeBSD.org References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F511496.50106@hm.net.br> <4F512BBB.9000403@ose.nl> In-Reply-To: <4F512BBB.9000403@ose.nl> X-Enigmail-Version: 1.3.5 OpenPGP: id=9C63083C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig06E9594F567A72B1C11277F8" X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL, BAYES_00, T_DKIM_INVALID, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2-hm_201202.c X-Spam-Checker-Version: SpamAssassin 3.3.2-hm_201202.c (2011-06-06) on msrv.matik.com.br Cc: Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 09:18:45 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig06E9594F567A72B1C11277F8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bas Smeelen wrote: > On 03/02/2012 07:42 PM, H wrote: >> Doug Barton wrote: >>> ... and here is the crux of the problem. The vast majority of our >>> developers don't use FreeBSD as their regular workstation. So it has >>> increasingly become an OS where changes are being lobbed over the wal= l >>> by developers who don't run systems that those changes affect. That's= >>> no way to run a railroad. Doug >> wow >> >> since it is not April 1st it must be revelation's day ...:) >> >> is this then the bottomline ? >> >> if [ $using_ports=3DYES ]; get_screwed($big_time); fi >> >> > Hey people > > There are still a lot of us which might not be smart enough or lack > the resources to help you debug issues but we still use and depend on > FreeBSD, and we test, and hopefully give you some debugging hints > > I have some production servers running on STABLE and even some on > CURRENT to stress our developers, but most run RELEASE and use > freebsd-update > > Keep up the good work, it makes me a more confident sysadmin > Ports is the best thing happening to me after going through al the apt > and other stuff you talk like the wind blows my friend ... remembering your own most recent words in another occasion what certainly do not match your last sentence ... >/ On Mon, Jan 30, 2012 at 3:58 PM, Bas Smeelen > wrote: />/ =20 />/ > On Mon, 30 Jan 2012 12:52:07 -0500 />/ > David Jackson > wrote: />/ > =20 />/ > > I have tried endlessly to no avail to upgrade binary the packages= />/ > > on Freebsd to the latest version. I have tried: />/ > > /... >/ > > />/ > > All fail miserably and totally and have left the system in an />/ > > unuseable state. =20 />/ > /.... >/=20 />/=20 />/ I wish to use binary packages and I specifically do not want to />/ compile anything, it tends to take far too long to compile programs />/ and would rather install some packages and have it all work right />/ away. Binary packages are a big time saver and are more efficient. It= />/ should be easy for FreeBSD to make it easy to install the most recent= />/ versions of all binary packages, its beyond belief they cannot pull />/ off such a simple ans straight forward, and basic part of any OS. / --=20 H --------------enig06E9594F567A72B1C11277F8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9R4eUACgkQvKVfg5xjCDytNwCbBIchuhBbZFNLzZ0aemIavAia vgcAoKDdmWmagK4TeRSYXBQxeLZxMwe0 =39jw -----END PGP SIGNATURE----- --------------enig06E9594F567A72B1C11277F8-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 10:12:37 2012 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 B81E51065670; Sat, 3 Mar 2012 10:12:37 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 2C5118FC18; Sat, 3 Mar 2012 10:12:37 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id q23ACaEi016466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Mar 2012 02:12:36 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.14.2/Submit) with UUCP id q23ACaaV016464; Sat, 3 Mar 2012 02:12:36 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA12669; Sat, 3 Mar 12 02:09:24 PST Date: Sat, 03 Mar 2012 09:09:09 -0800 From: perryh@pluto.rain.com To: hm@hm.net.br Message-Id: <4f525035.FeXsLHWGEs0tQIdS%perryh@pluto.rain.com> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F513B2D.6010809@FreeBSD.org> <4F5148A7.4080408@FreeBSD.org> <4F51BDDA.3020602@hm.net.br> In-Reply-To: <4F51BDDA.3020602@hm.net.br> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, dougb@freebsd.org, avg@freebsd.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 10:12:37 -0000 H wrote: > ... Forever installing FreeBSD Desktop, either KDE or Gnome, > was a nightmare process, or better, to make it appear on screen > was a nightmare. I have never understood the point of KDE or Gnome, other than (perhaps) as eye candy for the uninitiated. If I wanted a Windows desktop, I would install Windows. If I wanted a Mac desktop, I would use a Mac. I do use a few applications that were written using the Gnome or KDE _toolkits_, but that doesn't require me to run the whole Gnome or KDE "environment" (aka resource hog). Fvwm2 seems to be a perfectly adequate window manager. From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 11:00:08 2012 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 A7AD31065670; Sat, 3 Mar 2012 11:00:08 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 1D3B48FC0A; Sat, 3 Mar 2012 11:00:08 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id E3D7BE642A; Sat, 3 Mar 2012 11:00:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=38rGNBcCb4ci PfPy2PgORsfiH5A=; b=f6bzV3ePHpt/q9DGeDuTyAhwcIJlM+vhe4Tthf91BsyV 6OWpO8DRHpmmbp7fv7uX6e6wn0AvPjFPn1aClgbF+Op9BeCEXG+3IaT8e6XNOJrL WkdjknFku3SheYVytKk9Tgyqg2eZXMonQ+LdcWuTdImB4UGudyYfi5ozd3WCCuM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=wBEcDA n0RW/AwzGBVPCHObPtx+XWGK1wvda6BB12wgFx2eeoiFCv05OaTbj4OwA0d8eZAm e/sLlb8o55FpJ7S8PK7W+XYeVznk192jA8wjwG6v36XWecLJgPHUc5bc3vf7NCI+ ODzAhXMN9fZsCb6UWVtiqSfh8i1bremyElqr0= Received: from [192.168.1.72] (188-220-36-32.zone11.bethere.co.uk [188.220.36.32]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id BB773E6414; Sat, 3 Mar 2012 11:00:06 +0000 (GMT) Message-ID: <4F51F9A9.6010805@cran.org.uk> Date: Sat, 03 Mar 2012 10:59:53 +0000 From: Bruce Cran User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F513B2D.6010809@FreeBSD.org> <4F5148A7.4080408@FreeBSD.org> <4F51BDDA.3020602@hm.net.br> <4f525035.FeXsLHWGEs0tQIdS%perryh@pluto.rain.com> In-Reply-To: <4f525035.FeXsLHWGEs0tQIdS%perryh@pluto.rain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hm@hm.net.br, stable@freebsd.org, dougb@freebsd.org, avg@freebsd.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 11:00:08 -0000 On 03/03/2012 17:09, perryh@pluto.rain.com wrote: > I have never understood the point of KDE or Gnome, other than > (perhaps) as eye candy for the uninitiated. If I wanted a > Windows desktop, I would install Windows. If I wanted a Mac > desktop, I would use a Mac. And if you want a FreeBSD desktop with great integration between applications and the ability to change settings without reading man pages? You run FreeBSD with KDE or GNOME. -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 11:55:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 515E8106567E for ; Sat, 3 Mar 2012 11:55:50 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id BF8828FC1A for ; Sat, 3 Mar 2012 11:55:48 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1S3nJI-0003jF-Ur>; Sat, 03 Mar 2012 12:39:37 +0100 Received: from e178025231.adsl.alicedsl.de ([85.178.25.231] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1S3nJI-0007pw-NU>; Sat, 03 Mar 2012 12:39:36 +0100 Message-ID: <4F5202F0.1020205@zedat.fu-berlin.de> Date: Sat, 03 Mar 2012 12:39:28 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120223 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, Current FreeBSD References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F513B2D.6010809@FreeBSD.org> <4F5148A7.4080408@FreeBSD.org> <4F51BDDA.3020602@hm.net.br> In-Reply-To: <4F51BDDA.3020602@hm.net.br> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCDD584BCDD94D7E19CD4691B" X-Originating-IP: 85.178.25.231 Cc: Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 11:55:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCDD584BCDD94D7E19CD4691B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/03/12 07:44, H wrote: > Doug Barton wrote: >> [...] Sure, >> our strength is servers, and that is not going to change.=20 I agree and disagree. Based upon the struggle with desktop usage and focus on development, FreeBSD is de facto more server oriented. But in comparison to several other non-BSD opensource server OS projects, the corridor of advantages in FreeBSD became and still become smaller and smaller. This is the experience of using FreeBSD now since 1995 as my favorite OS for servers I maintained for scientific projects and my personal desktop(s). Please don't take me wrong, but the conclusion of the strength of FBSD is due to its weakness - and this is not willingly, it is coincidentialy.= >> But how many real-life bugs have I personally uncovered in -current as= >> a result of actually running it (mostly) daily? I'm not the only one, >> certainly, but if the numbers were flipped and the vast majority of >> our developers *did* use FreeBSD routinely, how much better off would >> we be? Well, for an "open" source project this sounds to me a bit strange. Developers do not use the OS they developing for as their platform? This might be new to me and an old information for the majority of you developers, but I see strange implications ins that fact. FreeBSD is considered an open source project ran by "volunteers" (I receive this magic message in all forums I ever complained about some problems ...). Honestly and in terms on logic, I can not line up several points, sorry, I might be too dumb. Obviously not a development by heart but by payment? But this is OT here and I never could emphaszie people to follow my philosophical tracks (which might be inadequate for some sets of people ...). > let's face some reality. Forever installing FreeBSD Desktop, either KDE= > or Gnome, was a nightmare process, or better, to make it appear on > screen was a nightmare. Since myself (and some remnant "we") use FreeBSD for both servers (development of scientific software, processing scientific stuff, modelling, rendering for PR products related in astrodynamics and planetary sciences) and as the desktop system of choice, I never found a friend in that performance eating thing "KDE" or "GNOME" and stayed long time with fvwm and now with windowmaker. Yes, this sounds like an echo from the past, but living like a monk and celebrating askesis in that fashion made me faster in some ways and independent from "fast" hardware and recent developments in X11, in which FreeBSd now turns out to get a position "last" in terms of modern display driver architectures. But I'm still impressed by the fancy and coloured desktops of PC-BSD, which I have ran for some people to lurde them into the BSD world ... >=20 > Even if somebody got all packages into his system (by miracle?), it > still did not popped up. Without some special knowledge _no_chance_. >=20 > who knows, the guys who created and battled on area51 knew why they > chose this name :) >=20 > Still now, kde4, hours of install, missing packages, compiling and stil= l > nothing, somewhere over the process, flies over the screen please set > kdm4_enable=3D"YES" ... I guess that will not be noticed by any user >=20 > Even if some smart guy figures out that he needs xorg-server, the port > or package do not select all it needs for running, its own drivers and > so. How a user should know that? There is a windeco which installs > hundreds of deps, even sound what do not work on FreeBSD, but xorg do > not have deps for its functionality? goooood ... ohhh I forgot, that ha= s > nothing to do with the desktop itself , sorry for mentioning ... Maybe the logic behind the dependency system need a refurbish? I feel lost when trying to look into the vast number of of *.mk files and having to figure out myself how they get involved when building some essential ports. Each "tweak" seems to go into those files undocumented and the logical hierarchy isn't obvious, since many dependencies are hidden in GNOME/KDE related files. Not to mention the mess that ariose when I tried to follow a strict separartion of building the core FreeBSD UNIX only with /etc/src.conf leaving compiler options for non-/usr/src related software in make.conf. Obviously, they are mixed up in a way I get tired as a non-developer to keep on pace with.CLANG is a nice compiler, I like it, I use it now as the base compiler for everything, but the lack of OpenMP and optimizations for modern CPUs (Core-i7/Sandy Bridge/-E) makes it a bit unapplicable to several software packages I'd like to use. And the confusion using the legacy, outdated gcc 4.2.1 in the base system and replace it "easily" by gcc 4.6.3 or now 4.7.X is taking valuable working time. I think, and this is my personal opinion and view, it would be much better to sort out the confusion in the build system(s) and then start over. I guess there are a lot of options to do so, even now, but how to find documentation? Crawling scripts and source code to find out the logic and vast numbers of variables isn't a way. > Even if lots of you do not like it to hear, fact is that we must look > around and see how others do it. Windows, whatever it is, it is easy to= > install for everybody. Well, this is right. But do not forget that even those fancy and easy to use installation framework hide a lot of the underlying system's hierarchy and logic. Look at all the Linux systems, trying to get on par with Windows. How long did they raped Linux to get it that way looking? In and on FreeBSD, speaking now for the server, I receive a problem or get aware of a problem. Since the system hasn't been overpolluted and made suffering with logic and structure covering scripts like, for instance in Suse Linux or Ubuntu, I often know were to look for a solution. On our Linux systems (CentOS, Ubuntu, Suse), I need to consult fancy scripts. Yes, the scripts work - in most cases, but I do not know what is going on beneath ... In terms of security, privacy and total control this is a very bad feeling situation. > If it was my decision, it should be go to ports=3Dno_no, packages=3DYES= In such a case, there would be no reason anymore to use FreeBSD! I want to use the system as fast as possible on desktop, so binary packages should be all right. But on servers, I'd like to squeeze out the last nanosecond I can grab by using dedicated compiler options. So I wnt to have the choise! My freedom, my responsibility and also the freedom to decide for my own how much "brain" I want to invest into understanding my OS - or even not. At this very point, I "can", up to a certain point, decide how much time I want to spend on understanding. Others "can not", by natural selection, they need to be stuck with binaries. or they won't, because they are more in business than science and have no interest in other things than money. Or, even in more soft words, they need a working horse to perform the daily work they are interested in. >=20 > I mean, as long as the packages are not complete and ready, no new port= > version should be released or announced Why not? How should the "free" open source community then ever help to debug? I guess what you think about is to have a more strict "RELEASE/STABLE/CURRENT/ based policy also for the ports system? I would agree. >=20 > So who dares,understand and can or like adventures, compiles from ports= It is not simple as that. The "logic" starts at the compiler's point. GCC 4.2.1 isn't an option in many cases, CLANG unsuitable (openMP). On the other hand, who should provide all the binary coverage? As you could see, the user domain of FreeBSD is shrinking. And even my department is not willing to spend my time, traffic volume and hardware to provide a build server for FreeBSD binaries to provide a better coverage for "world" or even only for the mid of Germany. They like to be better with Linux, preferably "Ubuntu". >=20 > Such a decision would help FreeBSD in all means and would help the user= s > as well, in any case it will create more users Yes, well said, but a bit false. World has changed since the last 50 years, politically. Monolithic capitalism with a herd of dumb, mean animals only want to "touch and use". Monolithic socialism creates mean people from the same source, greedy, envy to share and kick-asses those who can and are bright enough. The "bright" go to capitalism, sonce they get sucked in by monstrous large companies, the remnants remain in "socialism" pools. The so called Bourgeoisie is getting smaller, but this is also OT, sorry ... >=20 > Why somebody should chose FreeBSD as his daily desktop, oh man, only > some die-hard-guys like you and me, but you know, that is not hours of > work, that is days, weeks and constant setbacks for whatever reasons ..= =2E > that is not for anybody. And you are right, no traffic on the specific > lists, why? because the three on the list, two can help themselves (you= > and me) and the other is the moderator ... :) not even the port > maintainer/packager is on that list ... :) >=20 Well, these days dying on FreeBSD is much quicker than years before - in my special case. Linux is faster in (our) network. Linux response faster in (our) NFSv4 (environment). Linux has a better scalability (NUMA awareness seems to be better on our 2-socket servers). Linux adopt faster new architectures due to a better maintaining of the necessary compiler(s). And I'm going to face another development that will let FreeBSD die faster in certain scientific areas (were the BSD has been born!). This is mainly due to the lack of the support of modern GPGPU stuff. I'm forced to replace several FreeBSD servers now by Suse Linux machines. Reason: GPGPU. We can use OpenCL/CUDA on the TESLA boards we obtained, we can use OpenCL/CUDA on the desktop boxes equipted with expensive and fast GPU hardware (and we do this very intensive now). We modell, simulate and optimize on GPGPU code developed by scientists in our depeartment, based on OpenCL. Since we are also dependend on funding from the government (we have to present so called "PR products" which include scientifically prepared and rendered products of solar system objects like Mars or the Saturnian icy moons), we need to build up a "render cluster", which we do with a well known open source rendering software which has now GPGPU support. Even on "out of the box server Linux" this can not be performed "out of the box" and need "die hard" people. But they do not die hard on FBSD anymore. Call it "natural selection". Regards, oh --------------enigCDD584BCDD94D7E19CD4691B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJPUgL4AAoJEOgBcD7A/5N8s9gH/A3KdiTIyL9ayJGxHJ+Z8gve Hu08UXUH4sR1F3vXwSyroxSVEpz9KWa3WCkjMugeGJqT1sNegEHCQornaaVFRiat TcbiSOYgyOdwSWFaFo2KOfQgjL/ppP3oUQoYTP/dIKZBS+NwCjj1in48XLK+NKB0 YfxH3ktivLTHpCBQUi0OMuZunNBb1EGgoZy6F/8xn5EyOFSfHWjXFJ2Ilpkz8KT0 EWzAVuCSxWd9BVrkwfa2pLah4XIQ2fc7g+RXN37SEOrFhYodTnLmB2zX0tK0dWss 5J/grdI4lFju1atHGBB8OvzDCNFrPh7I3r+vBb6zK3LIe3ad33mqfzCI6FY+8aw= =pIUK -----END PGP SIGNATURE----- --------------enigCDD584BCDD94D7E19CD4691B-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 12:00:47 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C39F106567A; Sat, 3 Mar 2012 12:00:47 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 481C08FC1A; Sat, 3 Mar 2012 12:00:47 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1S3nO7-0004CP-Rz>; Sat, 03 Mar 2012 12:44:35 +0100 Received: from e178025231.adsl.alicedsl.de ([85.178.25.231] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1S3nO7-000841-NM>; Sat, 03 Mar 2012 12:44:35 +0100 Message-ID: <4F520423.1060803@zedat.fu-berlin.de> Date: Sat, 03 Mar 2012 12:44:35 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120223 Thunderbird/10.0.2 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F513B2D.6010809@FreeBSD.org> <4F5148A7.4080408@FreeBSD.org> <4F51BDDA.3020602@hm.net.br> <4f525035.FeXsLHWGEs0tQIdS%perryh@pluto.rain.com> In-Reply-To: <4f525035.FeXsLHWGEs0tQIdS%perryh@pluto.rain.com> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA056E3A86F04CCBA8848FD7B" X-Originating-IP: 85.178.25.231 Cc: hm@hm.net.br, stable@freebsd.org, dougb@freebsd.org, avg@freebsd.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 12:00:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA056E3A86F04CCBA8848FD7B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Back to the topic of the initial posting: Where can I find documentation for the "idiot" about flowtable? I can switch this to "ON" in the kernel config on FreeBSD 9.0-STABLE as well as in FreeBSD 10.0-CURRENT. But I can not find any hint what it is supposed to do, what benefit it could provide or what working environment it is aimed to. There are other kernel options, like IPI_PREEMPTION, which are very poor "documented". I feel willing to switch on and off options and watch the system's behaviour, but I'm not willing to find out what those options are for by running a uncountable number of benchmarks or tests. It would be really nice to have a very intuitive way to find some "notes" on that. The "NOTES" files are not sufficient. Regards Oliver --------------enigA056E3A86F04CCBA8848FD7B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJPUgQjAAoJEOgBcD7A/5N8gZAH/247OMk2RK0jBhZ6E3X0woyb 2VUuyL5Kp8su4srDiQ1D/7D2sUDktjhFZJHKS0M55Wsxcf6xYSuDJ2GGsaXyiqjz KxU2OW5qH3BEQhPoWtgp7N/jlMcSfYrMYf2gglX5vEjdSsuG1nGCNTccAum2Qjd2 VjBzmthM3b+YGsl4afdxtZX9xqbabfbxT2g1h35Kz8OuPLPEMVleWkRbL/OIQyPX 1C/3X2pjbmF+vAUVbYiga6d/Z93PbYeCtY1dNKVr/LaFO+a21GHArFSK6zHRrSOe +j2+5N0A0N0/wlKjT2qISjhh7ldPgD0r2fx4wo4+DuTHPgaJRJi/WLXsklw0XBk= =qRK9 -----END PGP SIGNATURE----- --------------enigA056E3A86F04CCBA8848FD7B-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 12:54:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 072EA106566B; Sat, 3 Mar 2012 12:54:08 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id AECD58FC16; Sat, 3 Mar 2012 12:54:07 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1S3oTO-0003qJ-JS>; Sat, 03 Mar 2012 13:54:06 +0100 Received: from e178025231.adsl.alicedsl.de ([85.178.25.231] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1S3oTO-0002vX-Eq>; Sat, 03 Mar 2012 13:54:06 +0100 Message-ID: <4F521467.6010709@zedat.fu-berlin.de> Date: Sat, 03 Mar 2012 13:53:59 +0100 From: "O. Hartmann" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120223 Thunderbird/10.0.2 MIME-Version: 1.0 To: Current FreeBSD , FreeBSD Stable Mailing List References: <4F520883.5090204@FreeBSD.org> In-Reply-To: <4F520883.5090204@FreeBSD.org> X-Enigmail-Version: 1.3.5 X-Forwarded-Message-Id: <4F520883.5090204@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCBA8523E8141C58FC0D68B22" X-Originating-IP: 85.178.25.231 Cc: Subject: Fwd: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 12:54:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCBA8523E8141C58FC0D68B22 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable on 03/03/2012 13:44 O. Hartmann said the following: > Back to the topic of the initial posting: >=20 > Where can I find documentation for the "idiot" about flowtable? I can=20 > switch this to "ON" in the kernel config on FreeBSD 9.0-STABLE as well = as > in FreeBSD 10.0-CURRENT. But I can not find any hint what it is suppose= d to > do, what benefit it could provide or what working environment it is aim= ed > to. >=20 > There are other kernel options, like IPI_PREEMPTION, which are very poo= r=20 > "documented". I feel willing to switch on and off options and watch the= =20 > system's behaviour, but I'm not willing to find out what those options = are > for by running a uncountable number of benchmarks or tests. >=20 > It would be really nice to have a very intuitive way to find some "note= s" > on that. The "NOTES" files are not sufficient. Maybe it would make sense to restore the original To/Cc list too? --=20 Andriy Gapon --------------enigCBA8523E8141C58FC0D68B22 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJPUhRtAAoJEOgBcD7A/5N8j7QH/jmxcsD/iSAV643TSIc2EAJi NAZQV87WcIEIKbW1NrZov1eA3b7GZDT8tXmbkj0JwdCmcX6CNDjN7p1Jqdmfq4uj RPntXi0DMhFxknvPkrOuQYHkrtJFxhJCC4G8C3Nf3ysL0wdyo+GD/xY/8wWopWVx cvTrI8XwcTX26v5SQzkR9RNtwjYZpb4UGrd8bTuQV7FYqDYRpy7W9J3daENyl6UA SFJ12k3MLvbPALl2glcFfR4VxGsJoviAxr+Ov11/I6spHJbtsdedWhrGut7cm+V4 ZdKXwpkgTr6QE+ikOcAfDu6htuaCJt8iL/OUyun7EeS+3jMSEU2+4hlHASJbJfo= =c3MI -----END PGP SIGNATURE----- --------------enigCBA8523E8141C58FC0D68B22-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 14:17:49 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26B111065670 for ; Sat, 3 Mar 2012 14:17:49 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 7DDCC8FC0C for ; Sat, 3 Mar 2012 14:17:48 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Sat, 3 Mar 2012 15:17:39 +0100 Message-ID: <4F522803.70205@ose.nl> Date: Sat, 03 Mar 2012 15:17:39 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: H References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F511496.50106@hm.net.br> <4F512BBB.9000403@ose.nl> <4F51E1E5.3000202@hm.net.br> In-Reply-To: <4F51E1E5.3000202@hm.net.br> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 14:17:49 -0000 On 03/03/2012 10:18 AM, H wrote: > you talk like the wind blows my friend ... > > remembering your own most recent words in another occasion what > certainly do not match your last sentence ... What you 'mis'quote further down was not my writing. http://lists.freebsd.org/pipermail/freebsd-questions/2012-January/237779.html My reply to djackson was and more, see link above I understand your motivations. On my 1,6GHz celeron it takes a lot of time to compile the ~600 ports I use, especially chromium for instance and when I forget to give an option to not bother me with questions it sits there waiting for me to enter y or n. Ports/ packages are not `a basic part` of the FreeBSD OS. I also don't think it is simple and straight forward to satisfy all different user requirements and options in a package system. Ubuntu for my taste has had flukes in many ways many times in the past and still has (often enough the developers desktop users complain). It works good with complete upgrades at times, on the other hand it still leaves me sometimes with an unusable freezing OS on the desktop, and before every upgrade it has becomes mandatory to me to first try it with an USB boot. This is something I cannot have on server systems being used 24x7. > >> / On Mon, Jan 30, 2012 at 3:58 PM, Bas Smeelen> wrote: > />/ > />/> On Mon, 30 Jan 2012 12:52:07 -0500 > />/> David Jackson> wrote: > />/> > />/> > I have tried endlessly to no avail to upgrade binary the packages > />/> > on Freebsd to the latest version. I have tried: > />/> > > /... >> /> > > />/> > All fail miserably and totally and have left the system in an > />/> > unuseable state. > />/> > /.... >> / > />/ > />/ I wish to use binary packages and I specifically do not want to > />/ compile anything, it tends to take far too long to compile programs > />/ and would rather install some packages and have it all work right > />/ away. Binary packages are a big time saver and are more efficient. It > />/ should be easy for FreeBSD to make it easy to install the most recent > />/ versions of all binary packages, its beyond belief they cannot pull > />/ off such a simple ans straight forward, and basic part of any OS. / > > > > > Disclaimer: http://www.ose.nl/email From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 14:20:23 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E840510656A7 for ; Sat, 3 Mar 2012 14:20:22 +0000 (UTC) (envelope-from b.smeelen@ose.nl) Received: from mail.ose.nl (mail.ose.nl [212.178.134.164]) by mx1.freebsd.org (Postfix) with ESMTP id 480678FC2B for ; Sat, 3 Mar 2012 14:20:21 +0000 (UTC) X-Footer: b3NlLm5s Received: from localhost ([127.0.0.1]) by mail.ose.nl (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Sat, 3 Mar 2012 15:20:20 +0100 Message-ID: <4F5228A3.1080707@ose.nl> Date: Sat, 03 Mar 2012 15:20:19 +0100 From: Bas Smeelen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: H References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F511496.50106@hm.net.br> <4F512BBB.9000403@ose.nl> <4F51E1E5.3000202@hm.net.br> In-Reply-To: <4F51E1E5.3000202@hm.net.br> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 14:20:23 -0000 On 03/03/2012 10:18 AM, H wrote: > Bas Smeelen wrote: >> On 03/02/2012 07:42 PM, H wrote: >>> Doug Barton wrote: >>>> ... and here is the crux of the problem. The vast majority of our >>>> developers don't use FreeBSD as their regular workstation. So it has >>>> increasingly become an OS where changes are being lobbed over the wall >>>> by developers who don't run systems that those changes affect. That's >>>> no way to run a railroad. Doug >>> wow >>> >>> since it is not April 1st it must be revelation's day ...:) >>> >>> is this then the bottomline ? >>> >>> if [ $using_ports=YES ]; get_screwed($big_time); fi >>> >>> >> Hey people >> >> There are still a lot of us which might not be smart enough or lack >> the resources to help you debug issues but we still use and depend on >> FreeBSD, and we test, and hopefully give you some debugging hints >> >> I have some production servers running on STABLE and even some on >> CURRENT to stress our developers, but most run RELEASE and use >> freebsd-update >> >> Keep up the good work, it makes me a more confident sysadmin >> Ports is the best thing happening to me after going through al the apt >> and other stuff > you talk like the wind blows my friend ... > > remembering your own most recent words in another occasion what > certainly do not match your last sentence ... The last sentences: In short: FreeBSD makes you think about what you are doing beforehand which makes a great way to upgrade/ update application, database e.g. on servers whithout running into service downtime. Other OS's don't or do it less. I like that a lot, it saves a lot of incoming phone calls. http://lists.freebsd.org/pipermail/freebsd-questions/2012-January/237779.html > >> / On Mon, Jan 30, 2012 at 3:58 PM, Bas Smeelen> wrote: > />/ > />/> On Mon, 30 Jan 2012 12:52:07 -0500 > />/> David Jackson> wrote: > />/> > />/> > I have tried endlessly to no avail to upgrade binary the packages > />/> > on Freebsd to the latest version. I have tried: > />/> > > /... >> /> > > />/> > All fail miserably and totally and have left the system in an > />/> > unuseable state. > />/> > /.... >> / > />/ > />/ I wish to use binary packages and I specifically do not want to > />/ compile anything, it tends to take far too long to compile programs > />/ and would rather install some packages and have it all work right > />/ away. Binary packages are a big time saver and are more efficient. It > />/ should be easy for FreeBSD to make it easy to install the most recent > />/ versions of all binary packages, its beyond belief they cannot pull > />/ off such a simple ans straight forward, and basic part of any OS. / > > > > > Disclaimer: http://www.ose.nl/email From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 15:33:08 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99E04106564A for ; Sat, 3 Mar 2012 15:33:08 +0000 (UTC) (envelope-from hm@hm.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [187.95.0.181]) by mx1.freebsd.org (Postfix) with ESMTP id 07FBB8FC08 for ; Sat, 3 Mar 2012 15:33:07 +0000 (UTC) Received: from pop1.hm.net.br (pop1.hm.net.br [186.222.215.103]) by msrv.matik.com.br (8.14.5/8.14.5) with ESMTP id q23FWcVr002681; Sat, 3 Mar 2012 12:32:38 -0300 (BRT) (envelope-from hm@hm.net.br) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at msrv.matik.com.br X-DKIM: OpenDKIM Filter v2.4.3 msrv.matik.com.br q23FWcVr002681 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hm.net.br; s=racoon; t=1330788765; bh=miZ/Oi66Z9xeKtZ1ZqdeQsprjINgMf42mZo8wKGBWq8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=dYvmdknz5tTPAVidkygRhZ2Z7oecRCosUA4u9bpJ5+fvjJxZh6SL4wjFzvrXODVcX jEOw7UT0CHlDw4rPjni+Z6NCspaSax3AjRbQo35hPbXzhb8VNVSflBCfUg6Jh7IHV4 +y5PrT9vXJHKiaR8Um5gn40qtDRgpRPAElIcmzvo= Authentication-Results: msrv.matik.com.br; sender-id=pass header.from=hm@hm.net.br; spf=pass smtp.mfrom=hm@hm.net.br Message-ID: <4F52398F.9030608@hm.net.br> Date: Sat, 03 Mar 2012 12:32:31 -0300 From: H User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Firefox/10.0.2 SeaMonkey/2.7.2 MIME-Version: 1.0 To: Bas Smeelen References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F511496.50106@hm.net.br> <4F512BBB.9000403@ose.nl> <4F51E1E5.3000202@hm.net.br> <4F522803.70205@ose.nl> In-Reply-To: <4F522803.70205@ose.nl> X-Enigmail-Version: 1.3.5 OpenPGP: id=9C63083C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEA14983C9780B3F9A0E431DD" X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL, BAYES_00, T_DKIM_INVALID, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2-hm_201202.c X-Spam-Checker-Version: SpamAssassin 3.3.2-hm_201202.c (2011-06-06) on msrv.matik.com.br Cc: freebsd-stable@FreeBSD.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 15:33:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEA14983C9780B3F9A0E431DD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bas Smeelen wrote: > />/ away. Binary packages are a big time saver and are more efficient. = It > />/ should be easy for FreeBSD to make it easy to install the most rece= nt > />/ versions of all binary packages, its beyond belief they cannot pull= > />/ off such a simple ans straight forward, and basic part of any OS. = /=20 come on, you really think I need lecturing about how to read threads? and I did not misquoted nothing, you are trying to save your ass here :) in the above excerpt _YOU_ are talking about packages and how easy it is =2E.. and this "cannot pull off" thing ... then you tell us today that ports is the best ever happened to you > Ports is the best thing happening to me after going through al the apt and other stuff but look my friend, either way, you're confirming this thread, as long as conflicts are in place, something needs improvement //* the following comment is not related to any living person, only a quote with personal note :) please lord forgive them, they don't know what they are doing (or talking about) .... *// --=20 H --------------enigEA14983C9780B3F9A0E431DD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9SOY8ACgkQvKVfg5xjCDyyYgCfdJykWwirqMU3jTKz17t53enY JyUAn17x7lLq/1Sb/Ugp3qeFbEbSA1q+ =e71w -----END PGP SIGNATURE----- --------------enigEA14983C9780B3F9A0E431DD-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 15:39:00 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC3771065673 for ; Sat, 3 Mar 2012 15:39:00 +0000 (UTC) (envelope-from adam.strohl@ateamsystems.com) Received: from fss.sandiego.ateamservers.com (fss.sandiego.ateamservers.com [69.55.229.149]) by mx1.freebsd.org (Postfix) with ESMTP id 809C58FC0A for ; Sat, 3 Mar 2012 15:39:00 +0000 (UTC) Received: from [192.168.15.220] (unknown [118.175.84.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by fss.sandiego.ateamservers.com (Postfix) with ESMTPSA id 3D269B90B0; Sat, 3 Mar 2012 10:38:52 -0500 (EST) Message-ID: <4F523B11.5050002@ateamsystems.com> Date: Sat, 03 Mar 2012 22:38:57 +0700 From: Adam Strohl Organization: A-Team Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: H References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F511496.50106@hm.net.br> <4F512BBB.9000403@ose.nl> <4F51E1E5.3000202@hm.net.br> <4F522803.70205@ose.nl> <4F52398F.9030608@hm.net.br> In-Reply-To: <4F52398F.9030608@hm.net.br> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030107000208030408070402" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Bas Smeelen , freebsd-stable@FreeBSD.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 15:39:00 -0000 This is a cryptographically signed message in MIME format. --------------ms030107000208030408070402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 3/3/2012 22:32, H wrote: > then you tell us today that ports is the best ever happened to you It definitely is for me, and is a major reason why I love FreeBSD. =20 Yum/RPM/etc are not without their own issues, and definitely is not fool = proof nor 100% reliable in my experience. --------------ms030107000208030408070402-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 16:09:03 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2658106566B; Sat, 3 Mar 2012 16:09:02 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 8397B8FC18; Sat, 3 Mar 2012 16:09:02 +0000 (UTC) Received: by dakl33 with SMTP id l33so7885586dak.17 for ; Sat, 03 Mar 2012 08:08:56 -0800 (PST) Received-SPF: pass (google.com: domain of yanegomi@gmail.com designates 10.68.132.1 as permitted sender) client-ip=10.68.132.1; Authentication-Results: mr.google.com; spf=pass (google.com: domain of yanegomi@gmail.com designates 10.68.132.1 as permitted sender) smtp.mail=yanegomi@gmail.com; dkim=pass header.i=yanegomi@gmail.com Received: from mr.google.com ([10.68.132.1]) by 10.68.132.1 with SMTP id oq1mr21852733pbb.137.1330790936098 (num_hops = 1); Sat, 03 Mar 2012 08:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5KN00C8t2j2UAeJJA9m3+xYPMQnDT+zvzilNjJoabNo=; b=aU4wRWZXAMF9bOUDkIANmo5vZ2IICabQbGnTBm4VC4utu2GXA5ovooHct96pgwD0QJ oAgjM8uw8BzarSltaOkqeTnL984O1gSIHxVLpj62NyvZOR3e5YwbBWIeNDmhCUzIzemW RQFm1fP8afvvVFEpdNwTWp6F4GBfudwjZFDXGAD4jPFpTHGsoGTQvoQPHXO/eyPKmYGu qIxBgtjecAfsXin6t2Yk4RHOo6zOOXXGgZbrVaZZFIJexTWzMPjRmSxa0iQrBnmbNhTO R5sljOyg//8ILnYRAYb4FBCM1AwbVDa4VNfsgbKW9I2D8cL8bvvhfnVLz5i3zuh8snBM T0aQ== MIME-Version: 1.0 Received: by 10.68.132.1 with SMTP id oq1mr18344076pbb.137.1330789079192; Sat, 03 Mar 2012 07:37:59 -0800 (PST) Received: by 10.68.130.106 with HTTP; Sat, 3 Mar 2012 07:37:58 -0800 (PST) In-Reply-To: <4F51BEE0.7090108@freebsd.org> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F51BEE0.7090108@freebsd.org> Date: Sat, 3 Mar 2012 07:37:58 -0800 Message-ID: From: Garrett Cooper To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , FreeBSD Stable , "K. Macy" , =?ISO-8859-2?Q?z_W=B1sikowski?= , FreeBSD Current , Arnaud Lacombe , Alexander Leidinger , "Bjoern A. Zeeb" Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 16:09:03 -0000 2012/3/2 Julian Elischer : > On 3/2/12 10:21 AM, Doug Barton wrote: >> >> On 03/02/2012 03:44, K. Macy wrote: > > not sure who wrote: >>> >>> Correct. However, I'm not sure the analogy is flawed. I am, to some >>> degree, guilty of the same sin. I now run Ubuntu and have never had a >>> single problem keeping my package system up date, in stark contrast to >>> my experiences of slow and nightmarishly error-ridden port updates. > > but I use the PBIs from pcbsd.. =A0you REALLY don't have this problem wit= h > them. (Thanks Kip for the heads up on the thread) It's well known that software has bugs; unfortunately PCBSD (I mention this because of PBIs noted above) isn't immune from bugs either -- they're just manifested in a different way. I think everyone here on the CC list has FreeBSD's best intentions in mind, but let's work together to improve the OS instead of causing discord with one another. Personally, I think that adding knobs with sane defaults (and we can debate about that and there will be disagreement on what is important and what is not) will go a long way because then people can pick and choose what they want to keep and what they want to toss as far as OS support is concerned. This is one of the strong selling points of Linux, OSX, Solaris, Windows, etc. Less effort is required to get greater profit without having to mess around with things because they fit the generic case as opposed to a number of niche cases or provide OS features that a user may or may not use. Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 16:25:55 2012 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 86F5E106564A for ; Sat, 3 Mar 2012 16:25:55 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 657AA8FC12 for ; Sat, 3 Mar 2012 16:25:55 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta04.emeryville.ca.mail.comcast.net with comcast id h4Jg1i0010FhH24A44Rp0Z; Sat, 03 Mar 2012 16:25:49 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta08.emeryville.ca.mail.comcast.net with comcast id h4Rn1i00T4NgCEG8U4Roiy; Sat, 03 Mar 2012 16:25:49 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q23GPki2011715; Sat, 3 Mar 2012 09:25:46 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: H In-Reply-To: <4F51BDDA.3020602@hm.net.br> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F513B2D.6010809@FreeBSD.org> <4F5148A7.4080408@FreeBSD.org> <4F51BDDA.3020602@hm.net.br> Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 Mar 2012 09:25:46 -0700 Message-ID: <1330791946.10695.51.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 16:25:55 -0000 On Sat, 2012-03-03 at 03:44 -0300, H wrote: > Doug Barton wrote: > > Just looking at the committers, of which we have over 300, only a > > couple dozen at most have ever identified as actually using FreeBSD as > > a desktop at my count. Taking the larger development community into > > account I think the numbers are a little better, but not much. Sure, > > our strength is servers, and that is not going to change. > eventually that could be a good starting point, good question is, why not? > > > But how many real-life bugs have I personally uncovered in -current as > > a result of actually running it (mostly) daily? I'm not the only one, > > certainly, but if the numbers were flipped and the vast majority of > > our developers *did* use FreeBSD routinely, how much better off would > > we be? > again, why? > > let's face some reality. Forever installing FreeBSD Desktop, either KDE > or Gnome, was a nightmare process, or better, to make it appear on > screen was a nightmare. > > Even if somebody got all packages into his system (by miracle?), it > still did not popped up. Without some special knowledge _no_chance_. > > who knows, the guys who created and battled on area51 knew why they > chose this name :) > > Still now, kde4, hours of install, missing packages, compiling and still > nothing, somewhere over the process, flies over the screen please set > kdm4_enable="YES" ... I guess that will not be noticed by any user > > Even if some smart guy figures out that he needs xorg-server, the port > or package do not select all it needs for running, its own drivers and > so. How a user should know that? There is a windeco which installs > hundreds of deps, even sound what do not work on FreeBSD, but xorg do > not have deps for its functionality? goooood ... ohhh I forgot, that has > nothing to do with the desktop itself , sorry for mentioning ... > > Anybody can tell how somebody can find all this out? Don't say by > reading because we need to look at the real facts and that is nobody > want to read, they want a desktop nothing else, something silly and easy > to read email and write docs and surf on the net, listen to a CD, they > need to put a cd into the drive, running install process, reboot, using, > nothing else and such a thing ... we do not have > > so where this potential users should come from? Only from heaven ... > > And before anyone bothers to point it out, yes, I happen to be using > > Windows at this exact moment. I have some layer 9 work to get done and > > I need tools that are only available to me in Windows (more's the > > pity). The sad thing is, judging by the activity on the -ports@ list, > > the traffic in #bsdports, and just talking to/interacting with FreeBSD > > users, a lot of *them* are not only interested in FreeBSD as a desktop > > OS, they are actually doing it. > > IMO the weakest point is that we do not have the packages ready. > > Even if lots of you do not like it to hear, fact is that we must look > around and see how others do it. Windows, whatever it is, it is easy to > install for everybody. > > Same for Fedora, in order to stay with a Unix system, package handling, > update with YUM on Fedora hardly fails. > > ALL packages are compiled, you never need to compile anything. Even if > you need 800MB of packages, yum picks them all, installs them all, and > all is fine up top date. Such a process is where we need to get > orientation from. > > If it was my decision, it should be go to ports=no_no, packages=YES > > I mean, as long as the packages are not complete and ready, no new port > version should be released or announced > > So who dares,understand and can or like adventures, compiles from ports > > Such a decision would help FreeBSD in all means and would help the users > as well, in any case it will create more users > > Why somebody should chose FreeBSD as his daily desktop, oh man, only > some die-hard-guys like you and me, but you know, that is not hours of > work, that is days, weeks and constant setbacks for whatever reasons ... > that is not for anybody. And you are right, no traffic on the specific > lists, why? because the three on the list, two can help themselves (you > and me) and the other is the moderator ... :) not even the port > maintainer/packager is on that list ... :) > > ps. the last statement might be exaggerated and might not be valid in > all cases, so please do not shoot > > When the announcement of the 8.3-BETA1 release was made on these lists I had just finished building a new machine to become my everyday desktop machine for code development. I figured I should download and install using the new beta to help test the release. I was disappointed to find that the packages weren't on the beta dvd ISO, so the test wasn't as complete as I was hoping in terms of being similar to what a new user would experience. I ran through the sysinstall process without any glitches and rebooted to a working text-mode system. Then I did, from my notes: pkg_add -r for the following: sudo rsync xorg-server xorg-drivers gnome2 nautilus-open-terminal firefox libreoffice emacs subversion mercurial There wasn't a single hitch during any of that. I did eventually discover that I had to enable the snd_hda driver to eliminate spewage of warning messages in the log from pulseaudio. This is annoying, but I had exactly the same problem with Fedora a couple years ago when I was using it as a desktop (it's okay to assume that most desktop users want better sound than a 1982-style beep; it's rude to require it). Assuming that the usual packages will be on the final release image, I'd have to say that anyone can successfully install and configure FreeBSD as a desktop machine without being a power user. It all just works, at least for 8.3. That hasn't always been the case in the past, and if you need to update a specific component or two after initial install I think it is likely to be way harder in FreeBSD with ports and packages than it is in a distro such as Fedora that uses yum. So turning brand new virgin hardware into a usable desktop system for everyday code development using a recent release from a mature branch took a couple hours (mostly package download time) and a handful of commands. On a non-beta release I think the time would have been much shorter, and the commands would have been reduced to checking a few boxes in the package browser part of sysinstall. I'm not sure whether it would go so well on 9.0, but it isn't yet a mature branch -- IMO, if you want to live on the leading edge you should expect to do a bit more work. I would expect that by time 9.1 comes out the process should be about as smooth as it was for 8.3. -- Ian From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 16:37:30 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 15536106564A for ; Sat, 3 Mar 2012 16:37:30 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 6CD498FC0C for ; Sat, 3 Mar 2012 16:37:28 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 41AEC1DD5B9; Sat, 3 Mar 2012 17:37:27 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 1A42B28470; Sat, 3 Mar 2012 17:37:27 +0100 (CET) Date: Sat, 3 Mar 2012 17:37:27 +0100 From: Jilles Tjoelker To: Willem Jan Withagen Message-ID: <20120303163726.GA21464@stack.nl> References: <201202250747.q1P7ldaJ005410@zfs.digiware.nl> <4F4A3639.2080408@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F4A3639.2080408@digiware.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "stable@freebsd.org" Subject: Re: A problem with MAXPATHLEN on a back X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 16:37:30 -0000 On Sun, Feb 26, 2012 at 02:40:09PM +0100, Willem Jan Withagen wrote: > I'm running into this on a backup-backupserver. > (8.2-STABLE #134: Wed Feb 1 15:05:59 CET 2012 amd64) > Haven't checked which paths are too long. > But is there any "easy" way out? Like making MAXPATHLEN 2048 and > rebuilding locate. > Or is that going to propagate and major impact all and everything. > Rebuilding locate database: > locate: integer out of +-MAXPATHLEN (1024): 1031 > locate: integer out of +-MAXPATHLEN (1024): 1031 It should be possible to replace (sed -i) MAXPATHLEN with something else in the locate source and recompile it. Changing the value of MAXPATHLEN itself is not safe because it defines the size of various buffers in the ABI (such as the one passed to realpath() if its resolved_path parameter is not NULL); in any case, it is a very intrusive change. Locate uses find(1) to generate its list of files, and find's output is not subject to MAXPATHLEN (unless the -L option or the -follow primary is used). Almost any use of the very long pathnames will require a manual split-up though (cd'ing to an initial part shorter than MAXPATHLEN, then repeating the process with relative pathnames until the remaining part is shorter than MAXPATHLEN). -- Jilles Tjoelker From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 16:40:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C73DC1065673 for ; Sat, 3 Mar 2012 16:40:04 +0000 (UTC) (envelope-from hm@hm.net.br) Received: from msrv.matik.com.br (msrv.matik.com.br [187.95.0.181]) by mx1.freebsd.org (Postfix) with ESMTP id D535A8FC13 for ; Sat, 3 Mar 2012 16:40:03 +0000 (UTC) Received: from pop1.hm.net.br (pop1.hm.net.br [186.222.215.103]) by msrv.matik.com.br (8.14.5/8.14.5) with ESMTP id q23Gdf0a007631; Sat, 3 Mar 2012 13:39:42 -0300 (BRT) (envelope-from hm@hm.net.br) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at msrv.matik.com.br X-DKIM: OpenDKIM Filter v2.4.3 msrv.matik.com.br q23Gdf0a007631 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hm.net.br; s=racoon; t=1330792787; bh=nwKin6JZcCmgUx4w3I1JPALFZIl6Z/P84L06hIVQKMU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=n9IdBSjofVUMKyRWAlP5b3Z2OW2lBtINELb3P2xvbugbjO2Vud+yNVoXWwWcT0GH2 UpT0dd63pGnR6dhHp+8eFa0rCAWHClIvVwuzPxdXJl+Z/UBTnBXE9pTiLQg4T9egZg WDjh3p3DgE6shX7EwuCmAN02popUtbcCE63PvLOg= Authentication-Results: msrv.matik.com.br; sender-id=pass header.from=hm@hm.net.br; spf=pass smtp.mfrom=hm@hm.net.br Message-ID: <4F524946.70207@hm.net.br> Date: Sat, 03 Mar 2012 13:39:34 -0300 From: H User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Firefox/10.0.2 SeaMonkey/2.7.2 MIME-Version: 1.0 To: "O. Hartmann" References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F513B2D.6010809@FreeBSD.org> <4F5148A7.4080408@FreeBSD.org> <4F51BDDA.3020602@hm.net.br> <4F5202F0.1020205@zedat.fu-berlin.de> In-Reply-To: <4F5202F0.1020205@zedat.fu-berlin.de> X-Enigmail-Version: 1.3.5 OpenPGP: id=9C63083C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDE190687B30633AAA80CC29C" X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL, BAYES_00, J_CHICKENPOX_83, T_DKIM_INVALID, T_RP_MATCHES_RCVD autolearn=no version=3.3.2-hm_201202.c X-Spam-Checker-Version: SpamAssassin 3.3.2-hm_201202.c (2011-06-06) on msrv.matik.com.br Cc: freebsd-stable@freebsd.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 16:40:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDE190687B30633AAA80CC29C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable O. Hartmann wrote: > Maybe the logic behind the dependency system need a refurbish? I feel > lost when trying to look into the vast number of of *.mk files and > having to figure out myself how they get involved when building some > essential ports. Each "tweak" seems to go into those files undocumented= > and the logical hierarchy isn't obvious, since many dependencies are > hidden in GNOME/KDE related files. it is kind of hard discussing logic here, certainly we are coming to the end of the natural thermodynamics chain, expansion=3D>chaos=3D>order whic= h also is a logic, letting the things in hand of natural orders is no good, too slow in first place, too many victims in second so eventually we use algebra and separate stuff, so what do we have? Base System Ports Packages so now comes a logic question before anything else target is what? more users how? the base system is pretty good, stable and secure, but this is not enough, to get more users we need other stuff on the table >> > Even if lots of you do not like it to hear, fact is that we must loo= k >> > around and see how others do it. Windows, whatever it is, it is easy= to >> > install for everybody. > Well, this is right. But do not forget that even those fancy and easy t= o > use installation framework hide a lot of the underlying system's > hierarchy and logic. Look at all the Linux systems, trying to get on pa= r > with Windows. How long did they raped Linux to get it that way looking?= of course, but we do not fear work at the end they looked for the target's needs and understood that that is the only point what matters for success >> > If it was my decision, it should be go to ports=3Dno_no, packages=3D= YES > In such a case, there would be no reason anymore to use FreeBSD! I want= > to use the system as fast as possible on desktop, so binary packages > should be all right. But on servers, I'd like to squeeze out the last > nanosecond I can grab by using dedicated compiler options. So I wnt to > have the choise! My freedom, my responsibility and also the freedom to slow slow with the young horses ... that is not what I said or meant first my saying is for/from user perspective, repeating, cd into the drive, install, boot, ready to go, without fiddling around - that is one and perhaps the only straight possibility to reach and get more users= you are not a common user, of course ports will stay alive for whom likes, needs or want it > decide for my own how much "brain" I want to invest into understanding > my OS - or even not. At this very point, I "can", up to a certain point= , > decide how much time I want to spend on understanding. Others "can not"= , > by natural selection, they need to be stuck with binaries. or they exactly >> >=20 >> > I mean, as long as the packages are not complete and ready, no new p= ort >> > version should be released or announced > Why not? How should the "free" open source community then ever help to > debug? I guess what you think about is to have a more strict > "RELEASE/STABLE/CURRENT/ based policy also for the ports system? I woul= d > agree. again recalling, user perspective and no, complete is the keyword before announcing an available upgrade, all necessary packages should be ready so that the common user do not get caught in some compiling process= >> >=20 >> > So who dares,understand and can or like adventures, compiles from po= rts > It is not simple as that. The "logic" starts at the compiler's point. > GCC 4.2.1 isn't an option in many cases, CLANG unsuitable (openMP). well, right or wrong, that is then issue for whom likes to compile, we do not speak about it because that is what we have, but that is not good for the users, still less for getting more users > On the other hand, who should provide all the binary coverage? As you > could see, the user domain of FreeBSD is shrinking. And even my the maintainer/packager today we are with some kind of mess because there are no rules today nobody cares because the actual FreeBSD horde is completely or almost composed of developers or insiders or programmers or lovers, so why making packages? No one requires them developers have other interests as users have >> >=20 >> > Such a decision would help FreeBSD in all means and would help the u= sers >> > as well, in any case it will create more users > Yes, well said, but a bit false. World has changed since the last 50 > years, politically. Monolithic capitalism with a herd of dumb, mean > animals only want to "touch and use". Monolithic socialism creates mean= don't be so harsh on people because it is the constructor who builds your house but he wants to read email and surf the net ... for that he certainly do not need to learn to compile or read Makefiles, but of course, he tells his wife how stupid this nerd is which do not know the name of the wood he uses :) so let skip this part >> >=20 >> > Why somebody should chose FreeBSD as his daily desktop, oh man, only= >> > some die-hard-guys like you and me, but you know, that is not hours = of >> > work, that is days, weeks and constant setbacks for whatever reasons= ... >> > that is not for anybody. And you are right, no traffic on the specif= ic >> > lists, why? because the three on the list, two can help themselves (= you >> > and me) and the other is the moderator ... :) not even the port >> > maintainer/packager is on that list ... :) >> >=20 > Well, these days dying on FreeBSD is much quicker than years before - i= n > my special case. in any case :) > Linux is faster in (our) network. Linux response faster in (our) NFSv4 > (environment). Linux has a better scalability (NUMA awareness seems to > be better on our 2-socket servers). Linux adopt faster new architecture= s well, if or not, it's another case, developer level case > due to a better maintaining of the necessary compiler(s). And I'm going= > to face another development that will let FreeBSD die faster in certain= > scientific areas (were the BSD has been born!). This is mainly due to > the lack of the support of modern GPGPU stuff. I'm forced to replace > several FreeBSD servers now by Suse Linux machines. Reason: GPGPU. We > can use OpenCL/CUDA on the TESLA boards we obtained, we can use > OpenCL/CUDA on the desktop boxes equipted with expensive and fast GPU > hardware (and we do this very intensive now). We modell, simulate and > optimize on GPGPU code developed by scientists in our depeartment, base= d > on OpenCL. > Since we are also dependend on funding from the government (we have to > present so called "PR products" which include scientifically prepared > and rendered products of solar system objects like Mars or the Saturnia= n > icy moons), we need to build up a "render cluster", which we do with a > well known open source rendering software which has now GPGPU support. > Even on "out of the box server Linux" this can not be performed "out of= > the box" and need "die hard" people. But they do not die hard on FBSD > anymore. > yooo, certainly you say it all, all this communication devices (space ships) are difficult to build and have some dependencies still more difficult, but nobody cares but the building staff and it's sponsor and some other crazy people the normal guy do not even assist anymore the launch and change to the MMA channel and he buys a firework-rocket, lit a match and blows it into the sky ... he do not care and do not need to know how it works, he only needs it to work, and now, when it fails, he does what? takes another one ... --=20 H --------------enigDE190687B30633AAA80CC29C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9SSUcACgkQvKVfg5xjCDyFDACeJHD/8cmNXhwkQNhA9wwB1DIZ C58An2q2zEVLivLcGJNaNT0OKx+1rKwa =9k2i -----END PGP SIGNATURE----- --------------enigDE190687B30633AAA80CC29C-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 16:56:37 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C5F4106564A for ; Sat, 3 Mar 2012 16:56:37 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 2B89F8FC20 for ; Sat, 3 Mar 2012 16:56:36 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta07.emeryville.ca.mail.comcast.net with comcast id h4vq1i0020FhH24A74wWWV; Sat, 03 Mar 2012 16:56:30 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta08.emeryville.ca.mail.comcast.net with comcast id h4wV1i01c4NgCEG8U4wWws; Sat, 03 Mar 2012 16:56:30 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q23GuSEF011743; Sat, 3 Mar 2012 09:56:28 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: perryh@pluto.rain.com In-Reply-To: <4f525035.FeXsLHWGEs0tQIdS%perryh@pluto.rain.com> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F513B2D.6010809@FreeBSD.org> <4F5148A7.4080408@FreeBSD.org> <4F51BDDA.3020602@hm.net.br> <4f525035.FeXsLHWGEs0tQIdS%perryh@pluto.rain.com> Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 Mar 2012 09:56:28 -0700 Message-ID: <1330793788.10695.60.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 16:56:37 -0000 On Sat, 2012-03-03 at 09:09 -0800, perryh@pluto.rain.com wrote: > H wrote: > > > ... Forever installing FreeBSD Desktop, either KDE or Gnome, > > was a nightmare process, or better, to make it appear on screen > > was a nightmare. > > I have never understood the point of KDE or Gnome, other than > (perhaps) as eye candy for the uninitiated. If I wanted a > Windows desktop, I would install Windows. If I wanted a Mac > desktop, I would use a Mac. I've been getting paid to develop software since 1975 -- I'm hardly what you would call "the uninitiated." I couldn't imagine working without a fully functional desktop environment. Look at a calendar, it's 2012. Maybe you long for a return to punch cards and fanfold greenbar paper, but I'm not going back there. It's exactly because I don't want a Windows or Mac desktop that I use gnome. (I used to be a Mac user, starting in the 80s, but Apple lost their way during their struggle to survive 10 years ago. Soon you won't be able to boot a Mac without an account at the iTunes store, and my last Mac will go into the e-cycle pile at that point.) -- Ian From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 17:06:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42DAA106564A for ; Sat, 3 Mar 2012 17:06:22 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0173E8FC17 for ; Sat, 3 Mar 2012 17:06:21 +0000 (UTC) Received: by iahk25 with SMTP id k25so4873099iah.13 for ; Sat, 03 Mar 2012 09:06:21 -0800 (PST) Received-SPF: pass (google.com: domain of kmacybsd@gmail.com designates 10.42.29.70 as permitted sender) client-ip=10.42.29.70; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kmacybsd@gmail.com designates 10.42.29.70 as permitted sender) smtp.mail=kmacybsd@gmail.com; dkim=pass header.i=kmacybsd@gmail.com Received: from mr.google.com ([10.42.29.70]) by 10.42.29.70 with SMTP id q6mr9693283icc.22.1330794381604 (num_hops = 1); Sat, 03 Mar 2012 09:06:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=N7SJ+M/yXwXNlS+BPsNEUVsVLGsORalhNaGXhM2pRy0=; b=Iw1GZOSs+LK1zpmYRsl/f9R0nCmJfNPPViclJb74ivw3wQ7upA/AjtMbcE4VvxRAZY n58DNilmqbZQSs6uYOB5WaucIqjZEBSAsoGKy2qsqyzYSyWxF+MoDoZTjfiQcxXPZme0 H3p8Uc96HwYSjvSXZkg2qYUKe0nvy6rieQ7eb9xfFfiNI2q/9BlqOqHE1pxpmux4nQ/u Ft3Rj5kdoeTUZ1WMZl80rrbUg/BqdAZz5CrVYnERItya0FVtyXNWRmi9+whM9U4ZDISj jUhIduKgmhie6yLxVejuHL9FlX4KCPEvbH9UZjJsWO86gnZcvbOuXPCzVasfyJ2POYj9 CeFA== MIME-Version: 1.0 Received: by 10.42.29.70 with SMTP id q6mr7984159icc.22.1330793902329; Sat, 03 Mar 2012 08:58:22 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.50.134.106 with HTTP; Sat, 3 Mar 2012 08:58:22 -0800 (PST) Date: Sat, 3 Mar 2012 17:58:22 +0100 X-Google-Sender-Auth: v7ReA_KcgrD8lzngrlgdLu9mYfI Message-ID: From: "K. Macy" To: FreeBSD Stable , FreeBSD Current Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Subject: Request for flowtable testers and actionable feedback RE: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 17:06:22 -0000 I'm re-sending this portion of another mail as it will inevitably not be read by most readers by virtue of having been part of a long and digressive thread. subject line: "flowtable usable or not" It is possible to re-structure the routing code to have a smaller cache footprint / shorter lookup time / and eliminate all locking in the packet transmit path (ip_output, ip_forward). However, it would take more time and effort than I have to do so as a recreational activity. The set of people able to fund such an effort is non-intersecting with the set of people who would benefit the most heavily from it. Hence, for the time being, for those who want to be able to approach anywhere near 1Mpps, much less 10 or 15 times that, whilst continuing to use the regular stack (i.e. not running netmap) we are left only with flowtable for bypassing the locking and compute overhead of per-packet route lookups. It is beyond debate that under some, if not many, circumstances flowtable was unusable and perhaps continues to be. Hence, any further reports of "it was broken so I turned it off, and now my life is better" should be left unsent. If you, the reader, are willing to contribute to the testing of changes, provide backtraces from cores etc. please follow up. Thank you for your support. Cheers, Kip -- =A0 =A0=93The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don=92t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won=92t take measure of their own strength, for fear of antagonizing their own weakness. Those who don=92t like to make waves=97or enemies. =A0 =A0Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It=92s the reductionist approach to life: if you keep it small, you=92ll keep it under control. If you don=92t make any noise, the bogeyman won=92t find you. =A0 =A0But it=92s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! >From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. =A0 =A0I choose my own way to burn.=94 =A0 =A0Sophie Scholl From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 17:22:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 943F1106566B; Sat, 3 Mar 2012 17:22:10 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 34C208FC0A; Sat, 3 Mar 2012 17:22:09 +0000 (UTC) Received: by iahk25 with SMTP id k25so4890080iah.13 for ; Sat, 03 Mar 2012 09:22:09 -0800 (PST) Received-SPF: pass (google.com: domain of kmacybsd@gmail.com designates 10.50.186.230 as permitted sender) client-ip=10.50.186.230; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kmacybsd@gmail.com designates 10.50.186.230 as permitted sender) smtp.mail=kmacybsd@gmail.com; dkim=pass header.i=kmacybsd@gmail.com Received: from mr.google.com ([10.50.186.230]) by 10.50.186.230 with SMTP id fn6mr2160451igc.30.1330795329574 (num_hops = 1); Sat, 03 Mar 2012 09:22:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vCinLuJi0LGWq7wZX2WSwRmZ1YPQpk1UuRZ9XZJ1M88=; b=Dm65CIwegWbiMG/whZ9rlVl1xT7on3hjyvrdlGxWnBazU4moc8ivDk0vVZIGr1IqJO yN03ZorVM+M5wdiDE6P6XtBwm9D8suDafKWAbl71ebuTTAx7wKSe8YwkXLglJOIz50jB GhEyXbCTvGbOeTqIUuNXWRXOPdUswz1EZg0CLQbYZFXBRYNcHGHaC9JqWHhWTRKFdOmH +O8HEG/yK3Q50N4+IglrTj/W74UL2ZF3VZnz1KDvPMSdc2BKs0jF5ZnGZugoq0Qgfbs9 feLTcZN/MermyoNbwQWmJz9rEpq+9eWx+KGkl8IpKNcC0rqXOLOsF+nVSInBxBXvkhQE P0sQ== MIME-Version: 1.0 Received: by 10.50.186.230 with SMTP id fn6mr1750001igc.30.1330793623206; Sat, 03 Mar 2012 08:53:43 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.50.134.106 with HTTP; Sat, 3 Mar 2012 08:53:43 -0800 (PST) In-Reply-To: References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F51BEE0.7090108@freebsd.org> Date: Sat, 3 Mar 2012 17:53:43 +0100 X-Google-Sender-Auth: 9d-IF_K-7ujGQLIfVF4DjiYk45o Message-ID: From: "K. Macy" To: Garrett Cooper Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Doug Barton , FreeBSD Stable , =?ISO-8859-2?Q?z_W=B1sikowski?= , FreeBSD Current , Arnaud Lacombe , "Bjoern A. Zeeb" , Alexander Leidinger , Julian Elischer Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 17:22:10 -0000 > Less effort is required to get greater profit without having to mess > around with things because they fit the generic case as opposed to a > number of niche cases or provide OS features that a user may or may > not use. My initial venting of my frustrations at Doug appears to have turned an open-ended discussion of FreeBSD's merits as a desktop vs. a server OS. I don't have the inclination to read every response closely, but I think that it is generating more heat than light. I have three points that I would like to make before I attempt to transition this thread back to its initial purpose: a) We as a members of the community are collectively responsible for the state of FreeBSD. Simply disabling features or removing functionality that doesn't work or doesn't work optimally and / or filing bug reports but not being able or willing to respond to feedback requests is in essence a form of neglect. Although we all have day to day obligations for which the use of FreeBSD is extremely impractical if not impossible ... any progress, any improvements, any advancements will only happen because *we* made it happen. b) There are many features and many changes that are introduced in to FreeBSD which extend the potential user base which are of no obvious benefit to many users. Just because one doesn't need a feature and doesn't hear users crying out for it, doesn't mean that it isn't important. c) My grievance was in no way with Doug Barton or ports per se, but with his response as a representative instance of a behaviour which bothers me, and, taken over time, is detrimental to the whole. Back to the initial subject line: "flowtable usable or not" It is possible to re-structure the routing code to have a smaller cache footprint / shorter lookup time / and eliminate all locking in the packet transmit path (ip_output, ip_forward). However, it would take more time and effort than I have to do so as a recreational activity. The set of people able to fund such an effort is non-intersecting with the set of people who would benefit the most heavily from it. Hence, for the time being, for those who want to be able to approach anywhere near 1Mpps, much less 10 or 15 times that, whilst continuing to use the regular stack (i.e. not running netmap) we are left only with flowtable for bypassing the locking and compute overhead of per-packet route lookups. It is beyond debate that under some, if not many, circumstances flowtable was unusable and perhaps continues to be. Hence, any further reports of "it was broken so I turned it off, and now my life is better" should be left unsent. If you, the reader, are willing to contribute to the testing of changes, provide backtraces from cores etc. please follow up. Thank you for your support. Cheers, Kip --=20 =A0 =A0=93The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don=92t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won=92t take measure of their own strength, for fear of antagonizing their own weakness. Those who don=92t like to make waves=97or enemies. =A0 =A0Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It=92s the reductionist approach to life: if you keep it small, you=92ll keep it under control. If you don=92t make any noise, the bogeyman won=92t find you. =A0 =A0But it=92s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! >From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. =A0 =A0I choose my own way to burn.=94 =A0 =A0Sophie Scholl From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 17:54:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F1C7106564A for ; Sat, 3 Mar 2012 17:54:31 +0000 (UTC) (envelope-from gorshkov.pavel@gmail.com) Received: from imp01.mtu.ru (imp01.mtu.ru [62.5.255.10]) by mx1.freebsd.org (Postfix) with ESMTP id D67ED8FC12 for ; Sat, 3 Mar 2012 17:54:30 +0000 (UTC) Received: from localhost.my.domain ([91.79.81.93]) by imp01.mtu.ru with bizsmtp id h5uM1i00420oBcz015uNhx; Sat, 03 Mar 2012 21:54:23 +0400 Received: from localhost (localhost [127.0.0.1]) by localhost.my.domain (8.14.5/8.14.5) with ESMTP id q23HsJPQ005077; Sat, 3 Mar 2012 21:54:20 +0400 (MSK) (envelope-from gorshkov.pavel@gmail.com) Date: Sat, 3 Mar 2012 21:54:19 +0400 From: Pavel Gorshkov To: YongHyeon PYUN Message-ID: <20120303175419.GA4959@localhost> References: <20120228210329.GA2741@localhost> <20120302012955.GC1685@michelle.cdnetworks.com> <20120301211356.GA2603@localhost> <20120302180554.GA1632@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120302180554.GA1632@michelle.cdnetworks.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: msk0: interrupt storm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 17:54:31 -0000 On Fri, Mar 02, 2012 at 10:05:54AM -0800, YongHyeon PYUN wrote: > Still have no idea. Would you post dmesg output? Sure, just let me know if you need anything else. Now running with hw.msk.msi_disable=1 hw.msk.jumbo_disable=1 still getting the storms, the above settings just seem to make them less severe/often. > If you know how to reproduce the issue, let me know. Any network activity will do, sometimes even just fetching new mail from pop.gmail.com via POP3 over SSL. So here's the dmesg as well as some other relevant bits: $ vmstat -i interrupt total rate irq9: acpi0 81 0 irq16: mskc0 uhci0 4419739 456 irq17: cbb0 fwohci+ 6085 0 irq18: uhci2 ehci0+ 2 0 irq20: hpet0 4333544 447 irq23: uhci3 ehci1 32 0 irq257: hdac0 1 0 irq258: hdac1 36 0 irq260: ahci0 169843 17 Total 8929363 921 ### currently configured with -rxcsum, ### but it doesn't seem to make any difference $ ifconfig msk0 msk0: flags=8843 metric 0 mtu 1500 options=c011a ether 00:17:42:c8:2a:2f inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::217:42ff:fec8:2a2f%msk0 prefixlen 64 scopeid 0x5 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active $ dmesg Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz (2261.05-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfebfbff Features2=0x8e3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 3221225472 (3072 MB) avail memory = 3068252160 (2926 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x2000-0x20ff mem 0xf0000000-0xf7ffffff,0xfa000000-0xfa00ffff irq 16 at device 0.0 on pci1 drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) info: [drm] Initialized radeon 1.31.0 20080613 hdac0: mem 0xfa010000-0xfa013fff irq 17 at device 0.1 on pci1 uhci0: port 0x1800-0x181f irq 16 at device 26.0 on pci0 usbus0: on uhci0 uhci1: port 0x1820-0x183f irq 17 at device 26.1 on pci0 usbus1: on uhci1 uhci2: port 0x1840-0x185f irq 18 at device 26.2 on pci0 usbus2: on uhci2 ehci0: mem 0xfa704800-0xfa704bff irq 18 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3: on ehci0 hdac1: mem 0xfa700000-0xfa703fff irq 22 at device 27.0 on pci0 pcib2: irq 17 at device 28.0 on pci0 pci8: on pcib2 mskc0: port 0x3000-0x30ff mem 0xfa100000-0xfa103fff irq 16 at device 0.0 on pci8 msk0: on mskc0 msk0: disabling jumbo frame support msk0: Ethernet address: 00:17:42:c8:2a:2f miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow pcib3: irq 16 at device 28.1 on pci0 pci16: on pcib3 pcib4: irq 18 at device 28.2 on pci0 pci24: on pcib4 iwn0: mem 0xfa200000-0xfa201fff irq 18 at device 0.0 on pci24 pcib5: irq 19 at device 28.3 on pci0 pci32: on pcib5 pci32: at device 0.0 (no driver attached) uhci3: port 0x1860-0x187f irq 23 at device 29.0 on pci0 usbus4: on uhci3 uhci4: port 0x1880-0x189f irq 19 at device 29.1 on pci0 usbus5: on uhci4 uhci5: port 0x18a0-0x18bf irq 18 at device 29.2 on pci0 usbus6: on uhci5 ehci1: mem 0xfa704c00-0xfa704fff irq 23 at device 29.7 on pci0 usbus7: EHCI version 1.0 usbus7: on ehci1 pcib6: at device 30.0 on pci0 pci56: on pcib6 cbb0: irq 17 at device 3.0 on pci56 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pci56: at device 3.2 (no driver attached) pci56: at device 3.3 (no driver attached) fwohci0: <1394 Open Host Controller Interface> mem 0xfa401000-0xfa401fff,0xfa402000-0xfa4027ff irq 17 at device 3.4 on pci56 fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:00:0e:10:03:fe:19:d3 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:0e:fe:19:d3 fwe0: Ethernet address: 02:00:0e:fe:19:d3 fwip0: on firewire0 fwip0: Firewire address: 00:00:0e:10:03:fe:19:d3 @ 0xfffe00000000, S400, maxrec 2048 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xbf05c000 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x18f0-0x18f7,0x18e4-0x18e7,0x18e8-0x18ef,0x18e0-0x18e3,0x18c0-0x18df mem 0xfa704000-0xfa7047ff irq 19 at device 31.2 on pci0 ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 5 on ahci0 pci0: at device 31.3 (no driver attached) acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version 5 ZFS storage pool version 28 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 hdac0: HDA Codec #0: ATI R6xx HDMI pcm0: at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: Realtek ALC269 pcm1: at cad 0 nid 1 on hdac1 pcm2: at cad 0 nid 1 on hdac1 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #1 Launched! uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Root mount waiting for: usbus7 usbus3 ugen7.2: at usbus7 Trying to mount root from zfs:zroot []... ugen0.2: at usbus0 ums0: on usbus0 ums0: 5 buttons and [XYZT] coordinates ID=0 ugen1.2: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 uhid0: on usbus1 msk0: link state changed to UP info: [drm] Setting GART location based on new memory map info: [drm] Loading RV620 Microcode info: [drm] Resetting GPU info: [drm] writeback test succeeded in 1 usecs interrupt storm detected on "irq16:"; throttling interrupt source interrupt storm detected on "irq16:"; throttling interrupt source interrupt storm detected on "irq16:"; throttling interrupt source interrupt storm detected on "irq16:"; throttling interrupt source interrupt storm detected on "irq16:"; throttling interrupt source interrupt storm detected on "irq16:"; throttling interrupt source interrupt storm detected on "irq16:"; throttling interrupt source interrupt storm detected on "irq16:"; throttling interrupt source interrupt storm detected on "irq16:"; throttling interrupt source interrupt storm detected on "irq16:"; throttling interrupt source interrupt storm detected on "irq16:"; throttling interrupt source From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 19:08:47 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49EAC106564A for ; Sat, 3 Mar 2012 19:08:47 +0000 (UTC) (envelope-from jfb@mr-happy.com) Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [IPv6:2001:470:b:28:f::1]) by mx1.freebsd.org (Postfix) with ESMTP id F341A8FC08 for ; Sat, 3 Mar 2012 19:08:46 +0000 (UTC) Received: from crow.mr-happy.com (crow-vpn.mr-happy.com [10.1.0.2]) by vexbert.mr-paradox.net (Postfix) with ESMTP id 0077984631 for ; Sat, 3 Mar 2012 14:08:45 -0500 (EST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96 at vexbert.mr-paradox.net Received: by crow.mr-happy.com (Postfix, from userid 16139) id 48B33A073; Sat, 3 Mar 2012 14:08:45 -0500 (EST) Date: Sat, 3 Mar 2012 14:08:45 -0500 From: Jeff Blank To: freebsd-stable@freebsd.org Message-ID: <20120303190845.GA2244@mr-happy.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline X-Face: #0jV*~a}VtKS-&E/!EJpH('H1Va}24dxF0oT&+.R3Gu8C; xhSC+<|+H84&YLbMvphuRT4cp3.|8EN_(2Eix/6{.Up~u`a^}0Ln&b+9Fw|BPig@-{y\pL_46d&ZwA]5%_AU?}DezfE&1!>H?3E$!Yve7.O<+..Jnb4:'6Ey_]FtFzU9=*l$1p/@gA,Ze>^5<]+r(XJ+m7`/vMDc$'wy|`e Subject: missing disk device under 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 19:08:47 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I attempted an upgrade last night from an old 8-STABLE (25 Apr 2011) to 9-STABLE and ran into a problem where a disk apparently wasn't detected. I'm of course aware of the ATA/CAM changes, but I haven't found anything that quite explains what's happening here. I've attached dmesg output from the 8-STABLE and 9-STABLE kernels as well as the results of 'ls -l /dev/ad*' and 'zpool status' under both kernels. ZFS seems to have figured out what to do about its ad4p3 member (switching to a gptid device), but since only ada0 is detected during boot, it can't complete the pool. The weird thing is, though, that the other disk was actually detected on one reboot to the 9.0 kernel, ZFS was happy, etc. I haven't been able to reproduce it, though. Due to these problems, I haven't upgraded userland yet and am of course sticking with the 8-STABLE kernel, but I can boot into the 9-STABLE kernel at will if anyone needs more information. Thanks for any help, Jeff --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="disk-8.txt" pool: z0 state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM z0 ONLINE 0 0 0 mirror ONLINE 0 0 0 ad4p3 ONLINE 0 0 0 ad6p3 ONLINE 0 0 0 errors: No known data errors --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="disk-9.txt" # ls -l /dev/ad* lrwxr-xr-x 1 root wheel 4 Mar 3 13:36 /dev/ad4 -> ada0 lrwxr-xr-x 1 root wheel 6 Mar 3 13:36 /dev/ad4p1 -> ada0p1 lrwxr-xr-x 1 root wheel 6 Mar 3 13:36 /dev/ad4p2 -> ada0p2 lrwxr-xr-x 1 root wheel 6 Mar 3 13:36 /dev/ad4p3 -> ada0p3 crw-r----- 1 root operator 0, 118 Mar 3 13:36 /dev/ada0 crw-r----- 1 root operator 0, 120 Mar 3 13:36 /dev/ada0p1 crw-r----- 1 root operator 0, 122 Mar 3 13:36 /dev/ada0p2 crw-r----- 1 root operator 0, 124 Mar 3 13:36 /dev/ada0p3 # zpool status pool: z0 state: DEGRADED status: One or more devices could not be opened. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-2Q scrub: none requested config: NAME STATE READ WRITE CKSUM z0 DEGRADED 0 0 0 mirror DEGRADED 0 0 0 gptid/96a50b26-9de7-11de-9693-00261882fc65 ONLINE 0 0 0 ad6p3 UNAVAIL 0 0 0 cannot open errors: No known data errors --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg-8.txt" Copyright (c) 1992-2011 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.2-STABLE #0 r221047: Mon Apr 25 23:03:11 EDT 2011 root@crow.mr-happy.com:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Phenom(tm) II X4 965 Processor (3411.64-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Family = 10 Model = 4 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 7980056576 (7610 MB) ACPI APIC Table: <060509 APIC1006> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20101013/tbfadt-655) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <060509 RSDT1006> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of ffb80000, 80000 (3) failed acpi0: reservation of fec10000, 20 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cfe00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xa000-0xa0ff mem 0xd0000000-0xdfffffff,0xfbbe0000-0xfbbeffff,0xfba00000-0xfbafffff irq 18 at device 5.0 on pci1 hdac0: mem 0xfbbfc000-0xfbbfffff irq 19 at device 5.1 on pci1 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pcib2: irq 16 at device 4.0 on pci0 pci2: on pcib2 em0: port 0xbc00-0xbc1f mem 0xfbce0000-0xfbcfffff,0xfbc00000-0xfbc7ffff,0xfbcdc000-0xfbcdffff irq 16 at device 0.0 on pci2 em0: Using MSIX interrupts with 3 vectors em0: [ITHREAD] em0: [ITHREAD] em0: [ITHREAD] em0: Ethernet address: 00:1b:21:c8:33:6f pcib3: irq 18 at device 6.0 on pci0 pci3: on pcib3 ale0: port 0xcc00-0xcc7f mem 0xfbdc0000-0xfbdfffff irq 18 at device 0.0 on pci3 ale0: 960 Tx FIFO, 1024 Rx FIFO ale0: Using 1 MSI messages. miibus0: on ale0 atphy0: PHY 0 on miibus0 atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ale0: Ethernet address: 00:26:18:82:fc:65 ale0: [FILTER] pcib4: irq 19 at device 7.0 on pci0 pci4: on pcib4 fwohci0: <1394 Open Host Controller Interface> port 0xd800-0xd8ff mem 0xfbeff800-0xfbefffff irq 19 at device 0.0 on pci4 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:1e:8c:00:01:fa:89:92 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:1e:8c:fa:89:92 fwe0: Ethernet address: 02:1e:8c:fa:89:92 fwip0: on firewire0 fwip0: Firewire address: 00:1e:8c:00:01:fa:89:92 @ 0xfffe00000000, S400, maxrec 2048 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x3520000 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode atapci0: port 0x9000-0x9007,0x8000-0x8003,0x7000-0x7007,0x6000-0x6003,0x5000-0x500f mem 0xfb9ffc00-0xfb9fffff irq 22 at device 17.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.10 controller with 4 3Gbps ports, PM supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ohci0: mem 0xfb9fd000-0xfb9fdfff irq 16 at device 18.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfb9fe000-0xfb9fefff irq 16 at device 18.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0xfb9ff800-0xfb9ff8ff irq 17 at device 18.2 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 ohci2: mem 0xfb9fb000-0xfb9fbfff irq 18 at device 19.0 on pci0 ohci2: [ITHREAD] usbus3: on ohci2 ohci3: mem 0xfb9fc000-0xfb9fcfff irq 18 at device 19.1 on pci0 ohci3: [ITHREAD] usbus4: on ohci3 ehci1: mem 0xfb9ff400-0xfb9ff4ff irq 19 at device 19.2 on pci0 ehci1: [ITHREAD] usbus5: EHCI version 1.0 usbus5: on ehci1 pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] hdac1: mem 0xfb9f4000-0xfb9f7fff irq 16 at device 20.2 on pci0 hdac1: HDA Driver Revision: 20100226_0142 hdac1: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib5: at device 20.4 on pci0 pci5: on pcib5 xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xec00-0xec3f irq 20 at device 5.0 on pci5 miibus1: on xl0 nsphy0: PHY 24 on miibus1 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:60:08:cd:b0:71 xl0: [ITHREAD] ohci4: mem 0xfb9fa000-0xfb9fafff irq 18 at device 20.5 on pci0 ohci4: [ITHREAD] usbus6: on ohci4 acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 acpi_hpet1: iomem 0xfed00000-0xfed003ff on acpi0 device_attach: acpi_hpet1 attach returned 12 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] orm0: at iomem 0xcf000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range acpi_throttle0: on cpu0 hwpstate0: on cpu0 ZFS filesystem version 4 ZFS storage pool version 15 Timecounters tick every 1.000 msec vboxdrv: fAsync=0 offMin=0x15a offMax=0x2f8 firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 usbus6: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 acd0: DMA limited to UDMA33, device found non-ATA66 cable acd0: DVDR at ata0-master UDMA33 acd1: DVDR at ata1-master UDMA100 SATA ad4: 715404MB at ata2-master UDMA100 SATA 3Gb/s ad6: 715404MB at ata3-master UDMA100 SATA 3Gb/s hdac0: HDA Codec #0: ATI RS690/780 HDMI pcm0: at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: VIA VT1708S_0 pcm1: at cad 0 nid 1 on hdac1 pcm2: at cad 0 nid 1 on hdac1 pcm3: at cad 0 nid 1 on hdac1 SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! GEOM_MIRROR: Device mirror/swap0 launched (2/2). Root mount waiting for: usbus6 usbus5 usbus4 usbus3 usbus2 usbus1 usbus0 uhub6: 2 ports with 2 removable, self powered uhub1: 3 ports with 3 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub3: 3 ports with 3 removable, self powered uhub4: 3 ports with 3 removable, self powered Root mount waiting for: usbus5 usbus2 Root mount waiting for: usbus5 usbus2 uhub2: 6 ports with 6 removable, self powered uhub5: 6 ports with 6 removable, self powered Root mount waiting for: usbus5 usbus2 ugen5.2: at usbus5 umass0: on usbus5 umass0: SCSI over Bulk-Only; quirks = 0x0000 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 Root mount waiting for: usbus5 (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM status: SCSI Status Error (probe0:ata0:0:0:0): SCSI status: Check Condition (probe0:ata0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) umass0:4:0:-1: Attached to scbus4 (probe1:ata1:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe1:ata1:0:0:0): CAM status: SCSI Status Error (probe1:ata1:0:0:0): SCSI status: Check Condition (probe1:ata1:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not present - tray closed) cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ata1 bus 0 scbus1 target 0 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 100.000MB/s transfers cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed ugen1.2: at usbus1 ums0: on usbus1 ums0: 5 buttons and [XYZ] coordinates ID=0 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present ugen1.3: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 ums1: on usbus1 ums1: 3 buttons and [XYZ] coordinates ID=0 (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 (probe0:umass-sim0:0:0:1): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:1): SCSI status: Check Condition (probe0:umass-sim0:0:0:1): SCSI sense: NOT READY asc:3a,0 (Medium not present) cd2 at umass-sim0 bus 0 scbus4 target 0 lun 1 cd2: Removable CD-ROM SCSI-2 device cd2: 40.000MB/s transfers cd2: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from zfs:z0/root vboxnet0: Ethernet address: 0a:00:27:00:00:00 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg-9.txt" Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-STABLE #0: Sat Mar 3 00:19:06 EST 2012 root@crow.mr-happy.com:/usr/obj/usr/src/sys/GENERIC amd64 CPU: AMD Phenom(tm) II X4 965 Processor (3411.69-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Family = 10 Model = 4 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 7975366656 (7605 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <060509 APIC1006> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20110527/tbfadt-586) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <060509 RSDT1006> on motherboard acpi0: Power Button (fixed) acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of ffb80000, 80000 (3) failed acpi0: reservation of fec10000, 20 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cfe00000 (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 450 Event timer "HPET2" frequency 14318180 Hz quality 450 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xa000-0xa0ff mem 0xd0000000-0xdfffffff,0xfbbe0000-0xfbbeffff,0xfba00000-0xfbafffff irq 18 at device 5.0 on pci1 hdac0: mem 0xfbbfc000-0xfbbfffff irq 19 at device 5.1 on pci1 pcib2: irq 16 at device 4.0 on pci0 pci2: on pcib2 em0: port 0xbc00-0xbc1f mem 0xfbce0000-0xfbcfffff,0xfbc00000-0xfbc7ffff,0xfbcdc000-0xfbcdffff irq 16 at device 0.0 on pci2 em0: Using MSIX interrupts with 3 vectors em0: Ethernet address: 00:1b:21:c8:33:6f pcib3: irq 18 at device 6.0 on pci0 pci3: on pcib3 ale0: port 0xcc00-0xcc7f mem 0xfbdc0000-0xfbdfffff irq 18 at device 0.0 on pci3 ale0: 960 Tx FIFO, 1024 Rx FIFO ale0: Using 1 MSI messages. miibus0: on ale0 atphy0: PHY 0 on miibus0 atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ale0: Ethernet address: 00:26:18:82:fc:65 pcib4: irq 19 at device 7.0 on pci0 pci4: on pcib4 fwohci0: <1394 Open Host Controller Interface> port 0xd800-0xd8ff mem 0xfbeff800-0xfbefffff irq 19 at device 0.0 on pci4 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:1e:8c:00:01:fa:89:92 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:1e:8c:fa:89:92 fwe0: Ethernet address: 02:1e:8c:fa:89:92 fwip0: on firewire0 fwip0: Firewire address: 00:1e:8c:00:01:fa:89:92 @ 0xfffe00000000, S400, maxrec 2048 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x173c000 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode ahci0: port 0x9000-0x9007,0x8000-0x8003,0x7000-0x7007,0x6000-0x6003,0x5000-0x500f mem 0xfb9ffc00-0xfb9fffff irq 22 at device 17.0 on pci0 ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ohci0: mem 0xfb9fd000-0xfb9fdfff irq 16 at device 18.0 on pci0 usbus0: on ohci0 ohci1: mem 0xfb9fe000-0xfb9fefff irq 16 at device 18.1 on pci0 usbus1: on ohci1 ehci0: mem 0xfb9ff800-0xfb9ff8ff irq 17 at device 18.2 on pci0 usbus2: EHCI version 1.0 usbus2: on ehci0 ohci2: mem 0xfb9fb000-0xfb9fbfff irq 18 at device 19.0 on pci0 usbus3: on ohci2 ohci3: mem 0xfb9fc000-0xfb9fcfff irq 18 at device 19.1 on pci0 usbus4: on ohci3 ehci1: mem 0xfb9ff400-0xfb9ff4ff irq 19 at device 19.2 on pci0 usbus5: EHCI version 1.0 usbus5: on ehci1 pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 hdac1: mem 0xfb9f4000-0xfb9f7fff irq 16 at device 20.2 on pci0 isab0: at device 20.3 on pci0 isa0: on isab0 pcib5: at device 20.4 on pci0 pci5: on pcib5 xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xec00-0xec3f irq 20 at device 5.0 on pci5 miibus1: on xl0 nsphy0: PHY 24 on miibus1 nsphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:60:08:cd:b0:71 ohci4: mem 0xfb9fa000-0xfb9fafff irq 18 at device 20.5 on pci0 usbus6: on ohci4 acpi_button0: on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 orm0: at iomem 0xcf000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range ctl: CAM Target Layer loaded acpi_throttle0: on cpu0 hwpstate0: on cpu0 firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 ZFS filesystem version 5 ZFS storage pool version 28 Timecounters tick every 1.000 msec hdac0: HDA Codec #0: ATI RS690/780 HDMI pcm0: at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: VIA VT1708S_0 pcm1: at cad 0 nid 1 on hdac1 pcm2: at cad 0 nid 1 on hdac1 pcm3: at cad 0 nid 1 on hdac1 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 usbus6: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 uhub6: 2 ports with 2 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered uhub3: 3 ports with 3 removable, self powered uhub4: 3 ports with 3 removable, self powered uhub2: 6 ports with 6 removable, self powered uhub5: 6 ports with 6 removable, self powered ugen1.2: at usbus1 ums0: on usbus1 ums0: 5 buttons and [XYZ] coordinates ID=0 ugen5.2: at usbus5 umass0: on usbus5 umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:7:0:-1: Attached to scbus7 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 (probe0:umass-sim0:0:0:1): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:1): SCSI status: Check Condition (probe0:umass-sim0:0:0:1): SCSI sense: NOT READY asc:3a,0 (Medium not present) ugen1.3: at usbus1 ukbd0: on usbus1 kbd2 at ukbd0 ums1: on usbus1 ums1: 3 buttons and [XYZ] coordinates ID=0 ahcich1: Timeout on slot 0 port 0 ahcich1: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr 00000000 cmd 00006017 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config ahcich1: Timeout on slot 0 port 0 ahcich1: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr 00000000 cmd 00006017 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! cd0 at ata0 bus 0 scbus4 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 66.700MB/s transfers (UDMA4, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ata1 bus 0 scbus5 target 0 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 150.000MB/s transfers (SATA, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed da0 at umass-sim0 bus 0 scbus7 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present cd2 at umass-sim0 bus 0 scbus7 target 0 lun 1 cd2: Removable CD-ROM SCSI-2 device cd2: 40.000MB/s transfers cd2: Attempt to query device size failed: NOT READY, Medium not present Timecounter "TSC-low" frequency 13326929 Hz quality 800 Root mount waiting for: GMIRROR Root mount waiting for: GMIRROR Root mount waiting for: GMIRROR Root mount waiting for: GMIRROR GEOM_MIRROR: Force device swap0 start due to timeout. GEOM_MIRROR: Device mirror/swap0 launched (1/2). Trying to mount root from zfs:z0/root []... --r5Pyd7+fXNt84Ff3-- From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 19:52:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 71E9A1065674 for ; Sat, 3 Mar 2012 19:52:07 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D976A8FC13 for ; Sat, 3 Mar 2012 19:52:06 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3083430bkc.13 for ; Sat, 03 Mar 2012 11:52:05 -0800 (PST) Received-SPF: pass (google.com: domain of mavbsd@gmail.com designates 10.204.173.11 as permitted sender) client-ip=10.204.173.11; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mavbsd@gmail.com designates 10.204.173.11 as permitted sender) smtp.mail=mavbsd@gmail.com; dkim=pass header.i=mavbsd@gmail.com Received: from mr.google.com ([10.204.173.11]) by 10.204.173.11 with SMTP id n11mr7717215bkz.120.1330804325719 (num_hops = 1); Sat, 03 Mar 2012 11:52:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=N5qNLevz6dKQSpX7iXnoP2RhK2xVCKhW3mucEsktcIU=; b=oeNdnKBAkZfapqdVKmMLzIPZyI83iyKb83hVmN1BA5E0b4WaWlx3LcD2wd7k+TwN+m 9+wRRe3myiC/WvXyI13cfiegyXONLbOSgQ5p9JcSkwk77e7DWUmiIYV2yIPZVaEK2va1 vpWujYUcyz5FeGHG3vKaOHXQPPYzM8eR3WVP5areFCYM/7E4h8VEVilnVCT7xQRgaSnh 0ZvOQ/g4Q42Kj+JcYhh5Vu6DRaLx3tD+UjgxblEqJYTtHZGKsQlLIqBQzkmkp/ybG3sp HivhpyptdHIYUB38qAKMqMgWsDw0xYztqqNAW/ZXiMGEfl0nmvQduXvbW0qUwC5bz8ji GKbA== Received: by 10.204.173.11 with SMTP id n11mr6159350bkz.120.1330804325640; Sat, 03 Mar 2012 11:52:05 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id y9sm16033158bkw.5.2012.03.03.11.52.04 (version=SSLv3 cipher=OTHER); Sat, 03 Mar 2012 11:52:04 -0800 (PST) Sender: Alexander Motin Message-ID: <4F527659.5030001@FreeBSD.org> Date: Sat, 03 Mar 2012 21:51:53 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: Jeff Blank References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: missing disk device under 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 19:52:07 -0000 Hi. On 03.03.2012 21:08, Jeff Blank wrote: > I attempted an upgrade last night from an old 8-STABLE (25 Apr 2011) > to 9-STABLE and ran into a problem where a disk apparently wasn't > detected. I'm of course aware of the ATA/CAM changes, but I haven't > found anything that quite explains what's happening here. I've > attached dmesg output from the 8-STABLE and 9-STABLE kernels as well > as the results of 'ls -l /dev/ad*' and 'zpool status' under both > kernels. > > ZFS seems to have figured out what to do about its ad4p3 member > (switching to a gptid device), but since only ada0 is detected during > boot, it can't complete the pool. The weird thing is, though, that > the other disk was actually detected on one reboot to the 9.0 kernel, > ZFS was happy, etc. I haven't been able to reproduce it, though. > > Due to these problems, I haven't upgraded userland yet and am of > course sticking with the 8-STABLE kernel, but I can boot into the > 9-STABLE kernel at will if anyone needs more information. This looks like cause of the missing disk: ahcich1: Timeout on slot 0 port 0 ahcich1: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr 00000000 cmd 00006017 ahcich1: Timeout on slot 0 port 0 ahcich1: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr 00000000 cmd 00006017 It tells that controller signals interrupt, but driver haven't got it. That is even more strange after the disk on first SATA port is working fine. You may try to add to your /boot/loader.conf line: hint.ahci.0.msi=0 , or just set it via loader prompt. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 19:53:54 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB4C8106566B for ; Sat, 3 Mar 2012 19:53:54 +0000 (UTC) (envelope-from remailer@dizum.com) Received: from smtp.zedz.net (outpost.zedz.net [194.109.206.210]) by mx1.freebsd.org (Postfix) with ESMTP id 8C9A38FC0A for ; Sat, 3 Mar 2012 19:53:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.zedz.net (Postfix) with ESMTP id 0408C1AA107 for ; Sat, 3 Mar 2012 20:53:46 +0100 (CET) Received: from smtp.zedz.net ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wv4mpdYxAnwA for ; Sat, 3 Mar 2012 20:53:44 +0100 (CET) Received: by smtp.zedz.net (Postfix, from userid 1003) id 3BBE41C4055; Sat, 3 Mar 2012 20:53:17 +0100 (CET) From: Nomen Nescio Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at . To: stable@FreeBSD.org In-Reply-To: <4F510FBD.50008@FreeBSD.org> Message-ID: <6665e7b1788afc5da128e8bef7244734@dizum.com> Date: Sat, 3 Mar 2012 20:53:17 +0100 (CET) Cc: Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 19:53:54 -0000 > ... and here is the crux of the problem. The vast majority of our > developers don't use FreeBSD as their regular workstation !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Something is wrong with this picture! If not, why not?! From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 20:08:49 2012 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 F299D106564A for ; Sat, 3 Mar 2012 20:08:49 +0000 (UTC) (envelope-from remailer@dizum.com) Received: from smtp.zedz.net (outpost.zedz.net [194.109.206.210]) by mx1.freebsd.org (Postfix) with ESMTP id B200B8FC17 for ; Sat, 3 Mar 2012 20:08:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.zedz.net (Postfix) with ESMTP id 053141AA137 for ; Sat, 3 Mar 2012 21:08:49 +0100 (CET) Received: from smtp.zedz.net ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLw+-8x4BWZL for ; Sat, 3 Mar 2012 21:08:47 +0100 (CET) Received: by smtp.zedz.net (Postfix, from userid 1003) id 8E74F1C4058; Sat, 3 Mar 2012 21:08:28 +0100 (CET) From: Nomen Nescio Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at . To: stable@freebsd.org In-Reply-To: <20120302164505.GA1500@lonesome.com> Message-ID: Date: Sat, 3 Mar 2012 21:08:28 +0100 (CET) Cc: Subject: Re: ports usable or not [was: flowtable usable or not] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 20:08:50 -0000 Thanks mcl. I am off on other things for now but I will file PRs next time I come across something. In the past I have emailed the port maintainer and the answer is usually "yeah I know". After a few of those I thought filing PRs is a waste of time considering the maintainer doesn't seem to care. From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 20:21:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27EC9106564A for ; Sat, 3 Mar 2012 20:21:10 +0000 (UTC) (envelope-from jfb@mr-happy.com) Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [IPv6:2001:470:b:28:f::1]) by mx1.freebsd.org (Postfix) with ESMTP id 062DE8FC14 for ; Sat, 3 Mar 2012 20:21:10 +0000 (UTC) Received: from crow.mr-happy.com (crow-vpn.mr-happy.com [10.1.0.2]) by vexbert.mr-paradox.net (Postfix) with ESMTP id AABF584635 for ; Sat, 3 Mar 2012 15:21:09 -0500 (EST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96 at vexbert.mr-paradox.net Received: by crow.mr-happy.com (Postfix, from userid 16139) id 083A79061; Sat, 3 Mar 2012 15:21:08 -0500 (EST) Date: Sat, 3 Mar 2012 15:21:08 -0500 From: Jeff Blank To: freebsd-stable@freebsd.org Message-ID: <20120303202108.GA2244@mr-happy.com> References: <4F527659.5030001@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F527659.5030001@FreeBSD.org> X-Face: #0jV*~a}VtKS-&E/!EJpH('H1Va}24dxF0oT&+.R3Gu8C; xhSC+<|+H84&YLbMvphuRT4cp3.|8EN_(2Eix/6{.Up~u`a^}0Ln&b+9Fw|BPig@-{y\pL_46d&ZwA]5%_AU?}DezfE&1!>H?3E$!Yve7.O<+..Jnb4:'6Ey_]FtFzU9=*l$1p/@gA,Ze>^5<]+r(XJ+m7`/vMDc$'wy|`e Subject: Re: missing disk device under 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 20:21:10 -0000 On Sat, Mar 03, 2012 at 09:51:53PM +0200, Alexander Motin wrote: > This looks like cause of the missing disk: > > ahcich1: Timeout on slot 0 port 0 > ahcich1: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr > 00000000 cmd 00006017 > ahcich1: Timeout on slot 0 port 0 > ahcich1: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr > 00000000 cmd 00006017 > > It tells that controller signals interrupt, but driver haven't got it. > That is even more strange after the disk on first SATA port is working > fine. You may try to add to your /boot/loader.conf line: > hint.ahci.0.msi=0 > , or just set it via loader prompt. Alexander, Thanks, that seemed to clear the problem up, no troubles through half a dozen or more reboots. Is disabling MSI likely to have any side effects on, for example, performance or reliability? Is there any point to pursuing this as a FreeBSD problem, since I didn't have any issues under the old ATA system? I'm happy to help troubleshoot this if anyone thinks it's worth looking into. thanks, Jeff From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 20:23:32 2012 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 ADD1C106564A; Sat, 3 Mar 2012 20:23:32 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 862408FC14; Sat, 3 Mar 2012 20:23:32 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 630E5563D7; Sat, 3 Mar 2012 14:23:26 -0600 (CST) Date: Sat, 3 Mar 2012 14:23:26 -0600 From: Mark Linimon To: H Message-ID: <20120303202326.GA4940@lonesome.com> References: <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F513B2D.6010809@FreeBSD.org> <4F5148A7.4080408@FreeBSD.org> <4F51BDDA.3020602@hm.net.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F51BDDA.3020602@hm.net.br> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@freebsd.org, Doug Barton , Andriy Gapon Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 20:23:32 -0000 On Sat, Mar 03, 2012 at 03:44:42AM -0300, H wrote: > nobody want to read, they want a desktop nothing else, something silly > and easy to read email and write docs and surf on the net, listen to a > CD, they need to put a cd into the drive, running install process, > reboot, using, nothing else and such a thing ... we do not have I really recommend this class of users investigate PC-BSD. It works "right out of the box" (all the type of work you are frustrated with has already been done, and is part of their release process). To my view, comparing FreeBSD to Ubuntu is apples-to-oranges. A much better point of comparison is PC-BSD to Ubuntu. I can't speak to whether or not PC-BSD will meet all your needs, but it is much more oriented to users than stock FreeBSD. mcl From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 20:54:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 22C37106564A; Sat, 3 Mar 2012 20:54:49 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 242B214FC2A; Sat, 3 Mar 2012 20:54:48 +0000 (UTC) Message-ID: <4F528517.5090702@FreeBSD.org> Date: Sat, 03 Mar 2012 12:54:47 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120224 Thunderbird/10.0.2 MIME-Version: 1.0 To: "K. Macy" References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F51BEE0.7090108@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , Garrett Cooper , =?UTF-8?B?eiBXxIVzaWtvd3NraQ==?= , FreeBSD Current , Arnaud Lacombe , "Bjoern A. Zeeb" , Alexander Leidinger , Julian Elischer Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 20:54:49 -0000 On 03/03/2012 08:53, K. Macy wrote: > a) We as a members of the community are collectively responsible for > the state of FreeBSD. Simply disabling features or removing > functionality that doesn't work or doesn't work optimally and / or > filing bug reports but not being able or willing to respond to > feedback requests is in essence a form of neglect. Although we all > have day to day obligations for which the use of FreeBSD is extremely > impractical if not impossible ... any progress, any improvements, any > advancements will only happen because *we* made it happen. Since we're reiterating key points, I'll do mine one more time. While I sympathize with what you wrote above, if you continue to believe that users have a responsibility to help you debug new features you're going to be disappointed and frustrated. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 20:57:52 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 636381065670; Sat, 3 Mar 2012 20:57:52 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C28F1176FAB; Sat, 3 Mar 2012 20:57:51 +0000 (UTC) Message-ID: <4F5285CF.3010001@FreeBSD.org> Date: Sat, 03 Mar 2012 12:57:51 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120224 Thunderbird/10.0.2 MIME-Version: 1.0 To: Adrian Chadd References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F5117A6.2030003@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, "K. Macy" , =?UTF-8?B?eiBXxIVzaWtvd3NraQ==?= , Arnaud Lacombe , "Bjoern A. Zeeb" , Alexander Leidinger , current@freebsd.org Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 20:57:52 -0000 On 03/02/2012 16:05, Adrian Chadd wrote: > Try breaking that cycle. ... one of the things I've been asking for years. :) Julian's right though, I think PC-BSD will help, but I still think that committers should run -current. I've asked privately for our committers to go back to -current and then have some dedicated development time where we work together to fix the problems that *we* find in order to make the project more desktop-friendly overall. I was (figuratively) laughed out of the room. Doug -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 21:03:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03934106564A; Sat, 3 Mar 2012 21:03:49 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 834CE8FC0A; Sat, 3 Mar 2012 21:03:48 +0000 (UTC) Received: by iahk25 with SMTP id k25so5109539iah.13 for ; Sat, 03 Mar 2012 13:03:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bbzCWAysnWJXCbf2QM/twqbmoYzzVyPnYGJ9ecETYM0=; b=MIZQo13VkdarNuZc85T0f30UEW79m1b//2Z3ldm5FJB+XCHtN6VIh+Sk1d6y5Xt0MI 5U32Rqf1IPN0P1uo8Ig/b5PTgMzsR6ESmwUjQSWl2sGTi5Z8fcoO/UoRqSpC1Ey1X0A1 J1mfFhj5UMQzFP/brAhtDLR4mEniDxgcmoYzpUFA4kMupUkiPCJ7R49JsTLHx8hzwEAi xZwrRvenEmc6PGaH2w86gqVOTK8wRqgy/wBiIS9m1ZNey+cI+Wa/jtZcKlmPWMwjOLvP wzauZ4lF3MA1rMOZ8mAcGmtXI6F4rESRoFKGJ1kqi7IZYXAnGwjeLLmcIdSHwlGeqvE+ /v5A== MIME-Version: 1.0 Received: by 10.50.149.163 with SMTP id ub3mr1598720igb.30.1330808628116; Sat, 03 Mar 2012 13:03:48 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.50.134.106 with HTTP; Sat, 3 Mar 2012 13:03:48 -0800 (PST) In-Reply-To: <4F528517.5090702@FreeBSD.org> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F51BEE0.7090108@freebsd.org> <4F528517.5090702@FreeBSD.org> Date: Sat, 3 Mar 2012 22:03:48 +0100 X-Google-Sender-Auth: AiCrA0GQzJk8gf62EdmgpL_fUv4 Message-ID: From: "K. Macy" To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable , Garrett Cooper , =?ISO-8859-2?Q?z_W=B1sikowski?= , FreeBSD Current , Arnaud Lacombe , "Bjoern A. Zeeb" , Alexander Leidinger , Julian Elischer Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 21:03:49 -0000 On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton wrote: > On 03/03/2012 08:53, K. Macy wrote: >> a) We as a members of the community are collectively responsible for >> the state of FreeBSD. Simply disabling features or removing >> functionality that doesn't work or doesn't work optimally and / or >> filing bug reports but not being able or willing to respond to >> feedback requests is in essence a form of neglect. Although we all >> have day to day obligations for which the use of FreeBSD is extremely >> impractical if not impossible ... any progress, any improvements, any >> advancements will only happen because *we* made it happen. > > Since we're reiterating key points, I'll do mine one more time. While I > sympathize with what you wrote above, if you continue to believe that *users* > have a responsibility to help you debug new features you're going > to be disappointed and frustrated. Users don't, community members do. So I guess I rest my case for you Doug. You're an end user at the end of the day who thinks he is a member of the community. As you've made apparent on other threads. In your mind Other People(TM) are responsible for FreeBSD's welfare for consuming your dogfood because you know the people who eat it. FreeBSD would still be at the UP stage or worse the 5.x stage if everyone thought the way you do. Individuals who fail to understand the distinction between simple user and community member and are confused by which role they play can only further contribute to the acrimony. -Kip From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 21:09:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 8C083106566C; Sat, 3 Mar 2012 21:09:27 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id D4DDE14D958; Sat, 3 Mar 2012 21:09:26 +0000 (UTC) Message-ID: <4F528886.4050606@FreeBSD.org> Date: Sat, 03 Mar 2012 13:09:26 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120224 Thunderbird/10.0.2 MIME-Version: 1.0 To: "K. Macy" References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F51BEE0.7090108@freebsd.org> <4F528517.5090702@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , Garrett Cooper , =?UTF-8?B?eiBXxIVzaWtvd3NraQ==?= , FreeBSD Current , Arnaud Lacombe , "Bjoern A. Zeeb" , Alexander Leidinger , Julian Elischer Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 21:09:27 -0000 On 03/03/2012 13:03, K. Macy wrote: > On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton wrote: >> On 03/03/2012 08:53, K. Macy wrote: >>> a) We as a members of the community are collectively responsible for >>> the state of FreeBSD. Simply disabling features or removing >>> functionality that doesn't work or doesn't work optimally and / or >>> filing bug reports but not being able or willing to respond to >>> feedback requests is in essence a form of neglect. Although we all >>> have day to day obligations for which the use of FreeBSD is extremely >>> impractical if not impossible ... any progress, any improvements, any >>> advancements will only happen because *we* made it happen. >> >> Since we're reiterating key points, I'll do mine one more time. While I >> sympathize with what you wrote above, if you continue to believe that > > *users* > >> have a responsibility to help you debug new features you're going >> to be disappointed and frustrated. > > Users don't, community members do. You're drawing a distinction that I don't. > So I guess I rest my case for you > Doug. You're an end user at the end of the day who thinks he is a > member of the community. As you've made apparent on other threads. > > In your mind Other People(TM) are responsible for FreeBSD's welfare > for consuming your dogfood because you know the people who eat it. Um, wow. Clearly you are either unable or unwilling to see my point, so I wish you all the best. -- This .signature sanitized for your protection From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 21:16:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADF43106564A; Sat, 3 Mar 2012 21:16:25 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3A2098FC14; Sat, 3 Mar 2012 21:16:25 +0000 (UTC) Received: by iahk25 with SMTP id k25so5120616iah.13 for ; Sat, 03 Mar 2012 13:16:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4INuS29uHUzT5IWSWw7z+oAl/eaWFGAsKM4rEvY3teU=; b=WVe8TiRbotJw2BebPksC9IlbHjiJgBZNtUrjKrwIK4KHwOwv0Bgoz42HDUdnjY0C+C 6ZiGhOn/+/XGxanaNhFU4W6dJJKZueAn7J8TsnZMkB4G8Xd6g7L4bZS8TXxscPSL+UUp VucXu0EXUkGy5m1dJ1g10GJgOD4j7xIiLilCayiIOwQRWXqxwOaiKOiMhcoIupsrv8rF H7xfGMVMoZ8JJysU00OkFL/zF3ROt9191aUbRUgN+csCRQd0EmdTSR3BO54/nwKNgytt gWPBgkP6xnUvor/7ZJd5NW3f/EPzTDduFYY4C8zEr7hlmJI02t8AcFQKTQay0CX40pgx yWaw== MIME-Version: 1.0 Received: by 10.50.140.2 with SMTP id rc2mr2117009igb.22.1330809384867; Sat, 03 Mar 2012 13:16:24 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.50.134.106 with HTTP; Sat, 3 Mar 2012 13:16:24 -0800 (PST) In-Reply-To: <4F528886.4050606@FreeBSD.org> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> <4F4BA707.5070608@wasikowski.net> <4F4C3FE7.3040802@FreeBSD.org> <4F4D51CB.2010508@FreeBSD.org> <4F4D5E5D.9040302@FreeBSD.org> <4F4DD288.5060106@FreeBSD.org> <4F4ED889.2070608@FreeBSD.org> <4F500BB9.4040307@FreeBSD.org> <4F5088CA.1090108@FreeBSD.org> <4F510FBD.50008@FreeBSD.org> <4F51BEE0.7090108@freebsd.org> <4F528517.5090702@FreeBSD.org> <4F528886.4050606@FreeBSD.org> Date: Sat, 3 Mar 2012 22:16:24 +0100 X-Google-Sender-Auth: bQUkFJEapnhHMEhac5Js5UsjfZI Message-ID: From: "K. Macy" To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable , Garrett Cooper , =?ISO-8859-2?Q?z_W=B1sikowski?= , FreeBSD Current , Arnaud Lacombe , "Bjoern A. Zeeb" , Alexander Leidinger , Julian Elischer Subject: Re: flowtable usable or not X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Mar 2012 21:16:25 -0000 On Sat, Mar 3, 2012 at 10:09 PM, Doug Barton wrote: > On 03/03/2012 13:03, K. Macy wrote: >> On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton wrote: >>> On 03/03/2012 08:53, K. Macy wrote: >>>> a) We as a members of the community are collectively responsible for >>>> the state of FreeBSD. Simply disabling features or removing >>>> functionality that doesn't work or doesn't work optimally and / or >>>> filing bug reports but not being able or willing to respond to >>>> feedback requests is in essence a form of neglect. Although we all >>>> have day to day obligations for which the use of FreeBSD is extremely >>>> impractical if not impossible ... any progress, any improvements, any >>>> advancements will only happen because *we* made it happen. >>> >>> Since we're reiterating key points, I'll do mine one more time. While I >>> sympathize with what you wrote above, if you continue to believe that >> >> *users* >> >>> have a responsibility to help you debug new features you're going >>> to be disappointed and frustrated. >> >> Users don't, community members do. > > You're drawing a distinction that I don't. > I'm drawing a distinction that you don't make or can't make? Like I said I expect a group of people whose existence as a distinct entity you are unaware of to be helpful. The initial conflict stemmed from confusion on my part that you belong to that group. However, as you've repeatedly made clear you don't, so I was wrong to have been critical of you. I apologize for the confusion. Cheers From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 21:19:09 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83082106566C for ; Sat, 3 Mar 2012 21:19:09 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id F29358FC1A for ; Sat, 3 Mar 2012 21:19:08 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3112310bkc.13 for ; Sat, 03 Mar 2012 13:19:08 -0800 (PST) Received-SPF: pass (google.com: domain of mavbsd@gmail.com designates 10.204.150.78 as permitted sender) client-ip=10.204.150.78; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mavbsd@gmail.com designates 10.204.150.78 as permitted sender) smtp.mail=mavbsd@gmail.com; dkim=pass header.i=mavbsd@gmail.com Received: from mr.google.com ([10.204.150.78]) by 10.204.150.78 with SMTP id x14mr7828686bkv.114.1330809548062 (num_hops = 1); Sat, 03 Mar 2012 13:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=or7HdAvj8Ssn7G9uAgi5vnf/hfGrIwktxwECm0V6VKc=; b=o+ahpDQyKXdSKv/HAXQBz8/tzTlfJQLGK96vO+tjrK+ooUHMPDZ637Mf/5KH0eCZY7 T1DXiJilipm63i2VfDftAJ72PLEIXks4bV8U85PHJmhJP1c8+MOM26iHGnYIIgy6vAC7 PA1pH5bS3mnEcVw32yCb0dzBsBGSKrD9CBAWIt2JALDwfosNfNI2nj3DqebgdkFJm7eT +RBoCmF12whfS8yYchyxLpHRWJlUeEbBvJs4Z4xZLvPr2b9trrlL4bMq8o+hq3haHIgn Lwy02OdyilRy//kl4ao2jRcPIzeceIeM6R+81aCvVrEX7ftSEY0iUaaoxv/p1FSQ6Ron Zcqg== Received: by 10.204.150.78 with SMTP id x14mr6244226bkv.114.1330809547981; Sat, 03 Mar 2012 13:19:07 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id bw9sm16323808bkb.8.2012.03.03.13.19.06 (version=SSLv3 cipher=OTHER); Sat, 03 Mar 2012 13:19:07 -0800 (PST) Sender: Alexander Motin Message-ID: <4F528ABF.5040308@FreeBSD.org> Date: Sat, 03 Mar 2012 23:18:55 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: Jeff Blank References: <4F527659.5030001@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: missing disk device under 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 21:19:09 -0000 On 03.03.2012 22:21, Jeff Blank wrote: > On Sat, Mar 03, 2012 at 09:51:53PM +0200, Alexander Motin wrote: >> This looks like cause of the missing disk: >> >> ahcich1: Timeout on slot 0 port 0 >> ahcich1: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr >> 00000000 cmd 00006017 >> ahcich1: Timeout on slot 0 port 0 >> ahcich1: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr >> 00000000 cmd 00006017 >> >> It tells that controller signals interrupt, but driver haven't got it. >> That is even more strange after the disk on first SATA port is working >> fine. You may try to add to your /boot/loader.conf line: >> hint.ahci.0.msi=0 >> , or just set it via loader prompt. > > Alexander, > > Thanks, that seemed to clear the problem up, no troubles through half > a dozen or more reboots. > > Is disabling MSI likely to have any side effects on, for example, > performance or reliability? Is there any point to pursuing this as a > FreeBSD problem, since I didn't have any issues under the old ATA > system? I'm happy to help troubleshoot this if anyone thinks it's > worth looking into. MSI interrupts could give a bit better performance. But with regular HDDs I think it is unlikely that you notice any difference. What's about about old driver, it never used MSI by default, while new one does. What board and chipset do you use? Have you tried to update BIOS? Please show `pciconf -lvcb` output about the controller. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Sat Mar 3 21:27:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F1B1106566B for ; Sat, 3 Mar 2012 21:27:22 +0000 (UTC) (envelope-from jfb@mr-paradox.net) Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [IPv6:2001:470:b:28:f::1]) by mx1.freebsd.org (Postfix) with ESMTP id 80C798FC13 for ; Sat, 3 Mar 2012 21:27:22 +0000 (UTC) Received: by vexbert.mr-paradox.net (Postfix, from userid 16139) id 3C1C284636; Sat, 3 Mar 2012 16:27:22 -0500 (EST) Date: Sat, 3 Mar 2012 16:27:20 -0500 From: Jeff Blank To: freebsd-stable@freebsd.org Message-ID: <20120303212720.GA82921@mr-happy.com> References: <4F527659.5030001@FreeBSD.org> <4F528ABF.5040308@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F528ABF.5040308@FreeBSD.org> X-Face: #0jV*~a}VtKS-&E/!EJpH('H1Va}24dxF0oT&+.R3Gu8C; xhSC+<|+H84&YLbMvphuRT4cp3.|8EN_(2Eix/6{.Up~u`a^}0Ln&b+9Fw|BPig@-{y\pL_46d&ZwA]5%_AU?}DezfE&1!>H?3E$!Yve7.O<+..Jnb4:'6Ey_]FtFzU9=*l$1p/@gA,Ze>^5<]+r(XJ+m7`/vMDc$'wy|`e Subject: Re: missing disk device under 9-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 21:27:22 -0000 On Sat, Mar 03, 2012 at 11:18:55PM +0200, Alexander Motin wrote: > MSI interrupts could give a bit better performance. But with regular > HDDs I think it is unlikely that you notice any difference. What's about > about old driver, it never used MSI by default, while new one does. I see, thanks. > What board and chipset do you use? Have you tried to update BIOS? Please I have not investigated a BIOS upgrade. I'll look into it. > show `pciconf -lvcb` output about the controller. the AHCI driver attachment: ahci0@pci0:0:17:0: class=0x01018f card=0x43901002 chip=0x43901002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'SB7x0/SB8x0/SB9x0 SATA Controller [IDE mode]' class = mass storage subclass = ATA bar [10] = type I/O Port, range 32, base 0x9000, size 8, enabled bar [14] = type I/O Port, range 32, base 0x8000, size 4, enabled bar [18] = type I/O Port, range 32, base 0x7000, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x6000, size 4, enabled bar [20] = type I/O Port, range 32, base 0x5000, size 16, enabled bar [24] = type Memory, range 32, base 0xfb9ffc00, size 1024, enabled cap 05[50] = MSI supports 4 messages, 64 bit cap 12[70] = SATA Index-Data Pair the ATA driver attachment, included for completeness: atapci0@pci0:0:20:1: class=0x01018a card=0x439c1002 chip=0x439c1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'SB7x0/SB8x0/SB9x0 IDE Controller' class = mass storage subclass = ATA bar [20] = type I/O Port, range 32, base 0xff00, size 16, enabled cap 05[70] = MSI supports 2 messages thanks, Jeff