From owner-freebsd-stable@FreeBSD.ORG Sun Jun 6 01:48:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2381A106567A for ; Sun, 6 Jun 2010 01:48:02 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id DB34B8FC0C for ; Sun, 6 Jun 2010 01:48:01 +0000 (UTC) Received: by iwn5 with SMTP id 5so2850232iwn.13 for ; Sat, 05 Jun 2010 18:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=DaHg0ZBS/jkYp0k5h3afns5I5xh0C27nv9KU9h527Jw=; b=hRRvF42FWoKejMaohrb9R5yUNVUR2Kc6JROTeo89i0Nt6wn3BmZa3ZNNbLu0sQgYq5 cx8+Y5krcrYmYqgJhhubnInbjUyZDmf2NDXI1C6TdLraYkM1fL2By+3dHml7pnhk/9ps fM+l4UfkXArNTch9rTPo9a+7OXkq8x6Lc6Y0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=OsH99c70eTgT/ugsnB1eJJ5BRme/qXy65Cog56Lk5CTpG3O2YIGB/lSYgziw7ntGto VWdToINyOpqHfpPhTnApggImMx9kJSAFCJN12t3zhGyLUG8ChevUrihg44hIXL+8i3hf xlkNVU4k3be/FFpHwrXVMunc5yg0+ZHz8Pk2c= MIME-Version: 1.0 Received: by 10.231.45.144 with SMTP id e16mr2691071ibf.130.1275788881100; Sat, 05 Jun 2010 18:48:01 -0700 (PDT) Received: by 10.231.190.131 with HTTP; Sat, 5 Jun 2010 18:48:01 -0700 (PDT) In-Reply-To: References: Date: Sat, 5 Jun 2010 21:48:01 -0400 Message-ID: From: Nick Rogers To: FreeBSD STABLE Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: arp -na performance w/ many permanent entries X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2010 01:48:02 -0000 On Mon, May 31, 2010 at 10:54 PM, Nick Rogers wrote: > > [root@ ~]# time arp -na > /dev/null > > real 0m12.761s > user 0m2.959s > sys 0m9.753s > [root@ ~]# > > > Notice that "arp -na" takes about 13s to execute even though there is no > other load. This can get a lot worse by a few orders of magnitude on a > loaded machine in a production environment, and seems to scale up linearly > when more aliases are added to the interface (permanent ARP entries > created). > > Is this a reasonable problem that can be fixed/improved, or am I stuck with > the slow arp -na output? Any help or comments is greatly appreciated. > I tried the same scenario on 8.1-BETA1 and it still takes a very long time for arp(8) to complete. I was able to isolate the performance bottleneck to a small piece of the arp(8) code. It seems that looking up the interface for an ARP entry is a very heavy operation when that entry corresponds to an alias assigned to the interface. Permanent ARP entries that do not correspond with an interface alias do not seem to cause arp(8) to puke on the interface lookup. The following commands and code diff illustrates how arp(8) can be modified to run a lot faster in this scenario, but obviously the associated interface is no longer printed for each entry. [root@ /usr/src/usr.sbin/arp]# uname -a FreeBSD .localdomain 8.1-BETA1 FreeBSD 8.1-BETA1 #0: Thu May 27 15:03:30 UTC 2010 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 [root@ /usr/src/usr.sbin/arp]# time /usr/sbin/arp -na | wc -l 4100 real 0m14.903s user 0m3.133s sys 0m11.519s [root@ /usr/src/usr.sbin/arp]# pwd /usr/src/usr.sbin/arp [root@ /usr/src/usr.sbin/arp]# !diff diff -ruN arp.c.orig arp.c --- arp.c.orig 2010-06-05 18:25:24.000000000 +0000 +++ arp.c 2010-06-05 18:28:19.000000000 +0000 @@ -562,7 +562,7 @@ const char *host; struct hostent *hp; struct iso88025_sockaddr_dl_data *trld; - char ifname[IF_NAMESIZE]; + //char ifname[IF_NAMESIZE]; int seg; if (nflag == 0) @@ -591,8 +591,8 @@ } } else printf("(incomplete)"); - if (if_indextoname(sdl->sdl_index, ifname) != NULL) - printf(" on %s", ifname); + //if (if_indextoname(sdl->sdl_index, ifname) != NULL) + //printf(" on %s", ifname); if (rtm->rtm_rmx.rmx_expire == 0) printf(" permanent"); else { [root@ /usr/src/usr.sbin/arp]# make clean && make rm -f arp arp.o arp.4.gz arp.8.gz arp.4.cat.gz arp.8.cat.gz Warning: Object directory not changed from original /usr/src/usr.sbin/arp cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c arp.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -o arp arp.o gzip -cn arp.4 > arp.4.gz gzip -cn arp.8 > arp.8.gz [root@ /usr/src/usr.sbin/arp]# time ./arp -na | wc -l 4099 real 0m0.036s user 0m0.015s sys 0m0.021s [root@ /usr/src/usr.sbin/arp]# Notice that 0.036s without the interface lookup is a heck of a lot faster than 14.903s when doing the interface lookup. Is there something that can be done to speedup the call to if_indextoname(), or would it be worthwhile for me to submit a patch that adds the ability to skip the interface lookup as an arp(8) option? From owner-freebsd-stable@FreeBSD.ORG Sun Jun 6 03:16:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AF73106566B for ; Sun, 6 Jun 2010 03:16:30 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id CB8E08FC12 for ; Sun, 6 Jun 2010 03:16:29 +0000 (UTC) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta13.westchester.pa.mail.comcast.net with comcast id STA51e0030EZKEL5DTGVBz; Sun, 06 Jun 2010 03:16:29 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta01.westchester.pa.mail.comcast.net with comcast id STGU1e0073S48mS3MTGVnw; Sun, 06 Jun 2010 03:16:29 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 62EE09B418; Sat, 5 Jun 2010 20:16:27 -0700 (PDT) Date: Sat, 5 Jun 2010 20:16:27 -0700 From: Jeremy Chadwick To: Nick Rogers Message-ID: <20100606031627.GA4742@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD STABLE Subject: Re: arp -na performance w/ many permanent entries X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2010 03:16:30 -0000 On Sat, Jun 05, 2010 at 09:48:01PM -0400, Nick Rogers wrote: > On Mon, May 31, 2010 at 10:54 PM, Nick Rogers wrote: > > > > > [root@ ~]# time arp -na > /dev/null > > > > real 0m12.761s > > user 0m2.959s > > sys 0m9.753s > > [root@ ~]# > > > > > > Notice that "arp -na" takes about 13s to execute even though there is no > > other load. This can get a lot worse by a few orders of magnitude on a > > loaded machine in a production environment, and seems to scale up linearly > > when more aliases are added to the interface (permanent ARP entries > > created). > > > > Is this a reasonable problem that can be fixed/improved, or am I stuck with > > the slow arp -na output? Any help or comments is greatly appreciated. > > > > I tried the same scenario on 8.1-BETA1 and it still takes a very long time > for arp(8) to complete. > > I was able to isolate the performance bottleneck to a small piece of the > arp(8) code. It seems that looking up the interface for an ARP entry is a > very heavy operation when that entry corresponds to an alias assigned to the > interface. Permanent ARP entries that do not correspond with an interface > alias do not seem to cause arp(8) to puke on the interface lookup. > > The following commands and code diff illustrates how arp(8) can be modified > to run a lot faster in this scenario, but obviously the associated interface > is no longer printed for each entry. > > [root@ /usr/src/usr.sbin/arp]# uname -a > FreeBSD .localdomain 8.1-BETA1 FreeBSD 8.1-BETA1 #0: Thu May 27 15:03:30 UTC > 2010 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > [root@ /usr/src/usr.sbin/arp]# time /usr/sbin/arp -na | wc -l > 4100 > > real 0m14.903s > user 0m3.133s > sys 0m11.519s > [root@ /usr/src/usr.sbin/arp]# pwd > /usr/src/usr.sbin/arp > [root@ /usr/src/usr.sbin/arp]# !diff > diff -ruN arp.c.orig arp.c > --- arp.c.orig 2010-06-05 18:25:24.000000000 +0000 > +++ arp.c 2010-06-05 18:28:19.000000000 +0000 > @@ -562,7 +562,7 @@ > const char *host; > struct hostent *hp; > struct iso88025_sockaddr_dl_data *trld; > - char ifname[IF_NAMESIZE]; > + //char ifname[IF_NAMESIZE]; > int seg; > > if (nflag == 0) > @@ -591,8 +591,8 @@ > } > } else > printf("(incomplete)"); > - if (if_indextoname(sdl->sdl_index, ifname) != NULL) > - printf(" on %s", ifname); > + //if (if_indextoname(sdl->sdl_index, ifname) != NULL) > + //printf(" on %s", ifname); > if (rtm->rtm_rmx.rmx_expire == 0) > printf(" permanent"); > else { > [root@ /usr/src/usr.sbin/arp]# make clean && make > rm -f arp arp.o arp.4.gz arp.8.gz arp.4.cat.gz arp.8.cat.gz > Warning: Object directory not changed from original /usr/src/usr.sbin/arp > cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c > arp.c > cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall > -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign > -o arp arp.o > gzip -cn arp.4 > arp.4.gz > gzip -cn arp.8 > arp.8.gz > [root@ /usr/src/usr.sbin/arp]# time ./arp -na | wc -l > 4099 > > real 0m0.036s > user 0m0.015s > sys 0m0.021s > [root@ /usr/src/usr.sbin/arp]# > > Notice that 0.036s without the interface lookup is a heck of a lot faster > than 14.903s when doing the interface lookup. > > Is there something that can be done to speedup the call to if_indextoname(), > or would it be worthwhile for me to submit a patch that adds the ability to > skip the interface lookup as an arp(8) option? This might be a better question for either freebsd-net or freebsd-hackers. I should warn you in advance that you might receive a bit of flack given that you have over 4000 IP aliases assigned to an interface. Explaining your setup may also help people understand why it is you need what you do. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jun 6 03:54:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27783106566B for ; Sun, 6 Jun 2010 03:54:23 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C952D8FC18 for ; Sun, 6 Jun 2010 03:54:22 +0000 (UTC) Received: by vws18 with SMTP id 18so1157162vws.13 for ; Sat, 05 Jun 2010 20:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=44+uVNFCYaVPHYGJp1ITtc36XFp3HVx6BD+/Ez2ASeM=; b=fUAKLe3ajgRJv/BG6HXUKEPw2aYZ5I7SU+vF2YbN9om6EGlpzc3CN5ckItJhgusdwl yrp1G331SHBZv9C00z2bBpjWSYsWbR+AvbsiCawxbO4ZP/cPgMVDDrqJDdL9PsAjSfXj QHW6wz7yUrVAdwVLJN0RSUO1GsYrGzeBpoIPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vf4NuGhS8qgxDHGyqoa+KfU2zjDDbhFsA5zfvNWJiMTELJfYCQZrr/AzOIhCTadQ7+ VLpWsvQaJlMNVIyhr1h7YGQvybTMHmQ/tkZyK7kyvQjcbTl/y2Rt6JL3yhTeD1sMMwyK BnVfVfUczIq4NaP+NgruQh/Idw+Ps+PIDvd5g= MIME-Version: 1.0 Received: by 10.224.53.153 with SMTP id m25mr1442074qag.133.1275796460818; Sat, 05 Jun 2010 20:54:20 -0700 (PDT) Received: by 10.229.233.74 with HTTP; Sat, 5 Jun 2010 20:54:20 -0700 (PDT) In-Reply-To: <20100606031627.GA4742@icarus.home.lan> References: <20100606031627.GA4742@icarus.home.lan> Date: Sat, 5 Jun 2010 20:54:20 -0700 Message-ID: From: Garrett Cooper To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Nick Rogers , FreeBSD STABLE Subject: Re: arp -na performance w/ many permanent entries X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2010 03:54:23 -0000 On Sat, Jun 5, 2010 at 8:16 PM, Jeremy Chadwick wrote: > On Sat, Jun 05, 2010 at 09:48:01PM -0400, Nick Rogers wrote: >> On Mon, May 31, 2010 at 10:54 PM, Nick Rogers wrote= : >> >> > >> > [root@ ~]# time arp -na > /dev/null >> > >> > real 0m12.761s >> > user 0m2.959s >> > sys 0m9.753s >> > [root@ ~]# >> > >> > >> > Notice that "arp -na" takes about 13s to execute even though there is = no >> > other load. This can get a lot worse by a few orders of magnitude on a >> > loaded machine in a production environment, and seems to scale up line= arly >> > when more aliases are added to the interface (permanent ARP entries >> > created). >> > >> > Is this a reasonable problem that can be fixed/improved, or am I stuck= with >> > the slow arp -na output? Any help or comments is greatly appreciated. >> > >> >> I tried the same scenario on 8.1-BETA1 and it still takes a very long ti= me >> for arp(8) to complete. >> >> I was able to isolate the performance bottleneck to a small piece of the >> arp(8) code. It seems that looking up the interface for an ARP entry is = a >> very heavy operation when that entry corresponds to an alias assigned to= the >> interface. Permanent ARP entries that do not correspond with an interfac= e >> alias do not seem to cause arp(8) to puke on the interface lookup. >> >> The following commands and code diff illustrates how arp(8) can be modif= ied >> to run a lot faster in this scenario, but obviously the associated inter= face >> is no longer printed for each entry. >> >> [root@ /usr/src/usr.sbin/arp]# uname -a >> FreeBSD .localdomain 8.1-BETA1 FreeBSD 8.1-BETA1 #0: Thu May 27 15:03:30= UTC >> 2010 =A0 =A0 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC =A0= amd64 >> [root@ /usr/src/usr.sbin/arp]# time /usr/sbin/arp -na | wc -l >> =A0 =A0 4100 >> >> real 0m14.903s >> user 0m3.133s >> sys 0m11.519s >> [root@ /usr/src/usr.sbin/arp]# pwd >> /usr/src/usr.sbin/arp >> [root@ /usr/src/usr.sbin/arp]# !diff >> diff -ruN arp.c.orig arp.c >> --- arp.c.orig 2010-06-05 18:25:24.000000000 +0000 >> +++ arp.c 2010-06-05 18:28:19.000000000 +0000 >> @@ -562,7 +562,7 @@ >> =A0 const char *host; >> =A0 struct hostent *hp; >> =A0 struct iso88025_sockaddr_dl_data *trld; >> - char ifname[IF_NAMESIZE]; >> + //char ifname[IF_NAMESIZE]; >> =A0 int seg; >> >> =A0 if (nflag =3D=3D 0) >> @@ -591,8 +591,8 @@ >> =A0 } >> =A0 } else >> =A0 printf("(incomplete)"); >> - if (if_indextoname(sdl->sdl_index, ifname) !=3D NULL) >> - printf(" on %s", ifname); >> + //if (if_indextoname(sdl->sdl_index, ifname) !=3D NULL) >> + //printf(" on %s", ifname); >> =A0 if (rtm->rtm_rmx.rmx_expire =3D=3D 0) >> =A0 printf(" permanent"); >> =A0 else { >> [root@ /usr/src/usr.sbin/arp]# make clean && make >> rm -f arp arp.o arp.4.gz arp.8.gz arp.4.cat.gz arp.8.cat.gz >> Warning: Object directory not changed from original /usr/src/usr.sbin/ar= p >> cc -O2 -pipe =A0-std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror = -Wall >> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sig= n -c >> arp.c >> cc -O2 -pipe =A0-std=3Dgnu99 -fstack-protector -Wsystem-headers -Werror = -Wall >> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sig= n >> =A0-o arp arp.o >> gzip -cn arp.4 > arp.4.gz >> gzip -cn arp.8 > arp.8.gz >> [root@ /usr/src/usr.sbin/arp]# time ./arp -na | wc -l >> =A0 =A0 4099 >> >> real 0m0.036s >> user 0m0.015s >> sys 0m0.021s >> [root@ /usr/src/usr.sbin/arp]# >> >> Notice that 0.036s without the interface lookup is a heck of a lot faste= r >> than 14.903s when doing the interface lookup. >> >> Is there something that can be done to speedup the call to if_indextonam= e(), >> or would it be worthwhile for me to submit a patch that adds the ability= to >> skip the interface lookup as an arp(8) option? > > This might be a better question for either freebsd-net or > freebsd-hackers. =A0I should warn you in advance that you might receive a > bit of flack given that you have over 4000 IP aliases assigned to an > interface. =A0Explaining your setup may also help people understand why i= t > is you need what you do. I agree with Jeremy. I think that the problem that you've discovered is the fact that it's using stdio-based buffered output instead of buffering more of the contents in a string and punting it out in larger chunks. HTH, -Garrett From owner-freebsd-stable@FreeBSD.ORG Sun Jun 6 05:25:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4F25106566B for ; Sun, 6 Jun 2010 05:25:53 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from k7.mavetju.org (ppp113-58.static.internode.on.net [150.101.113.58]) by mx1.freebsd.org (Postfix) with ESMTP id 5AE648FC0A for ; Sun, 6 Jun 2010 05:25:52 +0000 (UTC) Received: by k7.mavetju.org (Postfix, from userid 1001) id B15C945211; Sun, 6 Jun 2010 15:25:09 +1000 (EST) Date: Sun, 6 Jun 2010 15:25:09 +1000 From: Edwin Groothuis To: freebsd-stable@freebsd.org Message-ID: <20100606052509.GA4744@mavetju.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: gmirror refused to connect second disk after a reboot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2010 05:25:53 -0000 For two years I've had a happy gmirror RAID1 system. And a week or three ago I was found a degraded system due to a broken disk. I tried to replace the disk, first with one three sectors too small which didn't want to be entered in the array (as excepted), then with a same brand/type one which I added without a problem. Rebuilding, everything okay. [~] edwin@k7>sudo fdisk -s /dev/ad1 /dev/ad1: 1938021 cyl 16 hd 63 sec Part Start Size Type Flags 1: 63 1953520002 0xa5 0x00 [~] edwin@k7>sudo fdisk -s /dev/ad3 /dev/ad3: 1938021 cyl 16 hd 63 sec Part Start Size Type Flags 1: 63 1953520002 0xa5 0x80 [~] edwin@k7>gmirror status Name Status Components mirror/gm0 COMPLETE ad1 ad3 Until after a reboot, then GEOM complains about: GEOM: ad3s1: geometry does not match label (255h,63s != 16h,63s). GEOM_MIRROR: Force device gm0 start due to timeout. GEOM_MIRROR: Device mirror/gm0 launched (1/2). [~] edwin@k7>gmirror status Name Status Components mirror/gm0 DEGRADED ad1 Forgetting and re-inserting the ad3 does attach it again and rebuild everything, until the next reboot. Booting from ad3 instead of from ad1 results in the same result. This device is running 8.0-STABLE r204385. Who has any idea what is going wrong here and which smart commands I can to overcome this silly issues or are any clues which commands I should run next to get more information? Thanks heaps, Edwin -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-stable@FreeBSD.ORG Sun Jun 6 15:02:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4429D106566B for ; Sun, 6 Jun 2010 15:02:11 +0000 (UTC) (envelope-from elon@emmi.physik-pool.tu-berlin.de) Received: from emmi.physik-pool.tu-berlin.de (emmi.physik-pool.TU-Berlin.DE [130.149.58.146]) by mx1.freebsd.org (Postfix) with ESMTP id C529A8FC08 for ; Sun, 6 Jun 2010 15:02:10 +0000 (UTC) Received: from emmi.physik-pool.tu-berlin.de (localhost.physik-pool.tu-berlin.de [127.0.0.1]) by emmi.physik-pool.tu-berlin.de (8.14.4/8.14.4) with ESMTP id o56Eihgq028731 for ; Sun, 6 Jun 2010 16:44:43 +0200 (CEST) (envelope-from elon@emmi.physik-pool.tu-berlin.de) Received: (from elon@localhost) by emmi.physik-pool.tu-berlin.de (8.14.4/8.14.4/Submit) id o56EihmQ028730 for freebsd-stable@freebsd.org; Sun, 6 Jun 2010 16:44:43 +0200 (CEST) (envelope-from elon) Date: Sun, 6 Jun 2010 16:44:43 +0200 From: Leon =?iso-8859-15?Q?Me=DFner?= To: freebsd-stable@freebsd.org Message-ID: <20100606144443.GA50876@emmi.physik-pool.tu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: freeBSD nullfs together with nfs and "silly rename" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2010 15:02:11 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I hope this is not the wrong list to ask. Didn't get any answers on -questions. When you try to do the following inside a nullfs mounted directory, where the nullfs origin is itself mounted via nfs you get an error: # foo=20 # tail -f foo&=20 # rm -f foo=20 tail: foo: Stale NFS file handle # fg This is really a problem when running services inside jails and using NFS as storage. As of [2] it looks like this problem is known for a while. On a normal NFS mount this does not happen as "silly renaming" [1] works there (producing nasty little .nfsXXXX files). TIA, Leon [1] http://nfs.sourceforge.net/#faq_d2 [2] http://ftp.freebsd.org/pub/FreeBSD/development/FreeBSD-CVS/src/sys/nfsc= lient/nfsnode.h,v rev:1.32.2.1 --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkwLtFsACgkQJCh4HSRvNnxT4wCfZ9DBwVjHfLuXqR3UPkmrtBRH QVEAn3AftWuZnrZJZxGcIkdcNf2xYAjl =DMgV -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-stable@FreeBSD.ORG Sun Jun 6 18:55:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90B321065678 for ; Sun, 6 Jun 2010 18:55:54 +0000 (UTC) (envelope-from lambert@lambertfam.org) Received: from sysmon.tcworks.net (sysmon.tcworks.net [65.66.76.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4732B8FC24 for ; Sun, 6 Jun 2010 18:55:53 +0000 (UTC) Received: from sysmon.tcworks.net (localhost [127.0.0.1]) by sysmon.tcworks.net (8.13.1/8.13.1) with ESMTP id o56Itr1w074284; Sun, 6 Jun 2010 13:55:53 -0500 (CDT) (envelope-from lambert@lambertfam.org) Received: (from lambert@localhost) by sysmon.tcworks.net (8.13.1/8.13.1/Submit) id o56Itp9u074282; Sun, 6 Jun 2010 13:55:51 -0500 (CDT) (envelope-from lambert@lambertfam.org) X-Authentication-Warning: sysmon.tcworks.net: lambert set sender to lambert@lambertfam.org using -f Date: Sun, 6 Jun 2010 13:55:51 -0500 From: Scott Lambert To: freebsd-stable@freebsd.org Message-ID: <20100606185551.GA267@sysmon.tcworks.net> Mail-Followup-To: freebsd-stable@freebsd.org, Edwin Groothuis References: <20100606052509.GA4744@mavetju.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100606052509.GA4744@mavetju.org> User-Agent: Mutt/1.4.2.2i Cc: Edwin Groothuis Subject: Re: gmirror refused to connect second disk after a reboot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2010 18:55:54 -0000 On Sun, Jun 06, 2010 at 03:25:09PM +1000, Edwin Groothuis wrote: > For two years I've had a happy gmirror RAID1 system. And a week or > three ago I was found a degraded system due to a broken disk. > > I tried to replace the disk, first with one three sectors too small > which didn't want to be entered in the array (as excepted), then > with a same brand/type one which I added without a problem. Rebuilding, > everything okay. > > [~] edwin@k7>sudo fdisk -s /dev/ad1 > /dev/ad1: 1938021 cyl 16 hd 63 sec > Part Start Size Type Flags > 1: 63 1953520002 0xa5 0x00 > [~] edwin@k7>sudo fdisk -s /dev/ad3 > /dev/ad3: 1938021 cyl 16 hd 63 sec > Part Start Size Type Flags > 1: 63 1953520002 0xa5 0x80 > > [~] edwin@k7>gmirror status > Name Status Components > mirror/gm0 COMPLETE ad1 > ad3 > > > Until after a reboot, then GEOM complains about: > > GEOM: ad3s1: geometry does not match label (255h,63s != 16h,63s). > GEOM_MIRROR: Force device gm0 start due to timeout. > GEOM_MIRROR: Device mirror/gm0 launched (1/2). > > [~] edwin@k7>gmirror status > Name Status Components > mirror/gm0 DEGRADED ad1 > > Forgetting and re-inserting the ad3 does attach it again and rebuild > everything, until the next reboot. I have one dual PIII machine doing the same to me. I've been assuming my issue is with the ATA controller. But, in case it helps, here is the interesting information from my box. FreeBSD netmon.tcworks.net 7.2-STABLE FreeBSD 7.2-STABLE #2: Fri Dec 4 14:52:34 CST 2009 root@netmon.tcworks.net:/usr/obj/usr/src/sys/GENERIC i386 CPU: Intel(R) Pentium(R) III CPU family 1133MHz (1129.76-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383fbff real memory = 2147483648 (2048 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001025000 - 0x000000007dbaafff, 2092457984 bytes (510854 pages) avail memory = 2091831296 (1994 MB) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 15.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=50 stat1=00 devices=0x9 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 50 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata1: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=50 stat1=00 devices=0x1 ioapic0: routing intpin 15 (ISA IRQ 15) to vector 51 ata1: [MPSAFE] ata1: [ITHREAD] ata0-slave: pio=PIO4 wdma=WDMA2 udma=UNSUPPORTED cable=40 wire ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting PIO4 on ROSB4 chip ad0: setting UDMA33 on ROSB4 chip ad0: 238475MB at ata0-master UDMA33 ad0: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queue ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed acd0: setting PIO4 on ROSB4 chip acd0: CDROM drive at ata0 as slave acd0: 128KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad2: setting PIO4 on ROSB4 chip ad2: setting UDMA33 on ROSB4 chip ad2: 238475MB at ata1-master UDMA33 ad2: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queue ad2: Adaptec check1 failed ad2: LSI (v3) check1 failed ad2: LSI (v2) check1 failed ad2: FreeBSD check1 failed ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00040011 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00000000 err: 0x00010000 pcm: 0x00010400 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 3 to local APIC 1 ioapic0: Assigning ISA IRQ 4 to local APIC 0 ioapic0: Assigning ISA IRQ 6 to local APIC 1 ioapic0: Assigning PCI IRQ 10 to local APIC 0 ioapic0: Assigning ISA IRQ 14 to local APIC 1 ioapic0: Assigning ISA IRQ 15 to local APIC 0 ioapic1: Assigning PCI IRQ 20 to local APIC 1 ioapic1: Assigning PCI IRQ 21 to local APIC 0 GEOM: new disk ad0 GEOM: new disk ad2 GEOM_MIRROR: Device mirror/gm0 launched (2/2). Trying to mount root from ufs:/dev/mirror/gm0s1a start_init: trying /sbin/init 13:41:25 Sun Jun 06 $ bzcat messages.2.bz2 | egrep -i "geom|mirror|ad[[:digit:]]" Dec 11 02:01:34 netmon kernel: Preloaded elf module "/boot/kernel/geom_mirror.ko" at 0xc0e2e174. Dec 11 02:01:34 netmon kernel: pnpbios: handle 10 device ID PNP0a03 (030ad041) Dec 11 02:01:34 netmon kernel: ad0: setting PIO4 on ROSB4 chip Dec 11 02:01:34 netmon kernel: ad0: setting UDMA33 on ROSB4 chip Dec 11 02:01:34 netmon kernel: ad0: 238475MB at ata0-master UDMA33 Dec 11 02:01:34 netmon kernel: ad0: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queue Dec 11 02:01:34 netmon kernel: ad0: Adaptec check1 failed Dec 11 02:01:34 netmon kernel: ad0: LSI (v3) check1 failed Dec 11 02:01:34 netmon kernel: ad0: LSI (v2) check1 failed Dec 11 02:01:34 netmon kernel: ad0: FreeBSD check1 failed Dec 11 02:01:34 netmon kernel: ad2: setting PIO4 on ROSB4 chip Dec 11 02:01:34 netmon kernel: ad2: setting UDMA33 on ROSB4 chip Dec 11 02:01:34 netmon kernel: ad2: 238475MB at ata1-master UDMA33 Dec 11 02:01:34 netmon kernel: ad2: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queue Dec 11 02:01:34 netmon kernel: ad2: Adaptec check1 failed Dec 11 02:01:34 netmon kernel: ad2: LSI (v3) check1 failed Dec 11 02:01:34 netmon kernel: ad2: LSI (v2) check1 failed Dec 11 02:01:34 netmon kernel: ad2: FreeBSD check1 failed Dec 11 02:01:34 netmon kernel: GEOM: new disk ad0 Dec 11 02:01:34 netmon kernel: GEOM: new disk ad2 Dec 11 02:01:34 netmon kernel: GEOM_MIRROR: Device mirror/gm0 launched (2/2). Dec 11 02:01:34 netmon kernel: Trying to mount root from ufs:/dev/mirror/gm0s1a Dec 11 02:01:48 netmon kernel: ad2: setting PIO4 on ROSB4 chip Dec 11 02:01:48 netmon kernel: ad2: setting UDMA33 on ROSB4 chip Dec 11 02:01:48 netmon kernel: ad2: TIMEOUT - READ_DMA retrying (1 retry left) LBA=232068607 Dec 11 02:02:00 netmon kernel: ad2: setting PIO4 on ROSB4 chip Dec 11 02:02:00 netmon kernel: ad2: setting UDMA33 on ROSB4 chip Dec 11 02:02:00 netmon kernel: ad2: TIMEOUT - READ_DMA retrying (1 retry left) LBA=232766751 Dec 11 02:02:10 netmon kernel: ad0: setting PIO4 on ROSB4 chip Dec 11 02:02:10 netmon kernel: ad0: setting UDMA33 on ROSB4 chip Dec 11 02:02:10 netmon kernel: ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=232006207 Dec 11 02:02:36 netmon kernel: ad0: setting PIO4 on ROSB4 chip Dec 11 02:02:36 netmon kernel: ad0: setting UDMA33 on ROSB4 chip Dec 11 02:02:36 netmon kernel: ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=242232479 Dec 11 02:02:37 netmon kernel: ad2: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=242234911 Dec 11 02:02:37 netmon kernel: ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=242235039 Dec 11 02:02:37 netmon kernel: ad2: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=242234911 Dec 11 02:02:37 netmon kernel: ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=242235039 Dec 11 02:02:37 netmon kernel: ad2: FAILURE - READ_DMA status=51 error=84 LBA=242234911 Dec 11 02:02:37 netmon kernel: ad0: FAILURE - READ_DMA status=51 error=84 LBA=242235039 Dec 11 02:02:37 netmon kernel: GEOM_MIRROR: Request failed (error=5). ad2[READ(offset=124024274432, length=65536)] Dec 11 02:02:37 netmon kernel: GEOM_MIRROR: Device gm0: provider ad2 disconnected. Dec 11 02:02:37 netmon kernel: GEOM_MIRROR: Request failed (error=5). ad0[READ(offset=124024339968, length=65536)] Dec 11 02:02:37 netmon kernel: g_vfs_done():mirror/gm0s1e[READ(offset=112213082112, length=131072)]error = 5 Dec 11 02:02:47 netmon kernel: ad0: setting PIO4 on ROSB4 chip Dec 11 02:02:47 netmon kernel: ad0: setting UDMA33 on ROSB4 chip Dec 11 02:02:47 netmon kernel: ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=242234911 Dec 11 02:02:47 netmon kernel: ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=242235039 Dec 11 02:02:47 netmon kernel: ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=242235039 Dec 11 02:02:47 netmon kernel: ad0: FAILURE - READ_DMA status=51 error=84 LBA=242235039 Dec 11 02:02:47 netmon kernel: g_vfs_done():mirror/gm0s1e[READ(offset=112213082112, length=131072)]error = 5 Dec 11 02:02:50 netmon kernel: ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=232478271 Dec 11 02:02:50 netmon kernel: ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=232478271 Dec 11 02:02:50 netmon kernel: ad0: FAILURE - READ_DMA status=51 error=84 LBA=232478271 Dec 11 02:02:50 netmon kernel: g_vfs_done():mirror/gm0s1e[READ(offset=107217682432, length=131072)]error = 5 I have just left it broken this boot. I was annoyed by this issue and a few others which all happend to bite me on Dec 11th, while I was trying to get everything wrapped up for a vacation. 13:44:39 Sun Jun 06 $ geom mirror list Geom name: gm0 State: DEGRADED Components: 2 Balance: split Slice: 4096 Flags: NONE GenID: 2 SyncID: 1 ID: 3839024964 Providers: 1. Name: mirror/gm0 Mediasize: 250059349504 (233G) Sectorsize: 512 Mode: r8w4e5 Consumers: 1. Name: ad0 Mediasize: 250059350016 (233G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY, BROKEN GenID: 2 SyncID: 1 ID: 803371877 I guess I should rebuild it now that you've reminded me. :-) -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org From owner-freebsd-stable@FreeBSD.ORG Sun Jun 6 19:45:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4000C1065670 for ; Sun, 6 Jun 2010 19:45:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id E19EF8FC0A for ; Sun, 6 Jun 2010 19:45:17 +0000 (UTC) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta04.westchester.pa.mail.comcast.net with comcast id Sjig1e0020EZKEL54jlJyR; Sun, 06 Jun 2010 19:45:18 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta01.westchester.pa.mail.comcast.net with comcast id SjlG1e0083S48mS3MjlHxS; Sun, 06 Jun 2010 19:45:17 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 41D949B418; Sun, 6 Jun 2010 12:45:15 -0700 (PDT) Date: Sun, 6 Jun 2010 12:45:15 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org, Edwin Groothuis Message-ID: <20100606194515.GA29230@icarus.home.lan> References: <20100606052509.GA4744@mavetju.org> <20100606185551.GA267@sysmon.tcworks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100606185551.GA267@sysmon.tcworks.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: gmirror refused to connect second disk after a reboot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2010 19:45:18 -0000 On Sun, Jun 06, 2010 at 01:55:51PM -0500, Scott Lambert wrote: > I have one dual PIII machine doing the same to me. I've been assuming > my issue is with the ATA controller. ... > > Dec 11 02:01:48 netmon kernel: ad2: TIMEOUT - READ_DMA retrying (1 retry left) LBA=232068607 > Dec 11 02:02:00 netmon kernel: ad2: setting PIO4 on ROSB4 chip > Dec 11 02:02:00 netmon kernel: ad2: setting UDMA33 on ROSB4 chip > Dec 11 02:02:00 netmon kernel: ad2: TIMEOUT - READ_DMA retrying (1 retry left) LBA=232766751 > Dec 11 02:02:10 netmon kernel: ad0: setting PIO4 on ROSB4 chip > Dec 11 02:02:10 netmon kernel: ad0: setting UDMA33 on ROSB4 chip > Dec 11 02:02:10 netmon kernel: ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=232006207 > Dec 11 02:02:36 netmon kernel: ad0: setting PIO4 on ROSB4 chip > Dec 11 02:02:36 netmon kernel: ad0: setting UDMA33 on ROSB4 chip > Dec 11 02:02:36 netmon kernel: ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=242232479 > Dec 11 02:02:37 netmon kernel: ad2: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=242234911 > Dec 11 02:02:37 netmon kernel: ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=242235039 > Dec 11 02:02:37 netmon kernel: ad2: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=242234911 > Dec 11 02:02:37 netmon kernel: ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=242235039 > Dec 11 02:02:37 netmon kernel: ad2: FAILURE - READ_DMA status=51 error=84 LBA=242234911 > Dec 11 02:02:37 netmon kernel: ad0: FAILURE - READ_DMA status=51 error=84 LBA=242235039 > Dec 11 02:02:37 netmon kernel: GEOM_MIRROR: Request failed (error=5). ad2[READ(offset=124024274432, length=65536)] > Dec 11 02:02:37 netmon kernel: GEOM_MIRROR: Device gm0: provider ad2 disconnected. > Dec 11 02:02:37 netmon kernel: GEOM_MIRROR: Request failed (error=5). ad0[READ(offset=124024339968, length=65536)] > Dec 11 02:02:37 netmon kernel: g_vfs_done():mirror/gm0s1e[READ(offset=112213082112, length=131072)]error = 5 > Dec 11 02:02:47 netmon kernel: ad0: setting PIO4 on ROSB4 chip > Dec 11 02:02:47 netmon kernel: ad0: setting UDMA33 on ROSB4 chip > Dec 11 02:02:47 netmon kernel: ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=242234911 > Dec 11 02:02:47 netmon kernel: ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=242235039 > Dec 11 02:02:47 netmon kernel: ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=242235039 > Dec 11 02:02:47 netmon kernel: ad0: FAILURE - READ_DMA status=51 error=84 LBA=242235039 > Dec 11 02:02:47 netmon kernel: g_vfs_done():mirror/gm0s1e[READ(offset=112213082112, length=131072)]error = 5 > Dec 11 02:02:50 netmon kernel: ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=232478271 > Dec 11 02:02:50 netmon kernel: ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=232478271 > Dec 11 02:02:50 netmon kernel: ad0: FAILURE - READ_DMA status=51 error=84 LBA=232478271 > Dec 11 02:02:50 netmon kernel: g_vfs_done():mirror/gm0s1e[READ(offset=107217682432, length=131072)]error = 5 I agree -- these look like you have either a bad PATA cable, an PATA controller port which has gone bad, or a PATA controller which is behaving *very* badly (internal IC problems). ICRC errors indicate data transmission failures between the controller and the disk. Since these are classic PATA disks, ad0 is probably the master and ad2 is the slave -- but both are probably on the same physical cable. The LBAs for both ad0 and ad2 are very close (ad0=242235039, ad2=242234911), which makes sense since they're in a mirror config. But two disks going kaput at the same time, around the same LBA? I have my doubts. SMART statistics for both of the disks themselves would help determine if the disks are seeing issues or if the disks are also seeing problems communicating with the PATA controller. (Depends on the age of the disks though; some older PATA disks don't have the SMART attribute that describes this). What you should be worried about -- FreeBSD sees problems on both ad0 and ad2. ad2 is offline cuz of the problem, but ad0 isn't. Chances are ad0 is going to fall off the bus eventually because of this problem. I really hope you do backups regularly (daily) if you plan on just ignoring this problem. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jun 6 20:23:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA9881065675 for ; Sun, 6 Jun 2010 20:23:29 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A0DDB8FC1D for ; Sun, 6 Jun 2010 20:23:29 +0000 (UTC) Received: by iwn5 with SMTP id 5so3369302iwn.13 for ; Sun, 06 Jun 2010 13:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=qqvomEQuN8dd6bY7B+3ZL517OVHcKsYIR/B5HCcxT3s=; b=O77BUh5MyjllrSYBLECe1v/lHZWHYrCuGiucGsADzYxUVudYk18t0OTAzLKjF0gxp7 Ch6C/yqVC4ky3K4itSfqWTbd4YYNBR44R5461CTpsL994kFg9kj6B9+18Q+lvmPgoBAj qHBbBNSstV2O174rnSWb2Mt4odgX3pWzHAzmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=g2ePRjsJTC8/w1omvxgrWhRf0ox128SDFdCzkI0LXTyCx7GRrA9dbPQARPn3RdeiyY kMP81qEVNTZb04gI4LwU0wq2nxAPDjY1UUIg/6//+jrrxt/0qkvCXo7w07grvAoQxiXR vf+prF4+6cSfNn6zmW7FNkIz+AIjnqjjc9k1c= MIME-Version: 1.0 Received: by 10.231.190.132 with SMTP id di4mr5304146ibb.41.1275855808735; Sun, 06 Jun 2010 13:23:28 -0700 (PDT) Received: by 10.231.190.131 with HTTP; Sun, 6 Jun 2010 13:23:28 -0700 (PDT) In-Reply-To: References: <20100606031627.GA4742@icarus.home.lan> Date: Sun, 6 Jun 2010 16:23:28 -0400 Message-ID: From: Nick Rogers To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD STABLE , Jeremy Chadwick Subject: Re: arp -na performance w/ many permanent entries X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jun 2010 20:23:30 -0000 On Sat, Jun 5, 2010 at 11:54 PM, Garrett Cooper wrote: > > > I agree with Jeremy. I think that the problem that you've > discovered is the fact that it's using stdio-based buffered output > instead of buffering more of the contents in a string and punting it > out in larger chunks. > HTH, > -Garrett > I don't think so. The performance difference when taking out the interface lookup is huge even though the data output to STDOUT is mostly the same. I'll try the other lists, thanks. From owner-freebsd-stable@FreeBSD.ORG Mon Jun 7 05:15:04 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44F8D1065675 for ; Mon, 7 Jun 2010 05:15:04 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nschwqsrv01p.mx.bigpond.com (nschwqsrv01p.mx.bigpond.com [61.9.189.231]) by mx1.freebsd.org (Postfix) with ESMTP id CAAF08FC14 for ; Mon, 7 Jun 2010 05:15:03 +0000 (UTC) Received: from nschwotgx01p.mx.bigpond.com ([58.172.114.57]) by nschwmtas01p.mx.bigpond.com with ESMTP id <20100607015905.FHEK1369.nschwmtas01p.mx.bigpond.com@nschwotgx01p.mx.bigpond.com> for ; Mon, 7 Jun 2010 01:59:05 +0000 Received: from mail.heuristicsystems.com.au ([58.172.114.57]) by nschwotgx01p.mx.bigpond.com with ESMTP id <20100607015903.OBPB3673.nschwotgx01p.mx.bigpond.com@mail.heuristicsystems.com.au> for ; Mon, 7 Jun 2010 01:59:03 +0000 Received: from white (white.hs [10.0.5.2]) (authenticated bits=0) by mail.heuristicsystems.com.au (8.14.3/8.13.6) with ESMTP id o571wwnR040048 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 7 Jun 2010 11:59:01 +1000 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne Geraghty" To: "'FreeBSD Stable'" References: <4C04B39D.8060503@FreeBSD.org> Date: Mon, 7 Jun 2010 11:57:47 +1000 Message-ID: <329026D0D0CF4D349EB922AF8F731D9D@HS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcsBWlEhQw4V5iY5TLC+OFJKw9hzYgEh1y+w In-Reply-To: <4C04B39D.8060503@FreeBSD.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A090204.4C0C5269.0036,ss=1,fgs=0 X-SIH-MSG-ID: qRswF9T2TAD0zmQv0WC2O1J3yArnq3Mt8ZoaRdJjqwQZTULdvMbOPpX9Y9kEn5720y5MNxCAN2sgZrzmXY7RiA== Cc: Subject: RE: AHCI timeouts - 8.1-PRERELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 05:15:04 -0000 Quick update. Following extensive testing, I've recommended to Alexander, in a longer email, that the default for VIA's VT8251 AHCI Controller be set at AHCI_Q_NOPMP|AHCI_Q_NONCQ Use of ahci in the kernel without this option will result in timeouts, ultimately preventing the machine from performing IO. No timeouts occurred when the ahci driver was removed from the kernel. Approx 35 tests were applied, simultaneously copying a large number of files (~2000) to 8 partitions that ranged in size from 10B to 1.6GB. Testing included single and gmirror disks. The removal of NCQ resulted in a degraded performance of < 8% when compared against EDGEIS, which failed under gmirror testing. Performance under load without NCQ was better than a kernel without ahci. The test was conducted on a VIA SN18000 using two WD500GB-AAKS disks, the disks were repartitioned (gpart) and system rebooted before each test. Regards, Phil. From owner-freebsd-stable@FreeBSD.ORG Mon Jun 7 14:06:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B00A91065677 for ; Mon, 7 Jun 2010 14:06:14 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by mx1.freebsd.org (Postfix) with ESMTP id 30B8F8FC1C for ; Mon, 7 Jun 2010 14:06:13 +0000 (UTC) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.31) with ESMTP id o57E6BkS007693; Mon, 7 Jun 2010 16:06:11 +0200 (MEST) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id 591492E069; Mon, 7 Jun 2010 16:06:11 +0200 (CEST) Date: Mon, 7 Jun 2010 16:06:11 +0200 From: Olaf Seibert To: freebsd-stable@freebsd.org Message-ID: <20100607140611.GX883@twoquid.cs.ru.nl> References: <20100527131310.GS883@twoquid.cs.ru.nl> <20100527174211.GC1211@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100527174211.GC1211@michelle.cdnetworks.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -1.799 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 Cc: Pyun YongHyeon , freebsd-stable@freebsd.org, Olaf Seibert Subject: Re: nfe0 loses network connectivity (8.0-RELEASE-p2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Jun 2010 14:06:14 -0000 On Thu 27 May 2010 at 10:42:11 -0700, Pyun YongHyeon wrote: > On Thu, May 27, 2010 at 03:13:10PM +0200, Olaf Seibert wrote: > > Here is the output of netstat -m while the problem was going on: > > > > 25751/1774/27525 mbufs in use (current/cache/total) > > 24985/615/25600/25600 mbuf clusters in use (current/cache/total/max) > ^^^^^^^^^^^^^^^^^^^^^ > As Jeremy said, it seems you're hitting mbuf shortage situation. I > think nfe(4) is dropping received frames in that case. See how many > packets were dropped due to mbuf shortage from the output of > "netstat -ndI nfe0". You can also use "sysctl dev.nfe.0.stats" to > see MAC statistics maintained in nfe(4) if your MCP controller > supports hardware MAC counters. The sysctl command gives me (among other figures): dev.nfe.0.stats.rx.drops: 338180 so indeed frames seem to be dropped. Jeremy Chadwick mentioned that one can tune kern.ipc.nmbclusters in boot.conf, but apparently it is also changeable at runtime with sysctl. Since the problem recurred today, I increased the value from 25600 to 32768, the maximum recommended value in the Handbook. (I can probably go higher if needed; the box has 8 GB of RAM, although up to half of it is eaten by ZFS) I do get the impression there is a mbuf leak somehow. On a much older file server (FreeBSD 6.1, serves a bit of NFS but has no ZFS) the mbuf cluster useage is much lower, despite a longer uptime: 256/634/890/25600 mbuf clusters in use (current/cache/total/max) Also, it shows signs that measures are taken in case of mbuf shortage: 2259806/466391/598621 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 1016 calls to protocol drain routines whereas the FreeBSD 8.0 machine has zero or very low numbers: 0/3956/1959 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0 calls to protocol drain routines and useage keeps growing: 26122/1782/27904/32768 mbuf clusters in use (current/cache/total/max) -Olaf. -- From owner-freebsd-stable@FreeBSD.ORG Mon Jun 7 19:48:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 337D51065674 for ; Mon, 7 Jun 2010 19:48:52 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id AEDA68FC13 for ; Mon, 7 Jun 2010 19:48:51 +0000 (UTC) Received: by fxm20 with SMTP id 20so2922541fxm.13 for ; Mon, 07 Jun 2010 12:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :x-comment-to:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=la+PsLpe1/VPfCe+q3fn0ksSvMrB7xGdZgIBBchEFPQ=; b=JerUX5cRdBlYoZZRFuhmKMEiVF5rwv+w0yZgIIZpKeycd4cWyzjeRl2TeKMgpbPjNK vf87C+o2Jlpi87NzIne/50VnyTf6IHpBHzwaZSQoU/mo73l4ZW27wPtZSnS+E3SEsv3k C2fYnriqzyf7bYu2iZa7Fn78rnp3SXlMd9QZc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=E4lCox1GfUESMWU7f01g2oyRNu9nXwo+hNDu0yRj/y2xSHo1kW08hVp5aykZWVRoV6 UUbv4Qc0A5yIxuuGosiiQJuIwqRcv6yNipekgJoBSg7D7+ysCXJSYh+oUZw5U+a9trQI 8ime3ob5CiaGWMRDJHwQ6A6eeI0Om+qDm7Rrg= Received: by 10.204.163.66 with SMTP id z2mr7081951bkx.9.1275940130525; Mon, 07 Jun 2010 12:48:50 -0700 (PDT) Received: from localhost ([95.69.167.97]) by mx.google.com with ESMTPS id z7sm21103413bkx.5.2010.06.07.12.48.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Jun 2010 12:48:49 -0700 (PDT) From: Mikolaj Golub To: Olaf Seibert References: <20100527131310.GS883@twoquid.cs.ru.nl> <20100527174211.GC1211@michelle.cdnetworks.com> <20100607140611.GX883@twoquid.cs.ru.nl> X-Comment-To: Olaf Seibert Date: Mon, 07 Jun 2010 22:48:46 +0300 In-Reply-To: <20100607140611.GX883@twoquid.cs.ru.nl> (Olaf Seibert's message of "Mon, 7 Jun 2010 16:06:11 +0200") Message-ID: <86mxv6wrmp.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Pyun YongHyeon , freebsd-stable@freebsd.org Subject: Re: nfe0 loses network connectivity (8.0-RELEASE-p2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Jun 2010 19:48:52 -0000 On Mon, 7 Jun 2010 16:06:11 +0200 Olaf Seibert wrote: OS> I do get the impression there is a mbuf leak somehow. On a much older OS> file server (FreeBSD 6.1, serves a bit of NFS but has no ZFS) the mbuf OS> cluster useage is much lower, despite a longer uptime: OS> 256/634/890/25600 mbuf clusters in use (current/cache/total/max) OS> Also, it shows signs that measures are taken in case of mbuf shortage: OS> 2259806/466391/598621 requests for mbufs denied (mbufs/clusters/mbuf+clusters) OS> 1016 calls to protocol drain routines OS> whereas the FreeBSD 8.0 machine has zero or very low numbers: OS> 0/3956/1959 requests for mbufs denied (mbufs/clusters/mbuf+clusters) OS> 0 calls to protocol drain routines OS> and useage keeps growing: OS> 26122/1782/27904/32768 mbuf clusters in use (current/cache/total/max) It looks like the issue that has been fixed in STABLE. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/144330 -- Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Mon Jun 7 21:46:17 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32C54106566B for ; Mon, 7 Jun 2010 21:46:17 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id E37D38FC12 for ; Mon, 7 Jun 2010 21:46:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 2F1B765B8; Mon, 7 Jun 2010 23:46:15 +0200 (CEST) Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id r3RK9ghsfQG1; Mon, 7 Jun 2010 23:46:14 +0200 (CEST) Received: from Tom-iMac.local (dmhd.bsdunix.ch [82.220.17.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 1F3AA65B3; Mon, 7 Jun 2010 23:46:14 +0200 (CEST) Message-ID: <4C0D68A6.6090705@bsdunix.ch> Date: Mon, 07 Jun 2010 23:46:14 +0200 From: Thomas User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: d@delphij.net References: <4C0839CB.2070802@bsdunix.ch> <4C084006.5060702@delphij.net> In-Reply-To: <4C084006.5060702@delphij.net> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, Xin LI Subject: Re: Is crunchgen broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 07 Jun 2010 21:46:17 -0000 Am 04.06.10 01:51, schrieb Xin LI: > On 2010/06/03 16:24, Thomas wrote: >> Hello > >> I tryed to use crunchgen. It's not working for me. I always get a >> NFS4ACL error. > >> root@bert:/usr/src/release/i386# crunchgen boot_crunch.conf >> Run "make -f boot_crunch.mk" to build crunched binary. > >> (cd /usr/src/sbin/tunefs && make -DRELEASE_CRUNCH -Dlint depend && >> make -DRELEASE_CRUNCH -Dlint tunefs.o) >> cc -mtune=native -O2 -fno-strict-aliasing -pipe -march=native -std=gnu99 >> -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k >> -Wno-uninitialized -Wno-pointer-sign -c /usr/src/sbin/tunefs/tunefs.c >> /usr/src/sbin/tunefs/tunefs.c: In function 'main': >> /usr/src/sbin/tunefs/tunefs.c:274: error: 'FS_NFS4ACLS' undeclared >> (first use in this function) >> /usr/src/sbin/tunefs/tunefs.c:274: error: (Each undeclared identifier is >> reported only once >> /usr/src/sbin/tunefs/tunefs.c:274: error: for each function it appears in.) >> /usr/src/sbin/tunefs/tunefs.c: In function 'printfs': >> /usr/src/sbin/tunefs/tunefs.c:475: error: 'FS_NFS4ACLS' undeclared >> (first use in this function) >> *** Error code 1 > > Just a guess - did you have done a full build and 'make installworld'? I updated everything to 8.1-PRERELEASE #0: Fri Jun 4 01:44:00 CEST 2010 make buildworld, make kernel, make installworld, mergemaster, reboot I still see: unefs.c: In function 'main': tunefs.c:274: error: 'FS_NFS4ACLS' undeclared (first use in this function) tunefs.c:274: error: (Each undeclared identifier is reported only once tunefs.c:274: error: for each function it appears in.) tunefs.c: In function 'printfs': tunefs.c:475: error: 'FS_NFS4ACLS' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sbin/tunefs. *** Error code 1 Cheers, Thomas From owner-freebsd-stable@FreeBSD.ORG Mon Jun 7 23:11:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 850E91065670 for ; Mon, 7 Jun 2010 23:11:19 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 53CD48FC18 for ; Mon, 7 Jun 2010 23:11:19 +0000 (UTC) Received: by pvh11 with SMTP id 11so2119204pvh.13 for ; Mon, 07 Jun 2010 16:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=y4BNAw5RLBydo6EWgcU+n7PixvbBR+3y5ioq9JbmmwQ=; b=tyVG5da2novwO8qBBTMu6aL8JuvIIDjo4G3mMZLUvEhC46n6MHsQAKKZ46si2/QmVa el8wjb8A4Di/CpKn9AdtIBTbwFmXAqBFbMDgHD5B1C7ZDE6irm7VNFR9wsTZTnF0zels VdG8rLXCF7O7S6ZAiuqZf8rj6jgfOpDpBlwrM= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=P2Z9B5AaHHl+6Q34uAin/BdWjOM/SQQtJTeo/LwKcVeG+7YsIS73YyaJbp0QxrrzVH m9PE0mUGDtu1jpbt9W1QZ+cQV63DkO2mgvbCxYBM9EstPMTPmpfnDfX8iDtq8ABLRr+A dQDuTjZY7gPmjzWZzo4fRVoDm7MG6DuJAXX9k= Received: by 10.114.215.30 with SMTP id n30mr12205875wag.27.1275952278797; Mon, 07 Jun 2010 16:11:18 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id c22sm42728420wam.18.2010.06.07.16.11.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Jun 2010 16:11:18 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 7 Jun 2010 16:09:55 -0700 From: Pyun YongHyeon Date: Mon, 7 Jun 2010 16:09:55 -0700 To: Olaf Seibert Message-ID: <20100607230955.GD1369@michelle.cdnetworks.com> References: <20100527131310.GS883@twoquid.cs.ru.nl> <20100527174211.GC1211@michelle.cdnetworks.com> <20100607140611.GX883@twoquid.cs.ru.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100607140611.GX883@twoquid.cs.ru.nl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: nfe0 loses network connectivity (8.0-RELEASE-p2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 23:11:19 -0000 On Mon, Jun 07, 2010 at 04:06:11PM +0200, Olaf Seibert wrote: > On Thu 27 May 2010 at 10:42:11 -0700, Pyun YongHyeon wrote: > > On Thu, May 27, 2010 at 03:13:10PM +0200, Olaf Seibert wrote: > > > Here is the output of netstat -m while the problem was going on: > > > > > > 25751/1774/27525 mbufs in use (current/cache/total) > > > 24985/615/25600/25600 mbuf clusters in use (current/cache/total/max) > > ^^^^^^^^^^^^^^^^^^^^^ > > As Jeremy said, it seems you're hitting mbuf shortage situation. I > > think nfe(4) is dropping received frames in that case. See how many > > packets were dropped due to mbuf shortage from the output of > > "netstat -ndI nfe0". You can also use "sysctl dev.nfe.0.stats" to > > see MAC statistics maintained in nfe(4) if your MCP controller > > supports hardware MAC counters. > > The sysctl command gives me (among other figures): > > dev.nfe.0.stats.rx.drops: 338180 > > so indeed frames seem to be dropped. > > Jeremy Chadwick mentioned that one can tune kern.ipc.nmbclusters in > boot.conf, but apparently it is also changeable at runtime with sysctl. > > Since the problem recurred today, I increased the value from 25600 to > 32768, the maximum recommended value in the Handbook. (I can probably go > higher if needed; the box has 8 GB of RAM, although up to half of it is > eaten by ZFS) > > I do get the impression there is a mbuf leak somehow. On a much older > file server (FreeBSD 6.1, serves a bit of NFS but has no ZFS) the mbuf > cluster useage is much lower, despite a longer uptime: > Yeah, it surely indicates mbuf leakage in kernel. There was no mbuf leakage report in nfe(4) so I think the leakage is in other part of kernel. As Mikolaj said, it would be great if you give the latest stable/8 try and let us know whether the issue was fixed or not. > 256/634/890/25600 mbuf clusters in use (current/cache/total/max) > > Also, it shows signs that measures are taken in case of mbuf shortage: > > 2259806/466391/598621 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 1016 calls to protocol drain routines > > whereas the FreeBSD 8.0 machine has zero or very low numbers: > > 0/3956/1959 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0 calls to protocol drain routines > > and useage keeps growing: > > 26122/1782/27904/32768 mbuf clusters in use (current/cache/total/max) > > -Olaf. > -- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 09:11:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F003106566C for ; Tue, 8 Jun 2010 09:11:50 +0000 (UTC) (envelope-from kasahara@nc.kyushu-u.ac.jp) Received: from elvenbow.cc.kyushu-u.ac.jp (unknown [IPv6:2001:200:905:1407:21b:21ff:fe52:5260]) by mx1.freebsd.org (Postfix) with ESMTP id CE2D18FC08 for ; Tue, 8 Jun 2010 09:11:49 +0000 (UTC) Received: from localhost (kasahara@localhost [IPv6:::1]) by elvenbow.cc.kyushu-u.ac.jp (8.14.4/8.14.4) with ESMTP id o589BlsW051847 for ; Tue, 8 Jun 2010 18:11:47 +0900 (JST) (envelope-from kasahara@nc.kyushu-u.ac.jp) Date: Tue, 08 Jun 2010 18:11:46 +0900 (JST) Message-Id: <20100608.181146.1224841629154014733.kasahara@nc.kyushu-u.ac.jp> To: freebsd-stable@freebsd.org From: Yoshiaki Kasahara In-Reply-To: <4BE82C5D.1080806@bit0.com> References: <4BE110E3.8040902@zirakzigil.org> <4BE82C5D.1080806@bit0.com> X-Fingerprint: CDA2 B6B6 6796 0DD3 9D80 2602 E909 4623 A15E A074 X-URL: http://rd.cc.kyushu-u.ac.jp/~kasahara/ X-Mailer: Mew version 7.0.50 on Emacs 24.0.50 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 09:11:50 -0000 Hello, I'd like to add another instance of similar problems. I recently updated my FreeBSD amd64 box with ZFS root and 8GB RAM from 8-STABLE (as of Mar 1st) to 8.1-PRERELEASE (as of May 27th). After that, my box started to crash every couple of days due to kmem_map too small. Here is a (last week) screenshot of Munin graph about the memory usage of the box: http://eron.info/munin-memory.png In "by month" graph, a white gap at the end of "Week 20" is the update period from 8-STABLE to 8.1-PRERELEASE I mentioned above. Before the upgrade, the system was rock solid without any kmem tuning in loader.conf (vm.kmem_size was around 2.7GB IIRC). After the update, I could see that more wired memory was assigned, and then steep drop (crash) occured. "by day" graph shows my experiment to bump vm.kmem_size=12G (recommended somewhere in this thread) and explicitly limit vfs.zfs.arc_max=2G. I was surprised because the wired memory quickly increased over 5GB... Then I noticed that the default value of vfs.zfs.zio.use_uma was 1 on amd64, so I turned it off and removed other memory tunings (kmem_size and arc_max) in loader.conf on Tuesday at 16:00 and rebooted. It seems that the usage of wired memory was stablized and no crash since then with the default kmem_size and arc_max. Does anyone have any idea about this behavior? My wild guess is that ZFS/UMA code is not stable on amd64 too, and it should be turned off by default for 8.1-RELEASE maybe.... Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasahara@nc.kyushu-u.ac.jp From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 09:30:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09470106566C for ; Tue, 8 Jun 2010 09:30:34 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 994A28FC18 for ; Tue, 8 Jun 2010 09:30:33 +0000 (UTC) Received: by wwb22 with SMTP id 22so4340031wwb.13 for ; Tue, 08 Jun 2010 02:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=giyAut/8AJQ61rl0EmwsXgcI4UX8FieaIMF7Vs/xHic=; b=uOeeHDqjWbLWN5d+WNmcgm3u2J/AoHnvTivWdHvywwOTiwb4kVw1CSmBR6YJ/OGiFz dhZEXgLJb6O3I5mWCykGgarAkbyqNmIBazK93a9jeRL+LLZu4b4VAfwfx/kmGY5qZ6bs IbJvTXVHWgTIp65ONn2mj81vW3ftMKECVx/4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=mm0Pc2ao9m7dw5Sb1xc4vKUDXyDIjwhoQKs9a0tQNALueLoLyzbV/3SXsGFcc6Vr0Z aelqZzbb1vf+P8XZIzAJ9meaU+sZbwZuCB1D35MAx8H+gcRCSbDrgK+vaTs4FYpleiUj GD9B6mgbKLP6nZVff6qNgEnnfjwYTB15PG+mE= MIME-Version: 1.0 Received: by 10.227.144.147 with SMTP id z19mr3955228wbu.159.1275989431326; Tue, 08 Jun 2010 02:30:31 -0700 (PDT) Received: by 10.216.51.78 with HTTP; Tue, 8 Jun 2010 02:30:30 -0700 (PDT) Date: Tue, 8 Jun 2010 13:30:30 +0400 Message-ID: From: pluknet To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Subject: mfiutil create .. leads to deadlock in 6-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 09:30:34 -0000 hi, I faced w/ subj. issue on IBM ServeRAID M5015 (LSISAS2108 SAS2.0 6Gbps). As I can see, lockup is caused by sleeping on sx lock after Giant was acquired. Can r160217 help me or am I go the wrong way? from r160217: "Use a sleep mutex instead of an sx lock for the kernel environment." after `# mfiutil create raid5 8,9,10,11,12,13` db> bt 924 Tracing pid 924 tid 100156 td 0xc6fcb340 sched_switch(c6fcb340,0,2) at sched_switch+0x15b mi_switch(2,0,c0ac4020,0,c09b478a,...) at mi_switch+0x270 critical_exit(1,c6fcb340,c677d88a,b,a,...) at critical_exit+0x8b intr_execute_handlers(c67ae678,ed2f16a8,10,ed2f1838,c09141e3,...) at intr_execute_handlers+0x129 lapic_handle_intr(36) at lapic_handle_intr+0x2e Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc06d2c2f, esp = 0xed2f16ec, ebp = 0xed2f1838 --- vsscanf(c677d880,c09b523b,ed2f1864,ed2f1944,c06cd5c9,...) at vsscanf+0x123 sscanf(c677d880,c09b523b,ed2f1918,ed2f1874,ed2f18f8,...) at sscanf+0x12 res_find(ed2f19c8,0,c0993cb1,ed2f19dc,c09b5c62,0,0,0,0,0,0,ed2f19cc) at res_find+0x225 resource_find(ed2f19c8,0,c0993cb1,ed2f19dc,c09b5c62,0,0,0,0,0,0,ed2f19cc) at resource_find+0x3b resource_int_value(c0993cb1,0,c09b5c62,c6f5843c) at resource_int_value+0x32 device_probe_child(c695d200,c6f58400) at device_probe_child+0xc5 device_probe_and_attach(c6f58400) at device_probe_and_attach+0x7d bus_generic_attach(c695d200,c6f58400,c0993995,c6f58400,c6cb8800,...) at bus_generic_attach+0x16 mfi_add_ld_complete(c697b130,c697b130,c6cb8800,0,c6974400,...) at mfi_add_ld_complete+0xe5 mfi_add_ld(c6974400,0) at mfi_add_ld+0xcc mfi_ldprobe(c6974400) at mfi_ldprobe+0xfe mfi_check_command_post(c6974400,c697ad70,eae97080,c700d0c0,34) at mfi_check_command_post+0x1b6 mfi_user_command(c6974400,c700d0c0,2,c09b478a,27d,...) at mfi_user_command+0x1a4 mfi_ioctl(c6963900,c03c4366,c700d0c0,3,c6fcb340,...) at mfi_ioctl+0x790 devfs_ioctl_f(c70092d0,c03c4366,c700d0c0,c6d37000,c6fcb340) at devfs_ioctl_f+0xaf ioctl(c6fcb340,ed2f1d04) at ioctl+0x396 syscall(3b,3b,3b,bfbfeaa0,240,...) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28150877, esp = 0xbfbfea8c, ebp = 0xbfbfeaf8 --- db> all cpus in idle db> show alllocks Process 924 (mfiutil) thread 0xc6fcb340 (100156) shared sx kernel environment r = 0 (0xc0ac2140) locked @ /usr/src/sys/kern/subr_hints.c:117 exclusive sleep mutex Giant r = 0 (0xc0ac4060) locked @ /usr/src/sys/dev/mfi/mfi.c:1329 exclusive sx MFI config r = 0 (0xc6974578) locked @ /usr/src/sys/dev/mfi/mfi.c:1737 -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 09:54:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84549106568B for ; Tue, 8 Jun 2010 09:54:45 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3641E8FC16 for ; Tue, 8 Jun 2010 09:54:44 +0000 (UTC) Received: by vws4 with SMTP id 4so3505583vws.13 for ; Tue, 08 Jun 2010 02:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=zqliBgZ39yLTF0Q0iFvs+giSr8F2Ei09y/IXmwHqY58=; b=dw8IVSnFxY88WSAEpnOO0KbxzhypccaMK8rZewvb74kw4dauwlAiJuXG1FO7LT2/KB YDi/AvuyAg+RmKN575O3gBwLnrarUiRSmZUEHVzp0MOc5zIrbox6Y87KV0GdbzX5clgC X66iToAi8fMYhg4EZ3/hlAuIj4ZhOfJPIgA7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aEaPha9njZEwFCffzUhuIlbObPvuOCuwlOO+i5GWXlaj4vDIuG1hagDHST8eXG+5Y4 6yy3K4Ca/Y8VfCQdrKrNuxGRU43VTapmkWuWHh0U6Rh/5nFY8ZmjFtpAHxS7osSMdUwY T9utGIM6nTouoe62NPphFFaGkh5K2NT+ep3E0= MIME-Version: 1.0 Received: by 10.224.26.193 with SMTP id f1mr9198077qac.83.1275990883866; Tue, 08 Jun 2010 02:54:43 -0700 (PDT) Received: by 10.229.233.74 with HTTP; Tue, 8 Jun 2010 02:54:43 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Jun 2010 02:54:43 -0700 Message-ID: From: Garrett Cooper To: pluknet Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable Subject: Re: mfiutil create .. leads to deadlock in 6-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 09:54:45 -0000 On Tue, Jun 8, 2010 at 2:30 AM, pluknet wrote: > hi, > > I faced w/ subj. issue on IBM ServeRAID M5015 (LSISAS2108 SAS2.0 6Gbps). > > As I can see, lockup is caused by sleeping on sx lock after Giant was acquired. > Can r160217 help me or am I go the wrong way? > from r160217: "Use a sleep mutex instead of an sx lock for the kernel > environment." Where are you coming from :)? Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 09:54:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46A59106568E for ; Tue, 8 Jun 2010 09:54:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 2C2318FC18 for ; Tue, 8 Jun 2010 09:54:45 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta11.emeryville.ca.mail.comcast.net with comcast id TMrD1e00117UAYkABMul9n; Tue, 08 Jun 2010 09:54:45 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta13.emeryville.ca.mail.comcast.net with comcast id TMuk1e0063S48mS8ZMulLf; Tue, 08 Jun 2010 09:54:45 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8EAC19B418; Tue, 8 Jun 2010 02:54:44 -0700 (PDT) Date: Tue, 8 Jun 2010 02:54:44 -0700 From: Jeremy Chadwick To: Yoshiaki Kasahara Message-ID: <20100608095444.GA86953@icarus.home.lan> References: <4BE110E3.8040902@zirakzigil.org> <4BE82C5D.1080806@bit0.com> <20100608.181146.1224841629154014733.kasahara@nc.kyushu-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100608.181146.1224841629154014733.kasahara@nc.kyushu-u.ac.jp> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: pjd@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 09:54:46 -0000 On Tue, Jun 08, 2010 at 06:11:46PM +0900, Yoshiaki Kasahara wrote: > Hello, > > I'd like to add another instance of similar problems. I recently > updated my FreeBSD amd64 box with ZFS root and 8GB RAM from 8-STABLE > (as of Mar 1st) to 8.1-PRERELEASE (as of May 27th). After that, my > box started to crash every couple of days due to kmem_map too small. > > Here is a (last week) screenshot of Munin graph about the memory usage > of the box: > > http://eron.info/munin-memory.png > > In "by month" graph, a white gap at the end of "Week 20" is the update > period from 8-STABLE to 8.1-PRERELEASE I mentioned above. Before the > upgrade, the system was rock solid without any kmem tuning in > loader.conf (vm.kmem_size was around 2.7GB IIRC). > > After the update, I could see that more wired memory was assigned, and > then steep drop (crash) occured. > > "by day" graph shows my experiment to bump vm.kmem_size=12G > (recommended somewhere in this thread) and explicitly limit > vfs.zfs.arc_max=2G. I was surprised because the wired memory quickly > increased over 5GB... > > Then I noticed that the default value of vfs.zfs.zio.use_uma was 1 on > amd64, so I turned it off and removed other memory tunings (kmem_size > and arc_max) in loader.conf on Tuesday at 16:00 and rebooted. It > seems that the usage of wired memory was stablized and no crash since > then with the default kmem_size and arc_max. > > Does anyone have any idea about this behavior? > > My wild guess is that ZFS/UMA code is not stable on amd64 too, and it > should be turned off by default for 8.1-RELEASE maybe.... I realise you're talking about amd64, but I'm not sure how UMA is getting enabled on i386 to begin with. It does look like it's enabled on amd64 by default. src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -- #if defined(__amd64__) static int zio_use_uma = 1; #else static int zio_use_uma = 0; #endif SYSCTL_DECL(_vfs_zfs); SYSCTL_NODE(_vfs_zfs, OID_AUTO, zio, CTLFLAG_RW, 0, "ZFS ZIO"); TUNABLE_INT("vfs.zfs.zio.use_uma", &zio_use_uma); SYSCTL_INT(_vfs_zfs_zio, OID_AUTO, use_uma, CTLFLAG_RDTUN, &zio_use_uma, 0, "Use uma(9) for ZIO allocations"); Also note that this tunable does not appear in sysctl -a output; I believe this is caused by the first parameter to SYSCTL_INT() being incorrect -- should be _vfs_zfs, not _vfs_zfs_zio. Regardless of that, it's still adjustable in loader.conf. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 10:02:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E1FB1065675 for ; Tue, 8 Jun 2010 10:02:04 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C7A088FC17 for ; Tue, 8 Jun 2010 10:02:03 +0000 (UTC) Received: by wyi11 with SMTP id 11so563251wyi.13 for ; Tue, 08 Jun 2010 03:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=sNqneQssjrvfJDi+cjOd93T7sZzjvoQrOuMMKdE22DE=; b=iRX40bc3dkn9IZc4yn/fr//V23LZgeVmSLHJ+BQ3q0vDncwTZrNM7qyqp4saZGtRVk 4bLusNjNQ475iBXaxa9mNTVnWGbd7ZVo2CwsYcFccTW7eRfQ9n9jLnisXYneStMw9aXa 6+wrspFcpvbEvnCEzyarJ5sESvIIQv4qOynxo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oLLmke4jMWfKOPQjDrqRh+2yI8nzRFJWuKTovq3YLKDtHlTTpTDStSx/g6tXlIxrcF jPr2jA85sdNP1065EvZTa54vtG2bi28ROXz5bjl9DQ7my1cR0TkWNShQfCpre8xgGa8F PFwrKWVClw5w3CdCD5ciurQ4NjtqXtM96G0Q0= MIME-Version: 1.0 Received: by 10.227.136.147 with SMTP id r19mr3932120wbt.218.1275991320587; Tue, 08 Jun 2010 03:02:00 -0700 (PDT) Received: by 10.216.51.78 with HTTP; Tue, 8 Jun 2010 03:02:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Jun 2010 14:02:00 +0400 Message-ID: From: pluknet To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable Subject: Re: mfiutil create .. leads to deadlock in 6-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 10:02:04 -0000 On 8 June 2010 13:54, Garrett Cooper wrote: > On Tue, Jun 8, 2010 at 2:30 AM, pluknet wrote: >> hi, >> >> I faced w/ subj. issue on IBM ServeRAID M5015 (LSISAS2108 SAS2.0 6Gbps). >> >> As I can see, lockup is caused by sleeping on sx lock after Giant was acquired. >> Can r160217 help me or am I go the wrong way? >> from r160217: "Use a sleep mutex instead of an sx lock for the kernel >> environment." > > Where are you coming from :)? >From large legacy land. Hi there. -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 10:20:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 808AC1065674 for ; Tue, 8 Jun 2010 10:20:50 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id BC8CD8FC08 for ; Tue, 8 Jun 2010 10:20:49 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 9C13B45C98; Tue, 8 Jun 2010 12:20:47 +0200 (CEST) Received: from localhost (pdawidek.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id A5153456B1; Tue, 8 Jun 2010 12:20:41 +0200 (CEST) Date: Tue, 8 Jun 2010 12:20:36 +0200 From: Pawel Jakub Dawidek To: Jeremy Chadwick Message-ID: <20100608102036.GD1789@garage.freebsd.pl> References: <4BE110E3.8040902@zirakzigil.org> <4BE82C5D.1080806@bit0.com> <20100608.181146.1224841629154014733.kasahara@nc.kyushu-u.ac.jp> <20100608095444.GA86953@icarus.home.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9l24NVCWtSuIVIod" Content-Disposition: inline In-Reply-To: <20100608095444.GA86953@icarus.home.lan> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 10:20:50 -0000 --9l24NVCWtSuIVIod Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 08, 2010 at 02:54:44AM -0700, Jeremy Chadwick wrote: > SYSCTL_DECL(_vfs_zfs); > SYSCTL_NODE(_vfs_zfs, OID_AUTO, zio, CTLFLAG_RW, 0, "ZFS ZIO"); > TUNABLE_INT("vfs.zfs.zio.use_uma", &zio_use_uma); > SYSCTL_INT(_vfs_zfs_zio, OID_AUTO, use_uma, CTLFLAG_RDTUN, &zio_use_uma, = 0, > "Use uma(9) for ZIO allocations"); >=20 > Also note that this tunable does not appear in sysctl -a output; I > believe this is caused by the first parameter to SYSCTL_INT() being > incorrect -- should be _vfs_zfs, not _vfs_zfs_zio. Regardless of > that, it's still adjustable in loader.conf. Why? I create vfs.zfs.zio node and create vfs.zfs.zio.use_uma sysctl to match tunable name. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --9l24NVCWtSuIVIod Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwOGXQACgkQForvXbEpPzSitACg6K/Ov2//Tiq5bJbfjubQi83p AJIAoMTMwOaEIMPw0v1AkJCGqD4KW/s4 =sp6L -----END PGP SIGNATURE----- --9l24NVCWtSuIVIod-- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 10:26:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF4261065676; Tue, 8 Jun 2010 10:26:47 +0000 (UTC) (envelope-from kasahara@nc.kyushu-u.ac.jp) Received: from elvenbow.cc.kyushu-u.ac.jp (unknown [IPv6:2001:200:905:1407:21b:21ff:fe52:5260]) by mx1.freebsd.org (Postfix) with ESMTP id 3E0388FC1A; Tue, 8 Jun 2010 10:26:47 +0000 (UTC) Received: from localhost (kasahara@localhost [IPv6:::1]) by elvenbow.cc.kyushu-u.ac.jp (8.14.4/8.14.4) with ESMTP id o58AQjTM077659; Tue, 8 Jun 2010 19:26:45 +0900 (JST) (envelope-from kasahara@nc.kyushu-u.ac.jp) Date: Tue, 08 Jun 2010 19:26:45 +0900 (JST) Message-Id: <20100608.192645.266793829033956713.kasahara@nc.kyushu-u.ac.jp> To: freebsd@jdc.parodius.com From: Yoshiaki Kasahara In-Reply-To: <20100608095444.GA86953@icarus.home.lan> References: <4BE82C5D.1080806@bit0.com> <20100608.181146.1224841629154014733.kasahara@nc.kyushu-u.ac.jp> <20100608095444.GA86953@icarus.home.lan> X-Fingerprint: CDA2 B6B6 6796 0DD3 9D80 2602 E909 4623 A15E A074 X-URL: http://rd.cc.kyushu-u.ac.jp/~kasahara/ X-Mailer: Mew version 7.0.50 on Emacs 24.0.50 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pjd@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 10:26:47 -0000 On Tue, 8 Jun 2010 02:54:44 -0700, Jeremy Chadwick said: > I realise you're talking about amd64, but I'm not sure how UMA is > getting enabled on i386 to begin with. It does look like it's enabled > on amd64 by default. I believe that this thread had been started before this tunable was introduced on May 24th. Before that, ZIO_USE_UMA was used to control the use of UMA, and it was enabled unconditionally in /usr/src/sys/modules/zfs. -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasahara@nc.kyushu-u.ac.jp From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 10:56:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4CCA1065673 for ; Tue, 8 Jun 2010 10:56:03 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id F0CB98FC17 for ; Tue, 8 Jun 2010 10:56:02 +0000 (UTC) Received: by wyi11 with SMTP id 11so606720wyi.13 for ; Tue, 08 Jun 2010 03:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=adQAKti83130o7g4PMCdyM6qCdAkoNaX6/ScLDX5XmE=; b=ncKHaE3I47+L7BD4JdTU2BXvmfYlQ4ImuR4YKgEALlCu5c/ndTSLRXNYnM+8u7S0/J EIbL0rb1WLNK+ITAnf7qajk8ueL1DPIoTs8LyKH5n0/DIDcGZjzJW3dcMPUQ0QpxShFj 7pd8PulVsaNeXCteM4oxkObq3dG2I79mliHzc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=adeE6yY2PZinpXbtYahr8s1zYgWz2l9VkN627uKVTTzA+OjO1IoBPwfP46963gIcjN 3QlxCVY5B0ctWuiZIXoQHQWYRDiQV58rhdzmesf9tieLyuKIM268yGbmtD910sToWfVe h/mifK1uaHUnDSqwQBGaR6hpvRoAHfZveZgnA= MIME-Version: 1.0 Received: by 10.227.142.210 with SMTP id r18mr26668wbu.81.1275994561898; Tue, 08 Jun 2010 03:56:01 -0700 (PDT) Received: by 10.216.51.78 with HTTP; Tue, 8 Jun 2010 03:56:01 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Jun 2010 14:56:01 +0400 Message-ID: From: pluknet To: freebsd-stable Content-Type: multipart/mixed; boundary=0016367fb71198ea3f048882a2c3 Subject: Re: mfiutil create .. leads to deadlock in 6-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 10:56:03 -0000 --0016367fb71198ea3f048882a2c3 Content-Type: text/plain; charset=ISO-8859-1 On 8 June 2010 13:30, pluknet wrote: > hi, > > I faced w/ subj. issue on IBM ServeRAID M5015 (LSISAS2108 SAS2.0 6Gbps). Also, subj FreeBSD version has general instability namely w/ this controller (another issue). It locks up every time immediately after: <118>Starting sshd. <118>Starting cron. <118>cron: can't open or create /var/run/cron.pid: Operation not supported <118>Local package initialization: <118>. <118>Starting background file system checks in 60 seconds. ^^ here I've collected alltrace if that makes sense (attached). show alllocks produces nothing here. -- wbr, pluknet --0016367fb71198ea3f048882a2c3 Content-Type: application/octet-stream; name=typescript Content-Disposition: attachment; filename=typescript Content-Transfer-Encoding: base64 X-Attachment-Id: f_ga6m41bi0 VHJhY2luZyBjb21tYW5kIHNzaGQgcGlkIDc1MSB0aWQgMTAwMTE5IHRkIDB4YzZlMDgzNDANCnNj aGVkX3N3aXRjaChjNmUwODM0MCwwLDEpIGF0IHNjaGVkX3N3aXRjaCsweDE1Yg0KbWlfc3dpdGNo KDEsMCkgYXQgbWlfc3dpdGNoKzB4MjcwDQpzbGVlcHFfc3dpdGNoKGMwYjE2NTA0KSBhdCBzbGVl cHFfc3dpdGNoKzB4YzENCnNsZWVwcV93YWl0X3NpZyhjMGIxNjUwNCwyNDYsYzBhYzQwODAsYzA5 Yjc5YWMsMzAzLC4uLikgYXQgc2xlZXBxX3dhaXRfc2lnKzB4MWQNCmN2X3dhaXRfc2lnKGMwYjE2 NTA0LGMwYjE2NGUwKSBhdCBjdl93YWl0X3NpZysweDE4Yg0Ka2Vybl9zZWxlY3QoYzZlMDgzNDAs NSw4MDdiOTIwLDAsMCwuLi4pIGF0IGtlcm5fc2VsZWN0KzB4NGJmDQpzZWxlY3QoYzZlMDgzNDAs ZWQyODZkMDQpIGF0IHNlbGVjdCsweDQ0DQpzeXNjYWxsKDNiLDNiLDNiLDEsYSwuLi4pIGF0IHN5 c2NhbGwrMHgyMmYNClhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MWYN Ci0tLSBzeXNjYWxsICg5MywgRnJlZUJTRCBFTEYzMiwgc2VsZWN0KSwgZWlwID0gMHgyODM1NDg1 NywgZXNwID0gMHhiZmJmZTE1YywgZWJwID0gMHhiZmJmZWU2OCAtLS0NCg0KVHJhY2luZyBjb21t YW5kIG5mc2lvZCA2IHBpZCA2NDQgdGlkIDEwMDEwOSB0ZCAweGM2ZGUzYjYwDQpzY2hlZF9zd2l0 Y2goYzZkZTNiNjAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNWINCm1pX3N3aXRjaCgxLDApIGF0 IG1pX3N3aXRjaCsweDI3MA0Kc2xlZXBxX3N3aXRjaChjMGIxZWJmOCkgYXQgc2xlZXBxX3N3aXRj aCsweGMxDQpzbGVlcHFfdGltZWR3YWl0X3NpZyhjMGIxZWJmOCkgYXQgc2xlZXBxX3RpbWVkd2Fp dF9zaWcrMHgxZQ0KbXNsZWVwKGMwYjFlYmY4LDAsMTVjLGMwOWFiYmY2LDFkNGMwLC4uLikgYXQg bXNsZWVwKzB4MjQ0DQpuZnNzdmNfaW9kKGMwYjFlNTk4LGVkMjM3ZDM4LGMwYjFlNTk4LGMwN2Ey YzU4LDAsLi4uKSBhdCBuZnNzdmNfaW9kKzB4YTINCmZvcmtfZXhpdChjMDdhMmM1OCxjMGIxZTU5 OCxlZDIzN2QzOCkgYXQgZm9ya19leGl0KzB4YTANCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtf dHJhbXBvbGluZSsweDgNCi0tLSB0cmFwIDB4MSwgZWlwID0gMCwgZXNwID0gMHhlZDIzN2Q2Yywg ZWJwID0gMCAtLS0NCg0KVHJhY2luZyBjb21tYW5kIHN5c2xvZ2QgcGlkIDU5NiB0aWQgMTAwMTE3 IHRkIDB4YzZlMDg2ODANCnNjaGVkX3N3aXRjaChjNmUwODY4MCwwLDEpIGF0IHNjaGVkX3N3aXRj aCsweDE1Yg0KbWlfc3dpdGNoKDEsMCkgYXQgbWlfc3dpdGNoKzB4MjcwDQpzbGVlcHFfc3dpdGNo KGMwYjE2NTA0KSBhdCBzbGVlcHFfc3dpdGNoKzB4YzENCnNsZWVwcV93YWl0X3NpZyhjMGIxNjUw NCwyNDYsYzBhYzQwODAsYzA5Yjc5YWMsMzAzLC4uLikgYXQgc2xlZXBxX3dhaXRfc2lnKzB4MWQN CmN2X3dhaXRfc2lnKGMwYjE2NTA0LGMwYjE2NGUwKSBhdCBjdl93YWl0X3NpZysweDE4Yg0Ka2Vy bl9zZWxlY3QoYzZlMDg2ODAsOCw4MDU5MTkwLDAsMCwuLi4pIGF0IGtlcm5fc2VsZWN0KzB4NGJm DQpzZWxlY3QoYzZlMDg2ODAsZWQyOGNkMDQpIGF0IHNlbGVjdCsweDQ0DQpzeXNjYWxsKDNiLGJm YmYwMDNiLGJmYmYwMDNiLDgwNTkxOTQsODA1OTE5MCwuLi4pIGF0IHN5c2NhbGwrMHgyMmYNClhp bnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MWYNCi0tLSBzeXNjYWxsICg5 MywgRnJlZUJTRCBFTEYzMiwgc2VsZWN0KSwgZWlwID0gMHgyODE0ZDg1NywgZXNwID0gMHhiZmJm ZGExYywgZWJwID0gMHhiZmJmZWU2OCAtLS0NCg0KVHJhY2luZyBjb21tYW5kIGRldmQgcGlkIDU0 NyB0aWQgMTAwMTEzIHRkIDB4YzY5YWE0ZTANCnNjaGVkX3N3aXRjaChjNjlhYTRlMCwwLDEpIGF0 IHNjaGVkX3N3aXRjaCsweDE1Yg0KbWlfc3dpdGNoKDEsMCkgYXQgbWlfc3dpdGNoKzB4MjcwDQpz bGVlcHFfc3dpdGNoKGMwYjE2NTA0KSBhdCBzbGVlcHFfc3dpdGNoKzB4YzENCnNsZWVwcV93YWl0 X3NpZyhjMGIxNjUwNCwyNDYsYzBhYzQwODAsYzA5Yjc5YWMsMzAzLC4uLikgYXQgc2xlZXBxX3dh aXRfc2lnKzB4MWQNCmN2X3dhaXRfc2lnKGMwYjE2NTA0LGMwYjE2NGUwKSBhdCBjdl93YWl0X3Np ZysweDE4Yg0Ka2Vybl9zZWxlY3QoYzY5YWE0ZTAsNSxiZmJmZTlkMCwwLDAsLi4uKSBhdCBrZXJu X3NlbGVjdCsweDRiZg0Kc2VsZWN0KGM2OWFhNGUwLGVhZjZhZDA0KSBhdCBzZWxlY3QrMHg0NA0K c3lzY2FsbCgzYiwzYiwzYiwwLDgsLi4uKSBhdCBzeXNjYWxsKzB4MjJmDQpYaW50MHg4MF9zeXNj YWxsKCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDFmDQotLS0gc3lzY2FsbCAoOTMsIEZyZWVCU0Qg RUxGMzIsIHNlbGVjdCksIGVpcCA9IDB4ODA3NWIwMywgZXNwID0gMHhiZmJmZTk2YywgZWJwID0g MHhiZmJmZWU3OCAtLS0NCg0KVHJhY2luZyBjb21tYW5kIG5mc2lvZCAxIHBpZCA3MiB0aWQgMTAw MDkxIHRkIDB4YzZkMzI0ZTANCnNjaGVkX3N3aXRjaChjNmQzMjRlMCwwLDEpIGF0IHNjaGVkX3N3 aXRjaCsweDE1Yg0KbWlfc3dpdGNoKDEsMCkgYXQgbWlfc3dpdGNoKzB4MjcwDQpzbGVlcHFfc3dp dGNoKGMwYjFlYmU0KSBhdCBzbGVlcHFfc3dpdGNoKzB4YzENCnNsZWVwcV90aW1lZHdhaXRfc2ln KGMwYjFlYmU0KSBhdCBzbGVlcHFfdGltZWR3YWl0X3NpZysweDFlDQptc2xlZXAoYzBiMWViZTQs MCwxNWMsYzA5YWJiZjYsMWQ0YzAsLi4uKSBhdCBtc2xlZXArMHgyNDQNCm5mc3N2Y19pb2QoYzBi MWU1ODQsZWQxYjJkMzgsYzBiMWU1ODQsYzA3YTJjNTgsMCwuLi4pIGF0IG5mc3N2Y19pb2QrMHhh Mg0KZm9ya19leGl0KGMwN2EyYzU4LGMwYjFlNTg0LGVkMWIyZDM4KSBhdCBmb3JrX2V4aXQrMHhh MA0KZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OA0KLS0tIHRyYXAgMHgx LCBlaXAgPSAwLCBlc3AgPSAweGVkMWIyZDZjLCBlYnAgPSAwIC0tLQ0KDQpUcmFjaW5nIGNvbW1h bmQgbmZzaW9kIDAgcGlkIDYzIHRpZCAxMDAwNzUgdGQgMHhjNjlhYTljMA0Kc2NoZWRfc3dpdGNo KGM2OWFhOWMwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTViDQptaV9zd2l0Y2goMSwwKSBhdCBt aV9zd2l0Y2grMHgyNzANCnNsZWVwcV9zd2l0Y2goYzBiMWViZTApIGF0IHNsZWVwcV9zd2l0Y2gr MHhjMQ0Kc2xlZXBxX3RpbWVkd2FpdF9zaWcoYzBiMWViZTApIGF0IHNsZWVwcV90aW1lZHdhaXRf c2lnKzB4MWUNCm1zbGVlcChjMGIxZWJlMCwwLDE1YyxjMDlhYmJmNiwxZDRjMCwuLi4pIGF0IG1z bGVlcCsweDI0NA0KbmZzc3ZjX2lvZChjMGIxZTU4MCxlYWY3M2QzOCxjMGIxZTU4MCxjMDdhMmM1 OCwwLC4uLikgYXQgbmZzc3ZjX2lvZCsweGEyDQpmb3JrX2V4aXQoYzA3YTJjNTgsYzBiMWU1ODAs ZWFmNzNkMzgpIGF0IGZvcmtfZXhpdCsweGEwDQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3Ry YW1wb2xpbmUrMHg4DQotLS0gdHJhcCAweDEsIGVpcCA9IDAsIGVzcCA9IDB4ZWFmNzNkNmMsIGVi cCA9IDAgLS0tDQoNClRyYWNpbmcgY29tbWFuZCBzaCBwaWQgNjIgdGlkIDEwMDA3NiB0ZCAweGM2 OWFhODIwDQpzY2hlZF9zd2l0Y2goYzY5YWE4MjAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNWIN Cm1pX3N3aXRjaCgxLDApIGF0IG1pX3N3aXRjaCsweDI3MA0Kc2xlZXBxX3N3aXRjaChjNmQzNGM5 MCkgYXQgc2xlZXBxX3N3aXRjaCsweGMxDQpzbGVlcHFfd2FpdF9zaWcoYzZkMzRjOTApIGF0IHNs ZWVwcV93YWl0X3NpZysweDFkDQptc2xlZXAoYzZkMzRjOTAsYzZkMzRjZjgsMTVjLGMwOWI3ZjYx LDApIGF0IG1zbGVlcCsweDI2ZQ0Ka2Vybl93YWl0KGM2OWFhODIwLGZmZmZmZmZmLGVhZjcwYzg0 LDIsMCkgYXQga2Vybl93YWl0KzB4NmJiDQp3YWl0NChjNjlhYTgyMCxlYWY3MGQwNCkgYXQgd2Fp dDQrMHgyYQ0Kc3lzY2FsbCgzYiwzYiwzYixiZmJmZTgyOCwzZSwuLi4pIGF0IHN5c2NhbGwrMHgy MmYNClhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MWYNCi0tLSBzeXNj YWxsICg3LCBGcmVlQlNEIEVMRjMyLCB3YWl0NCksIGVpcCA9IDB4MjgxNDJlN2IsIGVzcCA9IDB4 YmZiZmU3ZGMsIGVicCA9IDB4YmZiZmU3ZjggLS0tDQoNClRyYWNpbmcgY29tbWFuZCBzb2Z0ZGVw Zmx1c2ggcGlkIDYxIHRpZCAxMDAwNTIgdGQgMHhjNjhkNGQwMA0Kc2NoZWRfc3dpdGNoKGM2OGQ0 ZDAwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTViDQptaV9zd2l0Y2goMSwwKSBhdCBtaV9zd2l0 Y2grMHgyNzANCnNsZWVwcV9zd2l0Y2goYzBiMjQzMzQsYzBhYzQwODAsMCxjMDliNWRiZSwyNDQs Li4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4YzENCnNsZWVwcV90aW1lZHdhaXQoYzBiMjQzMzQpIGF0 IHNsZWVwcV90aW1lZHdhaXQrMHg0YQ0KbXNsZWVwKGMwYjI0MzM0LGMwYjI0MzAwLDQ0LGMwOWNk YTIwLDNlOCkgYXQgbXNsZWVwKzB4MjU5DQpzb2Z0ZGVwX2ZsdXNoKDAsZTZlNTlkMzgsMCxjMDgw Y2E0OCwwLC4uLikgYXQgc29mdGRlcF9mbHVzaCsweDI0ZA0KZm9ya19leGl0KGMwODBjYTQ4LDAs ZTZlNTlkMzgpIGF0IGZvcmtfZXhpdCsweGEwDQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3Ry YW1wb2xpbmUrMHg4DQotLS0gdHJhcCAweDEsIGVpcCA9IDAsIGVzcCA9IDB4ZTZlNTlkNmMsIGVi cCA9IDAgLS0tDQoNClRyYWNpbmcgY29tbWFuZCB2bmxydSBwaWQgNjAgdGlkIDEwMDA1MyB0ZCAw eGM2OGQ0YjYwDQpzY2hlZF9zd2l0Y2goYzY4ZDRiNjAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgx NWINCm1pX3N3aXRjaCgxLDApIGF0IG1pX3N3aXRjaCsweDI3MA0Kc2xlZXBxX3N3aXRjaChjNjk2 Mjg2MCxjMGFjNDA4MCwwLGMwOWI1ZGJlLDI0NCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHhjMQ0K c2xlZXBxX3RpbWVkd2FpdChjNjk2Mjg2MCkgYXQgc2xlZXBxX3RpbWVkd2FpdCsweDRhDQptc2xl ZXAoYzY5NjI4NjAsYzBiMTZlODAsMjUwLGMwOWJjYTRmLDNlOCxjMGIxNmYwMCkgYXQgbXNsZWVw KzB4MjU5DQp2bmxydV9wcm9jKDAsZTZlNTZkMzgsMCxjMDcwYTFkOCwwLC4uLikgYXQgdm5scnVf cHJvYysweGRmDQpmb3JrX2V4aXQoYzA3MGExZDgsMCxlNmU1NmQzOCkgYXQgZm9ya19leGl0KzB4 YTANCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgNCi0tLSB0cmFwIDB4 MSwgZWlwID0gMCwgZXNwID0gMHhlNmU1NmQ2YywgZWJwID0gMCAtLS0NCg0KVHJhY2luZyBjb21t YW5kIHN5bmNlciBwaWQgNTkgdGlkIDEwMDA1NCB0ZCAweGM2OGQ0OWMwDQpzY2hlZF9zd2l0Y2go YzY4ZDQ5YzAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNWINCm1pX3N3aXRjaCgxLDApIGF0IG1p X3N3aXRjaCsweDI3MA0Kc2xlZXBxX3N3aXRjaChjMGFjNDcxYyxjMGFjNDA4MCwwLGMwOWI1ZGJl LDIxZiwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHhjMQ0Kc2xlZXBxX3dhaXQoYzBhYzQ3MWMsMCxj MDZhYjEwYSxjMGIxNmVjMCxjMDliYzk4MSwuLi4pIGF0IHNsZWVwcV93YWl0KzB4NDYNCm1zbGVl cChjMGFjNDcxYywwLDY4LGMwOWJjZDRjLDApIGF0IG1zbGVlcCsweDI3ZA0Kc2NoZWRfc3luYygw LGU2ZTUzZDM4LDAsYzA3MGJjODAsMCwuLi4pIGF0IHNjaGVkX3N5bmMrMHgzMDkNCmZvcmtfZXhp dChjMDcwYmM4MCwwLGU2ZTUzZDM4KSBhdCBmb3JrX2V4aXQrMHhhMA0KZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lKzB4OA0KLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAw eGU2ZTUzZDZjLCBlYnAgPSAwIC0tLQ0KDQpUcmFjaW5nIGNvbW1hbmQgYnVmZGFlbW9uIHBpZCA1 OCB0aWQgMTAwMDU1IHRkIDB4YzY4ZDQ4MjANCnNjaGVkX3N3aXRjaChjNjhkNDgyMCwwLDEpIGF0 IHNjaGVkX3N3aXRjaCsweDE1Yg0KbWlfc3dpdGNoKDEsMCkgYXQgbWlfc3dpdGNoKzB4MjcwDQpz bGVlcHFfc3dpdGNoKGMwYjE2YTgwLGMwYWM0MDgwLDAsYzA5YjVkYmUsMjQ0LC4uLikgYXQgc2xl ZXBxX3N3aXRjaCsweGMxDQpzbGVlcHFfdGltZWR3YWl0KGMwYjE2YTgwKSBhdCBzbGVlcHFfdGlt ZWR3YWl0KzB4NGENCm1zbGVlcChjMGIxNmE4MCxjMGIxNmFhMCw0NCxjMDliYjIzMywzZTgpIGF0 IG1zbGVlcCsweDI1OQ0KYnVmX2RhZW1vbigwLGU2ZTUwZDM4LDAsYzA2ZmQ2ZjQsMCwuLi4pIGF0 IGJ1Zl9kYWVtb24rMHgxMDgNCmZvcmtfZXhpdChjMDZmZDZmNCwwLGU2ZTUwZDM4KSBhdCBmb3Jr X2V4aXQrMHhhMA0KZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OA0KLS0t IHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGU2ZTUwZDZjLCBlYnAgPSAwIC0tLQ0KDQpUcmFj aW5nIGNvbW1hbmQgcGFnZXplcm8gcGlkIDU3IHRpZCAxMDAwNTYgdGQgMHhjNjhkNDY4MA0Kc2No ZWRfc3dpdGNoKGM2OGQ0NjgwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTViDQptaV9zd2l0Y2go MSwwKSBhdCBtaV9zd2l0Y2grMHgyNzANCnNsZWVwcV9zd2l0Y2goYzBiMjUzNjQsYzBhYzQwODAs MCxjMDliNWRiZSwyNDQsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4YzENCnNsZWVwcV90aW1lZHdh aXQoYzBiMjUzNjQpIGF0IHNsZWVwcV90aW1lZHdhaXQrMHg0YQ0KbXNsZWVwKGMwYjI1MzY0LGMw YjI0ZGUwLDIwMCxjMDlkMmQ2OSw0OTNlMCxjMGIyNGRlMCwwLGMwOWQyZDRiLDlkKSBhdCBtc2xl ZXArMHgyNTkNCnZtX3BhZ2V6ZXJvKDAsZTZlNGRkMzgsMCxjMDgzZmQ0MCwwLC4uLikgYXQgdm1f cGFnZXplcm8rMHg2Yw0KZm9ya19leGl0KGMwODNmZDQwLDAsZTZlNGRkMzgpIGF0IGZvcmtfZXhp dCsweGEwDQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4DQotLS0gdHJh cCAweDEsIGVpcCA9IDAsIGVzcCA9IDB4ZTZlNGRkNmMsIGVicCA9IDAgLS0tDQoNClRyYWNpbmcg Y29tbWFuZCB2bWRhZW1vbiBwaWQgNTYgdGlkIDEwMDA1NyB0ZCAweGM2OGQ0NGUwDQpzY2hlZF9z d2l0Y2goYzY4ZDQ0ZTAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNWINCm1pX3N3aXRjaCgxLDAp IGF0IG1pX3N3aXRjaCsweDI3MA0Kc2xlZXBxX3N3aXRjaChjMGIyNGU3NCxjMGFjNDA4MCwwLGMw OWI1ZGJlLDIxZiwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHhjMQ0Kc2xlZXBxX3dhaXQoYzBiMjRl NzQsMCxjMDlkMjllYyw2NmIsMCwuLi4pIGF0IHNsZWVwcV93YWl0KzB4NDYNCm1zbGVlcChjMGIy NGU3NCxjMGIyNGU4MCw2OCxjMDliYjIzMywwLC4uLikgYXQgbXNsZWVwKzB4MjdkDQp2bV9kYWVt b24oMCxlNmU0YWQzOCwwLGMwODNlZDQ0LDAsLi4uKSBhdCB2bV9kYWVtb24rMHgzNg0KZm9ya19l eGl0KGMwODNlZDQ0LDAsZTZlNGFkMzgpIGF0IGZvcmtfZXhpdCsweGEwDQpmb3JrX3RyYW1wb2xp bmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4DQotLS0gdHJhcCAweDEsIGVpcCA9IDAsIGVzcCA9 IDB4ZTZlNGFkNmMsIGVicCA9IDAgLS0tDQoNClRyYWNpbmcgY29tbWFuZCBwYWdlZGFlbW9uIHBp ZCA1NSB0aWQgMTAwMDU4IHRkIDB4YzY4ZDQzNDANCnNjaGVkX3N3aXRjaChjNjhkNDM0MCwwLDEp IGF0IHNjaGVkX3N3aXRjaCsweDE1Yg0KbWlfc3dpdGNoKDEsMCkgYXQgbWlfc3dpdGNoKzB4Mjcw DQpzbGVlcHFfc3dpdGNoKGMwYjI0ZTI4LGMwYWM0MDgwLDAsYzA5YjVkYmUsMjQ0LC4uLikgYXQg c2xlZXBxX3N3aXRjaCsweGMxDQpzbGVlcHFfdGltZWR3YWl0KGMwYjI0ZTI4KSBhdCBzbGVlcHFf dGltZWR3YWl0KzB4NGENCm1zbGVlcChjMGIyNGUyOCxjMGIyNGRlMCw0NCxjMDliYjIzMywxMzg4 KSBhdCBtc2xlZXArMHgyNTkNCnZtX3BhZ2VvdXQoMCxlNmU0N2QzOCwwLGMwODNlOWNjLDAsLi4u KSBhdCB2bV9wYWdlb3V0KzB4MjYwDQpmb3JrX2V4aXQoYzA4M2U5Y2MsMCxlNmU0N2QzOCkgYXQg Zm9ya19leGl0KzB4YTANCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgN Ci0tLSB0cmFwIDB4MSwgZWlwID0gMCwgZXNwID0gMHhlNmU0N2Q2YywgZWJwID0gMCAtLS0NCg0K VHJhY2luZyBjb21tYW5kIGlycTE6IGF0a2JkMCBwaWQgNTQgdGlkIDEwMDA1OSB0ZCAweGM2OGQ0 MWEwDQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUNCg0KVHJhY2luZyBjb21t YW5kIHN3aTA6IHNpbyBwaWQgNTMgdGlkIDEwMDA2MCB0ZCAweGM2OWFhMzQwDQpzY2hlZF9zd2l0 Y2goYzY5YWEzNDAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNWINCm1pX3N3aXRjaCgxLDApIGF0 IG1pX3N3aXRjaCsweDI3MA0KaXRocmVhZF9sb29wKGM2OWI4N2EwLGVhZjY3ZDM4LGM2OWI4N2Ew LGMwNjllNmZjLDAsLi4uKSBhdCBpdGhyZWFkX2xvb3ArMHhkYQ0KZm9ya19leGl0KGMwNjllNmZj LGM2OWI4N2EwLGVhZjY3ZDM4KSBhdCBmb3JrX2V4aXQrMHhhMA0KZm9ya190cmFtcG9saW5lKCkg YXQgZm9ya190cmFtcG9saW5lKzB4OA0KLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGVh ZjY3ZDZjLCBlYnAgPSAwIC0tLQ0KDQpUcmFjaW5nIGNvbW1hbmQgaXJxMjE6IGF0YXBjaTEgcGlk IDUyIHRpZCAxMDAwNjEgdGQgMHhjNjlhYTFhMA0KZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190 cmFtcG9saW5lDQoNClRyYWNpbmcgY29tbWFuZCBpcnExNTogYXRhMSBwaWQgNTEgdGlkIDEwMDA2 MiB0ZCAweGM2OWFhMDAwDQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUNCg0K VHJhY2luZyBjb21tYW5kIGlycTE0OiBhdGEwIHBpZCA1MCB0aWQgMTAwMDM4IHRkIDB4YzY4ZDM2 ODANCnNjaGVkX3N3aXRjaChjNjhkMzY4MCwwLDEpIGF0IHNjaGVkX3N3aXRjaCsweDE1Yg0KbWlf c3dpdGNoKDEsMCkgYXQgbWlfc3dpdGNoKzB4MjcwDQppdGhyZWFkX2xvb3AoYzY5YTczZTAsZTZl MzJkMzgsYzY5YTczZTAsYzA2OWU2ZmMsMCwuLi4pIGF0IGl0aHJlYWRfbG9vcCsweGRhDQpmb3Jr X2V4aXQoYzA2OWU2ZmMsYzY5YTczZTAsZTZlMzJkMzgpIGF0IGZvcmtfZXhpdCsweGEwDQpmb3Jr X3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4DQotLS0gdHJhcCAweDEsIGVpcCA9 IDAsIGVzcCA9IDB4ZTZlMzJkNmMsIGVicCA9IDAgLS0tDQoNClRyYWNpbmcgY29tbWFuZCB1c2I2 IHBpZCA0OSB0aWQgMTAwMDM5IHRkIDB4YzY4ZDM0ZTANCnNjaGVkX3N3aXRjaChjNjhkMzRlMCww LDEpIGF0IHNjaGVkX3N3aXRjaCsweDE1Yg0KbWlfc3dpdGNoKDEsMCkgYXQgbWlfc3dpdGNoKzB4 MjcwDQpzbGVlcHFfc3dpdGNoKGM2OGNhMjEwLGMwYWM0MDgwLDAsYzA5YjVkYmUsMjQ0LC4uLikg YXQgc2xlZXBxX3N3aXRjaCsweGMxDQpzbGVlcHFfdGltZWR3YWl0KGM2OGNhMjEwKSBhdCBzbGVl cHFfdGltZWR3YWl0KzB4NGENCm1zbGVlcChjNjhjYTIxMCwwLDVjLGMwOWE4Y2JmLGVhNjAsYzY5 NzJhODApIGF0IG1zbGVlcCsweDI1OQ0KdXNiX2V2ZW50X3RocmVhZChjNjk3MmE4MCxlNmUyZmQz OCxjNjk3MmE4MCxjMDY1MTg0OCwwLC4uLikgYXQgdXNiX2V2ZW50X3RocmVhZCsweDcwDQpmb3Jr X2V4aXQoYzA2NTE4NDgsYzY5NzJhODAsZTZlMmZkMzgpIGF0IGZvcmtfZXhpdCsweGEwDQpmb3Jr X3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4DQotLS0gdHJhcCAweDEsIGVpcCA9 IDAsIGVzcCA9IDB4ZTZlMmZkNmMsIGVicCA9IDAgLS0tDQoNClRyYWNpbmcgY29tbWFuZCB1c2I1 IHBpZCA0OCB0aWQgMTAwMDQwIHRkIDB4YzY4ZDMzNDANCnNjaGVkX3N3aXRjaChjNjhkMzM0MCww LDEpIGF0IHNjaGVkX3N3aXRjaCsweDE1Yg0KbWlfc3dpdGNoKDEsMCkgYXQgbWlfc3dpdGNoKzB4 MjcwDQpzbGVlcHFfc3dpdGNoKGM2OThiMjEwLGMwYWM0MDgwLDAsYzA5YjVkYmUsMjQ0LC4uLikg YXQgc2xlZXBxX3N3aXRjaCsweGMxDQpzbGVlcHFfdGltZWR3YWl0KGM2OThiMjEwKSBhdCBzbGVl cHFfdGltZWR3YWl0KzB4NGENCm1zbGVlcChjNjk4YjIxMCwwLDVjLGMwOWE4Y2JmLGVhNjAsYzY5 N2Y1NDApIGF0IG1zbGVlcCsweDI1OQ0KdXNiX2V2ZW50X3RocmVhZChjNjk3ZjU0MCxlNmUyY2Qz OCxjNjk3ZjU0MCxjMDY1MTg0OCwwLC4uLikgYXQgdXNiX2V2ZW50X3RocmVhZCsweDcwDQpmb3Jr X2V4aXQoYzA2NTE4NDgsYzY5N2Y1NDAsZTZlMmNkMzgpIGF0IGZvcmtfZXhpdCsweGEwDQpmb3Jr X3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4DQotLS0gdHJhcCAweDEsIGVpcCA9 IDAsIGVzcCA9IDB4ZTZlMmNkNmMsIGVicCA9IDAgLS0tDQoNClRyYWNpbmcgY29tbWFuZCB1c2I0 IHBpZCA0NyB0aWQgMTAwMDQxIHRkIDB4YzY4ZDMxYTANCnNjaGVkX3N3aXRjaChjNjhkMzFhMCww LDEpIGF0IHNjaGVkX3N3aXRjaCsweDE1Yg0KbWlfc3dpdGNoKDEsMCkgYXQgbWlfc3dpdGNoKzB4 MjcwDQpzbGVlcHFfc3dpdGNoKGM2OTgzMjEwLGMwYWM0MDgwLDAsYzA5YjVkYmUsMjQ0LC4uLikg YXQgc2xlZXBxX3N3aXRjaCsweGMxDQpzbGVlcHFfdGltZWR3YWl0KGM2OTgzMjEwKSBhdCBzbGVl cHFfdGltZWR3YWl0KzB4NGENCm1zbGVlcChjNjk4MzIxMCwwLDVjLGMwOWE4Y2JmLGVhNjAsYzY5 N2ZlMDApIGF0IG1zbGVlcCsweDI1OQ0KdXNiX2V2ZW50X3RocmVhZChjNjk3ZmUwMCxlNmUyOWQz OCxjNjk3ZmUwMCxjMDY1MTg0OCwwLC4uLikgYXQgdXNiX2V2ZW50X3RocmVhZCsweDcwDQpmb3Jr X2V4aXQoYzA2NTE4NDgsYzY5N2ZlMDAsZTZlMjlkMzgpIGF0IGZvcmtfZXhpdCsweGEwDQpmb3Jr X3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4DQotLS0gdHJhcCAweDEsIGVpcCA9 IDAsIGVzcCA9IDB4ZTZlMjlkNmMsIGVicCA9IDAgLS0tDQoNClRyYWNpbmcgY29tbWFuZCB1c2Iz IHBpZCA0NiB0aWQgMTAwMDQyIHRkIDB4YzY4ZDMwMDANCnNjaGVkX3N3aXRjaChjNjhkMzAwMCww LDEpIGF0IHNjaGVkX3N3aXRjaCsweDE1Yg0KbWlfc3dpdGNoKDEsMCkgYXQgbWlfc3dpdGNoKzB4 MjcwDQpzbGVlcHFfc3dpdGNoKGM2OTY2MjEwLGMwYWM0MDgwLDAsYzA5YjVkYmUsMjQ0LC4uLikg YXQgc2xlZXBxX3N3aXRjaCsweGMxDQpzbGVlcHFfdGltZWR3YWl0KGM2OTY2MjEwKSBhdCBzbGVl cHFfdGltZWR3YWl0KzB4NGENCm1zbGVlcChjNjk2NjIxMCwwLDVjLGMwOWE4Y2JmLGVhNjAsYzY5 ODA4MDApIGF0IG1zbGVlcCsweDI1OQ0KdXNiX2V2ZW50X3RocmVhZChjNjk4MDgwMCxlNmUyNmQz OCxjNjk4MDgwMCxjMDY1MTg0OCwwLC4uLikgYXQgdXNiX2V2ZW50X3RocmVhZCsweDcwDQpmb3Jr X2V4aXQoYzA2NTE4NDgsYzY5ODA4MDAsZTZlMjZkMzgpIGF0IGZvcmtfZXhpdCsweGEwDQpmb3Jr X3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4DQotLS0gdHJhcCAweDEsIGVpcCA9 IDAsIGVzcCA9IDB4ZTZlMjZkNmMsIGVicCA9IDAgLS0tDQoNClRyYWNpbmcgY29tbWFuZCBpcnEx NjogbWZpMCBwaWQgNDUgdGlkIDEwMDA0MyB0ZCAweGM2ODI1ZDAwDQpzY2hlZF9zd2l0Y2goYzY4 MjVkMDAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNWINCm1pX3N3aXRjaCgxLDApIGF0IG1pX3N3 aXRjaCsweDI3MA0KaXRocmVhZF9sb29wKGM2OTVlODcwLGU2ZTIzZDM4LGM2OTVlODcwLGMwNjll NmZjLDAsLi4uKSBhdCBpdGhyZWFkX2xvb3ArMHhkYQ0KZm9ya19leGl0KGMwNjllNmZjLGM2OTVl ODcwLGU2ZTIzZDM4KSBhdCBmb3JrX2V4aXQrMHhhMA0KZm9ya190cmFtcG9saW5lKCkgYXQgZm9y a190cmFtcG9saW5lKzB4OA0KLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGU2ZTIzZDZj LCBlYnAgPSAwIC0tLQ0KDQpUcmFjaW5nIGNvbW1hbmQgdXNiMiBwaWQgNDQgdGlkIDEwMDA0NCB0 ZCAweGM2ODI1YjYwDQpzY2hlZF9zd2l0Y2goYzY4MjViNjAsMCwxKSBhdCBzY2hlZF9zd2l0Y2gr MHgxNWINCm1pX3N3aXRjaCgxLDApIGF0IG1pX3N3aXRjaCsweDI3MA0Kc2xlZXBxX3N3aXRjaChj NjhjZTIxMCxjMGFjNDA4MCwwLGMwOWI1ZGJlLDI0NCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHhj MQ0Kc2xlZXBxX3RpbWVkd2FpdChjNjhjZTIxMCkgYXQgc2xlZXBxX3RpbWVkd2FpdCsweDRhDQpt c2xlZXAoYzY4Y2UyMTAsMCw1YyxjMDlhOGNiZixlYTYwLGM2OTcxYzQwKSBhdCBtc2xlZXArMHgy NTkNCnVzYl9ldmVudF90aHJlYWQoYzY5NzFjNDAsZTZlMjBkMzgsYzY5NzFjNDAsYzA2NTE4NDgs MCwuLi4pIGF0IHVzYl9ldmVudF90aHJlYWQrMHg3MA0KZm9ya19leGl0KGMwNjUxODQ4LGM2OTcx YzQwLGU2ZTIwZDM4KSBhdCBmb3JrX2V4aXQrMHhhMA0KZm9ya190cmFtcG9saW5lKCkgYXQgZm9y a190cmFtcG9saW5lKzB4OA0KLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGU2ZTIwZDZj LCBlYnAgPSAwIC0tLQ0KDQpUcmFjaW5nIGNvbW1hbmQgaXJxMTk6IGVoY2kwIHVoY2k0IHBpZCA0 MyB0aWQgMTAwMDQ1IHRkIDB4YzY4MjU5YzANCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJh bXBvbGluZQ0KDQpUcmFjaW5nIGNvbW1hbmQgdXNiMSBwaWQgNDIgdGlkIDEwMDA0NiB0ZCAweGM2 OTYwODIwDQpzY2hlZF9zd2l0Y2goYzY5NjA4MjAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNWIN Cm1pX3N3aXRjaCgxLDApIGF0IG1pX3N3aXRjaCsweDI3MA0Kc2xlZXBxX3N3aXRjaChjNjk1NDIx MCxjMGFjNDA4MCwwLGMwOWI1ZGJlLDI0NCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHhjMQ0Kc2xl ZXBxX3RpbWVkd2FpdChjNjk1NDIxMCkgYXQgc2xlZXBxX3RpbWVkd2FpdCsweDRhDQptc2xlZXAo YzY5NTQyMTAsMCw1YyxjMDlhOGNiZixlYTYwLGM2OTRhMTAwKSBhdCBtc2xlZXArMHgyNTkNCnVz Yl9ldmVudF90aHJlYWQoYzY5NGExMDAsZWFlN2JkMzgsYzY5NGExMDAsYzA2NTE4NDgsMCwuLi4p IGF0IHVzYl9ldmVudF90aHJlYWQrMHg3MA0KZm9ya19leGl0KGMwNjUxODQ4LGM2OTRhMTAwLGVh ZTdiZDM4KSBhdCBmb3JrX2V4aXQrMHhhMA0KZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lKzB4OA0KLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGVhZTdiZDZjLCBlYnAg PSAwIC0tLQ0KDQpUcmFjaW5nIGNvbW1hbmQgaXJxMTg6IHVoY2kxIHVoY2kzIHBpZCA0MSB0aWQg MTAwMDQ3IHRkIDB4YzY5NjA2ODANCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGlu ZQ0KDQpUcmFjaW5nIGNvbW1hbmQgdXNidGFzayBwaWQgNDAgdGlkIDEwMDA0OCB0ZCAweGM2OTYw NGUwDQpzY2hlZF9zd2l0Y2goYzY5NjA0ZTAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNWINCm1p X3N3aXRjaCgxLDApIGF0IG1pX3N3aXRjaCsweDI3MA0Kc2xlZXBxX3N3aXRjaChjMGFjMTNlNCxj MGFjNDA4MCwwLGMwOWI1ZGJlLDIxZiwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHhjMQ0Kc2xlZXBx X3dhaXQoYzBhYzEzZTQsMCxjMDZhYjA2NCxjMGFjNDBjMCxjMDlhOGNhNCwuLi4pIGF0IHNsZWVw cV93YWl0KzB4NDYNCm1zbGVlcChjMGFjMTNlNCwwLDVjLGMwOWE4Y2M2LDAsLi4uKSBhdCBtc2xl ZXArMHgyN2QNCnVzYl90YXNrX3RocmVhZCgwLGVhZTc1ZDM4LDAsYzA2NTE4ZDgsMCwuLi4pIGF0 IHVzYl90YXNrX3RocmVhZCsweDQ3DQpmb3JrX2V4aXQoYzA2NTE4ZDgsMCxlYWU3NWQzOCkgYXQg Zm9ya19leGl0KzB4YTANCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgN Ci0tLSB0cmFwIDB4MSwgZWlwID0gMCwgZXNwID0gMHhlYWU3NWQ2YywgZWJwID0gMCAtLS0NCg0K VHJhY2luZyBjb21tYW5kIHVzYjAgcGlkIDM5IHRpZCAxMDAwNDkgdGQgMHhjNjk2MDM0MA0Kc2No ZWRfc3dpdGNoKGM2OTYwMzQwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTViDQptaV9zd2l0Y2go MSwwKSBhdCBtaV9zd2l0Y2grMHgyNzANCnNsZWVwcV9zd2l0Y2goYzY4ZDkyMTAsYzBhYzQwODAs MCxjMDliNWRiZSwyNDQsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4YzENCnNsZWVwcV90aW1lZHdh aXQoYzY4ZDkyMTApIGF0IHNsZWVwcV90aW1lZHdhaXQrMHg0YQ0KbXNsZWVwKGM2OGQ5MjEwLDAs NWMsYzA5YThjYmYsZWE2MCxjNjk0Njg4MCkgYXQgbXNsZWVwKzB4MjU5DQp1c2JfZXZlbnRfdGhy ZWFkKGM2OTQ2ODgwLGVhZTcyZDM4LGM2OTQ2ODgwLGMwNjUxODQ4LDAsLi4uKSBhdCB1c2JfZXZl bnRfdGhyZWFkKzB4NzANCmZvcmtfZXhpdChjMDY1MTg0OCxjNjk0Njg4MCxlYWU3MmQzOCkgYXQg Zm9ya19leGl0KzB4YTANCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgN Ci0tLSB0cmFwIDB4MSwgZWlwID0gMCwgZXNwID0gMHhlYWU3MmQ2YywgZWJwID0gMCAtLS0NCg0K VHJhY2luZyBjb21tYW5kIGlycTE3OiB1aGNpMCB1aGNpKyBwaWQgMzggdGlkIDEwMDAyNyB0ZCAw eGM2N2MxZDAwDQpzY2hlZF9zd2l0Y2goYzY3YzFkMDAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgx NWINCm1pX3N3aXRjaCgxLDApIGF0IG1pX3N3aXRjaCsweDI3MA0KaXRocmVhZF9sb29wKGM2OTQ4 NWIwLGU1M2UyZDM4LGM2OTQ4NWIwLGMwNjllNmZjLDAsLi4uKSBhdCBpdGhyZWFkX2xvb3ArMHhk YQ0KZm9ya19leGl0KGMwNjllNmZjLGM2OTQ4NWIwLGU1M2UyZDM4KSBhdCBmb3JrX2V4aXQrMHhh MA0KZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OA0KLS0tIHRyYXAgMHgx LCBlaXAgPSAwLCBlc3AgPSAweGU1M2UyZDZjLCBlYnAgPSAwIC0tLQ0KDQpUcmFjaW5nIGNvbW1h bmQgaXJxNDA6IGJjZTEgcGlkIDM3IHRpZCAxMDAwMjggdGQgMHhjNjdjMWI2MA0KZm9ya190cmFt cG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lDQoNClRyYWNpbmcgY29tbWFuZCBpcnEyODogYmNl MCBwaWQgMzYgdGlkIDEwMDAyOSB0ZCAweGM2N2MxOWMwDQpzY2hlZF9zd2l0Y2goYzY3YzE5YzAs MCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNWINCm1pX3N3aXRjaCgxLDApIGF0IG1pX3N3aXRjaCsw eDI3MA0KaXRocmVhZF9sb29wKGM2OTMzOTcwLGU1M2RjZDM4LGM2OTMzOTcwLGMwNjllNmZjLDAs Li4uKSBhdCBpdGhyZWFkX2xvb3ArMHhkYQ0KZm9ya19leGl0KGMwNjllNmZjLGM2OTMzOTcwLGU1 M2RjZDM4KSBhdCBmb3JrX2V4aXQrMHhhMA0KZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lKzB4OA0KLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGU1M2RjZDZjLCBlYnAg PSAwIC0tLQ0KDQpUcmFjaW5nIGNvbW1hbmQgaXJxOTogYWNwaTAgcGlkIDM1IHRpZCAxMDAwMzAg dGQgMHhjNjdjMTgyMA0KZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lDQoNClRy YWNpbmcgY29tbWFuZCBzd2kyOiBjYW1iaW8gcGlkIDM0IHRpZCAxMDAwMzEgdGQgMHhjNjdjMTY4 MA0KZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lDQoNClRyYWNpbmcgY29tbWFu ZCB4cHRfdGhyZCBwaWQgMzMgdGlkIDEwMDAzMiB0ZCAweGM2N2MxNGUwDQpzY2hlZF9zd2l0Y2go YzY3YzE0ZTAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNWINCm1pX3N3aXRjaCgxLDApIGF0IG1p X3N3aXRjaCsweDI3MA0Kc2xlZXBxX3N3aXRjaChjMGFhNzMwNCxjMGFjNDA4MCwwLGMwOWI1ZGJl LDIxZiwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHhjMQ0Kc2xlZXBxX3dhaXQoYzBhYTczMDQsMCxj MDZhYjA2NCxjMGFjNDBjMCxjMDk2Y2E5NywuLi4pIGF0IHNsZWVwcV93YWl0KzB4NDYNCm1zbGVl cChjMGFhNzMwNCwwLDRjLGMwOTZjYWIyLDApIGF0IG1zbGVlcCsweDI3ZA0KeHB0X3NjYW5uZXJf dGhyZWFkKDAsZTUzZDNkMzgsMCxjMDQ1ZjYyOCwwLC4uLikgYXQgeHB0X3NjYW5uZXJfdGhyZWFk KzB4MzUNCmZvcmtfZXhpdChjMDQ1ZjYyOCwwLGU1M2QzZDM4KSBhdCBmb3JrX2V4aXQrMHhhMA0K Zm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OA0KLS0tIHRyYXAgMHgxLCBl aXAgPSAwLCBlc3AgPSAweGU1M2QzZDZjLCBlYnAgPSAwIC0tLQ0KDQpUcmFjaW5nIGNvbW1hbmQg c3dpNTogKyBwaWQgMzIgdGlkIDEwMDAzMyB0ZCAweGM2OGQ0MDAwDQpmb3JrX3RyYW1wb2xpbmUo KSBhdCBmb3JrX3RyYW1wb2xpbmUNCg0KVHJhY2luZyBjb21tYW5kIHRocmVhZCB0YXNrcSBwaWQg OSB0aWQgMTAwMDM0IHRkIDB4YzY4ZDNkMDANCnNjaGVkX3N3aXRjaChjNjhkM2QwMCwwLDEpIGF0 IHNjaGVkX3N3aXRjaCsweDE1Yg0KbWlfc3dpdGNoKDEsMCkgYXQgbWlfc3dpdGNoKzB4MjcwDQpz bGVlcHFfc3dpdGNoKGM2OGQxYjAwLGMwYWM0MDgwLDAsYzA5YjVkYmUsMjFmLC4uLikgYXQgc2xl ZXBxX3N3aXRjaCsweGMxDQpzbGVlcHFfd2FpdChjNjhkMWIwMCwwLGMwOWI2NDAxLDQ5LDgsLi4u KSBhdCBzbGVlcHFfd2FpdCsweDQ2DQptc2xlZXAoYzY4ZDFiMDAsYzY4ZDFiMWMsMCxjMDlhYmJm NiwwKSBhdCBtc2xlZXArMHgyN2QNCnRhc2txdWV1ZV90aHJlYWRfbG9vcChjMGFjZTg0OCxlNmUz ZWQzOCxjMGFjZTg0OCxjMDZkNTMyYywwLC4uLikgYXQgdGFza3F1ZXVlX3RocmVhZF9sb29wKzB4 NzgNCmZvcmtfZXhpdChjMDZkNTMyYyxjMGFjZTg0OCxlNmUzZWQzOCkgYXQgZm9ya19leGl0KzB4 YTANCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgNCi0tLSB0cmFwIDB4 MSwgZWlwID0gMCwgZXNwID0gMHhlNmUzZWQ2YywgZWJwID0gMCAtLS0NCg0KVHJhY2luZyBjb21t YW5kIGFjcGlfdGFza18yIHBpZCA4IHRpZCAxMDAwMzUgdGQgMHhjNjhkM2I2MA0Kc2NoZWRfc3dp dGNoKGM2OGQzYjYwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTViDQptaV9zd2l0Y2goMSwwKSBh dCBtaV9zd2l0Y2grMHgyNzANCnNsZWVwcV9zd2l0Y2goYzY4ZDFiODAsYzBhYzQwODAsMCxjMDli NWRiZSwyMWYsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4YzENCnNsZWVwcV93YWl0KGM2OGQxYjgw LDAsYzA5YjY0MDEsNDksOCwuLi4pIGF0IHNsZWVwcV93YWl0KzB4NDYNCm1zbGVlcChjNjhkMWI4 MCxjNjhkMWI5YywwLGMwOWFiYmY2LDApIGF0IG1zbGVlcCsweDI3ZA0KdGFza3F1ZXVlX3RocmVh ZF9sb29wKGMwY2E3NTAwLGU2ZTNiZDM4LGMwY2E3NTAwLGMwNmQ1MzJjLDAsLi4uKSBhdCB0YXNr cXVldWVfdGhyZWFkX2xvb3ArMHg3OA0KZm9ya19leGl0KGMwNmQ1MzJjLGMwY2E3NTAwLGU2ZTNi ZDM4KSBhdCBmb3JrX2V4aXQrMHhhMA0KZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9s aW5lKzB4OA0KLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGU2ZTNiZDZjLCBlYnAgPSAw IC0tLQ0KDQpUcmFjaW5nIGNvbW1hbmQgYWNwaV90YXNrXzEgcGlkIDcgdGlkIDEwMDAzNiB0ZCAw eGM2OGQzOWMwDQpzY2hlZF9zd2l0Y2goYzY4ZDM5YzAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgx NWINCm1pX3N3aXRjaCgxLDApIGF0IG1pX3N3aXRjaCsweDI3MA0Kc2xlZXBxX3N3aXRjaChjNjhk MWI4MCxjMGFjNDA4MCwwLGMwOWI1ZGJlLDIxZiwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHhjMQ0K c2xlZXBxX3dhaXQoYzY4ZDFiODAsMCxjMDliNjQwMSw0OSw4LC4uLikgYXQgc2xlZXBxX3dhaXQr MHg0Ng0KbXNsZWVwKGM2OGQxYjgwLGM2OGQxYjljLDAsYzA5YWJiZjYsMCkgYXQgbXNsZWVwKzB4 MjdkDQp0YXNrcXVldWVfdGhyZWFkX2xvb3AoYzBjYTc1MDAsZTZlMzhkMzgsYzBjYTc1MDAsYzA2 ZDUzMmMsMCwuLi4pIGF0IHRhc2txdWV1ZV90aHJlYWRfbG9vcCsweDc4DQpmb3JrX2V4aXQoYzA2 ZDUzMmMsYzBjYTc1MDAsZTZlMzhkMzgpIGF0IGZvcmtfZXhpdCsweGEwDQpmb3JrX3RyYW1wb2xp bmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4DQotLS0gdHJhcCAweDEsIGVpcCA9IDAsIGVzcCA9 IDB4ZTZlMzhkNmMsIGVicCA9IDAgLS0tDQoNClRyYWNpbmcgY29tbWFuZCBhY3BpX3Rhc2tfMCBw aWQgNiB0aWQgMTAwMDM3IHRkIDB4YzY4ZDM4MjANCnNjaGVkX3N3aXRjaChjNjhkMzgyMCwwLDEp IGF0IHNjaGVkX3N3aXRjaCsweDE1Yg0KbWlfc3dpdGNoKDEsMCkgYXQgbWlfc3dpdGNoKzB4Mjcw DQpzbGVlcHFfc3dpdGNoKGM2OGQxYjgwLGMwYWM0MDgwLDAsYzA5YjVkYmUsMjFmLC4uLikgYXQg c2xlZXBxX3N3aXRjaCsweGMxDQpzbGVlcHFfd2FpdChjNjhkMWI4MCwwLGMwOWI2NDAxLDQ5LGM2 OTJhY2MwLC4uLikgYXQgc2xlZXBxX3dhaXQrMHg0Ng0KbXNsZWVwKGM2OGQxYjgwLGM2OGQxYjlj LDAsYzA5YWJiZjYsMCkgYXQgbXNsZWVwKzB4MjdkDQp0YXNrcXVldWVfdGhyZWFkX2xvb3AoYzBj YTc1MDAsZTZlMzVkMzgsYzBjYTc1MDAsYzA2ZDUzMmMsMCwuLi4pIGF0IHRhc2txdWV1ZV90aHJl YWRfbG9vcCsweDc4DQpmb3JrX2V4aXQoYzA2ZDUzMmMsYzBjYTc1MDAsZTZlMzVkMzgpIGF0IGZv cmtfZXhpdCsweGEwDQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4DQot LS0gdHJhcCAweDEsIGVpcCA9IDAsIGVzcCA9IDB4ZTZlMzVkNmMsIGVicCA9IDAgLS0tDQoNClRy YWNpbmcgY29tbWFuZCBzd2k2OiBHaWFudCB0YXNrcSBwaWQgMzEgdGlkIDEwMDAxNyB0ZCAweGM2 N2JkNjgwDQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUNCg0KVHJhY2luZyBj b21tYW5kIHN3aTY6IHRhc2sgcXVldWUgcGlkIDMwIHRpZCAxMDAwMTggdGQgMHhjNjdiZDRlMA0K c2NoZWRfc3dpdGNoKGM2N2JkNGUwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTViDQptaV9zd2l0 Y2goMSwwKSBhdCBtaV9zd2l0Y2grMHgyNzANCml0aHJlYWRfbG9vcChjNjg2ZTRjMCxlNTNiOGQz OCxjNjg2ZTRjMCxjMDY5ZTZmYywwLC4uLikgYXQgaXRocmVhZF9sb29wKzB4ZGENCmZvcmtfZXhp dChjMDY5ZTZmYyxjNjg2ZTRjMCxlNTNiOGQzOCkgYXQgZm9ya19leGl0KzB4YTANCmZvcmtfdHJh bXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgNCi0tLSB0cmFwIDB4MSwgZWlwID0gMCwg ZXNwID0gMHhlNTNiOGQ2YywgZWJwID0gMCAtLS0NCg0KVHJhY2luZyBjb21tYW5kIGtxdWV1ZSB0 YXNrcSBwaWQgNSB0aWQgMTAwMDE5IHRkIDB4YzY3YmQzNDANCnNjaGVkX3N3aXRjaChjNjdiZDM0 MCwwLDEpIGF0IHNjaGVkX3N3aXRjaCsweDE1Yg0KbWlfc3dpdGNoKDEsMCkgYXQgbWlfc3dpdGNo KzB4MjcwDQpzbGVlcHFfc3dpdGNoKGM2ODIyNDAwLGMwYWM0MDgwLDAsYzA5YjVkYmUsMjFmLC4u LikgYXQgc2xlZXBxX3N3aXRjaCsweGMxDQpzbGVlcHFfd2FpdChjNjgyMjQwMCwwLGMwOWI2NDAx LDQ5LDgsLi4uKSBhdCBzbGVlcHFfd2FpdCsweDQ2DQptc2xlZXAoYzY4MjI0MDAsYzY4MjI0MWMs MCxjMDlhYmJmNiwwKSBhdCBtc2xlZXArMHgyN2QNCnRhc2txdWV1ZV90aHJlYWRfbG9vcChjMGFj MjIwMCxlNTNiNWQzOCxjMGFjMjIwMCxjMDZkNTMyYywwLC4uLikgYXQgdGFza3F1ZXVlX3RocmVh ZF9sb29wKzB4NzgNCmZvcmtfZXhpdChjMDZkNTMyYyxjMGFjMjIwMCxlNTNiNWQzOCkgYXQgZm9y a19leGl0KzB4YTANCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgNCi0t LSB0cmFwIDB4MSwgZWlwID0gMCwgZXNwID0gMHhlNTNiNWQ2YywgZWJwID0gMCAtLS0NCg0KVHJh Y2luZyBjb21tYW5kIHlhcnJvdyBwaWQgMjkgdGlkIDEwMDAyMCB0ZCAweGM2N2JkMWEwDQpzY2hl ZF9zd2l0Y2goYzY3YmQxYTAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNWINCm1pX3N3aXRjaCgx LDApIGF0IG1pX3N3aXRjaCsweDI3MA0Kc2xlZXBxX3N3aXRjaChjMGFiZjEwMCxjMGFjNDA4MCww LGMwOWI1ZGJlLDI0NCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHhjMQ0Kc2xlZXBxX3RpbWVkd2Fp dChjMGFiZjEwMCkgYXQgc2xlZXBxX3RpbWVkd2FpdCsweDRhDQptc2xlZXAoYzBhYmYxMDAsMCww LGMwOWFiYmY2LDY0KSBhdCBtc2xlZXArMHgyNTkNCnJhbmRvbV9rdGhyZWFkKDAsZTUzYjJkMzgs MCxjMDYwMTJlYywwLC4uLikgYXQgcmFuZG9tX2t0aHJlYWQrMHgxOTQNCmZvcmtfZXhpdChjMDYw MTJlYywwLGU1M2IyZDM4KSBhdCBmb3JrX2V4aXQrMHhhMA0KZm9ya190cmFtcG9saW5lKCkgYXQg Zm9ya190cmFtcG9saW5lKzB4OA0KLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGU1M2Iy ZDZjLCBlYnAgPSAwIC0tLQ0KDQpUcmFjaW5nIGNvbW1hbmQgZ19kb3duIHBpZCA0IHRpZCAxMDAw MjEgdGQgMHhjNjgyNTgyMA0Kc2NoZWRfc3dpdGNoKGM2ODI1ODIwLDAsMSkgYXQgc2NoZWRfc3dp dGNoKzB4MTViDQptaV9zd2l0Y2goMSwwKSBhdCBtaV9zd2l0Y2grMHgyNzANCnNsZWVwcV9zd2l0 Y2goYzBhYzE5NjgsYzBhYzQwODAsMCxjMDliNWRiZSwyNDQsLi4uKSBhdCBzbGVlcHFfc3dpdGNo KzB4YzENCnNsZWVwcV90aW1lZHdhaXQoYzBhYzE5NjgpIGF0IHNsZWVwcV90aW1lZHdhaXQrMHg0 YQ0KbXNsZWVwKGMwYWMxOTY4LGMwYWMxODQ4LDI0YyxjMDlhYmJmNiw2NCkgYXQgbXNsZWVwKzB4 MjU5DQpnX2lvX3NjaGVkdWxlX2Rvd24oYzY4MjU4MjApIGF0IGdfaW9fc2NoZWR1bGVfZG93bisw eDU2DQpnX2Rvd25fcHJvY2JvZHkoMCxlNmUxYWQzOCwwLGMwNjdjNjRjLDAsLi4uKSBhdCBnX2Rv d25fcHJvY2JvZHkrMHg1YQ0KZm9ya19leGl0KGMwNjdjNjRjLDAsZTZlMWFkMzgpIGF0IGZvcmtf ZXhpdCsweGEwDQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4DQotLS0g dHJhcCAweDEsIGVpcCA9IDAsIGVzcCA9IDB4ZTZlMWFkNmMsIGVicCA9IDAgLS0tDQoNClRyYWNp bmcgY29tbWFuZCBnX3VwIHBpZCAzIHRpZCAxMDAwMjIgdGQgMHhjNjgyNTY4MA0Kc2NoZWRfc3dp dGNoKGM2ODI1NjgwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTViDQptaV9zd2l0Y2goMSwwKSBh dCBtaV9zd2l0Y2grMHgyNzANCnNsZWVwcV9zd2l0Y2goYzBhYzE5NjQsYzBhYzQwODAsMCxjMDli NWRiZSwyNDQsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4YzENCnNsZWVwcV90aW1lZHdhaXQoYzBh YzE5NjQpIGF0IHNsZWVwcV90aW1lZHdhaXQrMHg0YQ0KbXNsZWVwKGMwYWMxOTY0LGMwYWMxODg4 LDI0YyxjMDlhYmJmNiw2NCkgYXQgbXNsZWVwKzB4MjU5DQpnX2lvX3NjaGVkdWxlX3VwKGM2ODI1 NjgwKSBhdCBnX2lvX3NjaGVkdWxlX3VwKzB4MTI3DQpnX3VwX3Byb2Nib2R5KDAsZTZlMTdkMzgs MCxjMDY3YzVlYywwLC4uLikgYXQgZ191cF9wcm9jYm9keSsweDVhDQpmb3JrX2V4aXQoYzA2N2M1 ZWMsMCxlNmUxN2QzOCkgYXQgZm9ya19leGl0KzB4YTANCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZv cmtfdHJhbXBvbGluZSsweDgNCi0tLSB0cmFwIDB4MSwgZWlwID0gMCwgZXNwID0gMHhlNmUxN2Q2 YywgZWJwID0gMCAtLS0NCg0KVHJhY2luZyBjb21tYW5kIGdfZXZlbnQgcGlkIDIgdGlkIDEwMDAy MyB0ZCAweGM2ODI1NGUwDQpzY2hlZF9zd2l0Y2goYzY4MjU0ZTAsMCwxKSBhdCBzY2hlZF9zd2l0 Y2grMHgxNWINCm1pX3N3aXRjaCgxLDApIGF0IG1pX3N3aXRjaCsweDI3MA0Kc2xlZXBxX3N3aXRj aChjMGFjMTk1YyxjMGFjNDA4MCwwLGMwOWI1ZGJlLDI0NCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2gr MHhjMQ0Kc2xlZXBxX3RpbWVkd2FpdChjMGFjMTk1YykgYXQgc2xlZXBxX3RpbWVkd2FpdCsweDRh DQptc2xlZXAoYzBhYzE5NWMsMCw0YyxjMDlhYmJmNiw2NCkgYXQgbXNsZWVwKzB4MjU5DQpnX2V2 ZW50X3Byb2Nib2R5KDAsZTZlMTRkMzgsMCxjMDY3YzZhYywwLC4uLikgYXQgZ19ldmVudF9wcm9j Ym9keSsweDllDQpmb3JrX2V4aXQoYzA2N2M2YWMsMCxlNmUxNGQzOCkgYXQgZm9ya19leGl0KzB4 YTANCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgNCi0tLSB0cmFwIDB4 MSwgZWlwID0gMCwgZXNwID0gMHhlNmUxNGQ2YywgZWJwID0gMCAtLS0NCg0KVHJhY2luZyBjb21t YW5kIHN3aTM6IHZtIHBpZCAyOCB0aWQgMTAwMDI0IHRkIDB4YzY4MjUzNDANCmZvcmtfdHJhbXBv bGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQ0KDQpUcmFjaW5nIGNvbW1hbmQgc3dpNDogY2xvY2sg c2lvIHBpZCAyNyB0aWQgMTAwMDI1IHRkIDB4YzY4MjUxYTANCnNjaGVkX3N3aXRjaChjNjgyNTFh MCwwLDEpIGF0IHNjaGVkX3N3aXRjaCsweDE1Yg0KbWlfc3dpdGNoKDEsMCkgYXQgbWlfc3dpdGNo KzB4MjcwDQppdGhyZWFkX2xvb3AoYzY3OTc4YzAsZTZlMGVkMzgsYzY3OTc4YzAsYzA2OWU2ZmMs MCwuLi4pIGF0IGl0aHJlYWRfbG9vcCsweGRhDQpmb3JrX2V4aXQoYzA2OWU2ZmMsYzY3OTc4YzAs ZTZlMGVkMzgpIGF0IGZvcmtfZXhpdCsweGEwDQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3Ry YW1wb2xpbmUrMHg4DQotLS0gdHJhcCAweDEsIGVpcCA9IDAsIGVzcCA9IDB4ZTZlMGVkNmMsIGVi cCA9IDAgLS0tDQoNClRyYWNpbmcgY29tbWFuZCBzd2kxOiBuZXQgcGlkIDI2IHRpZCAxMDAwMjYg dGQgMHhjNjgyNTAwMA0Kc2NoZWRfc3dpdGNoKGM2ODI1MDAwLDAsMSkgYXQgc2NoZWRfc3dpdGNo KzB4MTViDQptaV9zd2l0Y2goMSwwKSBhdCBtaV9zd2l0Y2grMHgyNzANCml0aHJlYWRfbG9vcChj Njc5NzhkMCxlNmUwYmQzOCxjNjc5NzhkMCxjMDY5ZTZmYywwLC4uLikgYXQgaXRocmVhZF9sb29w KzB4ZGENCmZvcmtfZXhpdChjMDY5ZTZmYyxjNjc5NzhkMCxlNmUwYmQzOCkgYXQgZm9ya19leGl0 KzB4YTANCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgNCi0tLSB0cmFw IDB4MSwgZWlwID0gMCwgZXNwID0gMHhlNmUwYmQ2YywgZWJwID0gMCAtLS0NCg0KVHJhY2luZyBj b21tYW5kIGlkbGU6IGNwdTAgcGlkIDI1IHRpZCAxMDAwMDggdGQgMHhjNjdiYjFhMA0Kc2NoZWRf c3dpdGNoKDQxOTRiOCxkZDMxMzE4MCwwLDAsYzY3YmIxYTAsLi4uKSBhdCBzY2hlZF9zd2l0Y2gr MHgxNWINCl9lbmQoKSBhdCAweGY2NTI5ZDAwDQoNClRyYWNpbmcgY29tbWFuZCBpZGxlOiBjcHUx IHBpZCAyNCB0aWQgMTAwMDA5IHRkIDB4YzY3YmIwMDANCnNjaGVkX3N3aXRjaCgwLGU1Mzk0Y2Mw LDIsZTUzOTRjZjgsYzA5MTQ0OTAsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxNWINCl9lbmQoMCxj NjdjMDQ0MCwwLGM2N2JlYmFjLDAsLi4uKSBhdCAweGM2N2MwNDMwDQpfZW5kKGM2N2JlYmEwLGM2 N2JlYmE0LGM2N2JiMDAwLGM2N2JiMDA4LDAsLi4uKSBhdCAweGM2N2JlYmEwDQpfZW5kKGM2N2Jl YjQwLGM2N2JlYjQ0LGM2N2MxMzQwLGM2N2MxMzQ4LDAsLi4uKSBhdCAweGM2N2MwMjE4DQpfZW5k KGM2N2JlYWUwLGM2N2JlYWU0LGM2N2MxMWEwLGM2N2MxMWE4LDAsLi4uKSBhdCAweGM2N2MwNDMw DQpfZW5kKGM2N2JlYTgwLGM2N2JlYTg0LGM2N2MxMDAwLGM2N2MxMDA4LDAsLi4uKSBhdCAweGM2 N2MwNjQ4DQpfZW5kKGM2N2JlYTIwLGM2N2JlYTI0LGM2N2JkZDAwLGM2N2JkZDA4LDAsLi4uKSBh dCAweGM2N2MwODYwDQpfZW5kKGM2N2JlOWMwLGM2N2JlOWM0LGM2N2JkYjYwLGM2N2JkYjY4LDAs Li4uKSBhdCAweGM2N2MwYTc4DQpfZW5kKGM2N2JlOTYwLGM2N2JlOTY0LGM2N2JkOWMwLGM2N2Jk OWM4LDAsLi4uKSBhdCAweGM2N2MwYzkwDQpfZW5kKGM2N2JlOTAwLGM2N2JlOTA0LGM2N2JkODIw LGM2N2JkODI4LDAsLi4uKSBhdCAweGM2N2NiMDAwDQpfZW5kKGM2N2JmMDAwLGM2N2JmMDA0LGM2 N2JkMDAwLGM2N2JkMDA4LDAsLi4uKSBhdCAweGM2N2NiMjE4DQpfZW5kKGM2N2JlZWEwLGM2N2Jl ZWE0LGM2N2JiZDAwLGM2N2JiZDA4LDAsLi4uKSBhdCAweGM2N2NiNDMwDQpfZW5kKGM2N2JlZTQw LGM2N2JlZTQ0LGM2N2JiYjYwLGM2N2JiYjY4LDAsLi4uKSBhdCAweGM2N2JhMDAwDQpfZW5kKGM2 N2JlZGUwLGM2N2JlZGU0LGM2N2JiOWMwLGM2N2JiOWM4LDAsLi4uKSBhdCAweGM2N2JhMjE4DQpf ZW5kKGM2N2JlZDgwLGM2N2JlZDg0LGM2N2JiODIwLGM2N2JiODI4LDAsLi4uKSBhdCAweGM2N2Jh NDMwDQpfZW5kKGM2N2JlZDIwLGM2N2JlZDI0LGM2N2JiNjgwLGM2N2JiNjg4LDAsLi4uKSBhdCAw eGM2N2JhNjQ4DQpfZW5kKGM2N2JlY2MwLGM2N2JlY2M0LGM2N2JiNGUwLGM2N2JiNGU4LDAsLi4u KSBhdCAweGM2N2JhODYwDQpfZW5kKGM2N2JlYzYwLGM2N2JlYzY0LGM2N2JiMzQwLGM2N2JiMzQ4 LDAsLi4uKSBhdCAweGM2N2JhYTc4DQpfZW5kKGMwYWMxYTAwLGMwYWMxYTA0LGMwYWMxYzgwLGMw YWMxYzg4LDAsLi4uKSBhdCAweGM2N2JhYzkwDQpfZW5kKCkgYXQgMHhjNjdjMDAwMA0KLS1Nb3Jl LS0NICAgICAgICANDQpUcmFjaW5nIGNvbW1hbmQgaWRsZTogY3B1MiBwaWQgMjMgdGlkIDEwMDAx MCB0ZCAweGM2N2MxMzQwDQpzY2hlZF9zd2l0Y2goMjgsNDYsYzA5MTQ1ZjEsYzBiNGNkYTAsZTUz ZDAwMDgsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxNWINCl9lbmQoYzY3YmIzNDAsYzY3YmIzNDgs MCxjNjdjMDAxOCxjNjdiOGQwMCwuLi4pIGF0IDB4YzY3YzAwMjgNCl9lbmQoYzY3YzAwMDgsYzY3 YmIzNDAsYzY3YmIzNTAsMCxjNjdiZWM3NCwuLi4pIGF0IDB4YzY3YmVjNjQNCl9faW5ldF9wdG9u KGM2N2JlYzYwLGM2N2JlYzY0LGM2N2JiMzQwLGM2N2JiMzQ4LDAsLi4uKSBhdCAwDQpfZW5kKGMw YWMxYTAwLGMwYWMxYTA0LGMwYWMxYzgwLGMwYWMxYzg4LDAsLi4uKSBhdCAweGM2N2JhYzkwDQpf ZW5kKCkgYXQgMHhjNjdjMDAwMA0KDQpUcmFjaW5nIGNvbW1hbmQgaWRsZTogY3B1MyBwaWQgMjIg dGlkIDEwMDAxMSB0ZCAweGM2N2MxMWEwDQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1w b2xpbmUNCg0KVHJhY2luZyBjb21tYW5kIGlkbGU6IGNwdTQgcGlkIDIxIHRpZCAxMDAwMTIgdGQg MHhjNjdjMTAwMA0Ka2RiX2VudGVyKGMwOWQ3OTZmKSBhdCBrZGJfZW50ZXIrMHgyYg0Kc2lvaW50 cjEoYzY5YmNjMDAsYzBiMzI2MjAsMCxjMDlkNzc3Yiw1NmUsLi4uKSBhdCBzaW9pbnRyMSsweGNl DQpzaW9pbnRyKGM2OWJjYzAwKSBhdCBzaW9pbnRyKzB4MjENCmludHJfZXhlY3V0ZV9oYW5kbGVy cyhjNjdhZTRjOCxlNTNjYWM5NCw0LGU1M2NhY2Q4LGMwOTE0MjYzLC4uLikgYXQgaW50cl9leGVj dXRlX2hhbmRsZXJzKzB4ZTENCmxhcGljX2hhbmRsZV9pbnRyKDNhKSBhdCBsYXBpY19oYW5kbGVf aW50cisweDJlDQpYYXBpY19pc3IxKCkgYXQgWGFwaWNfaXNyMSsweDMzDQotLS0gaW50ZXJydXB0 LCBlaXAgPSAweGMwYzk4NWUxLCBlc3AgPSAweGU1M2NhY2Q4LCBlYnAgPSAweGU1M2NhY2Q4IC0t LQ0KYWNwaV9jcHVfYzEoMCwwLDAsMTAsYzY3YzBhNzgsLi4uKSBhdCBhY3BpX2NwdV9jMSsweDUN CmFjcGlfY3B1X2lkbGUoZTUzY2FkMGMsYzA2OWRhNTUsYzA2OWQ5ZjgsZTUzY2FkMjQsYzA2OWQ4 MzgsLi4uKSBhdCBhY3BpX2NwdV9pZGxlKzB4MTYyDQpjcHVfaWRsZShjMDY5ZDlmOCxlNTNjYWQy NCxjMDY5ZDgzOCwwLGU1M2NhZDM4LC4uLikgYXQgY3B1X2lkbGUrMHgyOA0KaWRsZV9wcm9jKDAs ZTUzY2FkMzgsMCxjMDY5ZDlmOCwwLC4uLikgYXQgaWRsZV9wcm9jKzB4NWQNCmZvcmtfZXhpdChj MDY5ZDlmOCwwLGU1M2NhZDM4KSBhdCBmb3JrX2V4aXQrMHhhMA0KZm9ya190cmFtcG9saW5lKCkg YXQgZm9ya190cmFtcG9saW5lKzB4OA0KLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGU1 M2NhZDZjLCBlYnAgPSAwIC0tLQ0KDQpUcmFjaW5nIGNvbW1hbmQgaWRsZTogY3B1NSBwaWQgMjAg dGlkIDEwMDAxMyB0ZCAweGM2N2JkZDAwDQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1w b2xpbmUNCg0KVHJhY2luZyBjb21tYW5kIGlkbGU6IGNwdTYgcGlkIDE5IHRpZCAxMDAwMTQgdGQg MHhjNjdiZGI2MA0Kc2NoZWRfc3dpdGNoKGM2ODIxNzAwLGU1M2M0YzEwLGMwNmM3MDAzLGMwYWM0 MDgwLDIsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxNWINCl9lbmQoMCxjNjdjYjAxMCwwLGM2N2Jl OWNjLDAsLi4uKSBhdCAweGM2N2FlMGM4DQpfZW5kKGM2N2JlOWMwLGM2N2JlOWM0LGM2N2JkYjYw LGM2N2JkYjY4LDAsLi4uKSBhdCAweGM2N2JlOWMwDQpfZW5kKGM2N2JlOTYwLGM2N2JlOTY0LGM2 N2JkOWMwLGM2N2JkOWM4LDAsLi4uKSBhdCAweGM2N2MwYzkwDQpfZW5kKGM2N2JlOTAwLGM2N2Jl OTA0LGM2N2JkODIwLGM2N2JkODI4LDAsLi4uKSBhdCAweGM2N2NiMDAwDQpfZW5kKGM2N2JmMDAw LGM2N2JmMDA0LGM2N2JkMDAwLGM2N2JkMDA4LDAsLi4uKSBhdCAweGM2N2NiMjE4DQpfZW5kKGM2 N2JlZWEwLGM2N2JlZWE0LGM2N2JiZDAwLGM2N2JiZDA4LDAsLi4uKSBhdCAweGM2N2NiNDMwDQpf ZW5kKGM2N2JlZTQwLGM2N2JlZTQ0LGM2N2JiYjYwLGM2N2JiYjY4LDAsLi4uKSBhdCAweGM2N2Jh MDAwDQpfZW5kKGM2N2JlZGUwLGM2N2JlZGU0LGM2N2JiOWMwLGM2N2JiOWM4LDAsLi4uKSBhdCAw eGM2N2JhMjE4DQpfZW5kKGM2N2JlZDgwLGM2N2JlZDg0LGM2N2JiODIwLGM2N2JiODI4LDAsLi4u KSBhdCAweGM2N2JhNDMwDQpfZW5kKGM2N2JlZDIwLGM2N2JlZDI0LGM2N2JiNjgwLGM2N2JiNjg4 LDAsLi4uKSBhdCAweGM2N2JhNjQ4DQpfZW5kKGM2N2JlY2MwLGM2N2JlY2M0LGM2N2JiNGUwLGM2 N2JiNGU4LDAsLi4uKSBhdCAweGM2N2JhODYwDQpfZW5kKGM2N2JlYzYwLGM2N2JlYzY0LGM2N2Ji MzQwLGM2N2JiMzQ4LDAsLi4uKSBhdCAweGM2N2JhYTc4DQpfZW5kKGMwYWMxYTAwLGMwYWMxYTA0 LGMwYWMxYzgwLGMwYWMxYzg4LDAsLi4uKSBhdCAweGM2N2JhYzkwDQpfZW5kKCkgYXQgMHhjNjdj MDAwMA0KDQpUcmFjaW5nIGNvbW1hbmQgaWRsZTogY3B1NyBwaWQgMTggdGlkIDEwMDAxNSB0ZCAw eGM2N2JkOWMwDQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUNCg0KVHJhY2lu ZyBjb21tYW5kIGlkbGU6IGNwdTggcGlkIDE3IHRpZCAxMDAwMTYgdGQgMHhjNjdiZDgyMA0Kc2No ZWRfc3dpdGNoKDI4LDQ2LGMwOTE0NWYxLGMwYjRkYzQwLGU1M2IwMDA4LC4uLikgYXQgc2NoZWRf c3dpdGNoKzB4MTViDQpfZW5kKDAsZTZlMDU4NzQsMCwzNDIwMGZmLDAsLi4uKSBhdCAweGM2N2Mw MDI4DQoNClRyYWNpbmcgY29tbWFuZCBpZGxlOiBjcHU5IHBpZCAxNiB0aWQgMTAwMDAwIHRkIDB4 YzY3YmQwMDANCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQ0KDQpUcmFjaW5n IGNvbW1hbmQgaWRsZTogY3B1MTAgcGlkIDE1IHRpZCAxMDAwMDEgdGQgMHhjNjdiYmQwMA0KZm9y a190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lDQoNClRyYWNpbmcgY29tbWFuZCBpZGxl OiBjcHUxMSBwaWQgMTQgdGlkIDEwMDAwMiB0ZCAweGM2N2JiYjYwDQpmb3JrX3RyYW1wb2xpbmUo KSBhdCBmb3JrX3RyYW1wb2xpbmUNCg0KVHJhY2luZyBjb21tYW5kIGlkbGU6IGNwdTEyIHBpZCAx MyB0aWQgMTAwMDAzIHRkIDB4YzY3YmI5YzANCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJh bXBvbGluZQ0KDQpUcmFjaW5nIGNvbW1hbmQgaWRsZTogY3B1MTMgcGlkIDEyIHRpZCAxMDAwMDQg dGQgMHhjNjdiYjgyMA0KZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lDQoNClRy YWNpbmcgY29tbWFuZCBpZGxlOiBjcHUxNCBwaWQgMTEgdGlkIDEwMDAwNSB0ZCAweGM2N2JiNjgw DQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUNCg0KVHJhY2luZyBjb21tYW5k IGlkbGU6IGNwdTE1IHBpZCAxMCB0aWQgMTAwMDA2IHRkIDB4YzY3YmI0ZTANCnNjaGVkX3N3aXRj aCgwLGU1MzlkY2MwLDgwMDAsZTUzOWRjZjgsYzA5MTQ0OTAsLi4uKSBhdCBzY2hlZF9zd2l0Y2gr MHgxNWINCl9lbmQoMCxjNjdiYWNhMCwwLGM2N2JlY2NjLDAsLi4uKSBhdCAweGM2N2JhYzkwDQpf ZW5kKGM2N2JlY2MwLGM2N2JlY2M0LGM2N2JiNGUwLGM2N2JiNGU4LDAsLi4uKSBhdCAweGM2N2Jl Y2MwDQpfZW5kKGM2N2JlYzYwLGM2N2JlYzY0LGM2N2JiMzQwLGM2N2JiMzQ4LDAsLi4uKSBhdCAw eGM2N2JhYTc4DQpfZW5kKGMwYWMxYTAwLGMwYWMxYTA0LGMwYWMxYzgwLGMwYWMxYzg4LDAsLi4u KSBhdCAweGM2N2JhYzkwDQpfZW5kKCkgYXQgMHhjNjdjMDAwMA0KDQpUcmFjaW5nIGNvbW1hbmQg aW5pdCBwaWQgMSB0aWQgMTAwMDA3IHRkIDB4YzY3YmIzNDANCnNjaGVkX3N3aXRjaChjNjdiYjM0 MCwwLDEpIGF0IHNjaGVkX3N3aXRjaCsweDE1Yg0KbWlfc3dpdGNoKDEsMCkgYXQgbWlfc3dpdGNo KzB4MjcwDQpzbGVlcHFfc3dpdGNoKGM2N2MwMDAwKSBhdCBzbGVlcHFfc3dpdGNoKzB4YzENCnNs ZWVwcV93YWl0X3NpZyhjNjdjMDAwMCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4MWQNCm1zbGVlcChj NjdjMDAwMCxjNjdjMDA2OCwxNWMsYzA5YjdmNjEsMCkgYXQgbXNsZWVwKzB4MjZlDQprZXJuX3dh aXQoYzY3YmIzNDAsZmZmZmZmZmYsZTUzOWFjODQsMiwwKSBhdCBrZXJuX3dhaXQrMHg2YmINCndh aXQ0KGM2N2JiMzQwLGU1MzlhZDA0KSBhdCB3YWl0NCsweDJhDQpzeXNjYWxsKDNiLDNiLDNiLGJm YmZlZDM0LDNlLC4uLikgYXQgc3lzY2FsbCsweDIyZg0KWGludDB4ODBfc3lzY2FsbCgpIGF0IFhp bnQweDgwX3N5c2NhbGwrMHgxZg0KLS0tIHN5c2NhbGwgKDcsIEZyZWVCU0QgRUxGMzIsIHdhaXQ0 KSwgZWlwID0gMHg4MDUyZjVmLCBlc3AgPSAweGJmYmZlY2ZjLCBlYnAgPSAweGJmYmZlZDE4IC0t LQ0KDQpUcmFjaW5nIGNvbW1hbmQgc3dhcHBlciBwaWQgMCB0aWQgMCB0ZCAweGMwYWMxYzgwDQpz Y2hlZF9zd2l0Y2goYzBhYzFjODAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNWINCm1pX3N3aXRj aCgxLDApIGF0IG1pX3N3aXRjaCsweDI3MA0Kc2NoZWR1bGVyKDAsMTAxZWMwMCwxMDFlMDAwLDAs YzA0NTdmZDUsLi4uKSBhdCBzY2hlZHVsZXIrMHgxOTkNCm1pX3N0YXJ0dXAoKSBhdCBtaV9zdGFy dHVwKzB4OTYNCmJlZ2luKCkgYXQgYmVnaW4rMHgyYw0KZGI+IA0KdGVsbmV0PiBxdWl0DQpDb25u ZWN0aW9uIGNsb3NlZC4NCgo= --0016367fb71198ea3f048882a2c3-- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 10:59:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7AF01065676 for ; Tue, 8 Jun 2010 10:59:16 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id 62D858FC1D for ; Tue, 8 Jun 2010 10:59:15 +0000 (UTC) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta14.westchester.pa.mail.comcast.net with comcast id TNTL1e0041ap0As5ENzGwd; Tue, 08 Jun 2010 10:59:16 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta22.westchester.pa.mail.comcast.net with comcast id TNzE1e0063S48mS3iNzE36; Tue, 08 Jun 2010 10:59:16 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C12409B42E; Tue, 8 Jun 2010 03:59:12 -0700 (PDT) Date: Tue, 8 Jun 2010 03:59:12 -0700 From: Jeremy Chadwick To: Pawel Jakub Dawidek Message-ID: <20100608105912.GA2239@icarus.home.lan> References: <4BE110E3.8040902@zirakzigil.org> <4BE82C5D.1080806@bit0.com> <20100608.181146.1224841629154014733.kasahara@nc.kyushu-u.ac.jp> <20100608095444.GA86953@icarus.home.lan> <20100608102036.GD1789@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100608102036.GD1789@garage.freebsd.pl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 10:59:16 -0000 On Tue, Jun 08, 2010 at 12:20:36PM +0200, Pawel Jakub Dawidek wrote: > On Tue, Jun 08, 2010 at 02:54:44AM -0700, Jeremy Chadwick wrote: > > SYSCTL_DECL(_vfs_zfs); > > SYSCTL_NODE(_vfs_zfs, OID_AUTO, zio, CTLFLAG_RW, 0, "ZFS ZIO"); > > TUNABLE_INT("vfs.zfs.zio.use_uma", &zio_use_uma); > > SYSCTL_INT(_vfs_zfs_zio, OID_AUTO, use_uma, CTLFLAG_RDTUN, &zio_use_uma, 0, > > "Use uma(9) for ZIO allocations"); > > > > Also note that this tunable does not appear in sysctl -a output; I > > believe this is caused by the first parameter to SYSCTL_INT() being > > incorrect -- should be _vfs_zfs, not _vfs_zfs_zio. Regardless of > > that, it's still adjustable in loader.conf. > > Why? I create vfs.zfs.zio node and create vfs.zfs.zio.use_uma sysctl to > match tunable name. Sorry, I was looking at some example code that used _vfs_zfs, not realising the node delimiter is based on the underscore. So to recap, vfs.zfs.zio.use_uma doesn't show up in sysctl output. There are other pieces of code which declare their own node as well, and those do appear. So the question is why this specific tunable doesn't. Looking through comparative code (specifically sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_cache.c) -- 81 SYSCTL_DECL(_vfs_zfs_vdev); 82 SYSCTL_NODE(_vfs_zfs_vdev, OID_AUTO, cache, CTLFLAG_RW, 0, "ZFS VDEV Cache"); 83 TUNABLE_INT("vfs.zfs.vdev.cache.max", &zfs_vdev_cache_max); 84 SYSCTL_INT(_vfs_zfs_vdev_cache, OID_AUTO, max, CTLFLAG_RDTUN, 85 &zfs_vdev_cache_max, 0, "Maximum I/O request size that increase read size"); 86 TUNABLE_INT("vfs.zfs.vdev.cache.size", &zfs_vdev_cache_size); 87 SYSCTL_INT(_vfs_zfs_vdev_cache, OID_AUTO, size, CTLFLAG_RDTUN, 88 &zfs_vdev_cache_size, 0, "Size of VDEV cache"); 89 TUNABLE_INT("vfs.zfs.vdev.cache.bshift", &zfs_vdev_cache_bshift); 90 SYSCTL_INT(_vfs_zfs_vdev_cache, OID_AUTO, bshift, CTLFLAG_RDTUN, 91 &zfs_vdev_cache_bshift, 0, "Turn too small requests into 1 << this value"); While for sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c -- 41 SYSCTL_DECL(_vfs_zfs); 42 SYSCTL_NODE(_vfs_zfs, OID_AUTO, zio, CTLFLAG_RW, 0, "ZFS ZIO"); 43 TUNABLE_INT("vfs.zfs.zio.use_uma", &zio_use_uma); 44 SYSCTL_INT(_vfs_zfs_zio, OID_AUTO, use_uma, CTLFLAG_RDTUN, &zio_use_uma, 0, 45 "Use uma(9) for ZIO allocations"); I think lines 41 and 42 here are incorrect and should have _vfs_zfs_zio as their first parameter? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 11:04:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E272B1065679; Tue, 8 Jun 2010 11:04:00 +0000 (UTC) (envelope-from petefrench@ticketswitch.com) Received: from constantine.ticketswitch.com (constantine.ticketswitch.com [IPv6:2002:57e0:1d4e:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id A2E578FC1C; Tue, 8 Jun 2010 11:04:00 +0000 (UTC) Received: from dilbert.rattatosk ([10.64.50.6] helo=dilbert.ticketswitch.com) by constantine.ticketswitch.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OLwb2-0004ij-N6; Tue, 08 Jun 2010 12:03:52 +0100 Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OLwb2-000PrL-MH; Tue, 08 Jun 2010 12:03:52 +0100 Date: Tue, 08 Jun 2010 12:03:52 +0100 Message-Id: To: freebsd@jdc.parodius.com, pjd@FreeBSD.org In-Reply-To: <20100608105912.GA2239@icarus.home.lan> From: Pete French Cc: freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 11:04:01 -0000 > So to recap, vfs.zfs.zio.use_uma doesn't show up in sysctl output. Errr, does for me.... $ sysctl -a | grep vfs.zfs.zio.use_uma vfs.zfs.zio.use_uma: 1 Thats from 8.1-PRERELEASE on June 2nd. ...but all the question of sysctls is a bit of a red herring to me ?I'm more intyerested in whether we really need to disable UMA to get stable ZFS on amd64 right now. -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 11:10:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5846106564A for ; Tue, 8 Jun 2010 11:10:36 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id CAE9C8FC0C for ; Tue, 8 Jun 2010 11:10:36 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta15.emeryville.ca.mail.comcast.net with comcast id TP8b1e0011Y3wxoAFPAcZs; Tue, 08 Jun 2010 11:10:36 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.emeryville.ca.mail.comcast.net with comcast id TPAb1e0093S48mS8bPAb3G; Tue, 08 Jun 2010 11:10:36 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 52DDD9B42E; Tue, 8 Jun 2010 04:10:35 -0700 (PDT) Date: Tue, 8 Jun 2010 04:10:35 -0700 From: Jeremy Chadwick To: Yoshiaki Kasahara Message-ID: <20100608111035.GA3014@icarus.home.lan> References: <4BE82C5D.1080806@bit0.com> <20100608.181146.1224841629154014733.kasahara@nc.kyushu-u.ac.jp> <20100608095444.GA86953@icarus.home.lan> <20100608.192645.266793829033956713.kasahara@nc.kyushu-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100608.192645.266793829033956713.kasahara@nc.kyushu-u.ac.jp> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: pjd@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 11:10:37 -0000 On Tue, Jun 08, 2010 at 07:26:45PM +0900, Yoshiaki Kasahara wrote: > On Tue, 8 Jun 2010 02:54:44 -0700, > Jeremy Chadwick said: > > > I realise you're talking about amd64, but I'm not sure how UMA is > > getting enabled on i386 to begin with. It does look like it's enabled > > on amd64 by default. > > I believe that this thread had been started before this tunable was > introduced on May 24th. Before that, ZIO_USE_UMA was used to control > the use of UMA, and it was enabled unconditionally in > /usr/src/sys/modules/zfs. Yoshiaki, thanks for the tip. I didn't check CVS commit logs to see when this tunable was introduced. It appears that the systems I'm looking at don't have the use_uma tunable because the kernel was built from RELENG_8 code dated May 23rd. This would also explain why Pete sees the tunable and I don't. Wish this stuff was documented somewhere. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 15:18:07 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE555106564A; Tue, 8 Jun 2010 15:18:07 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.206]) by mx1.freebsd.org (Postfix) with ESMTP id 46E638FC1C; Tue, 8 Jun 2010 15:18:07 +0000 (UTC) Received: by smtpo.poczta.interia.pl (INTERIA.PL, from userid 502) id 1520C102CF2D; Tue, 8 Jun 2010 17:06:38 +0200 (CEST) Received: by f12.poczta.interia.pl (Postfix, from userid 502) id 9AE531A5305F; Tue, 8 Jun 2010 17:06:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by f12.poczta.interia.pl (Postfix) with ESMTP id 7CEBB1A53053; Tue, 8 Jun 2010 17:06:37 +0200 (CEST) Date: 08 Jun 2010 17:06:37 +0200 From: vermaden Sender: vermaden@interia.pl To: oliver@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-ORIGINATE-IP: 77.112.138.42 X-PRIORITY: 3 X-Mailer: PSE3 Message-Id: <20100608150637.7CEBB1A53053@f12.poczta.interia.pl> X-EMID: 19b40acc Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, bug-followup@FreeBSD.org Subject: Re: ports/139483: x11-fm/thunar name is in lowercase while package name is in uppercase X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 15:18:07 -0000 > I agree with you that this is a bit inconsistent and this had > been done right in the first place when the port was created. > But changing it now - I fear to much problems which may occur by very les= s > gain on th eother hand and this is why I'll not change the package name. I also agree with You mate, backward compatibility is very important, but so is consistency, at least from logical point of view. Maybe we should 'leave it as it is' for next 'BIG' release, or at least till next 'POINT' release (like 8.1-RELEASE for example), and the put all needed info in RELEASE NOTES, that during restructuring the PORTS tree infrastructure all ports were changes to _lowercase_ to make ports tree more consistent and logical, or at least a single package can be lowercase/UPPERCASE in its 'world' treated the same, (lowercase or UPPERCASE but not other). The same of course goes to many other ports, like TeTeX* ports, there are no tetex* ports of course, but using TeTeX name can be VERY misleading ... and I am a long time FreeBSD user/admin. With all respect to TeX 'way' of writing, it should be lowercase. I do not want to 'force' or should I use more appreciate word like 'bring back to order' word, to make it just better. I do not like all the mess in the Linux world, and its pity, that many of us are pointing Linux the mess while we are not 'clear' at the same time. Sorry for CC'ing that message into CURRENT/STABLE MLs, but I just feel that we need to do something about it, to make the FreeBSD (or ports) ecosystem better. For me this change does not mean much, I already KNOW that I must tyle TeTeX or Thunar in the CLI, but think about so many newcomers or just people who did not add that port earlier, its just not logical/consistent, to leave that case 'as is'. As I stated at the beginning, backward compatibility is also very important, so we may 'resolve' that problem in two ways generally, or maybe someone with bigger head then mine come with better solution. 1. Just rename ports to lowercase both in ports and packages with appreciate info in RELEASE NOTES, for some *-RELEASE (8.1-RELEASE comes into my mind of course, or some DOT ZERO release, that will be 9.0-RELEASE in 2012, which may be not so needed delay for that kind of annoucement). 2. Create BOTH lowercase/UPPERCASE/Various packages names both in ports (metaports) and packages (will take disk space), for some time and ANNOUNCE in RELEASE NOTES, that these 'other then lowercase' ports/packages are available only until next release. With all regards to developers/maintainers time, vermaden ---------------------------------------------------------------------- Najlepsza wyszukiwarka tanich lotow! Sprawdz >>> http://linkint.pl/f2726 From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 16:24:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6729E1065679 for ; Tue, 8 Jun 2010 16:24:15 +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 38E888FC1F for ; Tue, 8 Jun 2010 16:24:15 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E0E0946C1F; Tue, 8 Jun 2010 12:24:14 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 3A70C8A021; Tue, 8 Jun 2010 12:24:14 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 8 Jun 2010 11:48:06 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006081148.06315.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 08 Jun 2010 12:24:14 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: pluknet Subject: Re: mfiutil create .. leads to deadlock in 6-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 16:24:15 -0000 On Tuesday 08 June 2010 5:30:30 am pluknet wrote: > hi, > > I faced w/ subj. issue on IBM ServeRAID M5015 (LSISAS2108 SAS2.0 6Gbps). > > As I can see, lockup is caused by sleeping on sx lock after Giant was acquired. > Can r160217 help me or am I go the wrong way? > from r160217: "Use a sleep mutex instead of an sx lock for the kernel > environment." Giant is special, it can be acquired both before and after sx locks because it is released while blocking on an sx lock. Are you sure that mfiutil is hung? The thread appears to be running rather than blocked on a lock. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 17:12:14 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EA4E106566C; Tue, 8 Jun 2010 17:12:14 +0000 (UTC) (envelope-from tabthorpe@goodking.ca) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 843D88FC18; Tue, 8 Jun 2010 17:12:13 +0000 (UTC) Received: by gxk27 with SMTP id 27so182977gxk.13 for ; Tue, 08 Jun 2010 10:12:12 -0700 (PDT) Received: by 10.151.21.21 with SMTP id y21mr15187653ybi.192.1276015338824; Tue, 08 Jun 2010 09:42:18 -0700 (PDT) Received: from tabthorpe@goodking.ca (rex.goodking.ca [208.86.224.77]) by mx.google.com with ESMTPS id v2sm22576336ybh.16.2010.06.08.09.42.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Jun 2010 09:42:18 -0700 (PDT) Sender: Thomas Abthorpe Received: by tabthorpe@goodking.ca (sSMTP sendmail emulation); Tue, 08 Jun 2010 12:42:14 -0400 Date: Tue, 8 Jun 2010 12:42:14 -0400 From: FreeBSD portmgr secretary To: ports@FreeBSD.org, stable@FreeBSD.org Message-ID: <20100608164214.GA40920@rex.goodking.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline X-URL: http://www.freebsd.org X-PGP-Key: http://people.freebsd.org/~portmgr/portmgr-secretary.asc X-PGP-Key-ID: 0x7414629C X-PGP-Key-Fingerprint: D50C BA61 8DC6 C42E 4C05 BF9A 79F6 E071 7414 629C Organization: The FreeBSD Project User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@FreeBSD.org, re@FreeBSD.org, FreeBSD Ports Management Team Subject: [HEADSUP] ports feature freeze starts soon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 17:12:14 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In preparation for 8.1-RELEASE, the ports tree will be in feature freeze after release candidate 1 (RC1) is released, currently planned for June 11. If you have any commits with high impact planned, get them in the tree before then and if they require an experimental build, have a request for one in portmgr@ hands within the next few days. Note that this again will be a feature freeze and not a full freeze. Normal upgrade, new ports, and changes that only affect other branches will be allowed without prior approval but with the extra Feature safe: yes tag in the commit message. Any commit that is sweeping, i.e. touches a large number of ports, infrastructural changes, commits to ports with unusually high number of dependencies, and any other commit that requires the rebuilding of many packages will not be allowed without prior explicit approval from portmgr@ after that date. Thomas with portmgr-secretary@ hat on --=20 Thomas Abthorpe | FreeBSD Ports Management Team Secretary tabthorpe@FreeBSD.org | portmgr-secretary@FreeBSD.org --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwOcuYACgkQefbgcXQUYpwyhwCeLhjJ5kA4QhZPh+Yc/JWBXKaz O+UAoJ6slodOl0OnkzdhZKZgr0tG927r =SdXz -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 17:14:17 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 802791065670 for ; Tue, 8 Jun 2010 17:14:17 +0000 (UTC) (envelope-from sdupille@nospam.fr.eu.org) Received: from mail.nospam.fr.eu.org (galadriel.nospam.fr.eu.org [88.191.16.109]) by mx1.freebsd.org (Postfix) with ESMTP id 498848FC0A for ; Tue, 8 Jun 2010 17:14:16 +0000 (UTC) Received: from galadriel.nospam.fr.eu.org (localhost [127.0.0.1]) (Authenticated sender: dust) by mail.nospam.fr.eu.org (Postfix) with ESMTP id 0EB1A440815 for ; Tue, 8 Jun 2010 18:58:50 +0200 (CEST) From: Stephane Dupille To: stable@freebsd.org Organization: Home Mail-copies-to: never Date: Tue, 08 Jun 2010 18:58:50 +0200 Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Resizing GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 17:14:17 -0000 Hello, I installed a FreeBSD 8.0-RELEASE into a virtual machine (with virtual box), using a GTP partitioning scheme, and zfs. The virtual disk disk is 10 Go. I dumped this disk image to a real machine, which has a 160 Go disk. The system works fine, but I can only use 10 Go of disk space. How can I gain more space ? How can I enlarge the last partition of the disk to use the whole disk ? I tried to create a new partition on the disk, and planned to add it in the zfs pool, but that didn't work : # gpart add -t freebsd-zfs -l disk0f ad0 gpart: autofill: No space left on device That's odd, because it seems that gpart is aware of the new geometry. What's the problem ? Some info : # gpart list Geom name: ad0 fwheads: 16 fwsectors: 63 last: 20971486 first: 34 entries: 128 scheme: GPT Providers: 1. Name: ad0p1 Mediasize: 65536 (64K) Sectorsize: 512 Mode: r0w0e0 rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f label: (null) length: 65536 offset: 17408 type: freebsd-boot index: 1 end: 161 start: 34 2. Name: ad0p2 Mediasize: 4294967296 (4.0G) Sectorsize: 512 Mode: r1w1e1 rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b label: swap0 length: 4294967296 offset: 82944 type: freebsd-swap index: 2 end: 8388769 start: 162 3. Name: ad0p3 Mediasize: 6442351104 (6.0G) Sectorsize: 512 Mode: r1w1e2 rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b label: disk0 length: 6442351104 offset: 4295050240 type: freebsd-zfs index: 3 end: 20971486 start: 8388770 Consumers: 1. Name: ad0 Mediasize: 160041885696 (149G) Sectorsize: 512 # fdisk ad0 ******* Working on device /dev/ad0 ******* parameters extracted from in-core disklabel are: cylinders=310101 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=310101 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 20971487, size 291610321 (142387 Meg), flag 80 (active) beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 80/ sector 63 The data for partition 2 is: sysid 0 (0000),(unused) start 162, size 8388608 (4096 Meg), flag 0 beg: cyl 0/ head 2/ sector 37; end: cyl 522/ head 45/ sector 5 The data for partition 3 is: sysid 0 (0000),(unused) start 8388770, size 12582717 (6143 Meg), flag 0 beg: cyl 522/ head 45/ sector 6; end: cyl 1023/ head 105/ sector 47 The data for partition 4 is: From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 17:14:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95A671065674 for ; Tue, 8 Jun 2010 17:14:17 +0000 (UTC) (envelope-from sdupille@nospam.fr.eu.org) Received: from mail.nospam.fr.eu.org (galadriel.nospam.fr.eu.org [88.191.16.109]) by mx1.freebsd.org (Postfix) with ESMTP id 498F88FC0C for ; Tue, 8 Jun 2010 17:14:16 +0000 (UTC) Received: from galadriel.nospam.fr.eu.org (localhost [127.0.0.1]) (Authenticated sender: dust) by mail.nospam.fr.eu.org (Postfix) with ESMTP id B1CF8440817 for ; Tue, 8 Jun 2010 19:02:38 +0200 (CEST) From: Stephane Dupille To: freebsd-stable@freebsd.org Organization: Home Mail-copies-to: never Date: Tue, 08 Jun 2010 18:58:50 +0200 User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/22.1 (berkeley-unix) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Resizing GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 17:14:17 -0000 Hello, I installed a FreeBSD 8.0-RELEASE into a virtual machine (with virtual box), using a GTP partitioning scheme, and zfs. The virtual disk disk is 10 Go. I dumped this disk image to a real machine, which has a 160 Go disk. The system works fine, but I can only use 10 Go of disk space. How can I gain more space ? How can I enlarge the last partition of the disk to use the whole disk ? I tried to create a new partition on the disk, and planned to add it in the zfs pool, but that didn't work : # gpart add -t freebsd-zfs -l disk0f ad0 gpart: autofill: No space left on device That's odd, because it seems that gpart is aware of the new geometry. What's the problem ? Some info : # gpart list Geom name: ad0 fwheads: 16 fwsectors: 63 last: 20971486 first: 34 entries: 128 scheme: GPT Providers: 1. Name: ad0p1 Mediasize: 65536 (64K) Sectorsize: 512 Mode: r0w0e0 rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f label: (null) length: 65536 offset: 17408 type: freebsd-boot index: 1 end: 161 start: 34 2. Name: ad0p2 Mediasize: 4294967296 (4.0G) Sectorsize: 512 Mode: r1w1e1 rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b label: swap0 length: 4294967296 offset: 82944 type: freebsd-swap index: 2 end: 8388769 start: 162 3. Name: ad0p3 Mediasize: 6442351104 (6.0G) Sectorsize: 512 Mode: r1w1e2 rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b label: disk0 length: 6442351104 offset: 4295050240 type: freebsd-zfs index: 3 end: 20971486 start: 8388770 Consumers: 1. Name: ad0 Mediasize: 160041885696 (149G) Sectorsize: 512 # fdisk ad0 ******* Working on device /dev/ad0 ******* parameters extracted from in-core disklabel are: cylinders=310101 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=310101 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 20971487, size 291610321 (142387 Meg), flag 80 (active) beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 80/ sector 63 The data for partition 2 is: sysid 0 (0000),(unused) start 162, size 8388608 (4096 Meg), flag 0 beg: cyl 0/ head 2/ sector 37; end: cyl 522/ head 45/ sector 5 The data for partition 3 is: sysid 0 (0000),(unused) start 8388770, size 12582717 (6143 Meg), flag 0 beg: cyl 522/ head 45/ sector 6; end: cyl 1023/ head 105/ sector 47 The data for partition 4 is: From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 17:58:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1E19106566C for ; Tue, 8 Jun 2010 17:58:38 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by mx1.freebsd.org (Postfix) with ESMTP id 986F28FC15 for ; Tue, 8 Jun 2010 17:58:38 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=rQFZ6L6Aal0vML9zeUI9ITHmZV0MH09wIB0oRAt2u7aY2kIpQul1K9zlZ/TfxNib; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OM2sC-0000gw-Td for freebsd-stable@freebsd.org; Tue, 08 Jun 2010 13:46:00 -0400 Message-ID: <4C0E81D7.8020209@earthlink.net> Date: Tue, 08 Jun 2010 13:45:59 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec79786c24edc18d65cb7afbe50e2f659a42350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Subject: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 17:58:38 -0000 Hi, Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when 4.9 didn't? ***** 6.3 ***** $ sudo ipfstat -nio empty list for ipfilter(out) empty list for ipfilter(in) Z2984:~ $ ifconfig rl0 rl0: flags=8843 mtu 1500 options=8 inet 192.168.129.1 netmask 0xffffff00 broadcast 192.168.129.255 inet 169.254.1.1 netmask 0xffff0000 broadcast 169.254.255.255 ether 00:30:18:ae:7c:77 media: Ethernet autoselect (100baseTX ) status: active Z2984:~ $ ping 169.254.1.1 PING 169.254.1.1 (169.254.1.1): 56 data bytes ^C --- 169.254.1.1 ping statistics --- 4 packets transmitted, 0 packets received, 100% packet loss Z2984:~ $ uname -a FreeBSD Z2984.netwolves.com 6.3-RELEASE-p15 FreeBSD 6.3-RELEASE-p15 #17: Fri Apr 16 12:51:57 EST 2010 **** 4.9 ***** FreeBSD H101494.com 4.9-STABLE FreeBSD 4.9-STABLE #59: Thu Mar 30 13:42:10 EST 2006 root@A1234.com:/mnt2/src/sys/compile/ i386 H101494# ipf -Fa H101494# ipfstat -nio empty list for ipfilter(out) empty list for ipfilter(in) H101494# ifconfig rl0 rl0: flags=8843 mtu 1500 inet 10.254.151.1 netmask 0xffffff00 broadcast 10.254.151.255 inet 10.255.3.30 netmask 0xffffffff broadcast 10.255.3.30 inet 10.255.4.30 netmask 0xffffffff broadcast 10.255.4.30 inet 169.254.202.1 netmask 0xffff0000 broadcast 169.254.255.255 ether 00:30:18:a3:49:b5 media: Ethernet autoselect (none) status: no carrier H101494# ping 169.254.202.1 PING 169.254.202.1 (169.254.202.1): 56 data bytes 64 bytes from 169.254.202.1: icmp_seq=0 ttl=64 time=0.052 ms 64 bytes from 169.254.202.1: icmp_seq=1 ttl=64 time=0.080 ms 64 bytes from 169.254.202.1: icmp_seq=2 ttl=64 time=0.081 ms ^C --- 169.254.202.1 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.052/0.071/0.081/0.013 ms Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 18:05:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E7DA1065670 for ; Tue, 8 Jun 2010 18:05:08 +0000 (UTC) (envelope-from jdc@koitsu.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 67AE58FC1B for ; Tue, 8 Jun 2010 18:05:08 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta05.emeryville.ca.mail.comcast.net with comcast id TQEJ1e0030lTkoCA5W580H; Tue, 08 Jun 2010 18:05:08 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta04.emeryville.ca.mail.comcast.net with comcast id TW571e0073S48mS8QW57Vz; Tue, 08 Jun 2010 18:05:07 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id CFC0A9B418; Tue, 8 Jun 2010 11:05:06 -0700 (PDT) Date: Tue, 8 Jun 2010 11:05:06 -0700 From: Jeremy Chadwick To: Stephen Clark Message-ID: <20100608180506.GA9340@icarus.home.lan> References: <4C0E81D7.8020209@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C0E81D7.8020209@earthlink.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Stable Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 18:05:08 -0000 On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: > Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when > 4.9 didn't? The following output would help: - ifconfig -a - netstat -rn - Contents of /etc/rc.conf Also, be aware that RELENG_6 is to be EOL'd at the end of this year: http://security.freebsd.org/ -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 18:26:13 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBC4E106567A for ; Tue, 8 Jun 2010 18:26:13 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by mx1.freebsd.org (Postfix) with ESMTP id 777338FC1B for ; Tue, 8 Jun 2010 18:26:13 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=RROyeUd1qw47F1hQsKzq6Pcpzw99R6wA0Kah8HDC9oVw7tNyDhAQkVMxwAZjPP3j; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OM3V6-0001G8-OQ; Tue, 08 Jun 2010 14:26:12 -0400 Message-ID: <4C0E8B42.70603@earthlink.net> Date: Tue, 08 Jun 2010 14:26:10 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jeremy Chadwick References: <4C0E81D7.8020209@earthlink.net> <20100608180506.GA9340@icarus.home.lan> In-Reply-To: <20100608180506.GA9340@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec79d1ac86fc3f40b710766b08daeb6e10f2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Cc: FreeBSD Stable Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 18:26:13 -0000 On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: > On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: >> Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when >> 4.9 didn't? > > The following output would help: > > - ifconfig -a > - netstat -rn > - Contents of /etc/rc.conf > > Also, be aware that RELENG_6 is to be EOL'd at the end of this year: > http://security.freebsd.org/ > Hi Jeremy, I am not sure that information is relevant. We have two systems configured identically one using 4.9 the other 6.3. We were replacing the 4.9 system with the 6.3 system. The internal lan had been setup on the 4.9 box using dhcpd handing out ip addresses in the 169.254.202/24 range. This box had been working for years. When we replaced it with the identically configured 6.3 box we could no longer ping the internal interface which had an ip address of 169.254.202.1. So after spending about a day trouble shooting we finally realized if we changed the address to 169.253.202.1 everything worked on the 6.3 box. Investigating the 169.254.x.x address shows it is normally used when a box can't get an address using dhcp so it assigns one randomly from the 169.254.x.x address space. I don't know what happened with 6.3 but any 6.3 box we assign and address in that range then you can't ping the address. This is from another box. srmrd# ifconfig bge0 169.254.1.1 srmrd# ping 169.254.1.1 PING 169.254.1.1 (169.254.1.1): 56 data bytes ^C --- 169.254.1.1 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss srmrd# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.198.252 UGS 0 2711166 fxp0 10.0.128/17 link#1 UC 0 0 fxp0 10.0.128.1 00:30:18:a3:47:a5 UHLW 1 3805 fxp0 1155 10.0.129.5 00:00:24:ca:65:ec UHLW 1 33348 fxp0 1154 10.0.129.91 00:1c:c0:94:3a:12 UHLW 1 149 fxp0 773 10.0.129.101 00:b0:d0:fe:89:d9 UHLW 1 58 lo0 127.0.0.1 127.0.0.1 UH 0 18437 lo0 169.254 link#2 UC 0 0 bge0 169.254.1.1 00:b0:d0:fe:89:da UHLW 1 3 lo0 192.168.198 link#1 UC 0 0 fxp0 192.168.198.94 00:02:b6:36:e9:4a UHLW 1 1490 fxp0 1113 192.168.198.98 00:90:c2:c7:5e:78 UHLW 1 3369 fxp0 255 192.168.198.101 00:04:23:b6:da:8d UHLW 1 1458 fxp0 1153 192.168.198.252 00:30:18:a3:47:90 UHLW 2 0 fxp0 1144 192.168.198.253 00:30:18:a3:47:a3 UHLW 1 25662 fxp0 801 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UHL lo0 fe80::%lo0/64 fe80::1%lo0 U lo0 fe80::1%lo0 link#4 UHL lo0 ff01:4::/32 fe80::1%lo0 UC lo0 ff02::%lo0/32 fe80::1%lo0 UC lo0 srmrd# uname -a FreeBSD srmrd.com 6.3-RELEASE-p13 FreeBSD 6.3-RELEASE-p13 #1: Tue Oct 13 09:07:05 EDT 2009 root@srmrd..com:/usr/src/sys/i386/compile/SMP i386 ************************** Here I added an alias ip srmrd# ifconfig bge0 alias 169.253.1.1 srmrd# ping 169.253.1.1 PING 169.253.1.1 (169.253.1.1): 56 data bytes 64 bytes from 169.253.1.1: icmp_seq=0 ttl=64 time=0.082 ms 64 bytes from 169.253.1.1: icmp_seq=1 ttl=64 time=0.055 ms 64 bytes from 169.253.1.1: icmp_seq=2 ttl=64 time=0.056 ms 64 bytes from 169.253.1.1: icmp_seq=3 ttl=64 time=0.053 ms 64 bytes from 169.253.1.1: icmp_seq=4 ttl=64 time=0.061 ms ^C --- 169.253.1.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.053/0.061/0.082/0.011 ms srmrd# netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.198.252 UGS 0 2711166 fxp0 10.0.128/17 link#1 UC 0 0 fxp0 10.0.128.1 00:30:18:a3:47:a5 UHLW 1 3805 fxp0 892 10.0.129.5 00:00:24:ca:65:ec UHLW 1 33356 fxp0 1128 10.0.129.91 00:1c:c0:94:3a:12 UHLW 1 274 fxp0 510 10.0.129.101 00:b0:d0:fe:89:d9 UHLW 1 58 lo0 127.0.0.1 127.0.0.1 UH 0 18437 lo0 169.253 link#2 UC 0 0 bge0 169.253.1.1 00:b0:d0:fe:89:da UHLW 1 10 lo0 169.254 link#2 UC 0 0 bge0 169.254.1.1 00:b0:d0:fe:89:da UHLW 1 3 lo0 192.168.198 link#1 UC 0 0 fxp0 192.168.198.94 00:02:b6:36:e9:4a UHLW 1 1490 fxp0 1090 192.168.198.98 00:90:c2:c7:5e:78 UHLW 1 3394 fxp0 1196 192.168.198.101 00:04:23:b6:da:8d UHLW 1 1458 fxp0 1100 192.168.198.252 00:30:18:a3:47:90 UHLW 2 0 fxp0 1182 192.168.198.253 00:30:18:a3:47:a3 UHLW 1 25662 fxp0 1187 Regards, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 18:30:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9885D1065678 for ; Tue, 8 Jun 2010 18:30:51 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by mx1.freebsd.org (Postfix) with ESMTP id 571E48FC1B for ; Tue, 8 Jun 2010 18:30:51 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=YTAbgVj/OKU9KwyOu9J9VbM5kMy2fsebBRiwBEslxdIWzhRinmbBmFO2r9vKhOgn; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OM3Za-0006SW-Lp; Tue, 08 Jun 2010 14:30:50 -0400 Message-ID: <4C0E8C59.5010202@earthlink.net> Date: Tue, 08 Jun 2010 14:30:49 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Guy Helmer References: <4C0E81D7.8020209@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec791fb6753fe7843360d1314e21d5e8b740350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Cc: FreeBSD Stable Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 18:30:51 -0000 On 06/08/2010 02:21 PM, Guy Helmer wrote: > On Jun 8, 2010, at 12:45 PM, Stephen Clark wrote: > >> Hi, >> >> Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when >> 4.9 didn't? >> >> ***** 6.3 ***** >> $ sudo ipfstat -nio >> empty list for ipfilter(out) >> empty list for ipfilter(in) >> Z2984:~ >> $ ifconfig rl0 >> rl0: flags=8843 mtu 1500 >> options=8 >> inet 192.168.129.1 netmask 0xffffff00 broadcast 192.168.129.255 >> inet 169.254.1.1 netmask 0xffff0000 broadcast 169.254.255.255 >> ether 00:30:18:ae:7c:77 >> media: Ethernet autoselect (100baseTX) >> status: active >> Z2984:~ >> $ ping 169.254.1.1 >> PING 169.254.1.1 (169.254.1.1): 56 data bytes >> ^C >> --- 169.254.1.1 ping statistics --- >> 4 packets transmitted, 0 packets received, 100% packet loss >> Z2984:~ >> $ uname -a >> FreeBSD Z2984.netwolves.com 6.3-RELEASE-p15 FreeBSD 6.3-RELEASE-p15 #17: Fri Apr 16 12:51:57 EST 2010 >> >> **** 4.9 ***** >> FreeBSD H101494.com 4.9-STABLE FreeBSD 4.9-STABLE #59: Thu Mar 30 13:42:10 EST 2006 root@A1234.com:/mnt2/src/sys/compile/ i386 >> H101494# ipf -Fa >> H101494# ipfstat -nio >> empty list for ipfilter(out) >> empty list for ipfilter(in) >> H101494# ifconfig rl0 >> rl0: flags=8843 mtu 1500 >> inet 10.254.151.1 netmask 0xffffff00 broadcast 10.254.151.255 >> inet 10.255.3.30 netmask 0xffffffff broadcast 10.255.3.30 >> inet 10.255.4.30 netmask 0xffffffff broadcast 10.255.4.30 >> inet 169.254.202.1 netmask 0xffff0000 broadcast 169.254.255.255 >> ether 00:30:18:a3:49:b5 >> media: Ethernet autoselect (none) >> status: no carrier >> H101494# ping 169.254.202.1 >> PING 169.254.202.1 (169.254.202.1): 56 data bytes >> 64 bytes from 169.254.202.1: icmp_seq=0 ttl=64 time=0.052 ms >> 64 bytes from 169.254.202.1: icmp_seq=1 ttl=64 time=0.080 ms >> 64 bytes from 169.254.202.1: icmp_seq=2 ttl=64 time=0.081 ms >> ^C >> --- 169.254.202.1 ping statistics --- >> 3 packets transmitted, 3 packets received, 0% packet loss >> round-trip min/avg/max/stddev = 0.052/0.071/0.081/0.013 ms >> >> > > > That was a feature added to sys/netinet/in.c and ip_input.c back in 2007 to obey RFC 3927 not to output datagrams destined for 169.254.0.0/16. > > On a system that needed to be able to send datagrams to 169.254.0.0/16 addresses, I wrote this patch to add a sysctl knob net.inet.fwd_link_local to dynamically allow a system to send those datagrams: > > > Index: in.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/in.c,v > retrieving revision 1.102.2.4.2.1 > diff -u -r1.102.2.4.2.1 in.c > --- in.c 15 Apr 2009 03:14:26 -0000 1.102.2.4.2.1 > +++ in.c 29 Jul 2009 15:10:42 -0000 > @@ -67,6 +67,9 @@ > struct in_ifaddr *, struct sockaddr_in *, int); > static void in_purgemaddrs(struct ifnet *); > > +int ip_fwdlinklocal = 0; > +SYSCTL_INT(_net_inet_ip, OID_AUTO, fwd_link_local, CTLFLAG_RW, > + &ip_fwdlinklocal, 0, "Forward link-local addresses"); > static int subnetsarelocal = 0; > SYSCTL_INT(_net_inet_ip, OID_AUTO, subnets_are_local, CTLFLAG_RW, > &subnetsarelocal, 0, "Treat all subnets as directly connected"); > @@ -129,7 +132,8 @@ > register u_long i = ntohl(in.s_addr); > register u_long net; > > - if (IN_EXPERIMENTAL(i) || IN_MULTICAST(i) || IN_LINKLOCAL(i)) > + if (IN_EXPERIMENTAL(i) || IN_MULTICAST(i) || > + (!ip_fwdlinklocal&& IN_LINKLOCAL(i))) > return (0); > if (IN_CLASSA(i)) { > net = i& IN_CLASSA_NET; > Index: ip_input.c > =================================================================== > RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v > retrieving revision 1.332.2.5.2.1 > diff -u -r1.332.2.5.2.1 ip_input.c > --- ip_input.c 15 Apr 2009 03:14:26 -0000 1.332.2.5.2.1 > +++ ip_input.c 29 Jul 2009 15:10:44 -0000 > @@ -134,6 +134,7 @@ > static struct ifqueue ipintrq; > static int ipqmaxlen = IFQ_MAXLEN; > > +extern int ip_fwdlinklocal; > extern struct domain inetdomain; > extern struct protosw inetsw[]; > u_char ip_protox[IPPROTO_MAX]; > @@ -532,7 +533,7 @@ > } > } > /* RFC 3927 2.7: Do not forward datagrams for 169.254.0.0/16. */ > - if (IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) { > + if (!ip_fwdlinklocal&& IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) { > ipstat.ips_cantforward++; > m_freem(m); > return; > > Hmmm... how is not responding to pings associated with forwarding? -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 18:36:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 492CB1065674 for ; Tue, 8 Jun 2010 18:36:05 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from thalia-smout.broadpark.no (thalia-smout.broadpark.no [80.202.8.21]) by mx1.freebsd.org (Postfix) with ESMTP id 051278FC18 for ; Tue, 8 Jun 2010 18:36:04 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ignis-smin.broadpark.no ([unknown] [80.202.8.11]) by thalia-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-12.01 64bit (built Oct 15 2009)) with ESMTP id <0L3P005JUL03MN20@thalia-smout.broadpark.no> for freebsd-stable@freebsd.org; Tue, 08 Jun 2010 20:36:03 +0200 (CEST) Received: from kg-v2.kg4.no ([unknown] [80.203.92.186]) by ignis-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-12.01 64bit (built Oct 15 2009)) with SMTP id <0L3P00BD0L03TO80@ignis-smin.broadpark.no> for freebsd-stable@freebsd.org; Tue, 08 Jun 2010 20:36:03 +0200 (CEST) Date: Tue, 08 Jun 2010 20:36:02 +0200 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100608203602.c328e7ab.torfinn.ingolfsen@broadpark.no> In-reply-to: <4C0E8C59.5010202@earthlink.net> References: <4C0E81D7.8020209@earthlink.net> <4C0E8C59.5010202@earthlink.net> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; amd64-portbld-freebsd8.0) X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq; m"_0v; ~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 18:36:05 -0000 On Tue, 08 Jun 2010 14:30:49 -0400 Stephen Clark wrote: > Hmmm... how is not responding to pings associated with forwarding? See http://en.wikipedia.org/wiki/169.254 Link Local addresses are special. HTH -- Regards, Torfinn Ingolfsen From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 18:36:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B40FF106566C for ; Tue, 8 Jun 2010 18:36:09 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7A6CC8FC13 for ; Tue, 8 Jun 2010 18:36:09 +0000 (UTC) Received: by iwn7 with SMTP id 7so1249727iwn.13 for ; Tue, 08 Jun 2010 11:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=VH9Sfz5Um0X9E5fkmabJRirHYxN4Ia7kF5yHNpSZEUs=; b=rsv3S6svALjrDfJiOAedfbI621PaQP8kLTH70UM4Gho5qPmpW5qJELnPLUiSS1dzOY ucyFP4ABw7ZdK8wLfUpSdUQTOrM8bcDx0eS4XhMkPVtm0Qnym90C+9d7028i0nZ5cyJZ 62u9J9vAHv2LfIOZBvjikVjgdZv7pPkRSpOCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xAzLcHeiDVQZAtSjz2fTQbf2KNGzPg6eIVjwQPSQp6fN0jPK7spYr01cxmTeqFuFnW 96D2SjmcesG6A9JHW5Vw9XqEota1kUbMzBi+MBczJt0j2JZnfly1H5DqgihqfDK67Pbj yDehGWJlS6LX0krGsRZSY/DCD8bVF/E3/znbc= MIME-Version: 1.0 Received: by 10.224.34.141 with SMTP id l13mr2081448qad.220.1276022160219; Tue, 08 Jun 2010 11:36:00 -0700 (PDT) Received: by 10.229.233.74 with HTTP; Tue, 8 Jun 2010 11:36:00 -0700 (PDT) In-Reply-To: <4C0E8B42.70603@earthlink.net> References: <4C0E81D7.8020209@earthlink.net> <20100608180506.GA9340@icarus.home.lan> <4C0E8B42.70603@earthlink.net> Date: Tue, 8 Jun 2010 11:36:00 -0700 Message-ID: From: Garrett Cooper To: sclark46@earthlink.net Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Stable , Jeremy Chadwick Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 18:36:09 -0000 On Tue, Jun 8, 2010 at 11:26 AM, Stephen Clark wrote: > On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: >> >> On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: >>> >>> Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when >>> 4.9 didn't? >> >> The following output would help: >> >> - ifconfig -a >> - netstat -rn >> - Contents of /etc/rc.conf >> >> Also, be aware that RELENG_6 is to be EOL'd at the end of this year: >> http://security.freebsd.org/ >> > Hi Jeremy, > > I am not sure that information is relevant. We have two systems configured > identically one using 4.9 the other 6.3. > > We were replacing the 4.9 system with the 6.3 system. > The internal lan had been setup on the 4.9 box using dhcpd > handing out ip addresses in the 169.254.202/24 range. > > This box had been working for years. > > When we replaced it with the identically configured 6.3 box > we could no longer ping the internal interface which had an ip > address of 169.254.202.1. So after spending about a day trouble > shooting we finally realized if we changed the address to > 169.253.202.1 everything worked on the 6.3 box. Yes... the problem is that you're handing out auto-DHCP IP addresses to clients using dhcpd .. I wouldn't expect this to work particularly well unless you have routing set up for that (especially because there is code in the kernel that is explicitly told to not route packets from this psuedo subnet due to an RFC change (look for RFC 3927 2.7 under sys/netinet/ip_input.c). Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 18:38:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B4051065675 for ; Tue, 8 Jun 2010 18:38:44 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id C37058FC28 for ; Tue, 8 Jun 2010 18:38:43 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id o58IcXhZ004630 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 8 Jun 2010 19:38:38 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) Message-ID: <4C0E8E29.1080606@infracaninophile.co.uk> Date: Tue, 08 Jun 2010 19:38:33 +0100 From: Matthew Seaman Organization: Infracaninophile User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C0E81D7.8020209@earthlink.net> <20100608180506.GA9340@icarus.home.lan> In-Reply-To: <20100608180506.GA9340@icarus.home.lan> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.1 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50,DKIM_ADSP_ALL, SPF_FAIL,TO_NO_BRKTS_DIRECT autolearn=no version=3.3.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lucid-nonsense.infracaninophile.co.uk Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 18:38:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/06/2010 19:05:06, Jeremy Chadwick wrote: > On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: >> Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when >> 4.9 didn't? > > The following output would help: > > - ifconfig -a > - netstat -rn > - Contents of /etc/rc.conf > > Also, be aware that RELENG_6 is to be EOL'd at the end of this year: > http://security.freebsd.org/ > 169.254.0.0/16 is reserved address space for "Dynamic Configuration of IPv4 Link-Local Addresses" -- see RFC 3927. I'm sure you know all this, as you wouldn't have any other reason to be using addresses from that range. Basically it's an IPv4 equivalent to the IPv6 rtadv/rtsol thing. The addresses from that range are non-routable, similarly to the RFC 1918 private ranges, but that's just a convention for RFC1918, and I can see there is special code to handle RFC 3927 eg in: http://lists.freebsd.org/pipermail/svn-src-head/2009-September/009999.html Are you using avahi-autoipd ? Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwOjikACgkQ8Mjk52CukIyQLgCfXU3ta0DDR3igI1GowZ+SS0LM V/4AnApoNaezDb8cj3OuWOImQ90GZ9j+ =A7eE -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 18:40:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5BE3106567D for ; Tue, 8 Jun 2010 18:40:41 +0000 (UTC) (envelope-from yanefbsd@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 B80548FC16 for ; Tue, 8 Jun 2010 18:40:41 +0000 (UTC) Received: by pwj1 with SMTP id 1so2759365pwj.13 for ; Tue, 08 Jun 2010 11:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1mrlLzfBVtszeAtXFAZ7WhzqRG2Wn+gnuQtQj+2GFUs=; b=cSCogPckWjRiHgDwg7i0iiVEsl6Uudl2NAI84bHF5ic3E+pZb5H+zXoxK8A6iRLPO0 su/EKCSkYcnq84jyaTEQeRTlytsUOg4Dc4gs3r8LNAMKVL/cPOJdboRrEOUv/kVXL22a CVBqvJ6CNoh/aZd/WxwXNSrnKbBfHGH3iNHVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RHuOzrglElH4UA0fbi5R5y7THsrP7CBzNmfZFt6NTx//K9ylvn9tbB+c6x2EyE/Zdn BayoMZey9BCWnT6zEfkkJ9GupLZDs057s0M11QNAjuNodr51Z23ziDEGXs1CaGG95/+9 HfLR9hpd1wXeRuMUi12lBMpXfXBT4rGr2e6tw= MIME-Version: 1.0 Received: by 10.224.106.130 with SMTP id x2mr349500qao.245.1276022440629; Tue, 08 Jun 2010 11:40:40 -0700 (PDT) Received: by 10.229.233.74 with HTTP; Tue, 8 Jun 2010 11:40:38 -0700 (PDT) In-Reply-To: <4C0E8C59.5010202@earthlink.net> References: <4C0E81D7.8020209@earthlink.net> <4C0E8C59.5010202@earthlink.net> Date: Tue, 8 Jun 2010 11:40:38 -0700 Message-ID: From: Garrett Cooper To: sclark46@earthlink.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Guy Helmer , FreeBSD Stable Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 18:40:42 -0000 On Tue, Jun 8, 2010 at 11:30 AM, Stephen Clark wro= te: > On 06/08/2010 02:21 PM, Guy Helmer wrote: >> >> On Jun 8, 2010, at 12:45 PM, Stephen Clark wrote: >> >>> Hi, >>> >>> Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when >>> 4.9 didn't? >>> >>> ***** 6.3 ***** >>> $ sudo ipfstat -nio >>> empty list for ipfilter(out) >>> empty list for ipfilter(in) >>> Z2984:~ >>> $ ifconfig rl0 >>> rl0: flags=3D8843 =A0mtu 1500 >>> =A0 =A0 =A0 =A0options=3D8 >>> =A0 =A0 =A0 =A0inet 192.168.129.1 netmask 0xffffff00 broadcast 192.168.= 129.255 >>> =A0 =A0 =A0 =A0inet 169.254.1.1 netmask 0xffff0000 broadcast 169.254.25= 5.255 >>> =A0 =A0 =A0 =A0ether 00:30:18:ae:7c:77 >>> =A0 =A0 =A0 =A0media: Ethernet autoselect (100baseTX) >>> =A0 =A0 =A0 =A0status: active >>> Z2984:~ >>> $ ping 169.254.1.1 >>> PING 169.254.1.1 (169.254.1.1): 56 data bytes >>> ^C >>> --- 169.254.1.1 ping statistics --- >>> 4 packets transmitted, 0 packets received, 100% packet loss >>> Z2984:~ >>> $ uname -a >>> FreeBSD Z2984.netwolves.com 6.3-RELEASE-p15 FreeBSD 6.3-RELEASE-p15 #17= : >>> Fri Apr 16 12:51:57 EST 2010 >>> >>> **** 4.9 ***** >>> FreeBSD H101494.com 4.9-STABLE FreeBSD 4.9-STABLE #59: Thu Mar 30 >>> 13:42:10 EST 2006 =A0 =A0 root@A1234.com:/mnt2/src/sys/compile/ =A0i386 >>> H101494# ipf -Fa >>> H101494# ipfstat -nio >>> empty list for ipfilter(out) >>> empty list for ipfilter(in) >>> H101494# ifconfig rl0 >>> rl0: flags=3D8843 =A0mtu 1500 >>> =A0 =A0 =A0 =A0inet 10.254.151.1 netmask 0xffffff00 broadcast 10.254.15= 1.255 >>> =A0 =A0 =A0 =A0inet 10.255.3.30 netmask 0xffffffff broadcast 10.255.3.3= 0 >>> =A0 =A0 =A0 =A0inet 10.255.4.30 netmask 0xffffffff broadcast 10.255.4.3= 0 >>> =A0 =A0 =A0 =A0inet 169.254.202.1 netmask 0xffff0000 broadcast 169.254.= 255.255 >>> =A0 =A0 =A0 =A0ether 00:30:18:a3:49:b5 >>> =A0 =A0 =A0 =A0media: Ethernet autoselect (none) >>> =A0 =A0 =A0 =A0status: no carrier >>> H101494# ping 169.254.202.1 >>> PING 169.254.202.1 (169.254.202.1): 56 data bytes >>> 64 bytes from 169.254.202.1: icmp_seq=3D0 ttl=3D64 time=3D0.052 ms >>> 64 bytes from 169.254.202.1: icmp_seq=3D1 ttl=3D64 time=3D0.080 ms >>> 64 bytes from 169.254.202.1: icmp_seq=3D2 ttl=3D64 time=3D0.081 ms >>> ^C >>> --- 169.254.202.1 ping statistics --- >>> 3 packets transmitted, 3 packets received, 0% packet loss >>> round-trip min/avg/max/stddev =3D 0.052/0.071/0.081/0.013 ms >>> >>> >> >> >> That was a feature added to sys/netinet/in.c and ip_input.c back in 2007 >> to obey RFC 3927 not to output datagrams destined for 169.254.0.0/16. >> >> On a system that needed to be able to send datagrams to 169.254.0.0/16 >> addresses, I wrote this patch to add a sysctl knob net.inet.fwd_link_loc= al >> to dynamically allow a system to send those datagrams: >> >> >> Index: in.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> RCS file: /home/ncvs/src/sys/netinet/in.c,v >> retrieving revision 1.102.2.4.2.1 >> diff -u -r1.102.2.4.2.1 in.c >> --- in.c =A0 =A0 =A0 =A015 Apr 2009 03:14:26 -0000 =A0 =A0 =A01.102.2.4.= 2.1 >> +++ in.c =A0 =A0 =A0 =A029 Jul 2009 15:10:42 -0000 >> @@ -67,6 +67,9 @@ >> =A0 =A0 =A0 =A0 =A0 =A0struct in_ifaddr *, struct sockaddr_in *, int); >> =A0static void =A0 in_purgemaddrs(struct ifnet *); >> >> +int ip_fwdlinklocal =3D 0; >> +SYSCTL_INT(_net_inet_ip, OID_AUTO, fwd_link_local, CTLFLAG_RW, >> + =A0 =A0 =A0 &ip_fwdlinklocal, 0, "Forward link-local addresses"); >> =A0static int subnetsarelocal =3D 0; >> =A0SYSCTL_INT(_net_inet_ip, OID_AUTO, subnets_are_local, CTLFLAG_RW, >> =A0 =A0 =A0 =A0&subnetsarelocal, 0, "Treat all subnets as directly conne= cted"); >> @@ -129,7 +132,8 @@ >> =A0 =A0 =A0 =A0register u_long i =3D ntohl(in.s_addr); >> =A0 =A0 =A0 =A0register u_long net; >> >> - =A0 =A0 =A0 if (IN_EXPERIMENTAL(i) || IN_MULTICAST(i) || IN_LINKLOCAL(= i)) >> + =A0 =A0 =A0 if (IN_EXPERIMENTAL(i) || IN_MULTICAST(i) || >> + =A0 =A0 =A0 =A0 =A0 (!ip_fwdlinklocal&& =A0IN_LINKLOCAL(i))) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); >> =A0 =A0 =A0 =A0if (IN_CLASSA(i)) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0net =3D i& =A0IN_CLASSA_NET; >> Index: ip_input.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v >> retrieving revision 1.332.2.5.2.1 >> diff -u -r1.332.2.5.2.1 ip_input.c >> --- ip_input.c =A015 Apr 2009 03:14:26 -0000 =A0 =A0 =A01.332.2.5.2.1 >> +++ ip_input.c =A029 Jul 2009 15:10:44 -0000 >> @@ -134,6 +134,7 @@ >> =A0static struct ifqueue ipintrq; >> =A0static int =A0 =A0ipqmaxlen =3D IFQ_MAXLEN; >> >> +extern int ip_fwdlinklocal; >> =A0extern =A0 =A0 =A0 =A0struct domain inetdomain; >> =A0extern =A0 =A0 =A0 =A0struct protosw inetsw[]; >> =A0u_char =A0 =A0 =A0 =A0ip_protox[IPPROTO_MAX]; >> @@ -532,7 +533,7 @@ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> =A0 =A0 =A0 =A0} >> =A0 =A0 =A0 =A0/* RFC 3927 2.7: Do not forward datagrams for 169.254.0.0= /16. */ >> - =A0 =A0 =A0 if (IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) { >> + =A0 =A0 =A0 if (!ip_fwdlinklocal&& =A0IN_LINKLOCAL(ntohl(ip->ip_dst.s_= addr))) { >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ipstat.ips_cantforward++; >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m_freem(m); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return; >> >> > > Hmmm... how is not responding to pings associated with forwarding? Depends on where the box is located that you're pinging from and to (network topology). It looks like that section of code (and ones following it in the same function) just drops the packet on the floor if people attempt to route packets to/from 169.254.x.x. Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 18:41:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36F44106564A for ; Tue, 8 Jun 2010 18:41:10 +0000 (UTC) (envelope-from ghelmer@palisadesystems.com) Received: from smtp-saas1.palisadesystems.com (smtp-saas1.palisadesystems.com [216.81.161.161]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0918FC15 for ; Tue, 8 Jun 2010 18:41:08 +0000 (UTC) Received: from [172.16.2.94] (localhost.palisadesystems.com [127.0.0.1]) by smtp-saas1.palisadesystems.com (8.14.3/8.14.3) with ESMTP id o58IesQj050537; Tue, 8 Jun 2010 13:40:54 -0500 (CDT) (envelope-from ghelmer@palisadesystems.com) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Guy Helmer In-Reply-To: <4C0E8C59.5010202@earthlink.net> Date: Tue, 8 Jun 2010 13:40:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8C598A97-0F1E-44A1-BAFE-48927C143553@palisadesystems.com> References: <4C0E81D7.8020209@earthlink.net> <4C0E8C59.5010202@earthlink.net> To: sclark46@earthlink.net X-Mailer: Apple Mail (2.1078) X-PacketSure-Scanned: Yes Cc: bms@freebsd.org, FreeBSD Stable Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 18:41:10 -0000 On Jun 8, 2010, at 1:30 PM, Stephen Clark wrote: > On 06/08/2010 02:21 PM, Guy Helmer wrote: >> On Jun 8, 2010, at 12:45 PM, Stephen Clark wrote: >>=20 >>> Hi, >>>=20 >>> Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when >>> 4.9 didn't? >>>=20 >>> ***** 6.3 ***** >>> $ sudo ipfstat -nio >>> empty list for ipfilter(out) >>> empty list for ipfilter(in) >>> Z2984:~ >>> $ ifconfig rl0 >>> rl0: flags=3D8843 mtu 1500 >>> options=3D8 >>> inet 192.168.129.1 netmask 0xffffff00 broadcast = 192.168.129.255 >>> inet 169.254.1.1 netmask 0xffff0000 broadcast 169.254.255.255 >>> ether 00:30:18:ae:7c:77 >>> media: Ethernet autoselect (100baseTX) >>> status: active >>> Z2984:~ >>> $ ping 169.254.1.1 >>> PING 169.254.1.1 (169.254.1.1): 56 data bytes >>> ^C >>> --- 169.254.1.1 ping statistics --- >>> 4 packets transmitted, 0 packets received, 100% packet loss >>> Z2984:~ >>> $ uname -a >>> FreeBSD Z2984.netwolves.com 6.3-RELEASE-p15 FreeBSD 6.3-RELEASE-p15 = #17: Fri Apr 16 12:51:57 EST 2010 >>>=20 >>> **** 4.9 ***** >>> FreeBSD H101494.com 4.9-STABLE FreeBSD 4.9-STABLE #59: Thu Mar 30 = 13:42:10 EST 2006 root@A1234.com:/mnt2/src/sys/compile/ i386 >>> H101494# ipf -Fa >>> H101494# ipfstat -nio >>> empty list for ipfilter(out) >>> empty list for ipfilter(in) >>> H101494# ifconfig rl0 >>> rl0: flags=3D8843 mtu 1500 >>> inet 10.254.151.1 netmask 0xffffff00 broadcast 10.254.151.255 >>> inet 10.255.3.30 netmask 0xffffffff broadcast 10.255.3.30 >>> inet 10.255.4.30 netmask 0xffffffff broadcast 10.255.4.30 >>> inet 169.254.202.1 netmask 0xffff0000 broadcast = 169.254.255.255 >>> ether 00:30:18:a3:49:b5 >>> media: Ethernet autoselect (none) >>> status: no carrier >>> H101494# ping 169.254.202.1 >>> PING 169.254.202.1 (169.254.202.1): 56 data bytes >>> 64 bytes from 169.254.202.1: icmp_seq=3D0 ttl=3D64 time=3D0.052 ms >>> 64 bytes from 169.254.202.1: icmp_seq=3D1 ttl=3D64 time=3D0.080 ms >>> 64 bytes from 169.254.202.1: icmp_seq=3D2 ttl=3D64 time=3D0.081 ms >>> ^C >>> --- 169.254.202.1 ping statistics --- >>> 3 packets transmitted, 3 packets received, 0% packet loss >>> round-trip min/avg/max/stddev =3D 0.052/0.071/0.081/0.013 ms >>>=20 >>>=20 >>=20 >>=20 >> That was a feature added to sys/netinet/in.c and ip_input.c back in = 2007 to obey RFC 3927 not to output datagrams destined for = 169.254.0.0/16. >>=20 >> On a system that needed to be able to send datagrams to = 169.254.0.0/16 addresses, I wrote this patch to add a sysctl knob = net.inet.fwd_link_local to dynamically allow a system to send those = datagrams: >>=20 >>=20 >> Index: in.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> RCS file: /home/ncvs/src/sys/netinet/in.c,v >> retrieving revision 1.102.2.4.2.1 >> diff -u -r1.102.2.4.2.1 in.c >> --- in.c 15 Apr 2009 03:14:26 -0000 1.102.2.4.2.1 >> +++ in.c 29 Jul 2009 15:10:42 -0000 >> @@ -67,6 +67,9 @@ >> struct in_ifaddr *, struct sockaddr_in *, int); >> static void in_purgemaddrs(struct ifnet *); >>=20 >> +int ip_fwdlinklocal =3D 0; >> +SYSCTL_INT(_net_inet_ip, OID_AUTO, fwd_link_local, CTLFLAG_RW, >> + &ip_fwdlinklocal, 0, "Forward link-local addresses"); >> static int subnetsarelocal =3D 0; >> SYSCTL_INT(_net_inet_ip, OID_AUTO, subnets_are_local, CTLFLAG_RW, >> &subnetsarelocal, 0, "Treat all subnets as directly connected"); >> @@ -129,7 +132,8 @@ >> register u_long i =3D ntohl(in.s_addr); >> register u_long net; >>=20 >> - if (IN_EXPERIMENTAL(i) || IN_MULTICAST(i) || IN_LINKLOCAL(i)) >> + if (IN_EXPERIMENTAL(i) || IN_MULTICAST(i) || >> + (!ip_fwdlinklocal&& IN_LINKLOCAL(i))) >> return (0); >> if (IN_CLASSA(i)) { >> net =3D i& IN_CLASSA_NET; >> Index: ip_input.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v >> retrieving revision 1.332.2.5.2.1 >> diff -u -r1.332.2.5.2.1 ip_input.c >> --- ip_input.c 15 Apr 2009 03:14:26 -0000 1.332.2.5.2.1 >> +++ ip_input.c 29 Jul 2009 15:10:44 -0000 >> @@ -134,6 +134,7 @@ >> static struct ifqueue ipintrq; >> static int ipqmaxlen =3D IFQ_MAXLEN; >>=20 >> +extern int ip_fwdlinklocal; >> extern struct domain inetdomain; >> extern struct protosw inetsw[]; >> u_char ip_protox[IPPROTO_MAX]; >> @@ -532,7 +533,7 @@ >> } >> } >> /* RFC 3927 2.7: Do not forward datagrams for 169.254.0.0/16. */ >> - if (IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) { >> + if (!ip_fwdlinklocal&& IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) = { >> ipstat.ips_cantforward++; >> m_freem(m); >> return; >>=20 >>=20 > Hmmm... how is not responding to pings associated with forwarding? >=20 My previous understanding was that RFC 3927 did not allow transmitting = datagrams involving the 169.254.0.0/16 link-local prefix; now that I've = looked over the RFC more closely, I'm not sure that is the case. I have cc'ed Bruce Simpson on this message in hopes that he can shed = some light on this. I believe he committed the change that disallowed = transmitting from 169.254.0.0/16 addresses. Guy From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 18:44:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0080E1065678 for ; Tue, 8 Jun 2010 18:44:31 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id DB2328FC18 for ; Tue, 8 Jun 2010 18:44:30 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta13.emeryville.ca.mail.comcast.net with comcast id TRB61e0051bwxycADWkW5r; Tue, 08 Jun 2010 18:44:30 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta18.emeryville.ca.mail.comcast.net with comcast id TWkV1e0093S48mS8eWkVbr; Tue, 08 Jun 2010 18:44:29 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 29AAB9B418; Tue, 8 Jun 2010 11:44:29 -0700 (PDT) Date: Tue, 8 Jun 2010 11:44:29 -0700 From: Jeremy Chadwick To: Stephen Clark Message-ID: <20100608184429.GA12052@icarus.home.lan> References: <4C0E81D7.8020209@earthlink.net> <20100608180506.GA9340@icarus.home.lan> <4C0E8B42.70603@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C0E8B42.70603@earthlink.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Stable Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 18:44:31 -0000 On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote: > On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: > >On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: > >>Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when > >>4.9 didn't? > > > >The following output would help: > > > >- ifconfig -a > >- netstat -rn > >- Contents of /etc/rc.conf > > > >Also, be aware that RELENG_6 is to be EOL'd at the end of this year: > >http://security.freebsd.org/ > > > Hi Jeremy, > > I am not sure that information is relevant. We have two systems configured > identically one using 4.9 the other 6.3. My concern was that someone had botched something up in rc.conf or during the OS upgrade/migration, resulting in there being no loopback interface. I also wanted to verify that your routing table looked correct for what ifconfig showed. Other users pointed you to RFC 3927. Wikipedia has this to say: http://en.wikipedia.org/wiki/Link-local_address "Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses. However, the first and last /24 subnet (256 addresses each) in this block have been excluded from use and are reserved by the standard.[1]" I read this to mean 169.254.0.0/24 and 169.254.255.0/24. Your previous ifconfig statement shows: > $ ifconfig rl0 > rl0: flags=8843 mtu 1500 > options=8 > inet 192.168.129.1 netmask 0xffffff00 broadcast 192.168.129.255 > inet 169.254.1.1 netmask 0xffff0000 broadcast 169.254.255.255 > ether 00:30:18:ae:7c:77 > media: Ethernet autoselect (100baseTX ) > status: active With this configuration, you're using both the first and last /24 netblocks -- 169.254.0.0 for your network address, and 169.254.255.255 for your broadcast address. You should be able to avoid this by using 169.254.1.0/24. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 18:45:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ED6D106566B for ; Tue, 8 Jun 2010 18:45:28 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by mx1.freebsd.org (Postfix) with ESMTP id 0F2F78FC16 for ; Tue, 8 Jun 2010 18:45:27 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ndrx/5ePrCGPJV3gcUEJedZqPCSLpQFVviQVCiU5QMkseRWEeutl5nQNDMZdYiQq; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OM3ni-0001xa-JO; Tue, 08 Jun 2010 14:45:26 -0400 Message-ID: <4C0E8FC4.7070009@earthlink.net> Date: Tue, 08 Jun 2010 14:45:24 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Garrett Cooper References: <4C0E81D7.8020209@earthlink.net> <4C0E8C59.5010202@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec7956b157d5929fa9add300e76972c4c21b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Cc: Guy Helmer , FreeBSD Stable Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 18:45:28 -0000 On 06/08/2010 02:40 PM, Garrett Cooper wrote: > On Tue, Jun 8, 2010 at 11:30 AM, Stephen Clark wrote: >> On 06/08/2010 02:21 PM, Guy Helmer wrote: >>> >>> On Jun 8, 2010, at 12:45 PM, Stephen Clark wrote: >>> >>>> Hi, >>>> >>>> Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when >>>> 4.9 didn't? >>>> >>>> ***** 6.3 ***** >>>> $ sudo ipfstat -nio >>>> empty list for ipfilter(out) >>>> empty list for ipfilter(in) >>>> Z2984:~ >>>> $ ifconfig rl0 >>>> rl0: flags=8843 mtu 1500 >>>> options=8 >>>> inet 192.168.129.1 netmask 0xffffff00 broadcast 192.168.129.255 >>>> inet 169.254.1.1 netmask 0xffff0000 broadcast 169.254.255.255 >>>> ether 00:30:18:ae:7c:77 >>>> media: Ethernet autoselect (100baseTX) >>>> status: active >>>> Z2984:~ >>>> $ ping 169.254.1.1 >>>> PING 169.254.1.1 (169.254.1.1): 56 data bytes >>>> ^C >>>> --- 169.254.1.1 ping statistics --- >>>> 4 packets transmitted, 0 packets received, 100% packet loss >>>> Z2984:~ >>>> $ uname -a >>>> FreeBSD Z2984.netwolves.com 6.3-RELEASE-p15 FreeBSD 6.3-RELEASE-p15 #17: >>>> Fri Apr 16 12:51:57 EST 2010 >>>> >>>> **** 4.9 ***** >>>> FreeBSD H101494.com 4.9-STABLE FreeBSD 4.9-STABLE #59: Thu Mar 30 >>>> 13:42:10 EST 2006 root@A1234.com:/mnt2/src/sys/compile/ i386 >>>> H101494# ipf -Fa >>>> H101494# ipfstat -nio >>>> empty list for ipfilter(out) >>>> empty list for ipfilter(in) >>>> H101494# ifconfig rl0 >>>> rl0: flags=8843 mtu 1500 >>>> inet 10.254.151.1 netmask 0xffffff00 broadcast 10.254.151.255 >>>> inet 10.255.3.30 netmask 0xffffffff broadcast 10.255.3.30 >>>> inet 10.255.4.30 netmask 0xffffffff broadcast 10.255.4.30 >>>> inet 169.254.202.1 netmask 0xffff0000 broadcast 169.254.255.255 >>>> ether 00:30:18:a3:49:b5 >>>> media: Ethernet autoselect (none) >>>> status: no carrier >>>> H101494# ping 169.254.202.1 >>>> PING 169.254.202.1 (169.254.202.1): 56 data bytes >>>> 64 bytes from 169.254.202.1: icmp_seq=0 ttl=64 time=0.052 ms >>>> 64 bytes from 169.254.202.1: icmp_seq=1 ttl=64 time=0.080 ms >>>> 64 bytes from 169.254.202.1: icmp_seq=2 ttl=64 time=0.081 ms >>>> ^C >>>> --- 169.254.202.1 ping statistics --- >>>> 3 packets transmitted, 3 packets received, 0% packet loss >>>> round-trip min/avg/max/stddev = 0.052/0.071/0.081/0.013 ms >>>> >>>> >>> >>> >>> That was a feature added to sys/netinet/in.c and ip_input.c back in 2007 >>> to obey RFC 3927 not to output datagrams destined for 169.254.0.0/16. >>> >>> On a system that needed to be able to send datagrams to 169.254.0.0/16 >>> addresses, I wrote this patch to add a sysctl knob net.inet.fwd_link_local >>> to dynamically allow a system to send those datagrams: >>> >>> >>> Index: in.c >>> =================================================================== >>> RCS file: /home/ncvs/src/sys/netinet/in.c,v >>> retrieving revision 1.102.2.4.2.1 >>> diff -u -r1.102.2.4.2.1 in.c >>> --- in.c 15 Apr 2009 03:14:26 -0000 1.102.2.4.2.1 >>> +++ in.c 29 Jul 2009 15:10:42 -0000 >>> @@ -67,6 +67,9 @@ >>> struct in_ifaddr *, struct sockaddr_in *, int); >>> static void in_purgemaddrs(struct ifnet *); >>> >>> +int ip_fwdlinklocal = 0; >>> +SYSCTL_INT(_net_inet_ip, OID_AUTO, fwd_link_local, CTLFLAG_RW, >>> +&ip_fwdlinklocal, 0, "Forward link-local addresses"); >>> static int subnetsarelocal = 0; >>> SYSCTL_INT(_net_inet_ip, OID_AUTO, subnets_are_local, CTLFLAG_RW, >>> &subnetsarelocal, 0, "Treat all subnets as directly connected"); >>> @@ -129,7 +132,8 @@ >>> register u_long i = ntohl(in.s_addr); >>> register u_long net; >>> >>> - if (IN_EXPERIMENTAL(i) || IN_MULTICAST(i) || IN_LINKLOCAL(i)) >>> + if (IN_EXPERIMENTAL(i) || IN_MULTICAST(i) || >>> + (!ip_fwdlinklocal&& IN_LINKLOCAL(i))) >>> return (0); >>> if (IN_CLASSA(i)) { >>> net = i& IN_CLASSA_NET; >>> Index: ip_input.c >>> =================================================================== >>> RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v >>> retrieving revision 1.332.2.5.2.1 >>> diff -u -r1.332.2.5.2.1 ip_input.c >>> --- ip_input.c 15 Apr 2009 03:14:26 -0000 1.332.2.5.2.1 >>> +++ ip_input.c 29 Jul 2009 15:10:44 -0000 >>> @@ -134,6 +134,7 @@ >>> static struct ifqueue ipintrq; >>> static int ipqmaxlen = IFQ_MAXLEN; >>> >>> +extern int ip_fwdlinklocal; >>> extern struct domain inetdomain; >>> extern struct protosw inetsw[]; >>> u_char ip_protox[IPPROTO_MAX]; >>> @@ -532,7 +533,7 @@ >>> } >>> } >>> /* RFC 3927 2.7: Do not forward datagrams for 169.254.0.0/16. */ >>> - if (IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) { >>> + if (!ip_fwdlinklocal&& IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) { >>> ipstat.ips_cantforward++; >>> m_freem(m); >>> return; >>> >>> >> >> Hmmm... how is not responding to pings associated with forwarding? > > Depends on where the box is located that you're pinging from and > to (network topology). It looks like that section of code (and ones > following it in the same function) just drops the packet on the floor > if people attempt to route packets to/from 169.254.x.x. > Thanks, > -Garrett > _______________________________________________ > 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" > Thanks to all that replied. I now have a better understanding of what is happening. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 18:47:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C5671065679 for ; Tue, 8 Jun 2010 18:47:29 +0000 (UTC) (envelope-from ghelmer@palisadesystems.com) Received: from smtp-saas1.palisadesystems.com (smtp-saas1.palisadesystems.com [216.81.161.161]) by mx1.freebsd.org (Postfix) with ESMTP id 6D4088FC25 for ; Tue, 8 Jun 2010 18:47:27 +0000 (UTC) Received: from [172.16.2.94] (localhost.palisadesystems.com [127.0.0.1]) by smtp-saas1.palisadesystems.com (8.14.3/8.14.3) with ESMTP id o58ILBKg049930; Tue, 8 Jun 2010 13:21:12 -0500 (CDT) (envelope-from ghelmer@palisadesystems.com) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Guy Helmer In-Reply-To: <4C0E81D7.8020209@earthlink.net> Date: Tue, 8 Jun 2010 13:21:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C0E81D7.8020209@earthlink.net> To: sclark46@earthlink.net X-Mailer: Apple Mail (2.1078) X-PacketSure-Scanned: Yes Cc: FreeBSD Stable Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 18:47:29 -0000 On Jun 8, 2010, at 12:45 PM, Stephen Clark wrote: > Hi, >=20 > Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when > 4.9 didn't? >=20 > ***** 6.3 ***** > $ sudo ipfstat -nio > empty list for ipfilter(out) > empty list for ipfilter(in) > Z2984:~ > $ ifconfig rl0 > rl0: flags=3D8843 mtu 1500 > options=3D8 > inet 192.168.129.1 netmask 0xffffff00 broadcast 192.168.129.255 > inet 169.254.1.1 netmask 0xffff0000 broadcast 169.254.255.255 > ether 00:30:18:ae:7c:77 > media: Ethernet autoselect (100baseTX ) > status: active > Z2984:~ > $ ping 169.254.1.1 > PING 169.254.1.1 (169.254.1.1): 56 data bytes > ^C > --- 169.254.1.1 ping statistics --- > 4 packets transmitted, 0 packets received, 100% packet loss > Z2984:~ > $ uname -a > FreeBSD Z2984.netwolves.com 6.3-RELEASE-p15 FreeBSD 6.3-RELEASE-p15 = #17: Fri Apr 16 12:51:57 EST 2010 >=20 > **** 4.9 ***** > FreeBSD H101494.com 4.9-STABLE FreeBSD 4.9-STABLE #59: Thu Mar 30 = 13:42:10 EST 2006 root@A1234.com:/mnt2/src/sys/compile/ i386 > H101494# ipf -Fa > H101494# ipfstat -nio > empty list for ipfilter(out) > empty list for ipfilter(in) > H101494# ifconfig rl0 > rl0: flags=3D8843 mtu 1500 > inet 10.254.151.1 netmask 0xffffff00 broadcast 10.254.151.255 > inet 10.255.3.30 netmask 0xffffffff broadcast 10.255.3.30 > inet 10.255.4.30 netmask 0xffffffff broadcast 10.255.4.30 > inet 169.254.202.1 netmask 0xffff0000 broadcast 169.254.255.255 > ether 00:30:18:a3:49:b5 > media: Ethernet autoselect (none) > status: no carrier > H101494# ping 169.254.202.1 > PING 169.254.202.1 (169.254.202.1): 56 data bytes > 64 bytes from 169.254.202.1: icmp_seq=3D0 ttl=3D64 time=3D0.052 ms > 64 bytes from 169.254.202.1: icmp_seq=3D1 ttl=3D64 time=3D0.080 ms > 64 bytes from 169.254.202.1: icmp_seq=3D2 ttl=3D64 time=3D0.081 ms > ^C > --- 169.254.202.1 ping statistics --- > 3 packets transmitted, 3 packets received, 0% packet loss > round-trip min/avg/max/stddev =3D 0.052/0.071/0.081/0.013 ms >=20 >=20 That was a feature added to sys/netinet/in.c and ip_input.c back in 2007 = to obey RFC 3927 not to output datagrams destined for 169.254.0.0/16. On a system that needed to be able to send datagrams to 169.254.0.0/16 = addresses, I wrote this patch to add a sysctl knob = net.inet.fwd_link_local to dynamically allow a system to send those = datagrams:=20 Index: in.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/in.c,v retrieving revision 1.102.2.4.2.1 diff -u -r1.102.2.4.2.1 in.c --- in.c 15 Apr 2009 03:14:26 -0000 1.102.2.4.2.1 +++ in.c 29 Jul 2009 15:10:42 -0000 @@ -67,6 +67,9 @@ struct in_ifaddr *, struct sockaddr_in *, int); static void in_purgemaddrs(struct ifnet *); =20 +int ip_fwdlinklocal =3D 0; +SYSCTL_INT(_net_inet_ip, OID_AUTO, fwd_link_local, CTLFLAG_RW, + &ip_fwdlinklocal, 0, "Forward link-local addresses"); static int subnetsarelocal =3D 0; SYSCTL_INT(_net_inet_ip, OID_AUTO, subnets_are_local, CTLFLAG_RW, &subnetsarelocal, 0, "Treat all subnets as directly connected"); @@ -129,7 +132,8 @@ register u_long i =3D ntohl(in.s_addr); register u_long net; =20 - if (IN_EXPERIMENTAL(i) || IN_MULTICAST(i) || IN_LINKLOCAL(i)) + if (IN_EXPERIMENTAL(i) || IN_MULTICAST(i) || + (!ip_fwdlinklocal && IN_LINKLOCAL(i))) return (0); if (IN_CLASSA(i)) { net =3D i & IN_CLASSA_NET; Index: ip_input.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.332.2.5.2.1 diff -u -r1.332.2.5.2.1 ip_input.c --- ip_input.c 15 Apr 2009 03:14:26 -0000 1.332.2.5.2.1 +++ ip_input.c 29 Jul 2009 15:10:44 -0000 @@ -134,6 +134,7 @@ static struct ifqueue ipintrq; static int ipqmaxlen =3D IFQ_MAXLEN; =20 +extern int ip_fwdlinklocal; extern struct domain inetdomain; extern struct protosw inetsw[]; u_char ip_protox[IPPROTO_MAX]; @@ -532,7 +533,7 @@ } } /* RFC 3927 2.7: Do not forward datagrams for 169.254.0.0/16. */ - if (IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) { + if (!ip_fwdlinklocal && IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) = { ipstat.ips_cantforward++; m_freem(m); return; From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 18:49:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80BE6106564A for ; Tue, 8 Jun 2010 18:49:23 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id 3C02A8FC16 for ; Tue, 8 Jun 2010 18:49:23 +0000 (UTC) Received: from cesium.hyperfine.info (c2.8d.5646.static.theplanet.com [70.86.141.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hedwig.simons-rock.edu (Postfix) with ESMTP id F2F422BB34D; Tue, 8 Jun 2010 14:49:21 -0400 (EDT) Date: Tue, 8 Jun 2010 14:49:20 -0400 From: "Peter C. Lai" To: Jeremy Chadwick Message-ID: <20100608184919.GY63749@cesium.hyperfine.info> References: <4C0E81D7.8020209@earthlink.net> <20100608180506.GA9340@icarus.home.lan> <4C0E8B42.70603@earthlink.net> <20100608184429.GA12052@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100608184429.GA12052@icarus.home.lan> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Stephen Clark , FreeBSD Stable Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 18:49:23 -0000 On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote: > On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote: > > On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: > > >On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: > > >>Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when > > >>4.9 didn't? > > > > > >The following output would help: > > > > > >- ifconfig -a > > >- netstat -rn > > >- Contents of /etc/rc.conf > > > > > >Also, be aware that RELENG_6 is to be EOL'd at the end of this year: > > >http://security.freebsd.org/ > > > > > Hi Jeremy, > > > > I am not sure that information is relevant. We have two systems configured > > identically one using 4.9 the other 6.3. > > My concern was that someone had botched something up in rc.conf or > during the OS upgrade/migration, resulting in there being no loopback > interface. I also wanted to verify that your routing table looked > correct for what ifconfig showed. > > Other users pointed you to RFC 3927. Wikipedia has this to say: > > http://en.wikipedia.org/wiki/Link-local_address > > "Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses. > However, the first and last /24 subnet (256 addresses each) in this > block have been excluded from use and are reserved by the standard.[1]" > > I read this to mean 169.254.0.0/24 and 169.254.255.0/24. > > Your previous ifconfig statement shows: > > > $ ifconfig rl0 > > rl0: flags=8843 mtu 1500 > > options=8 > > inet 192.168.129.1 netmask 0xffffff00 broadcast 192.168.129.255 > > inet 169.254.1.1 netmask 0xffff0000 broadcast 169.254.255.255 > > ether 00:30:18:ae:7c:77 > > media: Ethernet autoselect (100baseTX ) > > status: active > > With this configuration, you're using both the first and last /24 > netblocks -- 169.254.0.0 for your network address, and 169.254.255.255 > for your broadcast address. > > You should be able to avoid this by using 169.254.1.0/24. > RFC 3927 also has complicated rules involving when one can or should not use a link-local address on the same interface as a routable IP, so at best your configuration may not be supported anyway. One should not use a link-local address as if it were under RFC 1918 rules, in particular because link-local involves self-assigned addresses and internal conflict mitigation. -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 18:57:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E66891065673 for ; Tue, 8 Jun 2010 18:57:02 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id CA8D28FC15 for ; Tue, 8 Jun 2010 18:57:02 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta15.emeryville.ca.mail.comcast.net with comcast id TUuq1e0021eYJf8AFWx24F; Tue, 08 Jun 2010 18:57:02 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta19.emeryville.ca.mail.comcast.net with comcast id TWx11e0023S48mS01Wx13t; Tue, 08 Jun 2010 18:57:01 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id F3BE19B418; Tue, 8 Jun 2010 11:57:00 -0700 (PDT) Date: Tue, 8 Jun 2010 11:57:00 -0700 From: Jeremy Chadwick To: "Peter C. Lai" Message-ID: <20100608185700.GA12544@icarus.home.lan> References: <4C0E81D7.8020209@earthlink.net> <20100608180506.GA9340@icarus.home.lan> <4C0E8B42.70603@earthlink.net> <20100608184429.GA12052@icarus.home.lan> <20100608184919.GY63749@cesium.hyperfine.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100608184919.GY63749@cesium.hyperfine.info> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Stephen Clark , FreeBSD Stable Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 18:57:03 -0000 On Tue, Jun 08, 2010 at 02:49:20PM -0400, Peter C. Lai wrote: > On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote: > > On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote: > > > On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: > > > >On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: > > > >>Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when > > > >>4.9 didn't? > > > > > > > >The following output would help: > > > > > > > >- ifconfig -a > > > >- netstat -rn > > > >- Contents of /etc/rc.conf > > > > > > > >Also, be aware that RELENG_6 is to be EOL'd at the end of this year: > > > >http://security.freebsd.org/ > > > > > > > Hi Jeremy, > > > > > > I am not sure that information is relevant. We have two systems configured > > > identically one using 4.9 the other 6.3. > > > > My concern was that someone had botched something up in rc.conf or > > during the OS upgrade/migration, resulting in there being no loopback > > interface. I also wanted to verify that your routing table looked > > correct for what ifconfig showed. > > > > Other users pointed you to RFC 3927. Wikipedia has this to say: > > > > http://en.wikipedia.org/wiki/Link-local_address > > > > "Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses. > > However, the first and last /24 subnet (256 addresses each) in this > > block have been excluded from use and are reserved by the standard.[1]" > > > > I read this to mean 169.254.0.0/24 and 169.254.255.0/24. > > > > Your previous ifconfig statement shows: > > > > > $ ifconfig rl0 > > > rl0: flags=8843 mtu 1500 > > > options=8 > > > inet 192.168.129.1 netmask 0xffffff00 broadcast 192.168.129.255 > > > inet 169.254.1.1 netmask 0xffff0000 broadcast 169.254.255.255 > > > ether 00:30:18:ae:7c:77 > > > media: Ethernet autoselect (100baseTX ) > > > status: active > > > > With this configuration, you're using both the first and last /24 > > netblocks -- 169.254.0.0 for your network address, and 169.254.255.255 > > for your broadcast address. > > > > You should be able to avoid this by using 169.254.1.0/24. > > > > RFC 3927 also has complicated rules involving when one can or should not > use a link-local address on the same interface as a routable IP, so at > best your configuration may not be supported anyway. One should not use > a link-local address as if it were under RFC 1918 rules, in particular > because link-local involves self-assigned addresses and internal > conflict mitigation. Thanks for the addendum, Peter. You're absolutely right. Furthermore, I looked at the IN_LINKLOCAL() macro and relevant code: include/netinet/in.h:#define IN_LINKLOCAL(i) (((u_int32_t)(i) & 0xffff0000) == 0xa9fe0000) - if (IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) { + if (!ip_fwdlinklocal && IN_LINKLOCAL(ntohl(ip->ip_dst.s_addr))) { I assume ip->ip_dst.s_addr is the source address of a packet destined somewhere (in the OP's case, this would be 169.254.1.1). If my assumption is correct, then the above macro filters out the last two octets of the source address, leaving only the first two, comparing those to 0xa9 and 0xfe respectively (decimal = 169 and 254). If true, then the if() statement applies, which I assume blackholes it. Based on that, I don't think using a smaller block like 169.254.1.0/24 would work; seems FreeBSD does what it does against the entire /16. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 19:00:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CDD61065676 for ; Tue, 8 Jun 2010 19:00:50 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by mx1.freebsd.org (Postfix) with ESMTP id F176F8FC15 for ; Tue, 8 Jun 2010 19:00:49 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ErhuhQ4Ho15uHhutZCQpi9EdPjYq+Oxyud5CYmtOP+QQcH3KMYhiBr9v3Ig7Gkyx; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OM42a-0003wh-Ds; Tue, 08 Jun 2010 15:00:48 -0400 Message-ID: <4C0E935E.1020409@earthlink.net> Date: Tue, 08 Jun 2010 15:00:46 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Peter C. Lai" References: <4C0E81D7.8020209@earthlink.net> <20100608180506.GA9340@icarus.home.lan> <4C0E8B42.70603@earthlink.net> <20100608184429.GA12052@icarus.home.lan> <20100608184919.GY63749@cesium.hyperfine.info> In-Reply-To: <20100608184919.GY63749@cesium.hyperfine.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec79992e346fe85fd40ad4bbe2bf35b29c82350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Cc: FreeBSD Stable , Jeremy Chadwick Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 19:00:50 -0000 On 06/08/2010 02:49 PM, Peter C. Lai wrote: > On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote: >> On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote: >>> On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: >>>> On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: >>>>> Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when >>>>> 4.9 didn't? >>>> >>>> The following output would help: >>>> >>>> - ifconfig -a >>>> - netstat -rn >>>> - Contents of /etc/rc.conf >>>> >>>> Also, be aware that RELENG_6 is to be EOL'd at the end of this year: >>>> http://security.freebsd.org/ >>>> >>> Hi Jeremy, >>> >>> I am not sure that information is relevant. We have two systems configured >>> identically one using 4.9 the other 6.3. >> >> My concern was that someone had botched something up in rc.conf or >> during the OS upgrade/migration, resulting in there being no loopback >> interface. I also wanted to verify that your routing table looked >> correct for what ifconfig showed. >> >> Other users pointed you to RFC 3927. Wikipedia has this to say: >> >> http://en.wikipedia.org/wiki/Link-local_address >> >> "Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses. >> However, the first and last /24 subnet (256 addresses each) in this >> block have been excluded from use and are reserved by the standard.[1]" >> >> I read this to mean 169.254.0.0/24 and 169.254.255.0/24. >> >> Your previous ifconfig statement shows: >> >>> $ ifconfig rl0 >>> rl0: flags=8843 mtu 1500 >>> options=8 >>> inet 192.168.129.1 netmask 0xffffff00 broadcast 192.168.129.255 >>> inet 169.254.1.1 netmask 0xffff0000 broadcast 169.254.255.255 >>> ether 00:30:18:ae:7c:77 >>> media: Ethernet autoselect (100baseTX) >>> status: active >> >> With this configuration, you're using both the first and last /24 >> netblocks -- 169.254.0.0 for your network address, and 169.254.255.255 >> for your broadcast address. >> >> You should be able to avoid this by using 169.254.1.0/24. >> > > RFC 3927 also has complicated rules involving when one can or should not > use a link-local address on the same interface as a routable IP, so at > best your configuration may not be supported anyway. One should not use > a link-local address as if it were under RFC 1918 rules, in particular > because link-local involves self-assigned addresses and internal > conflict mitigation. > Again what happened we had a box in the field that was running 4.9 being used as a router/nat/vpn/firewall device. It was handing out ip addresses to the internal lan using the range 169.254.202.0/24, who knows why this address range was picked. It worked great but the hardware died, so we were replacing it with our current SW which is based on 6.3 we duplicated the configuration and have been struggling trying to get it to work for the customer since Saturday with no luck. Today I finally tried to ping the internal address from the box itself and it wouldn't ping, so I started trying using other addresses on the internal interface and they worked but not 169.254.202.1. In googling I discovered that 169.254/16 was supposed to be assigned if a box couldn't obtain an ip but saw nothing about an OS dropping them. So anyway I know the reason behind the change now. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 19:28:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15C221065679 for ; Tue, 8 Jun 2010 19:28:39 +0000 (UTC) (envelope-from alteriks@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 918718FC1F for ; Tue, 8 Jun 2010 19:28:38 +0000 (UTC) Received: by fxm20 with SMTP id 20so3940215fxm.13 for ; Tue, 08 Jun 2010 12:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=dYKYRfHLC4TpGh6tfs35nJTlS4yqQeCC6g/By2NQPfA=; b=hHZ4dSaLAxeXQLRdXHrFOfG1ZMRb2IU29aYqtGoXgSSDbT+MoY3S1zLPnAIB4dupoe HzTt6KF9niQ4vtt20RvQ842xfuQD8MfAKz4zq1iu0hMlDd5wZ/2FdZ1smOaQP5yEe0p2 vt23EgPko7wL9E/AeN+BhijsehOseo8TGV2Ss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=KMxC7d0C5byT0MSHr4yQTrpMYbgLELXM606NAdX7qCgpD+2Ke1KkpFbq8Izj47eAmf B301vVIgV8EEgf9JuKiISH+he6DjR3/6rlfLy9rgent9oSB+ZOPskZ/NLX4dOqc8i/st YHaf0pAfMWX9s/se0tsDHr2wyBtEknVp+X8BU= Received: by 10.239.185.20 with SMTP id a20mr1193147hbh.12.1276025317161; Tue, 08 Jun 2010 12:28:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.161.146 with HTTP; Tue, 8 Jun 2010 12:28:17 -0700 (PDT) In-Reply-To: <201006041009.47004.kdajka@new.agora.pl> References: <684e57ec1003221341s241c6d4fl9f2afa411c55d697@mail.gmail.com> <201006041009.47004.kdajka@new.agora.pl> From: Krzysztof Dajka Date: Tue, 8 Jun 2010 21:28:17 +0200 Message-ID: To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Booting after make installworld takes ages [Was Re: Can't boot after make installworld] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 08 Jun 2010 19:28:39 -0000 On Fri, Jun 4, 2010 at 10:09 AM, Krzysztof Dajka wrote: > On Sunday, 21 of March 2010 20:15:29 Krzysztof Dajka wrote: > > Hi, I'm having problem with upgrading my FreeBSD to RELENG_8. Building > > world and kernel went smoothly I can boot with new kernel, but after > 'make > > installworld' I could boot my system. My system prints only: > > BTX loader 1.00 BTX version is 1.01 > > Console: internal video/keyboard > > BIOS drive C: is disk0 > > BIOS drive D: is disk1 > > BIOS drive E: is disk2 > > BIOS drive F: is disk3 > > | > > And freezes... > > > > I had a problem in march with booting after 'makeinstall' as stated above. > It seems that I was impatient prejudged facts. > For few months I was running newer kernel than world. After all I decided > to upgrade whole system yesterday. After 'make > installkernel', booting to new kernel went as usual. After 'make > installworld' and rebooting it hangs at: > > > BIOS drive C: is disk0 > > BIOS drive D: is disk1 > > BIOS drive E: is disk2 > > BIOS drive F: is disk3 > > | > > After waiting 50 seconds it started booting. During this time my usb flash > drive, which contains only bootcode blinked as > crazy. I remembered that Dan Naumov told me > > > The ZFS bootloader has been changed in 8-STABLE compared to > > 8.0-RELEASE. Reinstall your boot blocks. > > So this time I did: > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 > > But this didn't help, booting is still painfully slow. > -- > I have done few test and narrowed problem to probing usb devices. I have taken following steps: 1) I prepared installed bootcode to 3 devices - 512MB Kingston flash drive - 32MB SD Card - 1MB file (created with dd, mounted with mdconfig, added gpt partition and freebsd-boot slice) booted over pxe 2) All devices had newest bootcode, booting from every device was terrible slow, but sd card was significantly slower than others. 3) I played with my zpool # zpool offline zroot gpt/disk2 4) reboot 5) I booted with every device. Booting from both devices connected to usb bus, was slow. Booting over pxe from 1MB 'drive' with bootcode was very fast as it should be. 6) Booting over pxe with any device attached to usb bus was again slow! 7) I did: #zpool online zroot gpt/disk2 And rebooted over pxe. Still fast. I noticed that /boot/zfs/zpool.cache was updated after puting offline gpt/disk2, but I can't remember if it was updated after upgrading kernel and world. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 20:42:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D15691065675 for ; Tue, 8 Jun 2010 20:42:21 +0000 (UTC) (envelope-from baptiste.daroussin@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 AA8CC8FC19 for ; Tue, 8 Jun 2010 20:42:21 +0000 (UTC) Received: by pwj1 with SMTP id 1so2872786pwj.13 for ; Tue, 08 Jun 2010 13:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=D464GmslgYZfaxj0eb4xFJ3mr2Y2xpRcQTDtP5ouVgo=; b=SkdYP/y45qFBY+YE5lADgwIvHo6JkvCrJ1vX2k1cO5fagJF3wwpTMh6EVX0ma5++LR IELSPh1KePihwiT0rnzdXV62XX0jXml6pCC0PBfvoM22Nr+6i+1geRFmduqA9gURrlw6 Xf4sKsvD7mONYfd1iFHCz+rFLhV88WL6xPtl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=gdZfDBOgS8boW0/UnrSlSpPQf2B2ut3xYd79Cx/Nyiy8p9o6R1uj39qzvQxh5Vb45F IQOZi/lBVxDJsdb7Eui4KzwT7RoxtJS3AKP/PNVwUb62bmW3qBgzdHxZjnmUVgCpyLo4 zV2CLlUK1JshOYvxWSK3r3iEaU+f/2xfHVQ+g= MIME-Version: 1.0 Received: by 10.141.124.15 with SMTP id b15mr13598102rvn.107.1276028091427; Tue, 08 Jun 2010 13:14:51 -0700 (PDT) Received: by 10.140.208.16 with HTTP; Tue, 8 Jun 2010 13:14:51 -0700 (PDT) Date: Tue, 8 Jun 2010 20:14:51 +0000 Message-ID: From: Baptiste Daroussin To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: shouldn't libarchive be MFCed before 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: Tue, 08 Jun 2010 20:42:21 -0000 Hi all, I'm working on suport xz compressed packages for pkg_install, and libarchive on current supports natively xz compression but seems not having been MFCed (it should have beed two weeks after the 10th of may according to the commit message) I still have 2.7.0 on stable (from yesterday) I send this mail just to know if libarchive will be mfced on not before the release. regards, Bapt From owner-freebsd-stable@FreeBSD.ORG Tue Jun 8 20:48:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01656106564A for ; Tue, 8 Jun 2010 20:48:23 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id A4DF88FC14 for ; Tue, 8 Jun 2010 20:48:22 +0000 (UTC) Received: by gyh20 with SMTP id 20so4698967gyh.13 for ; Tue, 08 Jun 2010 13:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=pZATYCeCmIYPT5owG4fEBAWooU5XFFSuqwvNoVhgwn8=; b=t0vSYkNm/+z0OMKqWKczQDEFv8txqtPosOq/foE77eROjea37nU8/Y9ltYOdWhplU9 DhlHdqWeC5haanLjAMoJc1bfUAl9WtBJnEzsWrNIlzbeYUGSiah76/B+XG0qhW+UXUrh Ymyrd4bAZYbsscDGqj+jhCCrhmhw6F5d1UIZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MfGwz4oCKUQ69WD3z5+UHQaeSkzaEmmvCkCQkAw05Rfu1HJbj3d/icZV1uQYl9RbHf 28oak9jd3SrnY/rwWsql6NVWO0Uc/rcH5mpRUlMHkTpJf34k/9jVpCccYefNDUgn4UK2 wqfH/6CjwdepL6L9hNvRUaOxrrMA4UIn7YIsc= MIME-Version: 1.0 Received: by 10.224.115.25 with SMTP id g25mr339298qaq.179.1276030101541; Tue, 08 Jun 2010 13:48:21 -0700 (PDT) Received: by 10.229.233.74 with HTTP; Tue, 8 Jun 2010 13:48:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 8 Jun 2010 13:48:21 -0700 Message-ID: From: Garrett Cooper To: Baptiste Daroussin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: shouldn't libarchive be MFCed before 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: Tue, 08 Jun 2010 20:48:23 -0000 On Tue, Jun 8, 2010 at 1:14 PM, Baptiste Daroussin wrote: > Hi all, > > I'm working on suport xz compressed packages for pkg_install, and > libarchive on current supports natively xz compression but seems not > having been MFCed (it should have beed two weeks after the 10th of may > according to the commit message) I still have 2.7.0 on stable (from > yesterday) > > I send this mail just to know if libarchive will be mfced on not > before the release. libarchive and liblzma brings a lot of build related consequences into the picture because I'm pretty sure that not all of the dependencies are being articulated properly in lib (I'm running into nasty race conditions monkeying around with Makefile.inc1 and lib/Makefile trying to resolve the race conditions). Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 06:47:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BF75106566B for ; Wed, 9 Jun 2010 06:47:54 +0000 (UTC) (envelope-from lambert@lambertfam.org) Received: from sysmon.tcworks.net (sysmon.tcworks.net [65.66.76.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3B0B38FC1D for ; Wed, 9 Jun 2010 06:47:53 +0000 (UTC) Received: from sysmon.tcworks.net (localhost [127.0.0.1]) by sysmon.tcworks.net (8.13.1/8.13.1) with ESMTP id o596lr8a074842 for ; Wed, 9 Jun 2010 01:47:53 -0500 (CDT) (envelope-from lambert@lambertfam.org) Received: (from lambert@localhost) by sysmon.tcworks.net (8.13.1/8.13.1/Submit) id o596lrPI074841 for freebsd-stable@freebsd.org; Wed, 9 Jun 2010 01:47:53 -0500 (CDT) (envelope-from lambert@lambertfam.org) X-Authentication-Warning: sysmon.tcworks.net: lambert set sender to lambert@lambertfam.org using -f Date: Wed, 9 Jun 2010 01:47:53 -0500 From: Scott Lambert To: freebsd-stable@freebsd.org Message-ID: <20100609064753.GA46148@sysmon.tcworks.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20100606052509.GA4744@mavetju.org> <20100606185551.GA267@sysmon.tcworks.net> <20100606194515.GA29230@icarus.home.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100606194515.GA29230@icarus.home.lan> User-Agent: Mutt/1.4.2.2i Subject: Re: gmirror refused to connect second disk after a reboot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 06:47:54 -0000 On Sun, Jun 06, 2010 at 12:45:15PM -0700, Jeremy Chadwick wrote: > On Sun, Jun 06, 2010 at 01:55:51PM -0500, Scott Lambert wrote: > > I have one dual PIII machine doing the same to me. I've been assuming > > my issue is with the ATA controller. ... > I agree -- these look like you have either a bad PATA cable, an PATA > controller port which has gone bad, or a PATA controller which is > behaving *very* badly (internal IC problems). ICRC errors indicate data > transmission failures between the controller and the disk. > > Since these are classic PATA disks, ad0 is probably the master and ad2 > is the slave -- but both are probably on the same physical cable. > > The LBAs for both ad0 and ad2 are very close (ad0=242235039, > ad2=242234911), which makes sense since they're in a mirror config. But > two disks going kaput at the same time, around the same LBA? I have my > doubts. I think I actually made sure that ad0 and ad2 are on their own cables. ad0 may be sharing with acd0 though. Yeah, looks like it. 01:16:24 Wed Jun 09 $ sudo atacontrol list ATA channel 0: Master: ad0 ATA/ATAPI revision 7 Slave: acd0 ATA/ATAPI revision 0 ATA channel 1: Master: ad2 ATA/ATAPI revision 7 Slave: no device present > SMART statistics for both of the disks themselves would help determine > if the disks are seeing issues or if the disks are also seeing problems > communicating with the PATA controller. (Depends on the age of the disks > though; some older PATA disks don't have the SMART attribute that > describes this). The drives are only a couple of years old. The box itself is ancient. :-) The ICRC error only seem to have occured right after boot. I'll jerk the box apart to check/change the cabling when I get a chance. Maybe I'll just dump the cd drive. > What you should be worried about -- FreeBSD sees problems on both ad0 > and ad2. ad2 is offline cuz of the problem, but ad0 isn't. Chances are > ad0 is going to fall off the bus eventually because of this problem. I > really hope you do backups regularly (daily) if you plan on just > ignoring this problem. AMANDA takes care of things. Also, this box is not terribly important. I rebuilt the array Sunday. I don't see anything terribly scary in the smartctl output. Anyway, I do hope I haven't hijacked the thread for the OP. I actually just wanted to offer a possible matching datapoint. -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 08:48:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09DBA106566B for ; Wed, 9 Jun 2010 08:48:30 +0000 (UTC) (envelope-from prvs=1776ac14af=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 8982A8FC0A for ; Wed, 9 Jun 2010 08:48:29 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 09 Jun 2010 09:38:26 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 09 Jun 2010 09:38:26 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50010469608.msg for ; Wed, 09 Jun 2010 09:38:25 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.48 X-Return-Path: prvs=1776ac14af=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@freebsd.org Message-ID: From: "Steven Hartland" To: "Steven Hartland" , "Karl Denninger" References: <20091208174145.GA14312@mr-happy.com> <20091208175219.GA56219@icarus.home.lan> <4B1EAF01.2030803@icyb.net.ua><20091208195752.GF14312@mr-happy.com> <4B1ECEC0.2070005@quip.cz><4B1EECCD.7020200@denninger.net> Date: Wed, 9 Jun 2010 09:38:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: freebsd-stable@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz>, Jeff Blank Subject: Re: Dell PowerEdge Virtual Media X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jun 2010 08:48:30 -0000 For the record this appears to have been fixed in 8.1-BETA so we can now successfully use the fixit CD mounted from an iso under the IPMI tool on our supermicro machines. It even fixes the issue where previously you had to select device rescan for it to see the usb cdrom after boot :) ----- Original Message ----- From: "Steven Hartland" >> The ipmi implementation is limited to CD-sized media on the Supermicro >> ipKVM implementations. Try the CD boot media ISO. > > If thats the case why can it happily boot from it? The issue only seemed > to occur here when you tried to access it via the fixit menu even though > the console log showed it as being detected just fine. > > I've just retested on the machine now its up and running and see similar > results with both dvd's and cdroms. > > Connect dvd iso: > Dec 9 02:21:27 ipmitest root: Unknown USB device: vendor 0x14dd product 0x0002 bus uhub3 > Dec 9 02:21:27 ipmitest kernel: ugen3.2: at usbus3 > Dec 9 02:21:27 ipmitest kernel: umass0: on usbus3 > Dec 9 02:21:27 ipmitest kernel: umass0: SCSI over Bulk-Only; quirks = 0x0000 > Dec 9 02:21:28 ipmitest kernel: umass0:1:0:-1: Attached to scbus1 > Dec 9 02:21:28 ipmitest kernel: ums0: on usbus3 > Dec 9 02:21:28 ipmitest kernel: ums0: 3 buttons and [Z] coordinates ID=0 > Dec 9 02:21:28 ipmitest kernel: ukbd0: on usbus3 > Dec 9 02:21:28 ipmitest kernel: kbd2 at ukbd0 > Dec 9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > Dec 9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > Dec 9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition > Dec 9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:29,0 > Dec 9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): Power on, reset, or bus device reset occurred > Dec 9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) > Dec 9 02:21:28 ipmitest kernel: cd0 at umass-sim0 bus 0 target 0 lun 0 > Dec 9 02:21:28 ipmitest kernel: cd0: Removable CD-ROM SCSI-3 device > Dec 9 02:21:28 ipmitest kernel: cd0: 40.000MB/s transfers > Dec 9 02:21:28 ipmitest kernel: cd0: cd present [1058105 x 2048 byte records] > > Attempt to mount: > Dec 9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): READ TOC/PMA/ATIP. CDB: 43 0 0 0 0 0 0 0 4 0 > Dec 9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > Dec 9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): SCSI Status: Check Condition > Dec 9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): UNIT ATTENTION asc:29,0 > Dec 9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): Power on, reset, or bus device reset occurred > Dec 9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): Retries Exhausted > Dec 9 02:23:59 ipmitest kernel: g_vfs_done():cd0[READ(offset=32768, length=2048)]error = 5 > > disconnect iso: > Dec 9 02:26:50 ipmitest kernel: ugen3.2: at usbus3 (disconnected) > Dec 9 02:26:50 ipmitest kernel: umass0: at uhub3, port 6, addr 2 (disconnected) > Dec 9 02:26:50 ipmitest kernel: (cd0:umass-sim0:0:0:0): lost device > Dec 9 02:26:50 ipmitest kernel: (cd0:umass-sim0:0:0:0): removing device entry > Dec 9 02:26:50 ipmitest kernel: ums0: at uhub3, port 6, addr 2 (disconnected) > Dec 9 02:26:50 ipmitest kernel: ukbd0: at uhub3, port 6, addr 2 (disconnected) > Dec 9 02:26:51 ipmitest kernel: ugen3.2: at usbus3 > Dec 9 02:26:51 ipmitest kernel: ums0: on usbus3 > Dec 9 02:26:51 ipmitest kernel: ums0: 3 buttons and [Z] coordinates ID=0 > Dec 9 02:26:51 ipmitest kernel: ukbd0: on usbus3 > Dec 9 02:26:51 ipmitest kernel: kbd2 at ukbd0 > Dec 9 02:28:10 ipmitest kernel: ugen3.2: at usbus3 (disconnected) > Dec 9 02:28:10 ipmitest kernel: ums0: at uhub3, port 6, addr 2 (disconnected) > Dec 9 02:28:10 ipmitest kernel: ukbd0: at uhub3, port 6, addr 2 (disconnected) > > connect cdrom iso: > Dec 9 02:28:11 ipmitest root: Unknown USB device: vendor 0x14dd product 0x0002 bus uhub3 > Dec 9 02:28:11 ipmitest kernel: ugen3.2: at usbus3 > Dec 9 02:28:11 ipmitest kernel: umass0: on usbus3 > Dec 9 02:28:11 ipmitest kernel: umass0: SCSI over Bulk-Only; quirks = 0x0000 > Dec 9 02:28:13 ipmitest kernel: umass0:1:0:-1: Attached to scbus1 > Dec 9 02:28:13 ipmitest kernel: ums0: on usbus3 > Dec 9 02:28:13 ipmitest kernel: ums0: 3 buttons and [Z] coordinates ID=0 > Dec 9 02:28:13 ipmitest kernel: ukbd0: on usbus3 > Dec 9 02:28:13 ipmitest kernel: kbd2 at ukbd0 > Dec 9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > Dec 9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > Dec 9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition > Dec 9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:29,0 > Dec 9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): Power on, reset, or bus device reset occurred > Dec 9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) > Dec 9 02:28:13 ipmitest kernel: cd0 at umass-sim0 bus 0 target 0 lun 0 > Dec 9 02:28:13 ipmitest kernel: > Dec 9 02:28:13 ipmitest kernel: cd0: Removable CD-ROM SCSI-3 device > Dec 9 02:28:13 ipmitest kernel: cd0: 40.000MB/s transfers > Dec 9 02:28:13 ipmitest kernel: cd0: cd present [164374 x 2048 byte records] > > try to mount: > Dec 9 02:29:01 ipmitest kernel: (cd0:umass-sim0:0:0:0): READ TOC/PMA/ATIP. CDB: 43 0 0 0 0 0 0 0 4 0 > Dec 9 02:29:01 ipmitest kernel: (cd0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > Dec 9 02:29:01 ipmitest kernel: (cd0:umass-sim0:0:0:0): SCSI Status: Check Condition > Dec 9 02:29:01 ipmitest kernel: (cd0:umass-sim0:0:0:0): UNIT ATTENTION asc:29,0 > Dec 9 02:29:01 ipmitest kernel: (cd0:umass-sim0:0:0:0): Power on, reset, or bus device reset occurred > Dec 9 02:29:01 ipmitest kernel: (cd0:umass-sim0:0:0:0): Retries Exhausted > Dec 9 02:29:02 ipmitest kernel: g_vfs_done():cd0[READ(offset=32768, length=2048)]error = 5 ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 09:33:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A8F1106564A for ; Wed, 9 Jun 2010 09:33:23 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 977E18FC13 for ; Wed, 9 Jun 2010 09:33:22 +0000 (UTC) Received: by fxm20 with SMTP id 20so4291571fxm.13 for ; Wed, 09 Jun 2010 02:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=imddcq8ql1+clnRpl5eW6iOMUADTGhqQocANCVlAePI=; b=iuk5bYDYyLRrbhzHBt0Ds8iT8LHBJjpzCmbZo5IdW0j+OAHNC7tcTGZoTUlNQOzaf6 uCstzP4cd55rQaNbCrJDrxOrxO30PhX/6lb23xIWqMTRSJOGSlXK0YzKls2Wy4xR5HY8 xlKdp447BG8ghN6zzwhhY4Io1d0ZXfcIxhYxQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=jc4L4KAIVzU9IKUUGv8WkGAahV1gwpI8VCM+oXbRHcOw/JvALKFzzepySZ1hh4/exR 1rIMlfyLEtmwydWeAxcNX4eCyLyHX5Rf+bFNv0wEbHx83Im8agTvnDq+fmWgXwUFWz1C IuwG1RhxNM8XzyVB19RC+NMLh9qZP1w66SoTQ= Received: by 10.223.92.153 with SMTP id r25mr1728242fam.76.1276076001483; Wed, 09 Jun 2010 02:33:21 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r12sm2908282fah.20.2010.06.09.02.33.20 (version=SSLv3 cipher=RC4-MD5); Wed, 09 Jun 2010 02:33:21 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C0F5FC9.7080300@FreeBSD.org> Date: Wed, 09 Jun 2010 12:32:57 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Steven Hartland , FreeBSD Stable References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Dell PowerEdge Virtual Media X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jun 2010 09:33:23 -0000 Steven Hartland wrote: > For the record this appears to have been fixed in 8.1-BETA so we can > now successfully use the fixit CD mounted from an iso under the IPMI > tool on our supermicro machines. It even fixes the issue where > previously you had to select device rescan for it to see the usb > cdrom after boot :) It should be SVN rev 203108 of 2010-01-28. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 11:59:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43E29106566B for ; Wed, 9 Jun 2010 11:59:20 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by mx1.freebsd.org (Postfix) with ESMTP id 03C3C8FC0C for ; Wed, 9 Jun 2010 11:59:19 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=tpdr8D0AGAe+C0PRZuveYj1H9oGdTtc6CC/0dea8HlB4726NY1Rn8xr12PhUmm0w; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OMJwE-0005gs-M6; Wed, 09 Jun 2010 07:59:18 -0400 Message-ID: <4C0F8214.3090104@earthlink.net> Date: Wed, 09 Jun 2010 07:59:16 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: sclark46@earthlink.net References: <4C0E81D7.8020209@earthlink.net> <20100608180506.GA9340@icarus.home.lan> <4C0E8B42.70603@earthlink.net> <20100608184429.GA12052@icarus.home.lan> <20100608184919.GY63749@cesium.hyperfine.info> <4C0E935E.1020409@earthlink.net> In-Reply-To: <4C0E935E.1020409@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec79429dfd5150f9d44bb801b15ec16191fd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Cc: "Peter C. Lai" , FreeBSD Stable , Jeremy Chadwick Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 11:59:20 -0000 On 06/08/2010 03:00 PM, Stephen Clark wrote: > On 06/08/2010 02:49 PM, Peter C. Lai wrote: >> On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote: >>> On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote: >>>> On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: >>>>> On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: >>>>>> Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when >>>>>> 4.9 didn't? >>>>> >>>>> The following output would help: >>>>> >>>>> - ifconfig -a >>>>> - netstat -rn >>>>> - Contents of /etc/rc.conf >>>>> >>>>> Also, be aware that RELENG_6 is to be EOL'd at the end of this year: >>>>> http://security.freebsd.org/ >>>>> >>>> Hi Jeremy, >>>> >>>> I am not sure that information is relevant. We have two systems >>>> configured >>>> identically one using 4.9 the other 6.3. >>> >>> My concern was that someone had botched something up in rc.conf or >>> during the OS upgrade/migration, resulting in there being no loopback >>> interface. I also wanted to verify that your routing table looked >>> correct for what ifconfig showed. >>> >>> Other users pointed you to RFC 3927. Wikipedia has this to say: >>> >>> http://en.wikipedia.org/wiki/Link-local_address >>> >>> "Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses. >>> However, the first and last /24 subnet (256 addresses each) in this >>> block have been excluded from use and are reserved by the standard.[1]" >>> >>> I read this to mean 169.254.0.0/24 and 169.254.255.0/24. >>> >>> Your previous ifconfig statement shows: >>> >>>> $ ifconfig rl0 >>>> rl0: flags=8843 mtu 1500 >>>> options=8 >>>> inet 192.168.129.1 netmask 0xffffff00 broadcast 192.168.129.255 >>>> inet 169.254.1.1 netmask 0xffff0000 broadcast 169.254.255.255 >>>> ether 00:30:18:ae:7c:77 >>>> media: Ethernet autoselect (100baseTX) >>>> status: active >>> >>> With this configuration, you're using both the first and last /24 >>> netblocks -- 169.254.0.0 for your network address, and 169.254.255.255 >>> for your broadcast address. >>> >>> You should be able to avoid this by using 169.254.1.0/24. >>> >> >> RFC 3927 also has complicated rules involving when one can or should not >> use a link-local address on the same interface as a routable IP, so at >> best your configuration may not be supported anyway. One should not use >> a link-local address as if it were under RFC 1918 rules, in particular >> because link-local involves self-assigned addresses and internal >> conflict mitigation. >> > Again what happened we had a box in the field that was running 4.9 being > used as a router/nat/vpn/firewall device. It was handing out ip addresses > to the internal lan using the range 169.254.202.0/24, who knows why this > address range was picked. It worked great but > the hardware died, so we were replacing it with our current SW which is > based on 6.3 we duplicated the configuration and have been struggling > trying to > get it to work for the customer since Saturday with no luck. Today I > finally > tried to ping the internal address from the box itself and it wouldn't > ping, > so I started trying using other addresses on the internal interface and > they > worked but not 169.254.202.1. In googling I discovered that 169.254/16 > was supposed to be assigned if a box couldn't obtain an ip but saw > nothing about > an OS dropping them. > > So anyway I know the reason behind the change now. > One final comment - I still don't understand why FreeBSD "won't" respond to pings when it has an address like 169.254.1.1. I can ssh to the unit but it won't respond to pings. I tried setting up a linux box with an address like 169.254.1.2 and it "would" respond to pings. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 12:04:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 493181065674 for ; Wed, 9 Jun 2010 12:04:16 +0000 (UTC) (envelope-from O.Seibert@cs.ru.nl) Received: from kookpunt.science.ru.nl (kookpunt.science.ru.nl [131.174.30.61]) by mx1.freebsd.org (Postfix) with ESMTP id D921C8FC1A for ; Wed, 9 Jun 2010 12:04:15 +0000 (UTC) Received: from twoquid.cs.ru.nl (twoquid.cs.ru.nl [131.174.142.38]) by kookpunt.science.ru.nl (8.13.7/5.31) with ESMTP id o59C4DvQ021134; Wed, 9 Jun 2010 14:04:13 +0200 (MEST) Received: by twoquid.cs.ru.nl (Postfix, from userid 4100) id 3542D2E05E; Wed, 9 Jun 2010 14:04:13 +0200 (CEST) Date: Wed, 9 Jun 2010 14:04:13 +0200 From: Olaf Seibert To: Mikolaj Golub Message-ID: <20100609120413.GC883@twoquid.cs.ru.nl> References: <20100527131310.GS883@twoquid.cs.ru.nl> <20100527174211.GC1211@michelle.cdnetworks.com> <20100607140611.GX883@twoquid.cs.ru.nl> <86mxv6wrmp.fsf@kopusha.home.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86mxv6wrmp.fsf@kopusha.home.net> User-Agent: Mutt/1.5.19 (2009-01-05) X-Spam-Score: -1.799 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.63 on 131.174.30.61 Cc: Pyun YongHyeon , freebsd-stable@freebsd.org, Olaf Seibert Subject: Re: nfe0 loses network connectivity (8.0-RELEASE-p2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jun 2010 12:04:16 -0000 On Mon 07 Jun 2010 at 22:48:46 +0300, Mikolaj Golub wrote: > It looks like the issue that has been fixed in STABLE. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/144330 Indeed, and I applied the patch in there, rebooted, and at least over the course of the past day, mbuf cluser useage seems not to grow anymore. Thanks! -Olaf. -- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 12:16:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C5211065670 for ; Wed, 9 Jun 2010 12:16:40 +0000 (UTC) (envelope-from jdc@koitsu.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 4FE218FC1A for ; Wed, 9 Jun 2010 12:16:39 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta05.emeryville.ca.mail.comcast.net with comcast id TnB01e0031Y3wxoA5oGfc0; Wed, 09 Jun 2010 12:16:39 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.emeryville.ca.mail.comcast.net with comcast id ToGe1e0093S48mS8boGeii; Wed, 09 Jun 2010 12:16:39 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 447A99B418; Wed, 9 Jun 2010 05:16:38 -0700 (PDT) Date: Wed, 9 Jun 2010 05:16:38 -0700 From: Jeremy Chadwick To: Stephen Clark Message-ID: <20100609121638.GA36975@icarus.home.lan> References: <4C0E81D7.8020209@earthlink.net> <20100608180506.GA9340@icarus.home.lan> <4C0E8B42.70603@earthlink.net> <20100608184429.GA12052@icarus.home.lan> <20100608184919.GY63749@cesium.hyperfine.info> <4C0E935E.1020409@earthlink.net> <4C0F8214.3090104@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C0F8214.3090104@earthlink.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Peter C. Lai" , FreeBSD Stable Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jun 2010 12:16:40 -0000 On Wed, Jun 09, 2010 at 07:59:16AM -0400, Stephen Clark wrote: > On 06/08/2010 03:00 PM, Stephen Clark wrote: > >On 06/08/2010 02:49 PM, Peter C. Lai wrote: > >>On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote: > >>>On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote: > >>>>On 06/08/2010 02:05 PM, Jeremy Chadwick wrote: > >>>>>On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote: > >>>>>>Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when > >>>>>>4.9 didn't? > >>>>> > >>>>>The following output would help: > >>>>> > >>>>>- ifconfig -a > >>>>>- netstat -rn > >>>>>- Contents of /etc/rc.conf > >>>>> > >>>>>Also, be aware that RELENG_6 is to be EOL'd at the end of this year: > >>>>>http://security.freebsd.org/ > >>>>> > >>>>Hi Jeremy, > >>>> > >>>>I am not sure that information is relevant. We have two systems > >>>>configured > >>>>identically one using 4.9 the other 6.3. > >>> > >>>My concern was that someone had botched something up in rc.conf or > >>>during the OS upgrade/migration, resulting in there being no loopback > >>>interface. I also wanted to verify that your routing table looked > >>>correct for what ifconfig showed. > >>> > >>>Other users pointed you to RFC 3927. Wikipedia has this to say: > >>> > >>>http://en.wikipedia.org/wiki/Link-local_address > >>> > >>>"Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses. > >>>However, the first and last /24 subnet (256 addresses each) in this > >>>block have been excluded from use and are reserved by the standard.[1]" > >>> > >>>I read this to mean 169.254.0.0/24 and 169.254.255.0/24. > >>> > >>>Your previous ifconfig statement shows: > >>> > >>>>$ ifconfig rl0 > >>>>rl0: flags=8843 mtu 1500 > >>>>options=8 > >>>>inet 192.168.129.1 netmask 0xffffff00 broadcast 192.168.129.255 > >>>>inet 169.254.1.1 netmask 0xffff0000 broadcast 169.254.255.255 > >>>>ether 00:30:18:ae:7c:77 > >>>>media: Ethernet autoselect (100baseTX) > >>>>status: active > >>> > >>>With this configuration, you're using both the first and last /24 > >>>netblocks -- 169.254.0.0 for your network address, and 169.254.255.255 > >>>for your broadcast address. > >>> > >>>You should be able to avoid this by using 169.254.1.0/24. > >>> > >> > >>RFC 3927 also has complicated rules involving when one can or should not > >>use a link-local address on the same interface as a routable IP, so at > >>best your configuration may not be supported anyway. One should not use > >>a link-local address as if it were under RFC 1918 rules, in particular > >>because link-local involves self-assigned addresses and internal > >>conflict mitigation. > >> > >Again what happened we had a box in the field that was running 4.9 being > >used as a router/nat/vpn/firewall device. It was handing out ip addresses > >to the internal lan using the range 169.254.202.0/24, who knows why this > >address range was picked. It worked great but > >the hardware died, so we were replacing it with our current SW which is > >based on 6.3 we duplicated the configuration and have been struggling > >trying to > >get it to work for the customer since Saturday with no luck. Today I > >finally > >tried to ping the internal address from the box itself and it wouldn't > >ping, > >so I started trying using other addresses on the internal interface and > >they > >worked but not 169.254.202.1. In googling I discovered that 169.254/16 > >was supposed to be assigned if a box couldn't obtain an ip but saw > >nothing about > >an OS dropping them. > > > >So anyway I know the reason behind the change now. > > > One final comment - I still don't understand why FreeBSD "won't" respond to pings > when it has an address like 169.254.1.1. I can ssh to the unit but it won't > respond to pings. I tried setting up a linux box with an address like > 169.254.1.2 and it "would" respond to pings. I tried to explain it as best as I could here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057191.html The IP stack (not a firewall, etc.) is basically blackholing the packet. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 12:28:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93333106566C for ; Wed, 9 Jun 2010 12:28:29 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [62.220.235.15]) by mx1.freebsd.org (Postfix) with ESMTP id 4DD1D8FC1C for ; Wed, 9 Jun 2010 12:28:29 +0000 (UTC) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id A381D1CC63; Wed, 9 Jun 2010 15:37:49 +0300 (EEST) Message-ID: <4A84438AC2044DEF873A7341CF0CF2F0@rivendell> From: "Reko Turja" To: References: <4C0E81D7.8020209@earthlink.net> <20100608180506.GA9340@icarus.home.lan> <4C0E8B42.70603@earthlink.net> <20100608184429.GA12052@icarus.home.lan> <20100608184919.GY63749@cesium.hyperfine.info><4C0E935E.1020409@earthlink.net> <4C0F8214.3090104@earthlink.net> In-Reply-To: <4C0F8214.3090104@earthlink.net> Date: Wed, 9 Jun 2010 15:28:36 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: FreeBSD Stable Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jun 2010 12:28:29 -0000 > One final comment - I still don't understand why FreeBSD "won't"=20 > respond to pings > when it has an address like 169.254.1.1. I can ssh to the unit but=20 > it won't > respond to pings. I tried setting up a linux box with an address=20 > like > 169.254.1.2 and it "would" respond to pings. Linux is not really any measuring stick in standard compliance... -Reko=20 From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 13:07:22 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C988B1065670 for ; Wed, 9 Jun 2010 13:07:22 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 95E368FC1B for ; Wed, 9 Jun 2010 13:07:22 +0000 (UTC) Received: from [192.168.2.164] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Wed, 09 Jun 2010 09:07:15 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::712 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-stable@FreeBSD.org X-SMFBL: ZnJlZWJzZC1zdGFibGVARnJlZUJTRC5vcmc= Message-ID: <4C0F9202.9010304@comcast.net> Date: Wed, 09 Jun 2010 09:07:14 -0400 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100311 Thunderbird/3.0.1 MIME-Version: 1.0 To: Jeff Blank References: <20091208174145.GA14312@mr-happy.com> In-Reply-To: <20091208174145.GA14312@mr-happy.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable , "Brian A. Seklecki" Subject: Re: Dell PowerEdge Virtual Media X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jun 2010 13:07:22 -0000 On 12/08/09 12:41, Jeff Blank wrote: > Hi, > > I'm having a little trouble using the "virtual media" function of > Dell's PowerEdge R-series (R710 in this case) iDRAC6 under FreeBSD > (7.1, 8.0). This is presented as /dev/cd0, a USB/"SCSI" device, I > guess. This is in the dmesg buffer when I boot up the existing 7.1 > installation with the virtual optical drive mapped to the 8.0-RELEASE > amd64 DVD image: > We're having some similar issues with our older PowerEdge 1850s (DRAC4). Things were alright on 6.3-RELEASE, but now there is a large hangup when trying to install 8.0-RELEASE: We see ~ 30x of these in dmesg: acd1: WARNING - READ_TOC read data overrun 20>12 Followed by this in sysinstall: "The disc in your drive looks more like an audio disc than a FreeBSD Release" (1). The DRAC Virtual Media and physical CDROM drives are probed like this in dmesg: acd1: DVR at ata2-slave PIO3 acd0: CDROM This is with the latest DRAC firmware available from Dell. From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 13:26:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75A631065670 for ; Wed, 9 Jun 2010 13:26:19 +0000 (UTC) (envelope-from sclark46@earthlink.net) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by mx1.freebsd.org (Postfix) with ESMTP id 3D84C8FC1E for ; Wed, 9 Jun 2010 13:26:18 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=iH97hUnGrBN1il557XsJ4oBNlp5S6qcJoMiZTyD0XXRCxzs7Qf+4ejL6BmPEMNYc; h=Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [69.22.83.66] (helo=joker.seclark.com) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OMLIQ-00075t-At; Wed, 09 Jun 2010 09:26:18 -0400 Message-ID: <4C0F9678.90605@earthlink.net> Date: Wed, 09 Jun 2010 09:26:16 -0400 From: Stephen Clark User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Reko Turja References: <4C0E81D7.8020209@earthlink.net> <20100608180506.GA9340@icarus.home.lan> <4C0E8B42.70603@earthlink.net> <20100608184429.GA12052@icarus.home.lan> <20100608184919.GY63749@cesium.hyperfine.info><4C0E935E.1020409@earthlink.net> <4C0F8214.3090104@earthlink.net> <4A84438AC2044DEF873A7341CF0CF2F0@rivendell> In-Reply-To: <4A84438AC2044DEF873A7341CF0CF2F0@rivendell> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: a437fbc6971e80f61aa676d7e74259b7b3291a7d08dfec798f74db92c3f33b387982e1f37a035487350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.22.83.66 Cc: FreeBSD Stable Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sclark46@earthlink.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 13:26:19 -0000 On 06/09/2010 08:28 AM, Reko Turja wrote: >> One final comment - I still don't understand why FreeBSD "won't" >> respond to pings >> when it has an address like 169.254.1.1. I can ssh to the unit but it >> won't >> respond to pings. I tried setting up a linux box with an address like >> 169.254.1.2 and it "would" respond to pings. > > Linux is not really any measuring stick in standard compliance... > > -Reko > _______________________________________________ > 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" > But reading the RFC it says the packets should not be routed - I don't see where it says that pings should not be responded to. Think about it the RFC was for link local devices - shouldn't on device on a link be able to ping another device and get a response. -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 13:55:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 461A41065680 for ; Wed, 9 Jun 2010 13:55:27 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id F2DD38FC12 for ; Wed, 9 Jun 2010 13:55:26 +0000 (UTC) Received: by iwn7 with SMTP id 7so2391981iwn.13 for ; Wed, 09 Jun 2010 06:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=bMqrLbpCOKNrXUcvscE2WCnbjURs/NTYTMZ/eJPUyDI=; b=Ngfh2cBmUUrxe+HejW3TWrDIXOZ2K4WdxRco59Qy0Ja7xYrkDDJFuMUt7EQWCl6o97 NR0t8/iiCeEsC0gjSCIu78QaRD04IG7OdouKIIN2lfFspnwH0A1CoGzWx5Bbsf8CA7mf slYH5Ejo4HAHIVqlYGeAA73F8hCURVCRo/bl0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=kh4l1Wp9IMFVj1o0qqwF+YU8o4MGZwihEgMGTjkm4dbQg9hhX82NPucidDsmBfz6TC JLKDNqszIeNTcTXUDD/f0kZPxyqKBQE/t95sLTZ1R5/VMXVas3IawPlHdqzhRZrqeKno luVuvxHHS1lIPHamrn6vgobAIkoVPh2dhWPCo= Received: by 10.231.170.3 with SMTP id b3mr7998739ibz.122.1276091725950; Wed, 09 Jun 2010 06:55:25 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-128-180.dsl.klmzmi.sbcglobal.net [99.181.128.180]) by mx.google.com with ESMTPS id t28sm31038831ibg.12.2010.06.09.06.55.14 (version=SSLv3 cipher=RC4-MD5); Wed, 09 Jun 2010 06:55:20 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C0F9D41.40009@dataix.net> Date: Wed, 09 Jun 2010 09:55:13 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100515 Thunderbird MIME-Version: 1.0 To: Reko Turja References: <4C0E81D7.8020209@earthlink.net> <20100608180506.GA9340@icarus.home.lan> <4C0E8B42.70603@earthlink.net> <20100608184429.GA12052@icarus.home.lan> <20100608184919.GY63749@cesium.hyperfine.info><4C0E935E.1020409@earthlink.net> <4C0F8214.3090104@earthlink.net> <4A84438AC2044DEF873A7341CF0CF2F0@rivendell> In-Reply-To: <4A84438AC2044DEF873A7341CF0CF2F0@rivendell> X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sclark46@earthlink.net, FreeBSD Stable Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jun 2010 13:55:27 -0000 On 06/09/2010 08:28, Reko Turja wrote: >> One final comment - I still don't understand why FreeBSD "won't" >> respond to pings >> when it has an address like 169.254.1.1. I can ssh to the unit but it >> won't >> respond to pings. I tried setting up a linux box with an address like >> 169.254.1.2 and it "would" respond to pings. > > Linux is not really any measuring stick in standard compliance... > I do not believe that is what he was implying by comparing this to Linux. I think he might be using Linux as a example of "They have not limited their users to only changing source code" to get the objective completed. They should have. In this case and reviewing the previous messages + remembering these: http://bit.ly/9sigji http://bit.ly/9pfE9A http://bit.ly/9CNT3K FreeBSD takes the correct action for this scenario which could proudly be used as an exemplary piece of code that other forms of OS's should use as a reference for integrity. http://bit.ly/byHBzN Regards, -- jhell From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 16:18:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6EB6106567C for ; Wed, 9 Jun 2010 16:18:33 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 1A10D8FC29 for ; Wed, 9 Jun 2010 16:18:32 +0000 (UTC) Received: (qmail 27619 invoked from network); 9 Jun 2010 16:18:30 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 9 Jun 2010 16:18:30 -0000 Date: Wed, 09 Jun 2010 18:18:30 +0200 (CEST) Message-Id: <20100609.181830.74726190.sthaug@nethelp.no> To: reko.turja@liukuma.net From: sthaug@nethelp.no In-Reply-To: <4A84438AC2044DEF873A7341CF0CF2F0@rivendell> References: <4C0E935E.1020409@earthlink.net> <4C0F8214.3090104@earthlink.net> <4A84438AC2044DEF873A7341CF0CF2F0@rivendell> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: sclark46@earthlink.net, freebsd-stable@freebsd.org Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jun 2010 16:18:34 -0000 > > One final comment - I still don't understand why FreeBSD "won't" > > respond to pings > > when it has an address like 169.254.1.1. I can ssh to the unit but > > it won't > > respond to pings. I tried setting up a linux box with an address > > like > > 169.254.1.2 and it "would" respond to pings. > > Linux is not really any measuring stick in standard compliance... If 169.254.0.0/16 addresses are supposed to be link local then I'd definitely expect a reply to a ping from another box on the same LAN, sourced from another 169.254.0.0/16 address. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 16:38:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D024C106566B for ; Wed, 9 Jun 2010 16:38:32 +0000 (UTC) (envelope-from Toras@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 2662F8FC1B for ; Wed, 9 Jun 2010 16:38:31 +0000 (UTC) Received: (qmail 29805 invoked by uid 0); 9 Jun 2010 16:11:50 -0000 Received: from 217.6.95.137 by www156.gmx.net with HTTP; Wed, 09 Jun 2010 18:11:48 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Wed, 09 Jun 2010 18:11:48 +0200 From: "Thorsten Baumeister" Message-ID: <20100609161148.250580@gmx.net> MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Authenticated: #622589 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX19Wz2xP8+hWZ2U3diIDz8up9gjnGNPwt2GwDbwBx5 Fq3kwa5CGvER1eiBdisanlQWHKAtk9XXsGkA== Content-Transfer-Encoding: 8bit X-GMX-UID: INRqDYwVfW47a8clfmVoZsxudmllcgWA X-FuHaFi: 0.59999999999999998 Subject: (no subject) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jun 2010 16:38:32 -0000 Hi everyone! I have a problem to get my KDE4 Terminal working. I use a German keyboard, and I am not able to use some special keys. Especially I miss the pipe symbol ('|'), but there are some more like '§', '@', '€'. I compiled KDE on my own computer running a FreeBSD 8.0-STABLE kernel. All packages are up to date. Any hints? If I use an SSH connection (PuTTY), everything is fine. Thorsten Baumeister -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 17:22:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ADA11065675 for ; Wed, 9 Jun 2010 17:22:38 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id B761A8FC0A for ; Wed, 9 Jun 2010 17:22:37 +0000 (UTC) Received: by wwb22 with SMTP id 22so6019958wwb.13 for ; Wed, 09 Jun 2010 10:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=P8KddXHzfb+Uiv25uTR17QKrzAw7mTFo8g3cA8nTcvQ=; b=ckycie3HXwtXN0MuYqKCLdAR1YSw/B9Y4RaDDWgOquVyIIYjRr1VA+weivw4e/TAHH 0o4Q1owEqEXYkdVU6WZS9xAgf4N5fUXiKEOh479UQiqdLQWrsEtEZ6G/xnOSB3Fhns8e UUyoXeRpAchE1FQd7booiY98m+mMXLsZx+N9Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kXX+VTRoTqRBwGGoDz18lzCDNH462YmZFmvYYIXPADvGRLHFSi7OBYx40zaPeNAQcC cJHtBmUNV4looOx+BBq8kJF9/P6QjCBzedUChtwI0Zwz1RXEX9L33VCpLjJpI+Zn8MMM GUVtNYxGwm8w/EuMuraNsyRCk1WL3h+Dmu1qE= MIME-Version: 1.0 Received: by 10.216.85.17 with SMTP id t17mr1584780wee.30.1276104153554; Wed, 09 Jun 2010 10:22:33 -0700 (PDT) Received: by 10.216.229.24 with HTTP; Wed, 9 Jun 2010 10:22:33 -0700 (PDT) In-Reply-To: <20100609161148.250580@gmx.net> References: <20100609161148.250580@gmx.net> Date: Wed, 9 Jun 2010 19:22:33 +0200 Message-ID: From: Christian Walther To: Thorsten Baumeister Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: (no subject) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jun 2010 17:22:38 -0000 Hi Thorsten, On 9 June 2010 18:11, Thorsten Baumeister wrote: > Hi everyone! > I have a problem to get my KDE4 Terminal working. I use a German keyboard= , and I am not able to use some special keys. Especially I miss the pipe sy= mbol ('|'), but there are some more like '=A7', '@', '=80'. I compiled KDE = on my own computer running a FreeBSD 8.0-STABLE kernel. All packages are up= to date. Any hints? If I use an SSH connection (PuTTY), everything is fine= . I created a /etc/X11/xorg.conf file using # X -configure and added/changed the following section: Section "InputDevice" Identifier "Keyboard0" Driver "keyboard" Option "XkbModel" "pc105" Option "XkbLayout" "de" Option "XkbVariant" "nodeadkeys" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection The last Option line isn't necessary, but it makes it possible to terminate the X server by pressing Ctrl+Alt+Backspace, which has been deactivated in recent default configurations. If you add the above mentioned Section "InputDevice", make sure that the Section "ServerLayout" contains a CoreKeyboard entry matching the given identifier. In my case, Section "ServerLayout" looks like: Section "ServerLayout" Identifier "XFree86 Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" Option "Clone" "off" EndSection HTH Christian Walther From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 18:08:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 973D4106564A for ; Wed, 9 Jun 2010 18:08:46 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward13.mail.yandex.net (forward13.mail.yandex.net [95.108.130.120]) by mx1.freebsd.org (Postfix) with ESMTP id 4137E8FC1F for ; Wed, 9 Jun 2010 18:08:45 +0000 (UTC) Received: from smtp13.mail.yandex.net (smtp13.mail.yandex.net [95.108.130.68]) by forward13.mail.yandex.net (Yandex) with ESMTP id 4EB931081A6E; Wed, 9 Jun 2010 22:08:44 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1276106924; bh=Q2qJMj8OMfHsBxv2N8JWcATHTxOSrCGBelfIxItrnCA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=Xk/6EJPktssBrrS/7ZqAMXxQnZQMTdIJCL8QCl/RpmPak3WnrNBH0DRRkVPUCWFnr ROGLjFoCJypNvQKocpsV9allEAd/w4LApA21fOGPiXlNKeN7DupY2P1KdDTwUnLCdB +YxyefSzHkMa6+C0Nm2djsKDINWKQLETpQlF3ARg= Received: from btr.properlan.net (butcher.heavennet.ru [77.72.136.194]) by smtp13.mail.yandex.net (Yandex) with ESMTPSA id 9E7664158099; Wed, 9 Jun 2010 22:08:43 +0400 (MSD) Message-ID: <4C0FD8A2.3070307@yandex.ru> Date: Wed, 09 Jun 2010 22:08:34 +0400 From: "Andrey V. Elsukov" User-Agent: Thunderbird 2.0.0.23 (X11/20100209) MIME-Version: 1.0 To: Stephane Dupille References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig656C11DA8768E202236AAC7D" X-Yandex-TimeMark: 1276106924 X-Yandex-Spam: 1 X-Yandex-Front: smtp13.mail.yandex.net Cc: freebsd-stable@freebsd.org Subject: Re: Resizing GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jun 2010 18:08:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig656C11DA8768E202236AAC7D Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Stephane Dupille wrote: > I dumped this disk image to a real machine, which has a 160 Go disk. > The system works fine, but I can only use 10 Go of disk space. How can > I gain more space ? >=20 > How can I enlarge the last partition of the disk to use the whole disk = ? >=20 > I tried to create a new partition on the disk, and planned to add it > in the zfs pool, but that didn't work : > # gpart add -t freebsd-zfs -l disk0f ad0 > gpart: autofill: No space left on device >=20 > That's odd, because it seems that gpart is aware of the new geometry. Currently there is no easy way to do it. GPT holds information about first and last usable sectors. You can see them in your output: > last: 20971486 > first: 34 You can look at freebsd-geom's mail list archive. There was a topic "OCE and GPT" with similar problem. --=20 WBR, Andrey V. Elsukov --------------enig656C11DA8768E202236AAC7D 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.14 (FreeBSD) iQEcBAEBAgAGBQJMD9imAAoJEAHF6gQQyKF6rEgH/AppjQDQXCh4JMzpgcQdFivq /4jlluSdhRS5WOuAUysCQIS67X1wNpEe9V1Tzq9/S1lVkOMfhyJ+OY/kNIhA06vk N1ajjZ0k8eQrz6PemZwARj2EuO+GGRYmr+W84uzHl/UpR4IyGpzAXpGIEKl3Dvbz ghtjyAcjMEXoPwZR5DkNHCfJ3vD5CH6OZBM7DOJ5iWWe0KQj6n5XwG3MRAXm/guK JjyasAhQ22HUt95Y3UQveA7a9RFD/yEvNfdNNalk3R8udObT2SA6kpgmeogN88Nd Afh8XOBpwD6O+R1OHDvMd1SkOVMCX7iLebYkmoeKpEVhvG06UvWD5trBiak1SeQ= =lnl6 -----END PGP SIGNATURE----- --------------enig656C11DA8768E202236AAC7D-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 19:32:24 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DA051065678 for ; Wed, 9 Jun 2010 19:32:24 +0000 (UTC) (envelope-from prvs=1776ac14af=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id D56B68FC0A for ; Wed, 9 Jun 2010 19:32:23 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 09 Jun 2010 20:32:22 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 09 Jun 2010 20:32:22 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50010476047.msg for ; Wed, 09 Jun 2010 20:32:21 +0100 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 188.220.16.48 X-Return-Path: prvs=1776ac14af=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-stable@FreeBSD.org Message-ID: From: "Steven Hartland" To: "Steve Polyack" , "Jeff Blank" References: <20091208174145.GA14312@mr-happy.com> <4C0F9202.9010304@comcast.net> Date: Wed, 9 Jun 2010 20:32:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Cc: "Brian A. Seklecki" , freebsd-stable Subject: Re: Dell PowerEdge Virtual Media X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jun 2010 19:32:24 -0000 Try 8.1 to see if that helps, did here :) ----- Original Message ----- From: "Steve Polyack" > We're having some similar issues with our older PowerEdge 1850s > (DRAC4). Things were alright on 6.3-RELEASE, but now there is a large > hangup when trying to install 8.0-RELEASE: > > We see ~ 30x of these in dmesg: > acd1: WARNING - READ_TOC read data overrun 20>12 > > Followed by this in sysinstall: > "The disc in your drive looks more like an audio disc than a > FreeBSD Release" (1). > > The DRAC Virtual Media and physical CDROM drives are probed like this in > dmesg: > acd1: DVR at ata2-slave PIO3 > acd0: CDROM > > This is with the latest DRAC firmware available from Dell. > > _______________________________________________ > 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 e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 19:40:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 175771065672 for ; Wed, 9 Jun 2010 19:40:17 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 537E78FC25 for ; Wed, 9 Jun 2010 19:40:15 +0000 (UTC) Received: (qmail 57506 invoked from network); 9 Jun 2010 19:40:14 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 9 Jun 2010 19:40:14 -0000 Date: Wed, 09 Jun 2010 21:40:14 +0200 (CEST) Message-Id: <20100609.214014.104050932.sthaug@nethelp.no> To: freebsd-stable@freebsd.org From: sthaug@nethelp.no In-Reply-To: <20100609.181830.74726190.sthaug@nethelp.no> References: <4C0F8214.3090104@earthlink.net> <4A84438AC2044DEF873A7341CF0CF2F0@rivendell> <20100609.181830.74726190.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD eats 169.254.x.x addressed packets X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jun 2010 19:40:17 -0000 > > > One final comment - I still don't understand why FreeBSD "won't" > > > respond to pings > > > when it has an address like 169.254.1.1. I can ssh to the unit but > > > it won't > > > respond to pings. I tried setting up a linux box with an address > > > like > > > 169.254.1.2 and it "would" respond to pings. > > > > Linux is not really any measuring stick in standard compliance... > > If 169.254.0.0/16 addresses are supposed to be link local then I'd > definitely expect a reply to a ping from another box on the same > LAN, sourced from another 169.254.0.0/16 address. Having tested this in the lab I'd say FreeBSD 7.x works exactly as expected. Traffic on the same LAN works, traffic to other LANs is not routed. All is well. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 22:14:53 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 214A01065678; Wed, 9 Jun 2010 22:14:53 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id CBFC48FC14; Wed, 9 Jun 2010 22:14:52 +0000 (UTC) Received: by iwn7 with SMTP id 7so3008336iwn.13 for ; Wed, 09 Jun 2010 15:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=pXeRkbj6RS52l+DiULX7xdabhwCzBaFrRerTa3JO7lE=; b=wBBT0rebyf5CMxbx7vJjRFdPA6pgqeyEdoCkL9myb8nbCm6pQhfDcOKw2/gR+Ajt2I yQLL2g+ilOjT3ZZCM30PaoGzSpBsWw0IlZjGcvIdiDmwhR7nqDTkayFt8jj2UWaBzX85 ANVRfi4/E6+A7vS6ucJgzAX1SyGPeAOP+AAqo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wHFU76BOFo6yjxv3cNiLq/CTS6VmVrrcm9RWVCZjK+uigj0I0NtAEdhFqIB+J/d97U Yg5C6rBNicFTpShpXaiVVitWKJPGhwRY5sDOtUr+Mda7J2J3wYA8YJQFUuMLeocpsrZd Bd1SLtGvhl/9z11356VVU5gPUTMhhCzMdB94I= MIME-Version: 1.0 Received: by 10.231.204.199 with SMTP id fn7mr8539422ibb.132.1276121692128; Wed, 09 Jun 2010 15:14:52 -0700 (PDT) Received: by 10.231.190.131 with HTTP; Wed, 9 Jun 2010 15:14:52 -0700 (PDT) In-Reply-To: <147432021001260849l7c2e1175gdee26b44fc1191ba@mail.gmail.com> References: <147432021001251901u7d56f014n83e834061fd09fec@mail.gmail.com> <20100126124154.GA72180@edoofus.dev.vega.ru> <147432021001260849l7c2e1175gdee26b44fc1191ba@mail.gmail.com> Date: Wed, 9 Jun 2010 18:14:52 -0400 Message-ID: From: Nick Rogers To: Ruslan Ermilov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org Subject: Re: netstat output changes in 8.0? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 22:14:53 -0000 On Tue, Jan 26, 2010 at 12:49 PM, Nick Rogers wrote: > Thanks a lot. Thats a bummer. What are the chances of getting something > like that worked into arp(8) permanently? > > I recently noticed that arp(8) was changed a few months back to show when an entry expires. Thanks! http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/arp/arp.c?rev=1.75 From owner-freebsd-stable@FreeBSD.ORG Wed Jun 9 22:18:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2916106567C for ; Wed, 9 Jun 2010 22:18:26 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6CFAA8FC12 for ; Wed, 9 Jun 2010 22:18:26 +0000 (UTC) Received: by iwn7 with SMTP id 7so3012300iwn.13 for ; Wed, 09 Jun 2010 15:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=vlvXXtEY2PtYcF/4GHHqnuIejZ/usyMS2je7T7OnHhw=; b=IEYqZVZ2IO9sXbx5jil4IgiAiO1faZujgghicj+/kGyCQrGp5zTCd37zU3xfGIdVeY 2owt4FMUhUJY5BFyThkMCDzhd2janjWQW+4UCOig2bPVLa/MNkh+JNigNtPRx0RSz9ZW e+HkBvD7T4NlkyYDS4TacWJcQZuqU8ACQpu8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=X5HyipRW6o9d3cnE2L7jBx3AVvgb7wtDOoy1cz15BzucWHIvuLYtSughedu93bZzrz +Ko/F+EzTongY6dePH63mqTb10cCTXdKKyqlZ9CrbTd0P3CAzA9E1f4+RVtcyFenD7sb 50b+F1rYzPI+Il6OOzuMg9UiSJHTlaUHZLvXs= MIME-Version: 1.0 Received: by 10.231.124.40 with SMTP id s40mr8748244ibr.172.1276121903409; Wed, 09 Jun 2010 15:18:23 -0700 (PDT) Received: by 10.231.190.131 with HTTP; Wed, 9 Jun 2010 15:18:23 -0700 (PDT) In-Reply-To: References: <20100606031627.GA4742@icarus.home.lan> Date: Wed, 9 Jun 2010 18:18:23 -0400 Message-ID: From: Nick Rogers To: FreeBSD STABLE Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: arp -na performance w/ many permanent entries X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Jun 2010 22:18:27 -0000 On Sun, Jun 6, 2010 at 4:23 PM, Nick Rogers wrote: > > > On Sat, Jun 5, 2010 at 11:54 PM, Garrett Cooper wrote: >> >> >> I agree with Jeremy. I think that the problem that you've >> discovered is the fact that it's using stdio-based buffered output >> instead of buffering more of the contents in a string and punting it >> out in larger chunks. >> HTH, >> -Garrett >> > > I don't think so. The performance difference when taking out the interface > lookup is huge even though the data output to STDOUT is mostly the same. > I'll try the other lists, thanks. > > FYI there is a bugfix/patch for this issue being discussed in freebsd-hackers: http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg157097.html Thanks again for suggesting I try another list. From owner-freebsd-stable@FreeBSD.ORG Thu Jun 10 08:10:43 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C11DF1065679 for ; Thu, 10 Jun 2010 08:10:43 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 4797A8FC0A for ; Thu, 10 Jun 2010 08:10:42 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o5A8AcVT022587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jun 2010 10:10:41 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4C109DF7.6070007@omnilan.de> Date: Thu, 10 Jun 2010 10:10:31 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6D298B2BA6A0E9657231BED0" Cc: Subject: extremely strange results with "mail" or "make" after one day uptime X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2010 08:10:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6D298B2BA6A0E9657231BED0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello all, I have absolutley no idea how it comes: After one or two days of uptime, 'make -j3 buildworld' just returns=20 without any error but without doing anything. Also sending mail via 'mail' produces mutilatet output: no valid rcpt,=20 no subject. When I reboot the machine everything is fine again. Daily status reports also stop working; that's how I found this=20 absolutley mysterious spookie thing. And: sshguard destroys hosts.allow. It's suddenly empty. The jails don't seem to suffer form that ghost. My setup: 8.1-prerelease on amd64 with _read-only_ / (and unionfs /etc), and=20 dozends of ZFS filesystems for jails. Where to start to debug? Any hints highly appreciated. -Harry --------------enig6D298B2BA6A0E9657231BED0 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.13 (FreeBSD) iEYEARECAAYFAkwQnf4ACgkQLDqVQ9VXb8gyFwCgi/4oNYpMqUP6YzZGYQsIcaGp jiAAn3ERBCM30RVdjPYkiuv8S3/GTmhk =hJ6k -----END PGP SIGNATURE----- --------------enig6D298B2BA6A0E9657231BED0-- From owner-freebsd-stable@FreeBSD.ORG Thu Jun 10 09:17:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C097E1065675 for ; Thu, 10 Jun 2010 09:17:35 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 30FF18FC24 for ; Thu, 10 Jun 2010 09:17:34 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o5A9HX0L023428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jun 2010 11:17:34 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4C10ADAD.2010908@omnilan.de> Date: Thu, 10 Jun 2010 11:17:33 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C109DF7.6070007@omnilan.de> In-Reply-To: <4C109DF7.6070007@omnilan.de> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF9EAFC7A9A8FE2F5E177DE73" Subject: Re: extremely strange results with "mail" or "make" after one day uptime X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2010 09:17:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF9EAFC7A9A8FE2F5E177DE73 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Harald Schmalzbauer schrieb am 10.06.2010 10:10 (localtime): > Hello all, >=20 > I have absolutley no idea how it comes: > After one or two days of uptime, 'make -j3 buildworld' just returns=20 > without any error but without doing anything. > Also sending mail via 'mail' produces mutilatet output: no valid rcpt, = > no subject. > When I reboot the machine everything is fine again. > Daily status reports also stop working; that's how I found this=20 > absolutley mysterious spookie thing. > And: sshguard destroys hosts.allow. It's suddenly empty. It seems that any text handling routine gets crazy because=20 /var/run/jail_XXX.id is also empty when starting new jails. It worked at machine boot, since older running jails do have a number in = their id file. Only newer started/restarted jails have an empty id file. Also the hosts.allow gets reproducable emptied by sshguard. Where's the part of FreeBSD doing such text manipulation? Maybe that's also responsable for makefile parsing and such explains the = 'make' failure? Interesting is that 'make' without -j3 at least starts=20 the build, but reproducable fails at different points while src tree is=20 absolutely consistent. If I mount it elsewhere everything compiles fine. And to ephisize: This mysteric behaviour of some base system components=20 appears only after some uptime. I haven't seen it the first day after=20 fresh booting. Anybody any ideas? I'm desperate because I don't know here I could start = to search/test. Thanks in advance, -Harry --------------enigF9EAFC7A9A8FE2F5E177DE73 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.13 (FreeBSD) iEYEARECAAYFAkwQra0ACgkQLDqVQ9VXb8jOxQCeKIBGiw3YHG6U5pJBLss5nGgP xtkAnAqmt+pvk5VUvzePUNHQFtWZsmqn =kyZs -----END PGP SIGNATURE----- --------------enigF9EAFC7A9A8FE2F5E177DE73-- From owner-freebsd-stable@FreeBSD.ORG Thu Jun 10 09:28:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE11B1065672 for ; Thu, 10 Jun 2010 09:28:25 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 62B488FC0C for ; Thu, 10 Jun 2010 09:28:24 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o5A9SO69023549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jun 2010 11:28:24 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4C10B037.6030702@omnilan.de> Date: Thu, 10 Jun 2010 11:28:23 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4C109DF7.6070007@omnilan.de> <4C10ADAD.2010908@omnilan.de> In-Reply-To: <4C10ADAD.2010908@omnilan.de> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBD6362A107F1EEB5AE41A1A7" Subject: tmpfs problem [Was: Re: extremely strange results with "mail" or "make" after one day uptime] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2010 09:28:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBD6362A107F1EEB5AE41A1A7 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Harald Schmalzbauer schrieb am 10.06.2010 11:17 (localtime): > Harald Schmalzbauer schrieb am 10.06.2010 10:10 (localtime): >> Hello all, >> >> I have absolutley no idea how it comes: >> After one or two days of uptime, 'make -j3 buildworld' just returns=20 >> without any error but without doing anything. >> Also sending mail via 'mail' produces mutilatet output: no valid rcpt,= =20 >> no subject. >> When I reboot the machine everything is fine again. >> Daily status reports also stop working; that's how I found this=20 >> absolutley mysterious spookie thing. >> And: sshguard destroys hosts.allow. It's suddenly empty. >=20 > It seems that any text handling routine gets crazy because=20 > /var/run/jail_XXX.id is also empty when starting new jails. > It worked at machine boot, since older running jails do have a number i= n=20 > their id file. Only newer started/restarted jails have an empty id file= =2E > Also the hosts.allow gets reproducable emptied by sshguard. >=20 > Where's the part of FreeBSD doing such text manipulation? > Maybe that's also responsable for makefile parsing and such explains th= e=20 > 'make' failure? Interesting is that 'make' without -j3 at least starts = > the build, but reproducable fails at different points while src tree is= =20 > absolutely consistent. If I mount it elsewhere everything compiles fine= =2E >=20 > And to ephisize: This mysteric behaviour of some base system components= =20 > appears only after some uptime. I haven't seen it the first day after=20 > fresh booting. >=20 > Anybody any ideas? I'm desperate because I don't know here I could star= t=20 > to search/test. Ok, luck seems to be with the stupid this day ;) I identified tmpfs as the culprit. 'head /etc/hosts.allow' correctly returnes two lines! 'head -n 2 /etc/hosts.allow' > /tmp/test results in a empty file 'head -n 2 /etc/hosts.allow > /var/tmp/test' produves a file with the=20 expected two lines. Ok, next time I'll better adhere to developers experimental warnings... Is there anything I can do for the hackers? I haven't had that symptom=20 before on any other machine and I'm using tmpfs for quiet some time.=20 Maby it's an interesting edge case. Thanks, -Harry --------------enigBD6362A107F1EEB5AE41A1A7 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.13 (FreeBSD) iEYEARECAAYFAkwQsDcACgkQLDqVQ9VXb8gxfwCeL3FHajyKCGRj9tUJNENNlYtK UWsAn3L1ux1OJ61TEmwV8IqezzMnb848 =AWZs -----END PGP SIGNATURE----- --------------enigBD6362A107F1EEB5AE41A1A7-- From owner-freebsd-stable@FreeBSD.ORG Thu Jun 10 09:33:48 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFC9B1065689 for ; Thu, 10 Jun 2010 09:33:48 +0000 (UTC) (envelope-from sdupille@nospam.fr.eu.org) Received: from mail.nospam.fr.eu.org (galadriel.nospam.fr.eu.org [88.191.16.109]) by mx1.freebsd.org (Postfix) with ESMTP id 893008FC13 for ; Thu, 10 Jun 2010 09:33:47 +0000 (UTC) Received: from galadriel.nospam.fr.eu.org (localhost [127.0.0.1]) (Authenticated sender: dust) by mail.nospam.fr.eu.org (Postfix) with ESMTP id 68EA3440817 for ; Thu, 10 Jun 2010 11:33:46 +0200 (CEST) From: Stephane Dupille To: stable@freebsd.org References: <4C0FD8A2.3070307@yandex.ru> Organization: Home Mail-copies-to: never Date: Thu, 10 Jun 2010 11:33:45 +0200 In-Reply-To: <4C0FD8A2.3070307@yandex.ru> (Andrey V. Elsukov's message of "Wed, 09 Jun 2010 22:08:34 +0400") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Cc: Subject: Re: Resizing GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2010 09:33:48 -0000 "Andrey V. Elsukov" écrit : Hi, > Stephane Dupille wrote: > Currently there is no easy way to do it. GPT holds information about > first and last usable sectors. You can see them in your output: >> last: 20971486 >> first: 34 I had the opportunity to boot that machine from network (a linux), and parted fix GPT tables correctly. Now, I have in FreeBSD the right last usable sector : last: 312581774 first: 34 And dmesg does not say anymore that the secondary GPT table is corrupt or invalid. (yeah, one problem fixed) Unfortunatly, parted does not allow me to resize the last partition because it does not know the type of the partition. > You can look at freebsd-geom's mail list archive. There was a topic > "OCE and GPT" with similar problem. Yep, seen it. I applied your patch to resize partition, but I didn't manage to use it correctly. # cd /usr/src # patch < /root/patch # cd sbin/geom/class/part/ # make # make install Did I applied the patch correctly ? It seems not working : # gpart resize -i 3 ad0 gpart: param 'size': Invalid argument Thanks for your reply. From owner-freebsd-stable@FreeBSD.ORG Thu Jun 10 16:58:34 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9706A106566C for ; Thu, 10 Jun 2010 16:58:34 +0000 (UTC) (envelope-from jtgotis@gmail.com) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.211.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4DD9F8FC15 for ; Thu, 10 Jun 2010 16:58:33 +0000 (UTC) Received: by ywh12 with SMTP id 12so183577ywh.14 for ; Thu, 10 Jun 2010 09:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=pxubkBTdO91s2TU4unjcvQLyVaUWB3DNNSDv/fiZS1s=; b=fnw359dUmPlFv9DB2xgV0znhV8ENqRiR6y1YGjBgl6iwHHQSSCmjHi5tJftXW24ipW JYSa8AAYrwGa4HYyl4F3G1mcKiXj+McM1nbB/gLg/zUj7HZNlPjh4l1nXCDzOLfX2SRS Pv+2JpI/HaVDdimpCxPX9y9Gd2+9VP+wcE2ws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=L0lYe0I+HUYLDNQsnDIoYQMzl7CtMLGZelntdEmV8E27PfUsqaEdKd6W66P52Tev+m W3PgHjf4T/kcSe3iQAVCubldckxZA1llhSxwU6Fb+24j1m/SLbzdcl5/yKeSh7GgxFV4 J687rtASUnN+sSwqm/Spe5hj7A1XAWbDwvGkk= MIME-Version: 1.0 Received: by 10.229.236.76 with SMTP id kj12mr333208qcb.226.1276187705480; Thu, 10 Jun 2010 09:35:05 -0700 (PDT) Received: by 10.220.86.213 with HTTP; Thu, 10 Jun 2010 09:35:05 -0700 (PDT) Date: Fri, 11 Jun 2010 00:35:05 +0800 Message-ID: From: Jansen Gotis To: freebsd-stable@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: "calcru: runtime went backwards" messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2010 16:58:34 -0000 Hi, for the past couple of months since moving to RELENG_8 I've been receiving "calcru: runtime went backwards" messages on the console. My machine is a dual Pentium III 1.26GHz with an Intel SAI2 board. Disabling EIST is not an option in my BIOS, and I've tried disabling the ACPI timer as well as setting kern.timecounter.hardware=i8254. I've also tried disabling cpufreq in my kernel configuration. For what it's worth, I'm running base ntpd. I've also tried openntpd, but no dice. I did a binary search of the commit with which this started, and apparently it's svn r204546, a summary of which can be seen here: http://freshbsd.org/2010/03/02/01/56/55 The calcru messages appear whether vesa is loaded as a module or compiled into the kernel. If anyone needs more information, I'll be happy to provide it. Best regards, Jansen ===== snippet of /var/log/messages relating to calcru messages ===== Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from 3502 usec to 3297 usec for pid 1106 (mksh) Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from 36785 usec to 35858 usec for pid 1114 (csh) Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from 13438 usec to 12652 usec for pid 1113 (su) Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from 14956 usec to 14081 usec for pid 1111 (mksh) Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from 3323 usec to 3128 usec for pid 1111 (mksh) Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from 610 usec to 574 usec for pid 549 (devd) Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from 517 usec to 486 usec for pid 548 (dhclient) Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from 1912 usec to 1800 usec for pid 532 (dhclient) Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from 39738 usec to 37412 usec for pid 532 (dhclient) Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from 3369010 usec to 3334846 usec for pid 1 (init) ===== /var/run/dmesg.boot ===== Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-STABLE #0 r204546: Thu Jun 10 21:05:09 PHT 2010 jansen@hobbes.jansen.homenet:/usr/obj/usr/src/sys/LOCAL i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) III CPU family 1266MHz (1263.45-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383fbff real memory = 2148007936 (2048 MB) avail memory = 2090995712 (1994 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 3 cpu1 (AP): APIC ID: 0 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-15 on motherboard ioapic1 irqs 16-31 on motherboard kbd1 at kbdmux0 netsmb_dev: loaded smbios0: at iomem 0xf6e90-0xf6eae on motherboard smbios0: Version: 2.3, BCD Revision: 2.3 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x2000-0x20ff mem 0xfa000000-0xfaffffff,0xfb000000-0xfb000fff at device 2.0 on pci0 fxp0: port 0x2400-0x243f mem 0xfb001000-0xfb001fff,0xfb100000-0xfb1fffff irq 18 at device 3.0 on pci0 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:03:47:a6:0d:4a fxp0: [ITHREAD] isab0: at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x2440-0x244f at device 15.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] ohci0: mem 0xfb002000-0xfb002fff irq 9 at device 15.2 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 pcib1: on acpi0 pci1: on pcib1 atapci1: port 0x2480-0x24ff,0x2800-0x28ff mem 0xfb420000-0xfb420fff,0xfb400000-0xfb41ffff irq 20 at device 10.0 on pci1 atapci1: [ITHREAD] atapci1: [ITHREAD] ata2: on atapci1 ata2: SIGNATURE: 00000101 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 cpu0: on acpi0 cpu1: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xc97ff,0xc9800-0xce7ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: <(0x1166)> at usbus0 uhub0: <(0x1166) OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0 uhub0: 2 ports with 2 removable, self powered acd0: CDRW at ata1-master UDMA33 ad4: 953869MB at ata2-master UDMA100 SATA 1.5Gb/s ad8: 190781MB at ata4-master UDMA100 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s1a From owner-freebsd-stable@FreeBSD.ORG Thu Jun 10 17:14:17 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5161F106572D for ; Thu, 10 Jun 2010 17:14:17 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward7.mail.yandex.net (forward7.mail.yandex.net [77.88.61.37]) by mx1.freebsd.org (Postfix) with ESMTP id EFC6C8FC0C for ; Thu, 10 Jun 2010 17:14:16 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward7.mail.yandex.net (Yandex) with ESMTP id 070B11B08651; Thu, 10 Jun 2010 21:14:15 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1276190055; bh=0CQ4abxg50J16BpYSgsC2pMUibwY/w156reFFdD4DlE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=tNRemZxkOOtVhYnV05bcXI+zNjPab3N02eTJS/eXDQM8WLBd8yeUf8zL/PoPKG/Mj sxYr39zRMX+35JKeGOmyF7KkXs7LupPcpxydY/+lPjt10/n2J+CbxiE2rP9qZiWg5m rtuo/z255F8U1VysEWDu7QMCs2VZMjIJzLOeVlCE= Received: from btr.properlan.net (unknown [77.72.138.63]) by smtp8.mail.yandex.net (Yandex) with ESMTPSA id B9B6E2028095; Thu, 10 Jun 2010 21:14:14 +0400 (MSD) Message-ID: <4C111D5D.3030006@yandex.ru> Date: Thu, 10 Jun 2010 21:14:05 +0400 From: "Andrey V. Elsukov" User-Agent: Thunderbird 2.0.0.23 (X11/20100209) MIME-Version: 1.0 To: Stephane Dupille References: <4C0FD8A2.3070307@yandex.ru> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig173CF9AC1FA5EF8BC25CC233" X-Yandex-TimeMark: 1276190054 X-Yandex-Spam: 1 X-Yandex-Front: smtp8.mail.yandex.net Cc: stable@freebsd.org Subject: Re: Resizing GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2010 17:14:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig173CF9AC1FA5EF8BC25CC233 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Stephane Dupille wrote: > And dmesg does not say anymore that the secondary GPT table is corrupt > or invalid. I have plan to add `gpart recover` feature in near future. > Yep, seen it. I applied your patch to resize partition, but I didn't > manage to use it correctly. >=20 > # cd /usr/src > # patch < /root/patch > # cd sbin/geom/class/part/ > # make > # make install >=20 > Did I applied the patch correctly ? It seems not working : > # gpart resize -i 3 ad0 > gpart: param 'size': Invalid argument It needs in kernel support too. You can try to download snapshot of livefs CD of 9.0-CURRENT and use it. http://pub.allbsd.org/FreeBSD-snapshots/ --=20 WBR, Andrey V. Elsukov --------------enig173CF9AC1FA5EF8BC25CC233 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.14 (FreeBSD) iQEcBAEBAgAGBQJMER1iAAoJEAHF6gQQyKF6EwkH/2O0mzQls3XILtu6MNAZmVvw tFQ2tonJ0SVMx4weBN6GeEijiE3VFhaigV0d93OlO7VXdqGRRdMfacXlJufbe2Of Repk1D/V7ktjEy3PsC3LTxtsnPQbWk/M2gOX5SMk+bSNCi/Q1qzgtSNrM2fTHISp OnaBnNwogM4Y9T+3yuf0hsH5v3EGsnOidPY3Q84MKLYPuTv/ULrdbb4f7kiRP6gx CMrpmDXLOdNE6c2vEpeYvbcK5OoW1ujyXhiSxrspgyv4TGqCDsLIu8Bpp9cb9URK 1j0WBBI4dxNNj2j4mCzBD0xYoBJ1x52xFmAKW4+h8iss53BCJLBeTRyWeNB4fzU= =ENly -----END PGP SIGNATURE----- --------------enig173CF9AC1FA5EF8BC25CC233-- From owner-freebsd-stable@FreeBSD.ORG Thu Jun 10 17:20:00 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FB9E106566B for ; Thu, 10 Jun 2010 17:20:00 +0000 (UTC) (envelope-from robin@icir.org) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by mx1.freebsd.org (Postfix) with ESMTP id 406478FC12 for ; Thu, 10 Jun 2010 17:20:00 +0000 (UTC) Received: from empire.icsi.berkeley.edu (empire.ICSI.Berkeley.EDU [192.150.186.169]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o5AGTKYO002270 for ; Thu, 10 Jun 2010 09:29:20 -0700 (PDT) Received: by empire.icsi.berkeley.edu (Postfix, from userid 502) id 78D6929284B; Thu, 10 Jun 2010 09:29:19 -0700 (PDT) Date: Thu, 10 Jun 2010 09:29:19 -0700 From: Robin Sommer To: freebsd-stable@freebsd.org Message-ID: <20100610162918.GA23022@icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: File system trouble with ICH9 controller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2010 17:20:00 -0000 I'm running 8.0-RELEASE-p2 (amd64) on a larger number of Supermicro SBI-7425C-T3 blades. Each of the blades has 2 x 500GB disks striped into a single volume via the on-board ICH9 RAID controller. However, after running fine for a while (days), the blades crash eventually with file system problems such as the one below. Initially I thought that must be a bad disk, but by now 5 different blades have shown similar problems so I'm suspecting some OS issue. Has anybody seen something similar before? Could this be an incompatibility with the RAID controller (I haven't found much recent on Google but there are a number of older threads indicating that it might not be well supported. Not sure though whether those still apply). Any other thoughts? Thanks, Robin --------- syslog ------------------------------------------------------- Jun 9 10:00:02 blade19 kernel: ar0s1a[WRITE(offset=704187858944, length=114688)]error = 5 Jun 9 10:00:02 blade19 kernel: g_vfs_done():ar0s1a[WRITE(offset=704188219392, length=131072)]error = 5 Jun 9 10:00:02 blade19 kernel: g_vfs_done():ar0s1a[WRITE(offset=704188891136, length=114688)]error = 5 Jun 9 10:00:02 blade19 kernel: g_vfs_done():ar0s1a[WRITE(offset=704189382656, length=114688)]error = 5 Jun 9 10:00:02 blade19 kernel: g_vfs_done():ar0s1a[WRITE(offset=704189743104, length=131072)] Jun 9 10:00:02 blade19 kernel: error = 5 --------- system information ------------------------------------------ # uname -a FreeBSD blade5 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan 5 21:11:58 UTC 2010 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # pciconf -lv | grep SATA device = '82801IB/IR/IH (ICH9 Family) SATA RAID Controller' # atacontrol list ATA channel 2: Master: ad4 SATA revision 2.x Slave: no device present ATA channel 3: Master: ad6 SATA revision 2.x Slave: no device present # dmesg | grep ata atapci0: port 0x1c50-0x1c57,0x1c44-0x1c47,0x1c48-0x1c4f,0x1c40-0x1c43,0x18e0-0x18ff mem 0xfcc00000-0xfcc007ff irq 17 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI v1.20 controller with 6 3Gbps ports, PM supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: stopping AHCI engine failed ata4: [ITHREAD] ata5: on atapci0 ata5: stopping AHCI engine failed ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: [ITHREAD] ad4: 476940MB at ata2-master SATA300 ad6: 476940MB at ata3-master SATA300 ar0: writing of DDF metadata is NOT supported yet ar0: disk0 READY using ad4 at ata2-master ar0: disk1 READY using ad6 at ata3-master -- Robin Sommer * Phone +1 (510) 666-2886 * robin@icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From owner-freebsd-stable@FreeBSD.ORG Thu Jun 10 17:42:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84FFC106566C for ; Thu, 10 Jun 2010 17:42:48 +0000 (UTC) (envelope-from robin@icir.org) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by mx1.freebsd.org (Postfix) with ESMTP id 6863D8FC08 for ; Thu, 10 Jun 2010 17:42:48 +0000 (UTC) Received: from empire.icsi.berkeley.edu (empire.ICSI.Berkeley.EDU [192.150.186.169]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o5AHgmQY014509 for ; Thu, 10 Jun 2010 10:42:48 -0700 (PDT) Received: by empire.icsi.berkeley.edu (Postfix, from userid 502) id C0C232936A8; Thu, 10 Jun 2010 10:42:47 -0700 (PDT) Date: Thu, 10 Jun 2010 10:42:47 -0700 From: Robin Sommer To: freebsd-stable@freebsd.org Message-ID: <20100610174247.GA35800@icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: File system trouble with ICH9 controller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2010 17:42:48 -0000 I'm running 8.0-RELEASE-p2 (amd64) on a larger number of Supermicro SBI-7425C-T3 blades. Each of the blades has 2 x 500GB disks striped into a single volume via the on-board ICH9 RAID controller. However, after running fine for a while (days), the blades crash eventually with file system problems such as the one below. Initially I thought that must be a bad disk, but by now 5 different blades have shown similar problems so I'm suspecting some OS issue. Has anybody seen something similar before? Could this be an incompatibility with the RAID controller (I haven't found much recent on Google but there are a number of older threads indicating that it might not be well supported. Not sure though whether those still apply). Any other thoughts? Thanks, Robin --------- syslog ------------------------------------------------------- Jun 9 10:00:02 blade19 kernel: ar0s1a[WRITE(offset=704187858944, length=114688)]error = 5 Jun 9 10:00:02 blade19 kernel: g_vfs_done():ar0s1a[WRITE(offset=704188219392, length=131072)]error = 5 Jun 9 10:00:02 blade19 kernel: g_vfs_done():ar0s1a[WRITE(offset=704188891136, length=114688)]error = 5 Jun 9 10:00:02 blade19 kernel: g_vfs_done():ar0s1a[WRITE(offset=704189382656, length=114688)]error = 5 Jun 9 10:00:02 blade19 kernel: g_vfs_done():ar0s1a[WRITE(offset=704189743104, length=131072)] Jun 9 10:00:02 blade19 kernel: error = 5 --------- system information ------------------------------------------ # uname -a FreeBSD blade5 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan 5 21:11:58 UTC 2010 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # pciconf -lv | grep SATA device = '82801IB/IR/IH (ICH9 Family) SATA RAID Controller' # atacontrol list ATA channel 2: Master: ad4 SATA revision 2.x Slave: no device present ATA channel 3: Master: ad6 SATA revision 2.x Slave: no device present # dmesg | grep ata atapci0: port 0x1c50-0x1c57,0x1c44-0x1c47,0x1c48-0x1c4f,0x1c40-0x1c43,0x18e0-0x18ff mem 0xfcc00000-0xfcc007ff irq 17 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI v1.20 controller with 6 3Gbps ports, PM supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: stopping AHCI engine failed ata4: [ITHREAD] ata5: on atapci0 ata5: stopping AHCI engine failed ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: [ITHREAD] ad4: 476940MB at ata2-master SATA300 ad6: 476940MB at ata3-master SATA300 ar0: writing of DDF metadata is NOT supported yet ar0: disk0 READY using ad4 at ata2-master ar0: disk1 READY using ad6 at ata3-master -- Robin Sommer * Phone +1 (510) 666-2886 * robin@icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From owner-freebsd-stable@FreeBSD.ORG Thu Jun 10 18:17:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C7121065673 for ; Thu, 10 Jun 2010 18:17:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 750F08FC1D for ; Thu, 10 Jun 2010 18:17:04 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta13.emeryville.ca.mail.comcast.net with comcast id UCPl1e0041GXsucADJH40s; Thu, 10 Jun 2010 18:17:04 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta07.emeryville.ca.mail.comcast.net with comcast id UJH31e00G3S48mS8UJH3Eo; Thu, 10 Jun 2010 18:17:04 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2EE9F9B418; Thu, 10 Jun 2010 11:17:03 -0700 (PDT) Date: Thu, 10 Jun 2010 11:17:03 -0700 From: Jeremy Chadwick To: Robin Sommer Message-ID: <20100610181703.GA80162@icarus.home.lan> References: <20100610162918.GA23022@icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100610162918.GA23022@icir.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: File system trouble with ICH9 controller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2010 18:17:05 -0000 On Thu, Jun 10, 2010 at 09:29:19AM -0700, Robin Sommer wrote: > I'm running 8.0-RELEASE-p2 (amd64) on a larger number of Supermicro > SBI-7425C-T3 blades. Each of the blades has 2 x 500GB disks striped > into a single volume via the on-board ICH9 RAID controller. > > However, after running fine for a while (days), the blades crash > eventually with file system problems such as the one below. > Initially I thought that must be a bad disk, but by now 5 different > blades have shown similar problems so I'm suspecting some OS issue. > > Has anybody seen something similar before? Could this be an > incompatibility with the RAID controller (I haven't found much > recent on Google but there are a number of older threads indicating > that it might not be well supported. Not sure though whether those > still apply). > > Jun 9 10:00:02 blade19 kernel: ar0s1a[WRITE(offset=704187858944, length=114688)]error = 5 > Jun 9 10:00:02 blade19 kernel: g_vfs_done():ar0s1a[WRITE(offset=704188219392, length=131072)]error = 5 > Jun 9 10:00:02 blade19 kernel: g_vfs_done():ar0s1a[WRITE(offset=704188891136, length=114688)]error = 5 > Jun 9 10:00:02 blade19 kernel: g_vfs_done():ar0s1a[WRITE(offset=704189382656, length=114688)]error = 5 > Jun 9 10:00:02 blade19 kernel: g_vfs_done():ar0s1a[WRITE(offset=704189743104, length=131072)] > Jun 9 10:00:02 blade19 kernel: error = 5 You're using Intel MatrixRAID. Please stop[1]; you're living dangerously. The messages your kernel is spitting out could indicate a lot of different things. Tracking it down will take time. So let's start wit this: 1) Provide output from "gpart show ar0s1". I'm curious about something (likely a red herring, but I want to see). 2) Install sysutils/smartmontools and run "smartctl -a /dev/adXX" on each of the disks which make up the RAID array. I believe FreeBSD can see the disks associated with the array (meaning you should have a few adXX disks, in addition to an ar0 entry). I can help you decode the output, to see if any of the disks have actual problems that indicate they could be going bad. 3) Remove use of MatrixRAID. Alternatives include ccd, gstripe, gvinum, or ZFS. I would recommend ZFS if you ran RELENG_8 instead of -RELEASE, system was amd64, and has at least 4GB RAM. Remove use of MatrixRAID first, then see if the problem goes away. 4) If the problem still happens after this, there should be developers who can help diagnose the problem. Keeping MatrixRAID out of the picture helps greatly. More details: you might consider these opinions, but they're based on personal experience (I've dealt many a time with MatrixRAID). The problem is not with the ICH9, given that most of our systems are Supermicro (not blades but that doesn't matter) and use ICH9 with AHCI (both with and without ahci.ko). Intel ICHxx and ESBx controllers are heavily tested on FreeBSD, both by users and developers. [1]: http://en.wikipedia.org/wiki/Intel_Matrix_RAID -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jun 10 20:31:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B40A106567B for ; Thu, 10 Jun 2010 20:31:14 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id ADC458FC1B for ; Thu, 10 Jun 2010 20:31:13 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.4/8.14.3) with ESMTP id o5AKVCH2016467; Thu, 10 Jun 2010 16:31:12 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201006102031.o5AKVCH2016467@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 10 Jun 2010 16:31:10 -0400 To: freebsd-stable@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: jfvogel@gmail.com Subject: RELENG_7 em problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2010 20:31:14 -0000 Hi Jack, I am seeing some issues on RELENG_7 with a specific em nic em2@pci0:13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (82573E)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) If I disable tso, I am not able to make a tcp connection into the host eg 0[psbgate1]# ifconfig em2 em2: flags=8843 metric 0 mtu 1500 options=219b ether 00:30:48:9f:eb:80 inet 192.168.128.200 netmask 0xfffffff0 broadcast 192.168.128.207 media: Ethernet autoselect (100baseTX ) status: active 0[psbgate1]# ifconfig em2 -tso 0[psbgate1]# Looking at the pcap, the checksum is bad on the syn-ack. If I re-enable tso, it seems to be ok 16:18:01.113297 IP (tos 0x10, ttl 64, id 6339, offset 0, flags [DF], proto TCP (6), length 60) 192.168.128.196.54172 > 192.168.128.200.22: S, cksum 0x4e79 (correct), 3313156149:3313156149(0) win 65535 16:18:01.123676 IP (tos 0x0, ttl 64, id 3311, offset 0, flags [DF], proto TCP (6), length 60) 192.168.128.200.22 > 192.168.128.196.54172: S, cksum 0x81c9 (incorrect (-> 0x51f2), 1373042663:1373042663(0) ack 3313156150 win 65535 em2: port 0x5000-0x501f mem 0xe8200000-0xe821ffff irq 16 at device 0.0 on pci13 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:30:48:9f:eb:80 pcib5: irq 16 at device 28.5 on pci0 pci14: on pcib5 em3: port 0x6000-0x601f mem 0xe8300000-0xe831ffff irq 17 at device 0.0 on pci14 em3: Using MSI interrupt em3: [FILTER] em3: Ethernet address: 00:30:48:9f:eb:81 Also there is still the issue with http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052842.html in RELENG_7 ? ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-stable@FreeBSD.ORG Thu Jun 10 21:06:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D85E5106566B for ; Thu, 10 Jun 2010 21:06:09 +0000 (UTC) (envelope-from robin@icir.org) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by mx1.freebsd.org (Postfix) with ESMTP id C2FC98FC12 for ; Thu, 10 Jun 2010 21:06:09 +0000 (UTC) Received: from empire.icsi.berkeley.edu (empire.ICSI.Berkeley.EDU [192.150.186.169]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id o5AL69Le012089; Thu, 10 Jun 2010 14:06:09 -0700 (PDT) Received: by empire.icsi.berkeley.edu (Postfix, from userid 502) id E1D50297733; Thu, 10 Jun 2010 14:06:08 -0700 (PDT) Date: Thu, 10 Jun 2010 14:06:08 -0700 From: Robin Sommer To: Jeremy Chadwick Message-ID: <20100610210608.GA60944@icir.org> References: <20100610162918.GA23022@icir.org> <20100610181703.GA80162@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100610181703.GA80162@icarus.home.lan> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-stable@freebsd.org Subject: Re: File system trouble with ICH9 controller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2010 21:06:09 -0000 On Thu, Jun 10, 2010 at 11:17 -0700, you wrote: > You're using Intel MatrixRAID. Please stop[1]; you're living > dangerously. Thanks for your quick response. I don't need much in terms of long-term data reliability on these machines (thus the RAID 0). However, if MatrixRAID is unreliably even without further external events (like disk problems/changes), I'll turn it off. > 1) Provide output from "gpart show ar0s1". I'm curious about something > (likely a red herring, but I want to see). # gpart show ar0s1 => 0 1952989857 ar0s1 BSD (931G) 0 1952989857 1 freebsd-ufs (931G) > 2) Install sysutils/smartmontools and run "smartctl -a /dev/adXX" on > each of the disks which make up the RAID array. See below. Thanks, Robin --------- cut ------------------------------------------------------- # smartctl -a /dev/ad4 smartctl 5.39.1 2010-01-28 r3054 [FreeBSD 8.0-RELEASE-p2 amd64] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: Seagate Momentus 5400.6 series Device Model: ST9500325AS Serial Number: 6VE3R9QW Firmware Version: 0001SDM1 User Capacity: 500,107,862,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 4 Local Time is: Thu Jun 10 12:16:49 2010 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 0) seconds. Offline data collection capabilities: (0x73) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. No Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 144) minutes. Conveyance self-test routine recommended polling time: ( 2) minutes. SCT capabilities: (0x103b) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. 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 111 099 006 Pre-fail Always - 37061718 3 Spin_Up_Time 0x0003 099 099 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 10 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 100 253 030 Pre-fail Always - 453274 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 1564 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 037 020 Old_age Always - 10 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 - 0 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 079 073 045 Old_age Always - 21 (Lifetime Min/Max 21/22) 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 1 193 Load_Cycle_Count 0x0032 075 075 000 Old_age Always - 51466 194 Temperature_Celsius 0x0022 021 040 000 Old_age Always - 21 (0 19 0 0) 195 Hardware_ECC_Recovered 0x001a 052 052 000 Old_age Always - 37061718 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 254 Free_Fall_Sensor 0x0032 100 100 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. --------- cut ------------------------------------------------------- # smartctl -a /dev/ad6 smartctl 5.39.1 2010-01-28 r3054 [FreeBSD 8.0-RELEASE-p2 amd64] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Model Family: Seagate Momentus 5400.6 series Device Model: ST9500325AS Serial Number: 6VE3SV1G Firmware Version: 0001SDM1 User Capacity: 500,107,862,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 4 Local Time is: Thu Jun 10 12:17:43 2010 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 0) seconds. Offline data collection capabilities: (0x73) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. No Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 144) minutes. Conveyance self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 144) minutes. Conveyance self-test routine recommended polling time: ( 2) minutes. SCT capabilities: (0x103b) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. 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 111 099 006 Pre-fail Always - 37297906 3 Spin_Up_Time 0x0003 099 099 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 9 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 100 253 030 Pre-fail Always - 484782 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 1598 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 037 020 Old_age Always - 9 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 - 0 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 079 074 045 Old_age Always - 21 (Lifetime Min/Max 20/21) 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 0 193 Load_Cycle_Count 0x0032 075 075 000 Old_age Always - 51868 194 Temperature_Celsius 0x0022 021 040 000 Old_age Always - 21 (0 18 0 0) 195 Hardware_ECC_Recovered 0x001a 051 050 000 Old_age Always - 37297906 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 254 Free_Fall_Sensor 0x0032 100 100 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. -- Robin Sommer * Phone +1 (510) 666-2886 * robin@icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From owner-freebsd-stable@FreeBSD.ORG Thu Jun 10 21:47:34 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8050106564A for ; Thu, 10 Jun 2010 21:47:34 +0000 (UTC) (envelope-from cptsalek@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6C63F8FC15 for ; Thu, 10 Jun 2010 21:47:34 +0000 (UTC) Received: by wyb33 with SMTP id 33so387958wyb.13 for ; Thu, 10 Jun 2010 14:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=qC6U7K7qSOxUG47bKwJdwcufKJ5kebJdwVfHPEreP+s=; b=wfwXBhWTiMa/aiWHMt8EKEpcX3PFoQ/4YZ6weUOsxXNsp4XX2WKRTIoe/wiXcNYa9Z WPzALZ0KOIyZdSmUaxw2y/EEs+pmjqZgmpywSYqwl7nswgj+nxNqq1ceVxpTeU78C6nv 4KXM19355Ve07SHm+pKH/tN/0rojiOMEj4gIg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=EfK7Jr3rh7Rj3/rRxMeF8WPcUoozfSMCqoP3wHxShcW+YGHwQKT3jJvxxD2fL+udAw 2QcGSBWrTATvmrfS8+/c6JM+grDfD2rSrflzXLEcczIDUbUD0k0OpQmW6PIiIled3mIX ZRtvseaW9+v1cbYtuyti/zaUgRncxwfT4YfzY= MIME-Version: 1.0 Received: by 10.227.69.8 with SMTP id x8mr863654wbi.105.1276206452993; Thu, 10 Jun 2010 14:47:32 -0700 (PDT) Received: by 10.216.229.24 with HTTP; Thu, 10 Jun 2010 14:47:32 -0700 (PDT) Date: Thu, 10 Jun 2010 23:47:32 +0200 Message-ID: From: Christian Walther To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Setting up X Terminals: What about audio, Pulseaudio or NAS? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2010 21:47:34 -0000 Hi, I'm currently thinking about reconfiguring my wives and my laptop as X Terminals. We're using them most of the time mostly, and my server is a Athlon X2 with 4GB RAM. The only thing I'm currently wondering about is what audio system to use. Both pulseaudio and NAS seem to be an option. Pulseaudio seems to be more widely supported, while I heard some bad things about it that indicate that the Network Audio System has been implemented more cleanly and thus is easier to setup. Has anybody used one or maybe both ports and is willing to share the experience? Regards Christian Walther From owner-freebsd-stable@FreeBSD.ORG Thu Jun 10 23:03:02 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 861D61065674 for ; Thu, 10 Jun 2010 23:03:02 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 4B46B8FC08 for ; Thu, 10 Jun 2010 23:03:02 +0000 (UTC) Received: from turtle.stack.nl (turtle.stack.nl [IPv6:2001:610:1108:5010::132]) by mx1.stack.nl (Postfix) with ESMTP id 195D435A85C; Fri, 11 Jun 2010 01:03:01 +0200 (CEST) Received: by turtle.stack.nl (Postfix, from userid 1677) id 04E4E172B6; Fri, 11 Jun 2010 01:03:01 +0200 (CEST) Date: Fri, 11 Jun 2010 01:03:00 +0200 From: Jilles Tjoelker To: Jansen Gotis Message-ID: <20100610230300.GA51804@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@FreeBSD.org Subject: Re: "calcru: runtime went backwards" messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 10 Jun 2010 23:03:02 -0000 On Fri, Jun 11, 2010 at 12:35:05AM +0800, Jansen Gotis wrote: > Hi, for the past couple of months since moving to RELENG_8 I've been > receiving "calcru: runtime went backwards" messages on the console. > My machine is a dual Pentium III 1.26GHz with an Intel SAI2 board. > Disabling EIST is not an option in my BIOS, and I've tried disabling > the ACPI timer as well as setting kern.timecounter.hardware=i8254. > I've also tried disabling cpufreq in my kernel configuration. > For what it's worth, I'm running base ntpd. I've also tried openntpd, > but no dice. > I did a binary search of the commit with which this started, and > apparently it's svn r204546, a summary of which can be seen here: > http://freshbsd.org/2010/03/02/01/56/55 > The calcru messages appear whether vesa is loaded as a module > or compiled into the kernel. > If anyone needs more information, I'll be happy to provide it. > ===== snippet of /var/log/messages relating to calcru messages ===== > Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from > 3502 usec to 3297 usec for pid 1106 (mksh) > Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from > 36785 usec to 35858 usec for pid 1114 (csh) > Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from > 13438 usec to 12652 usec for pid 1113 (su) > Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from > 14956 usec to 14081 usec for pid 1111 (mksh) > Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from > 3323 usec to 3128 usec for pid 1111 (mksh) > Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from 610 > usec to 574 usec for pid 549 (devd) > Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from 517 > usec to 486 usec for pid 548 (dhclient) > Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from > 1912 usec to 1800 usec for pid 532 (dhclient) > Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from > 39738 usec to 37412 usec for pid 532 (dhclient) > Jun 10 22:41:42 hobbes kernel: calcru: runtime went backwards from > 3369010 usec to 3334846 usec for pid 1 (init) This may well be a manifestation of a brokenness (which should not be unknown) in how FreeBSD stores CPU time utilization. The time is maintained in "CPU ticks" (CPU clock cycles), so if the clock frequency changes, the values of existing processes will be wrong (a jump when converted to seconds). When calcru detects this, it generates messages like the above. If this analysis is right, the messages can be ignored, but indicate that CPU time statistics may be inaccurate. I suppose fairly arbitrary changes can cause the messages to appear or disappear. -- Jilles Tjoelker From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 00:06:32 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E7851065676 for ; Fri, 11 Jun 2010 00:06:32 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id EF2228FC0A for ; Fri, 11 Jun 2010 00:06:31 +0000 (UTC) Received: by iwn7 with SMTP id 7so671942iwn.13 for ; Thu, 10 Jun 2010 17:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=jQ7GcDzIXv6LBsDSNfrtmO0Be6lBLZj/fUeOYwYGZg8=; b=IHn81wcuwURYMoMA0q1SJg++QkitknOWN2NCfwbuE6xbzeExPd+/ljNJhp/xaO7g+k rQFZ21ppEZ5y4PEOqEDPCu451CiEiHgGMvh/IM/AuyvHVZ3oO9gz6cY0CbHxiIX5wpgh 2r7IbxQ3UOW6gYkNT8ZKgKPF46FR9WUaUIYWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=u4zooPttF8zYgfHl6C43wRvShZMF6iFcMkoq9tLJY1HJnszcVGV0QO4B1kh4OUOZUc ik7+yIBX8Wl9zINApzWyvAUeJMpzqNfrnMTRpxOKAofkfLNVS5sRxUvsJTPJXSG4Pwjb A4BCn4y8AamBQIgDSJ1jAKnIXOZIpo++XbrxY= MIME-Version: 1.0 Received: by 10.231.167.69 with SMTP id p5mr899237iby.126.1276214791031; Thu, 10 Jun 2010 17:06:31 -0700 (PDT) Received: by 10.231.16.137 with HTTP; Thu, 10 Jun 2010 17:06:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Jun 2010 17:06:30 -0700 Message-ID: From: Freddie Cash To: stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Setting up X Terminals: What about audio, Pulseaudio or NAS? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 00:06:32 -0000 On Thu, Jun 10, 2010 at 2:47 PM, Christian Walther wrote: > I'm currently thinking about reconfiguring my wives and my laptop as X > Terminals. We're using them most of the time mostly, and my server is > a Athlon X2 with 4GB RAM. The only thing I'm currently wondering about > is what audio system to use. Both pulseaudio and NAS seem to be an > option. Pulseaudio seems to be more widely supported, while I heard > some bad things about it that indicate that the Network Audio System > has been implemented more cleanly and thus is easier to setup. > > Has anybody used one or maybe both ports and is willing to share the > experience? > How powerful are the laptops? Are they good enough to run FreeBSD + X + apps locally? Do they have at least 1 GB of RAM? If they have fast enough CPUs and enough RAM to run things locally, then look into diskless booting via PXE instead of thin-client setups. You get all the benefits of thin-clients (central management as everything is on the server, the benefits of having nothing installed locally so no moving parts, etc) ... along with the power of running apps locally, and minimising the network load (only time network is used is to boot, and to load apps). This also allows for accelerated 3D and easy sound configuration. If they aren't fast enough to support X locally, then you'll need to use thin-client / X terminal setups. NAS was created for just this purpose. It works in virtually the same way that X works across a network. Definitely look into NAS first. Only if that fails, should you go down the dark, twisted path of PulseAudio. :) We (School District 73 Kamloops/Thompson in BC, Canada) started out using thin-client setups with P2 333 Mhz clients with 256 MB of RAM. Worked well as a base to start from, but we quickly ran into issues with online Flash games, 3D accelerated programs like Blender and CAD apps, full-motion video, educational games like TuxMath, TuxMath, TenThumbs Typing Tutor, etc. Within 3 years, we had started a migration to diskless setup with apps running locally. We now run strictly diskless, even on teacher, office, and admin desktops. :) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 06:03:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB5591065676 for ; Fri, 11 Jun 2010 06:03:09 +0000 (UTC) (envelope-from jtgotis@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id B22898FC1A for ; Fri, 11 Jun 2010 06:03:09 +0000 (UTC) Received: by pvb32 with SMTP id 32so430955pvb.13 for ; Thu, 10 Jun 2010 23:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=mPWSU/4tKOJXE7a93K+5gusGdIfy54dtmCXaggbzLkA=; b=oG5qAodJzpY26MDHwXMlKao7eFj9eSLEBAJiP6uutP8HVbp+ZQ/aBqumDtmpMs9tUg SfdeVaFvsdQoB3EbgeDxLC+bXa3JpgLoBja5yEilumr0TtVbvhgV0+PYnRuVofI/pXE9 Xnx0xgjzsot/oljHXd0bt/RmQ5HvhTCCazWZ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=pVCfd7mv8bfT0WJrF+VF6WADXW+kNoVnG3lTCM/4eU7yB9TFJgo77EwsTJlYTuwSWv q8s7rzMhq/uyBdAT42mq/ipnty97Ji+EJTm07vHAvMJpJupCSEpsn2pwLsVZoRlijfg6 Ogmp7VOovOKCBNawXf1J4pnbSop7D8K9O8BNE= MIME-Version: 1.0 Received: by 10.142.56.8 with SMTP id e8mr929606wfa.117.1276236189095; Thu, 10 Jun 2010 23:03:09 -0700 (PDT) Received: by 10.143.168.14 with HTTP; Thu, 10 Jun 2010 23:03:08 -0700 (PDT) In-Reply-To: <20100610230300.GA51804@stack.nl> References: <20100610230300.GA51804@stack.nl> Date: Fri, 11 Jun 2010 14:03:08 +0800 Message-ID: From: Jansen Gotis To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: "calcru: runtime went backwards" messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 06:03:09 -0000 On Fri, Jun 11, 2010 at 7:03 AM, Jilles Tjoelker wrote: > On Fri, Jun 11, 2010 at 12:35:05AM +0800, Jansen Gotis wrote: >> Hi, for the past couple of months since moving to RELENG_8 I've been >> receiving "calcru: runtime went backwards" messages on the console. > > > This may well be a manifestation of a brokenness (which should not be > unknown) in how FreeBSD stores CPU time utilization. The time is > maintained in "CPU ticks" (CPU clock cycles), so if the clock frequency > changes, the values of existing processes will be wrong (a jump when > converted to seconds). When calcru detects this, it generates messages > like the above. If this analysis is right, the messages can be ignored, > but indicate that CPU time statistics may be inaccurate. > You're probably right, the messages can be ignored. I don't see any issues other than the messages being printed on the console; I don't experience freezing, etc. It just struck me as weird because searching the -current and -stable mailing lists does not show anyone else having the issue as recently as I have. Just some more info to add which I forgot about last time...setting kern.hz to 100 did not help. Thanks for the reply. Best regards, Jansen From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 08:36:03 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12680106566C for ; Fri, 11 Jun 2010 08:36:03 +0000 (UTC) (envelope-from sdupille@nospam.fr.eu.org) Received: from mail.nospam.fr.eu.org (galadriel.nospam.fr.eu.org [88.191.16.109]) by mx1.freebsd.org (Postfix) with ESMTP id CC56C8FC15 for ; Fri, 11 Jun 2010 08:36:02 +0000 (UTC) Received: from galadriel.nospam.fr.eu.org (localhost [127.0.0.1]) (Authenticated sender: dust) by mail.nospam.fr.eu.org (Postfix) with ESMTP id C7031440817 for ; Fri, 11 Jun 2010 10:36:00 +0200 (CEST) From: Stephane Dupille To: stable@freebsd.org References: <4C0FD8A2.3070307@yandex.ru> <4C111D5D.3030006@yandex.ru> Organization: Home Mail-copies-to: never Date: Fri, 11 Jun 2010 10:36:00 +0200 In-Reply-To: <4C111D5D.3030006@yandex.ru> (Andrey V. Elsukov's message of "Thu, 10 Jun 2010 21:14:05 +0400") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit Cc: Subject: Re: Resizing GPT partitions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 08:36:03 -0000 "Andrey V. Elsukov" écrit : > I have plan to add `gpart recover` feature in near future. I've seen that. It seems to me that's a good idea. > It needs in kernel support too. You can try to download snapshot > of livefs CD of 9.0-CURRENT and use it. > http://pub.allbsd.org/FreeBSD-snapshots/ Well, it's becoming too complicated for me. I'll try another approach : installaing the system in the swap partition, boot on that, make the other partition, install the system, boot on the right partition, delete the first one and use it as a real swap. Thanks for your help ! regards, SD From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 08:48:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F4B21065678 for ; Fri, 11 Jun 2010 08:48:28 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by mx1.freebsd.org (Postfix) with ESMTP id E1CB68FC18 for ; Fri, 11 Jun 2010 08:48:27 +0000 (UTC) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id o5B8mQaG036806 for ; Fri, 11 Jun 2010 10:48:26 +0200 (CEST) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 11 Jun 2010 10:48:25 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA57A86@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.1 AMD64 Beta1 cd panics on Proliant ML110 G6 Thread-Index: AcsJQtq230XIsHlMQ1ODNL//iMLxmw== From: "Johan Hendriks" To: X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 8.1 AMD64 Beta1 cd panics on Proliant ML110 G6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 08:48:28 -0000 Hello all. I try to install the Beta of 8.1 but it panics on my server HP Proliant ML110 with the following. =20 SMP: AP CPU #1 Launched! =20 Fatal trap 12: page fault while in kernel mode =20 cpuid =3D 1; apic id =3D 04 fault virtual address =3D 0x290 fault code =3D supervisor read data, = page not present instuction pointer =3D 0x20:0xffffffff805b03f6 stack pointer =3D 0x28:0xffffff80001cebe0 frame pointer =3D 0x28:0xffffff80001cec00 code segment =3D base 0x0x, limit = 0xfffff, type 0x1b =3DDPL 0, pres 1, long1,de32 0, gran 1 proccessor eflags =3Dinterupt enabled, resume,IOPL =3D 0 current process =3D 19 (flowcleaner) trap number =3D 12 panic: page fault cpuid =3D 1=20 =20 Uptime 3s =20 Regards, Johan Hendriks From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 09:26:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09D7F106564A for ; Fri, 11 Jun 2010 09:26:36 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 45CDF8FC08 for ; Fri, 11 Jun 2010 09:26:34 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA05572; Fri, 11 Jun 2010 12:26:30 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ON0VR-000NCi-Q9; Fri, 11 Jun 2010 12:26:29 +0300 Message-ID: <4C120144.80002@icyb.net.ua> Date: Fri, 11 Jun 2010 12:26:28 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Johan Hendriks References: <57200BF94E69E54880C9BB1AF714BBCBA57A86@w2003s01.double-l.local> In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBA57A86@w2003s01.double-l.local> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 8.1 AMD64 Beta1 cd panics on Proliant ML110 G6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 09:26:36 -0000 on 11/06/2010 11:48 Johan Hendriks said the following: > Hello all. > > I try to install the Beta of 8.1 but it panics on my server HP Proliant ML110 > with the following. > > > > > > > SMP: AP CPU #1 Launched! > > > > Fatal trap 12: page fault while in kernel mode > > > > cpuid = 1; apic id = 04 > > fault virtual address = 0x290 > > fault code = supervisor read data, page not > present > > instuction pointer = 0x20:0xffffffff805b03f6 > > stack pointer = 0x28:0xffffff80001cebe0 > > frame pointer = 0x28:0xffffff80001cec00 > > code segment = base 0x0x, limit 0xfffff, type > 0x1b > > =DPL 0, pres 1, long1,de32 0, gran 1 > > proccessor eflags =interupt enabled, resume,IOPL = > 0 > > current process = 19 (flowcleaner) > > trap number = 12 > > panic: page fault > > cpuid = 1 Stacktrace would be helpful. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 09:51:03 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60B94106568F for ; Fri, 11 Jun 2010 09:51:03 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id ABD9D8FC29 for ; Fri, 11 Jun 2010 09:51:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.4/8.14.4) with ESMTP id o5B9oxMM036588 for ; Fri, 11 Jun 2010 13:50:59 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 11 Jun 2010 13:50:59 +0400 (MSD) From: Dmitry Morozovsky To: freebsd-stable@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.5 (woozle.rinet.ru [0.0.0.0]); Fri, 11 Jun 2010 13:51:00 +0400 (MSD) Cc: Subject: same addresses on different interfaces X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 09:51:03 -0000 Dear colleagues, is it OK that no warnings are given when one set the very same address on different interfaces? Example (tested on stable/7 and stable/8): Script started on Fri Jun 11 13:44:08 2010 hamster# ifconfig vlan8 create vlan 8 vlandev em0 hamster# ifconfig vlan8 10.5.5.9/30 hamster# netstat -rn | grep '10\.5' 10.5.5.8/30 link#3 U 0 0 vlan8 10.5.5.9 link#3 UHS 0 0 lo0 hamster# ifconfig vlan9 create vlan 9 vlandev em0 hamster# ifconfig vlan9 10.5.5.9/30 hamster# netstat -rn | grep '10\.5' 10.5.5.8/30 link#3 U 0 0 vlan8 10.5.5.9 link#3 UHS 1 0 lo0 hamster# exit Script done on Fri Jun 11 13:46:24 2010 Thanks. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 09:55:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 873921065676 for ; Fri, 11 Jun 2010 09:55:47 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by mx1.freebsd.org (Postfix) with ESMTP id 1D5B28FC1D for ; Fri, 11 Jun 2010 09:55:46 +0000 (UTC) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id o5B9tigX096488; Fri, 11 Jun 2010 11:55:45 +0200 (CEST) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Jun 2010 11:55:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA57A90@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.1 AMD64 Beta1 cd panics on Proliant ML110 G6 Thread-Index: AcsJSOUkJ8MIdoSdTryPffB3yuPgbAAAt7FA References: <57200BF94E69E54880C9BB1AF714BBCBA57A86@w2003s01.double-l.local> <4C120144.80002@icyb.net.ua> From: "Johan Hendriks" To: "Andriy Gapon" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org Subject: RE: 8.1 AMD64 Beta1 cd panics on Proliant ML110 G6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 09:55:47 -0000 >> Hello all. >>=20 >> I try to install the Beta of 8.1 but it panics on my server HP Proliant ML110 >> with the following. >> >> SMP: AP CPU #1 Launched! >> >> Fatal trap 12: page fault while in kernel mode >> >> cpuid =3D 1; apic id =3D 04 >>=20 >> fault virtual address =3D 0x290 >>=20 >> fault code =3D supervisor read data, page not >> present >>=20 >> instuction pointer =3D = 0x20:0xffffffff805b03f6 >>=20 >> stack pointer =3D = 0x28:0xffffff80001cebe0 >> >> frame pointer =3D = 0x28:0xffffff80001cec00 >>=20 >> code segment =3D base 0x0x, limit 0xfffff, type >> 0x1b >>=20 >> =3DDPL 0, pres 1, long1,de32 0, gran 1 >> >> proccessor eflags =3Dinterupt enabled, resume,IOPL =3D >> 0 >>=20 >> current process =3D 19 (flowcleaner) >>=20 >> trap number =3D 12 >>=20 >> panic: page fault >>=20 >> cpuid =3D 1 >Stacktrace would be helpful. Well at startup, the keyboard is not working, i can not select any boot mode, and after the timer is at 0 ti boots, and then ends with this panic, and totally hangs. 8.0 works fine also CURRENT Works! Regards, Johan Hendriks From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 10:27:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 987431065674; Fri, 11 Jun 2010 10:27:53 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 40C988FC1A; Fri, 11 Jun 2010 10:27:50 +0000 (UTC) Received: by fxm7 with SMTP id 7so670046fxm.13 for ; Fri, 11 Jun 2010 03:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=6K+1sJ5xK+VTOXOVSMd0CsyZossbAzd+Uz0N0VZa6wg=; b=orpJ0U+MYmzRwLdzCL8xoWQNk3uyff1C/+snG1cOV4Zul9VcNMrHvhNXzP/ql9eaxl MGoWE3S4I2NE3FyIaWAQmDt3QVbb7fyZ+9Qknvc77zKEEW4EhhXdcIKOLqR8DtyKChcj 8KPK9erEPh7q2rEHLtD/DFYQ9VVFCUxqTjick= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PPbTEMeg9p7eW5J0VqI92P9wSmnvMqR1LAnBydp3Ygp7Wc0+UrFVqaPj5/FR2oJCm9 s3GV6xrd7CmwwkTy0/c0yL7BpAweon4IS6zfLas/L1Ru7mt24hFwB0LEeUCwxEAoUUbe QWXoBJwIlGCvyEoGd/cfnaoSa5gu8sDUmfEP4= MIME-Version: 1.0 Received: by 10.223.24.130 with SMTP id v2mr1599149fab.61.1276252068955; Fri, 11 Jun 2010 03:27:48 -0700 (PDT) Received: by 10.223.103.209 with HTTP; Fri, 11 Jun 2010 03:27:48 -0700 (PDT) In-Reply-To: References: <20100503224206.GB9134@icarus.home.lan> <20100504083738.GA23820@icarus.home.lan> <20100504085332.GA24219@icarus.home.lan> Date: Fri, 11 Jun 2010 12:27:48 +0200 Message-ID: From: Giovanni Trematerra To: freebsd-stable , John Baldwin , kib@freebsd.org, jkim@freebsd.org, avg@freebsd.org Content-Type: multipart/mixed; boundary=00151747357036c86b0488be97bd Cc: David DEMELIER , Brandon Gooch , Rui Paulo , Attilio Rao Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 10:27:53 -0000 --00151747357036c86b0488be97bd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 10, 2010 at 10:58 PM, Giovanni Trematerra wrote: > On Tue, May 4, 2010 at 6:35 PM, David DEMELIER = wrote: >> Good news ! It worked, check the picture here : >> >> http://img63.imageshack.us/img63/4244/dsc00361g.jpg >> > > Into the file sys/dev/acpica/acpi_cpu.c at the end of acpi_cpu_notify > (a per cpu notification handler), called when _CST objects changing, > global cpu_cx_count is set to the greatest value of all sc->cpu_cx_count > per-cpu variables. That could result in a panic as David reported, > because that lets to invoke acpi_cpu_global_cx_lowest_sysctl from > /etc/rc.d/power_profile, when AC adapter is unplugged, =A0with a value > that not all the CPUs could handle in the acpi_cpu_idle. > The patch also change global cpu_cx_lowest according to new value of > global cpu_cx_count if needed. > > David Demelier made a great work to test every patch I sent him > to identify the source of the problem. > > Please, let me know your comments and possibly commit the patch > if you think is good enough. As jhb@ pointed me out in private with the previous patch a CPU could never enter in the lowest Cx-state even if it gained. So I'd like to propose this new solution. When hw.acpi.cpu.cx_lowest sysctl is set, the global handler in sys/dev/acpi_cpu.c will set the greatest sc->cpu_cx_lowest value supported by the CPU and not the same value for all CPUs. Later, when CPU, possibly gain new Cx-states, the acpi_cpu_notify handler will set sc->cpu_cx_lowest accordingly with global cx_lowest and the Cx-states supported by the CPU. Now I think that /etc/rc.d/power_profile script has a problem but that is a different story. The script select the lowest_value only querying cx-states of the dev.cpu.0= . If different CPUs may have different Cx-states, the script should use as lowest_value the lowest value between all the CPUs. Please, let me know your comments and possibly commit the patch if you think is good enough. -- Gianni --00151747357036c86b0488be97bd Content-Type: text/plain; charset=US-ASCII; name="acpi_cpu_notify4.diff.txt" Content-Disposition: attachment; filename="acpi_cpu_notify4.diff.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gaauzzri1 ZGlmZiAtciBhYzk1YTczZDM1OGQgc3lzL2Rldi9hY3BpY2EvYWNwaV9jcHUuYwotLS0gYS9zeXMv ZGV2L2FjcGljYS9hY3BpX2NwdS5jCVR1ZSBNYXkgMTggMDg6MTM6NDAgMjAxMCAtMDQwMAorKysg Yi9zeXMvZGV2L2FjcGljYS9hY3BpX2NwdS5jCUZyaSBKdW4gMTEgMDM6MTA6MzcgMjAxMCAtMDQw MApAQCAtMTAwOSw2ICsxMDA5LDggQEAgYWNwaV9jcHVfbm90aWZ5KEFDUElfSEFORExFIGgsIFVJ TlQzMiBubwogCWlmIChpc2MtPmNwdV9jeF9jb3VudCA+IGNwdV9jeF9jb3VudCkKIAkgICAgY3B1 X2N4X2NvdW50ID0gaXNjLT5jcHVfY3hfY291bnQ7CiAgICAgfQorICAgIGlmIChzYy0+Y3B1X2N4 X2xvd2VzdCA8IGNwdV9jeF9sb3dlc3QpCisJYWNwaV9jcHVfc2V0X2N4X2xvd2VzdChzYywgbWlu KGNwdV9jeF9sb3dlc3QsIHNjLT5jcHVfY3hfY291bnQgLSAxKSk7CiAgICAgQUNQSV9TRVJJQUxf RU5EKGNwdSk7CiB9CiAKQEAgLTEyMDQsNyArMTIwNiw3IEBAIGFjcGlfY3B1X2dsb2JhbF9jeF9s b3dlc3Rfc3lzY3RsKFNZU0NUTF8KICAgICBBQ1BJX1NFUklBTF9CRUdJTihjcHUpOwogICAgIGZv ciAoaSA9IDA7IGkgPCBjcHVfbmRldmljZXM7IGkrKykgewogCXNjID0gZGV2aWNlX2dldF9zb2Z0 YyhjcHVfZGV2aWNlc1tpXSk7Ci0JYWNwaV9jcHVfc2V0X2N4X2xvd2VzdChzYywgdmFsKTsKKwlh Y3BpX2NwdV9zZXRfY3hfbG93ZXN0KHNjLCBtaW4odmFsLCBzYy0+Y3B1X2N4X2NvdW50IC0gMSkp OwogICAgIH0KICAgICBBQ1BJX1NFUklBTF9FTkQoY3B1KTsKIAo= --00151747357036c86b0488be97bd-- From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 12:25:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10158106567D; Fri, 11 Jun 2010 12:25: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 CF27C8FC0C; Fri, 11 Jun 2010 12:25:09 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7EA1D46C2F; Fri, 11 Jun 2010 08:25:09 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 998938A04F; Fri, 11 Jun 2010 08:25:08 -0400 (EDT) From: John Baldwin To: Giovanni Trematerra Date: Fri, 11 Jun 2010 08:18:27 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201006110818.27366.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 11 Jun 2010 08:25:08 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.8 required=4.2 tests=AWL,BAYES_00,URIBL_SBL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable , David DEMELIER , avg@freebsd.org, Attilio Rao , Brandon Gooch , kib@freebsd.org, Rui Paulo , jkim@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 12:25:10 -0000 On Friday 11 June 2010 6:27:48 am Giovanni Trematerra wrote: > On Thu, Jun 10, 2010 at 10:58 PM, Giovanni Trematerra > wrote: > > On Tue, May 4, 2010 at 6:35 PM, David DEMELIER wrote: > >> Good news ! It worked, check the picture here : > >> > >> http://img63.imageshack.us/img63/4244/dsc00361g.jpg > >> > > > > Into the file sys/dev/acpica/acpi_cpu.c at the end of acpi_cpu_notify > > (a per cpu notification handler), called when _CST objects changing, > > global cpu_cx_count is set to the greatest value of all sc->cpu_cx_count > > per-cpu variables. That could result in a panic as David reported, > > because that lets to invoke acpi_cpu_global_cx_lowest_sysctl from > > /etc/rc.d/power_profile, when AC adapter is unplugged, with a value > > that not all the CPUs could handle in the acpi_cpu_idle. > > The patch also change global cpu_cx_lowest according to new value of > > global cpu_cx_count if needed. > > > > David Demelier made a great work to test every patch I sent him > > to identify the source of the problem. > > > > Please, let me know your comments and possibly commit the patch > > if you think is good enough. > > As jhb@ pointed me out in private with the previous patch a CPU could > never enter in the > lowest Cx-state even if it gained. > So I'd like to propose this new solution. > When hw.acpi.cpu.cx_lowest sysctl is set, the global handler in > sys/dev/acpi_cpu.c > will set the greatest sc->cpu_cx_lowest value supported by the CPU and > not the same > value for all CPUs. > Later, when CPU, possibly gain new Cx-states, the acpi_cpu_notify > handler will set > sc->cpu_cx_lowest accordingly with global cx_lowest and the Cx-states > supported by > the CPU. > > Now I think that /etc/rc.d/power_profile script has a problem but that > is a different story. > The script select the lowest_value only querying cx-states of the dev.cpu.0. > If different CPUs may have different Cx-states, the script should use > as lowest_value the > lowest value between all the CPUs. Yes. > Please, let me know your comments and possibly commit the patch > if you think is good enough. I think this is a good compromise for now. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 13:45:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A56461065670 for ; Fri, 11 Jun 2010 13:45:58 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id 8AC3E8FC17 for ; Fri, 11 Jun 2010 13:45:57 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta14.emeryville.ca.mail.comcast.net with comcast id Udke1e0050lTkoCAEdlxfZ; Fri, 11 Jun 2010 13:45:57 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta04.emeryville.ca.mail.comcast.net with comcast id Udlw1e0013S48mS8QdlwLr; Fri, 11 Jun 2010 13:45:57 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D17229B418; Fri, 11 Jun 2010 06:45:55 -0700 (PDT) Date: Fri, 11 Jun 2010 06:45:55 -0700 From: Jeremy Chadwick To: Johan Hendriks Message-ID: <20100611134555.GA9682@icarus.home.lan> References: <57200BF94E69E54880C9BB1AF714BBCBA57A86@w2003s01.double-l.local> <4C120144.80002@icyb.net.ua> <57200BF94E69E54880C9BB1AF714BBCBA57A90@w2003s01.double-l.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBA57A90@w2003s01.double-l.local> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: 8.1 AMD64 Beta1 cd panics on Proliant ML110 G6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 13:45:58 -0000 On Fri, Jun 11, 2010 at 11:55:42AM +0200, Johan Hendriks wrote: > >> Hello all. > >> > >> I try to install the Beta of 8.1 but it panics on my server HP > Proliant ML110 > >> with the following. > >> > >> SMP: AP CPU #1 Launched! > >> > >> Fatal trap 12: page fault while in kernel mode > >> > >> cpuid = 1; apic id = 04 > >> > >> fault virtual address = 0x290 > >> > >> fault code = supervisor read data, > page not > >> present > >> > >> instuction pointer = 0x20:0xffffffff805b03f6 > >> > >> stack pointer = 0x28:0xffffff80001cebe0 > >> > >> frame pointer = 0x28:0xffffff80001cec00 > >> > >> code segment = base 0x0x, limit > 0xfffff, type > >> 0x1b > >> > >> =DPL 0, pres 1, long1,de32 0, gran 1 > >> > >> proccessor eflags =interupt enabled, > resume,IOPL = > >> 0 > >> > >> current process = 19 (flowcleaner) > >> > >> trap number = 12 > >> > >> panic: page fault > >> > >> cpuid = 1 > > >Stacktrace would be helpful. > > Well at startup, the keyboard is not working, i can not select any boot > mode, and after the timer is at 0 ti boots, and then ends with this > panic, and totally hangs. > 8.0 works fine also CURRENT Works! Regarding the keyboard not working -- it should still be working during the loader phase (FreeBSD logo, press 4 for single user, etc.), correct? If so, two things to try. Escape to the loader prompt and try one of the below (if (a) doesn't work, try (b)): a) set hint.kbdmux.0.disabled=1 boot b) set hint.atkbd.0.disabled=1 set hint.atkbdc.0.disabled=1 boot Hopefully one of these will allow your keyboard to continue functioning once the system panics, so that you can provide a backtrace. Thanks. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 13:51:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E243D106564A for ; Fri, 11 Jun 2010 13:51:32 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 99EDC8FC28 for ; Fri, 11 Jun 2010 13:51:32 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1ON4dv-0002BZ-51 for freebsd-stable@freebsd.org; Fri, 11 Jun 2010 15:51:31 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Jun 2010 15:51:31 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Jun 2010 15:51:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org connect(): No such file or directory From: Ivan Voras Date: Fri, 11 Jun 2010 15:51:21 +0200 Lines: 8 Message-ID: References: <57200BF94E69E54880C9BB1AF714BBCBA57A86@w2003s01.double-l.local> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBA57A86@w2003s01.double-l.local> X-Enigmail-Version: 1.0.1 Subject: Re: 8.1 AMD64 Beta1 cd panics on Proliant ML110 G6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 13:51:33 -0000 On 06/11/10 10:48, Johan Hendriks wrote: > Hello all. > > I try to install the Beta of 8.1 but it panics on my server HP Proliant > ML110 with the following. Just as a data-point: I've tested 8.1 on HP DL380 G6 (i.e. same generation, different series) and there were no problems. From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 14:07:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEF561065673 for ; Fri, 11 Jun 2010 14:07:01 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4B2228FC1D for ; Fri, 11 Jun 2010 14:07:00 +0000 (UTC) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id o5BE6wpS015295; Fri, 11 Jun 2010 16:06:59 +0200 (CEST) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 11 Jun 2010 16:11:48 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB0111C2@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.1 AMD64 Beta1 cd panics on Proliant ML110 G6 Thread-Index: AcsJbSE3IyxVkPzbROm/x/qpInUsEwAAETgc References: <57200BF94E69E54880C9BB1AF714BBCBA57A86@w2003s01.double-l.local> <4C120144.80002@icyb.net.ua> <57200BF94E69E54880C9BB1AF714BBCBA57A90@w2003s01.double-l.local> <20100611134555.GA9682@icarus.home.lan> From: "Johan Hendriks" To: "Jeremy Chadwick" , X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: RE: 8.1 AMD64 Beta1 cd panics on Proliant ML110 G6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 14:07:01 -0000 >> >> Hello all. >> >>=20 >> >> I try to install the Beta of 8.1 but it panics on my server HP >> Proliant ML110 >>=20 >>>Stacktrace would be helpful. >>=20 >> Well at startup, the keyboard is not working, i can not select any = boot >> mode, and after the timer is at 0 ti boots, and then ends with this >> panic, and totally hangs. >> 8.0 works fine also CURRENT Works! >Regarding the keyboard not working -- it should still be working during >the loader phase (FreeBSD logo, press 4 for single user, etc.), = correct? >If so, two things to try. Escape to the loader prompt and try one of >the below (if (a) doesn't work, try (b)): >a) set hint.kbdmux.0.disabled=3D1 > boot >b) set hint.atkbd.0.disabled=3D1 > set hint.atkbdc.0.disabled=3D1 > boot >Hopefully one of these will allow your keyboard to continue functioning >once the system panics, so that you can provide a backtrace. Thanks. > >--=20 >| Jeremy Chadwick jdc@parodius.com | >| Parodius Networking http://www.parodius.com/ | >| UNIX Systems Administrator Mountain View, CA, USA | >| Making life hard for others since 1977. PGP: 4BD6C0CB | The problem is the keyboard is not working at all, so i need to wait = till the counter reach 0. I did also installed 8.0, no problem. Then did a buildworld to the latest 8.1 source from 2010-06-08, = buildworld runs fine, then after the reboot same issue as the = BETA1-install-only iso. regards, Johan Hendriks From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 14:12:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68BC7106564A for ; Fri, 11 Jun 2010 14:12:56 +0000 (UTC) (envelope-from flo@smeets.im) Received: from mail.solomo.de (mail.solomo.de [IPv6:2a01:238:43fa:7100::2]) by mx1.freebsd.org (Postfix) with ESMTP id E5F448FC08 for ; Fri, 11 Jun 2010 14:12:55 +0000 (UTC) Received: from mail.solomo.de (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 120FC61C5C; Fri, 11 Jun 2010 16:12:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at vistream.de Received: from mail.solomo.de ([127.0.0.1]) by mail.solomo.de (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0whmZUNdPKpV; Fri, 11 Jun 2010 16:12:51 +0200 (CEST) Received: from nibbler.vistream.local (relay3.vistream.de [87.139.10.28]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id 962E661C5B; Fri, 11 Jun 2010 16:12:51 +0200 (CEST) Message-ID: <4C124462.30408@smeets.im> Date: Fri, 11 Jun 2010 16:12:50 +0200 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Yoshiaki Kasahara References: <4BE110E3.8040902@zirakzigil.org> <4BE82C5D.1080806@bit0.com> <20100608.181146.1224841629154014733.kasahara@nc.kyushu-u.ac.jp> In-Reply-To: <20100608.181146.1224841629154014733.kasahara@nc.kyushu-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Freebsd 8.0 kmem map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 14:12:56 -0000 On 6/8/10 11:11 AM, Yoshiaki Kasahara wrote: > Hello, > > I'd like to add another instance of similar problems. I recently > updated my FreeBSD amd64 box with ZFS root and 8GB RAM from 8-STABLE > (as of Mar 1st) to 8.1-PRERELEASE (as of May 27th). After that, my > box started to crash every couple of days due to kmem_map too small. > > Here is a (last week) screenshot of Munin graph about the memory usage > of the box: > > http://eron.info/munin-memory.png > > In "by month" graph, a white gap at the end of "Week 20" is the update > period from 8-STABLE to 8.1-PRERELEASE I mentioned above. Before the > upgrade, the system was rock solid without any kmem tuning in > loader.conf (vm.kmem_size was around 2.7GB IIRC). > > After the update, I could see that more wired memory was assigned, and > then steep drop (crash) occured. > > "by day" graph shows my experiment to bump vm.kmem_size=12G > (recommended somewhere in this thread) and explicitly limit > vfs.zfs.arc_max=2G. I was surprised because the wired memory quickly > increased over 5GB... > > Then I noticed that the default value of vfs.zfs.zio.use_uma was 1 on > amd64, so I turned it off and removed other memory tunings (kmem_size > and arc_max) in loader.conf on Tuesday at 16:00 and rebooted. It > seems that the usage of wired memory was stablized and no crash since > then with the default kmem_size and arc_max. > > Does anyone have any idea about this behavior? > > My wild guess is that ZFS/UMA code is not stable on amd64 too, and it > should be turned off by default for 8.1-RELEASE maybe.... > I can confirm this. I just upgraded a system from late January to yesterdays 8-STABLE. I had to set vfs.zfs.zio.use_uma="0", to get the system survive buildworld again. This is amd64 with only 1GB, (i know this is considered not enough for ZFS) with the kernel from January it was stable without any tuning. After disabling ZFSs UMA usage, it seems to be working fine again. Just another data point. Cheers, Florian From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 14:36:45 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72AA6106568D for ; Fri, 11 Jun 2010 14:36:45 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by mx1.freebsd.org (Postfix) with ESMTP id 8401F8FC2F for ; Fri, 11 Jun 2010 14:36:44 +0000 (UTC) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id o5BEagig031028 for ; Fri, 11 Jun 2010 16:36:42 +0200 (CEST) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 11 Jun 2010 16:41:32 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB0111C3@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.1 AMD64 Beta1 cd panics on Proliant ML110 G6 Thread-Index: AcsJbSE3IyxVkPzbROm/x/qpInUsEwAAETgcAAF0Bn0= References: <57200BF94E69E54880C9BB1AF714BBCBA57A86@w2003s01.double-l.local> <4C120144.80002@icyb.net.ua> <57200BF94E69E54880C9BB1AF714BBCBA57A90@w2003s01.double-l.local> <20100611134555.GA9682@icarus.home.lan> <57200BF94E69E54880C9BB1AF714BBCB0111C2@w2003s01.double-l.local> From: "Johan Hendriks" To: X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FW: 8.1 AMD64 Beta1 cd panics on Proliant ML110 G6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 14:36:45 -0000 >> >> Hello all. >> >>=20 >> >> I try to install the Beta of 8.1 but it panics on my server HP >> Proliant ML110 >>=20 >>>Stacktrace would be helpful. >>=20 >> Well at startup, the keyboard is not working, i can not select any = boot >> mode, and after the timer is at 0 ti boots, and then ends with this >> panic, and totally hangs. >> 8.0 works fine also CURRENT Works! >Regarding the keyboard not working -- it should still be working during >the loader phase (FreeBSD logo, press 4 for single user, etc.), = correct? >If so, two things to try. Escape to the loader prompt and try one of >the below (if (a) doesn't work, try (b)): >a) set hint.kbdmux.0.disabled=3D1 > boot >b) set hint.atkbd.0.disabled=3D1 > set hint.atkbdc.0.disabled=3D1 > boot >Hopefully one of these will allow your keyboard to continue functioning >once the system panics, so that you can provide a backtrace. Thanks. > Little update, also 9-CURRENT build today is not able to use the = keyboard at startup, but it boots normal, and after the boot the system = works normal. I did do pciconf and dmesg on the machine from 9-CURRENT. DMESG Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #0: Fri Jun 11 14:34:42 CEST 2010 root@hast-master.double-l.local:/usr/obj/usr/src/sys/KRNL amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) CPU G6950 @ 2.80GHz (3189.54-MHz = K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x20652 Family =3D 6 Model =3D 25 = Stepping =3D 2 = Features=3D0xbfebfbff = Features2=3D0x80e3bd AMD Features=3D0x28100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 2147483648 (2048 MB) avail memory =3D 2047291392 (1952 MB) 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: 4 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 ehci0: mem 0xdfd01800-0xdfd01bff = irq 16 at device 26.0 on pci0 ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: on ehci0 pcib2: irq 17 at device 28.0 on pci0 pci16: on pcib2 pcib3: irq 16 at device 28.1 on pci0 pci26: on pcib3 pcib4: irq 18 at device 28.2 on pci0 pci28: on pcib4 vgapci0: mem = 0xde000000-0xdeffffff,0xdf800000-0xdf803fff,0xdf000000-0xdf7fffff irq 18 = at device 0.0 on pci28 pcib5: irq 19 at device 28.3 on pci0 pci30: on pcib5 bge0: mem = 0xdf900000-0xdf90ffff irq 19 at device 0.0 on pci30 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, = 1000baseT-FDX, auto bge0: Ethernet address: 78:e7:d1:bd:ad:0e bge0: [FILTER] pcib6: irq 17 at device 28.4 on pci0 pci32: on pcib6 ehci1: mem 0xdfd01c00-0xdfd01fff = irq 23 at device 29.0 on pci0 ehci1: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci1 pcib7: at device 30.0 on pci0 pci48: on pcib7 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x2000-0x207f mem = 0xdfa00000-0xdfa0007f irq 17 at device 0.0 on pci48 miibus1: on xl0 ukphy0: PHY 24 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:04:75:fb:e2:37 xl0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port = 0x1830-0x1837,0x1824-0x1827,0x1828-0x182f,0x1820-0x1823,0x1810-0x181f,0x1= 800-0x180f irq 18 at device 31.2 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port = 0x1888-0x188f,0x183c-0x183f,0x1880-0x1887,0x1838-0x183b,0x1870-0x187f,0x1= 860-0x186f irq 17 at device 31.5 on pci0 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] acpi_button0: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff irq = 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 atrtc0: port 0x70-0x71 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] orm0: at iomem = 0xc0000-0xc7fff,0xca000-0xcafff,0xcb000-0xcb7ff,0xdf000-0xdffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 ppc0: cannot reserve I/O port range est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ad4: 152627MB at ata2-master UDMA100 SATA 1.5Gb/s ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 GEOM: ad4s1: geometry does not match label (255h,63s !=3D 16h,63s). uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered ugen0.2: at usbus0 uhub2: = on usbus0 ugen1.2: at usbus1 uhub3: = on usbus1 acd0: DVDROM at ata4-master UDMA100 SATA 1.5Gb/s SMP: AP CPU #1 Launched! Root mount waiting for: usbus1 usbus0 uhub2: 6 ports with 6 removable, self powered uhub3: 8 ports with 8 removable, self powered ugen0.3: at usbus0 ukbd0: = on usbus0 kbd0 at ukbd0 Root mount waiting for: usbus1 usbus0 ugen1.3: at usbus1 ukbd1: = on usbus1 kbd2 at ukbd1 ums0: on = usbus1 ums0: 8 buttons and [XYZ] coordinates ID=3D0 ugen0.4: at usbus0 ums1: = on usbus0 ums1: 3 buttons and [XYZ] coordinates ID=3D0 Trying to mount root from ufs:/dev/label/rootfs PCICONF -lv hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x3318103c chip=3D0x00488086 = rev=3D0x12 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:0:1:0: class=3D0x060400 card=3D0x00428086 chip=3D0x00498086 = rev=3D0x12 hdr=3D0x01 vendor =3D 'Intel Corporation' class =3D bridge subclass =3D PCI-PCI ehci0@pci0:0:26:0: class=3D0x0c0320 card=3D0x3118103c chip=3D0x3b3c8086 = rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D serial bus subclass =3D USB pcib2@pci0:0:28:0: class=3D0x060400 card=3D0x3318103c chip=3D0x3b428086 = rev=3D0x05 hdr=3D0x01 vendor =3D 'Intel Corporation' class =3D bridge subclass =3D PCI-PCI pcib3@pci0:0:28:1: class=3D0x060400 card=3D0x3318103c chip=3D0x3b448086 = rev=3D0x05 hdr=3D0x01 vendor =3D 'Intel Corporation' class =3D bridge subclass =3D PCI-PCI pcib4@pci0:0:28:2: class=3D0x060400 card=3D0x3318103c chip=3D0x3b468086 = rev=3D0x05 hdr=3D0x01 vendor =3D 'Intel Corporation' class =3D bridge subclass =3D PCI-PCI pcib5@pci0:0:28:3: class=3D0x060400 card=3D0x3318103c chip=3D0x3b488086 = rev=3D0x05 hdr=3D0x01 vendor =3D 'Intel Corporation' class =3D bridge subclass =3D PCI-PCI pcib6@pci0:0:28:4: class=3D0x060400 card=3D0x3318103c chip=3D0x3b4a8086 = rev=3D0x05 hdr=3D0x01 vendor =3D 'Intel Corporation' class =3D bridge subclass =3D PCI-PCI ehci1@pci0:0:29:0: class=3D0x0c0320 card=3D0x3118103c chip=3D0x3b348086 = rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D serial bus subclass =3D USB pcib7@pci0:0:30:0: class=3D0x060401 card=3D0x3318103c chip=3D0x244e8086 = rev=3D0xa5 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub = Interface to PCI Bridge' class =3D bridge subclass =3D PCI-PCI isab0@pci0:0:31:0: class=3D0x060100 card=3D0x3118103c chip=3D0x3b148086 = rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D bridge subclass =3D PCI-ISA atapci0@pci0:0:31:2: class=3D0x01018f card=3D0x3118103c = chip=3D0x3b208086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'IBEX SATA Controller' class =3D mass storage subclass =3D ATA none0@pci0:0:31:3: class=3D0x0c0500 card=3D0x3318103c chip=3D0x3b308086 = rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D serial bus subclass =3D SMBus atapci1@pci0:0:31:5: class=3D0x010185 card=3D0x3118103c = chip=3D0x3b268086 rev=3D0x05 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'IBEX SATA Controller' class =3D mass storage subclass =3D ATA vgapci0@pci0:28:0:0: class=3D0x030000 card=3D0x31fa103c = chip=3D0x0522102b rev=3D0x02 hdr=3D0x00 vendor =3D 'Matrox Electronic Systems Ltd.' device =3D 'Matrox G200e (ServerEngines) - English (G200e)' class =3D display subclass =3D VGA bge0@pci0:30:0:0: class=3D0x020000 card=3D0x705d103c chip=3D0x165b14e4 = rev=3D0x10 hdr=3D0x00 vendor =3D 'Broadcom Corporation' class =3D network subclass =3D ethernet xl0@pci0:48:0:0: class=3D0x020000 card=3D0x100010b7 chip=3D0x920010b7 = rev=3D0x78 hdr=3D0x00 vendor =3D '3COM Corp, Networking Division' device =3D 'Fast EtherLink for PC Management NIC (3C905 CX-TXM)' class =3D network subclass =3D ethernet regards, Johan Hendriks From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 14:38:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 716D11065675 for ; Fri, 11 Jun 2010 14:38:20 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 0EA518FC25 for ; Fri, 11 Jun 2010 14:38:17 +0000 (UTC) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta02.westchester.pa.mail.comcast.net with comcast id UaiL1e0051YDfWL52eeJpz; Fri, 11 Jun 2010 14:38:18 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.westchester.pa.mail.comcast.net with comcast id UeeH1e0053S48mS3geeHju; Fri, 11 Jun 2010 14:38:18 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id DC0F39B423; Fri, 11 Jun 2010 07:38:15 -0700 (PDT) Date: Fri, 11 Jun 2010 07:38:15 -0700 From: Jeremy Chadwick To: Johan Hendriks Message-ID: <20100611143815.GA11015@icarus.home.lan> References: <57200BF94E69E54880C9BB1AF714BBCBA57A86@w2003s01.double-l.local> <4C120144.80002@icyb.net.ua> <57200BF94E69E54880C9BB1AF714BBCBA57A90@w2003s01.double-l.local> <20100611134555.GA9682@icarus.home.lan> <57200BF94E69E54880C9BB1AF714BBCB0111C2@w2003s01.double-l.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB0111C2@w2003s01.double-l.local> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: 8.1 AMD64 Beta1 cd panics on Proliant ML110 G6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 14:38:20 -0000 On Fri, Jun 11, 2010 at 04:11:48PM +0200, Johan Hendriks wrote: > > >> >> Hello all. > >> >> > >> >> I try to install the Beta of 8.1 but it panics on my server HP > >> Proliant ML110 > > >> > >>>Stacktrace would be helpful. > >> > >> Well at startup, the keyboard is not working, i can not select any boot > >> mode, and after the timer is at 0 ti boots, and then ends with this > >> panic, and totally hangs. > >> 8.0 works fine also CURRENT Works! > > >Regarding the keyboard not working -- it should still be working during > >the loader phase (FreeBSD logo, press 4 for single user, etc.), correct? > > >If so, two things to try. Escape to the loader prompt and try one of > >the below (if (a) doesn't work, try (b)): > > >a) set hint.kbdmux.0.disabled=1 > > boot > > >b) set hint.atkbd.0.disabled=1 > > set hint.atkbdc.0.disabled=1 > > boot > > >Hopefully one of these will allow your keyboard to continue functioning > >once the system panics, so that you can provide a backtrace. Thanks. > > The problem is the keyboard is not working at all, so i need to wait till the counter reach 0. > I did also installed 8.0, no problem. > Then did a buildworld to the latest 8.1 source from 2010-06-08, buildworld runs fine, then after the reboot same issue as the BETA1-install-only iso. A non-working keyboard during loader is more easily explainable. It's a USB keyboard, isn't it? You need to find whatever BIOS option in your system correlates with "Enable USB Legacy Support". This should allow a USB keyboard to be "emulated" (via BIOS) as a PS/2-style keyboard up until the kernel resets USB-related devices. If there is no such option, can you point me to the User's Manual for this model of system so I can review it? (Hopefully it includes BIOS options...). Thanks. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 15:55:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45E4310656C0 for ; Fri, 11 Jun 2010 15:55:36 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 11D198FC0C for ; Fri, 11 Jun 2010 15:55:35 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta11.emeryville.ca.mail.comcast.net with comcast id Ud3N1e0011smiN4ABfvbNo; Fri, 11 Jun 2010 15:55:35 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.emeryville.ca.mail.comcast.net with comcast id Ufva1e00D3S48mS8gfvaUD; Fri, 11 Jun 2010 15:55:35 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3C7209B418; Fri, 11 Jun 2010 08:55:34 -0700 (PDT) Resent-From: Jeremy Chadwick Resent-Date: Fri, 11 Jun 2010 08:55:34 -0700 Resent-Message-ID: <20100611155534.GA12944@icarus.home.lan> Resent-To: freebsd-stable@freebsd.org X-Original-To: jdc@localhost Received: from icarus.home.lan (localhost [127.0.0.1]) by icarus.home.lan (Postfix) with ESMTP id AA0E19B408 for ; Fri, 11 Jun 2010 07:44:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on horus.parodius.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=2.9 tests=BAYES_00, RCVD_IN_DNSWL_NONE, USER_IN_BLACKLIST_TO, USER_IN_WHITELIST_TO autolearn=ham version=3.3.1 X-Original-To: freebsd@jdc.parodius.com Received: from mx01.sc1.parodius.com [72.20.98.67] by icarus.home.lan with POP3 (fetchmail-6.3.17) for (single-drop); Fri, 11 Jun 2010 07:44:00 -0700 (PDT) Received: from smtp-vbr16.xs4all.nl (smtp-vbr16.xs4all.nl [194.109.24.36]) by mx01.sc1.parodius.com (Postfix) with ESMTP id BAAF29585B for ; Fri, 11 Jun 2010 07:43:21 -0700 (PDT) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr16.xs4all.nl (8.13.8/8.13.8) with ESMTP id o5BEhJbs087806 for ; Fri, 11 Jun 2010 16:43:20 +0200 (CEST) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 11 Jun 2010 16:43:18 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA57A94@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.1 AMD64 Beta1 cd panics on Proliant ML110 G6 Thread-Index: AcsJdHQcjiIKtzxIS5GRUkbiJIKyzQAACrfw References: <57200BF94E69E54880C9BB1AF714BBCBA57A86@w2003s01.double-l.local> <4C120144.80002@icyb.net.ua> <57200BF94E69E54880C9BB1AF714BBCBA57A90@w2003s01.double-l.local> <20100611134555.GA9682@icarus.home.lan> <57200BF94E69E54880C9BB1AF714BBCB0111C2@w2003s01.double-l.local> <20100611143815.GA11015@icarus.home.lan> From: "Johan Hendriks" To: "Jeremy Chadwick" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Subject: RE: 8.1 AMD64 Beta1 cd panics on Proliant ML110 G6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 15:55:36 -0000 Sorry for top posting this one, i am at a custumor and he is using outlook! It is a PS/2 keyboard!! regards, Johan Hendriks =20 > >> >> Hello all. > >> >>=20 > >> >> I try to install the Beta of 8.1 but it panics on my server HP > >> Proliant ML110 >=20 > >>=20 > >>>Stacktrace would be helpful. > >>=20 > >> Well at startup, the keyboard is not working, i can not select any boot > >> mode, and after the timer is at 0 ti boots, and then ends with this > >> panic, and totally hangs. > >> 8.0 works fine also CURRENT Works! >=20 > >Regarding the keyboard not working -- it should still be working during > >the loader phase (FreeBSD logo, press 4 for single user, etc.), correct? >=20 > >If so, two things to try. Escape to the loader prompt and try one of > >the below (if (a) doesn't work, try (b)): >=20 > >a) set hint.kbdmux.0.disabled=3D1 > > boot >=20 > >b) set hint.atkbd.0.disabled=3D1 > > set hint.atkbdc.0.disabled=3D1 > > boot >=20 > >Hopefully one of these will allow your keyboard to continue functioning > >once the system panics, so that you can provide a backtrace. Thanks. >=20 > The problem is the keyboard is not working at all, so i need to wait till the counter reach 0. > I did also installed 8.0, no problem. > Then did a buildworld to the latest 8.1 source from 2010-06-08, buildworld runs fine, then after the reboot same issue as the BETA1-install-only iso. A non-working keyboard during loader is more easily explainable. It's a USB keyboard, isn't it? You need to find whatever BIOS option in your system correlates with "Enable USB Legacy Support". This should allow a USB keyboard to be "emulated" (via BIOS) as a PS/2-style keyboard up until the kernel resets USB-related devices. If there is no such option, can you point me to the User's Manual for this model of system so I can review it? (Hopefully it includes BIOS options...). Thanks. --=20 | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 15:58:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15B12106566C for ; Fri, 11 Jun 2010 15:58:57 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by mx1.freebsd.org (Postfix) with ESMTP id B39658FC16 for ; Fri, 11 Jun 2010 15:58:56 +0000 (UTC) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA11.westchester.pa.mail.comcast.net with comcast id UaRW1e0050mv7h05Bfywnp; Fri, 11 Jun 2010 15:58:56 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta11.westchester.pa.mail.comcast.net with comcast id Ufyv1e00D3S48mS3Xfyw29; Fri, 11 Jun 2010 15:58:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5D0489B418; Fri, 11 Jun 2010 08:58:54 -0700 (PDT) Date: Fri, 11 Jun 2010 08:58:54 -0700 From: Jeremy Chadwick To: Johan Hendriks Message-ID: <20100611155854.GA13058@icarus.home.lan> References: <57200BF94E69E54880C9BB1AF714BBCBA57A86@w2003s01.double-l.local> <4C120144.80002@icyb.net.ua> <57200BF94E69E54880C9BB1AF714BBCBA57A90@w2003s01.double-l.local> <20100611134555.GA9682@icarus.home.lan> <57200BF94E69E54880C9BB1AF714BBCB0111C2@w2003s01.double-l.local> <20100611143815.GA11015@icarus.home.lan> <57200BF94E69E54880C9BB1AF714BBCBA57A94@w2003s01.double-l.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBA57A94@w2003s01.double-l.local> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: 8.1 AMD64 Beta1 cd panics on Proliant ML110 G6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 15:58:57 -0000 On Fri, Jun 11, 2010 at 04:43:18PM +0200, Johan Hendriks wrote: > Sorry for top posting this one, i am at a custumor and he is using > outlook! > > It is a PS/2 keyboard!! > > regards, > Johan Hendriks > > > >> >> Hello all. > > >> >> > > >> >> I try to install the Beta of 8.1 but it panics on my server HP > > >> Proliant ML110 > > > > >> > > >>>Stacktrace would be helpful. > > >> > > >> Well at startup, the keyboard is not working, i can not select any > boot > > >> mode, and after the timer is at 0 ti boots, and then ends with this > > >> panic, and totally hangs. > > >> 8.0 works fine also CURRENT Works! > > > > >Regarding the keyboard not working -- it should still be working > during > > >the loader phase (FreeBSD logo, press 4 for single user, etc.), > correct? > > > > >If so, two things to try. Escape to the loader prompt and try one of > > >the below (if (a) doesn't work, try (b)): > > > > >a) set hint.kbdmux.0.disabled=1 > > > boot > > > > >b) set hint.atkbd.0.disabled=1 > > > set hint.atkbdc.0.disabled=1 > > > boot > > > > >Hopefully one of these will allow your keyboard to continue > functioning > > >once the system panics, so that you can provide a backtrace. Thanks. > > > > The problem is the keyboard is not working at all, so i need to wait > till the counter reach 0. > > I did also installed 8.0, no problem. > > Then did a buildworld to the latest 8.1 source from 2010-06-08, > buildworld runs fine, then after the reboot same issue as the > BETA1-install-only iso. > > A non-working keyboard during loader is more easily explainable. It's a > USB keyboard, isn't it? You need to find whatever BIOS option in your > system correlates with "Enable USB Legacy Support". This should allow a > USB keyboard to be "emulated" (via BIOS) as a PS/2-style keyboard up > until the kernel resets USB-related devices. > > If there is no such option, can you point me to the User's Manual for > this model of system so I can review it? (Hopefully it includes BIOS > options...). Thanks. I bounced a copy of this mail to the list since the OP sent it to me directly. This is the first I've heard of a PS/2 keyboard not working during the boot phases/loader. Is there anyone on -stable who might know how to diagnose this? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 17:05:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 814E61065670 for ; Fri, 11 Jun 2010 17:05:11 +0000 (UTC) (envelope-from luke@foolishgames.com) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id 5E1498FC14 for ; Fri, 11 Jun 2010 17:05:11 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta09.emeryville.ca.mail.comcast.net with comcast id Ud1n1e0011smiN4A9grzu9; Fri, 11 Jun 2010 16:51:59 +0000 Received: from stargazer.midnightbsd.org ([70.91.226.201]) by omta20.emeryville.ca.mail.comcast.net with comcast id Ugry1e0054MLobJ8ggrzv8; Fri, 11 Jun 2010 16:51:59 +0000 Received: from lholt-desktop.primemediaanalysis.com (75-151-13-201-Michigan.hfc.comcastbusiness.net [75.151.13.201]) (authenticated bits=0) by stargazer.midnightbsd.org (8.14.4/8.14.4) with ESMTP id o5BGpurn074564 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Fri, 11 Jun 2010 12:51:57 -0400 (EDT) (envelope-from luke@foolishgames.com) X-Authentication-Warning: stargazer.midnightbsd.org: Host 75-151-13-201-Michigan.hfc.comcastbusiness.net [75.151.13.201] claimed to be lholt-desktop.primemediaanalysis.com Message-ID: <4C1269AB.30400@foolishgames.com> Date: Fri, 11 Jun 2010 12:51:55 -0400 From: Lucas Holt User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100401 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <57200BF94E69E54880C9BB1AF714BBCBA57A86@w2003s01.double-l.local> <4C120144.80002@icyb.net.ua> <57200BF94E69E54880C9BB1AF714BBCBA57A90@w2003s01.double-l.local> <20100611134555.GA9682@icarus.home.lan> <57200BF94E69E54880C9BB1AF714BBCB0111C2@w2003s01.double-l.local> <20100611143815.GA11015@icarus.home.lan> <57200BF94E69E54880C9BB1AF714BBCBA57A94@w2003s01.double-l.local> <20100611155854.GA13058@icarus.home.lan> In-Reply-To: <20100611155854.GA13058@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: 8.1 AMD64 Beta1 cd panics on Proliant ML110 G6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 17:05:11 -0000 > I bounced a copy of this mail to the list since the OP sent it to me > directly. > > This is the first I've heard of a PS/2 keyboard not working during the > boot phases/loader. Is there anyone on -stable who might know how to > diagnose this? > > I've seen this problem on an HP ML110 as well. I suspect it might be related to the LOM. I've had success using a serial console when I needed to do anything with the menu. From owner-freebsd-stable@FreeBSD.ORG Fri Jun 11 18:42:56 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 555331065677 for ; Fri, 11 Jun 2010 18:42:56 +0000 (UTC) (envelope-from ogud@ogud.com) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by mx1.freebsd.org (Postfix) with ESMTP id E83668FC25 for ; Fri, 11 Jun 2010 18:42:55 +0000 (UTC) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id o5BIVCYb091378 for ; Fri, 11 Jun 2010 14:31:12 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4C1280EE.8000309@ogud.com> Date: Fri, 11 Jun 2010 14:31:10 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: Subject: 8.1Beta1 DVD does not finish boot sequence X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 11 Jun 2010 18:42:56 -0000 I have a brand new Dell Inspiron 570. When trying to install FreeBSD-8.1beta1 from DVD, the boot sequence starts, but I get spinning "*". (I got the same result from a 7.2-Release DVD). The same machine has similar problems with number of other OS distributions, but installation works from an external DVD so the problem is related to the DVD drive. Windows-7 and Ubuntu 10.4 can install from the drive. Dell lists the Drive as: V2P99 Assembly,Dvd+/-Rw,16X,BARE,Toshiba Samsung Storage Technology Windows-7 identifies the DVD drive as: TSSTcorp DVD+-RW TS-H653G ATA What I see o the screen is: ------ CD Loader 1.2 Building the boot loader arguments Looking up /BOOT/LOADER... Found /\| ----- Olafur From owner-freebsd-stable@FreeBSD.ORG Sat Jun 12 00:00:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C858106564A for ; Sat, 12 Jun 2010 00:00:54 +0000 (UTC) (envelope-from jeff.dowsley@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id 7DBC28FC15 for ; Sat, 12 Jun 2010 00:00:54 +0000 (UTC) MIME-version: 1.0 Received: from [192.168.1.101] (110-175-193-74.static.tpgi.com.au [110.175.193.74]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L3V00H3VK1E9N70@asmtp021.mac.com> for freebsd-stable@freebsd.org; Fri, 11 Jun 2010 17:00:54 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1006110172 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5,1.2.40,4.0.166 definitions=2010-06-11_03:2010-02-06, 2010-06-11, 2010-06-11 signatures=0 In-reply-to: References: <20100610230300.GA51804@stack.nl> Message-id: <53C5B962-676B-4787-9C84-49F70884A3A1@mac.com> From: Jeff Dowsley Date: Sat, 12 Jun 2010 10:01:08 +1000 To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: "calcru: runtime went backwards" messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2010 00:00:54 -0000 You're not alone. Noticed the calcru messages after a rebuild in May on a Compaq PIII, but assumed it wasn't doing any harm, and that it would eventually be fixed. JeffD _____________________________ M 0427565791 jeff.dowsley@mac.com On 11/06/2010, at 4:03 PM, Jansen Gotis wrote: > On Fri, Jun 11, 2010 at 7:03 AM, Jilles Tjoelker > wrote: >> On Fri, Jun 11, 2010 at 12:35:05AM +0800, Jansen Gotis wrote: >>> Hi, for the past couple of months since moving to RELENG_8 I've been >>> receiving "calcru: runtime went backwards" messages on the console. >> > >> >> This may well be a manifestation of a brokenness (which should not be >> unknown) in how FreeBSD stores CPU time utilization. The time is >> maintained in "CPU ticks" (CPU clock cycles), so if the clock >> frequency >> changes, the values of existing processes will be wrong (a jump when >> converted to seconds). When calcru detects this, it generates >> messages >> like the above. If this analysis is right, the messages can be >> ignored, >> but indicate that CPU time statistics may be inaccurate. >> > > You're probably right, the messages can be ignored. I don't see any > issues > other than the messages being printed on the console; I don't > experience > freezing, etc. It just struck me as weird because searching the - > current and > -stable mailing lists does not show anyone else having the issue as > recently > as I have. > > Just some more info to add which I forgot about last time...setting > kern.hz to > 100 did not help. > > Thanks for the reply. > > > Best regards, > Jansen > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable- > unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Jun 12 04:53:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 353BB106564A for ; Sat, 12 Jun 2010 04:53:47 +0000 (UTC) (envelope-from jtgotis@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 DD3818FC1A for ; Sat, 12 Jun 2010 04:53:46 +0000 (UTC) Received: by vws20 with SMTP id 20so1162103vws.13 for ; Fri, 11 Jun 2010 21:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=+a7xphkUnE5/fvWvRU08V+VJStuv4YxZwQSaioD16Qw=; b=PPkeWc/b1zuKHG40vXarFcxeQUqwc8ygTWFGj2pR6GCJDb+tIXLAkkopI8//ckooxb vNeL0BvYYuY6pGmv6zir9YgdM1LD7A2IGAz9CODsid36GWboa2jHQfLzdBIKPThg8cJO Hx6np3fPrvhjdMcvGP3m2Ptnor0+E6JGU+4Vk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=QvOCQGXHTw2CIuk02OX5R4Bba7FwkfZbn+kW5lU3ILRU/u+Fi/nW7d+AXio/7Rnd6H aLqqrAWPkD6+pwnQxQRfAkyQm75IIh1VoQw3IuYC0ju8hlZNPqb+03o5osM9RX5Mk1Wp kQROid0HBZNhzSVpZmNOrFkzrl3vXBykr1J7s= MIME-Version: 1.0 Received: by 10.220.126.200 with SMTP id d8mr272364vcs.41.1276318425838; Fri, 11 Jun 2010 21:53:45 -0700 (PDT) Received: by 10.220.86.213 with HTTP; Fri, 11 Jun 2010 21:53:45 -0700 (PDT) In-Reply-To: <53C5B962-676B-4787-9C84-49F70884A3A1@mac.com> References: <20100610230300.GA51804@stack.nl> <53C5B962-676B-4787-9C84-49F70884A3A1@mac.com> Date: Sat, 12 Jun 2010 12:53:45 +0800 Message-ID: From: Jansen Gotis To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: "calcru: runtime went backwards" messages X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2010 04:53:47 -0000 On Sat, Jun 12, 2010 at 8:01 AM, Jeff Dowsley wrote: > You're not alone. =A0Noticed the calcru messages after a rebuild in May o= n a > Compaq PIII, but assumed it wasn't doing any harm, and that it would > eventually be fixed. > > JeffD > It appears to be related to VESA, because when support for it is neither lo= aded as a module nor compiled into the kernel, the system does not print the messages. Can you please verify that on your machine? Thanks. Best regards, Jansen From owner-freebsd-stable@FreeBSD.ORG Sat Jun 12 08:56:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C3871065670 for ; Sat, 12 Jun 2010 08:56:14 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E03DF8FC1B for ; Sat, 12 Jun 2010 08:56:13 +0000 (UTC) Received: by bwz2 with SMTP id 2so1161550bwz.13 for ; Sat, 12 Jun 2010 01:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :x-comment-to:date:in-reply-to:message-id:user-agent:mime-version :content-type:content-transfer-encoding; bh=7HlmGkTm+AfSzAwGYxgssB6odoMov3JJqdAAOLJuIg0=; b=R7WRCBytKIdQo+pwxZA/Fdwz8jL7434p8Hh7TQrAHrBjzillbFczuxySjW+6/g8AX2 vkOyq/6lELANEsbe+gSo5AqOX/5mfrrrTGrHkG99iEf6mFInnOCJFH0Na1UTlH1aySfP cHciNoeo3P/HWH5RF2Y/4p+1xRI0lAi1PV8zI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:user-agent:mime-version:content-type :content-transfer-encoding; b=mnUwYl9PjcHy+ljuigCOUQFvFbgVspGNgDjlzPgNhjEuho/ruVXQIPxhbuGOMu3eE3 tEErnW918mIqtbBDdp3E6jFkr7XQidKWGwKnxN6N052m8Il6byFIhvnC3Qgcpp4lkPWa M9/NP4am+QeK/oWS/pYYIrd6LWKZs8deBSbc8= Received: by 10.204.83.198 with SMTP id g6mr2127081bkl.104.1276332972371; Sat, 12 Jun 2010 01:56:12 -0700 (PDT) Received: from localhost ([95.69.160.52]) by mx.google.com with ESMTPS id v2sm8926329bkz.7.2010.06.12.01.56.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 12 Jun 2010 01:56:11 -0700 (PDT) From: Mikolaj Golub To: Leon =?utf-8?Q?Me=C3=9Fner?= References: <20100606144443.GA50876@emmi.physik-pool.tu-berlin.de> X-Comment-To: Leon =?utf-8?Q?Me=C3=9Fner?= Date: Sat, 12 Jun 2010 11:56:10 +0300 In-Reply-To: <20100606144443.GA50876@emmi.physik-pool.tu-berlin.de> ("Leon =?utf-8?Q?Me=C3=9Fner=22's?= message of "Sun, 6 Jun 2010 16:44:43 +0200") Message-ID: <8639wsk4t1.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: freeBSD nullfs together with nfs and "silly rename" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2010 08:56:14 -0000 On Sun, 6 Jun 2010 16:44:43 +0200 Leon Me=C3=9Fner wrote: LM> Hi, LM> I hope this is not the wrong list to ask. Didn't get any answers on LM> -questions. LM> When you try to do the following inside a nullfs mounted directory, LM> where the nullfs origin is itself mounted via nfs you get an error: LM> # foo=20 LM> # tail -f foo&=20 LM> # rm -f foo=20 LM> tail: foo: Stale NFS file handle LM> # fg LM> This is really a problem when running services inside jails and using LM> NFS as storage. As of [2] it looks like this problem is known for a LM> while. On a normal NFS mount this does not happen as "silly renaming" LM> [1] works there (producing nasty little .nfsXXXX files). nfs_sillyrename() is called when vnode's usecount is more then 1. It is expected that unlink() syscall increases vnode's usecount in namei() and if the file has been already opened usecount will be more then 1. But with nullfs layer present the reference counts are held by the upper no= de, not the lower (nfs) one, so when unlink() is called it increases usecount of the upper vnode, not nfs vnode and nfs_sillyrename() is never called. The strightforward solution looks like to implement null_remove() that will increase lower vnode's refcount before calling null_bypass() and then decrement it after the call. See the attached patch (it works for me on both 8-STABLE and CURRENT). --=20 Mikolaj Golub From owner-freebsd-stable@FreeBSD.ORG Sat Jun 12 08:59:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 349071065687 for ; Sat, 12 Jun 2010 08:59:08 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A8ED88FC13 for ; Sat, 12 Jun 2010 08:59:07 +0000 (UTC) Received: by bwz2 with SMTP id 2so1163171bwz.13 for ; Sat, 12 Jun 2010 01:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :x-comment-to:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=RwiOpOa+sB3hM+6n8Cs5LjNQndnULwzVe71uymqGI9k=; b=bVYEBhkNv576LthxFFpIFCGKKvSoCMxJId/92KPvLuVQiQxF/VSxhs6y4hXyM6FaEC GHgOAw6x3nsHPRlHJF/J981iCBBaPP8Nitn15yIID+q4X4qiCzg/Fllm9CW3uOTorHVs 6vI02cb7+7YS+plbqHAdhRqqaSoA2wjMEY/uI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=IWIdFzFB+9Pei5+LDaQPCv1Uy0X+Lgg/am9WHPH4fh9q1enAOy6SF8vUkeBIstjCor U2B1X8DiLrRyMKfXL+DSGDjdIe6ze/T6CGrK4EswnbaJMnaOkTSx5Q+PZRyidW/VVSK3 vf1qTamo+d25HDClguVbXvNGrTb+r4eMkETh4= Received: by 10.204.160.156 with SMTP id n28mr2168435bkx.1.1276333144992; Sat, 12 Jun 2010 01:59:04 -0700 (PDT) Received: from localhost ([95.69.160.52]) by mx.google.com with ESMTPS id z17sm8949284bkx.0.2010.06.12.01.59.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 12 Jun 2010 01:59:03 -0700 (PDT) From: Mikolaj Golub To: Leon =?utf-8?Q?Me=C3=9Fner?= References: <20100606144443.GA50876@emmi.physik-pool.tu-berlin.de> <8639wsk4t1.fsf@kopusha.home.net> X-Comment-To: Mikolaj Golub Date: Sat, 12 Jun 2010 11:59:03 +0300 In-Reply-To: <8639wsk4t1.fsf@kopusha.home.net> (Mikolaj Golub's message of "Sat, 12 Jun 2010 11:56:10 +0300") Message-ID: <86y6ekiq3s.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: freebsd-stable@freebsd.org Subject: Re: freeBSD nullfs together with nfs and "silly rename" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2010 08:59:08 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, 12 Jun 2010 11:56:10 +0300 Mikolaj Golub wrote to Leon Me=C3=9Fner: MG> See the attached patch (it works for me on both 8-STABLE and CURRENT). Sorry, actually here is the patch. --=20 Mikolaj Golub --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=null_vnops.c.null_remove.patch Index: sys/fs/nullfs/null_vnops.c =================================================================== --- sys/fs/nullfs/null_vnops.c (revision 208960) +++ sys/fs/nullfs/null_vnops.c (working copy) @@ -499,6 +499,23 @@ } /* + * Increasing refcount of lower vnode is needed at least for the case + * when lower FS is NFS to do sillyrename if the file is in use. + */ +static int +null_remove(struct vop_remove_args *ap) +{ + int retval; + struct vnode *lvp; + + lvp = NULLVPTOLOWERVP(ap->a_vp); + VREF(lvp); + retval = null_bypass(&ap->a_gen); + vrele(lvp); + return (retval); +} + +/* * We handle this to eliminate null FS to lower FS * file moving. Don't know why we don't allow this, * possibly we should. @@ -809,6 +826,7 @@ .vop_open = null_open, .vop_print = null_print, .vop_reclaim = null_reclaim, + .vop_remove = null_remove, .vop_rename = null_rename, .vop_setattr = null_setattr, .vop_strategy = VOP_EOPNOTSUPP, --=-=-=-- From owner-freebsd-stable@FreeBSD.ORG Sat Jun 12 14:15:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC417106566C for ; Sat, 12 Jun 2010 14:15:57 +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 4E76D8FC15 for ; Sat, 12 Jun 2010 14:15:56 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o5CEFqlm026082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Jun 2010 17:15:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o5CEFqIR076341; Sat, 12 Jun 2010 17:15:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o5CEFnBe076340; Sat, 12 Jun 2010 17:15:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 12 Jun 2010 17:15:49 +0300 From: Kostik Belousov To: Mikolaj Golub Message-ID: <20100612141549.GM13238@deviant.kiev.zoral.com.ua> References: <20100606144443.GA50876@emmi.physik-pool.tu-berlin.de> <8639wsk4t1.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Cqq5NadOW2RfLMJ/" Content-Disposition: inline In-Reply-To: <8639wsk4t1.fsf@kopusha.home.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Leon Me??ner , freebsd-stable@freebsd.org Subject: Re: freeBSD nullfs together with nfs and "silly rename" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2010 14:15:57 -0000 --Cqq5NadOW2RfLMJ/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 12, 2010 at 11:56:10AM +0300, Mikolaj Golub wrote: >=20 > On Sun, 6 Jun 2010 16:44:43 +0200 Leon Me??ner wrote: >=20 > LM> Hi, > LM> I hope this is not the wrong list to ask. Didn't get any answers on > LM> -questions. >=20 > LM> When you try to do the following inside a nullfs mounted directory, > LM> where the nullfs origin is itself mounted via nfs you get an error: >=20 > LM> # foo=20 > LM> # tail -f foo&=20 > LM> # rm -f foo=20 > LM> tail: foo: Stale NFS file handle > LM> # fg >=20 > LM> This is really a problem when running services inside jails and using > LM> NFS as storage. As of [2] it looks like this problem is known for a > LM> while. On a normal NFS mount this does not happen as "silly renaming" > LM> [1] works there (producing nasty little .nfsXXXX files). >=20 > nfs_sillyrename() is called when vnode's usecount is more then 1. It is > expected that unlink() syscall increases vnode's usecount in namei() and = if > the file has been already opened usecount will be more then 1. >=20 > But with nullfs layer present the reference counts are held by the upper = node, > not the lower (nfs) one, so when unlink() is called it increases usecount= of > the upper vnode, not nfs vnode and nfs_sillyrename() is never called. >=20 > The strightforward solution looks like to implement null_remove() that wi= ll > increase lower vnode's refcount before calling null_bypass() and then > decrement it after the call. See the attached patch (it works for me on b= oth > 8-STABLE and CURRENT). The upper vnode holds a reference to the lower vnode, as you noted. Now, with your patch, I believe that _all_ calls to the nfs_remove() are happen with refcount > 1. --Cqq5NadOW2RfLMJ/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwTlpUACgkQC3+MBN1Mb4gkRwCg4QvbVcDxkzdEgeMmtKUpgDP4 F2AAnj+DyLLiPVvIe+7/bjdyKb87oy1f =Jmsd -----END PGP SIGNATURE----- --Cqq5NadOW2RfLMJ/-- From owner-freebsd-stable@FreeBSD.ORG Sat Jun 12 14:59:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53F40106566C for ; Sat, 12 Jun 2010 14:59:36 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 057288FC0C for ; Sat, 12 Jun 2010 14:59:35 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJI9E0yDaFvH/2dsb2JhbACfA3G+HIJggjoE X-IronPort-AV: E=Sophos;i="4.53,408,1272859200"; d="scan'208";a="80429862" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 12 Jun 2010 10:59:33 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id DF0241084242; Sat, 12 Jun 2010 10:59:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XQhs8R-1dLJ; Sat, 12 Jun 2010 10:59:33 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id AEF33108422C; Sat, 12 Jun 2010 10:59:33 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o5CFFnU05004; Sat, 12 Jun 2010 11:15:49 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sat, 12 Jun 2010 11:15:49 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Kostik Belousov In-Reply-To: <20100612141549.GM13238@deviant.kiev.zoral.com.ua> Message-ID: References: <20100606144443.GA50876@emmi.physik-pool.tu-berlin.de> <8639wsk4t1.fsf@kopusha.home.net> <20100612141549.GM13238@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Leon Me??ner , freebsd-stable@freebsd.org, Mikolaj Golub Subject: Re: Re: freeBSD nullfs together with nfs and "silly rename" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2010 14:59:36 -0000 On Sat, 12 Jun 2010, Kostik Belousov wrote: > On Sat, Jun 12, 2010 at 11:56:10AM +0300, Mikolaj Golub wrote: >> >> On Sun, 6 Jun 2010 16:44:43 +0200 Leon Me??ner wrote: >> >> LM> Hi, >> LM> I hope this is not the wrong list to ask. Didn't get any answers on >> LM> -questions. >> >> LM> When you try to do the following inside a nullfs mounted directory, >> LM> where the nullfs origin is itself mounted via nfs you get an error: >> >> LM> # foo >> LM> # tail -f foo& >> LM> # rm -f foo >> LM> tail: foo: Stale NFS file handle >> LM> # fg >> >> LM> This is really a problem when running services inside jails and using >> LM> NFS as storage. As of [2] it looks like this problem is known for a >> LM> while. On a normal NFS mount this does not happen as "silly renaming" >> LM> [1] works there (producing nasty little .nfsXXXX files). >> >> nfs_sillyrename() is called when vnode's usecount is more then 1. It is >> expected that unlink() syscall increases vnode's usecount in namei() and if >> the file has been already opened usecount will be more then 1. >> >> But with nullfs layer present the reference counts are held by the upper node, >> not the lower (nfs) one, so when unlink() is called it increases usecount of >> the upper vnode, not nfs vnode and nfs_sillyrename() is never called. >> >> The strightforward solution looks like to implement null_remove() that will >> increase lower vnode's refcount before calling null_bypass() and then >> decrement it after the call. See the attached patch (it works for me on both >> 8-STABLE and CURRENT). > > The upper vnode holds a reference to the lower vnode, as you noted. > Now, with your patch, I believe that _all_ calls to the nfs_remove() > are happen with refcount > 1. > I'm not familiar with the nullfs so this might be way off, but would this patch be ok by any chance? Index: sys/fs/nullfs/null_vnops.c =================================================================== --- sys/fs/nullfs/null_vnops.c (revision 208960) +++ sys/fs/nullfs/null_vnops.c (working copy) @@ -499,6 +499,23 @@ } /* + * Increasing refcount of lower vnode is needed at least for the case + * when lower FS is NFS to do sillyrename if the file is in use. + */ +static int +null_remove(struct vop_remove_args *ap) +{ + int retval; + struct vnode *lvp; + + if (ap->a_vp->v_usecount > 1) { + lvp = NULLVPTOLOWERVP(ap->a_vp); + VREF(lvp); + } else + lvp = NULL; + retval = null_bypass(&ap->a_gen); + if (lvp != NULL) + vrele(lvp); + return (retval); +} + +/* * We handle this to eliminate null FS to lower FS * file moving. Don't know why we don't allow this, * possibly we should. @@ -809,6 +826,7 @@ .vop_open = null_open, .vop_print = null_print, .vop_reclaim = null_reclaim, + .vop_remove = null_remove, .vop_rename = null_rename, .vop_setattr = null_setattr, .vop_strategy = VOP_EOPNOTSUPP, From owner-freebsd-stable@FreeBSD.ORG Sat Jun 12 15:09:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E22E9106567C for ; Sat, 12 Jun 2010 15:09:19 +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 64ECC8FC14 for ; Sat, 12 Jun 2010 15:09:19 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o5CF9FXv029941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Jun 2010 18:09:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o5CF9FKc076591; Sat, 12 Jun 2010 18:09:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o5CF9FPw076590; Sat, 12 Jun 2010 18:09:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 12 Jun 2010 18:09:15 +0300 From: Kostik Belousov To: Rick Macklem Message-ID: <20100612150915.GN13238@deviant.kiev.zoral.com.ua> References: <20100606144443.GA50876@emmi.physik-pool.tu-berlin.de> <8639wsk4t1.fsf@kopusha.home.net> <20100612141549.GM13238@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aIbcA3MSwnGacr4f" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Leon Me??ner , freebsd-stable@freebsd.org, Mikolaj Golub Subject: Re: Re: freeBSD nullfs together with nfs and "silly rename" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2010 15:09:20 -0000 --aIbcA3MSwnGacr4f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 12, 2010 at 11:15:49AM -0400, Rick Macklem wrote: >=20 >=20 > On Sat, 12 Jun 2010, Kostik Belousov wrote: >=20 > >On Sat, Jun 12, 2010 at 11:56:10AM +0300, Mikolaj Golub wrote: > >> > >>On Sun, 6 Jun 2010 16:44:43 +0200 Leon Me??ner wrote: > >> > >> LM> Hi, > >> LM> I hope this is not the wrong list to ask. Didn't get any answers on > >> LM> -questions. > >> > >> LM> When you try to do the following inside a nullfs mounted directory, > >> LM> where the nullfs origin is itself mounted via nfs you get an error: > >> > >> LM> # foo > >> LM> # tail -f foo& > >> LM> # rm -f foo > >> LM> tail: foo: Stale NFS file handle > >> LM> # fg > >> > >> LM> This is really a problem when running services inside jails and us= ing > >> LM> NFS as storage. As of [2] it looks like this problem is known for a > >> LM> while. On a normal NFS mount this does not happen as "silly renami= ng" > >> LM> [1] works there (producing nasty little .nfsXXXX files). > >> > >>nfs_sillyrename() is called when vnode's usecount is more then 1. It is > >>expected that unlink() syscall increases vnode's usecount in namei() an= d=20 > >>if > >>the file has been already opened usecount will be more then 1. > >> > >>But with nullfs layer present the reference counts are held by the uppe= r=20 > >>node, > >>not the lower (nfs) one, so when unlink() is called it increases usecou= nt=20 > >>of > >>the upper vnode, not nfs vnode and nfs_sillyrename() is never called. > >> > >>The strightforward solution looks like to implement null_remove() that= =20 > >>will > >>increase lower vnode's refcount before calling null_bypass() and then > >>decrement it after the call. See the attached patch (it works for me on= =20 > >>both > >>8-STABLE and CURRENT). > > > >The upper vnode holds a reference to the lower vnode, as you noted. > >Now, with your patch, I believe that _all_ calls to the nfs_remove() > >are happen with refcount > 1. > > > I'm not familiar with the nullfs so this might be way off, but would > this patch be ok by any chance? >=20 > Index: sys/fs/nullfs/null_vnops.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/fs/nullfs/null_vnops.c (revision 208960) > +++ sys/fs/nullfs/null_vnops.c (working copy) > @@ -499,6 +499,23 @@ > } >=20 > /* > + * Increasing refcount of lower vnode is needed at least for the case > + * when lower FS is NFS to do sillyrename if the file is in use. > + */ > +static int > +null_remove(struct vop_remove_args *ap) > +{ > + int retval; > + struct vnode *lvp; > + > + if (ap->a_vp->v_usecount > 1) { > + lvp =3D NULLVPTOLOWERVP(ap->a_vp); > + VREF(lvp); > + } else > + lvp =3D NULL; > + retval =3D null_bypass(&ap->a_gen); > + if (lvp !=3D NULL) > + vrele(lvp); > + return (retval); > +} > + > +/* Yes, I hoped that Mikolaj ends up with something similar :). Please note that this is racy, since we cannot know why usecount is greater then 1. This might cause the silly rename to kick in some time where it should not, but the race is rare. --aIbcA3MSwnGacr4f Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwToxsACgkQC3+MBN1Mb4icPACcDNXe595aY92KTDDMm1Wjuj9E LxcAoOaScCNCZS1OXRmR4zR4sLEClw4n =N2VX -----END PGP SIGNATURE----- --aIbcA3MSwnGacr4f-- From owner-freebsd-stable@FreeBSD.ORG Sat Jun 12 17:19:44 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 293F5106566B; Sat, 12 Jun 2010 17:19:44 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B1F9E8FC12; Sat, 12 Jun 2010 17:19:42 +0000 (UTC) Received: by bwz2 with SMTP id 2so1441600bwz.13 for ; Sat, 12 Jun 2010 10:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xq8uzJux/wjPY/bIURMp7DESND+ETUfy3S39274zpm0=; b=hSjT6KaLvzrFGHtzgaBQ52NZQLEijqlRSZjbsoE2nwzw2XTi+MvQ6oM9geaI9yVmQm CLktfDzzqb7nrU3sx3NzO+CbTN0MjTJ/ge4cujLL4sZJjs7IWsg+SSs0sSvD1RJLS7dw 1dBDbFfOe5roBxrg0SqyEpqpnKL2sTib//U7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=U62T36bXRpx+pcEK+SDSjbsq33kq+5BUdOz1voqkjsM6OUf020wgM+Imh3wjjmsb1x I9Ok39xkS0B0F5sHTndt81035bx6DyKuw4Lb7DHP8LKmOjSDRabvcwMEy3XWST3ru44W 7nUjxQQYex9W/gMjZhjqvNPXi0NqpJGFzef3k= MIME-Version: 1.0 Received: by 10.204.2.71 with SMTP id 7mr2491027bki.213.1276363181245; Sat, 12 Jun 2010 10:19:41 -0700 (PDT) Received: by 10.204.123.202 with HTTP; Sat, 12 Jun 2010 10:19:41 -0700 (PDT) In-Reply-To: <201006110818.27366.jhb@freebsd.org> References: <201006110818.27366.jhb@freebsd.org> Date: Sat, 12 Jun 2010 19:19:41 +0200 Message-ID: From: David DEMELIER To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable , Brandon Gooch , Giovanni Trematerra , avg@freebsd.org, Attilio Rao , kib@freebsd.org, Rui Paulo , jkim@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2010 17:19:44 -0000 2010/6/11 John Baldwin : > On Friday 11 June 2010 6:27:48 am Giovanni Trematerra wrote: >> On Thu, Jun 10, 2010 at 10:58 PM, Giovanni Trematerra >> wrote: >> > On Tue, May 4, 2010 at 6:35 PM, David DEMELIER > wrote: >> >> Good news ! It worked, check the picture here : >> >> >> >> http://img63.imageshack.us/img63/4244/dsc00361g.jpg >> >> >> > >> > Into the file sys/dev/acpica/acpi_cpu.c at the end of acpi_cpu_notify >> > (a per cpu notification handler), called when _CST objects changing, >> > global cpu_cx_count is set to the greatest value of all sc->cpu_cx_cou= nt >> > per-cpu variables. That could result in a panic as David reported, >> > because that lets to invoke acpi_cpu_global_cx_lowest_sysctl from >> > /etc/rc.d/power_profile, when AC adapter is unplugged, =C2=A0with a va= lue >> > that not all the CPUs could handle in the acpi_cpu_idle. >> > The patch also change global cpu_cx_lowest according to new value of >> > global cpu_cx_count if needed. >> > >> > David Demelier made a great work to test every patch I sent him >> > to identify the source of the problem. >> > >> > Please, let me know your comments and possibly commit the patch >> > if you think is good enough. >> >> As jhb@ pointed me out in private with the previous patch a CPU could >> never enter in the >> lowest Cx-state even if it gained. >> So I'd like to propose this new solution. >> When hw.acpi.cpu.cx_lowest sysctl is set, the global handler in >> sys/dev/acpi_cpu.c >> will set the greatest sc->cpu_cx_lowest value supported by the CPU and >> not the same >> value for all CPUs. >> Later, when CPU, possibly gain new Cx-states, the acpi_cpu_notify >> handler will set >> sc->cpu_cx_lowest accordingly with global cx_lowest and the Cx-states >> supported by >> the CPU. >> >> Now I think that /etc/rc.d/power_profile script has a problem but that >> is a different story. >> The script select the lowest_value only querying cx-states of the dev.cp= u.0. >> If different CPUs may have different Cx-states, the script should use >> as lowest_value the >> lowest value between all the CPUs. > > Yes. > >> Please, let me know your comments and possibly commit the patch >> if you think is good enough. > > I think this is a good compromise for now. > > -- > John Baldwin > Thanks for Giovanni's patience and work, he made a lot of research to solve this little problem :-). Is there a chance that this patch appears in 8.1-RELEASE ? Kind regards. --=20 Demelier David From owner-freebsd-stable@FreeBSD.ORG Sat Jun 12 17:30:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2243106566C; Sat, 12 Jun 2010 17:30:32 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 45DFD8FC13; Sat, 12 Jun 2010 17:30:31 +0000 (UTC) Received: by iwn7 with SMTP id 7so3042904iwn.13 for ; Sat, 12 Jun 2010 10:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1xtirC9tuyOQAe11M2qs98mVsw0zi+GU3MnEeBbfvOg=; b=JKQ/kdiUJCzugkSUAglnGKzgVEtxfyWeZJFVwwwezq03U9lQDIDZ6QyXkQFHYL02Xt Tsf2FLHjeacdJ+xTp00t5FXZ2wF1yV5geK2s4QjyxJkzbQ3F97FvuIvR5ThOfi3sXKaU BzA6vhNNwsXLRBFig3LhbXCOXZNW7sx7FZbI8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ryGVS6B+N0zcGVv8qXQ6kyj4pSNNrEKyUFBFLifNm9aqHHgqQdW40PZYjbtQTejCf9 HfJWNaSU1PG6pyLKEhfdSvp4Ly+G37YVbR9kHwr45Eh5JCA5kb86NQrr5hBwPhRF6Z2n geYiSn7oZCip0Nv9w6hK0C2ElvuhMRZClc1vs= MIME-Version: 1.0 Received: by 10.231.157.17 with SMTP id z17mr3585348ibw.124.1276363831372; Sat, 12 Jun 2010 10:30:31 -0700 (PDT) Received: by 10.231.182.196 with HTTP; Sat, 12 Jun 2010 10:30:31 -0700 (PDT) In-Reply-To: References: <201006110818.27366.jhb@freebsd.org> Date: Sat, 12 Jun 2010 12:30:31 -0500 Message-ID: From: Brandon Gooch To: David DEMELIER Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable , John Baldwin , Giovanni Trematerra , avg@freebsd.org, Attilio Rao , kib@freebsd.org, Rui Paulo , jkim@freebsd.org Subject: Re: Kernel panic when unpluggin AC adaptor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2010 17:30:33 -0000 On Sat, Jun 12, 2010 at 12:19 PM, David DEMELIER wrote: > 2010/6/11 John Baldwin : >> On Friday 11 June 2010 6:27:48 am Giovanni Trematerra wrote: >>> On Thu, Jun 10, 2010 at 10:58 PM, Giovanni Trematerra >>> wrote: >>> > On Tue, May 4, 2010 at 6:35 PM, David DEMELIER >> wrote: >>> >> Good news ! It worked, check the picture here : >>> >> >>> >> http://img63.imageshack.us/img63/4244/dsc00361g.jpg >>> >> >>> > >>> > Into the file sys/dev/acpica/acpi_cpu.c at the end of acpi_cpu_notify >>> > (a per cpu notification handler), called when _CST objects changing, >>> > global cpu_cx_count is set to the greatest value of all sc->cpu_cx_co= unt >>> > per-cpu variables. That could result in a panic as David reported, >>> > because that lets to invoke acpi_cpu_global_cx_lowest_sysctl from >>> > /etc/rc.d/power_profile, when AC adapter is unplugged, =A0with a valu= e >>> > that not all the CPUs could handle in the acpi_cpu_idle. >>> > The patch also change global cpu_cx_lowest according to new value of >>> > global cpu_cx_count if needed. >>> > >>> > David Demelier made a great work to test every patch I sent him >>> > to identify the source of the problem. >>> > >>> > Please, let me know your comments and possibly commit the patch >>> > if you think is good enough. >>> >>> As jhb@ pointed me out in private with the previous patch a CPU could >>> never enter in the >>> lowest Cx-state even if it gained. >>> So I'd like to propose this new solution. >>> When hw.acpi.cpu.cx_lowest sysctl is set, the global handler in >>> sys/dev/acpi_cpu.c >>> will set the greatest sc->cpu_cx_lowest value supported by the CPU and >>> not the same >>> value for all CPUs. >>> Later, when CPU, possibly gain new Cx-states, the acpi_cpu_notify >>> handler will set >>> sc->cpu_cx_lowest accordingly with global cx_lowest and the Cx-states >>> supported by >>> the CPU. >>> >>> Now I think that /etc/rc.d/power_profile script has a problem but that >>> is a different story. >>> The script select the lowest_value only querying cx-states of the dev.c= pu.0. >>> If different CPUs may have different Cx-states, the script should use >>> as lowest_value the >>> lowest value between all the CPUs. >> >> Yes. >> >>> Please, let me know your comments and possibly commit the patch >>> if you think is good enough. >> >> I think this is a good compromise for now. >> >> -- >> John Baldwin >> > > Thanks for Giovanni's patience and work, he made a lot of research to > solve this little problem :-). > > Is there a chance that this patch appears in 8.1-RELEASE ? > > Kind regards. > > -- > Demelier David > Someone would have to discuss with the Release Engineering team, but it would be cool :) -Brandon From owner-freebsd-stable@FreeBSD.ORG Sat Jun 12 22:49:57 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA1A01065673 for ; Sat, 12 Jun 2010 22:49:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7A4CE8FC12 for ; Sat, 12 Jun 2010 22:49:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALurE0yDaFvG/2dsb2JhbACefnG9SYUaBA X-IronPort-AV: E=Sophos;i="4.53,409,1272859200"; d="scan'208";a="80454134" Received: from amazon.cs.uoguelph.ca ([131.104.91.198]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 12 Jun 2010 18:49:55 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 96A78210156; Sat, 12 Jun 2010 18:49:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at amazon.cs.uoguelph.ca Received: from amazon.cs.uoguelph.ca ([127.0.0.1]) by localhost (amazon.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hePH4FGH41pH; Sat, 12 Jun 2010 18:49:55 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id DAA6F210119; Sat, 12 Jun 2010 18:49:55 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o5CN6B728867; Sat, 12 Jun 2010 19:06:11 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sat, 12 Jun 2010 19:06:11 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Kostik Belousov In-Reply-To: <20100612150915.GN13238@deviant.kiev.zoral.com.ua> Message-ID: References: <20100606144443.GA50876@emmi.physik-pool.tu-berlin.de> <8639wsk4t1.fsf@kopusha.home.net> <20100612141549.GM13238@deviant.kiev.zoral.com.ua> <20100612150915.GN13238@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Leon Me??ner , freebsd-stable@freebsd.org, Mikolaj Golub Subject: Re: Re: Re: freeBSD nullfs together with nfs and "silly rename" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2010 22:49:57 -0000 On Sat, 12 Jun 2010, Kostik Belousov wrote: > > Yes, I hoped that Mikolaj ends up with something similar :). Please note > that this is racy, since we cannot know why usecount is greater then 1. > This might cause the silly rename to kick in some time where it should > not, but the race is rare. > I'd say that having silly rename happen once in a while for unlink when it doesn't have to happen is better than having the file deleted on the server while it is still open on the client. rick From owner-freebsd-stable@FreeBSD.ORG Sat Jun 12 22:54:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D793A106566B for ; Sat, 12 Jun 2010 22:54:03 +0000 (UTC) (envelope-from lynx.ripe@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A39248FC0C for ; Sat, 12 Jun 2010 22:54:03 +0000 (UTC) Received: by iwn7 with SMTP id 7so3271121iwn.13 for ; Sat, 12 Jun 2010 15:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=rwbyYWhIzhjn7zu71j9YbbZ5DZX2rKLwL5kxuwqsAc4=; b=pnUb2+zdcYXuXPMhsaOTHBzZ0KGBrbTDSvZSoE6at7mfAGutDoYPjMsFkFB3IF41Yv kaPuKgxbm5Ap9Qn8mz4WXoIzp1MvEPd+Hp9AQDjz+QNAlt3inAftpGWrxWj1ycGxqwkq w8lOE2ftMfhaOH5DSIhcxChnovSZfTvFteHA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=fq7Yn72A2MjRQVsJqLbJ03R0r3i+FnhMEj4ANoBQCBv1zT67jTBv9ALIgsuGaz2a7J xS4lA2MNzn0QvlAUCoQudrYJxwm9MGma9YZiEeYm2nP/fNCflurWQkMMKg4VB2SLQLGv b4zTjl5zw27C9PH3xJCOXQZidOLnRXcUVoBCQ= MIME-Version: 1.0 Received: by 10.231.157.205 with SMTP id c13mr3943783ibx.53.1276381612882; Sat, 12 Jun 2010 15:26:52 -0700 (PDT) Received: by 10.231.146.199 with HTTP; Sat, 12 Jun 2010 15:26:52 -0700 (PDT) Date: Sun, 13 Jun 2010 01:26:52 +0300 Message-ID: From: Dmitry Pryanishnikov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: nfsv4_server_enable="YES": link_elf: symbol svcpool_destroy undefined X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2010 22:54:03 -0000 Hello! I'm trying to start the experimental NFSv4 server in RELENG_8 w/o building it into the kernel, as nfsv4(4) suggests: ... or start mountd(8) and nfsd(8) with the ``-e'' option to force use of the experimental server. The nfsuserd(8) daemon must also be running. This will occur if nfs_server_enable="YES" nfsv4_server_enable="YES" nfsuserd_enable="YES" are set in rc.conf(5). However, mountd fails to start nfsd; the same problem exists when doing it by hands: "kldload nfsd" gives kernel: link_elf: symbol svcpool_destroy undefined error. Can this problem be solved w/o building kernel with "options NFSD"? -- Sincerely, Dmitry nic-hdl: LYNX-RIPE