From jb at what-creek.com Mon Sep 1 01:52:59 2008 From: jb at what-creek.com (John Birrell) Date: Mon Sep 1 01:53:08 2008 Subject: Unresponsive after dtrace In-Reply-To: References: Message-ID: <20080901015258.GA56694@what-creek.com> On Sun, Aug 31, 2008 at 06:35:16AM -0500, Wes Morgan wrote: > I know this has been reported already, but I want to give a "me too". > After installing a new world and kernel from the tree yesterday afternoon, > I let my system run all night. This morning everything was extremely > sluggish and unresponsive. According to top, which I thankfully left > running, processes were going in and out of "*kmem_" (obviously > truncated). CPU usage was 80+% system and load averages were around 5.4. > The only changes I made to my system besides upgrading were to include the > options KDB, DDB and STACK in my kernel for zfs functionality. > Unfortunately, I cannot try without those options since my root is zfs. > Booting a kernel from 8/20 works fine. Wes, will you please try removing "#define KMEM_DEBUG" from: src/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c This is the likely cause of the performance problems you are seeing. It is also the reason why you needed to add DDB, DBB and stack to the kernel. The quickest way to try this is to just build the 'opensolaris' kernel module: (keep a copy of your current /boot/kernel) cd src/sys/modules/opensolaris make obj && make depend && make all && make install -- John Birrell From jb at what-creek.com Mon Sep 1 02:15:29 2008 From: jb at what-creek.com (John Birrell) Date: Mon Sep 1 02:15:36 2008 Subject: ZFS performance issues (solved?!) Message-ID: <20080901021528.GB56694@what-creek.com> For those people experiencing a performance degradation since the DTrace import, please update your copy of src/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c by either cvsup of direct edit to remove "#define KMEM_DEBUG". You only need to rebuild the opensolaris kernel module after this change. The code is shared between ZFS and DTrace via the opensolaris kernel module. This is also the reason why you found it necessary to add KDB, DDB and STACK to your kernel. After removing KMEM_DEBUG, you won't need those. Please confirm that this solves the problem you have been seeing. -- John Birrell From freebsdports at bindone.de Mon Sep 1 02:39:40 2008 From: freebsdports at bindone.de (Michael) Date: Mon Sep 1 02:39:48 2008 Subject: bin/121684: : dump(8) frequently hangs Message-ID: <48BB4FA6.2090708@bindone.de> Any progress here? Does anyone know if this will be fixed in 7.1 latest, or should we start looking for different backup solution (in this case I would suggest to remove dump from the source tree - having a backup tool that doesn't work is worse than having none). After upgrading we basically cannot backup our servers. Shouldn't this issue be on http://www.freebsd.org/releases/7.0R/errata.html? cheers michael From morganw at chemikals.org Mon Sep 1 03:45:25 2008 From: morganw at chemikals.org (Wes Morgan) Date: Mon Sep 1 03:45:32 2008 Subject: Unresponsive after dtrace In-Reply-To: <20080901015258.GA56694@what-creek.com> References: <20080901015258.GA56694@what-creek.com> Message-ID: On Mon, 1 Sep 2008, John Birrell wrote: > On Sun, Aug 31, 2008 at 06:35:16AM -0500, Wes Morgan wrote: >> I know this has been reported already, but I want to give a "me too". >> After installing a new world and kernel from the tree yesterday afternoon, >> I let my system run all night. This morning everything was extremely >> sluggish and unresponsive. According to top, which I thankfully left >> running, processes were going in and out of "*kmem_" (obviously >> truncated). CPU usage was 80+% system and load averages were around 5.4. >> The only changes I made to my system besides upgrading were to include the >> options KDB, DDB and STACK in my kernel for zfs functionality. >> Unfortunately, I cannot try without those options since my root is zfs. >> Booting a kernel from 8/20 works fine. > > Wes, will you please try removing "#define KMEM_DEBUG" from: > > src/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c > > This is the likely cause of the performance problems you are seeing. It > is also the reason why you needed to add DDB, DBB and stack to the kernel. > > The quickest way to try this is to just build the 'opensolaris' kernel module: > > (keep a copy of your current /boot/kernel) > cd src/sys/modules/opensolaris > make obj && make depend && make all && make install Everything compiled with my original kern config (no STACK etc). I'll let it go for a bit and see, but I don't see any processes going into "kmem_" in top yet. From tinderbox at freebsd.org Mon Sep 1 06:47:57 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Sep 1 06:48:06 2008 Subject: [releng_7 tinderbox] failure on i386/i386 Message-ID: <20080901064753.888AB1B5078@freebsd-stable.sentex.ca> TB --- 2008-09-01 05:28:34 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-09-01 05:28:34 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2008-09-01 05:28:34 - cleaning the object tree TB --- 2008-09-01 05:29:00 - cvsupping the source tree TB --- 2008-09-01 05:29:00 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2008-09-01 05:29:08 - building world (CFLAGS=-O2 -pipe) TB --- 2008-09-01 05:29:08 - cd /src TB --- 2008-09-01 05:29:08 - /usr/bin/make -B buildworld >>> World build started on Mon Sep 1 05:29:10 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Sep 1 06:35:39 UTC 2008 TB --- 2008-09-01 06:35:39 - generating LINT kernel config TB --- 2008-09-01 06:35:39 - cd /src/sys/i386/conf TB --- 2008-09-01 06:35:39 - /usr/bin/make -B LINT TB --- 2008-09-01 06:35:39 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-09-01 06:35:39 - cd /src TB --- 2008-09-01 06:35:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Sep 1 06:35:39 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/ip_gre.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/ip_id.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/in_mcast.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/netinet/in_pcb.c cc1: warnings being treated as errors /src/sys/netinet/in_pcb.c: In function 'inp_wunlock_assert': /src/sys/netinet/in_pcb.c:1342: warning: implicit declaration of function 'INP_WUNLOCK_ASSERT' /src/sys/netinet/in_pcb.c:1342: warning: nested extern declaration of 'INP_WUNLOCK_ASSERT' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-01 06:47:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-01 06:47:53 - ERROR: failed to build lint kernel TB --- 2008-09-01 06:47:53 - tinderbox aborted TB --- 3885.15 user 404.93 system 4759.10 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full From hlh at restart.be Mon Sep 1 07:39:06 2008 From: hlh at restart.be (Henri Hennebert) Date: Mon Sep 1 07:39:13 2008 Subject: ZFS performance issues (solved?!) In-Reply-To: <20080901021528.GB56694@what-creek.com> References: <20080901021528.GB56694@what-creek.com> Message-ID: <48BB9BF7.8090202@restart.be> John Birrell wrote: > For those people experiencing a performance degradation since the DTrace import, > please update your copy of src/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c > by either cvsup of direct edit to remove "#define KMEM_DEBUG". > > You only need to rebuild the opensolaris kernel module after this change. The code > is shared between ZFS and DTrace via the opensolaris kernel module. > > This is also the reason why you found it necessary to add KDB, DDB and STACK to > your kernel. After removing KMEM_DEBUG, you won't need those. > > Please confirm that this solves the problem you have been seeing. Great, now everything is back to normal Thanks Henri > > -- > John Birrell > _______________________________________________ > 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 tinderbox at freebsd.org Mon Sep 1 08:11:39 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Sep 1 08:11:57 2008 Subject: [releng_7 tinderbox] failure on i386/pc98 Message-ID: <20080901081135.1F5051B5078@freebsd-stable.sentex.ca> TB --- 2008-09-01 06:47:53 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-09-01 06:47:53 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2008-09-01 06:47:53 - cleaning the object tree TB --- 2008-09-01 06:48:16 - cvsupping the source tree TB --- 2008-09-01 06:48:16 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2008-09-01 06:48:26 - building world (CFLAGS=-O2 -pipe) TB --- 2008-09-01 06:48:26 - cd /src TB --- 2008-09-01 06:48:26 - /usr/bin/make -B buildworld >>> World build started on Mon Sep 1 06:48:28 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Sep 1 07:57:48 UTC 2008 TB --- 2008-09-01 07:57:48 - generating LINT kernel config TB --- 2008-09-01 07:57:48 - cd /src/sys/pc98/conf TB --- 2008-09-01 07:57:48 - /usr/bin/make -B LINT TB --- 2008-09-01 07:57:48 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-09-01 07:57:48 - cd /src TB --- 2008-09-01 07:57:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Sep 1 07:57:48 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -pg -mprofiler-epilogue vers.c linking kernel in_pcb.o(.text+0xbba): In function `inp_wunlock_assert': : undefined reference to `INP_WUNLOCK_ASSERT' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-01 08:11:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-01 08:11:34 - ERROR: failed to build lint kernel TB --- 2008-09-01 08:11:34 - tinderbox aborted TB --- 3956.26 user 411.37 system 5020.91 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-pc98.full From tinderbox at freebsd.org Mon Sep 1 08:40:37 2008 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Sep 1 08:40:55 2008 Subject: [releng_7 tinderbox] failure on ia64/ia64 Message-ID: <20080901084032.56BCE1B5078@freebsd-stable.sentex.ca> TB --- 2008-09-01 06:55:05 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-09-01 06:55:05 - starting RELENG_7 tinderbox run for ia64/ia64 TB --- 2008-09-01 06:55:05 - cleaning the object tree TB --- 2008-09-01 06:55:19 - cvsupping the source tree TB --- 2008-09-01 06:55:19 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/ia64/ia64/supfile TB --- 2008-09-01 06:55:25 - building world (CFLAGS=-O2 -pipe) TB --- 2008-09-01 06:55:25 - cd /src TB --- 2008-09-01 06:55:25 - /usr/bin/make -B buildworld >>> World build started on Mon Sep 1 06:55:26 UTC 2008 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Sep 1 08:27:05 UTC 2008 TB --- 2008-09-01 08:27:05 - generating LINT kernel config TB --- 2008-09-01 08:27:05 - cd /src/sys/ia64/conf TB --- 2008-09-01 08:27:05 - /usr/bin/make -B LINT TB --- 2008-09-01 08:27:05 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2008-09-01 08:27:05 - cd /src TB --- 2008-09-01 08:27:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Sep 1 08:27:05 UTC 2008 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/netinet/ip_gre.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/netinet/ip_id.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/netinet/in_mcast.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/netinet/in_pcb.c cc1: warnings being treated as errors /src/sys/netinet/in_pcb.c: In function 'inp_wunlock_assert': /src/sys/netinet/in_pcb.c:1342: warning: implicit declaration of function 'INP_WUNLOCK_ASSERT' /src/sys/netinet/in_pcb.c:1342: warning: nested extern declaration of 'INP_WUNLOCK_ASSERT' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-09-01 08:40:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-09-01 08:40:32 - ERROR: failed to build lint kernel TB --- 2008-09-01 08:40:32 - tinderbox aborted TB --- 5248.51 user 409.09 system 6326.45 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-ia64-ia64.full From takeda at takeda.tk Mon Sep 1 09:22:10 2008 From: takeda at takeda.tk (=?utf-8?Q?Derek_Kuli=C5=84ski?=) Date: Mon Sep 1 09:22:19 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: <48BB4FA6.2090708@bindone.de> References: <48BB4FA6.2090708@bindone.de> Message-ID: <1188558750.20080901020711@takeda.tk> Hello Michael, Sunday, August 31, 2008, 7:12:54 PM, you wrote: > Any progress here? Does anyone know if this will be fixed in 7.1 latest, > or should we start looking for different backup solution (in this case I > would suggest to remove dump from the source tree - having a backup tool > that doesn't work is worse than having none). After upgrading we > basically cannot backup our servers. > Shouldn't this issue be on > http://www.freebsd.org/releases/7.0R/errata.html? I was generally upgrading to new minor version each time it appeared, since usually the minor version number change meant that more bugs were fixed and the whole OS was more started. Now, you honestly scared me. Actually I noticed some regression with dump/restore since 6.x and 7.0 (I reported some bugs, but I don't think there was much concern about them). I don't get why nobody cares about this, I think having a reliable backup is one of the most important things. Now I'm honestly a bit scared about it (even if it will be fixed before 7.1, I'm not sure I'll hurry with the update). -- Best regards, Derek mailto:takeda@takeda.tk Scandisk is now checking your hard drive. You can start praying. From morganw at chemikals.org Mon Sep 1 10:48:39 2008 From: morganw at chemikals.org (Wes Morgan) Date: Mon Sep 1 10:48:45 2008 Subject: ZFS performance issues (solved?!) In-Reply-To: <20080901021528.GB56694@what-creek.com> References: <20080901021528.GB56694@what-creek.com> Message-ID: On Mon, 1 Sep 2008, John Birrell wrote: > For those people experiencing a performance degradation since the DTrace > import, please update your copy of > src/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c by either cvsup > of direct edit to remove "#define KMEM_DEBUG". > > You only need to rebuild the opensolaris kernel module after this > change. The code is shared between ZFS and DTrace via the opensolaris > kernel module. > > This is also the reason why you found it necessary to add KDB, DDB and > STACK to your kernel. After removing KMEM_DEBUG, you won't need those. > > Please confirm that this solves the problem you have been seeing. 8 or so hours later and everything is good here. One other suggestion, the "opensolaris" module that is now required for zfs is not mentioned anywhere in UPDATING. Users of "MODULES_OVERRIDE" will likely find themselves with a system that will not boot without manual intervention, sometimes even requiring a live cd. A headsup or warning would probably be appreciated by other zfs'ers. From koitsu at FreeBSD.org Mon Sep 1 10:53:00 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 1 10:53:08 2008 Subject: ZFS performance issues (solved?!) In-Reply-To: References: <20080901021528.GB56694@what-creek.com> Message-ID: <20080901105257.GA4269@icarus.home.lan> On Mon, Sep 01, 2008 at 05:48:34AM -0500, Wes Morgan wrote: > On Mon, 1 Sep 2008, John Birrell wrote: > >> For those people experiencing a performance degradation since the >> DTrace import, please update your copy of >> src/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c by either cvsup >> of direct edit to remove "#define KMEM_DEBUG". >> >> You only need to rebuild the opensolaris kernel module after this >> change. The code is shared between ZFS and DTrace via the opensolaris >> kernel module. >> >> This is also the reason why you found it necessary to add KDB, DDB and >> STACK to your kernel. After removing KMEM_DEBUG, you won't need those. >> >> Please confirm that this solves the problem you have been seeing. > > 8 or so hours later and everything is good here. > > One other suggestion, the "opensolaris" module that is now required for > zfs is not mentioned anywhere in UPDATING. Users of "MODULES_OVERRIDE" > will likely find themselves with a system that will not boot without > manual intervention, sometimes even requiring a live cd. A headsup or > warning would probably be appreciated by other zfs'ers. I second this motion. Upon rebuilding my system this morning, I was surprised to see the kernel printf()s about OpenSolaris and CDDL, and could find no mention of what purpose the module served. I'm assuming it's a module with some centralised code-pieces that DTrace and ZFS share, but I don't have any confirmation of this. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From mike at sentex.net Mon Sep 1 13:36:20 2008 From: mike at sentex.net (Mike Tancsa) Date: Mon Sep 1 13:36:27 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: <1188558750.20080901020711@takeda.tk> References: <48BB4FA6.2090708@bindone.de> <1188558750.20080901020711@takeda.tk> Message-ID: <200809011336.m81Da5BT046532@lava.sentex.ca> At 05:07 AM 9/1/2008, Derek Kuli??ski wrote: >Now I'm honestly a bit scared about it (even if it will be fixed >before 7.1, I'm not sure I'll hurry with the update). There have been a number of commits to releng_7 that fixed dump issues for me. A box that used to regularly exhibit hung dump processes have been working fine since April. e.g. a kernel from 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed Apr 30 does weekly level 0 dumps and daily differential dumps on the file systems below without issue % df -i Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/twed0s1a 2026030 284346 1579602 15% 2937 279685 1% / devfs 1 1 0 100% 0 0 100% /dev /dev/twed0s1d 5077038 575828 4095048 12% 1197 658257 0% /tmp /dev/twed0s1e 20308398 11072840 7610888 59% 1065406 1572416 40% /usr /dev/twed0s1f 20308398 13275050 5408678 71% 13750 2624072 1% /var /dev/twed0s1g 246875258 186393906 40731332 82% 9118036 22794922 29% /zoo However, you should test and make sure it works for you. ---Mike ---Mike From arnaud.houdelette at tzim.net Mon Sep 1 15:21:58 2008 From: arnaud.houdelette at tzim.net (Arnaud Houdelette) Date: Mon Sep 1 15:22:10 2008 Subject: ZFS performance issues (solved?!) In-Reply-To: References: <20080901021528.GB56694@what-creek.com> Message-ID: <48BC0897.8030602@tzim.net> Wes Morgan a ?crit : >
On Mon, 1 > Sep 2008, John Birrell wrote: > >> For those people experiencing a performance degradation since the >> DTrace import, please update your copy of >> src/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c by either >> cvsup of direct edit to remove "#define KMEM_DEBUG". >> >> You only need to rebuild the opensolaris kernel module after this >> change. The code is shared between ZFS and DTrace via the opensolaris >> kernel module. >> >> This is also the reason why you found it necessary to add KDB, DDB >> and STACK to your kernel. After removing KMEM_DEBUG, you won't need >> those. >> >> Please confirm that this solves the problem you have been seeing. > > 8 or so hours later and everything is good here. > > One other suggestion, the "opensolaris" module that is now required > for zfs is not mentioned anywhere in UPDATING. Users of > "MODULES_OVERRIDE" will likely find themselves with a system that will > not boot without manual intervention, sometimes even requiring a live > cd. A headsup or warning would probably be appreciated by other zfs'ers. I had really bad performance before removing the line. I had to disable zil on zfs (my /usr/src is on zfs) to be able to recompile, as one of the zil process was eating up nearly all off the CPU. After rebuild/install kernel, no problems anymore. Thanks. I second the above suggestion about opensolaris. There's no mention anywhere of this module (or at least, I didn'it find one before), on UPDATING nor on the list of what this module is for ? From oberman at es.net Mon Sep 1 16:00:18 2008 From: oberman at es.net (Kevin Oberman) Date: Mon Sep 1 16:00:26 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: Your message of "Mon, 01 Sep 2008 09:36:11 EDT." <200809011336.m81Da5BT046532@lava.sentex.ca> Message-ID: <20080901160013.0005F4500F@ptavv.es.net> > Date: Mon, 01 Sep 2008 09:36:11 -0400 > From: Mike Tancsa > Sender: owner-freebsd-stable@freebsd.org > > At 05:07 AM 9/1/2008, Derek KuliƄski wrote: > > >Now I'm honestly a bit scared about it (even if it will be fixed > >before 7.1, I'm not sure I'll hurry with the update). > > There have been a number of commits to releng_7 > that fixed dump issues for me. A box that used > to regularly exhibit hung dump processes have > been working fine since April. e.g. a kernel from > 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed Apr 30 > > does weekly level 0 dumps and daily differential > dumps on the file systems below without issue > % df -i > Filesystem 1K-blocks Used Avail > Capacity iused ifree %iused Mounted on > /dev/twed0s1a 2026030 284346 1579602 15% 2937 279685 1% / > devfs 1 1 0 > 100% 0 0 100% /dev > /dev/twed0s1d 5077038 575828 4095048 > 12% 1197 658257 0% /tmp > /dev/twed0s1e 20308398 11072840 7610888 > 59% 1065406 1572416 40% /usr > /dev/twed0s1f 20308398 13275050 5408678 > 71% 13750 2624072 1% /var > /dev/twed0s1g 246875258 > 186393906 40731332 82% 9118036 22794922 29% /zoo > > However, you should test and make sure it works for you. I have a 7-Stable system which has not been able to successfully dump(8) for about 2 months. Since it contains almost no important data that is subject to change, it's not too big a deal, but I worry that other systems might start showing the same problems. I have no idea why it's failing, though, and I have spent little effort in troubleshooting it. I'm running 3 week old stable and I'll be updating to today's RELENG_7 later today. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080901/b57ad3a8/attachment.pgp From mike at sentex.net Mon Sep 1 16:06:45 2008 From: mike at sentex.net (Mike Tancsa) Date: Mon Sep 1 16:06:57 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: <20080901160013.0005F4500F@ptavv.es.net> References: <20080901160013.0005F4500F@ptavv.es.net> Message-ID: <200809011606.m81G6Sfq047073@lava.sentex.ca> At 12:00 PM 9/1/2008, Kevin Oberman wrote: >I have a 7-Stable system which has not been able to successfully dump(8) >for about 2 months. Since it contains almost no important data that is >subject to change, it's not too big a deal, but I worry that other >systems might start showing the same problems. How does it actually fail ? Do the dump processes stall, or does it error out ? Did you fsck the file system ? I have seen dump fail when the file system is dirty. Also, I am not using snapshots. The flags I use are /sbin/dump -C24 -${BACKUP_LEVEL}anuf - /zoo | /usr/bin/gzip | dd of=/backup/zoo-level-${BACKUP_LEVEL}.gz ---Mike From yds at CoolRat.org Mon Sep 1 16:32:07 2008 From: yds at CoolRat.org (Yarema) Date: Mon Sep 1 16:32:14 2008 Subject: ZFS performance issues (solved?!) In-Reply-To: <20080901021528.GB56694@what-creek.com> References: <20080901021528.GB56694@what-creek.com> Message-ID: <48BC1904.2080503@CoolRat.org> John Birrell wrote: > For those people experiencing a performance degradation since the DTrace import, > please update your copy of src/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c > by either cvsup of direct edit to remove "#define KMEM_DEBUG". > > You only need to rebuild the opensolaris kernel module after this change. The code > is shared between ZFS and DTrace via the opensolaris kernel module. > > This is also the reason why you found it necessary to add KDB, DDB and STACK to > your kernel. After removing KMEM_DEBUG, you won't need those. > > Please confirm that this solves the problem you have been seeing. Yes! Last night doing a csup would peg the Sys CPU usage at 100%. After rebuilding the opensolaris kernel module everything is back to normal. There's a csup running as I type this and the system is upwards of 90%Idle. Thanks, Yarema From freebsd-stable at epcdirect.co.uk Mon Sep 1 17:00:03 2008 From: freebsd-stable at epcdirect.co.uk (Lawrence Farr) Date: Mon Sep 1 17:00:10 2008 Subject: Anyone else seeing make release failing? In-Reply-To: <20080901160013.0005F4500F@ptavv.es.net> References: Your message of "Mon, 01 Sep 2008 09:36:11 EDT." <200809011336.m81Da5BT046532@lava.sentex.ca> <20080901160013.0005F4500F@ptavv.es.net> Message-ID: <076e01c90c51$9e226bb0$da674310$@co.uk> I build releases nightly, and have been getting (snip) + shift + FSLABEL=minimum3 + shift + [ 4320 -eq 0 -a minimum3 = auto ] + rm -f /R/stage/mfsroot/mfsroot + dd of=/R/stage/mfsroot/mfsroot if=/dev/zero count=4320 bs=1k uname -r + [ -f /R/stage/trees/base/boot/boot ] BOOT=-B -b + /R/stage/trees/base/boot/boot dofs_md [ x != x ] mdconfig -a -t vnode + -f /R/stage/mfsroot/mfsroot mdconfig: failed to load geom_md module: No such file or directory + MDDEVICE= + umount /dev For a few days now. The module exists, but refuses to load, as I guess it's already in Generic? kldload: can't load geom_md: File exists Do I just need a newer -STABLE than FreeBSD 7.0-STABLE #1: Mon Mar 17 13:20:41 GMT 2008? From oberman at es.net Mon Sep 1 20:13:27 2008 From: oberman at es.net (Kevin Oberman) Date: Mon Sep 1 20:13:39 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: Your message of "Mon, 01 Sep 2008 12:06:35 EDT." <200809011606.m81G6Sfq047073@lava.sentex.ca> Message-ID: <20080901201324.191594501A@ptavv.es.net> > Date: Mon, 01 Sep 2008 12:06:35 -0400 > From: Mike Tancsa > > At 12:00 PM 9/1/2008, Kevin Oberman wrote: > > >I have a 7-Stable system which has not been able to successfully dump(8) > >for about 2 months. Since it contains almost no important data that is > >subject to change, it's not too big a deal, but I worry that other > >systems might start showing the same problems. > > How does it actually fail ? Do the dump processes stall, or does it > error out ? Did you fsck the file system ? I have seen dump fail > when the file system is dirty. Also, I am not using snapshots. The > flags I use are > > /sbin/dump -C24 -${BACKUP_LEVEL}anuf - /zoo | /usr/bin/gzip | dd > of=/backup/zoo-level-${BACKUP_LEVEL}.gz Mike, Thanks for the suggestion. I'm pretty sure I have done a full fsck, but not positive, so I will try one tomorrow. The system is in a location which is unmanned today due to the holiday, and a full fsck kind of needs either a human or remote console. I have tried both with and without snapshots, so those don't seem to be the problem. In any case, I'll know more tomorrow. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080901/4b862812/attachment.pgp From takeda at takeda.tk Mon Sep 1 20:18:09 2008 From: takeda at takeda.tk (=?windows-1250?Q?Derek_Kuli=F1ski?=) Date: Mon Sep 1 20:18:16 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: <20080901201324.191594501A@ptavv.es.net> References: Your message of "Mon, 01 Sep 2008 12:06:35 EDT." <200809011606.m81G6Sfq047073@lava.sentex.ca> <20080901201324.191594501A@ptavv.es.net> Message-ID: <1559181345.20080901131750@takeda.tk> Hello Kevin, Monday, September 1, 2008, 1:13:24 PM, you wrote: > Thanks for the suggestion. I'm pretty sure I have done a full fsck, but > not positive, so I will try one tomorrow. The system is in a location > which is unmanned today due to the holiday, and a full fsck kind of needs > either a human or remote console. > I have tried both with and without snapshots, so those don't seem to be > the problem. > In any case, I'll know more tomorrow. You can also make a snapshot and run fsck on it. According to the documentation, if system is good state, then fsck on a snapshot should return no errors. I don't know how does it work the other way (i.e. if there are no errors shown, does that mean fs is ok?) -- Best regards, Derek mailto:takeda@takeda.tk Hey! It compiles! Ship it! From freebsdports at bindone.de Mon Sep 1 21:28:56 2008 From: freebsdports at bindone.de (Michael) Date: Mon Sep 1 21:29:04 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: <200809011336.m81Da5BT046532@lava.sentex.ca> References: <48BB4FA6.2090708@bindone.de> <1188558750.20080901020711@takeda.tk> <200809011336.m81Da5BT046532@lava.sentex.ca> Message-ID: <48BC5E90.1060900@bindone.de> Sorry to scare you, I was a little unhappy about dump hanging. Based on the cvs repository I wrote a little patch that combines two changes made by scott and jeff that works agains 7.0-RELEASE (looking at the commit logs scared me away from trying STABLE on production right now. After applying this patch I could run dumps successfully on seven machines where it hung before on every single attempt (use is at your own risk of course). cd /usr/src/sys/kern patch < /tmp/mysleepqueue.patch recompile and install kernel reboot Since I also found a fatal bug in ipv6 (panic on ping6) it might be better for you to wait for 7.1, for us there is no way back now. cheers michael Mike Tancsa wrote: > At 05:07 AM 9/1/2008, Derek Kuli??ski wrote: > >> Now I'm honestly a bit scared about it (even if it will be fixed >> before 7.1, I'm not sure I'll hurry with the update). > > There have been a number of commits to releng_7 that fixed dump issues > for me. A box that used to regularly exhibit hung dump processes have > been working fine since April. e.g. a kernel from > 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed Apr 30 > > does weekly level 0 dumps and daily differential dumps on the file > systems below without issue > % df -i > Filesystem 1K-blocks Used Avail Capacity iused ifree > %iused Mounted on > /dev/twed0s1a 2026030 284346 1579602 15% 2937 279685 > 1% / > devfs 1 1 0 100% 0 0 > 100% /dev > /dev/twed0s1d 5077038 575828 4095048 12% 1197 658257 0% > /tmp > /dev/twed0s1e 20308398 11072840 7610888 59% 1065406 1572416 40% > /usr > /dev/twed0s1f 20308398 13275050 5408678 71% 13750 2624072 1% > /var > /dev/twed0s1g 246875258 186393906 40731332 82% 9118036 22794922 > 29% /zoo > > However, you should test and make sure it works for you. > > ---Mike > > ---Mike -------------- next part -------------- --- subr_sleepqueue.c~ 2008-09-01 05:14:28.000000000 +0200 +++ subr_sleepqueue.c 2008-09-01 05:14:28.000000000 +0200 @@ -177,7 +177,7 @@ for (i = 0; i < SC_TABLESIZE; i++) { LIST_INIT(&sleepq_chains[i].sc_queues); mtx_init(&sleepq_chains[i].sc_lock, "sleepq chain", NULL, - MTX_SPIN); + MTX_SPIN | MTX_RECURSE); #ifdef SLEEPQUEUE_PROFILING snprintf(chain_name, sizeof(chain_name), "%d", i); chain_oid = SYSCTL_ADD_NODE(NULL, @@ -403,12 +403,15 @@ mtx_unlock(&ps->ps_mtx); } /* - * Lock sleepq chain before unlocking proc - * without this, we could lose a race. - */ + * Lock the per-process spinlock prior to dropping the PROC_LOCK + * to avoid a signal delivery race. PROC_LOCK, PROC_SLOCK, and + * thread_lock() are currently held in tdsignal(). + */ + PROC_SLOCK(p); mtx_lock_spin(&sc->sc_lock); PROC_UNLOCK(p); thread_lock(td); + PROC_SUNLOCK(p); if (ret == 0) { if (!(td->td_flags & TDF_INTERRUPT)) { sleepq_switch(wchan); From koitsu at FreeBSD.org Mon Sep 1 21:38:58 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 1 21:39:07 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: <20080901160013.0005F4500F@ptavv.es.net> References: <200809011336.m81Da5BT046532@lava.sentex.ca> <20080901160013.0005F4500F@ptavv.es.net> Message-ID: <20080901213856.GA17155@icarus.home.lan> On Mon, Sep 01, 2008 at 09:00:12AM -0700, Kevin Oberman wrote: > > Date: Mon, 01 Sep 2008 09:36:11 -0400 > > From: Mike Tancsa > > Sender: owner-freebsd-stable@freebsd.org > > > > At 05:07 AM 9/1/2008, Derek Kuli??ski wrote: > > > > >Now I'm honestly a bit scared about it (even if it will be fixed > > >before 7.1, I'm not sure I'll hurry with the update). > > > > There have been a number of commits to releng_7 > > that fixed dump issues for me. A box that used > > to regularly exhibit hung dump processes have > > been working fine since April. e.g. a kernel from > > 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed Apr 30 > > > > does weekly level 0 dumps and daily differential > > dumps on the file systems below without issue > > % df -i > > Filesystem 1K-blocks Used Avail > > Capacity iused ifree %iused Mounted on > > /dev/twed0s1a 2026030 284346 1579602 15% 2937 279685 1% / > > devfs 1 1 0 > > 100% 0 0 100% /dev > > /dev/twed0s1d 5077038 575828 4095048 > > 12% 1197 658257 0% /tmp > > /dev/twed0s1e 20308398 11072840 7610888 > > 59% 1065406 1572416 40% /usr > > /dev/twed0s1f 20308398 13275050 5408678 > > 71% 13750 2624072 1% /var > > /dev/twed0s1g 246875258 > > 186393906 40731332 82% 9118036 22794922 29% /zoo > > > > However, you should test and make sure it works for you. > > I have a 7-Stable system which has not been able to successfully dump(8) > for about 2 months. Since it contains almost no important data that is > subject to change, it's not too big a deal, but I worry that other > systems might start showing the same problems. > > I have no idea why it's failing, though, and I have spent little effort > in troubleshooting it. I'm running 3 week old stable and I'll be > updating to today's RELENG_7 later today. Can someone explain what "dump frequently hangs" actually means? Does it lock up the entire machine indefinitely (and if so, how long did you wait for it to (hopefully) recover)? Or does it more or less "deadlock" the machine, making it generally unusable, until the dump is completely finished? If the latter, I can confirm this problem -- which is why we moved all of our production systems away from using dump on UFS2 to simply using rsnapshot[1]. I'll try to find the thread (it was a year or so ago) where a developer told me more or less what was going on. The problem was that UFS2 snapshot generation, over time, becomes slower and slower to generate (this is what dump does on UFS2 systems, with or without the -L flag), and is a known design issue. If anything, this issue makes ZFS incredibly important with regards to -STABLE, where its snapshot generation for backups does not behave this was; fast and very easily managable. [1]: rsync is great for backups, and very fast, but there's the issue of modifying atimes. I committed a patch to ports/net/rsync which adds an --atimes flag, except its behaviour is not what you'd expect: the file which was copied, at the destination, has the correct atime (of the source), but the source itself ends up getting its atime modified, so you're essentially destroying the atime data on the source. This is a problem when it comes to programs which use atime to discern things, such as classic UNIX mailboxes/mbox. "Um, why does mutt say I don't have any new mail when I do??" In our case, the only person using classic UNIX mboxes with a mail client local to the machine was me, so I ended up migrating my procmail rules and data to Maildir using mutt, solving the problem entirely. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Mon Sep 1 22:27:42 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 1 22:27:49 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: <20080901213856.GA17155@icarus.home.lan> References: <200809011336.m81Da5BT046532@lava.sentex.ca> <20080901160013.0005F4500F@ptavv.es.net> <20080901213856.GA17155@icarus.home.lan> Message-ID: <20080901222738.GA17793@icarus.home.lan> On Mon, Sep 01, 2008 at 02:38:56PM -0700, Jeremy Chadwick wrote: > ... I'll try to find the thread (it was a year or so ago) > where a developer told me more or less what was going on. The problem > was that UFS2 snapshot generation, over time, becomes slower and slower > to generate (this is what dump does on UFS2 systems, with or without the > -L flag), and is a known design issue. The issue I'm describing above is fully discussed here. Be sure to read the threads I reference in my mail, as well as Eric Anderson and Peter Jeremy's replies: http://lists.freebsd.org/pipermail/freebsd-hackers/2007-October/021985.html There's also a statement from Kris Kennaway in one of the above referenced threads, who states that "UFS2 snapshots (e.g. dump -L) were not intended to be used this way": http://lists.freebsd.org/pipermail/freebsd-stable/2007-January/032070.html In that same thread, Doug Ambrisko provided a patch which supposedly made UFS2 snapshot generation significantly better for him, specifically with regards to dump "getting wedged": http://lists.freebsd.org/pipermail/freebsd-stable/2007-January/032250.html Another thread discussing this problem ("lock up when dump is used"): http://lists.freebsd.org/pipermail/freebsd-stable/2008-June/042823.html And finally, an issue I encountered (rebooting a system in the middle of dump -L) was documented here: http://lists.freebsd.org/pipermail/freebsd-stable/2007-September/036916.html I'll be adding these issues to my FreeBSD wiki page momentarily. I think folks should reconsider use of dump when UFS2 filesystems are chosen. This goes against what the O'Reilly "Backup & Recovery" book concludes, and what Elizabeth Zwicky concluded in her backup/recovery torture tests (albeit 17 years ago, but the document is referenced in the FreeBSD handbook itself): http://www.coredumps.de/doc/dump/zwicky/testdump.doc.html If you're using older UFS1 filesystems, dump should be fine, as there's no snapshot generation supported there. If the problem is truly with UFS2 snapshot generation, then I'd like to know why dump bothers with spitting out a warning when -L is used, more or less inducing people to modify their scripts to use the -L flag. The commit which induced this behaviour is from November 2002, and modified in April 2004 to advocate -L usage even more: http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/dump/main.c.diff?r1=1.42;r2=1.43;f=h http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/dump/main.c.diff?r1=1.57;r2=1.58;f=h -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From mike at sentex.net Mon Sep 1 22:31:45 2008 From: mike at sentex.net (Mike Tancsa) Date: Mon Sep 1 22:31:53 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: <20080901213856.GA17155@icarus.home.lan> References: <200809011336.m81Da5BT046532@lava.sentex.ca> <20080901160013.0005F4500F@ptavv.es.net> <20080901213856.GA17155@icarus.home.lan> Message-ID: <200809012231.m81MVTJK048487@lava.sentex.ca> At 05:38 PM 9/1/2008, Jeremy Chadwick wrote: >Can someone explain what "dump frequently hangs" actually means? > >Does it lock up the entire machine indefinitely (and if so, how long did >you wait for it to (hopefully) recover)? As in the process hanging. For me, it was fixed quite some time ago. [zoo]# ps -auxlww | grep dump root 32093 0.0 3.8 39972 38036 ?? D Fri11PM 0:00.43 /sbin/dump -C24 0 1 0 20 0 pause root 73970 0.0 2.7 28708 26688 ?? D Thu11PM 0:00.14 /sbin/dump -C24 0 1 1 20 0 pause root 80852 0.0 3.8 39972 38000 ?? D 11:30PM 0:18.43 /sbin/dump -C24 0 1 0 20 0 pause root 98637 0.0 0.1 3308 1040 pd RL+ 8:20AM 0:00.00 grep dump 0 72305 0 96 0 - [zoo]# kill -9 80852 [zoo]# kill -9 80852 [zoo]# kill -9 80852 [zoo]# ps -auxlww | grep dump root 32093 0.0 3.8 39972 38036 ?? D Fri11PM 0:00.43 /sbin/dump -C24 0 1 0 20 0 pause root 73970 0.0 2.7 28708 26688 ?? D Thu11PM 0:00.14 /sbin/dump -C24 0 1 1 20 0 pause root 80852 0.0 3.8 39972 38000 ?? D 11:30PM 0:18.43 /sbin/dump -C24 0 1 0 20 0 pause root 98639 0.0 0.1 3308 1040 pd R+ 8:20AM 0:00.00 grep dump 0 72305 0 96 0 - [zoo]# >[1]: rsync is great for backups, and very fast, but there's the issue of >modifying atimes. I committed a patch to ports/net/rsync which adds an >--atimes flag, except its behaviour is not what you'd expect: the file >which was copied, at the destination, has the correct atime (of the >source), but the source itself ends up getting its atime modified, so >you're essentially destroying the atime data on the source. One of the reasons I dont use it for backups. Also its a pain with things like /dev and other special files. ---Mike From koitsu at FreeBSD.org Mon Sep 1 22:36:33 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 1 22:36:40 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: <20080901213856.GA17155@icarus.home.lan> References: <200809011336.m81Da5BT046532@lava.sentex.ca> <20080901160013.0005F4500F@ptavv.es.net> <20080901213856.GA17155@icarus.home.lan> Message-ID: <20080901223629.GA18346@icarus.home.lan> On Mon, Sep 01, 2008 at 02:38:56PM -0700, Jeremy Chadwick wrote: > The problem was that UFS2 snapshot generation, over time, becomes > slower and slower to generate (this is what dump does on UFS2 systems, > with or without the -L flag), and is a known design issue. Clarification: dump on UFS2 (without -L flag) will NOT generate a snapshot, but emits a nasty message telling you to use -L on live filesystems which are mounted r/w. I'm wondering if people experiencing this problem are using the -L flag or not (I'm betting most are). If you are, try removing it and see if things improve. But if I remember correctly, there's also a risk involved with this: not generating a snapshot on UFS2 means your dump could actually contain "half-written" files (e.g. when you recover, you might only have a partial file for something that was being written at the time of dump). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From torfinn.ingolfsen at broadpark.no Mon Sep 1 23:07:08 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Mon Sep 1 23:07:17 2008 Subject: trying to mount a write prptected zip disk panics the machine (unless the -r flag is used) In-Reply-To: <200808191715.54250.jhb@freebsd.org> References: <20080815235523.5b019915.torfinn.ingolfsen@broadpark.no> <200808181033.05680.jhb@freebsd.org> <20080818194400.70430d39.torfinn.ingolfsen@broadpark.no> <200808191715.54250.jhb@freebsd.org> Message-ID: <20080902004250.3b006e50.torfinn.ingolfsen@broadpark.no> On Tue, 19 Aug 2008 17:15:54 -0400 John Baldwin wrote: > That's right, but not the specific bug I am familiar with. :( Ok. The issue is now documented as PR i386/127029 http://www.freebsd.org/cgi/query-pr.cgi?pr=127029 No, I am not sure that this issue only relates to i386. But I haven't tested the zip drive elsewhere. -- Regards, Torfinn Ingolfsen, Norway From oberman at es.net Mon Sep 1 23:51:47 2008 From: oberman at es.net (Kevin Oberman) Date: Mon Sep 1 23:51:54 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: Your message of "Mon, 01 Sep 2008 14:38:56 PDT." <20080901213856.GA17155@icarus.home.lan> Message-ID: <20080901235144.4B53B4501A@ptavv.es.net> > Date: Mon, 1 Sep 2008 14:38:56 -0700 > From: Jeremy Chadwick > > On Mon, Sep 01, 2008 at 09:00:12AM -0700, Kevin Oberman wrote: > > > Date: Mon, 01 Sep 2008 09:36:11 -0400 > > > From: Mike Tancsa > > > Sender: owner-freebsd-stable@freebsd.org > > > > > > At 05:07 AM 9/1/2008, Derek Kuli??ski wrote: > > > > > > >Now I'm honestly a bit scared about it (even if it will be fixed > > > >before 7.1, I'm not sure I'll hurry with the update). > > > > > > There have been a number of commits to releng_7 > > > that fixed dump issues for me. A box that used > > > to regularly exhibit hung dump processes have > > > been working fine since April. e.g. a kernel from > > > 7.0-STABLE FreeBSD 7.0-STABLE #4: Wed Apr 30 > > > > > > does weekly level 0 dumps and daily differential > > > dumps on the file systems below without issue > > > % df -i > > > Filesystem 1K-blocks Used Avail > > > Capacity iused ifree %iused Mounted on > > > /dev/twed0s1a 2026030 284346 1579602 15% 2937 279685 1% / > > > devfs 1 1 0 > > > 100% 0 0 100% /dev > > > /dev/twed0s1d 5077038 575828 4095048 > > > 12% 1197 658257 0% /tmp > > > /dev/twed0s1e 20308398 11072840 7610888 > > > 59% 1065406 1572416 40% /usr > > > /dev/twed0s1f 20308398 13275050 5408678 > > > 71% 13750 2624072 1% /var > > > /dev/twed0s1g 246875258 > > > 186393906 40731332 82% 9118036 22794922 29% /zoo > > > > > > However, you should test and make sure it works for you. > > > > I have a 7-Stable system which has not been able to successfully dump(8) > > for about 2 months. Since it contains almost no important data that is > > subject to change, it's not too big a deal, but I worry that other > > systems might start showing the same problems. > > > > I have no idea why it's failing, though, and I have spent little effort > > in troubleshooting it. I'm running 3 week old stable and I'll be > > updating to today's RELENG_7 later today. > > Can someone explain what "dump frequently hangs" actually means? > > Does it lock up the entire machine indefinitely (and if so, how long did > you wait for it to (hopefully) recover)? > > Or does it more or less "deadlock" the machine, making it generally > unusable, until the dump is completely finished? > > If the latter, I can confirm this problem -- which is why we moved all > of our production systems away from using dump on UFS2 to simply using > rsnapshot[1]. I'll try to find the thread (it was a year or so ago) > where a developer told me more or less what was going on. The problem > was that UFS2 snapshot generation, over time, becomes slower and slower > to generate (this is what dump does on UFS2 systems, with or without the > -L flag), and is a known design issue. > > If anything, this issue makes ZFS incredibly important with regards to > -STABLE, where its snapshot generation for backups does not behave this > was; fast and very easily managable. > > [1]: rsync is great for backups, and very fast, but there's the issue of > modifying atimes. I committed a patch to ports/net/rsync which adds an > --atimes flag, except its behaviour is not what you'd expect: the file > which was copied, at the destination, has the correct atime (of the > source), but the source itself ends up getting its atime modified, so > you're essentially destroying the atime data on the source. > > This is a problem when it comes to programs which use atime to discern > things, such as classic UNIX mailboxes/mbox. "Um, why does mutt say I > don't have any new mail when I do??" In our case, the only person using > classic UNIX mboxes with a mail client local to the machine was me, so I > ended up migrating my procmail rules and data to Maildir using mutt, > solving the problem entirely. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > In my case the dump deadlocks, but the system is unaffected. The dump just freezes. I need to look at it more closely, but I simply have not had time. I don't even recall what state it is in when frozen, but it can be 'kill -9'ed. The problem has persisted through at least one system upgrade. I'll try to track down more tomorrow. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080901/2b95e488/attachment.pgp From takeda at takeda.tk Tue Sep 2 01:27:15 2008 From: takeda at takeda.tk (=?utf-8?Q?Derek_Kuli=C5=84ski?=) Date: Tue Sep 2 01:27:21 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: <20080901222738.GA17793@icarus.home.lan> References: <200809011336.m81Da5BT046532@lava.sentex.ca> <20080901160013.0005F4500F@ptavv.es.net> <20080901213856.GA17155@icarus.home.lan> <20080901222738.GA17793@icarus.home.lan> Message-ID: <256483253.20080901181824@takeda.tk> Hello Jeremy, Monday, September 1, 2008, 3:27:38 PM, you wrote: [... links about problems with snapshots ...] the dump can be used without snapshots, in that case is it a still worse method of doing backups? as for the snapshots, you made me even more depressed :) I don't have huge hard disk so I think backup on biggest partition takes a minute (maybe less) which is not so bad. I loved snapshots because the backup that I got was always consistent (I had an opportunity to test it three times already). I only had to remember to lock the database and flush all writes during the snapshot, which was possible to be completely done through a simple script. -- Best regards, Derek mailto:takeda@takeda.tk -- Hidden DOS secret: add BUGS=OFF to your CONFIG.SYS From koitsu at FreeBSD.org Tue Sep 2 06:47:43 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Sep 2 06:47:52 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: References: <20080901235144.4B53B4501A@ptavv.es.net> Message-ID: <20080902064740.GA17890@icarus.home.lan> On Tue, Sep 02, 2008 at 09:39:20AM +0300, Danny Braniss wrote: > take a look at: > http://www.freebsd.org/cgi/query-pr.cgi?pr=117603 > danny That PR may or may not be relevant, depending upon what FreeBSD version users are using, and what kernel build date. The bug mentioned in that PR got addressed in HEAD on March 13th, 2008, and the fix MFC'd to RELENG_7 on April 19th, 2008. It was never MFC'd to RELENG_6. If there are users on RELENG_7 with kernels built with sources after April 19th 2008 who are experiencing the problem, then the PR is probably not relevant. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From danny at cs.huji.ac.il Tue Sep 2 07:09:20 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Tue Sep 2 07:09:26 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: <20080901235144.4B53B4501A@ptavv.es.net> References: <20080901235144.4B53B4501A@ptavv.es.net> Message-ID: take a look at: http://www.freebsd.org/cgi/query-pr.cgi?pr=117603 danny From rwatson at FreeBSD.org Tue Sep 2 07:55:33 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Sep 2 07:55:40 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: <20080902064740.GA17890@icarus.home.lan> References: <20080901235144.4B53B4501A@ptavv.es.net> <20080902064740.GA17890@icarus.home.lan> Message-ID: On Mon, 1 Sep 2008, Jeremy Chadwick wrote: > On Tue, Sep 02, 2008 at 09:39:20AM +0300, Danny Braniss wrote: >> take a look at: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=117603 danny > > That PR may or may not be relevant, depending upon what FreeBSD version > users are using, and what kernel build date. > > The bug mentioned in that PR got addressed in HEAD on March 13th, 2008, and > the fix MFC'd to RELENG_7 on April 19th, 2008. It was never MFC'd to > RELENG_6. > > If there are users on RELENG_7 with kernels built with sources after April > 19th 2008 who are experiencing the problem, then the PR is probably not > relevant. Part of the "problem" here is that a whole class of possible bugs have near-identical symptoms. While each of the following means quite different things to a kernel developer working on the problem, and may reflect quite different types of bugs, they are all often described as "dump hangs" or "dump wedges": - the system deadlocks - dump fails to complete and/or exit, but cannot be killed - dump fails to complete and/or exit, but can be killed When snapshots were first introduced, the problems tended to be at the top end of that list, corresponding to VFS locking and resource starvation deadlocks. As the snapshot code has matured, new problems in both the kernel scheduler and dump code have arisen as parallelism has increased, reflecting a combination of old bugs in the dump code and new bugs in the kernel scheduler. Unfortunately, these bugs don't tend to get discovered much during testing in -CURRENT -- perhaps people don't back up their -CURRENT boxes much :-). I think we need to rigorously do the following: - For each bug report, determine whether it is reporting one or more of the above types of "hangs". If multiple types are reported, track them with different bug reports. - Establish as early as possible whether a fix resolves the problems in each report. Because we're dealing with many bugs over time, it's possible to end up with accidentally "omnibus" reports that remain open and are never closed, even though committed and released fixes may correct the problems experienced by the reporter. It is almost impossible, btw, to rewind and years later determine if any particular fix would have corrected any particular report, because the original submitter will have moved on. Dump happens to be particularly sensitive to bugs of these sorts because it uses snapshots and it uses multiple workers that signal each other, so it's a good lithmus test of stability of both of those features. However, it's easy to conclude that dump is much less stable than it proves in practice because we have a lot of stale and confusing bug reports. What we do need is a dump bug report owner, who can keep track of the outstanding set, try to agressively close the ones that are fixed, which will among other things allow us to better track regressions vs bugs from inception. Robert N M Watson Computer Laboratory University of Cambridge From ohartman at zedat.fu-berlin.de Tue Sep 2 10:07:49 2008 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Tue Sep 2 10:07:56 2008 Subject: nVidia driver update today: renders X11 unusable Message-ID: <48BD0C5A.4060706@zedat.fu-berlin.de> Just upgraded my ports and installed the new xf86-video-nv driver. Well, loggin out works now without crashing the Xorg server, but most fonts now show up as balck bars - unreadable and ugly :-( From c.kworr at gmail.com Tue Sep 2 10:24:47 2008 From: c.kworr at gmail.com (Volodymyr Kostyrko) Date: Tue Sep 2 10:24:55 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: <48BD0C5A.4060706@zedat.fu-berlin.de> References: <48BD0C5A.4060706@zedat.fu-berlin.de> Message-ID: O. Hartmann wrote: > Just upgraded my ports and installed the new xf86-video-nv driver. Well, > loggin out works now without crashing the Xorg server, but most fonts > now show up as balck bars - unreadable and ugly :-( Same for me, just some transparent pictures render transparency as black, good example is reader.google.com. This also isn't new to me, some pictures was shown like this in previous driver versions. I was just a bit unsure who was bad at it. -- Sphinx of black quartz judge my vow. From ohartman at zedat.fu-berlin.de Tue Sep 2 12:54:17 2008 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Tue Sep 2 12:54:24 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: References: <48BD0C5A.4060706@zedat.fu-berlin.de> Message-ID: <48BD36F2.2030902@zedat.fu-berlin.de> Volodymyr Kostyrko wrote: > O. Hartmann wrote: >> Just upgraded my ports and installed the new xf86-video-nv driver. >> Well, loggin out works now without crashing the Xorg server, but most >> fonts now show up as balck bars - unreadable and ugly :-( > > Same for me, just some transparent pictures render transparency as > black, good example is reader.google.com. This also isn't new to me, > some pictures was shown like this in previous driver versions. I was > just a bit unsure who was bad at it. > Well, everything with a transparency, as you stated above, seems to be broken, reading Email is a horror, most web sites are rendered broken in Firefox 3. Luckily, within xterm everthing is ok. I recompiled xorg and my windowmanager, no effect. Even xdm shows up with black bars were normally 'LOGIN:' and 'PASSWORD:' shows up ... Is there a solution? The situation is serious ... -- Oliver Hartmann Freie Universitaet Berlin Planetologie und Fernerkundung Malteserstr. 74 - 100/Haus D D-12249 Berlin Tel.: +49 (0) 30 838 70 508 FAX: +49 (0) 30 838 70 539 From freebsd-stable at bengrimm.net Tue Sep 2 13:23:40 2008 From: freebsd-stable at bengrimm.net (Ben C. O. Grimm) Date: Tue Sep 2 13:23:47 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: <48BD36F2.2030902@zedat.fu-berlin.de> References: <48BD0C5A.4060706@zedat.fu-berlin.de> <48BD36F2.2030902@zedat.fu-berlin.de> Message-ID: <48BD3ACE.1090009@bengrimm.net> O. Hartmann wrote: > Well, everything with a transparency, as you stated above, seems to be > broken, reading Email is a horror, most web sites are rendered broken in > Firefox 3. Luckily, within xterm everthing is ok. > I recompiled xorg and my windowmanager, no effect. Even xdm shows up > with black bars were normally 'LOGIN:' and 'PASSWORD:' shows up ... > Is there a solution? The situation is serious ... Back out of the upgrade, back to the previous version? The current _binary_ package is still the old version, so you could try to force-install that one (e.g. by using "portupgrade -fPP xf86-video-nv-2.1.11") until the port gets fixed, I guess. Haven't tried this (haven't upgraded yet), but it should revert your upgrade and get you up and running for now (but ymmv). From flo at kasimir.com Tue Sep 2 13:29:52 2008 From: flo at kasimir.com (Florian Smeets) Date: Tue Sep 2 13:30:00 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: <48BD0C5A.4060706@zedat.fu-berlin.de> References: <48BD0C5A.4060706@zedat.fu-berlin.de> Message-ID: <48BD3FCC.2080506@kasimir.com> O. Hartmann wrote: > Just upgraded my ports and installed the new xf86-video-nv driver. Well, > loggin out works now without crashing the Xorg server, but most fonts > now show up as balck bars - unreadable and ugly :-( flz@ has committed an updated version (2.4.2) an hour ago. You could try if that fixes your problems. Cheers, Florian From flo at kasimir.com Tue Sep 2 13:33:48 2008 From: flo at kasimir.com (Florian Smeets) Date: Tue Sep 2 13:33:56 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: <48BD3FCC.2080506@kasimir.com> References: <48BD0C5A.4060706@zedat.fu-berlin.de> <48BD3FCC.2080506@kasimir.com> Message-ID: <48BD40B8.2050907@kasimir.com> Florian Smeets wrote: > O. Hartmann wrote: >> Just upgraded my ports and installed the new xf86-video-nv driver. Well, >> loggin out works now without crashing the Xorg server, but most fonts >> now show up as balck bars - unreadable and ugly :-( > > flz@ has committed an updated version (2.4.2) an hour ago. You could try > if that fixes your problems. > Gah. Never mind. It was the xf86-video-intel driver which was updated. I think i need a pair of glasses :-( Sorry, Florian From c.kworr at gmail.com Tue Sep 2 13:45:06 2008 From: c.kworr at gmail.com (Volodymyr Kostyrko) Date: Tue Sep 2 13:45:13 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: <48BD36F2.2030902@zedat.fu-berlin.de> References: <48BD0C5A.4060706@zedat.fu-berlin.de> <48BD36F2.2030902@zedat.fu-berlin.de> Message-ID: O. Hartmann wrote: > Volodymyr Kostyrko wrote: >> O. Hartmann wrote: >>> Just upgraded my ports and installed the new xf86-video-nv driver. >>> Well, loggin out works now without crashing the Xorg server, but most >>> fonts now show up as balck bars - unreadable and ugly :-( >> >> Same for me, just some transparent pictures render transparency as >> black, good example is reader.google.com. This also isn't new to me, >> some pictures was shown like this in previous driver versions. I was >> just a bit unsure who was bad at it. >> > > Well, everything with a transparency, as you stated above, seems to be > broken, reading Email is a horror, most web sites are rendered broken in > Firefox 3. Luckily, within xterm everthing is ok. > > I recompiled xorg and my windowmanager, no effect. Even xdm shows up > with black bars were normally 'LOGIN:' and 'PASSWORD:' shows up ... > > Is there a solution? The situation is serious ... 1. portdowngrade 2. Kick upstream, the problem isn't that new, it's just getting sharper. 3. Quick look through Xephyr at KDE4 gives me no quirks in displaying images. It maybe gtk2-only thingy, or it maybe Xephyr already fixes it somehow... dunno... -- Sphinx of black quartz judge my vow. From ohartman at zedat.fu-berlin.de Tue Sep 2 13:49:20 2008 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Tue Sep 2 13:49:27 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: <48BD3FCC.2080506@kasimir.com> References: <48BD0C5A.4060706@zedat.fu-berlin.de> <48BD3FCC.2080506@kasimir.com> Message-ID: <48BD43DA.4010805@zedat.fu-berlin.de> Florian Smeets wrote: > O. Hartmann wrote: >> Just upgraded my ports and installed the new xf86-video-nv driver. Well, >> loggin out works now without crashing the Xorg server, but most fonts >> now show up as balck bars - unreadable and ugly :-( > > flz@ has committed an updated version (2.4.2) an hour ago. You could try > if that fixes your problems. > > Cheers, > Florian I guess we are already talking about this aupdate because I updated approx. 1 hour ago when the probems took place. Regards, Oliver From avg at icyb.net.ua Tue Sep 2 14:19:37 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Sep 2 14:19:44 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: <48BD43DA.4010805@zedat.fu-berlin.de> References: <48BD0C5A.4060706@zedat.fu-berlin.de> <48BD3FCC.2080506@kasimir.com> <48BD43DA.4010805@zedat.fu-berlin.de> Message-ID: <48BD46BB.9060407@icyb.net.ua> Question to those having this problem - what kind of nVidia hardware do you have? Is that something that is based on G80 GPU or later (GeForce 8XXX or later)? I see that there is already version 2.1.12 of nv driver (in xorg repository) that is supposed to fix CPUToScreenColorExpandFill function for G80 cards. -- Andriy Gapon From ohartman at zedat.fu-berlin.de Tue Sep 2 14:30:34 2008 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Tue Sep 2 14:30:41 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: <48BD46BB.9060407@icyb.net.ua> References: <48BD0C5A.4060706@zedat.fu-berlin.de> <48BD3FCC.2080506@kasimir.com> <48BD43DA.4010805@zedat.fu-berlin.de> <48BD46BB.9060407@icyb.net.ua> Message-ID: <48BD4D84.4030209@zedat.fu-berlin.de> Andriy Gapon wrote: > Question to those having this problem - what kind of nVidia hardware do > you have? > Is that something that is based on G80 GPU or later (GeForce 8XXX or later)? > I see that there is already version 2.1.12 of nv driver (in xorg > repository) that is supposed to fix CPUToScreenColorExpandFill function > for G80 cards. > Well, the problems I have are related to a nv8600GTS based board, this is, as far as I know, a G8X-based graphics board. Nearly 3 months ago some weird behaviour started to be static on the same hardware, Xorg wasn't capable of resetting the terminal is was bound to and presented me funny blinking block graphics on the screen. The Xorg server could oly be revived remotelly by killing the Xorg or within a running session by killing the Xorg for logging off. This problem has gone with today's update, but now my box (nv8600GTS) and the one of a collegue is rendered unusable. My private box runs with a nv6800GT board and there Xorg freezes now very often and renders the box unusable, too. I'm very unpleased about the situation, because it is impossible to do reasonable work. How can I selectively 'downgrade' a port? Regards, Oliver P.S. Sorry about some weird formatting, I'm typing blind, I see 'censor black bars' all over my screen, even in Thunderbird, Firefox ...). From ronald-freebsd8 at klop.yi.org Tue Sep 2 14:55:38 2008 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Tue Sep 2 14:55:50 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: <48BD4D84.4030209@zedat.fu-berlin.de> References: <48BD0C5A.4060706@zedat.fu-berlin.de> <48BD3FCC.2080506@kasimir.com> <48BD43DA.4010805@zedat.fu-berlin.de> <48BD46BB.9060407@icyb.net.ua> <48BD4D84.4030209@zedat.fu-berlin.de> Message-ID: On Tue, 02 Sep 2008 16:28:20 +0200, O. Hartmann wrote: > Andriy Gapon wrote: >> Question to those having this problem - what kind of nVidia hardware do >> you have? >> Is that something that is based on G80 GPU or later (GeForce 8XXX or >> later)? >> I see that there is already version 2.1.12 of nv driver (in xorg >> repository) that is supposed to fix CPUToScreenColorExpandFill function >> for G80 cards. >> > > Well, > the problems I have are related to a nv8600GTS based board, this is, as > far as I know, a G8X-based graphics board. Nearly 3 months ago some > weird behaviour started to be static on the same hardware, Xorg wasn't > capable of resetting the terminal is was bound to and presented me funny > blinking block graphics on the screen. The Xorg server could oly be > revived remotelly by killing the Xorg or within a running session by > killing the Xorg for logging off. This problem has gone with today's > update, but now my box (nv8600GTS) and the one of a collegue is rendered > unusable. > My private box runs with a nv6800GT board and there Xorg freezes now > very often and renders the box unusable, too. > > I'm very unpleased about the situation, because it is impossible to do > reasonable work. > > How can I selectively 'downgrade' a port? Mmmm... # whereis portdowngrade portdowngrade: /usr/ports/ports-mgmt/portdowngrade Cheers, Ronald. From oberman at es.net Tue Sep 2 15:22:21 2008 From: oberman at es.net (Kevin Oberman) Date: Tue Sep 2 15:22:27 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: Your message of "Tue, 02 Sep 2008 09:39:20 +0300." Message-ID: <20080902152220.954FA4500F@ptavv.es.net> > Date: Tue, 02 Sep 2008 09:39:20 +0300 > From: Danny Braniss > > take a look at: > http://www.freebsd.org/cgi/query-pr.cgi?pr=117603 Danny, Thanks for the suggestion, but my system is a P-III so there is only one CPU. At 1GHz, I think that this easily qualifies as an "older, slower, non-smp host". -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080902/135efcdb/attachment.pgp From cmt at burggraben.net Tue Sep 2 15:44:31 2008 From: cmt at burggraben.net (Christoph Moench-Tegeder) Date: Tue Sep 2 15:44:38 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: References: <48BD0C5A.4060706@zedat.fu-berlin.de> Message-ID: <20080902151456.GA1593@elch.haidundneu23.net> ## Volodymyr Kostyrko (c.kworr@gmail.com): > > Just upgraded my ports and installed the new xf86-video-nv driver. Well, > > loggin out works now without crashing the Xorg server, but most fonts > > now show up as balck bars - unreadable and ugly :-( > Same for me, just some transparent pictures render transparency as > black, good example is reader.google.com. This also isn't new to me, > some pictures was shown like this in previous driver versions. I was > just a bit unsure who was bad at it. Seems you've got an issue between X and firefox3; at least there's a note in the firefox3 release notes which desribes similar effects: https://bugzilla.mozilla.org/show_bug.cgi?id=411831 Oh, but by the way, it's not an nvidia/nv issue; I've got the exactly same issues with radeonhd... Luckily, I do not depend that much on web browsers, let alone firefox3. Regards, Christoph -- Spare Space From marck at rinet.ru Tue Sep 2 16:47:04 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Tue Sep 2 16:47:12 2008 Subject: RELENG_7/amd64: booting from gpt failed. Message-ID: <20080902204047.K27579@woozle.rinet.ru> Dear colleagues, I'm trying to set up new machine with RAID array slightly larger than 2T, so I'm forced to use gpt. I did successfully gpt create gpt boot gpt add newfs tar base system gpt show output looks like: start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 128 1 GPT part - FreeBSD boot 162 1048576 2 GPT part - FreeBSD UFS/UFS2 1048738 33554432 3 GPT part - FreeBSD swap 34603170 4359862077 4 GPT part - FreeBSD ZFS 4394465247 32 Sec GPT table 4394465279 1 Sec GPT header and I hope it boots from da0p2, but it fails: /boot.config: -Dh -S115200 FreeBSD/i386 boot Default: 0:ad(0p2)/boot/loader boot: Consoles: internal video/keyboard serial port BIOS drive C: is disk0 BIOS 628kB/3405248kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 (marck@shrew.rinet.ru, Wed Feb 20 17:29:26 MSK 2008) can't load 'kernel' Type '?' for a list of commands, 'help' for more detailed help. OK ls bad path '' OK show loaddev disk0s2`: OK show currdev disk0s2`: Quick googling does not help much. Any hints? Thanks in advance. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From chris# at 1command.com Tue Sep 2 17:49:52 2008 From: chris# at 1command.com (chris#@1command.com) Date: Tue Sep 2 17:49:59 2008 Subject: Is it safe to delete /bin/[ && /usr/bin/false? Message-ID: <20080902104943.71ub86qsussgoo80@webmail.1command.com> Greetings, Well, I en devoured to install a copy of 7 as an effort to upgrade one of our servers. After installing a few ports, I began to notice: [: -le: argument expected messages being emitted during the configure/make process. I've already invested a fair amount of time on this upgrade, and /really/ don't want to wipe the disk(s) and start all over. This issue is not new to me - see thread:[: -le: argument expected for details. But I have /yet/ to discover a solution. When I started the upgrade (install), I had an /etc/make.conf. Thinking that this might be the culprit when these messages starting to appear, I looked it over for possible typos. The only possible issue I could see was the reference to databases/mysql: .if ${.CURDIR:M*/databases/mysql*} WITH_OPENSSL=yes WITH_CHARSET=latin1 WITH_XCHARSET=complex WITH_COLLATION=latin1_general_ci WITH_PROC_SCOPE_PTH=yes BUILD_OPTIMIZED=yes WITH_ARCHIVE=yes WITH_CSV=yes .endif NOTE the YES | NO, as opposed to TRUE | FALSE. I changed them to true v false. But I have already built MySQL with the YES | NO. Could this be the issue? Source(s) cvsupped 08-09-01 Thank you for all your time and consideration. --Chris From freebsd at celestial.com Tue Sep 2 18:24:04 2008 From: freebsd at celestial.com (Bill Campbell) Date: Tue Sep 2 18:24:11 2008 Subject: Is it safe to delete /bin/[ && /usr/bin/false? In-Reply-To: <20080902104943.71ub86qsussgoo80@webmail.1command.com> References: <20080902104943.71ub86qsussgoo80@webmail.1command.com> Message-ID: <20080902180442.GA20336@ayn.mi.celestial.com> No it isn't safe to delete these as many, many scripts depend on them. Bill -- INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way Voice: (206) 236-1676 Mercer Island, WA 98040-0820 Fax: (206) 232-9186 One man's brain plus one other will produce one half as many ideas as one man would have produced alone. These two plus two more will produce half again as many ideas. These four plus four more begin to represent a creative meeting, and the ratio changes to one quarter as many ... -- Anthony Chevins From chris# at 1command.com Tue Sep 2 18:44:37 2008 From: chris# at 1command.com (chris#@1command.com) Date: Tue Sep 2 18:44:45 2008 Subject: Is it safe to delete /bin/[ && /usr/bin/false? In-Reply-To: <20080902180442.GA20336@ayn.mi.celestial.com> References: <20080902104943.71ub86qsussgoo80@webmail.1command.com> <20080902180442.GA20336@ayn.mi.celestial.com> Message-ID: <20080902114428.5njcob6fhckk4kgk@webmail.1command.com> Quoting Bill Campbell : > No it isn't safe to delete these as many, many scripts depend on them. LOL yes, I knew that :) My chosen title for the thread is more a reflection of my frustration with this problem. I'm hoping that a solution is possible. Because /bin/[ & /usr/bin/false are used to evaluate conditionals. It is /quite/ necessary for me to resolve /why/ this keeps happening. As nothing (many||most) things will not work as intended - if at all until the problem is found & fixed. Thank you for taking the time to respond. --Chris > > Bill > -- > INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC > URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way > Voice: (206) 236-1676 Mercer Island, WA 98040-0820 > Fax: (206) 232-9186 > > One man's brain plus one other will produce one half as many ideas as one > man would have produced alone. These two plus two more will produce half > again as many ideas. These four plus four more begin to represent a > creative meeting, and the ratio changes to one quarter as many ... > -- Anthony Chevins > _______________________________________________ > 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 tom.hurst at clara.net Tue Sep 2 19:07:17 2008 From: tom.hurst at clara.net (Thomas Hurst) Date: Tue Sep 2 19:07:31 2008 Subject: ICRC's In-Reply-To: <20080811130555.GA25024@eos.sc1.parodius.com> References: <20080810175934.X2427@borg> <20080811065822.GA81972@voi.aagh.net> <20080811130555.GA25024@eos.sc1.parodius.com> Message-ID: <20080902190714.GA34895@voi.aagh.net> * Jeremy Chadwick (koitsu@FreeBSD.org) wrote: > On Mon, Aug 11, 2008 at 07:58:22AM +0100, Thomas Hurst wrote: > > * Larry Rosenman (ler@lerctr.org) wrote: > > > ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=154593293 > > > > > > NAME STATE READ WRITE CKSUM > > > ad8 ONLINE 0 0 17 > > Having just experienced NTFS corruption in Windows thanks to a > > slightly kinked SATA cable (hint: *never* chkdsk/fsck/etc until > > you're sure the cables are fine), I would *love* to know why this > > causes a checksum error at ZFS level rather than a read error that > > any filesystem (or indeed RAID layer) will notice. > > The ad8 errors you're quoting come from the ATA subsystem in FreeBSD. > That is lower-level (e.g. closer to the hardware) than ZFS's checksum > method is. Yes, but ZFS is clearly still seeing corrupt data from its reads because the CKSUM counter's going up, not READ, which would indicate it's reads were actually failing at ATA level. > If Larry was using UFS, he'd also see the above errors from the > kernel. FreeBSD reports the CRC errors reported by the ATA device, > ZFS reports the said data as corrupted during scrubbing or standard > usage (hence the CKSUM field in 'zpool status'), ZFS should only see corruption that's undetected by ATA's CRC's though (or the disk's own error correction); if it's actually causing a CRC error at protocol level, ZFS should not see it, because that IO operation failed. > and ZFS also *repairs* the corrupted data. I can't explain how the > repair works, It repairs by having duplicate copies of data and metadata; in the case of vital metadata it stores "ditto-blocks" so there are always multiple copies of it about, similar to UFS's superblock being spread all over the disk. For most data you generally want some level of ZFS RAID, but I'm pretty sure you can make it store multiple copies on the same disk (zfs set copies=2 on a 1-disk ZFS, for example). In the event of IO errors, I believe some Linux software RAID levels can perform similar recovery; rewriting the erroring blocks from another device to force the disk to rewrite the broken block. > I believe journalling filesystems (e.g. ext3fs and gjournal) have > this ability, while Standard UFS, UFS2, NTFS, FAT, and many others do > not. No, journalling has nothing to do with this kind of self-healing; a journal allows a filesystem to be made consistent when interrupted (i.e. by a crash or power failure) with a very small number of operations because it has a log of what has or was about to happen. Journalling filesystems are just as vulnerable to corruption as non-journalling ones. NTFS is journalling, BTW. > > What's the point in having the connection protected by a CRC if it's > > just going to let bogus data through anyway? > > A CRC (or checksum) acts as a method of differential detection, e.g. > detect corruption between X and Y. CRCs are not the same thing as error > correction or retransmittal; they only result in reporting data > corruption, and cannot repair it. Yes, I know what CRC's are; my point is, a CRC error should mean the corrupt data doesn't make it to the higher layers; ZFS, UFS, gmirror, whatever, should get an IO error if the data can't be retrieved after retries fail, they shouldn't get an apparently successful read with corrupt data in it. Perhaps this is the case, and (S)ATA's CRC's are just so poor a couple of retries is enough to get corrupt data which happens to have a correct CRC. -- Thomas 'Freaky' Hurst http://hur.st/ From peterjeremy at optushome.com.au Tue Sep 2 19:09:37 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Tue Sep 2 19:09:45 2008 Subject: Is it safe to delete /bin/[ && /usr/bin/false? In-Reply-To: <20080902104943.71ub86qsussgoo80@webmail.1command.com> References: <20080902104943.71ub86qsussgoo80@webmail.1command.com> Message-ID: <20080902190919.GE86609@server.vk2pj.dyndns.org> On 2008-Sep-02 10:49:43 -0700, chris#@1command.com wrote: >Well, I en devoured to install a copy of 7 as an effort to upgrade >one of our servers. After installing a few ports, I began to notice: >[: -le: argument expected messages being emitted during the configure/make >process. This probably indicates badly written configure scripts that have things like "[ 23 -le $x ]" but don't set $x. The solution is to write patches for the configure scripts and feed them back upstream. > I've already invested a fair amount of time on this upgrade, >and /really/ don't want to wipe the disk(s) and start all over. I'm not sure how this will help. > This >issue is not new to me - see thread:[: -le: argument expected for details. You haven't mentioned where this thread exists - definitely not here. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080902/966f62d9/attachment.pgp From chris# at 1command.com Tue Sep 2 19:26:45 2008 From: chris# at 1command.com (chris#@1command.com) Date: Tue Sep 2 19:26:51 2008 Subject: Is it safe to delete /bin/[ && /usr/bin/false? In-Reply-To: <20080902190919.GE86609@server.vk2pj.dyndns.org> References: <20080902104943.71ub86qsussgoo80@webmail.1command.com> <20080902190919.GE86609@server.vk2pj.dyndns.org> Message-ID: <20080902122551.jfly404kcg00o40w@webmail.1command.com> Hello, and thank you for your reply. Quoting Peter Jeremy : > On 2008-Sep-02 10:49:43 -0700, chris#@1command.com wrote: >> Well, I en devoured to install a copy of 7 as an effort to upgrade >> one of our servers. After installing a few ports, I began to notice: >> [: -le: argument expected messages being emitted during the configure/make >> process. > > This probably indicates badly written configure scripts that have > things like "[ 23 -le $x ]" but don't set $x. The solution is to > write patches for the configure scripts and feed them back upstream. Bummer. > >> I've already invested a fair amount of time on this upgrade, >> and /really/ don't want to wipe the disk(s) and start all over. > > I'm not sure how this will help. Good. Perhaps you (or anyone) can suggest how I might debug /when/where/ these eval are called. I could use /usr/bin/script, but not sure how to (e)grep the culprit(s). > >> This >> issue is not new to me - see thread:[: -le: argument expected for details. > > You haven't mentioned where this thread exists - definitely not here. Ahem... Quoting Jeremy Chadwick : On Fri, Feb 01, 2008 at 10:18:14AM -0800, Chris H. wrote: I wanted to sync up my ports database before hand. So ran a portsdb -uU. ---8<---[huge snip]---8<--- Hello again Jeremy, Well, after carefully examining your reply; emptying /etc/make.conf; searching for any sign of another Apache APR, and finding none.; performing a cvsup -g -L 2 ports-supfile && portsdb -uU && pkgdb -F; which resulted in many [: -le: argument expected's, and [: -eq: argument expected's; I performed a: cd /usr/ports/lang/php5 && make extract; Yep! You guessed it, [: -le: argument expected again! Well, what was expected to be a 3 day affair, has turned into a 2 week affair. At least that's been my past experience with installing a FreeBSD server (3 days). :) Anyway, I've run out of patience (and time) debugging this issue. So I think it would be more expedient to wipe the disk and start anew. :) If I should run into this again on the new install. I guess a send-pr would be in order. Oh, and expect /alot/ of noise in the list. :) Thank you again for your continued (and valued) input. Best wishes. --Chris H [Hide Quoted Text] -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | _______________________________________________ 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" I didn't mean to sound argumentative but the above was my last posting to the thread: [: -le: argument expected in freebsd-stable on Feb 2008. :) Thanks again for taking the time to respond. --Chris > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. > From jhb at freebsd.org Tue Sep 2 20:09:09 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Sep 2 20:09:16 2008 Subject: IPMI and Dell ERA/O In-Reply-To: <002c01c90ab8$e8063170$b8129450$@com> References: <004701c90998$c9d70240$5d8506c0$@com> <200808291124.10275.jhb@freebsd.org> <002c01c90ab8$e8063170$b8129450$@com> Message-ID: <200809021533.57430.jhb@freebsd.org> On Saturday 30 August 2008 11:56:01 am Jonathan Bond-Caron wrote: > On Fri Aug 29 11:24 AM, John Baldwin wrote: > > > > If your BIOS doesn't tell us about the IPMI BMC via ACPI or SMBIOS, > > you can try using hints (I've seen machines thave a BMC, but the BIOS > > doesn't bother to tell you about it). Dell boxes I've seen have KCS > > at the default address, so you can just do: > > > > hint.ipmi.0.at=isa0 > > hint.ipmi.0.mode=KCS > > > > Either add that to /boot/device.hints or for a test just explicitly > > set those variables at the loader prompt before booting. > > > > Thanks, that works! > > Although I don't really understand why? After some digging, I found this: > (man 4 ipmi) > BUGS > Not all features of the MontaVista driver are supported. > Currently, IPMB and BT modes are not implemented. > > > But the interface for the Dell 1750 with ERA/O seems to be BT. Luckily it > works enough for me with KCS (hint.ipmi.0.mode=KCS) > http://linux.dell.com/ipmi.shtml Not the same BT. BT is a different transport for the host OS to talk to the BMC that allows for a more asynchronous model. I've not seen any hardware that supports BT yet. > I'm saying 'works enough' because some readings show as 'disabled', I'm not > sure if that's because the interface is not BT or the supported IPMI version > is 1.0 (on the BMC): > > [root@home /home/jbondc]# ipmitool -I open sdr > CPU 1 | disabled | ns > CPU 2 | disabled | ns > CPU 3 | disabled | ns > CPU 4 | disabled | ns > CPU Planar | 35 degrees C | ok > Ambient | 27 degrees C | ok > CPU | 1.48 Volts | ok > CPU 2 | disabled | ns > CPU 3 | disabled | ns > CPU 4 | disabled | ns > +5 | 5.05 Volts | ok > +12 | 11.97 Volts | ok > +3.3 | 3.29 Volts | ok > Battery | 3.06 Volts | ok > +2.5 | 2.55 Volts | ok > NIC +2.5 | disabled | ns > NIC +1.8 | disabled | ns > MemCard A +2.5 | disabled | ns > MemCard B +2.5 | disabled | ns > MemCard A +1.25 | disabled | ns > MemCard B +1.25 | disabled | ns > Cover Intrusion | 0x00 | ok > Fan Control | 0x17 | ok > Fan 1 | 6240 RPM | ok > Fan 2 | 6120 RPM | ok > ... This is a property of your BMC. The fact that you can talk to it at all means communication with the BMC is working, and that is all the ipmi(4) driver provides (communication with the BMC). -- John Baldwin From jfesler at gigo.com Wed Sep 3 04:08:15 2008 From: jfesler at gigo.com (Jason Fesler) Date: Wed Sep 3 04:08:22 2008 Subject: IPV6_V6ONLY and UDP Message-ID: I see in the release notes for 7.0; and seperately CURRENT on alpha; that IPV6_V6ONLY is now fully supported for UDP. Can someone point me to code/text that explains what exactly was broken about it? In what case(s) udp sockets set with IPV6_V6ONLY accepted V4 packets? Thanks in advance.. -- Jason Fesler, email/jabber resume: http://jfesler.com "Give a man fire, and he'll be warm for a day; set a man on fire, and he'll be warm for the rest of his life." From ohartman at zedat.fu-berlin.de Wed Sep 3 06:06:53 2008 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Wed Sep 3 06:07:00 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: <20080902151456.GA1593@elch.haidundneu23.net> References: <48BD0C5A.4060706@zedat.fu-berlin.de> <20080902151456.GA1593@elch.haidundneu23.net> Message-ID: <48BE28F7.7030500@zedat.fu-berlin.de> Christoph Moench-Tegeder wrote: > ## Volodymyr Kostyrko (c.kworr@gmail.com): > >>> Just upgraded my ports and installed the new xf86-video-nv driver. Well, >>> loggin out works now without crashing the Xorg server, but most fonts >>> now show up as balck bars - unreadable and ugly :-( >> Same for me, just some transparent pictures render transparency as >> black, good example is reader.google.com. This also isn't new to me, >> some pictures was shown like this in previous driver versions. I was >> just a bit unsure who was bad at it. > > Seems you've got an issue between X and firefox3; at least there's > a note in the firefox3 release notes which desribes similar effects: > https://bugzilla.mozilla.org/show_bug.cgi?id=411831 > Oh, but by the way, it's not an nvidia/nv issue; I've got the exactly > same issues with radeonhd... Luckily, I do not depend that much on > web browsers, let alone firefox3. > > Regards, > Christoph > The issue of X with firefox is well known and be aured I'm aware of that. This issue I complained about is with nearly every client I use under X - and that includes Firefox. This 'issue' renders a bunch of FreeBSD boxes around here unusable, only those with non-G80 derived graphics boards seem to be not infected by the problem, but every box with FreeBSD (mostly 7.0/7.1). By the way, the Linux boxes, especially the Gentoo-boxes, with also the open source nv-driver DO NOT SHOW this problem. From cmt at burggraben.net Wed Sep 3 06:37:57 2008 From: cmt at burggraben.net (Christoph Moench-Tegeder) Date: Wed Sep 3 06:38:04 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: <48BE28F7.7030500@zedat.fu-berlin.de> References: <48BD0C5A.4060706@zedat.fu-berlin.de> <20080902151456.GA1593@elch.haidundneu23.net> <48BE28F7.7030500@zedat.fu-berlin.de> Message-ID: <20080903063753.GA2120@reindeer.haidundneu23.net> ## O. Hartmann (ohartman@zedat.fu-berlin.de): > > Seems you've got an issue between X and firefox3; at least there's > > a note in the firefox3 release notes which desribes similar effects: > > https://bugzilla.mozilla.org/show_bug.cgi?id=411831 > > Oh, but by the way, it's not an nvidia/nv issue; I've got the exactly > > same issues with radeonhd... Luckily, I do not depend that much on > > web browsers, let alone firefox3. > The issue of X with firefox is well known and be aured I'm aware of > that. This issue I complained about is with nearly every client I use > under X - and that includes Firefox. This 'issue' renders a bunch of > FreeBSD boxes around here unusable, only those with non-G80 derived > graphics boards seem to be not infected by the problem, but every box > with FreeBSD (mostly 7.0/7.1). Ah, that explains why I'm having only the usual firefox issue, obviously my laptop's "Quadro NVS 140M" is not a G80-derived chip (nautilus, gimp, gnumeric do wirk fine without black bars). The first mails read as if all nvidia boards were affected. Regards, Christoph -- Spare Space From ohartman at zedat.fu-berlin.de Wed Sep 3 07:13:22 2008 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Wed Sep 3 07:13:29 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: <20080903063753.GA2120@reindeer.haidundneu23.net> References: <48BD0C5A.4060706@zedat.fu-berlin.de> <20080902151456.GA1593@elch.haidundneu23.net> <48BE28F7.7030500@zedat.fu-berlin.de> <20080903063753.GA2120@reindeer.haidundneu23.net> Message-ID: <48BE388C.7050706@zedat.fu-berlin.de> Christoph Moench-Tegeder wrote: > ## O. Hartmann (ohartman@zedat.fu-berlin.de): > >>> Seems you've got an issue between X and firefox3; at least there's >>> a note in the firefox3 release notes which desribes similar effects: >>> https://bugzilla.mozilla.org/show_bug.cgi?id=411831 >>> Oh, but by the way, it's not an nvidia/nv issue; I've got the exactly >>> same issues with radeonhd... Luckily, I do not depend that much on >>> web browsers, let alone firefox3. >> The issue of X with firefox is well known and be aured I'm aware of >> that. This issue I complained about is with nearly every client I use >> under X - and that includes Firefox. This 'issue' renders a bunch of >> FreeBSD boxes around here unusable, only those with non-G80 derived >> graphics boards seem to be not infected by the problem, but every box >> with FreeBSD (mostly 7.0/7.1). > > Ah, that explains why I'm having only the usual firefox issue, > obviously my laptop's "Quadro NVS 140M" is not a G80-derived > chip (nautilus, gimp, gnumeric do wirk fine without black bars). > The first mails read as if all nvidia boards were affected. > > Regards, > Christoph > My box at home has an older NV6800GT and I do not have this special issue, but instead I do have another well known issue of box-freezing. This also happens with 'nv'. Since FreeBSD 7.0 this freezing occurs more frequent than in FBSD 6, but in the meanwhile thenv-driver changed several times. It is a horror :-( Regards, Oliver From 000.fbsd at quip.cz Wed Sep 3 08:07:52 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Wed Sep 3 08:08:00 2008 Subject: external HDD disconnects - umass1: BBB reset failed, IOERROR (FreeBSD 6.3) Message-ID: <48BE45F1.4020409@quip.cz> Hi, I tried to use 1TB HDD (SAMSUNG HD103UJ) in external enclosure connected by USB 2.0 to my old machine with FreeBSD 6.3-RELEASE-p1 GENERIC i386. It connects OK, I can read & write to disk (shown as /dev/da1). But my dd command test failed after 50 minutes: root@amanda ~/# dd if=/dev/da1 of=/dev/da1 bs=1m dd: /dev/da1: Invalid argument 20435+0 records in 20435+0 records out 21427650560 bytes transferred in 2963.876996 secs (7229602 bytes/sec) Usr: 0.092s Krnl: 10.689s Totl: 49:23.87s CPU: 0.3% swppd: 0 I/O: 0+0 relevant part of /var/log/messages Sep 2 20:06:15 amanda kernel: umass1: Sunplus Technology Co.,Ltd. USB to Serial-ATA bridge, rev 2.00/1.12, addr 3 Sep 2 20:06:15 amanda kernel: da1 at umass-sim1 bus 1 target 0 lun 0 Sep 2 20:06:15 amanda kernel: da1: Fixed Direct Access SCSI-2 device Sep 2 20:06:15 amanda kernel: da1: 40.000MB/s transfers Sep 2 20:06:15 amanda kernel: da1: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) Sep 2 20:06:46 amanda login: ROOT LOGIN (root) ON ttyv0 Sep 2 20:07:29 amanda ntpd[845]: kernel time sync enabled 6001 Sep 2 20:24:32 amanda ntpd[845]: kernel time sync enabled 2001 Sep 2 20:58:06 amanda kernel: umass1: BBB reset failed, IOERROR Sep 2 20:58:06 amanda kernel: umass1: BBB bulk-in clear stall failed, IOERROR Sep 2 20:58:06 amanda kernel: umass1: BBB bulk-out clear stall failed, IOERROR Sep 2 20:58:06 amanda kernel: umass1: BBB reset failed, IOERROR Sep 2 20:58:06 amanda kernel: umass1: BBB bulk-in clear stall failed, IOERROR Sep 2 20:58:06 amanda kernel: umass1: BBB bulk-out clear stall failed, IOERROR Sep 2 20:58:06 amanda kernel: umass1: BBB reset failed, IOERROR Sep 2 20:58:06 amanda kernel: umass1: at uhub2 port 1 (addr 3) disconnected Sep 2 20:58:06 amanda kernel: (da1:umass-sim1:1:0:0): lost device Sep 2 20:58:06 amanda kernel: (da1:dead_sim0:0:0:0): Synchronize cache failed, status == 0x8, scsi status == 0x0 Sep 2 20:58:06 amanda kernel: (da1:dead_sim0:0:0:0): removing device entry Sep 2 20:58:06 amanda kernel: umass1: detached I have another disk (500GB) with different enclosure connected to another USB port as /dev/da0 without any problem for more than 3 month and using it for nightly rsync backups. I tried to reattache it again without reboot, without success. root@amanda ~/# camcontrol rescan all Re-scan of bus 0 was successful Re-scan of bus 1 was successful root@amanda ~/# camcontrol devlist -v scbus0 on umass-sim0 bus 0: at scbus0 target 0 lun 0 (pass0,da0) scbus1 on sbp0 bus 0: < > at scbus1 target -1 lun -1 () scbus-1 on xpt0 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) root@amanda ~/# camcontrol reset 1 Reset of bus 1 returned error 0x6 Does anybody know what causes this problem? Miroslav Lachman root@amanda ~/# pciconf -l -v agp0@pci0:0:0: class=0x060000 card=0x80ac1043 chip=0x01e010de rev=0xc1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce2 AGP Controller' class = bridge subclass = HOST-PCI none0@pci0:0:1: class=0x050000 card=0x80ac1043 chip=0x01eb10de rev=0xc1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce2 Memory Controller 1' class = memory subclass = RAM none1@pci0:0:2: class=0x050000 card=0x80ac1043 chip=0x01ee10de rev=0xc1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce2 Memory Controller 4' class = memory subclass = RAM none2@pci0:0:3: class=0x050000 card=0x80ac1043 chip=0x01ed10de rev=0xc1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce2 Memory Controller 3' class = memory subclass = RAM none3@pci0:0:4: class=0x050000 card=0x80ac1043 chip=0x01ec10de rev=0xc1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce2 Memory Controller 2' class = memory subclass = RAM none4@pci0:0:5: class=0x050000 card=0x80ac1043 chip=0x01ef10de rev=0xc1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce2 Memory Controller 5' class = memory subclass = RAM isab0@pci0:1:0: class=0x060100 card=0x80ad1043 chip=0x006010de rev=0xa4 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce MCP2 ISA Bridge' class = bridge subclass = PCI-ISA none5@pci0:1:1: class=0x0c0500 card=0x0c111043 chip=0x006410de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce MCP-T SMBus Controller' class = serial bus subclass = SMBus ohci0@pci0:2:0: class=0x0c0310 card=0x0c111043 chip=0x006710de rev=0xa4 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce MCP2 OpenHCI USB Controller' class = serial bus subclass = USB ohci1@pci0:2:1: class=0x0c0310 card=0x0c111043 chip=0x006710de rev=0xa4 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce MCP2 OpenHCI USB Controller' class = serial bus subclass = USB ehci0@pci0:2:2: class=0x0c0320 card=0x0c111043 chip=0x006810de rev=0xa4 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce MCP2 EHCI USB 2.0 Controller' class = serial bus subclass = USB nve0@pci0:4:0: class=0x020000 card=0x80a71043 chip=0x006610de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce MCP-T Ethernet Adapter Chip 10/100/HD/FD-Autosense' class = network subclass = ethernet none6@pci0:5:0: class=0x040100 card=0x0c111043 chip=0x006b10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce MCP-T? Audio Processing Unit (Dolby Digital)' class = multimedia subclass = audio none7@pci0:6:0: class=0x040100 card=0x80951043 chip=0x006a10de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce MCP-T Audio Codec Interface' class = multimedia subclass = audio pcib1@pci0:8:0: class=0x060400 card=0x00000000 chip=0x006c10de rev=0xa3 hdr=0x01 vendor = 'Nvidia Corp' device = 'nForce MCP-T CPU to PCI Bridge' class = bridge subclass = PCI-PCI atapci1@pci0:9:0: class=0x01018a card=0x0c111043 chip=0x006510de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce MCP2 EIDE Controller' class = mass storage subclass = ATA fwohci0@pci0:13:0: class=0x0c0010 card=0x809a1043 chip=0x006e10de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce MCP2 OHCI Compliant IEEE 1394 Controller' class = serial bus subclass = FireWire pcib2@pci0:30:0: class=0x060400 card=0x00000000 chip=0x01e810de rev=0xc1 hdr=0x01 vendor = 'Nvidia Corp' device = 'nForce2 AGP Host to PCI Bridge' class = bridge subclass = PCI-PCI skc0@pci1:4:0: class=0x020000 card=0x811a1043 chip=0x432011ab rev=0x13 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = 'Yukon 88E8001/8003/8010 PCI Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet none8@pci1:9:0: class=0x030000 card=0x8a015333 chip=0x8a015333 rev=0x01 hdr=0x00 vendor = 'S3 Graphics Co., Ltd' device = '86C375 ViRGE/DX, 86C385 ViRGE/GX' class = display subclass = VGA atapci0@pci1:11:0: class=0x010400 card=0x61121095 chip=0x31121095 rev=0x02 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'SiI 3112 SATALink/SATARaid Controller' class = mass storage subclass = RAID dmesg: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.3-RELEASE-p1 #0: Wed Feb 13 02:40:56 UTC 2008 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC mptable_probe: Unable to map end of MP Config Table ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 1800+ (1531.03-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383fbff AMD Features=0xc0400800 real memory = 536805376 (511 MB) avail memory = 515878912 (491 MB) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Feb 13 2008 02:40:39) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 Correcting nForce2 C1 CPU disconnect hangs agp0: mem 0xe0000000-0xe3ffffff at device 0.0 on pci0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xed081000-0xed081fff irq 20 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xed084000-0xed084fff irq 21 at device 2.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xed085000-0xed0850ff irq 22 at device 2.2 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 6 ports with 6 removable, self powered umass0: JMicron JM20336 SATA, USB Combo, rev 2.00/1.00, addr 2 nve0: port 0xe400-0xe407 mem 0xed080000-0xed080fff irq 20 at device 4.0 on pci0 nve0: Ethernet address 00:0e:a6:2b:e5:3d miibus0: on nve0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto nve0: Ethernet address: 00:0e:a6:2b:e5:3d pci0: at device 5.0 (no driver attached) pci0: at device 6.0 (no driver attached) pcib1: at device 8.0 on pci0 pci1: on pcib1 skc0: port 0xa000-0xa0ff mem 0xe9000000-0xe9003fff irq 17 at device 4.0 on pci1 skc0: Marvell Yukon Lite Gigabit Ethernet rev. A3(0x7) sk0: on skc0 sk0: Ethernet address: 00:0e:a6:2b:d9:82 miibus1: on sk0 e1000phy0: on miibus1 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto pci1: at device 9.0 (no driver attached) atapci0: port 0xa400-0xa407,0xa800-0xa803,0xac00-0xac07,0xb000-0xb003,0xb400-0xb40f mem 0xe9004000-0xe90041ff irq 18 at device 11.0 on pci1 ata2: on atapci0 ata3: on atapci0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 9.0 on pci0 ata0: on atapci1 ata1: on atapci1 fwohci0: <1394 Open Host Controller Interface> mem 0xed086000-0xed0867ff,0xed087000-0xed08703f irq 20 at device 13.0 on pci0 fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:e0:18:00:00:4f:c4:90 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:e0:18:4f:c4:90 fwe0: Ethernet address: 02:e0:18:4f:c4:90 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pcib2: at device 30.0 on pci0 pci3: on pcib2 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff,0xcc000-0xcd7ff,0xce000-0xcefff 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 Timecounter "TSC" frequency 1531026903 Hz quality 800 Timecounters tick every 1.000 msec hptrr: no controller detected. acd0: CDRW at ata0-master PIO4 ad2: 152627MB at ata1-master UDMA100 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 476940MB (976773168 512 byte sectors: 255H 63S/T 60801C) Trying to mount root from ufs:/dev/ad2s1a sk0: link state changed to UP From danny at cs.huji.ac.il Wed Sep 3 09:14:44 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Wed Sep 3 09:15:01 2008 Subject: bin/121684: : dump(8) frequently hangs In-Reply-To: <20080902152220.954FA4500F@ptavv.es.net> References: <20080902152220.954FA4500F@ptavv.es.net> Message-ID: > Danny, > > Thanks for the suggestion, but my system is a P-III so there is only one > CPU. At 1GHz, I think that this easily qualifies as an "older, slower, > non-smp host". I just tried it on a GEODE/7.0 stable - slower than a P-III :-), and dump went smoothly so, to help isolate the problem, if it still happens to you, let me know what os/version - I can probably find a P-III around here. danny From is at rambler-co.ru Wed Sep 3 10:15:33 2008 From: is at rambler-co.ru (Igor Sysoev) Date: Wed Sep 3 10:15:43 2008 Subject: vfs.ffs.rawreadahead Message-ID: <20080903095352.GA62541@rambler-co.ru> Hi, could anyone tell what does vfs.ffs.rawreadahead enable ? As I understand it's used in DIRECTIO code that allows read data directly to an userland buffer bypassing the buffer cache. What I can not understand where the read ahead data can be placed in ? -- Igor Sysoev http://sysoev.ru/en/ From sjt.kar at gmail.com Wed Sep 3 11:03:00 2008 From: sjt.kar at gmail.com (Sujit Karataparambil) Date: Wed Sep 3 11:03:06 2008 Subject: vfs.ffs.rawreadahead In-Reply-To: <20080903095352.GA62541@rambler-co.ru> References: <20080903095352.GA62541@rambler-co.ru> Message-ID: <921ca19c0809030333u6accf415l80ec5bfb4a984ce1@mail.gmail.com> The VFS was designed to be Object abtraction of the Berkeley Fast File System. This has been since an terminology with journalling filesystem to have functionality to added on request. Thanks, Sujit On 9/3/08, Igor Sysoev wrote: > Hi, > > could anyone tell what does vfs.ffs.rawreadahead enable ? > As I understand it's used in DIRECTIO code that allows read data > directly to an userland buffer bypassing the buffer cache. > What I can not understand where the read ahead data can be placed in ? > > > -- > Igor Sysoev > http://sysoev.ru/en/ > _______________________________________________ > 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" > -- --linux(2.4/2.6),bsd(4.5.x+),solaris(2.5+) From is at rambler-co.ru Wed Sep 3 11:27:16 2008 From: is at rambler-co.ru (Igor Sysoev) Date: Wed Sep 3 11:27:24 2008 Subject: vfs.ffs.rawreadahead In-Reply-To: <921ca19c0809030333u6accf415l80ec5bfb4a984ce1@mail.gmail.com> References: <20080903095352.GA62541@rambler-co.ru> <921ca19c0809030333u6accf415l80ec5bfb4a984ce1@mail.gmail.com> Message-ID: <20080903112512.GB62541@rambler-co.ru> On Wed, Sep 03, 2008 at 04:03:59PM +0530, Sujit Karataparambil wrote: > The VFS was designed to be Object abtraction of the Berkeley Fast File System. > This has been since an terminology with journalling filesystem to have > functionality to added on request. In src/sys/ufs/ffs/ffs_rawread.c I see that rawreadahead is used. However, I do not understand whether rawreadahead starts a second parallel ahead disk transaction with supplied userland buffer or not. -- Igor Sysoev http://sysoev.ru/en/ > On 9/3/08, Igor Sysoev wrote: > > Hi, > > > > could anyone tell what does vfs.ffs.rawreadahead enable ? > > As I understand it's used in DIRECTIO code that allows read data > > directly to an userland buffer bypassing the buffer cache. > > What I can not understand where the read ahead data can be placed in ? > > > > > > -- > > Igor Sysoev > > http://sysoev.ru/en/ From sjt.kar at gmail.com Wed Sep 3 11:33:22 2008 From: sjt.kar at gmail.com (Sujit Karataparambil) Date: Wed Sep 3 11:33:29 2008 Subject: vfs.ffs.rawreadahead In-Reply-To: <20080903112512.GB62541@rambler-co.ru> References: <20080903095352.GA62541@rambler-co.ru> <921ca19c0809030333u6accf415l80ec5bfb4a984ce1@mail.gmail.com> <20080903112512.GB62541@rambler-co.ru> Message-ID: <921ca19c0809030433w50e16100rd624cdb4a2e4e947@mail.gmail.com> These are Journalling File System. Some thing like WAPBL which stands for Write-Ahead Physical Block Logging. These are built on Generic kernel components. On 9/3/08, Igor Sysoev wrote: > On Wed, Sep 03, 2008 at 04:03:59PM +0530, Sujit Karataparambil wrote: > > > The VFS was designed to be Object abtraction of the Berkeley Fast File System. > > This has been since an terminology with journalling filesystem to have > > functionality to added on request. > > In src/sys/ufs/ffs/ffs_rawread.c I see that rawreadahead is used. > However, I do not understand whether rawreadahead starts a second > parallel ahead disk transaction with supplied userland buffer or not. > > > -- > Igor Sysoev > http://sysoev.ru/en/ > > > On 9/3/08, Igor Sysoev wrote: > > > Hi, > > > > > > could anyone tell what does vfs.ffs.rawreadahead enable ? > > > As I understand it's used in DIRECTIO code that allows read data > > > directly to an userland buffer bypassing the buffer cache. > > > What I can not understand where the read ahead data can be placed in ? > > > > > > > > > -- > > > Igor Sysoev > > > http://sysoev.ru/en/ > -- --linux(2.4/2.6),bsd(4.5.x+),solaris(2.5+) From is at rambler-co.ru Wed Sep 3 11:44:15 2008 From: is at rambler-co.ru (Igor Sysoev) Date: Wed Sep 3 11:44:25 2008 Subject: vfs.ffs.rawreadahead In-Reply-To: <921ca19c0809030433w50e16100rd624cdb4a2e4e947@mail.gmail.com> References: <20080903095352.GA62541@rambler-co.ru> <921ca19c0809030333u6accf415l80ec5bfb4a984ce1@mail.gmail.com> <20080903112512.GB62541@rambler-co.ru> <921ca19c0809030433w50e16100rd624cdb4a2e4e947@mail.gmail.com> Message-ID: <20080903114210.GC62541@rambler-co.ru> On Wed, Sep 03, 2008 at 05:03:21PM +0530, Sujit Karataparambil wrote: > These are Journalling File System. Some thing like WAPBL > which stands for Write-Ahead Physical Block Logging. These > are built on Generic kernel components. vfs.ffs.rawreadahead as it may be seen from its name is read-ahead capability, but not write-ahead. And there is no any write-ahead related sysctl: #sysctl -a|grep ahead vfs.ffs.rawreadahead: 1 # > On 9/3/08, Igor Sysoev wrote: > > On Wed, Sep 03, 2008 at 04:03:59PM +0530, Sujit Karataparambil wrote: > > > > > The VFS was designed to be Object abtraction of the Berkeley Fast File System. > > > This has been since an terminology with journalling filesystem to have > > > functionality to added on request. > > > > In src/sys/ufs/ffs/ffs_rawread.c I see that rawreadahead is used. > > However, I do not understand whether rawreadahead starts a second > > parallel ahead disk transaction with supplied userland buffer or not. > > > > > > -- > > Igor Sysoev > > http://sysoev.ru/en/ > > > > > On 9/3/08, Igor Sysoev wrote: > > > > Hi, > > > > > > > > could anyone tell what does vfs.ffs.rawreadahead enable ? > > > > As I understand it's used in DIRECTIO code that allows read data > > > > directly to an userland buffer bypassing the buffer cache. > > > > What I can not understand where the read ahead data can be placed in ? > > > > > > > > > > > > -- > > > > Igor Sysoev > > > > http://sysoev.ru/en/ > > > > > -- > --linux(2.4/2.6),bsd(4.5.x+),solaris(2.5+) -- Igor Sysoev http://sysoev.ru/en/ From admin at kkip.pl Wed Sep 3 12:28:42 2008 From: admin at kkip.pl (Bartosz Stec) Date: Wed Sep 3 12:28:50 2008 Subject: bugged sysinstall, bsdlabel, zfs, gmirror - recept for disaster :) Message-ID: <48BE82F6.9070103@kkip.pl> Hello there! Here's my story, hopefully some of you won't follow my steps and avoid some troubles :) Yesterday I've decided that's about time to test zfs functionality on my home server PC (i386 FreeBSD 7.1-pre) . A couple of weeks ago I bought new desktop PC (with SATA), so I had a bunch of PATA disks from old one to use in server. Lucky me - there was 3 HDD at size 40GB - RAIDZ was on approch! So after a thirty minutes I had a plan, and my server had 4 disks connected - one 20GB with actual system (ad1), and three 40GB to replace actual system (ad[023]). Plan was simple: 1. csup freebsd-stable 2. follow the tuning guide for zfs, rebuild world, kernel, and follow system upgrade 3. Reboot in single user mode 4. fdisk new disks with sysinstall using one big slice for every disk 5. bsdlabel every new disk with sysinstall using: 1GB for /, 512MB for swap, and rest unused (for ZFS) 6. gmirror -n -v -b round-robin boot ad0s1a ad2s1a ad3s1a 7. newfs /dev/mirror/boot 8. mount /dev/mirror/boot /mnt && cd /mnt 9. dump -h 0 -L -f - -C 32 / | restore rf - 10. zpool create tank raidz ad0s1d ad2s1d ad3s1d 11. zfs create new cool filesystems :) 12. dump | restore old ufs2 filesystem to new cool zfs filesystems :) 13. changing mount points from tank/foo to /foo 14. edit new fstab on mirror by replacing root mount point by "boot" mirror, adding new swaps and remove ald ones and all fs now placed on zpool 15. power off system, detach ad1 and power on new system in mixed gmirror - raidz environment. Yay! Well...it has almost works. Sysinstall screw it up. I was always too lazy to read man bsdlabel, that's why I've been using this "nice" tool for disk related tasks. Such a mistake! Problem with labels created with sysinstal, is that it aks for a mount point for every partition in slice. Well, in my case it was unwanted behaviour, so on every disk I created first: a: / b: swap c: none d: /foo Then by using "M" key I removed mount points and saved changes with "W". At this point everything seems ok. So I've added gmirror to loader.conf and run "gmirror label -n -v -b round-robin boot ad0s1a ad2s1a ad3s1a". Still ok until now. Next step - kldload geom_mirror. Here's disaster! System became unresponsible and hangs after a while. Reboot didn't help, just after gmirror module was loaded by kernel, screen was flooded with messages: WARNING: Expected rawoffset 0, found 63 andy didn't boot. I've made system start only because an old drive ad1 has no gmirror module added to loader.conf. So after reboot I've cleared metadata on providers and made some another attempts, but results were always the same. Finally I have found explanation for this issue. Man bsdlabel says: /offset/ The offset of the start of the partition from the beginning of the drive in sectors, or *** to have *bsdlabel* calculate the correct offset to use (the end of the previous partition plus one, ignor- ing partition `c'). For partition `c', *** will be interpreted as an offset of 0. The first partition should start at offset 16, because the first 16 sectors are reserved for metadata. So proper labels for disks should be (and they are now): # /dev/ad0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 2097152 16 4.2BSD 0 0 0 b: 1048576 2097168 swap c: 78156162 0 unused 0 0 # "raw" part, don't edit d: 75010418 3145744 unused 0 0 Problem was - Sysinstall has placed partition "a:" starting with offset 0! This is what happens when you don't RTFM :) I assume that this bug occured because I created mount point for root on ad[023]s1a and removed it after, than saved label. It seems that GEOM framework didn't expect this, neither maual for bsdlabel. I think that should be fixed somehow. Fortunately manually editing labels by "bsdlabel -e" wasn't so hard as I expected. This is how I made everything back to normal: a: 1024M * 4.2BSD 0 0 0 b: 512M * swap c: 78156162 0 unused 0 0 # "raw" part, don't edit d: * * unused 0 0 After that, gmirror has stopped pissing me off, and I finished my plan, as below: # zpool status pool: tank state: ONLINE scrub: scrub completed with 0 errors on Wed Sep 3 10:10:07 2008 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad0s1d ONLINE 0 0 0 ad2s1d ONLINE 0 0 0 ad3s1d ONLINE 0 0 0 errors: No known data errors # gmirror status Name Status Components mirror/boot COMPLETE ad0s1a ad2s1a ad3s1a Good luck with ZFS everyone! :) And RTFM ;) -- Bartosz Stec - specjalista ds. IT AUXILIA Sp??ka z o.o. From kostikbel at gmail.com Wed Sep 3 12:40:00 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Sep 3 12:40:07 2008 Subject: vfs.ffs.rawreadahead In-Reply-To: <20080903095352.GA62541@rambler-co.ru> References: <20080903095352.GA62541@rambler-co.ru> Message-ID: <20080903123955.GE2038@deviant.kiev.zoral.com.ua> On Wed, Sep 03, 2008 at 01:53:52PM +0400, Igor Sysoev wrote: > Hi, > > could anyone tell what does vfs.ffs.rawreadahead enable ? > As I understand it's used in DIRECTIO code that allows read data > directly to an userland buffer bypassing the buffer cache. > What I can not understand where the read ahead data can be placed in ? The operation of the ffs_rawread is more accurately described as bypassing the page cache. It creates the physical buffer that maps the user pages. The readahead is performed only when the supplied user memory region is bigger then blocksize. In this case, two reads are performed simultaneously, with both buffers mapping consequent blocks from user-supplied buffers. The read operation looks like footsteps. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080903/3e07deb6/attachment.pgp From is at rambler-co.ru Wed Sep 3 12:49:37 2008 From: is at rambler-co.ru (Igor Sysoev) Date: Wed Sep 3 12:49:44 2008 Subject: vfs.ffs.rawreadahead In-Reply-To: <20080903123955.GE2038@deviant.kiev.zoral.com.ua> References: <20080903095352.GA62541@rambler-co.ru> <20080903123955.GE2038@deviant.kiev.zoral.com.ua> Message-ID: <20080903124733.GH62541@rambler-co.ru> On Wed, Sep 03, 2008 at 03:39:55PM +0300, Kostik Belousov wrote: > On Wed, Sep 03, 2008 at 01:53:52PM +0400, Igor Sysoev wrote: > > Hi, > > > > could anyone tell what does vfs.ffs.rawreadahead enable ? > > As I understand it's used in DIRECTIO code that allows read data > > directly to an userland buffer bypassing the buffer cache. > > What I can not understand where the read ahead data can be placed in ? > > The operation of the ffs_rawread is more accurately described as > bypassing the page cache. It creates the physical buffer that maps > the user pages. > > The readahead is performed only when the supplied user memory region > is bigger then blocksize. In this case, two reads are performed > simultaneously, with both buffers mapping consequent blocks from > user-supplied buffers. The read operation looks like footsteps. Nice! As I understand the size limit of one read operation is MAXPHYS, which is equal to 128K due to LBA28 ATA limit. On SCSI, SATA, and LBA48 ATA this limit can be increased. Is it safe ? -- Igor Sysoev http://sysoev.ru/en/ From kostikbel at gmail.com Wed Sep 3 13:01:57 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Sep 3 13:03:04 2008 Subject: vfs.ffs.rawreadahead In-Reply-To: <20080903124733.GH62541@rambler-co.ru> References: <20080903095352.GA62541@rambler-co.ru> <20080903123955.GE2038@deviant.kiev.zoral.com.ua> <20080903124733.GH62541@rambler-co.ru> Message-ID: <20080903130149.GF2038@deviant.kiev.zoral.com.ua> On Wed, Sep 03, 2008 at 04:47:33PM +0400, Igor Sysoev wrote: > On Wed, Sep 03, 2008 at 03:39:55PM +0300, Kostik Belousov wrote: > > > On Wed, Sep 03, 2008 at 01:53:52PM +0400, Igor Sysoev wrote: > > > Hi, > > > > > > could anyone tell what does vfs.ffs.rawreadahead enable ? > > > As I understand it's used in DIRECTIO code that allows read data > > > directly to an userland buffer bypassing the buffer cache. > > > What I can not understand where the read ahead data can be placed in ? > > > > The operation of the ffs_rawread is more accurately described as > > bypassing the page cache. It creates the physical buffer that maps > > the user pages. > > > > The readahead is performed only when the supplied user memory region > > is bigger then blocksize. In this case, two reads are performed > > simultaneously, with both buffers mapping consequent blocks from > > user-supplied buffers. The read operation looks like footsteps. > > Nice! > > As I understand the size limit of one read operation is MAXPHYS, which is > equal to 128K due to LBA28 ATA limit. On SCSI, SATA, and LBA48 ATA this limit > can be increased. Is it safe ? As I understand, mnt_iosize_max value, that is topped at MAXPHYS, is used to limit the size of the buffer cluster used for clustered reads/writes. This readw clustering sometimes is called readahead too, but it seems to not be directly related to readahead done by ffs_rawread.c. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080903/b89a3bfd/attachment.pgp From danallen46 at airwired.net Wed Sep 3 16:36:14 2008 From: danallen46 at airwired.net (Dan Allen) Date: Wed Sep 3 16:36:20 2008 Subject: FreeBSD 7.1 Content Message-ID: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> BACKGROUND: A few years ago one could get a FreeBSD CD and install X and get a decent basic system from one CD. One can still do this with Ubuntu today as well. Why can't we have a small window manager like icewm along with Firefox 3.0+ be among the packages on the first FreeBSD CD so a basic working system with a web browser can be a default install? Is it that X.org is now too big? I have been a FreeBSD user/builder for more than a decade because of / usr/src/make - complete sources and a beautiful build system, but I must admit that Ubuntu has done a great job of modern hardware detection and providing a nice useable system out of the box. I wish we could join both worlds in a future BSD release. (I crashed Ubuntu 8.04 in the first day so I still prefer BSD to Linux.) Also, and I am sure I am not the only one with one of these, my new $500 Dell Inspiron 1525 is not supported well by BSD RELENG_7: the Intel 4965 wireless and the Marvell 88E80xx Ethernet are both NOT supported so I have a great new laptop which cannot connect to the outside world with BSD. :-( Ubuntu supports these and lots more. SUMMARY: I would like to see FreeBSD 7.1 add to its disc1: 1) X.org 2) icewm 3) firefox-3.0 4) support for Intel 4965 wireless drivers 5) support for Marvell 88E8040 ethernet driver Dan Allen From scottl at samsco.org Wed Sep 3 17:14:13 2008 From: scottl at samsco.org (Scott Long) Date: Wed Sep 3 17:14:20 2008 Subject: vfs.ffs.rawreadahead In-Reply-To: <20080903124733.GH62541@rambler-co.ru> References: <20080903095352.GA62541@rambler-co.ru> <20080903123955.GE2038@deviant.kiev.zoral.com.ua> <20080903124733.GH62541@rambler-co.ru> Message-ID: <20080903103846.T39726@pooker.samsco.org> On Wed, 3 Sep 2008, Igor Sysoev wrote: > On Wed, Sep 03, 2008 at 03:39:55PM +0300, Kostik Belousov wrote: > >> On Wed, Sep 03, 2008 at 01:53:52PM +0400, Igor Sysoev wrote: >>> Hi, >>> >>> could anyone tell what does vfs.ffs.rawreadahead enable ? >>> As I understand it's used in DIRECTIO code that allows read data >>> directly to an userland buffer bypassing the buffer cache. >>> What I can not understand where the read ahead data can be placed in ? >> >> The operation of the ffs_rawread is more accurately described as >> bypassing the page cache. It creates the physical buffer that maps >> the user pages. >> >> The readahead is performed only when the supplied user memory region >> is bigger then blocksize. In this case, two reads are performed >> simultaneously, with both buffers mapping consequent blocks from >> user-supplied buffers. The read operation looks like footsteps. > > Nice! > > As I understand the size limit of one read operation is MAXPHYS, which is > equal to 128K due to LBA28 ATA limit. On SCSI, SATA, and LBA48 ATA this limit > can be increased. Is it safe ? > > The value of MAXPHYS is unrelated to capabilities or limitations of ATA. It was chosen based on the needs to prevent an excessive amount of parallel I/O from exhausting the kernel address space and system memory. In fact, the concern was with SCSI, not with ATA. MAXPHYS can be raised, especially on 64bit platforms, but doing so also bloats the sizes of a few key data structures. I've been looking at a solution for this, and I'd rather that people keep their MAXPHYS changes confined to their local trees rather than changing FreeBSD unless they also solve the associated side effects. SCott From is at rambler-co.ru Wed Sep 3 17:46:57 2008 From: is at rambler-co.ru (Igor Sysoev) Date: Wed Sep 3 17:47:05 2008 Subject: vfs.ffs.rawreadahead In-Reply-To: <20080903103846.T39726@pooker.samsco.org> References: <20080903095352.GA62541@rambler-co.ru> <20080903123955.GE2038@deviant.kiev.zoral.com.ua> <20080903124733.GH62541@rambler-co.ru> <20080903103846.T39726@pooker.samsco.org> Message-ID: <20080903174452.GB73831@rambler-co.ru> On Wed, Sep 03, 2008 at 10:44:46AM -0600, Scott Long wrote: > On Wed, 3 Sep 2008, Igor Sysoev wrote: > >On Wed, Sep 03, 2008 at 03:39:55PM +0300, Kostik Belousov wrote: > > > >>On Wed, Sep 03, 2008 at 01:53:52PM +0400, Igor Sysoev wrote: > >>>Hi, > >>> > >>>could anyone tell what does vfs.ffs.rawreadahead enable ? > >>>As I understand it's used in DIRECTIO code that allows read data > >>>directly to an userland buffer bypassing the buffer cache. > >>>What I can not understand where the read ahead data can be placed in ? > >> > >>The operation of the ffs_rawread is more accurately described as > >>bypassing the page cache. It creates the physical buffer that maps > >>the user pages. > >> > >>The readahead is performed only when the supplied user memory region > >>is bigger then blocksize. In this case, two reads are performed > >>simultaneously, with both buffers mapping consequent blocks from > >>user-supplied buffers. The read operation looks like footsteps. > > > >Nice! > > > >As I understand the size limit of one read operation is MAXPHYS, which is > >equal to 128K due to LBA28 ATA limit. On SCSI, SATA, and LBA48 ATA this > >limit > >can be increased. Is it safe ? > > The value of MAXPHYS is unrelated to capabilities or limitations of ATA. > It was chosen based on the needs to prevent an excessive amount of > parallel I/O from exhausting the kernel address space and system memory. > In fact, the concern was with SCSI, not with ATA. > > MAXPHYS can be raised, especially on 64bit platforms, but doing so also > bloats the sizes of a few key data structures. I've been looking at a > solution for this, and I'd rather that people keep their MAXPHYS changes > confined to their local trees rather than changing FreeBSD unless they > also solve the associated side effects. As I understand MAXPHYS affects at least on pager_map size: on modern machines it's usually 256 * MAXPHYS = 32M, therefore increasing MAXPHYS will increase the map too. The 128K is probably good value and I do not suggest to increase it by default, I just want to increase MAXPHYS to improve disk throughput on some hosts where nginx serves large files (1G+) using DIRECTIO. BTW, is it possible to change MAXPHYS to a loader tunnable ? -- Igor Sysoev http://sysoev.ru/en/ From scottl at samsco.org Wed Sep 3 17:56:19 2008 From: scottl at samsco.org (Scott Long) Date: Wed Sep 3 17:56:32 2008 Subject: vfs.ffs.rawreadahead In-Reply-To: <20080903174452.GB73831@rambler-co.ru> References: <20080903095352.GA62541@rambler-co.ru> <20080903123955.GE2038@deviant.kiev.zoral.com.ua> <20080903124733.GH62541@rambler-co.ru> <20080903103846.T39726@pooker.samsco.org> <20080903174452.GB73831@rambler-co.ru> Message-ID: <20080903114853.Q39726@pooker.samsco.org> On Wed, 3 Sep 2008, Igor Sysoev wrote: > On Wed, Sep 03, 2008 at 10:44:46AM -0600, Scott Long wrote: > >> On Wed, 3 Sep 2008, Igor Sysoev wrote: >>> On Wed, Sep 03, 2008 at 03:39:55PM +0300, Kostik Belousov wrote: >>> >>>> On Wed, Sep 03, 2008 at 01:53:52PM +0400, Igor Sysoev wrote: >>>>> Hi, >>>>> >>>>> could anyone tell what does vfs.ffs.rawreadahead enable ? >>>>> As I understand it's used in DIRECTIO code that allows read data >>>>> directly to an userland buffer bypassing the buffer cache. >>>>> What I can not understand where the read ahead data can be placed in ? >>>> >>>> The operation of the ffs_rawread is more accurately described as >>>> bypassing the page cache. It creates the physical buffer that maps >>>> the user pages. >>>> >>>> The readahead is performed only when the supplied user memory region >>>> is bigger then blocksize. In this case, two reads are performed >>>> simultaneously, with both buffers mapping consequent blocks from >>>> user-supplied buffers. The read operation looks like footsteps. >>> >>> Nice! >>> >>> As I understand the size limit of one read operation is MAXPHYS, which is >>> equal to 128K due to LBA28 ATA limit. On SCSI, SATA, and LBA48 ATA this >>> limit >>> can be increased. Is it safe ? >> >> The value of MAXPHYS is unrelated to capabilities or limitations of ATA. >> It was chosen based on the needs to prevent an excessive amount of >> parallel I/O from exhausting the kernel address space and system memory. >> In fact, the concern was with SCSI, not with ATA. >> >> MAXPHYS can be raised, especially on 64bit platforms, but doing so also >> bloats the sizes of a few key data structures. I've been looking at a >> solution for this, and I'd rather that people keep their MAXPHYS changes >> confined to their local trees rather than changing FreeBSD unless they >> also solve the associated side effects. > > As I understand MAXPHYS affects at least on pager_map size: on modern > machines it's usually 256 * MAXPHYS = 32M, therefore increasing MAXPHYS > will increase the map too. This is intended and desirable. > > The 128K is probably good value and I do not suggest to increase it by > default, I just want to increase MAXPHYS to improve disk throughput > on some hosts where nginx serves large files (1G+) using DIRECTIO. I've tested increases up to 1M, and they all are very beneficial not only for silly sequential style benchmarks but also for clustered i/o. 256-512k is the sweet spot, but Windows has set the standard at 1M and I'd like to have FreeBSD follow suit eventually. > > BTW, is it possible to change MAXPHYS to a loader tunnable ? > > No. Struct buf is sized based on MAXPHYS, and there's no convenient way yet to dynamically size that at runtime. Scott From peterjeremy at optushome.com.au Wed Sep 3 19:15:09 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Wed Sep 3 19:15:16 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> Message-ID: <20080903191454.GA15376@server.vk2pj.dyndns.org> On 2008-Sep-03 10:36:11 -0600, Dan Allen wrote: >Also, and I am sure I am not the only one with one of these, my new >$500 Dell Inspiron 1525 is not supported well by BSD RELENG_7: the >Intel 4965 wireless and the Marvell 88E80xx Ethernet are both NOT >supported so I have a great new laptop which cannot connect to the >outside world with BSD. :-( Ubuntu supports these and lots more. Your patches to add support for the i4965 and your Marvell 88E80xx must have been stripped by the mailing list software. Can you please re-send them. WiFi chip support is very hit-and-miss. Vendors won't release programming information because of regulatory issues and this makes supporting them very difficult. Have you tried using ndis? A large number of Marvell 88E80xx chips are supported by msk(4). If yours isn't, you are going to need to provide more details on what chip you have. >I would like to see FreeBSD 7.1 add to its disc1: > >1) X.org >2) icewm >3) firefox-3.0 >4) support for Intel 4965 wireless drivers >5) support for Marvell 88E8040 ethernet driver Disc1 is full. What do you suggest should be removed from disk1 to make space for the above? -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080903/91ff816d/attachment.pgp From cmt at burggraben.net Wed Sep 3 19:37:29 2008 From: cmt at burggraben.net (Christoph Moench-Tegeder) Date: Wed Sep 3 19:37:37 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: <48BE388C.7050706@zedat.fu-berlin.de> References: <48BD0C5A.4060706@zedat.fu-berlin.de> <20080902151456.GA1593@elch.haidundneu23.net> <48BE28F7.7030500@zedat.fu-berlin.de> <20080903063753.GA2120@reindeer.haidundneu23.net> <48BE388C.7050706@zedat.fu-berlin.de> Message-ID: <20080903193703.GA72896@elch.haidundneu23.net> ## O. Hartmann (ohartman@zedat.fu-berlin.de): > My box at home has an older NV6800GT and I do not have this special > issue, but instead I do have another well known issue of box-freezing. > This also happens with 'nv'. Whoa. Guess I'm lucky, as my nvidia chis is working, albeit quite slowly. My radeonhd-based card at home is way faster, but exhibits the same black-image-issue with firefox. Regards, Christoph -- Spare Space From mad at madpilot.net Wed Sep 3 19:54:09 2008 From: mad at madpilot.net (Guido Falsi) Date: Wed Sep 3 19:54:18 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> Message-ID: <48BEEB55.4050406@madpilot.net> Dan Allen wrote: > BACKGROUND: > > A few years ago one could get a FreeBSD CD and install X and get a > decent basic system from one CD. > > One can still do this with Ubuntu today as well. > > Why can't we have a small window manager like icewm along with Firefox > 3.0+ be among the packages on the first FreeBSD CD so a basic working > system with a web browser can be a default install? Is it that X.org is > now too big? > > SUMMARY: > > I would like to see FreeBSD 7.1 add to its disc1: > > 1) X.org > 2) icewm > 3) firefox-3.0 > 4) support for Intel 4965 wireless drivers > 5) support for Marvell 88E8040 ethernet driver > If you just want na instant workstation, why you just don't try Freesbie or something like that? If I install FreeBSD on a PC I expect this installation to live there for some years. I can spend some hours/days installing and configuring what I really need. At least this is the way I see it. Maybe I'm misunderstanding you. -- Guido Falsi From wxs at FreeBSD.org Wed Sep 3 20:15:13 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Wed Sep 3 20:15:20 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <20080903191454.GA15376@server.vk2pj.dyndns.org> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> Message-ID: <20080903195825.GC28299@atarininja.org> On Thu, Sep 04, 2008 at 05:14:55AM +1000, Peter Jeremy wrote: > On 2008-Sep-03 10:36:11 -0600, Dan Allen wrote: > >Also, and I am sure I am not the only one with one of these, my new > >$500 Dell Inspiron 1525 is not supported well by BSD RELENG_7: the > >Intel 4965 wireless and the Marvell 88E80xx Ethernet are both NOT > >supported so I have a great new laptop which cannot connect to the > >outside world with BSD. :-( Ubuntu supports these and lots more. > > Your patches to add support for the i4965 and your Marvell 88E80xx > must have been stripped by the mailing list software. Can you please > re-send them. > > WiFi chip support is very hit-and-miss. Vendors won't release > programming information because of regulatory issues and this makes > supporting them very difficult. Have you tried using ndis? I installed the June snapshot of -current on my laptop and it supports my Intel 4965 just fine. Support for this card is out there and does work, just not in RELENG_7. -- WXS From danallen46 at airwired.net Wed Sep 3 20:58:47 2008 From: danallen46 at airwired.net (Dan Allen) Date: Wed Sep 3 20:58:54 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <20080903191454.GA15376@server.vk2pj.dyndns.org> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> Message-ID: <32833CD6-DE00-4FDB-A01A-B86B0A25B3E4@airwired.net> On 3 Sep 2008, at 1:14 PM, Peter Jeremy wrote: > Your patches to add support for the i4965 and your Marvell 88E80xx > must have been stripped by the mailing list software. Can you please > re-send them. I have not written patches, thus I did not send any patches. Dan From danallen46 at airwired.net Wed Sep 3 21:01:50 2008 From: danallen46 at airwired.net (Dan Allen) Date: Wed Sep 3 21:02:02 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <48BEEB55.4050406@madpilot.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <48BEEB55.4050406@madpilot.net> Message-ID: On 3 Sep 2008, at 1:53 PM, Guido Falsi wrote: > If you just want na instant workstation, why you just don't try > Freesbie or something like that? Because I want something from the source -- from the main team -- and not something downstream. > If I install FreeBSD on a PC I expect this installation to live > there for some years. I can spend some hours/days installing and > configuring what I really need. At least this is the way I see it. > Maybe I'm misunderstanding you. I too spend the time. I am thinking that for other people to want to use FreeBSD they want something other than a command prompt. They at least want a web browser out of the box. The Ubuntu install is very compelling. I am just wishing that FreeBSD was AS compelling in its first install experience. At present it is far, far behind. That does not stop ME from preferring FreeBSD, but it stops many other people. Dan From danallen46 at airwired.net Wed Sep 3 21:05:42 2008 From: danallen46 at airwired.net (Dan Allen) Date: Wed Sep 3 21:05:48 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <20080903195825.GC28299@atarininja.org> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <20080903195825.GC28299@atarininja.org> Message-ID: <55EA18D2-E017-4426-9377-1FC113ED83D2@airwired.net> On 3 Sep 2008, at 1:58 PM, Wesley Shields wrote: > I installed the June snapshot of -current on my laptop and it supports > my Intel 4965 just fine. Support for this card is out there and does > work, just not in RELENG_7. On 3 Sep 2008, at 2:45 PM, Gavin Atkinson wrote: > There is support for the Intel 4965 in HEAD, with the iwn(4) driver. Thanks guys for the info. Not having ANY wired or wireless support in FreeBSD for a very decent Dell laptop that is flying off of the shelves at $500, I deleted FreeBSD from the machine and installed Ubuntu 8.04. I therefore cannot run "pciconf -l" at this moment in time, but I may get back around to it. Stay tuned... maybe for 7.2. Dan From gavin at FreeBSD.org Wed Sep 3 21:16:32 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Wed Sep 3 21:16:39 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> Message-ID: <20080903211010.G57629@ury.york.ac.uk> On Wed, 3 Sep 2008, Dan Allen wrote: > Also, and I am sure I am not the only one with one of these, my new $500 Dell > Inspiron 1525 is not supported well by BSD RELENG_7: the Intel 4965 wireless > and the Marvell 88E80xx Ethernet are both NOT supported so I have a great new > laptop which cannot connect to the outside world with BSD. :-( Ubuntu > supports these and lots more. There is support for the Intel 4965 in HEAD, with the iwn(4) driver. I don't know how likely this is to be merged before 7.1, but I suspect if people test it and confirms that it works for them, it may be possible. As for the 88E80xx, it probably depends exaclty which chipset you are talking about. Several are already supported with the msk(4) driver, have you tried it? If that doesn't work, the output of "pciconf -l" will be necessary before there's any chance of helping. Gavn From killing at multiplay.co.uk Wed Sep 3 21:26:34 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Wed Sep 3 21:26:42 2008 Subject: FreeBSD 7.1 Content References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net><48BEEB55.4050406@madpilot.net> Message-ID: ----- Original Message ----- From: "Dan Allen" > I too spend the time. I am thinking that for other people to want to > use FreeBSD they want something other than a command prompt. They at > least want a web browser out of the box. For some, but for others like ourselves here we really don't want all that bloat. One of the reasons we really like it is its perfect for server installs, no crap installed that you don't want :) Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From k at kevinkevin.com Wed Sep 3 21:28:12 2008 From: k at kevinkevin.com (Kevin) Date: Wed Sep 3 21:28:19 2008 Subject: FreeBSD 7.1 Content In-Reply-To: References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <48BEEB55.4050406@madpilot.net> Message-ID: <000b01c90e0b$eba99b40$c2fcd1c0$@com> > The Ubuntu install is very compelling. I am just wishing that FreeBSD > was AS compelling in its first install experience. At present it is > far, far behind. > > That does not stop ME from preferring FreeBSD, but it stops many other > people. FreeBSD is primarily a server oriented operating system, while ubuntu is geared (from a development and design perspective) towards the desktop market. This is the primary reason why you are experiencing this. ~k From kuuse at redantigua.com Wed Sep 3 21:46:20 2008 From: kuuse at redantigua.com (Johan Kuuse) Date: Wed Sep 3 21:46:27 2008 Subject: kernel panic In-Reply-To: <200808121439.48158.jhb@freebsd.org> References: <1179.83.49.238.144.1218565410.frodo@webmail.bilbomedia.com> <200808121439.48158.jhb@freebsd.org> Message-ID: <200809032346.14053.kuuse@redantigua.com> On Tuesday 12 August 2008 20:39:47 you wrote: > On Tuesday 12 August 2008 02:23:30 pm Johan Kuuse wrote: > > > On Tuesday 12 August 2008 02:42:52 am Johan Kuuse wrote: > > >> On Monday 11 August 2008 23:04:30 John Baldwin wrote: > > >> > On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote: > > >> > > Hi, > > >> > > > > >> > > I am a kgdb newbie, so please be patient. > > >> > > I suspect (just based on the fact that this is the 4th time I edit > text > > >> > > > >> > files on my NTFS partition through ntfs-3g, using Emacs, and getting > > >> > frequent I/O error messages inside Emacs, and then a kernel panic) that > > >> > this is a ntfs-3g related problem. > > >> > > > >> > > If you ask me exactly how to reproduce it, I sorry, I can tell you > > >> > > exactly > > >> > > > >> > (but see the kgdb output below). > > >> > > > >> > > Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530 > > >> > > > > >> > > Just a suggestion for a patch (without knowing the functionality > > >> > > > >> > of /usr/src/sys/kern/vfs_bio.c): > > >> > > The line where the kernel panics: > > >> > > /usr/src/sys/kern/vfs_bio.c: > > >> > > ---------------------------------- > > >> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > >> > > ... > > >> > > ---------------------------------- > > >> > > > > >> > > Comparing to another file, which does error checking before calling > > >> > > > >> > VM_OBJECT_LOCK: > > >> > > /usr/src/sys/kern/vfs_aio.c: > > >> > > ---------------------------------- > > >> > > if (vp->v_object != NULL) { > > >> > > VM_OBJECT_LOCK(vp->v_object); > > >> > > ... > > >> > > ---------------------------------- > > >> > > > > >> > > Perhaps the kernel panic could be avoided with the following patch? > > >> > > /usr/src/sys/kern/vfs_bio.c (suggested patch): > > >> > > ---------------------------------- > > >> > > if ((bp->b_bufobj != NULL) && (bp->b_bufobj->bo_object != NULL)) { > > >> > > VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > >> > > ... > > >> > > ---------------------------------- > > >> > > > > >> > > Please let me know if you need more information. > > >> > > > > >> > > Regards, > > >> > > Johan Kuuse > > >> > > > > >> > > > ----------------------------------------------------------------------- > > >> > >------------------------------------ kgdb kernel.debug > > >> > > /var/crash/vmcore.1 > > >> > > [GDB will not be able to debug user-mode threads: > > >> > > /usr/lib/libthread_db.so: > > >> > > > >> > Undefined symbol "ps_pglobal_lookup"] > > >> > > > >> > > GNU gdb 6.1.1 [FreeBSD] > > >> > > Copyright 2004 Free Software Foundation, Inc. > > >> > > GDB is free software, covered by the GNU General Public License, and > > >> > > you are welcome to change it and/or distribute copies of it under > > >> > > certain > > >> > > > >> > conditions. > > >> > > > >> > > Type "show copying" to see the conditions. > > >> > > There is absolutely no warranty for GDB. Type "show warranty" for > > >> > > details. This GDB was configured as "i386-marcel-freebsd". > > >> > > > > >> > > Unread portion of the kernel message buffer: > > >> > > > > >> > > > > >> > > Fatal trap 12: page fault while in kernel mode > > >> > > cpuid = 0; apic id = 00 > > >> > > fault virtual address = 0x34 > > >> > > fault code = supervisor read, page not present > > >> > > instruction pointer = 0x20:0xc07b6de4 > > >> > > stack pointer = 0x28:0xe79de7c8 > > >> > > frame pointer = 0x28:0xe79de7e8 > > >> > > code segment = base 0x0, limit 0xfffff, type 0x1b > > >> > > = DPL 0, pres 1, def32 1, gran 1 > > >> > > processor eflags = interrupt enabled, resume, IOPL = 0 > > >> > > current process = 1214 (opera) > > >> > > trap number = 12 > > >> > > panic: page fault > > >> > > cpuid = 0 > > >> > > Uptime: 5h20m30s > > >> > > Physical memory: 2035 MB > > >> > > Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11 > > >> > > > > >> > > #0 doadump () at pcpu.h:195 > > >> > > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > > >> > > (kgdb) list *0xc07b6de4 > > >> > > 0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530). > > >> > > 1525 vfs_vmio_release(struct buf *bp) > > >> > > 1526 { > > >> > > 1527 int i; > > >> > > 1528 vm_page_t m; > > >> > > 1529 > > >> > > 1530 VM_OBJECT_LOCK(bp->b_bufobj->bo_object); > > >> > > 1531 vm_page_lock_queues(); > > >> > > 1532 for (i = 0; i < bp->b_npages; i++) { > > >> > > 1533 m = bp->b_pages[i]; > > >> > > 1534 bp->b_pages[i] = NULL; > > >> > > (kgdb) bt > > >> > > #0 doadump () at pcpu.h:195 > > >> > > #1 0xc0754457 in boot (howto=260) at > > >> > > /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic > > >> > > (fmt=Variable "fmt" is not available. > > >> > > ) at /usr/src/sys/kern/kern_shutdown.c:563 > > >> > > #3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52) > > >> > > > >> > at /usr/src/sys/i386/i386/trap.c:899 > > >> > > > >> > > #4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52) > > >> > > > >> > at /usr/src/sys/i386/i386/trap.c:812 > > >> > > > >> > > #5 0xc0a49c8c in trap (frame=0xe79de788) > > >> > > > >> > at /usr/src/sys/i386/i386/trap.c:490 > > >> > > > >> > > #6 0xc0a2fc0b in calltrap () > at /usr/src/sys/i386/i386/exception.s:139 > > >> > > #7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c) > > >> > > > >> > at /usr/src/sys/kern/vfs_bio.c:1530 > > >> > > > >> > > #8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Variable > > >> > > "size" is > > >> > > > >> > not available. > > >> > > > >> > > ) at /usr/src/sys/kern/vfs_bio.c:1847 > > >> > > #9 0xc07ba118 in getblk (vp=0xc8891bb0, blkno=0, size=2048, > slpflag=0, > > >> > > > >> > slptimeo=0, flags=Variable "flags" is not available. > > >> > > > >> > > ) at /usr/src/sys/kern/vfs_bio.c:2602 > > >> > > #10 0xc0932815 in ffs_balloc_ufs2 (vp=0xc8891bb0, > > >> > > > >> > startoffset=Variable "startoffset" is not available. > > >> > > > >> > > ) at /usr/src/sys/ufs/ffs/ffs_balloc.c:699 > > >> > > #11 0xc0952a85 in ffs_write (ap=0xe79debc4) > > >> > > > >> > at /usr/src/sys/ufs/ffs/ffs_vnops.c:720 > > >> > > > >> > > #12 0xc0a5efc6 in VOP_WRITE_APV (vop=0xc0b93c60, a=0xe79debc4) at > > >> > > > >> > vnode_if.c:691 > > >> > > > >> > > #13 0xc07dbf37 in vn_write (fp=0xc85f3168, uio=0xe79dec60, > > >> > > > >> > active_cred=0xc61c6300, flags=0, td=0xc583fc60) at vnode_if.h:373 > > >> > > > >> > > #14 0xc07875e7 in dofilewrite (td=0xc583fc60, fd=17, fp=0xc85f3168, > > >> > > > >> > auio=0xe79dec60, offset=-1, flags=0) at file.h:254 > > >> > > > >> > > #15 0xc07878c8 in kern_writev (td=0xc583fc60, fd=17, auio=0xe79dec60) > > >> > > > >> > at /usr/src/sys/kern/sys_generic.c:401 > > >> > > > >> > > #16 0xc078793f in write (td=0xc583fc60, uap=0xe79decfc) > > >> > > > >> > at /usr/src/sys/kern/sys_generic.c:317 > > >> > > > >> > > #17 0xc0a49635 in syscall (frame=0xe79ded38) > > >> > > > >> > at /usr/src/sys/i386/i386/trap.c:1035 > > >> > > > >> > > #18 0xc0a2fc70 in Xint0x80_syscall () > > >> > > > >> > at /usr/src/sys/i386/i386/exception.s:196 > > >> > > > >> > > #19 0x00000033 in ?? () > > >> > > Previous frame inner to this frame (corrupt stack?) > > >> > > > >> > FYI, you got the panic in ffs/ufs, not fuse. I've seen this at work on > > >> > 6.x with NFS with no clues on what causes it. You can start by going > to > > >> > frame 7 and doing 'p *bp'. > > >> > > >> Thanks for the hints. > > >> See below for more debug output. > > >> I recognize that the bp struct members b_data and b_kvabase both point to > a > > >> chunk of memory containing the text of the Opera web page I was reading > > >> when the kernel crashed. (This is indicated above: current process > > >> = 1214 (opera)) > > >> > > >> But what is most interesting is that b_bufobj = 0x0 > > >> Obviously, then trying to access bp->b_bufobj->bo_object will cause a > > >> crash. So I think it would be a good idea to NULL-check the struct member > > >> before trying to access it. How should I proceed? Should I post this as a > > >> possible bug somewhere else, to another list? > > > > > > Unfortunately, it is a worse problem that b_bufobj is NULL. That means > there > > > is a bug elsewhere. I'll look at this some more. > > > > > > Hmm, can you reproduce this at all? If so, can you try the patch below. > > > Hopefully it panics here which might help: > > > > > > Index: vfs_subr.c > > > =================================================================== > > > --- vfs_subr.c (revision 181629) > > > +++ vfs_subr.c (working copy) > > > @@ -1546,6 +1546,9 @@ > > > CTR3(KTR_BUF, "brelvp(%p) vp %p flags %X", bp, bp->b_vp, bp->b_flags); > > > KASSERT(bp->b_vp != NULL, ("brelvp: NULL")); > > > > > > + if (bp->flags & B_VMIO) > > > + panic("brelvp of B_VMIO buffer"); > > > + > > > /* > > > * Delete from old vnode list, if on one. > > > */ > > > > > > -- > > > John Baldwin > > > > > > > Sorry, at the moment I don't know how to reproduce the crash. > > I mentioned ntfs-ng/fuse as I got the impression that they caused a heavy > load > > on my box, but in the end, it was Opera which caused the crash (also causing > a > > heavy load, however). > > What I can do is to apply your patch and play around with CPU-consuming apps > to > > try if I can reproduce the crash during heavy load. > > Ok. > > > Currently I'm running 7.-0-RELEASE. > > Do you recommend me to upgrade to STABLE before applying the patch? > > No, you can just leave it as it is. At work I've seen this occasionally on > 6.x, so it's probably an older bug. > Hi again, I got another kernel panic in vfs_subr.c, but not in the patched function brelvp(), but in delmntque(). At the moment of the kernel panic, I was installing the sysutils/e2fsprogs, which performs some ext2fs mount/umount tests during install. Debug output listed below. Please let me know if you need some more info. Regards, Johan Kuuse -------------------------------------------------------------------------------- cd /usr/obj/usr/src/sys/MYDEBUGKERNEL kgdb kernel.debug /var/crash/vmcore.4 -------------------------------------------------------------------------------- [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc07cb876 stack pointer = 0x28:0xe79a8824 frame pointer = 0x28:0xe79a8860 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12674 (mtree) trap number = 12 panic: page fault cpuid = 0 Uptime: 29m39s Physical memory: 2035 MB Dumping 152 MB: 137 121 105 89 73 57 41 25 9 #0 doadump () at pcpu.h:195 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); -------------------------------------------------------------------------------- (kgdb) list *0xc07cb876 -------------------------------------------------------------------------------- 0xc07cb876 is in vgonel (/usr/src/sys/kern/vfs_subr.c:990). 985 return; 986 MNT_ILOCK(mp); 987 vp->v_mount = NULL; 988 VNASSERT(mp->mnt_nvnodelistsize > 0, vp, 989 ("bad mount point vnode list size")); 990 TAILQ_REMOVE(&mp->mnt_nvnodelist, vp, v_nmntvnodes); 991 mp->mnt_nvnodelistsize--; 992 MNT_REL(mp); 993 MNT_IUNLOCK(mp); 994 } -------------------------------------------------------------------------------- (kgdb) From danallen46 at airwired.net Wed Sep 3 21:53:33 2008 From: danallen46 at airwired.net (Dan Allen) Date: Wed Sep 3 21:53:40 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <20080903191454.GA15376@server.vk2pj.dyndns.org> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> Message-ID: On 3 Sep 2008, at 1:14 PM, Peter Jeremy wrote: > Disc1 is full. What do you suggest should be removed from disk1 to > make space for the above? I see. I was thinking of FreeBSD 7.0 whose disc1 is 509 MB in size, leaving almost 200 MB free for a standard 700 MB CD. Q: Has FreeBSD 7.1 REALLY filled up 189 MB with bug fixes and new hardware support? Ubuntu 8.04 has room for the linux kernel, for GCC, for tons of packages including almost all of OpenOffice 2.2.1 (which is HUGE), GIMP, Firefox, X of course, and quite a few other things on their 700 MB CD, including support for lots of new hardware that BSD does not have. BSD has source code -- which I personally would rather have than GIMP, etc. -- but do the sources take up that much room? They take 70-80 MB, but the bulk of that is already included in the above 509 MB of 7.0 disc1. (BTW, having full sources as part of FreeBSD is in my opinion one of the coolest features of BSD so that should NEVER be compromised.) So, I where the BSD free space is going?? Here is a quick list (not exhaustive or definitive) of the libraries that Firefox 3.0 requires, and their sizes in bytes: 3969 firefox 8332 firefox-bin 1080753 libX11.so.6 9564 libXcomposite.so.1 40524 libXcursor.so.1 9040 libXdamage.so.1 64848 libXext.so.6 18716 libXfixes.so.3 37019 libXi.so.6 9279 libXinerama.so.1 26618 libXrandr.so.2 35933 libXrender.so.1 132271 libatk-1.0.so.0 478869 libcairo.so.2 204002 libfontconfig.so.1 341460 libfreebl3.so 514577 libfreetype.so.9 603150 libgdk-x11-2.0.so.0 102751 libgdk_pixbuf-2.0.so.0 760129 libglib-2.0.so 13540 libgmodule-2.0.so.0 251326 libgobject-2.0.so.0 3930035 libgtk-x11-2.0.so.0 592012 libmozjs.so 238383 libnspr4.so.1 1140648 libnss3.so 324468 libnssckbi.so 113912 libnssdbm3.so 86560 libnssutil3.so 262000 libpango-1.0.so.0 37947 libpangocairo-1.0.so.0 163539 libpangoft2-1.0.so.0 213877 libplc4.so.1 209648 libplds4.so.1 145260 libsmime3.so 210076 libsoftokn3.so 409876 libsqlite3.so 180320 libssl3.so 13296 libxpcom.so 14678048 libxul.so These total 27696575 bytes or 26.4 MB. Notice this includes some of X (but I am sure some of these libraries include other libraries that are not included in this total. This is not a full DAG analysis.) Firefox also links to libc, libz, libm and other common libs, but they are part of the base system so they are not on this list. Compressed using tar czpf (gzip) these files occupy 11003400 bytes or 10.5 MB. Compressed using tar cjpf (bzip) these files occupy 10124743 bytes or 9.7 MB! Dan From phill at sysctl.net Wed Sep 3 22:09:17 2008 From: phill at sysctl.net (Phillip Salzman) Date: Wed Sep 3 22:09:24 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <000b01c90e0b$eba99b40$c2fcd1c0$@com> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <48BEEB55.4050406@madpilot.net> <000b01c90e0b$eba99b40$c2fcd1c0$@com> Message-ID: I second that FreeBSD is a server OS, but do sympathize with what Dan has mentioned. Opening new audiences of course starts with a quick install on a desktop or laptop. An easy answer would be to put the web-browser and such the first disk, but I don't think it would solve anything. If it kept with those, FreeBSD would find itself just moving towards the same work being done at PC-BSD, wouldn't it? Phillip Salzman On Wed, Sep 3, 2008 at 2:27 PM, Kevin wrote: > > The Ubuntu install is very compelling. I am just wishing that FreeBSD > > was AS compelling in its first install experience. At present it is > > far, far behind. > > > > That does not stop ME from preferring FreeBSD, but it stops many other > > people. > > > FreeBSD is primarily a server oriented operating system, while ubuntu is > geared (from a development and design perspective) towards the desktop > market. > > This is the primary reason why you are experiencing this. > > > ~k > > > _______________________________________________ > 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 danallen46 at airwired.net Wed Sep 3 22:43:48 2008 From: danallen46 at airwired.net (Dan Allen) Date: Wed Sep 3 22:43:55 2008 Subject: FreeBSD 7.1 Content In-Reply-To: References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net><48BEEB55.4050406@madpilot.net> Message-ID: On 3 Sep 2008, at 3:11 PM, Steven Hartland wrote: > ----- Original Message ----- From: "Dan Allen" > > >> I too spend the time. I am thinking that for other people to want >> to use FreeBSD they want something other than a command prompt. >> They at least want a web browser out of the box. > > For some, but for others like ourselves here we really don't want all > that bloat. One of the reasons we really like it is its perfect for > server installs, no crap installed that you don't want :) Agreed, but if you go back to earlier versions of FreeBSD they gave you an install option for just binaries, or binaries + sources, or binaries + sources + X Windows. I am proposing something similar once again, but this time if would be enough of X, a small window manager, and Firefox so a basic windowing environment was able to be installed, from the CD, with a single choice. I doubt many developers are really browsing the web all day with lynx. Dan From mad at madpilot.net Wed Sep 3 22:58:32 2008 From: mad at madpilot.net (Guido Falsi) Date: Wed Sep 3 22:58:40 2008 Subject: FreeBSD 7.1 Content In-Reply-To: References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net><48BEEB55.4050406@madpilot.net> Message-ID: <48BF1694.9010108@madpilot.net> Dan Allen wrote: > > On 3 Sep 2008, at 3:11 PM, Steven Hartland wrote: > >> ----- Original Message ----- From: "Dan Allen" >> >>> I too spend the time. I am thinking that for other people to want >>> to use FreeBSD they want something other than a command prompt. >>> They at least want a web browser out of the box. >> >> For some, but for others like ourselves here we really don't want all >> that bloat. One of the reasons we really like it is its perfect for >> server installs, no crap installed that you don't want :) > > Agreed, but if you go back to earlier versions of FreeBSD they gave you > an install option for just binaries, or binaries + sources, or binaries > + sources + X Windows. Last time I installed from CD (I have made some manual installs from livefs lately because this gives me more options for disk layouts(gjournal/gmirror for example) ) there was an option to install X and other ports. Never used it though. > > I am proposing something similar once again, but this time if would be > enough of X, a small window manager, and Firefox so a basic windowing > environment was able to be installed, from the CD, with a single > choice. I doubt many developers are really browsing the web all day > with lynx. > The choice is there I think, It just requires you to swap CDs. It's of little use to newbies though, you still need to customize rc.conf and other bits. Also, FreeBSD is still a little download compared to other systems. I would not like to download a multiGB distribution when what I need is just base system + sources, to build everything up from there. -- Guido Falsi From danallen46 at airwired.net Wed Sep 3 23:01:34 2008 From: danallen46 at airwired.net (Dan Allen) Date: Wed Sep 3 23:01:40 2008 Subject: FreeBSD 7.1 Content Message-ID: <0497DBEF-6DC8-4DDD-9ED4-EAD9188D660C@airwired.net> Phillip Salzman wrote: > An easy answer would be to put the web-browser and such the first > disk, but > I don't think it would solve anything. If it kept with those, > FreeBSD would > find itself just moving towards the same work being done at PC-BSD, > wouldn't > it? When I see almost 200 MB free on disc1 of 7.0, and I remember the handy apps & pkgs which used to be on past releases of FreeBSD, I do not see it as moving towards PC-BSD as much as I see it as going back to what FreeBSD used to have just a few releases ago. In truth, for workstations and laptops at least, most of us do want a web browser. Not having a decent web browser out of the box in 2008 after 15 years of web browser development gives BSD a really archaic look and feel. We all know that BSD is the best, most solid OS out there - but occasionally we need to do a bit of marketing, we need to show our stuff to let others see that "we get it". Dan From danallen46 at airwired.net Wed Sep 3 23:04:13 2008 From: danallen46 at airwired.net (Dan Allen) Date: Wed Sep 3 23:04:22 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <48BF1694.9010108@madpilot.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net><48BEEB55.4050406@madpilot.net> <48BF1694.9010108@madpilot.net> Message-ID: <1364EE81-0BD1-4F7D-9B83-2C92E1A22AD7@airwired.net> On 3 Sep 2008, at 4:58 PM, Guido Falsi wrote: > Also, FreeBSD is still a little download compared to other systems. > I would not like to download a multiGB distribution when what I need > is just base system + sources, to build everything up from there. I do not want to download a big multi GB distro either. If you however could see how much cool stuff Ubuntu has in their single CD, you would be very impressed. (See my earlier mail.) We can do much better. Dan PS - back in the BSD 4.0-5.0 timeframe rc.conf got setup by the installer for you so that you could get X up and going without much hassle at all. From iceman_79701 at att.net Wed Sep 3 23:29:12 2008 From: iceman_79701 at att.net (TechAutoCareers.com) Date: Wed Sep 3 23:29:21 2008 Subject: Press Release: For Imediate Release Message-ID: <00e73e5f$39694$019f7516999421@unimatrix001> "If you cannot see graphics in this email, [1]click here to view it as a web page." "To make sure you continue to receive email from us -- including order confirmation and special offers please add [2]customer_care@techautocareers.com to your address book or safe list." For more information contact: Marketing Director / Gayle Bower: [3]Gayle Trainer@techautocareers.com TAC's Logo "We aim to be the definitive Sales Training point of reference on the web for Automotive Sales Consultants worldwide"(TM) Techniques in Automotive Careers the online Resource for Automotive Sales Consultants TAC's Group [bar101.jpg] News TACpubUSAź Techniques in Automotive Careers(TM) TechAutoCareers.comź UPDATE: TechAutoCareers.comź A new look, more information PRESS RELEASE: For Immediate Release [4]CONTACT: [5]customer_care@TechAutoCareers.com I.C. Collins 2900 W. Illinois Ave. Ste.# 4 Midland, TX 79701 1-432 - 699-6890 Techniques in Automotive Careers the online resource for Automotive Sales Consultants(TM) ( [6]TechAutoCareers.comź ) the independent publishing division of TACpubUSAź has updated our look. [7]TechAutoCareers.comź (TAC) announces the expansion of its online product selection for today's TechAutoCareersź / Automotive Sales Consultants. What's New? [8]TAC's 360 Sales Training Blog. Wait! There's More Lots of FREE sales training information available for Automotive Sales Consultants just got a whole lot easier with more information on [9]TAC's Sales Training Blog and [10]TAC's 360 so feel free to stop by. We've always worked hard to publish the most authoritative, insightful and relevant information on the latest automotive sales techniques regarding marketplace trends and ethics best practices in the Automotive Sales Fraternity. Not one of our competitors can provide all of these features. Send us your feedback & tell us what you think.. Our goal with this transformation was to make TechAutoCareers.comź as visually interesting and engaging as the stories we publish. To this end, we've overhauled our look from top to bottom and made some adjustments to our coverage to match our new design. Provide even more information than before so you may take advantage of our rapidly improving web site at [11]TAC's Sales Training Blog. We've always put a great deal of effort into our Web Sites because we strongly believe it is important for you to have a solid and accurate objective foundation to support our subjective observations about Automotive Sales Training. We remain the only Automotive Sales Training Web site that regularly publishes latest automotive sales techniques regarding marketplace trends and ethics best practices in the business. Come grow with us at [12]TAC's Group, [13]TAC's 360 and [14]TAC's Sales Training Blog. Please take notice the term TechAutoCareersź is a registered collective membership mark that identifies a Automotive Sales Consultant / TechAutoCareersź who is a member of Techniques in Automotive Careers online resource for automotive sales consultants and subscribes to its strict [15]Code of Ethics. Our goal is to inspire TechAutoCareersź to drive change within their organizations, making customer-based initiatives and relationship selling the centerpiece of their growth strategy. TechAutoCareersź occupations are among the most important occupations in the dealership. Their success in selling vehicles and services determines the success of the dealership. TechAutoCareersź usually are the first to greet customers and determine their interests through a series of questions. Before entering the dealership, many customers use the Internet to research and compare vehicle prices, features, and options. TechAutoCareersź then explain and demonstrate the vehicle's features in the showroom and on the road. Working closely with their customers, they negotiate the final terms and price of the sale. TechAutoCareersź must be tactful, well-groomed, and able to express themselves well. Their success in sales depends upon their ability to win the respect and trust of prospective customers. TAC's integrated approach to sales training has been proven to boost sales results. TechAutoCareersź equipped with The Handbook For Automotive Sales Consultants(TM) an industry-proven handbook with results-based techniques, delivered by a 25-year auto industry veteran teaching state-of-the-art processes, will get you out in front of the competition early. The Handbook For Automotive Sales Consultants(TM) (Should be required reading for management and auto sales consultants) instructs TechAutoCareersź on the fundamentals of selling, customer service, and follow-up. For instance the handbook will deliver and demonstrate advanced persuasion-based sales techniques, it combines sales training with a good read. Explaining in great detail how to create a "interpersonal selling experience" it offers an insight into sales that you may never have thought about before. As a result, TechAutoCareersź capitalize on their interactions with customers, maximizing profits while creating customer satisfaction and loyalty. We hope you enjoy the new look of TechAutoCareers.comź. Let us know what you think through the usual channels. You will not find a more useful site. The site offers everything that Automotive Sales Consultants need to succeed in the Automotive Sales Fraternity. TAC is firmly committed to being the premiere trusted resource for Automotive Sales Consultants worldwide. TechAutoCareers.comź promises to be everything to a select few. Rather than going after the wide consumer audience, it is focused on the Automotive Sales Fraternity. Offering a unique blend of original material, news feed summaries, galleries and a forum, TechAutoCareers.comź gives visitors the best of what the web format has to offer. Fun and irreverent, [16]TAC's Sales Training Blog has some great photography and unique articles that make it worth a permanent bookmark. We will continue to cover, as we have since 2000 ([17]TAC's Sales Training Blog), all the motor vehicles that come to market that are available to our readers. But we will focus our coverage on those machines that have strong appeal to mainstream car enthusiasts. From the Publisher A career in the automotive industry isn't for the timid. You need an energetic and outgoing personality, a healthy work ethic, and the drive and commitment to build your client base. But there's more: you also need to know how to open yourself to opportunity. A sales veteran with a stellar record, I. C. Collins shows you how to do just that as you earn your way to top salesperson of the month. Whether you're new to the automotive business or have worked the floor for decades, you'll find all the motivation and guidance you need to earn bigger and better commissions in The Handbook For Automotive Sales Consultants(TM) comes with a money back* - Guarantee - all designed to maximize performance and profitability. About TechAutoCareers.comź TechAutoCareers.comź is the first and only company with the firm commitment to satisfying one important market, the Automotive Sales Consultant. As a Business Unit of TACpubUSAź, a 14-year-old company. TechAutoCareers.comź was formed to focus on the needs of the Automotive Sales Fraternity - Dealers' and sales consultants alike. With a primary goal of being an open exchange of ideas and to provide proven techniques to insure productivity. TAC believes sharing is about much more than just sacrificing some of what you've got and giving it to someone else! In reality, sharing is all about connecting with other people and joining in an experience together.. Serving clients and employees throughout North America and Globally TechAutoCareers.comź leads the industry in providing unmatched satisfaction. Because we are an integral part of the automotive industry, our "insider" experience allows us to be the online resource for automotive sales consultants so you get the information essential to the Automotive Sales Fraternity in today's market. The Handbook For Automotive Sales Consultants(TM) can be ordered online or factory direct. The company is headquartered in Midland, TX. TACpubUSAź, 2900 W. Illinois Ave. Ste.# 4 Midland, TX 79701 1-432- 699-6890 Thanks, Marketing Director / Gayle Bower: [18]Gayle_Trainer@techautocareers.com P.S. Did a friend send you this? Go Visit [19]TechAutoCareers.comź - it's award-winning, useful, and complimentary. P.P.S. Got questions, comments, or ideas for editorial? Email Editorial Director I.C. Collins at [20]Editor-in-Chief@techautocareers.com or call Customer Service at (432) 699-6890 -- thanks! "How To Succeed In The Automotive Sales Industryź: The Handbook For Automotive Sales Consultants" (TM) can be ordered online [21]BUY NOW or factory direct. Forward-Looking Statements All statements made in this release, other than statements of historical fact, are forward-looking statements. The words "anticipate," "believe," "estimate," "expect," "intend," "may," "plan," "will," "would," "should," "guidance," "potential," "continue," "project," "forecast," "confident," "prospects," "schedule" and similar expressions typically are used to identify forward-looking statements. Forward-looking statements are based on the then-current expectations, beliefs, assumptions, estimates and forecasts about the business of TACpubUSAź. These statements are not guarantees of future performance and involve risks, uncertainties and assumptions which are difficult to predict. Therefore, actual outcomes and results may differ materially from what is expressed or implied by these forward-looking statements. Factors which may affect TACpubUSAź's business, financial condition and operating results include the effects of changes in the economy, consumer spending, the financial markets and the industries in which TACpubUSAź and its partners operate, changes affecting the Internet and e-commerce, the ability of TACpubUSAź to develop and maintain relationships with strategic partners and suppliers and the timing of its establishment, extension or termination of its relationships with strategic partners, the ability of TACpubUSAź to timely and successfully develop, maintain and protect its technology, confidential and proprietary information, and product and service offerings and execute operationally, the ability of TACpubUSAź to attract and retain qualified personnel, and the ability of TACpubUSAź to successfully integrate its acquisitions of other businesses, if any, the performance of acquired businesses. TACpubUSAź expressly disclaims any intent or obligation to update these forward-looking statements. " The trusted resource' for Automotive Sales Consultants worldwide, A Success and Still Growing (TM) " [22]Send to a friend [23]Contact us "We value your privacy" [24]Terms of Service | [25]Privacy Policy TACpubUSAź 2900 W. Illinois Ave. Ste.# 4 Midland, TX 79701 1-432- 699-6890 For more information contact Marketing Director / Gayle Bower [26]Gayle_Trainer@techautocareers.com © copyright 1994-2008 TACpubUSAź / TAC All rights reserved. Mr. Collins is President of TechAutoCareers.comź and Ethics & Compliance Strategies in Midland, TX He assists Dealers and management in the development, implementation and management of ethics and compliance programs which support good business practices, encourage ethical decision making, assist in adherence to regulatory requirements. [909w423.jpg] I. C. Collins Director of TACpubUSAź / [27]TechAutoCareers.comź and Ethics & Compliance Strategies CONTACT: TACpubUSAź 2900 W. Illinois Ste. # 4 Midland, TX 79701 Phone: 1 - 432 - 699 - 6890 "If you cannot see graphics in this email, click here to view it as a web page." [28]http://www.techautocareers.com/news_release.htm To get this in a different format (Text, AOL or HTML), or to change your e-mail address, please contact us to change your delivery preferences. For questions concerning delivery of this letter, please contact our Customer Service Department at: [29]Customer_care@techautocareers.com US: (432) 699-6890 "To make sure you continue to receive email from us -- including order confirmation and special offers please add [30]iceman_79701@att.net to your address book or safe list." To opt out of all future mailings send an email with email address to [31]customer_care@techautocareers.com Please allow up to 10 days to be removed from our list. [32]website traffic statistics References 1. http://www.techautocareers.com/news_release.htm 2. mailto:customer_care@techautocareers.com 3. mailto:gayle_trainer@techautocareers.com 4. mailto:customer_care@techautocareers.com 5. mailto:customer_care@techautocareers.com 6. http://www.techautocareers.com/ 7. http://www.techautocareers.com/ 8. http://360.yahoo.com/iceman_79701 9. http://www.techautocareers.com/SalesTrainingBlog.htm 10. http://360.yahoo.com/iceman_79701 11. http://www.techautocareers.com/SalesTrainingBlog.htm 12. http://finance.groups.yahoo.com/group/TechAutoCareers/ 13. http://360.yahoo.com/iceman_79701 14. http://www.techautocareers.com/SalesTrainingBlog.htm 15. http://www.techautocareers.com/Code_of_Ethics.htm 16. http://www.techautocareers.com/SalesTrainingBlog.htm 17. http://www.techautocareers.com/SalesTrainingBlog.htm 18. mailto:gayle_trainer@techautocareers.com 19. http://www.techautocareers.com/ 20. mailto:Editor-in-Chief@techautocareers.com 21. http://www.techautocareers.com/TAC_ordering.htm 22. javascript:e_friend() 23. mailto:customer_care@techautocareers.com 24. http://www.techautocareers.com/terms.htm 25. http://www.techautocareers.com/privacy.htm 26. mailto:gayle_trainer@techautocareers.com 27. http://www.techautocareers.com/ 28. http://www.techautocareers.com/news_release.htm 29. mailto:Customer_care@techautocareers.com 30. mailto:iceman_79701@att.net 31. mailto:customer_care@techautocareers.com 32. http://www.statcounter.com/ From scottl at samsco.org Wed Sep 3 23:36:31 2008 From: scottl at samsco.org (Scott Long) Date: Wed Sep 3 23:36:40 2008 Subject: FreeBSD 7.1 Content In-Reply-To: References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <48BEEB55.4050406@madpilot.net> Message-ID: <48BF1F70.4020509@samsco.org> Dan Allen wrote: > > On 3 Sep 2008, at 1:53 PM, Guido Falsi wrote: > >> If you just want na instant workstation, why you just don't try >> Freesbie or something like that? > > Because I want something from the source -- from the main team -- and > not something downstream. > What's wrong with "downstream"? Have the PCBSD or FreesBIE guys somehow altered things in an untrustworthy or unprofessional way? How are these releases any different than Ubuntu, or Fedora, or SuSE, or _every_single_linux_release_in_existance? Surely you don't get your linux kernel from kernel.org and then go assemble the rest of the OS from the source -- from the main team -- do you? Having derivative releases like FreeSBIE and PCBSD and others is an excellent way to make the release process scalable and able to meet the wants and needs to different users, yourself included. In fact, I think it's an utter waste of time for the FreeBSD release team to worry about packages on disc1 and whatnot. That needs to be done by teams who can focus on doing that task and doing it well. The FreeBSD releases need to become bare-bones references for others to build on an repackage and grow and improve. That's already started, but the efforts of those teams needs to be highlighted and given more, dare I say it, respect. They are the future that will bring FreeBSD to a wider audience. They need to be treated as first-class developers and members of the FreeBSD family; the "official" freebsd.org releases need to relegated to being just bare-bones bits that are there for others to bring to the masses. Go give these releases a try. They do an excellent job of packaging and installing exactly the stuff that you've mentioned that you want. Scott From brian at brianwhalen.net Wed Sep 3 23:55:09 2008 From: brian at brianwhalen.net (Brian) Date: Wed Sep 3 23:55:15 2008 Subject: FreeBSD 7.1 Content In-Reply-To: References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> Message-ID: <48BF23D3.2070509@brianwhalen.net> I always do the minimal install over the net. I got X working in 7-stable by doing the minimal install, then the following. pkg_add -r xorg pkg_add -r portupgrade portupgrade -NRP kde pkg_add -r tightvnc. I then edited the vnc config file in my homedir, it was really pretty easy on a dual core AM2 system using the AMD64 version. Now, on my P3 Celeron, this was a LOT slower. Brian From stas at FreeBSD.org Thu Sep 4 00:08:56 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Thu Sep 4 00:09:31 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <0497DBEF-6DC8-4DDD-9ED4-EAD9188D660C@airwired.net> References: <0497DBEF-6DC8-4DDD-9ED4-EAD9188D660C@airwired.net> Message-ID: <20080904034010.ff1e541e.stas@FreeBSD.org> On Wed, 3 Sep 2008 17:01:31 -0600 Dan Allen mentioned: > Phillip Salzman wrote: > > An easy answer would be to put the web-browser and such the first > > disk, but > > I don't think it would solve anything. If it kept with those, > > FreeBSD would > > find itself just moving towards the same work being done at PC-BSD, > > wouldn't > > it? > > When I see almost 200 MB free on disc1 of 7.0, and I remember the > handy apps & pkgs which used to be on past releases of FreeBSD, I do > not see it as moving towards PC-BSD as much as I see it as going back > to what FreeBSD used to have just a few releases ago. > In truth, for workstations and laptops at least, most of us do want a > web browser. Not having a decent web browser out of the box in 2008 > after 15 years of web browser development gives BSD a really archaic > look and feel. We all know that BSD is the best, most solid OS out > there - but occasionally we need to do a bit of marketing, we need to > show our stuff to let others see that "we get it". > Dan > I don't think the the problem really is in including the web browser, or X11 or not. All of us have different preferences on which soft we want to have on the first CD. That is I won't probably want a web browser when installing the server, but php, ruby and nginx instead. I think, that the current set of packages for the first CD is reasonable enough. The real problem is that our installation program isn't flexible enough and, truly speaking, obsolete. There're several programs of preparing the new generation installation system for FreeBSD, and after it's finished we'll probably able to prepare target-oriented CD sets, e.g. one for server installs, one for workstations, etc. It should be also good enough to allow you easily install any software you want whatever way you prefer. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080904/9176990d/attachment.pgp From stas at FreeBSD.org Thu Sep 4 00:08:57 2008 From: stas at FreeBSD.org (Stanislav Sedov) Date: Thu Sep 4 00:09:32 2008 Subject: Is it safe to delete /bin/[ && /usr/bin/false? In-Reply-To: <20080902122551.jfly404kcg00o40w@webmail.1command.com> References: <20080902104943.71ub86qsussgoo80@webmail.1command.com> <20080902190919.GE86609@server.vk2pj.dyndns.org> <20080902122551.jfly404kcg00o40w@webmail.1command.com> Message-ID: <20080904034519.96acd326.stas@FreeBSD.org> On Tue, 02 Sep 2008 12:25:51 -0700 chris#@1command.com mentioned: > > Good. Perhaps you (or anyone) can suggest how I might debug /when/where/ > these eval are called. I could use /usr/bin/script, but not sure how to > (e)grep the culprit(s). > Try to find the exact script which causes this (it'd be pretty easy if you could find a port with this error reproducible). Then you will be able to track the problem down by inserting a couple of echos/exits in the offending script and observing the result. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080904/20d2bde4/attachment.pgp From danallen46 at airwired.net Thu Sep 4 00:18:57 2008 From: danallen46 at airwired.net (Dan Allen) Date: Thu Sep 4 00:19:04 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <48BF1F70.4020509@samsco.org> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <48BEEB55.4050406@madpilot.net> <48BF1F70.4020509@samsco.org> Message-ID: On 3 Sep 2008, at 5:36 PM, Scott Long wrote: > What's wrong with "downstream"? I can crash most Linux distributions in an hour. Your examples are just why I like FreeBSD and why I do not like or normally use Linux. I only grabbed Ubuntu recently because there is ZERO net access from FreeBSD on my new Dell laptop. Linux to me is too random. FreeBSD has always appealed to me because it has a higher quality bar, more structure to it (like /usr/src/ and its sweet buildworld), and it does not include every possible gadget in it. I know that my proposing the addition of Firefox to disc1 may be seen as "every possible gadget" but having a web browser is pretty important these days. > Having derivative releases like FreeSBIE and PCBSD and others is an > excellent way to make the release process scalable and able to meet > the > wants and needs to different users, yourself included. In fact, I > think > it's an utter waste of time for the FreeBSD release team to worry > about > packages on disc1 and whatnot. That needs to be done by teams who can > focus on doing that task and doing it well. The FreeBSD releases need > to become bare-bones references for others to build on an repackage > and > grow and improve. That's already started, but the efforts of those > teams needs to be highlighted and given more, dare I say it, respect. > They are the future that will bring FreeBSD to a wider audience. They > need to be treated as first-class developers and members of the > FreeBSD > family; the "official" freebsd.org releases need to relegated to being > just bare-bones bits that are there for others to bring to the masses. You have good arguments here. You state -- very correctly -- that derivative release teams need to be "treated as first-class developers and members of the FreeBSD family". But are they treated so? Can larger audiences of developers be entertained while maintaining FreeBSD's stability? FreeBSD has as one of its great strengths a small set of developers and a release process that seems to deliver a more reliable product than Linux, at least in my experience. The fewer people that mess with the bits, the more stability delivered. Obviously the other side of the coin is that if not enough people mess with the bits then not enough features and hardware support will exist and the product will be irrelevant. Finding the sweet spot is hard. If derivative release teams are modeled after FreeBSD core -- good checkin structure, a few solid contributors rather than teaming hordes of inexperienced programmers -- then perhaps that is the way to go. If they do not have the structure, process, and experience, then it should be done by the mainline team. For me, as long as ANY packages are shipped on disc1, then I think they should be the right ones, and my hunch is that there should be just a few packages and their dependencies: rsync, perl and firefox. Firefox of course will drag in a bunch of stuff (X.org,atk,gtk...). (Actually rsync should become part of the main distro. It is so incredibly useful, but that is just one man's opinion.) This is a good dialog to have. I do not know if this is the right list for it, and I certainly do not want to mess up 7.1. Perhaps none of this can be ironed out in time for 7.1 and it will have to wait for 7.2. That is fine. Whose job is it to decide on the packages for a release? I have spent a non-zero amount of time looking for specifications or design plans for releases and have been unable to find them. Thanks to everyone today for your comments! Dan From bsd-unix at embarqmail.com Thu Sep 4 00:19:26 2008 From: bsd-unix at embarqmail.com (Randy Pratt) Date: Thu Sep 4 00:19:34 2008 Subject: FreeBSD 7.1 Content In-Reply-To: References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <48BEEB55.4050406@madpilot.net> Message-ID: <20080903195922.eee0b5ad.bsd-unix@embarqmail.com> On Wed, 3 Sep 2008 16:43:45 -0600 Dan Allen wrote: > > On 3 Sep 2008, at 3:11 PM, Steven Hartland wrote: > > > ----- Original Message ----- From: "Dan Allen" > > > > > >> I too spend the time. I am thinking that for other people to want > >> to use FreeBSD they want something other than a command prompt. > >> They at least want a web browser out of the box. > > > > For some, but for others like ourselves here we really don't want all > > that bloat. One of the reasons we really like it is its perfect for > > server installs, no crap installed that you don't want :) > > Agreed, but if you go back to earlier versions of FreeBSD they gave > you an install option for just binaries, or binaries + sources, or > binaries + sources + X Windows. > > I am proposing something similar once again, but this time if would be > enough of X, a small window manager, and Firefox so a basic windowing > environment was able to be installed, from the CD, with a single > choice. I doubt many developers are really browsing the web all day > with lynx. If I understand correctly, you've described some problems with wireless and ethernet hardware on FreeBSD 7. Others have mentioned that it seems to work on FreeBSD 6. It might be worth setting up two partitions with one for 6 and the other for 7 so that you can work with the developers to resolve the problems on 7. As a desktop user, you may not even notice the differences between 6 and 7. I think this is probably worth the time to pursue since developers usually can't easily fix problems for hardware they don't have. The content of the installation disks has been discussed in the past but I don't remember anything conclusive coming out of it. I personally quit using packages around 3.x. It was too easy to introduce problems mixing packages and compiling ports so everything is now built from source and updated daily. The ports/packages are actually not part of FreeBSD but are third-party applications. I've often thought that the packages on the installation disks should really be split to a separate project which produces package disks. This would lessen the burden on the Release Engineers and perhaps the cycle time between releases. It should also be noted that the useful life of a package is limited and outdated very quickly. For my own taste, it would be a bit annoying to have any port/package installed by default. Randy -- From danallen46 at airwired.net Thu Sep 4 00:28:46 2008 From: danallen46 at airwired.net (Dan Allen) Date: Thu Sep 4 00:28:53 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <48BF23D3.2070509@brianwhalen.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <48BF23D3.2070509@brianwhalen.net> Message-ID: On 3 Sep 2008, at 5:54 PM, Brian wrote: > I always do the minimal install over the net. I got X working in 7- > stable by doing the minimal install, then the following. > > pkg_add -r xorg > pkg_add -r portupgrade > portupgrade -NRP kde > pkg_add -r tightvnc. On 3 Sep 2008, at 5:59 PM, Randy Pratt wrote: > The ports/packages are actually not part of FreeBSD but are third- > party > applications. I've often thought that the packages on the > installation > disks should really be split to a separate project which produces > package disks. This would lessen the burden on the Release Engineers > and perhaps the cycle time between releases. It should also be > noted that the useful life of a package is limited and outdated very > quickly. Hey, these great comments bring up a different solution, which may be the way to go. It is simple: have a few of the common apps that are net-centric (like firefox) be simply calls to pkg_add -r in the installer. No ports databases, no packages on the discs. A few packages may be useful (like perl) to someone without net access, but many need the net to be useful. I often forget about pkg_add -r because I build everything from source myself, but just a prompted dialog offering a few of the most common and popular apps like: * kde or gnome * firefox or xxx_browser * vnc * openoffice via pkg_add -r might be a very simple solution (no disk impact to speak of) and perhaps could even be determined by a look at which pkgs are installed the most from server logs (not dynamically, but just as a way of offering common pkgs). Dan From jrhett at netconsonance.com Thu Sep 4 00:36:34 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Sep 4 00:36:41 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> Message-ID: <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> Where can one find the expected EoL for these releases? I've poked around the website and can't find any notes mentioning this, although several people have been making posts suggesting that people should review the EoL schedule when planning their upgrades. On Aug 22, 2008, at 5:51 AM, Ken Smith wrote: > We're about to start the release cycle for FreeBSD-7.1 and > FreeBSD-6.4. > The proposed schedule for the "major events" of the cycle is: > > Freeze August 29 > BETA September 1 > Branch September 6 > 6.4-RC1 September 8 > 7.1-RC1 September 15 > 6.4-RC2 September 22 > 7.1-RC2 September 29 > 6.4-REL October 6 > 7.1-REL October 13 > > I haven't posted the schedule on the Web site yet, I'll try to get > that > done over the weekend. > > On Monday I'll switch RELENG_7 and RELENG_6 over to say they are > 7.1-PRERELEASE and 6.4-PRERELEASE respectively as a heads-up that > there > will likely be higher-than-normal developer activity MFC-ing stuff > before code freeze starts. Odds get higher that if you do updates > using > RELENG_7/RELENG_6 branches during this period you *might* wind up > with a > tree that isn't quite right because you happened to catch it part way > through a developer doing a multi-step commit. > > We had been procrastinating on saying definitively whether we thought > 6.4-REL would be the last of the RELENG_6 releases to see how well > things went with 7.X (if 7.0-REL was a total disaster we'd have > considered doing a 6.5-REL). It seems that 7.0-REL went well and > RELENG_7 in general seems to be in good shape so we now expect 6.4-REL > to be the last of the RELENG_6 releases. > > Thanks. > > -- > Ken Smith > - From there to here, from here to | kensmith@cse.buffalo.edu > there, funny things are everywhere. | > - Theodore Geisel | > -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From aragon at phat.za.net Thu Sep 4 01:02:41 2008 From: aragon at phat.za.net (Aragon Gouveia) Date: Thu Sep 4 01:02:49 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <55EA18D2-E017-4426-9377-1FC113ED83D2@airwired.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <20080903195825.GC28299@atarininja.org> <55EA18D2-E017-4426-9377-1FC113ED83D2@airwired.net> Message-ID: <20080904010239.GA45270@phat.za.net> | By Dan Allen | [ 2008-09-03 23:06 +0200 ] > FreeBSD from the machine and installed Ubuntu 8.04. I therefore > cannot run "pciconf -l" at this moment in time, but I may get back > around to it. lspci ? Regards, Aragon From kurt.buff at gmail.com Thu Sep 4 02:56:20 2008 From: kurt.buff at gmail.com (Kurt Buff) Date: Thu Sep 4 02:56:27 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> Message-ID: Google for freesbie, or perhaps PC-BSD On Wed, Sep 3, 2008 at 9:36 AM, Dan Allen wrote: > BACKGROUND: > > A few years ago one could get a FreeBSD CD and install X and get a decent > basic system from one CD. > > One can still do this with Ubuntu today as well. > > Why can't we have a small window manager like icewm along with Firefox 3.0+ > be among the packages on the first FreeBSD CD so a basic working system with > a web browser can be a default install? Is it that X.org is now too big? > > I have been a FreeBSD user/builder for more than a decade because of > /usr/src/make - complete sources and a beautiful build system, but I must > admit that Ubuntu has done a great job of modern hardware detection and > providing a nice useable system out of the box. I wish we could join both > worlds in a future BSD release. (I crashed Ubuntu 8.04 in the first day so > I still prefer BSD to Linux.) > > Also, and I am sure I am not the only one with one of these, my new $500 > Dell Inspiron 1525 is not supported well by BSD RELENG_7: the Intel 4965 > wireless and the Marvell 88E80xx Ethernet are both NOT supported so I have a > great new laptop which cannot connect to the outside world with BSD. :-( > Ubuntu supports these and lots more. > > SUMMARY: > > I would like to see FreeBSD 7.1 add to its disc1: > > 1) X.org > 2) icewm > 3) firefox-3.0 > 4) support for Intel 4965 wireless drivers > 5) support for Marvell 88E8040 ethernet driver > > Dan Allen > > _______________________________________________ > 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 nathan at datanode.com Thu Sep 4 04:45:28 2008 From: nathan at datanode.com (Nathan Way) Date: Thu Sep 4 04:45:35 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> Message-ID: > > Where can one find the expected EoL for these releases? I've poked > around the website and can't find any notes mentioning this, although > several people have been making posts suggesting that people should > review the EoL schedule when planning their upgrades. http://www.freebsd.org/security/security.html#supported-branches To quote from the above web site: Branch Release Type Release Date Estimated EoL RELENG_6 n/a n/a n/a January 31, 2010 RELENG_6_3 6.3-RELEASE Extended January 18, 2008 January 31, 2010 RELENG_7 n/a n/a n/a last release + 2 years RELENG_7_0 7.0-RELEASE Normal February 27, 2008 February 28, 2009 From torfinn.ingolfsen at broadpark.no Thu Sep 4 05:13:04 2008 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Thu Sep 4 05:13:11 2008 Subject: FreeBSD 7.1 Content In-Reply-To: References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <48BEEB55.4050406@madpilot.net> Message-ID: <20080904071257.b42ab922.torfinn.ingolfsen@broadpark.no> On Wed, 03 Sep 2008 15:01:48 -0600 Dan Allen wrote: > The Ubuntu install is very compelling. I am just wishing that > FreeBSD was AS compelling in its first install experience. At > present it is far, far behind. Well, do you really want all those people who can't even read to be FreeBSD users? (Not aiming at Ubuntu users here) Personally, I think that the FreeBSD learning curve is a good thing, it means that FreeBSD users wil know more about FreeBSD when they get it running. -- Regards, Torfinn Ingolfsen From koitsu at FreeBSD.org Thu Sep 4 06:20:55 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 4 06:21:03 2008 Subject: FreeBSD 7.1 Content In-Reply-To: References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <48BEEB55.4050406@madpilot.net> Message-ID: <20080904062053.GA5953@icarus.home.lan> On Wed, Sep 03, 2008 at 03:01:48PM -0600, Dan Allen wrote: > > On 3 Sep 2008, at 1:53 PM, Guido Falsi wrote: > >> If you just want na instant workstation, why you just don't try >> Freesbie or something like that? > > Because I want something from the source -- from the main team -- and > not something downstream. > >> If I install FreeBSD on a PC I expect this installation to live there >> for some years. I can spend some hours/days installing and configuring >> what I really need. At least this is the way I see it. Maybe I'm >> misunderstanding you. > > I too spend the time. I am thinking that for other people to want to > use FreeBSD they want something other than a command prompt. They at > least want a web browser out of the box. I haven't finished reading the thread yet, but your assumption is ignorant. Why do you think FreeBSD is intended solely for desktop usage? It's not. I, for one, **only want a command prompt** out of the box. I **do not** want Xorg or any X-related garbage on my servers. > The Ubuntu install is very compelling. I am just wishing that FreeBSD > was AS compelling in its first install experience. At present it is > far, far behind. > > That does not stop ME from preferring FreeBSD, but it stops many other > people. I am in no way an "advocate" of operating systems, so despite me having freebsd.org mail address, do not think for a minute that what I'm about to tell you is biased in favour of FreeBSD. Use whatever operating system works best for you. If that's Linux, awesome! If that's FreeBSD, awesome! If that's Windows, awesome! Different people have different needs -- case in point, you want a simple and easy-to-install out-of-the-box desktop version of FreeBSD, while I want a no-cruft-like-X install server version of FreeBSD. FreeBSD caters to both. There's nothing stopping you from downloading disc1 and during the install choosing to install Firefox and X, which will accomplish what you need. You'll still be booted into a command prompt, but that's how UNIX is; FreeBSD is not Kubuntu. I think what you might be looking for is, believe it or not, PC-BSD. I believe you can install PC-BSD and get a working X desktop with a browser and all that jazz right out of the box. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From mad at madpilot.net Thu Sep 4 06:51:06 2008 From: mad at madpilot.net (Guido Falsi) Date: Thu Sep 4 06:51:13 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <20080904062053.GA5953@icarus.home.lan> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <48BEEB55.4050406@madpilot.net> <20080904062053.GA5953@icarus.home.lan> Message-ID: <48BF8554.6060905@madpilot.net> Jeremy Chadwick wrote: > On Wed, Sep 03, 2008 at 03:01:48PM -0600, Dan Allen wrote: >> On 3 Sep 2008, at 1:53 PM, Guido Falsi wrote: >> >>> If you just want na instant workstation, why you just don't try >>> Freesbie or something like that? >> Because I want something from the source -- from the main team -- and >> not something downstream. >> >>> If I install FreeBSD on a PC I expect this installation to live there >>> for some years. I can spend some hours/days installing and configuring >>> what I really need. At least this is the way I see it. Maybe I'm >>> misunderstanding you. >> I too spend the time. I am thinking that for other people to want to >> use FreeBSD they want something other than a command prompt. They at >> least want a web browser out of the box. > > I haven't finished reading the thread yet, but your assumption is > ignorant. Why do you think FreeBSD is intended solely for desktop > usage? It's not. > > I, for one, **only want a command prompt** out of the box. I **do not** > want Xorg or any X-related garbage on my servers. > I fully agree with this last statement. I choose freebsd for many reasons, and this is one of those, I tried a few linux distributions, and even slackware installs too much garbage if you're not looking closely at it. And n the way to providing a useful desktop system out of the box, I think no one can choose arbitrarily what to include and what not. Most people would find WM+FF[23] too little, some other would want some minimal gnome/kde, some others full blown gnome/kde (or other des for example) who's bound to choose? FreeBSD has always made a choice to be just an os, and a server oriented one. There are downstream distributions bundling full blown systems, and, as stated by others, the devel team has no time to spare, I think it should concentrate on that, and leave the desktop work to others. -- Guido Falsi From peterjeremy at optushome.com.au Thu Sep 4 08:54:28 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Sep 4 08:54:35 2008 Subject: FreeBSD 7.1 Content In-Reply-To: References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> Message-ID: <20080904085415.GG15376@server.vk2pj.dyndns.org> On 2008-Sep-03 15:53:30 -0600, Dan Allen wrote: >I see. I was thinking of FreeBSD 7.0 whose disc1 is 509 MB in size, >leaving almost 200 MB free for a standard 700 MB CD. I missed that the disc layous have been rearranged and disc1 is now somewhat emptier than when I last looked. However, you've missed a few points as well: 1) Currently, the contents of each disk is the same on each architecture. Changing this is possible but would be very confusing to users. sparc64 appears to be the largest and disk1 is over 600MB. 2) Traditionally, the ISO images have been sized to fit on 650MB CD-RWs. Maybe this should be revisited but during a release freeze is not the right time for that. 3) It's desirable to leave some slack so that a slight size increase in the final builds doesn't necessitate re-working the CD layouts. >Ubuntu 8.04 has room for [the kitchen sink] For most architectures, disc1 includes a live filesystem. This is very useful for recovery purposes. Since FreeBSD does not include cloop or similar compressed FS support, this takes a fair amount of space. And you've already pointed out that disc1 includes sources (which you want to keep). >Here is a quick list (not exhaustive or definitive) of the libraries >that Firefox 3.0 requires, and their sizes in bytes: Note that you need to include the space needed by the packages for all the FF3 dependencies, not just the shared libraries. >These total 27696575 bytes or 26.4 MB. Including the full list of runtime dependencies, FF3 needs 120 packages, totalling 89MB (already bzip'd) on i386. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080904/508be420/attachment.pgp From ohartman at zedat.fu-berlin.de Thu Sep 4 09:02:50 2008 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Thu Sep 4 09:03:02 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: <20080903193703.GA72896@elch.haidundneu23.net> References: <48BD0C5A.4060706@zedat.fu-berlin.de> <20080902151456.GA1593@elch.haidundneu23.net> <48BE28F7.7030500@zedat.fu-berlin.de> <20080903063753.GA2120@reindeer.haidundneu23.net> <48BE388C.7050706@zedat.fu-berlin.de> <20080903193703.GA72896@elch.haidundneu23.net> Message-ID: <48BFA3B3.3050506@zedat.fu-berlin.de> Christoph Moench-Tegeder wrote: > ## O. Hartmann (ohartman@zedat.fu-berlin.de): > >> My box at home has an older NV6800GT and I do not have this special >> issue, but instead I do have another well known issue of box-freezing. >> This also happens with 'nv'. > > Whoa. Guess I'm lucky, as my nvidia chis is working, albeit quite > slowly. My radeonhd-based card at home is way faster, but exhibits > the same black-image-issue with firefox. > > Regards, > Christoph > The situation is harsh. More than 5 boxes running all the same card type and FreeBSD are simply unusuable since this upgrade and I'm typing blind due to black bars covering typed in sentences. This is in most clients which do font rendering, I guess, but I really don't know. That is clearly a mess and I do not understand why this sh..-driver has gone into ports while the issues with some chips are well known :-( From lists at peter.de.com Thu Sep 4 09:59:05 2008 From: lists at peter.de.com (Oliver Peter) Date: Thu Sep 4 09:59:13 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <32833CD6-DE00-4FDB-A01A-B86B0A25B3E4@airwired.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <32833CD6-DE00-4FDB-A01A-B86B0A25B3E4@airwired.net> Message-ID: <20080904094218.GB32453@nemesis.frida.mouhaha.de> On Wed, Sep 03, 2008 at 02:58:45PM -0600, Dan Allen wrote: > > On 3 Sep 2008, at 1:14 PM, Peter Jeremy wrote: > > > Your patches to add support for the i4965 and your Marvell 88E80xx > > must have been stripped by the mailing list software. Can you please > > re-send them. > > I have not written patches, thus I did not send any patches. | `--> http://en.wikipedia.org/wiki/Sarcasm Btw. my philosophy is if you would like to use your favourite open source operating system - which I guess is FreeBSD - on your new hardware, you should spend additional 15 minutes when you make the decision what hardware you are going to buy and check the specs with the "Hardware Notes" at http://www.freebsd.org/where.html. Complaining afterwards is easy but no one forces you to buy unsupported hardware. -- Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174 "If it feels good, you're doing something wrong." -- Coach McTavish From vince at unsane.co.uk Thu Sep 4 10:16:17 2008 From: vince at unsane.co.uk (Vincent Hoffman) Date: Thu Sep 4 10:16:24 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <20080904085415.GG15376@server.vk2pj.dyndns.org> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <20080904085415.GG15376@server.vk2pj.dyndns.org> Message-ID: <48BFB564.2000802@unsane.co.uk> Peter Jeremy wrote: > On 2008-Sep-03 15:53:30 -0600, Dan Allen wrote: > >> I see. I was thinking of FreeBSD 7.0 whose disc1 is 509 MB in size, >> leaving almost 200 MB free for a standard 700 MB CD. >> > > I missed that the disc layous have been rearranged and disc1 is now > somewhat emptier than when I last looked. However, you've missed a > few points as well: > 1) Currently, the contents of each disk is the same on each architecture. > Changing this is possible but would be very confusing to users. > sparc64 appears to be the largest and disk1 is over 600MB. > 2) Traditionally, the ISO images have been sized to fit on 650MB CD-RWs. > Maybe this should be revisited but during a release freeze is not > the right time for that. > 3) It's desirable to leave some slack so that a slight size increase in > the final builds doesn't necessitate re-working the CD layouts. > > >> Ubuntu 8.04 has room for [the kitchen sink] >> > > For most architectures, disc1 includes a live filesystem. This is > very useful for recovery purposes. Since FreeBSD does not include > cloop or similar compressed FS support, this takes a fair amount of > space. And you've already pointed out that disc1 includes sources > (which you want to keep). > > Actually FreeBSD does support a compressed (read only) filesystem, geom_uzip(4) This is used by freesbie if I remember rightly. However it does mean you cannot just mount and browse the install cd with the generic kernel, and I'd guess it bumps up the base system requirements. Vnce >> Here is a quick list (not exhaustive or definitive) of the libraries >> that Firefox 3.0 requires, and their sizes in bytes: >> > > Note that you need to include the space needed by the packages for all > the FF3 dependencies, not just the shared libraries. > > >> These total 27696575 bytes or 26.4 MB. >> > > Including the full list of runtime dependencies, FF3 needs 120 packages, > totalling 89MB (already bzip'd) on i386. > > From chih.liang at ipeen.com.tw Thu Sep 4 11:34:09 2008 From: chih.liang at ipeen.com.tw (Chih Liang) Date: Thu Sep 4 11:34:18 2008 Subject: boot failed after make installkernel from 6.3-RELEASE to 7.0-RELEASE Message-ID: <48BFC40C.3050309@ipeen.com.tw> Dear all, I've tried to upgrade my FreeBSD server from 6.3-RELEASE to 7.0-RELEASE, but it is failed to boot after make kernel KERNCONF=GENERIC. I didn't modify any file at /usr/src/sys/i386/conf, it was all default. After done make kernel and reboot, system stop at: Timecounters tick every 1.000 msec ad0: 38166MB at ata0-master UDMA100 I can't boot in single mode, but I can boot in safe mode, and it showed: Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input I type "?" for list, but it only show acd0 and fdc0, "ufs:ad0s1a" or "ufs:/dev/ad0s1a" are not working I can boot with /boot/kernel.old now (6.3-RELEASE), I rebuilt kernel again and again, but still not work. I check the difference between old GENERIC on 6.3-RELEASE and new GENERIC on 7.0-RELEASE, it has not difference besides new add in 7.0-RELEASE. Is any one can help me? I don't want to reinstall...because I don't have install cd... And sorry for my poor English, thank you for reading! Regards, Chih Liang From bms at incunabulum.net Thu Sep 4 11:40:55 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu Sep 4 11:41:02 2008 Subject: ACPI sleep broken on ASUS Vintage AH-1 Message-ID: <48BFC577.7000800@incunabulum.net> Hi, Just noticed that when I try to ACPI-sleep an ASUS Vintage AH-1 based desktop system, that I get the following message: acpiconf: request sleep type (3) failed: Operation not supported Supported sleep states in sysctl: hw.acpi.supported_sleep_state: S1 S3 S4 S5 This is an amd64 uniprocessor system running 7.0-RELEASE. BIOS version is 0303 (last release), it is an AMI BIOS. I've seen S3 sleep work fine in Windows XP on this box. I would really like to be able to sleep this box rather than up/down it, as it's in my home, less noise, less power consumption etc. Any further info needed let me know. thanks! BMS From jeff.dowsley at mac.com Thu Sep 4 11:43:13 2008 From: jeff.dowsley at mac.com (Jeff Dowsley) Date: Thu Sep 4 11:43:20 2008 Subject: boot failed after make installkernel from 6.3-RELEASE to 7.0-RELEASE In-Reply-To: <48BFC40C.3050309@ipeen.com.tw> References: <48BFC40C.3050309@ipeen.com.tw> Message-ID: <48BFC9C2.8020208@mac.com> Chih Liang wrote: > Dear all, > > I've tried to upgrade my FreeBSD server from 6.3-RELEASE to > 7.0-RELEASE, but it is failed to boot after make kernel KERNCONF=GENERIC. > I didn't modify any file at /usr/src/sys/i386/conf, it was all default. > After done make kernel and reboot, system stop at: > > Timecounters tick every 1.000 msec > ad0: 38166MB at ata0-master UDMA100 Try selecting boot option 2, ACPI disabled. J > > > I can't boot in single mode, but I can boot in safe mode, and it showed: > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:da0s1a > ? List valid disk boot devices > Abort manual input > > I type "?" for list, but it only show acd0 and fdc0, "ufs:ad0s1a" or > "ufs:/dev/ad0s1a" are not working > > I can boot with /boot/kernel.old now (6.3-RELEASE), I rebuilt kernel > again and again, but still not work. > I check the difference between old GENERIC on 6.3-RELEASE and new > GENERIC on 7.0-RELEASE, it has not difference besides new add in > 7.0-RELEASE. > > Is any one can help me? I don't want to reinstall...because I don't > have install cd... > > And sorry for my poor English, thank you for reading! > > Regards, > Chih Liang > _______________________________________________ > 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 admin at kkip.pl Thu Sep 4 11:50:34 2008 From: admin at kkip.pl (Bartosz Stec) Date: Thu Sep 4 11:50:41 2008 Subject: boot failed after make installkernel from 6.3-RELEASE to 7.0-RELEASE In-Reply-To: <48BFC40C.3050309@ipeen.com.tw> References: <48BFC40C.3050309@ipeen.com.tw> Message-ID: <48BFCB88.9050505@kkip.pl> Chih Liang pisze: > Dear all, > > I've tried to upgrade my FreeBSD server from 6.3-RELEASE to > 7.0-RELEASE, but it is failed to boot after make kernel KERNCONF=GENERIC. > I didn't modify any file at /usr/src/sys/i386/conf, it was all default. > After done make kernel and reboot, system stop at: > > Timecounters tick every 1.000 msec > ad0: 38166MB at ata0-master UDMA100 > > I can't boot in single mode, but I can boot in safe mode, and it showed: > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:da0s1a > ? List valid disk boot devices > Abort manual input > > I type "?" for list, but it only show acd0 and fdc0, "ufs:ad0s1a" or > "ufs:/dev/ad0s1a" are not working > > I can boot with /boot/kernel.old now (6.3-RELEASE), I rebuilt kernel > again and again, but still not work. > I check the difference between old GENERIC on 6.3-RELEASE and new > GENERIC on 7.0-RELEASE, it has not difference besides new add in > 7.0-RELEASE. > > Is any one can help me? I don't want to reinstall...because I don't > have install cd... > > And sorry for my poor English, thank you for reading! > > Regards, > Chih Liang > _______________________________________________ > 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" Did you make buildworld before buildkernel? If not, boot kernel.old ane follow these rules: 1. csup 7-stable sources (just to be sure) 2. rm -fR /usr/obj (just to be sure again) 3. make buildworld && make buildkernel KERNCONF=GENERIC 4. make installkernel 5. reboot in single user mode 6. mergemaster -p 7. make installworld 8. mergemaster 9. make delete-old 10. make delete-old-libs Good luck! -- Bartosz Stec - specjalista ds. IT AUXILIA Sp??ka z o.o. ul. Wa?brzyska 43/2 52-314 Wroc?aw tel. (71) 79 99 760 w. 69 GSM: 662171775 E-Mail: admin@kkip.pl -- E-Mail Disclaimer Niniejsza wiadomosc oraz wszystkie zalaczone do niej pliki przeznaczone sa do wylacznego uzytku adresata i moga zawierac chronione lub poufne informacje. Przegladanie, wykorzystywanie, ujawnianie lub dystrybuowanie przez osoby do tego nieupowaznione jest zabronione. Jesli nie jest Pani/Pan wymienionym adresatem niniejszej wiadomosci, prosimy o niezwloczny kontakt z nadawca i usuniecie oryginalnej wiadomosci wraz ze zniszczeniem wszystkich jej kopii. Der Inhalt dieser E-Mail ist vertraulich und ausschlie?lich f?r den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, da? jede Form der Kenntnisnahme, Ver?ffentlichung, Vervielf?ltigung oder Weitergabe des Inhalts dieser E-Mail unzul?ssig ist. Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen. This e-mail message including any attachments is for the sole use of the intended recipient(s) and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply e-mail and delete the original message and destroy all copies thereof. From 000.fbsd at quip.cz Thu Sep 4 12:24:18 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Thu Sep 4 12:24:25 2008 Subject: external HDD disconnects - umass1: BBB reset failed, IOERROR (FreeBSD 6.3) In-Reply-To: <48BE45F1.4020409@quip.cz> References: <48BE45F1.4020409@quip.cz> Message-ID: <48BFD38A.7090908@quip.cz> I am sorry for the noise, it was caused by failure of enclosures power supply. Miroslav Lachman wrote: > Hi, > > I tried to use 1TB HDD (SAMSUNG HD103UJ) in external enclosure connected > by USB 2.0 to my old machine with FreeBSD 6.3-RELEASE-p1 GENERIC i386. > > It connects OK, I can read & write to disk (shown as /dev/da1). > But my dd command test failed after 50 minutes: > > root@amanda ~/# dd if=/dev/da1 of=/dev/da1 bs=1m > dd: /dev/da1: Invalid argument > 20435+0 records in > 20435+0 records out > 21427650560 bytes transferred in 2963.876996 secs (7229602 bytes/sec) > > Usr: 0.092s Krnl: 10.689s Totl: 49:23.87s CPU: 0.3% swppd: 0 I/O: 0+0 > > relevant part of /var/log/messages > > Sep 2 20:06:15 amanda kernel: umass1: Sunplus Technology Co.,Ltd. USB > to Serial-ATA bridge, rev 2.00/1.12, addr 3 > Sep 2 20:06:15 amanda kernel: da1 at umass-sim1 bus 1 target 0 lun 0 > Sep 2 20:06:15 amanda kernel: da1: Fixed Direct > Access SCSI-2 device > Sep 2 20:06:15 amanda kernel: da1: 40.000MB/s transfers > Sep 2 20:06:15 amanda kernel: da1: 953869MB (1953525168 512 byte > sectors: 255H 63S/T 121601C) > Sep 2 20:06:46 amanda login: ROOT LOGIN (root) ON ttyv0 > Sep 2 20:07:29 amanda ntpd[845]: kernel time sync enabled 6001 > Sep 2 20:24:32 amanda ntpd[845]: kernel time sync enabled 2001 > Sep 2 20:58:06 amanda kernel: umass1: BBB reset failed, IOERROR > Sep 2 20:58:06 amanda kernel: umass1: BBB bulk-in clear stall failed, > IOERROR > Sep 2 20:58:06 amanda kernel: umass1: BBB bulk-out clear stall failed, > IOERROR > Sep 2 20:58:06 amanda kernel: umass1: BBB reset failed, IOERROR > Sep 2 20:58:06 amanda kernel: umass1: BBB bulk-in clear stall failed, > IOERROR > Sep 2 20:58:06 amanda kernel: umass1: BBB bulk-out clear stall failed, > IOERROR > Sep 2 20:58:06 amanda kernel: umass1: BBB reset failed, IOERROR > Sep 2 20:58:06 amanda kernel: umass1: at uhub2 port 1 (addr 3) > disconnected > Sep 2 20:58:06 amanda kernel: (da1:umass-sim1:1:0:0): lost device > Sep 2 20:58:06 amanda kernel: (da1:dead_sim0:0:0:0): Synchronize cache > failed, status == 0x8, scsi status == 0x0 > Sep 2 20:58:06 amanda kernel: (da1:dead_sim0:0:0:0): removing device entry > Sep 2 20:58:06 amanda kernel: umass1: detached [...] From 000.fbsd at quip.cz Thu Sep 4 12:27:47 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Thu Sep 4 12:27:54 2008 Subject: boot failed after make installkernel from 6.3-RELEASE to 7.0-RELEASE In-Reply-To: <48BFC40C.3050309@ipeen.com.tw> References: <48BFC40C.3050309@ipeen.com.tw> Message-ID: <48BFD461.6070606@quip.cz> Chih Liang wrote: > Dear all, > > I've tried to upgrade my FreeBSD server from 6.3-RELEASE to 7.0-RELEASE, > but it is failed to boot after make kernel KERNCONF=GENERIC. > I didn't modify any file at /usr/src/sys/i386/conf, it was all default. > After done make kernel and reboot, system stop at: > > Timecounters tick every 1.000 msec > ad0: 38166MB at ata0-master UDMA100 > > I can't boot in single mode, but I can boot in safe mode, and it showed: > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:da0s1a > ? List valid disk boot devices > Abort manual input > > I type "?" for list, but it only show acd0 and fdc0, "ufs:ad0s1a" or > "ufs:/dev/ad0s1a" are not working > > I can boot with /boot/kernel.old now (6.3-RELEASE), I rebuilt kernel > again and again, but still not work. > I check the difference between old GENERIC on 6.3-RELEASE and new > GENERIC on 7.0-RELEASE, it has not difference besides new add in > 7.0-RELEASE. > > Is any one can help me? I don't want to reinstall...because I don't have > install cd... > > And sorry for my poor English, thank you for reading! What is your hardware setup? (post dmesg) I have bad experience with some old PC with nForce 2 chipset. This machine is unbootable with 7.x kernel, so I am using it with 6.3. (it can't boot even from 7.x CD) Miroslav Lachman From gavin at FreeBSD.org Thu Sep 4 12:51:35 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Thu Sep 4 12:51:42 2008 Subject: ACPI sleep broken on ASUS Vintage AH-1 In-Reply-To: <48BFC577.7000800@incunabulum.net> References: <48BFC577.7000800@incunabulum.net> Message-ID: <1220532689.94705.4.camel@buffy.york.ac.uk> On Thu, 2008-09-04 at 12:24 +0100, Bruce M Simpson wrote: > Hi, > > Just noticed that when I try to ACPI-sleep an ASUS Vintage AH-1 based > desktop system, that I get the following message: > acpiconf: request sleep type (3) failed: Operation not supported > > Supported sleep states in sysctl: > hw.acpi.supported_sleep_state: S1 S3 S4 S5 > > This is an amd64 uniprocessor system running 7.0-RELEASE. BIOS version > is 0303 (last release), it is an AMI BIOS. I've seen S3 sleep work fine > in Windows XP on this box. > > I would really like to be able to sleep this box rather than up/down it, > as it's in my home, less noise, less power consumption etc. Currently, suspend/resume is unsupported on FreeBSD/amd64, as nobody has yet written the amd64 equivalent of sys/i386/acpica/acpi_wakecode.S. NetBSD has this code, I'm not sure how easy it would be to port it over or if it would be easier to write it from scratch. Gavin From doconnor at gsoft.com.au Thu Sep 4 13:07:34 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu Sep 4 13:07:42 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <48BFB564.2000802@unsane.co.uk> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080904085415.GG15376@server.vk2pj.dyndns.org> <48BFB564.2000802@unsane.co.uk> Message-ID: <200809042237.13436.doconnor@gsoft.com.au> On Thu, 4 Sep 2008, Vincent Hoffman wrote: > Actually FreeBSD does support a compressed (read only) filesystem, > geom_uzip(4) This is used by freesbie if I remember rightly. > However it does mean you cannot just mount and browse the install cd > with the generic kernel, and I'd guess it bumps up the base system > requirements. You could, because geom_uzip is a module :) That said you _would_ duplicate things because what is on the live disk is not in a form suitable for pkg_add'ing to the installed system. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080904/dbf6a405/attachment.pgp From vince at unsane.co.uk Thu Sep 4 13:13:38 2008 From: vince at unsane.co.uk (Vincent Hoffman) Date: Thu Sep 4 13:13:44 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <200809042237.13436.doconnor@gsoft.com.au> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080904085415.GG15376@server.vk2pj.dyndns.org> <48BFB564.2000802@unsane.co.uk> <200809042237.13436.doconnor@gsoft.com.au> Message-ID: <48BFDEF2.7050108@unsane.co.uk> Daniel O'Connor wrote: > On Thu, 4 Sep 2008, Vincent Hoffman wrote: > >> Actually FreeBSD does support a compressed (read only) filesystem, >> geom_uzip(4) This is used by freesbie if I remember rightly. >> However it does mean you cannot just mount and browse the install cd >> with the generic kernel, and I'd guess it bumps up the base system >> requirements. >> > > You could, because geom_uzip is a module :) > > That said you _would_ duplicate things because what is on the live disk > is not in a form suitable for pkg_add'ing to the installed system. > > Indeed, putting the already compressed package files in a compressed disk would be unlikely to save much space either. From royce at alaska.net Thu Sep 4 13:14:37 2008 From: royce at alaska.net (Royce Williams) Date: Thu Sep 4 13:14:44 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <20080904085415.GG15376@server.vk2pj.dyndns.org> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <20080904085415.GG15376@server.vk2pj.dyndns.org> Message-ID: <48BFDF48.1090203@alaska.net> Peter Jeremy wrote, on 9/4/2008 12:54 AM: > 2) Traditionally, the ISO images have been sized to fit on 650MB CD-RWs. > Maybe this should be revisited but during a release freeze is not > the right time for that. Isn't there a little more room now by default? From the 7.0 release notes: The ISO images for FreeBSD are now sized for 700MB CDROM media. For most prior versions of FreeBSD, they assumed 650MB CDROM media. [MERGED] Royce -- Royce D. Williams - http://royce.ws/ The absence of alternatives clears the mind marvelously. -H. Kissinger From wxs at FreeBSD.org Thu Sep 4 13:35:25 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Thu Sep 4 13:35:33 2008 Subject: Upcoming Releases Schedule... In-Reply-To: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> Message-ID: <20080904133604.GB1188@atarininja.org> On Wed, Sep 03, 2008 at 09:24:04PM -0700, Nathan Way wrote: > > > > Where can one find the expected EoL for these releases? I've poked > > around the website and can't find any notes mentioning this, although > > several people have been making posts suggesting that people should > > review the EoL schedule when planning their upgrades. > > http://www.freebsd.org/security/security.html#supported-branches > > To quote from the above web site: > > Branch Release Type Release Date Estimated EoL > RELENG_6 n/a n/a n/a January 31, 2010 > RELENG_6_3 6.3-RELEASE Extended January 18, 2008 January 31, 2010 > RELENG_7 n/a n/a n/a last release + 2 > years > RELENG_7_0 7.0-RELEASE Normal February 27, 2008 February 28, 2009 These are the existing releases. I believe Jo was looking for EoL for 7.1 and 6.4 once they are released. The answer to that is not clear - nor do I know if it should be clear yet. I don't know when the type of support decision is made, but I suspect it's not this early in the process. -- WXS From wxs at FreeBSD.org Thu Sep 4 13:42:26 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Thu Sep 4 13:42:33 2008 Subject: FreeBSD 7.1 Content In-Reply-To: References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <48BF23D3.2070509@brianwhalen.net> Message-ID: <20080904134305.GC1188@atarininja.org> On Wed, Sep 03, 2008 at 06:28:44PM -0600, Dan Allen wrote: > > On 3 Sep 2008, at 5:54 PM, Brian wrote: > > > I always do the minimal install over the net. I got X working in 7- > > stable by doing the minimal install, then the following. > > > > pkg_add -r xorg > > pkg_add -r portupgrade > > portupgrade -NRP kde > > pkg_add -r tightvnc. > > On 3 Sep 2008, at 5:59 PM, Randy Pratt wrote: > > > The ports/packages are actually not part of FreeBSD but are third- > > party > > applications. I've often thought that the packages on the > > installation > > disks should really be split to a separate project which produces > > package disks. This would lessen the burden on the Release Engineers > > and perhaps the cycle time between releases. It should also be > > noted that the useful life of a package is limited and outdated very > > quickly. > > Hey, these great comments bring up a different solution, which may be > the way to go. > > It is simple: have a few of the common apps that are net-centric (like > firefox) be simply calls to pkg_add -r in the installer. No ports > databases, no packages on the discs. A few packages may be useful > (like perl) to someone without net access, but many need the net to be > useful. No thanks. This means you have to have a working connection to install firefox via this method. Since not everyone will have that it is still necessary to bundle the firefox package on the media, bringing us right back to the very issue you are trying to solve. -- WXS From antik at bsd.ee Thu Sep 4 13:58:05 2008 From: antik at bsd.ee (Andrei Kolu) Date: Thu Sep 4 13:58:41 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <48BFDF48.1090203@alaska.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <20080904085415.GG15376@server.vk2pj.dyndns.org> <48BFDF48.1090203@alaska.net> Message-ID: <48BFE275.80207@bsd.ee> Royce Williams wrote: > Peter Jeremy wrote, on 9/4/2008 12:54 AM: > >> 2) Traditionally, the ISO images have been sized to fit on 650MB CD-RWs. >> Maybe this should be revisited but during a release freeze is not >> the right time for that. >> > > Isn't there a little more room now by default? From the 7.0 release > notes: > > The ISO images for FreeBSD are now sized for 700MB CDROM media. For > most prior versions of FreeBSD, they assumed 650MB CDROM media. [MERGED] > > > Royce > > First: Do you realise that there are old computers still in use that can't read more than 650MB cd media in case some sudden upgrade needed? Second: Why there is no rescue environment available on 1st cd? It is really lame to pop in second "livecd" (why such a name is beyound me- there is nothing live there...). I'd suggest to remove ports tree from first cd (we are using csup and portsnap anyway?) and move it to second- leaving more important features to first one. Andrei Kolu IT-Juht From otlk at cons.ru Thu Sep 4 14:29:49 2008 From: otlk at cons.ru (otlk@cons.ru) Date: Thu Sep 4 14:29:56 2008 Subject: aic-9405 Help! Message-ID: <1238227334.20080904180303@cons.ru> Hello, Freebsd-stable! I wonder if there will be available the support for AIC-9405 in relises 7.0 or 6.4 Regards, Nic Grig -- mailto:otlk@cons.ru From danallen46 at airwired.net Thu Sep 4 14:34:56 2008 From: danallen46 at airwired.net (Dan Allen) Date: Thu Sep 4 14:35:03 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <20080904134305.GC1188@atarininja.org> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <48BF23D3.2070509@brianwhalen.net> <20080904134305.GC1188@atarininja.org> Message-ID: On 4 Sep 2008, at 7:43 AM, Wesley Shields wrote: > No thanks. This means you have to have a working connection to > install > firefox via this method. Since not everyone will have that it is > still > necessary to bundle the firefox package on the media, bringing us > right > back to the very issue you are trying to solve. No. You do NOT get my point. Firefox is (almost) worthless without an internet connection. It's whole purpose is to browse the internet. Therefore, if you are going to use firefox, you by definition have an internet connection, hence you have the ability to get firefox through this same internet connection. (This assumes fetch or wget or curl is around to get firefox.) Dan From freebsd-stable at bengrimm.net Thu Sep 4 14:38:12 2008 From: freebsd-stable at bengrimm.net (Ben C. O. Grimm) Date: Thu Sep 4 14:38:32 2008 Subject: aic-9405 Help! In-Reply-To: <1238227334.20080904180303@cons.ru> References: <1238227334.20080904180303@cons.ru> Message-ID: <48BFF2A2.3010002@bengrimm.net> otlk@cons.ru wrote: > Hello, Freebsd-stable! > > I wonder if there will be available the support for AIC-9405 in > relises 7.0 or 6.4 > Regards, > Nic Grig http://www.mailinglistarchive.com/freebsd-drivers@freebsd.org/msg00346.html From lists at pingle.org Thu Sep 4 14:39:25 2008 From: lists at pingle.org (Jim Pingle) Date: Thu Sep 4 14:39:56 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <20080904134305.GC1188@atarininja.org> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <48BF23D3.2070509@brianwhalen.net> <20080904134305.GC1188@atarininja.org> Message-ID: <48BFEF26.2070405@pingle.org> Wesley Shields wrote: > On Wed, Sep 03, 2008 at 06:28:44PM -0600, Dan Allen wrote: >> Hey, these great comments bring up a different solution, which may be >> the way to go. >> >> It is simple: have a few of the common apps that are net-centric (like >> firefox) be simply calls to pkg_add -r in the installer. No ports >> databases, no packages on the discs. A few packages may be useful >> (like perl) to someone without net access, but many need the net to be >> useful. > > No thanks. This means you have to have a working connection to install > firefox via this method. Since not everyone will have that it is still > necessary to bundle the firefox package on the media, bringing us right > back to the very issue you are trying to solve. Could this not also be resolved another way? Most desktops these days have DVD drives. If someone wants a bootable desktop-targeted release with X, Firefox and such, why not make that a DVD instead of trying to shoehorn all of this into a CD? Most of the older machines with aging CD-ROM drives or without a DVD drive may not have the horsepower to run a live CD with X anyhow. My servers only have CD-ROM drives, but then again they wouldn't be using a desktop-oriented live CD with X either. :-) Sure, the download would be (much?) larger, but you would have a lot more room to work with. The CD installs are great for me, and have worked well for years. Personally, I install, update to -STABLE from a local cvsup mirror, then use an updated ports tree or install packages remotely. The packages on CD are out of date practically from the moment they are placed there, so I rarely use them. The only package I regularly used was cvsup-without-gui, which has been replaced by csup in the base system. Also, is not Ubuntu a "downstream" release of Debian, much like FreeSBIE and PC-BSD are "downstream" of FreeBSD? If you want to compare apples to apples, you might investigate those choices a little closer. Jim From koitsu at FreeBSD.org Thu Sep 4 14:41:26 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 4 14:41:35 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <48BFEF26.2070405@pingle.org> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <48BF23D3.2070509@brianwhalen.net> <20080904134305.GC1188@atarininja.org> <48BFEF26.2070405@pingle.org> Message-ID: <20080904144124.GA19965@icarus.home.lan> On Thu, Sep 04, 2008 at 10:22:30AM -0400, Jim Pingle wrote: > Also, is not Ubuntu a "downstream" release of Debian, much like FreeSBIE and > PC-BSD are "downstream" of FreeBSD? Re: Ubuntu -- Yes, it is. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From danallen46 at airwired.net Thu Sep 4 14:45:03 2008 From: danallen46 at airwired.net (Dan Allen) Date: Thu Sep 4 14:45:11 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <20080904062053.GA5953@icarus.home.lan> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <48BEEB55.4050406@madpilot.net> <20080904062053.GA5953@icarus.home.lan> Message-ID: <650D6892-6372-44A2-957F-B049E70DB881@airwired.net> On 4 Sep 2008, at 12:20 AM, Jeremy Chadwick wrote: > I haven't finished reading the thread yet, but your assumption is > ignorant. Why do you think FreeBSD is intended solely for desktop > usage? It's not. > > I, for one, **only want a command prompt** out of the box. I **do > not** > want Xorg or any X-related garbage on my servers. Jeremy - read the whole thread first. My assumption is NOT ignorant. I know that most people want just a command prompt. I myself live in command prompt mode on FreeBSD most of the time as well. I completely agree with you that there are many times when I do not want X.org anywhere around. I get that many people consider FreeBSD a server OS. I often tell people about how Yahoo and other big sites run on it. You may be interested to know, however, that some people ALSO use it as a desktop system. ;-) This is not trying to force anyone to have Firefox or Xorg. This is about options in the FreeBSD installer that USED to allow the OPTION of having X setup for you. This is about OPTIONS to install the single most widely used kind of software (a web browser) on the system in a simple, straightforward way. In the Standard Install there should be an option that says "Install Firefox & Xorg". It should be an OPTIONAL CHECK BOX, not a mandatory one, but it should allow a desktop scenario to be setup easily. If the disks are near full, or need to be uniform across processors, or whatever, then I am okay with not having all of X and Firefox on disc1 IF there was a simple set of "pkg_add -r" commands that could hidden behind a script or dialog which could fetch the necessary software over the internet and set it up (along with .conf files so X starts up reasonably well) so that a non-command line user could have a good first time experience. It was using Ubuntu that caused me to realize how far behind FreeBSD is on the desktop side, and how, with a SMALL AMOUNT of work and changes, it could make a big jump forward by this proposed simple addition. Heck, if nothing else the installer could simply say in a help screen, "if you want a web browser on your system, type 'pkg_add - r firefox' on your system and edit blah blah .conf blah". As it stands right now, however, there is very little in the install process which helps a user get X up and going with a browser. Thanks to everyone else for their comments. Dan From danallen46 at airwired.net Thu Sep 4 14:48:49 2008 From: danallen46 at airwired.net (Dan Allen) Date: Thu Sep 4 14:48:57 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <20080904094218.GB32453@nemesis.frida.mouhaha.de> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <32833CD6-DE00-4FDB-A01A-B86B0A25B3E4@airwired.net> <20080904094218.GB32453@nemesis.frida.mouhaha.de> Message-ID: <2FFE8E59-5CF1-4D65-BD6C-4ED8DE8FB14D@airwired.net> On 4 Sep 2008, at 3:42 AM, Oliver Peter wrote: > On Wed, Sep 03, 2008 at 02:58:45PM -0600, Dan Allen wrote: >> >> On 3 Sep 2008, at 1:14 PM, Peter Jeremy wrote: >> >>> Your patches to add support for the i4965 and your Marvell 88E80xx >>> must have been stripped by the mailing list software. Can you >>> please >>> re-send them. >> >> I have not written patches, thus I did not send any patches. > > | > `--> http://en.wikipedia.org/wiki/Sarcasm > > Btw. my philosophy is if you would like to use your favourite open > source > operating system - which I guess is FreeBSD - on your new hardware, > you > should spend additional 15 minutes when you make the decision what > hardware > you are going to buy and check the specs with the "Hardware Notes" at > http://www.freebsd.org/where.html. > > Complaining afterwards is easy but no one forces you to buy > unsupported > hardware. Point taken. A $500 Dell laptop, however, will be a popular machine and sooner or later should be supported. You know I thought you were being sarcastic, but then I was not sure... Dan From wxs at FreeBSD.org Thu Sep 4 14:51:15 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Thu Sep 4 14:51:23 2008 Subject: FreeBSD 7.1 Content In-Reply-To: References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <48BF23D3.2070509@brianwhalen.net> <20080904134305.GC1188@atarininja.org> Message-ID: <20080904145155.GD1188@atarininja.org> On Thu, Sep 04, 2008 at 08:34:54AM -0600, Dan Allen wrote: > > On 4 Sep 2008, at 7:43 AM, Wesley Shields wrote: > > > No thanks. This means you have to have a working connection to > > install > > firefox via this method. Since not everyone will have that it is > > still > > necessary to bundle the firefox package on the media, bringing us > > right > > back to the very issue you are trying to solve. > > No. You do NOT get my point. Firefox is (almost) worthless without > an internet connection. It's whole purpose is to browse the > internet. Therefore, if you are going to use firefox, you by > definition have an internet connection, hence you have the ability to > get firefox through this same internet connection. (This assumes > fetch or wget or curl is around to get firefox.) Firefox is not worthless without an internet connection. It can browse websites on networks not connected to the internet just fine. You seem to use it mostly on the internet at large, but don't assume the rest of the world does. Pushing firefox off the media is a bad idea. I've had scenarios in the past where I needed to stand up a machine with a browser on a physically isolated network. Having firefox on the media was very helpful in this case. Another scenario involves documentation which comes in HTML form. Why should I need an internet connection to get firefox just to read the documentation off my hard drive. Sure, I could use something else which can render the HTML but maybe I want to use firefox. This whole idea is a non-starter IMO. Although the install media suits my needs just fine I'm not naive enough to think it suits everyones needs just fine. There are projects mentioned in this thread already which are attempting to make the installer better and/or move to a DVD to ease some of the space constraints. If anyone wants to work on the problems outlined in this thread I think efforts are better spent on the sysinstall replacement projects going on and moving to a DVD. -- WXS From danallen46 at airwired.net Thu Sep 4 14:58:30 2008 From: danallen46 at airwired.net (Dan Allen) Date: Thu Sep 4 14:58:37 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <48BFEF26.2070405@pingle.org> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <48BF23D3.2070509@brianwhalen.net> <20080904134305.GC1188@atarininja.org> <48BFEF26.2070405@pingle.org> Message-ID: <7BDBF15A-A8E2-424C-9988-043B6A70F541@airwired.net> On 4 Sep 2008, at 8:22 AM, Jim Pingle wrote: > The CD installs are great for me, and have worked well for years. > Personally, I install, update to -STABLE from a local cvsup mirror, > then use > an updated ports tree or install packages remotely. The packages on > CD are > out of date practically from the moment they are placed there, so I > rarely > use them. The only package I regularly used was cvsup-without-gui, > which has > been replaced by csup in the base system. Okay, so how about for packages on the base CD: * cvsup-without-gui (I also always use this) * rsync * perl Then, since packages are always out-of-date, why not just skip the DVD and use the internet with a couple of check boxes at the end of the install, the way ports is treated now, that are just calls to pkg_add - r for: * KDE * GNOME * Firefox * ... whatever else are the most popular add-ons Fewer bits to be delivered via CD/DVD, and things are always up-to-date. > Also, is not Ubuntu a "downstream" release of Debian, much like > FreeSBIE and > PC-BSD are "downstream" of FreeBSD? If you want to compare apples to > apples, > you might investigate those choices a little closer. Touche. I had forgotten this. Perhaps this is why I was able to crash Ubuntu so quickly yesterday... ;-) I hope everyone realizes that I am not trying to "de-server" FreeBSD. I just remember how daunting it was for me to get X setup when all I wanted to use was a web browser when I was new to it all. The early BSD releases had a simple check box to add X support and it all just worked. That was COOL. That is what I am hoping to get back into BSD. I do not want to spill onto DVDs, remove the sources, get rid of command prompts, or force systems to have X.org on them... Dan From mad at madpilot.net Thu Sep 4 15:07:37 2008 From: mad at madpilot.net (Guido Falsi) Date: Thu Sep 4 15:07:48 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <7BDBF15A-A8E2-424C-9988-043B6A70F541@airwired.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <48BF23D3.2070509@brianwhalen.net> <20080904134305.GC1188@atarininja.org> <48BFEF26.2070405@pingle.org> <7BDBF15A-A8E2-424C-9988-043B6A70F541@airwired.net> Message-ID: <20080904150736.GA35003@megatron.madpilot.net> On Thu, Sep 04, 2008 at 08:58:27AM -0600, Dan Allen wrote: > > I hope everyone realizes that I am not trying to "de-server" FreeBSD. I > just remember how daunting it was for me to get X setup when all I > wanted to use was a web browser when I was new to it all. > > The early BSD releases had a simple check box to add X support and it > all just worked. That was COOL. That is what I am hoping to get back > into BSD. But setting X up now is perhaps even harder than what it used to be, and common user expectation are higher. You can't get away by just installing a vesa server...People would telle you it's slow, they would expect the system to already accelerated drivers, if available. Sure Vesa Xserver is more than enough for firefox....But newbies need to understand they will have to manually tweak xorg.conf anyway if they want a really working X setup. -- Guido Falsi From lists at peter.de.com Thu Sep 4 15:11:00 2008 From: lists at peter.de.com (Oliver Peter) Date: Thu Sep 4 15:11:08 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <2FFE8E59-5CF1-4D65-BD6C-4ED8DE8FB14D@airwired.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <32833CD6-DE00-4FDB-A01A-B86B0A25B3E4@airwired.net> <20080904094218.GB32453@nemesis.frida.mouhaha.de> <2FFE8E59-5CF1-4D65-BD6C-4ED8DE8FB14D@airwired.net> Message-ID: <20080904151056.GC32453@nemesis.frida.mouhaha.de> On Thu, Sep 04, 2008 at 08:48:46AM -0600, Dan Allen wrote: > > On 4 Sep 2008, at 3:42 AM, Oliver Peter wrote: > > > On Wed, Sep 03, 2008 at 02:58:45PM -0600, Dan Allen wrote: > >> > >> On 3 Sep 2008, at 1:14 PM, Peter Jeremy wrote: > >> > >>> Your patches to add support for the i4965 and your Marvell 88E80xx > >>> must have been stripped by the mailing list software. Can you > >>> please > >>> re-send them. > >> > >> I have not written patches, thus I did not send any patches. > > > > | > > `--> http://en.wikipedia.org/wiki/Sarcasm > > > > Btw. my philosophy is if you would like to use your favourite open > > source > > operating system - which I guess is FreeBSD - on your new hardware, > > you > > should spend additional 15 minutes when you make the decision what > > hardware > > you are going to buy and check the specs with the "Hardware Notes" at > > http://www.freebsd.org/where.html. > > > > Complaining afterwards is easy but no one forces you to buy > > unsupported > > hardware. > > Point taken. A $500 Dell laptop, however, will be a popular machine > and sooner or later should be supported. Would be nice to have that, I agree with you. But popularity is not an argument: Those 'fat' ATI graphics cards are quite popular as well but as long as the manufactor does not hand out nicer documentation you wont have a nice kernel module to get hardware acceleration. -- Oliver PETER, email: oliver@peter.de.com, ICQ# 113969174 "If it feels good, you're doing something wrong." -- Coach McTavish From mh at kernel32.de Thu Sep 4 15:19:55 2008 From: mh at kernel32.de (Marian Hettwer) Date: Thu Sep 4 15:20:03 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <650D6892-6372-44A2-957F-B049E70DB881@airwired.net> References: <650D6892-6372-44A2-957F-B049E70DB881@airwired.net> Message-ID: Hi Dan, On Thu, 4 Sep 2008 08:45:00 -0600, Dan Allen wrote: > > You may be interested to know, however, that some people ALSO use it > as a desktop system. ;-) > I second that! :) I for one really love FreeBSD on a server, 'cause it has a (to me) perfect setup of tools to use on a command line. On the other hand, guess what, since I'm administrating some FreeBSD boxes (and a whole lot more debian boxes too), my Desktop is a FreeBSD machine. > In the Standard Install there should be an option that says "Install > Firefox & Xorg". It should be an OPTIONAL CHECK BOX, not a mandatory > one, but it should allow a desktop scenario to be setup easily. > sounds good to me. > If the disks are near full, or need to be uniform across processors, > or whatever, then I am okay with not having all of X and Firefox on > disc1 IF there was a simple set of "pkg_add -r" commands that could > hidden behind a script or dialog which could fetch the necessary > software over the internet and set it up (along with .conf files so X > starts up reasonably well) so that a non-command line user could have > a good first time experience. > Ah well, create DVD images additionally to the standard iso images. > It was using Ubuntu that caused me to realize how far behind FreeBSD > is on the desktop side, and how, with a SMALL AMOUNT of work and > changes, it could make a big jump forward by this proposed simple > addition. Heck, if nothing else the installer could simply say in a > help screen, "if you want a web browser on your system, type 'pkg_add - > r firefox' on your system and edit blah blah .conf blah". As it > stands right now, however, there is very little in the install process > which helps a user get X up and going with a browser. > There is PC-BSD, FreeBSD based but aims on the desktop to achieve exactly what you said. I'm not sure wether FreeBSD needs to go that road too. Regards, Marian From mh at kernel32.de Thu Sep 4 15:35:11 2008 From: mh at kernel32.de (Marian Hettwer) Date: Thu Sep 4 15:35:19 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <20080904150736.GA35003@megatron.madpilot.net> References: <20080904150736.GA35003@megatron.madpilot.net> Message-ID: Hej Guido, On Thu, 4 Sep 2008 17:07:36 +0200, Guido Falsi wrote: > On Thu, Sep 04, 2008 at 08:58:27AM -0600, Dan Allen wrote: >> >> I hope everyone realizes that I am not trying to "de-server" FreeBSD. I >> just remember how daunting it was for me to get X setup when all I >> wanted to use was a web browser when I was new to it all. >> >> The early BSD releases had a simple check box to add X support and it >> all just worked. That was COOL. That is what I am hoping to get back >> into BSD. > > But setting X up now is perhaps even harder than what it used to be, and > common user expectation are higher. You can't get away by just > installing a vesa server...People would telle you it's slow, they would > expect the system to already accelerated drivers, if available. > Ah, I have to disagree. The last few times I installed a FreeBSD with xorg, I was really pleased how good xorg was in guessing my hardware in comparison to the olde days of XFree86. It was really, install xorg, run xorg -configure, take the config, install the nvidia driver from ports and nvidia settings too, then replace "nv" with "nvidia" in xorg.conf and with some clicks in the nvidia settings I was up and running dual screen. I thought to myself afterwards, Wow! that was easy. Used to be harder... > Sure Vesa Xserver is more than enough for firefox....But newbies need to > understand they will have to manually tweak xorg.conf anyway if they > want a really working X setup. > And really, place a warning "You're using Vesa 'cause we couldn't find a correct video driver" and off you go. In fact, I would be surprised if the ubuntu folks would do it different. Sometimes (hello newer ATI) you're lost in xorg land with some strange graphic boards. Cheers, ./Marian PS.: am I the only one, thinking that this thread should move to -chat? From besko at msu.edu Thu Sep 4 15:40:54 2008 From: besko at msu.edu (Lisa Besko) Date: Thu Sep 4 15:41:02 2008 Subject: boot failed after make installkernel from 6.3-RELEASE to 7.0-RELEASE In-Reply-To: <48BFC40C.3050309@ipeen.com.tw> References: <48BFC40C.3050309@ipeen.com.tw> Message-ID: <48C00184.7090005@msu.edu> I've had this very same problem. I had to go into the kernel config and change comment out this line: options ATA_STATIC_ID I may have also had to edit /etc/fstab so that it had the proper device name in it. Then I could rebuild the kernel and it worked. For me this had to to with the device names not matching up properly and after going to the latest version of 7 it would not find the correct device names for the drive. LB Chih Liang wrote: > Dear all, > > I've tried to upgrade my FreeBSD server from 6.3-RELEASE to 7.0-RELEASE, > but it is failed to boot after make kernel KERNCONF=GENERIC. > I didn't modify any file at /usr/src/sys/i386/conf, it was all default. > After done make kernel and reboot, system stop at: > > Timecounters tick every 1.000 msec > ad0: 38166MB at ata0-master UDMA100 > > I can't boot in single mode, but I can boot in safe mode, and it showed: > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:da0s1a > ? List valid disk boot devices > Abort manual input > > I type "?" for list, but it only show acd0 and fdc0, "ufs:ad0s1a" or > "ufs:/dev/ad0s1a" are not working > > I can boot with /boot/kernel.old now (6.3-RELEASE), I rebuilt kernel > again and again, but still not work. > I check the difference between old GENERIC on 6.3-RELEASE and new > GENERIC on 7.0-RELEASE, it has not difference besides new add in > 7.0-RELEASE. > > Is any one can help me? I don't want to reinstall...because I don't have > install cd... > > And sorry for my poor English, thank you for reading! > > Regards, > Chih Liang > _______________________________________________ > 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 bsd-unix at embarqmail.com Thu Sep 4 15:42:40 2008 From: bsd-unix at embarqmail.com (Randy Pratt) Date: Thu Sep 4 15:42:47 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <7BDBF15A-A8E2-424C-9988-043B6A70F541@airwired.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <48BF23D3.2070509@brianwhalen.net> <20080904134305.GC1188@atarininja.org> <48BFEF26.2070405@pingle.org> <7BDBF15A-A8E2-424C-9988-043B6A70F541@airwired.net> Message-ID: <20080904114236.bb1a6eb8.bsd-unix@embarqmail.com> On Thu, 4 Sep 2008 08:58:27 -0600 Dan Allen wrote: > Then, since packages are always out-of-date, why not just skip the DVD > and use the internet with a couple of check boxes at the end of the > install, the way ports is treated now, that are just calls to pkg_add - > r for: > > * KDE > * GNOME > * Firefox > * ... whatever else are the most popular add-ons > > Fewer bits to be delivered via CD/DVD, and things are always up-to-date. This functionality already exists in sysinstall. Go to Configure Do post-install configuration of FreeBSD Select: Packages Install pre-packaged software for FreeBSD Then select the installation media/method: 2 FTP Install from an FTP server Select ftp server: Main Site ftp.freebsd.org Sysinstall will retrieve the INDEX of all available packages. It might take a few minutes to display all the package options. Selecting a package to install will automatically install all needed dependencies. It might be necessary to set some options under: Options View/Set various installation options if you're trying to get package versions other than the particular FreeBSD version that you have (ie, LATEST). I don't remember the exact details for doing this since I no longer use (possibly obsolete) packages. Its been years since I used Sysinstall but I seem to remember that at the end of a new installation, it will ask if you want to install packages which is done as described above. HTH, Randy -- From peterson at notredame.ac.jp Thu Sep 4 15:47:00 2008 From: peterson at notredame.ac.jp (Greg Peterson) Date: Thu Sep 4 15:47:07 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <48BF8554.6060905@madpilot.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <48BEEB55.4050406@madpilot.net> <20080904062053.GA5953@icarus.home.lan> <48BF8554.6060905@madpilot.net> Message-ID: <82hc8wdl9a.wl%peterson@notredame.ac.jp> Guido, I agree completely with you and Jeremy. At Thu, 04 Sep 2008 08:51:00 +0200, Guido Falsi wrote: > > Jeremy Chadwick wrote: > > On Wed, Sep 03, 2008 at 03:01:48PM -0600, Dan Allen wrote: > >> On 3 Sep 2008, at 1:53 PM, Guido Falsi wrote: > >> > >>> If you just want na instant workstation, why you just don't try > >>> Freesbie or something like that? > >> Because I want something from the source -- from the main team -- and > >> not something downstream. > >> > >>> If I install FreeBSD on a PC I expect this installation to live there > >>> for some years. I can spend some hours/days installing and configuring > >>> what I really need. At least this is the way I see it. Maybe I'm > >>> misunderstanding you. > >> I too spend the time. I am thinking that for other people to want to > >> use FreeBSD they want something other than a command prompt. They at > >> least want a web browser out of the box. With the choices we have these days, I think they would be happier with a FreeBSD-based integrated distribution. > > I haven't finished reading the thread yet, but your assumption is > > ignorant. Why do you think FreeBSD is intended solely for desktop > > usage? It's not. > > > > I, for one, **only want a command prompt** out of the box. I **do not** > > want Xorg or any X-related garbage on my servers. > > I fully agree with this last statement. I choose freebsd for many > reasons, and this is one of those, I tried a few linux distributions, > and even slackware installs too much garbage if you're not looking > closely at it. Me, too. I'm typing this on an IBM ThinkPad R40e that once ran Xubuntu. Installation was a dream, and everything worked for a while. When the system became unstable after an upgrade, I couldn't untangle the different parts of the system since everything was dumped together under /etc/ and /usr/. I reinstalled FreeBSD, which I've used for over a decade. Now the machine is stable, and I can control which ports to install. More importantly, I can always get back to the operating system, and I know that it will work okay. I use FreeBSD for 99% of my desktop work (Xorg/fvwm2), but I would not want GUI code in the OS. People who want pre-installed software can use one of the new distributions that are getting good reviews. For me the clear distinction between the operating system and other software inspires great long-term confidence in FreeBSD. > And n the way to providing a useful desktop system out of the box, I > think no one can choose arbitrarily what to include and what not. Most > people would find WM+FF[23] too little, some other would want some > minimal gnome/kde, some others full blown gnome/kde (or other des for > example) who's bound to choose? Exactly. I even disagree with myself sometimes! A Web/mail/whatever server, an old laptop, and a fast, new workstation are different kinds of systems for different purposes. I really appreciate the separation of ports from the operating system. With the same OS it's easy to communicate about any FreeBSD system. With ports we have great flexibility, and we can back out of trouble (deinstall ports) and still keep the OS intact. That gives us solid reliability. > FreeBSD has always made a choice to be just an os, and a server oriented > one. There are downstream distributions bundling full blown systems, > and, as stated by others, the devel team has no time to spare, I think > it should concentrate on that, and leave the desktop work to others. I agree completely. As a long-term STABLE user, I'm happy to install ported and non-ported software that helps me do my work every day. People who port software and who develop integrated desktop systems contribute extremely valuable work, but that work is separate from the development and maintenance of FreeBSD. FreeBSD has been really rock-solid for so many years because dedicated people concentrate on the operating system. Their concentration on the OS enables others to contribute ports and special-purpose distributions with confidence. Greg Peterson From danallen46 at airwired.net Thu Sep 4 15:47:55 2008 From: danallen46 at airwired.net (Dan Allen) Date: Thu Sep 4 15:48:02 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <20080903191454.GA15376@server.vk2pj.dyndns.org> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> Message-ID: On 3 Sep 2008, at 1:14 PM, Peter Jeremy wrote: > A large number of Marvell 88E80xx chips are supported by msk(4). If > yours isn't, you are going to need to provide more details on what > chip you have. On 3 Sep 2008, at 7:02 PM, Aragon Gouveia wrote: > lspci ? I ran the lspci command and it states that the Ethernet is a Marvell 88E8040 PCI-E Fast Ethernet Controller. Are you looking for more info? Here is what lspci on Ubunut returns: Slot: 00:00.0 Class: Host bridge [0600] Vendor: Intel Corporation [8086] Device: Mobile PM965/GM965/GL960 Memory Controller Hub [2a00] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 0c Slot: 00:02.0 Class: VGA compatible controller [0300] Vendor: Intel Corporation [8086] Device: Mobile GM965/GL960 Integrated Graphics Controller [2a02] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 0c Slot: 00:02.1 Class: Display controller [0380] Vendor: Intel Corporation [8086] Device: Mobile GM965/GL960 Integrated Graphics Controller [2a03] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 0c Slot: 00:1a.0 Class: USB Controller [0c03] Vendor: Intel Corporation [8086] Device: 82801H (ICH8 Family) USB UHCI Controller #4 [2834] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 02 Slot: 00:1a.1 Class: USB Controller [0c03] Vendor: Intel Corporation [8086] Device: 82801H (ICH8 Family) USB UHCI Controller #5 [2835] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 02 Slot: 00:1a.7 Class: USB Controller [0c03] Vendor: Intel Corporation [8086] Device: 82801H (ICH8 Family) USB2 EHCI Controller #2 [283a] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 02 ProgIf: 20 Slot: 00:1b.0 Class: Audio device [0403] Vendor: Intel Corporation [8086] Device: 82801H (ICH8 Family) HD Audio Controller [284b] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 02 Slot: 00:1c.0 Class: PCI bridge [0604] Vendor: Intel Corporation [8086] Device: 82801H (ICH8 Family) PCI Express Port 1 [283f] Rev: 02 Slot: 00:1c.1 Class: PCI bridge [0604] Vendor: Intel Corporation [8086] Device: 82801H (ICH8 Family) PCI Express Port 2 [2841] Rev: 02 Slot: 00:1c.4 Class: PCI bridge [0604] Vendor: Intel Corporation [8086] Device: 82801H (ICH8 Family) PCI Express Port 5 [2847] Rev: 02 Slot: 00:1d.0 Class: USB Controller [0c03] Vendor: Intel Corporation [8086] Device: 82801H (ICH8 Family) USB UHCI Controller #1 [2830] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 02 Slot: 00:1d.1 Class: USB Controller [0c03] Vendor: Intel Corporation [8086] Device: 82801H (ICH8 Family) USB UHCI Controller #2 [2831] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 02 Slot: 00:1d.2 Class: USB Controller [0c03] Vendor: Intel Corporation [8086] Device: 82801H (ICH8 Family) USB UHCI Controller #3 [2832] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 02 Slot: 00:1d.7 Class: USB Controller [0c03] Vendor: Intel Corporation [8086] Device: 82801H (ICH8 Family) USB2 EHCI Controller #1 [2836] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 02 ProgIf: 20 Slot: 00:1e.0 Class: PCI bridge [0604] Vendor: Intel Corporation [8086] Device: 82801 Mobile PCI Bridge [2448] Rev: f2 ProgIf: 01 Slot: 00:1f.0 Class: ISA bridge [0601] Vendor: Intel Corporation [8086] Device: 82801HEM (ICH8M) LPC Interface Controller [2815] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 02 Slot: 00:1f.1 Class: IDE interface [0101] Vendor: Intel Corporation [8086] Device: 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller [2850] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 02 ProgIf: 8a Slot: 00:1f.2 Class: IDE interface [0101] Vendor: Intel Corporation [8086] Device: 82801HBM/HEM (ICH8M/ICH8M-E) SATA IDE Controller [2828] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 02 ProgIf: 8f Slot: 00:1f.3 Class: SMBus [0c05] Vendor: Intel Corporation [8086] Device: 82801H (ICH8 Family) SMBus Controller [283e] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 02 Slot: 02:09.0 Class: FireWire (IEEE 1394) [0c00] Vendor: Ricoh Co Ltd [1180] Device: R5C832 IEEE 1394 Controller [0832] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 05 ProgIf: 10 Slot: 02:09.1 Class: SD Host controller [0805] Vendor: Ricoh Co Ltd [1180] Device: R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [0822] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 22 ProgIf: 01 Slot: 02:09.2 Class: System peripheral [0880] Vendor: Ricoh Co Ltd [1180] Device: R5C843 MMC Host Controller [0843] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 12 Slot: 02:09.3 Class: System peripheral [0880] Vendor: Ricoh Co Ltd [1180] Device: R5C592 Memory Stick Bus Host Adapter [0592] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 12 Slot: 02:09.4 Class: System peripheral [0880] Vendor: Ricoh Co Ltd [1180] Device: xD-Picture Card Controller [0852] Rev: ff ProgIf: ff Slot: 09:00.0 Class: Ethernet controller [0200] Vendor: Marvell Technology Group Ltd. [11ab] Device: 88E8040 PCI-E Fast Ethernet Controller [4354] SVendor: Dell [1028] SDevice: Unknown device [022f] Rev: 12 Slot: 0b:00.0 Class: Network controller [0280] Vendor: Intel Corporation [8086] Device: PRO/Wireless 4965 AG or AGN Network Connection [4229] SVendor: Intel Corporation [8086] SDevice: Unknown device [1120] Rev: 61 From lists at pingle.org Thu Sep 4 15:49:23 2008 From: lists at pingle.org (Jim Pingle) Date: Thu Sep 4 15:49:31 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <7BDBF15A-A8E2-424C-9988-043B6A70F541@airwired.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <48BF23D3.2070509@brianwhalen.net> <20080904134305.GC1188@atarininja.org> <48BFEF26.2070405@pingle.org> <7BDBF15A-A8E2-424C-9988-043B6A70F541@airwired.net> Message-ID: <48C0037E.1040503@pingle.org> Dan Allen wrote: > On 4 Sep 2008, at 8:22 AM, Jim Pingle wrote: > Okay, so how about for packages on the base CD: > > * cvsup-without-gui (I also always use this) > * rsync > * perl As others have mentioned, there are plenty of uses for packages, even if I do not use them "out of the box" there are lots of people who do so, and need them because their networks are completely isolated, or the computers will not be networked and do not have an urgent need for security updates or the latest & greatest versions. > Then, since packages are always out-of-date, why not just skip the DVD > and use the internet with a couple of check boxes at the end of the > install, the way ports is treated now, that are just calls to pkg_add -r > for: > > * KDE > * GNOME > * Firefox > * ... whatever else are the most popular add-ons > > Fewer bits to be delivered via CD/DVD, and things are always up-to-date. My memory may be failing me, but there used to be a port called "instant workstaion" that accomplished quite a bit, and the installer would drop in X but asked for KDE or Gnome, but I don't recall when those choices went away. It appears the workstation port went away because it was broken and had no maintainer[1]. I have no idea what it might take to gather support for someone to resurrect the port and keep it updated. I would not mind having such an option again for desktops, but I would use it very rarely (only two, maybe three of my FreeBSD systems see desktop-type use). >> Also, is not Ubuntu a "downstream" release of Debian, much like >> FreeSBIE and >> PC-BSD are "downstream" of FreeBSD? If you want to compare apples to >> apples, >> you might investigate those choices a little closer. > > Touche. I had forgotten this. Perhaps this is why I was able to crash > Ubuntu so quickly yesterday... ;-) Perhaps. I use Ubuntu on a couple systems and it is pretty solid. I used it mainly because it was easy to turn on the eye candy bits in X to show people what other OS choices are out there. (Average Joes are really impressed with the wobbly windows and the way the cube switches multiple desktops) > I hope everyone realizes that I am not trying to "de-server" FreeBSD. I > just remember how daunting it was for me to get X setup when all I > wanted to use was a web browser when I was new to it all. Really? It's been easy for me lately, but I don't run on new hardware very often. On older systems it's been a matter of installing the packages/ports and running startx. The hard part was waiting for all the packages to install. I have had a few systems where I needed to tweak Xorg's config, but not too much. In my experience, it runs much better these days with default choices than it did in years past. I know others have had just the opposite experience, so apparently there is still work to be done. > The early BSD releases had a simple check box to add X support and it > all just worked. That was COOL. That is what I am hoping to get back > into BSD. See above, re: instant workstation port. I don't know if it was the same in the installer or not, but I seem to recall it having a similar effect. I also thought I remembered FreeBSD themes for KDE and Gnome that were used by default. There is a beasie theme for Gnome (x11-themes/beastie) but I have not used it so I don't know what it looks like. > I do not want to spill onto DVDs, remove the sources, get rid of command > prompts, or force systems to have X.org on them... I don't think spilling onto a DVD is a bad thing, as a choice. Then again, even Ubuntu has separate install CDs for desktop and server. You might want to talk to the developer of finstall[2], it might be in line with what you are envisioning. Jim 1: http://lists.freebsd.org/pipermail/freebsd-questions/2008-April/173383.html 2: http://wiki.freebsd.org/finstall From danallen46 at airwired.net Thu Sep 4 15:50:23 2008 From: danallen46 at airwired.net (Dan Allen) Date: Thu Sep 4 15:50:31 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <20080904114236.bb1a6eb8.bsd-unix@embarqmail.com> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <48BF23D3.2070509@brianwhalen.net> <20080904134305.GC1188@atarininja.org> <48BFEF26.2070405@pingle.org> <7BDBF15A-A8E2-424C-9988-043B6A70F541@airwired.net> <20080904114236.bb1a6eb8.bsd-unix@embarqmail.com> Message-ID: On 4 Sep 2008, at 9:42 AM, Randy Pratt wrote: > 2 FTP Install from an FTP server We have a winner! I think this is what I may have overlooked: setting the source to FTP rather than to CD. I have always used the packages on the discs, and I have always downloaded just disc1, which used to include some of the packages being discussed, such as X. Dan From koitsu at FreeBSD.org Thu Sep 4 15:54:04 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 4 15:54:12 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <7BDBF15A-A8E2-424C-9988-043B6A70F541@airwired.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <48BF23D3.2070509@brianwhalen.net> <20080904134305.GC1188@atarininja.org> <48BFEF26.2070405@pingle.org> <7BDBF15A-A8E2-424C-9988-043B6A70F541@airwired.net> Message-ID: <20080904155403.GA21394@icarus.home.lan> On Thu, Sep 04, 2008 at 08:58:27AM -0600, Dan Allen wrote: > Okay, so how about for packages on the base CD: > > * cvsup-without-gui (I also always use this) Side note: You don't need this, especially since you're using -without-gui. There is a utility in the base system called csup(1) which supports the same command-line arguments, is written entirely in C / doesn't rely on ezm3/modula3. It behaves the same way, and speaks the CVSup protocol. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From danallen46 at airwired.net Thu Sep 4 15:55:46 2008 From: danallen46 at airwired.net (Dan Allen) Date: Thu Sep 4 15:55:53 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <48C0037E.1040503@pingle.org> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <48BF23D3.2070509@brianwhalen.net> <20080904134305.GC1188@atarininja.org> <48BFEF26.2070405@pingle.org> <7BDBF15A-A8E2-424C-9988-043B6A70F541@airwired.net> <48C0037E.1040503@pingle.org> Message-ID: <6526664E-70F0-4683-A37A-3839D51C7AF6@airwired.net> On 4 Sep 2008, at 9:49 AM, Jim Pingle wrote: > My memory may be failing me, but there used to be a port called > "instant > workstaion" that accomplished quite a bit, and the installer would > drop in X > but asked for KDE or Gnome, but I don't recall when those choices > went away. This is in fact what I remember too: one had a choice of Server or Workstation and a further choice of KDE or GNOME. I remember that when I saw the choice of KDE or GNOME I had no idea which I should choose because I knew nothing about them. I will re-explore these sysinstall options, and grabbing packages with FTP once I can figure out how to get some sort of networking going on my new laptop. Dan From koitsu at FreeBSD.org Thu Sep 4 16:01:53 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 4 16:02:05 2008 Subject: Inspiron 1525 Hardware In-Reply-To: References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> Message-ID: <20080904160150.GB21394@icarus.home.lan> On Thu, Sep 04, 2008 at 09:47:52AM -0600, Dan Allen wrote: > On 3 Sep 2008, at 7:02 PM, Aragon Gouveia wrote: >> lspci ? > > I ran the lspci command and it states that the Ethernet is a Marvell > 88E8040 PCI-E Fast Ethernet Controller. Are you looking for more info? > > Here is what lspci on Ubunut returns: "Ubunut" is a funny typo. I know it was unintentional, but it made me laugh. :-) > Slot: 09:00.0 > Class: Ethernet controller [0200] > Vendor: Marvell Technology Group Ltd. [11ab] > Device: 88E8040 PCI-E Fast Ethernet Controller [4354] > SVendor: Dell [1028] > SDevice: Unknown device [022f] > Rev: 12 This revision of Marvell NIC isn't supported under FreeBSD 7.0 or 8.0 (CURRENT/HEAD). I've looked at the source to msk(4), and it matches what's in the manpage, so it's not a documentation mistake. http://www.freebsd.org/cgi/man.cgi?query=msk&apropos=0&sektion=0&manpath=FreeBSD+7.0-stable&format=html Support for the 88E8040 can be added to the msk(4) driver, probably via a PCI ID addition to the msk_products[] struct in src/sys/dev/msk/if_msk.c, but sometimes more is needed. I've CC'd the maintainer of msk(4), PYUN Yong-Hyeon, who can work with you and provide patches to get support for that NIC. (Please note that when referring to him, his first name is Yong-Hyeon, not Pyun.) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From mad at madpilot.net Thu Sep 4 16:08:40 2008 From: mad at madpilot.net (Guido Falsi) Date: Thu Sep 4 16:08:52 2008 Subject: FreeBSD 7.1 Content In-Reply-To: References: <20080904150736.GA35003@megatron.madpilot.net> Message-ID: <20080904160839.GC35003@megatron.madpilot.net> On Thu, Sep 04, 2008 at 05:35:09PM +0200, Marian Hettwer wrote: > > > Ah, I have to disagree. > The last few times I installed a FreeBSD with xorg, I was really pleased > how good xorg was in guessing my hardware in comparison to the olde days of > XFree86. > It was really, install xorg, run xorg -configure, take the config, install > the nvidia driver from ports and nvidia settings too, then replace "nv" > with "nvidia" in xorg.conf and with some clicks in the nvidia settings I > was up and running dual screen. > I thought to myself afterwards, Wow! that was easy. Used to be harder... This goes beyond the scope of the thread. I know I started this, my point was that trying to guess what people will be expecting or trying to do with such an option is difficult. It may cause more problems that solve them, and that things like FreeSBIE are bbetter tools at the job. No objection to an option like "install xorg/fvwm/FF3", but I think it will make just a few people happier, not really help any newbie, and be of no purpose to people like me. On the other hand such an option will have to be supported if present. > PS.: am I the only one, thinking that this thread should move to -chat? I think this thread has outgrown both the original author's intentions and mine. I just answered by instinct, I disagreed with some points, but as I said here I have no objection to an option in istall, but IMHO supporting it may be harder than what it's worth. -- Guido Falsi From brian at brianwhalen.net Thu Sep 4 16:11:25 2008 From: brian at brianwhalen.net (Brian) Date: Thu Sep 4 16:11:40 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <20080904134305.GC1188@atarininja.org> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <48BF23D3.2070509@brianwhalen.net> <20080904134305.GC1188@atarininja.org> Message-ID: <48C0089C.6090902@brianwhalen.net> > No thanks. This means you have to have a working connection to install > firefox via this method. Since not everyone will have that it is still > necessary to bundle the firefox package on the media, bringing us right > back to the very issue you are trying to solve. > > -- WXS > _______________________________________________ > 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 is a benefit to me, by doing the minimal boot then net install, I know VERY quickly if the network adapter on the mobo is supported or if I need to go insert some known supported pci Ethernet card. For most users, I suspect a system without net access isn't worth m,uch. Brian From gavin.atkinson at ury.york.ac.uk Thu Sep 4 16:30:15 2008 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Thu Sep 4 16:30:22 2008 Subject: Inspiron 1525 Hardware In-Reply-To: References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> Message-ID: <1220545795.94705.15.camel@buffy.york.ac.uk> On Thu, 2008-09-04 at 09:47 -0600, Dan Allen wrote: > Here is what lspci on Ubunut returns: > Slot: 09:00.0 > Class: Ethernet controller [0200] > Vendor: Marvell Technology Group Ltd. [11ab] > Device: 88E8040 PCI-E Fast Ethernet Controller [4354] > SVendor: Dell [1028] > SDevice: Unknown device [022f] > Rev: 12 This particular chip isn't supported in any version of FreeBSD at this moment. Patches do exist for it at http://people.freebsd.org/~yongari/msk/msk.88E8040.patch but they haven't been integrated yet, presumably because it hasn't been sufficiently tested yet. > Slot: 0b:00.0 > Class: Network controller [0280] > Vendor: Intel Corporation [8086] > Device: PRO/Wireless 4965 AG or AGN Network Connection [4229] > SVendor: Intel Corporation [8086] > SDevice: Unknown device [1120] > Rev: 61 This is supported by the iwn(4) driver in CURRENT, and it should be quite easy to port the driver to 7-STABLE. If you're interested in reinstalling FreeBSD and testing a backported driver, I'm sure this can be sorted. Gavin From gphoto6 at gmail.com Thu Sep 4 16:33:58 2008 From: gphoto6 at gmail.com (Tim Chen) Date: Thu Sep 4 16:34:06 2008 Subject: How to disable NFS fnctl in /etc/fstab? Message-ID: <1f51039c0809040911oe4409b5ibe3f4dcf53528407@mail.gmail.com> For some reason we want to disable fnctl lock for NFS mounted partition. We can achieve this by the following command: mount_nfs -T -L server:/home /mnt However after several time of failure tests, we still can not make it work in /etc/fstab. server:/home /mnt nfs rw,tcp 0 0 It seems there is no coresponding options in /etc/fstab so that I can disable fnctl lock for NFS. If we can not set it right in /etc/fstab, every time the machine reboot requires human intervention to mount the partition manually. It is very annoying and inconvenient. Please give us some suggestion and hint to solve this situation. By the way, since the machine is running as a mail server which install postfix,courier-imap, will it happen any kind of data corruption due to NFS fnctl lock disabled? Best regards, Tim From kometen at gmail.com Thu Sep 4 16:52:34 2008 From: kometen at gmail.com (Claus Guttesen) Date: Thu Sep 4 16:52:41 2008 Subject: How to disable NFS fnctl in /etc/fstab? In-Reply-To: <1f51039c0809040911oe4409b5ibe3f4dcf53528407@mail.gmail.com> References: <1f51039c0809040911oe4409b5ibe3f4dcf53528407@mail.gmail.com> Message-ID: > For some reason we want to disable fnctl lock for NFS > mounted partition. We can achieve this by the following > command: mount_nfs -T -L server:/home /mnt > However after several time of failure tests, we still > can not make it work in /etc/fstab. > According to man mount_nfs: -L Do not forward fcntl(2) locks over the wire. All locks will be local and not seen by the server and likewise not seen by other NFS clients. This removes the need to run the rpcbind(8) service and the rpc.statd(8) and rpc.lockd(8) servers on the client. Note that this option will only be honored when performing the initial mount, it will be silently ignored if used while updating the mount options. ... Historic -o Options Use of these options is deprecated, they are only mentioned here for compatibility with historic versions of mount_nfs. bg Same as -b. ... lockd Same as not specifying -L. If you do not specify lockd on the client and don't run rpcbind on the server it may run as you require. But I haven't tried myself. If my assumption is correct you only need to make shure that rpcbind is not running on the server. -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare From freebsd-stable at bengrimm.net Thu Sep 4 16:56:02 2008 From: freebsd-stable at bengrimm.net (Ben C. O. Grimm) Date: Thu Sep 4 16:56:09 2008 Subject: How to disable NFS fnctl in /etc/fstab? In-Reply-To: <1f51039c0809040911oe4409b5ibe3f4dcf53528407@mail.gmail.com> References: <1f51039c0809040911oe4409b5ibe3f4dcf53528407@mail.gmail.com> Message-ID: <48C012F7.6090809@bengrimm.net> Tim Chen wrote: > For some reason we want to disable fnctl lock for NFS > mounted partition. We can achieve this by the following > command: mount_nfs -T -L server:/home /mnt > However after several time of failure tests, we still > can not make it work in /etc/fstab. > > server:/home /mnt nfs rw,tcp 0 0 > > It seems there is no coresponding options in /etc/fstab > so that I can disable fnctl lock for NFS. If we can not > set it right in /etc/fstab, every time the machine reboot > requires human intervention to mount the partition manually. > It is very annoying and inconvenient. > > Please give us some suggestion and hint to solve this situation. I see some references to 'nolock' here and there, but YMMV. From Ben.Grimm at BenGrimm.net Thu Sep 4 17:00:01 2008 From: Ben.Grimm at BenGrimm.net (Ben C. O. Grimm) Date: Thu Sep 4 17:00:08 2008 Subject: How to disable NFS fnctl in /etc/fstab? In-Reply-To: <1f51039c0809040911oe4409b5ibe3f4dcf53528407@mail.gmail.com> References: <1f51039c0809040911oe4409b5ibe3f4dcf53528407@mail.gmail.com> Message-ID: <48C00FEF.2000209@BenGrimm.net> Tim Chen wrote: > For some reason we want to disable fnctl lock for NFS > mounted partition. We can achieve this by the following > command: mount_nfs -T -L server:/home /mnt > However after several time of failure tests, we still > can not make it work in /etc/fstab. > > server:/home /mnt nfs rw,tcp 0 0 > > It seems there is no coresponding options in /etc/fstab > so that I can disable fnctl lock for NFS. If we can not > set it right in /etc/fstab, every time the machine reboot > requires human intervention to mount the partition manually. > It is very annoying and inconvenient. > > Please give us some suggestion and hint to solve this situation. I see some references to 'nolock' here and there, but YMMV. From koitsu at FreeBSD.org Thu Sep 4 17:16:35 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 4 17:16:43 2008 Subject: How to disable NFS fnctl in /etc/fstab? In-Reply-To: <1f51039c0809040911oe4409b5ibe3f4dcf53528407@mail.gmail.com> References: <1f51039c0809040911oe4409b5ibe3f4dcf53528407@mail.gmail.com> Message-ID: <20080904171633.GA22946@icarus.home.lan> On Fri, Sep 05, 2008 at 12:11:20AM +0800, Tim Chen wrote: > By the way, since the machine is running as a mail server which > install postfix,courier-imap, will it happen any kind of data > corruption due to NFS fnctl lock disabled? Regarding postfix, you will probably need dotlocking enabled during mailbox delivery. http://www.postfix.org/NFS_README.html Regarding courier-imap (have you considered dovecot?), you might want to see commit revision 1.4.3 to the Makefile, indicating fcntl is required to build the port on an NFS mount, so fcntl is forced: http://www.freebsd.org/cgi/cvsweb.cgi/ports/mail/courier-imap/Makefile Be sure to look at line 65 of the Makefile. Regarding courier-imap itself, I believe it can be configured to use dotlocks, but I can't find any documentation on this (I'm searching Google though). Finally, this seems relevant (arguing "do not disable fcntl over NFS!"), as something I happened to be reading earlier today; see "Why is NFS so slow?": http://www.fefe.de/muttfaq/faq.html#common-problems Personally, I think you're asking for trouble disabling fcntl on NFS; the fact you're having to (more or less) reverse-engineer all this software to find out if it's compatible with that scenario is added proof. The fact you're doing this on a mail server running an MDA is even more scary. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From danallen46 at airwired.net Thu Sep 4 17:33:00 2008 From: danallen46 at airwired.net (Dan Allen) Date: Thu Sep 4 17:33:07 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <1220545795.94705.15.camel@buffy.york.ac.uk> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <1220545795.94705.15.camel@buffy.york.ac.uk> Message-ID: <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> On 4 Sep 2008, at 10:29 AM, Gavin Atkinson wrote: > This is supported by the iwn(4) driver in CURRENT, and it should be > quite easy to port the driver to 7-STABLE. If you're interested in > reinstalling FreeBSD and testing a backported driver, I'm sure this > can > be sorted. I am interested in doing this. Please advise on how I can get these bits. Dan From gavin at FreeBSD.org Thu Sep 4 17:49:12 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Thu Sep 4 17:49:19 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <1220545795.94705.15.camel@buffy.york.ac.uk> <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> Message-ID: <1220550536.94705.18.camel@buffy.york.ac.uk> On Thu, 2008-09-04 at 11:32 -0600, Dan Allen wrote: > On 4 Sep 2008, at 10:29 AM, Gavin Atkinson wrote: > > > This is supported by the iwn(4) driver in CURRENT, and it should be > > quite easy to port the driver to 7-STABLE. If you're interested in > > reinstalling FreeBSD and testing a backported driver, I'm sure this > > can be sorted. > > I am interested in doing this. Please advise on how I can get these > bits. I've got hold of a laptop with the 4965 chipset in it, if nobody beats me to it I'll have a go at backporting the driver. Gavin From jrhett at netconsonance.com Thu Sep 4 18:40:47 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Sep 4 18:40:59 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <20080904133604.GB1188@atarininja.org> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> Message-ID: >>> Where can one find the expected EoL for these releases? > On Wed, Sep 03, 2008 at 09:24:04PM -0700, Nathan Way wrote: >> http://www.freebsd.org/security/security.html#supported-branches >> To quote from the above web site: (snip) On Sep 4, 2008, at 6:36 AM, Wesley Shields wrote: > These are the existing releases. I believe Jo was looking for EoL for > 7.1 and 6.4 once they are released. Yes, thank you. > The answer to that is not clear - > nor do I know if it should be clear yet. I don't know when the type > of > support decision is made, but I suspect it's not this early in the > process. The release date for 6.4 is ~30 days away, isn't it? Also given that we've previously seen overlaps such that a newer version is only supported to the same EoL as the older version, that would pretty much dictate that spending resources on testing 6.4-REL and/or upgrading would be futile. To go back to the original statements made at the time: "you should consider the lifetime of the release before you invest resources in it". That means we need to know the lifetime to determine how much resources to apply to testing it, yes? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From stephen at math.missouri.edu Thu Sep 4 18:56:36 2008 From: stephen at math.missouri.edu (Stephen Montgomery-Smith) Date: Thu Sep 4 18:56:46 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <1220550536.94705.18.camel@buffy.york.ac.uk> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <1220545795.94705.15.camel@buffy.york.ac.uk> <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> <1220550536.94705.18.camel@buffy.york.ac.uk> Message-ID: <48C02768.1080207@math.missouri.edu> Gavin Atkinson wrote: > On Thu, 2008-09-04 at 11:32 -0600, Dan Allen wrote: >> On 4 Sep 2008, at 10:29 AM, Gavin Atkinson wrote: >> >>> This is supported by the iwn(4) driver in CURRENT, and it should be >>> quite easy to port the driver to 7-STABLE. If you're interested in >>> reinstalling FreeBSD and testing a backported driver, I'm sure this >>> can be sorted. >> I am interested in doing this. Please advise on how I can get these >> bits. > > I've got hold of a laptop with the 4965 chipset in it, if nobody beats > me to it I'll have a go at backporting the driver. I have a Dell Inspiron 1525 with the intel wireless ethernet. The iwn driver in CURRENT works well. The http://people.freebsd.org/~yongari/msk/msk.88E8040.patch patch for the 88E8040 simply doesn't work. It is not because of lack of testing (which I have performed for Pyun who wrote the patch), but apparently because of lack of reliable documentation. There is a driver for FreeBSD on the Marvell web site, which did work for me, but I am told it is unreliable. I also have had a hard time getting the sound to work. The oss port does work, but has a habit of freezing up. From unixmania at gmail.com Thu Sep 4 19:17:17 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Thu Sep 4 19:17:24 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <48C02768.1080207@math.missouri.edu> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <1220545795.94705.15.camel@buffy.york.ac.uk> <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> <1220550536.94705.18.camel@buffy.york.ac.uk> <48C02768.1080207@math.missouri.edu> Message-ID: On Thu, Sep 4, 2008 at 3:22 PM, Stephen Montgomery-Smith wrote: > Gavin Atkinson wrote: >> >> On Thu, 2008-09-04 at 11:32 -0600, Dan Allen wrote: >>> >>> On 4 Sep 2008, at 10:29 AM, Gavin Atkinson wrote: >>> >>>> This is supported by the iwn(4) driver in CURRENT, and it should be >>>> quite easy to port the driver to 7-STABLE. If you're interested in >>>> reinstalling FreeBSD and testing a backported driver, I'm sure this can >>>> be sorted. >>> >>> I am interested in doing this. Please advise on how I can get these >>> bits. >> >> I've got hold of a laptop with the 4965 chipset in it, if nobody beats >> me to it I'll have a go at backporting the driver. > > I have a Dell Inspiron 1525 with the intel wireless ethernet. > > The iwn driver in CURRENT works well. > > The http://people.freebsd.org/~yongari/msk/msk.88E8040.patch patch for the > 88E8040 simply doesn't work. It is not because of lack of testing (which I > have performed for Pyun who wrote the patch), but apparently because of lack > of reliable documentation. There is a driver for FreeBSD on the Marvell web > site, which did work for me, but I am told it is unreliable. > > I also have had a hard time getting the sound to work. The oss port does > work, but has a habit of freezing up. Did you try using Alexander Motin's new snd_hda patches? They are available at http://people.freebsd.org/~mav/ -- cd /usr/ports/sysutils/life make clean From lambert at lambertfam.org Thu Sep 4 19:22:34 2008 From: lambert at lambertfam.org (Scott Lambert) Date: Thu Sep 4 19:22:42 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <20080904062053.GA5953@icarus.home.lan> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <48BEEB55.4050406@madpilot.net> <20080904062053.GA5953@icarus.home.lan> Message-ID: <20080904190008.GA19413@sysmon.tcworks.net> On Wed, Sep 03, 2008 at 11:20:53PM -0700, Jeremy Chadwick wrote: > On Wed, Sep 03, 2008 at 03:01:48PM -0600, Dan Allen wrote: > > On 3 Sep 2008, at 1:53 PM, Guido Falsi wrote: > >> If you just want na instant workstation, why you just don't try > >> Freesbie or something like that? > > > > Because I want something from the source -- from the main team -- and > > not something downstream. > > I think what you might be looking for is, believe it or not, PC-BSD. I > believe you can install PC-BSD and get a working X desktop with a > browser and all that jazz right out of the box. Don't forget DesktopBSD. I'm not a big user of PC-BSD or DesktopBSD. My desktop operating system is Mac OS X. My servers are FreeBSD WITHOUT_X11=YES. Howeever, it is my understanding, from what I've read, that DesktopBSD tries to stay closer to "the source" in that they use the ports collection to install most of the "make it easier for end-users" stuff. They seem to have an installer and some extra ports. That may give you more of the warm fuzzies than PC-BSD. -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org From ersaloz at gmail.com Thu Sep 4 21:03:13 2008 From: ersaloz at gmail.com (Ernest Sales) Date: Thu Sep 4 21:03:20 2008 Subject: ports from -release vs. -latest [was: RE: FreeBSD 7.1 Content] In-Reply-To: <20080904160211.927EF10657BF@hub.freebsd.org> Message-ID: <000001c90ecd$207cbca0$2101a8c0@asinusaureus> > Date: Thu, 04 Sep 2008 10:22:30 -0400 > From: Jim Pingle > Subject: Re: FreeBSD 7.1 Content > To: Wesley Shields > Cc: Dan Allen , freebsd-stable@freebsd.org > Message-ID: <48BFEF26.2070405@pingle.org> > Content-Type: text/plain; charset=UTF-8 > > Wesley Shields wrote: > > On Wed, Sep 03, 2008 at 06:28:44PM -0600, Dan Allen wrote: > >> Hey, these great comments bring up a different solution, > which may be > >> the way to go. > >> > >> It is simple: have a few of the common apps that are > net-centric (like > >> firefox) be simply calls to pkg_add -r in the installer. No ports > >> databases, no packages on the discs. A few packages may be useful > >> (like perl) to someone without net access, but many need > the net to be > >> useful. > > > > No thanks. This means you have to have a working > connection to install > > firefox via this method. Since not everyone will have that > it is still > > necessary to bundle the firefox package on the media, > bringing us right > > back to the very issue you are trying to solve. > > Could this not also be resolved another way? > > Most desktops these days have DVD drives. If someone wants a bootable > desktop-targeted release with X, Firefox and such, why not > make that a DVD > instead of trying to shoehorn all of this into a CD? Most of the older > machines with aging CD-ROM drives or without a DVD drive may > not have the > horsepower to run a live CD with X anyhow. My servers only have CD-ROM > drives, but then again they wouldn't be using a > desktop-oriented live CD > with X either. :-) > > Sure, the download would be (much?) larger, but you would > have a lot more > room to work with. > > The CD installs are great for me, and have worked well for years. > Personally, I install, update to -STABLE from a local cvsup > mirror, then use > an updated ports tree or install packages remotely. The > packages on CD are > out of date practically from the moment they are placed > there, so I rarely > use them. The only package I regularly used was I use to update ports almost weekly from -latest, but the resulting GUI is not always consistent, so I am considering to stick with the -release tag. Could someone comment on the quality of ports from -release vs. -latest? In other words, can I expect a substantial gain in usability by doing so? Ernest > cvsup-without-gui, which has > been replaced by csup in the base system. > > Also, is not Ubuntu a "downstream" release of Debian, much > like FreeSBIE and > PC-BSD are "downstream" of FreeBSD? If you want to compare > apples to apples, > you might investigate those choices a little closer. > > Jim From stephen at math.missouri.edu Thu Sep 4 22:31:18 2008 From: stephen at math.missouri.edu (Stephen Montgomery-Smith) Date: Thu Sep 4 22:31:25 2008 Subject: Inspiron 1525 Hardware In-Reply-To: References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <1220545795.94705.15.camel@buffy.york.ac.uk> <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> <1220550536.94705.18.camel@buffy.york.ac.uk> <48C02768.1080207@math.missouri.edu> Message-ID: <48C061AA.5090507@math.missouri.edu> Carlos A. M. dos Santos wrote: > Did you try using Alexander Motin's new snd_hda patches? They are available at > > http://people.freebsd.org/~mav/ > Thanks. I hadn't tried them. But they didn't work. (I used the Sept 4 patch on CURRENT.) I could provide more diagnostics if anyone wants to work to make it work. From unixmania at gmail.com Fri Sep 5 00:34:01 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Fri Sep 5 00:34:07 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <48C061AA.5090507@math.missouri.edu> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <1220545795.94705.15.camel@buffy.york.ac.uk> <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> <1220550536.94705.18.camel@buffy.york.ac.uk> <48C02768.1080207@math.missouri.edu> <48C061AA.5090507@math.missouri.edu> Message-ID: On Thu, Sep 4, 2008 at 7:31 PM, Stephen Montgomery-Smith wrote: > Carlos A. M. dos Santos wrote: > >> Did you try using Alexander Motin's new snd_hda patches? They are >> available at >> >> http://people.freebsd.org/~mav/ >> > > Thanks. I hadn't tried them. But they didn't work. (I used the Sept 4 > patch on CURRENT.) > > I could provide more diagnostics if anyone wants to work to make it work. Stephen, I'm pretty sure that Alexander would appreciate your help and bug reports. So I suggest you to move this discussion to freebsd-multimedia, the list in which the new driver has been discussed. -- cd /usr/ports/sysutils/life make clean From chih.liang at ipeen.com.tw Fri Sep 5 01:42:16 2008 From: chih.liang at ipeen.com.tw (Chih Liang) Date: Fri Sep 5 01:42:23 2008 Subject: boot failed after make installkernel from 6.3-RELEASE to 7.0-RELEASE In-Reply-To: <48BFCB88.9050505@kkip.pl> References: <48BFC40C.3050309@ipeen.com.tw> <48BFCB88.9050505@kkip.pl> Message-ID: <48C08E6C.7010408@ipeen.com.tw> Bartosz Stec wrote: > Chih Liang pisze: >> Dear all, >> >> I've tried to upgrade my FreeBSD server from 6.3-RELEASE to >> 7.0-RELEASE, but it is failed to boot after make kernel >> KERNCONF=GENERIC. >> I didn't modify any file at /usr/src/sys/i386/conf, it was all default. >> After done make kernel and reboot, system stop at: >> >> Timecounters tick every 1.000 msec >> ad0: 38166MB at ata0-master UDMA100 >> >> I can't boot in single mode, but I can boot in safe mode, and it showed: >> >> Manual root filesystem specification: >> : Mount using filesystem >> eg. ufs:da0s1a >> ? List valid disk boot devices >> Abort manual input >> >> I type "?" for list, but it only show acd0 and fdc0, "ufs:ad0s1a" or >> "ufs:/dev/ad0s1a" are not working >> >> I can boot with /boot/kernel.old now (6.3-RELEASE), I rebuilt kernel >> again and again, but still not work. >> I check the difference between old GENERIC on 6.3-RELEASE and new >> GENERIC on 7.0-RELEASE, it has not difference besides new add in >> 7.0-RELEASE. >> >> Is any one can help me? I don't want to reinstall...because I don't >> have install cd... >> >> And sorry for my poor English, thank you for reading! >> >> Regards, >> Chih Liang >> _______________________________________________ >> 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" > Did you make buildworld before buildkernel? If not, boot kernel.old > ane follow these rules: > > 1. csup 7-stable sources (just to be sure) > 2. rm -fR /usr/obj (just to be sure again) > 3. make buildworld && make buildkernel KERNCONF=GENERIC > 4. make installkernel > 5. reboot in single user mode > 6. mergemaster -p > 7. make installworld > 8. mergemaster > 9. make delete-old > 10. make delete-old-libs > > Good luck! > Yes I did. I tried to update source to 7.1, but it failed with the same problem, then I thought it is the bug at -STABLE. And I remove entire /usr/src and /usr/obj and update source to 7.0 again, but still failed when I boot after make buildworld and make kernel. Thanks! From chih.liang at ipeen.com.tw Fri Sep 5 01:47:53 2008 From: chih.liang at ipeen.com.tw (Chih Liang) Date: Fri Sep 5 01:47:59 2008 Subject: boot failed after make installkernel from 6.3-RELEASE to 7.0-RELEASE Message-ID: <48C08FBF.1090809@ipeen.com.tw> Jeff Dowsley wrote: > Try selecting boot option 2, ACPI disabled It still stop with "mountroot" message. Thanks! From chih.liang at ipeen.com.tw Fri Sep 5 01:51:14 2008 From: chih.liang at ipeen.com.tw (Chih Liang) Date: Fri Sep 5 01:51:21 2008 Subject: boot failed after make installkernel from 6.3-RELEASE to 7.0-RELEASE In-Reply-To: <48BFD461.6070606@quip.cz> References: <48BFC40C.3050309@ipeen.com.tw> <48BFD461.6070606@quip.cz> Message-ID: <48C09087.2030205@ipeen.com.tw> Miroslav Lachman ??: > Chih Liang wrote: > >> Dear all, >> >> I've tried to upgrade my FreeBSD server from 6.3-RELEASE to >> 7.0-RELEASE, but it is failed to boot after make kernel >> KERNCONF=GENERIC. >> I didn't modify any file at /usr/src/sys/i386/conf, it was all default. >> After done make kernel and reboot, system stop at: >> >> Timecounters tick every 1.000 msec >> ad0: 38166MB at ata0-master UDMA100 >> >> I can't boot in single mode, but I can boot in safe mode, and it showed: >> >> Manual root filesystem specification: >> : Mount using filesystem >> eg. ufs:da0s1a >> ? List valid disk boot devices >> Abort manual input >> >> I type "?" for list, but it only show acd0 and fdc0, "ufs:ad0s1a" or >> "ufs:/dev/ad0s1a" are not working >> >> I can boot with /boot/kernel.old now (6.3-RELEASE), I rebuilt kernel >> again and again, but still not work. >> I check the difference between old GENERIC on 6.3-RELEASE and new >> GENERIC on 7.0-RELEASE, it has not difference besides new add in >> 7.0-RELEASE. >> >> Is any one can help me? I don't want to reinstall...because I don't >> have install cd... >> >> And sorry for my poor English, thank you for reading! > > What is your hardware setup? (post dmesg) > > I have bad experience with some old PC with nForce 2 chipset. This > machine is unbootable with 7.x kernel, so I am using it with 6.3. (it > can't boot even from 7.x CD) > > Miroslav Lachman > Here is my /var/run/dmesg.boot: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.3-RELEASE-p3 #0: Wed Sep 3 15:58:00 CST 2008 root@daxiongb:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (801.83-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x631 Stepping = 1 Features=0x183f9ff AMD Features=0xc0440800,MMX+,3DNow!+,3DNow!> real memory = 335478784 (319 MB) avail memory = 318791680 (304 MB) kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Sep 3 2008 15:57:08) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe0000000-0xe0ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 7.1 on pci0 ata0: on atapci0 ata1: on atapci0 uhci0: port 0xd400-0xd41f irq 12 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xd800-0xd81f irq 12 at device 7.3 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at device 7.4 (no driver attached) rl0: port 0xd000-0xd0ff mem 0xdfffff00-0xdfffffff irq 9 at device 13.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:40:c7:81:90:ca pci0: at device 14.0 (no driver attached) acpi_button1: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f,0x778-0x77b 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 ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff 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 Timecounter "TSC" frequency 801825289 Hz quality 800 Timecounters tick every 1.000 msec hptrr: no controller detected. ad0: 39266MB at ata0-master UDMA66 acd0: CDRW at ata1-slave UDMA33 Trying to mount root from ufs:/dev/ad0s1a rl0: link state changed to UP Is it the VIA chipset? From wxs at FreeBSD.org Fri Sep 5 02:01:48 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Fri Sep 5 02:01:58 2008 Subject: ports from -release vs. -latest [was: RE: FreeBSD 7.1 Content] In-Reply-To: <000001c90ecd$207cbca0$2101a8c0@asinusaureus> References: <20080904160211.927EF10657BF@hub.freebsd.org> <000001c90ecd$207cbca0$2101a8c0@asinusaureus> Message-ID: <20080905020231.GI1188@atarininja.org> On Thu, Sep 04, 2008 at 10:30:49PM +0200, Ernest Sales wrote: > I use to update ports almost weekly from -latest, but the resulting GUI is > not always consistent, so I am considering to stick with the -release tag. > Could someone comment on the quality of ports from -release vs. -latest? In > other words, can I expect a substantial gain in usability by doing so? The ports tree is not branched like the src tree. If you want any updates you get the latest. The ports tree as presented on the install media is merely a snapshot of the tree at that point in time. If you only use that tree you will never receive updates. If that tree works well for you and you don't care about updates of any kind then go ahead and stick on that tree. Personally, I want updates to some important (to me) pieces of software so I do keep things updated. Please do not take this as an opportunity to bring up the "we should use a branched approach to ports" discussion. That's been done many times before so look in the archives if you want more information. -- WXS From chih.liang at ipeen.com.tw Fri Sep 5 03:54:32 2008 From: chih.liang at ipeen.com.tw (Chih Liang) Date: Fri Sep 5 03:54:39 2008 Subject: boot failed after make installkernel from 6.3-RELEASE to 7.0-RELEASE In-Reply-To: <48BFD461.6070606@quip.cz> References: <48BFC40C.3050309@ipeen.com.tw> <48BFD461.6070606@quip.cz> Message-ID: <48C0AD6D.70809@ipeen.com.tw> Miroslav Lachman wrote: > > What is your hardware setup? (post dmesg) > > I have bad experience with some old PC with nForce 2 chipset. This > machine is unbootable with 7.x kernel, so I am using it with 6.3. (it > can't boot even from 7.x CD) > > Miroslav Lachman > I've tried to boot with 7.0 CD, it hung again...then I reboot with ACPI disabled, it could be boot but said can't find the disk. So I think this PC maybe with too old chipset. Anyway, thanks a lot. From pyunyh at gmail.com Fri Sep 5 05:35:06 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Sep 5 05:35:18 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <48C02768.1080207@math.missouri.edu> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <1220545795.94705.15.camel@buffy.york.ac.uk> <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> <1220550536.94705.18.camel@buffy.york.ac.uk> <48C02768.1080207@math.missouri.edu> Message-ID: <20080905053455.GD65464@cdnetworks.co.kr> On Thu, Sep 04, 2008 at 01:22:32PM -0500, Stephen Montgomery-Smith wrote: > Gavin Atkinson wrote: > >On Thu, 2008-09-04 at 11:32 -0600, Dan Allen wrote: > >>On 4 Sep 2008, at 10:29 AM, Gavin Atkinson wrote: > >> > >>>This is supported by the iwn(4) driver in CURRENT, and it should be > >>>quite easy to port the driver to 7-STABLE. If you're interested in > >>>reinstalling FreeBSD and testing a backported driver, I'm sure this > >>>can be sorted. > >>I am interested in doing this. Please advise on how I can get these > >>bits. > > > >I've got hold of a laptop with the 4965 chipset in it, if nobody beats > >me to it I'll have a go at backporting the driver. > > I have a Dell Inspiron 1525 with the intel wireless ethernet. > > The iwn driver in CURRENT works well. > > The http://people.freebsd.org/~yongari/msk/msk.88E8040.patch patch for > the 88E8040 simply doesn't work. It is not because of lack of testing > (which I have performed for Pyun who wrote the patch), but apparently > because of lack of reliable documentation. There is a driver for Another problem is lack of hardware. 88E8040 seems to be intialized after applying the patch but link establishment seem to fail. :-( > FreeBSD on the Marvell web site, which did work for me, but I am told it > is unreliable. > > I also have had a hard time getting the sound to work. The oss port > does work, but has a habit of freezing up. -- Regards, Pyun YongHyeon From koitsu at FreeBSD.org Fri Sep 5 05:54:24 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 5 05:54:33 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <20080905053455.GD65464@cdnetworks.co.kr> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <1220545795.94705.15.camel@buffy.york.ac.uk> <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> <1220550536.94705.18.camel@buffy.york.ac.uk> <48C02768.1080207@math.missouri.edu> <20080905053455.GD65464@cdnetworks.co.kr> Message-ID: <20080905055423.GA37775@icarus.home.lan> On Fri, Sep 05, 2008 at 02:34:55PM +0900, Pyun YongHyeon wrote: > On Thu, Sep 04, 2008 at 01:22:32PM -0500, Stephen Montgomery-Smith wrote: > > Gavin Atkinson wrote: > > >On Thu, 2008-09-04 at 11:32 -0600, Dan Allen wrote: > > >>On 4 Sep 2008, at 10:29 AM, Gavin Atkinson wrote: > > >> > > >>>This is supported by the iwn(4) driver in CURRENT, and it should be > > >>>quite easy to port the driver to 7-STABLE. If you're interested in > > >>>reinstalling FreeBSD and testing a backported driver, I'm sure this > > >>>can be sorted. > > >>I am interested in doing this. Please advise on how I can get these > > >>bits. > > > > > >I've got hold of a laptop with the 4965 chipset in it, if nobody beats > > >me to it I'll have a go at backporting the driver. > > > > I have a Dell Inspiron 1525 with the intel wireless ethernet. > > > > The iwn driver in CURRENT works well. > > > > The http://people.freebsd.org/~yongari/msk/msk.88E8040.patch patch for > > the 88E8040 simply doesn't work. It is not because of lack of testing > > (which I have performed for Pyun who wrote the patch), but apparently > > because of lack of reliable documentation. There is a driver for > > Another problem is lack of hardware. 88E8040 seems to be intialized > after applying the patch but link establishment seem to fail. :-( Yong-Hyeon, I can purchase and send you a Marvel 88E8040 NIC, assuming we can find a PCI or PCIe card somewhere that uses one. Otherwise, I could purchase a motherboard which uses the IC and send that to you. Let me know if this would be of any help! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From pyunyh at gmail.com Fri Sep 5 06:06:50 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Sep 5 06:06:57 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <20080905055423.GA37775@icarus.home.lan> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <1220545795.94705.15.camel@buffy.york.ac.uk> <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> <1220550536.94705.18.camel@buffy.york.ac.uk> <48C02768.1080207@math.missouri.edu> <20080905053455.GD65464@cdnetworks.co.kr> <20080905055423.GA37775@icarus.home.lan> Message-ID: <20080905060642.GF65464@cdnetworks.co.kr> On Thu, Sep 04, 2008 at 10:54:23PM -0700, Jeremy Chadwick wrote: > On Fri, Sep 05, 2008 at 02:34:55PM +0900, Pyun YongHyeon wrote: > > On Thu, Sep 04, 2008 at 01:22:32PM -0500, Stephen Montgomery-Smith wrote: > > > Gavin Atkinson wrote: > > > >On Thu, 2008-09-04 at 11:32 -0600, Dan Allen wrote: > > > >>On 4 Sep 2008, at 10:29 AM, Gavin Atkinson wrote: > > > >> > > > >>>This is supported by the iwn(4) driver in CURRENT, and it should be > > > >>>quite easy to port the driver to 7-STABLE. If you're interested in > > > >>>reinstalling FreeBSD and testing a backported driver, I'm sure this > > > >>>can be sorted. > > > >>I am interested in doing this. Please advise on how I can get these > > > >>bits. > > > > > > > >I've got hold of a laptop with the 4965 chipset in it, if nobody beats > > > >me to it I'll have a go at backporting the driver. > > > > > > I have a Dell Inspiron 1525 with the intel wireless ethernet. > > > > > > The iwn driver in CURRENT works well. > > > > > > The http://people.freebsd.org/~yongari/msk/msk.88E8040.patch patch for > > > the 88E8040 simply doesn't work. It is not because of lack of testing > > > (which I have performed for Pyun who wrote the patch), but apparently > > > because of lack of reliable documentation. There is a driver for > > > > Another problem is lack of hardware. 88E8040 seems to be intialized > > after applying the patch but link establishment seem to fail. :-( > > Yong-Hyeon, > :-) > I can purchase and send you a Marvel 88E8040 NIC, assuming we can find a > PCI or PCIe card somewhere that uses one. Otherwise, I could purchase a > motherboard which uses the IC and send that to you. > I failed to find a standalone PCI/PCIe NIC based on 88E8040 controller in local store. > Let me know if this would be of any help! > Having a hardware surely helps a lot! -- Regards, Pyun YongHyeon From admin at kkip.pl Fri Sep 5 06:22:54 2008 From: admin at kkip.pl (Bartosz Stec) Date: Fri Sep 5 06:23:01 2008 Subject: boot failed after make installkernel from 6.3-RELEASE to 7.0-RELEASE In-Reply-To: <48C0AD6D.70809@ipeen.com.tw> References: <48BFC40C.3050309@ipeen.com.tw> <48BFD461.6070606@quip.cz> <48C0AD6D.70809@ipeen.com.tw> Message-ID: <48C0D03B.8070804@kkip.pl> Chih Liang pisze: > Miroslav Lachman wrote: >> >> What is your hardware setup? (post dmesg) >> >> I have bad experience with some old PC with nForce 2 chipset. This >> machine is unbootable with 7.x kernel, so I am using it with 6.3. (it >> can't boot even from 7.x CD) >> >> Miroslav Lachman >> > > I've tried to boot with 7.0 CD, it hung again...then I reboot with > ACPI disabled, it could be boot but said can't find the disk. So I > think this PC maybe with too old chipset. > Anyway, thanks a lot. Well, it's VIA chipset you have, not nForce2 - . And it's not too old to run 7.0 as far as I know. It's strange that kernel has some problem with your hardware. Maybe you have buggy BIOS? Try to update to newest one and/or at least load BIOS safe-defaults. Then you should try to boot with and without ACPI enabled. Adding the following line to /boot/device.hints: hint.acpi.0.disabled="1" may help if your system won't boot with ACPI enabled. Don't give up yet! :) -- Bartosz Stec - specjalista ds. IT AUXILIA Sp??ka z o.o. From jlm at caamora.com.au Fri Sep 5 06:37:35 2008 From: jlm at caamora.com.au (jonathan michaels) Date: Fri Sep 5 06:37:42 2008 Subject: boot failed after make installkernel from 6.3-RELEASE to 7.0-RELEASE In-Reply-To: <48C0AD6D.70809@ipeen.com.tw>; from Chih Liang on Fri, Sep 05, 2008 at 11:54:21AM +0800 References: <48BFC40C.3050309@ipeen.com.tw> <48BFD461.6070606@quip.cz> <48C0AD6D.70809@ipeen.com.tw> Message-ID: <20080905161124.53699@caamora.com.au> On Fri, Sep 05, 2008 at 11:54:21AM +0800, Chih Liang wrote: > Miroslav Lachman wrote: > > > > What is your hardware setup? (post dmesg) > > > > I have bad experience with some old PC with nForce 2 chipset. This > > machine is unbootable with 7.x kernel, so I am using it with 6.3. (it > > can't boot even from 7.x CD) > > > > Miroslav Lachman > > > > I've tried to boot with 7.0 CD, it hung again...then I reboot with ACPI > disabled, it could be boot but said can't find the disk. So I think this > PC maybe with too old chipset. > Anyway, thanks a lot. i have an amd athlon with an nvidia video card that freebsd v7.0-RELEASE locks the last thing mine says is hptrr (there is something about rocketraid raid device in teh dmesg) "no device found' if i disable acpi (by booting in safe mode) all works well the installation completes, the machine works well at least so far ... hope this helps regards jonathan -- ================================================================ powered by .. QNX, OS9 and freeBSD -- http://caamora com au/operating system ==== === appropriate solution in an inappropriate world === ==== From mav at mavhome.dp.ua Fri Sep 5 09:24:09 2008 From: mav at mavhome.dp.ua (Alexander Motin) Date: Fri Sep 5 09:25:49 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <1220581380.00009504.1220568001@10.7.7.3> References: <1220478861.00008786.1220467203@10.7.7.3> <1220480589.00008846.1220469605@10.7.7.3> <1220556187.00009295.1220543401@10.7.7.3> <1220559781.00009317.1220546402@10.7.7.3> <1220563382.00009338.1220550001@10.7.7.3> <1220563384.00009347.1220550601@10.7.7.3> <1220565324.00009371.1220554803@10.7.7.3> <1220566985.00009381.1220556006@10.7.7.3> <1220581380.00009504.1220568001@10.7.7.3> Message-ID: <48C0ECA6.9090800@mavhome.dp.ua> Stephen Montgomery-Smith wrote: >> Did you try using Alexander Motin's new snd_hda patches? They are >> available at >> >> http://people.freebsd.org/~mav/ > > Thanks. I hadn't tried them. But they didn't work. (I used the Sept 4 > patch on CURRENT.) > > I could provide more diagnostics if anyone wants to work to make it work. Send me 'cat /dev/sndstat' and verbose dmesg output of the patched driver. There are many possible reasons of this "didn't work" including hardware specific hardware implementation and broken BIOS configuration. But many of them could be diagnosed by reading of verbose dmesg and fixed by specifying device hints. -- Alexander Motin From koitsu at FreeBSD.org Fri Sep 5 09:26:35 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 5 09:26:42 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <20080905060642.GF65464@cdnetworks.co.kr> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <1220545795.94705.15.camel@buffy.york.ac.uk> <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> <1220550536.94705.18.camel@buffy.york.ac.uk> <48C02768.1080207@math.missouri.edu> <20080905053455.GD65464@cdnetworks.co.kr> <20080905055423.GA37775@icarus.home.lan> <20080905060642.GF65464@cdnetworks.co.kr> Message-ID: <20080905092633.GA53234@icarus.home.lan> On Fri, Sep 05, 2008 at 03:06:42PM +0900, Pyun YongHyeon wrote: > On Thu, Sep 04, 2008 at 10:54:23PM -0700, Jeremy Chadwick wrote: > > On Fri, Sep 05, 2008 at 02:34:55PM +0900, Pyun YongHyeon wrote: > > > On Thu, Sep 04, 2008 at 01:22:32PM -0500, Stephen Montgomery-Smith wrote: > > > > The http://people.freebsd.org/~yongari/msk/msk.88E8040.patch patch for > > > > the 88E8040 simply doesn't work. It is not because of lack of testing > > > > (which I have performed for Pyun who wrote the patch), but apparently > > > > because of lack of reliable documentation. There is a driver for > > > > > > Another problem is lack of hardware. 88E8040 seems to be intialized > > > after applying the patch but link establishment seem to fail. :-( > > > I can purchase and send you a Marvel 88E8040 NIC, assuming we can find a > > PCI or PCIe card somewhere that uses one. Otherwise, I could purchase a > > motherboard which uses the IC and send that to you. > > > > I failed to find a standalone PCI/PCIe NIC based on 88E8040 > controller in local store. I'll look around, and if I can't find anything, contact Marvell asking which of their clients use their 88E8040 in standalone PCI/PCIe NICs. If push comes to shove, I'll pick up a motherboard that has the 88E8040 on it and ship it to you free of cost. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From tevans.uk at googlemail.com Fri Sep 5 10:09:07 2008 From: tevans.uk at googlemail.com (Tom Evans) Date: Fri Sep 5 10:09:14 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <650D6892-6372-44A2-957F-B049E70DB881@airwired.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <48BEEB55.4050406@madpilot.net> <20080904062053.GA5953@icarus.home.lan> <650D6892-6372-44A2-957F-B049E70DB881@airwired.net> Message-ID: <1220609335.3846.6.camel@localhost> On Thu, 2008-09-04 at 08:45 -0600, Dan Allen wrote: > On 4 Sep 2008, at 12:20 AM, Jeremy Chadwick wrote: ... > It was using Ubuntu that caused me to realize how far behind FreeBSD > is on the desktop side, and how, with a SMALL AMOUNT of work and > changes, it could make a big jump forward by this proposed simple > addition. Heck, if nothing else the installer could simply say in a > help screen, "if you want a web browser on your system, type 'pkg_add - > r firefox' on your system and edit blah blah .conf blah". As it > stands right now, however, there is very little in the install process > which helps a user get X up and going with a browser. > > Thanks to everyone else for their comments. > > Dan (this isn't meant to be a flame :) For me, part of the install process was reading the handbook, which details quite clearly how to go from sysinstall to desktop. Projects driven by billionaire South Africans can target their paid developers at whatever tasks they think are important. It seems very few FreeBSD devs are interested enough to attack this 'small amount' of work, and that is their (valid) choice*. In a volunteer project, volunteers work on what interests them, not what someone else thinks is important. Cheers Tom * although check out finstall.sf.net, which looks as though it will be very good. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080905/d38b57a5/attachment.pgp From kais.deliverymail at googlemail.com Fri Sep 5 11:41:36 2008 From: kais.deliverymail at googlemail.com (Kai Otto) Date: Fri Sep 5 11:41:45 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: <69919f4a0809050423r554105a1jd3f1233a1fbbc9ab@mail.gmail.com> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <48BEEB55.4050406@madpilot.net> <20080904062053.GA5953@icarus.home.lan> <650D6892-6372-44A2-957F-B049E70DB881@airwired.net> <1220609335.3846.6.camel@localhost> <69919f4a0809050423r554105a1jd3f1233a1fbbc9ab@mail.gmail.com> Message-ID: <69919f4a0809050424n374cea16rb194b04ad55cd59d@mail.gmail.com> ---------- Forwarded message ---------- From: Kai Otto Date: 2008/9/5 Subject: Re: FreeBSD 7.1 Content To: Tom Evans Hello I think someone mentioned it earlier, but I'm not shure. IMHO it would _be_ nice if there's a HTML-browser in the standard installation (with option to not install it in sysinstall). I say HTML and not web because I think about the /usr/share/doc .html-documentation. If someone really has no Internet-connection as mentioned before he/she isn't able to read the handbook, which IMHO is a very important part of FreeBSD. There are great manpages and exaple files, but the best explanations are in the handbook. Optional, the motd could tell the interested newbie how he/she can start reading the handbook. At the moment, the standard motd explains how to learn about manpages ('man man') and how to learn about the disklayout ('man hier') that's just great. An other way would be adding a hint to the shipped htmlbrowser (eg. lynx) and it's initialisation with the handbook to the hier manpage. I don't know if thats to 'deep hidden'. An other thing was the problem with the outdated packages on the discset and the people who need it because the 'target pc' for the install has no (or only slow) internetconnection. I think this is already solved: People needing up-to-date packages/ports can use the 'bootonly' iso-images and download the complete installation from a local or internet server. The other people can use the not-100%-up-to-date packages on the discset. Greets, Kai From admin at kkip.pl Fri Sep 5 13:12:17 2008 From: admin at kkip.pl (Bartosz Stec) Date: Fri Sep 5 13:12:39 2008 Subject: Funny things with cflags and world/kernel building Message-ID: <48C1302C.2040109@kkip.pl> As well as i know variables works this way: # set foo=bar # set | grep foo _ set foo=bar foo bar # echo $foo bar # echo ${foo} bar So maybe someone could explain me why following things happens with variables in make.conf? My make.conf: CPUTYPE=athlon64 MAKEOPTS=-j3 # USE CCACHE .if !defined(NOCCACHE) CC=/usr/local/libexec/ccache/world-cc CXX=/usr/local/libexec/ccache/world-c++ .endif # default build settings for ports collection .if ${.CURDIR:M*/ports/*} CFLAGS= -O2 -fno-strict-aliasing -pipe -funroll-loops -fomit-frame-pointer CXXFLAGS= -O2 -fno-strict-aliasing -pipe -funroll-loops .endif # default build settings for base system .if ${.CURDIR:M*/usr/src/*} || ${.CURDIR:M*/usr/obj/*} CFLAGS=-O2 -fno-strict-aliasing -pipe #CXXFLAGS=-O2 -fno-strict-aliasing -pipe COPTFLAGS=-O2 -fno-strict-aliasing -pipe CXXFLAGS=${CFLAGS} #COPTFLAGS=${CFLAGS} .endif # added by use.perl 2008-04-14 10:39:38 PERL_VER=5.8.8 PERL_VERSION=5.8.8 As you see I use ccache and different flags for world and port building, but what's interesting: 1. when I use these flags: CFLAGS=-O2 -fno-strict-aliasing -pipe CXXFLAGS=${CFLAGS} COPTFLAGS=${CFLAGS} world building finish without problem, but making kernel give an error: -------------------------------------------------------------- >>> stage 3.1: making dependencies -------------------------------------------------------------- cd /usr/obj/usr/src/sys/AMD64SMP7; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE=athlon64 GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 7.1-PRERELEASE amd64 700112" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin NO_CTF=1 make KERNEL=kernel depend -DNO_MODULES_OBJ machine -> /usr/src/sys/amd64/include Variable CFLAGS is recursive. *** Error code 2 Stop in /usr/src. *** Error code 1 Stop in /usr/src. 2. When I use these flags: CFLAGS=-O2 -fno-strict-aliasing -pipe CXXFLAGS=-O2 -fno-strict-aliasing -pipe COPTFLAGS=-O2 -fno-strict-aliasing -pipe kernel build finish without problem, but... building world give an error!: ===> gnu/lib/libstdc++ (depend) ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/cpu/generic/ atomicity_builtins/atomicity.h atomicity.cc ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/gcc/unwind-generic.h unwind.h rm -f .depend (...) /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41: 20: error: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libs upc++/vec.cc:37: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41: 20: error: unwind.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/gnu/lib/libstdc++. *** Error code 1 Stop in /usr/src/gnu/lib. *** Error code 1 3. What's even more funny? When I use flags: CFLAGS=-O2 -fno-strict-aliasing -pipe COPTFLAGS=-O2 -fno-strict-aliasing -pipe CXXFLAGS=${CFLAGS} I have no errors at all! But shouldn't all those flags be treated by make command exactly the same way?? It isn't new issue - it's couple of months as I face this problem - on AMD 64 machine with CPUTYPE=athlon64 and MAKEOPTS=-j3 and olso on i386 machine with CPUTYPE=pentium2 and MAKEOPTS=-j2. Other flags are the same as in the beginning of this message. Another machine - exactly the same flags but CPUTYPE=athlon-tbird and MAKEOPTS=-j2 and no problems compiling world and kernel regardless of flags combination. Could anyone explain to me sthis trange behaviour ? p.s. Sorry for my poor english ;) -- Bartosz Stec - specjalista ds. IT AUXILIA Sp??ka z o.o. From marck at rinet.ru Fri Sep 5 13:41:35 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Fri Sep 5 13:41:42 2008 Subject: RELENG_7/amd64: booting from gpt failed. In-Reply-To: <20080902204047.K27579@woozle.rinet.ru> References: <20080902204047.K27579@woozle.rinet.ru> Message-ID: On Tue, 2 Sep 2008, Dmitry Morozovsky wrote: [snip] DM> and I hope it boots from da0p2, but it fails: Pilot error; rebuilding fresh RELENG_7 from scratch and reinstall fixed the issue; now I'm almost happy with new 4-core builder/tinderbox with ZFS over gpt. ;) Sorry for the noise. Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From mail25 at bzerk.org Fri Sep 5 14:36:56 2008 From: mail25 at bzerk.org (Ruben de Groot) Date: Fri Sep 5 14:37:03 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: <69919f4a0809050424n374cea16rb194b04ad55cd59d@mail.gmail.com> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <48BEEB55.4050406@madpilot.net> <20080904062053.GA5953@icarus.home.lan> <650D6892-6372-44A2-957F-B049E70DB881@airwired.net> <1220609335.3846.6.camel@localhost> <69919f4a0809050423r554105a1jd3f1233a1fbbc9ab@mail.gmail.com> <69919f4a0809050424n374cea16rb194b04ad55cd59d@mail.gmail.com> Message-ID: <20080905140214.GA28789@ei.bzerk.org> On Fri, Sep 05, 2008 at 01:24:49PM +0200, Kai Otto typed: > > I think someone mentioned it earlier, but I'm not shure. > IMHO it would _be_ nice if there's a HTML-browser in the standard > installation (with option to not install it in sysinstall). > I say HTML and not web because I think about the /usr/share/doc > .html-documentation. If someone really has no Internet-connection as > mentioned before he/she isn't able to read the handbook, which IMHO is a > very important part of FreeBSD. There are great manpages and exaple files, > but the best explanations are in the handbook. Isn't that why we have: /usr/share/doc/handbook/book.txt ?? Ruben From lyebeng_ong at yahoo.com Fri Sep 5 17:41:14 2008 From: lyebeng_ong at yahoo.com (LB Ong) Date: Fri Sep 5 17:41:21 2008 Subject: raidz pool metadata corrupted nexanta-core->freenas 0.7->nexanta-core Message-ID: <454176.13423.qm@web33905.mail.mud.yahoo.com> I made a bad judgment and now my raidz pool is corrupted. I have a raidz pool running on Opensolaris b85. I wanted to try out freenas 0.7 and tried to add my pool to freenas. After adding the zfs disk, vdev and pool. I decided to back out and went back to opensolaris. Now my raidz pool will not mount and got the following errors. Hope someone expert can help me recover from this error. root@cempedak:/dev/rdsk# zpool status pool: syspool state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM syspool ONLINE 0 0 0 c1d0s0 ONLINE 0 0 0 errors: No known data errors pool: tank state: FAULTED status: The pool metadata is corrupted and the pool cannot be opened. action: Destroy and re-create the pool from a backup source. see: http://www.sun.com/msg/ZFS-8000-72 scrub: none requested config: NAME STATE READ WRITE CKSUM tank FAULTED 0 0 4 corrupted data raidz1 ONLINE 0 0 4 c2d0 ONLINE 0 0 0 c2d1 ONLINE 0 0 0 c3d0 ONLINE 0 0 0 c3d1 ONLINE 0 0 0 root@cempedak:/dev/rdsk# root@cempedak:/dev/rdsk# zdb -vvv syspool version=10 name='syspool' state=0 txg=13 pool_guid=7417064082496892875 hostname='elatte_installcd' vdev_tree type='root' id=0 guid=7417064082496892875 children[0] type='disk' id=0 guid=16996723219710622372 path='/dev/dsk/c1d0s0' devid='id1,cmdk@AST3160812AS=____________9LS6M819/a' phys_path='/pci@0,0/pci-ide@e/ide@0/cmdk@0,0:a' whole_disk=0 metaslab_array=14 metaslab_shift=30 ashift=9 asize=158882856960 is_log=0 tank version=10 name='tank' state=0 txg=9305484 pool_guid=6165551123815947851 hostname='cempedak' vdev_tree type='root' id=0 guid=6165551123815947851 children[0] type='raidz' id=0 guid=18029757455913565148 nparity=1 metaslab_array=14 metaslab_shift=33 ashift=9 asize=1280228458496 is_log=0 children[0] type='disk' id=0 guid=14740261559114907785 path='/dev/dsk/c2d0s0' devid='id1,cmdk@AST3320620AS=____________3QF0WLTV/a' phys_path='/pci@0,0/pci10de,26f@10/pci-ide@8/ide@0/cmdk@0,0:a' whole_disk=1 children[1] type='disk' id=1 guid=7618479640615121644 path='/dev/dsk/c2d1s0' devid='id1,cmdk@AST3320620AS=____________3QF0YZEM/a' phys_path='/pci@0,0/pci10de,26f@10/pci-ide@8/ide@0/cmdk@1,0:a' whole_disk=1 children[2] type='disk' id=2 guid=1801493855297946488 path='/dev/dsk/c3d0s0' devid='id1,cmdk@AST3320620AS=____________3QF0PGBS/a' phys_path='/pci@0,0/pci10de,26f@10/pci-ide@8/ide@1/cmdk@0,0:a' whole_disk=1 children[3] type='disk' id=3 guid=15710901655082836445 path='/dev/dsk/c3d1s0' devid='id1,cmdk@AST3320620AS=____________3QF0VABG/a' phys_path='/pci@0,0/pci10de,26f@10/pci-ide@8/ide@1/cmdk@1,0:a' whole_disk=1 root@cempedak:/dev/rdsk# root@cempedak:/dev/rdsk# zdb -l /dev/rdsk/c2d0 -------------------------------------------- LABEL 0 -------------------------------------------- version=6 name='tank' state=2 txg=14 pool_guid=11155694179612409655 hostid=0 hostname='cempedak.local' top_guid=17207490567963887885 guid=15107016125503765553 vdev_tree type='raidz' id=0 guid=17207490567963887885 nparity=1 metaslab_array=14 metaslab_shift=33 ashift=9 asize=1280272498688 children[0] type='disk' id=0 guid=550142777835149292 path='/dev/ad10' devid='ad:3QF0PGBS' whole_disk=0 children[1] type='disk' id=1 guid=11315967116113415008 path='/dev/ad12' devid='ad:3QF0YZEM' whole_disk=0 children[2] type='disk' id=2 guid=4506299097155628566 path='/dev/ad14' devid='ad:3QF0VABG' whole_disk=0 children[3] type='disk' id=3 guid=15107016125503765553 path='/dev/ad8' devid='ad:3QF0WLTV' whole_disk=0 -------------------------------------------- LABEL 1 -------------------------------------------- version=6 name='tank' state=2 txg=14 pool_guid=11155694179612409655 hostid=0 hostname='cempedak.local' top_guid=17207490567963887885 guid=15107016125503765553 vdev_tree type='raidz' id=0 guid=17207490567963887885 nparity=1 metaslab_array=14 metaslab_shift=33 ashift=9 asize=1280272498688 children[0] type='disk' id=0 guid=550142777835149292 path='/dev/ad10' devid='ad:3QF0PGBS' whole_disk=0 children[1] type='disk' id=1 guid=11315967116113415008 path='/dev/ad12' devid='ad:3QF0YZEM' whole_disk=0 children[2] type='disk' id=2 guid=4506299097155628566 path='/dev/ad14' devid='ad:3QF0VABG' whole_disk=0 children[3] type='disk' id=3 guid=15107016125503765553 path='/dev/ad8' devid='ad:3QF0WLTV' whole_disk=0 -------------------------------------------- LABEL 2 -------------------------------------------- failed to unpack label 2 -------------------------------------------- LABEL 3 -------------------------------------------- failed to unpack label 3 root@cempedak:/dev/rdsk# root@cempedak:/dev/rdsk# zdb -l /dev/rdsk/c2d1 -------------------------------------------- LABEL 0 -------------------------------------------- version=6 name='tank' state=2 txg=14 pool_guid=11155694179612409655 hostid=0 hostname='cempedak.local' top_guid=17207490567963887885 guid=11315967116113415008 vdev_tree type='raidz' id=0 guid=17207490567963887885 nparity=1 metaslab_array=14 metaslab_shift=33 ashift=9 asize=1280272498688 children[0] type='disk' id=0 guid=550142777835149292 path='/dev/ad10' devid='ad:3QF0PGBS' whole_disk=0 children[1] type='disk' id=1 guid=11315967116113415008 path='/dev/ad12' devid='ad:3QF0YZEM' whole_disk=0 children[2] type='disk' id=2 guid=4506299097155628566 path='/dev/ad14' devid='ad:3QF0VABG' whole_disk=0 children[3] type='disk' id=3 guid=15107016125503765553 path='/dev/ad8' devid='ad:3QF0WLTV' whole_disk=0 -------------------------------------------- LABEL 1 -------------------------------------------- version=6 name='tank' state=2 txg=14 pool_guid=11155694179612409655 hostid=0 hostname='cempedak.local' top_guid=17207490567963887885 guid=11315967116113415008 vdev_tree type='raidz' id=0 guid=17207490567963887885 nparity=1 metaslab_array=14 metaslab_shift=33 ashift=9 asize=1280272498688 children[0] type='disk' id=0 guid=550142777835149292 path='/dev/ad10' devid='ad:3QF0PGBS' whole_disk=0 children[1] type='disk' id=1 guid=11315967116113415008 path='/dev/ad12' devid='ad:3QF0YZEM' whole_disk=0 children[2] type='disk' id=2 guid=4506299097155628566 path='/dev/ad14' devid='ad:3QF0VABG' whole_disk=0 children[3] type='disk' id=3 guid=15107016125503765553 path='/dev/ad8' devid='ad:3QF0WLTV' whole_disk=0 -------------------------------------------- LABEL 2 -------------------------------------------- failed to unpack label 2 -------------------------------------------- LABEL 3 -------------------------------------------- failed to unpack label 3 root@cempedak:/dev/rdsk# root@cempedak:/dev/rdsk# zdb -l /dev/rdsk/c3d0 -------------------------------------------- LABEL 0 -------------------------------------------- version=6 name='tank' state=2 txg=14 pool_guid=11155694179612409655 hostid=0 hostname='cempedak.local' top_guid=17207490567963887885 guid=550142777835149292 vdev_tree type='raidz' id=0 guid=17207490567963887885 nparity=1 metaslab_array=14 metaslab_shift=33 ashift=9 asize=1280272498688 children[0] type='disk' id=0 guid=550142777835149292 path='/dev/ad10' devid='ad:3QF0PGBS' whole_disk=0 children[1] type='disk' id=1 guid=11315967116113415008 path='/dev/ad12' devid='ad:3QF0YZEM' whole_disk=0 children[2] type='disk' id=2 guid=4506299097155628566 path='/dev/ad14' devid='ad:3QF0VABG' whole_disk=0 children[3] type='disk' id=3 guid=15107016125503765553 path='/dev/ad8' devid='ad:3QF0WLTV' whole_disk=0 -------------------------------------------- LABEL 1 -------------------------------------------- version=6 name='tank' state=2 txg=14 pool_guid=11155694179612409655 hostid=0 hostname='cempedak.local' top_guid=17207490567963887885 guid=550142777835149292 vdev_tree type='raidz' id=0 guid=17207490567963887885 nparity=1 metaslab_array=14 metaslab_shift=33 ashift=9 asize=1280272498688 children[0] type='disk' id=0 guid=550142777835149292 path='/dev/ad10' devid='ad:3QF0PGBS' whole_disk=0 children[1] type='disk' id=1 guid=11315967116113415008 path='/dev/ad12' devid='ad:3QF0YZEM' whole_disk=0 children[2] type='disk' id=2 guid=4506299097155628566 path='/dev/ad14' devid='ad:3QF0VABG' whole_disk=0 children[3] type='disk' id=3 guid=15107016125503765553 path='/dev/ad8' devid='ad:3QF0WLTV' whole_disk=0 -------------------------------------------- LABEL 2 -------------------------------------------- failed to unpack label 2 -------------------------------------------- LABEL 3 -------------------------------------------- failed to unpack label 3 root@cempedak:/dev/rdsk# root@cempedak:/dev/rdsk# zdb -l /dev/rdsk/c3d1 -------------------------------------------- LABEL 0 -------------------------------------------- version=6 name='tank' state=2 txg=14 pool_guid=11155694179612409655 hostid=0 hostname='cempedak.local' top_guid=17207490567963887885 guid=4506299097155628566 vdev_tree type='raidz' id=0 guid=17207490567963887885 nparity=1 metaslab_array=14 metaslab_shift=33 ashift=9 asize=1280272498688 children[0] type='disk' id=0 guid=550142777835149292 path='/dev/ad10' devid='ad:3QF0PGBS' whole_disk=0 children[1] type='disk' id=1 guid=11315967116113415008 path='/dev/ad12' devid='ad:3QF0YZEM' whole_disk=0 children[2] type='disk' id=2 guid=4506299097155628566 path='/dev/ad14' devid='ad:3QF0VABG' whole_disk=0 children[3] type='disk' id=3 guid=15107016125503765553 path='/dev/ad8' devid='ad:3QF0WLTV' whole_disk=0 -------------------------------------------- LABEL 1 -------------------------------------------- version=6 name='tank' state=2 txg=14 pool_guid=11155694179612409655 hostid=0 hostname='cempedak.local' top_guid=17207490567963887885 guid=4506299097155628566 vdev_tree type='raidz' id=0 guid=17207490567963887885 nparity=1 metaslab_array=14 metaslab_shift=33 ashift=9 asize=1280272498688 children[0] type='disk' id=0 guid=550142777835149292 path='/dev/ad10' devid='ad:3QF0PGBS' whole_disk=0 children[1] type='disk' id=1 guid=11315967116113415008 path='/dev/ad12' devid='ad:3QF0YZEM' whole_disk=0 children[2] type='disk' id=2 guid=4506299097155628566 path='/dev/ad14' devid='ad:3QF0VABG' whole_disk=0 children[3] type='disk' id=3 guid=15107016125503765553 path='/dev/ad8' devid='ad:3QF0WLTV' whole_disk=0 -------------------------------------------- LABEL 2 -------------------------------------------- failed to unpack label 2 -------------------------------------------- LABEL 3 -------------------------------------------- failed to unpack label 3 root@cempedak:/dev/rdsk# From minimarmot at gmail.com Fri Sep 5 20:19:24 2008 From: minimarmot at gmail.com (Ben Kaduk) Date: Fri Sep 5 20:19:31 2008 Subject: Upcoming Releases Schedule... In-Reply-To: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> Message-ID: <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> On Thu, Sep 4, 2008 at 2:40 PM, Jo Rhett wrote: >>>> Where can one find the expected EoL for these releases? > >> On Wed, Sep 03, 2008 at 09:24:04PM -0700, Nathan Way wrote: >>> >>> http://www.freebsd.org/security/security.html#supported-branches >>> To quote from the above web site: (snip) > > On Sep 4, 2008, at 6:36 AM, Wesley Shields wrote: >> >> These are the existing releases. I believe Jo was looking for EoL for >> 7.1 and 6.4 once they are released. > > Yes, thank you. > To quote from the same website: Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. Extended Selected releases will be supported by the Security Officer for a minimum of 24 months after the release. I don't remember seeing any speculation about 6.4 being an extended release, so, EoL is 12 months after release, whenever that actually happens. I thought this was mentioned in the previous thread you started about EoL, but I didn't see it in a quick search. >> The answer to that is not clear - >> nor do I know if it should be clear yet. I don't know when the type of >> support decision is made, but I suspect it's not this early in the >> process. > > > The release date for 6.4 is ~30 days away, isn't it? > > Also given that we've previously seen overlaps such that a newer version is > only supported to the same EoL as the older version, that would pretty much > dictate that spending resources on testing 6.4-REL and/or upgrading would be > futile. > That's the difference between a long-term-support branch and a regular branch; many OSes do that. If you want to run the same machines for a long time and not have to do a huge battery of tests (at the expense of getting new features and better performance in the interim), you use long-term branches. The regular branches that get released later, will then become unsupported at the same time as the (older) long-term branch. Yes, it's poor when a long-term branch goes EoL before there's another one ready to take its place, but if the new one isn't ready, then you just use whichever regular release is current and then snag a long-term release when it becomes available. Yes, it's more work, but that's life. -Ben Kaduk From oberman at es.net Fri Sep 5 21:36:59 2008 From: oberman at es.net (Kevin Oberman) Date: Fri Sep 5 21:37:11 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: Your message of "Fri, 05 Sep 2008 13:24:49 +0200." <69919f4a0809050424n374cea16rb194b04ad55cd59d@mail.gmail.com> Message-ID: <20080905213656.BDB444500F@ptavv.es.net> > Date: Fri, 5 Sep 2008 13:24:49 +0200 > From: "Kai Otto" > Sender: owner-freebsd-stable@freebsd.org > > ---------- Forwarded message ---------- > From: Kai Otto > Date: 2008/9/5 > Subject: Re: FreeBSD 7.1 Content > To: Tom Evans > > > Hello > > I think someone mentioned it earlier, but I'm not shure. > IMHO it would _be_ nice if there's a HTML-browser in the standard > installation (with option to not install it in sysinstall). > I say HTML and not web because I think about the /usr/share/doc > .html-documentation. If someone really has no Internet-connection as > mentioned before he/she isn't able to read the handbook, which IMHO is a > very important part of FreeBSD. There are great manpages and exaple files, > but the best explanations are in the handbook. These days a web browser is almost essential. The question is lynx or links? I prefer links, but lynx is more popular. I hope you don't insist on a GUI. Those things are far too big and require an X install. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080905/c8b11e96/attachment.pgp From koitsu at FreeBSD.org Sat Sep 6 03:43:31 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Sep 6 03:43:42 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <20080905092633.GA53234@icarus.home.lan> References: <20080903191454.GA15376@server.vk2pj.dyndns.org> <1220545795.94705.15.camel@buffy.york.ac.uk> <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> <1220550536.94705.18.camel@buffy.york.ac.uk> <48C02768.1080207@math.missouri.edu> <20080905053455.GD65464@cdnetworks.co.kr> <20080905055423.GA37775@icarus.home.lan> <20080905060642.GF65464@cdnetworks.co.kr> <20080905092633.GA53234@icarus.home.lan> Message-ID: <20080906034327.GA74236@icarus.home.lan> On Fri, Sep 05, 2008 at 02:26:33AM -0700, Jeremy Chadwick wrote: > On Fri, Sep 05, 2008 at 03:06:42PM +0900, Pyun YongHyeon wrote: > > On Thu, Sep 04, 2008 at 10:54:23PM -0700, Jeremy Chadwick wrote: > > > On Fri, Sep 05, 2008 at 02:34:55PM +0900, Pyun YongHyeon wrote: > > > > On Thu, Sep 04, 2008 at 01:22:32PM -0500, Stephen Montgomery-Smith wrote: > > > > > The http://people.freebsd.org/~yongari/msk/msk.88E8040.patch patch for > > > > > the 88E8040 simply doesn't work. It is not because of lack of testing > > > > > (which I have performed for Pyun who wrote the patch), but apparently > > > > > because of lack of reliable documentation. There is a driver for > > > > > > > > Another problem is lack of hardware. 88E8040 seems to be intialized > > > > after applying the patch but link establishment seem to fail. :-( > > > > > I can purchase and send you a Marvel 88E8040 NIC, assuming we can find a > > > PCI or PCIe card somewhere that uses one. Otherwise, I could purchase a > > > motherboard which uses the IC and send that to you. > > > > > > > I failed to find a standalone PCI/PCIe NIC based on 88E8040 > > controller in local store. > > I'll look around, and if I can't find anything, contact Marvell asking > which of their clients use their 88E8040 in standalone PCI/PCIe NICs. > > If push comes to shove, I'll pick up a motherboard that has the 88E8040 > on it and ship it to you free of cost. I cannot find a single PCI/PCIe card that uses the 88E8040. There do not appear to be any consumer motherboards that use the 88E8040 either. I haven't mailed Marvell yet, but I doubt they'd disclose to me a list of their customers who purchase said chip. The only product I can find on the market which uses this chip are a two Dell laptops: the Inspiron 1525 and the XPS M1530. The Inspiron 1525 is approximately US$499, and the XPS M1530 is approximately US$1000. Both of these are quite expensive, so purchasing one solely for this project would put a pretty large hole in my pocket. Ironically, I just bought an Inspiron 1525 for a friend of mine's son as a birthday gift, so I do have access to one indirectly, and can probably borrow it for a day or two if need be. It lacks a serial port, so I'd have to buy a USB serial adapter for serial console if remote console was needed. All of this seems like a lot of work/hassle, when possibly someone with one of these laptops could hook it up (wirelessly) and provide Yong-Hyeon with remote + root access, while leaving it on/plugged in for a few days. Otherwise, if push comes to shove, I can ask my friend's son if I can borrow the laptop for a weekend and provide Yong-Hyeon access to it. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From smithi at nimnet.asn.au Sat Sep 6 05:15:43 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Sat Sep 6 05:15:50 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: <20080905213656.BDB444500F@ptavv.es.net> References: <20080905213656.BDB444500F@ptavv.es.net> Message-ID: <20080906141423.N439@sola.nimnet.asn.au> On Fri, 5 Sep 2008, Kevin Oberman wrote: > > ---------- Forwarded message ---------- > > From: Kai Otto > > Date: 2008/9/5 > > Subject: Re: FreeBSD 7.1 Content > > To: Tom Evans > > > > > > Hello > > > > I think someone mentioned it earlier, but I'm not shure. > > IMHO it would _be_ nice if there's a HTML-browser in the standard > > installation (with option to not install it in sysinstall). > > I say HTML and not web because I think about the /usr/share/doc > > .html-documentation. If someone really has no Internet-connection as > > mentioned before he/she isn't able to read the handbook, which IMHO is a > > very important part of FreeBSD. There are great manpages and exaple files, > > but the best explanations are in the handbook. > > These days a web browser is almost essential. The question is lynx or > links? I prefer links, but lynx is more popular. I hope you don't > insist on a GUI. Those things are far too big and require an X install. Agreed; also that it's much better than lynx, which as I recall used to be installed by older versions, up to 4.X at least .. the installed MOTD even used to advise how to use it with provided handbook and faq URLs. I just booted off the 7.0 disc1 to check, and /usr/local/bin/links is still the default browser in Options, available during installation from another vty. So I was a bit surprised, on rebooting into my so far not much configured 7.0, to find that it hadn't actually been installed. It's a pretty small package, useful enough to at least read local docs, and would be handy installed from disc1 .. and maybe even by bootonly? cheers, Ian From annona2 at gmail.com Sat Sep 6 10:29:41 2008 From: annona2 at gmail.com (annona2@gmail.com) Date: Sat Sep 6 10:29:47 2008 Subject: idea about FreeBSD 7.1-RELEASE Message-ID: <200809061017.m86AH8IK001307@softbank219001162114.bbtec.net> Hello. I have an idea that, in FreeBSD 7.1-RELEASE, the code of freebsd-update is included. If SA is announced, it would be nice. When so, iso-image is still 7.1-RELEASE not 7.1-RELEASE-p1. So, if someone intend to install 7.1-RELEASE, and if network is coonnected, the installer runs the freebsd-update script and it will be secure install. Please take this idea into account. Sincerely, G. Otsuji. From rwatson at FreeBSD.org Sat Sep 6 11:06:14 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Sep 6 11:06:21 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> Message-ID: On Fri, 5 Sep 2008, Ben Kaduk wrote: > To quote from the same website: > Early adopter > Releases which are published from the -CURRENT branch will be > supported by the Security Officer for a minimum of 6 months after the > release. > Normal > Releases which are published from a -STABLE branch will be > supported by the Security Officer for a minimum of 12 months after the > release. > Extended > Selected releases will be supported by the Security Officer for a > minimum of 24 months after the release. > > I don't remember seeing any speculation about 6.4 being an extended release, > so, EoL is 12 months after release, whenever that actually happens. Unfortunately, it's a little hard to tell at time-of-release whether a particular release will become extended life or not. This is because extended support status is dependent on the success of the release (i.e., general perception of stability and performance), but also based on the success of other simultaneously releasing branches. We normally don't make a .0 release "extended support" because there's a reasonable expectation that .0 releases will see more limited deployment than, say, a .1 or .2 release, and that those incrementally later releases will be significantly more stable or performant as a resut of the burn-in the .0 received from earlier branch adopters. How long we keep release 6.x releases will depend entirely on how successful 7.x is; I think there's a reasonable expectation that 6.4 or 6.5 will be the last 6.x release, in which case we would want to grant it extended support status. But what happens depends a lot on how successful 7.1 is. My hopes are high, but there's nothing like real-world deployment to shed light on things :-). Robert N M Watson Computer Laboratory University of Cambridge > > I thought this was mentioned in the previous thread you started about EoL, > but I didn't see it in a quick search. > >>> The answer to that is not clear - >>> nor do I know if it should be clear yet. I don't know when the type of >>> support decision is made, but I suspect it's not this early in the >>> process. >> >> >> The release date for 6.4 is ~30 days away, isn't it? >> >> Also given that we've previously seen overlaps such that a newer version is >> only supported to the same EoL as the older version, that would pretty much >> dictate that spending resources on testing 6.4-REL and/or upgrading would be >> futile. >> > > That's the difference between a long-term-support branch and a regular branch; > many OSes do that. If you want to run the same machines for a long time and > not have to do a huge battery of tests (at the expense of getting new features > and better performance in the interim), you use long-term branches. > The regular branches that get released later, will then become unsupported > at the same time as the (older) long-term branch. > > Yes, it's poor when a long-term branch goes EoL before there's another one > ready to take its place, but if the new one isn't ready, then you just use > whichever regular release is current and then snag a long-term release > when it becomes available. Yes, it's more work, but that's life. > > -Ben Kaduk > _______________________________________________ > 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 delphij at delphij.net Sat Sep 6 11:21:09 2008 From: delphij at delphij.net (Xin LI) Date: Sat Sep 6 11:21:40 2008 Subject: idea about FreeBSD 7.1-RELEASE In-Reply-To: <200809061017.m86AH8IK001307@softbank219001162114.bbtec.net> References: <200809061017.m86AH8IK001307@softbank219001162114.bbtec.net> Message-ID: <48C2679A.3060909@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 annona2@gmail.com wrote: > Hello. > I have an idea that, in FreeBSD 7.1-RELEASE, the code of freebsd-update > is included. > If SA is announced, it would be nice. > When so, iso-image is still 7.1-RELEASE not 7.1-RELEASE-p1. > So, if someone intend to install 7.1-RELEASE, and if network is coonnected, > the installer runs the freebsd-update script and it will be secure install. > Please take this idea into account. Perhaps a nightly script (i.e. 350.freebsd-update which basically do freebsd-update cron) would be better, as it ? Note that we can even make the script configurable to install and reboot system. Also, I always wish that the official installation disc to ship with a portsnap tarball which included the snapshot at the tagged time, instead of just do a tarball of export of CVS ports/, and use portsnap instead. This will make the first time portsnap execution much less painful. Another idea is to ship /var/db/mergemaster.mtree with the installation. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjCZ5YACgkQi+vbBBjt66ADLACgslzT7cfwEDLQ8xfqZlS/Uq8L DXwAoJ/4Fncws7urXm4qI2dux0R3f9RZ =5vgr -----END PGP SIGNATURE----- From andrew-freebsd at areilly.bpc-users.org Sat Sep 6 14:03:40 2008 From: andrew-freebsd at areilly.bpc-users.org (Andrew Reilly) Date: Sat Sep 6 14:03:47 2008 Subject: nVidia driver update today: renders X11 unusable In-Reply-To: <48BD4D84.4030209@zedat.fu-berlin.de> References: <48BD0C5A.4060706@zedat.fu-berlin.de> <48BD3FCC.2080506@kasimir.com> <48BD43DA.4010805@zedat.fu-berlin.de> <48BD46BB.9060407@icyb.net.ua> <48BD4D84.4030209@zedat.fu-berlin.de> Message-ID: <20080906085940.GA3141@duncan.reilly.home> On Tue, Sep 02, 2008 at 02:28:20PM +0000, O. Hartmann wrote: > How can I selectively 'downgrade' a port? I've never had the nv driver be able to happily (or at all, really) drive my LCD screen, so I've been using the VESA driver. Works pretty OK. So it's not accelerated, but chips and busses are fast these days, and the nv driver isn't doing 3D accel anyway. I saw the nv driver update come up, and was going to give it another go, but maybe I'll wait for a bit... FWIW my system is an Athlon X2 box with NVIDIA motherboard chipset and a cheapo 6600LE graphics card. Anyway, my point is that you should be able to use the VESA driver as a fall-back until the nv driver starts to work (again?) Cheers, Andrew From danallen46 at airwired.net Sat Sep 6 19:12:31 2008 From: danallen46 at airwired.net (Dan Allen) Date: Sat Sep 6 19:12:52 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <20080906034327.GA74236@icarus.home.lan> References: <20080903191454.GA15376@server.vk2pj.dyndns.org> <1220545795.94705.15.camel@buffy.york.ac.uk> <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> <1220550536.94705.18.camel@buffy.york.ac.uk> <48C02768.1080207@math.missouri.edu> <20080905053455.GD65464@cdnetworks.co.kr> <20080905055423.GA37775@icarus.home.lan> <20080905060642.GF65464@cdnetworks.co.kr> <20080905092633.GA53234@icarus.home.lan> <20080906034327.GA74236@icarus.home.lan> Message-ID: On 5 Sep 2008, at 9:43 PM, Jeremy Chadwick wrote: > I cannot find a single PCI/PCIe card that uses the 88E8040. I wonder how Ubuntu supports this ethernet chip? It is amazing that only two Dell's use this chip. Maybe it is not worth worrying about after all... Don't kill yourself over this. It is not the end of the world. It appears I will be able to get my Intel 4965 Wireless working in which case I can use that. I have lots of computers in which I can run FreeBSD. Dan From richardtector at thekeelecentre.com Sat Sep 6 20:42:01 2008 From: richardtector at thekeelecentre.com (Richard Tector) Date: Sat Sep 6 20:42:08 2008 Subject: Problem with mod_fcgid on AMD64 Message-ID: <48C2E676.5000104@thekeelecentre.com> Earlier today I reinstalled one of our web servers (Dell PowerEdge 860 running dual or quad core Xeons) with amd64 RELENG_7 as of today, replacing i386 RELENG_7 from about a month back (clean install). After installing Apache 2.2.9 and mod_fcgid 2.2 from ports exactly as on the other i386 machines, Apache fails to start with: [Sat Sep 06 19:48:19 2008] [notice] suEXEC mechanism enabled (wrapper: /usr/local/sbin/suexec) [Sat Sep 06 19:48:19 2008] [emerg] (12)Cannot allocate memory: mod_fcgid: Can't create share memory for size %zu byte The only information I can find on the web relating to this error suggests (on Linux) adding a SharememPath config option to httpd.conf, but setting this makes no difference. A zero byte file is created, and that's it. The exact same configuration works fine with i386. Is it possible there is some incompatibility with amd64? Regards, Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2709 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080906/cc99c5aa/smime.bin From lfrigault at agneau.org Sat Sep 6 22:21:56 2008 From: lfrigault at agneau.org (Laurent Frigault) Date: Sat Sep 6 22:22:09 2008 Subject: how to compute vm.pmap.pv_entry_count from procstat ? Message-ID: <20080906220448.GA78044@obelix.bergerie.agneau.org> Hi, On a 7.0-STABLE i386 web server, I got kernel messages reporting problems with PV entries: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable. This server (DELL poweredge R200 quad core 4G RAM) is having random hang every few weeks (need power off/on cycle, IPMI not responding any more with those hangs) , but I don't know if the hangs are related to a PV entries problem. Before increasing blindly vm.pmap.shpgperproc , I would like to evaluate a good value for vm.pmap.shpgperproc (default 200) because I remember reading somewhere that increasing too much shpgperproc could result in panic at boot time or later. If I guess correctly (I did not find any understandable by me documentation on vm.pmap.*) vm.pmap.pv_entry_count is the value of currently used PV entries . My idea was to use procstat -av output to compute some statistics about the number of PV entries needed by various kind of process (apache, ...) It should be possible to compute a good evaluation of vm.pmap.pv_entry_count by adding some combination of RES,PRES, SHD columns. When I add RES,PRES, SHD values, the result is bigger than pv_entry_count. What is the formula to retrieve pv_entry_count from procstat output or in other words, how to compute the number of PV entries used by a process ? Regards, -- Laurent Frigault | From koitsu at FreeBSD.org Sun Sep 7 00:50:39 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Sep 7 00:50:48 2008 Subject: Inspiron 1525 Hardware In-Reply-To: References: <1220545795.94705.15.camel@buffy.york.ac.uk> <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> <1220550536.94705.18.camel@buffy.york.ac.uk> <48C02768.1080207@math.missouri.edu> <20080905053455.GD65464@cdnetworks.co.kr> <20080905055423.GA37775@icarus.home.lan> <20080905060642.GF65464@cdnetworks.co.kr> <20080905092633.GA53234@icarus.home.lan> <20080906034327.GA74236@icarus.home.lan> Message-ID: <20080907005036.GA98944@icarus.home.lan> On Sat, Sep 06, 2008 at 01:12:29PM -0600, Dan Allen wrote: > On 5 Sep 2008, at 9:43 PM, Jeremy Chadwick wrote: >> I cannot find a single PCI/PCIe card that uses the 88E8040. > > I wonder how Ubuntu supports this ethernet chip? It is amazing that > only two Dell's use this chip. Maybe it is not worth worrying about > after all... The reason I'm "worried" about it is that both of those laptop models, especially the Inspiron, are becoming increasingly common. The Inspiron is decently priced/affordable, which means more and more people will start to come out of the woodwork stating FreeBSD doesn't work with its Ethernet chip. This is mainly for Yong-Hyeon: The code for the Linux driver is in sky2.c. You can get a "revision history" with dates by clicking on the weird triangle image on the far left, or get a commit comments by clicking on "CSets" (which is quite useful). Clicking on the actual sky2.c link provides an annotated version. http://linux.bkbits.net:8080/linux-2.6/drivers/net/?PAGE=dir It appears Linux got support for the 88E8040 in September 2007 (revision 1.2.73). Support for the 88E8040T was added in June 2008 (revision 1.330.1.3). The 1.2.73 commit also added support for the 88E8048 and the 88E8070. This might be of great help in tracking down just what register tweaks they added to get support working: http://linux.bkbits.net:8080/linux-2.6/drivers/net/sky2.c?PAGE=diffs&REV=46f2c896NoiOKP_Nx0TcSvNe1G-elw However, there is a comment at the very top that says "this driver lacks link management", indicating PHY support might be somewhere else in the Linux kernel. If that's the case, this code might not be of much help. It might be worth getting in contact with the driver author, shemminger@linux-foundation.org, or jeff@garzik.org, and asking for tips. > Don't kill yourself over this. It is not the end of the world. It > appears I will be able to get my Intel 4965 Wireless working in which > case I can use that. I have lots of computers in which I can run > FreeBSD. It doesn't surprise me that only two products on the US market (that I can find) use this chip. I blogged about the horrible state of Ethernet chips used on consumer products back in July; everyone is using Realtek or Attansic/Atheros now, which means they pretty much have a stronghold on the consumer market. I wouldn't be concerned with this if their chips weren't buggy as hell. http://koitsu.wordpress.com/2008/07/10/realtek-everywhere-when-will-it-stop/ The same problem applies to laptops, although I believe in the case of the laptop market, engineers often (justifiably) look for chips which draw the least amount of power, rather than "the cheapest chip" (which appears to be Realtek). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Sun Sep 7 01:06:58 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Sep 7 01:07:05 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <20080907005036.GA98944@icarus.home.lan> References: <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> <1220550536.94705.18.camel@buffy.york.ac.uk> <48C02768.1080207@math.missouri.edu> <20080905053455.GD65464@cdnetworks.co.kr> <20080905055423.GA37775@icarus.home.lan> <20080905060642.GF65464@cdnetworks.co.kr> <20080905092633.GA53234@icarus.home.lan> <20080906034327.GA74236@icarus.home.lan> <20080907005036.GA98944@icarus.home.lan> Message-ID: <20080907010655.GA99789@icarus.home.lan> On Sat, Sep 06, 2008 at 05:50:36PM -0700, Jeremy Chadwick wrote: > It appears Linux got support for the 88E8040 in September 2007 (revision > 1.2.73). Support for the 88E8040T was added in June 2008 (revision > 1.330.1.3). > > The 1.2.73 commit also added support for the 88E8048 and the 88E8070. > This might be of great help in tracking down just what register tweaks > they added to get support working: > > http://linux.bkbits.net:8080/linux-2.6/drivers/net/sky2.c?PAGE=diffs&REV=46f2c896NoiOKP_Nx0TcSvNe1G-elw The Linux folks refer to these chips as "FE+". The below URL shows quite a lot of commits for FE+ stuff, as well as documentation of actual hardware bugs on some revisions of those chips. http://linux.bkbits.net:8080/linux-2.6/drivers/net/sky2.c?PAGE=related CSet revisions worth looking at (clicking the revision string will take you to a page allowing annotation and diffs, which is helpful): CSet 1.6247.61.6 -- initial support for FE+ chips CSet 1.6247.61.21 -- fix for PHY initialisation in FE+ chips CSet 1.6247.96.1 -- fix for recv status hardware bug in FE+ chips CSet 1.6247.96.2 -- disable VLAN acceleration for FE+ chips (status reg. unreliable) CSet 1.7736 -- disable dynamic Tx watermark support on FE+ chips A lot of these commits are for hardware revision A0 of certain FE+ chips; looks like rev. A0 has a lot of bugs. Yong-Hyeon might be interested in the PHY initialisation fix, since I can imagine that could affect link negotiation. The first CSet in the above list has the following comment. Note the part about "hardware evaluation boards": "Add support for newest Marvell chips. The Yukon FE plus chip is found in some not yet released laptops. Tested on hardware evaluation boards." It appears to me even the Linux guys couldn't get hardware for these chips, without talking to Marvell directly. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From kensmith at cse.Buffalo.EDU Sun Sep 7 04:46:40 2008 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Sun Sep 7 04:46:47 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: <20080906141423.N439@sola.nimnet.asn.au> References: <20080905213656.BDB444500F@ptavv.es.net> <20080906141423.N439@sola.nimnet.asn.au> Message-ID: <1220762797.29265.43.camel@bauer.cse.buffalo.edu> On Sat, 2008-09-06 at 14:51 +1000, Ian Smith wrote: > I just booted off the 7.0 disc1 to check, and /usr/local/bin/links is > still the default browser in Options, available during installation from > another vty. So I was a bit surprised, on rebooting into my so far not > much configured 7.0, to find that it hadn't actually been installed. > > It's a pretty small package, useful enough to at least read local docs, > and would be handy installed from disc1 .. and maybe even by bootonly? I'm actually planning to go in the opposite direction so to speak as far as sysinstall is concerned. There are a couple projects in the works to replace sysinstall, along with the other nifty projects that roll FreeBSD into "another distro" in Linux-speak. Basically this is something where one thing can't cater to everyones' needs/tastes/bikeshed-color. All you need to do is tolerate this thread long enough to reach this message to see that... :-) I'm with Scott in that I like the "other distros" being around. I don't think that necessarily means we shouldn't try harder. But IMHO trying harder needs to be reflected in a new installer. Lets face it, sysinstall s*cks... For the type of folks who want the installer to do more than sysinstall does now sysinstall simply isn't the right tool (no offense intended). That said I think "I" (as RE) am stuck with sysinstall being around for the forseeable future, even after we get a new installer, because some people are so accustomed to it and it fits their needs (again witness this thread...). So I do have some plans for sysinstall but as I said above it'll be more towards a different direction than mentioned above. The path I'm planning is based on these observations: - Many people believe you should just use sysinstall to install the baseline system, and any packages/ports installs should be done post-install. Its hard to say that point of view is wrong. - The baseline system and the ports are fundamentally different. People should be aware of that from the beginning. - At least some of the packages on the ISOs are stale within a week of release at times; a bit longer than a week in most cases but ... - My plans for DVD sized media (still uncertain how that will factor into 6.4/7.1) are to provide CDROM sized ISOs that have no packages on them at all (giving people who don't have DVD drives something they can still install from) and one DVD sized ISO that has packages. The path will be to finish what I started a while ago when I removed the X11 options in the "installation distributions" section of sysinstall by removing the last couple of tidbits that touch packages before you get to the "Would you like to view the list of available packages?" section of sysinstall (e.g. the offer to install Linux compatibility on i386). This will provide us with a clean separation of the baseline system from the packages. After doing a baseline install you can choose to: - reboot and install ports/packages when it comes back up - switch install media to be an FTP server and get a larger selection of packages to choose from - use the available packages if you're installing from DVD No matter which approach you use, you're clearly seeing a separation between the baseline system and the packages/ports. If you want lynx or links or Gnome or KDE you're aware that they are packages/ports and simply select them. If you didn't want them then you don't wind up with them sitting on your disk. Basically I'm saying any of the things that may have been in the "Distributions" section of sysinstall before (X11 stuff used to be in the Distributions) are now in the packages section along with all the other things that are packages. And with the packages only being available on the DVD sized media we stop needing to deal with deciding what precious little amount of stuff is worthy of being on disc1 versus disc2/disc3/etc. and all the disc swapping that comes with CDROM sized media. And for at least some arch's we *might* be able to move the livefs support back onto disc1 if there are no packages there for CDROM sized media - I haven't had a chance to check if that's still feasible. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080907/9ecfba8c/attachment.pgp From annona2 at gmail.com Sun Sep 7 06:23:42 2008 From: annona2 at gmail.com (Gen Otsuji) Date: Sun Sep 7 06:23:49 2008 Subject: idea about FreeBSD 7.1-RELEASE In-Reply-To: <48C2679A.3060909@delphij.net> References: <200809061017.m86AH8IK001307@softbank219001162114.bbtec.net> <48C2679A.3060909@delphij.net> Message-ID: <200809070623.m876NZJN001348@softbank219001162114.bbtec.net> At Sat, 06 Sep 2008 04:20:58 -0700, Xin LI wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > annona2@gmail.com wrote: > > Hello. > > I have an idea that, in FreeBSD 7.1-RELEASE, the code of freebsd-update > > is included. > > If SA is announced, it would be nice. > > When so, iso-image is still 7.1-RELEASE not 7.1-RELEASE-p1. > > So, if someone intend to install 7.1-RELEASE, and if network is coonnected, > > the installer runs the freebsd-update script and it will be secure install. > > Please take this idea into account. > > Perhaps a nightly script (i.e. 350.freebsd-update which basically do > freebsd-update cron) would be better, as it ? Note that we can even > make the script configurable to install and reboot system. > > Also, I always wish that the official installation disc to ship with a > portsnap tarball which included the snapshot at the tagged time, instead > of just do a tarball of export of CVS ports/, and use portsnap instead. > This will make the first time portsnap execution much less painful. > > Another idea is to ship /var/db/mergemaster.mtree with the installation. > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! Thank you for your response. I understood it. Regards, Gen Otsuji From sec+freebsdstable at 42.org Sun Sep 7 11:30:49 2008 From: sec+freebsdstable at 42.org (Stefan `Sec` Zehl) Date: Sun Sep 7 11:30:56 2008 Subject: snapshots and disk usage Message-ID: <20080907113045.GA11293@ice.42.org> Hi, I am using ufs snapshots on RELENG_7 for some time now, and am generally happy with it. I have noticed a strange behaviour when removing large amount of files, and wanted to ask if this is expected. Before starting, we check the free space on /usr: | ice:/usr>df -h . | Filesystem Size Used Avail Capacity Mounted on | /dev/ad4s2.elid 9.7G 7.6G 1.3G 64% /usr Then delete /usr/obj and run df again: | ice:/usr>sudo rm -rf obj 2>/dev/null | ice:/usr>df -h . | Filesystem Size Used Avail Capacity Mounted on | /dev/ad4s2.elid 9.7G 5.7G 3.2G 64% /usr This is unexpected. With snapshots, removing something should not release space. Sure enough, in the course of the next minute, the fake free space vanishes.... | ice:/usr>df -h . | Filesystem Size Used Avail Capacity Mounted on | /dev/ad4s2.elid 9.7G 5.9G 3.0G 66% /usr | ice:/usr>df -h . | Filesystem Size Used Avail Capacity Mounted on | /dev/ad4s2.elid 9.7G 6.6G 2.3G 74% /usr | ice:/usr>df -h . | Filesystem Size Used Avail Capacity Mounted on | /dev/ad4s2.elid 9.7G 8.6G 269M 97% /usr and all the free space is allocated in the snapshot: | ice:~>sudo snapshot list | Filesystem User User% Snap Snap% Snapshot | /usr 8GB 89.3% 2GB 21.5% daily.1 | /usr 8GB 89.3% 344MB 3.5% daily.0 | /usr 8GB 89.3% 344MB 3.5% weekly.0 | /usr 8GB 89.3% 344MB 3.5% hourly.1 | /usr 8GB 89.3% 7MB 0.1% hourly.0 My understanding so far was that df may underreport free space, but i find overreporting it a bit troublesome. -- What would happen if I tried to use that space before it was allocated to the snapshot? Case in point: I created a few unkillable hung process on /usr a few weeks ago, by running make world which was running out of diskspace, and deleting files from another windows. -- At leat thats what I think has happened. CU, Sec -- Consider the need for having to type "www.domain.name" a little IQ test that you have to take before you can access my web site.' -- Wietse From stickybit at gmx.net Sun Sep 7 11:37:20 2008 From: stickybit at gmx.net (Sticky Bit) Date: Sun Sep 7 11:37:28 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: <1220762797.29265.43.camel@bauer.cse.buffalo.edu> References: <20080905213656.BDB444500F@ptavv.es.net> <20080906141423.N439@sola.nimnet.asn.au> <1220762797.29265.43.camel@bauer.cse.buffalo.edu> Message-ID: <200809071309.13542.stickybit@gmx.net> On Sunday 07 September 2008 06:46:37 Ken Smith wrote: > The path I'm planning is based on these observations: > > - Many people believe you should just use sysinstall to install > the baseline system, and any packages/ports installs should > be done post-install. Its hard to say that point of view is > wrong. > > - The baseline system and the ports are fundamentally different. > People should be aware of that from the beginning. > > - At least some of the packages on the ISOs are stale within a > week of release at times; a bit longer than a week in most > cases but ... These points are very true. > - My plans for DVD sized media (still uncertain how that will > factor into 6.4/7.1) are to provide CDROM sized ISOs that have > no packages on them at all (giving people who don't have DVD > drives something they can still install from) and one DVD > sized ISO that has packages. > > The path will be to finish what I started a while ago when I removed the > X11 options in the "installation distributions" section of sysinstall by > removing the last couple of tidbits that touch packages before you get > to the "Would you like to view the list of available packages?" section > of sysinstall (e.g. the offer to install Linux compatibility on i386). > This will provide us with a clean separation of the baseline system from > the packages. After doing a baseline install you can choose to: > > - reboot and install ports/packages when it comes back up > - switch install media to be an FTP server and get a larger > selection of packages to choose from > - use the available packages if you're installing from DVD > > No matter which approach you use, you're clearly seeing a separation > between the baseline system and the packages/ports. If you want lynx or > links or Gnome or KDE you're aware that they are packages/ports and > simply select them. If you didn't want them then you don't wind up with > them sitting on your disk. Basically I'm saying any of the things that > may have been in the "Distributions" section of sysinstall before (X11 > stuff used to be in the Distributions) are now in the packages section > along with all the other things that are packages. And with the > packages only being available on the DVD sized media we stop needing to > deal with deciding what precious little amount of stuff is worthy of > being on disc1 versus disc2/disc3/etc. and all the disc swapping that > comes with CDROM sized media. > > And for at least some arch's we *might* be able to move the livefs > support back onto disc1 if there are no packages there for CDROM sized > media - I haven't had a chance to check if that's still feasible. Very well! I hope you actually go this road and this really becomes true. It is the most advanced approach I read within this thread, covers pretty much all needs and make things really idiot proof (no offense meant). Please make it true! Thanks a lot! Regards From bsd-unix at embarqmail.com Sun Sep 7 12:06:27 2008 From: bsd-unix at embarqmail.com (Randy Pratt) Date: Sun Sep 7 12:06:39 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: <1220762797.29265.43.camel@bauer.cse.buffalo.edu> References: <20080905213656.BDB444500F@ptavv.es.net> <20080906141423.N439@sola.nimnet.asn.au> <1220762797.29265.43.camel@bauer.cse.buffalo.edu> Message-ID: <20080907080624.078e7e13.bsd-unix@embarqmail.com> On Sun, 07 Sep 2008 00:46:37 -0400 Ken Smith wrote: > On Sat, 2008-09-06 at 14:51 +1000, Ian Smith wrote: > > I just booted off the 7.0 disc1 to check, and /usr/local/bin/links is > > still the default browser in Options, available during installation from > > another vty. So I was a bit surprised, on rebooting into my so far not > > much configured 7.0, to find that it hadn't actually been installed. > > > > It's a pretty small package, useful enough to at least read local docs, > > and would be handy installed from disc1 .. and maybe even by bootonly? > > I'm actually planning to go in the opposite direction so to speak as far > as sysinstall is concerned. There are a couple projects in the works to > replace sysinstall, along with the other nifty projects that roll > FreeBSD into "another distro" in Linux-speak. > > Basically this is something where one thing can't cater to everyones' > needs/tastes/bikeshed-color. All you need to do is tolerate this thread > long enough to reach this message to see that... :-) > > I'm with Scott in that I like the "other distros" being around. I don't > think that necessarily means we shouldn't try harder. But IMHO trying > harder needs to be reflected in a new installer. Lets face it, > sysinstall s*cks... For the type of folks who want the installer to do > more than sysinstall does now sysinstall simply isn't the right tool (no > offense intended). > > That said I think "I" (as RE) am stuck with sysinstall being around for > the forseeable future, even after we get a new installer, because some > people are so accustomed to it and it fits their needs (again witness > this thread...). So I do have some plans for sysinstall but as I said > above it'll be more towards a different direction than mentioned above. > > The path I'm planning is based on these observations: > > - Many people believe you should just use sysinstall to install > the baseline system, and any packages/ports installs should > be done post-install. Its hard to say that point of view is > wrong. > > - The baseline system and the ports are fundamentally different. > People should be aware of that from the beginning. > > - At least some of the packages on the ISOs are stale within a > week of release at times; a bit longer than a week in most > cases but ... > > - My plans for DVD sized media (still uncertain how that will > factor into 6.4/7.1) are to provide CDROM sized ISOs that have > no packages on them at all (giving people who don't have DVD > drives something they can still install from) and one DVD > sized ISO that has packages. > > The path will be to finish what I started a while ago when I removed the > X11 options in the "installation distributions" section of sysinstall by > removing the last couple of tidbits that touch packages before you get > to the "Would you like to view the list of available packages?" section > of sysinstall (e.g. the offer to install Linux compatibility on i386). > This will provide us with a clean separation of the baseline system from > the packages. After doing a baseline install you can choose to: > > - reboot and install ports/packages when it comes back up > - switch install media to be an FTP server and get a larger > selection of packages to choose from > - use the available packages if you're installing from DVD > > No matter which approach you use, you're clearly seeing a separation > between the baseline system and the packages/ports. If you want lynx or > links or Gnome or KDE you're aware that they are packages/ports and > simply select them. If you didn't want them then you don't wind up with > them sitting on your disk. Basically I'm saying any of the things that > may have been in the "Distributions" section of sysinstall before (X11 > stuff used to be in the Distributions) are now in the packages section > along with all the other things that are packages. And with the > packages only being available on the DVD sized media we stop needing to > deal with deciding what precious little amount of stuff is worthy of > being on disc1 versus disc2/disc3/etc. and all the disc swapping that > comes with CDROM sized media. > > And for at least some arch's we *might* be able to move the livefs > support back onto disc1 if there are no packages there for CDROM sized > media - I haven't had a chance to check if that's still feasible. Excellent summary! It addresses things that have been discussed on the lists many times. The ports tree distribution tarball provided on the installation disks is another area that needs some consideration. I suspect that many people aren't aware of the need for "adoption": http://myfreebsd.homeunix.net/hints_n_kinks/adoptportstree.html Is it possible to provide/install the necessary file(s) along with the ports tree such that cvsup/csup would be aware of the files installed so that obsolete files can be removed when updating the ports tree? The same situation probably exists for the source tree and the documentation tree. Would it just be a matter of installing the appropriate "checkouts.cvs:." files when the sources are installed? I've only done the adoption process one time and decided that its easier to just csup a new trees right after booting the new system. Additionally, I've never seen a clear way of synchronizing a local ports tree to that used to create the "LATEST" packages. I've had to resort to building my own package sets for the slow boxes on the network. I realize that this aspect diverges from the subject of this thread but I do think some more thought should be given to this aspect. Anyway, the direction you're proposing for sysinstall/packages seems to be the most logical approach. Thanks to you and the rest of the Release Engineering teams for all the work put into the releases! Randy -- From scottl at samsco.org Sun Sep 7 18:50:18 2008 From: scottl at samsco.org (Scott Long) Date: Sun Sep 7 18:50:26 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: <1220762797.29265.43.camel@bauer.cse.buffalo.edu> References: <20080905213656.BDB444500F@ptavv.es.net> <20080906141423.N439@sola.nimnet.asn.au> <1220762797.29265.43.camel@bauer.cse.buffalo.edu> Message-ID: <48C42263.2050808@samsco.org> Ken Smith wrote: > I'm with Scott in that I like the "other distros" being around. I don't > think that necessarily means we shouldn't try harder. But IMHO trying > harder needs to be reflected in a new installer. Lets face it, > sysinstall s*cks... For the type of folks who want the installer to do > more than sysinstall does now sysinstall simply isn't the right tool (no > offense intended). To me, the "sysinstall problem" is already solved. PCBSD already has a new installer that is quite capable. Granted, it's not part of the "base system", but I don't think that it needs to be. In fact, I don't think it can be, because the modern APIs and languages that one would use to write a modern installer aren't in the base system and likely never will be. Furthermore, there should not and can not be "one true installer" just like there cannot be "one true distribution." Trying to make it be that way only stifles innovation. People should be encouraged to write many installers in Python, Ruby, LUA, or whatever language and API set gets the job done, without worrying about how it'll all integrate into the base system or what colliding viewpoints from the peanut gallery they'll need to compromise on. I think that this is all the more reason to stop viewing the freebsd.org release bits as the One True Release and start encouraging people, in earnest, to view them as reference bits for others to build on and package. Scott From marck at rinet.ru Sun Sep 7 19:25:57 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Sun Sep 7 19:26:05 2008 Subject: mysterious uname non-updates Message-ID: Dear colleagues, today, updating one of my machines, I got the following mysterious results after reboot: root@ogre:~# sysctl -a | grep RELE kern.osrelease: 6.3-RELEASE kern.version: FreeBSD 6.3-RELEASE #4: Thu Jan 17 15:28:57 MSK 2008 root@ogre:~# strings /boot/kernel/kernel | grep RELE AE_RELEASE_DEADLOCK 6.3-RELEASE-p4 FreeBSD 6.3-RELEASE-p4 #6: Sun Sep 7 23:13:45 MSD 2008 @(#)FreeBSD 6.3-RELEASE-p4 #6: Sun Sep 7 23:13:45 MSD 2008 root@ogre:~# env | grep -i uname root@ogre:~# WTF? Why my kernel reports that it is previous version (actually it is already deleted, so I'm double puzzled) Any clues? Thanks! Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From zflyer at gmail.com Sun Sep 7 19:35:56 2008 From: zflyer at gmail.com (Walker) Date: Sun Sep 7 19:36:04 2008 Subject: WOL (Wake On LAN) no longer working Message-ID: <6293ba970809071213q3d50d46aoaddfead349f90039@mail.gmail.com> Somewhere along the road from 7.0 to 7.1 WOL stopped working for me. I have an "82546EB Dual Port Gigabit Ethernet Controller" which, after shutdown, has link lights on the card and switch. Nothing has changed on the PC or NIC BIOS. I noticed new wol ifconfig settings, and add "wol" to my rc.conf, with no effect. ********** $pciconf -vl em0@pci0:0:8:0: class=0x020000 card=0x118a8086 chip=0x10798086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82546EB Dual Port Gigabit Ethernet Controller' class = network subclass = ethernet ********** Thanks for any help. From dnelson at allantgroup.com Sun Sep 7 19:55:39 2008 From: dnelson at allantgroup.com (Dan Nelson) Date: Sun Sep 7 19:55:46 2008 Subject: snapshots and disk usage In-Reply-To: <20080907113045.GA11293@ice.42.org> References: <20080907113045.GA11293@ice.42.org> Message-ID: <20080907195535.GA30343@dan.emsphone.com> In the last episode (Sep 07), Stefan `Sec` Zehl said: > Hi, > > I am using ufs snapshots on RELENG_7 for some time now, and am generally > happy with it. I have noticed a strange behaviour when removing large > amount of files, and wanted to ask if this is expected. > > Before starting, we check the free space on /usr: > > | ice:/usr>df -h . > | Filesystem Size Used Avail Capacity Mounted on > | /dev/ad4s2.elid 9.7G 7.6G 1.3G 64% /usr > > Then delete /usr/obj and run df again: > > | ice:/usr>sudo rm -rf obj 2>/dev/null > | ice:/usr>df -h . > | Filesystem Size Used Avail Capacity Mounted on > | /dev/ad4s2.elid 9.7G 5.7G 3.2G 64% /usr > > This is unexpected. With snapshots, removing something should not > release space. > > Sure enough, in the course of the next minute, the fake free space > vanishes.... > > | ice:/usr>df -h . > | Filesystem Size Used Avail Capacity Mounted on > | /dev/ad4s2.elid 9.7G 5.9G 3.0G 66% /usr > | ice:/usr>df -h . > | Filesystem Size Used Avail Capacity Mounted on > | /dev/ad4s2.elid 9.7G 6.6G 2.3G 74% /usr > | ice:/usr>df -h . > | Filesystem Size Used Avail Capacity Mounted on > | /dev/ad4s2.elid 9.7G 8.6G 269M 97% /usr > > and all the free space is allocated in the snapshot: > > | ice:~>sudo snapshot list > | Filesystem User User% Snap Snap% Snapshot > | /usr 8GB 89.3% 2GB 21.5% daily.1 > | /usr 8GB 89.3% 344MB 3.5% daily.0 > | /usr 8GB 89.3% 344MB 3.5% weekly.0 > | /usr 8GB 89.3% 344MB 3.5% hourly.1 > | /usr 8GB 89.3% 7MB 0.1% hourly.0 > > My understanding so far was that df may underreport free space, but i > find overreporting it a bit troublesome. -- What would happen if I tried > to use that space before it was allocated to the snapshot? I think you're running into the softupdates delay. When you delete a file on a SU-enabled filessytem, the space isn't actually freed until sync. But applications expect that statfs() info is updated immediately, so the kernel pretends that the space is available. That doesn't really work with a snapshot, since if you delete a file that existed in the snapshot, no space will free up. So you see a jump in freespace as the kernel fakes the f_bfree statfs amount, then it slowly drops to the correct value as the deletions actually sync to disk. -- Dan Nelson dnelson@allantgroup.com From takeda at takeda.tk Sun Sep 7 20:41:05 2008 From: takeda at takeda.tk (=?utf-8?Q?Derek_Kuli=C5=84ski?=) Date: Sun Sep 7 20:41:13 2008 Subject: Funny things with cflags and world/kernel building In-Reply-To: <48C1302C.2040109@kkip.pl> References: <48C1302C.2040109@kkip.pl> Message-ID: <334439428.20080907134019@takeda.tk> Hello Bartosz, Friday, September 5, 2008, 6:12:12 AM, you wrote: > My make.conf: > CPUTYPE=athlon64 > MAKEOPTS=-j3 I would recommend to take that -j3 out from make.conf, it might screw up make install, not to mention many ports might not build with it. > # USE CCACHE > .if !defined(NOCCACHE) > CC=/usr/local/libexec/ccache/world-cc > CXX=/usr/local/libexec/ccache/world-c++ > .endif AFAIK this is setting for building world, the way you set it up seems to be using it for everything else (i.e. ports) I belive this is the recommended way of using it: .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && !defined(NOCCACHE) CC=/usr/local/libexec/ccache/world-cc CXX=/usr/local/libexec/ccache/world-c++ .endif > 1. when I use these flags: > CFLAGS=-O2 -fno-strict-aliasing -pipe > CXXFLAGS=${CFLAGS} > COPTFLAGS=${CFLAGS} > world building finish without problem, but making kernel give an error: > 2. When I use these flags: > CFLAGS=-O2 -fno-strict-aliasing -pipe > CXXFLAGS=-O2 -fno-strict-aliasing -pipe > COPTFLAGS=-O2 -fno-strict-aliasing -pipe > kernel build finish without problem, but... building world give an error!: > 3. What's even more funny? When I use flags: > CFLAGS=-O2 -fno-strict-aliasing -pipe > COPTFLAGS=-O2 -fno-strict-aliasing -pipe > CXXFLAGS=${CFLAGS} > I have no errors at all! But shouldn't all those flags be treated by > make command exactly the same way?? I think the strange behavior probably is because make.conf is called each time a make is executed. Building world, kernel etc. Will call multiple makes inside of another make. I suspect some of the Makefiles might append additional flags, so the ${CFLAGS} might change its value in different parts of the compiling, so that's why you might get the weird errors. I guess perhaps you could use the last option since it works, or instead of using = you would use ?= i.e. CFLAGS ?= -O2 -fno-strict-aliasing -pipe This will assign cflags only if CFLAGS is empty. -- Best regards, Derek mailto:takeda@takeda.tk -- Be nice to your kids. They'll choose your nursing home. From pyunyh at gmail.com Mon Sep 8 00:44:28 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Sep 8 00:44:36 2008 Subject: WOL (Wake On LAN) no longer working In-Reply-To: <6293ba970809071213q3d50d46aoaddfead349f90039@mail.gmail.com> References: <6293ba970809071213q3d50d46aoaddfead349f90039@mail.gmail.com> Message-ID: <20080908004422.GB77346@cdnetworks.co.kr> On Sun, Sep 07, 2008 at 03:13:47PM -0400, Walker wrote: > Somewhere along the road from 7.0 to 7.1 WOL stopped working for me. > I have an "82546EB Dual Port Gigabit Ethernet Controller" which, after > shutdown, has link lights on the card and switch. Nothing has changed > on the PC or NIC BIOS. I noticed new wol ifconfig settings, and add > "wol" to my rc.conf, with no effect. > I don't know what caused the issue but both em(4) and igb(4) implements WOL with its own way and does not honor interface capability configuration of ifconfig. -- Regards, Pyun YongHyeon From koitsu at FreeBSD.org Mon Sep 8 01:07:21 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 8 01:07:28 2008 Subject: WOL (Wake On LAN) no longer working In-Reply-To: <20080908004422.GB77346@cdnetworks.co.kr> References: <6293ba970809071213q3d50d46aoaddfead349f90039@mail.gmail.com> <20080908004422.GB77346@cdnetworks.co.kr> Message-ID: <20080908010718.GA53820@icarus.home.lan> On Mon, Sep 08, 2008 at 09:44:22AM +0900, Pyun YongHyeon wrote: > On Sun, Sep 07, 2008 at 03:13:47PM -0400, Walker wrote: > > Somewhere along the road from 7.0 to 7.1 WOL stopped working for me. > > I have an "82546EB Dual Port Gigabit Ethernet Controller" which, after > > shutdown, has link lights on the card and switch. Nothing has changed > > on the PC or NIC BIOS. I noticed new wol ifconfig settings, and add > > "wol" to my rc.conf, with no effect. > > > > I don't know what caused the issue but both em(4) and igb(4) > implements WOL with its own way and does not honor interface > capability configuration of ifconfig. CC'ing Jack Vogel (driver maintainer), who should be able to help with this. Ideally, the "wol" flag of ifconfig *should* be the standard interface for said functionality. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From gaijin.k at gmail.com Mon Sep 8 01:12:28 2008 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Mon Sep 8 01:12:36 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <20080906034327.GA74236@icarus.home.lan> References: <20080903191454.GA15376@server.vk2pj.dyndns.org> <1220545795.94705.15.camel@buffy.york.ac.uk> <49B92D81-74EC-4BAB-BEEC-EC4DCFF5E336@airwired.net> <1220550536.94705.18.camel@buffy.york.ac.uk> <48C02768.1080207@math.missouri.edu> <20080905053455.GD65464@cdnetworks.co.kr> <20080905055423.GA37775@icarus.home.lan> <20080905060642.GF65464@cdnetworks.co.kr> <20080905092633.GA53234@icarus.home.lan> <20080906034327.GA74236@icarus.home.lan> Message-ID: <1220836334.1172.5.camel@RabbitsDen> On Fri, 2008-09-05 at 20:43 -0700, Jeremy Chadwick wrote: > On Fri, Sep 05, 2008 at 02:26:33AM -0700, Jeremy Chadwick wrote: > > On Fri, Sep 05, 2008 at 03:06:42PM +0900, Pyun YongHyeon wrote: > > > On Thu, Sep 04, 2008 at 10:54:23PM -0700, Jeremy Chadwick wrote: > > > > On Fri, Sep 05, 2008 at 02:34:55PM +0900, Pyun YongHyeon wrote: > > > > > On Thu, Sep 04, 2008 at 01:22:32PM -0500, Stephen Montgomery-Smith wrote: > > > > > > The http://people.freebsd.org/~yongari/msk/msk.88E8040.patch patch for > > > > > > the 88E8040 simply doesn't work. It is not because of lack of testing > > > > > > (which I have performed for Pyun who wrote the patch), but apparently > > > > > > because of lack of reliable documentation. There is a driver for > > > > > > > > > > Another problem is lack of hardware. 88E8040 seems to be intialized > > > > > after applying the patch but link establishment seem to fail. :-( > > > > > > > I can purchase and send you a Marvel 88E8040 NIC, assuming we can find a > > > > PCI or PCIe card somewhere that uses one. Otherwise, I could purchase a > > > > motherboard which uses the IC and send that to you. > > > > > > > > > > I failed to find a standalone PCI/PCIe NIC based on 88E8040 > > > controller in local store. > > > > I'll look around, and if I can't find anything, contact Marvell asking > > which of their clients use their 88E8040 in standalone PCI/PCIe NICs. > > > > If push comes to shove, I'll pick up a motherboard that has the 88E8040 > > on it and ship it to you free of cost. > > I cannot find a single PCI/PCIe card that uses the 88E8040. There do > not appear to be any consumer motherboards that use the 88E8040 either. > I haven't mailed Marvell yet, but I doubt they'd disclose to me a list > of their customers who purchase said chip. > > The only product I can find on the market which uses this chip are a two > Dell laptops: the Inspiron 1525 and the XPS M1530. The Inspiron 1525 is > approximately US$499, and the XPS M1530 is approximately US$1000. Both > of these are quite expensive, so purchasing one solely for this project > would put a pretty large hole in my pocket. > > Ironically, I just bought an Inspiron 1525 for a friend of mine's son as > a birthday gift, so I do have access to one indirectly, and can probably > borrow it for a day or two if need be. It lacks a serial port, so I'd > have to buy a USB serial adapter for serial console if remote console > was needed. Actually, you might not need to -- according to the Dell's website 1525 has Firewire port. I do not have access to the machine in question, but Firewire console works beautifully on my ThinkPad X60. You will need the second machine with Firewire port running FreeBSD, though, and you might want to invest in the long Firewire cable for convenience. HTH, -- Alexandre "Sunny" Kovalenko (????????? ?????????) From doconnor at gsoft.com.au Mon Sep 8 01:57:20 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Mon Sep 8 01:57:28 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <20080906034327.GA74236@icarus.home.lan> References: <20080903191454.GA15376@server.vk2pj.dyndns.org> <20080905092633.GA53234@icarus.home.lan> <20080906034327.GA74236@icarus.home.lan> Message-ID: <200809081127.14069.doconnor@gsoft.com.au> On Sat, 6 Sep 2008, Jeremy Chadwick wrote: > Ironically, I just bought an Inspiron 1525 for a friend of mine's son > as a birthday gift, so I do have access to one indirectly, and can > probably borrow it for a day or two if need be. It lacks a serial > port, so I'd have to buy a USB serial adapter for serial console if > remote console was needed. Just FYI.. This won't work. You need a 'real' serial port for console, the other option would be to use Firewire (if the laptop has it). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080908/e5617cc6/attachment.pgp From koitsu at FreeBSD.org Mon Sep 8 02:02:32 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 8 02:02:39 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <200809081127.14069.doconnor@gsoft.com.au> References: <20080903191454.GA15376@server.vk2pj.dyndns.org> <20080905092633.GA53234@icarus.home.lan> <20080906034327.GA74236@icarus.home.lan> <200809081127.14069.doconnor@gsoft.com.au> Message-ID: <20080908020230.GA54841@icarus.home.lan> On Mon, Sep 08, 2008 at 11:27:11AM +0930, Daniel O'Connor wrote: > On Sat, 6 Sep 2008, Jeremy Chadwick wrote: > > Ironically, I just bought an Inspiron 1525 for a friend of mine's son > > as a birthday gift, so I do have access to one indirectly, and can > > probably borrow it for a day or two if need be. It lacks a serial > > port, so I'd have to buy a USB serial adapter for serial console if > > remote console was needed. > > Just FYI.. This won't work. > You need a 'real' serial port for console, the other option would be to > use Firewire (if the laptop has it). Ah, now that I think about it, I see why it won't work... good catch. I didn't think it all the way through. :-) Firewire is an alternative which won't work for a different reason: none of my BSD machines at home have support for Firewire. Bummer. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From doconnor at gsoft.com.au Mon Sep 8 02:24:35 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Mon Sep 8 02:25:15 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <20080908020230.GA54841@icarus.home.lan> References: <20080903191454.GA15376@server.vk2pj.dyndns.org> <200809081127.14069.doconnor@gsoft.com.au> <20080908020230.GA54841@icarus.home.lan> Message-ID: <200809081154.18157.doconnor@gsoft.com.au> On Mon, 8 Sep 2008, Jeremy Chadwick wrote: > On Mon, Sep 08, 2008 at 11:27:11AM +0930, Daniel O'Connor wrote: > > On Sat, 6 Sep 2008, Jeremy Chadwick wrote: > > > Ironically, I just bought an Inspiron 1525 for a friend of mine's > > > son as a birthday gift, so I do have access to one indirectly, > > > and can probably borrow it for a day or two if need be. It lacks > > > a serial port, so I'd have to buy a USB serial adapter for serial > > > console if remote console was needed. > > > > Just FYI.. This won't work. > > You need a 'real' serial port for console, the other option would > > be to use Firewire (if the laptop has it). > > Ah, now that I think about it, I see why it won't work... good catch. > I didn't think it all the way through. :-) > > Firewire is an alternative which won't work for a different reason: > none of my BSD machines at home have support for Firewire. Bummer. A PCI Firewire card can be had for $20 or so.. Much nicer than RS232 debugging too (a shitload faster for a start) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080908/53c7311b/attachment.pgp From danallen46 at airwired.net Mon Sep 8 03:19:13 2008 From: danallen46 at airwired.net (Dan Allen) Date: Mon Sep 8 03:19:20 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <200809081127.14069.doconnor@gsoft.com.au> References: <20080903191454.GA15376@server.vk2pj.dyndns.org> <20080905092633.GA53234@icarus.home.lan> <20080906034327.GA74236@icarus.home.lan> <200809081127.14069.doconnor@gsoft.com.au> Message-ID: On 7 Sep 2008, at 7:57 PM, Daniel O'Connor wrote: > You need a 'real' serial port for console, the other option would be > to > use Firewire (if the laptop has it). The Dell Inspiron 1525 DOES have a mini-Firewire port on the front of the machine. Dan From pyunyh at gmail.com Mon Sep 8 04:26:17 2008 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Sep 8 04:26:24 2008 Subject: Inspiron 1525 Hardware In-Reply-To: <20080907010655.GA99789@icarus.home.lan> References: <1220550536.94705.18.camel@buffy.york.ac.uk> <48C02768.1080207@math.missouri.edu> <20080905053455.GD65464@cdnetworks.co.kr> <20080905055423.GA37775@icarus.home.lan> <20080905060642.GF65464@cdnetworks.co.kr> <20080905092633.GA53234@icarus.home.lan> <20080906034327.GA74236@icarus.home.lan> <20080907005036.GA98944@icarus.home.lan> <20080907010655.GA99789@icarus.home.lan> Message-ID: <20080908042606.GG77346@cdnetworks.co.kr> On Sat, Sep 06, 2008 at 06:06:55PM -0700, Jeremy Chadwick wrote: > On Sat, Sep 06, 2008 at 05:50:36PM -0700, Jeremy Chadwick wrote: > > It appears Linux got support for the 88E8040 in September 2007 (revision > > 1.2.73). Support for the 88E8040T was added in June 2008 (revision > > 1.330.1.3). > > > > The 1.2.73 commit also added support for the 88E8048 and the 88E8070. > > This might be of great help in tracking down just what register tweaks > > they added to get support working: > > > > http://linux.bkbits.net:8080/linux-2.6/drivers/net/sky2.c?PAGE=diffs&REV=46f2c896NoiOKP_Nx0TcSvNe1G-elw > > The Linux folks refer to these chips as "FE+". The below URL shows > quite a lot of commits for FE+ stuff, as well as documentation of actual > hardware bugs on some revisions of those chips. > > http://linux.bkbits.net:8080/linux-2.6/drivers/net/sky2.c?PAGE=related > > CSet revisions worth looking at (clicking the revision string will take > you to a page allowing annotation and diffs, which is helpful): > Are you proposing to be a msk(4) maintainer? :-) > CSet 1.6247.61.6 -- initial support for FE+ chips > CSet 1.6247.61.21 -- fix for PHY initialisation in FE+ chips > CSet 1.6247.96.1 -- fix for recv status hardware bug in FE+ chips > CSet 1.6247.96.2 -- disable VLAN acceleration for FE+ chips (status reg. unreliable) > CSet 1.7736 -- disable dynamic Tx watermark support on FE+ chips > Thanks for the valuable information. Due to the complexity of Yukon II hardware and its bugs for each revision msk(4) still requires lots of workaround code. The patch you've mentioned in CSet 1.6247.61.21 might help for FE+ but the reason why it needed that patch is not clear. Marvell released 88E8016 datasheet which seem to be used on FE+. The datasheet just mentions that the purpose of the bit of PHY specific control register II choose a behavour(Class A or Class B). I have no idea why FE+ requires class A configuration due to lack of errata information. Also datasheet says that it is only for 100baseTX. I wonder what happens on 10baseT media. Anyway, this kind of testing requires hardware access I guess. Unlike Linux, e1000phy(4) is shared for all other drivers so it's somewhat difficult to program as Linux did. As you might know the PHY fix is only for FE+ A0 and it's hard to pass that information to PHY driver without hack. Let's see what can be done... > A lot of these commits are for hardware revision A0 of certain FE+ > chips; looks like rev. A0 has a lot of bugs. Yong-Hyeon might be Yes, I have no idea how revision A0 could be released to customer. This chip revision looks like worst one I ever seen on consumer products. > interested in the PHY initialisation fix, since I can imagine that could > affect link negotiation. > > The first CSet in the above list has the following comment. Note the > part about "hardware evaluation boards": > > "Add support for newest Marvell chips. The Yukon FE plus chip is found > in some not yet released laptops. Tested on hardware evaluation > boards." > > It appears to me even the Linux guys couldn't get hardware for these > chips, without talking to Marvell directly. -- Regards, Pyun YongHyeon From darrenr at freebsd.org Mon Sep 8 08:30:59 2008 From: darrenr at freebsd.org (Darren Reed) Date: Mon Sep 8 08:31:16 2008 Subject: the future of sun4v In-Reply-To: <20080822201603.GA14444@alchemy.franken.de> References: <3c1674c90808211442t707966fq29997b53a70ed2f7@mail.gmail.com> <20080822113317.GD32539@server.vk2pj.dyndns.org> <48AEA699.10903@FreeBSD.org> <20080822201603.GA14444@alchemy.franken.de> Message-ID: <48C4DEEF.7070201@freebsd.org> Marius Strobl wrote: > On Fri, Aug 22, 2008 at 01:44:25PM +0200, Kris Kennaway wrote: > > Peter Jeremy wrote: > > >[Replies re-directed to freebsd-sun4v] > > > > > >On 2008-Aug-21 14:42:55 -0700, Kip Macy wrote: > > >>I believe that there is a general expectation by freebsd users and > > >>developers that unsupported code should not be in CVS. Although sun4v > > >>is a very interesting platform for developers doing SMP work, I simply > > >>do not have the time or energy to maintain it. If someone else would > > >>like to step up and try his hand I would be supportive of his efforts. > > >>In the likely event that no one steps forward by the time that 7.1 is > > >>released I will ask that it be moved to the Attic. > > > > > >Since there are no other current SPARC CPUs that FreeBSD can run on > > >(the US-II has been obsolete for about 6 years and FreeBSD won't run > > >on any more recent sun4u chips), that will also remove the > > >justification for maintaining a SPARC64 port. > > > > > >I don't have the knowledge or available time to maintain the sun4v > > >port by myself but would be happy to be part of a team doing so. One > > >impediment I have is that I don't have a T-1 or T-2 system that I can > > >dedicate to FreeBSD. I could work on FreeBSD in a guest domain - but > > >since FreeBSD doesn't support either the virtual disk or virtual > > >network, actually getting FreeBSD running there presents somewhat of a > > >challenge. > > > > > > > There are two t1000 systems in the freebsd.org cluster that are > > available for people to work on. Rink Springer has also expressed > > interest in this. > > > > Perhaps Kip can explain some more about what things he looked at, but > > the most serious bugs might be in pmap or perhaps trap handling. > > Operationally, things like buildworld -jN die quickly with random > > signals, kernel traps, etc. > > > > Kris > > > > P.S. It looks like marius has made progress on US III but sun4u is still > > an architectural dead end. > > Well, let's see what architecture the upcoming Rock CPUs are; > judging their feature list they appear to be a continuation of > the Fujitsu sun4u line rather than a successor of UST1/2 :) > That's inaccurate. Rock is meant to be very compatible with sun4v, although I don't know if uname will say "sun4v" or something else...but you will need a bug-free sun4v operating system to run them (which is to say that various bugs in the solaris sun4v support needed to get fixed rather than left...) The critical issue for freebsd (and any operating system for that matter) on rock is how well does the kernel scale to a system with that many concurrent threads? Darren From brooks at freebsd.org Mon Sep 8 14:15:55 2008 From: brooks at freebsd.org (Brooks Davis) Date: Mon Sep 8 14:16:01 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: <20080907080624.078e7e13.bsd-unix@embarqmail.com> References: <20080905213656.BDB444500F@ptavv.es.net> <20080906141423.N439@sola.nimnet.asn.au> <1220762797.29265.43.camel@bauer.cse.buffalo.edu> <20080907080624.078e7e13.bsd-unix@embarqmail.com> Message-ID: <20080908141635.GA20793@lor.one-eyed-alien.net> On Sun, Sep 07, 2008 at 08:06:24AM -0400, Randy Pratt wrote: > The ports tree distribution tarball provided on the installation disks > is another area that needs some consideration. I suspect that many > people aren't aware of the need for "adoption": > > http://myfreebsd.homeunix.net/hints_n_kinks/adoptportstree.html > > Is it possible to provide/install the necessary file(s) along with > the ports tree such that cvsup/csup would be aware of the files > installed so that obsolete files can be removed when updating the ports > tree? The same situation probably exists for the source tree > and the documentation tree. Would it just be a matter of installing > the appropriate "checkouts.cvs:." files when the sources are > installed? > > I've only done the adoption process one time and decided that its > easier to just csup a new trees right after booting the new system. IMO, an even better (but complementary) approach would be to have /usr/ports be a valid portsnap extraction and give users the option to bootstrap /var/db/portsnap. In general I'm finding it to be a much better approach. At this point I'm mostly using cvsup for development. I literally check out a separate ports tree on boxes I do ports development on and keep the main tree up to date with portsnap. I also use freebsd-update to manage most of my servers at work even ones with custom kernels (just let it update /usr/src and don't let it update the kernel). > Additionally, I've never seen a clear way of synchronizing a > local ports tree to that used to create the "LATEST" packages. I've > had to resort to building my own package sets for the slow boxes > on the network. I realize that this aspect diverges from the > subject of this thread but I do think some more thought should > be given to this aspect. With cvs there probably isn't a cost effective way to indicate this (though I suppose the package collections could include a file with a cvsup date string in them). -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080908/236f9951/attachment.pgp From olli at lurza.secnetix.de Mon Sep 8 16:41:58 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Mon Sep 8 16:42:05 2008 Subject: How to disable NFS fnctl in /etc/fstab? In-Reply-To: <1f51039c0809040911oe4409b5ibe3f4dcf53528407@mail.gmail.com> Message-ID: <200809081641.m88GfsXb082210@lurza.secnetix.de> Tim Chen wrote: > For some reason we want to disable fnctl lock for NFS > mounted partition. We can achieve this by the following > command: mount_nfs -T -L server:/home /mnt > However after several time of failure tests, we still > can not make it work in /etc/fstab. > > server:/home /mnt nfs rw,tcp 0 0 server:/home /mnt nfs rw,tcp,-L 0 0 > By the way, since the machine is running as a mail server which > install postfix,courier-imap, will it happen any kind of data > corruption due to NFS fnctl lock disabled? In general, all programs that access mail files must use locking for concurrent access. Without proper locking you'll get data corruption. I strongly advise against running mail software on NFS mounts without locking (i.e. with the -L option). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil, C++ Journal From olli at lurza.secnetix.de Mon Sep 8 16:49:45 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Mon Sep 8 16:49:52 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: <20080905213656.BDB444500F@ptavv.es.net> Message-ID: <200809081649.m88GncbW082522@lurza.secnetix.de> Kevin Oberman wrote: > Kai Otto wrote: > > I think someone mentioned it earlier, but I'm not shure. > > IMHO it would _be_ nice if there's a HTML-browser in the standard > > installation (with option to not install it in sysinstall). > > I say HTML and not web because I think about the /usr/share/doc > > .html-documentation. If someone really has no Internet-connection as > > mentioned before he/she isn't able to read the handbook, which IMHO is a > > very important part of FreeBSD. There are great manpages and exaple files, > > but the best explanations are in the handbook. That's why there's a plain .txt file of the Handbook. No browser required. > These days a web browser is almost essential. The question is lynx or > links? I prefer links, but lynx is more popular. I hope you don't > insist on a GUI. Those things are far too big and require an X install. There's also w3m which some people seem to prefer. It's quite light-weight: $ cd /usr/local/bin $ ls links lynx w3m -r-xr-xr-x 1 root wheel 1059000 Aug 7 09:48 links -r-xr-xr-x 1 root wheel 1184784 Jun 9 15:17 lynx -r-xr-xr-x 1 root wheel 403592 Jun 9 16:15 w3m Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "In My Egoistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton From olli at lurza.secnetix.de Mon Sep 8 17:05:35 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Mon Sep 8 17:05:41 2008 Subject: mysterious uname non-updates In-Reply-To: Message-ID: <200809081705.m88H5Pdh083088@lurza.secnetix.de> Dmitry Morozovsky wrote: > today, updating one of my machines, I got the following mysterious results > after reboot: > > root@ogre:~# sysctl -a | grep RELE > kern.osrelease: 6.3-RELEASE > kern.version: FreeBSD 6.3-RELEASE #4: Thu Jan 17 15:28:57 MSK 2008 > root@ogre:~# strings /boot/kernel/kernel | grep RELE > AE_RELEASE_DEADLOCK > 6.3-RELEASE-p4 > FreeBSD 6.3-RELEASE-p4 #6: Sun Sep 7 23:13:45 MSD 2008 > @(#)FreeBSD 6.3-RELEASE-p4 #6: Sun Sep 7 23:13:45 MSD 2008 > root@ogre:~# env | grep -i uname > root@ogre:~# > > WTF? Why my kernel reports that it is previous version (actually it is already > deleted, so I'm double puzzled) What does "sysctl kern.bootfile" say? And are you sure that you rebooted the right machine? ;-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -- Robert Firth From linimon at lonesome.com Mon Sep 8 22:50:08 2008 From: linimon at lonesome.com (Mark Linimon) Date: Mon Sep 8 22:50:15 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: <20080907080624.078e7e13.bsd-unix@embarqmail.com> References: <20080905213656.BDB444500F@ptavv.es.net> <20080906141423.N439@sola.nimnet.asn.au> <1220762797.29265.43.camel@bauer.cse.buffalo.edu> <20080907080624.078e7e13.bsd-unix@embarqmail.com> Message-ID: <20080908225008.GA28908@soaustin.net> On Sun, Sep 07, 2008 at 08:06:24AM -0400, Randy Pratt wrote: > Additionally, I've never seen a clear way of synchronizing a > local ports tree to that used to create the "LATEST" packages. There's really not a way to easily track this, especially with the fact that we tend to run incremental updates. The best approximation we can give you is e.g.: http://pointyhat.freebsd.org/errorlogs/amd64-6-latest/cvsdone but if there were manual updates to the tree, then the cvsdone files may be out-of-date. In addition, if there were checkins in progress as of that time, the tree may be inconsistent in the first place :-/ I used to have a page that indexed those and a lot of other statistics but it is currently broken. I need to put fixing that on the TODO list. mcl From bsd-unix at embarqmail.com Tue Sep 9 02:27:35 2008 From: bsd-unix at embarqmail.com (Randy Pratt) Date: Tue Sep 9 02:27:42 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: <20080908225008.GA28908@soaustin.net> References: <20080905213656.BDB444500F@ptavv.es.net> <20080906141423.N439@sola.nimnet.asn.au> <1220762797.29265.43.camel@bauer.cse.buffalo.edu> <20080907080624.078e7e13.bsd-unix@embarqmail.com> <20080908225008.GA28908@soaustin.net> Message-ID: <20080908222731.1e360766.bsd-unix@embarqmail.com> On Mon, 8 Sep 2008 17:50:08 -0500 linimon@lonesome.com (Mark Linimon) wrote: > On Sun, Sep 07, 2008 at 08:06:24AM -0400, Randy Pratt wrote: > > Additionally, I've never seen a clear way of synchronizing a > > local ports tree to that used to create the "LATEST" packages. > > There's really not a way to easily track this, especially with the > fact that we tend to run incremental updates. The best approximation > we can give you is e.g.: > > http://pointyhat.freebsd.org/errorlogs/amd64-6-latest/cvsdone > > but if there were manual updates to the tree, then the cvsdone files > may be out-of-date. In addition, if there were checkins in progress > as of that time, the tree may be inconsistent in the first place :-/ > > I used to have a page that indexed those and a lot of other statistics > but it is currently broken. I need to put fixing that on the TODO list. If its not an easy thing to do then its probably not worth spending Release Engineering time on it. Personally, I quit using packages in the 2.x-3.x days since there were far less problems building everything from sources and not trying to mix pre-built packages and locally built ports. That was the only reason I mentioned the syncronization. Thanks for taking the time to explain why it isn't an easy thing to do! Randy -- From linimon at lonesome.com Tue Sep 9 04:40:45 2008 From: linimon at lonesome.com (Mark Linimon) Date: Tue Sep 9 04:40:52 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: <20080908222731.1e360766.bsd-unix@embarqmail.com> References: <20080905213656.BDB444500F@ptavv.es.net> <20080906141423.N439@sola.nimnet.asn.au> <1220762797.29265.43.camel@bauer.cse.buffalo.edu> <20080907080624.078e7e13.bsd-unix@embarqmail.com> <20080908225008.GA28908@soaustin.net> <20080908222731.1e360766.bsd-unix@embarqmail.com> Message-ID: <20080909044044.GB1307@soaustin.net> On Mon, Sep 08, 2008 at 10:27:31PM -0400, Randy Pratt wrote: > Personally, I quit using packages in the 2.x-3.x days since there were > far less problems building everything from sources and not trying to > mix pre-built packages and locally built ports. We are doing much better these days in terms of building packages quickly, especially on amd64 and to some extent i386. More hardware has helped. However, with over 19,000 makefile and makefile parts involved, there's really only so much that can be done outside of the QA/freeze timeframes. mcl From dominique.goncalves at gmail.com Tue Sep 9 11:52:22 2008 From: dominique.goncalves at gmail.com (Dominique Goncalves) Date: Tue Sep 9 11:52:30 2008 Subject: HDD USB still on after computer shutdown In-Reply-To: <20080828111526.GA5373@holstein.holy.cow> References: <7daacbbe0808261055w62f46ebah93b2b595011c6117@mail.gmail.com> <20080828111526.GA5373@holstein.holy.cow> Message-ID: <7daacbbe0809090452x56453123j27fc080f9a01dc56@mail.gmail.com> Hi Parv, On Thu, Aug 28, 2008 at 1:15 PM, Parv wrote: > in message <7daacbbe0808261055w62f46ebah93b2b595011c6117@mail.gmail.com>, > wrote Dominique Goncalves thusly... >> >> I use FreeBSD 6.3-STABLE and an HDD USB (Maxtor, external PSU, >> 500GB). When I shutdown my computer (shutdown -p now ) the HDD >> USB is still on. In Windows XP it works, the HDD USB is off. >> >> Is there a way to resolve this issue? >> >> %dmesg > ... > > I have a Thinkpad T61 laptop which has a section in BIOS > configuration titled "USB something-or-other". When a particular > subsection is activated, the "help text" mentions along the lines > that enabling the option would continue to power USB ports for > connected devices after shutdown. > > So do poke around in BIOS, unless of course somebody else could > offer a solution to be executed within FreeBSD. Sorry for being so long to answer. I've not found an option about this in the bios. I'll give a try on acpi mailing list. Thanks anyway for your help! > > - Parv > > -- > > Regards. -- There's this old saying: "Give a man a fish, feed him for a day. Teach a man to fish, feed him for life." From bms at incunabulum.net Tue Sep 9 14:05:45 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Tue Sep 9 14:07:20 2008 Subject: Panic when detaching Vodafone 3G card Message-ID: <48C682B7.8000806@incunabulum.net> Hi, I just acquired one of these cards, it attaches as a USB cardbus device. This is just to say that I can reproduce the problem described here: http://www.rinta-aho.org/docs/option3g/option.html The driver support was originally committed here: http://www.freebsd.org/cgi/query-pr.cgi?pr=112161&cat= ...the ubsa driver attaches to the virtual modem port. If I unplug it, the kernel panics. The panic is in kobj_delete() (a null pointer reference) and it's on the usb detach path. Unfortunately I wasn't able to get a backtrace this time around. PS Does anybody know if ubsa will be ported to the new USB driver framework? cheers BMS From stefan.lambrev at moneybookers.com Tue Sep 9 16:12:26 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Tue Sep 9 16:12:33 2008 Subject: Panic when detaching Vodafone 3G card In-Reply-To: <48C682B7.8000806@incunabulum.net> References: <48C682B7.8000806@incunabulum.net> Message-ID: <48C6A062.1040205@moneybookers.com> Hi, Bruce M Simpson wrote: > Hi, > > I just acquired one of these cards, it attaches as a USB cardbus device. I have similar problems with Huawei E630, and not just me http://lists.freebsd.org/pipermail/freebsd-current/2007-June/073405.html Panics are fixed with usb4bsd ... :) I didn't find time to get the card actually working and receive a lot of those: ubsa_cfg_request: device request failed, err=USBD_ERR_STALLED (ignored) > > This is just to say that I can reproduce the problem described here: > http://www.rinta-aho.org/docs/option3g/option.html > > The driver support was originally committed here: > http://www.freebsd.org/cgi/query-pr.cgi?pr=112161&cat= > > ...the ubsa driver attaches to the virtual modem port. > > If I unplug it, the kernel panics. > > The panic is in kobj_delete() (a null pointer reference) and it's on > the usb detach path. Unfortunately I wasn't able to get a backtrace > this time around. > > PS Does anybody know if ubsa will be ported to the new USB driver > framework? I think it is because ubsa works with usb4bsd and it's basically the same? > > cheers > BMS > _______________________________________________ > 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" -- Best Wishes, Stefan Lambrev ICQ# 24134177 From pekkas at netcore.fi Tue Sep 9 19:33:59 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Tue Sep 9 19:34:05 2008 Subject: Buildworld Fails RELENG_7 Message-ID: On May 19, Dave Uhring reported the following kind of RELENG_7 buildworld failure: /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/ lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/ libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/ lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H - DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/ lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_openssl.c -o eng_openssl.So /usr/bin/gcc -fpic -DPIC -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/ lib/libcrypto/../../../crypto/openssl -I/usr/src/secure/lib/ libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/ lib/libcrypto -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H - DOPENSSL_NO_IDEA -DL_ENDIAN -DNO_IDEA -std=gnu89 -c /usr/src/secure/ lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_padlock.c -o eng_padlock.So /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c: In function 'padlock_xcrypt_ecb': /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c:445: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/ eng_padlock.c:445: error: 'asm' operand has impossible constraints On May 20, Doug Rabson gave a hint: In this, your build is explicitly using '/usr/bin/gcc' for the build which is not the way buildworld normally works. In normal operation, buildworld first builds a compiler from source and then uses that compiler by adding to $PATH and building with just 'cc'. Are you overriding $CC in your environment? With today's RELENG_7 I spotted a similar kind of compilation problem, and this gave a hint to solving it. In my case, the problem was that I had set the following environment variables (for enabling the compilation of a program): LDFLAGS=-L/usr/local/lib CFLAGS= (or CFLAGS=-pg, not 100% sure) unsetenv'ing these fixed by 'make buildworld'. I wonder if this is something that the build scripts themselves should catch and correct? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From chris# at 1command.com Tue Sep 9 23:21:49 2008 From: chris# at 1command.com (chris#@1command.com) Date: Tue Sep 9 23:21:56 2008 Subject: Is it safe to delete /bin/[ && /usr/bin/false? In-Reply-To: <20080904034519.96acd326.stas@FreeBSD.org> References: <20080902104943.71ub86qsussgoo80@webmail.1command.com> <20080902190919.GE86609@server.vk2pj.dyndns.org> <20080902122551.jfly404kcg00o40w@webmail.1command.com> <20080904034519.96acd326.stas@FreeBSD.org> Message-ID: <20080909162141.b1x2r25k0g4gockk@webmail.1command.com> Hello, and thank you for your reply. Quoting Stanislav Sedov : > On Tue, 02 Sep 2008 12:25:51 -0700 > chris#@1command.com mentioned: > >> >> Good. Perhaps you (or anyone) can suggest how I might debug /when/where/ >> these eval are called. I could use /usr/bin/script, but not sure how to >> (e)grep the culprit(s). >> > > Try to find the exact script which causes this (it'd be pretty easy if you > could find a port with this error reproducible). Then you will be able > to track the problem down by inserting a couple of echos/exits in the > offending script and observing the result. Well, I ultimately found the problem by recognizing a pattern. Since the error messages hadn't proved fatal as far as I could see. I just continued to build as required - always keeping a watchful eye. I began to notice what seemed to be ports checking against Apache were emitting errors, where others were not. Then it occurred to me that my problem was self-inflicted. I had made some changes to the Apache source before making && installing. Because the changes were so unique, I bumped the version by a tenth of a point (1.4x). I then remembered all the Apache make conditionals being against 1.3 || 2 - the light went off in my pointy head; the version /I/ installed was != 1.3 || 2, but > 1.3 < 2. D'OH! Well, no harm has /yet/ come of it. The scripts simply emit the error and continue on their merry way. So unless something bombs farther down the road, I'll just accept/expect the errors knowing what they are trying to tell me. :) Thanks again for responding. --Chris > > -- > Stanislav Sedov > ST4096-RIPE > From chris# at 1command.com Wed Sep 10 00:04:44 2008 From: chris# at 1command.com (chris#@1command.com) Date: Wed Sep 10 00:04:51 2008 Subject: bugged sysinstall, bsdlabel, zfs, gmirror - recept for disaster :) In-Reply-To: <48BE82F6.9070103@kkip.pl> References: <48BE82F6.9070103@kkip.pl> Message-ID: <20080909170437.zarijodao8gcggoo@webmail.1command.com> Congratulations! Thanks for sharing, I'm guessing that you've probably prevented a few ppl from tripping on this by posting this. Me; I'm still waiting for: make zfs ad0s1, ad1s1, ad2s1 install. :-) Best wishes. --Chris Quoting Bartosz Stec : > Hello there! > Here's my story, hopefully some of you won't follow my steps and > avoid some troubles :) > > Yesterday I've decided that's about time to test zfs functionality on > my home server PC (i386 FreeBSD 7.1-pre) . A couple of weeks ago I > bought new desktop PC (with SATA), so I had a bunch of PATA disks > from old one to use in server. Lucky me - there was 3 HDD at size > 40GB - RAIDZ was on approch! > > So after a thirty minutes I had a plan, and my server had 4 disks > connected - one 20GB with actual system (ad1), and three 40GB to > replace actual system (ad[023]). > Plan was simple: > > 1. csup freebsd-stable > 2. follow the tuning guide for zfs, rebuild world, kernel, and > follow system upgrade > 3. Reboot in single user mode > 4. fdisk new disks with sysinstall using one big slice for every disk > 5. bsdlabel every new disk with sysinstall using: 1GB for /, 512MB > for swap, and rest unused (for ZFS) > 6. gmirror -n -v -b round-robin boot ad0s1a ad2s1a ad3s1a > 7. newfs /dev/mirror/boot > 8. mount /dev/mirror/boot /mnt && cd /mnt > 9. dump -h 0 -L -f - -C 32 / | restore rf - > 10. zpool create tank raidz ad0s1d ad2s1d ad3s1d > 11. zfs create new cool filesystems :) > 12. dump | restore old ufs2 filesystem to new cool zfs filesystems :) > 13. changing mount points from tank/foo to /foo > 14. edit new fstab on mirror by replacing root mount point by "boot" > mirror, adding new swaps and remove ald ones and all fs now placed > on zpool > 15. power off system, detach ad1 and power on new system in mixed > gmirror - raidz environment. Yay! > > Well...it has almost works. Sysinstall screw it up. I was always too > lazy to read man bsdlabel, that's why I've been using this "nice" > tool for disk related tasks. Such a mistake! > Problem with labels created with sysinstal, is that it aks for a > mount point for every partition in slice. Well, in my case it was > unwanted behaviour, so on every disk I created first: > > a: / b: swap > c: none > d: /foo > > Then by using "M" key I removed mount points and saved changes with > "W". At this point everything seems ok. So I've added gmirror to > loader.conf and run "gmirror label -n -v -b round-robin boot ad0s1a > ad2s1a ad3s1a". Still ok until now. Next step - kldload geom_mirror. > Here's disaster! System became unresponsible and hangs after a while. > Reboot didn't help, just after gmirror module was loaded by kernel, > screen was flooded with messages: > > WARNING: Expected rawoffset 0, found 63 > > andy didn't boot. I've made system start only because an old drive > ad1 has no gmirror module added to loader.conf. So after reboot I've > cleared metadata on providers and made some another attempts, but > results were always the same. Finally I have found explanation for > this issue. Man bsdlabel says: > > /offset/ The offset of the start of the partition from the beginning of > the drive in sectors, or *** to have *bsdlabel* calculate > the correct > offset to use (the end of the previous partition plus one, ignor- > ing partition `c'). For partition `c', *** will be interpreted as > an offset of 0. The first partition should start at offset 16, > because the first 16 sectors are reserved for metadata. > > > So proper labels for disks should be (and they are now): > > # /dev/ad0s1: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 2097152 16 4.2BSD 0 0 0 > b: 1048576 2097168 swap > c: 78156162 0 unused 0 0 # "raw" > part, don't edit > d: 75010418 3145744 unused 0 0 > > Problem was - Sysinstall has placed partition "a:" starting with > offset 0! This is what happens when you don't RTFM :) I assume that > this bug occured because I created mount point for root on ad[023]s1a > and removed it after, than saved label. It seems that GEOM framework > didn't expect this, neither maual for bsdlabel. I think that should > be fixed somehow. > Fortunately manually editing labels by "bsdlabel -e" wasn't so hard > as I expected. This is how I made everything back to normal: > > a: 1024M * 4.2BSD 0 0 0 > b: 512M * swap > c: 78156162 0 unused 0 0 # "raw" > part, don't edit > d: * * unused 0 0 > > After that, gmirror has stopped pissing me off, and I finished my > plan, as below: > > # zpool status > pool: tank > state: ONLINE > scrub: scrub completed with 0 errors on Wed Sep 3 10:10:07 2008 > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad0s1d ONLINE 0 0 0 > ad2s1d ONLINE 0 0 0 > ad3s1d ONLINE 0 0 0 > > errors: No known data errors > > # gmirror status > Name Status Components > mirror/boot COMPLETE ad0s1a > ad2s1a > ad3s1a > > Good luck with ZFS everyone! :) And RTFM ;) > > -- > Bartosz Stec - specjalista ds. IT > > AUXILIA Sp??ka z o.o. > > > _______________________________________________ > 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 mike at sentex.net Wed Sep 10 02:31:52 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Sep 10 02:31:59 2008 Subject: cvs commit: src/usr.bin/netstat Makefile bpf.c inet.c pfkey.c route.c sctp.c In-Reply-To: <200809011505.m81F5UwC062968@repoman.freebsd.org> References: <200809011505.m81F5UwC062968@repoman.freebsd.org> Message-ID: <200809100231.m8A2VliB098720@lava.sentex.ca> Hi, The change below seems to make netstat -B on RELENG_7 coredump netstat -B specifically, - printf("%5d %6s %7s %9lu %9lu %9lu %5d %5d %s\n", + printf("%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n", Not sure if its a netstat issue or a libc issue as it works fine in HEAD 0[releng7]# gdb /usr/bin/netstat GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... (gdb) r -B Starting program: /usr/bin/netstat -B Pid Netif Flags Recv Drop Match Sblen Hblen Command Program received signal SIGSEGV, Segmentation fault. strlen () at /usr/src/lib/libc/i386/string/strlen.S:48 48 repne /* search! */ Current language: auto; currently asm (gdb) bt #0 strlen () at /usr/src/lib/libc/i386/string/strlen.S:48 #1 0x281c5491 in __vfprintf (fp=0x281e8798, fmt0=0x80671ac "%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n", ap=0xbfbfeba4 "\224\020\020\bA\001") at /usr/src/lib/libc/stdio/vfprintf.c:1052 #2 0x281c37e2 in vfprintf (fp=0x281e8798, fmt0=0x80671ac "%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n", ap=0xbfbfeb74 "A\001") at /usr/src/lib/libc/stdio/vfprintf.c:398 #3 0x281ac086 in printf (fmt=0x80671ac "%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n") at /usr/src/lib/libc/stdio/printf.c:49 #4 0x08059dc4 in bpf_stats (ifname=0x0) at /usr/src/usr.bin/netstat/bpf.c:123 #5 0x080504a1 in main (argc=0, argv=0xbfbfec7c) at /usr/src/usr.bin/netstat/main.c:498 (gdb) bt full #0 strlen () at /usr/src/lib/libc/i386/string/strlen.S:48 No locals. #1 0x281c5491 in __vfprintf (fp=0x281e8798, fmt0=0x80671ac "%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n", ap=0xbfbfeba4 "\224\020\020\bA\001") at /usr/src/lib/libc/stdio/vfprintf.c:1052 fmt = 0x80671d1 "\n" ch = 115 n = 1 n2 = 0 cp = 0x38e38e39 iovp = (struct __siov *) 0xbfbfea04 flags = 0 ret = 80 width = 0 prec = -1 sign = 0 '\0' thousands_sep = 0 '\0' grouping = 0x0 decimal_point = 0x281e35b4 "." signflag = 1 fparg = {dbl = 0, ldbl = 0} expt = 0 expchar = 0 '\0' dtoaend = 0x0 expsize = 0 lead = 1 ndig = 50 expstr = "\000\000\000\000\000\000\000" dtoaresult = 0x0 nseps = 134 nrepeats = 2 ulval = 672080317 ujval = 581017334647357440 base = 10 dprec = 0 realsz = 9 size = 9 prsize = 9 xdigs = 0x0 uio = {uio_iov = 0xbfbfe9fc, uio_iovcnt = 1, uio_resid = 1} iov = {{iov_base = 0x80671ce, iov_len = 1}, {iov_base = 0xbfbfe9f3, iov_len = 9}, {iov_base = 0xbfbfe9fa, iov_len = 2}, { iov_base = 0x0, iov_len = 0}, {iov_base = 0x0, iov_len = 0}, {iov_base = 0x0, iov_len = 0}, {iov_base = 0x0, iov_len = 0}, { iov_base = 0x0, iov_len = 0}} buf = "\003\000\000\000?", '\0' , "select\000\000\000root", '\0' , "dhclient", '\0' to continue, or q to quit--- eats 12 times>, "Fre581017334672080317" ox = "\000" argtable = (union arg *) 0x0 statargtable = {{intarg = 0, uintarg = 0, longarg = 0, ulongarg = 0, longlongarg = 0, ulonglongarg = 0, ptrdiffarg = 0, sizearg = 0, intmaxarg = 0, uintmaxarg = 0, pvoidarg = 0x0, pchararg = 0x0, pschararg = 0x0, pshortarg = 0x0, pintarg = 0x0, plongarg = 0x0, plonglongarg = 0x0, pptrdiffarg = 0x0, psizearg = 0x0, pintmaxarg = 0x0, doublearg = 0, longdoublearg = 0, wintarg = 0, pwchararg = 0x0}, {intarg = 0, uintarg = 0, longarg = 0, ulongarg = 0, longlongarg = 0, ulonglongarg = 0, ptrdiffarg = 0, sizearg = 0, intmaxarg = 0, uintmaxarg = 0, pvoidarg = 0x0, pchararg = 0x0, pschararg = 0x0, pshortarg = 0x0, pintarg = 0x0, plongarg = 0x0, plonglongarg = 0x0, pptrdiffarg = 0x0, psizearg = 0x0, pintmaxarg = 0x0, doublearg = 0, longdoublearg = , wintarg = 0, pwchararg = 0x0}, {intarg = 278, uintarg = 278, longarg = 278, ulongarg = 278, longlongarg = 278, ulonglongarg = 278, ptrdiffarg = 278, sizearg = 278, intmaxarg = 278, uintmaxarg = 278, pvoidarg = 0x116, pchararg = 0x116 , pschararg = 0x116 , pshortarg = 0x116, pintarg = 0x116, plongarg = 0x116, plonglongarg = 0x116, pptrdiffarg = 0x116, psizearg = 0x116, pintmaxarg = 0x116, doublearg = 1.3735024954386654e-321, longdoublearg = , wintarg = 278, pwchararg = 0x116}, {intarg = 423, uintarg = 423, longarg = 423, ulongarg = 423, longlongarg = 137438953895, ulonglongarg = 137438953895, ptrdiffarg = 423, sizearg = 423, intmaxarg = 137438953895, uintmaxarg = 137438953895, pvoidarg = 0x1a7, pchararg = 0x1a7 , pschararg = 0x1a7 , pshortarg = 0x1a7, pintarg = 0x1a7, plongarg = 0x1a7, plonglongarg = 0x1a7, pptrdiffarg = 0x1a7, psizearg = 0x1a7, pintmaxarg = 0x1a7, doublearg = 6.7903865519878482e-313, longdoublearg = 5.0099241040047100945541003353856387e-4940, wintarg = 423, pwchararg = 0x1a7}, {intarg = 0, uintarg = 0, longarg = 0, ulongarg = 0, longlongarg = 0, ulonglongarg = 0, ptrdiffarg = 0, sizearg = 0, intmaxarg = 0, uintmaxarg = 0, pvoidarg = 0x0, pchararg = 0x0, pschararg = 0x0, pshortarg = 0x0, pintarg = 0x0, plongarg = 0x0, plonglongarg = 0x0, pptrdiffarg = 0x0, psizearg = 0x0, pintmaxarg = 0x0, doublearg = 0, longdoublearg = , wintarg = 0, pwchararg = 0x0}, {intarg = 31662, uintarg = 31662, longarg = 31662, ulongarg = 31662, longlongarg = 31662, ulonglongarg = 31662, ptrdiffarg = 31662, sizearg = 31662, intmaxarg = 31662, uintmaxarg = 31662, pvoidarg = 0x7bae, pchararg = 0x7bae , pschararg = 0x7bae , pshortarg = 0x7bae, pintarg = 0x7bae, plongarg = 0x7bae, plonglongarg = 0x7bae, pptrdiffarg = 0x7bae, psizearg = 0x7bae, pintmaxarg = 0x7bae, doublearg = 1.5643106478625548e-319, longdoublearg = , wintarg = 31662, pwchararg = 0x7bae}, {intarg = 0, uintarg = 0, longarg = 0, ulongarg = 0, longlongarg = 5244055244786106368, ulonglongarg = 5244055244786106368, ptrdiffarg = 0, sizearg = 0, intmaxarg = 5244055244786106368, uintmaxarg = 5244055244786106368, pvoidarg = 0x0, pchararg = 0x0, pschararg = 0x0, pshortarg = 0x0, pintarg = 0x0, plongarg = 0x0, plonglongarg = 0x0, pptrdiffarg = 0x0, psizearg = 0x0, pintmaxarg = 0x0, doublearg = 3.9421446362191564e+42, longdoublearg = , wintarg = 0, pwchararg = 0x0}, {intarg = 0, uintarg = 0, longarg = 0, ulongarg = 0, longlongarg = 0, ulonglongarg = 0, ptrdiffarg = 0, sizearg = 0, intmaxarg = 0, uintmaxarg = 0, pvoidarg = 0x0, pchararg = 0x0, pschararg = 0x0, pshortarg = 0x0, pintarg = 0x0, plongarg = 0x0, plonglongarg = 0x0, pptrdiffarg = 0x0, psizearg = 0x0, pintmaxarg = 0x0, doublearg = 0, longdoublearg = , wintarg = 0, pwchararg = 0x0}} nextarg = 10 orgap = 0xbfbfeb74 "A\001" convbuf = 0x0 blanks = ' ' zeroes = '0' xdigs_lower = "0123456789abcdef" ---Type to continue, or q to quit--- xdigs_upper = "0123456789ABCDEF" initial = {__mbstate8 = '\0' , _mbstateL = 0} #2 0x281c37e2 in vfprintf (fp=0x281e8798, fmt0=0x80671ac "%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n", ap=0xbfbfeb74 "A\001") at /usr/src/lib/libc/stdio/vfprintf.c:398 ret = 0 #3 0x281ac086 in printf (fmt=0x80671ac "%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n") at /usr/src/lib/libc/stdio/printf.c:49 ret = 76 ap = 0xbfbfeb74 "A\001" #4 0x08059dc4 in bpf_stats (ifname=0x0) at /usr/src/usr.bin/netstat/bpf.c:123 d = (struct xbpf_d *) 0x8101060 bd = (struct xbpf_d *) 0x8101060 pname = 0x8103030 "dhclient" flagbuf = "-ifs--l\000????" size = 72 #5 0x080504a1 in main (argc=0, argv=0xbfbfec7c) at /usr/src/usr.bin/netstat/main.c:498 tp = (struct protox *) 0x0 ch = -1 (gdb) frame 0 #0 strlen () at /usr/src/lib/libc/i386/string/strlen.S:48 48 repne /* search! */ (gdb) list 43 pushl %edi 44 movl 8(%esp),%edi /* string address */ 45 cld /* set search forward */ 46 xorl %eax,%eax /* set search for null terminator */ 47 movl $-1,%ecx /* set search for lots of characters */ 48 repne /* search! */ 49 scasb 50 notl %ecx /* get length by taking complement */ 51 leal -1(%ecx),%eax /* and subtracting one */ 52 popl %edi (gdb) frame 1 #1 0x281c5491 in __vfprintf (fp=0x281e8798, fmt0=0x80671ac "%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n", ap=0xbfbfeba4 "\224\020\020\bA\001") at /usr/src/lib/libc/stdio/vfprintf.c:1052 1052 size = strlen(cp); Current language: auto; currently c (gdb) list 1047 if (size > prec) 1048 size = prec; 1049 } else 1050 size = prec; 1051 } else 1052 size = strlen(cp); 1053 sign = '\0'; 1054 break; 1055 case 'U': 1056 flags |= LONGINT; (gdb) frame 2 #2 0x281c37e2 in vfprintf (fp=0x281e8798, fmt0=0x80671ac "%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n", ap=0xbfbfeb74 "A\001") at /usr/src/lib/libc/stdio/vfprintf.c:398 398 ret = __vfprintf(fp, fmt0, ap); (gdb) list 393 394 { 395 int ret; 396 397 FLOCKFILE(fp); 398 ret = __vfprintf(fp, fmt0, ap); 399 FUNLOCKFILE(fp); 400 return (ret); 401 } 402 (gdb) frame 3 #3 0x281ac086 in printf (fmt=0x80671ac "%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n") at /usr/src/lib/libc/stdio/printf.c:49 49 ret = vfprintf(stdout, fmt, ap); (gdb) list 44 { 45 int ret; 46 va_list ap; 47 48 va_start(ap, fmt); 49 ret = vfprintf(stdout, fmt, ap); 50 va_end(ap); 51 return (ret); 52 } (gdb) frame 4 #4 0x08059dc4 in bpf_stats (ifname=0x0) at /usr/src/usr.bin/netstat/bpf.c:123 123 (void) printf("%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n", (gdb) list 118 for (d = &bd[0]; d < &bd[size / sizeof(*d)]; d++) { 119 if (ifname && strcmp(ifname, d->bd_ifname) != 0) 120 continue; 121 bpf_flags(d, flagbuf); 122 pname = bpf_pidname(d->bd_pid); 123 (void) printf("%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n", 124 d->bd_pid, d->bd_ifname, flagbuf, 125 d->bd_rcount, d->bd_dcount, d->bd_fcount, 126 d->bd_slen, d->bd_hlen, pname); 127 free(pname); (gdb) p *d $1 = {bd_promisc = 0 '\0', bd_immediate = 1 '\001', bd_hdrcmplt = 0, bd_direction = 1, bd_feedback = 0, bd_async = 0, bd_rcount = 109321, bd_dcount = 0, bd_fcount = 24, bd_sig = 23, bd_slen = 0, bd_hlen = 0, bd_bufsize = 4096, bd_pid = 321, bd_ifname = "nfe0", '\0' , bd_locked = 1} (gdb) p pname $2 = 0x8103030 "dhclient" (gdb) p flagbuf $3 = "-ifs--l\000????" (gdb) frame 5 #5 0x080504a1 in main (argc=0, argv=0xbfbfec7c) at /usr/src/usr.bin/netstat/main.c:498 498 bpf_stats(interface); (gdb) list 493 setgid(getgid()); 494 495 if (Bflag) { 496 if (!live) 497 usage(); 498 bpf_stats(interface); 499 exit(0); 500 } 501 if (mflag) { 502 if (memf != NULL) { (gdb) At 11:05 AM 9/1/2008, David E. O'Brien wrote: >obrien 2008-09-01 15:05:19 UTC > > FreeBSD src repository > > Modified files: (Branch: RELENG_7) > usr.bin/netstat Makefile bpf.c inet.c pfkey.c route.c > sctp.c > Log: > SVN rev 182603 on 2008-09-01 15:05:19Z by obrien > > MFC: r182602: Minimize changes CURRENT<->releng7. > > Revision Changes Path > 1.39.2.1 +1 -0 src/usr.bin/netstat/Makefile > 1.9.2.2 +2 -2 src/usr.bin/netstat/bpf.c > 1.78.2.4 +2 -2 src/usr.bin/netstat/inet.c > 1.5.2.2 +6 -3 src/usr.bin/netstat/pfkey.c > 1.82.2.7 +8 -7 src/usr.bin/netstat/route.c > 1.7.2.3 +4 -4 src/usr.bin/netstat/sctp.c >_______________________________________________ >cvs-all@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/cvs-all >To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From koitsu at FreeBSD.org Wed Sep 10 03:56:29 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Sep 10 03:56:38 2008 Subject: cvs commit: src/usr.bin/netstat Makefile bpf.c inet.c pfkey.c route.c sctp.c In-Reply-To: <200809100231.m8A2VliB098720@lava.sentex.ca> References: <200809011505.m81F5UwC062968@repoman.freebsd.org> <200809100231.m8A2VliB098720@lava.sentex.ca> Message-ID: <20080910035627.GA14487@icarus.home.lan> On Tue, Sep 09, 2008 at 10:31:46PM -0400, Mike Tancsa wrote: > > Hi, > The change below seems to make netstat -B on RELENG_7 coredump > netstat -B > > specifically, > > - printf("%5d %6s %7s %9lu %9lu %9lu %5d %5d %s\n", > + printf("%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n", > > ... > > Not sure if its a netstat issue or a libc issue as it works fine in HEAD The commit: http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/netstat/bpf.c.diff?r1=1.9.2.1;r2=1.9.2.2;f=h Explanation: The variables being printed (bd_rcount, bd_dcount and bd_fcount) are all u_long on RELENG_7 i386 and amd64. See include/net/bpfdesc.h. %lu = unsigned long (i386 returns 4, amd64 returns 8) %ju = unsigned intmax_t (i386 returns 8, amd64 returns 8) The segfault reason should be obvious here; u_long != unsigned intmax_t on i386. This is specific to i386 (which I see you're using from the gdb output); it works fine on amd64. The commit should be backed out or re-worked to work on i386, or more bpf-related pieces from HEAD need to be MFC'd. The reason it might work in HEAD (did you test HEAD i386 or HEAD amd64?) is that HEAD might have the variables in bpfdesc.h declared as something like unsigned intmax_t, which might be a better solution, but MFC'ing that could break things. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From bsam at ipt.ru Wed Sep 10 11:47:56 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Wed Sep 10 11:48:08 2008 Subject: radeon and FreeBSD freeze (was: Re: Do you need x11-drivers/xf86-video-radeonhd-devel?) In-Reply-To: <20080910104936.GR39652@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Wed\, 10 Sep 2008 13\:49\:36 +0300") References: <20080826005920.8aca164b.nork@FreeBSD.org> <20080906080801.8099c753.nork@ninth-nine.com> <47655429@bb.ipt.ru> <20080907163909.e4ed4fab.nork@FreeBSD.org> <36888738@bb.ipt.ru> <20080910104936.GR39652@deviant.kiev.zoral.com.ua> Message-ID: <04728766_-_@bb.ipt.ru> (Since I use RELENG_7, the email should go to stable@. Please trim current@ at reply.) Hello Kostik, Kostik Belousov writes: > On Wed, Sep 10, 2008 at 01:01:33PM +0400, Boris Samorodov wrote: >> Norikatsu Shigemura writes: >> > On Sat, 06 Sep 2008 20:06:50 +0400 >> > Boris Samorodov wrote: >> >> >> > works. To get that result, I made a ports/x11-drivers/xf86-video- >> >> > radeonhd-devel port. Anyone do you need this port, too? >> >> Sure. Thanks! >> > Thank you, I brushed up my port. Please test attached port. >> >> Sorry to inform you but actually I have: >> ----- >> (--) PCI:*(1:0:0) ATI Technologies Inc RV370 [Sapphire X550 Silent] rev 0, Mem @ 0xd0000000/28, 0xfe7e0000/16, I/O @ 0xb000/8, BIOS @ 0xfe7c0000/17 >> (--) PCI: (1:0:1) ATI Technologies Inc RV370 secondary [Sapphire X550 Silent] rev 0, Mem @ 0xfe7f0000/16 >> ----- >> ...which seems to be supported by the radeon (not radeonhd) driver. >> Well, I'd say that my card rather unsupported, since I get freezing >> X with it. So I have to use the vesa driver. > > Could you give more details on the freeze symptoms ? > E.g., is it complete freeze, or is mouse pointer still alive ? The most convenient way to freeze the OS is to finish gnome session. When gdm is reloading the whole mashine freezes at gnome greeter. The mouse cursor freezes while being a clock-buzzer. Ctrl-alt-del doesn't help, only reset does. > Does disabling DRI in xorg.conf fixes the problem ? Didn't try, but may do if it may help. Here is my X-log: ftp://ftp.ipt.ru/pub/tmp/Xorg.0.log WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From olli at lurza.secnetix.de Wed Sep 10 12:08:47 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Sep 10 12:08:53 2008 Subject: Panic when detaching Vodafone 3G card In-Reply-To: <48C682B7.8000806@incunabulum.net> Message-ID: <200809101208.m8AC8ims084480@lurza.secnetix.de> Bruce M Simpson wrote: > I just acquired one of these cards, it attaches as a USB cardbus device. > [...] > If I unplug it, the kernel panics. That's expected and a known problem. The card contains an OHCI controller, but the ohci(4) driver doesn't support detaching. I think that's also the reason why you have to compile ohci statically in your kernel, there's no module for it. Solution: Don't unplug the card. The problem is supposed to be fixed with usb4bsd, but I haven't tried it myself. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Perl will consistently give you what you want, unless what you want is consistency." -- Larry Wall From rnoland at FreeBSD.org Wed Sep 10 12:38:47 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Wed Sep 10 12:38:54 2008 Subject: radeon and FreeBSD freeze (was: Re: Do you need x11-drivers/xf86-video-radeonhd-devel?) In-Reply-To: <04728766_-_@bb.ipt.ru> References: <20080826005920.8aca164b.nork@FreeBSD.org> <20080906080801.8099c753.nork@ninth-nine.com> <47655429@bb.ipt.ru> <20080907163909.e4ed4fab.nork@FreeBSD.org> <36888738@bb.ipt.ru> <20080910104936.GR39652@deviant.kiev.zoral.com.ua> <04728766_-_@bb.ipt.ru> Message-ID: <1221049692.1945.7.camel@wombat.2hip.net> On Wed, 2008-09-10 at 15:47 +0400, Boris Samorodov wrote: > (Since I use RELENG_7, the email should go to stable@. Please trim > current@ at reply.) > > > Hello Kostik, > > Kostik Belousov writes: > > On Wed, Sep 10, 2008 at 01:01:33PM +0400, Boris Samorodov wrote: > >> Norikatsu Shigemura writes: > >> > On Sat, 06 Sep 2008 20:06:50 +0400 > >> > Boris Samorodov wrote: > >> > >> >> > works. To get that result, I made a ports/x11-drivers/xf86-video- > >> >> > radeonhd-devel port. Anyone do you need this port, too? > >> >> Sure. Thanks! > >> > Thank you, I brushed up my port. Please test attached port. > >> > >> Sorry to inform you but actually I have: > >> ----- > >> (--) PCI:*(1:0:0) ATI Technologies Inc RV370 [Sapphire X550 Silent] rev 0, Mem @ 0xd0000000/28, 0xfe7e0000/16, I/O @ 0xb000/8, BIOS @ 0xfe7c0000/17 > >> (--) PCI: (1:0:1) ATI Technologies Inc RV370 secondary [Sapphire X550 Silent] rev 0, Mem @ 0xfe7f0000/16 > >> ----- > >> ...which seems to be supported by the radeon (not radeonhd) driver. > >> Well, I'd say that my card rather unsupported, since I get freezing > >> X with it. So I have to use the vesa driver. > > > > Could you give more details on the freeze symptoms ? > > E.g., is it complete freeze, or is mouse pointer still alive ? > > The most convenient way to freeze the OS is to finish gnome session. > When gdm is reloading the whole mashine freezes at gnome greeter. > The mouse cursor freezes while being a clock-buzzer. Ctrl-alt-del > doesn't help, only reset does. > > > Does disabling DRI in xorg.conf fixes the problem ? > > Didn't try, but may do if it may help. > > Here is my X-log: > ftp://ftp.ipt.ru/pub/tmp/Xorg.0.log Something is very odd here... drm is not being enabled, so it is not at fault. Are all of your ports up to date and built without the nvidia option? (WW) RADEON(0): Direct rendering disabled ... (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found) robert. > > WBR -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080910/706caa8b/attachment.pgp From talon at lpthe.jussieu.fr Wed Sep 10 12:52:02 2008 From: talon at lpthe.jussieu.fr (Michel Talon) Date: Wed Sep 10 12:52:10 2008 Subject: radeon and FreeBSD freeze Message-ID: <20080910122127.GA70086@lpthe.jussieu.fr> Boris Samorodov wrote: > The most convenient way to freeze the OS is to finish gnome session. > When gdm is reloading the whole mashine freezes at gnome greeter. > The mouse cursor freezes while being a clock-buzzer. Ctrl-alt-del > doesn't help, only reset does. > > > Does disabling DRI in xorg.conf fixes the problem ? > > Didn't try, but may do if it may help. This is a well known problem, with radeon cards on machines with Via chipsets. The freeze occurs under FreeBSD, Linux and even Windows, most easily with DRI but sometimes without DRI. The only solution i have found is to exchange the video card on the machine with a Via chipset to an nVidia card, and put the Radeon on a machine with an Intel chipset. Now i have zero problem, including with DRI. The radeon card now drives a beautiful 1920x1200 screen without any problem, and gives a very good display quality. -- Michel TALON From mike at sentex.net Wed Sep 10 13:09:04 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Sep 10 13:09:11 2008 Subject: cvs commit: src/usr.bin/netstat Makefile bpf.c inet.c pfkey.c route.c sctp.c In-Reply-To: <20080910035627.GA14487@icarus.home.lan> References: <200809011505.m81F5UwC062968@repoman.freebsd.org> <200809100231.m8A2VliB098720@lava.sentex.ca> <20080910035627.GA14487@icarus.home.lan> Message-ID: <200809101308.m8AD8v2Y001698@lava.sentex.ca> At 11:56 PM 9/9/2008, Jeremy Chadwick wrote: >The reason it might work in HEAD (did you test HEAD i386 or HEAD amd64?) Yes, amd64 on HEAD actually. ---Mike >is that HEAD might have the variables in bpfdesc.h declared as something >like unsigned intmax_t, which might be a better solution, but MFC'ing >that could break things. > >-- >| Jeremy Chadwick jdc at parodius.com | >| Parodius Networking http://www.parodius.com/ | >| UNIX Systems Administrator Mountain View, CA, USA | >| Making life hard for others since 1977. PGP: 4BD6C0CB | From bsam at ipt.ru Wed Sep 10 13:39:52 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Wed Sep 10 13:39:59 2008 Subject: radeon and FreeBSD freeze In-Reply-To: <1221049692.1945.7.camel@wombat.2hip.net> (Robert Noland's message of "Wed\, 10 Sep 2008 08\:28\:12 -0400") References: <20080826005920.8aca164b.nork@FreeBSD.org> <20080906080801.8099c753.nork@ninth-nine.com> <47655429@bb.ipt.ru> <20080907163909.e4ed4fab.nork@FreeBSD.org> <36888738@bb.ipt.ru> <20080910104936.GR39652@deviant.kiev.zoral.com.ua> <04728766_-_@bb.ipt.ru> <1221049692.1945.7.camel@wombat.2hip.net> Message-ID: <40404018@bb.ipt.ru> Robert Noland writes: > On Wed, 2008-09-10 at 15:47 +0400, Boris Samorodov wrote: >> Kostik Belousov writes: >> > On Wed, Sep 10, 2008 at 01:01:33PM +0400, Boris Samorodov wrote: >> >> Norikatsu Shigemura writes: >> >> > On Sat, 06 Sep 2008 20:06:50 +0400 >> >> > Boris Samorodov wrote: >> >> >> >> >> > works. To get that result, I made a ports/x11-drivers/xf86-video- >> >> >> > radeonhd-devel port. Anyone do you need this port, too? >> >> >> Sure. Thanks! >> >> > Thank you, I brushed up my port. Please test attached port. >> >> >> >> Sorry to inform you but actually I have: >> >> ----- >> >> (--) PCI:*(1:0:0) ATI Technologies Inc RV370 [Sapphire X550 Silent] rev 0, Mem @ 0xd0000000/28, 0xfe7e0000/16, I/O @ 0xb000/8, BIOS @ 0xfe7c0000/17 >> >> (--) PCI: (1:0:1) ATI Technologies Inc RV370 secondary [Sapphire X550 Silent] rev 0, Mem @ 0xfe7f0000/16 >> >> ----- >> >> ...which seems to be supported by the radeon (not radeonhd) driver. >> >> Well, I'd say that my card rather unsupported, since I get freezing >> >> X with it. So I have to use the vesa driver. >> > >> > Could you give more details on the freeze symptoms ? >> > E.g., is it complete freeze, or is mouse pointer still alive ? >> >> The most convenient way to freeze the OS is to finish gnome session. I stand corrected. It's not a freeze but panic -- the machine reboots itself. No core though: ----- Sep 10 17:02:01 host savecore: reboot after panic: page fault Sep 10 17:02:01 host savecore: no dump, not enough free space on device (55888 available, need 359726) Sep 10 17:02:01 host savecore: unsaved dumps found but not saved ----- Don't understand why it's not enough memory: ----- host% swapinfo -h Device 1K-blocks Used Avail Capacity /dev/ad8s1b 4194304 0B 4.0G 0% ----- >> When gdm is reloading the whole mashine freezes at gnome greeter. >> The mouse cursor freezes while being a clock-buzzer. Ctrl-alt-del >> doesn't help, only reset does. >> >> > Does disabling DRI in xorg.conf fixes the problem ? >> >> Didn't try, but may do if it may help. >> >> Here is my X-log: >> ftp://ftp.ipt.ru/pub/tmp/Xorg.0.log > > Something is very odd here... drm is not being enabled, so it is not at > fault. Are all of your ports up to date and built without the nvidia > option? I used to build ports at tinderbox and then unstall packages. I can't find any changes for xorg ports options -- seems that tinderbox uses the defaults. I'm not sure if all (needed?) ports are up-to-date. > (WW) RADEON(0): Direct rendering disabled > ... > (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not > found) May be because the glx extension is loading by default?: ----- (II) "glx" will be loaded by default. ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From bsam at ipt.ru Wed Sep 10 13:48:52 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Wed Sep 10 13:49:03 2008 Subject: radeon and FreeBSD freeze In-Reply-To: <20080910122127.GA70086@lpthe.jussieu.fr> (Michel Talon's message of "Wed\, 10 Sep 2008 14\:21\:27 +0200") References: <20080910122127.GA70086@lpthe.jussieu.fr> Message-ID: <58327942@bb.ipt.ru> Michel Talon writes: > Boris Samorodov wrote: >> The most convenient way to freeze the OS is to finish gnome session. >> When gdm is reloading the whole mashine freezes at gnome greeter. >> The mouse cursor freezes while being a clock-buzzer. Ctrl-alt-del >> doesn't help, only reset does. >> >> > Does disabling DRI in xorg.conf fixes the problem ? >> >> Didn't try, but may do if it may help. > > This is a well known problem, with radeon cards on machines with Via > chipsets. The freeze occurs under FreeBSD, Linux and even Windows, > most easily with DRI but sometimes without DRI. The only solution i have > found is to exchange the video card on the machine with a Via chipset to > an nVidia card, and put the Radeon on a machine with an Intel chipset. > Now i have zero problem, including with DRI. The radeon card now drives > a beautiful 1920x1200 screen without any problem, and gives a very good > display quality. I have an ASUS P5K motherboard with Intel P35/ICH9 chipset together with the radeon card. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From bsam at ipt.ru Wed Sep 10 13:59:58 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Wed Sep 10 14:00:05 2008 Subject: radeon and FreeBSD freeze In-Reply-To: <40404018@bb.ipt.ru> (Boris Samorodov's message of "Wed\, 10 Sep 2008 17\:39\:41 +0400") References: <20080826005920.8aca164b.nork@FreeBSD.org> <20080906080801.8099c753.nork@ninth-nine.com> <47655429@bb.ipt.ru> <20080907163909.e4ed4fab.nork@FreeBSD.org> <36888738@bb.ipt.ru> <20080910104936.GR39652@deviant.kiev.zoral.com.ua> <04728766_-_@bb.ipt.ru> <1221049692.1945.7.camel@wombat.2hip.net> <40404018@bb.ipt.ru> Message-ID: <49363883@bb.ipt.ru> Boris Samorodov writes: > I stand corrected. It's not a freeze but panic -- the machine reboots > itself. No core though: > ----- > Sep 10 17:02:01 host savecore: reboot after panic: page fault > Sep 10 17:02:01 host savecore: no dump, not enough free space on device (55888 available, need 359726) > Sep 10 17:02:01 host savecore: unsaved dumps found but not saved > ----- > > Don't understand why it's not enough memory: > ----- > host% swapinfo -h > Device 1K-blocks Used Avail Capacity > /dev/ad8s1b 4194304 0B 4.0G 0% > ----- It was a /var file system which lacked space. Fixed. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From rnoland at FreeBSD.org Wed Sep 10 14:07:45 2008 From: rnoland at FreeBSD.org (Robert Noland) Date: Wed Sep 10 14:07:52 2008 Subject: radeon and FreeBSD freeze In-Reply-To: <40404018@bb.ipt.ru> References: <20080826005920.8aca164b.nork@FreeBSD.org> <20080906080801.8099c753.nork@ninth-nine.com> <47655429@bb.ipt.ru> <20080907163909.e4ed4fab.nork@FreeBSD.org> <36888738@bb.ipt.ru> <20080910104936.GR39652@deviant.kiev.zoral.com.ua> <04728766_-_@bb.ipt.ru> <1221049692.1945.7.camel@wombat.2hip.net> <40404018@bb.ipt.ru> Message-ID: <1221055651.98457.6.camel@squirrel.corp.cox.com> On Wed, 2008-09-10 at 17:39 +0400, Boris Samorodov wrote: > Robert Noland writes: > > On Wed, 2008-09-10 at 15:47 +0400, Boris Samorodov wrote: > >> Kostik Belousov writes: > >> > On Wed, Sep 10, 2008 at 01:01:33PM +0400, Boris Samorodov wrote: > >> >> Norikatsu Shigemura writes: > >> >> > On Sat, 06 Sep 2008 20:06:50 +0400 > >> >> > Boris Samorodov wrote: > >> >> > >> >> >> > works. To get that result, I made a ports/x11-drivers/xf86-video- > >> >> >> > radeonhd-devel port. Anyone do you need this port, too? > >> >> >> Sure. Thanks! > >> >> > Thank you, I brushed up my port. Please test attached port. > >> >> > >> >> Sorry to inform you but actually I have: > >> >> ----- > >> >> (--) PCI:*(1:0:0) ATI Technologies Inc RV370 [Sapphire X550 Silent] rev 0, Mem @ 0xd0000000/28, 0xfe7e0000/16, I/O @ 0xb000/8, BIOS @ 0xfe7c0000/17 > >> >> (--) PCI: (1:0:1) ATI Technologies Inc RV370 secondary [Sapphire X550 Silent] rev 0, Mem @ 0xfe7f0000/16 > >> >> ----- > >> >> ...which seems to be supported by the radeon (not radeonhd) driver. > >> >> Well, I'd say that my card rather unsupported, since I get freezing > >> >> X with it. So I have to use the vesa driver. > >> > > >> > Could you give more details on the freeze symptoms ? > >> > E.g., is it complete freeze, or is mouse pointer still alive ? > >> > >> The most convenient way to freeze the OS is to finish gnome session. > > I stand corrected. It's not a freeze but panic -- the machine reboots > itself. No core though: > ----- > Sep 10 17:02:01 host savecore: reboot after panic: page fault > Sep 10 17:02:01 host savecore: no dump, not enough free space on device (55888 available, need 359726) > Sep 10 17:02:01 host savecore: unsaved dumps found but not saved > ----- > > Don't understand why it's not enough memory: > ----- > host% swapinfo -h > Device 1K-blocks Used Avail Capacity > /dev/ad8s1b 4194304 0B 4.0G 0% > ----- It's not enough free space on /var to save the core. > >> When gdm is reloading the whole mashine freezes at gnome greeter. > >> The mouse cursor freezes while being a clock-buzzer. Ctrl-alt-del > >> doesn't help, only reset does. > >> > >> > Does disabling DRI in xorg.conf fixes the problem ? > >> > >> Didn't try, but may do if it may help. > >> > >> Here is my X-log: > >> ftp://ftp.ipt.ru/pub/tmp/Xorg.0.log > > > > Something is very odd here... drm is not being enabled, so it is not at > > fault. Are all of your ports up to date and built without the nvidia > > option? > > I used to build ports at tinderbox and then unstall packages. > I can't find any changes for xorg ports options -- seems that > tinderbox uses the defaults. > > I'm not sure if all (needed?) ports are up-to-date. Well, I'm going to go out on a limb here and say the it looks like libGL and / or dri need to be updated. That may not resolve the issue, but it definately doesn't look correct. If that doesn't fix it, a core is going to be the best chance of figuring out exactly what is wrong. robert. > > (WW) RADEON(0): Direct rendering disabled > > ... > > (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not > > found) > > May be because the glx extension is loading by default?: > ----- > (II) "glx" will be loaded by default. > ----- > > > WBR -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080910/fb47b54b/attachment.pgp From besko at msu.edu Wed Sep 10 14:26:55 2008 From: besko at msu.edu (Lisa Besko) Date: Wed Sep 10 14:27:12 2008 Subject: Fixing cvsup bus error Message-ID: <48C7D925.8090108@msu.edu> I'm getting the bus error mentioned in PR bin/124353 and I need a bit more detail on how to apply the patch. Right now I'm getting the following error when I try to do a make on cvsup-without-gui: Fatal Error: bad version stamps: SupTCP.m3 I put the changes in the /usr/local/lib/m3/pkg/m3core/src/unix/freebsd-4.amd64/Unix.i3 file I created the file /usr/local/lib/m3/pkg/m3core/src/runtime/FBSD_AMD64/RTHeapDepC.c since it didn't exist on my system. I'm running 6.4-PRERELEASE I am not clear on where I should be making these changes or when I should make them so if someone would be kind enough to point me in the correct direction I would appreciate it. Thanks, LB From ip at doom.ctinet.ru Wed Sep 10 14:56:41 2008 From: ip at doom.ctinet.ru (Igor Pokrovsky) Date: Wed Sep 10 14:56:48 2008 Subject: Fixing cvsup bus error In-Reply-To: <48C7D925.8090108@msu.edu> References: <48C7D925.8090108@msu.edu> Message-ID: <20080910145637.GA25667@doom.ctinet.ru> On Wed, Sep 10, 2008 at 10:26:45AM -0400, Lisa Besko wrote: > I'm getting the bus error mentioned in PR bin/124353 and I need a bit > more detail on how to apply the patch. > > Right now I'm getting the following error when I try to do a make on > cvsup-without-gui: > > Fatal Error: bad version stamps: SupTCP.m3 > > I put the changes in the > /usr/local/lib/m3/pkg/m3core/src/unix/freebsd-4.amd64/Unix.i3 file > > I created the file > /usr/local/lib/m3/pkg/m3core/src/runtime/FBSD_AMD64/RTHeapDepC.c since > it didn't exist on my system. > > I'm running 6.4-PRERELEASE > > I am not clear on where I should be making these changes or when I > should make them so if someone would be kind enough to point me in the > correct direction I would appreciate it. FYI there is a program called csup in base system which implements probably all aspects of cvsup. -ip From koitsu at FreeBSD.org Wed Sep 10 14:57:54 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Sep 10 14:58:01 2008 Subject: Fixing cvsup bus error In-Reply-To: <48C7D925.8090108@msu.edu> References: <48C7D925.8090108@msu.edu> Message-ID: <20080910145748.GA4295@icarus.home.lan> On Wed, Sep 10, 2008 at 10:26:45AM -0400, Lisa Besko wrote: > I'm getting the bus error mentioned in PR bin/124353 and I need a bit > more detail on how to apply the patch. > > Right now I'm getting the following error when I try to do a make on > cvsup-without-gui: > > Fatal Error: bad version stamps: SupTCP.m3 > > I put the changes in the > /usr/local/lib/m3/pkg/m3core/src/unix/freebsd-4.amd64/Unix.i3 file > > I created the file > /usr/local/lib/m3/pkg/m3core/src/runtime/FBSD_AMD64/RTHeapDepC.c since > it didn't exist on my system. > > I'm running 6.4-PRERELEASE > > I am not clear on where I should be making these changes or when I > should make them so if someone would be kind enough to point me in the > correct direction I would appreciate it. I can see how the PR is confusing in this regard. The problem is with ezm3 (the Modula3 software), which cvsup relies on, and not really with cvsup itself. The patches in the PR (from jkoshky@) are for the ports/lang/ezm3 software. Those patches were added to the lang/ezm3 port about 3 weeks ago: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/ezm3/Makefile.diff?r1=1.18;r2=1.19;f=h http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/ezm3/files/extra-patch-fcntl Are you at all able to update your ports tree using csup, even if just temporarily? If so, the patches should get pulled down, and all you have to do is: * pkg_delete cvsup-without-gui and ezm3 from your system (use pkg_info to find out what their exact names are, then pkg_delete them) Then: # cd /usr/ports/lang/ezm3 # make clean # cd /usr/ports/net/cvsup-without-gui # make clean && make && make install If you cannot update your ports tree, you'll have to download these two files: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/lang/ezm3/Makefile?rev=1.19;content-type=text%2Fplain http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/lang/ezm3/files/extra-patch-fcntl?rev=1.1;content-type=text%2Fplain Take the first URL and save it as /usr/ports/lang/ezm3/Makefile Take the second URL and save it as /usr/ports/lang/ezm3/files/extra-patch-fcntl Then follow the same steps I listed above (starting with the pkg_delete). Hope this helps. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From besko at msu.edu Wed Sep 10 15:10:01 2008 From: besko at msu.edu (Lisa Besko) Date: Wed Sep 10 15:10:07 2008 Subject: Fixing cvsup bus error In-Reply-To: <20080910145748.GA4295@icarus.home.lan> References: <48C7D925.8090108@msu.edu> <20080910145748.GA4295@icarus.home.lan> Message-ID: <48C7E342.6040300@msu.edu> Jeremy, Thanks that helped alot. I used portsnap to update my ports tree then rebuilt ezm3 and cvsup and life is much better. Thanks for the pointer. LB Jeremy Chadwick wrote: > On Wed, Sep 10, 2008 at 10:26:45AM -0400, Lisa Besko wrote: >> I'm getting the bus error mentioned in PR bin/124353 and I need a bit >> more detail on how to apply the patch. >> >> Right now I'm getting the following error when I try to do a make on >> cvsup-without-gui: >> >> Fatal Error: bad version stamps: SupTCP.m3 >> >> I put the changes in the >> /usr/local/lib/m3/pkg/m3core/src/unix/freebsd-4.amd64/Unix.i3 file >> >> I created the file >> /usr/local/lib/m3/pkg/m3core/src/runtime/FBSD_AMD64/RTHeapDepC.c since >> it didn't exist on my system. >> >> I'm running 6.4-PRERELEASE >> >> I am not clear on where I should be making these changes or when I >> should make them so if someone would be kind enough to point me in the >> correct direction I would appreciate it. > > I can see how the PR is confusing in this regard. The problem is with > ezm3 (the Modula3 software), which cvsup relies on, and not really with > cvsup itself. > > The patches in the PR (from jkoshky@) are for the ports/lang/ezm3 > software. Those patches were added to the lang/ezm3 port about 3 > weeks ago: > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/ezm3/Makefile.diff?r1=1.18;r2=1.19;f=h > http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/ezm3/files/extra-patch-fcntl > > Are you at all able to update your ports tree using csup, even if just > temporarily? If so, the patches should get pulled down, and all you > have to do is: > > * pkg_delete cvsup-without-gui and ezm3 from your system (use pkg_info > to find out what their exact names are, then pkg_delete them) > > Then: > > # cd /usr/ports/lang/ezm3 > # make clean > # cd /usr/ports/net/cvsup-without-gui > # make clean && make && make install > > If you cannot update your ports tree, you'll have to download these > two files: > > http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/lang/ezm3/Makefile?rev=1.19;content-type=text%2Fplain > http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/lang/ezm3/files/extra-patch-fcntl?rev=1.1;content-type=text%2Fplain > > Take the first URL and save it as /usr/ports/lang/ezm3/Makefile > > Take the second URL and save it as /usr/ports/lang/ezm3/files/extra-patch-fcntl > > Then follow the same steps I listed above (starting with the > pkg_delete). > > Hope this helps. > From obrien at freebsd.org Wed Sep 10 15:46:38 2008 From: obrien at freebsd.org (David O'Brien) Date: Wed Sep 10 15:46:44 2008 Subject: cvs commit: src/usr.bin/netstat Makefile bpf.c inet.c pfkey.c route.c sctp.c In-Reply-To: <200809100231.m8A2VliB098720@lava.sentex.ca> References: <200809011505.m81F5UwC062968@repoman.freebsd.org> <200809100231.m8A2VliB098720@lava.sentex.ca> Message-ID: <20080910153105.GA93325@dragon.NUXI.org> On Tue, Sep 09, 2008 at 10:31:46PM -0400, Mike Tancsa wrote: > > Hi, > The change below seems to make netstat -B on RELENG_7 coredump > netstat -B > > specifically, > > - printf("%5d %6s %7s %9lu %9lu %9lu %5d %5d %s\n", > + printf("%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n", > > > Not sure if its a netstat issue or a libc issue as it works fine in HEAD Can you test this patch? This will quickly fix the issue, until I can build world with matching the releng7 definitions with CURRENT. Index: bpf.c =================================================================== --- bpf.c (revision 182906) +++ bpf.c (working copy) @@ -122,7 +122,8 @@ bpf_stats(char *ifname) pname = bpf_pidname(d->bd_pid); (void) printf("%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n", d->bd_pid, d->bd_ifname, flagbuf, - d->bd_rcount, d->bd_dcount, d->bd_fcount, + (intmax_t)d->bd_rcount, (intmax_t)d->bd_dcount, + (intmax_t)d->bd_fcount, d->bd_slen, d->bd_hlen, pname); free(pname); } From bsam at ipt.ru Wed Sep 10 16:02:25 2008 From: bsam at ipt.ru (Boris Samorodov) Date: Wed Sep 10 16:02:36 2008 Subject: radeon and FreeBSD freeze In-Reply-To: <1221055651.98457.6.camel@squirrel.corp.cox.com> (Robert Noland's message of "Wed\, 10 Sep 2008 10\:07\:31 -0400") References: <20080826005920.8aca164b.nork@FreeBSD.org> <20080906080801.8099c753.nork@ninth-nine.com> <47655429@bb.ipt.ru> <20080907163909.e4ed4fab.nork@FreeBSD.org> <36888738@bb.ipt.ru> <20080910104936.GR39652@deviant.kiev.zoral.com.ua> <04728766_-_@bb.ipt.ru> <1221049692.1945.7.camel@wombat.2hip.net> <40404018@bb.ipt.ru> <1221055651.98457.6.camel@squirrel.corp.cox.com> Message-ID: <13682250@bb.ipt.ru> Robert Noland writes: > On Wed, 2008-09-10 at 17:39 +0400, Boris Samorodov wrote: >> Don't understand why it's not enough memory: >> ----- >> host% swapinfo -h >> Device 1K-blocks Used Avail Capacity >> /dev/ad8s1b 4194304 0B 4.0G 0% >> ----- > > It's not enough free space on /var to save the core. Yes, I've fixed it. Thanks. >> >> When gdm is reloading the whole mashine freezes at gnome greeter. >> >> The mouse cursor freezes while being a clock-buzzer. Ctrl-alt-del >> >> doesn't help, only reset does. >> >> >> >> > Does disabling DRI in xorg.conf fixes the problem ? >> >> >> >> Didn't try, but may do if it may help. >> >> >> >> Here is my X-log: >> >> ftp://ftp.ipt.ru/pub/tmp/Xorg.0.log >> > >> > Something is very odd here... drm is not being enabled, so it is not at >> > fault. Are all of your ports up to date and built without the nvidia >> > option? >> >> I used to build ports at tinderbox and then unstall packages. >> I can't find any changes for xorg ports options -- seems that >> tinderbox uses the defaults. >> >> I'm not sure if all (needed?) ports are up-to-date. > > Well, I'm going to go out on a limb here and say the it looks like libGL > and / or dri need to be updated. That may not resolve the issue, but it > definately doesn't look correct. If that doesn't fix it, a core is > going to be the best chance of figuring out exactly what is wrong. Upgraded to the latest packages, got five total freezes w/o dump (only reset helped). I'm rather reluctant to continue experiments for now -- it's my main machine for the day-job. May be some time later... Returning to the vesa driver. Robert and others -- thank you for your help! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From mike at sentex.net Wed Sep 10 16:19:06 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Sep 10 16:19:15 2008 Subject: cvs commit: src/usr.bin/netstat Makefile bpf.c inet.c pfkey.c route.c sctp.c In-Reply-To: <20080910153105.GA93325@dragon.NUXI.org> References: <200809011505.m81F5UwC062968@repoman.freebsd.org> <200809100231.m8A2VliB098720@lava.sentex.ca> <20080910153105.GA93325@dragon.NUXI.org> Message-ID: <200809101618.m8AGIxM5002508@lava.sentex.ca> At 11:31 AM 9/10/2008, David O'Brien wrote: >On Tue, Sep 09, 2008 at 10:31:46PM -0400, Mike Tancsa wrote: > > > > Hi, > > The change below seems to make netstat -B on RELENG_7 coredump > > netstat -B > > > > specifically, > > > > - printf("%5d %6s %7s %9lu %9lu %9lu %5d %5d %s\n", > > + printf("%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n", > > > > > > Not sure if its a netstat issue or a libc issue as it works fine in HEAD > >Can you test this patch? Hi, Thanks! Yes, it does fix the problem for me on my i386 RELENG_7 box ---Mike >This will quickly fix the issue, until I can >build world with matching the releng7 definitions with CURRENT. > > >Index: bpf.c >=================================================================== >--- bpf.c (revision 182906) >+++ bpf.c (working copy) >@@ -122,7 +122,8 @@ bpf_stats(char *ifname) > pname = bpf_pidname(d->bd_pid); > (void) printf("%5d %6s %7s %9ju %9ju %9ju %5d %5d %s\n", > d->bd_pid, d->bd_ifname, flagbuf, >- d->bd_rcount, d->bd_dcount, d->bd_fcount, >+ (intmax_t)d->bd_rcount, (intmax_t)d->bd_dcount, >+ (intmax_t)d->bd_fcount, > d->bd_slen, d->bd_hlen, pname); > free(pname); > } From marck at rinet.ru Wed Sep 10 17:14:00 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Wed Sep 10 17:14:08 2008 Subject: mysterious uname non-updates In-Reply-To: <200809081705.m88H5Pdh083088@lurza.secnetix.de> References: <200809081705.m88H5Pdh083088@lurza.secnetix.de> Message-ID: On Mon, 8 Sep 2008, Oliver Fromme wrote: OF> > today, updating one of my machines, I got the following mysterious results OF> > after reboot: OF> > OF> > root@ogre:~# sysctl -a | grep RELE OF> > kern.osrelease: 6.3-RELEASE OF> > kern.version: FreeBSD 6.3-RELEASE #4: Thu Jan 17 15:28:57 MSK 2008 OF> > root@ogre:~# strings /boot/kernel/kernel | grep RELE OF> > AE_RELEASE_DEADLOCK OF> > 6.3-RELEASE-p4 OF> > FreeBSD 6.3-RELEASE-p4 #6: Sun Sep 7 23:13:45 MSD 2008 OF> > @(#)FreeBSD 6.3-RELEASE-p4 #6: Sun Sep 7 23:13:45 MSD 2008 OF> > root@ogre:~# env | grep -i uname OF> > root@ogre:~# OF> > OF> > WTF? Why my kernel reports that it is previous version (actually it is already OF> > deleted, so I'm double puzzled) OF> OF> What does "sysctl kern.bootfile" say? OF> And are you sure that you rebooted the right machine? ;-) sysctl kern.bootfile said correct /boot/kernel/kernel And it was the right machine, but... in a bit "interesting" configuration: there are two pairs of mirrored disks: ad4/ad6 with gmirror, and ad8/ad10 from previous installation, from which I did migrate to the first pair. All file systems are refered as /dev/mirror/* Strange and mysterious thing was sourced by ad8 somehow activated to be *BIOS BOOT DISK* - so boot blocks, loader *and kernel* was loaded from there, but root mounted from correct /dev/mirror/m0a. Removing old pair of disks returned situation to controllable ;-) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From nork at FreeBSD.org Wed Sep 10 17:17:16 2008 From: nork at FreeBSD.org (Norikatsu Shigemura) Date: Wed Sep 10 17:17:23 2008 Subject: Panic when detaching Vodafone 3G card In-Reply-To: <200809101208.m8AC8ims084480@lurza.secnetix.de> References: <48C682B7.8000806@incunabulum.net> <200809101208.m8AC8ims084480@lurza.secnetix.de> Message-ID: <20080911021714.b175db96.nork@FreeBSD.org> On Wed, 10 Sep 2008 14:08:44 +0200 (CEST) Oliver Fromme wrote: > Bruce M Simpson wrote: > > I just acquired one of these cards, it attaches as a USB cardbus device. > > [...] > > If I unplug it, the kernel panics. > That's expected and a known problem. The card contains > an OHCI controller, but the ohci(4) driver doesn't support > detaching. I think that's also the reason why you have > to compile ohci statically in your kernel, there's no > module for it. > Solution: Don't unplug the card. Ah! I know this issue. It has been fixed by imp@ at AsiaBSDCon2008, but not committed:-(. Please see also: http://people.freebsd.org/~imp/usb-detach.diff From jb000002 at mr-happy.com Wed Sep 10 20:34:53 2008 From: jb000002 at mr-happy.com (Jeff Blank) Date: Wed Sep 10 20:35:01 2008 Subject: can't see non-root writes to /dev/console Message-ID: <20080910203445.GA8561@mr-happy.com> I just upgraded a RELENG_7 (amd64) box from 20080714 to "latest" (which seems to be from a few days ago--no changes from Monday morning's csup to today's) and can no longer see the effect of writing to /dev/console as non-root. When I log in using xdm, my user owns /dev/console, mode 0622 (-rw--w--w-), and I start an 'xterm -C'. But when I, for example, echo foo > /dev/console I see nothing in the console xterm. No error messages, and echo exits 0. If I su to root and do the same, I get 'foo' in the same console xterm. Syslog messages to /dev/console also appear, of course. All the above applies to xconsole as well, not just xterm. I did recompile xterm from 20080616 ports, but it didn't fix the issue (didn't expect it to, as xterm clearly has no trouble attaching and reading). So my echo is getting lost in the kernel, I guess. Known problem? Intentional change? Something else? thanks, Jeff From jb000002 at mr-happy.com Wed Sep 10 20:43:01 2008 From: jb000002 at mr-happy.com (Jeff Blank) Date: Wed Sep 10 20:43:09 2008 Subject: can't see non-root writes to /dev/console In-Reply-To: <20080910203445.GA8561@mr-happy.com> References: <20080910203445.GA8561@mr-happy.com> Message-ID: <20080910204259.GB8561@mr-happy.com> On Wed, Sep 10, 2008 at 04:34:51PM -0400, Jeff Blank wrote: > I just upgraded a RELENG_7 (amd64) box from 20080714 to "latest" > (which seems to be from a few days ago--no changes from Monday > morning's csup to today's) and can no longer see the effect of writing > to /dev/console as non-root. Sorry, I should have mentioned that my kernel is GENERIC + 'options DEVICE_POLLING'. And I guess I havn't updated my kernel config file since the last time amd64/GENERIC changed, but the only (other) differences are that I don't have device lines for igb, age, et, or jme. Jeff From bms at incunabulum.net Wed Sep 10 22:19:12 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Wed Sep 10 22:19:21 2008 Subject: Intel ICH7 SMBus support, ichsmb(4) Message-ID: <48C847DE.7040508@incunabulum.net> Hi there, I have been looking at a system which has the Intel ICH7 south bridge. Whenever I try to probe the SMBus on this system with 'smbmsg -p', I get a lot of status=41 timeout messages in dmesg from the ichsmb(4) driver. I have been given the addresses of the SMBus peripherals and have tried initiating reads to their register space directly using 'smbmsg', with the same result. * Has anyone seen the same issues with the ICH7? * Does anyone know of any userland code I could use as an alternative to the ichsmb(4) driver? I looked at mbmon, it appears it relies on the smb(4) drivers; its direct ISA access only works for specific hardware monitoring chips which appear on the ISA/LPC bus and does not implement SMBus bit-banging in userland. Many many thanks for any help you can provide. cheers BMS From unixmania at gmail.com Thu Sep 11 01:54:28 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Thu Sep 11 01:54:35 2008 Subject: can't see non-root writes to /dev/console In-Reply-To: <20080910203445.GA8561@mr-happy.com> References: <20080910203445.GA8561@mr-happy.com> Message-ID: On Wed, Sep 10, 2008 at 5:34 PM, Jeff Blank wrote: > I just upgraded a RELENG_7 (amd64) box from 20080714 to "latest" > (which seems to be from a few days ago--no changes from Monday > morning's csup to today's) and can no longer see the effect of writing > to /dev/console as non-root. When I log in using xdm, my user owns > /dev/console, mode 0622 (-rw--w--w-), and I start an 'xterm -C'. But > when I, for example, > > echo foo > /dev/console > > I see nothing in the console xterm. No error messages, and echo exits > 0. If I su to root and do the same, I get 'foo' in the same console > xterm. Syslog messages to /dev/console also appear, of course. All > the above applies to xconsole as well, not just xterm. I did > recompile xterm from 20080616 ports, but it didn't fix the issue > (didn't expect it to, as xterm clearly has no trouble attaching and > reading). So my echo is getting lost in the kernel, I guess. > > Known problem? Intentional change? Something else? I have seen this problem since 6.x times and still on 7.x. I also noticed that if I send something to the console after xconsole starts then I can sned messages as an ordinary user. My workaround was modifying the Xsetup_0 script (I used xdm for login), adding a line with (sleep 3; date >> "$dev_console") & just after starting xconsole. I didn't have time to set up a machine with 8-CURRENT yet, so I could not check if the new mp-safe tty implementation fixes this, either intentionally or by a fortunate side effect. -- cd /usr/ports/sysutils/life make clean From koitsu at FreeBSD.org Thu Sep 11 04:33:29 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 11 04:33:37 2008 Subject: Intel ICH7 SMBus support, ichsmb(4) In-Reply-To: <48C847DE.7040508@incunabulum.net> References: <48C847DE.7040508@incunabulum.net> Message-ID: <20080911043326.GA19290@icarus.home.lan> On Wed, Sep 10, 2008 at 11:19:10PM +0100, Bruce M Simpson wrote: > Hi there, > > I have been looking at a system which has the Intel ICH7 south bridge. > > Whenever I try to probe the SMBus on this system with 'smbmsg -p', I get > a lot of status=41 timeout messages in dmesg from the ichsmb(4) driver. > > I have been given the addresses of the SMBus peripherals and have tried > initiating reads to their register space directly using 'smbmsg', with > the same result. Yes, I have seen this behaviour but *only* when querying a slave address which was incorrect or had no device tied to it. You should not be using the "8-bit data address". > * Has anyone seen the same issues with the ICH7? All of my development on bsdhwmon has been done exclusively on ICH7 chipsets, except for the hardware I don't have access to (which use other chipsets, but still use ichsmb(4)): http://bsdhwmon.parodius.com/ During early development of bsdhwmon, I used smbmsg exclusively for testing. So in that respect, no, I've never seen the problem you report. > * Does anyone know of any userland code I could use as an alternative to > the ichsmb(4) driver? > > I looked at mbmon, it appears it relies on the smb(4) drivers; its > direct ISA access only works for specific hardware monitoring chips > which appear on the ISA/LPC bus and does not implement SMBus bit-banging > in userland. mbmon does not use SMBus properly, or in the way you think it would. It's a bad example. If you would like some real code that interfaces with ichsmb(4) reliably, let me know and I'll send you the current tarball to bsdhwmon. It's very clean/easy to follow code. If you're working on a hardware monitoring tool, possibly it would just be best for me to include support for it in bsdhwmon. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From smithi at nimnet.asn.au Thu Sep 11 07:18:08 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Sep 11 07:18:16 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: <1220762797.29265.43.camel@bauer.cse.buffalo.edu> References: <20080905213656.BDB444500F@ptavv.es.net> <20080906141423.N439@sola.nimnet.asn.au> <1220762797.29265.43.camel@bauer.cse.buffalo.edu> Message-ID: <20080909010813.L439@sola.nimnet.asn.au> On Sun, 7 Sep 2008, Ken Smith wrote: > On Sat, 2008-09-06 at 14:51 +1000, Ian Smith wrote: > > I just booted off the 7.0 disc1 to check, and /usr/local/bin/links is > > still the default browser in Options, available during installation from > > another vty. So I was a bit surprised, on rebooting into my so far not > > much configured 7.0, to find that it hadn't actually been installed. > > > > It's a pretty small package, useful enough to at least read local docs, > > and would be handy installed from disc1 .. and maybe even by bootonly? > > I'm actually planning to go in the opposite direction so to speak as far > as sysinstall is concerned. There are a couple projects in the works to > replace sysinstall, along with the other nifty projects that roll > FreeBSD into "another distro" in Linux-speak. [Please in FreeBSD-speak, to avoid getting called that? 'derivative'? (deriv for short? :) Anything but what world plus dog will inevitably equate to a linux 'distro'. Sorry, bikeshed topic but it tweaked me ..] Yes derivative releases (Freesbie, PC-BSD, Desktop BSD) are Good Things, and your New Direction below sounds like it should faciliate more such. > Basically this is something where one thing can't cater to everyones' > needs/tastes/bikeshed-color. All you need to do is tolerate this thread > long enough to reach this message to see that... :-) Hope you can handle just one more :) > I'm with Scott in that I like the "other distros" being around. I don't > think that necessarily means we shouldn't try harder. But IMHO trying > harder needs to be reflected in a new installer. Lets face it, > sysinstall s*cks... For the type of folks who want the installer to do > more than sysinstall does now sysinstall simply isn't the right tool (no > offense intended). % man sysinstall | tail says it all. However sysinstall has enough bits (modules, really) that don't suck to make its presence still worthy. The wrappers around fdisk and bsdlabel alone are worth a lot, despite a notion that 'real men' figure out cylinder and slice offsets themselves. If even those sections were broken out to separate tools, I'd rarely need to fire up sysinstall to, for example, partition a new disk/slice. And sysinstall's frontend to pkg_add is pretty handy, especially for noobs, though by the time you're doing an FTP install you have to wade through all x,000 packages .. a bit more on this aspect later .. > That said I think "I" (as RE) am stuck with sysinstall being around for > the forseeable future, even after we get a new installer, because some > people are so accustomed to it and it fits their needs (again witness > this thread...). So I do have some plans for sysinstall but as I said > above it'll be more towards a different direction than mentioned above. > > The path I'm planning is based on these observations: > > - Many people believe you should just use sysinstall to install > the baseline system, and any packages/ports installs should > be done post-install. Its hard to say that point of view is > wrong. Indeed, perhaps it should be enforced by some sort of 'yes we have a functioning basic install aboard' flag before allowing postinstall stuff at all? The only times I've ever had problems with sysinstall were when trying to do too much - like selecting lots of assorted packages before having committing the base install, which can be tempting as it is. > - The baseline system and the ports are fundamentally different. > People should be aware of that from the beginning. Yes, though any other installer than sysinstall, unless part of the base system - and therefore not relying on other languages like ruby, python, whatever - might need to install some bits to run? That is, such a separation may sometimes need to be less than religiously enforced? > - At least some of the packages on the ISOs are stale within a > week of release at times; a bit longer than a week in most > cases but ... This is really a separate issue. While many well-connected folks with fast machines tend to advocate updating the ports tree and installing all from source, quite validly, at the other end of the spectrum - those with older, slower and/or smaller kit and/or those still stuck with dialup connections (still very common in other-than-urban Australia, let alone 'developing' countries) it should still be possible to do what I did over 10 years ago; install from CDs, spend some weeks learning and configuring the system and tools before even first putting it online. > - My plans for DVD sized media (still uncertain how that will > factor into 6.4/7.1) are to provide CDROM sized ISOs that have > no packages on them at all (giving people who don't have DVD > drives something they can still install from) and one DVD > sized ISO that has packages. Downloading even 2 CDs at 56k dialup is thinkable, over a couple of days. A 4GB DVD, probably not. Even on my ADSL plan it's heavy. This seems a bit close to forcing the abandonment of pre-DVD kit, in the less well-endowed circumstances I'm advocating for here. FreeBSD's always been able to be installed and setup from multi-CD sets, but I can well see needing to rethink just how these CDs are used .. more below .. > The path will be to finish what I started a while ago when I removed the > X11 options in the "installation distributions" section of sysinstall by > removing the last couple of tidbits that touch packages before you get > to the "Would you like to view the list of available packages?" section > of sysinstall (e.g. the offer to install Linux compatibility on i386). > This will provide us with a clean separation of the baseline system from > the packages. After doing a baseline install you can choose to: > > - reboot and install ports/packages when it comes back up Which means rebooting into, or at least clearly offering some way to 'return' to sysinstall (ono) for the genuine noob, I guess? I know how hard it is to remember just what those genuinely new to BSD know and may not know, but Jordan did do a pretty good job then of making it easy for those knowing very little to get FreeBSD up and running, without needing to hook into the mailing lists and such first. And despite what someone offered, browsing the handbook as a text file is really only for the masochist .. yet the handbook is really essential before you have much of a clue - even with regards installing. It's not even fair to assume that people have ready access to another machine .. > - switch install media to be an FTP server and get a larger > selection of packages to choose from So much larger that it's almost a problem finding stuff you _know_ you want. I did one bootonly-CD install of 6.1-R just to check it out on a blank-slate laptop - and modulo a bit of hunting for packages amongst various incomplete mirrors, for installing packages it was just great, but mostly because I already knew what I wanted. It's a bit too 'flat' when faced with the whole of, say, packages/sysutils, compared to the nice sparse sets on the CDs or even, I imagine, on a single DVD. I wonder would it be possible to use, say, the INDEX off the DVD as a subset to use when viewing the whole banana of an FTP packages install? If so, various people could create various subset INDEXes for different sets of packages, maybe? > - use the available packages if you're installing from DVD As I see it, the problem with packages on multiple CDs has been both the ongoing bloat in package sizes and virtually indeterminate dependencies mandating very nearly intolerable disc swapping in some instances. Everything solid is in packages/All/* the rest are links in directories. Back on 2.2.6 and for 4.x boxes I just copied the CDs to disk images, so I could merrily mount and browse these and pkg_add at will, mostly when logged in remotely, and usually got away with it. One multi-CDs to DVD script I saw handled the problem by updating the INDEX file to change the CD number all to disc 1, as I recall. Perhaps another option instead of DVD is using a USB stick, with same issues. An easy process to put the DVD image onto a stick would be something I could use on this pre-DVD laptop, for instance, despite onlu USB 1.0 .. Another useful way might be a process that sucks up as many CDs that have /packages/* as you care to feed it, copying the package files to their default home in /usr/ports/packages, which I think pkg_add looks in as well - certainly portupgrade/install does. Or to some temporary space you specify, whatever. Copying say 2-6 CDs to a new /usr isn't going to bother anyone, and you can always rm /usr/ports/packages/* This would get away from that mindless disc-swapping scenario, while still letting people download (or otherwise obtain) CD images for say, Xorg plus KDE | Gnome | xfce, which are probably the main things people with smaller/older gear would rather not have to build from source, and for those without net access for FTP at install time. > No matter which approach you use, you're clearly seeing a separation > between the baseline system and the packages/ports. If you want lynx or > links or Gnome or KDE you're aware that they are packages/ports and > simply select them. If you didn't want them then you don't wind up with > them sitting on your disk. Basically I'm saying any of the things that > may have been in the "Distributions" section of sysinstall before (X11 > stuff used to be in the Distributions) are now in the packages section > along with all the other things that are packages. And with the > packages only being available on the DVD sized media we stop needing to > deal with deciding what precious little amount of stuff is worthy of > being on disc1 versus disc2/disc3/etc. and all the disc swapping that > comes with CDROM sized media. So if we got away from CDs being anything other than pieces that go to make up the DVD, or to be copied to .../packages on the HD, we wouldn't have to worry about all that trying to fit stuff sensibly much if at all? I guess another option would be for people who care about this (like me :) figuring out how to make sensible subset CDs that people could use, as above. The actual copy-CD-to-HD script doesn't sound too challenging, so could the 'install from image/s on disk' section be easily hacked/configured to accommodate accessing something like that? > And for at least some arch's we *might* be able to move the livefs > support back onto disc1 if there are no packages there for CDROM sized > media - I haven't had a chance to check if that's still feasible. Sounds worthy. Modulo not wanting to lose CDs, and advocating a useful developing-world install process, it all sounds like improvement to me. Thanks for letting us know what's happening with all this, Ken; hope you can excuse my perhaps too long unspoken concerns this late in the piece. cheers, Ian From mgrant at grant.org Thu Sep 11 09:11:33 2008 From: mgrant at grant.org (Michael Grant) Date: Thu Sep 11 09:11:39 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <4888E207.4020606@FreeBSD.org> References: <854CADB9D95147CAB10BC35887A8E5DC@emea.hubersuhner.net> <62b856460807160743v3fce951eg1b2bd9e50a35ba1d@mail.gmail.com> <487E0D1B.2060902@FreeBSD.org> <20080716203900.5jt4qce17gg0og0o@mail.basicnets.co.uk> <62b856460807241309k3cea60dbh24eea677cd6751f7@mail.gmail.com> <4888E207.4020606@FreeBSD.org> Message-ID: <62b856460809110138o5fb10171h9832ac8b964fa3f6@mail.gmail.com> My box crashed again: panic: kmem_malloc(4096): kmem_map too small: 1073741824 total allocated cpuid = 0 Uptime: 33d11h12m58s Dumping 3327 MB (2 chunks) chunk 0: 1MB (151 pages) ... ok chunk 1: 3327MB (851568 pages) <---hung here Still no valid dump. There is 4gig of physical memory in the machine. In /boot/loader.conf, I currently have the following: vm.kmem_size=1G vm.kmem_size_max=1G vm.kmem_size_scale=2 and in my kernel conf file I have: options KVA_PAGES=512 It stayed up for 33 days this time. Is there anything else I can do? Michael Grant From koitsu at FreeBSD.org Thu Sep 11 09:20:49 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 11 09:20:56 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <62b856460809110138o5fb10171h9832ac8b964fa3f6@mail.gmail.com> References: <62b856460807160743v3fce951eg1b2bd9e50a35ba1d@mail.gmail.com> <487E0D1B.2060902@FreeBSD.org> <20080716203900.5jt4qce17gg0og0o@mail.basicnets.co.uk> <62b856460807241309k3cea60dbh24eea677cd6751f7@mail.gmail.com> <4888E207.4020606@FreeBSD.org> <62b856460809110138o5fb10171h9832ac8b964fa3f6@mail.gmail.com> Message-ID: <20080911092047.GA24499@icarus.home.lan> On Thu, Sep 11, 2008 at 10:38:36AM +0200, Michael Grant wrote: > My box crashed again: > > panic: kmem_malloc(4096): kmem_map too small: 1073741824 total allocated > cpuid = 0 > Uptime: 33d11h12m58s > Dumping 3327 MB (2 chunks) > chunk 0: 1MB (151 pages) ... ok > chunk 1: 3327MB (851568 pages) <---hung here > > Still no valid dump. > > There is 4gig of physical memory in the machine. > > In /boot/loader.conf, I currently have the following: > > vm.kmem_size=1G > vm.kmem_size_max=1G > vm.kmem_size_scale=2 > > and in my kernel conf file I have: > > options KVA_PAGES=512 > > It stayed up for 33 days this time. Is there anything else I can do? First and foremost: are you using ZFS on this machine? If so, there are many tunables you can apply to try and limit this; I'm willing to bet it's ARC which is doing it. See below. In general, it appears that you need to increase the maximum range of kmem. The kernel attempted to utilise more than 1GB, and your limit is 1G. My machines running RELENG_7 on amd64, with only 2GB of RAM installed, use the following tunables in loader.conf: vm.kmem_size="1536M" vm.kmem_size_max="1536M" If ZFS is in use, I recommend these as well: vfs.zfs.arc_min="16M" vfs.zfs.arc_max="64M" vfs.zfs.prefetch_disable="1" Do not increase kmem_size any larger than 1.5GB; the amount of RAM you have in the machine, with regards to RELENG_7, will not help. This is a known limitation which has been fixed in HEAD/CURRENT (where the limit has been increased to 512GB). See the "Kernel" section below; you'll see the applicable item. http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues Your only solution may be to run HEAD/CURRENT. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From 000.fbsd at quip.cz Thu Sep 11 09:51:28 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Thu Sep 11 09:51:37 2008 Subject: Intel ICH7 SMBus support, ichsmb(4) In-Reply-To: <20080911043326.GA19290@icarus.home.lan> References: <48C847DE.7040508@incunabulum.net> <20080911043326.GA19290@icarus.home.lan> Message-ID: <48C8EA38.6090903@quip.cz> Jeremy Chadwick wrote: > On Wed, Sep 10, 2008 at 11:19:10PM +0100, Bruce M Simpson wrote: > >>Hi there, >> >>I have been looking at a system which has the Intel ICH7 south bridge. >> >>Whenever I try to probe the SMBus on this system with 'smbmsg -p', I get >>a lot of status=41 timeout messages in dmesg from the ichsmb(4) driver. >> >>I have been given the addresses of the SMBus peripherals and have tried >>initiating reads to their register space directly using 'smbmsg', with >>the same result. > > > Yes, I have seen this behaviour but *only* when querying a slave address > which was incorrect or had no device tied to it. You should not be > using the "8-bit data address". > > >>* Has anyone seen the same issues with the ICH7? > > > All of my development on bsdhwmon has been done exclusively on ICH7 > chipsets, except for the hardware I don't have access to (which use > other chipsets, but still use ichsmb(4)): > > http://bsdhwmon.parodius.com/ > > During early development of bsdhwmon, I used smbmsg exclusively for > testing. > > So in that respect, no, I've never seen the problem you report. Are you still actively working on bsdhwmon and do you plan to support non-Supermicro servers? I wrote you an e-mail in June about my interest in testing thist project on my servers, but got no reply. I have some Sun Fire X2100 M2 (nVidia chips), IBM x335 (Intel), IBM x336 (Intel) servers and one Supermicro X6DHP-8G (Intel) server. Miroslav Lachman From mgrant at grant.org Thu Sep 11 10:08:49 2008 From: mgrant at grant.org (Michael Grant) Date: Thu Sep 11 10:09:04 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <20080911092047.GA24499@icarus.home.lan> References: <487E0D1B.2060902@FreeBSD.org> <20080716203900.5jt4qce17gg0og0o@mail.basicnets.co.uk> <62b856460807241309k3cea60dbh24eea677cd6751f7@mail.gmail.com> <4888E207.4020606@FreeBSD.org> <62b856460809110138o5fb10171h9832ac8b964fa3f6@mail.gmail.com> <20080911092047.GA24499@icarus.home.lan> Message-ID: <62b856460809110308sa44f057mc08189a97efa9d0c@mail.gmail.com> On Thu, Sep 11, 2008 at 11:20 AM, Jeremy Chadwick wrote: > On Thu, Sep 11, 2008 at 10:38:36AM +0200, Michael Grant wrote: >> My box crashed again: >> >> panic: kmem_malloc(4096): kmem_map too small: 1073741824 total allocated >> cpuid = 0 >> Uptime: 33d11h12m58s >> Dumping 3327 MB (2 chunks) >> chunk 0: 1MB (151 pages) ... ok >> chunk 1: 3327MB (851568 pages) <---hung here >> >> Still no valid dump. >> >> There is 4gig of physical memory in the machine. >> >> In /boot/loader.conf, I currently have the following: >> >> vm.kmem_size=1G >> vm.kmem_size_max=1G >> vm.kmem_size_scale=2 >> >> and in my kernel conf file I have: >> >> options KVA_PAGES=512 >> >> It stayed up for 33 days this time. Is there anything else I can do? > > First and foremost: are you using ZFS on this machine? If so, there are > many tunables you can apply to try and limit this; I'm willing to bet > it's ARC which is doing it. See below. > > In general, it appears that you need to increase the maximum range of > kmem. The kernel attempted to utilise more than 1GB, and your limit is > 1G. My machines running RELENG_7 on amd64, with only 2GB of RAM > installed, use the following tunables in loader.conf: > > vm.kmem_size="1536M" > vm.kmem_size_max="1536M" > > If ZFS is in use, I recommend these as well: > > vfs.zfs.arc_min="16M" > vfs.zfs.arc_max="64M" > vfs.zfs.prefetch_disable="1" > > Do not increase kmem_size any larger than 1.5GB; the amount of RAM you > have in the machine, with regards to RELENG_7, will not help. This is a > known limitation which has been fixed in HEAD/CURRENT (where the limit > has been increased to 512GB). See the "Kernel" section below; you'll > see the applicable item. > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > Your only solution may be to run HEAD/CURRENT. I am not running ZFS. My file systems are ufs. This feels like some sort of memory leak in the kernel. Giving it more and more memory just seems to delay the crash. Are you saying the crash is fixed in HEAD/CURRENT? I'm running 6.3 by the way. I have put your changes into my loader.conf, we'll see how long it goes this time. I'm not qute in position to update everything to 7.x at the moment. Michael Grant From vince at unsane.co.uk Thu Sep 11 10:20:31 2008 From: vince at unsane.co.uk (Vincent Hoffman) Date: Thu Sep 11 10:20:42 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: <20080909010813.L439@sola.nimnet.asn.au> References: <20080905213656.BDB444500F@ptavv.es.net> <20080906141423.N439@sola.nimnet.asn.au> <1220762797.29265.43.camel@bauer.cse.buffalo.edu> <20080909010813.L439@sola.nimnet.asn.au> Message-ID: <48C8F0EA.4030505@unsane.co.uk> Ian Smith wrote: > The wrappers around fdisk and bsdlabel alone are worth a lot, despite a > notion that 'real men' figure out cylinder and slice offsets themselves. > If even those sections were broken out to separate tools, I'd rarely > need to fire up sysinstall to, for example, partition a new disk/slice. > man 8 sade someone kindly pointed this out to me not long ago, very handy. Vince From smithi at nimnet.asn.au Thu Sep 11 10:40:22 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Sep 11 10:40:29 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: <48C8F0EA.4030505@unsane.co.uk> References: <20080905213656.BDB444500F@ptavv.es.net> <20080906141423.N439@sola.nimnet.asn.au> <1220762797.29265.43.camel@bauer.cse.buffalo.edu> <20080909010813.L439@sola.nimnet.asn.au> <48C8F0EA.4030505@unsane.co.uk> Message-ID: <20080911203746.L439@sola.nimnet.asn.au> On Thu, 11 Sep 2008, Vincent Hoffman wrote: > Ian Smith wrote: > > > > The wrappers around fdisk and bsdlabel alone are worth a lot, despite a > > notion that 'real men' figure out cylinder and slice offsets themselves. > > If even those sections were broken out to separate tools, I'd rarely > > need to fire up sysinstall to, for example, partition a new disk/slice. > > man 8 sade > someone kindly pointed this out to me not long ago, very handy. Magic .. thanks Vince. From bms at incunabulum.net Thu Sep 11 10:44:23 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu Sep 11 10:44:32 2008 Subject: alpm(4) I/O range is claimed by ACPI Message-ID: <48C8F684.8090409@incunabulum.net> Hi, How can I load the alpm(4) module for SMBus support on my ASUS Vintage AH-1 system? It appears the I/O range it uses is claimed by the acpi(4) driver. Can I override the mapping in some way i.e. tell ACPI not to claim the range? I don't see anything obvious about this in the acpi(4) man page. thanks, BMS From koitsu at FreeBSD.org Thu Sep 11 10:47:40 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 11 10:47:47 2008 Subject: Intel ICH7 SMBus support, ichsmb(4) In-Reply-To: <48C8EA38.6090903@quip.cz> References: <48C847DE.7040508@incunabulum.net> <20080911043326.GA19290@icarus.home.lan> <48C8EA38.6090903@quip.cz> Message-ID: <20080911104738.GA25493@icarus.home.lan> On Thu, Sep 11, 2008 at 11:51:52AM +0200, Miroslav Lachman wrote: > Are you still actively working on bsdhwmon and do you plan to support > non-Supermicro servers? Yes, I'm still actively working on it -- it is in no way shape or form a dead project. Most of the delays of releasing the software are caused by the following: * No man page or decent documentation -- this is a big show-stopper for me. I hate writing man pages (I write them by hand; I do not believe in using irritating tools to try and do the work for me), and writing one takes quite a bit of time to continually look up troff syntax and what not, * Code comments need to be added and cleaned up -- I need to document my functions better so anyone examining the source can understand it, * Badly-written Makefile with lots of hard-coded settings and options -- I need someone with better familiarity with Make to assist in cleaning this up, * Supermicro not providing me some necessary details (such as how to deal with the 5VCC/5VDD bug on some motherboards), resulting in that specific voltage being calculated wrong -- I've looked at the Linux lm-sensors project to try and get answers, but their code is absolute spaghetti and heavily abstracted, * Many testers not getting back to me with results of their tests -- I've mailed many of the ones who wanted to test, but got no response from them, indicating they lack time or lost interest in helping, * Some users requesting additional features too soon, such as: support for a configuration file, customisable output, and ISA I/O port support. I suppose a lot of these could be addressed if I released the code in a preliminary fashion (providing folks the ability to help me with documentation, etc.). Hmm... Yeah, I should really get a beta tarball up, and/or make a FreeBSD port for it already (since I am a ports committer). Also, I recently discovered that at EuroBSDCon, Constantine Murenin will be giving a talk about the OpenBSD Hardware Sensors Framework: http://2008.eurobsdcon.org/talks.html. This makes me makes me wonder if the project is being re-considered for FreeBSD (it was committed to CURRENT in October 2007 and then backed out after being referred to as a "festering junkpile that does not belong in the kernel", reference: http://lists.freebsd.org/pipermail/cvs-src/2007-October/082398.html). If it is being reconsidered, I think it would make *much* more sense for me to spend my time getting ICHx SMBus support working under that, since the framework provides an interface for me to work with. To answer your 2nd question: yes, I plan on supporting other motherboards and products. The reason that is on hold/back-burner is: * I have contacts at Supermicro who can provide me full register details and provide overall support/help when I need it. I have none of this with Sun, nVidia, IBM, nor Intel. I can assure you that if I mail the general "Technical Support" lists these companies have, the support folks will /dev/null my mails, or simply go "What is this? SMBus slave hardware chip what? What the hell is that? Whatever..." and ignore the mail because it's outside of the norm. I do not believe in "randomly probing the SMBus" to try and find things by trial and error -- the risks are huge! People don't realise that reading registers can cause interrupts or features to be reset or disabled on the chip, which could cause the entire machine (or maybe just the SMBus layer) to lock up. I can assure you none of the bsdhwmon testers will put up with those risks, as most of them are doing testing on actual production servers and are trusting my "play it safe" judgement... * I want to get a good, solid list of Supermicro servers officially supported before moving on to a mix-match of other hardware. I do have very basic support for an AMD-based H/W monitoring chip used in a Supermicro board, but there's no SMBus driver available on FreeBSD for that chipset, so bsdhwmon can't work with it. > I wrote you an e-mail in June about my interest in testing thist > project on my servers, but got no reply. Hmm... I've looked through my mail archives for all of 2008, and I don't see any mail from you pertaining to bsdhwmon. I do see other mails (discussing GRUB, ATA problems, etc.) but nothing about bsdhwmon. I was grepping for 'Miroslav', looking specifically in my mailbox dedicated for koitsu@freebsd.org. Could you resend it? > I have some Sun Fire X2100 M2 (nVidia chips), IBM x335 (Intel), IBM x336 > (Intel) servers and one Supermicro X6DHP-8G (Intel) server. Thanks. I'll add these to my list of servers that I should try to focus on in the near future (since you have hardware available for testing), and mark you down as the contact I should refer to for help/testing. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Thu Sep 11 10:56:33 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 11 10:56:40 2008 Subject: Fresh 7.0 Install: Fatal Trap 12 panic when put under load In-Reply-To: <62b856460809110308sa44f057mc08189a97efa9d0c@mail.gmail.com> References: <487E0D1B.2060902@FreeBSD.org> <20080716203900.5jt4qce17gg0og0o@mail.basicnets.co.uk> <62b856460807241309k3cea60dbh24eea677cd6751f7@mail.gmail.com> <4888E207.4020606@FreeBSD.org> <62b856460809110138o5fb10171h9832ac8b964fa3f6@mail.gmail.com> <20080911092047.GA24499@icarus.home.lan> <62b856460809110308sa44f057mc08189a97efa9d0c@mail.gmail.com> Message-ID: <20080911105631.GB25493@icarus.home.lan> On Thu, Sep 11, 2008 at 12:08:47PM +0200, Michael Grant wrote: > On Thu, Sep 11, 2008 at 11:20 AM, Jeremy Chadwick wrote: > > On Thu, Sep 11, 2008 at 10:38:36AM +0200, Michael Grant wrote: > >> My box crashed again: > >> > >> panic: kmem_malloc(4096): kmem_map too small: 1073741824 total allocated > >> cpuid = 0 > >> Uptime: 33d11h12m58s > >> Dumping 3327 MB (2 chunks) > >> chunk 0: 1MB (151 pages) ... ok > >> chunk 1: 3327MB (851568 pages) <---hung here > >> > >> Still no valid dump. > >> > >> There is 4gig of physical memory in the machine. > >> > >> In /boot/loader.conf, I currently have the following: > >> > >> vm.kmem_size=1G > >> vm.kmem_size_max=1G > >> vm.kmem_size_scale=2 > >> > >> and in my kernel conf file I have: > >> > >> options KVA_PAGES=512 > >> > >> It stayed up for 33 days this time. Is there anything else I can do? > > > > First and foremost: are you using ZFS on this machine? If so, there are > > many tunables you can apply to try and limit this; I'm willing to bet > > it's ARC which is doing it. See below. > > > > In general, it appears that you need to increase the maximum range of > > kmem. The kernel attempted to utilise more than 1GB, and your limit is > > 1G. My machines running RELENG_7 on amd64, with only 2GB of RAM > > installed, use the following tunables in loader.conf: > > > > vm.kmem_size="1536M" > > vm.kmem_size_max="1536M" > > > > If ZFS is in use, I recommend these as well: > > > > vfs.zfs.arc_min="16M" > > vfs.zfs.arc_max="64M" > > vfs.zfs.prefetch_disable="1" > > > > Do not increase kmem_size any larger than 1.5GB; the amount of RAM you > > have in the machine, with regards to RELENG_7, will not help. This is a > > known limitation which has been fixed in HEAD/CURRENT (where the limit > > has been increased to 512GB). See the "Kernel" section below; you'll > > see the applicable item. > > > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > > > Your only solution may be to run HEAD/CURRENT. > > I am not running ZFS. My file systems are ufs. > > This feels like some sort of memory leak in the kernel. Giving it > more and more memory just seems to delay the crash. Are you saying > the crash is fixed in HEAD/CURRENT? It's an intentional crash, not "the program tried to access NULL, which crashed the machine" crash. The kernel wants more memory to accomplish a certain thing, and it's not available. kris@ can explain this in better terms than I can. First and foremost, it would be good to find out what all you are running on this machine (process-wise). A process could be tickling something in the kernel which requires a large amount of memory to be required. I can imagine something like MySQL would require this. Ideally what needs to happen is to debug the kernel or get a full map of kmem to find out what's using what. I believe vmstat -m or vmstat -z output might help. Obviously since the machine panics, you won't be able to run those commands after the fact. I would recommend you set up a cronjob that runs every 1-2 minutes and logs the output of both of those commands to a file. When the panic happens, restart the system and look at the logfile to see if you can figure out if anything suddenly starts taking up a large amount of memory, or if it's a gradual thing (indicating a memory leak). If you can figure out what might be tickling the problem, you can ultimately figure out if increasing kmem is the right thing to do, or if there's a greater problem here. > I'm running 6.3 by the way. > > I have put your changes into my loader.conf, we'll see how long it > goes this time. I'm not qute in position to update everything to 7.x > at the moment. Our production webservers run RELENG_6 and RELENG_7, and we don't encounter this kind of problem. I'm not saying what you're experiencing is indicative of hardware issues or something like that -- I'm simply saying I have loaded systems which don't ever hit that condition. So figuring out what's causing it in your case would be good. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Thu Sep 11 11:04:09 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 11 11:04:17 2008 Subject: alpm(4) I/O range is claimed by ACPI In-Reply-To: <48C8F684.8090409@incunabulum.net> References: <48C8F684.8090409@incunabulum.net> Message-ID: <20080911110407.GC25493@icarus.home.lan> On Thu, Sep 11, 2008 at 11:44:20AM +0100, Bruce M Simpson wrote: > How can I load the alpm(4) module for SMBus support on my ASUS Vintage > AH-1 system? > > It appears the I/O range it uses is claimed by the acpi(4) driver. Can I > override the mapping in some way i.e. tell ACPI not to claim the range? > I don't see anything obvious about this in the acpi(4) man page. Might mention this to jhb@ to see if it's related to the SMBus changes made 1.5 years ago: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/alpm.c I found this thread, which despite being USB-centric, shows someone trying to load alpm(4) on RELENG_6 and getting a map allocation error back in 2003. Not sure if this is of any help: http://lists.freebsd.org/pipermail/freebsd-mobile/2003-April/000190.html http://lists.freebsd.org/pipermail/freebsd-mobile/2003-April/000192.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From 000.fbsd at quip.cz Thu Sep 11 11:49:54 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Thu Sep 11 11:50:02 2008 Subject: Intel ICH7 SMBus support, ichsmb(4) In-Reply-To: <20080911104738.GA25493@icarus.home.lan> References: <48C847DE.7040508@incunabulum.net> <20080911043326.GA19290@icarus.home.lan> <48C8EA38.6090903@quip.cz> <20080911104738.GA25493@icarus.home.lan> Message-ID: <48C905F7.5020306@quip.cz> Jeremy Chadwick wrote: > On Thu, Sep 11, 2008 at 11:51:52AM +0200, Miroslav Lachman wrote: > >>Are you still actively working on bsdhwmon and do you plan to support >>non-Supermicro servers? > > > Yes, I'm still actively working on it -- it is in no way shape or form a > dead project. Most of the delays of releasing the software are caused > by the following: > > * No man page or decent documentation -- this is a big show-stopper > for me. I hate writing man pages (I write them by hand; I do not > believe in using irritating tools to try and do the work for me), and > writing one takes quite a bit of time to continually look up troff > syntax and what not, > > * Code comments need to be added and cleaned up -- I need to document > my functions better so anyone examining the source can understand it, > > * Badly-written Makefile with lots of hard-coded settings and options -- > I need someone with better familiarity with Make to assist in cleaning > this up, > > * Supermicro not providing me some necessary details (such as how > to deal with the 5VCC/5VDD bug on some motherboards), resulting in > that specific voltage being calculated wrong -- I've looked at the Linux > lm-sensors project to try and get answers, but their code is absolute > spaghetti and heavily abstracted, > > * Many testers not getting back to me with results of their tests -- > I've mailed many of the ones who wanted to test, but got no response > from them, indicating they lack time or lost interest in helping, > > * Some users requesting additional features too soon, such as: support > for a configuration file, customisable output, and ISA I/O port > support. > > I suppose a lot of these could be addressed if I released the code in a > preliminary fashion (providing folks the ability to help me with > documentation, etc.). Hmm... Yeah, I should really get a beta tarball > up, and/or make a FreeBSD port for it already (since I am a ports > committer). > > Also, I recently discovered that at EuroBSDCon, Constantine Murenin will > be giving a talk about the OpenBSD Hardware Sensors Framework: > http://2008.eurobsdcon.org/talks.html. This makes me makes me wonder if > the project is being re-considered for FreeBSD (it was committed to > CURRENT in October 2007 and then backed out after being referred to as a > "festering junkpile that does not belong in the kernel", reference: > http://lists.freebsd.org/pipermail/cvs-src/2007-October/082398.html). > If it is being reconsidered, I think it would make *much* more sense for > me to spend my time getting ICHx SMBus support working under that, since > the framework provides an interface for me to work with. > > To answer your 2nd question: yes, I plan on supporting other > motherboards and products. The reason that is on hold/back-burner is: > > * I have contacts at Supermicro who can provide me full register > details and provide overall support/help when I need it. I have none of > this with Sun, nVidia, IBM, nor Intel. I can assure you that if I mail > the general "Technical Support" lists these companies have, the support > folks will /dev/null my mails, or simply go "What is this? SMBus slave > hardware chip what? What the hell is that? Whatever..." and ignore the > mail because it's outside of the norm. > > I do not believe in "randomly probing the SMBus" to try and find things > by trial and error -- the risks are huge! People don't realise that > reading registers can cause interrupts or features to be reset or > disabled on the chip, which could cause the entire machine (or maybe > just the SMBus layer) to lock up. I can assure you none of the bsdhwmon > testers will put up with those risks, as most of them are doing testing > on actual production servers and are trusting my "play it safe" > judgement... > > * I want to get a good, solid list of Supermicro servers officially > supported before moving on to a mix-match of other hardware. I do have > very basic support for an AMD-based H/W monitoring chip used in a > Supermicro board, but there's no SMBus driver available on FreeBSD for > that chipset, so bsdhwmon can't work with it. > > >>I wrote you an e-mail in June about my interest in testing thist >>project on my servers, but got no reply. > > > Hmm... I've looked through my mail archives for all of 2008, and I > don't see any mail from you pertaining to bsdhwmon. I do see other > mails (discussing GRUB, ATA problems, etc.) but nothing about bsdhwmon. > I was grepping for 'Miroslav', looking specifically in my mailbox > dedicated for koitsu@freebsd.org. Could you resend it? re-sent with subject "[Fwd: bsdhwmon [was: Re: cpufreq broken on core2duo]]" >>I have some Sun Fire X2100 M2 (nVidia chips), IBM x335 (Intel), IBM x336 >>(Intel) servers and one Supermicro X6DHP-8G (Intel) server. > > > Thanks. I'll add these to my list of servers that I should try to focus > on in the near future (since you have hardware available for testing), > and mark you down as the contact I should refer to for help/testing. Thank you for your time and for informations! As I have mostly Sun Fire X2100 M2 servers, I have one as spare / testing machine, where I can test potentially "dangerous" code, or give you full access with remote Java based KVM if needed (Sun eLOM). Miroslav Lachman From olli at lurza.secnetix.de Thu Sep 11 12:47:34 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Sep 11 12:47:43 2008 Subject: Fwd: FreeBSD 7.1 Content In-Reply-To: <20080909010813.L439@sola.nimnet.asn.au> Message-ID: <200809111247.m8BClN7i038391@lurza.secnetix.de> Ian Smith wrote: > % man sysinstall | tail says it all. However sysinstall has enough bits > (modules, really) that don't suck to make its presence still worthy. > > The wrappers around fdisk and bsdlabel alone are worth a lot, despite a > notion that 'real men' figure out cylinder and slice offsets themselves. It's not that bad. I agree that fdisk's "user interface" is not pretty. But the most common usage is simply "fdisk -BI" to initialize a new disk to be used by FreeBSD. This is a simple, non-interactive command, so there's no reason to use sysinstall for that. And bsdlabel (formerly disklabel) is actually quite user-friendly. In the most common cases (preparing a fresh disk or slice), you don't have to calculate anything at all. When "bsdlabel -e" drops you into your favourite editor (assuming you have set $EDITOR to something you're familiar with), just enter the partition letters that you need, and their respective sizes. Note you can use "M" and "G" suffixes for MBytes and GBytes; you don't have to calculate sector counts. You can even use percent values, so entering "50%" for the size will use half of the free space on that slice (after subtracting all fixed-size partitions), and "100%" will use all the remaining space, as does "*". Just enter "*" for all the offsets, and they will automatically allocated sequentially. Again, you don't have to calculate anything, unless you really want to. The bsdlabel tool is pretty fool-proof, it checks all data and will warn you if partitons overlap or extend beyond the end of the slice, or if the "c" partition doesn't cover the whole slice. In that case it will refuse to continue, and offer to go back to the editor. Certainly there could be a "nicer" interface for all of that (I'm not saying sade(8) is useless), but I think bsdlabel does its job pretty well, and it is _not_ difficult to use, contrary to what many people seem to believe. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I made up the term 'object-oriented', and I can tell you I didn't have C++ in mind." -- Alan Kay, OOPSLA '97 From bms at incunabulum.net Thu Sep 11 12:55:04 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu Sep 11 12:55:12 2008 Subject: Long delays for USB realbtx boot Message-ID: <48C91525.10806@incunabulum.net> Hi, I have hacked NanoBSD locally to deal with generation of images for booting off USB keys. I am using the RELENG_7 branch as real-mode BTX support is necessary to support USB boot. During testing I noticed that whilst the images eventually boot, there is an extremely long delay before doing so, between when the BIOS reads the boot sector and when the BTX loader messages appear. Test system Time ---------------------------- Thinkpad T43 1m 40s ASUS Vintage AH-1 1m 7s Any ideas why this long delay is occuring? I see this with MBR geometries prepared for both USB-HDD (255H/63S/xxC) and USB-ZIP (64H/32S/xxC) modes. I am not using the strict USB-ZIP mode where everything resides on the 4th slice (da0s4) at the moment, as it requires further NanoBSD patches. I am not currently generating images sized to the entire USB key to save space and time, so the cylinder size is smaller than the physical media, this might also be a factor. Thanks for any light you can shed on this. cheers, BMS From bms at FreeBSD.org Thu Sep 11 14:10:52 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Sep 11 14:10:58 2008 Subject: Long delays for USB realbtx boot In-Reply-To: <48C91525.10806@incunabulum.net> References: <48C91525.10806@incunabulum.net> Message-ID: <48C922BC.4030504@FreeBSD.org> Bruce M Simpson wrote: > ... > During testing I noticed that whilst the images eventually boot, there > is an extremely long delay before doing so, between when the BIOS > reads the boot sector and when the BTX loader messages appear. P.S. It appears none of QEMU, VMware 3.0, or VirtualBox 1.6.6 are able to emulate booting from a USB key in their BIOS, and only QEMU seems to support attaching a disk image on USB, making testing this a bit of a pain (real hardware is always needed). cheers BMS From bms at incunabulum.net Thu Sep 11 14:14:48 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu Sep 11 14:15:02 2008 Subject: alpm(4) I/O range is claimed by ACPI In-Reply-To: <20080911110407.GC25493@icarus.home.lan> References: <48C8F684.8090409@incunabulum.net> <20080911110407.GC25493@icarus.home.lan> Message-ID: <48C927D6.5020800@incunabulum.net> Jeremy Chadwick wrote: > ... > Might mention this to jhb@ to see if it's related to the SMBus changes > made 1.5 years ago: > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/alpm.c > Thanks for the pointers. The other reports sound like duplicate reports of the same issue. I'm not sure that backing out the last change is going to help. The BIOS has generally set up the I/O resource before FreeBSD boots; the bus_set_resource() call might only be useful in those cases where that hasn't happened. In any event, in alpm_attach(), the rman is going to notice that the bus space is already allocated by acpi(4), and will balk. I'm sure there has been some kind of override mechanism in place for certain other drivers; but they seem to boil down to using an ACPI attachment of some kind, which won't work here as alpm(4) is a PCI function and needs to attach to the pcib parent. It would be really, really useful to have working SMBus drivers right now on a machine I can actually touch... cheers BMS From bms at incunabulum.net Thu Sep 11 14:14:54 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu Sep 11 14:15:03 2008 Subject: Any working ichsmb(4) platforms out there? Message-ID: <48C927DC.6000202@incunabulum.net> Does anyone have ichsmb(4) actually seeing SMBus devices? e.g. you run "smbmsg -p" on your FreeBSD-STABLE system and see something. I just tried it again on my IBM ThinkPad T43 and saw nothing, all I get is: ichsmb0: device timeout, status=0x41 ...in dmesg. cheers BMS From bms at FreeBSD.org Thu Sep 11 14:32:06 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Sep 11 14:32:13 2008 Subject: Intel ICH7 SMBus support, ichsmb(4) In-Reply-To: <48C905F7.5020306@quip.cz> References: <48C847DE.7040508@incunabulum.net> <20080911043326.GA19290@icarus.home.lan> <48C8EA38.6090903@quip.cz> <20080911104738.GA25493@icarus.home.lan> <48C905F7.5020306@quip.cz> Message-ID: <48C92BE2.4060906@FreeBSD.org> Miroslav Lachman wrote: > Jeremy Chadwick wrote: > >> I suppose a lot of these could be addressed if I released the code in a >> preliminary fashion (providing folks the ability to help me with >> documentation, etc.). Hmm... Yeah, I should really get a beta tarball >> up, and/or make a FreeBSD port for it already (since I am a ports >> committer). My suggestion would be to make the code available using a Mercurial repository. People are then free to participate and send diffs as they see fit, and they can do so very easily. The learning curve for the tool is reasonable. I'd also recommend http://freehg.org/ if you need some hosting for a public repo. cheers BMS From imb at protected-networks.net Thu Sep 11 14:41:06 2008 From: imb at protected-networks.net (Michael Butler) Date: Thu Sep 11 14:41:14 2008 Subject: Intel ICH7 SMBus support, ichsmb(4) In-Reply-To: <48C92BE2.4060906@FreeBSD.org> References: <48C847DE.7040508@incunabulum.net> <20080911043326.GA19290@icarus.home.lan> <48C8EA38.6090903@quip.cz> <20080911104738.GA25493@icarus.home.lan> <48C905F7.5020306@quip.cz> <48C92BE2.4060906@FreeBSD.org> Message-ID: <48C92DD8.8060808@protected-networks.net> Bruce M. Simpson wrote: > Miroslav Lachman wrote: >> Jeremy Chadwick wrote: >> >>> I suppose a lot of these could be addressed if I released the code in a >>> preliminary fashion (providing folks the ability to help me with >>> documentation, etc.). Hmm... Yeah, I should really get a beta tarball >>> up, and/or make a FreeBSD port for it already (since I am a ports >>> committer). > > My suggestion would be to make the code available using a Mercurial > repository. People are then free to participate and send diffs as they > see fit, and they can do so very easily. The learning curve for the > tool is reasonable. > > I'd also recommend http://freehg.org/ if you need some hosting for a > public repo. What would prevent this being accepted as a loadable module built (by user request) out of the ports tree in much the same manner as kqemu et al.? Michael From richardtector at thekeelecentre.com Thu Sep 11 15:06:28 2008 From: richardtector at thekeelecentre.com (Richard Tector) Date: Thu Sep 11 15:06:35 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: <48C927DC.6000202@incunabulum.net> References: <48C927DC.6000202@incunabulum.net> Message-ID: <48C932D9.50604@thekeelecentre.com> Bruce M Simpson wrote: > Does anyone have ichsmb(4) actually seeing SMBus devices? > e.g. you run "smbmsg -p" on your FreeBSD-STABLE system and see something. > > I just tried it again on my IBM ThinkPad T43 and saw nothing, all I > get is: > ichsmb0: device timeout, status=0x41 > ...in dmesg. I have an ICH9 machine, Tyan motherboard: FreeBSD 7.0-STABLE #0: Fri Aug 1 14:57:33 BST 2008 ichsmb0: port 0x18e0-0x18ff mem 0xf4a03000-0xf4a030ff irq 17 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] daffy# smbmsg -p Probing for devices on /dev/smb0: Device @0x2e: rw Device @0x44: rw Device @0x60: rw Device @0x88: w Device @0xae: rw Device @0xc4: rw Device @0xe0: rw daffy# Any use? Richard From bms at incunabulum.net Thu Sep 11 15:10:12 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu Sep 11 15:10:19 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: <48C932D9.50604@thekeelecentre.com> References: <48C927DC.6000202@incunabulum.net> <48C932D9.50604@thekeelecentre.com> Message-ID: <48C934D1.5030703@incunabulum.net> Richard, Thanks for this. Richard Tector wrote: > > I have an ICH9 machine, Tyan motherboard: > FreeBSD 7.0-STABLE #0: Fri Aug 1 14:57:33 BST 2008 > ichsmb0: port 0x18e0-0x18ff mem > 0xf4a03000-0xf4a030ff irq 17 at device 31.3 on pci0 > ichsmb0: [GIANT-LOCKED] > ichsmb0: [ITHREAD] > > daffy# smbmsg -p > Probing for devices on /dev/smb0: > Device @0x2e: rw ... So it looks like yours works! I see no differences to RELENG_7_0. Are you using any hardware monitoring devices? Can you give bsdhwmon a shot? cheers BMS From bms at FreeBSD.org Thu Sep 11 15:10:45 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Sep 11 15:10:53 2008 Subject: viapm(4) does not see VT8237A on Gigabyte GA-VM900M In-Reply-To: <48C927DC.6000202@incunabulum.net> References: <48C927DC.6000202@incunabulum.net> Message-ID: <48C934F3.5060500@FreeBSD.org> Bruce M Simpson wrote: > Does anyone have ichsmb(4) actually seeing SMBus devices? > e.g. you run "smbmsg -p" on your FreeBSD-STABLE system and see something. > I just tried to port over some of the hardware IDs from OpenBSD 4.3's viapm(4) driver to the driver in 6.3-RELEASE, as I really need to see what working SMBus support looks like in a FreeBSD system. Unfortunately the driver wouldn't attach. It looks like isab already claims the ISA bridge. Is there any trick I can use to get viapm to attach to the ISA bridge controller, without breaking the ISA bus bridge attachment? I am using a Gigabyte GA-VM900M board. thanks, BMS From richardtector at thekeelecentre.com Thu Sep 11 15:16:14 2008 From: richardtector at thekeelecentre.com (Richard Tector) Date: Thu Sep 11 15:16:21 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: <48C934D1.5030703@incunabulum.net> References: <48C927DC.6000202@incunabulum.net> <48C932D9.50604@thekeelecentre.com> <48C934D1.5030703@incunabulum.net> Message-ID: <48C93582.3080107@thekeelecentre.com> Bruce M Simpson wrote: > Richard, > > Thanks for this. > > Richard Tector wrote: >> >> I have an ICH9 machine, Tyan motherboard: >> FreeBSD 7.0-STABLE #0: Fri Aug 1 14:57:33 BST 2008 >> ichsmb0: port 0x18e0-0x18ff mem >> 0xf4a03000-0xf4a030ff irq 17 at device 31.3 on pci0 >> ichsmb0: [GIANT-LOCKED] >> ichsmb0: [ITHREAD] >> >> daffy# smbmsg -p >> Probing for devices on /dev/smb0: >> Device @0x2e: rw > ... > So it looks like yours works! I see no differences to RELENG_7_0. > > Are you using any hardware monitoring devices? > Can you give bsdhwmon a shot? > > cheers > BMS Sure. If yourself or Jeremy could send over the tarball? I don't use any hardware monitoring on it currently. Interestingly, I just tried on a couple of our webservers. Dell PowerEdge 860's with ICH7 running 7.0-STABLE, amd64. Loading the ichsmb module gives: ichsmb0: port 0x8c0-0x8df at device 31.3 on pci0 pcib0: no PRT entry for 0.31.INTB ichsmb0: can't get IRQ device_attach: ichsmb0 attach returned 6 Richard From richardtector at thekeelecentre.com Thu Sep 11 15:25:20 2008 From: richardtector at thekeelecentre.com (Richard Tector) Date: Thu Sep 11 15:25:27 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: <48C93582.3080107@thekeelecentre.com> References: <48C927DC.6000202@incunabulum.net> <48C932D9.50604@thekeelecentre.com> <48C934D1.5030703@incunabulum.net> <48C93582.3080107@thekeelecentre.com> Message-ID: <48C937A3.8040708@thekeelecentre.com> Richard Tector wrote: > Interestingly, I just tried on a couple of our webservers. Dell > PowerEdge 860's with ICH7 running 7.0-STABLE, amd64. Loading the > ichsmb module gives: > > ichsmb0: port 0x8c0-0x8df at > device 31.3 on pci0 > pcib0: no PRT entry for 0.31.INTB > ichsmb0: can't get IRQ > device_attach: ichsmb0 attach returned 6 I found one another ICH7 machine. 6.3-STABLE, i386. It exhibits the same problems you were having. An unkillable smbmsg, and several ichsmb0: device timeout, status=0x41 Regards, Richard From imb at protected-networks.net Thu Sep 11 15:28:46 2008 From: imb at protected-networks.net (Michael Butler) Date: Thu Sep 11 15:29:02 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: <48C93582.3080107@thekeelecentre.com> References: <48C927DC.6000202@incunabulum.net> <48C932D9.50604@thekeelecentre.com> <48C934D1.5030703@incunabulum.net> <48C93582.3080107@thekeelecentre.com> Message-ID: <48C93903.5060604@protected-networks.net> Richard Tector wrote: > Bruce M Simpson wrote: >> Richard, >> >> Thanks for this. >> >> Richard Tector wrote: >>> >>> I have an ICH9 machine, Tyan motherboard: >>> FreeBSD 7.0-STABLE #0: Fri Aug 1 14:57:33 BST 2008 >>> ichsmb0: port 0x18e0-0x18ff mem >>> 0xf4a03000-0xf4a030ff irq 17 at device 31.3 on pci0 >>> ichsmb0: [GIANT-LOCKED] >>> ichsmb0: [ITHREAD] >>> >>> daffy# smbmsg -p >>> Probing for devices on /dev/smb0: >>> Device @0x2e: rw >> ... >> So it looks like yours works! I see no differences to RELENG_7_0. >> >> Are you using any hardware monitoring devices? >> Can you give bsdhwmon a shot? >> >> cheers >> BMS > > Sure. If yourself or Jeremy could send over the tarball? > I don't use any hardware monitoring on it currently. I'd also appreciate the opportunity to try it .. old hardware but .. imb@aaron:/home/imb> devinfo -v | grep smb intsmb0 pnpinfo vendor=0x8086 device=0x7113 subvendor=0x0000 subdevice=0x0000 class=0x068000 at slot=7 function=3 handle=\_SB_.PCI0.PMU_ smbus0 smb0 imb@aaron:/home/imb> kenv | grep smbios smbios.bios.reldate="07/20/2001" smbios.bios.vendor="Intel Corp." smbios.bios.version="TR440BXA.86B.0042.P15.0107200951" smbios.chassis.maker="Dell Computer Corp. " smbios.chassis.serial="YC571 " smbios.chassis.tag=" " smbios.chassis.version="SPAW70W PA[CA] " smbios.planar.maker="Intel Corporation " smbios.planar.product="TR440BXA " smbios.planar.serial="IMTR02702003 " smbios.planar.version="A16643-305 " smbios.socket.enabled="1" smbios.socket.populated="1" smbios.system.maker="Dell Computer Corp. " smbios.system.product="PowerApp.web 100 W " smbios.system.serial="YC571 " smbios.system.uuid="44454c4c-00ca-1059-8043-80c04f353731" smbios.system.version="SPAW70W " imb@aaron:/home/imb> sudo smbmsg -p Probing for devices on /dev/smb0: Device @0x5a: rw Device @0x60: rw Device @0x62: rw Device @0x64: rw Device @0x66: rw Device @0xa0: rw Device @0xa2: rw Device @0xa4: rw Device @0xa6: rw imb@aaron:/home/imb> sudo mbmon -d Using SMBus-ioctl access method[IntelPIIX4(440BX/MX)]!! * Analog Dev. Chip ADM9240 found. From bms at FreeBSD.org Thu Sep 11 15:30:06 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Sep 11 15:30:15 2008 Subject: Long delays for USB realbtx boot In-Reply-To: <48C922BC.4030504@FreeBSD.org> References: <48C91525.10806@incunabulum.net> <48C922BC.4030504@FreeBSD.org> Message-ID: <48C9397C.5000308@FreeBSD.org> Bruce M. Simpson wrote: > Bruce M Simpson wrote: >> ... >> During testing I noticed that whilst the images eventually boot, >> there is an extremely long delay before doing so, between when the >> BIOS reads the boot sector and when the BTX loader messages appear. I can reproduce the boot delay condition on a crusty old A/Open MX3S based, socket 370 Celeron that I keep around for testing stuff like this. [...in another thread, it's documented to have working SMBus-based mbmon support... but I don't have any boot media for it. grrr.] From bms at incunabulum.net Thu Sep 11 15:49:59 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu Sep 11 15:50:05 2008 Subject: Long delays for USB realbtx boot In-Reply-To: <200809111536.m8BFaTqU014459@monk.cnd.dundas.on.ca> References: <200809111536.m8BFaTqU014459@monk.cnd.dundas.on.ca> Message-ID: <48C93E24.8020507@incunabulum.net> [Ccing to list to track up thread] Douglas Berry wrote: > Perhaps this doesn't help... I do RELENG_7 based images > for USB keys/CDROM using the FreesBIE toolkit, and haven't > noticed such delays. I do fill the stick 'tho. Here's > fdisk output... > > ******* Working on device /dev/md4 ******* > parameters extracted from in-core disklabel are: > cylinders=62 heads=255 sectors/track=63 (16065 blks/cyl) > Interesting, that's classic USB-HDD geometry (255H, 63S). Can you tell me what make, model of stick this is? It could be that the cylinder change is what's confusing the BIOS. I will need to do some tweak to make sure the cylinder calculation is right for the stick's capacity. The A/Open MX3S has no USB-HDD mode. It appears to have the same delay issue, however, it didn't see any difference between the USB-HDD geometry image and the USB-ZIP geometry image. %%% empiric:~/shelf/chipdocs/aopen % camcontrol inquiry da0 pass1: Removable Direct Access SCSI-0 device pass1: Serial Number 40.000MB/s transfers empiric:~/shelf/chipdocs/aopen % camcontrol readcap da0 Last Block: 1953791, Block Length: 512 bytes %%% That device uses USB-ZIP style geometry (64H, 32S), and based on the "last block", 1953792 / 2048 is 954 cylinders exactly, which is how it came factory formatted. So I should probably give it a shot based on this. To get something up and running I've been using generic methods in the NanoBSD patch, I haven't sized the MBR geometry specifically to the device. By my reckoning your stick is just under 512MiB, based on the geometry you provided: > parameters to be used for BIOS calculations are: > cylinders=62 heads=255 sectors/track=63 (16065 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 32, size 1001440 (488 Meg), flag 80 (active) > beg: cyl 0/ head 1/ sector 1; > end: cyl 488/ head 63/ sector 32 > The data for partition 2 is: > > The data for partition 3 is: > > The data for partition 4 is: > > cheers BMS From eugen at kuzbass.ru Thu Sep 11 16:30:01 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Thu Sep 11 16:30:09 2008 Subject: Long delays for USB realbtx boot In-Reply-To: <48C91525.10806@incunabulum.net> References: <48C91525.10806@incunabulum.net> Message-ID: <20080911162956.GA15152@svzserv.kemerovo.su> On Thu, Sep 11, 2008 at 01:55:01PM +0100, Bruce M Simpson wrote: > I have hacked NanoBSD locally to deal with generation of images for > booting off USB keys. I am using the RELENG_7 branch as real-mode BTX > support is necessary to support USB boot. > > During testing I noticed that whilst the images eventually boot, there > is an extremely long delay before doing so, between when the BIOS reads > the boot sector and when the BTX loader messages appear. > > Test system Time > ---------------------------- > Thinkpad T43 1m 40s > ASUS Vintage AH-1 1m 7s > > Any ideas why this long delay is occuring? For me, it helps to include these knobs to Nano config file: CONF_WORLD=' BOOT_MBR_FLAGS=0x0 BOOT_BOOT1_FLAGS=0x0 ... ' Eugene Grosbein From doug at bitnix.ca Thu Sep 11 17:07:12 2008 From: doug at bitnix.ca (Douglas Berry) Date: Thu Sep 11 17:07:19 2008 Subject: Long delays for USB realbtx boot In-Reply-To: Your message of "Thu, 11 Sep 2008 16:49:56 BST." <48C93E24.8020507@incunabulum.net> Message-ID: <200809111617.m8BGHAPD014842@monk.cnd.dundas.on.ca> On Thu, 11 Sep 2008 16:49:56 BST, Bruce M Simpson wrote: > Interesting, that's classic USB-HDD geometry (255H, 63S). Can you > tell me what make, model of stick this is? It's Kingston DTI/512 # diskinfo -v da0 da0 512 # sectorsize 512753664 # mediasize in bytes (489M) 1001472 # mediasize in sectors 489 # Cylinders according to firmware. 64 # Heads according to firmware. 32 # Sectors according to firmware. # camcontrol inquiry da0 pass1: Removable Direct Access SCSI-2 device pass1: Serial Number 40.000MB/s transfers cheers, doug From jhb at freebsd.org Thu Sep 11 17:56:51 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Sep 11 17:56:57 2008 Subject: alpm(4) I/O range is claimed by ACPI In-Reply-To: <48C927D6.5020800@incunabulum.net> References: <48C8F684.8090409@incunabulum.net> <20080911110407.GC25493@icarus.home.lan> <48C927D6.5020800@incunabulum.net> Message-ID: <200809111043.18265.jhb@freebsd.org> On Thursday 11 September 2008 10:14:46 am Bruce M Simpson wrote: > Jeremy Chadwick wrote: > > ... > > Might mention this to jhb@ to see if it's related to the SMBus changes > > made 1.5 years ago: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/alpm.c > > > > Thanks for the pointers. The other reports sound like duplicate reports > of the same issue. > > I'm not sure that backing out the last change is going to help. The BIOS > has generally set up the I/O resource before FreeBSD boots; the > bus_set_resource() call might only be useful in those cases where that > hasn't happened. > In any event, in alpm_attach(), the rman is going to notice that the bus > space is already allocated by acpi(4), and will balk. > > I'm sure there has been some kind of override mechanism in place for > certain other drivers; but they seem to boil down to using an ACPI > attachment of some kind, which won't work here as alpm(4) is a PCI > function and needs to attach to the pcib parent. > > It would be really, really useful to have working SMBus drivers right > now on a machine I can actually touch... Umm, ACPI will allow children devices to allocate their resources out of the "sysresource" pool. IPMI has to do this on some systems where ACPI claims the IPMI I/O ports as a system resource. That's what this chunk of code in acpi_alloc_resource() does: /* * If this is an allocation of a specific range, see if we can satisfy * the request from our system resource regions. If we can't, pass the * request up to the parent. */ if (start + count - 1 == end && rm != NULL) res = rman_reserve_resource(rm, start, end, count, flags & ~RF_ACTIVE, child); I'm not sure why you are having issues with SMBus. I know I've been able to use IPMI over SSIF (IPMI over SMBus) using ichsmb0 on some Intel boxes that were new about 2 years ago. -- John Baldwin From mack at macktronics.com Thu Sep 11 20:06:57 2008 From: mack at macktronics.com (Dan Mack) Date: Thu Sep 11 20:07:05 2008 Subject: installkernel and nvram.ko on RELENG_6 broken? Message-ID: I have a custom kernel without nvram defined anywhere, however, make installkernel still attempts to install the module. About 45 days ago, I didn't have this issue. I didn't see anything about this in UPDATING so I thought I would check here. This system is currently running stable from 45 days ago built from source. I cvsuped 4 hours ago. # make installkernel KERNCONF=SMP-COCO ===> nullfs (install) install -o root -g wheel -m 555 nullfs.ko /boot/kernel ===> nve (install) install -o root -g wheel -m 555 if_nve.ko /boot/kernel ===> nvram (install) install -o root -g wheel -m 555 nvram.ko /boot/kernel install: nvram.ko: No such file or directory *** Error code 71 Stop in /usr/src/sys/modules/nvram. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/SMP-COCO. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From mack at macktronics.com Thu Sep 11 20:09:42 2008 From: mack at macktronics.com (Dan Mack) Date: Thu Sep 11 20:09:49 2008 Subject: installkernel and nvram.ko on RELENG_6 broken? In-Reply-To: References: Message-ID: <8ADD2753-713A-40B3-A3E2-22EC8B3A6959@macktronics.com> I have removed /usr/obj and am going through the whole buildworld/ buildkernel/installkernel process again. There were a bunch of stale files under /usr/obj/usr/src/sys/i386/compile that may be the issue. Dan On Sep 11, 2008, at 2:55 PM, Dan Mack wrote: > I have a custom kernel without nvram defined anywhere, however, make > installkernel still attempts to install the module. About 45 days > ago, I didn't have this issue. I didn't see anything about this in > UPDATING so I thought I would check here. This system is currently > running stable from 45 days ago built from source. I cvsuped 4 > hours ago. > > # make installkernel KERNCONF=SMP-COCO > > ===> nullfs (install) > install -o root -g wheel -m 555 nullfs.ko /boot/kernel > ===> nve (install) > install -o root -g wheel -m 555 if_nve.ko /boot/kernel > ===> nvram (install) > install -o root -g wheel -m 555 nvram.ko /boot/kernel > install: nvram.ko: No such file or directory > *** Error code 71 > > Stop in /usr/src/sys/modules/nvram. > *** Error code 1 > > Stop in /usr/src/sys/modules. > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/SMP-COCO. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > _______________________________________________ > 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 hawei at free.fr Thu Sep 11 20:18:13 2008 From: hawei at free.fr (Harald Weis) Date: Thu Sep 11 20:18:21 2008 Subject: Audio CD problem on laptop VGN-SZ61MN In-Reply-To: <20080810065417.GA1164@pollux> References: <20080808081330.GA1203@sirius.local.net> <20080809140339.GA1522@sirius.local.net> <20080810065417.GA1164@pollux> Message-ID: <20080911202357.GA3201@pollux> On Sun, Aug 10, 2008 at 08:54:17AM +0200, Harald Weis wrote: > On Sat, Aug 09, 2008 at 11:56:23AM -0300, Carlos A. M. dos Santos wrote: > > > 1. Try to insert the CD and wait until it stops pinning before > > starting mplayer. Some drives are a bit lazy on media recognition. Doesn't make a difference. > > 2. Run "truss mplayer ..." and look for error messages. The output file does not mention the "Invalid argument" message or, as far as I can understand, any other fatal stuff. > > 3. Attempt to use a different player. Xine and/or one of its alternate > > front-ends like GXine or Kaffeine are good choices. > > I'll be away from keyboard for two weeks or so. > I shall reply then as soon as possible. Xine: ``xine cdda://dev/acd0/n'' works fine despite of six lines ``Cannot find address for OpenGl extension function ... which should be available according to extension specs.''. But the GUI does not work properly. For example, the CD button generates ``CDIOCREADAUDIO: Invalid argument'' messages. No wonder that gxine and kaffeine which use the xine engine don't work either. Finally, the only (audioCD) command which does work on this laptop is ``vlc cdda:///dev/acd0@1-3''. Disappointing, but better than nothing. Thank you again for your comments. Harald From bms at incunabulum.net Thu Sep 11 23:26:03 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu Sep 11 23:26:10 2008 Subject: Long delays for USB realbtx boot In-Reply-To: <20080911162956.GA15152@svzserv.kemerovo.su> References: <48C91525.10806@incunabulum.net> <20080911162956.GA15152@svzserv.kemerovo.su> Message-ID: <48C9A907.8000000@incunabulum.net> Eugene Grosbein wrote: > For me, it helps to include these knobs to Nano config file: > > CONF_WORLD=' > BOOT_MBR_FLAGS=0x0 > BOOT_BOOT1_FLAGS=0x0 > ... > ' > I added this to the CONF_WORLD in my config file. Unfortunately this seems to break USB boot completely for me. When I attempt to boot the USB flash device on the AH-1, the 1 minute delay still exists. The messages "No /boot/loader" and "No /boot/kernel/kernel" are printed, and the image does not boot -- it sits at the "FreeBSD/i386 boot" prompt. It does however see the files at the top of the root filesystem, it just refuses to boot further. The device has less than 1023 cylinders, so the restrictions which would make EDD/packet mode necessary should not apply, and I would have thought that your workaround would work. I am using "USB-HDD" style geometry at the moment (255/63/cc), not "USB-ZIP" (64/32/cc). Would that make a difference? What's interesting is that "camcontrol modepage da0 -m 0x05" returns a different geometry from that reported by the BIOS: %%% Transfer rate: 61440 Number of heads: 16 Sectors per track: 32 Data bytes per sector: 512 Number of cylinders: 3816 Starting cylinder-write precompensation: 0 Starting cylinder-reduced write current: 0 Drive step rate: 0 Drive step pulse width: 0 Head settle delay: 0 Motor on delay: 0 Motor off delay: 0 TRDY: 0 SSN: 0 MO: 0 SPC: 0 Write Compensation: 0 Head load delay: 0 Head unload delay: 0 Pin 34: 0 Pin 2: 0 Pin 4: 0 Pin 1: 0 Medium rotation rate: 0 %%% cheers BMS From bms at FreeBSD.org Thu Sep 11 23:33:05 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Sep 11 23:33:12 2008 Subject: Long delays for USB realbtx boot In-Reply-To: <48C9A907.8000000@incunabulum.net> References: <48C91525.10806@incunabulum.net> <20080911162956.GA15152@svzserv.kemerovo.su> <48C9A907.8000000@incunabulum.net> Message-ID: <48C9AAAE.1030909@FreeBSD.org> Woops, I noticed right after I sent this message, that there was an I/O error writing to the USB key from dd in my shell -- I think I was using a 32768 block size instead of 16384 which might account for the problem. I'll be sure to try this all again after I've had some sleep. cheers BMS From vinwa at rocky.kais.kyoto-u.ac.jp Fri Sep 12 01:41:06 2008 From: vinwa at rocky.kais.kyoto-u.ac.jp (KAHO Toshikazu) Date: Fri Sep 12 01:41:14 2008 Subject: alpm(4) I/O range is claimed by ACPI References: 00809111043.18265.jhb@freebsd.org Message-ID: <200809120123.m8C1Ntt6032356@pf2.ed.niigata-u.ac.jp> Hello. I have same error message on Sharp PC-CV50. Is it a hardware or BIOS problem ? The device dosen't have PCIM_CMD_PORTEN bit on PCIR_COMMAND (address 0x04, bit 0), and dosen't have any valid address on PCIR_BAR(x). pciconf can't write PCIR_BAR(x). `pciconf -lv` shows: none0@pci0:3:1: class=0x068000 card=0x104313bd chip=0x710110b9 rev=0x00 hdr=0x00 vendor = 'Acer Labs Incorporated (ALi/ULi)' device = 'ALI M7101 Power Management Controller' class = bridge and `pciconf -r pci0:3:1 0:0x1f` shows: 710110b9 02000000 06800000 00800000 00000000 00000000 00000000 00000000 -- KAHO Toshikazu From adrian at freebsd.org Fri Sep 12 02:23:00 2008 From: adrian at freebsd.org (Adrian Chadd) Date: Fri Sep 12 02:23:08 2008 Subject: FreeBSD 7.1 Content In-Reply-To: <55EA18D2-E017-4426-9377-1FC113ED83D2@airwired.net> References: <35445338-D597-4FE2-996F-DEC7BE986741@airwired.net> <20080903191454.GA15376@server.vk2pj.dyndns.org> <20080903195825.GC28299@atarininja.org> <55EA18D2-E017-4426-9377-1FC113ED83D2@airwired.net> Message-ID: Under linux: install pci-tools or something, then "lspci". Adrian 2008/9/4 Dan Allen : > > On 3 Sep 2008, at 1:58 PM, Wesley Shields wrote: > >> I installed the June snapshot of -current on my laptop and it supports >> my Intel 4965 just fine. Support for this card is out there and does >> work, just not in RELENG_7. > > On 3 Sep 2008, at 2:45 PM, Gavin Atkinson wrote: > >> There is support for the Intel 4965 in HEAD, with the iwn(4) driver. > > Thanks guys for the info. > > Not having ANY wired or wireless support in FreeBSD for a very decent Dell > laptop that is flying off of the shelves at $500, I deleted FreeBSD from the > machine and installed Ubuntu 8.04. I therefore cannot run "pciconf -l" at > this moment in time, but I may get back around to it. > > Stay tuned... maybe for 7.2. > > Dan > > _______________________________________________ > 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 eugen at kuzbass.ru Fri Sep 12 04:42:32 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Fri Sep 12 04:42:39 2008 Subject: Long delays for USB realbtx boot References: <48C91525.10806@incunabulum.net> <20080911162956.GA15152@svzserv.kemerovo.su> <48C9A907.8000000@incunabulum.net> Message-ID: <48C9F32F.99B1D161@kuzbass.ru> Bruce M Simpson wrote: > > Eugene Grosbein wrote: > > For me, it helps to include these knobs to Nano config file: > > > > CONF_WORLD=' > > BOOT_MBR_FLAGS=0x0 > > BOOT_BOOT1_FLAGS=0x0 > > ... > > ' > > > > I added this to the CONF_WORLD in my config file. Unfortunately this > seems to break USB boot completely for me. Sorry, I missed that you are using USB flash. I use IDE flash only. Eugene Grosbein From koitsu at FreeBSD.org Fri Sep 12 06:52:02 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 12 06:52:11 2008 Subject: Intel ICH7 SMBus support, ichsmb(4) In-Reply-To: <48C92DD8.8060808@protected-networks.net> References: <48C847DE.7040508@incunabulum.net> <20080911043326.GA19290@icarus.home.lan> <48C8EA38.6090903@quip.cz> <20080911104738.GA25493@icarus.home.lan> <48C905F7.5020306@quip.cz> <48C92BE2.4060906@FreeBSD.org> <48C92DD8.8060808@protected-networks.net> Message-ID: <20080912065200.GA49512@icarus.home.lan> On Thu, Sep 11, 2008 at 10:40:24AM -0400, Michael Butler wrote: > Bruce M. Simpson wrote: > > Miroslav Lachman wrote: > >> Jeremy Chadwick wrote: > >> > >>> I suppose a lot of these could be addressed if I released the code in a > >>> preliminary fashion (providing folks the ability to help me with > >>> documentation, etc.). Hmm... Yeah, I should really get a beta tarball > >>> up, and/or make a FreeBSD port for it already (since I am a ports > >>> committer). > > > > My suggestion would be to make the code available using a Mercurial > > repository. People are then free to participate and send diffs as they > > see fit, and they can do so very easily. The learning curve for the > > tool is reasonable. > > > > I'd also recommend http://freehg.org/ if you need some hosting for a > > public repo. > What would prevent this being accepted as a loadable module built (by > user request) out of the ports tree in much the same manner as kqemu et al.? > > Michael I'm confused by this question and its relevancy to what Bruce said. :-) Can you explain? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Fri Sep 12 06:53:45 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 12 06:53:53 2008 Subject: alpm(4) I/O range is claimed by ACPI In-Reply-To: <48C927D6.5020800@incunabulum.net> References: <48C8F684.8090409@incunabulum.net> <20080911110407.GC25493@icarus.home.lan> <48C927D6.5020800@incunabulum.net> Message-ID: <20080912065343.GB49512@icarus.home.lan> On Thu, Sep 11, 2008 at 03:14:46PM +0100, Bruce M Simpson wrote: > Jeremy Chadwick wrote: >> ... >> Might mention this to jhb@ to see if it's related to the SMBus changes >> made 1.5 years ago: >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/alpm.c >> > > Thanks for the pointers. The other reports sound like duplicate reports > of the same issue. > > I'm not sure that backing out the last change is going to help. The BIOS > has generally set up the I/O resource before FreeBSD boots; the > bus_set_resource() call might only be useful in those cases where that > hasn't happened. > In any event, in alpm_attach(), the rman is going to notice that the bus > space is already allocated by acpi(4), and will balk. > > I'm sure there has been some kind of override mechanism in place for > certain other drivers; but they seem to boil down to using an ACPI > attachment of some kind, which won't work here as alpm(4) is a PCI > function and needs to attach to the pcib parent. > > It would be really, really useful to have working SMBus drivers right > now on a machine I can actually touch... Interesting timing -- Toshikazu Kaho just reported the same issue with alpm(4) today: http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/044989.html I've CC'd him, as he's probably unaware of this already-existing thread. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Fri Sep 12 07:20:40 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 12 07:20:47 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: <48C93903.5060604@protected-networks.net> References: <48C927DC.6000202@incunabulum.net> <48C932D9.50604@thekeelecentre.com> <48C934D1.5030703@incunabulum.net> <48C93582.3080107@thekeelecentre.com> <48C93903.5060604@protected-networks.net> Message-ID: <20080912072037.GC49512@icarus.home.lan> On Thu, Sep 11, 2008 at 11:28:03AM -0400, Michael Butler wrote: > Richard Tector wrote: > > Bruce M Simpson wrote: > >> Richard, > >> > >> Thanks for this. > >> > >> Richard Tector wrote: > >>> > >>> I have an ICH9 machine, Tyan motherboard: > >>> FreeBSD 7.0-STABLE #0: Fri Aug 1 14:57:33 BST 2008 > >>> ichsmb0: port 0x18e0-0x18ff mem > >>> 0xf4a03000-0xf4a030ff irq 17 at device 31.3 on pci0 > >>> ichsmb0: [GIANT-LOCKED] > >>> ichsmb0: [ITHREAD] > >>> > >>> daffy# smbmsg -p > >>> Probing for devices on /dev/smb0: > >>> Device @0x2e: rw > >> ... > >> So it looks like yours works! I see no differences to RELENG_7_0. > >> > >> Are you using any hardware monitoring devices? > >> Can you give bsdhwmon a shot? > >> > >> cheers > >> BMS > > > > Sure. If yourself or Jeremy could send over the tarball? > > I don't use any hardware monitoring on it currently. > I'd also appreciate the opportunity to try it .. old hardware but .. > > imb@aaron:/home/imb> devinfo -v | grep smb > intsmb0 pnpinfo vendor=0x8086 device=0x7113 subvendor=0x0000 > subdevice=0x0000 class=0x068000 at slot=7 function=3 handle=\_SB_.PCI0.PMU_ > smbus0 > smb0 > imb@aaron:/home/imb> kenv | grep smbios > smbios.bios.reldate="07/20/2001" > smbios.bios.vendor="Intel Corp." > smbios.bios.version="TR440BXA.86B.0042.P15.0107200951" > smbios.chassis.maker="Dell Computer Corp. " > smbios.chassis.serial="YC571 " > smbios.chassis.tag=" " > smbios.chassis.version="SPAW70W PA[CA] " > smbios.planar.maker="Intel Corporation " > smbios.planar.product="TR440BXA " > smbios.planar.serial="IMTR02702003 " > smbios.planar.version="A16643-305 " > smbios.socket.enabled="1" > smbios.socket.populated="1" > smbios.system.maker="Dell Computer Corp. " > smbios.system.product="PowerApp.web 100 W " > smbios.system.serial="YC571 " > smbios.system.uuid="44454c4c-00ca-1059-8043-80c04f353731" > smbios.system.version="SPAW70W " didn't think anyone was still using Intel 440BX boards in this day and age! (A great chipset, though!) I can absolutely assure you bsdhwmon will not work on this board. I can add support for it, but I need to know full register details of what H/W monitoring IC is tied to SMBus, and what the SMBus slave address is of the monitoring IC. > imb@aaron:/home/imb> sudo smbmsg -p > Probing for devices on /dev/smb0: > Device @0x5a: rw > Device @0x60: rw > Device @0x62: rw > Device @0x64: rw > Device @0x66: rw > Device @0xa0: rw > Device @0xa2: rw > Device @0xa4: rw > Device @0xa6: rw > imb@aaron:/home/imb> sudo mbmon -d > Using SMBus-ioctl access method[IntelPIIX4(440BX/MX)]!! > * Analog Dev. Chip ADM9240 found. Can you confirm this is correct? Does this board really have an ADM H/W monitoring IC on it? Are the rpms/voltages/temps returned by mbmon *actually correct? Hardware monitoring software in the ports tree make some general assumptions over what the register offset/indexes are, which are often wrong depending upon what sub-model of chip is used. This is one reason why bsdhwmon reads the smbios data and matches motherboard model up with what chip is installed on the board. I'm sure I'll eventually encounter a situation where motherboard X has two different revisions of hardware monitoring ICs on it (e.g. one is a 1234A, and later releases of the same board use a 1234B), but the code should be able to account for that cleanly. The state of hardware monitoring on BSD is atrocious, and it was atrocious 10 years ago. Absolutely no evolution has occurred in this regard, while Linux's lm-sensors has pretty much dominated in this regard. OpenBSD has sensors framework, too. A user on #bsdports privately discussed this situation with me yesterday, as apparently there are a large number of Russian forums and mailing lists discussing how to get mbmon, consolehw, or healthd to work with their systems. What these people aren't aware of is how outdated the programs are, how it all works, and the risks involved when using a hardware monitor that blindly hits certain registers (this is especially risky with ISA bus interaction). I'm trying my best to make things better, doing things purely from a userland perspective and using SMBus exclusively (since the interface is quite reliable, assuming the SMBus driver used on FreeBSD is working correctly). I understand-- Bruce is having problems with ichsmb(4), while on every ICH7 board I have (and I have many), I've had nothing but success. All of bsdhwmon's main development has been done on ICH7 boards I use and have physical access to, for example. I wish I knew more about the inner-workings of PCI and SMBus in general, but as it stands, my knowledge is limited solely to interfacing with a device *on* the SMBus. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From mh at kernel32.de Fri Sep 12 10:00:35 2008 From: mh at kernel32.de (Marian Hettwer) Date: Fri Sep 12 10:00:47 2008 Subject: RELENG_7 nvidia xorg hard lock Message-ID: <447c841f548fa265b665ff6df4ab56fe@localhost> Hi All, I'm testing 7.1 Prerelease right now and am having difficulties to get my xorg with nvidia up and running. I updated from: [mhettwer@motor] <~>uname -a FreeBSD motor.mobile.rz 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon Aug 4 16:54:32 CEST 2008 root@motor.mobile.rz:/usr/obj/usr/src/sys/GENERIC i386 with: [mhettwer@motor] <~>pkg_info xorg-server-1.4.2,1 [mhettwer@motor] <~>pkg_info nvidia-driver-173.14.09 to: [mhettwer@motor] <~>uname -a FreeBSD motor.mobile.rz 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Wed Sep 10 18:39:19 CEST 2008 root@motor.mobile.rz:/usr/obj/usr/src/sys/GENERIC i386 with the same xorg-server and nvidia driver. However, I wind up having a dead lock. Not pingable anymore and blank screen. That's very unfortunate. a dmesg and pciconf of that machine is at: http://crivens.kernel32.de/~rabauke/FreeBSD/dmesg-7.1-prelease.txt http://crivens.kernel32.de/~rabauke/FreeBSD/pciconf-7.1-prerelease.txt I also tried the latest nvidia-driver, which also results in a blank screen and not pingable machine :( Any help is highly appreciated! best regards, Marian From emss at free.fr Fri Sep 12 10:07:53 2008 From: emss at free.fr (Eric Masson) Date: Fri Sep 12 10:08:01 2008 Subject: viapm(4) does not see VT8237A on Gigabyte GA-VM900M In-Reply-To: <48C934F3.5060500@FreeBSD.org> (Bruce M. Simpson's message of "Thu, 11 Sep 2008 16:10:43 +0100") References: <48C927DC.6000202@incunabulum.net> <48C934F3.5060500@FreeBSD.org> Message-ID: <86vdx275nh.fsf@srvbsdnanssv.interne.kisoft-services.com> "Bruce M. Simpson" writes: Hi, > I just tried to port over some of the hardware IDs from OpenBSD 4.3's > viapm(4) driver to the driver in 6.3-RELEASE, as I really need to see > what working SMBus support looks like in a FreeBSD system. Same here, Abit KV8, VIA8237 and viapm doesn't attach. -- Ol: ..un plan perdu au fond d'une armoire dont seul Steve Jobs a la cl?. BL: Qu'il a laiss?e dans un pantalon d?pos? chez un teinturier dont il a perdu l'adresse et le ticket?! -+- BL in Guide du Macounet Pervers : Bien cacher sa strat?gie -+- From mh at kernel32.de Fri Sep 12 10:39:58 2008 From: mh at kernel32.de (Marian Hettwer) Date: Fri Sep 12 10:40:06 2008 Subject: RELENG_7 nvidia xorg hard lock In-Reply-To: <447c841f548fa265b665ff6df4ab56fe@localhost> References: <447c841f548fa265b665ff6df4ab56fe@localhost> Message-ID: <68ee715093bc303a951e317e25d5767b@localhost> Reply to myself: it seems, that the nvidia card isn't recognized by the nvidia kld. xorg.log states: (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module! Please ensure (EE) NVIDIA(0): that there is a supported NVIDIA GPU in this system, and (EE) NVIDIA(0): that the NVIDIA device files have been created properly. (EE) NVIDIA(0): Please consult the NVIDIA README for details. (EE) NVIDIA(0): *** Aborting *** Wh00t? This card worked before... nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] Something is odd here... On Fri, 12 Sep 2008 12:00:32 +0200, Marian Hettwer wrote: > Hi All, > > I'm testing 7.1 Prerelease right now and am having difficulties to get my > xorg with nvidia up and running. > I updated from: > [mhettwer@motor] <~>uname -a > FreeBSD motor.mobile.rz 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon Aug 4 > 16:54:32 CEST 2008 root@motor.mobile.rz:/usr/obj/usr/src/sys/GENERIC > i386 > > with: > [mhettwer@motor] <~>pkg_info xorg-server-1.4.2,1 > [mhettwer@motor] <~>pkg_info nvidia-driver-173.14.09 > > to: > [mhettwer@motor] <~>uname -a > FreeBSD motor.mobile.rz 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Wed Sep > 10 18:39:19 CEST 2008 > root@motor.mobile.rz:/usr/obj/usr/src/sys/GENERIC > i386 > > with the same xorg-server and nvidia driver. > > However, I wind up having a dead lock. Not pingable anymore and blank > screen. > That's very unfortunate. > > a dmesg and pciconf of that machine is at: > http://crivens.kernel32.de/~rabauke/FreeBSD/dmesg-7.1-prelease.txt > http://crivens.kernel32.de/~rabauke/FreeBSD/pciconf-7.1-prerelease.txt > > I also tried the latest nvidia-driver, which also results in a blank > screen > and not pingable machine :( > > Any help is highly appreciated! > > best regards, > Marian > > _______________________________________________ > 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 olli at lurza.secnetix.de Fri Sep 12 16:04:53 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Sep 12 16:04:59 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: <20080912072037.GC49512@icarus.home.lan> Message-ID: <200809121604.m8CG4okb000577@lurza.secnetix.de> Jeremy Chadwick wrote: > didn't think anyone was still using Intel 440BX boards in this day and > age! (A great chipset, though!) I just updated an i440BX based dual-celeron-466 from some old 4.8-stable to 7.1-prerelease. "make buildworld" takes about eight hours (without -j), but I don't care, I just let it run over night. The machine is perfectly capable and fast enough to act as a name server, small mail and web server for a dozen people, and as a generic shell box for various tasks. There's also an old notebook (2001) with i440BX and a Pentium-III 850 MHz, which I use occasionally on trips. It's completely sufficient to get online, read e-mails, chat, browse the web, upload digital photos and so on. I hate throwing away hardware that's still working and up to the task. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++: "an octopus made by nailing extra legs onto a dog" -- Steve Taylor, 1998 From webmaster at kibab.com Fri Sep 12 16:46:01 2008 From: webmaster at kibab.com (Ilya Bakulin) Date: Fri Sep 12 16:46:09 2008 Subject: RELENG_7 nvidia xorg hard lock In-Reply-To: <68ee715093bc303a951e317e25d5767b@localhost> References: <447c841f548fa265b665ff6df4ab56fe@localhost> <68ee715093bc303a951e317e25d5767b@localhost> Message-ID: <1221235898.1784.9.camel@localhost> ? ??, 12/09/2008 ? 12:39 +0200, Marian Hettwer ?????: > Reply to myself: > > it seems, that the nvidia card isn't recognized by the nvidia kld. > xorg.log states: > (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module! Please > ensure > (EE) NVIDIA(0): that there is a supported NVIDIA GPU in this system, > and > (EE) NVIDIA(0): that the NVIDIA device files have been created > properly. > (EE) NVIDIA(0): Please consult the NVIDIA README for details. > (EE) NVIDIA(0): *** Aborting *** > > Wh00t? This card worked before... > nvidia0: on vgapci0 > vgapci0: child nvidia0 requested pci_enable_busmaster > vgapci0: child nvidia0 requested pci_enable_io > nvidia0: [GIANT-LOCKED] > nvidia0: [ITHREAD] > > Something is odd here... > Obviously Xorg has nothing to do with this issue. Please make sure that your nvidia module is up-to-date and in sync with current kernel. If I were you, I would delete nvidia-driver package, make sure that it has gone from /boot/modules, than download latest driver version and recompile it. After that try to reboot and see what happens. -- Ilya Bakulin xmpp://kibab612@jabber.ru mailto:webmaster@kibab.com http://kibab.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: =?koi8-r?Q?=FC=D4=C1?= =?koi8-r?Q?_=DE=C1=D3=D4=D8?= =?koi8-r?Q?_=D3=CF=CF=C2=DD=C5=CE=C9=D1?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=C1=CE=C1?= =?koi8-r?Q?_=C3=C9=C6=D2=CF=D7=CF=CA?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=D8=C0?= Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080912/0d9ba62b/attachment.pgp From bms at FreeBSD.org Fri Sep 12 16:53:42 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri Sep 12 16:53:48 2008 Subject: Long delays for USB realbtx boot In-Reply-To: <48C9AAAE.1030909@FreeBSD.org> References: <48C91525.10806@incunabulum.net> <20080911162956.GA15152@svzserv.kemerovo.su> <48C9A907.8000000@incunabulum.net> <48C9AAAE.1030909@FreeBSD.org> Message-ID: <48CA9E93.3060306@FreeBSD.org> Bruce M. Simpson wrote: > Woops, I noticed right after I sent this message, that there was an > I/O error writing to the USB key from dd in my shell -- I think I was > using a 32768 block size instead of 16384 which might account for the > problem. > I'll be sure to try this all again after I've had some sleep. Sure enough, this was my screwup. In short: I found the problem. The "active" flag wasn't set on any MBR slices. Tried booting from USB on 3 machines, and it all works perfectly. Thanks to kib@ and jhb@ for all their hard work on real mode BTX. For details of the bug bashing, read on. There is a thread here on the SYSLINUX list about USB long boot times: http://syslinux.zytor.com/archives/files/2005-January/004592.html Unrelated, as USB-HDD mode appears OK here. I tried this again with the EDD stuff disabled in mbr and boot1 as per your suggestion. Didn't make any difference. The boot delay (up to a minute) is still present. I note that the access light on the flash device DOES NOT flicker during this period, so I'm not sure that we're seeing sector-by-sector access. Of course without a POST card who can tell -- I didn't get one of those involved yet. After the delay I decided to interrupt loader(8) and do 'lsdev'. According to loader(8), the USB key is seen as BIOS drive C: (number 1) when 'mbr' is used as the mbr bootstrap. Turns out the AMI BIOS v2.58 on the ASUS Vintage AH-1 lets you force the boot mode for attached USB mass storage devices. This option is buried under Advanced->Chipset->SouthBridge Configuration->USB Configuration->USB Mass Storage Device Configuration->Emulation Type. It only appears if a USB mass storage device is plugged in at boot time. Choosing "Hard Disk" made no difference. Presumably this is because "Hard Disk" mode is chosen anyway if "Auto" is selected (the default) as the device is larger than 530MB. I re-examined the MBR on the key and it looks like it is using USB-HDD style geometry. Choosing "Forced FDD" mode seems to break boot completely, no change after 2m 40s. I'd expect this because there is an MBR on the disk, instead of a huge FAT filesystem. So USB-HDD mode appears to be chosen by the BIOS for this device as a default. So I tried reinstalling boot0 which lets me change packet/setdrv modes, as well as giving me some visual feedback about the boot stage. ...after much tweaking... So it appears the "active" flag was not being set for the first partition, it seems NanoBSD's fdisk script didn't set it; that should probably get patched, as this was the root cause of the USB booting delay. PS If there are any other drives present, then the boot menu does get displayed, regardless of the "mask" setting in boot0cfg. cheers BMS From chris at young-alumni.com Fri Sep 12 17:38:52 2008 From: chris at young-alumni.com (Chris Ruiz) Date: Fri Sep 12 17:38:59 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: <48C927DC.6000202@incunabulum.net> References: <48C927DC.6000202@incunabulum.net> Message-ID: <1EDB9C24-8E69-43D3-8082-2379955FF8FF@young-alumni.com> On Sep 11, 2008, at 9:14 AM, Bruce M Simpson wrote: > Does anyone have ichsmb(4) actually seeing SMBus devices? > e.g. you run "smbmsg -p" on your FreeBSD-STABLE system and see > something. > > I just tried it again on my IBM ThinkPad T43 and saw nothing, all I > get is: > ichsmb0: device timeout, status=0x41 > ...in dmesg. > > cheers > BMS BMS, I have an ICH9 system and get the following: First, my kernel: FreeBSD attack.young-alumni.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Sat Sep 6 08:33:04 CDT 2008 root@:/usr/src/sys/amd64/compile/ ATTACK amd64 Dmesg: ichsmb0: port 0x3000-0x301f mem 0xe0427000-0xe04270ff irq 18 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] smbus0: on ichsmb0 Error: attack:~ root# smbmsg -p smbmsg: Cannot open /dev/smb0: No such file or directory Hope this helps, Chris Ruiz > > _______________________________________________ > 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 bms at incunabulum.net Fri Sep 12 17:47:09 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Fri Sep 12 17:47:17 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: <20080912072037.GC49512@icarus.home.lan> References: <48C927DC.6000202@incunabulum.net> <48C932D9.50604@thekeelecentre.com> <48C934D1.5030703@incunabulum.net> <48C93582.3080107@thekeelecentre.com> <48C93903.5060604@protected-networks.net> <20080912072037.GC49512@icarus.home.lan> Message-ID: <48CAAB1A.9070502@incunabulum.net> Jeremy Chadwick wrote: > I'm trying my best to make things better, doing things purely from a > userland perspective and using SMBus exclusively (since the interface is > quite reliable, assuming the SMBus driver used on FreeBSD is working > correctly). I understand-- Bruce is having problems with ichsmb(4), > while on every ICH7 board I have (and I have many), I've had nothing but > success. All of bsdhwmon's main development has been done on ICH7 > boards I use and have physical access to, for example. I fished out the A/Open MX3S board I have. It seems to have an ICH2 south bridge. An old version of Gentoo I had installed finds the ICH2. mbmon is able to talk to a Winbond chip over ISA; it sees an SMBus slave 0xA0/0x50, I don't know what that is yet. I got this board years ago, I think because it does actually support smbus. I'm just futzing with Gentoo now to get the HWMON and other i2c drivers up. i2c-i801.ko probes and attaches. i2c-dev.ko created /dev/i2c* nodes ok. I then downloaded i2c-tools from http://www.lm-sensors.org/wiki/I2CTools and built it. %%% raisin i2c-tools-3.0.1 # /usr/local/sbin/i2cdetect 3 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c/3. I will probe address range 0x03-0x77. Continue? [Y/n] Y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: 30 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- %%% %%% raisin i2c-tools-3.0.1 # mbmon -S -D Probe Request: none >>> Testing Reg's at SMBus <<< [Intel8XX(ICH/ICH2/ICH3/ICH4/ICH5/ICH6), IO-Base:0x5000] SMBus slave 0xA0(0x50) found... SMBus[Intel8XX(ICH/ICH2/ICH3/ICH4/ICH5/ICH6)] found, but No HWM available on it!! InitMBInfo: Success %%% Likely these are old versions of the mbmon tools. %%%raisin i2c-tools-3.0.1 # /usr/local/sbin/i2cdump 3 0x50 b 0 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c/3, address 0x50, mode byte Continue? [Y/n] Y 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 80 08 04 0c 0a 01 40 00 01 80 60 00 80 08 00 01 ??????@.??`.??.? 10: 8f 04 06 01 01 00 0e a0 60 00 00 14 14 14 32 20 ?????.??`..???2 20: 20 10 20 10 00 00 00 00 00 00 00 00 00 00 00 00 ? ?............ 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 f6 ..............?? 40: 2c ff ff ff ff ff ff ff 08 38 4c 53 44 54 31 36 ,.......?8LSDT16 50: 36 34 41 47 2d 31 30 45 45 31 20 01 00 03 10 6c 64AG-10EE1 ?.??l 60: 08 95 7e 00 00 00 00 00 00 00 00 00 00 00 00 00 ??~............. 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 af ..............d? 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ %%% Hey, that looks like a Micron DIMM. I didn't see anything on the other two i2c bus addresses. So I can confirm SMBus works on the MX3S from Linux 2.6.x. I'll blow it away with 7.1-BETA and see what happens next. cheers BMS From koitsu at FreeBSD.org Fri Sep 12 17:57:51 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 12 17:57:58 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: <1EDB9C24-8E69-43D3-8082-2379955FF8FF@young-alumni.com> References: <48C927DC.6000202@incunabulum.net> <1EDB9C24-8E69-43D3-8082-2379955FF8FF@young-alumni.com> Message-ID: <20080912175749.GA62725@icarus.home.lan> On Fri, Sep 12, 2008 at 12:19:55PM -0500, Chris Ruiz wrote: > I have an ICH9 system and get the following: > > First, my kernel: > FreeBSD attack.young-alumni.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE > #0: Sat Sep 6 08:33:04 CDT 2008 root@:/usr/src/sys/amd64/compile/ > ATTACK amd64 > > Dmesg: > ichsmb0: port 0x3000-0x301f mem 0xe0427000-0xe04270ff > irq 18 > at device 31.3 on pci0 > ichsmb0: [GIANT-LOCKED] > ichsmb0: [ITHREAD] > smbus0: on ichsmb0 > > Error: > attack:~ root# smbmsg -p > smbmsg: Cannot open /dev/smb0: No such file or directory Does your kernel include all 3 of the following devices? device smbus device smb device ichsmb -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From bms at FreeBSD.org Fri Sep 12 18:02:17 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri Sep 12 18:02:24 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: <1EDB9C24-8E69-43D3-8082-2379955FF8FF@young-alumni.com> References: <48C927DC.6000202@incunabulum.net> <1EDB9C24-8E69-43D3-8082-2379955FF8FF@young-alumni.com> Message-ID: <48CAAEA7.7060304@FreeBSD.org> Chris Ruiz wrote: > > Error: > attack:~ root# smbmsg -p > smbmsg: Cannot open /dev/smb0: No such file or directory Looks like the smb.ko module ain't loaded. cheers, BMS From chris at young-alumni.com Fri Sep 12 18:12:37 2008 From: chris at young-alumni.com (Chris Ruiz) Date: Fri Sep 12 18:12:43 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: <20080912175749.GA62725@icarus.home.lan> References: <48C927DC.6000202@incunabulum.net> <1EDB9C24-8E69-43D3-8082-2379955FF8FF@young-alumni.com> <20080912175749.GA62725@icarus.home.lan> Message-ID: On Sep 12, 2008, at 12:57 PM, Jeremy Chadwick wrote: > On Fri, Sep 12, 2008 at 12:19:55PM -0500, Chris Ruiz wrote: >> I have an ICH9 system and get the following: >> >> First, my kernel: >> FreeBSD attack.young-alumni.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE >> #0: Sat Sep 6 08:33:04 CDT 2008 root@:/usr/src/sys/amd64/ >> compile/ >> ATTACK amd64 >> >> Dmesg: >> ichsmb0: port 0x3000-0x301f mem >> 0xe0427000-0xe04270ff >> irq 18 >> at device 31.3 on pci0 >> ichsmb0: [GIANT-LOCKED] >> ichsmb0: [ITHREAD] >> smbus0: on ichsmb0 >> >> Error: >> attack:~ root# smbmsg -p >> smbmsg: Cannot open /dev/smb0: No such file or directory > > Does your kernel include all 3 of the following devices? > > device smbus > device smb > device ichsmb > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > Jeremy, I loaded smb.ko and it fixed the situation. I had the line 'ichsmb_load="YES"' in my loader.conf and it loaded smbus.ko but not smb.ko for me. Seems like a module load dependency issue. Here's my output: attack:~ root# smbmsg -p Probing for devices on /dev/smb0: Device @0x44: rw Device @0x50: rw Device @0x52: rw Device @0x64: w Device @0x80: rw Device @0x88: w Device @0x8c: r Device @0xc4: rw Device @0xd0: rw Device @0xd2: rw Device @0xe4: w Thanks, Chris From koitsu at FreeBSD.org Fri Sep 12 18:32:40 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 12 18:32:46 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: References: <48C927DC.6000202@incunabulum.net> <1EDB9C24-8E69-43D3-8082-2379955FF8FF@young-alumni.com> <20080912175749.GA62725@icarus.home.lan> Message-ID: <20080912183233.GA63271@icarus.home.lan> On Fri, Sep 12, 2008 at 01:12:34PM -0500, Chris Ruiz wrote: > > On Sep 12, 2008, at 12:57 PM, Jeremy Chadwick wrote: > >> On Fri, Sep 12, 2008 at 12:19:55PM -0500, Chris Ruiz wrote: >>> I have an ICH9 system and get the following: >>> >>> First, my kernel: >>> FreeBSD attack.young-alumni.com 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE >>> #0: Sat Sep 6 08:33:04 CDT 2008 root@:/usr/src/sys/amd64/ >>> compile/ >>> ATTACK amd64 >>> >>> Dmesg: >>> ichsmb0: port 0x3000-0x301f mem >>> 0xe0427000-0xe04270ff >>> irq 18 >>> at device 31.3 on pci0 >>> ichsmb0: [GIANT-LOCKED] >>> ichsmb0: [ITHREAD] >>> smbus0: on ichsmb0 >>> >>> Error: >>> attack:~ root# smbmsg -p >>> smbmsg: Cannot open /dev/smb0: No such file or directory >> >> Does your kernel include all 3 of the following devices? >> >> device smbus >> device smb >> device ichsmb >> >> -- >> | Jeremy Chadwick jdc at parodius.com | >> | Parodius Networking http://www.parodius.com/ | >> | UNIX Systems Administrator Mountain View, CA, USA | >> | Making life hard for others since 1977. PGP: 4BD6C0CB | >> > > Jeremy, > > I loaded smb.ko and it fixed the situation. I had the line > 'ichsmb_load="YES"' in my loader.conf and it loaded smbus.ko but not > smb.ko for me. Seems like a module load dependency issue. They're all independent pieces, that's why. I realise the naming convention is confusing ("wait, what do I need? Do I need iicbus? What is that thing?!"), and older FreeBSD kernel configuration syntaxes and documentation made it even worse. Here's the breakdown in layman's terms: ichsmb(4) -- support for Intel ICHxx SMBus via PCI bus smbus(4) -- adds support for kernel SMBus API framework and interfaces with chipset SMBus driver (e.g. ichsmb(4)) smb(4) -- creates /dev/smbXX entries and provides ioctl(2) interface for userland applications Does this help reduce confusion? I don't consider this a "dependency issue" at all. These are all literally separate things; you do not meed smbus(4) and smb(4) if you just simply want to tie a driver to a feature/device that's on the PCI bus (e.g. ichsmb(4)). Besides, does kldload or kernel modules in general have *any* sort of dependency tree code? I didn't think they did. > Here's my output: > attack:~ root# smbmsg -p > Probing for devices on /dev/smb0: > Device @0x44: rw > Device @0x50: rw > Device @0x52: rw > Device @0x64: w > Device @0x80: rw > Device @0x88: w > Device @0x8c: r > Device @0xc4: rw > Device @0xd0: rw > Device @0xd2: rw > Device @0xe4: w Good deal, this is functioning normally. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From eugen at kuzbass.ru Fri Sep 12 18:35:21 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Fri Sep 12 18:35:28 2008 Subject: Long delays for USB realbtx boot In-Reply-To: <48CA9E93.3060306@FreeBSD.org> References: <48C91525.10806@incunabulum.net> <20080911162956.GA15152@svzserv.kemerovo.su> <48C9A907.8000000@incunabulum.net> <48C9AAAE.1030909@FreeBSD.org> <48CA9E93.3060306@FreeBSD.org> Message-ID: <20080912183517.GA36416@svzserv.kemerovo.su> On Fri, Sep 12, 2008 at 05:53:39PM +0100, Bruce M. Simpson wrote: > So it appears the "active" flag was not being set for the first > partition, it seems NanoBSD's fdisk script didn't set it; that should > probably get patched, as this was the root cause of the USB booting delay. I also always use boot0 for my NanoBSDs as I need safe way for remote upgrades, so have two code slices. And I always use these knobs: NANO_BOOTLOADER="boot/boot0" NANO_BOOT0CFG="-o packet -s 1 -m 3 -t 36" May it make a difference? Eugene Grosbein From bms at FreeBSD.org Fri Sep 12 18:41:54 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri Sep 12 18:42:01 2008 Subject: Long delays for USB realbtx boot In-Reply-To: <20080912183517.GA36416@svzserv.kemerovo.su> References: <48C91525.10806@incunabulum.net> <20080911162956.GA15152@svzserv.kemerovo.su> <48C9A907.8000000@incunabulum.net> <48C9AAAE.1030909@FreeBSD.org> <48CA9E93.3060306@FreeBSD.org> <20080912183517.GA36416@svzserv.kemerovo.su> Message-ID: <48CAB7EE.1030505@FreeBSD.org> Eugene Grosbein wrote: > I also always use boot0 for my NanoBSDs as I need safe way for remote > upgrades, so have two code slices. And I always use these knobs: > > NANO_BOOTLOADER="boot/boot0" > NANO_BOOT0CFG="-o packet -s 1 -m 3 -t 36" > ... Good point, it looks like NanoBSD was installing boot0sio by default. I overrode this in my config with boot0 as you do and that works for me. thanks again, BMS From bms at FreeBSD.org Fri Sep 12 18:43:35 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri Sep 12 18:43:43 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: <20080912183233.GA63271@icarus.home.lan> References: <48C927DC.6000202@incunabulum.net> <1EDB9C24-8E69-43D3-8082-2379955FF8FF@young-alumni.com> <20080912175749.GA62725@icarus.home.lan> <20080912183233.GA63271@icarus.home.lan> Message-ID: <48CAB855.2020200@FreeBSD.org> Jeremy Chadwick wrote: > I don't consider this a "dependency issue" at all. These are all > literally separate things; you do not meed smbus(4) and smb(4) if you > just simply want to tie a driver to a feature/device that's on the PCI > bus (e.g. ichsmb(4)). > > Besides, does kldload or kernel modules in general have *any* sort > of dependency tree code? I didn't think they did. > Some modules do, some modules don't. One of the issues here is that there is sometimes a diamond-like dependency graph between kernel modules, or there is no way to establish dependency at all. For example, smb(4) has no idea that ichsmb(4) should be loaded, for the very reason you point out that smb(4) isn't needed by ichsmb(4); whilst ichsmb(4) presents an smbus(4) interface in the kernel, which smb(4) will recognise and attach to, it has no idea that it should get loaded. Having said that, I thought your plain language explanation of how things are was excellent and clear. cheers BMS From jon at witchspace.com Fri Sep 12 19:01:31 2008 From: jon at witchspace.com (Jonathan Belson) Date: Fri Sep 12 19:01:38 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: <48CAAB1A.9070502@incunabulum.net> References: <48C927DC.6000202@incunabulum.net> <48C932D9.50604@thekeelecentre.com> <48C934D1.5030703@incunabulum.net> <48C93582.3080107@thekeelecentre.com> <48C93903.5060604@protected-networks.net> <20080912072037.GC49512@icarus.home.lan> <48CAAB1A.9070502@incunabulum.net> Message-ID: <48CAB8AB.3040802@witchspace.com> Bruce M Simpson wrote: > Jeremy Chadwick wrote: >> I'm trying my best to make things better, doing things purely from a >> userland perspective and using SMBus exclusively (since the interface is >> quite reliable, assuming the SMBus driver used on FreeBSD is working >> correctly). I understand-- Bruce is having problems with ichsmb(4), >> while on every ICH7 board I have (and I have many), I've had nothing but >> success. All of bsdhwmon's main development has been done on ICH7 >> boards I use and have physical access to, for example. I have a Dell PowerEdge SC440 here and I'm not having much luck with smbmsg: # smbmsg -p Probing for devices on /dev/smb0: [ lots and lots of 'ichsmb0: device timeout, status=0x41' ] As far as I can see, I've got all the relevant devices built into the kernel (from kldstat -v: ichsmb/smbus, pci/ichsmb, iicbus/iicsmb, smbus/smb, intsmb/smbus, pci/intsmb). This is a Dell-branded motherboard, so I've no idea what it's based on. The boot message shows 'ichsmb0: '. Cheers, --Jon From bms at FreeBSD.org Fri Sep 12 19:36:20 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri Sep 12 19:36:27 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: <48CAAB1A.9070502@incunabulum.net> References: <48C927DC.6000202@incunabulum.net> <48C932D9.50604@thekeelecentre.com> <48C934D1.5030703@incunabulum.net> <48C93582.3080107@thekeelecentre.com> <48C93903.5060604@protected-networks.net> <20080912072037.GC49512@icarus.home.lan> <48CAAB1A.9070502@incunabulum.net> Message-ID: <48CAC4B1.6030108@FreeBSD.org> Bruce M Simpson wrote: > > I fished out the A/Open MX3S board I have. ... > So I can confirm SMBus works on the MX3S from Linux 2.6.x. I'll blow > it away with 7.1-BETA and see what happens next. I can confirm that SMBus appears to work on the A/Open MX3S under FreeBSD 7.1-BETA. After kldload ichsmb and kldload smb: %%% ichsmb0: port 0x5000-0x500f at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 %%% smbmsg -p: %%% Probing for devices on /dev/smb0: Device @0x30: rw Device @0x50: rw Device @0xb0: rw Device @0xd0: rw %%% pciconf -a seems to be broken: %%% raisin:~ % s pciconf -a pci0:0:31:3 pciconf: ioctl(PCIOCATTACHED): Inappropriate ioctl for device %%% My theory at the moment is that the working platforms might have had some other bits twiddled in PCI config space. I'm ruling that out for now, based on the fact that when I dump the CSRs for the SMBus function on both the ICH2 (known good, working) and ICH7 (suspect), the HOSTC register contents are the same (SMBus is enabled) and both have interrupt lines routed to them. working system, ICH2: %%% raisin# pciconf -r pci0:0:31:3 0:0x40 24438086 02800001 0c050002 00000000 00000000 00000000 00000000 00000000 00005001 00000000 00000000 244b8086 00000000 00000000 00000000 0000020c 00000001 %%% suspect system, ICH7: %%% foo:~ % s pciconf -r pci0:0:31:3 0:0x40 27da8086 02800001 0c050001 00000000 00000000 00000000 00000000 00000000 00000501 00000000 00000000 27da8086 00000000 00000000 00000000 00000213 00000001 %%% Both are using SMP-enabled kernels. The working system is running a 7.1-BETA kernel, GENERIC so it has SMP, but it's a uniprocessor 633MHz Celeron; the suspect system has dual-core (I *think* it is Intel Atom). I'm not sure how that could make a difference. The ichsmb(4) driver uses msleep() (now deprecated) to avoid busy-waiting when polling for SMB transaction completion. On the suspect system, msleep() always times out. So both are using ithreads... AHA! After a reboot it looks like I can see a device on the suspect system, interesting. But after the first probe, it doesn't respond. This could well be down to the implementation of that particular SMBus device on the platform, and it tends to move the finger of suspicion away from the smbus drivers themselves. cheers BMS From bruce at cran.org.uk Fri Sep 12 23:29:07 2008 From: bruce at cran.org.uk (Bruce Cran) Date: Fri Sep 12 23:29:19 2008 Subject: ACPI regression on recent 7.0-STABLE: HPET stops working In-Reply-To: <200807231116.02389.jhb@freebsd.org> References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <200807221514.55055.jhb@freebsd.org> <20080723140927.duc11agcg44ockw4@webmail.opentransfer.com> <200807231116.02389.jhb@freebsd.org> Message-ID: <20080913002850.26f322ab@tau.draftnet> On Wed, 23 Jul 2008 11:16:02 -0400 John Baldwin wrote: > I've committed the patch. However, I think this actually points out > a slightly bigger issue in that the HPET timer is probably > piggybacking on the ichsmb0 device's BAR, and they really should both > be able to attach somehow. > > A way to fix that would be to make the HPET device actually borrow > the PCI device's resource instead of allocating its own perhaps. I > think the HPET ACPI device and the table tell us the PCI deviec the > HPET lives in. > I just upgraded from 7.0-p3 to 7.1-PRERELEASE on my Dell I1501 laptop and hit this problem too. I noticed the patch was committed to HEAD - are there any plans to MFC it for 7.1? -- Bruce Cran From bms at incunabulum.net Sat Sep 13 02:13:35 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sat Sep 13 02:13:42 2008 Subject: alpm(4) I/O range is claimed by ACPI In-Reply-To: <200809111043.18265.jhb@freebsd.org> References: <48C8F684.8090409@incunabulum.net> <20080911110407.GC25493@icarus.home.lan> <48C927D6.5020800@incunabulum.net> <200809111043.18265.jhb@freebsd.org> Message-ID: <48CB21C7.9050706@incunabulum.net> John Baldwin wrote: > Umm, ACPI will allow children devices to allocate their resources out of > the "sysresource" pool. IPMI has to do this on some systems where ACPI > claims the IPMI I/O ports as a system resource. But surely if alpm(4) were to attach to such a range in this way, it would need to be a child of the acpi bus device, yes? The IPMI driver probes for a specific ACPI ID in the DSDT. PCI ID looks like this: alpm0@pci0:0:30:1: class=0x068000 card=0x81561043 chip=0x710110b9 rev=0x00 hdr=0x00 So I grabbed the M1543 datasheet off the web and looked in CSR space. Guess what: the AMI BIOS on the ASUS Vintage AH-1 does NOT set up the PMU. The function is still visible, it just has no active I/O mappings. No wonder alpm(4) does not attach. I tried looking for this device in the DSDT, I don't see anything which obviously resembles it. The equivalent Linux driver has a means of forcing the mapping to be set up if it isn't available: http://www.kernel.org/doc/Documentation/i2c/busses/i2c-ali15x3 It looks like there used to be a means of doing this in the FreeBSD driver but it got nuked. And that ASUS didn't much care about power management support in this machine... Oh well! I know ichsmb works on at least one machine that I have. cheers BMS From uspoerlein at gmail.com Sat Sep 13 14:02:07 2008 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Sat Sep 13 14:02:14 2008 Subject: Any working ichsmb(4) platforms out there? In-Reply-To: <48C927DC.6000202@incunabulum.net> References: <48C927DC.6000202@incunabulum.net> Message-ID: <20080913130139.GM76117@roadrunner.spoerlein.net> On Thu, 11.09.2008 at 15:14:52 +0100, Bruce M Simpson wrote: > Does anyone have ichsmb(4) actually seeing SMBus devices? > e.g. you run "smbmsg -p" on your FreeBSD-STABLE system and see something. > > I just tried it again on my IBM ThinkPad T43 and saw nothing, all I get is: > ichsmb0: device timeout, status=0x41 > ...in dmesg. No luck with an ICH5, here: ichsmb0: port 0x2400-0x241f irq 17 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] smbus0: on ichsmb0 smb0: on smbus0 ichsmb0: device timeout, status=0x41 ichsmb0: device timeout, status=0x41 ichsmb0: device timeout, status=0x41 ichsmb0: device timeout, status=0x41 ... # uname -rsm FreeBSD 6.3-STABLE i386 # devinfo -v|grep smb ichsmb0 pnpinfo vendor=0x8086 device=0x24d3 subvendor=0x1734 subdevice=0x101c class=0x0c0500 at slot=31 function=3 handle=\_SB_.PCI0.PM__ # kenv|grep smb smbios.bios.reldate="11/25/2004" smbios.bios.vendor="FUJITSU SIEMENS // Phoenix Technologies Ltd." smbios.bios.version="5.00 R2.14.1534.01 " smbios.chassis.maker="FUJITSU SIEMENS" smbios.chassis.serial="YBFC445826 " smbios.chassis.tag=" " smbios.chassis.version="SCEE " smbios.planar.maker="FUJITSU SIEMENS" smbios.planar.product="D1534" smbios.planar.serial=" " smbios.planar.version="S26361-D1534" smbios.socket.enabled="1" smbios.socket.populated="1" smbios.system.maker="FUJITSU SIEMENS" smbios.system.product="SCENIC E" smbios.system.serial="YBFC445826 " smbios.system.uuid="93D4A7A3-705F-11D9-8688-00300577E7A0" smbios.system.version=" " Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From jhb at freebsd.org Sat Sep 13 15:20:20 2008 From: jhb at freebsd.org (John Baldwin) Date: Sat Sep 13 15:20:28 2008 Subject: alpm(4) I/O range is claimed by ACPI In-Reply-To: <48CB21C7.9050706@incunabulum.net> References: <48C8F684.8090409@incunabulum.net> <200809111043.18265.jhb@freebsd.org> <48CB21C7.9050706@incunabulum.net> Message-ID: <200809131109.06694.jhb@freebsd.org> On Friday 12 September 2008 10:13:27 pm Bruce M Simpson wrote: > John Baldwin wrote: > > Umm, ACPI will allow children devices to allocate their resources out of > > the "sysresource" pool. IPMI has to do this on some systems where ACPI > > claims the IPMI I/O ports as a system resource. > > But surely if alpm(4) were to attach to such a range in this way, it > would need to be a child of the acpi bus device, yes? No, the code in acpi_alloc_resources() does _not_ check for that. Any child device with a specific allocation that falls in a system resource range will succeed the allocation. > The IPMI driver > probes for a specific ACPI ID in the DSDT. The IPMI driver also attaches on the isa0 device via the SMBIOS tables, and that is the case where the resources clash with ACPI's system resources. IPMI devices listed in the ACPI namespace don't have their resources listed in ACPI's system resources. > PCI ID looks like this: > alpm0@pci0:0:30:1: class=0x068000 card=0x81561043 chip=0x710110b9 > rev=0x00 hdr=0x00 > > So I grabbed the M1543 datasheet off the web and looked in CSR space. > Guess what: the AMI BIOS on the ASUS Vintage AH-1 does NOT set up the > PMU. The function is still visible, it just has no active I/O mappings. > No wonder alpm(4) does not attach. > > I tried looking for this device in the DSDT, I don't see anything which > obviously resembles it. The equivalent Linux driver has a means of > forcing the mapping to be set up if it isn't available: > http://www.kernel.org/doc/Documentation/i2c/busses/i2c-ali15x3 > > It looks like there used to be a means of doing this in the FreeBSD > driver but it got nuked. And that ASUS didn't much care about power > management support in this machine... If you can re-enable it in such a way that it uses bus_alloc_resource(), then the driver will probably work fine. > Oh well! I know ichsmb works on at least one machine that I have. > > cheers > BMS -- John Baldwin From kensmith at cse.Buffalo.EDU Sat Sep 13 18:39:47 2008 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Sat Sep 13 18:40:00 2008 Subject: FreeBSD 7.1-BETA/6.4-BETA Available... Message-ID: <1221331179.35788.70.camel@neo.cse.buffalo.edu> The FreeBSD 7.1-BETA and 6.4-BETA builds are now available on the FreeBSD FTP mirror sites. This is the first step in the release process for FreeBSD-7.1 and FreeBSD-6.4. This set of builds do not include pre-built packages. The ISOs are available from: ftp://ftp.freebsd.org/pub/FreeBSD/releases/${arch}/ISO-IMAGES/7.1/ ftp://ftp.freebsd.org/pub/FreeBSD/releases/${arch}/ISO-IMAGES/6.4/ where $arch is one of alpha, amd64, i386, ia64, pc98, powerpc, or sparc64. For the Tier-2 architectures ia64 and powerpc only the 7.1-BETA builds are available. For the Tier-2 architecture alpha only the 6.4-BETA builds are available. We encourage people to help out with the testing. Problems can be reported through Gnats or on the freebsd-stable@freebsd.org mailing list. At this point we expect the 6.4-RC1 builds to start in about two weeks, and the 7.1-RC1 builds a week after that. Checksums for the ISOs: ------------ MD5 (6.4-BETA-alpha-bootonly.iso) = 3e222422a6c029b8b1922dbbfeb4b040 MD5 (6.4-BETA-alpha-disc1.iso) = 94a7df84eaa9111ee34ab849c9211560 MD5 (6.4-BETA-alpha-docs.iso) = 8a4606e35db9c2dc0ae1b6a6ea17eed2 SHA256 (6.4-BETA-alpha-bootonly.iso) = f11dcdf0d8eb549a273ac15ce4b2434a4ac90990565d8bd45f1901b01a818936 SHA256 (6.4-BETA-alpha-disc1.iso) = 244b65286c8c8c6b7270320506eb2fd233f0cf4ca968613384496aa10a706f75 SHA256 (6.4-BETA-alpha-docs.iso) = 49d753dfb3cfd80b137b2b10f34e30799a0765e03561863279de420119f02333 MD5 (7.1-BETA-amd64-bootonly.iso) = 72fdf9c01667c99bb6153101b188122d MD5 (7.1-BETA-amd64-disc1.iso) = 87f7e93ca707b08a08accf989ff7060b MD5 (7.1-BETA-amd64-disc2.iso) = 707fdd5281a66268eb72fa975caeada5 MD5 (7.1-BETA-amd64-disc3.iso) = cc100e18c8790d66fe192e7f71f4e5aa MD5 (7.1-BETA-amd64-docs.iso) = 98e21ba5a44912fbf9dcdc4b8cf23a7a MD5 (7.1-BETA-amd64-livefs.iso) = e9a4a8c20db73408990c70fdac3c3d22 SHA256 (7.1-BETA-amd64-bootonly.iso) = ec9054b879cf154e553776233c3bbe31e93c613778e1d107897528d1f63cf4fb SHA256 (7.1-BETA-amd64-disc1.iso) = b3ddcab735c4ea3f096d92d212940216859bbd47403896eb2e741d5ad2db6d7c SHA256 (7.1-BETA-amd64-disc2.iso) = b9ffb599f849a3ba8d2354c847d7c9715e954f2d1aa179a530238ee462ca8014 SHA256 (7.1-BETA-amd64-disc3.iso) = c8b9d99239481339001aeda45c06104ccfa93e6e11f682fff054c30e612106aa SHA256 (7.1-BETA-amd64-docs.iso) = e92d6c5858aa540588775d2eb3708e3fc85078ddaba860c5c2704523a54728cb SHA256 (7.1-BETA-amd64-livefs.iso) = fb733dbdd3c755215e80678706a76963254decff6800d3b2adde4b55e90dee59 MD5 (6.4-BETA-amd64-bootonly.iso) = ac3b2b39cd8c875be4dbc7a7ccbcce24 MD5 (6.4-BETA-amd64-disc1.iso) = ec5c1df7a0b4be9a8f5ecdd1d23d1209 MD5 (6.4-BETA-amd64-disc2.iso) = 37e54556eabf8df7514aecc7134b53b3 MD5 (6.4-BETA-amd64-disc3.iso) = 636fded834831e7f60a75f83537b30a7 MD5 (6.4-BETA-amd64-docs.iso) = 2e435bcc934600fb1ddedf0102c70e01 SHA256 (6.4-BETA-amd64-bootonly.iso) = e13fe3e4b8c7fab0d433e38fdf5de27bf8ffdfa996d3b6c68459a8fda7100a9a SHA256 (6.4-BETA-amd64-disc1.iso) = a6a8dbfaf34d404058e0a62dce29526d30d86a15aca1c46521e01d976b36d651 SHA256 (6.4-BETA-amd64-disc2.iso) = 58470a464d57658aaf5b7c5783684a20b64d0078c1007b50a332efdf1ce761a9 SHA256 (6.4-BETA-amd64-disc3.iso) = af3e2447b87a97c78f4e59fc3f083ceaeaa9f4c3e466411d55250d9a354d6d6d SHA256 (6.4-BETA-amd64-docs.iso) = 009292acad493678e540c9209407df7b63dfaf689f35b04cb846fbdbba4b801c MD5 (7.1-BETA-i386-bootonly.iso) = a3885274226f96f21ddf22b3047c858d MD5 (7.1-BETA-i386-disc1.iso) = f06c2453309e001cd67f72bb954a4b4a MD5 (7.1-BETA-i386-disc2.iso) = 38cfeeb16db98c37189336f055b41756 MD5 (7.1-BETA-i386-disc3.iso) = af70d157f064e39bf790505f185e565f MD5 (7.1-BETA-i386-docs.iso) = 23adf38460f2f1febaa58c294f03b120 MD5 (7.1-BETA-i386-livefs.iso) = 26d91e9a60243db9e28113a391d80e8f SHA256 (7.1-BETA-i386-bootonly.iso) = 87eba44221e41a0928bc3ebdd753e28c3c66315fc58954a3a79b261dee94cc5a SHA256 (7.1-BETA-i386-disc1.iso) = 096ad85048a660684731ec4fd1f4a384ae4a76c3256726dfb61b4a4d8213d107 SHA256 (7.1-BETA-i386-disc2.iso) = 22a6207200978cafee5aa186275e1e0b60fc8f8a75f1351a1377a5f3bca14b76 SHA256 (7.1-BETA-i386-disc3.iso) = e4241590f10315be2e1b4b51e36d882e287d97654f5a9e13f9089ade87a91541 SHA256 (7.1-BETA-i386-docs.iso) = c2caa0a0d2151866c7b24f49944dab55cede84b209dfd2036e4745dc7b89b9e9 SHA256 (7.1-BETA-i386-livefs.iso) = eef80a184b5b2d1d2504dd80e2ca000612b8a0139e059cbe12c7122774159537 MD5 (6.4-BETA-i386-bootonly.iso) = f71aeb1bfc51ce9c744eebf9e542c52a MD5 (6.4-BETA-i386-disc1.iso) = 3710f169c1b29d9aee64b883ba7ae481 MD5 (6.4-BETA-i386-disc2.iso) = 8959ecb31dd11a635dc8758bfa8b37a7 MD5 (6.4-BETA-i386-disc3.iso) = fa95fc7842598e00a4d7ff853e406dfc MD5 (6.4-BETA-i386-docs.iso) = 3a95e600000589bef780e2166adeed0e SHA256 (6.4-BETA-i386-bootonly.iso) = 00fba46869644b4ac52bc7ec4b69b2d5bbe17a9ff423d4e1d899f59bc824bb80 SHA256 (6.4-BETA-i386-disc1.iso) = dba12bb568328e284cd75ff9f6b69fb52a7ec34be9a38c3c0be1d44adf8f9dcf SHA256 (6.4-BETA-i386-disc2.iso) = 52dd575e05bdf4626a5353329e7a92d9e2f8562640df3b82d21cedda86d86640 SHA256 (6.4-BETA-i386-disc3.iso) = 172d43f77a7afa84158215ef72420cc165cc9d4d873c81bd1cd0af9f80f8ac61 SHA256 (6.4-BETA-i386-docs.iso) = 9633cd9d2b553ef36f0442219cabe6261cf8d79c84c3528e85a58f5185a242b1 MD5 (7.1-BETA-ia64-bootonly.iso) = e1986dfa000e2170a45105346a849ca3 MD5 (7.1-BETA-ia64-disc1.iso) = caab8fb8f7f67dc98d0ddba3fd336e85 MD5 (7.1-BETA-ia64-docs.iso) = 0fa4b3be3755cbf0130710b289cd62c2 MD5 (7.1-BETA-ia64-livefs.iso) = f50a38df8ebc98ae56ff5b794d3f2643 SHA256 (7.1-BETA-ia64-bootonly.iso) = 87030e8802c0ca0fc7bf96271b2a530524485a2eff72c6182d3be1cb27867587 SHA256 (7.1-BETA-ia64-disc1.iso) = 32b0562d66902d09911f30844407a8b40a9299f6014a2de5ed4bfe1514207d1d SHA256 (7.1-BETA-ia64-docs.iso) = 42f4e967c6ce045db478fe9ac599877eb42c33ec0771017b10140bf80b3ced36 SHA256 (7.1-BETA-ia64-livefs.iso) = 88387b45f7d50db58bc7d643acd4d1853df6ec86416fee7f08797602fc4c0516 MD5 (7.1-BETA-pc98-bootonly.iso) = 68196648c68fb4cb713607c72b42e891 MD5 (7.1-BETA-pc98-disc1.iso) = cb34f6468a7206c77e8ae918117841b0 MD5 (7.1-BETA-pc98-livefs.iso) = 582edf1c52d1bdb013158d102dbd11fe SHA256 (7.1-BETA-pc98-bootonly.iso) = 2dbc37babb6bdc31250a8014bb95ee50d0678c4c9ba2dcb241bc3fb766538b24 SHA256 (7.1-BETA-pc98-disc1.iso) = 5bf6662e4c60f86c86c38dbe08ea9a713436bf99173219c0f1888bb7abf3ca66 SHA256 (7.1-BETA-pc98-livefs.iso) = 8869fba63ed00072fc55fdfc9176d3b4947a393bb8496c88af4a909c26750fec MD5 (6.4-BETA-pc98-bootonly.iso) = c802290e1f8ba468682f3f6bdcafd970 MD5 (6.4-BETA-pc98-disc1.iso) = b5e8bc8f75ca7931a5d5774b5884a27e SHA256 (6.4-BETA-pc98-bootonly.iso) = 5d625e75b34b41da7ada3309bc9e8362b961ba41d2f7820697bccb395fdf9389 SHA256 (6.4-BETA-pc98-disc1.iso) = 08b0d379781ba1fffed428d79dae7f46514f60857b466a6699b44cbfffe6cb1b MD5 (7.1-BETA-powerpc-bootonly.iso) = 46432c50e37d544edfeaafce36669302 MD5 (7.1-BETA-powerpc-disc1.iso) = a75d63c141825b49e2995b16f7e589d8 MD5 (7.1-BETA-powerpc-docs.iso) = f77e7100e5851c46018554b0f915deae SHA256 (7.1-BETA-powerpc-bootonly.iso) = 795ed4d9c0cdabc5347e1e34a8a82f7f615501087ac9c66f03e36010903e945b SHA256 (7.1-BETA-powerpc-disc1.iso) = ac41b89a3123b7615db1716706f0c8cda3f60259fc052c0b503eed048be7137d SHA256 (7.1-BETA-powerpc-docs.iso) = 824edcf668819eeab94a87b324c11619e6af57fb45a170648207320a121c8916 MD5 (7.1-BETA-sparc64-bootonly.iso) = 692a01f6caab4803ecf9ed17abd61e9c MD5 (7.1-BETA-sparc64-disc1.iso) = 7092a46fab7ccb05db785a32c1af08c3 MD5 (7.1-BETA-sparc64-disc2.iso) = 2f359e0903676eced8e8375ca4447a1f MD5 (7.1-BETA-sparc64-disc3.iso) = 531b611408530f9f25d11fdb1d8b9835 MD5 (7.1-BETA-sparc64-docs.iso) = dc348caaeeba589cee00119aa5b71da7 SHA256 (7.1-BETA-sparc64-bootonly.iso) = 7ec15f71f2f86d0fadcc948277e4f16fff74de144c9fe570eef7385eaf53663d SHA256 (7.1-BETA-sparc64-disc1.iso) = 2b650b04fe2bf8daf4217c5433f005219f30071a022573bee6fe99c08594c43d SHA256 (7.1-BETA-sparc64-disc2.iso) = 01f9033d8e0cd04664a74e188ba79aa7f4964ebabea2f06002d4dd8334fc17f3 SHA256 (7.1-BETA-sparc64-disc3.iso) = eef05abda7ab3e91538dcf4463992fdffb3a0fabeebc8687ccd617659dd98491 SHA256 (7.1-BETA-sparc64-docs.iso) = 53a0330ae9753e52ca8f76a4cacdf7b18bd23be8230e01e8690ad26d9da2a5e9 MD5 (6.4-BETA-sparc64-bootonly.iso) = ffb805b08bf565e5aa86c897c22842a1 MD5 (6.4-BETA-sparc64-disc1.iso) = 11de6709c6fc877f2c56d8631eba6cd2 MD5 (6.4-BETA-sparc64-disc2.iso) = e98001cf234c309914460321ea5aa346 MD5 (6.4-BETA-sparc64-disc3.iso) = 5d23f5bacf271cfca51bea42476a49b7 MD5 (6.4-BETA-sparc64-docs.iso) = bda7ae7675fb5ed689f7af398751ac29 SHA256 (6.4-BETA-sparc64-bootonly.iso) = 36c73e2aab8eac46ddea4372c7f42147545009e410314b420a03b8dfe0778c59 SHA256 (6.4-BETA-sparc64-disc1.iso) = 33069aa05fb83219a868000bcc542acd9cf0b58f82144adcd806b4bd39c02563 SHA256 (6.4-BETA-sparc64-disc2.iso) = 01ecb7abd009219d3fe7fe6b2a923fa5fed91c084e4ac68be45e221274e56ec8 SHA256 (6.4-BETA-sparc64-disc3.iso) = a8618809453e0107f272a7f291331ee9650dec0fc14595d0f64667b32d9aaa80 SHA256 (6.4-BETA-sparc64-docs.iso) = c3c835540f4fc8033ee0645a8d51142943feb06c364371dc12f52028bc74a8f8 -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080913/b889a649/attachment.pgp From shoesoft at gmx.net Sat Sep 13 18:57:19 2008 From: shoesoft at gmx.net (Stefan Ehmann) Date: Sat Sep 13 18:57:27 2008 Subject: ipfw uid regression Message-ID: <200809132030.34870.shoesoft@gmx.net> I've updated from 7.0 to RELENG_7 today. ipfw uid rules have caused problems in the past with PREEMPTION enabled. This was fixed in 7.0, at least for me. In RELENG_7 the old problems are back: Total freeze within some seconds/minutes after the first network access. With WITNESS I get a LOR, see at the end of dmesg. Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #58: Sat Sep 13 19:38:47 CEST 2008 stefan@taxman.pepperland:/usr/obj/usr/src/sys/TAXMAN WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) XP 2700+ (2166.44-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383fbff AMD Features=0xc0400800 real memory = 1073725440 (1023 MB) avail memory = 1032847360 (985 MB) ACPI APIC Table: ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xd7000000-0xd7ffffff,0xe0000000-0xefffffff,0xd6000000-0xd6ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] pcm0: port 0xd800-0xd81f,0xd400-0xd40f,0xd000-0xd00f,0xb800-0xb83f irq 16 at device 13.0 on pci0 pcm0: [ITHREAD] pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0xd634 XIN2 Clock Source: 22.5792MHz(44.1kHz*512) MPU-401 UART(s) #: 1 AC'97 codec: not exist ADC #: 1 DAC #: 1 Multi-track converter type: I2S(96KHz support, 24bit resolution, ID#0x2) S/PDIF(IN/OUT): 1/1 ID# 0x00 GPIO(mask/dir/state): 0x04/0xfb/0xfe pci0: at device 15.0 (no driver attached) uhci0: port 0xb400-0xb41f at device 16.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb000-0xb01f at device 16.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xa800-0xa81f at device 16.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xd5800000-0xd58000ff at device 16.3 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xa400-0xa40f at device 17.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] vr0: port 0xa000-0xa0ff mem 0xd5000000-0xd50000ff at device 18.0 on pci0 vr0: Quirks: 0x0 vr0: Revision: 0x74 miibus0: on vr0 rlphy0: PHY 1 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:0e:a6:40:3f:d0 vr0: [ITHREAD] cpu0: on acpi0 acpi_button0: on acpi0 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd5fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ums0: on uhub0 ums0: 3 buttons and Z dir. Timecounter "TSC" frequency 2166438045 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled ad0: 305245MB at ata0-master UDMA100 acd0: DVDROM <@LEP HB @D \^R/\^B0> at ata1-master UDMA33 acd1: DVDR at ata1-slave UDMA33 WARNING: WITNESS option enabled, expect reduced performance. GEOM_LABEL: Label for provider acd0 is iso9660/K3b data project. Trying to mount root from ufs:/dev/ad0s1a lock order reversal: 1st 0xc0a338cc IPFW static rules (IPFW static rules) @ /usr/src/sys/modules/ipfw/../../netinet/ip_fw2.c:2469 2nd 0xc08c1a4c tcp (tcp) @ /usr/src/sys/modules/ipfw/../../netinet/ip_fw2.c:2016 KDB: stack backtrace: db_trace_self_wrapper(c07e5ba8,e48b2770,c05a6ede,c07e80cd,c08c1a4c,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07e80cd,c08c1a4c,c07e817e,c07e817e,c0a31b2d,...) at kdb_backtrace+0x29 witness_checkorder(c08c1a4c,1,c0a31b2d,7e0,c0a2c8e3,...) at witness_checkorder+0x6de _rw_rlock(c08c1a4c,c0a31b2d,7e0,0,0,...) at _rw_rlock+0x8e ipfw_chk(e48b2abc,41ec0d7e,0,0,c4777100,...) at ipfw_chk+0x35a4 ipfw_check_in(0,e48b2bc0,c453c400,1,0,...) at ipfw_check_in+0xd7 pfil_run_hooks(c08c0d00,e48b2c14,c453c400,1,0,...) at pfil_run_hooks+0x88 ip_input(c4777100,14e,800,c453c400,800,...) at ip_input+0x24d netisr_dispatch(2,c4777100,10,3,0,...) at netisr_dispatch+0x73 ether_demux(c453c400,c4777100,3,0,3,...) at ether_demux+0x1f1 ether_input(c453c400,c4777100,c09b95e3,585,e48b2cc0,...) at ether_input+0x37f vr_intr(c453e000,0,c07df398,4b6,c437e3e8,...) at vr_intr+0x370 ithread_loop(c455b8d0,e48b2d38,c07df0fd,31c,c455d828,...) at ithread_loop+0x1c5 fork_exit(c054c050,c455b8d0,e48b2d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe48b2d70, ebp = 0 --- From bms at incunabulum.net Sun Sep 14 14:14:47 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Sun Sep 14 14:14:56 2008 Subject: alpm(4) I/O range is claimed by ACPI In-Reply-To: <200809131109.06694.jhb@freebsd.org> References: <48C8F684.8090409@incunabulum.net> <200809111043.18265.jhb@freebsd.org> <48CB21C7.9050706@incunabulum.net> <200809131109.06694.jhb@freebsd.org> Message-ID: <48CD1C54.7040208@incunabulum.net> John Baldwin wrote: >> But surely if alpm(4) were to attach to such a range in this way, it >> would need to be a child of the acpi bus device, yes? >> > > No, the code in acpi_alloc_resources() does _not_ check for that. Any child > device with a specific allocation that falls in a system resource range will > succeed the allocation. > Ah, it is clearer after looking at devinfo output. Allocations will bubble up the bus drivers until they get to nexus. In this case, acpi is a child of nexus, therefore it will satisfy the allocation. >> It looks like there used to be a means of doing this in the FreeBSD >> driver but it got nuked. And that ASUS didn't much care about power >> management support in this machine... >> > > If you can re-enable it in such a way that it uses bus_alloc_resource(), then > the driver will probably work fine. > In that case it sounds like one needs to be able to use a hard-wired hint. It has been over a year since I've been able to do any proper work on mips , which needs a lot of this sort of thing, and I don't have a compelling case to do it now, so hopefully someone with an interest can pick this up. cheers BMS From kamikaze at bsdforen.de Sun Sep 14 16:53:30 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Sun Sep 14 16:53:37 2008 Subject: crossbuilding of RELENG_7 broken? Message-ID: <48CD3A19.8030404@bsdforen.de> Hello, I've been building my i386 systems on an amd64 system for some time, now and this is the first time I encounter problems. Building them works fine, but when I nfs-mount /usr/obj and /usr/src on the target system, install does not work. Neiter installkernel nor installworld. I can install the Kernel by cd-ing into the right directory und /usr/obj and run 'make install', but I have not found a workaround for installing world. Does anyone else encounter this? If someone is interested I'll produce some logs, but I'll have to compile again - I've thrown away all built attempts in my frustration. From fbsd-ml at scrapper.ca Sun Sep 14 19:47:35 2008 From: fbsd-ml at scrapper.ca (Norbert Papke) Date: Sun Sep 14 19:47:43 2008 Subject: Possible UDP related deadlock in 7.1-PRERELEASE Message-ID: <200809141219.24943.fbsd-ml@scrapper.ca> Environment: * i386, 7.1 Prerelease (updated today) with a custom UP kernel, ULE scheduler * KDE 3.5.10 * NIC does not share interrupts with another device * See below for configuration files Symptoms: * I can trigger this lockup reliably by starting ktorrent. After a short while (one to two minutes), it locks up. Other commands, e.g., netstat, also lock up. * The console generates "nfe0: watchdog timeout" error messages. * The system becomes unusable and must be rebooted. Attempted Work-arounds: * I have replaced the NIC. No change except now the console now generates "dc0: watchdog timeout". * I have tried an SMP kernel. No change. Attempted Diagnosis: If I break into DDB, the 'ps' output shows a number of processes that seem to be locked related to udp. [irq18:dc0] L *udp ktorrent L *udpinp hald L *udp ntpd L *udp Unfortunately, I am rapidly getting out of my depth here. I have no idea how to go about further analyzing this problem and would appreciate help. Cheers, -- Norbert. /boot/loader.conf: loader_logo=beastie verbose_loading="YES" cpufreq_load="YES" geom_gpt_load="YES" hwpmc_load="YES" # File systems cd9660_load="YES" msdosfs_load="YES" # NIC supprt (MII provides common controller code) miibus_load="YES" if_dc_load=YES pflog_load="YES" procfs_load="YES" # USB ugen_load="YES" uhid_load="YES" ukbd_load="YES" umass_load="YES" ums_load="YES" # Linux linprocfs_load="YES" linux_load="YES" nvidia_load="YES" pseudo_load="YES" random_load="YES" snd_hda_load="YES" # SYSV support sysvmsg_load="YES" sysvsem_load="YES" sysvshm_load="YES" # For gamin kern.maxfiles="25000" # For ZFS vm.kmem_size="512M" vm.kmem_size_max="512M" vfs.zfs.arc_max="160M" vfs.zfs.arc_min="100M" vfs.zfs.vdev.cache.size="5M" vfs.zfs.debug=1 vfs.zfs.prefetch_disable="1" Kernel Config: machine i386 cpu I686_CPU ident NGP makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options KDB # kernel debugger (just in case) options KDB_TRACE options DDB # kernel debugger (just in case) options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options KTRACE # ktrace(1) support options STACK # stack(9) support options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI options HWPMC_HOOKS # hwpmc(4) performance measurements support. also needs device or kernel module #option KVA_PAGES=512 # bigger kernel address space (2GB) for ZFS (conflicts with nvidia-driver) # Alternate Queuing of network packets options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) #options ALTQ_NOPCC # Required for SMP build device apic # I/O APIC # Bus support. device eisa device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering device atapicam # SCSI emulation for ATA device scbus device cd # SCSI CD (for atapicam) device da # SCSI disk (for umass) device pass # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc option SC_HISTORY_SIZE=1000 # normal output options SC_NORM_ATTR=(FG_GREEN|BG_BLACK) options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN) # kernel messages options SC_KERNEL_CONS_ATTR=(FG_LIGHTRED|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED) # Add suspend/resume support for the i8254. device pmtimer # Parallel port device ppc device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support # Pseudo devices. device loop # Network loopback device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support (specific devices loaded as modules) device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # cannot be module -- otherwise compile errors From mh at kernel32.de Mon Sep 15 07:56:12 2008 From: mh at kernel32.de (Marian Hettwer) Date: Mon Sep 15 07:56:19 2008 Subject: RELENG_7 nvidia xorg hard lock In-Reply-To: <1221235898.1784.9.camel@localhost> References: <1221235898.1784.9.camel@localhost> Message-ID: <6aff3946d1ffdd72561648b346093be3@localhost> >> Reply to myself: >> >> it seems, that the nvidia card isn't recognized by the nvidia kld. >> xorg.log states: >> (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module! Please >> ensure >> (EE) NVIDIA(0): that there is a supported NVIDIA GPU in this system, >> and >> (EE) NVIDIA(0): that the NVIDIA device files have been created >> properly. >> (EE) NVIDIA(0): Please consult the NVIDIA README for details. >> (EE) NVIDIA(0): *** Aborting *** >> >> Wh00t? This card worked before... >> nvidia0: on vgapci0 >> vgapci0: child nvidia0 requested pci_enable_busmaster >> vgapci0: child nvidia0 requested pci_enable_io >> nvidia0: [GIANT-LOCKED] >> nvidia0: [ITHREAD] >> >> Something is odd here... >> > > Obviously Xorg has nothing to do with this issue. You are right on that point. > Please make sure that your nvidia module is up-to-date and in sync with > current kernel. It is. I double checked that. > If I were you, I would delete nvidia-driver package, make sure that it has > gone from /boot/modules, than download latest driver version > and recompile it. After that try to reboot and see what happens. > That's what I actually did. "make deinstall" the nvidia-driver, checked /boot/modules and recompiled the driver. Afterwards reboot, since the pkg-message states, users of 7.X and above shouldn't use kldload but loader.conf instead (why's that by the way???). Still no luck. The card doesn't get recognized. And it used to work, as I wrote in my initial mail. I even plugged the card into a different box to verify that the hardware is okay. It is! best regards, Marian > > From peterjeremy at optushome.com.au Mon Sep 15 08:41:58 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Mon Sep 15 08:42:06 2008 Subject: crossbuilding of RELENG_7 broken? In-Reply-To: <48CD3A19.8030404@bsdforen.de> References: <48CD3A19.8030404@bsdforen.de> Message-ID: <20080915084126.GW15376@server.vk2pj.dyndns.org> On 2008-Sep-14 18:21:45 +0200, Dominic Fandrey wrote: >Building them works fine, but when I nfs-mount /usr/obj and /usr/src on the >target system, install does not work. Neiter installkernel nor installworld. You're going to have to give more detail - like your exact command and the last few dozen lines of the make install{world,kernel} output. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080915/20a43e97/attachment.pgp From gavin at FreeBSD.org Mon Sep 15 09:37:22 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Mon Sep 15 09:37:29 2008 Subject: Possible UDP related deadlock in 7.1-PRERELEASE In-Reply-To: <200809141219.24943.fbsd-ml@scrapper.ca> References: <200809141219.24943.fbsd-ml@scrapper.ca> Message-ID: <1221471431.49328.5.camel@buffy.york.ac.uk> On Sun, 2008-09-14 at 12:19 -0700, Norbert Papke wrote: > Symptoms: > > * I can trigger this lockup reliably by starting ktorrent. After a short > while (one to two minutes), it locks up. Other commands, e.g., netstat, also > lock up. > * The console generates "nfe0: watchdog timeout" error messages. > * The system becomes unusable and must be rebooted. > Attempted Diagnosis: > > If I break into DDB, the 'ps' output shows a number of processes that seem to > be locked related to udp. > > [irq18:dc0] L *udp > ktorrent L *udpinp > hald L *udp > ntpd L *udp > > Unfortunately, I am rapidly getting out of my depth here. I have no idea how > to go about further analyzing this problem and would appreciate help. Can you add: options WITNESS options WITNESS_SKIPSPIN to your kernel, recompile and wait for the problem to happen again? When it does, from the debugger issue "sh alllocks" and make a note of the output? This will probably show that two locks are held, "Giant" and "udp", along with the thread that holds each of them. Take the ID of the thread that holds the "udp" lock, and enter "tr 100150" (where 100150 is the thread ID. This should hopefully provide enough info to figure out what is happening. Thanks, Gavin From avg at icyb.net.ua Mon Sep 15 13:09:51 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Sep 15 13:09:58 2008 Subject: sio => uart: one port is gone Message-ID: <48CE5E9B.9000304@icyb.net.ua> This is a fairly standard and old machine with 2 COM ports. Recently (last Friday) I decided to update my RELENG_7 system and also to transition from sio to uart. This what I had before the upgrade: kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 kernel: sio0: type 16550A kernel: sio0: [FILTER] kernel: sio1: <16550A-compatible COM port> port 0x2e8-0x2ef irq 3 on acpi0 kernel: sio1: type 16550A kernel: sio1: [FILTER] This is what I have now: uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: [FILTER] This is what I have in device.hints for uart: hint.uart.0.at="isa" hint.uart.0.port="0x3F8" hint.uart.0.flags="0x10" hint.uart.0.irq="4" hint.uart.1.at="isa" hint.uart.1.port="0x2F8" hint.uart.1.irq="3" hint.uart.2.at="isa" Precisely the same hints (s/uart/sio/) I had for sio. Please advise. -- Andriy Gapon From smithi at nimnet.asn.au Mon Sep 15 14:36:07 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Mon Sep 15 14:36:15 2008 Subject: sio => uart: one port is gone In-Reply-To: <48CE5E9B.9000304@icyb.net.ua> References: <48CE5E9B.9000304@icyb.net.ua> Message-ID: <20080916002823.E439@sola.nimnet.asn.au> On Mon, 15 Sep 2008, Andriy Gapon wrote: > This is a fairly standard and old machine with 2 COM ports. > Recently (last Friday) I decided to update my RELENG_7 system and also > to transition from sio to uart. > > This what I had before the upgrade: > kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags > 0x10 on acpi0 > kernel: sio0: type 16550A > kernel: sio0: [FILTER] > kernel: sio1: <16550A-compatible COM port> port 0x2e8-0x2ef irq 3 on acpi0 > kernel: sio1: type 16550A > kernel: sio1: [FILTER] > > This is what I have now: > uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > uart0: [FILTER] > > This is what I have in device.hints for uart: > hint.uart.0.at="isa" > hint.uart.0.port="0x3F8" > hint.uart.0.flags="0x10" > hint.uart.0.irq="4" > hint.uart.1.at="isa" > hint.uart.1.port="0x2F8" but it's shown as 0x2e8 above .. > hint.uart.1.irq="3" > hint.uart.2.at="isa" > > Precisely the same hints (s/uart/sio/) I had for sio. 0x2f8 is 'standard COM2' address .. did sio1 work ok at 0x2e8 before? cheers, Ian From avg at icyb.net.ua Mon Sep 15 15:38:04 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Sep 15 15:38:11 2008 Subject: sio => uart: one port is gone In-Reply-To: <20080916002823.E439@sola.nimnet.asn.au> References: <48CE5E9B.9000304@icyb.net.ua> <20080916002823.E439@sola.nimnet.asn.au> Message-ID: <48CE815A.9040907@icyb.net.ua> on 15/09/2008 17:36 Ian Smith said the following: > On Mon, 15 Sep 2008, Andriy Gapon wrote: > > This is a fairly standard and old machine with 2 COM ports. > > Recently (last Friday) I decided to update my RELENG_7 system and also > > to transition from sio to uart. > > > > This what I had before the upgrade: > > kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags > > 0x10 on acpi0 > > kernel: sio0: type 16550A > > kernel: sio0: [FILTER] > > kernel: sio1: <16550A-compatible COM port> port 0x2e8-0x2ef irq 3 on acpi0 > > kernel: sio1: type 16550A > > kernel: sio1: [FILTER] > > > > This is what I have now: > > uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > > uart0: [FILTER] > > > > This is what I have in device.hints for uart: > > hint.uart.0.at="isa" > > hint.uart.0.port="0x3F8" > > hint.uart.0.flags="0x10" > > hint.uart.0.irq="4" > > hint.uart.1.at="isa" > > hint.uart.1.port="0x2F8" > > but it's shown as 0x2e8 above .. > > > hint.uart.1.irq="3" > > hint.uart.2.at="isa" > > > > Precisely the same hints (s/uart/sio/) I had for sio. > > 0x2f8 is 'standard COM2' address .. did sio1 work ok at 0x2e8 before? Ian, thank you, I guess I had a typo in my hints, but the port did work. Looking at the old dmesg I see that sio devices are found 'on acpi0' as opposed to uart now being found on 'isa0'. Maybe this is another difference. Maybe sio was attached using some information from acpi, so hints were not that important. But maybe the same acpi information is not applied to uart, so it does depend on the hints. If this guess is correct then this is a regression in sio=>uart transition, if not, then I'll just correct my device.hints and shut up :-) -- Andriy Gapon From gphoto6 at gmail.com Mon Sep 15 15:57:03 2008 From: gphoto6 at gmail.com (Tim Chen) Date: Mon Sep 15 15:57:12 2008 Subject: Suddenly frozen fcntl/stat call on NFS over TCP with MTU 9000 Message-ID: <1f51039c0809150857l50b6be8eu848e21189a4175d6@mail.gmail.com> Currently I was running a mail server using a netapp filer as backend storage. >From time to time, the whole system get stuck and lasted for 3-5 minutes. But after that, everything recovers normally. During the "stuck" moment, using ps auxw shows 200-300 of mail delivery agent(MDA) processes staying in "D" status. The command df certainly does not reponse either. System configuration: 1. NFS server: NetApp FAS3020 2. NFS client: acting as a smtp/pop3/imap server. freebsd 7.0-stable (almost 7.1-prelease) hardware: IBM x3550 server network interface: bce1: mem 0xc8000000-0xc9ffffff irq 18 at device 0.0 on pci4 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce1: Ethernet address: 00:1a:64:--:--:-- bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x04000305); Flags( MFW MSI ) ifconfig: bce1: flags=8843 metric 0 mtu 9000 options=1bb ether 00:1a:64:--:--:-- inet 192.168.1.166 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseTX ) status: active software: postfix 2.5.4 courier-imap 4.4.1 maildrop 2.0.4 After further investigation, I found that the situation is most severe when nfs over tcp and using mtu 9000. If nfs mount is changed to either (over udp and mtu 9000) or (over tcp and mtu 1500), things get significantly improvement. The frequency of "suddenly hang" decreases from every 10-15 min to several hours. Another observation is the "freeze" happens more frequently when server load is high, especially working hours. So I believed it is tightly related to server load (or nfs load). I tried to modify the source code of MDA (maildrop) and adding some debug code to identify the problem. What I found is: 1) MDA processing time always approximate 0 sec or < 1 sec when things work normally. 2) MDA processing time may up to 30 second when system got stuck. If the incoming email continues to come, later emails may cost up to 200 second to complete. At this time, using ps auxw shows MDAs were in "D" status. 3) Detail trace shows the processing time spent were waiting around the fcntl (lock) and stat(fstat) code. One more thing to note: I've tried to turn on and off rpc.statd,rpc.lockd, -L mount, even compile NFSLOCKD in kernel. All were in vain, things still got stuck when using NFS over TCP with mtu 9000. We have already lots of mail servers whose hardware were different and OS is freebsd 6-stable. Softwares were all the same but with prior version. Those servers didn't show any of the above strange behavior. Based on all of the above experiment and observation, I guess there might be something wrong with: 1) NFS or network stack of freebsd 7 2) fcntl/stat over NFS 3) bce driver Need your help/suggestion to solve the problem! Thanks very much. Sincerely, Tim Chen From kamikaze at bsdforen.de Mon Sep 15 16:19:05 2008 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Mon Sep 15 16:19:13 2008 Subject: crossbuilding of RELENG_7 broken? In-Reply-To: <20080915084126.GW15376@server.vk2pj.dyndns.org> References: <48CD3A19.8030404@bsdforen.de> <20080915084126.GW15376@server.vk2pj.dyndns.org> Message-ID: <48CE8AD4.8090408@bsdforen.de> Peter Jeremy wrote: > On 2008-Sep-14 18:21:45 +0200, Dominic Fandrey wrote: >> Building them works fine, but when I nfs-mount /usr/obj and /usr/src on the >> target system, install does not work. Neiter installkernel nor installworld. > > You're going to have to give more detail - like your exact command and > the last few dozen lines of the make install{world,kernel} output. > So well, here it is: Command on the amd64 build machine: # env MAKEOBJDIRPREFIX=/usr/obj/VECTRA-7 make -j4 buildworld buildkernel KERNCONF=VECTRA-7 It builds without incident and yes I did try without -j4 and it didn't work either. On the i386 target machine, /usr/src and /usr/obj are NFS mounts: =============================================================== # env MAKEOBJDIRPREFIX=/usr/obj/VECTRA-7/i386 make installkernel KERNCONF=VECTRA-7 -------------------------------------------------------------- >>> Installing kernel -------------------------------------------------------------- cd /usr/obj/VECTRA-7/i386/usr/src/sys/VECTRA-7; MAKEOBJDIRPREFIX=/usr/obj/VECTRA-7/i386 MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE=pentium4 GROFF_BIN_PATH=/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/share/tmac PATH=/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/sbin:/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/bin:/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/games:/usr/obj/VECTRA-7/i386/usr/src/tmp/usr/sbin:/usr/obj/VECTRA-7/i386/usr/src/tmp/usr/bin:/usr/obj/VECTRA-7/i386/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel install thiskernel=`sysctl -n kern.bootfile` ; if [ ! "`dirname "$thiskernel"`" -ef /boot/kernel ] ; then chflags -R noschg /boot/kernel ; rm -rf /boot/kernel ; else if [ -d /boot/kernel.old ] ; then chflags -R noschg /boot/kernel.old ; rm -rf /boot/kernel.old ; fi ; mv /boot/kernel /boot/kernel.old ; sysctl kern.bootfile=/boot/kernel.old/"`basename "$thiskernel"`" ; fi mkdir -p /boot/kernel install -p -m 555 -o root -g wheel kernel /boot/kernel ???@?FreeBSD?: not found @@????W?W: not found ELF: not found /usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/bin/install: 19: Syntax error: ")" unexpected *** Error code 2 Stop in /usr/obj/VECTRA-7/i386/usr/src/sys/VECTRA-7. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. =============================================================== I can successfully install the kernel with the following command: # cd /usr/obj/VECTRA-7/i386/usr/src/sys/boot/i386 # make install The system boots fine with a kernel installed like this. I have found no such workaround for installing world. =============================================================== # env MAKEOBJDIRPREFIX=/usr/obj/VECTRA-7/i386 make installworld mkdir -p /tmp/install.LaibTyRC for prog in [ awk cap_mkdb cat chflags chmod chown date echo egrep find grep install-info ln lockf make mkdir mtree mv pwd_mkdb rm sed sh sysctl test true uname wc zic; do cp `which $prog` /tmp/install.LaibTyRC; done cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/VECTRA-7/i386 MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE=pentium4 GROFF_BIN_PATH=/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/share/tmac PATH=/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/sbin:/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/bin:/usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/games:/usr/obj/VECTRA-7/i386/usr/src/tmp/usr/sbin:/usr/obj/VECTRA-7/i386/usr/src/tmp/usr/bin:/usr/obj/VECTRA-7/i386/usr/src/tmp/usr/games:/tmp/install.LaibTyRC make -f Makefile.inc1 reinstall -------------------------------------------------------------- >>> Making hierarchy -------------------------------------------------------------- cd /usr/src; make -f Makefile.inc1 hierarchy cd /usr/src/etc; make distrib-dirs mtree -eU -f /usr/src/etc/mtree/BSD.root.dist -p / root changed type expected dir found link mtree -eU -f /usr/src/etc/mtree/BSD.var.dist -p /var tmp changed type expected dir found link ./tmp/vi.recover missing (created) mtree -eU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr mtree -eU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/include mtree -deU -f /usr/src/etc/mtree/BIND.chroot.dist -p /var/named mtree -deU -f /usr/src/etc/mtree/BSD.sendmail.dist -p / cd /; rm -f /sys; ln -s usr/src/sys sys cd /usr/share/man/en.ISO8859-1; ln -sf ../man* . cd /usr/share/man; set - `grep "^[a-zA-Z]" /usr/src/etc/man.alias`; while [ $# -gt 0 ] ; do rm -rf "$1"; ln -s "$2" "$1"; shift; shift; done cd /usr/share/openssl/man; set - `grep "^[a-zA-Z]" /usr/src/etc/man.alias`; while [ $# -gt 0 ] ; do rm -rf "$1"; ln -s "$2" "$1"; shift; shift; done cd /usr/share/openssl/man/en.ISO8859-1; ln -sf ../man* . cd /usr/share/nls; set - `grep "^[a-zA-Z]" /usr/src/etc/nls.alias`; while [ $# -gt 0 ] ; do rm -rf "$1"; ln -s "$2" "$1"; shift; shift; done -------------------------------------------------------------- >>> Installing everything -------------------------------------------------------------- cd /usr/src; make -f Makefile.inc1 install ===> share/info (install) ===> lib (install) ===> lib/csu/i386-elf (install) install -o root -g wheel -m 444 crt1.o crti.o crtn.o gcrt1.o /usr/lib ???@?FreeBSD?: not found @@????W?W: not found ELF: not found /usr/obj/VECTRA-7/i386/usr/src/tmp/legacy/usr/bin/install: 19: Syntax error: ")" unexpected *** Error code 2 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From koitsu at FreeBSD.org Mon Sep 15 16:37:29 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 15 16:37:38 2008 Subject: sio => uart: one port is gone In-Reply-To: <48CE815A.9040907@icyb.net.ua> References: <48CE5E9B.9000304@icyb.net.ua> <20080916002823.E439@sola.nimnet.asn.au> <48CE815A.9040907@icyb.net.ua> Message-ID: <20080915163725.GA41476@icarus.home.lan> On Mon, Sep 15, 2008 at 06:38:02PM +0300, Andriy Gapon wrote: > on 15/09/2008 17:36 Ian Smith said the following: >> On Mon, 15 Sep 2008, Andriy Gapon wrote: >> > This is a fairly standard and old machine with 2 COM ports. >> > Recently (last Friday) I decided to update my RELENG_7 system and also >> > to transition from sio to uart. >> > > This what I had before the upgrade: >> > kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags >> > 0x10 on acpi0 >> > kernel: sio0: type 16550A >> > kernel: sio0: [FILTER] >> > kernel: sio1: <16550A-compatible COM port> port 0x2e8-0x2ef irq 3 on acpi0 >> > kernel: sio1: type 16550A >> > kernel: sio1: [FILTER] >> > > This is what I have now: >> > uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 >> > uart0: [FILTER] >> > > This is what I have in device.hints for uart: >> > hint.uart.0.at="isa" >> > hint.uart.0.port="0x3F8" >> > hint.uart.0.flags="0x10" >> > hint.uart.0.irq="4" >> > hint.uart.1.at="isa" >> > hint.uart.1.port="0x2F8" >> >> but it's shown as 0x2e8 above .. >> >> > hint.uart.1.irq="3" >> > hint.uart.2.at="isa" >> > > Precisely the same hints (s/uart/sio/) I had for sio. >> >> 0x2f8 is 'standard COM2' address .. did sio1 work ok at 0x2e8 before? > > Ian, > > thank you, I guess I had a typo in my hints, but the port did work. > Looking at the old dmesg I see that sio devices are found 'on acpi0' as > opposed to uart now being found on 'isa0'. > Maybe this is another difference. > > Maybe sio was attached using some information from acpi, so hints were > not that important. But maybe the same acpi information is not applied > to uart, so it does depend on the hints. > > If this guess is correct then this is a regression in sio=>uart > transition, if not, then I'll just correct my device.hints and shut up > :-) I've CC'd Marcel Moolenaar, who can very likely explain what's going on here. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From smithi at nimnet.asn.au Mon Sep 15 16:48:41 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Mon Sep 15 16:48:54 2008 Subject: sio => uart: one port is gone In-Reply-To: <48CE815A.9040907@icyb.net.ua> References: <48CE5E9B.9000304@icyb.net.ua> <20080916002823.E439@sola.nimnet.asn.au> <48CE815A.9040907@icyb.net.ua> Message-ID: <20080916021035.N439@sola.nimnet.asn.au> On Mon, 15 Sep 2008, Andriy Gapon wrote: > on 15/09/2008 17:36 Ian Smith said the following: > > On Mon, 15 Sep 2008, Andriy Gapon wrote: > > > This is a fairly standard and old machine with 2 COM ports. > > > Recently (last Friday) I decided to update my RELENG_7 system and also > > > to transition from sio to uart. > > > > This what I had before the upgrade: > > > kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags > > > 0x10 on acpi0 > > > kernel: sio0: type 16550A > > > kernel: sio0: [FILTER] > > > kernel: sio1: <16550A-compatible COM port> port 0x2e8-0x2ef irq 3 on acpi0 > > > kernel: sio1: type 16550A > > > kernel: sio1: [FILTER] > > > > This is what I have now: > > > uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > > > uart0: [FILTER] > > > > This is what I have in device.hints for uart: > > > hint.uart.0.at="isa" > > > hint.uart.0.port="0x3F8" > > > hint.uart.0.flags="0x10" > > > hint.uart.0.irq="4" > > > hint.uart.1.at="isa" > > > hint.uart.1.port="0x2F8" > > > > but it's shown as 0x2e8 above .. > > > > > hint.uart.1.irq="3" > > > hint.uart.2.at="isa" > > > > Precisely the same hints (s/uart/sio/) I had for sio. > > > > 0x2f8 is 'standard COM2' address .. did sio1 work ok at 0x2e8 before? > thank you, I guess I had a typo in my hints, but the port did work. > Looking at the old dmesg I see that sio devices are found 'on acpi0' as > opposed to uart now being found on 'isa0'. > Maybe this is another difference. Does sound a bit odd; looks like the ACPI info trumped hints for sio. > Maybe sio was attached using some information from acpi, so hints were not > that important. But maybe the same acpi information is not applied to uart, > so it does depend on the hints. Sounds a reasonable theory .. so does fixing that hint find the UART? Maybe a verbose dmesg would provide more clues re uart's attachment? > If this guess is correct then this is a regression in sio=>uart transition, > if not, then I'll just correct my device.hints and shut up :-) Or both :) You'd think if ACPI info is available uart should use it, but then if it's attaching to the isa bus instead, maybe not .. hmm. cheers, Ian From jrhett at netconsonance.com Mon Sep 15 16:48:43 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon Sep 15 16:48:55 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> Message-ID: <17B9E874-88E0-4DBF-8525-D6FF11FCBAD1@netconsonance.com> On Sep 5, 2008, at 1:19 PM, Ben Kaduk wrote: > Normal > Releases which are published from a -STABLE branch will be > supported by the Security Officer for a minimum of 12 months after the > release. > Extended > Selected releases will be supported by the Security Officer for a > minimum of 24 months after the release. > > I don't remember seeing any speculation about 6.4 being an extended > release, so, EoL is 12 months after release, whenever that actually > happens. Okay, so 6.3 will EoL at roughly the same time as 6.4. Why should anyone spend any effort on 6.4? > That's the difference between a long-term-support branch and a > regular branch; > many OSes do that. If you want to run the same machines for a long > time and > not have to do a huge battery of tests (at the expense of getting > new features > and better performance in the interim), you use long-term branches. > The regular branches that get released later, will then become > unsupported > at the same time as the (older) long-term branch. > > Yes, it's poor when a long-term branch goes EoL before there's > another one > ready to take its place, but if the new one isn't ready, then you > just use > whichever regular release is current and then snag a long-term release > when it becomes available. Yes, it's more work, but that's life. Is it just me, or does this make no sense at all? This does make it clear to me why the release team can't find the resources to do longer support. Who can convince their company to put resources into the mainstream release effort, when this kind of cycle basically forces every company to run their own internal release process. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Mon Sep 15 17:00:22 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon Sep 15 17:00:29 2008 Subject: Upcoming Releases Schedule... In-Reply-To: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> Message-ID: <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> On Sep 6, 2008, at 4:06 AM, Robert Watson wrote: > Unfortunately, it's a little hard to tell at time-of-release whether > a particular release will become extended life or not. This is > because extended support status is dependent on the success of the > release ... > from earlier branch adopters. How long we keep release 6.x releases > will depend entirely on how successful 7.x is; I think there's a > reasonable expectation that 6.4 or 6.5 will be the last 6.x release, > in which case we would want to grant it extended support status. > But what happens depends a lot on how successful 7.1 is. My hopes > are high, but there's nothing like real-world deployment to shed > light on things :-). Robert, I'd like to point out to you that when I complained about 6.2's accelerated EoL, I was soundly boxed around the ears and told that I should have been paying attention to the projected EoL date when we decided to roll out 6.2 across the business. I was also told that I should have been more active in the release cycle process for 6.3, etc. Now you are saying that expected EoL will be determined at some random point in the future based on gut feelings about how well a completely different branch is doing. How can I reconcile these disparate points of view? How does one focus on testing and upgrade cycle for an "appropriately supported release" when the decision for the support cycle is completely up in the air? How does one talk to management about getting resources assigned to help with the freebsd release testing process, when one cannot make any valid predictions for that release will even be supported long enough to justify the effort involved in upgrading? What you are saying is completely reasonable from a developers point of view. But those of us who use freebsd in an environment which requires extensive testing and long-term planning for support have trouble with this. In short, I can't imagine how I could possibly make any business case to get support for helping the freebsd dev/rel process at all. Why? Because frankly we're going to be forced to run our own internal release management process instead. I guess this is not surprising, as this appears to be what every other business using significant amounts of freebsd in production are doing today. My point to you is that if this wasn't being forced upon every company that uses FreeBSD, those companies could commit more resources to help the core (main branch, whatever - not "Core") freebsd development. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From peterjeremy at optushome.com.au Mon Sep 15 19:20:34 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Mon Sep 15 19:20:41 2008 Subject: crossbuilding of RELENG_7 broken? In-Reply-To: <48CE8AD4.8090408@bsdforen.de> References: <48CD3A19.8030404@bsdforen.de> <20080915084126.GW15376@server.vk2pj.dyndns.org> <48CE8AD4.8090408@bsdforen.de> Message-ID: <20080915192004.GD15376@server.vk2pj.dyndns.org> On 2008-Sep-15 18:18:28 +0200, Dominic Fandrey wrote: >Peter Jeremy wrote: >> On 2008-Sep-14 18:21:45 +0200, Dominic Fandrey wrote: >>> Building them works fine, but when I nfs-mount /usr/obj and /usr/src on the >>> target system, install does not work. Neiter installkernel nor installworld. >> >> You're going to have to give more detail - like your exact command and >> the last few dozen lines of the make install{world,kernel} output. >> > >So well, here it is: > >Command on the amd64 build machine: > ># env MAKEOBJDIRPREFIX=/usr/obj/VECTRA-7 make -j4 buildworld buildkernel KERNCONF=VECTRA-7 > >It builds without incident and yes I did try without -j4 and it didn't work either. > >On the i386 target machine, /usr/src and /usr/obj are NFS mounts: > >=============================================================== > ># env MAKEOBJDIRPREFIX=/usr/obj/VECTRA-7/i386 make installkernel KERNCONF=VECTRA-7 I didn't understand exactly what you were doing before. The install{world,kernel} must be executed on the same architecture (and similar FreeBSD version) as the build{world,kernel} because the install{world,kernel} executes code that was built as part of the buildworld. Rather than NFS mounting the buildhost onto the target and running install{world,kernel} on the target, you need to NFS mount the target / and /usr onto the buildhost and use DESTDIR to point the install at the correct location. This will work, modulo some chflags issues (chflags isn't supported over NFS - I don't recall offhand where this is discussed but google should be able to help). -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080915/d8dadb76/attachment.pgp From rodrigc at crodrigues.org Mon Sep 15 20:08:38 2008 From: rodrigc at crodrigues.org (Craig Rodrigues) Date: Mon Sep 15 20:08:45 2008 Subject: ssh to FreeBSD 4 systems: xmalloc: zero size Message-ID: <20080915200838.GA51668@crodrigues.org> Hi, With the latest FreeBSD 7.1 PRE-RELEASE, I am having trouble ssh'ing to FreeBSD 4 systems. I am getting this error: OpenSSH_5.1p1 FreeBSD-20080901, OpenSSL 0.9.8e 23 Feb 2007 debug1: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connection established. debug1: identity file /homes/rodrigc/.ssh/identity type -1 debug1: identity file /homes/rodrigc/.ssh/id_rsa type -1 debug1: identity file /homes/rodrigc/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1 FreeBSD-20060930 debug1: match: OpenSSH_3.5p1 FreeBSD-20060930 pat OpenSSH_3.* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 FreeBSD-20080901 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'bbuild47.juniper.net' is known and matches the DSA host key. debug1: Found key in /homes/rodrigc/.ssh/known_hosts:100 debug1: ssh_dss_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received xmalloc: zero size At this point I cannot log in. The system I am trying to log into is: 4.11-RELEASE-p26 Any ideas? This is a big problem for me, because I have a lot of FreeBSD 4.x servers that I need to log into. Thanks. -- Craig Rodrigues rodrigc@crodrigues.org From jhb at freebsd.org Mon Sep 15 20:49:43 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Sep 15 20:49:57 2008 Subject: Suddenly frozen fcntl/stat call on NFS over TCP with MTU 9000 In-Reply-To: <1f51039c0809150857l50b6be8eu848e21189a4175d6@mail.gmail.com> References: <1f51039c0809150857l50b6be8eu848e21189a4175d6@mail.gmail.com> Message-ID: <200809151606.23933.jhb@freebsd.org> On Monday 15 September 2008 11:57:02 am Tim Chen wrote: > Currently I was running a mail server using a netapp filer as backend > storage. > >From time to time, the whole system get stuck and lasted for 3-5 minutes. > But > after that, everything recovers normally. During the "stuck" moment, using > ps > auxw shows 200-300 of mail delivery agent(MDA) processes staying in "D" > status. > The command df certainly does not reponse either. Can you use 'ps axl' to determine the wait mesg ("wchan") of the stuck threads when they hang? If it is "lockf", then make sure you have an up-to-date RELENG_6 kernel as there was a recent fix for a "lockf" hang. Alternatively, if things are stuck in "nfsreq", it may be useful to use tcpdump to look at the NFS requests your client is making. nfsstat can also be useful as you can see which counters are increasing during a hang. -- John Baldwin From jhb at freebsd.org Mon Sep 15 20:49:46 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Sep 15 20:49:58 2008 Subject: ACPI regression on recent 7.0-STABLE: HPET stops working In-Reply-To: <20080913002850.26f322ab@tau.draftnet> References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <200807231116.02389.jhb@freebsd.org> <20080913002850.26f322ab@tau.draftnet> Message-ID: <200809151548.33070.jhb@freebsd.org> On Friday 12 September 2008 07:28:50 pm Bruce Cran wrote: > On Wed, 23 Jul 2008 11:16:02 -0400 > John Baldwin wrote: > > I've committed the patch. However, I think this actually points out > > a slightly bigger issue in that the HPET timer is probably > > piggybacking on the ichsmb0 device's BAR, and they really should both > > be able to attach somehow. > > > > A way to fix that would be to make the HPET device actually borrow > > the PCI device's resource instead of allocating its own perhaps. I > > think the HPET ACPI device and the table tell us the PCI deviec the > > HPET lives in. > > > > I just upgraded from 7.0-p3 to 7.1-PRERELEASE on my Dell I1501 laptop > and hit this problem too. I noticed the patch was committed to HEAD - > are there any plans to MFC it for 7.1? I will MFC it. -- John Baldwin From rodrigc at crodrigues.org Mon Sep 15 21:29:42 2008 From: rodrigc at crodrigues.org (Craig Rodrigues) Date: Mon Sep 15 21:29:48 2008 Subject: ssh to FreeBSD 4 systems: xmalloc: zero size In-Reply-To: <20080915200838.GA51668@crodrigues.org> References: <20080915200838.GA51668@crodrigues.org> Message-ID: <20080915212942.GA87277@crodrigues.org> On Mon, Sep 15, 2008 at 08:08:38PM +0000, Craig Rodrigues wrote: > Hi, > > With the latest FreeBSD 7.1 PRE-RELEASE, I am having trouble > ssh'ing to FreeBSD 4 systems. > > xmalloc: zero size This looks like the same problem: https://bugzilla.mindrot.org/show_bug.cgi?id=1496 -- Craig Rodrigues rodrigc@crodrigues.org From rodrigc at crodrigues.org Mon Sep 15 22:17:04 2008 From: rodrigc at crodrigues.org (Craig Rodrigues) Date: Mon Sep 15 22:17:11 2008 Subject: ssh to FreeBSD 4 systems: xmalloc: zero size In-Reply-To: <20080915200838.GA51668@crodrigues.org> References: <20080915200838.GA51668@crodrigues.org> Message-ID: <20080915221704.GA4580@crodrigues.org> Hi, I can confirm that this patch solves my problem: https://bugzilla.mindrot.org/attachment.cgi?id=1554 That patch is part of this ssh bug: https://bugzilla.mindrot.org/show_bug.cgi?id=1496 Can we get this fix into FreeBSD before the 7.1 RELEASE? Thanks. -- Craig Rodrigues rodrigc@crodrigues.org On Mon, Sep 15, 2008 at 08:08:38PM +0000, Craig Rodrigues wrote: > Hi, > > With the latest FreeBSD 7.1 PRE-RELEASE, I am having trouble > ssh'ing to FreeBSD 4 systems. > > I am getting this error: > OpenSSH_5.1p1 FreeBSD-20080901, OpenSSL 0.9.8e 23 Feb 2007 > debug1: Applying options for * > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Connection established. > debug1: identity file /homes/rodrigc/.ssh/identity type -1 > debug1: identity file /homes/rodrigc/.ssh/id_rsa type -1 > debug1: identity file /homes/rodrigc/.ssh/id_dsa type 2 > debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1 FreeBSD-20060930 > debug1: match: OpenSSH_3.5p1 FreeBSD-20060930 pat OpenSSH_3.* > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_5.1p1 FreeBSD-20080901 > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug1: kex: server->client aes128-cbc hmac-md5 none > debug1: kex: client->server aes128-cbc hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug1: Host 'bbuild47.juniper.net' is known and matches the DSA host key. > debug1: Found key in /homes/rodrigc/.ssh/known_hosts:100 > debug1: ssh_dss_verify: signature correct > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug1: SSH2_MSG_NEWKEYS received > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug1: SSH2_MSG_SERVICE_ACCEPT received > xmalloc: zero size > > At this point I cannot log in. The system I am trying to log into > is: 4.11-RELEASE-p26 > Any ideas? > > This is a big problem for me, because I have a lot of FreeBSD 4.x > servers that I need to log into. > > Thanks. > -- > Craig Rodrigues > rodrigc@crodrigues.org From ivoras at freebsd.org Mon Sep 15 23:04:50 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Sep 15 23:05:03 2008 Subject: Apache-worker stuck at 100% CPU In-Reply-To: <20080912225251.GG16977@elvis.mu.org> References: <20080912165808.GE16977@elvis.mu.org> <9bbcef730809121444u34991c52m2cbc01a8ada47eb5@mail.gmail.com> <20080912225251.GG16977@elvis.mu.org> Message-ID: <9bbcef730809151604i28533745m286e7314810d0362@mail.gmail.com> 2008/9/13 Alfred Perlstein : >> Yes, it's multithreaded apache. This did help somewhat - when I show threads in top >> I see that it's not actually stuck in umtxn - there's one thread that >> consumes the CPU and it's apparently always running (in state CPUx). >> >> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND >> 7212 www 103 0 30340K 7932K CPU2 2 444:23 99.02% httpd >> >> I'm currently upgrading the system to 7-STABLE, to see if it helps. It didn't help. Exactly the same symptom happened again. It looks like it happens a few days after the last system reboot. After it happens the first time, restarting Apache immediately produces one such "stuck" thread - it looks like some system state gets corrupted over time. >> How do I pick what thread to backtrace in gdb? > > i think the command is 'info threads' or 'show > threads' then i think you just type > 'thread FOO' to select the thread. Both commands don't work / don't exist. Any others? (background: apache22-worker port, no mod_php, on 7.0 and 7-STABLE suddenly gets stuck at 100% CPU; the same setup worked on 6-STABLE. I'm looking for ideas) From fbsd-ml at scrapper.ca Tue Sep 16 01:14:01 2008 From: fbsd-ml at scrapper.ca (Norbert Papke) Date: Tue Sep 16 01:14:08 2008 Subject: Possible UDP related deadlock in 7.1-PRERELEASE In-Reply-To: <1221471431.49328.5.camel@buffy.york.ac.uk> References: <200809141219.24943.fbsd-ml@scrapper.ca> <1221471431.49328.5.camel@buffy.york.ac.uk> Message-ID: <200809151813.58749.fbsd-ml@scrapper.ca> On September 15, 2008, Gavin Atkinson wrote: > On Sun, 2008-09-14 at 12:19 -0700, Norbert Papke wrote: > > Symptoms: > > > > * I can trigger this lockup reliably by starting ktorrent. After a short > > while (one to two minutes), it locks up. Other commands, e.g., netstat, > > also lock up. > > * The console generates "nfe0: watchdog timeout" error messages. > > * The system becomes unusable and must be rebooted. > > > > Attempted Diagnosis: > > > > If I break into DDB, the 'ps' output shows a number of processes that > > seem to be locked related to udp. > > > > [irq18:dc0] L *udp > > ktorrent L *udpinp > > hald L *udp > > ntpd L *udp > > > > Unfortunately, I am rapidly getting out of my depth here. I have no idea > > how to go about further analyzing this problem and would appreciate help. > > Can you add: > options WITNESS > options WITNESS_SKIPSPIN > > to your kernel, recompile and wait for the problem to happen again? > When it does, from the debugger issue "sh alllocks" and make a note of > the output? With WITNESS enabled, I now experience panics and could not follow your instructions. There is no core dump. The following gets logged to /var/log/messages: shared lock of (rw) udpinp @ /usr/src/sys/netinet/udp_usrreq.c:864 while exclusively locked from /usr/src/sys/netinet6/udp6_usrreq.c:940 panic: share->excl KDB: stack backtrace: db_trace_self_wrapper(c06fda7c,f6b96978,c052046a,c06fbb5d,c07695c0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c06fbb5d,c07695c0,c06febd1,f6b96984,f6b96984,...) at kdb_backtrace+0x29 panic(c06febd1,c070c409,3ac,c0709eee,360,...) at panic+0xaa witness_checkorder(ccd5209c,1,c0709eee,360,8,...) at witness_checkorder+0x17c _rw_rlock(ccd5209c,c0709eee,360,c07780e0,cd4652c8,...) at _rw_rlock+0x2a udp_send(d3942000,0,c580f400,c68faa00,0,...) at udp_send+0x197 udp6_send(d3942000,0,c580f400,c68faa00,0,...) at udp6_send+0x140 sosend_generic(d3942000,c68faa00,f6b96be8,0,0,...) at sosend_generic+0x50d sosend(d3942000,c68faa00,f6b96be8,0,0,...) at sosend+0x3f kern_sendit(cd465230,f,f6b96c64,0,0,...) at kern_sendit+0x106 sendit(0,871b9fe,0,c68faa00,1c,...) at sendit+0x182 sendto(cd465230,f6b96cfc,18,cd465230,c072bab8,...) at sendto+0x4f syscall(f6b96d38) at syscall+0x293 Note that I do not use IPv6, none of my network interfaces is configured for it. Also, since I enabled WITNESS, I get the following logged during system startup: Enabling pf. lock order reversal: 1st 0xc09af92c pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contri b/pf/net/pf_ioctl.c:1394 2nd 0xc07b4d68 ifnet (ifnet) @ /usr/src/sys/net/if.c:1558 KDB: stack backtrace: db_trace_self_wrapper(c06fda7c,f4914a60,c0552c75,c06fed11,c07b4d68,...) at db_tr ace_self_wrapper+0x26 kdb_backtrace(c06fed11,c07b4d68,c0703ca2,c0703ca2,c0703c73,...) at kdb_backtrace +0x29 witness_checkorder(c07b4d68,9,c0703c73,616,572,...) at witness_checkorder+0x5e5 _mtx_lock_flags(c07b4d68,0,c0703c73,616,c0104414,...) at _mtx_lock_flags+0x34 ifunit(c6ef5c20,0,c09adfb5,572,c0703a71,...) at ifunit+0x2f pfioctl(c566ce00,c0104414,c6ef5c20,3,c60c38c0,...) at pfioctl+0x2b43 devfs_ioctl_f(c588bb94,c0104414,c6ef5c20,c54bb900,c60c38c0,...) at devfs_ioctl_f +0xe6 kern_ioctl(c60c38c0,3,c0104414,c6ef5c20,1000000,...) at kern_ioctl+0x243 ioctl(c60c38c0,f4914cfc,c,c0718d59,c072b350,...) at ioctl+0x134 syscall(f4914d38) at syscall+0x293 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281ab6f3, esp = 0xbfbfde3c, ebp = 0xbfbfde68 --- pf enabled I tried to unload 'pf' to see if it was the culprit. However, even without pf loaded, I experience the panic. Is there anything else I can try to provide better insight into what might be going on? Cheers, -- Norbert. From joji at eskimo.com Tue Sep 16 02:39:53 2008 From: joji at eskimo.com (Joseph Olatt) Date: Tue Sep 16 02:40:03 2008 Subject: unsupported NVIDIA SATA controller Message-ID: <20080915192515.A13327@eskimo.com> Hello, I have the following SATA controller card on my system that appears to be unsupported by FreeBSD 7-STABLE. Does anybody know if this card is supported or will be supported in the near future? none13@pci0:0:14:0: class=0x010485 card=0x01371025 chip=0x07f810de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' class = mass storage subclass = RAID I have a SATA hard disk and DVD drive connedted to this controller that is not detected as a result. I have Ubuntu loaded on the SATA disk. In an attempt to see if I could get FreeBSD 7-STABLE to work, I made the following changes to the source. But it didn't seem to work. /*** Begin change #1 ***/ [/usr/src/sys/dev/ata] joji@snow> diff -u ata-pci.h ata-pci.h.orig --- ata-pci.h 2008-09-15 20:40:30.000000000 -0500 +++ ata-pci.h.orig 2008-09-15 20:37:36.000000000 -0500 @@ -242,7 +242,6 @@ #define ATA_NFORCE_MCP65 0x044810de #define ATA_NFORCE_MCP67 0x056010de #define ATA_NFORCE_MCP73 0x056c10de -#define ATA_NFORCE_MCP73_S1 0x07f810de #define ATA_NFORCE_MCP77 0x075910de #define ATA_PROMISE_ID 0x105a /*** End change #1 ***/ /*** Begin change #2 ***/ [/usr/src/sys/dev/ata] joji@snow> diff -u ata-chipset.c ata-chipset.c.orig --- ata-chipset.c 2008-09-15 20:47:55.000000000 -0500 +++ ata-chipset.c.orig 2008-09-15 20:40:43.000000000 -0500 @@ -3051,7 +3051,6 @@ { ATA_NFORCE_MCP65, 0, AMDNVIDIA, NVIDIA, ATA_UDMA6, "nForce MCP65" }, { ATA_NFORCE_MCP67, 0, AMDNVIDIA, NVIDIA, ATA_UDMA6, "nForce MCP67" }, { ATA_NFORCE_MCP73, 0, AMDNVIDIA, NVIDIA, ATA_UDMA6, "nForce MCP73" }, - { ATA_NFORCE_MCP73_S1, 0, 0, NV4|NVQ, ATA_SA300, "nForce MCP73" }, { ATA_NFORCE_MCP77, 0, AMDNVIDIA, NVIDIA, ATA_UDMA6, "nForce MCP77" }, { 0, 0, 0, 0, 0, 0}} ; /*** End change #2 ***/ After making the above changes, I rebuilt the kernel and got the card a driver assigned to it. But my DVD drive nor the SATA hard disk was detected. I must admit that I did not quite understand the changes that I made. It was just an attempt. Any insight or help will be greatly appreciated. atapci1@pci0:0:14:0: class=0x010485 card=0x01371025 chip=0x07f810de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' class = mass storage subclass = RAID /*** Begin dmesg ***/ Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #4: Mon Sep 15 20:55:34 CDT 2008 joji@snow:/usr/obj/usr/src/sys/SNOW Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1799.96-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 793821184 (757 MB) avail memory = 764108800 (728 MB) ACPI APIC Table: <012908 APIC1443> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fed45000, febfb000 (3) failed acpi0: reservation of fec00000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3ff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 1.0 (no driver attached) pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pci0: at device 1.3 (no driver attached) pci0: at device 1.4 (no driver attached) pci0: at device 1.5 (no driver attached) pci0: at device 1.6 (no driver attached) pci0: at device 2.0 (no driver attached) isab0: port 0x4f00-0x4fff at device 3.0 on pci0 isa0: on isab0 pci0: at device 3.1 (no driver attached) pci0: at device 3.2 (no driver attached) pci0: at device 3.3 (no driver attached) pci0: at device 3.4 (no driver attached) ohci0: mem 0xfea7f000-0xfea7ffff irq 22 at device 4.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 8 ports with 8 removable, self powered ehci0: mem 0xfea7ec00-0xfea7ecff irq 23 at device 4.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 10 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 8 ports with 8 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 8.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pcm0: mem 0xfea78000-0xfea7bfff irq 20 at device 9.0 on pci0 pcm0: [ITHREAD] pcib1: at device 10.0 on pci0 pci1: on pcib1 wb0: port 0xec00-0xec7f mem 0xfebffc00-0xfebffc7f irq 16 at device 5.0 on pci1 miibus0: on wb0 amphy0: PHY 1 on miibus0 amphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto wb0: WARNING: using obsoleted if_watchdog interface wb0: Ethernet address: 00:80:48:d7:53:ac wb0: [ITHREAD] fwohci0: port 0xe880-0xe8ff mem 0xfebff000-0xfebff7ff irq 17 at device 7.0 on pci1 fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:10:dc:00:01:54:98:34 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 512 bytes. fwohci0: max_rec 512 -> 2048 firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:10:dc:54:98:34 fwe0: Ethernet address: 02:10:dc:54:98:34 fwip0: on firewire0 fwip0: Firewire address: 00:10:dc:00:01:54:98:34 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x2e470000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode pcib2: at device 11.0 on pci0 pci2: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 pcib4: at device 13.0 on pci0 pci4: on pcib4 atapci1: port 0xd480-0xd487,0xd400-0xd403,0xd080-0xd087,0xd000-0xd003,0xcc00-0xcc0f mem 0xfea7c000-0xfea7dfff irq 21 at device 14.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] nfe0: port 0xc880-0xc887 mem 0xfea73000-0xfea73fff,0xfea7e800-0xfea7e8ff,0xfea7e400-0xfea7e40f irq 22 at device 15.0 on pci0 miibus1: on nfe0 rgephy0: PHY 1 on miibus1 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: Ethernet address: 00:1d:92:89:12:da nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] vgapci0: mem 0xfd000000-0xfdffffff,0xd0000000-0xdfffffff,0xfc000000-0xfcffffff irq 23 at device 16.0 on pci0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 cpu0: on acpi0 est0: failed to enable SpeedStep p4tcc0: on cpu0 cpu1: on acpi0 est1: failed to enable SpeedStep p4tcc1: on cpu1 acpi_button0: on acpi0 acpi_tz0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] 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 NetMouse/NetScroll Optical, device ID 0 orm0: at iomem 0xce000-0xcf7ff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 umass0: on uhub0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad0: 305245MB at ata0-master UDMA100 pcm0: pcm0: SMP: AP CPU #1 Launched! da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da1 at umass-sim0 bus 0 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 1.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da2 at umass-sim0 bus 0 target 0 lun 2 da2: Removable Direct Access SCSI-0 device da2: 1.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da3 at umass-sim0 bus 0 target 0 lun 3 da3: Removable Direct Access SCSI-0 device da3: 1.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad0s1a /*** End dmesg ***/ From alfred at freebsd.org Tue Sep 16 02:45:55 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Sep 16 02:46:02 2008 Subject: Apache-worker stuck at 100% CPU In-Reply-To: <9bbcef730809151604i28533745m286e7314810d0362@mail.gmail.com> References: <20080912165808.GE16977@elvis.mu.org> <9bbcef730809121444u34991c52m2cbc01a8ada47eb5@mail.gmail.com> <20080912225251.GG16977@elvis.mu.org> <9bbcef730809151604i28533745m286e7314810d0362@mail.gmail.com> Message-ID: <20080916022738.GJ36572@elvis.mu.org> * Ivan Voras [080915 16:05] wrote: > 2008/9/13 Alfred Perlstein : > > >> Yes, it's multithreaded apache. This did help somewhat - when I show threads in top > >> I see that it's not actually stuck in umtxn - there's one thread that > >> consumes the CPU and it's apparently always running (in state CPUx). > >> > >> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > >> 7212 www 103 0 30340K 7932K CPU2 2 444:23 99.02% httpd > >> > >> I'm currently upgrading the system to 7-STABLE, to see if it helps. > > It didn't help. Exactly the same symptom happened again. It looks like > it happens a few days after the last system reboot. After it happens > the first time, restarting Apache immediately produces one such > "stuck" thread - it looks like some system state gets corrupted over > time. > > >> How do I pick what thread to backtrace in gdb? > > > > i think the command is 'info threads' or 'show > > threads' then i think you just type > > 'thread FOO' to select the thread. > > Both commands don't work / don't exist. Any others? > > (background: apache22-worker port, no mod_php, on 7.0 and 7-STABLE > suddenly gets stuck at 100% CPU; the same setup worked on 6-STABLE. > I'm looking for ideas) I'm sorry, I really can't help at this point other than to look through the documents myself to figure out how to do a backtrace/select threads. Give it a shot, and let us know and we can go further. Apologies, -Alfred From gphoto6 at gmail.com Tue Sep 16 06:02:15 2008 From: gphoto6 at gmail.com (Tim Chen) Date: Tue Sep 16 06:02:23 2008 Subject: Suddenly frozen fcntl/stat call on NFS over TCP with MTU 9000 In-Reply-To: <200809151606.23933.jhb@freebsd.org> References: <1f51039c0809150857l50b6be8eu848e21189a4175d6@mail.gmail.com> <200809151606.23933.jhb@freebsd.org> Message-ID: <1f51039c0809152302s2e6c1471n89588b058069f73d@mail.gmail.com> On Tue, Sep 16, 2008 at 4:06 AM, John Baldwin wrote: > On Monday 15 September 2008 11:57:02 am Tim Chen wrote: > > Currently I was running a mail server using a netapp filer as backend > > storage. > > >From time to time, the whole system get stuck and lasted for 3-5 > minutes. > > But > > after that, everything recovers normally. During the "stuck" moment, > using > > ps > > auxw shows 200-300 of mail delivery agent(MDA) processes staying in "D" > > status. > > The command df certainly does not reponse either. > > Can you use 'ps axl' to determine the wait mesg ("wchan") of the stuck > threads > when they hang? If it is "lockf", then make sure you have an up-to-date > RELENG_6 kernel as there was a recent fix for a "lockf" hang. > Thanks for your suggestion. After trying to 'ps axl', it seems all the "D status" process were in nfs,nfsreq,nfsreq. Can you give some hint how to keep delving the problem? My system is RELENG_7 within one week, I always make world to keep my system up to date. > > Alternatively, if things are stuck in "nfsreq", it may be useful to use > tcpdump to look at the NFS requests your client is making. nfsstat can > also > be useful as you can see which counters are increasing during a hang. > > When system was stuck, counters of nfsstat grows slowly. It seems only read, write, create, remove in RPC counts were increased. As to tcpdump, since I am not familiar with that, I will try to read some doc and make some tests. Thanks very much for your kindly help. Hope the problem can be solved soon. Sincerely, Tim Chen From andrew at modulus.org Tue Sep 16 06:47:24 2008 From: andrew at modulus.org (Andrew Snow) Date: Tue Sep 16 06:47:32 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> Message-ID: <48CF5282.10608@modulus.org> Jo Rhett wrote: > Because frankly we're going to be forced to run our own internal > release management process instead. > I guess this is not surprising, as this appears to be what every other > business using significant amounts of freebsd in production are doing > today. I'm afraid you've hit the nail on the head. Stable, Current, these words mean nothing to me anymore, I'm using 8-CURRENT to get stable ZFS with the ata driver from 7 (because 8's doesn't work), and the old BTX loader because the new one locks up on all my newer hardware. Then there's the bag of patches I am now carrying around from release to release, some for bug fixes and some for feature enhancements, none of which are in the base system for whatever reason. I think FreeBSD is getting in a difficult position now because there's so much cool new stuff being shoe-horned in, but without the necessary volume of contributors to back it up with testing and bug fixes. There's some truth to what you say, in that I would love to be directly contributing to the FreeBSD effort but instead I feel I'm running around putting out little fires all the time. Plus this era of 4 to 8 CPU cores has meant I am seeing bugs that are difficult to pin down and only occur under production load. - Andrew From linimon at lonesome.com Tue Sep 16 06:56:57 2008 From: linimon at lonesome.com (Mark Linimon) Date: Tue Sep 16 06:57:06 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <48CF5282.10608@modulus.org> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <48CF5282.10608@modulus.org> Message-ID: <20080916065657.GB12295@soaustin.net> On Tue, Sep 16, 2008 at 04:30:26PM +1000, Andrew Snow wrote: > I think FreeBSD is getting in a difficult position now because there's > so much cool new stuff being shoe-horned in, but without the necessary > volume of contributors to back it up with testing and bug fixes. We're interested in suggestions about how to get more people involved with testing and bug fixes. There's certainly no lack of demand for the features -- all the way from running on inexpensive wireless routers all the way up to 'enterprise- grade' distributed storage solutions. (These are real examples from various mailing lists.) So, in your opinion, what's the way to reconcile all these demands (features + stability + long-term support of release branches) with a group that is 95%-plus volunteer effort? mcl From m.seaman at infracaninophile.co.uk Tue Sep 16 07:39:17 2008 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Tue Sep 16 07:39:30 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <20080916065657.GB12295@soaustin.net> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <48CF5282.10608@modulus.org> <20080916065657.GB12295@soaustin.net> Message-ID: <48CF6292.7050909@infracaninophile.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Mark Linimon wrote: | On Tue, Sep 16, 2008 at 04:30:26PM +1000, Andrew Snow wrote: |> I think FreeBSD is getting in a difficult position now because there's |> so much cool new stuff being shoe-horned in, but without the necessary |> volume of contributors to back it up with testing and bug fixes. | | We're interested in suggestions about how to get more people involved | with testing and bug fixes. | | There's certainly no lack of demand for the features -- all the way from | running on inexpensive wireless routers all the way up to 'enterprise- | grade' distributed storage solutions. (These are real examples from | various mailing lists.) | | So, in your opinion, what's the way to reconcile all these demands | (features + stability + long-term support of release branches) with | a group that is 95%-plus volunteer effort? I think that the FreeBSD project as presently constituted does pretty well on the 'features + stability' side of things -- although it seems the glut of new features coming in at the moment probably is enough for the time being and we need a period of consolidation to restore the balance on the stability side of things. On 'long term support of release branches' -- a volunteer project is always going to struggle to provide this without some form of income to support the necessary hardware and personnel resources needed. Or in other words, if FreeBSD users want the same sort of support structure as they can get from a commercial vendor, it's going to take a commercial vendor to supply it. FreeBSD Corporation anyone? Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. Flat 3 ~ 7 Priory Courtyard PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate ~ Kent, CT11 9PW, UK -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREDAAYFAkjPYpIACgkQ3jDkPpsZ+VbD6gCgwjuVsjPXx9sOc+MzI5yhiG4J XzMAn1wVNZJamCpJejL7WZsjwZ/C8bIF =QnBp -----END PGP SIGNATURE----- From andrew at modulus.org Tue Sep 16 08:51:48 2008 From: andrew at modulus.org (Andrew Snow) Date: Tue Sep 16 08:51:56 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <20080916065657.GB12295@soaustin.net> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <48CF5282.10608@modulus.org> <20080916065657.GB12295@soaustin.net> Message-ID: <48CF7394.8040707@modulus.org> Mark Linimon wrote: > So, in your opinion, what's the way to reconcile all these demands > (features + stability + long-term support of release branches) with > a group that is 95%-plus volunteer effort? Its important to me that people keep using FreeBSD. Numbers are important. To that end I'm happy for developers to keep working hardest on the parts of FreeBSD they find most rewarding. Something's got to give and you can't stop it by creating more beaurocracy and red tape. Another thing I think is important is for new hardware to be perpetually sent to those who can implement drivers and create patches. I don't feel the FreeBSD foundation is doing enough in that regard. Not talking about big ticket items like server farms, just new motherboards every time a new CPU or chipset is released. - Andrew From ivoras at freebsd.org Tue Sep 16 09:12:02 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Sep 16 09:12:09 2008 Subject: Apache-worker stuck at 100% CPU In-Reply-To: <20080916022738.GJ36572@elvis.mu.org> References: <20080912165808.GE16977@elvis.mu.org> <9bbcef730809121444u34991c52m2cbc01a8ada47eb5@mail.gmail.com> <20080912225251.GG16977@elvis.mu.org> <9bbcef730809151604i28533745m286e7314810d0362@mail.gmail.com> <20080916022738.GJ36572@elvis.mu.org> Message-ID: <9bbcef730809160212m72fffc7k93d0c92ace2b7c19@mail.gmail.com> 2008/9/16 Alfred Perlstein : > * Ivan Voras [080915 16:05] wrote: >> >> How do I pick what thread to backtrace in gdb? >> > >> > i think the command is 'info threads' or 'show >> > threads' then i think you just type >> > 'thread FOO' to select the thread. >> >> Both commands don't work / don't exist. Any others? >> >> (background: apache22-worker port, no mod_php, on 7.0 and 7-STABLE >> suddenly gets stuck at 100% CPU; the same setup worked on 6-STABLE. >> I'm looking for ideas) > > I'm sorry, I really can't help at this point other than to look > through the documents myself to figure out how to do a backtrace/select > threads. > > Give it a shot, and let us know and we can go further. Sorry, I should have been more verbose - "info threads" should work but it doesn't - I can attach and get threads from a "regular" multithreaded process, but when yesterday when I attached to the stuck process, I couldn't get the list of threads. I'll try again the next time it gets stuck and try to provide more information. From koitsu at FreeBSD.org Tue Sep 16 09:48:18 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Sep 16 09:48:26 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <48CF7394.8040707@modulus.org> References: <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <48CF5282.10608@modulus.org> <20080916065657.GB12295@soaustin.net> <48CF7394.8040707@modulus.org> Message-ID: <20080916094815.GA60168@icarus.home.lan> On Tue, Sep 16, 2008 at 06:51:32PM +1000, Andrew Snow wrote: > Mark Linimon wrote: >> So, in your opinion, what's the way to reconcile all these demands >> (features + stability + long-term support of release branches) with >> a group that is 95%-plus volunteer effort? > > Its important to me that people keep using FreeBSD. Numbers are > important. To that end I'm happy for developers to keep working hardest > on the parts of FreeBSD they find most rewarding. Something's got to > give and you can't stop it by creating more beaurocracy and red tape. > > Another thing I think is important is for new hardware to be perpetually > sent to those who can implement drivers and create patches. I don't > feel the FreeBSD foundation is doing enough in that regard. Not talking > about big ticket items like server farms, just new motherboards every > time a new CPU or chipset is released. I agree with the last point. However, a couple counter-points: 1) I believe this is what freebsd-donations@ is for (though I feel the Foundation as a whole could be helping more with this), 2) Based on my own experience: I've offered to purchase new hardware to send developers (free of charge), assuming I can get my hands on whatever hardware it is they need. I'm willing to spend a few hundred dollars to get whatever it is they want, so financially I'm flexible. Here's my experience: What I'm finding out is that it's not the hardware developers need -- it's the time required to sit down and test everything and write the code. No matter what we do, we cannot create more time (or in some cases, more incentives) for developers. What we ultimately need is more talent to make things better. There's a number of people I see doing really good work, at least with regards to RELENG_7 (I do not follow HEAD/CURRENT commits). From what I understand, all these folks are incredibly pressed for time. I'll name names, just because they deserve mention: rwatson, pjd, phk, jhb, alfred, kmacy, kris, kib, yongari, scottl, Andrey Elsukov, and Max Laier. I apologise if I've upset anyone by this -- I'm not naming names to "rank" people against others (it's a volunteer project after all), I'm just listing off people who I've seen do really good work over the past year or so, with regards to the few devices or kernel pieces I actively follow. For something as gargantuan/massive as an entire operating system and all of its device support, there's a very small number of central people doing regular work. Compare this to Linux, where you've got: a) 6-7 times the amount of kernel-people, b) Commercial interest and support from companies (that means developers are more likely to get documentation and development/test hardware from the vendor themselves), c) A significantly larger user-base for testing. I have never agreed with Eric Raymond's "bazaar" concept, where the attitude is "more eyes = overall better". The problem in our case is not lack of eyes, it's lack of hands and brains. We have a lot of smart people who aren't working on kernel-stuff because they lack the experience/knowledge of how to get involved, where to start, and overall understanding of the code. I'm one of those people, for example. I do not understanding threading (the concept yes, the implementation no), nor any "core" part of the kernel. The most common rebuttal to this argument is "Well, there's and ", but then when you try to follow either of them, are later told "yeah, is wrong, and is completely out of date, everything has changed". It's demoralising. I can sit down and within about 15-20 minutes have a minimum understanding of part of a C userland program. Comparatively, I have looked at kernel drivers for hours without any understanding of what numerous kernel ABI/API functions do, why they're being done, why they're being done when they are. I'm not even talking about device-specific semantics (e.g. what does this IC register do, etc.). I'm talking about the surrounding pieces. I *have* hacked on the em(4) driver, but all the surrounding pieces made me say "hmm, do not touch". Any time I see the words VFS, BIO, mtx, or uma, I back off. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From gavin at FreeBSD.org Tue Sep 16 11:13:09 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Sep 16 11:14:58 2008 Subject: unsupported NVIDIA SATA controller In-Reply-To: <20080915192515.A13327@eskimo.com> References: <20080915192515.A13327@eskimo.com> Message-ID: <1221563567.13651.21.camel@buffy.york.ac.uk> On Mon, 2008-09-15 at 19:25 -0700, Joseph Olatt wrote: > Hello, > > I have the following SATA controller card on my system that appears to > be unsupported by FreeBSD 7-STABLE. Does anybody know if this card is > supported or will be supported in the near future? > > /*** Begin change #2 ***/ > [/usr/src/sys/dev/ata] > joji@snow> diff -u ata-chipset.c ata-chipset.c.orig > --- ata-chipset.c 2008-09-15 20:47:55.000000000 -0500 > +++ ata-chipset.c.orig 2008-09-15 20:40:43.000000000 -0500 > @@ -3051,7 +3051,6 @@ > { ATA_NFORCE_MCP65, 0, AMDNVIDIA, NVIDIA, ATA_UDMA6, "nForce MCP65" }, > { ATA_NFORCE_MCP67, 0, AMDNVIDIA, NVIDIA, ATA_UDMA6, "nForce MCP67" }, > { ATA_NFORCE_MCP73, 0, AMDNVIDIA, NVIDIA, ATA_UDMA6, "nForce MCP73" }, > - { ATA_NFORCE_MCP73_S1, 0, 0, NV4|NVQ, ATA_SA300, "nForce MCP73" }, > { ATA_NFORCE_MCP77, 0, AMDNVIDIA, NVIDIA, ATA_UDMA6, "nForce MCP77" }, > { 0, 0, 0, 0, 0, 0}} ; > /*** End change #2 ***/ Before you do anything, can you get a verbose DMESG and stick it online somewhere? This may well help identify why the above isn't working. Secondly, you could try changing the line you've added to be: { ATA_NFORCE_MCP73_S1, 0, AMDNVIDIA, NVIDIA, ATA_SA300, "nForce MCP73" }, although to be honest, I'm not expecting that to fix things for you. If it doesn't, then it looks like this chip may need special support. Because the chip identifies itself as a RAID controller and not as a standard IDE controller, the generic code does not attach to it either. You could override this behaviour by removing your patch and using the attached patch. If nothing else, that may well get you working at UDMA33, which is the most the "generic" ATA controller support can do. Again, if this fails, stick a verbose dmesg online somewhere. The real solution, of proper support for the chip, may not be possible until either documentation is available for it, or another OS (Linux/*BSD/OpenSolaris) support it. Out of interest, what motherboard is this on? Gavin -------------- next part -------------- A non-text attachment was scrubbed... Name: nv73-2.diff Type: text/x-patch Size: 670 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080916/34f30b98/nv73-2.bin From josh.carroll at gmail.com Tue Sep 16 16:41:43 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Tue Sep 16 16:42:36 2008 Subject: recent MFC of soreceive_dgram breaks kernels without INET6 option Message-ID: <8cb6106e0809160941m57b9aa9ehc21b5f92a396082b@mail.gmail.com> Hello, I just csup'd this morning and now I cannot build a kernel that does not include INET6. I can send my KERNCONF, but it is sufficient to create a kernel config with: include GENERIC nooption INET6 Here's the error during kernel compilation of a kernel config without "options INET6" in the kernel config: /usr/src/sys/netinet/udp_usrreq.c: In function 'udp_inpcb_init': /usr/src/sys/netinet/udp_usrreq.c:170: error: 'udp6_usrreqs' undeclared (first use in this function) /usr/src/sys/netinet/udp_usrreq.c:170: error: (Each undeclared identifier is reported only once /usr/src/sys/netinet/udp_usrreq.c:170: error: for each function it appears in.) It looks like the MFC for the new soreceive_dgram stuff is the culprit. Can this can be fixed to not require IPv6? I have no desire to include it in my kernel, but if that will be the requirement going forward, perhaps a note in UPDATING is in order? Thanks, Josh From alfred at freebsd.org Tue Sep 16 16:42:03 2008 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Sep 16 16:42:53 2008 Subject: Apache-worker stuck at 100% CPU In-Reply-To: <9bbcef730809160212m72fffc7k93d0c92ace2b7c19@mail.gmail.com> References: <20080912165808.GE16977@elvis.mu.org> <9bbcef730809121444u34991c52m2cbc01a8ada47eb5@mail.gmail.com> <20080912225251.GG16977@elvis.mu.org> <9bbcef730809151604i28533745m286e7314810d0362@mail.gmail.com> <20080916022738.GJ36572@elvis.mu.org> <9bbcef730809160212m72fffc7k93d0c92ace2b7c19@mail.gmail.com> Message-ID: <20080916164203.GL36572@elvis.mu.org> * Ivan Voras [080916 02:12] wrote: > 2008/9/16 Alfred Perlstein : > > * Ivan Voras [080915 16:05] wrote: > > >> >> How do I pick what thread to backtrace in gdb? > >> > > >> > i think the command is 'info threads' or 'show > >> > threads' then i think you just type > >> > 'thread FOO' to select the thread. > >> > >> Both commands don't work / don't exist. Any others? > >> > >> (background: apache22-worker port, no mod_php, on 7.0 and 7-STABLE > >> suddenly gets stuck at 100% CPU; the same setup worked on 6-STABLE. > >> I'm looking for ideas) > > > > I'm sorry, I really can't help at this point other than to look > > through the documents myself to figure out how to do a backtrace/select > > threads. > > > > Give it a shot, and let us know and we can go further. > > Sorry, I should have been more verbose - "info threads" should work > but it doesn't - I can attach and get threads from a "regular" > multithreaded process, but when yesterday when I attached to the stuck > process, I couldn't get the list of threads. I'll try again the next > time it gets stuck and try to provide more information. If it happens again, you could try sending it a SIGABRT or SEGV and then trying to diagnose the core dump. Or try using gcore to generate a coredump and debug that. -- - Alfred Perlstein From ivoras at freebsd.org Tue Sep 16 16:45:18 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Sep 16 16:47:35 2008 Subject: Apache-worker stuck at 100% CPU In-Reply-To: <20080916164203.GL36572@elvis.mu.org> References: <20080912165808.GE16977@elvis.mu.org> <9bbcef730809121444u34991c52m2cbc01a8ada47eb5@mail.gmail.com> <20080912225251.GG16977@elvis.mu.org> <9bbcef730809151604i28533745m286e7314810d0362@mail.gmail.com> <20080916022738.GJ36572@elvis.mu.org> <9bbcef730809160212m72fffc7k93d0c92ace2b7c19@mail.gmail.com> <20080916164203.GL36572@elvis.mu.org> Message-ID: <9bbcef730809160945y8f472bfw60af0d22149d9376@mail.gmail.com> 2008/9/16 Alfred Perlstein : > * Ivan Voras [080916 02:12] wrote: >> Sorry, I should have been more verbose - "info threads" should work >> but it doesn't - I can attach and get threads from a "regular" >> multithreaded process, but when yesterday when I attached to the stuck >> process, I couldn't get the list of threads. I'll try again the next >> time it gets stuck and try to provide more information. > > If it happens again, you could try sending it a SIGABRT or SEGV > and then trying to diagnose the core dump. > > Or try using gcore to generate a coredump and debug that. It happens approximately every two days; I've rebuild apache with debugging symbols so it will be easier to dig around this time. From clint.olsen at gmail.com Tue Sep 16 17:23:07 2008 From: clint.olsen at gmail.com (Clint Olsen) Date: Tue Sep 16 17:24:31 2008 Subject: Help debugging DMA_READ errors Message-ID: <20080916170452.GB4861@0lsen.net> Ok, I've had some flakiness with my 6.3-STABLE (Sun May 25 21:55:57 PDT 2008) box. I assume that these errors are indicative of a system-level problem rather than a single disk: Event 1 ------- Sep 14 05:12:54 belle kernel: ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=216477719 Result: Hard reset required Event 2 ------- Sep 16 02:11:09 belle kernel: ad4: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=172088735 Sep 16 02:13:08 belle kernel: acd0: WARNING - READ_TOC taskqueue timeout - completing request directly Sep 16 02:13:09 belle kernel: acd0: timeout waiting for ATAPI ready Sep 16 02:13:09 belle kernel: acd0: error issuing ATA PACKET command Sep 16 02:13:09 belle kernel: acd0: WARNING - READ_TOC freeing taskqueue zombie request Sep 16 02:13:09 belle kernel: acd0: timeout waiting for ATAPI ready Sep 16 02:13:09 belle kernel: acd0: error issuing ATA PACKET command ...last two repeating until reset... Result: Hard reset required Disk configuration: ad0: 114473MB at ata0-master UDMA100 ad4: 114473MB at ata2-master SATA150 ad6: 476940MB at ata3-master SATA150 I'm using one of those eSATA converter brackets in the back of the machine for ad6. I'm guessing this doesn't have to do with this problem since that disk wasn't mentioned. Any advice you can offer will be much appreciated. Thanks, -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From koitsu at FreeBSD.org Tue Sep 16 17:59:01 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Sep 16 18:02:42 2008 Subject: Help debugging DMA_READ errors In-Reply-To: <20080916170452.GB4861@0lsen.net> References: <20080916170452.GB4861@0lsen.net> Message-ID: <20080916175858.GA70396@icarus.home.lan> On Tue, Sep 16, 2008 at 10:04:52AM -0700, Clint Olsen wrote: > Ok, I've had some flakiness with my 6.3-STABLE (Sun May 25 21:55:57 PDT > 2008) box. I assume that these errors are indicative of a system-level > problem rather than a single disk: Not necessarily, but FreeBSD makes debugging this kind of situation fairly difficult. It takes time and a lot of patience. If the problem is easily reproducible, that can significantly help. > Event 1 > ------- > Sep 14 05:12:54 belle kernel: ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=216477719 > > Result: Hard reset required > > Event 2 > ------- > Sep 16 02:11:09 belle kernel: ad4: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=172088735 > Sep 16 02:13:08 belle kernel: acd0: WARNING - READ_TOC taskqueue timeout - completing request directly > Sep 16 02:13:09 belle kernel: acd0: timeout waiting for ATAPI ready > Sep 16 02:13:09 belle kernel: acd0: error issuing ATA PACKET command > Sep 16 02:13:09 belle kernel: acd0: WARNING - READ_TOC freeing taskqueue zombie request > Sep 16 02:13:09 belle kernel: acd0: timeout waiting for ATAPI ready > Sep 16 02:13:09 belle kernel: acd0: error issuing ATA PACKET command > ...last two repeating until reset... > > Result: Hard reset required The ad4 error looks very similar to your ad0 timeout earlier, just on a different disk. acd0 is a CD/DVD drive. ad4 is a hard disk. What exactly were you doing with the system at the time these errors appeared? Were you using the CD/DVD drive? Was there a disc in the drive that was mounted? If none of these things, I'm baffled as to what would read acd0 and cause what you see here. I have a feeling all of these might be driven off of a single southbridge controller, which could be going bad, or "wedged" in some way. You've now seen errors on ad0 (PATA device), ad4 (SATA device), and acd0 (unknown, but probably a PATA device). > Disk configuration: > > ad0: 114473MB at ata0-master UDMA100 > ad4: 114473MB at ata2-master SATA150 > ad6: 476940MB at ata3-master SATA150 Can you please provide full details of what these disks are connected to? I'd like to see dmesg output for ata0, ata2, and ata3, as well as the atapci devices those ataX devices are attached to, ditto with vmstat -i output. Are there any other errors in your logs around that time (e.g. watchdog timeouts of any kind on network devices, etc.?) Additionally, it would be very useful if you could install ports/sysutils/smartmontools and provide the following output: # smartctl -a /dev/ad0 # smartctl -a /dev/ad4 This will help in determining if either of the disks saw the DMA errors reported, and help determine if the disks are going bad, or if your machine somehow lost power briefly, or imply that you might have a voltage/PSU problem of some kind. > I'm using one of those eSATA converter brackets in the back of the machine > for ad6. I'm guessing this doesn't have to do with this problem since that > disk wasn't mentioned. I can't say for certain. The above information will help. > Any advice you can offer will be much appreciated. The best advice I can give you is the above, combined with the below Wiki document I've made, time permitting. It is in no way complete, and it may simply induce more questions than answers. http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting The bottom line is that, if the problems you're seeing are the "same thing" others are seeing, then you are not alone. As I said initially, finding the source of these problems is difficult, and they are often "unique" to each individual's machine. For some, replacing cables, the entire motherboard, disk controller, or just the PSU helped; for others, the problem disappeared on its own; in other cases, the problem was so severe that they ended up switching to Linux. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From clint.olsen at gmail.com Tue Sep 16 18:19:17 2008 From: clint.olsen at gmail.com (Clint Olsen) Date: Tue Sep 16 18:22:13 2008 Subject: Help debugging DMA_READ errors In-Reply-To: <20080916175858.GA70396@icarus.home.lan> References: <20080916170452.GB4861@0lsen.net> <20080916175858.GA70396@icarus.home.lan> Message-ID: <20080916181903.GC7540@0lsen.net> Hi Jeremy: Thanks for your detailed response. Here are the answers I have thus far: On Sep 16, Jeremy Chadwick wrote: > acd0 is a CD/DVD drive. ad4 is a hard disk. What exactly were you > doing with the system at the time these errors appeared? Were you using > the CD/DVD drive? Was there a disc in the drive that was mounted? > If none of these things, I'm baffled as to what would read acd0 and > cause what you see here. I was not at the system at the time. I never have had a disk in the drive nor is /cdrom mounted currently. I have dump backups that run in the middle of the night on the various filesystems. > Can you please provide full details of what these disks are connected > to? I'd like to see dmesg output for ata0, ata2, and ata3, as well as > the atapci devices those ataX devices are attached to, ditto with > vmstat -i output. Are there any other errors in your logs around > that time (e.g. watchdog timeouts of any kind on network devices, etc.?) # dmesg | grep -i ata atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0xeff0-0xeff7,0xefe4-0xefe7,0xefa8-0xefaf,0xefe0-0xefe3,0xef60-0xef6f irq 18 at device 31.2 on pci0 ata2: on atapci1 ata3: on atapci1 I skipped the disks, of course. > Additionally, it would be very useful if you could install > ports/sysutils/smartmontools and provide the following output: > > # smartctl -a /dev/ad0 > # smartctl -a /dev/ad4 See attached. > http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting > > The bottom line is that, if the problems you're seeing are the "same > thing" others are seeing, then you are not alone. As I said initially, > finding the source of these problems is difficult, and they are often > "unique" to each individual's machine. For some, replacing cables, the > entire motherboard, disk controller, or just the PSU helped; for others, > the problem disappeared on its own; in other cases, the problem was > so severe that they ended up switching to Linux. I'll take a look at this page. Thanks, -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------- next part -------------- smartctl version 5.38 [i386-portbld-freebsd6.3] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Western Digital Caviar SE family Device Model: WDC WD1200JB-32EVA0 Serial Number: WD-WMAEL1302890 Firmware Version: 15.05R15 User Capacity: 120,034,123,776 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 6 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Tue Sep 16 11:11:04 2008 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: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. 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: (3801) seconds. Offline data collection capabilities: (0x79) SMART execute Offline immediate. No Auto Offline data collection support. Suspend Offline collection upon new command. 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. No General Purpose Logging support. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 53) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 162 148 021 Pre-fail Always - 2433 4 Start_Stop_Count 0x0032 100 100 040 Old_age Always - 79 5 Reallocated_Sector_Ct 0x0033 199 199 140 Pre-fail Always - 7 7 Seek_Error_Rate 0x000b 100 253 051 Pre-fail Always - 0 9 Power_On_Hours 0x0032 042 042 000 Old_age Always - 42740 10 Spin_Retry_Count 0x0013 100 253 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0013 100 253 051 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 79 194 Temperature_Celsius 0x0022 111 253 000 Old_age Always - 39 196 Reallocated_Event_Count 0x0032 193 193 000 Old_age Always - 7 197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0012 200 200 000 Old_age Always - 0 199 UDMA_CRC_Error_Count 0x000a 200 253 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0009 200 155 051 Pre-fail Offline - 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. -------------- next part -------------- smartctl version 5.38 [i386-portbld-freebsd6.3] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Western Digital Caviar SE Serial ATA family Device Model: WDC WD1200JD-00GBB0 Serial Number: WD-WMAET1326141 Firmware Version: 02.05D02 User Capacity: 120,034,123,776 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 6 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Tue Sep 16 11:11:17 2008 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: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. 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: (3801) seconds. Offline data collection capabilities: (0x79) SMART execute Offline immediate. No Auto Offline data collection support. Suspend Offline collection upon new command. 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. No General Purpose Logging support. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 53) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 160 139 021 Pre-fail Always - 2508 4 Start_Stop_Count 0x0032 100 100 040 Old_age Always - 55 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 200 200 051 Pre-fail Always - 0 9 Power_On_Hours 0x0032 051 051 000 Old_age Always - 36471 10 Spin_Retry_Count 0x0013 100 253 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0013 100 253 051 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 55 194 Temperature_Celsius 0x0022 104 253 000 Old_age Always - 46 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0012 200 200 000 Old_age Always - 0 199 UDMA_CRC_Error_Count 0x000a 200 253 000 Old_age Always - 2 200 Multi_Zone_Error_Rate 0x0009 200 155 051 Pre-fail Offline - 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. From joji at eskimo.com Tue Sep 16 18:20:44 2008 From: joji at eskimo.com (Joseph Olatt) Date: Tue Sep 16 18:22:30 2008 Subject: unsupported NVIDIA SATA controller In-Reply-To: <1221563567.13651.21.camel@buffy.york.ac.uk>; from gavin@FreeBSD.org on Tue, Sep 16, 2008 at 12:12:47PM +0100 References: <20080915192515.A13327@eskimo.com> <1221563567.13651.21.camel@buffy.york.ac.uk> Message-ID: <20080916112040.A27758@eskimo.com> On Tue, Sep 16, 2008 at 12:12:47PM +0100, Gavin Atkinson wrote: > On Mon, 2008-09-15 at 19:25 -0700, Joseph Olatt wrote: > > Hello, > > > > I have the following SATA controller card on my system that appears to > > be unsupported by FreeBSD 7-STABLE. Does anybody know if this card is > > supported or will be supported in the near future? > > > > /*** Begin change #2 ***/ > > [/usr/src/sys/dev/ata] > > joji@snow> diff -u ata-chipset.c ata-chipset.c.orig > > --- ata-chipset.c 2008-09-15 20:47:55.000000000 -0500 > > +++ ata-chipset.c.orig 2008-09-15 20:40:43.000000000 -0500 > > @@ -3051,7 +3051,6 @@ > > { ATA_NFORCE_MCP65, 0, AMDNVIDIA, NVIDIA, ATA_UDMA6, "nForce MCP65" }, > > { ATA_NFORCE_MCP67, 0, AMDNVIDIA, NVIDIA, ATA_UDMA6, "nForce MCP67" }, > > { ATA_NFORCE_MCP73, 0, AMDNVIDIA, NVIDIA, ATA_UDMA6, "nForce MCP73" }, > > - { ATA_NFORCE_MCP73_S1, 0, 0, NV4|NVQ, ATA_SA300, "nForce MCP73" }, > > { ATA_NFORCE_MCP77, 0, AMDNVIDIA, NVIDIA, ATA_UDMA6, "nForce MCP77" }, > > { 0, 0, 0, 0, 0, 0}} ; > > /*** End change #2 ***/ > > Before you do anything, can you get a verbose DMESG and stick it online > somewhere? This may well help identify why the above isn't working. http://www.eskimo.com/~joji/nvidia_sata/snow_dmesg-v.txt > Secondly, you could try changing the line you've added to be: > > { ATA_NFORCE_MCP73_S1, 0, AMDNVIDIA, NVIDIA, ATA_SA300, "nForce MCP73" }, > > although to be honest, I'm not expecting that to fix things for you. If > it doesn't, then it looks like this chip may need special support. Made the change suggested above. Building a new kernel. Will provide update after installation and boot-up of new kernel. > Because the chip identifies itself as a RAID controller and not as a > standard IDE controller, the generic code does not attach to it either. > You could override this behaviour by removing your patch and using the > attached patch. If nothing else, that may well get you working at > UDMA33, which is the most the "generic" ATA controller support can do. > Again, if this fails, stick a verbose dmesg online somewhere. > > The real solution, of proper support for the chip, may not be possible > until either documentation is available for it, or another OS > (Linux/*BSD/OpenSolaris) support it. I do have Ubuntu installed on a disk connected to the above mentioned SATA controller. The dmesg from Ubuntu is at: http://www.eskimo.com/~joji/nvidia_sata/dmesg_ubuntu.txt The output of "lspci -vv" from Ubuntu is at: http://www.eskimo.com/~joji/nvidia_sata/lspci-vv.txt I am not clear if Ubuntu is recognizing the SATA hard disk as ATA or SATA. I suspect it is being recognized as a ATA disk because of the following lines from Ubuntu dmesg: [ 23.044251] ata1: SATA max UDMA/133 abar m8192@0xfea7c000 port 0xfea7c100 irq 508 [ 23.044253] ata2: SATA max UDMA/133 abar m8192@0xfea7c000 port 0xfea7c180 irq 508 [ 23.044256] ata3: SATA max UDMA/133 abar m8192@0xfea7c000 port 0xfea7c200 irq 508 [ 23.044258] ata4: SATA max UDMA/133 abar m8192@0xfea7c000 port 0xfea7c280 irq 508 [ 23.682254] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 23.682854] ata1.00: ATA-7: ST3250410AS, 3.AAF, max UDMA/133 But the following line confusing: [ 23.682254] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > Out of interest, what motherboard is this on? > > Gavin Is there a way to find out the motherboard details without opening up the box? If nothing else works, I will back out all my changes and install your patch and see how it goes. Thanks very much for helping. regards, joseph From wb at freebie.xs4all.nl Tue Sep 16 18:45:43 2008 From: wb at freebie.xs4all.nl (Wilko Bulte) Date: Tue Sep 16 18:48:54 2008 Subject: Help debugging DMA_READ errors In-Reply-To: <20080916181903.GC7540@0lsen.net> References: <20080916170452.GB4861@0lsen.net> <20080916175858.GA70396@icarus.home.lan> <20080916181903.GC7540@0lsen.net> Message-ID: <20080916183231.GG41919@freebie.xs4all.nl> Quoting Clint Olsen, who wrote on Tue, Sep 16, 2008 at 11:19:03AM -0700 .. > Hi Jeremy: > > Thanks for your detailed response. Here are the answers I have thus far: > > On Sep 16, Jeremy Chadwick wrote: > > acd0 is a CD/DVD drive. ad4 is a hard disk. What exactly were you > > doing with the system at the time these errors appeared? Were you using > > the CD/DVD drive? Was there a disc in the drive that was mounted? > > If none of these things, I'm baffled as to what would read acd0 and > > cause what you see here. > > I was not at the system at the time. I never have had a disk in the drive > nor is /cdrom mounted currently. I have dump backups that run in the > middle of the night on the various filesystems. Taking a long shot: you do not have cooling issues of the drives maybe? Wilko > > > Can you please provide full details of what these disks are connected > > to? I'd like to see dmesg output for ata0, ata2, and ata3, as well as > > the atapci devices those ataX devices are attached to, ditto with > > vmstat -i output. Are there any other errors in your logs around > > that time (e.g. watchdog timeouts of any kind on network devices, etc.?) > > # dmesg | grep -i ata > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > atapci1: port 0xeff0-0xeff7,0xefe4-0xefe7,0xefa8-0xefaf,0xefe0-0xefe3,0xef60-0xef6f irq 18 at device 31.2 on pci0 > ata2: on atapci1 > ata3: on atapci1 > > I skipped the disks, of course. > > > Additionally, it would be very useful if you could install > > ports/sysutils/smartmontools and provide the following output: > > > > # smartctl -a /dev/ad0 > > # smartctl -a /dev/ad4 > > See attached. > > > http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting > > > > The bottom line is that, if the problems you're seeing are the "same > > thing" others are seeing, then you are not alone. As I said initially, > > finding the source of these problems is difficult, and they are often > > "unique" to each individual's machine. For some, replacing cables, the > > entire motherboard, disk controller, or just the PSU helped; for others, > > the problem disappeared on its own; in other cases, the problem was > > so severe that they ended up switching to Linux. > > I'll take a look at this page. > > Thanks, > > -Clint > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > smartctl version 5.38 [i386-portbld-freebsd6.3] Copyright (C) 2002-8 Bruce Allen > Home page is http://smartmontools.sourceforge.net/ > > === START OF INFORMATION SECTION === > Model Family: Western Digital Caviar SE family > Device Model: WDC WD1200JB-32EVA0 > Serial Number: WD-WMAEL1302890 > Firmware Version: 15.05R15 > User Capacity: 120,034,123,776 bytes > Device is: In smartctl database [for details use: -P show] > ATA Version is: 6 > ATA Standard is: Exact ATA specification draft version not indicated > Local Time is: Tue Sep 16 11:11:04 2008 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: (0x82) Offline data collection activity > was completed without error. > Auto Offline Data Collection: Enabled. > 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: (3801) seconds. > Offline data collection > capabilities: (0x79) SMART execute Offline immediate. > No Auto Offline data collection support. > Suspend Offline collection upon new > command. > 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. > No General Purpose Logging support. > Short self-test routine > recommended polling time: ( 2) minutes. > Extended self-test routine > recommended polling time: ( 53) minutes. > Conveyance self-test routine > recommended polling time: ( 5) minutes. > > SMART Attributes Data Structure revision number: 16 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x000b 200 200 051 Pre-fail Always - 0 > 3 Spin_Up_Time 0x0007 162 148 021 Pre-fail Always - 2433 > 4 Start_Stop_Count 0x0032 100 100 040 Old_age Always - 79 > 5 Reallocated_Sector_Ct 0x0033 199 199 140 Pre-fail Always - 7 > 7 Seek_Error_Rate 0x000b 100 253 051 Pre-fail Always - 0 > 9 Power_On_Hours 0x0032 042 042 000 Old_age Always - 42740 > 10 Spin_Retry_Count 0x0013 100 253 051 Pre-fail Always - 0 > 11 Calibration_Retry_Count 0x0013 100 253 051 Pre-fail Always - 0 > 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 79 > 194 Temperature_Celsius 0x0022 111 253 000 Old_age Always - 39 > 196 Reallocated_Event_Count 0x0032 193 193 000 Old_age Always - 7 > 197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0 > 198 Offline_Uncorrectable 0x0012 200 200 000 Old_age Always - 0 > 199 UDMA_CRC_Error_Count 0x000a 200 253 000 Old_age Always - 0 > 200 Multi_Zone_Error_Rate 0x0009 200 155 051 Pre-fail Offline - 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. > > smartctl version 5.38 [i386-portbld-freebsd6.3] Copyright (C) 2002-8 Bruce Allen > Home page is http://smartmontools.sourceforge.net/ > > === START OF INFORMATION SECTION === > Model Family: Western Digital Caviar SE Serial ATA family > Device Model: WDC WD1200JD-00GBB0 > Serial Number: WD-WMAET1326141 > Firmware Version: 02.05D02 > User Capacity: 120,034,123,776 bytes > Device is: In smartctl database [for details use: -P show] > ATA Version is: 6 > ATA Standard is: Exact ATA specification draft version not indicated > Local Time is: Tue Sep 16 11:11:17 2008 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: (0x82) Offline data collection activity > was completed without error. > Auto Offline Data Collection: Enabled. > 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: (3801) seconds. > Offline data collection > capabilities: (0x79) SMART execute Offline immediate. > No Auto Offline data collection support. > Suspend Offline collection upon new > command. > 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. > No General Purpose Logging support. > Short self-test routine > recommended polling time: ( 2) minutes. > Extended self-test routine > recommended polling time: ( 53) minutes. > Conveyance self-test routine > recommended polling time: ( 5) minutes. > > SMART Attributes Data Structure revision number: 16 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x000b 200 200 051 Pre-fail Always - 0 > 3 Spin_Up_Time 0x0007 160 139 021 Pre-fail Always - 2508 > 4 Start_Stop_Count 0x0032 100 100 040 Old_age Always - 55 > 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 > 7 Seek_Error_Rate 0x000b 200 200 051 Pre-fail Always - 0 > 9 Power_On_Hours 0x0032 051 051 000 Old_age Always - 36471 > 10 Spin_Retry_Count 0x0013 100 253 051 Pre-fail Always - 0 > 11 Calibration_Retry_Count 0x0013 100 253 051 Pre-fail Always - 0 > 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 55 > 194 Temperature_Celsius 0x0022 104 253 000 Old_age Always - 46 > 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 > 197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0 > 198 Offline_Uncorrectable 0x0012 200 200 000 Old_age Always - 0 > 199 UDMA_CRC_Error_Count 0x000a 200 253 000 Old_age Always - 2 > 200 Multi_Zone_Error_Rate 0x0009 200 155 051 Pre-fail Offline - 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. > > _______________________________________________ > 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" --- End of quoted text --- From koitsu at FreeBSD.org Tue Sep 16 18:54:03 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Sep 16 18:55:45 2008 Subject: Help debugging DMA_READ errors In-Reply-To: <20080916181903.GC7540@0lsen.net> References: <20080916170452.GB4861@0lsen.net> <20080916175858.GA70396@icarus.home.lan> <20080916181903.GC7540@0lsen.net> Message-ID: <20080916185401.GA71275@icarus.home.lan> On Tue, Sep 16, 2008 at 11:19:03AM -0700, Clint Olsen wrote: > On Sep 16, Jeremy Chadwick wrote: > > acd0 is a CD/DVD drive. ad4 is a hard disk. What exactly were you > > doing with the system at the time these errors appeared? Were you using > > the CD/DVD drive? Was there a disc in the drive that was mounted? > > If none of these things, I'm baffled as to what would read acd0 and > > cause what you see here. > > I was not at the system at the time. I never have had a disk in the drive > nor is /cdrom mounted currently. I have dump backups that run in the > middle of the night on the various filesystems. That's very strange then. Something definitely tried to utilise acd0 at that hour of the night. What is acd0 connected to, ATA-wise? Again, I assume it's PATA, but I'd like to know the primary/secondary and master/slave organisation, since you are using a PATA disk too. > > Can you please provide full details of what these disks are connected > > to? I'd like to see dmesg output for ata0, ata2, and ata3, as well as > > the atapci devices those ataX devices are attached to, ditto with > > vmstat -i output. Are there any other errors in your logs around > > that time (e.g. watchdog timeouts of any kind on network devices, etc.?) > > # dmesg | grep -i ata > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 > ata0: on atapci0 > ata1: on atapci0 > atapci1: port 0xeff0-0xeff7,0xefe4-0xefe7,0xefa8-0xefaf,0xefe0-0xefe3,0xef60-0xef6f irq 18 at device 31.2 on pci0 > ata2: on atapci1 > ata3: on atapci1 Looks fine, although I swore ATA controllers listed their IRQs. atapci0 doesn't appear to have an IRQ associated with it (should be 14 or 15), so that's a little odd to me. vmstat -i would help here. > See attached. Okay, there are some problems with your disks, but it's going to be impossible for me to determine if the below problems caused what you saw. First, ad0: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE > 5 Reallocated_Sector_Ct 0x0033 199 199 140 Pre-fail Always - 7 > 194 Temperature_Celsius 0x0022 111 253 000 Old_age Always - 39 > 196 Reallocated_Event_Count 0x0032 193 193 000 Old_age Always - 7 You have 7 bad sectors on ad0, and all 7 of those sectors have been successfully remapped (meaning spare sectors on the disk (there is a limited/reserved number of them) have been used). Sector reallocation on ATA and SATA disks happens transparently, meaning the OS is never told by the disk/controller what's going on behind the scenes. However, reallocation can take time -- consider the situation where a bad sector/block cannot be read or written to. The disk may attempt to re-read/write that sector/block a few times before giving up, marking it bad, and using a reallocated spare. FreeBSD will begin spitting out DMA errors after 5 full seconds of not receiving responses to ATA commands. So, if the above reallocations caused what you saw, then the reallocations took >5 seconds. Since you don't have SMART stats for your disks **before** this issue began, we're not going to be able to determine if the reallocations are what caused it. This is why some people run smartd. That said: I do not see any sign of DMA read/write errors in the SMART log. That's good. The temperature of this drive is also acceptable (39C), which is also okay. On to ad4: > 194 Temperature_Celsius 0x0022 104 253 000 Old_age Always - 46 > 199 UDMA_CRC_Error_Count 0x000a 200 253 000 Old_age Always - 2 There are two CRC errors reported here, detected during DMA. These could have resulted in data corruption on your drive; CRC errors cannot correct data, it's just a simple way of determining if what data was sent or received was intact. However, there's no sign of DMA errors in the SMART log. I'm not sure what to make of that; I really would expect there to be some. Additionally, this disk is running at 46C, which borders on the high end of warm. You may want to check cooling or general airflow around the drive. I strongly doubt temperature is the problem here though. Regarding both disks: Some statistics are "offline", which means those attributes/stats will not be updated until you run a short/long/offline SMART test. Do not let the word "offline" make you think the drive is actually taken offline -- it isn't. I would recommend two things: 1) Run "smartctl -t short" on /dev/ad0 and /dev/ad4. You can safely use the disks during this time. After a few minutes (depends on how much disk I/O is happening; the more I/O, the longer the test takes to complete), you should see an entry in the SMART self-test log saying Completed. Once you see that, you should run smartctl -a on the disk again, and see if the attributes labelled "Offline" are different than they were before. 2) Consider running smartd. I do not normally advocate this, but in your case, it may be the only way to see which attribute values are actually changing on you if/when the issue happens again. Any time a value changes, it'll be logged via syslog. You can set up smartd.conf to ignore certain attributes (e.g. temperature, since that has a tendency to fluctuate up and down a degree). If/when this happens again, you should be able to look at your logs and see what counters have changed. For example if you see something like Power_Cycle_Count or Stop_Start_Count increase, you have disks which are losing power. Welcome to the pain of debugging disk problems. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From mike at sentex.net Tue Sep 16 19:34:12 2008 From: mike at sentex.net (Mike Tancsa) Date: Tue Sep 16 19:37:17 2008 Subject: Help debugging DMA_READ errors In-Reply-To: <20080916185401.GA71275@icarus.home.lan> References: <20080916170452.GB4861@0lsen.net> <20080916175858.GA70396@icarus.home.lan> <20080916181903.GC7540@0lsen.net> <20080916185401.GA71275@icarus.home.lan> Message-ID: <200809161934.m8GJY9oe039218@lava.sentex.ca> At 02:54 PM 9/16/2008, Jeremy Chadwick wrote: >However, there's no sign of DMA errors in the SMART log. I'm not sure >what to make of that; I really would expect there to be some. Would not bad cables (or trays) be consistent with symptoms like that ? i.e. the OS sees errors, but when we ask the drive, it says, "what errors". I am sure there are other things that could cause this, but in the past I would start with the cables and or trays. ---Mike From rwatson at FreeBSD.org Tue Sep 16 19:47:21 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Sep 16 19:51:36 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> Message-ID: On Mon, 15 Sep 2008, Jo Rhett wrote: > On Sep 6, 2008, at 4:06 AM, Robert Watson wrote: >> Unfortunately, it's a little hard to tell at time-of-release whether a >> particular release will become extended life or not. This is because >> extended support status is dependent on the success of the release ... >> from earlier branch adopters. How long we keep release 6.x releases will >> depend entirely on how successful 7.x is; I think there's a reasonable >> expectation that 6.4 or 6.5 will be the last 6.x release, in which case we >> would want to grant it extended support status. But what happens depends a >> lot on how successful 7.1 is. My hopes are high, but there's nothing like >> real-world deployment to shed light on things :-). > > Robert, I'd like to point out to you that when I complained about 6.2's > accelerated EoL, I was soundly boxed around the ears and told that I should > have been paying attention to the projected EoL date when we decided to roll > out 6.2 across the business. > > I was also told that I should have been more active in the release cycle > process for 6.3, etc. > > Now you are saying that expected EoL will be determined at some random point > in the future based on gut feelings about how well a completely different > branch is doing. > > How can I reconcile these disparate points of view? How does one focus on > testing and upgrade cycle for an "appropriately supported release" when the > decision for the support cycle is completely up in the air? The FreeBSD Project, as with any other company or organization, responds to events as they occur. We try to plan ahead, and when things go better or worse than expected, we sometimes change the plans. As far as I know we've never *shortened* the expected support timeline for any branch or release, but we have on occasion lenthened them when we feel it's important to do so. I'm not sure what other answer is possible. Robert N M Watson Computer Laboratory University of Cambridge From jhb at freebsd.org Tue Sep 16 19:49:28 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Sep 16 19:52:27 2008 Subject: Suddenly frozen fcntl/stat call on NFS over TCP with MTU 9000 In-Reply-To: <1f51039c0809152302s2e6c1471n89588b058069f73d@mail.gmail.com> References: <1f51039c0809150857l50b6be8eu848e21189a4175d6@mail.gmail.com> <200809151606.23933.jhb@freebsd.org> <1f51039c0809152302s2e6c1471n89588b058069f73d@mail.gmail.com> Message-ID: <200809161130.22736.jhb@freebsd.org> On Tuesday 16 September 2008 02:02:14 am Tim Chen wrote: > On Tue, Sep 16, 2008 at 4:06 AM, John Baldwin wrote: > > > On Monday 15 September 2008 11:57:02 am Tim Chen wrote: > > > Currently I was running a mail server using a netapp filer as backend > > > storage. > > > >From time to time, the whole system get stuck and lasted for 3-5 > > minutes. > > > But > > > after that, everything recovers normally. During the "stuck" moment, > > using > > > ps > > > auxw shows 200-300 of mail delivery agent(MDA) processes staying in "D" > > > status. > > > The command df certainly does not reponse either. > > > > Can you use 'ps axl' to determine the wait mesg ("wchan") of the stuck > > threads > > when they hang? If it is "lockf", then make sure you have an up-to-date > > RELENG_6 kernel as there was a recent fix for a "lockf" hang. > > > > Thanks for your suggestion. After trying to 'ps axl', it seems all the "D > status" process were in nfs,nfsreq,nfsreq. Can you give some hint how to > keep delving the problem? > > My system is RELENG_7 within one week, I always make world to keep my system > up to date. > > > > > > Alternatively, if things are stuck in "nfsreq", it may be useful to use > > tcpdump to look at the NFS requests your client is making. nfsstat can > > also > > be useful as you can see which counters are increasing during a hang. > > > > When system was stuck, counters of nfsstat grows slowly. It seems only > read, write, create, remove in RPC counts were increased. > > As to tcpdump, since I am not familiar with that, I will try to read some > doc and make some tests. > > Thanks very much for your kindly help. Hope the problem can be solved soon. Also, do the nfsstats thing I suggested. During a hang, you can do something like 'nfsstat > one ; sleep 1 ; nfsstat > two' and compare the 'one' and 'two' files to see which counters (if any) are being bumped during the hang. -- John Baldwin From rwatson at FreeBSD.org Tue Sep 16 19:56:38 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Sep 16 19:59:36 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <48CF7394.8040707@modulus.org> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <48CF5282.10608@modulus.org> <20080916065657.GB12295@soaustin.net> <48CF7394.8040707@modulus.org> Message-ID: On Tue, 16 Sep 2008, Andrew Snow wrote: > Mark Linimon wrote: >> So, in your opinion, what's the way to reconcile all these demands >> (features + stability + long-term support of release branches) with a group >> that is 95%-plus volunteer effort? > > Its important to me that people keep using FreeBSD. Numbers are important. > To that end I'm happy for developers to keep working hardest on the parts of > FreeBSD they find most rewarding. Something's got to give and you can't > stop it by creating more beaurocracy and red tape. > > Another thing I think is important is for new hardware to be perpetually > sent to those who can implement drivers and create patches. I don't feel > the FreeBSD foundation is doing enough in that regard. Not talking about > big ticket items like server farms, just new motherboards every time a new > CPU or chipset is released. The FreeBSD Foundation regular funds hardware purchases for FreeBSD developers, both in terms of individual components and larger purchases; we also play an active role in soliciting donations of larger devices. We recently received a very generous donation of a second Filer from NetApp, which has allowed us to help arrange offsite backup for the FreeBSD.org cluster as part of our general effort to improve contingency planning. As far as I know, we've never once received a request from a developer to, for example, fund the purchases of 20 motherboards of various shapes and sizes to improve test coverage. We do have a specific budget to cover exactly those sorts of requests, and the grant application form is placed fairly prominently on our web site. We've also recently announced a developer project funding programme to contract developers to work on specific projects not served adequately by volunteer or developer time, and hope to announce initial grant recipients in the next few weeks. We've just completed an initial proposal selection and I think you'll find that quite few of the proposed projects are of immediate interest to the larger user community. The Foundation, like the Project, is run largely by volunteers (an all-volunteer board, with the exception of one part-time employee who handles administrative aspects of the Foundation), and therefore experiences exactly the same time limitations as developers do. We drive some initiatives forward directly (such as our Netperf Cluster, a high-performance 10gbps network test environment made possible through a collaboration between the FreeBSD Foundation Sentex Communications, and a number of donors including Cisco, NetApp, FreeBSD Systems, Intel, Chelsio, Myricom, Google, iXSystems, IronPort Systems, and individual donors), but we rely on developers to tell us what they need so that we can fund it or seek donations from potential sponsors. Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Tue Sep 16 19:57:43 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Sep 16 19:59:38 2008 Subject: recent MFC of soreceive_dgram breaks kernels without INET6 option In-Reply-To: <8cb6106e0809160941m57b9aa9ehc21b5f92a396082b@mail.gmail.com> References: <8cb6106e0809160941m57b9aa9ehc21b5f92a396082b@mail.gmail.com> Message-ID: On Tue, 16 Sep 2008, Josh Carroll wrote: > I just csup'd this morning and now I cannot build a kernel that does not > include INET6. I can send my KERNCONF, but it is sufficient to create a > kernel config with: > > include GENERIC nooption INET6 > > Here's the error during kernel compilation of a kernel config without > "options INET6" in the kernel config: > > /usr/src/sys/netinet/udp_usrreq.c: In function 'udp_inpcb_init': > /usr/src/sys/netinet/udp_usrreq.c:170: error: 'udp6_usrreqs' > undeclared (first use in this function) > /usr/src/sys/netinet/udp_usrreq.c:170: error: (Each undeclared > identifier is reported only once > /usr/src/sys/netinet/udp_usrreq.c:170: error: for each function it appears in.) > > It looks like the MFC for the new soreceive_dgram stuff is the culprit. > > Can this can be fixed to not require IPv6? I have no desire to include it in > my kernel, but if that will be the requirement going forward, perhaps a note > in UPDATING is in order? This was an oversight on my part -- none of our LINT build targets (apparently) excludes INET6. It's fixed easily with an ifdef, and I've received re@ approval to merge the fix, so it's in the tree as of about an hour or two ago. If you experience continuing problems after a cvsup, please let me know. Robert N M Watson Computer Laboratory University of Cambridge From max.kutsevol at gmail.com Tue Sep 16 20:02:41 2008 From: max.kutsevol at gmail.com (=?koi8-r?B?69XDxdfPzCDtwcvTyc0=?=) Date: Tue Sep 16 20:06:41 2008 Subject: Cypress Semiconductor USB to serial In-Reply-To: <20080916094831.22ED0106571B@hub.freebsd.org> References: <20080916094831.22ED0106571B@hub.freebsd.org> Message-ID: <48d009f2.0405560a.5255.fffff443@mx.google.com> My UPS has a usb interface with USB-to-Serial chip. But ucycom driver doesn't recognize it. uhid driver does, but it doesn't help me, I need a virtual com port. (output below is without uhid loaded) What can I do to get it working? udi = '/org/freedesktop/Hal/devices/usb_device_665_5161_noserial' freebsd.device_file = '/dev/ugen1' (string) freebsd.driver = 'ugen' (string) freebsd.unit = 1 (0x1) (int) info.bus = 'usb_device' (string) info.parent = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial' (string) info.product = 'USB to Serial' (string) info.subsystem = 'usb_device' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_665_5161_noserial' (string) info.vendor = 'Cypress Semiconductor' (string) usb_device.bus_number = 0 (0x0) (int) usb_device.can_wake_up = false (bool) usb_device.configuration_value = 1 (0x1) (int) usb_device.device_class = 0 (0x0) (int) usb_device.device_protocol = 0 (0x0) (int) usb_device.device_revision_bcd = 2 (0x2) (int) usb_device.device_subclass = 0 (0x0) (int) usb_device.is_self_powered = false (bool) usb_device.max_power = 100 (0x64) (int) usb_device.num_configurations = 1 (0x1) (int) usb_device.num_interfaces = 1 (0x1) (int) usb_device.num_ports = 0 (0x0) (int) usb_device.port_number = 3 (0x3) (int) usb_device.product = 'USB to Serial' (string) usb_device.product_id = 20833 (0x5161) (int) usb_device.speed_bcd = 336 (0x150) (int) usb_device.vendor = 'Cypress Semiconductor' (string) usb_device.vendor_id = 1637 (0x665) (int) usb_device.version_bcd = 272 (0x110) (int) From josh.carroll at gmail.com Tue Sep 16 20:04:05 2008 From: josh.carroll at gmail.com (Josh Carroll) Date: Tue Sep 16 20:07:02 2008 Subject: recent MFC of soreceive_dgram breaks kernels without INET6 option In-Reply-To: References: <8cb6106e0809160941m57b9aa9ehc21b5f92a396082b@mail.gmail.com> Message-ID: <8cb6106e0809161304if19ec1crf00be1da955fed54@mail.gmail.com> > This was an oversight on my part -- none of our LINT build targets > (apparently) excludes INET6. It's fixed easily with an ifdef, and I've > received re@ approval to merge the fix, so it's in the tree as of about an > hour or two ago. If you experience continuing problems after a cvsup, > please let me know. Thanks Robert! I pulled down the new version via cvsweb.freebsd.org, since my cvsup mirror did not yet have the update. And the kernel is building properly now. Regards, Josh From koitsu at FreeBSD.org Tue Sep 16 20:15:38 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Sep 16 20:16:14 2008 Subject: Help debugging DMA_READ errors In-Reply-To: <200809161934.m8GJY9oe039218@lava.sentex.ca> References: <20080916170452.GB4861@0lsen.net> <20080916175858.GA70396@icarus.home.lan> <20080916181903.GC7540@0lsen.net> <20080916185401.GA71275@icarus.home.lan> <200809161934.m8GJY9oe039218@lava.sentex.ca> Message-ID: <20080916201530.GA72912@icarus.home.lan> On Tue, Sep 16, 2008 at 03:34:07PM -0400, Mike Tancsa wrote: > At 02:54 PM 9/16/2008, Jeremy Chadwick wrote: > >> However, there's no sign of DMA errors in the SMART log. I'm not sure >> what to make of that; I really would expect there to be some. > > Would not bad cables (or trays) be consistent with symptoms like that ? > i.e. the OS sees errors, but when we ask the drive, it says, "what > errors". I am sure there are other things that could cause this, but in > the past I would start with the cables and or trays. My official answer is: "I'm not sure". :-) Anything is possible. I'd expect carrier/tray problems to manifest themselves as constant data corruption, or disks falling off the bus (loose signal cable or losing power). I'd expect "detach" messages for the SATA channels. But remember, ICH5 lacks AHCI, and I don't know if the FreeBSD ata(4) driver would report detach/attach in that case. I guess a disk falling off the bus or disappearing could in fact lock the controller up in this scenario, I'd imagine. I'd expect cable problems to show constant data errors or loss, and regular DMA errors. FreeBSD would be quite chatty about this, I assume. He just started getting these, and they're only "every couple days". I'd also expect the attribute counters to be much higher -- a bad cable would eventually get noticed by both the controller and the disk, maybe just not consistently. ZFS could help with detecting this (checksum errors), but that's a different beast. I have doubts about the cables being bad because he's seeing issues on a SATA disk and a PATA disk. It seems very unlikely that separate SATA and PATA cables would go bad within a day or two of one another. Another possibility is that the firmware on his drives lack UDMA error logging in SMART. I've seen some drives do this (increase the attribute but not stick anything in the SMART log), but they were old Maxtors. UDMA CRCs were sky-high (to the point where the general drive health was FAIL, REPLACE NOW), but nothing in the SMART log. The acd0 thing bothers me the most, I think -- not because of the oddity, but because it tried to read the TOC of a disc that wasn't even there. A specific ATAPI command induces that, if I remember right. All that said: there is absolutely no harm in replacing the cables! By doing so you can rule those out. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From clint.olsen at gmail.com Tue Sep 16 20:46:03 2008 From: clint.olsen at gmail.com (Clint Olsen) Date: Tue Sep 16 20:46:11 2008 Subject: Help debugging DMA_READ errors In-Reply-To: <200809161934.m8GJY9oe039218@lava.sentex.ca> References: <20080916170452.GB4861@0lsen.net> <20080916175858.GA70396@icarus.home.lan> <20080916181903.GC7540@0lsen.net> <20080916185401.GA71275@icarus.home.lan> <200809161934.m8GJY9oe039218@lava.sentex.ca> Message-ID: <20080916204223.GA19373@0lsen.net> On Sep 16, Mike Tancsa wrote: > Would not bad cables (or trays) be consistent with symptoms like that ? > i.e. the OS sees errors, but when we ask the drive, it says, "what > errors". I am sure there are other things that could cause this, but in > the past I would start with the cables and or trays. Interestingly enough, here are the results for the disk that has the poor-man's eSATA. I would assume those read errors have something to do with cabling. -Clint smartctl version 5.38 [i386-portbld-freebsd6.3] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.9 family Device Model: ST3500641AS Serial Number: 3PM0Y73G Firmware Version: 3.AAJ User Capacity: 500,107,862,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Tue Sep 16 13:41:46 2008 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 See vendor-specific Attribute list for marginal Attributes. General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. 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: ( 430) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No 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: ( 255) minutes. 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 114 096 006 Pre-fail Always - 80481549 3 Spin_Up_Time 0x0003 087 087 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 6 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 085 060 030 Pre-fail Always - 341147812 9 Power_On_Hours 0x0032 095 095 000 Old_age Always - 5037 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 9 187 Reported_Uncorrect 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 050 043 045 Old_age Always In_the_past 50 (Lifetime Min/Max 32/53) 194 Temperature_Celsius 0x0022 050 057 000 Old_age Always - 50 (0 21 0 0) 195 Hardware_ECC_Recovered 0x001a 053 049 000 Old_age Always - 154508649 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 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 5037 - 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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From aragon at phat.za.net Tue Sep 16 21:33:24 2008 From: aragon at phat.za.net (Aragon Gouveia) Date: Tue Sep 16 21:33:32 2008 Subject: Keyspan USB serial adapter Message-ID: <20080916213322.GA70196@phat.za.net> Hi, I'm on the market for a USB serial adapter. The Keyspan USA-19HS gets a lot of good reviews for its performance, but I've noticed previous Keyspan models have a history of not supporting FreeBSD due to firmware issues. The 19HS is listed in /usr/src/sys/dev/usb/usbdevs with nothing noted about firmware (as opposed to the older 19WQ). Can I assume that the firmware problems of the past aren't relevant to the current 19HS? Can anyone confirm if a USA-19HS works on FreeBSD 7-STABLE right now? Thanks, Aragon From stevefranks at ieee.org Tue Sep 16 21:43:48 2008 From: stevefranks at ieee.org (Steve Franks) Date: Tue Sep 16 21:43:55 2008 Subject: Cypress Semiconductor USB to serial In-Reply-To: <48d009f2.0405560a.5255.fffff443@mx.google.com> References: <20080916094831.22ED0106571B@hub.freebsd.org> <48d009f2.0405560a.5255.fffff443@mx.google.com> Message-ID: <539c60b90809161414l2ec415bbpd51c45ff0b1822df@mail.gmail.com> On Tue, Sep 16, 2008 at 12:32 PM, ??????? ?????? wrote: > My UPS has a usb interface with USB-to-Serial chip. > But ucycom driver doesn't recognize it. > uhid driver does, but it doesn't help me, I need a virtual com port. > (output below is without uhid loaded) > What can I do to get it working? > > udi = '/org/freedesktop/Hal/devices/usb_device_665_5161_noserial' > freebsd.device_file = '/dev/ugen1' (string) > freebsd.driver = 'ugen' (string) > freebsd.unit = 1 (0x1) (int) > info.bus = 'usb_device' (string) > info.parent = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial' > (string) > info.product = 'USB to Serial' (string) > info.subsystem = 'usb_device' (string) > info.udi = '/org/freedesktop/Hal/devices/usb_device_665_5161_noserial' > (string) > info.vendor = 'Cypress Semiconductor' (string) > usb_device.bus_number = 0 (0x0) (int) > usb_device.can_wake_up = false (bool) > usb_device.configuration_value = 1 (0x1) (int) > usb_device.device_class = 0 (0x0) (int) > usb_device.device_protocol = 0 (0x0) (int) > usb_device.device_revision_bcd = 2 (0x2) (int) > usb_device.device_subclass = 0 (0x0) (int) > usb_device.is_self_powered = false (bool) > usb_device.max_power = 100 (0x64) (int) > usb_device.num_configurations = 1 (0x1) (int) > usb_device.num_interfaces = 1 (0x1) (int) > usb_device.num_ports = 0 (0x0) (int) > usb_device.port_number = 3 (0x3) (int) > usb_device.product = 'USB to Serial' (string) > usb_device.product_id = 20833 (0x5161) (int) > usb_device.speed_bcd = 336 (0x150) (int) > usb_device.vendor = 'Cypress Semiconductor' (string) > usb_device.vendor_id = 1637 (0x665) (int) > usb_device.version_bcd = 272 (0x110) (int) > > _______________________________________________ > 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" > I believe most older cypress chips require you load a .hex firmware file from devfs.rules on usb connect before they will do anything useful. You can probably find this file (with some other extension than .hex, no doubt) in the windows driver package/install that comes with the device. You might need a spare windows box to un-cab the files. Anyway, after that you would call ezload (/usr/ports/misc/ezload) from devfs.rules to "burn" the .hex into ram every time the device is plugged in. I am the new ezload maintainer as of last week. ezload won't work with recent Cypress chips, but I have a patch such that it will. If you think this is your problem, get back to me, and I'll get you started. On the other hand, the Cypress chip may not need a .hex at all - that is not something I know for sure...I do know that silicon labs & ftdi serial-usb converters have native support and need no .hex (I have several of each)... Steve From thompsa at FreeBSD.org Tue Sep 16 22:16:17 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Tue Sep 16 22:16:24 2008 Subject: Cypress Semiconductor USB to serial In-Reply-To: <48d009f2.0405560a.5255.fffff443@mx.google.com> References: <20080916094831.22ED0106571B@hub.freebsd.org> <48d009f2.0405560a.5255.fffff443@mx.google.com> Message-ID: <20080916214644.GA48294@citylink.fud.org.nz> On Tue, Sep 16, 2008 at 10:32:46PM +0300, ??????? ?????? wrote: > My UPS has a usb interface with USB-to-Serial chip. > But ucycom driver doesn't recognize it. > uhid driver does, but it doesn't help me, I need a virtual com port. > (output below is without uhid loaded) > What can I do to get it working? You could try adding it to the ucycom_devices table in sys/dev/usb/ucycom.c and recompiling ucycom. Andrew From clint.olsen at gmail.com Tue Sep 16 23:17:05 2008 From: clint.olsen at gmail.com (Clint Olsen) Date: Tue Sep 16 23:17:13 2008 Subject: Help debugging DMA_READ errors In-Reply-To: <20080916185401.GA71275@icarus.home.lan> References: <20080916170452.GB4861@0lsen.net> <20080916175858.GA70396@icarus.home.lan> <20080916181903.GC7540@0lsen.net> <20080916185401.GA71275@icarus.home.lan> Message-ID: <20080916231655.GC19665@0lsen.net> On Sep 16, Jeremy Chadwick wrote: > That's very strange then. Something definitely tried to utilise acd0 at > that hour of the night. What is acd0 connected to, ATA-wise? Again, I > assume it's PATA, but I'd like to know the primary/secondary and > master/slave organisation, since you are using a PATA disk too. What's the best way to give you this? Generally with disks I try to separate them from DVD/CD drives, so I don't think they are on the same chain. Is the question whether or not the DVD/CD is a slave to the PATA disk? acd0: CDRW at ata1-master UDMA33 > Looks fine, although I swore ATA controllers listed their IRQs. atapci0 > doesn't appear to have an IRQ associated with it (should be 14 or 15), > so that's a little odd to me. vmstat -i would help here. interrupt total rate irq1: atkbd0 14 0 irq6: fdc0 1 0 irq12: psm0 1624 0 irq14: ata0 410187 14 irq15: ata1 225418 7 irq18: uhci2+ 111881 3 irq22: skc0 260062 9 cpu0: timer 56551841 1999 Total 57561028 2035 > Okay, there are some problems with your disks, but it's going to be > impossible for me to determine if the below problems caused what you saw. > First, ad0: I just freed up a 300G SATA disk, so I can swap out the PATA drive if you think it's worth the effort. > 1) Run "smartctl -t short" on /dev/ad0 and /dev/ad4. You can safely use > the disks during this time. After a few minutes (depends on how much > disk I/O is happening; the more I/O, the longer the test takes to > complete), you should see an entry in the SMART self-test log saying > Completed. Once you see that, you should run smartctl -a on the disk > again, and see if the attributes labelled "Offline" are different than > they were before. > > 2) Consider running smartd. I do not normally advocate this, but in > your case, it may be the only way to see which attribute values are > actually changing on you if/when the issue happens again. Any time a > value changes, it'll be logged via syslog. You can set up smartd.conf > to ignore certain attributes (e.g. temperature, since that has a > tendency to fluctuate up and down a degree). I'm looking at that. The sample conf file that comes with it isn't the easiest on the eyes, so I haven't figure out what configuration I want or how to set it up yet. My external hard drive is running around 50 in that small external enclosure. That sounds bad. 190 Airflow_Temperature_Cel 0x0022 050 043 045 Old_age Always In_the_past 50 (Lifetime Min/Max 32/53) 194 Temperature_Celsius 0x0022 050 057 000 Old_age Always - 50 (0 21 0 0) > If/when this happens again, you should be able to look at your logs and > see what counters have changed. For example if you see something like > Power_Cycle_Count or Stop_Start_Count increase, you have disks which are > losing power. > > Welcome to the pain of debugging disk problems. :-) Thanks :) -Clint -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From vinwa at rocky.kais.kyoto-u.ac.jp Wed Sep 17 02:59:00 2008 From: vinwa at rocky.kais.kyoto-u.ac.jp (KAHO Toshikazu) Date: Wed Sep 17 02:59:07 2008 Subject: alpm(4) I/O range is claimed by ACPI References: <48CD1C54.7040208@incunabulum.net> <20080912065343.GB49512@icarus.home.lan> <200809131109.06694.jhb@freebsd.org> Message-ID: <200809170258.m8H2wsrO064420@pf2.ed.niigata-u.ac.jp> Hello, I am sorry to mistake copying message-id and break mail thread. >> I tried looking for this device in the DSDT, I don't see anything which >> obviously resembles it. The equivalent Linux driver has a means of >> forcing the mapping to be set up if it isn't available: >> http://www.kernel.org/doc/Documentation/i2c/busses/i2c-ali15x3 >> >> It looks like there used to be a means of doing this in the FreeBSD >> driver but it got nuked. And that ASUS didn't much care about power >> management support in this machine... > >If you can re-enable it in such a way that it uses bus_alloc_resource(), then >the driver will probably work fine. How to re-enable it? Please give me some points. PCIR_BAR is always 0, even if any values are written by pciconf. -- KAHO Toshikazu From koitsu at FreeBSD.org Wed Sep 17 04:24:28 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Sep 17 04:24:36 2008 Subject: Keyspan USB serial adapter In-Reply-To: <20080916213322.GA70196@phat.za.net> References: <20080916213322.GA70196@phat.za.net> Message-ID: <20080917042426.GA81776@icarus.home.lan> On Tue, Sep 16, 2008 at 11:33:22PM +0200, Aragon Gouveia wrote: > I'm on the market for a USB serial adapter. The Keyspan USA-19HS gets a > lot of good reviews for its performance, but I've noticed previous Keyspan > models have a history of not supporting FreeBSD due to firmware issues. > The 19HS is listed in /usr/src/sys/dev/usb/usbdevs with nothing noted about > firmware (as opposed to the older 19WQ). Can I assume that the firmware > problems of the past aren't relevant to the current 19HS? > > Can anyone confirm if a USA-19HS works on FreeBSD 7-STABLE right now? Since you're still in the market: I've heard wonderful things about any of the USB serial adapters that use the Prolific chip; see uplcom(4). Others apparently are known for dropping characters on occasion. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Wed Sep 17 05:43:33 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Sep 17 05:43:40 2008 Subject: Help debugging DMA_READ errors In-Reply-To: <20080916231655.GC19665@0lsen.net> References: <20080916170452.GB4861@0lsen.net> <20080916175858.GA70396@icarus.home.lan> <20080916181903.GC7540@0lsen.net> <20080916185401.GA71275@icarus.home.lan> <20080916231655.GC19665@0lsen.net> Message-ID: <20080917054326.GC81776@icarus.home.lan> On Tue, Sep 16, 2008 at 04:16:55PM -0700, Clint Olsen wrote: > On Sep 16, Jeremy Chadwick wrote: > > That's very strange then. Something definitely tried to utilise acd0 at > > that hour of the night. What is acd0 connected to, ATA-wise? Again, I > > assume it's PATA, but I'd like to know the primary/secondary and > > master/slave organisation, since you are using a PATA disk too. > > What's the best way to give you this? Generally with disks I try to > separate them from DVD/CD drives, so I don't think they are on the same > chain. Is the question whether or not the DVD/CD is a slave to the PATA > disk? Correct. I wanted to see if it was on the same primary or secondary controller as the ad0 disk which emitted errors. > acd0: CDRW at ata1-master UDMA33 ...and it doesn't appear to be. Taken from your previous mails: ad0: 114473MB at ata0-master UDMA100 acd0: CDRW at ata1-master UDMA33 What this confirms is that there are two separate PATA cables (one for the ad0 disk, sitting on primary-master on IRQ 14, and one for the acd0 DVD drive, sitting on secondary-master on IRQ 15). So that would mean, in the case of "bad cables", you would have *three* separate cables (2xPATA, 1xSATA) which would all have gone bad at the same time. This is highly, highly unlikely. > > Looks fine, although I swore ATA controllers listed their IRQs. atapci0 > > doesn't appear to have an IRQ associated with it (should be 14 or 15), > > so that's a little odd to me. vmstat -i would help here. > > interrupt total rate > irq1: atkbd0 14 0 > irq6: fdc0 1 0 > irq12: psm0 1624 0 > irq14: ata0 410187 14 > irq15: ata1 225418 7 > irq18: uhci2+ 111881 3 > irq22: skc0 260062 9 > cpu0: timer 56551841 1999 > Total 57561028 2035 IRQs sharing is in effect, despite an APIC being used. But I doubt this is an interrupt problem. IRQ18 is also shared with at least one other device; it's definitely shared with the USB controller, but the "+" indicates there's even more devices associated with the IRQ. Piecing together things from previous mails: ad0 is on ata0 (which is atapci0, Intel ICH5 UDMA100 controller; IRQ 14) acd0 is on ata1 (which is atapci0, Intel ICH5 UDMA100 controller; IRQ 15) ad4 is on ata2 (which is atapci1, Intel ICH5 SATA150 controller; IRQ 18) ad6 is on ata3 (which is atapci1, Intel ICH5 SATA150 controller; IRQ 18) > > Okay, there are some problems with your disks, but it's going to be > > impossible for me to determine if the below problems caused what you saw. > > First, ad0: > > I just freed up a 300G SATA disk, so I can swap out the PATA drive if you > think it's worth the effort. With regards to ad0, it's entirely your call. I'm pedantic about bad blocks, even if they've been remapped successfully, but that's just me. Others are more relaxed about it all. > > 1) Run "smartctl -t short" on /dev/ad0 and /dev/ad4. You can safely use > > the disks during this time. After a few minutes (depends on how much > > disk I/O is happening; the more I/O, the longer the test takes to > > complete), you should see an entry in the SMART self-test log saying > > Completed. Once you see that, you should run smartctl -a on the disk > > again, and see if the attributes labelled "Offline" are different than > > they were before. > > > > 2) Consider running smartd. I do not normally advocate this, but in > > your case, it may be the only way to see which attribute values are > > actually changing on you if/when the issue happens again. Any time a > > value changes, it'll be logged via syslog. You can set up smartd.conf > > to ignore certain attributes (e.g. temperature, since that has a > > tendency to fluctuate up and down a degree). > > I'm looking at that. The sample conf file that comes with it isn't the > easiest on the eyes, so I haven't figure out what configuration I want or > how to set it up yet. The example configuration is overzealous with comments and is badly formatted making it difficult to read. The simple version: If smartd sees the string DEVICESCAN (before any disk definitions), it'll simply probe SMART stats periodically for all disks attached at the time smartd was started. (If disk definitions are seen first, then it ignores DEVICESCAN from that point forward). The problem with DEVICESCAN is that you can't give each device its own flags (see below). Each disk is configured on its own line in the config. The flags you can pass it do many different things (ignore certain changing attributes (-I), send mail to an address on attribute change (-m), and many other things -- see smartd.conf(5)). > My external hard drive is running around 50 in that small external > enclosure. That sounds bad. > > 190 Airflow_Temperature_Cel 0x0022 050 043 045 Old_age Always In_the_past 50 (Lifetime Min/Max 32/53) > 194 Temperature_Celsius 0x0022 050 057 000 Old_age Always - 50 (0 21 0 0) I covered this in another mail; yes, the temperature is of concern, but it's not causing the DMA errors you're seeing on other disks. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From richard at unixguru.nl Wed Sep 17 05:59:59 2008 From: richard at unixguru.nl (Richard Arends) Date: Wed Sep 17 06:00:06 2008 Subject: Keyspan USB serial adapter In-Reply-To: <20080917042426.GA81776@icarus.home.lan> References: <20080916213322.GA70196@phat.za.net> <20080917042426.GA81776@icarus.home.lan> Message-ID: <20080917050330.GB62255@shell.unixguru.nl> On Tue, Sep 16, 2008 at 09:24:26PM -0700, Jeremy Chadwick wrote: > Since you're still in the market: I've heard wonderful things about any > of the USB serial adapters that use the Prolific chip; see uplcom(4). I can second that. I use a Sitecom CN-104 (also Prolific) with several devices like Sun hardware and Soekris/Wrap systems boards and it al works perfectly (FreeBSD/Linux and Windows). http://www.sitecom.com/product.php?productname=USB+to+serial+cable+%96+60cm&productcode=CN-104&productid=31&subgroupid=20 -- Regards, Richard. /* Homo Sapiens non urinat in ventum */ From olli at lurza.secnetix.de Wed Sep 17 11:11:38 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Sep 17 11:11:46 2008 Subject: unsupported NVIDIA SATA controller In-Reply-To: <20080916112040.A27758@eskimo.com> Message-ID: <200809171111.m8HBBMhD081064@lurza.secnetix.de> Joseph Olatt wrote: > Gavin Atkinson wrote: > > Out of interest, what motherboard is this on? > > Is there a way to find out the motherboard details without > opening up the box? Yes. Install and run dmidecode from ports/sysutils/dmidecode. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "And believe me, as a C++ programmer, I don't hesitate to question the decisions of language designers. After a decent amount of C++ exposure, Python's flaws seem ridiculously small." -- Ville Vainio From rwatson at FreeBSD.org Wed Sep 17 11:23:12 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Sep 17 11:23:18 2008 Subject: Possible UDP related deadlock in 7.1-PRERELEASE In-Reply-To: <200809151813.58749.fbsd-ml@scrapper.ca> References: <200809141219.24943.fbsd-ml@scrapper.ca> <1221471431.49328.5.camel@buffy.york.ac.uk> <200809151813.58749.fbsd-ml@scrapper.ca> Message-ID: On Mon, 15 Sep 2008, Norbert Papke wrote: > With WITNESS enabled, I now experience panics and could not follow your > instructions. There is no core dump. The following gets logged to > /var/log/messages: > > shared lock of (rw) udpinp @ /usr/src/sys/netinet/udp_usrreq.c:864 > while exclusively locked from /usr/src/sys/netinet6/udp6_usrreq.c:940 > panic: share->excl > KDB: stack backtrace: > db_trace_self_wrapper(c06fda7c,f6b96978,c052046a,c06fbb5d,c07695c0,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c06fbb5d,c07695c0,c06febd1,f6b96984,f6b96984,...) at > kdb_backtrace+0x29 > panic(c06febd1,c070c409,3ac,c0709eee,360,...) at panic+0xaa > witness_checkorder(ccd5209c,1,c0709eee,360,8,...) at witness_checkorder+0x17c > _rw_rlock(ccd5209c,c0709eee,360,c07780e0,cd4652c8,...) at _rw_rlock+0x2a > udp_send(d3942000,0,c580f400,c68faa00,0,...) at udp_send+0x197 > udp6_send(d3942000,0,c580f400,c68faa00,0,...) at udp6_send+0x140 > sosend_generic(d3942000,c68faa00,f6b96be8,0,0,...) at sosend_generic+0x50d > sosend(d3942000,c68faa00,f6b96be8,0,0,...) at sosend+0x3f > kern_sendit(cd465230,f,f6b96c64,0,0,...) at kern_sendit+0x106 > sendit(0,871b9fe,0,c68faa00,1c,...) at sendit+0x182 > sendto(cd465230,f6b96cfc,18,cd465230,c072bab8,...) at sendto+0x4f > syscall(f6b96d38) at syscall+0x293 > > Note that I do not use IPv6, none of my network interfaces is configured for > it. Dear Norbert, Thanks for this report -- the additional WITNESS debugging information is very helpful, and the above warning may well be the source of the problem you're experiencing. To clarify what you're seeing a bit: some applications that are adapted to use both IPv4 and IPv6 open combined v4/v6 sockets. This is possible because there is a section of the IPv6 address space that "contains" the v4 address space. When an application sends to a v4 address using a v6 socket (wave hands here) the kernel actually calls the v4 UDP code from within the v6 socket code, and it turns out there's a locking bug in that path. So likely some application you are running is using this compatibility mode, and hence triggering this bug. I need to think for a bit about the best way to fix it (it's easy to hack around, but obviously "hacking around" is not the desired solution), and I'll get back to you later this week with a patch. For my reference, it would probably be helpful to know what the application is, since apparently this didn't arise in our testing. You can type "show pcpu" at the DDB prompt after this panic to show what thread is currently running. Thanks, Robert N M Watson Computer Laboratory University of Cambridge > > Also, since I enabled WITNESS, I get the following logged during system > startup: > > Enabling pf. > lock order reversal: > 1st 0xc09af92c pf task mtx (pf task mtx) > @ /usr/src/sys/modules/pf/../../contri > b/pf/net/pf_ioctl.c:1394 > 2nd 0xc07b4d68 ifnet (ifnet) @ /usr/src/sys/net/if.c:1558 > KDB: stack backtrace: > db_trace_self_wrapper(c06fda7c,f4914a60,c0552c75,c06fed11,c07b4d68,...) at > db_tr > ace_self_wrapper+0x26 > kdb_backtrace(c06fed11,c07b4d68,c0703ca2,c0703ca2,c0703c73,...) at > kdb_backtrace > +0x29 > witness_checkorder(c07b4d68,9,c0703c73,616,572,...) at > witness_checkorder+0x5e5 > _mtx_lock_flags(c07b4d68,0,c0703c73,616,c0104414,...) at _mtx_lock_flags+0x34 > ifunit(c6ef5c20,0,c09adfb5,572,c0703a71,...) at ifunit+0x2f > pfioctl(c566ce00,c0104414,c6ef5c20,3,c60c38c0,...) at pfioctl+0x2b43 > devfs_ioctl_f(c588bb94,c0104414,c6ef5c20,c54bb900,c60c38c0,...) at > devfs_ioctl_f > +0xe6 > kern_ioctl(c60c38c0,3,c0104414,c6ef5c20,1000000,...) at kern_ioctl+0x243 > ioctl(c60c38c0,f4914cfc,c,c0718d59,c072b350,...) at ioctl+0x134 > syscall(f4914d38) at syscall+0x293 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281ab6f3, esp = 0xbfbfde3c, > ebp > = 0xbfbfde68 --- > pf enabled > > > I tried to unload 'pf' to see if it was the culprit. However, even without pf > loaded, I experience the panic. > > Is there anything else I can try to provide better insight into what might be > going on? > > Cheers, > > -- Norbert. > _______________________________________________ > 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 marck at rinet.ru Wed Sep 17 11:30:48 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Wed Sep 17 11:30:55 2008 Subject: Supermicro PDSMI failed to boot on fresh RELENG_7/amd64 Message-ID: Colleagues, 3 of 4 times this machine failed to boot, panicing somewhere in late kernel initialization phase (before /sbin/init is executed) I have serial console and KDB enabled, so can do experiments. Last two crashes: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff8026978a stack pointer = 0x10:0xffffffff80611810 frame pointer = 0x10:0xffffffff80611830 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 0 ] Stopped at kobj_lookup_method_mi+0xa: movq 0x8(%rdi),%rax db> bt Tracing pid 0 tid 0 td 0xffffffff80544000 kobj_lookup_method_mi() at kobj_lookup_method_mi+0xa kobj_lookup_method() at kobj_lookup_method+0x1f acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0xc1 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_attach() at acpi_attach+0x984 device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a nexus_attach() at nexus_attach+0x19 device_attach() at device_attach+0x69 root_bus_configure() at root_bus_configure+0x28 configure() at configure+0xa mi_startup() at mi_startup+0x59 btext() at btext+0x2c Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x8:0xffffffff8016f8a1 stack pointer = 0x10:0xffffffff80611850 frame pointer = 0x10:0xffffffff806118d0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 0 ] Stopped at acpi_wake_sysctl_walk+0xa1: cmpq $0x804f8420,(%rax) db> bt Tracing pid 0 tid 0 td 0xffffffff80544000 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0xa1 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_wake_sysctl_walk() at acpi_wake_sysctl_walk+0x74 acpi_attach() at acpi_attach+0x984 device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a nexus_attach() at nexus_attach+0x19 device_attach() at device_attach+0x69 root_bus_configure() at root_bus_configure+0x28 configure() at configure+0xa mi_startup() at mi_startup+0x59 btext() at btext+0x2c Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From olli at lurza.secnetix.de Wed Sep 17 11:47:21 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Sep 17 11:47:28 2008 Subject: ACPI "blacklist" question Message-ID: <200809171147.m8HBlI7F082370@lurza.secnetix.de> Hello, I have recently updated a machine to 7-stable. ACPI doesn't seem to work correctly on this machine. With earlier versions of FreeBSD (including the latest RELENG_6), I got this line in dmesg: ACPI disabled by blacklist. Contact your BIOS vendor. And everything was fine. The box runs perfectly well with ACPI disabled. (I can't get a BIOS update because the mainboard is too old.) When I updated to RELENG_7 a few days ago, the above line did _not_ appear anymore, and the machine didn't proceed to boot, so I had to travel to the console. :-( After disabling ACPI manually via boot.conf hint, it is up and running fine again. Now i'm wondering: Has the ACPI blacklist been removed intentionally, or is this a regression? Certainly I did not find any mentioning of it in UPDATING or anywhere else. Best regards Oliver PS: This is a Gigabyte GA-6BXD board with two Celeron-466 processors on it. Apart from not wanting ACPI it is rock- solid, and I expect it to be in production for DNS, packet filtering, mail backup and small web server for at least another 10 years. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "anyone new to programming should be kept as far from C++ as possible; actually showing the stuff should be considered a criminal offence" -- Jacek Generowicz From sclark46 at earthlink.net Wed Sep 17 12:14:42 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Wed Sep 17 12:14:49 2008 Subject: 6.3 reboot -d doesn't work Message-ID: <48D0EBCE.9030503@earthlink.net> Hello List, I am trying to get a crash dump but am unable to with FreeBSD 6.3-RELEASE-p2 /etc/defaults/rc.conf dumpdir="/var/crash" # Directory where crash dumps are to be stored savecore_flags="" # Used if dumpdev is enabled above, and present. Z2873# sysctl -a |grep physmem hw.physmem: 259481600 Swap: 1024M Total, 1024M Free Z2873# dumpon -v /dev/ad0s1b kernel dumps on /dev/ad0s1b reboot -d ... dumping 255M 2 chunks Then nothing - the system doesn't reboot and I have to hard reset it. When it comes back up there is no crash file in /var/crash from /var/log/messages: Sep 17 07:28:12 Z2873 kernel: ad0: 28615MB at ata0-master UDMA66 Sep 17 07:28:12 Z2873 kernel: Trying to mount root from ufs:/dev/ad0s1a Sep 17 07:28:12 Z2873 savecore: no dumps found Is this broken? 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 talon at lpthe.jussieu.fr Wed Sep 17 15:04:38 2008 From: talon at lpthe.jussieu.fr (Michel Talon) Date: Wed Sep 17 15:04:45 2008 Subject: floppy disk controller broken Message-ID: <20080917150433.GA3585@lpthe.jussieu.fr> Hello, when testing FreeBSD-7.1-BETA i discovered that the floppy disk controller doesn't work correctly. Trying to format a floppy (perhaps with bad blocks) i get: Processing fdformat: ioctl(FD_FORM): Device not configured instead of the normal E letter. I then checked the same problem is present on FreeBSD-6.3 and it has been reported by Beech Rintoul (*) in 2006! Of course the floppy disk driver is particularly messy, but this is not pretty. (*) i386/103862: Error with fdformat -- Michel TALON From fbsd-ml at scrapper.ca Wed Sep 17 15:12:07 2008 From: fbsd-ml at scrapper.ca (Norbert Papke) Date: Wed Sep 17 15:12:15 2008 Subject: Possible UDP related deadlock in 7.1-PRERELEASE In-Reply-To: References: <200809141219.24943.fbsd-ml@scrapper.ca> <200809151813.58749.fbsd-ml@scrapper.ca> Message-ID: <200809170812.05338.fbsd-ml@scrapper.ca> On September 17, 2008, Robert Watson wrote: > On Mon, 15 Sep 2008, Norbert Papke wrote: > > With WITNESS enabled, I now experience panics and could not follow your > > instructions. There is no core dump. The following gets logged to > > /var/log/messages: > > > > shared lock of (rw) udpinp @ /usr/src/sys/netinet/udp_usrreq.c:864 > > while exclusively locked from /usr/src/sys/netinet6/udp6_usrreq.c:940 > > panic: share->excl > > KDB: stack backtrace: > > db_trace_self_wrapper(c06fda7c,f6b96978,c052046a,c06fbb5d,c07695c0,...) > > at db_trace_self_wrapper+0x26 > > kdb_backtrace(c06fbb5d,c07695c0,c06febd1,f6b96984,f6b96984,...) at > > kdb_backtrace+0x29 > > panic(c06febd1,c070c409,3ac,c0709eee,360,...) at panic+0xaa > > witness_checkorder(ccd5209c,1,c0709eee,360,8,...) at > > witness_checkorder+0x17c > > _rw_rlock(ccd5209c,c0709eee,360,c07780e0,cd4652c8,...) at _rw_rlock+0x2a > > udp_send(d3942000,0,c580f400,c68faa00,0,...) at udp_send+0x197 > > udp6_send(d3942000,0,c580f400,c68faa00,0,...) at udp6_send+0x140 > > sosend_generic(d3942000,c68faa00,f6b96be8,0,0,...) at > > sosend_generic+0x50d sosend(d3942000,c68faa00,f6b96be8,0,0,...) at > > sosend+0x3f > > kern_sendit(cd465230,f,f6b96c64,0,0,...) at kern_sendit+0x106 > > sendit(0,871b9fe,0,c68faa00,1c,...) at sendit+0x182 > > sendto(cd465230,f6b96cfc,18,cd465230,c072bab8,...) at sendto+0x4f > > syscall(f6b96d38) at syscall+0x293 > > > > Note that I do not use IPv6, none of my network interfaces is configured > > for it. > To clarify what you're seeing a bit: some applications that are adapted to > use both IPv4 and IPv6 open combined v4/v6 sockets. This is possible > because there is a section of the IPv6 address space that "contains" the v4 > address space. When an application sends to a v4 address using a v6 socket > (wave hands here) the kernel actually calls the v4 UDP code from within the > v6 socket code, and it turns out there's a locking bug in that path. So > likely some application you are running is using this compatibility mode, > and hence triggering this bug. Thank you for this explanation. It helps my peace of mind to understand the context. > I need to think for a bit about the best way to fix it (it's easy to hack > around, but obviously "hacking around" is not the desired solution), and > I'll get back to you later this week with a patch. I am certainly happy to try a patch when it becomes available. > For my reference, it would probably be helpful to know what the application > is, since apparently this didn't arise in our testing. You can type "show > pcpu" at the DDB prompt after this panic to show what thread is currently > running. This may be difficult. I was not entirely clear in my description of the panic. I experience spontaneous reboots when the panic is occurs. DDB is not invoked, nor is a core generated. My suspicion is that "ktorrent", the KDE3 torrent client, is triggering this condition. When I broke into DDB with a non-WITNESS kernel, I observed that one of the "ktorrent" threads was locked on "*udpinp". Additionally, "hald", "ntpd" and the NIC interrupt thread had "*udp" locked. Not sure if this is information is helpful. Cheers, -- Norbert. From marck at rinet.ru Wed Sep 17 16:07:53 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Wed Sep 17 16:08:01 2008 Subject: Supermicro PDSMI failed to boot on fresh RELENG_7/amd64 In-Reply-To: References: Message-ID: On Wed, 17 Sep 2008, Dmitry Morozovsky wrote: DM> Colleagues, DM> DM> 3 of 4 times this machine failed to boot, panicing somewhere in late kernel DM> initialization phase (before /sbin/init is executed) DM> DM> I have serial console and KDB enabled, so can do experiments. Update: booting GENERIC in single user succeeds, but then after pressing ^D machine stucks running sh very slowly: # ^Dload: 0.56 cmd: sh 57 [runnable] 0.90u 2.72s 18% 1760k load: 0.62 cmd: sh 57 [runnable] 1.41u 5.93s 28% 1760k load: 0.65 cmd: sh 57 [runnable] 1.81u 8.80s 32% 1760k load: 0.99 cmd: ps 61 [runnable] 11.44u 106.73s 36% 1124k load: 0.99 cmd: sh 57 [runnable] 3.63u 24.01s 3% 1760k Loading configuration files. load: 0.99 cmd: sh 57 [runnable] 12.58u 95.10s 37% 1884k (these lines consume 5-10 minutes...) Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From koitsu at FreeBSD.org Wed Sep 17 16:23:46 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Sep 17 16:23:54 2008 Subject: Supermicro PDSMI failed to boot on fresh RELENG_7/amd64 In-Reply-To: References: Message-ID: <20080917162342.GA95431@icarus.home.lan> On Wed, Sep 17, 2008 at 03:30:45PM +0400, Dmitry Morozovsky wrote: > Colleagues, > > 3 of 4 times this machine failed to boot, panicing somewhere in late kernel > initialization phase (before /sbin/init is executed) > > {snip} We have many (specifically, 6) PDSMI+ (not PDSMI) boxes which do not exhibit this problem. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Wed Sep 17 16:25:41 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Sep 17 16:26:13 2008 Subject: 6.3 reboot -d doesn't work In-Reply-To: <48D0EBCE.9030503@earthlink.net> References: <48D0EBCE.9030503@earthlink.net> Message-ID: <20080917162537.GB95431@icarus.home.lan> On Wed, Sep 17, 2008 at 07:36:46AM -0400, Stephen Clark wrote: > I am trying to get a crash dump but am unable to with FreeBSD 6.3-RELEASE-p2 > > /etc/defaults/rc.conf > dumpdir="/var/crash" # Directory where crash dumps are to be stored > savecore_flags="" # Used if dumpdev is enabled above, and present. > > Z2873# sysctl -a |grep physmem > hw.physmem: 259481600 > Swap: 1024M Total, 1024M Free > Z2873# dumpon -v /dev/ad0s1b > kernel dumps on /dev/ad0s1b > > reboot -d > ... > dumping 255M 2 chunks > > > Then nothing - the system doesn't reboot and I have to hard reset it. > When it comes back up there is no crash file in /var/crash > > from /var/log/messages: > Sep 17 07:28:12 Z2873 kernel: ad0: 28615MB at > ata0-master UDMA66 > Sep 17 07:28:12 Z2873 kernel: Trying to mount root from ufs:/dev/ad0s1a > Sep 17 07:28:12 Z2873 savecore: no dumps found > > Is this broken? It's a known problem. If when the machine reboots, you forcefully enter single-user, you should be able to get the kernel dump using savecore. http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/118255 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From emaste at freebsd.org Wed Sep 17 17:25:54 2008 From: emaste at freebsd.org (Ed Maste) Date: Wed Sep 17 17:26:01 2008 Subject: 6.3 reboot -d doesn't work In-Reply-To: <20080917162537.GB95431@icarus.home.lan> References: <48D0EBCE.9030503@earthlink.net> <20080917162537.GB95431@icarus.home.lan> Message-ID: <20080917170346.GA49607@sandvine.com> On Wed, Sep 17, 2008 at 09:25:37AM -0700, Jeremy Chadwick wrote: > On Wed, Sep 17, 2008 at 07:36:46AM -0400, Stephen Clark wrote: > > I am trying to get a crash dump but am unable to with FreeBSD 6.3-RELEASE-p2 > > > > [...] > > reboot -d > > ... > > dumping 255M 2 chunks > > > > > > Then nothing - the system doesn't reboot and I have to hard reset it. > > When it comes back up there is no crash file in /var/crash > > [...] > > It's a known problem. If when the machine reboots, you forcefully enter > single-user, you should be able to get the kernel dump using savecore. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/118255 Your PR doesn't look like Stephen's problem to me, since according to his description the system hangs when trying to do the dump so there won't be anything on the disk for savecore to save. - Ed From jhb at freebsd.org Wed Sep 17 17:43:38 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 17 17:43:51 2008 Subject: alpm(4) I/O range is claimed by ACPI In-Reply-To: <200809170258.m8H2wsrO064420@pf2.ed.niigata-u.ac.jp> References: <48CD1C54.7040208@incunabulum.net> <200809131109.06694.jhb@freebsd.org> <200809170258.m8H2wsrO064420@pf2.ed.niigata-u.ac.jp> Message-ID: <200809171137.32759.jhb@freebsd.org> On Tuesday 16 September 2008 10:58:54 pm KAHO Toshikazu wrote: > Hello, > > I am sorry to mistake copying message-id and break mail thread. > > >> I tried looking for this device in the DSDT, I don't see anything which > >> obviously resembles it. The equivalent Linux driver has a means of > >> forcing the mapping to be set up if it isn't available: > >> http://www.kernel.org/doc/Documentation/i2c/busses/i2c-ali15x3 > >> > >> It looks like there used to be a means of doing this in the FreeBSD > >> driver but it got nuked. And that ASUS didn't much care about power > >> management support in this machine... > > > >If you can re-enable it in such a way that it uses bus_alloc_resource(), then > >the driver will probably work fine. > > How to re-enable it? Please give me some points. PCIR_BAR is always 0, > even if any values are written by pciconf. Well, bus_alloc_resource() will allocate resources for the BAR and update the BAR for you, the question is if you need to hardcode the range to bus_alloc_resource() or not. -- John Baldwin From jhb at freebsd.org Wed Sep 17 17:43:44 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 17 17:43:52 2008 Subject: ACPI "blacklist" question In-Reply-To: <200809171147.m8HBlI7F082370@lurza.secnetix.de> References: <200809171147.m8HBlI7F082370@lurza.secnetix.de> Message-ID: <200809171144.48424.jhb@freebsd.org> On Wednesday 17 September 2008 07:47:18 am Oliver Fromme wrote: > Hello, > > I have recently updated a machine to 7-stable. > ACPI doesn't seem to work correctly on this machine. > With earlier versions of FreeBSD (including the latest > RELENG_6), I got this line in dmesg: > > ACPI disabled by blacklist. Contact your BIOS vendor. > > And everything was fine. The box runs perfectly well > with ACPI disabled. (I can't get a BIOS update because > the mainboard is too old.) > > When I updated to RELENG_7 a few days ago, the above line > did _not_ appear anymore, and the machine didn't proceed > to boot, so I had to travel to the console. :-( > After disabling ACPI manually via boot.conf hint, it is > up and running fine again. > > Now i'm wondering: Has the ACPI blacklist been removed > intentionally, or is this a regression? Certainly I did > not find any mentioning of it in UPDATING or anywhere > else. This is a regression. Try this fix: Index: acpi_quirk.c =================================================================== --- acpi_quirk.c (revision 183112) +++ acpi_quirk.c (working copy) @@ -149,9 +149,9 @@ if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_FADT, 0, &fadt))) bzero(&fadt, sizeof(fadt)); if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_DSDT, 0, &dsdt))) - bzero(&fadt, sizeof(dsdt)); + bzero(&dsdt, sizeof(dsdt)); if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_XSDT, 0, &xsdt))) - bzero(&fadt, sizeof(xsdt)); + bzero(&xsdt, sizeof(xsdt)); /* Then, override the quirks with any matched from table signatures. */ for (entry = acpi_quirks_table; entry->match; entry++) { -- John Baldwin From olli at lurza.secnetix.de Wed Sep 17 18:54:39 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Sep 17 18:54:47 2008 Subject: ACPI "blacklist" question In-Reply-To: <200809171144.48424.jhb@freebsd.org> Message-ID: <200809171854.m8HIsanu000121@lurza.secnetix.de> John Baldwin wrote: > Oliver Fromme wrote: > > [...] > > Now i'm wondering: Has the ACPI blacklist been removed > > intentionally, or is this a regression? Certainly I did > > not find any mentioning of it in UPDATING or anywhere > > else. > > This is a regression. Try this fix: > > Index: acpi_quirk.c > =================================================================== > --- acpi_quirk.c (revision 183112) > +++ acpi_quirk.c (working copy) > @@ -149,9 +149,9 @@ > if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_FADT, 0, &fadt))) > bzero(&fadt, sizeof(fadt)); > if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_DSDT, 0, &dsdt))) > - bzero(&fadt, sizeof(dsdt)); > + bzero(&dsdt, sizeof(dsdt)); > if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_XSDT, 0, &xsdt))) > - bzero(&fadt, sizeof(xsdt)); > + bzero(&xsdt, sizeof(xsdt)); > > /* Then, override the quirks with any matched from table signatures. */ > for (entry = acpi_quirks_table; entry->match; entry++) { > Thanks for the quick reply. I will try this on Friday when I'm near the console. I'm a little reluctant to try it remotely. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The ITU has offered the IETF formal alignment with its corresponding technology, Penguins, but that won't fly." -- RFC 2549 From aragon at phat.za.net Wed Sep 17 19:02:35 2008 From: aragon at phat.za.net (Aragon Gouveia) Date: Wed Sep 17 19:02:42 2008 Subject: Keyspan USB serial adapter In-Reply-To: <20080917050330.GB62255@shell.unixguru.nl> References: <20080916213322.GA70196@phat.za.net> <20080917042426.GA81776@icarus.home.lan> <20080917050330.GB62255@shell.unixguru.nl> Message-ID: <20080917190233.GA60386@phat.za.net> | By Richard Arends | [ 2008-09-17 07:05 +0200 ] > On Tue, Sep 16, 2008 at 09:24:26PM -0700, Jeremy Chadwick wrote: > > > Since you're still in the market: I've heard wonderful things about any > > of the USB serial adapters that use the Prolific chip; see uplcom(4). > > I can second that. I use a Sitecom CN-104 (also Prolific) with several > devices like Sun hardware and Soekris/Wrap systems boards and it al works > perfectly (FreeBSD/Linux and Windows). Thanks. I decided to not take a chance and ordered a Prolific based Iogear adapter. :) Thanks, Aragon (who wishes laptops still had com ports) From koitsu at FreeBSD.org Wed Sep 17 20:28:50 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Sep 17 20:28:57 2008 Subject: 6.3 reboot -d doesn't work In-Reply-To: <20080917170346.GA49607@sandvine.com> References: <48D0EBCE.9030503@earthlink.net> <20080917162537.GB95431@icarus.home.lan> <20080917170346.GA49607@sandvine.com> Message-ID: <20080917202848.GA99931@icarus.home.lan> On Wed, Sep 17, 2008 at 01:03:46PM -0400, Ed Maste wrote: > On Wed, Sep 17, 2008 at 09:25:37AM -0700, Jeremy Chadwick wrote: > > > On Wed, Sep 17, 2008 at 07:36:46AM -0400, Stephen Clark wrote: > > > I am trying to get a crash dump but am unable to with FreeBSD 6.3-RELEASE-p2 > > > > > > [...] > > > reboot -d > > > ... > > > dumping 255M 2 chunks > > > > > > > > > Then nothing - the system doesn't reboot and I have to hard reset it. > > > When it comes back up there is no crash file in /var/crash > > > [...] > > > > It's a known problem. If when the machine reboots, you forcefully enter > > single-user, you should be able to get the kernel dump using savecore. > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/118255 > > Your PR doesn't look like Stephen's problem to me, since according to > his description the system hangs when trying to do the dump so there > won't be anything on the disk for savecore to save. You're right, thanks Ed. His "when it comes back up there is no crash file" is what threw me for a loop. Stephen, does the problem *only* happen when using the -d flag, or does the system lock up on reboot in general? If the latter, try using one or both of the following sysctls: hw.acpi.handle_reboot=1 hw.acpi.disable_on_reboot=1 If the lesser, I've no idea. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From nox at jelal.kn-bremen.de Wed Sep 17 21:18:32 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Wed Sep 17 21:18:41 2008 Subject: dtrace: processing aborted: Abort due to systemic unresponsiveness (dtrace_gethrtime()?) - and kgdb Message-ID: <20080917204107.GA11167@saturn.kn-bremen.de> Hi! I got curious in dtrace, and after mr's sys/amd64/amd64/trap.c commit (r183050, thanx! :) I was able to build a kernel that could kldload dtraceall on 7-stable amd64, but trying even simple things like dtrace -n tick-1sec only runs for a short time, or not at all, ending with $subject: # dtrace -n tick-1sec dtrace: description 'tick-1sec' matched 1 probe dtrace: buffer size lowered to 2m CPU ID FUNCTION:NAME 1 32125 :tick-1sec dtrace: processing aborted: Abort due to systemic unresponsiveness # dtrace -n tick-1sec dtrace: description 'tick-1sec' matched 1 probe dtrace: buffer size lowered to 2m dtrace: processing aborted: Abort due to systemic unresponsiveness # Looking around on the net I find that this is probably related to dtrace_gethrtime() (this box is SMP), which I see defined in sys/amd64/amd64/tsc.c, but also in sys/cddl/dev/dtrace/amd64/dtrace_subr.c, and in sys/cddl/dev/dtrace/i386/dtrace_subr.c, but nowhere under sys/i386. The versions in sys/cddl/dev/dtrace take cpu-dependent tsc offsets into account which the one in sys/amd64/amd64/tsc.c doesn't, is there any particular reason this version is used? Also I don't see it in HEAD... Wondering, Juergen PS: I also found out that kgdb doesn't seem to like dtrace bits in the kernel, backtraces look like from a kernel without debug symbols, even if I don't use dtrace or even kldload it. From jhb at freebsd.org Wed Sep 17 21:18:45 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 17 21:18:58 2008 Subject: floppy disk controller broken In-Reply-To: <20080917150433.GA3585@lpthe.jussieu.fr> References: <20080917150433.GA3585@lpthe.jussieu.fr> Message-ID: <200809171713.39694.jhb@freebsd.org> On Wednesday 17 September 2008 11:04:33 am Michel Talon wrote: > Hello, > > when testing FreeBSD-7.1-BETA i discovered that the floppy disk > controller doesn't work correctly. Trying to format a floppy (perhaps > with bad blocks) i get: > Processing fdformat: ioctl(FD_FORM): Device not configured > instead of the normal E letter. I then checked the same problem is > present on FreeBSD-6.3 and it has been reported by Beech Rintoul (*) in > 2006! Of course the floppy disk driver is particularly messy, but > this is not pretty. > > (*) i386/103862: Error with fdformat It looks like the ioctl to format a track used to never report failures from the controller. The newer driver does. What I've done with fdformat is to make it just ignore the errors in userland instead. Try this: Index: fdformat.c =================================================================== --- fdformat.c (revision 183112) +++ fdformat.c (working copy) @@ -75,8 +75,7 @@ f.fd_formb_secno(i) = il[i+1]; f.fd_formb_secsize(i) = secsize; } - if(ioctl(fd, FD_FORM, (caddr_t)&f) < 0) - err(EX_OSERR, "ioctl(FD_FORM)"); + (void)ioctl(fd, FD_FORM, (caddr_t)&f); } static int -- John Baldwin From jrhett at netconsonance.com Wed Sep 17 21:52:41 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed Sep 17 21:52:48 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <20080916065657.GB12295@soaustin.net> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <48CF5282.10608@modulus.org> <20080916065657.GB12295@soaustin.net> Message-ID: <78BA6D76-2667-44B3-BF21-0B940D3C6E13@netconsonance.com> > On Tue, Sep 16, 2008 at 04:30:26PM +1000, Andrew Snow wrote: >> I think FreeBSD is getting in a difficult position now because >> there's >> so much cool new stuff being shoe-horned in, but without the >> necessary >> volume of contributors to back it up with testing and bug fixes. On Sep 15, 2008, at 11:56 PM, Mark Linimon wrote: > We're interested in suggestions about how to get more people involved > with testing and bug fixes. > > There's certainly no lack of demand for the features -- all the way > from > running on inexpensive wireless routers all the way up to 'enterprise- > grade' distributed storage solutions. (These are real examples from > various mailing lists.) > > So, in your opinion, what's the way to reconcile all these demands > (features + stability + long-term support of release branches) with > a group that is 95%-plus volunteer effort? As I have said to you directly in personal e-mail, the maintenance schedule is creating a chicken and egg problem. If companies weren't forced to run internal distribution and release management on their own, they could allocate more resources (ie volunteers -- PAID ones!) to testing and release management of the main distribution. To speak personally from my own experience: our business can not afford to pay me to help develop a release effort with an unknown maintenance period (6.4-REL). Since we need to have a clear maintenance window for any installed/upgraded host, we are forced to provide that support internally. If we had known (and longer than 12 month) maintenance periods for a given release, then I could avoid maintaining this infrastructure internally and would have somewhere in the neighborhood of 20 hours a month I could dedicate to testing and bug fixes of FreeBSD as a whole. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Wed Sep 17 21:57:59 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed Sep 17 21:58:07 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <48CF6292.7050909@infracaninophile.co.uk> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <48CF5282.10608@modulus.org> <20080916065657.GB12295@soaustin.net> <48CF6292.7050909@infracaninophile.co.uk> Message-ID: On Sep 16, 2008, at 12:38 AM, Matthew Seaman wrote: > On 'long term support of release branches' -- a volunteer project is > always > going to struggle to provide this without some form of income to > support the > necessary hardware and personnel resources needed. Or in other > words, if > FreeBSD users want the same sort of support structure as they can > get from a > commercial vendor, it's going to take a commercial vendor to supply > it. > > FreeBSD Corporation anyone? I disagree. The entire advantage of open source is the advantage provided by shared interest in a working product. Each party can put in a little and the product is improved for everyone. If we remove the factors that hamstring companies from providing more resources to assist, then you can get more resources working on the problem - to everyone's benefit. I'm not kidding when I say that nearly everyone I know who uses FreeBSD in their company spends a lot of time managing their internal distribution. (And every reply to this topic on this mailing list has echoed the exact same statement.) None of the ones I know personally have any interest in doing this, and would be happier focusing their effort on the mainstream release. A bunch of us made proposals to our $EMPLOYERs to make this happen, but there was no apparent interest from the release team so the effort was abandoned. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Wed Sep 17 22:02:43 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed Sep 17 22:02:50 2008 Subject: Upcoming Releases Schedule... In-Reply-To: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> Message-ID: <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> > On Mon, 15 Sep 2008, Jo Rhett wrote: >> Robert, I'd like to point out to you that when I complained about >> 6.2's accelerated EoL, I was soundly boxed around the ears and told >> that I should have been paying attention to the projected EoL date >> when we decided to roll out 6.2 across the business. >> >> Now you are saying that expected EoL will be determined at some >> random point in the future based on gut feelings about how well a >> completely different branch is doing. >> >> How can I reconcile these disparate points of view? How does one >> focus on testing and upgrade cycle for an "appropriately supported >> release" when the decision for the support cycle is completely up >> in the air? > On Sep 16, 2008, at 12:47 PM, Robert Watson wrote: > The FreeBSD Project, as with any other company or organization, > responds to events as they occur. We try to plan ahead, and when > things go better or worse than expected, we sometimes change the > plans. As far as I know we've never *shortened* the expected > support timeline for any branch or release, but we have on occasion > lenthened them when we feel it's important to do so. I'm not sure > what other answer is possible. No other answer. But nobody has yet provided what the EoL period is going to be. I have no problems with a period being extended ;-) But the business needs to know the minimum EoL for a given release to determine if upgrading to that release is viable. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From rwatson at FreeBSD.org Wed Sep 17 23:33:48 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Wed Sep 17 23:33:54 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> Message-ID: On Wed, 17 Sep 2008, Jo Rhett wrote: >> On Mon, 15 Sep 2008, Jo Rhett wrote: >>> Robert, I'd like to point out to you that when I complained about 6.2's >>> accelerated EoL, I was soundly boxed around the ears and told that I >>> should have been paying attention to the projected EoL date when we >>> decided to roll out 6.2 across the business. >>> >>> Now you are saying that expected EoL will be determined at some random >>> point in the future based on gut feelings about how well a completely >>> different branch is doing. >>> >>> How can I reconcile these disparate points of view? How does one focus on >>> testing and upgrade cycle for an "appropriately supported release" when >>> the decision for the support cycle is completely up in the air? >> > On Sep 16, 2008, at 12:47 PM, Robert Watson wrote: >> The FreeBSD Project, as with any other company or organization, responds to >> events as they occur. We try to plan ahead, and when things go better or >> worse than expected, we sometimes change the plans. As far as I know we've >> never *shortened* the expected support timeline for any branch or release, >> but we have on occasion lenthened them when we feel it's important to do >> so. I'm not sure what other answer is possible. > > No other answer. But nobody has yet provided what the EoL period is going > to be. I have no problems with a period being extended ;-) But the > business needs to know the minimum EoL for a given release to determine if > upgrading to that release is viable. Well, a starting answer is the policy found on http://security.FreeBSD.org/: Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. Extended Selected releases will be supported by the Security Officer for a minimum of 24 months after the release. At the time of release, we know if a release is considered "early adopter", and attempt to clearly mark it as such. The harder question is whether or not we will start out considering a release "normal" or "extended" -- sometimes we are able to make that decision at the time of the release (i.e., we believe firmly it's the last release on the branch at the time of release), but on the whole we will make that decision based on the facts on the ground. An important factor is whether or not we consider the release a highly maintainable release, and while we have intuitions at the time of release, that's something we can only learn in the first couple of months after it's in production. I don't know of any COTS software house that really does it any differently, and I'm not sure you could do it differently -- no one plans to ship a lemon, but once in a while you discover that things don't go as planned. Robert N M Watson Computer Laboratory University of Cambridge From vinwa at rocky.kais.kyoto-u.ac.jp Thu Sep 18 01:39:22 2008 From: vinwa at rocky.kais.kyoto-u.ac.jp (KAHO Toshikazu) Date: Thu Sep 18 01:39:31 2008 Subject: alpm(4) I/O range is claimed by ACPI References: <200809171137.32759.jhb@freebsd.org> Message-ID: <200809180139.m8I1dJEt067791@pf2.ed.niigata-u.ac.jp> Hello, > Well, bus_alloc_resource() will allocate resources for the BAR and update the > BAR for you, the question is if you need to hardcode the range to > bus_alloc_resource() or not. It is necessary for a pci device to set the BAR, if the device would use memory or I/O space, isn't it? I don't know why the BAR is not settable, but I think it is disabled by some reasons and the BAR may be settable if the device could be enabled. If the device have default I/O space, it needs to hardcode the range or isa attach code. The device dose not seem to have default I/O space. This problem is not so important for myself, but it is a good if it was solved. -- KAHO Toshikazu From jrhett at netconsonance.com Thu Sep 18 04:27:36 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Sep 18 04:27:42 2008 Subject: Upcoming Releases Schedule... In-Reply-To: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> Message-ID: <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> On Sep 17, 2008, at 4:33 PM, Robert Watson wrote: > An important factor is whether or not we consider the release a > highly maintainable release, and while we have intuitions at the > time of release, that's something we can only learn in the first > couple of months after it's in production. I don't know of any COTS > software house that really does it any differently I understand what you mean, but the statement is blatantly false as stated. Anyone selling software to the US Government *must* specify (or meet, depending) a minimum support period, and must also specify a cost the agency can pay to extend the support period. Not relevant to FreeBSD -- just qualifying the statement as it stands. For the obvious comparison, Solaris versions have well- published release and support periods, usually upwards of 8 years. Obviously they have more resources to do this, I'm just pointing out that the statement you made is incorrect as stated. > and I'm not sure you could do it differently -- no one plans to ship > a lemon, but once in a while you discover that things don't go as > planned. I am amazed at the preposterously large elephant in the room that none of you are willing to address. Watching each of you dance around it would be terribly funny if it didn't affect my job so badly. (and if I wasn't going to have to bail on FreeBSD and go to some crap form of Linux because the FreeBSD developers appear to be unwilling to consider the idea of getting more help) Your limitation is resources, right? You've calculated what you can support based on the resources you have, right? We are talking about ways to increase the resources available to you... right? So the math on which the conclusions are reached then changes. So lets figure out... what do the basis numbers need to be to change the support period? Obviously this is a bit of hand waving. These numbers are unlikely to be empirical. But try. Examine the concept of having increased resources. What do you need. How do you need it, to make a real change? Please stop avoiding even considering what people are offering to you. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From andrew at modulus.org Thu Sep 18 04:56:51 2008 From: andrew at modulus.org (Andrew Snow) Date: Thu Sep 18 04:56:59 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> Message-ID: <48D1DF82.20205@modulus.org> Another thing that I believe would help: Voting on PRs. Currently a maintainer has no idea if a PR is due to one guy's flakey hardware or if 50 people have had the same problem and are waiting for a fix. For each major problem report, there are probably many people who tried FreeBSD on particular hardware and just silently gave up when it failed. Ability to "vote up" on a PR on the freebsd website would give maintainers a tool to see which PRs are affecting the userbase. - Andrew From andrewd at webzone.net.au Thu Sep 18 06:41:43 2008 From: andrewd at webzone.net.au (Andrew D (Webzone)) Date: Thu Sep 18 06:41:50 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <48D1DF82.20205@modulus.org> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <48D1DF82.20205@modulus.org> Message-ID: <48D1F5C0.6070502@webzone.net.au> Andrew Snow wrote: > > Another thing that I believe would help: Voting on PRs. > > Currently a maintainer has no idea if a PR is due to one guy's flakey > hardware or if 50 people have had the same problem and are waiting for a > fix. > > For each major problem report, there are probably many people who tried > FreeBSD on particular hardware and just silently gave up when it failed. You might even find that people don't even know what a PR is or how to report it. Maybe a dialog during the install telling people about the PR system might be helpful. > > Ability to "vote up" on a PR on the freebsd website would give > maintainers a tool to see which PRs are affecting the userbase. Andrew > > - Andrew > _______________________________________________ > 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 talon at lpthe.jussieu.fr Thu Sep 18 07:53:10 2008 From: talon at lpthe.jussieu.fr (Michel Talon) Date: Thu Sep 18 07:53:17 2008 Subject: floppy disk controller broken In-Reply-To: <200809171713.39694.jhb@freebsd.org> References: <20080917150433.GA3585@lpthe.jussieu.fr> <200809171713.39694.jhb@freebsd.org> Message-ID: <20080918075306.GA30709@lpthe.jussieu.fr> On Wed, Sep 17, 2008 at 05:13:39PM -0400, John Baldwin wrote: > On Wednesday 17 September 2008 11:04:33 am Michel Talon wrote: > > Hello, > > > > when testing FreeBSD-7.1-BETA i discovered that the floppy disk > > controller doesn't work correctly. Trying to format a floppy (perhaps > > with bad blocks) i get: > > Processing fdformat: ioctl(FD_FORM): Device not configured > > instead of the normal E letter. I then checked the same problem is > > present on FreeBSD-6.3 and it has been reported by Beech Rintoul (*) in > > 2006! Of course the floppy disk driver is particularly messy, but > > this is not pretty. > > > > (*) i386/103862: Error with fdformat > > It looks like the ioctl to format a track used to never report failures from > the controller. The newer driver does. What I've done with fdformat is to > make it just ignore the errors in userland instead. Try this: > > Index: fdformat.c > =================================================================== > --- fdformat.c (revision 183112) > +++ fdformat.c (working copy) > @@ -75,8 +75,7 @@ > f.fd_formb_secno(i) = il[i+1]; > f.fd_formb_secsize(i) = secsize; > } > - if(ioctl(fd, FD_FORM, (caddr_t)&f) < 0) > - err(EX_OSERR, "ioctl(FD_FORM)"); > + (void)ioctl(fd, FD_FORM, (caddr_t)&f); > } > > static int > > > -- > John Baldwin This doesn't work any more. This time i get niobe# fdformat fd0 Format 1440K floppy `/dev/fd0'? (y/n): y Processing EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE done. where only the first E takes some time to be printed, and all subsequent ones are printed instantaneously, that is all other formatting is not tried. In principle the formatting process must try each of the "sectors" in turn, and can come up with a series of V and F. Moreover, trying to write to the floppy: niobe# dd if=/dev/zero of=/dev/fd0 conv=noerror dd: /dev/fd0: Input/output error 5+0 records in 4+0 records out 2048 bytes transferred in 4.054404 secs (505 bytes/sec) I don't expect such result. Traditionnally writing works, while reading may fail. Here reading fails with incoherent messages: dd: /dev/fd0: Device not configured 3+0 records in 3+0 records out 1536 bytes transferred in 2.595216 secs (592 bytes/sec) repeated a large number of times. But nothing in dmesg, contrary to the tradition which showed the defective sectors. In conclusion i am under the impression that the in kernel driver is severely botched. Of course nobody uses floppies any more, but this is quite ugly. -- Michel TALON From sclark46 at earthlink.net Thu Sep 18 11:57:21 2008 From: sclark46 at earthlink.net (Stephen Clark) Date: Thu Sep 18 11:57:28 2008 Subject: 6.3 reboot -d doesn't work In-Reply-To: <20080917202848.GA99931@icarus.home.lan> References: <48D0EBCE.9030503@earthlink.net> <20080917162537.GB95431@icarus.home.lan> <20080917170346.GA49607@sandvine.com> <20080917202848.GA99931@icarus.home.lan> Message-ID: <48D2421E.5090909@earthlink.net> Jeremy Chadwick wrote: > On Wed, Sep 17, 2008 at 01:03:46PM -0400, Ed Maste wrote: >> On Wed, Sep 17, 2008 at 09:25:37AM -0700, Jeremy Chadwick wrote: >> >>> On Wed, Sep 17, 2008 at 07:36:46AM -0400, Stephen Clark wrote: >>>> I am trying to get a crash dump but am unable to with FreeBSD 6.3-RELEASE-p2 >>>> >>>> [...] >>>> reboot -d >>>> ... >>>> dumping 255M 2 chunks >>>> >>>> >>>> Then nothing - the system doesn't reboot and I have to hard reset it. >>>> When it comes back up there is no crash file in /var/crash >>>> [...] >>> It's a known problem. If when the machine reboots, you forcefully enter >>> single-user, you should be able to get the kernel dump using savecore. >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/118255 >> Your PR doesn't look like Stephen's problem to me, since according to >> his description the system hangs when trying to do the dump so there >> won't be anything on the disk for savecore to save. > > You're right, thanks Ed. His "when it comes back up there is no crash > file" is what threw me for a loop. > > Stephen, does the problem *only* happen when using the -d flag, or does > the system lock up on reboot in general? > > If the latter, try using one or both of the following sysctls: > > hw.acpi.handle_reboot=1 > hw.acpi.disable_on_reboot=1 > > If the lesser, I've no idea. > The problem only happens when I do the reboot -d. If I do reboot it comes back ok. I have tried it on two different platforms 1) a Biostar TForce 6100 mainboard with an AMD dual core processor 2) a Soekris net5501 with the same results. I get the dumping message and then it hangs and I have to hard reset the box. 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 wb at freebie.xs4all.nl Thu Sep 18 12:58:11 2008 From: wb at freebie.xs4all.nl (Wilko Bulte) Date: Thu Sep 18 12:58:18 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> References: <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> Message-ID: <20080918124608.GK91598@freebie.xs4all.nl> Quoting Jo Rhett, who wrote on Wed, Sep 17, 2008 at 09:25:27PM -0700 .. > On Sep 17, 2008, at 4:33 PM, Robert Watson wrote: > > An important factor is whether or not we consider the release a > > highly maintainable release, and while we have intuitions at the > > time of release, that's something we can only learn in the first > > couple of months after it's in production. I don't know of any COTS > > software house that really does it any differently > > I understand what you mean, but the statement is blatantly false as > stated. Anyone selling software to the US Government *must* specify > (or meet, depending) a minimum support period, and must also specify a > cost the agency can pay to extend the support period. > > Not relevant to FreeBSD -- just qualifying the statement as it > stands. For the obvious comparison, Solaris versions have well- > published release and support periods, usually upwards of 8 years. > Obviously they have more resources to do this, I'm just pointing out > that the statement you made is incorrect as stated. > > > and I'm not sure you could do it differently -- no one plans to ship > > a lemon, but once in a while you discover that things don't go as > > planned. > > > I am amazed at the preposterously large elephant in the room that none > of you are willing to address. Watching each of you dance around it > would be terribly funny if it didn't affect my job so badly. (and if > I wasn't going to have to bail on FreeBSD and go to some crap form of > Linux because the FreeBSD developers appear to be unwilling to > consider the idea of getting more help) You seem to be *demanding* quite a lot lately. Wilko From koitsu at FreeBSD.org Thu Sep 18 13:18:44 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 18 13:18:51 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <20080918124608.GK91598@freebie.xs4all.nl> References: <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <20080918124608.GK91598@freebie.xs4all.nl> Message-ID: <20080918131840.GA18595@icarus.home.lan> On Thu, Sep 18, 2008 at 02:46:09PM +0200, Wilko Bulte wrote: > Quoting Jo Rhett, who wrote on Wed, Sep 17, 2008 at 09:25:27PM -0700 .. > > On Sep 17, 2008, at 4:33 PM, Robert Watson wrote: > > > An important factor is whether or not we consider the release a > > > highly maintainable release, and while we have intuitions at the > > > time of release, that's something we can only learn in the first > > > couple of months after it's in production. I don't know of any COTS > > > software house that really does it any differently > > > > I understand what you mean, but the statement is blatantly false as > > stated. Anyone selling software to the US Government *must* specify > > (or meet, depending) a minimum support period, and must also specify a > > cost the agency can pay to extend the support period. > > > > Not relevant to FreeBSD -- just qualifying the statement as it > > stands. For the obvious comparison, Solaris versions have well- > > published release and support periods, usually upwards of 8 years. > > Obviously they have more resources to do this, I'm just pointing out > > that the statement you made is incorrect as stated. > > > > > and I'm not sure you could do it differently -- no one plans to ship > > > a lemon, but once in a while you discover that things don't go as > > > planned. > > > > > > I am amazed at the preposterously large elephant in the room that none > > of you are willing to address. Watching each of you dance around it > > would be terribly funny if it didn't affect my job so badly. (and if > > I wasn't going to have to bail on FreeBSD and go to some crap form of > > Linux because the FreeBSD developers appear to be unwilling to > > consider the idea of getting more help) > > You seem to be *demanding* quite a lot lately. Jo has a point, though. I'm certain he's looked at the situation from the developers' point of view, and in response, I'd recommend others try to look at it from his, even if others consider it silly or unreasonable. It's a frustrating situation, and there's no snap-your-fingers-voila solution for it, other than extending support lifetimes per release. Mark's graphs show release lifetimes are getting shorter, which I doubt Jo would have a problem with, assuming each new release was somehow guaranteed (more or less, cut me some slack) to not break previous releases' binaries and so on. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From wb at freebie.xs4all.nl Thu Sep 18 13:32:45 2008 From: wb at freebie.xs4all.nl (Wilko Bulte) Date: Thu Sep 18 13:32:53 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <20080918131840.GA18595@icarus.home.lan> References: <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <20080918124608.GK91598@freebie.xs4all.nl> <20080918131840.GA18595@icarus.home.lan> Message-ID: <20080918133211.GL91598@freebie.xs4all.nl> Quoting Jeremy Chadwick, who wrote on Thu, Sep 18, 2008 at 06:18:40AM -0700 .. > On Thu, Sep 18, 2008 at 02:46:09PM +0200, Wilko Bulte wrote: > > Quoting Jo Rhett, who wrote on Wed, Sep 17, 2008 at 09:25:27PM -0700 .. > > > On Sep 17, 2008, at 4:33 PM, Robert Watson wrote: > > > > An important factor is whether or not we consider the release a > > > > highly maintainable release, and while we have intuitions at the > > > > time of release, that's something we can only learn in the first > > > > couple of months after it's in production. I don't know of any COTS > > > > software house that really does it any differently > > > > > > I understand what you mean, but the statement is blatantly false as > > > stated. Anyone selling software to the US Government *must* specify > > > (or meet, depending) a minimum support period, and must also specify a > > > cost the agency can pay to extend the support period. > > > > > > Not relevant to FreeBSD -- just qualifying the statement as it > > > stands. For the obvious comparison, Solaris versions have well- > > > published release and support periods, usually upwards of 8 years. > > > Obviously they have more resources to do this, I'm just pointing out > > > that the statement you made is incorrect as stated. > > > > > > > and I'm not sure you could do it differently -- no one plans to ship > > > > a lemon, but once in a while you discover that things don't go as > > > > planned. > > > > > > > > > I am amazed at the preposterously large elephant in the room that none > > > of you are willing to address. Watching each of you dance around it > > > would be terribly funny if it didn't affect my job so badly. (and if > > > I wasn't going to have to bail on FreeBSD and go to some crap form of > > > Linux because the FreeBSD developers appear to be unwilling to > > > consider the idea of getting more help) > > > > You seem to be *demanding* quite a lot lately. > > Jo has a point, though. I'm certain he's looked at the situation from > the developers' point of view, and in response, I'd recommend others > try to look at it from his, even if others consider it silly or > unreasonable. > > It's a frustrating situation, and there's no snap-your-fingers-voila > solution for it, other than extending support lifetimes per release. Indeed, there is no easy solution. Extending support lifetime takes more resources of course. Wilko From fjwcash at gmail.com Thu Sep 18 15:21:44 2008 From: fjwcash at gmail.com (Freddie Cash) Date: Thu Sep 18 15:21:51 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> Message-ID: <200809180821.32188.fjwcash@gmail.com> Maybe I'm missing something here, but it seems like Jo just wants to argue for the sake of arguing. First Jo wrote: >No other answer. ?But nobody has yet provided what the EoL period is ? >going to be. ?I have no problems with a period being extended ;-) ?But ? >the business needs to know the minimum EoL for a given release to ? >determine if upgrading to that release is viable. To which Robert Watson replied, giving the minimums asked for: >Well, a starting answer is the policy found on >http://security.FreeBSD.org/: >Early adopter >? ?Releases which are published from the -CURRENT branch will be >? ?supported by >? ?the Security Officer for a minimum of 6 months after the release. > >Normal >? ?Releases which are published from a -STABLE branch will be supported >? ?by the?Security Officer for a minimum of 12 months after the release. > >Extended >? ?Selected releases will be supported by the Security Officer for a >? ?minimum of?24 months after the release. And yet Jo completely ignored that, and focused in on something completely unrelated: > I am amazed at the preposterously large elephant in the room that none > of you are willing to address. Watching each of you dance around it > would be terribly funny if it didn't affect my job so badly. (and if > I wasn't going to have to bail on FreeBSD and go to some crap form of > Linux because the FreeBSD developers appear to be unwilling to > consider the idea of getting more help) Jo: You know the minimum support period for each release, before it is released. You know what the earliest EoL time will be for each release as it is released. What more do you want? -- Freddie Cash fjwcash@gmail.com From oleg at opentransfer.com Thu Sep 18 15:55:46 2008 From: oleg at opentransfer.com (Oleg V. Nauman) Date: Thu Sep 18 15:55:53 2008 Subject: RELENG_7: something is very wrong with UDP? Message-ID: <20080918180543.pt7s2zmaio48ww8g@webmail.opentransfer.com> It seems to be something is very wrong with UDP on latest RELENG_7 Well some symptoms I have seen today when I was trying to boot newly compiled RELENG_7 on my laptop: a) rc scripts indefinitely waiting on logger to be completed during the boot ( devd and ifconfig are good examples) b) Sporadic DNS request failures c) traceroute prints 0.00 like response time for every host d) was unable to reboot my laptop performing shutdown -r ( due to logger/syslog related issues I think) e ) I was unable to start X session ( it seems to be freezes laptop because I was unable to switch to another virtual console even) csup "backout" to date=2008.09.15.12.00.00 and recompiling the kernel fixes this issue for me. Is anybody experiencing the same issues with fresh RELENG_7? Unsure it is my local issues though From a134qaed at gmail.com Thu Sep 18 16:12:16 2008 From: a134qaed at gmail.com (Dylan Cochran) Date: Thu Sep 18 16:12:47 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> Message-ID: On Thu, Sep 18, 2008 at 12:25 AM, Jo Rhett wrote: > I understand what you mean, but the statement is blatantly false as stated. > Anyone selling software to the US Government *must* specify (or meet, > depending) a minimum support period, and must also specify a cost the agency > can pay to extend the support period. > > Not relevant to FreeBSD -- just qualifying the statement as it stands. For > the obvious comparison, Solaris versions have well-published release and > support periods, usually upwards of 8 years. Obviously they have more > resources to do this, I'm just pointing out that the statement you made is > incorrect as stated. > >> and I'm not sure you could do it differently -- no one plans to ship a >> lemon, but once in a while you discover that things don't go as planned. > > > I am amazed at the preposterously large elephant in the room that none of > you are willing to address. Watching each of you dance around it would be > terribly funny if it didn't affect my job so badly. (and if I wasn't going > to have to bail on FreeBSD and go to some crap form of Linux because the > FreeBSD developers appear to be unwilling to consider the idea of getting > more help) My opinion on this matter may be considered radical, but I do think it should be at least recorded, if not impartially considered. While this problem can't be solved just by extending time with the hope that the resources will be allocated (no offense to your character, but that promise is made by a lot of people, and it doesn't always work out that way; particularly in environments with ingrained and blind politics where the money flows can change based on pride and/or sheer ignorance), it may be advantageous to treat the root causes. One of the biggest (and most prominent, though not obviously so) issues is the lack of concurrency with regards to releases. With the default system, having multiple freebsd releases side by side (both different versions, and different architectures) is infeasible. This makes the choice more critical, while hindering flexibility. The necessity of long support schedules is one of the symptoms. The fact that you have to choose, and then to change the choice you must clean up, back up, and create a new environment in order to test on a different release/architecture (release in this context includes kernel, a chroot is incomplete for testing), has two major effects: it hinders users from being able to selectively test newer releases with their software stack/hardware selection, with no adverse (within reason; obviously bugs like disk corruption will still happen) changes that will prevent them from reverting. While it may not please the accountants, cleaning up the namespace and allowing safe concurrency of releases will increase the /legitmate/ feasibility of using FreeBSD on a large scale. Oh, I forgot to mention, this is far from a pipe dream. I have a working environment with this capability, and I use it whenever I am able. This isn't to say it is the only cause, it is one of many, and I would never even claim it was a magic bullet. But it is my opinion that this problem is best solved not by arguing how to work around the symptoms, but to analyze and solve the parent problems that may not be so obvious. There's my two cents on the matter. From olli at lurza.secnetix.de Thu Sep 18 16:18:48 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Sep 18 16:18:55 2008 Subject: floppy disk controller broken In-Reply-To: <20080918075306.GA30709@lpthe.jussieu.fr> Message-ID: <200809181618.m8IGIj2P050390@lurza.secnetix.de> Michel Talon wrote: > John Baldwin wrote: > > It looks like the ioctl to format a track used to never report failures from > > the controller. The newer driver does. What I've done with fdformat is to > > make it just ignore the errors in userland instead. Try this: > > > > Index: fdformat.c > > =================================================================== > > --- fdformat.c (revision 183112) > > +++ fdformat.c (working copy) > > @@ -75,8 +75,7 @@ > > f.fd_formb_secno(i) = il[i+1]; > > f.fd_formb_secsize(i) = secsize; > > } > > - if(ioctl(fd, FD_FORM, (caddr_t)&f) < 0) > > - err(EX_OSERR, "ioctl(FD_FORM)"); > > + (void)ioctl(fd, FD_FORM, (caddr_t)&f); > > } > > > > static int > > This doesn't work any more. This time i get > niobe# fdformat fd0 > Format 1440K floppy `/dev/fd0'? (y/n): y > Processing EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE done. > > where only the first E takes some time to be printed, and all subsequent > ones are printed instantaneously, that is all other formatting is not > tried. In principle the formatting process must try each of the > "sectors" in turn, and can come up with a series of V and F. > > Moreover, trying to write to the floppy: > niobe# dd if=/dev/zero of=/dev/fd0 conv=noerror > dd: /dev/fd0: Input/output error > 5+0 records in > 4+0 records out > 2048 bytes transferred in 4.054404 secs (505 bytes/sec) > > I don't expect such result. Traditionnally writing works, while reading > may fail. Maybe I misunderstand what you're saying, but ... When I try to write to a floppy that has *not* been successfully formatted, I very much expect to get Input/output error. Anything else would be a bug. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The most important decision in [programming] language design concerns what is to be left out." -- Niklaus Wirth From talon at lpthe.jussieu.fr Thu Sep 18 18:33:00 2008 From: talon at lpthe.jussieu.fr (Michel Talon) Date: Thu Sep 18 18:33:14 2008 Subject: floppy disk controller broken In-Reply-To: <200809181618.m8IGIj2P050390@lurza.secnetix.de> References: <20080918075306.GA30709@lpthe.jussieu.fr> <200809181618.m8IGIj2P050390@lurza.secnetix.de> Message-ID: <20080918183250.GA48347@lpthe.jussieu.fr> On Thu, Sep 18, 2008 at 06:18:45PM +0200, Oliver Fromme wrote: > Michel Talon wrote: > > John Baldwin wrote: > > > It looks like the ioctl to format a track used to never report failures from > > > the controller. The newer driver does. What I've done with fdformat is to > > > make it just ignore the errors in userland instead. Try this: > > > > > > Index: fdformat.c > > > =================================================================== > > > --- fdformat.c (revision 183112) > > > +++ fdformat.c (working copy) > > > @@ -75,8 +75,7 @@ > > > f.fd_formb_secno(i) = il[i+1]; > > > f.fd_formb_secsize(i) = secsize; > > > } > > > - if(ioctl(fd, FD_FORM, (caddr_t)&f) < 0) > > > - err(EX_OSERR, "ioctl(FD_FORM)"); > > > + (void)ioctl(fd, FD_FORM, (caddr_t)&f); > > > } > > > > > > static int > > > > This doesn't work any more. This time i get > > niobe# fdformat fd0 > > Format 1440K floppy `/dev/fd0'? (y/n): y > > Processing EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE done. > > > > where only the first E takes some time to be printed, and all subsequent > > ones are printed instantaneously, that is all other formatting is not > > tried. In principle the formatting process must try each of the > > "sectors" in turn, and can come up with a series of V and F. > > > > Moreover, trying to write to the floppy: > > niobe# dd if=/dev/zero of=/dev/fd0 conv=noerror > > dd: /dev/fd0: Input/output error > > 5+0 records in > > 4+0 records out > > 2048 bytes transferred in 4.054404 secs (505 bytes/sec) > > > > I don't expect such result. Traditionnally writing works, while reading > > may fail. > > Maybe I misunderstand what you're saying, but ... > When I try to write to a floppy that has *not* been > successfully formatted, I very much expect to get > Input/output error. Anything else would be a bug. > > Best regards > Oliver The floppy has certainly be formatted, in the past. Perhaps i remember badly, i have not used floppies since years, but in this case the behavior with Windows, Linux and ancient FreeBSD was that you could write to the floppy, but could encounter errors while reading. Using dd conv=noerror allowed to recover the valid part. Under Windows you could very well use floppies partly damaged with bad blocks or tracks. Here the driver seems to bail out at the first error, so that the above commands run much faster than they should, a few seconds, while something of the order of a minute should be more realistic. -- Michel TALON From koitsu at FreeBSD.org Thu Sep 18 18:48:31 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 18 18:48:38 2008 Subject: floppy disk controller broken In-Reply-To: <20080918183250.GA48347@lpthe.jussieu.fr> References: <20080918075306.GA30709@lpthe.jussieu.fr> <200809181618.m8IGIj2P050390@lurza.secnetix.de> <20080918183250.GA48347@lpthe.jussieu.fr> Message-ID: <20080918184828.GA25072@icarus.home.lan> On Thu, Sep 18, 2008 at 08:32:50PM +0200, Michel Talon wrote: > On Thu, Sep 18, 2008 at 06:18:45PM +0200, Oliver Fromme wrote: > > Michel Talon wrote: > > > John Baldwin wrote: > > > > It looks like the ioctl to format a track used to never report failures from > > > > the controller. The newer driver does. What I've done with fdformat is to > > > > make it just ignore the errors in userland instead. Try this: > > > > > > > > Index: fdformat.c > > > > =================================================================== > > > > --- fdformat.c (revision 183112) > > > > +++ fdformat.c (working copy) > > > > @@ -75,8 +75,7 @@ > > > > f.fd_formb_secno(i) = il[i+1]; > > > > f.fd_formb_secsize(i) = secsize; > > > > } > > > > - if(ioctl(fd, FD_FORM, (caddr_t)&f) < 0) > > > > - err(EX_OSERR, "ioctl(FD_FORM)"); > > > > + (void)ioctl(fd, FD_FORM, (caddr_t)&f); > > > > } > > > > > > > > static int > > > > > > This doesn't work any more. This time i get > > > niobe# fdformat fd0 > > > Format 1440K floppy `/dev/fd0'? (y/n): y > > > Processing EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE done. > > > > > > where only the first E takes some time to be printed, and all subsequent > > > ones are printed instantaneously, that is all other formatting is not > > > tried. In principle the formatting process must try each of the > > > "sectors" in turn, and can come up with a series of V and F. > > > > > > Moreover, trying to write to the floppy: > > > niobe# dd if=/dev/zero of=/dev/fd0 conv=noerror > > > dd: /dev/fd0: Input/output error > > > 5+0 records in > > > 4+0 records out > > > 2048 bytes transferred in 4.054404 secs (505 bytes/sec) > > > > > > I don't expect such result. Traditionnally writing works, while reading > > > may fail. > > > > Maybe I misunderstand what you're saying, but ... > > When I try to write to a floppy that has *not* been > > successfully formatted, I very much expect to get > > Input/output error. Anything else would be a bug. > > > > Best regards > > Oliver > > The floppy has certainly be formatted, in the past. Perhaps i > remember badly, i have not used floppies since years, but > in this case the behavior with Windows, Linux and ancient FreeBSD > was that you could write to the floppy, but could encounter errors > while reading. Using dd conv=noerror allowed to recover the valid part. > Under Windows you could very well use floppies partly damaged with > bad blocks or tracks. Here the driver seems to bail out at the first > error, so that the above commands run much faster than they should, > a few seconds, while something of the order of a minute should be > more realistic. I swore in older FreeBSD (2.x days?) there was a command which was actually used for dealing with bad sectors on floppy disks. I might be thinking of badsect(8), can't remember... -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jrhett at netconsonance.com Thu Sep 18 18:58:38 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Sep 18 18:58:44 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <20080918124608.GK91598@freebie.xs4all.nl> References: <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <20080918124608.GK91598@freebie.xs4all.nl> Message-ID: <2FDF3E2C-7344-4F70-BF71-4643E0E4DDD7@netconsonance.com> On Sep 18, 2008, at 5:46 AM, Wilko Bulte wrote: > You seem to be *demanding* quite a lot lately. I have demanded nothing. I have made a suggestion or two -- presented the background which pretty much everyone agrees with, made some suggestions about how to improve it. My last post was expressing amusement about watching every developer dance around the topic, skipping over the relevant part -- how do we improve things? We could improve things. We could get more resources. Why not consider the topic? That's not demanding. Check your dictionary. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From rwatson at FreeBSD.org Thu Sep 18 19:01:58 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Sep 18 19:02:05 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> Message-ID: On Wed, 17 Sep 2008, Jo Rhett wrote: > Please stop avoiding even considering what people are offering to you. So far, this conversation has largely consisted of you telling us that you don't like what we're doing and demanding that we change. Let's consider three more productive avenues by which you can offer assistance with the problem of how to increase branch support lifetimes: (1) Become a contributor to the community by developing and maintaining patches against unsupported branches, especially against older releases such as 4.x and 5.x where the branches are open for commits but have fallen out of support status. I can't promise the results will immediately fall into the official project "umbrella", but consider Colin Percival's freebsd-update as an example of what can be accomplished by someone outside the project when they find a niche. What started out as an external software project (freebsd-update) is now a core system update tool, and Colin has gone from being a random guy with some code to our security officer. (2) Become a contributor to the community by identifying members of the existing developer team for whom additional funding would enable them to spend more time working on and supporting FreeBSD and providing that funding. Consider approaching the FreeBSD Foundation formally to seek matching grant funding for the project. (3) Become a contributor to the community by working with an existing or new company that provides support for FreeBSD commercially, and discussing with them ways that they could provide support for branches past their official EoL date for the project. Companies like FreeBSD Mall have strong relationships with the project, and in the past have contributed significantly to efforts such as release engineering. It's not hard to imagine a company along those lines using something along th elines of a support subscription to fund community-centered support for branches. And those companies may be able to help you identify developers who can do the work, as well as play an active role in seeking further customers with similar interests. Robert N M Watson Computer Laboratory University of Cambridge From jrhett at netconsonance.com Thu Sep 18 19:03:45 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Sep 18 19:03:53 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <20080918133211.GL91598@freebie.xs4all.nl> References: <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <20080918124608.GK91598@freebie.xs4all.nl> <20080918131840.GA18595@icarus.home.lan> <20080918133211.GL91598@freebie.xs4all.nl> Message-ID: On Sep 18, 2008, at 6:32 AM, Wilko Bulte wrote: > Indeed, there is no easy solution. Extending support lifetime takes > more > resources of course. And my e-mails have always discussed ways to get more resources. Recently we even had a group of people trying to arrange for more explicit corporate support for testing and release process. For some reason unclear to me, not a single developer has stepped up and said "Great. Here's how we could use you..." The entire concept of getting *more resources* is the elephant in the room that everyone seems intent to avoid considering. Maybe, just maybe, there is some reason why FreeBSD doesn't want more people helping. Or ... something. I haven't the vaguest clue. If there is some reason why getting paid people to work on testing and release cycle is a bad idea, would someone please stand up and explain? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 18 19:09:13 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Sep 18 19:09:20 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <200809180821.32188.fjwcash@gmail.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <200809180821.32188.fjwcash@gmail.com> Message-ID: <2EF98B3E-F245-42B7-B94C-3DB26047C4D8@netconsonance.com> On Sep 18, 2008, at 8:21 AM, Freddie Cash wrote: > Maybe I'm missing something here, but it seems like Jo just wants to > argue > for the sake of arguing. You are missing a lot. You're not reading even half of what I am saying. re: ignored. I don't ignore anything. If something is answered clearly I tend to address topics which aren't resolved. But the section you quoted is your worst example -- If you look at my reply, you'll notice that not only did I not ignore it, I replied to that section with concerns about fluctuating schedules that this document presents. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From rwatson at FreeBSD.org Thu Sep 18 19:13:59 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Sep 18 19:14:05 2008 Subject: RELENG_7: something is very wrong with UDP? In-Reply-To: <20080918180543.pt7s2zmaio48ww8g@webmail.opentransfer.com> References: <20080918180543.pt7s2zmaio48ww8g@webmail.opentransfer.com> Message-ID: On Thu, 18 Sep 2008, Oleg V. Nauman wrote: > It seems to be something is very wrong with UDP on latest RELENG_7 > > Well some symptoms I have seen today when I was trying to boot newly > compiled RELENG_7 on my laptop: > > a) rc scripts indefinitely waiting on logger to be completed during the boot > ( devd and ifconfig are good examples) If you hit "ctrl-t" while these are waiting, what is the output? > b) Sporadic DNS request failures I don't know what your comfortable level with debugging tools is, but if you're happy using tcpdump, etc, I think I'd recommend diagnosing this directly that way. I'd probably do something like this: (1) Start by deleting all but one nameserver entry in /etc/resolv.conf. Confirm that you can still reproduce the problem. (2) Use dig(1) and tcpdump(1) to watch wire-level DNS behavior -- do you see queries go out? Do you see replies come back? Is dig "waking up" and seeing the replies when they arrive, or is there a delay or hang in dig? If dig hangs, what does ctrl-t show the sleep state (wmesg) is? Could you also use procstat -k on the dig process to generate a kernel stack trace for it? > c) traceroute prints 0.00 like response time for every host > > d) was unable to reboot my laptop performing shutdown -r ( due to > logger/syslog related issues I think) Could you try killing syslogd by hand and see if it dies? If not, can you use procstat -kk to generate a stack trace for it? > e ) I was unable to start X session ( it seems to be freezes laptop because > I was unable to switch to another virtual console even) > > csup "backout" to date=2008.09.15.12.00.00 and recompiling the kernel fixes > this issue for me. This is approximately the date of my last UDP MFC. Could you try backing out just src/sys/netinet6/udp6_usrreq.c revision 1.81.2.7 and see if that helps? (specifically, restore the use of sosend_generic instead of sosend_dgram) Could you confirm that either you're not using any kernel modules from ports, or that if you are, you have recompiled them with your most recent update? Could you try compiling your kernel with WITNESS to see if we get any extended debugging information? > Is anybody experiencing the same issues with fresh RELENG_7? Unsure it is my > local issues though I'm not experiencing them, but these sorts of things can be quite subtle and workload-dependent. Robert N M Watson Computer Laboratory University of Cambridge From jrhett at netconsonance.com Thu Sep 18 19:15:33 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Sep 18 19:15:40 2008 Subject: Upcoming Releases Schedule... In-Reply-To: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> Message-ID: <12944D4C-5243-4EC7-8E1A-04A7735B5AEA@netconsonance.com> First, thanks for taking the question seriously ;-) On Sep 18, 2008, at 8:47 AM, Dylan Cochran wrote: > problem can't be solved just by extending time with the hope that the > resources will be allocated (no offense to your character, but that No offense taken. I would never suggest we do anything based on hope. In my company's specific case, we'd want to work out the details of exactly how much time we'd commit and what our goal was in committing that time. (besides the obvious "giving back to the community part" which we do anyway) Most of the people that I know personally who are interested in this topic are in similar situations. They would want to discuss the necessary resources to achieve a specific goal, and make specific commitments on the amount of time they could give. I seriously don't know anyone who wanders into any situation saying "oh, maybe if I help out the tooth fairy will visit me!" ;-) That said, I know little about the multi-architecture problems you present here so I can't offer much other commentary, other than: > problem is best solved not by arguing how to work around the symptoms, > but to analyze and solve the parent problems that may not be so > obvious. I suspect this above statement applies to every problem the release and testing teams have. What is necessary to get consensus to even discuss the issues involved? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From koitsu at FreeBSD.org Thu Sep 18 19:18:24 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 18 19:18:35 2008 Subject: RELENG_7: something is very wrong with UDP? In-Reply-To: <20080918180543.pt7s2zmaio48ww8g@webmail.opentransfer.com> References: <20080918180543.pt7s2zmaio48ww8g@webmail.opentransfer.com> Message-ID: <20080918191822.GA25698@icarus.home.lan> On Thu, Sep 18, 2008 at 06:05:43PM +0300, Oleg V. Nauman wrote: > c) traceroute prints 0.00 like response time for every host Interesting, since traceroute bases the RTT on the amount of time it takes between the initial packet sent (see below) and the time it receives the ICMP port unreachable response. Yes, I am fully aware traceroute uses UDP as the default protocol to induce said ICMP. That said, does the erroneous behaviour go away when using -P tcp? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From rwatson at FreeBSD.org Thu Sep 18 19:22:10 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Sep 18 19:22:17 2008 Subject: Upcoming Releases Schedule... In-Reply-To: References: <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <20080918124608.GK91598@freebie.xs4all.nl> <20080918131840.GA18595@icarus.home.lan> <20080918133211.GL91598@freebie.xs4all.nl> Message-ID: On Thu, 18 Sep 2008, Jo Rhett wrote: > On Sep 18, 2008, at 6:32 AM, Wilko Bulte wrote: >> Indeed, there is no easy solution. Extending support lifetime takes more >> resources of course. > > And my e-mails have always discussed ways to get more resources. Recently > we even had a group of people trying to arrange for more explicit corporate > support for testing and release process. For some reason unclear to me, not > a single developer has stepped up and said "Great. Here's how we could use > you..." The entire concept of getting *more resources* is the elephant in > the room that everyone seems intent to avoid considering. No, we're just waiting for you to go ahead and do it. > Maybe, just maybe, there is some reason why FreeBSD doesn't want more people > helping. Or ... something. I haven't the vaguest clue. If there is some > reason why getting paid people to work on testing and release cycle is a bad > idea, would someone please stand up and explain? No, we'd love it if more people were paid to work on things like this, but there are two practical problems: (1) finding people, and (2) paying them. All of us are busy people -- we have jobs, we have houses with mortgages, etc, and those of us who are already spending a lot of time on FreeBSD are probably pretty maxed out without adding more to our plates. You seem to have a lot of energy to burn sending e-mail about how to improve the world, and I think what the rest of us would like to see is that energy get turned to the more practical part of the problem. If you are literally standing there with money that you can't figure out how to spend, contact the FreeBSD Foundation Board with a specific proposal regarding the amount of money and what you're trying to accomplish. Perhaps we can help you identify people who would take the money, companies that might want to be involved, help provide some matching funding, etc. However, it needs to be at least a strawman concrete proposal, because waving hands only gets you so far. And it has to be something worth taking time away from all the other things busy people get up to in life, such as optimizing network stacks, fixing file system bugs, supporting releases, etc, or the endeavour has hurt rather than helped. Robert N M Watson Computer Laboratory University of Cambridge From jrhett at netconsonance.com Thu Sep 18 19:24:53 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Sep 18 19:25:00 2008 Subject: Upcoming Releases Schedule... In-Reply-To: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> Message-ID: <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> On Sep 18, 2008, at 12:01 PM, Robert Watson wrote: > So far, this conversation has largely consisted of you telling us > that you don't like what we're doing and demanding that we change. I'm not sure what is going on in your life to make you so defensive that someone saying "I have resources, I can help. Here's the problem I'd like to address" makes you think they are "demanding". Nobody is "demanding" anything (that I have seen in this conversation). Take a deep breath, stop taking this personal - which I assume you are when you talk about "demanding" and let's talk about this. Most of the rest of your post is valid. > Let's consider three more productive avenues by which you can offer > assistance with the problem of how to increase branch support > lifetimes: > > (1) Become a contributor to the community by developing and > maintaining > patches against unsupported branches, especially against older > releases > such as 4.x and 5.x where the branches are open for commits but > have > fallen out of support status. I can't promise the results will We have no 4.x or 5.x systems nor do we have any interest in maintaining those. So perhaps a good idea, but not something I can help with. I *did* offer to work on maintenance for 6.2, but was told it would be rejected by the developers. Would I extend effort to do exactly what I am talking about -- extending the support lifetime for very recent releases? Absolutely. If its in a form useful for the community as a whole. If I have to do this on my own (what we are doing internally now) then the FreeBSD community leverages nothing from the effort, and we're not changing the resources limitations at all. > (2) Become a contributor to the community by identifying members of > the > existing developer team for whom additional funding would enable > them to > spend more time working on and supporting FreeBSD and providing > that > funding. Consider approaching the FreeBSD Foundation formally to > seek > matching grant funding for the project. We have funded projects, we continue to fund projects. Most of our funding right now is aimed at people who don't have the time to work on it, money or no. But again, funding does not improve the resources problem in most cases. Many $EMPLOYERs find it easier to have an employee allocate 10-20% of their work to a project than to get cash allocations for the same. > (3) Become a contributor to the community by working with an > existing or new > company that provides support for FreeBSD commercially, and > discussing Nobody who does FreeBSD support on a paid basis can generally solve the kind of problems we find. I have tried these kind of things in the past with both FreeBSD and Linux, and in every case I was significantly better at finding/fixing/patching bugs than anyone on the team. The ones I could not address (usually device driver issues) the support team could do nothing more than forward a bug report to the developer. And in general, they were less good at including relevant details and debug output than I was. In short, it's a non-op. > official EoL date for the project. Companies like FreeBSD Mall > have > strong relationships with the project, and in the past have > contributed > significantly to efforts such as release engineering. It's not > hard to > imagine a company along those lines using something along th > elines of a Robert, here we go again. You have given several options, not a single one of which will provide more resources to the release team. The only thing you've successfully done is given me three different ways to eff off and leave you alone. Apparently, more resources is not in your interest. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From mike at sentex.net Thu Sep 18 19:25:54 2008 From: mike at sentex.net (Mike Tancsa) Date: Thu Sep 18 19:26:01 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <12944D4C-5243-4EC7-8E1A-04A7735B5AEA@netconsonance.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <12944D4C-5243-4EC7-8E1A-04A7735B5AEA@netconsonance.com> Message-ID: <200809181925.m8IJPo3Z053187@lava.sentex.ca> At 03:11 PM 9/18/2008, Jo Rhett wrote: >committing that time. (besides the obvious "giving back to the >community part" which we do anyway) I am not familiar with your company nor any developers that work for you. Perhaps you could elaborate on how you have contributed to FreeBSD ? ---Mike From jrhett at netconsonance.com Thu Sep 18 19:36:13 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Sep 18 19:36:36 2008 Subject: Upcoming Releases Schedule... In-Reply-To: References: <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <20080918124608.GK91598@freebie.xs4all.nl> <20080918131840.GA18595@icarus.home.lan> <20080918133211.GL91598@freebie.xs4all.nl> Message-ID: <5A9175CD-9D13-4A8D-BFE9-27C749FF8F5C@netconsonance.com> > On Thu, 18 Sep 2008, Jo Rhett wrote: >> And my e-mails have always discussed ways to get more resources. >> Recently we even had a group of people trying to arrange for more >> explicit corporate support for testing and release process. For >> some reason unclear to me, not a single developer has stepped up >> and said "Great. Here's how we could use you..." The entire >> concept of getting *more resources* is the elephant in the room >> that everyone seems intent to avoid considering. On Sep 18, 2008, at 12:22 PM, Robert Watson wrote: > No, we're just waiting for you to go ahead and do it. Um, how? I suspect you're being sarcastic, but I'll take this at straight value. I have repeatedly said "I could commit X resources, and I know others who are likewise willing to make a proposal for the same with their employer, if our efforts could help improve Y problem." Not a single person, *not one*, has ever taken the proposal seriously enough to sit down and discuss with me what kind of resources are necessary to solve this problem. Seriously, go back and read every reply to me on this or the other thread. Every one says "We aren't going to do it." > No, we'd love it if more people were paid to work on things like > this, but there are two practical problems: (1) finding people, and > (2) paying them. At the moment I will only speak for myself, so let's start there. I write code. I do integration and testing for a living. I currently maintain a number of ports, including cfengine -- which I personally added the PKGMGR code to for FreeBSD support. My employer is paying my salary, and is willing to dedicate some of my time to the FreeBSD project as a whole. (already does in fact, on the table is to increase that amount) (1) you've found me and (2) I'm already being paid. There are others in the same situation. > All of us are busy people -- we have jobs, we have houses with > mortgages, etc, and those of us who are already spending a lot of > time on FreeBSD are probably pretty maxed out without adding more to > our plates. You seem to have a lot of energy to burn sending e-mail > about how to improve the world, and I think what the rest of us > would like to see is that energy get turned to the more practical > part of the problem. As would I. If we could focus on how to improve the situation which has been very well described, we'd be doing something. I don't think you have any idea how frustrating it has been -- I'm here. I'm ready to help. We need to determine how to do this... and nobody will even discuss the problems with me. (if this was a port or a single component then I'd just go run away and do it myself. But the release process is obviously much more complex and I couldn't possibly replicate it or extend it in any fashion from the outside) > If you are literally standing there with money that you can't figure > out how to spend, contact the FreeBSD Foundation Board with a > specific proposal regarding the amount of money and what you're > trying to accomplish. Perhaps we can help you identify people who > would take the money, companies that might want to be involved, help > provide some matching funding, etc. However, it needs to be at > least a strawman concrete proposal, because waving hands only gets > you so far. And it has to be something worth taking time away from > all the other things busy people get up to in life, such as > optimizing network stacks, fixing file system bugs, supporting > releases, etc, or the endeavour has hurt rather than helped. From our experience, there is a lot more money than there is people's time to address the problem. (as you note above and in the final sentence here) I'm trying to offer something -- more people, already paid, to provide more assistance. But since this involves the release process, we'd have to be integrated into the effort to be useful. FYI: this message is the first I've seen that is going somewhere good. I hope you'll take what I am saying seriously. I'm going to stop replying to many of the other subthreads because they aren't going anywhere good, and I'm probably replying too often anyway. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 18 19:40:46 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Sep 18 19:40:53 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <200809181925.m8IJPo3Z053187@lava.sentex.ca> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <12944D4C-5243-4EC7-8E1A-04A7735B5AEA@netconsonance.com> <200809181925.m8IJPo3Z053187@lava.sentex.ca> Message-ID: <40E3236C-CAF7-406D-835F-948954F67D51@netconsonance.com> On Sep 18, 2008, at 12:25 PM, Mike Tancsa wrote: > I am not familiar with your company nor any developers that work for > you. Perhaps you could elaborate on how you have contributed to > FreeBSD ? This domain is my vanity domain, actually. Well not vanity but the domain I use on the rare occasions when I do paid work for other companies. (used to be a lot more, is significantly less now) And no developers work for me. When I sold out my contract got an explicit "no head count" ;-) I likey ;-) In my $EMPLOYER the main proposal would be to dedicate more of my time. The others contribute at random, but I don't see that changing much due to their existing commitments. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From mike at sentex.net Thu Sep 18 19:46:18 2008 From: mike at sentex.net (Mike Tancsa) Date: Thu Sep 18 19:46:25 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <40E3236C-CAF7-406D-835F-948954F67D51@netconsonance.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <12944D4C-5243-4EC7-8E1A-04A7735B5AEA@netconsonance.com> <200809181925.m8IJPo3Z053187@lava.sentex.ca> <40E3236C-CAF7-406D-835F-948954F67D51@netconsonance.com> Message-ID: <200809181946.m8IJkFDa053266@lava.sentex.ca> At 03:39 PM 9/18/2008, Jo Rhett wrote: >On Sep 18, 2008, at 12:25 PM, Mike Tancsa wrote: >>I am not familiar with your company nor any developers that work for >>you. Perhaps you could elaborate on how you have contributed to >>FreeBSD ? > > >In my $EMPLOYER the main proposal would be to dedicate more of my >time. The others contribute at random, but I don't see that changing >much due to their existing commitments. I am sorry, I meant, what have you contributed currently or in the past to FreeBSD ? i.e. what code, or money or physical resources (hardware) or time testing code ? ---Mike From dalroi at solfertje.student.utwente.nl Thu Sep 18 20:09:43 2008 From: dalroi at solfertje.student.utwente.nl (Alban Hertroys) Date: Thu Sep 18 20:09:50 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> Message-ID: On Sep 18, 2008, at 9:23 PM, Jo Rhett wrote: > On Sep 18, 2008, at 12:01 PM, Robert Watson wrote: >> Let's consider three more productive avenues by which you can >> offer assistance with the problem of how to increase branch >> support lifetimes: >> >> (1) Become a contributor to the community by developing and >> maintaining >> patches against unsupported branches, especially against older >> releases >> such as 4.x and 5.x where the branches are open for commits but >> have >> fallen out of support status. I can't promise the results will > > We have no 4.x or 5.x systems nor do we have any interest in > maintaining those. So perhaps a good idea, but not something I can > help with. > > I *did* offer to work on maintenance for 6.2, but was told it would > be rejected by the developers. Would I extend effort to do exactly > what I am talking about -- extending the support lifetime for very > recent releases? Absolutely. If its in a form useful for the > community as a whole. Are you seriously insisting that a minor release should be supported for more than a year? I think that's pretty exceptional already for any piece of software, and yet you want to extend that? I don't know what your line of work demands, but maybe you're not as constrained as you think you are? The support lifetime of FreeBSD 6 (the major release) is estimated to be up to somewhere in 2010, according to the release information, which seems to satisfy your needs. To me this is a rhetorical question only, I have no way to apply any answers I get to these questions. I'm not involved in the FreeBSD project or in your line of work, I'm just a humble user and supporter. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:74,48d2afa510139919116692! From jrhett at netconsonance.com Thu Sep 18 20:14:17 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Sep 18 20:14:25 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <200809181946.m8IJkFDa053266@lava.sentex.ca> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <12944D4C-5243-4EC7-8E1A-04A7735B5AEA@netconsonance.com> <200809181925.m8IJPo3Z053187@lava.sentex.ca> <40E3236C-CAF7-406D-835F-948954F67D51@netconsonance.com> <200809181946.m8IJkFDa053266@lava.sentex.ca> Message-ID: <9ECDD71F-D4EB-4846-AB12-40B123AE7E16@netconsonance.com> On Sep 18, 2008, at 12:46 PM, Mike Tancsa wrote: > I am sorry, I meant, what have you contributed currently or in the > past to FreeBSD ? i.e. what code, or money or physical resources > (hardware) or time testing code ? I do a lot of testing and patches regarding components we use. Search the PRs. I maintain several ports. I built freebsd package management into cfengine, and greatly extended the package management functionality above and beyond to support every operation freebsd can take on a package. We host numerous freebsd developers in our facility for nearly nothing. We pay for development of features that we need but don't have the appropriate skills to fix ourselves. We sponsor freebsd promotional activity, like the MeetBSD conference coming up this November. In short, we support FreeBSD in every way that I am aware of there is to support it. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From freebsd-stable-local at be-well.ilk.org Thu Sep 18 20:35:44 2008 From: freebsd-stable-local at be-well.ilk.org (Lowell Gilbert) Date: Thu Sep 18 20:35:51 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> (Jo Rhett's message of "Thu\, 18 Sep 2008 12\:23\:45 -0700") References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> Message-ID: <448wtpcikb.fsf@be-well.ilk.org> Jo Rhett writes: > We have no 4.x or 5.x systems nor do we have any interest in > maintaining those. So perhaps a good idea, but not something I can > help with. > > I *did* offer to work on maintenance for 6.2, but was told it would be > rejected by the developers. Would I extend effort to do exactly what > I am talking about -- extending the support lifetime for very recent > releases? Absolutely. If its in a form useful for the community as a > whole. > > If I have to do this on my own (what we are doing internally now) then > the FreeBSD community leverages nothing from the effort, and we're not > changing the resources limitations at all. I've kind of lost the drift, but it sounds to me as though Jo Rhett is tentatively offering to take on extended support for 6.2, but not earlier versions. Aside from programming skills, what would Jo need to bring to the table in order to provide that back to the project? Is that a reasonable statement of what's on discussion here? [Sorry for putting words into people's mouths, but I need a more concrete discussion in order to be sure I know what anybody actually means.] From mike at sentex.net Thu Sep 18 21:03:07 2008 From: mike at sentex.net (Mike Tancsa) Date: Thu Sep 18 21:03:18 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <9ECDD71F-D4EB-4846-AB12-40B123AE7E16@netconsonance.com> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <12944D4C-5243-4EC7-8E1A-04A7735B5AEA@netconsonance.com> <200809181925.m8IJPo3Z053187@lava.sentex.ca> <40E3236C-CAF7-406D-835F-948954F67D51@netconsonance.com> <200809181946.m8IJkFDa053266@lava.sentex.ca> <9ECDD71F-D4EB-4846-AB12-40B123AE7E16@netconsonance.com> Message-ID: <200809182103.m8IL34r2053611@lava.sentex.ca> At 04:13 PM 9/18/2008, Jo Rhett wrote: >On Sep 18, 2008, at 12:46 PM, Mike Tancsa wrote: >>I am sorry, I meant, what have you contributed currently or in the >>past to FreeBSD ? i.e. what code, or money or physical resources >>(hardware) or time testing code ? > > >I do a lot of testing and patches regarding components we use. Search >the PRs. I maintain several ports. I had a search and I see some PRs you have submitted, but I guess you commit under a different @freebsd.org email address ? > I built freebsd package >management into cfengine, and greatly extended the package management >functionality above and beyond to support every operation freebsd can >take on a package. > We host numerous freebsd developers in our >facility for nearly nothing. Thats most excellent! I think people would take your suggestions with greater gravity if you reminded them with a few URLs to point out the various commit messages that say, "sponsored by netconsonance" etc. Or perhaps a few of these numerous developers could speak up on your behalf? > We pay for development of features that >we need but don't have the appropriate skills to fix ourselves. That then went back into FreeBSD ? Can you give examples ? I ask all this as you really, really want things to change, and you say you have resources to offer, yet you seem to have alienated a LOT of people from previously similar threads (http://freebsd.monkey.org/freebsd-stable/200806/msg00037.html) You advocate that people not reject your offers of help and resources, yet at the same time respond to developers who actually do a LOT of work and were going to look at what you have to offer by way of bug reports that you are way too busy to oblige http://freebsd.monkey.org/freebsd-stable/200806/msg00069.html Perhaps if you posted some references to success stories you have had with the FreeBSD developer community at large, this would help make your case. ---Mike From rwatson at FreeBSD.org Thu Sep 18 21:07:32 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Sep 18 21:07:41 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <448wtpcikb.fsf@be-well.ilk.org> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> Message-ID: On Thu, 18 Sep 2008, Lowell Gilbert wrote: > Jo Rhett writes: > >> We have no 4.x or 5.x systems nor do we have any interest in maintaining >> those. So perhaps a good idea, but not something I can help with. >> >> I *did* offer to work on maintenance for 6.2, but was told it would be >> rejected by the developers. Would I extend effort to do exactly what I am >> talking about -- extending the support lifetime for very recent releases? >> Absolutely. If its in a form useful for the community as a whole. >> >> If I have to do this on my own (what we are doing internally now) then the >> FreeBSD community leverages nothing from the effort, and we're not changing >> the resources limitations at all. > > I've kind of lost the drift, but it sounds to me as though Jo Rhett is > tentatively offering to take on extended support for 6.2, but not earlier > versions. Aside from programming skills, what would Jo need to bring to the > table in order to provide that back to the project? Is that a reasonable > statement of what's on discussion here? > > [Sorry for putting words into people's mouths, but I need a more concrete > discussion in order to be sure I know what anybody actually means.] What Jo needs to do is what we expect from other participants in the project who want to take on positions of responsibility: build a long-term track record of contributions so that we can trust that when they agree to take on obligations (and we advertise those claims, be it by changing branch lifetimes, accepting WIP feature contributions, etc), they will be fulfilled. Developers offer to mentor new contributors and help shepherd their work when they see that the contributor both has a clear technical contribution to offer *and* that they build necessary rapport and confidence that the investment of time by the mentor is worthwhile. Everyone on this list is a busy person and values their time, and mentoring a developer is a highly non-trivial investment of time, and in most cases, it's a donation of personal time. It is potentially very rewarding, but a lot of work. Robert N M Watson Computer Laboratory University of Cambridge From koitsu at FreeBSD.org Thu Sep 18 21:27:09 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 18 21:27:18 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <200809182103.m8IL34r2053611@lava.sentex.ca> References: <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <12944D4C-5243-4EC7-8E1A-04A7735B5AEA@netconsonance.com> <200809181925.m8IJPo3Z053187@lava.sentex.ca> <40E3236C-CAF7-406D-835F-948954F67D51@netconsonance.com> <200809181946.m8IJkFDa053266@lava.sentex.ca> <9ECDD71F-D4EB-4846-AB12-40B123AE7E16@netconsonance.com> <200809182103.m8IL34r2053611@lava.sentex.ca> Message-ID: <20080918212707.GA27780@icarus.home.lan> On Thu, Sep 18, 2008 at 05:03:05PM -0400, Mike Tancsa wrote: > At 04:13 PM 9/18/2008, Jo Rhett wrote: >> On Sep 18, 2008, at 12:46 PM, Mike Tancsa wrote: >>> I am sorry, I meant, what have you contributed currently or in the >>> past to FreeBSD ? i.e. what code, or money or physical resources >>> (hardware) or time testing code ? >> >> >> I do a lot of testing and patches regarding components we use. Search >> the PRs. I maintain several ports. > > I had a search and I see some PRs you have submitted, but I guess you > commit under a different @freebsd.org email address ? I don't think Jo has a freebsd.org account or mail address. Netconsonance is more or less Jo's own personal/contracting thing, as I understand it, while one of his employers is SVColo (who you WILL see mentioned in commit messages). >> We pay for development of features that >> we need but don't have the appropriate skills to fix ourselves. > > That then went back into FreeBSD ? Can you give examples ? I ask > all this as you really, really want things to change, and you say you > have resources to offer, yet you seem to have alienated a LOT of people > from previously similar threads > (http://freebsd.monkey.org/freebsd-stable/200806/msg00037.html) > > You advocate that people not reject your offers of help and resources, > yet at the same time respond to developers who actually do a LOT of work > and were going to look at what you have to offer by way of bug reports > that you are way too busy to oblige > http://freebsd.monkey.org/freebsd-stable/200806/msg00069.html I'm sorry to see that this thread has reached the point where Jo's character has come into question. This path is too commonly taken within this community (read: BSD); the equivalent of doing burn-outs in a parking lot (lots of smoke, zero gain). If Jo's character is truly under scrutiny, be aware that I will stand up for him, as I've interacted with him professionally (read: at my day job, for network outages or other anomalies -- and no, my day job is unrelated to my signature). What surprises me is, sans Robert, everyone seems to be taking what Jo says as a form of flaming, borderline trolling. But in all my years (including on IRC, which should give you some insight to what my definition of "troll" is), I don't know of anyone who would spend this amount of effort and time discussing an issue at length if they did not have professional and/or personal interest in it. If Jo was just "stirring up the ants", this topic wouldn't keep coming up. Likewise, SVColo would not have donated money to meetBSD if they didn't care; and for SVColo to care, that means there's a professional reliance on something (in this case, FreeBSD). Jo is often that representative. I do not deny the mails are "heated", and express both frustration and concern, but I don't see anything insulting in them. Possibly this topic could be discussed amongst interested parties at meetBSD. I will be there, and would be more than happy to participate in such a discussion -- or at least take notes. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jrhett at netconsonance.com Thu Sep 18 21:41:36 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Sep 18 21:41:42 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <448wtpcikb.fsf@be-well.ilk.org> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> Message-ID: On Sep 18, 2008, at 1:20 PM, Lowell Gilbert wrote: > I've kind of lost the drift, but it sounds to me as though Jo Rhett is > tentatively offering to take on extended support for 6.2, but not > earlier versions. Aside from programming skills, what would Jo need > to bring to the table in order to provide that back to the project? > Is that a reasonable statement of what's on discussion here? > > [Sorry for putting words into people's mouths, but I need a more > concrete discussion in order to be sure I know what anybody actually > means.] Thank you. If you don't mind I'd prefer to widen the scope a touch because 6.2 will eventually go away, and frankly it is probably better to look forward than to resurrect an unsupported version. So I would probably state: Jo's $EMPLOYER has significant interest in longer support for -REL versions. Enough to fund my time supporting the mainstream project. What would Jo (or anyone else in a similar situation) need to bring to the table in order to provide back to the project? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From jrhett at netconsonance.com Thu Sep 18 21:48:18 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Sep 18 21:48:24 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <200809182103.m8IL34r2053611@lava.sentex.ca> References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <12944D4C-5243-4EC7-8E1A-04A7735B5AEA@netconsonance.com> <200809181925.m8IJPo3Z053187@lava.sentex.ca> <40E3236C-CAF7-406D-835F-948954F67D51@netconsonance.com> <200809181946.m8IJkFDa053266@lava.sentex.ca> <9ECDD71F-D4EB-4846-AB12-40B123AE7E16@netconsonance.com> <200809182103.m8IL34r2053611@lava.sentex.ca> Message-ID: On Sep 18, 2008, at 2:03 PM, Mike Tancsa wrote: > I had a search and I see some PRs you have submitted, but I guess > you commit under a different @freebsd.org email address ? I don't commit. I submit and others commit. This hasn't really been a handicap ;-) > Thats most excellent! I think people would take your suggestions > with greater gravity if you reminded them with a few URLs to point > out the various commit messages that say, "sponsored by > netconsonance" etc. Or perhaps a few of these numerous developers > could speak up on your behalf? Again, netconsonance is "Jo" and a few random others that contract via the company to avoid having to create their own company. The "We" in most of my discussions is my $EMPLOYER. And you can see their logos and name listed in numerous places. >> We pay for development of features that >> we need but don't have the appropriate skills to fix ourselves. > > That then went back into FreeBSD ? Can you give examples ? I > ask all this as you really, really want things to change, and you > say you have \ I'm sorry, but I have neither the time nor the interest in trying to provide a FreeBSD resume to someone. This is a tangent, and never in my experience has a tangent moved the original discussion forward. Are you in a position to make changes? What role in this do you have? What value is there answering these questions? (which have been answered many times if you google for them) I'd rather just drop this tangent. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From lambert at lambertfam.org Thu Sep 18 22:02:14 2008 From: lambert at lambertfam.org (Scott Lambert) Date: Thu Sep 18 22:02:22 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> References: <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> Message-ID: <20080918220213.GA94268@sysmon.tcworks.net> On Thu, Sep 18, 2008 at 12:23:45PM -0700, Jo Rhett wrote: > On Sep 18, 2008, at 12:01 PM, Robert Watson wrote: > > (1) Become a contributor to the community by developing and > > maintaining patches against unsupported branches, especially against > > older releases such as 4.x and 5.x where the branches are open for > > commits but have fallen out of support status. I can't promise the > > results will > > We have no 4.x or 5.x systems nor do we have any interest in > maintaining those. So perhaps a good idea, but not something I can > help with. > > I *did* offer to work on maintenance for 6.2, but was told it would be > rejected by the developers. Would I extend effort to do exactly what > I am talking about -- extending the support lifetime for very recent > releases? Absolutely. If its in a form useful for the community as a > whole. > > If I have to do this on my own (what we are doing internally now) then > the FreeBSD community leverages nothing from the effort, and we're not > changing the resources limitations at all. I don't have a dog in this fight. I'm just writing this message because it looks to me like there is a lot of talking past one another going on between people who are basically in violent agreement with one another. I am hoping that wording things differently will lead to understanding on both sides. I may have completely misinterpreted both sides. Spoken languages are too ambiguous. Here is the boiled down gist of my interpretation of a possible way to go forward with this; bad pseudo code: RESOURCES='Jo and the others he seems to know of who back port fixes to their production versions of "unsupported" versions of FreeBSD.' For i in "RELENG_X_Y" (where X_Y is not a currently "supported" version of FreeBSD); do grant maintenance commit access for $i to ${RESOURCES} done; Now for the code documentation: Maybe one of the ${RESOURCES} could build some web application whereby people could sign up to be a "community extended support" resource for RELENG_X_Y until $date_in_the_future. Perhaps a letter of commitment from ${RESOURCE}s ${EMPLOYER} would be required before accepting the candidate for work on RELENG_X_Y. Then the existing developers or core team could approve their application/access and provide a mentor if they aren't currently commiters. (This is some extra work for the existing people. But hopefully the rewards would be worth the minimal? effort.) Eventually, the mentor pool could be wholly from ${RESOURCES}. Much of the approval of new candidates would be from the same pool. The whole thing might have to be conditional on ${RESOURCES} bringing the necessary tinderbox type hardware to do basic QA on their extended support branches. With enough ${RESOURCES} signed up, they might be able to get hardware from ${DONORS} other than themselves. The ${RESOURCES} people could gang up on which RELENG_X_Ys they want to support. They can support them for as long as they have people on the team who are interested in supporting them. Presumably, these people would be working for companies which have made a commitment to use RELENG_X_Y for N years. In this way, the companies which are already paying their people to apply security fixes to old releases can donate the work which is already being done back to the project. Hopefully they will end up sharing the load so that they reap the benefits of work done by other companies which are paying people to do the same things. So long as the requirements for a back port to the ${RESOURCES} supported branches are the same as to an officially supported branch, there shouldn't be much chance of harm. Perhaps they are only allowed to back port fixes which have been approved for a supported RELENG_X_Y. Eventually, if enough ${RESOURCES} sign up, they might be able to release X.Y.z distribution media. If they only provide the media for CD/DVD purchase, the revenue might help to provide for QA tinderboxes for the ${RESOURCES} supported work. We might even end up with more people who are familiar with the release process and volunteer to work on RELENG_X_Y from initial release all the way through normal end of support and into the community extended support period. I think that would provide, as much as is possible, for the "don't make extra work for the existing developers" requirement as well as giving these resources a way to "put up or shut up." I could be wrong. -- Scott Lambert KC5MLE Unix SysAdmin lambert@lambertfam.org From wb at freebie.xs4all.nl Thu Sep 18 22:03:23 2008 From: wb at freebie.xs4all.nl (Wilko Bulte) Date: Thu Sep 18 22:03:35 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <2FDF3E2C-7344-4F70-BF71-4643E0E4DDD7@netconsonance.com> References: <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <20080918124608.GK91598@freebie.xs4all.nl> <2FDF3E2C-7344-4F70-BF71-4643E0E4DDD7@netconsonance.com> Message-ID: <20080918220252.GB2622@freebie.xs4all.nl> Quoting Jo Rhett, who wrote on Thu, Sep 18, 2008 at 11:58:00AM -0700 .. > On Sep 18, 2008, at 5:46 AM, Wilko Bulte wrote: > > You seem to be *demanding* quite a lot lately. > > > I have demanded nothing. I have made a suggestion or two -- presented > the background which pretty much everyone agrees with, made some > suggestions about how to improve it. > > My last post was expressing amusement about watching every developer > dance around the topic, skipping over the relevant part -- how do we > improve things? > We could improve things. We could get more resources. Why not > consider the topic? > > That's not demanding. Check your dictionary. I do not need a dictionary thank you very much. Wilko From jrhett at netconsonance.com Thu Sep 18 22:30:21 2008 From: jrhett at netconsonance.com (Jo Rhett) Date: Thu Sep 18 22:30:28 2008 Subject: Upcoming Releases Schedule... In-Reply-To: <20080918220213.GA94268@sysmon.tcworks.net> References: <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <20080918220213.GA94268@sysmon.tcworks.net> Message-ID: I agree with pretty much everything you've said here, with the obvious exception that I don't know what's involved in the release management process to do as you've said. Also for my own self, rather than resurrect 6.2 I'd personally rather focus on what we could do to extend the support period for 6.4. And other releases going forward. In particular, I'd like to highlight what you said here because you've said very clearly what I've been trying (apparently not so well) to say for some time now: > In this way, the companies which are already paying their people to > apply security fixes to old releases can donate the work which is > already being done back to the project. Hopefully they will end up > sharing the load so that they reap the benefits of work done by other > companies which are paying people to do the same things. Thanks. On Sep 18, 2008, at 3:02 PM, Scott Lambert wrote: > I don't have a dog in this fight. I'm just writing this message > because > it looks to me like there is a lot of talking past one another going > on > between people who are basically in violent agreement with one > another. > I am hoping that wording things differently will lead to understanding > on both sides. I may have completely misinterpreted both sides. > Spoken > languages are too ambiguous. > > Here is the boiled down gist of my interpretation of a possible way to > go forward with this; bad pseudo code: > > RESOURCES='Jo and the others he seems to know of who back port fixes > to > their production versions of "unsupported" versions of > FreeBSD.' > > For i in "RELENG_X_Y" (where X_Y is not a currently "supported" > version of FreeBSD); do > grant maintenance commit access for $i to ${RESOURCES} > done; > > Now for the code documentation: > > Maybe one of the ${RESOURCES} could build some web application whereby > people could sign up to be a "community extended support" resource for > RELENG_X_Y until $date_in_the_future. Perhaps a letter of commitment > from ${RESOURCE}s ${EMPLOYER} would be required before accepting the > candidate for work on RELENG_X_Y. > > Then the existing developers or core team could approve their > application/access and provide a mentor if they aren't currently > commiters. (This is some extra work for the existing people. But > hopefully the rewards would be worth the minimal? effort.) > > Eventually, the mentor pool could be wholly from ${RESOURCES}. Much > of the approval of new candidates would be from the same pool. The > whole thing might have to be conditional on ${RESOURCES} bringing the > necessary tinderbox type hardware to do basic QA on their extended > support branches. With enough ${RESOURCES} signed up, they might be > able to get hardware from ${DONORS} other than themselves. > > The ${RESOURCES} people could gang up on which RELENG_X_Ys they want > to > support. They can support them for as long as they have people on the > team who are interested in supporting them. Presumably, these people > would be working for companies which have made a commitment to use > RELENG_X_Y for N years. > > In this way, the companies which are already paying their people to > apply security fixes to old releases can donate the work which is > already being done back to the project. Hopefully they will end up > sharing the load so that they reap the benefits of work done by other > companies which are paying people to do the same things. > > So long as the requirements for a back port to the ${RESOURCES} > supported branches are the same as to an officially supported branch, > there shouldn't be much chance of harm. Perhaps they are only allowed > to back port fixes which have been approved for a supported > RELENG_X_Y. > > Eventually, if enough ${RESOURCES} sign up, they might be able to > release X.Y.z distribution media. If they only provide the media for > CD/DVD purchase, the revenue might help to provide for QA tinderboxes > for the ${RESOURCES} supported work. > > We might even end up with more people who are familiar with the > release > process and volunteer to work on RELENG_X_Y from initial release all > the way through normal end of support and into the community extended > support period. > > I think that would provide, as much as is possible, for the "don't > make > extra work for the existing developers" requirement as well as giving > these resources a way to "put up or shut up." I could be wrong. > > -- > Scott Lambert KC5MLE Unix > SysAdmin > lambert@lambertfam.org > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From bms at FreeBSD.org Thu Sep 18 22:33:43 2008 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Thu Sep 18 22:33:49 2008 Subject: floppy disk controller broken In-Reply-To: <20080918183250.GA48347@lpthe.jussieu.fr> References: <20080918075306.GA30709@lpthe.jussieu.fr> <200809181618.m8IGIj2P050390@lurza.secnetix.de> <20080918183250.GA48347@lpthe.jussieu.fr> Message-ID: <48D2D744.40304@FreeBSD.org> You could try formatting the floppy in a USB drive. Someone was going to pick this up, finish it off, and commit it, but I haven't heard back from them: http://people.freebsd.org/~bms/dump/tools/ufdformat/ From mike at sentex.net Fri Sep 19 00:06:14 2008 From: mike at sentex.net (Mike Tancsa) Date: Fri Sep 19 00:06:22 2008 Subject: Upcoming Releases Schedule... In-Reply-To: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <12944D4C-5243-4EC7-8E1A-04A7735B5AEA@netconsonance.com> <200809181925.m8IJPo3Z053187@lava.sentex.ca> <40E3236C-CAF7-406D-835F-948954F67D51@netconsonance.com> <200809181946.m8IJkFDa053266@lava.sentex.ca> <9ECDD71F-D4EB-4846-AB12-40B123AE7E16@netconsonance.com> <200809182103.m8IL34r2053611@lava.sentex.ca> Message-ID: <200809190006.m8J06Bih054261@lava.sentex.ca> At 05:46 PM 9/18/2008, Jo Rhett wrote: >I'd rather just drop this tangent. Me too. ---Mike From stefan.lambrev at moneybookers.com Fri Sep 19 08:59:58 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Fri Sep 19 09:00:05 2008 Subject: Upcoming Releases Schedule... In-Reply-To: References: <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <20080918220213.GA94268@sysmon.tcworks.net> Message-ID: <48D36A09.30802@moneybookers.com> Hi, Jo Rhett wrote: > I agree with pretty much everything you've said here, with the obvious > exception that I don't know what's involved in the release management > process to do as you've said. > > Also for my own self, rather than resurrect 6.2 I'd personally rather > focus on what we could do to extend the support period for 6.4. And > other releases going forward. If you want extended support period, you should go for 7.1 If I remember correctly .1 REL is supposed to be the target for all binary programs/drivers. But if your target is not only security fixes, but drivers (included in base) and new features then release is not working for you, right? Because new drivers are never back-ported to release, best they go to -stable, but you are not tracking -stable? As I understand if you track stable then you really do not care about the numbers after the dot - you are using just 6.x or 7.x (or 8.x in future) And 7-stable will not reach EOL at least next 4-5 years. Sorry if you already answer this, but the thread is very long and it's hard to track every mail in it. My simple question is how you plan to benefit if 7.1 have extended EOL? You will stick with 7.1Release (RELENG_7_1) and security patches, or to (RELENG_7) - which include new drivers? I'm asking because you said, that the main problem with EOL is not fixing bugs which you can do fine, but new drivers that are not back-ported. How you think this can be solved? Most business user do not want new driver to be masked as security update? -- Best Wishes, Stefan Lambrev ICQ# 24134177 From olli at lurza.secnetix.de Fri Sep 19 09:55:13 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Sep 19 09:55:20 2008 Subject: floppy disk controller broken In-Reply-To: <20080918183250.GA48347@lpthe.jussieu.fr> Message-ID: <200809190955.m8J9t5mE092126@lurza.secnetix.de> Michel Talon wrote: > Oliver Fromme wrote: > > Michel Talon wrote: > > > Moreover, trying to write to the floppy: > > > niobe# dd if=/dev/zero of=/dev/fd0 conv=noerror > > > dd: /dev/fd0: Input/output error > > > 5+0 records in > > > 4+0 records out > > > 2048 bytes transferred in 4.054404 secs (505 bytes/sec) > > > > > > I don't expect such result. Traditionnally writing works, while reading > > > may fail. > > > > Maybe I misunderstand what you're saying, but ... > > When I try to write to a floppy that has *not* been > > successfully formatted, I very much expect to get > > Input/output error. Anything else would be a bug. > > The floppy has certainly be formatted, in the past. Perhaps i > remember badly, i have not used floppies since years, but > in this case the behavior with Windows, Linux and ancient FreeBSD > was that you could write to the floppy, but could encounter errors > while reading. Since you mentioned "ancient" FreeBSD, I assume that was using buffered block devices, when FreeBSD still supported them? Nowadays /dev/fd0 is a character device which is unbuffered, i.e. your dd(1) command goes straight to the disk, and if the drive reports an error (typically sync mark not found if the floppy is unformatted), it goes back up to dd(1) immediately and you get Input/output error. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "We will perhaps eventually be writing only small modules which are identi- fied by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language." -- Donald E. Knuth, 1974 From rwatson at FreeBSD.org Fri Sep 19 11:20:15 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Sep 19 11:20:16 2008 Subject: Upcoming Releases Schedule... In-Reply-To: References: <1219409496.10487.22.camel@bauer.cse.buffalo.edu> <593618A3-56DA-4891-A4A0-690E9A9C5B32@netconsonance.com> <20080904133604.GB1188@atarininja.org> <47d0403c0809051319r3c82f87bhdb15ce5b0167987a@mail.gmail.com> <2742CAB1-8FF2-425D-A3B6-0658D7DB8F4D@netconsonance.com> <0C2C7E9B-61E3-4720-B76F-4745A3C963DA@netconsonance.com> <658B8861-1E78-4767-8D3D-8B79CC0BD45F@netconsonance.com> <15F15FD1-3C53-4018-8792-BC63289DC4C2@netconsonance.com> <448wtpcikb.fsf@be-well.ilk.org> Message-ID: On Thu, 18 Sep 2008, Jo Rhett wrote: > Thank you. If you don't mind I'd prefer to widen the scope a touch because > 6.2 will eventually go away, and frankly it is probably better to look > forward than to resurrect an unsupported version. So I would probably > state: > > Jo's $EMPLOYER has significant interest in longer support for -REL versions. > Enough to fund my time supporting the mainstream project. What would Jo (or > anyone else in a similar situation) need to bring to the table in order to > provide back to the project? This is the same answer I gave Lowell, but let me expand on it slightly. Our community grants rights (read also: responsibilities) on the basis of credibility in the community. Here's a possible plan: In the first stage, you need to establish credibility with the community as someone able and willing to do the work. You can do this by doing hard bits of the work without getting "official" sanction by creating an "Unofficial security and errata support for EoL'd FreeBSD releases" web page. Be very careful to scope the work so that you're not over-committing and there's no misunderstanding of what you're trying to do. Flag certain branches as "in support", and for each of those branches, provide pointers to the security advisories and errata patches that you've backported. If you take a branch out of support for your page (are no longer interested in maintaining it), keep the old stuff around for historical reasons, but clearly marked as historical rather than active. This will allow you to gain experience in maintaining security and errata patches for FreeBSD branches (more different than you might think from maintaining patches locally), establish credibility with the community as a whole, but in particular with the FreeBSD developers who are responsible for doing similar work for supported branches. This in turn may convince them that they should invest their time in mentoring you for a FreeBSD commit bit, and potentially join the security or release engineering teams once you've established that you are a member of the developer team who works well with others, does good technical work, and who is in it for the long haul. Some downsides to this approach: (1) It doesn't give the immediate gratification of seeing the official support status extended for releases. However, as you say, you're already doing the work. (2) You don't gain early access to confidential vulnerability information as a member of the security team, so (a) you can't have the patches ready in advance of the advisory, and (b) if there are reports of vulnerabilities in versions you support but the FreeBSD security team doesn't, you might not receive it in a timely manner. However, it accepts the way the project works: we don't provide access to our CVS (SVN) repository to people unless they have a mentor willing to propose them, and that mentor has to argue on the basis of a proven track record that the contribution you will make justify commit access to the tree. Likewise, we don't grant membership to the security team to committers unless they've shown a longer term commitment even than required for a commit bit, shown specific interest and commitment to security support issues, and that have they confidence of the security team that will be able to work with appropriate discretion in protecting the confidential and often critical security information we receive. Don't take this as a personal slight -- none of this says you aren't able to work with others, that you don't have the technical skills, that you don't have the time, aren't willing to make the commitment, or that you lack adequate discretion. Rather, it's saying that the way we evaluate people for participation in the project is that they have a track record of these things in the community. In a largely online and volunteer community, that's the way it works. Robert N M Watson Computer Laboratory University of Cambridge From oleg at opentransfer.com Fri Sep 19 11:36:38 2008 From: oleg at opentransfer.com (Oleg V. Nauman) Date: Fri Sep 19 11:36:39 2008 Subject: RELENG_7: something is very wrong with UDP? In-Reply-To: References: <20080918180543.pt7s2zmaio48ww8g@webmail.opentransfer.com> Message-ID: <20080919143636.p661cjfopw44osco@webmail.opentransfer.com> Quoting Robert Watson : > On Thu, 18 Sep 2008, Oleg V. Nauman wrote: > >> It seems to be something is very wrong with UDP on latest RELENG_7 >> >> Well some symptoms I have seen today when I was trying to boot >> newly compiled RELENG_7 on my laptop: >> >> a) rc scripts indefinitely waiting on logger to be completed during >> the boot ( devd and ifconfig are good examples) > > If you hit "ctrl-t" while these are waiting, what is the output? load: 0.00 cmd: logger [nanslp] 0.00u 0.07s 0% 832k > >> b) Sporadic DNS request failures > > I don't know what your comfortable level with debugging tools is, but > if you're happy using tcpdump, etc, I think I'd recommend diagnosing > this directly that way. I'd probably do something like this: > > (1) Start by deleting all but one nameserver entry in /etc/resolv.conf. > Confirm that you can still reproduce the problem. Due to various reasons my laptop running local caching DNS server ( named ) without any forwarders assigned. My /etc/resolv.conf contains nameserver 127.0.0.1 > > (2) Use dig(1) and tcpdump(1) to watch wire-level DNS behavior -- do you see > queries go out? Do you see replies come back? Is dig "waking up" and > seeing the replies when they arrive, or is there a delay or hang in dig? > If dig hangs, what does ctrl-t show the sleep state (wmesg) is? Will try do dig into when it occurs again > Could you > also use procstat -k on the dig process to generate a kernel stack trace > for it? > >> c) traceroute prints 0.00 like response time for every host >> >> d) was unable to reboot my laptop performing shutdown -r ( due to >> logger/syslog related issues I think) > > Could you try killing syslogd by hand and see if it dies? If not, can > you use procstat -kk to generate a stack trace for it? syslogd killing not helps.. Here is procstat -kk output for "shutdown -r now" process waiting on something: PID TID COMM TDNAME KSTACK 1447 100098 shutdown - mi_switch+0x2c8 sleepq_switch+0xd9 sleepq_catch_signals+0x239 sleepq_timedwait_sig+0x17 _sleep+0x339 kern_nanosleep+0xc1 nanosleep+0x6f syscall+0x2b3 Xint0x80_syscall+0x20 And procstat -kk output for logger process waiting: PID TID COMM TDNAME KSTACK 1421 100095 logger - mi_switch+0x2c8 sleepq_switch+0xd9 sleepq_catch_signals+0x239 sleepq_wait_sig+0x14 _sleep+0x35f pipe_read+0x389 dofileread+0x96 kern_readv+0x58 read+0x4f syscall+0x2b3 Xint0x80_syscall+0x20 > >> e ) I was unable to start X session ( it seems to be freezes laptop >> because I was unable to switch to another virtual console even) >> >> csup "backout" to date=2008.09.15.12.00.00 and recompiling the >> kernel fixes this issue for me. > > This is approximately the date of my last UDP MFC. Could you try > backing out just src/sys/netinet6/udp6_usrreq.c revision 1.81.2.7 and > see if that helps? (specifically, restore the use of sosend_generic > instead of sosend_dgram) > > Could you confirm that either you're not using any kernel modules from > ports, or that if you are, you have recompiled them with your most > recent update? I'm not using any third party kernel modules at this moment. > > Could you try compiling your kernel with WITNESS to see if we get any > extended debugging information? Have added WITNESS ( and STACK required by procstat ) options but it is not producing any output ( so no LORs or something like this ) > >> Is anybody experiencing the same issues with fresh RELENG_7? Unsure >> it is my local issues though > > I'm not experiencing them, but these sorts of things can be quite > subtle and workload-dependent. Well experiencing this issue during the system boot even.. > > > Robert N M Watson > Computer Laboratory > University of Cambridge From rwatson at FreeBSD.org Fri Sep 19 11:48:49 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Sep 19 11:48:53 2008 Subject: RELENG_7: something is very wrong with UDP? In-Reply-To: <20080919143636.p661cjfopw44osco@webmail.opentransfer.com> References: <20080918180543.pt7s2zmaio48ww8g@webmail.opentransfer.com> <20080919143636.p661cjfopw44osco@webmail.opentransfer.com> Message-ID: On Fri, 19 Sep 2008, Oleg V. Nauman wrote: >> (1) Start by deleting all but one nameserver entry in /etc/resolv.conf. >> Confirm that you can still reproduce the problem. > > Due to various reasons my laptop running local caching DNS server ( named ) > without any forwarders assigned. My /etc/resolv.conf contains nameserver > 127.0.0.1 This is simplifying in some senses, but complicating in others. In particular, the question it raises is whether the problem is in the DNS resolver or the nameserver. Seeing a tcpdump of lo0 for DNS traffic would be quite interesting, since we could look at timestamps and try to place the blame a bit more precisely. >> Could you >> also use procstat -k on the dig process to generate a kernel stack trace >> for it? Let's add to this list: when the problem happens, could you also procstat -k the name server process(es)? > And procstat -kk output for logger process waiting: > > PID TID COMM TDNAME KSTACK > 1421 100095 logger - mi_switch+0x2c8 > sleepq_switch+0xd9 sleepq_catch_signals+0x239 sleepq_wait_sig+0x14 > _sleep+0x35f pipe_read+0x389 dofileread+0x96 kern_readv+0x58 read+0x4f > syscall+0x2b3 Xint0x80_syscall+0x20 Interesting -- logger is blocked on reading from a pipe, likely standard input. So it sounds like something else is failing to complete in a timely manner -- perhaps due to DNS. >> This is approximately the date of my last UDP MFC. Could you try backing >> out just src/sys/netinet6/udp6_usrreq.c revision 1.81.2.7 and see if that >> helps? (specifically, restore the use of sosend_generic instead of >> sosend_dgram) If you can show that it's definitely a problem with the change to sosend_dgram for UDPv6 socket send, then it might suggest it's the same problem that it is related to the UDPv46 code there. In which case I will propose we back out that portion of the change in the 7-stable branch until it's known to be resolved -- I don't want other people tripping over this. >> Could you try compiling your kernel with WITNESS to see if we get any >> extended debugging information? > > Have added WITNESS ( and STACK required by procstat ) options but it is not > producing any output ( so no LORs or something like this ) OK. Could you try adding INVARIANT_SUPPORT and INVARIANTS if they aren't there? Be aware: this may convert the wedging you are experiencing into a kernel panic. >>> Is anybody experiencing the same issues with fresh RELENG_7? Unsure it is >>> my local issues though >> >> I'm not experiencing them, but these sorts of things can be quite subtle >> and workload-dependent. > > Well experiencing this issue during the system boot even.. OK. So there must be something a bit different about your setup -- perhaps there's something specific about the way things are interacting over the loopback address for the name server. Is this the stock system BIND9 or something else? Are you able to temporarily switch to an external name server and see if that changes things? Robert N M Watson Computer Laboratory University of Cambridge From koitsu at FreeBSD.org Fri Sep 19 12:36:02 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 19 12:36:11 2008 Subject: floppy disk controller broken In-Reply-To: <200809190955.m8J9t5mE092126@lurza.secnetix.de> References: <20080918183250.GA48347@lpthe.jussieu.fr> <200809190955.m8J9t5mE092126@lurza.secnetix.de> Message-ID: <20080919123559.GA45054@icarus.home.lan> On Fri, Sep 19, 2008 at 11:55:05AM +0200, Oliver Fromme wrote: > Michel Talon wrote: > > Oliver Fromme wrote: > > > Michel Talon wrote: > > > > Moreover, trying to write to the floppy: > > > > niobe# dd if=/dev/zero of=/dev/fd0 conv=noerror > > > > dd: /dev/fd0: Input/output error > > > > 5+0 records in > > > > 4+0 records out > > > > 2048 bytes transferred in 4.054404 secs (505 bytes/sec) > > > > > > > > I don't expect such result. Traditionnally writing works, while reading > > > > may fail. > > > > > > Maybe I misunderstand what you're saying, but ... > > > When I try to write to a floppy that has *not* been > > > successfully formatted, I very much expect to get > > > Input/output error. Anything else would be a bug. > > > > The floppy has certainly be formatted, in the past. Perhaps i > > remember badly, i have not used floppies since years, but > > in this case the behavior with Windows, Linux and ancient FreeBSD > > was that you could write to the floppy, but could encounter errors > > while reading. > > Since you mentioned "ancient" FreeBSD, I assume that was > using buffered block devices, when FreeBSD still supported > them? That sounds right -- again, if my memory hasn't failed me... > Nowadays /dev/fd0 is a character device which is > unbuffered, i.e. your dd(1) command goes straight to the > disk, and if the drive reports an error (typically sync > mark not found if the floppy is unformatted), it goes back > up to dd(1) immediately and you get Input/output error. Ah ha! Evolution has occurred. Thanks for educating me. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From olli at lurza.secnetix.de Fri Sep 19 14:20:32 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Sep 19 14:20:34 2008 Subject: ACPI "blacklist" question In-Reply-To: <200809171144.48424.jhb@freebsd.org> Message-ID: <200809191420.m8JEKTEf002635@lurza.secnetix.de> John Baldwin wrote: > On Wednesday 17 September 2008 07:47:18 am Oliver Fromme wrote: > > I have recently updated a machine to 7-stable. > > ACPI doesn't seem to work correctly on this machine. > > With earlier versions of FreeBSD (including the latest > > RELENG_6), I got this line in dmesg: > > > > ACPI disabled by blacklist. Contact your BIOS vendor. > > > > And everything was fine. The box runs perfectly well > > with ACPI disabled. (I can't get a BIOS update because > > the mainboard is too old.) > > > > When I updated to RELENG_7 a few days ago, the above line > > did _not_ appear anymore, and the machine didn't proceed > > [...] > > This is a regression. Try this fix: > > Index: acpi_quirk.c > =================================================================== > --- acpi_quirk.c (revision 183112) > +++ acpi_quirk.c (working copy) > @@ -149,9 +149,9 @@ > if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_FADT, 0, &fadt))) > bzero(&fadt, sizeof(fadt)); > if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_DSDT, 0, &dsdt))) > - bzero(&fadt, sizeof(dsdt)); > + bzero(&dsdt, sizeof(dsdt)); > if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_XSDT, 0, &xsdt))) > - bzero(&fadt, sizeof(xsdt)); > + bzero(&xsdt, sizeof(xsdt)); > > /* Then, override the quirks with any matched from table signatures. */ > for (entry = acpi_quirks_table; entry->match; entry++) { The patch fixes the problem. The blacklist message is now back again, and the machine boots without hints right out of the box. Thanks! Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' From jasone at FreeBSD.org Fri Sep 19 14:31:27 2008 From: jasone at FreeBSD.org (Jason Evans) Date: Fri Sep 19 14:31:32 2008 Subject: Calling malloc from a signal handler In-Reply-To: <48D3AE8D.50304@math.missouri.edu> References: <48D3AE8D.50304@math.missouri.edu> Message-ID: <48D3B2F9.7020900@FreeBSD.org> Stephen Montgomery-Smith wrote: > I notice that if you use "malloc" from within a signal handler on > FreeBSD-6.x, that you can potentially trigger a "recursive call" error. > > But this seems to have changed in FreeBSD-7.x. The malloc implementation is completely new in FreeBSD 7, so not all of the internal error checking code is the same. > Is it now permissible to call "malloc" from within a signal handler in > FreeBSD-7.x? Calling malloc from within a signal handler can cause application deadlock, so although you won't see an error message printed, you are unlikely to be happy with the results. Jason From stephen at math.missouri.edu Fri Sep 19 14:32:02 2008 From: stephen at math.missouri.edu (Stephen Montgomery-Smith) Date: Fri Sep 19 14:32:06 2008 Subject: Calling malloc from a signal handler Message-ID: <48D3AE8D.50304@math.missouri.edu> I notice that if you use "malloc" from within a signal handler on FreeBSD-6.x, that you can potentially trigger a "recursive call" error. But this seems to have changed in FreeBSD-7.x. Is it now permissible to call "malloc" from within a signal handler in FreeBSD-7.x? If so, should the man page of "sigaction(2)" be upgraded to say this? Thanks, Stephen From jkim at FreeBSD.org Fri Sep 19 15:12:17 2008 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Fri Sep 19 15:12:19 2008 Subject: ACPI "blacklist" question In-Reply-To: <200809171144.48424.jhb@freebsd.org> References: <200809171147.m8HBlI7F082370@lurza.secnetix.de> <200809171144.48424.jhb@freebsd.org> Message-ID: <200809191112.06765.jkim@FreeBSD.org> On Wednesday 17 September 2008 11:44 am, John Baldwin wrote: > On Wednesday 17 September 2008 07:47:18 am Oliver Fromme wrote: > > Hello, > > > > I have recently updated a machine to 7-stable. > > ACPI doesn't seem to work correctly on this machine. > > With earlier versions of FreeBSD (including the latest > > RELENG_6), I got this line in dmesg: > > > > ACPI disabled by blacklist. Contact your BIOS vendor. > > > > And everything was fine. The box runs perfectly well > > with ACPI disabled. (I can't get a BIOS update because > > the mainboard is too old.) > > > > When I updated to RELENG_7 a few days ago, the above line > > did _not_ appear anymore, and the machine didn't proceed > > to boot, so I had to travel to the console. :-( > > After disabling ACPI manually via boot.conf hint, it is > > up and running fine again. > > > > Now i'm wondering: Has the ACPI blacklist been removed > > intentionally, or is this a regression? Certainly I did > > not find any mentioning of it in UPDATING or anywhere > > else. > > This is a regression. Try this fix: > > Index: acpi_quirk.c > =================================================================== > --- acpi_quirk.c (revision 183112) > +++ acpi_quirk.c (working copy) > @@ -149,9 +149,9 @@ > if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_FADT, 0, &fadt))) > bzero(&fadt, sizeof(fadt)); > if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_DSDT, 0, &dsdt))) > - bzero(&fadt, sizeof(dsdt)); > + bzero(&dsdt, sizeof(dsdt)); > if (ACPI_FAILURE(AcpiGetTableHeader(ACPI_SIG_XSDT, 0, &xsdt))) > - bzero(&fadt, sizeof(xsdt)); > + bzero(&xsdt, sizeof(xsdt)); > > /* Then, override the quirks with any matched from table > signatures. */ for (entry = acpi_quirks_table; entry->match; > entry++) { Doh, that's my copy-and-pasto. Thanks for catching it! Jung-uk Kim From jkim at FreeBSD.org Fri Sep 19 15:30:28 2008 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Fri Sep 19 15:30:31 2008 Subject: ACPI "blacklist" question In-Reply-To: <200809191420.m8JEKTEf002635@lurza.secnetix.de> References: <200809191420.m8JEKTEf002635@lurza.secnetix.de> Message-ID: <200809191130.21002.jkim@FreeBSD.org> On Friday 19 September 2008 10:20 am, Oliver Fromme wrote: > John Baldwin wrote: > > On Wednesday 17 September 2008 07:47:18 am Oliver Fromme wrote: > > > I have recently updated a machine to 7-stable. > > > ACPI doesn't seem to work correctly on this machine. > > > With earlier versions of FreeBSD (including the latest > > > RELENG_6), I got this line in dmesg: > > > > > > ACPI disabled by blacklist. Contact your BIOS vendor. > > > > > > And everything was fine. The box runs perfectly well > > > with ACPI disabled. (I can't get a BIOS update because > > > the mainboard is too old.) > > > > > > When I updated to RELENG_7 a few days ago, the above line > > > did _not_ appear anymore, and the machine didn't proceed > > > [...] > > > > This is a regression. Try this fix: > > > > Index: acpi_quirk.c