[releng_7 tinderbox] failure on amd64/amd64
TB --- 2010-09-01 05:39:04 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-09-01 05:39:04 - starting RELENG_7 tinderbox run for amd64/amd64 TB --- 2010-09-01 05:39:04 - cleaning the object tree TB --- 2010-09-01 05:39:33 - cvsupping the source tree TB --- 2010-09-01 05:39:33 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/amd64/amd64/supfile TB --- 2010-09-01 05:39:43 - building world TB --- 2010-09-01 05:39:43 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-01 05:39:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-01 05:39:43 - TARGET=amd64 TB --- 2010-09-01 05:39:43 - TARGET_ARCH=amd64 TB --- 2010-09-01 05:39:43 - TZ=UTC TB --- 2010-09-01 05:39:43 - __MAKE_CONF=/dev/null TB --- 2010-09-01 05:39:43 - cd /src TB --- 2010-09-01 05:39:43 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 1 05:39:43 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Sep 1 07:12:52 UTC 2010 TB --- 2010-09-01 07:12:52 - generating LINT kernel config TB --- 2010-09-01 07:12:52 - cd /src/sys/amd64/conf TB --- 2010-09-01 07:12:52 - /usr/bin/make -B LINT TB --- 2010-09-01 07:12:52 - building LINT kernel TB --- 2010-09-01 07:12:52 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-01 07:12:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-01 07:12:52 - TARGET=amd64 TB --- 2010-09-01 07:12:52 - TARGET_ARCH=amd64 TB --- 2010-09-01 07:12:52 - TZ=UTC TB --- 2010-09-01 07:12:52 - __MAKE_CONF=/dev/null TB --- 2010-09-01 07:12:52 - cd /src TB --- 2010-09-01 07:12:52 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Sep 1 07:12:52 UTC 2010 >>> 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 -frename-registers -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_novell.c cc -c -O2 -frename-registers -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_rtl80x9.c cc -c -O2 -frename-registers -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.c cc -c -O2 -frename-registers -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
Re: [releng_7 tinderbox] failure on amd64/amd64
On Wed, Sep 01, 2010 at 03:21:48AM -0400, FreeBSD Tinderbox wrote: > TB --- 2010-09-01 05:39:04 - tinderbox 2.6 running on freebsd-stable.sentex.ca > TB --- 2010-09-01 05:39:04 - starting RELENG_7 tinderbox run for amd64/amd64 > TB --- 2010-09-01 05:39:04 - cleaning the object tree > TB --- 2010-09-01 05:39:33 - cvsupping the source tree > TB --- 2010-09-01 05:39:33 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s > /tinderbox/RELENG_7/amd64/amd64/supfile > TB --- 2010-09-01 05:39:43 - building world > TB --- 2010-09-01 05:39:43 - MAKEOBJDIRPREFIX=/obj > TB --- 2010-09-01 05:39:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2010-09-01 05:39:43 - TARGET=amd64 > TB --- 2010-09-01 05:39:43 - TARGET_ARCH=amd64 > TB --- 2010-09-01 05:39:43 - TZ=UTC > TB --- 2010-09-01 05:39:43 - __MAKE_CONF=/dev/null > TB --- 2010-09-01 05:39:43 - cd /src > TB --- 2010-09-01 05:39:43 - /usr/bin/make -B buildworld > >>> World build started on Wed Sep 1 05:39:43 UTC 2010 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> stage 5.1: building 32 bit shim libraries > >>> World build completed on Wed Sep 1 07:12:52 UTC 2010 > TB --- 2010-09-01 07:12:52 - generating LINT kernel config > TB --- 2010-09-01 07:12:52 - cd /src/sys/amd64/conf > TB --- 2010-09-01 07:12:52 - /usr/bin/make -B LINT > TB --- 2010-09-01 07:12:52 - building LINT kernel > TB --- 2010-09-01 07:12:52 - MAKEOBJDIRPREFIX=/obj > TB --- 2010-09-01 07:12:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2010-09-01 07:12:52 - TARGET=amd64 > TB --- 2010-09-01 07:12:52 - TARGET_ARCH=amd64 > TB --- 2010-09-01 07:12:52 - TZ=UTC > TB --- 2010-09-01 07:12:52 - __MAKE_CONF=/dev/null > TB --- 2010-09-01 07:12:52 - cd /src > TB --- 2010-09-01 07:12:52 - /usr/bin/make -B buildkernel KERNCONF=LINT > >>> Kernel build for LINT started on Wed Sep 1 07:12:52 UTC 2010 > >>> 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 -frename-registers -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone > -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg > -mprofiler-epilogue /src/sys/dev/ed/if_ed_novell.c > cc -c -O2 -frename-registers -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone > -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg > -mprofiler-epilogue /src/sys/dev/ed/if_ed_rtl80x9.c > cc -c -O2 -frename-registers -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone > -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg > -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.c > cc -c -O2 -frename-registers -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
Re: Broadcom Wireless BCM4312 Rev.02 (BCM4310 UART) troubles
On Tue, Aug 31, 2010 at 10:30 AM, Michael BlackHeart wrote: > Hello > > I've got a problem with Broadcomm Wireless. > I have notebook HP Compaq 6720s with BCM4312. I disassemblied book and saw > there plugable Wireless Module but I'm lazy to do it again to werify it's > ID. > > Windows XP drivers works fine and says that is's > > PCI\VEN_14E4&DEV_4312&SUBSYS_1371103C&REV_02\4&29E2C51B&0&00E1 > MEMORY E400 - E4003FFF > IRQ 17 > > I've tried : > FreeBSD 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 2010 > r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > And noting as i386 8.1 release. > > Now I'm running: > FreeBSD 8.1-STABLE FreeBSD 8.1-STABLE #0 r211991: Mon Aug 30 14:58:34 MSD > 2010 > root@:/usr/obj/usr/src/sys/GENERIC amd64 > > With no driver attached "pciconf -l -cvb" says: > > no...@pci0:16:0:0: class=0x028000 card=0x1371103c chip=0x431214e4 rev=0x02 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM4310 UART (Wireless Ethernet Adapter)' > class = network > bar [10] = type Memory, range 64, base 0xe400, size 16384, enabled > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 09[58] = vendor (length 120) > cap 05[e8] = MSI supports 1 message, 64 bit > cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > > Clean install, trying bwi driver first > > cd /usr/ports/net/bwi-firmware-kmod && make install clean && rehash > kldload bwi_ucode_v3 > cd /usr/sys/src/modules/bwi > make all obj depend install clean > kldload if_bwi > > Aug 18 12:19:58 kernel: bwi0: > mem 0xe400-0xe4003fff irq 17 at device 0.0 on pci16 > Aug 18 12:19:58 kernel: bwi0: [ITHREAD] > Aug 18 12:19:58 kernel: bwi0: BBP: id 0x4311, rev 0x2, pkg 0 > Aug 18 12:19:58 kernel: bwi0: MAC rev 13 is not supported bwi(4) does not support your card. > Aug 18 12:19:58 kernel: bwi0: no MAC was found > Aug 18 12:19:58 kernel: device_attach: bwi0 attach returned 6 > > pciconf -l -cvb says: > > b...@pci0:16:0:0: class=0x028000 card=0x1371103c chip=0x431214e4 rev=0x02 > hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM4310 UART (Wireless Ethernet Adapter)' > class = network > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 09[58] = vendor (length 120) > cap 05[e8] = MSI supports 1 message, 64 bit > cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > > now rebooting 'cos even after kldunloading if_bwi module it's still lists in > pciconfand trying bwn > > cd /usr/ports/net/bwn-firmware-kmod && make install clean && rehash > kldload bwn_v4_ucode.ko > kldload if_bwn > > pciconf -l -cvb says: > > siba_bwn0: mem 0xe400-0xe4003fff > irq 17 at device 0.0 on pci16 > siba_bwn0: unsupported coreid (USB 1.1 Host) > bwn0 on siba_bwn0 > bwn0: WLAN (chipid 0x4311 rev 13) PHY (analog 4 type 2 rev 9) RADIO (manuf > 0x17f ver 0x2050 rev 2) > bwn0: DMA (64 bits) > bwn0: Using 1 MSI messages > bwn0: [FILTER] > > siba_b...@pci0:16:0:0: class=0x028000 card=0x1371103c chip=0x431214e4 > rev=0x02 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM4310 UART (Wireless Ethernet Adapter)' > class = network > bar [10] = type Memory, range 64, base 0xe400, size 16384, enabled > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 09[58] = vendor (length 120) > cap 05[e8] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > > ifconfig bwn0 up scan > bwn0: firmware version (rev 410 patch 2160 date 0x751a time 0x7c0a) > ifconfig: unable to get scan results > bwn0: status of RF switch is changed to OFF You must create wlanX first. > > book have a switch to turn on/off all radio and it's always on. also when > i'm switching it FreeBSD says nothing > Also I tried acpi_hp - no sense > And i didn't find any apropriate in sysctl > > Moving next - ndis > I've tried couple of drivers > With WinXP that running on drivers v. VERSION: 7.10 REV: B from sp41680 > And OS goes to kernel panic just when I kldloaded it. NDISulator on amd64 is mostly broken. It can panic on driver initialization (fixed in my git repo). Also fpudna in kernel mode can cause panic (not yet fixed). > No dump, sorry, but I don't think that it matters a thing > > Another one - VERSION: 6.10 REV: A from sp34152 works a bit better > It converts and loads without panic but in debug: > kldload bcmwl564_sys.ko > > ndis0: mem 0xe400-0xe4003fff irq 17 at > device 0. > 0 on pci16 > > ndis0: [ITHREAD] > > ndis0: NDIS API version: 5.1 > > fpudna in kernel mode! Interesting, that version of driver does not use symbols which cause crash on driver initialization of older driver... Of course most 6.X drivers dont have support for older NDIS 5.1 API. > pciconf -lcvb says: > nd...@pci0:16:0:0: class=0x028000 card=0x1371103c chip=0x431214e4 rev=0x02 > hdr=0x00 > > vendor = 'Broadcom Corporation' > > device = 'BCM4310 UART (Wireless Ethernet Adapter)' > > class = network > > bar [10] = type Memory, range 64, base 0xe4
[releng_7 tinderbox] failure on i386/i386
TB --- 2010-09-01 06:54:06 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-09-01 06:54:06 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2010-09-01 06:54:06 - cleaning the object tree TB --- 2010-09-01 06:54:29 - cvsupping the source tree TB --- 2010-09-01 06:54:29 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2010-09-01 06:54:38 - building world TB --- 2010-09-01 06:54:38 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-01 06:54:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-01 06:54:38 - TARGET=i386 TB --- 2010-09-01 06:54:38 - TARGET_ARCH=i386 TB --- 2010-09-01 06:54:38 - TZ=UTC TB --- 2010-09-01 06:54:38 - __MAKE_CONF=/dev/null TB --- 2010-09-01 06:54:38 - cd /src TB --- 2010-09-01 06:54:38 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 1 06:54:39 UTC 2010 >>> 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 Wed Sep 1 08:04:41 UTC 2010 TB --- 2010-09-01 08:04:41 - generating LINT kernel config TB --- 2010-09-01 08:04:41 - cd /src/sys/i386/conf TB --- 2010-09-01 08:04:41 - /usr/bin/make -B LINT TB --- 2010-09-01 08:04:41 - building LINT kernel TB --- 2010-09-01 08:04:41 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-01 08:04:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-01 08:04:41 - TARGET=i386 TB --- 2010-09-01 08:04:41 - TARGET_ARCH=i386 TB --- 2010-09-01 08:04:41 - TZ=UTC TB --- 2010-09-01 08:04:41 - __MAKE_CONF=/dev/null TB --- 2010-09-01 08:04:41 - cd /src TB --- 2010-09-01 08:04:41 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Sep 1 08:04:42 UTC 2010 >>> 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 -fno-omit-frame-pointer -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/dev/ed/if_ed_rtl80x9.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 -fno-omit-frame-pointer -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/dev/ed/if_ed_pccard.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 -fno-omit-frame-pointer -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/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -fno-omit-frame-pointer -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffree
[releng_7 tinderbox] failure on i386/pc98
TB --- 2010-09-01 07:21:48 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2010-09-01 07:21:48 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2010-09-01 07:21:48 - cleaning the object tree TB --- 2010-09-01 07:22:24 - cvsupping the source tree TB --- 2010-09-01 07:22:24 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2010-09-01 07:22:34 - building world TB --- 2010-09-01 07:22:34 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-01 07:22:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-01 07:22:34 - TARGET=pc98 TB --- 2010-09-01 07:22:34 - TARGET_ARCH=i386 TB --- 2010-09-01 07:22:34 - TZ=UTC TB --- 2010-09-01 07:22:34 - __MAKE_CONF=/dev/null TB --- 2010-09-01 07:22:34 - cd /src TB --- 2010-09-01 07:22:34 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 1 07:22:35 UTC 2010 >>> 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 Wed Sep 1 08:28:55 UTC 2010 TB --- 2010-09-01 08:28:55 - generating LINT kernel config TB --- 2010-09-01 08:28:55 - cd /src/sys/pc98/conf TB --- 2010-09-01 08:28:55 - /usr/bin/make -B LINT TB --- 2010-09-01 08:28:55 - building LINT kernel TB --- 2010-09-01 08:28:55 - MAKEOBJDIRPREFIX=/obj TB --- 2010-09-01 08:28:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-09-01 08:28:55 - TARGET=pc98 TB --- 2010-09-01 08:28:55 - TARGET_ARCH=i386 TB --- 2010-09-01 08:28:55 - TZ=UTC TB --- 2010-09-01 08:28:55 - __MAKE_CONF=/dev/null TB --- 2010-09-01 08:28:55 - cd /src TB --- 2010-09-01 08:28:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Sep 1 08:28:55 UTC 2010 >>> 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 -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_novell.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 -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_rtl80x9.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 -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.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 -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -
Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable.
I'm running -STABLE with a kde-derived desktop. This setup (which is pretty standard) is providing abysmal interactive performance on an eight-core machine whenever I try to do anything CPU-intensive (such as building a port). Basically, trying to build anything from ports rapidly renders everything else so "non-interactive" in the eyes of the scheduler that, for instance, switching between virtual desktops (I have six of them in reasonably frequent use) takes about a minute of painful waiting on redraws to complete. Once I pay attention to any particular window, the scheduler rapidly (like, in 15 agonising seconds or so) decides that the processes associated with that particular window are "interactive" and performance there picks up again. But it only takes 10 seconds (not timed; ballpark figures) or so of inattention for a window's processes to lapse back into a low-priority state, with the attendant performance problems. I don't think my desktop usage is particularly abnormal; I doubt my level of frustration is, either :-) I think the issue here is that a modern desktop has quite a lot of associated processes, and you can't keep them all sufficiently "interactive" in the eyes of sched_ule to ensure they stay responsive. Are there particular tunables associated with sched_ule (the manpage says not) that I might look at to try to address this? Or process flags I can set on my desktop tasks to keep them nearer the interactive end of the spectrum? Claimed is: o Interactivity heuristics that detect interactive applications and schedules them preferentially under high load. but compared to the performance under sched_4bsd, what I'm seeing is an atrocious user experience. At the moment I'm fiddling around with cpusets to try to pin my port builds to a subset of the available processors. Suggestions are welcome! Cheers, jan PS. I've stuck it out with sched_ule since it's been available, but I should point out this isn't a sudden change in its behaviour; it's done this for a while. -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ "No generalised law is without exception." A self-demonstrating axiom. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: if_rtdel: error 47
On Tue, 31 Aug 2010, Mike Tancsa wrote: Hey Mike, On a RELENG_8 box from aug 25th, I started seeing a constant spew of Aug 31 00:17:46 gate8 kernel: if_rtdel: error 47 Aug 31 00:18:29 gate8 kernel: ifa_del_loopback_route: deletion failed Aug 31 00:18:29 gate8 kernel: if_rtdel: error 3 Aug 31 00:18:29 gate8 last message repeated 2 times Aug 31 00:18:37 gate8 kernel: ifa_del_loopback_route: deletion failed Aug 31 00:18:37 gate8 kernel: if_rtdel: error 3 Aug 31 00:18:37 gate8 last message repeated 2 times Aug 31 00:18:38 gate8 kernel: ifa_del_loopback_route: deletion failed Aug 31 00:18:38 gate8 kernel: if_rtdel: error 3 Aug 31 00:18:38 gate8 last message repeated 2 times What do they mean and how can I find the cause of it ? The box acts as an LNS with about 700 ng interfaces with mpd5.5. ipv6 is enabled on this server as well, so I am guessing it might be related to ipv6 as I havent seen it on the other LNS boxes that have the same setup, except no ipv6. It was happily running for a few days until this error started showing up ? I thought this was fixed already but maybe only in HEAD and not merged. I'll go and look. /bz -- Bjoern A. Zeeb This signature is about you not me. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Why is NFSv4 so slow?
Hi everyone, I am experiencing similar issues with newnfs: 1) I have two clients that each get around 0.5MiB/s to 2.6MiB/s reading from the NFS4-share on Gbit-Lan 2) Mounting with -t newnfs -o nfsv3 results in no performance gain whatsoever. 3) Mounting with -t nfs results in 58MiB/s ! (Netcat has similar performance) → not a hardware/driver issue from my pov Is there anything I can do to help fix this? Thank you, -- ┌─┐ Best Regards,│ Free Software Foundation Europe█▉ │ Hannes Hauswedell│ German Team█▉█▉█▉ │ │ Coordinator for pdfreaders.org ▉▉ │ └─┘ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kernel panic when accessing /dev/tap0
On Wed, 1 Sep 2010, Frank Razenberg wrote: Hey, Robert Watson described a problem in this discussion: http://lists.freebsd.org/pipermail/freebsd-stable/2006-May/025880.html Currently I'm experiencing a similar problem, but on amd64 and FreeBSD 8.1 Release. Accessing /dev/tap0 instantly results in a kernel panic, so it's most likely if_tap related. Is this a known problem? I've started encountering it ever since I rebuilt my kernel with "options vimage". this is expected. I have a work in progress fix in perforce for most/all cloned interfaces. It's only a matter of extracting patches now but it'll be anohter few days till I'll get to that. /bz PS: freebsd-virtualization@ might be the better place to post VIMAGE problems. -- Bjoern A. Zeeb This signature is about you not me. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.1R ZFS almost locking up system
On Tue, Aug 31, 2010 at 10:58:29AM -0500, Dan Nelson wrote: > In the last episode (Aug 31), Tim Bishop said: > > On Sat, Aug 21, 2010 at 05:24:29PM -0500, Dan Nelson wrote: > > > In the last episode (Aug 21), Tim Bishop said: > > > > A few items from top, including zfskern: > > > > > > > > PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU > > > > COMMAND > > > > 5 root4 -8- 0K60K zio->i 0 54:38 3.47% > > > > zfskern > > > > 91775 70 1 440 53040K 31144K tx->tx 1 2:11 0.00% > > > > postgres > > > > 39661 tdb 1 440 55776K 32968K tx->tx 0 0:39 0.00% mutt > > > > 14828 root1 470 14636K 1572K tx->tx 1 0:03 0.00% zfs > > > > 11188 root1 510 14636K 1572K tx->tx 0 0:03 0.00% zfs > > > > > > > > At some point during this process my zfs snapshots have been failing to > > > > complete: > > > > > > > > root5 0.8 0.0 060 ?? DL7Aug10 54:43.83 > > > > [zfskern] > > > > root 8265 0.0 0.0 14636 1528 ?? D10:00AM 0:03.12 zfs > > > > snapshot -r po...@2010-08-21_10:00:01--1d > > > > root11188 0.0 0.1 14636 1572 ?? D11:00AM 0:02.93 zfs > > > > snapshot -r po...@2010-08-21_11:00:01--1d > > > > root14828 0.0 0.1 14636 1572 ?? D12:00PM 0:03.04 zfs > > > > snapshot -r po...@2010-08-21_12:00:00--1d > > > > root17862 0.0 0.1 14636 1572 ?? D 1:00PM 0:01.96 zfs > > > > snapshot -r po...@2010-08-21_13:00:01--1d > > > > root20986 0.0 0.1 14636 1572 ?? D 2:00PM 0:02.07 zfs > > > > snapshot -r po...@2010-08-21_14:00:01--1d > > > > > > procstat -k on some of these processes might help to pinpoint what part of > > > the zfs code they're all waiting in. > > > > It happened again this Saturday (clearly something in the weekly > > periodic run is triggering the issue). procstat -kk shows the following > > for processes doing something zfs related (where zfs related means the > > string 'zfs' in the procstat -kk output): > > > > 0 100084 kernel zfs_vn_rele_task mi_switch+0x16f > > sleepq_wait+0x42 _sleep+0x31c taskqueue_thread_loop+0xb7 fork_exit+0x118 > > fork_trampoline+0xe > > 5 100031 zfskern arc_reclaim_thre mi_switch+0x16f > > sleepq_timedwait+0x42 _cv_timedwait+0x129 arc_reclaim_thread+0x2d1 > > fork_exit+0x118 fork_trampoline+0xe > > 5 100032 zfskern l2arc_feed_threa mi_switch+0x16f > > sleepq_timedwait+0x42 _cv_timedwait+0x129 l2arc_feed_thread+0x1be > > fork_exit+0x118 fork_trampoline+0xe > > 5 100085 zfskern txg_thread_enter mi_switch+0x16f > > sleepq_wait+0x42 _cv_wait+0x111 txg_thread_wait+0x79 > > txg_quiesce_thread+0xb5 fork_exit+0x118 fork_trampoline+0xe > > 5 100086 zfskern txg_thread_enter mi_switch+0x16f > > sleepq_wait+0x42 _cv_wait+0x111 zio_wait+0x61 dsl_pool_sync+0xea > > spa_sync+0x355 txg_sync_thread+0x195 fork_exit+0x118 fork_trampoline+0xe > >17 100040 syncer -mi_switch+0x16f > > sleepq_wait+0x42 _cv_wait+0x111 txg_wait_synced+0x7c zil_commit+0x416 > > zfs_sync+0xa6 sync_fsync+0x184 sync_vnode+0x16b sched_sync+0x1c9 > > fork_exit+0x118 fork_trampoline+0xe > > 2210 100156 syslogd -mi_switch+0x16f > > sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 > > VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 > > writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 > > 3500 100177 syslogd -mi_switch+0x16f > > sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 > > VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 > > writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 > > 3783 100056 syslogd -mi_switch+0x16f > > sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 zfs_freebsd_write+0x378 > > VOP_WRITE_APV+0xb2 vn_write+0x2d7 dofilewrite+0x85 kern_writev+0x60 > > writev+0x41 syscall+0x1e7 Xfast_syscall+0xe1 > > 4064 100165 mysqld initial thread mi_switch+0x16f > > sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c > > zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc > > vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 closef+0x3b kern_close+0x14d > > syscall+0x1e7 Xfast_syscall+0xe1 > > 4441 100224 python2.6initial thread mi_switch+0x16f > > sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c > > zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc > > null_reclaim+0xbc vgonel+0x12e vrecycle+0x7d null_inactive+0x1f > > vinactive+0x6a vputx+0x1cc vn_close+0xa1 vn_closefile+0x5a _fdrop+0x23 > > 100227 python2.6initial thread mi_switch+0x16f > > sleepq_wait+0x42 _cv_wait+0x111 txg_wait_open+0x85 dmu_tx_assign+0x16c > > zfs_inactive+0xd9 zfs_freebsd_inactive+0x1a vinactive+0x6a vputx+0x1cc > > null_reclaim+0xbc vg
Re: Tuning the scheduler? Desktop with a CPU-intensive task becomes rapidly unusable.
On 09/01/10 15:08, jan.gr...@bristol.ac.uk wrote: I'm running -STABLE with a kde-derived desktop. This setup (which is pretty standard) is providing abysmal interactive performance on an eight-core machine whenever I try to do anything CPU-intensive (such as building a port). Basically, trying to build anything from ports rapidly renders everything else so "non-interactive" in the eyes of the scheduler that, for instance, switching between virtual desktops (I have six of them in reasonably frequent use) takes about a minute of painful waiting on redraws to complete. Are you sure this is about the scheduler or maybe bad X11 drivers? Once I pay attention to any particular window, the scheduler rapidly (like, in 15 agonising seconds or so) decides that the processes associated with that particular window are "interactive" and performance there picks up again. But it only takes 10 seconds (not timed; ballpark figures) or so of inattention for a window's processes to lapse back into a low-priority state, with the attendant performance problems. "windows" in X11 have nothing to do with the scheduler (contrary to MS Windows where the OS actually "re-nices" processes whose windows have focus) - here you are just interacting with a process. I don't think my desktop usage is particularly abnormal; I doubt my level of frustration is, either :-) I think the issue here is that a modern I'm writing this on a quad-core Core2 machine with 4 GB RAM, amd64 arch, Radeon 2500 HD, with KDE4 with most of the 3D visual effects turned on. I have not yet experienced problems like you describe. On the other hand, I have noticed that a 2xQuad-core machine I have access too has more X11 interactivity problems than this single quad-core machine, though again not as serious as yours. I don't know why this is. From the hardware side it might be the shared FSB or from the software side it might be the scheduler. If you want to try something I think it's easier for you to disable one CPU in BIOS or pin X.org and its descendant processes to CPUs of a single socket than to diagnose scheduler problems. but compared to the performance under sched_4bsd, what I'm seeing is an atrocious user experience. It would be best if you could quantify this in some way. I have no idea how. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Everyone, On November 30th, FreeBSD 6.4 and FreeBSD 8.0 will have reached their End of Life and will no longer be supported by the FreeBSD Security Team. Since FreeBSD 6.4 is the last remaining supported release from the FreeBSD 6.x stable branch, support for the FreeBSD 6.x stable branch will also cease at the same point. Users of either of these FreeBSD releases are strongly encouraged to upgrade to either FreeBSD 7.3 or FreeBSD 8.1 before that date. The FreeBSD Ports Management Team wishes to remind users that November 30 is also the end of support for the Ports Collection for both FreeBSD 6.4 RELEASE and the FreeBSD 6.x STABLE branch. Neither the infrastructure nor individual ports are guaranteed to work on these FreeBSD versions after that date. A CVS tag will be created for users who cannot upgrade for some reason, at which time these users are advised to stop tracking the latest ports CVS repository and use the RELEASE_6_EOL tag instead. The current supported branches and expected EoL dates are: +-+ | Branch | Release | Type | Release date | Estimated EoL | |---+++-+-| |RELENG_6 |n/a |n/a |n/a |November 30, 2010| |-| |RELENG_6_4 |6.4-RELEASE |Extended|November 18, 2008|November 30, 2010| |-| |RELENG_7 |n/a |n/a |n/a |last release + 2y| |---+++-+-| |RELENG_7_1 |7.1-RELEASE |Extended|January 4, 2009 |January 31, 2011 | |---+++-+-| |RELENG_7_3 |7.3-RELEASE |Extended|March 23, 2010 |March 31, 2012 | |---+++-+-| |RELENG_8 |n/a |n/a |n/a |last release + 2y| |---+++-+-| |RELENG_8_0 |8.0-RELEASE |Normal |November 25, 2009|November 30, 2010| |---+++-+-| |RELENG_8_1 |8.1-RELEASE |Extended|July 23, 2010|July 31, 2012| +-+ - -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkx+cdwACgkQFdaIBMps37K/VACgnkGPT1G76AYaor9ifcTeFDA2 dzgAn0Oqz5UsoaoCvWycUSsFFlpBi0gB =WWDq -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why is NFSv4 so slow?
> Hi everyone, > > I am experiencing similar issues with newnfs: > > 1) I have two clients that each get around 0.5MiB/s to 2.6MiB/s > reading > from the NFS4-share on Gbit-Lan > > 2) Mounting with -t newnfs -o nfsv3 results in no performance gain > whatsoever. > > 3) Mounting with -t nfs results in 58MiB/s ! (Netcat has similar > performance) → not a hardware/driver issue from my pov > The experimental client does reads in larger MAXBSIZE chunks, which did cause a similar problem in Mac OS X until rsize=32768,wsize=32768 was specified. Rick already tried that, but you might want to try it for your case. > Is there anything I can do to help fix this? > Ok, so it does sound like an issue in the experimental client and not NFSv4. For the most part, the read code is the same as the regular client, but it hasn't been brought up-to-date with recent changes. One thing you could try is building a kernel without SMP enabled and see if that helps? (I only have single core hardware, so I won't see any SMP races.) If that helps, I can compare the regular vs experimental client for smp locking in the read stuff. rick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
page fault in e1000_clear_hw_cntrs_base_generic() during SIOCAIFADDR
Hi. This is reproducible from time to time on boot when handling SIOCAIFADDR called from ifconfig on igb on fresh (and not so fresh) 8-STABLE. How can I help with debugging? Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex igb0 (IGB Core Lock) r = 0 (0xc2655534) locked @ /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:965 KDB: stack backtrace: db_trace_self_wrapper(c08b5055,cce577b8,c060db15,3c5,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(3c5,0,,c0a94864,cce577f0,...) at kdb_backtrace+0x29 _witness_debugger(c08b74fe,cce57804,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c08e3140,cce5782c,c2956000,...) at witness_warn+0x1fe trap(cce57890) at trap+0x195 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc3192477, esp = 0xcce578d0, ebp = 0xcce578e0 --- e1000_clear_hw_cntrs_base_generic(c2651004,64,c3185850,c2651000,0,...) at e1000_clear_hw_cntrs_base_generic+0x3e7 igb_init_locked(c2655534,0,c31ac72f,3c5,c31c3d00,...) at igb_init_locked+0x16e2 igb_ioctl(c2642c00,8020690c,c31c3d00,cce57a8c,c457ea9b,...) at igb_ioctl+0x495 in_ifinit(0,c08c391b,1aa,1a6,c2642c00,...) at in_ifinit+0x29e in_control(c2a58b44,8040691a,c31bd100,c2642c00,c2948000,...) at in_control+0xccb ifioctl(c2a58b44,8040691a,c31bd100,c2948000,c31c3b00,...) at ifioctl+0x1820 soo_ioctl(c29b7bd0,8040691a,c31bd100,c254b100,c2948000,...) at soo_ioctl+0x415 kern_ioctl(c2948000,3,8040691a,c31bd100,6073c0,...) at kern_ioctl+0x1fd ioctl(c2948000,cce57cf8,c08e3073,c08c398f,c2956000,...) at ioctl+0x134 syscall(cce57d38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281c1543, esp = 0xbfbfe60c, ebp = 0xbfbfe648 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xcc5af000 fault code = supervisor read, page not present instruction pointer = 0x20:0xc3192477 stack pointer = 0x28:0xcce578d0 frame pointer = 0x28:0xcce578e0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 700 (ifconfig) db> show ifnet 0xc2642c00 igb0: if_dname = igb if_dunit = 0 if_description = (null) if_index = 2 if_refcount = 2 if_softc = 0xc2651000 if_l2com = 0xc2676b80 if_vnet = 0 if_home_vnet = 0 if_addr = 0xc31c4500 if_llsoftc = 0 if_label = 0 if_pcount = 0 if_flags = 0x8803 if_drv_flags = 0x0040 if_capabilities = 0x000101bb if_capenable = 0x01bb if_snd.ifq_head = 0 if_snd.ifq_tail = 0 if_snd.ifq_len = 0 if_snd.ifq_maxlen = 1023 if_snd.ifq_drops = 0 if_snd.ifq_drv_head = 0 if_snd.ifq_drv_tail = 0 if_snd.ifq_drv_len = 0 if_snd.ifq_drv_maxlen = 1023 if_snd.altq_type = 0 if_snd.altq_flags = 1 -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NFS 75 second stall
On 07/01/10 15:23, Garrett Cooper wrote: On Thu, Jul 1, 2010 at 11:51 AM, alan bryan wrote: --- On Thu, 7/1/10, Garrett Cooper wrote: From: Garrett Cooper Subject: Re: NFS 75 second stall To: "alan bryan" Cc: freebsd-stable@freebsd.org Date: Thursday, July 1, 2010, 11:13 AM On Thu, Jul 1, 2010 at 11:01 AM, alan bryan wrote: Setup: server - FreeBSD 8-stable from today. 2 UFS dirs exported via NFS. client - FreeBSD 8.0-Release. Running a test php script that copies around various files to/from 2 separate NFS mounts. Situation: script is started (forked to do 20 simultaneous runs) and 20 1GB files are copied to the NFS dir which works fine. When it then switches to reading those files back and simultaneously writing to the other NFS mount I see a hang of 75 seconds. If I do an "ls -l" on the NFS mount it hangs too. After 75 seconds the client has reported: nfs server 192.168.10.133:/usr/local/export1: not responding nfs server 192.168.10.133:/usr/local/export1: is alive again nfs server 192.168.10.133:/usr/local/export1: not responding nfs server 192.168.10.133:/usr/local/export1: is alive again and then things start working again. The server was originally FreeBSD 8.0-Release also but was upgraded to the latest stable to see if this issue could be avoided. # nfsstat -s -W -w 1 GtAttr Lookup Rdlink Read Write Rename Access Rddir 0 0 0222257 0 0 0 0 0 0178135 0 0 0 0 0 0 85127 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ... for 75 rows of all zeros 0 0 0272266 0 0 0 0 0 0167165 0 0 0 I also tried runs with 15 simultaneous processes and 25. 15 processes gave only about a 5 second stall but 25 gave again the same 75 second stall. Further, I tested with 2 mounts to the same server but from ZFS filesytems with the exact same stall/timeout periods. So, it doesn't appear to matter what the underlying filesystem is - it's something in NFS or networking code. Any ideas on what's going on here? What's causing the complete stall period of zero NFS activity? Any flaws with my testing methods? Thanks for any and all help/ideas. What network driver are you using? Have you tried tcpdumping the packets? -Garrett I'm using igb currently but have also used em. I have not tried tcpdumping the packets yet on this test. Any suggestions on things to look out for (I'm not that familiar with that whole process). Which brings up another point - I'm using TCP connections for NFS, not UDP. Is the net.inet.tcp.tso sysctl enabled or not? What about rxcsum and txcsum? Thanks, -Garrett We're occaisionally seeing these same types of stalls (+ repeated "is not responding" "is alive again" messages in quick succession). We're seeing it only on our 8.1-RELEASE systems against a variety of NFS servers (6.3-RELEASE, 7.2-RELEASE, and 8-STABLE from before the release of 8.1). We also see it happen with a variety of client hardware and network adapters (em, bce, bge); the only common denominator is 8.1-RELEASE on the clients. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: NFS 75 second stall
> On 07/01/10 15:23, Garrett Cooper wrote:
> > On Thu, Jul 1, 2010 at 11:51 AM, alan bryan
> > wrote:
> >>
> >> --- On Thu, 7/1/10, Garrett Cooper wrote:
> >>
> >>> From: Garrett Cooper
> >>> Subject: Re: NFS 75 second stall
> >>> To: "alan bryan"
> >>> Cc: freebsd-stable@freebsd.org
> >>> Date: Thursday, July 1, 2010, 11:13 AM
> >>> On Thu, Jul 1, 2010 at 11:01 AM, alan
> >>> bryan
> >>> wrote:
> Setup:
>
> server - FreeBSD 8-stable from today. 2 UFS dirs
> >>> exported via NFS.
> client - FreeBSD 8.0-Release. Running a test php
> >>> script that copies around various files to/from 2 separate
> >>> NFS mounts.
> Situation:
>
> script is started (forked to do 20 simultaneous runs)
> >>> and 20 1GB files are copied to the NFS dir which works
> >>> fine. When it then switches to reading those files back
> >>> and simultaneously writing to the other NFS mount I see a
> >>> hang of 75 seconds. If I do an "ls -l" on the NFS mount it
> >>> hangs too. After 75 seconds the client has reported:
> nfs server 192.168.10.133:/usr/local/export1: not
> >>> responding
> nfs server 192.168.10.133:/usr/local/export1: is alive
> >>> again
> nfs server 192.168.10.133:/usr/local/export1: not
> >>> responding
> nfs server 192.168.10.133:/usr/local/export1: is alive
> >>> again
> and then things start working again. The server was
> >>> originally FreeBSD 8.0-Release also but was upgraded to the
> >>> latest stable to see if this issue could be avoided.
> # nfsstat -s -W -w 1
> GtAttr Lookup Rdlink Read Write Rename
> >>> Access Rddir
> 0 0 0 222 257
> >>>0 0 0
> 0 0 0 178 135
> >>>0 0 0
> 0 0 0 85 127
> >>> 0 0 0
> 0 0 0 0 0
> >>> 0 0 0
> 0 0 0 0 0
> >>> 0 0 0
> 0 0 0 0 0
> >>> 0 0 0
> 0 0 0 0 0
> >>> 0 0 0
> 0 0 0 0 0
> >>> 0 0 0
> ... for 75 rows of all zeros
>
> 0 0 0 272 266
> >>>0 0 0
> 0 0 0 167 165
> >>>0 0 0
> I also tried runs with 15 simultaneous processes and
> >>> 25. 15 processes gave only about a 5 second stall but 25
> >>> gave again the same 75 second stall.
> Further, I tested with 2 mounts to the same server but
> >>> from ZFS filesytems with the exact same stall/timeout
> >>> periods. So, it doesn't appear to matter what the
> >>> underlying filesystem is - it's something in NFS or
> >>> networking code.
> Any ideas on what's going on here? What's causing
> >>> the complete stall period of zero NFS activity? Any flaws
> >>> with my testing methods?
> Thanks for any and all help/ideas.
> >>> What network driver are you using? Have you tried
> >>> tcpdumping the packets?
> >>> -Garrett
> >>>
> >> I'm using igb currently but have also used em. I have not tried
> >> tcpdumping the packets yet on this test. Any suggestions on things
> >> to look out for (I'm not that familiar with that whole process).
> >>
> >> Which brings up another point - I'm using TCP connections for NFS,
> >> not UDP.
> > Is the net.inet.tcp.tso sysctl enabled or not? What about
> > rxcsum and txcsum?
> > Thanks,
> > -Garrett
>
> We're occaisionally seeing these same types of stalls (+ repeated "is
> not responding" "is alive again" messages in quick succession). We're
> seeing it only on our 8.1-RELEASE systems against a variety of NFS
> servers (6.3-RELEASE, 7.2-RELEASE, and 8-STABLE from before the
> release
> of 8.1). We also see it happen with a variety of client hardware and
> network adapters (em, bce, bge); the only common denominator is
> 8.1-RELEASE on the clients.
>
You could try the attached patch. It won't fix anything, but it
should print out what the errno is that is causing a TCP reconnect
and might give us a hint w.r.t. what is going on.
rick
--- rpc/clnt_rc.c.sav 2010-09-01 10:56:56.0 -0400
+++ rpc/clnt_rc.c 2010-09-01 11:00:49.0 -0400
@@ -264,6 +264,7 @@
mtx_unlock(&rc->rc_lock);
stat = clnt_reconnect_connect(cl);
if (stat == RPC_SYSTEMERROR) {
+printf("recon err=%d\n", rpc_createerr.cf_error.re_errno);
error = tsleep(&fake_wchan,
rc->rc_intr ? PCATCH | PBDRY : 0, "rpccon",
hz);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: page fault in e1000_clear_hw_cntrs_base_generic() during SIOCAIFADDR
On Wednesday, September 01, 2010 11:53:09 am pluknet wrote: > Hi. > > This is reproducible from time to time on boot when > handling SIOCAIFADDR called from ifconfig on igb > on fresh (and not so fresh) 8-STABLE. > > How can I help with debugging? > > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex igb0 (IGB Core Lock) r = 0 (0xc2655534) locked @ > /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:965 > KDB: stack backtrace: > db_trace_self_wrapper(c08b5055,cce577b8,c060db15,3c5,0,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(3c5,0,,c0a94864,cce577f0,...) at kdb_backtrace+0x29 > _witness_debugger(c08b74fe,cce57804,4,1,0,...) at _witness_debugger+0x25 > witness_warn(5,0,c08e3140,cce5782c,c2956000,...) at witness_warn+0x1fe > trap(cce57890) at trap+0x195 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0xc3192477, esp = 0xcce578d0, ebp = 0xcce578e0 --- > e1000_clear_hw_cntrs_base_generic(c2651004,64,c3185850,c2651000,0,...) > at e1000_clear_hw_cntrs_base_generic+0x3e7 Can you use gdb on your kernel.debug to map this to a source file and line? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon
> On November 30th, FreeBSD 6.4 and FreeBSD 8.0 will have reached their FreeBSD -7 & -8 do not support ISDN I'm told. So 6.4 is the last working FreeBSD ISDN. DSL is faster than ISDN, but Losing ISDN would be unfortunate: - Not all can get DSL speed, if they live far from phone exchange. - ISDN allows one more security (caller ID comes from phone company), additional to whatever crypto keys/passwords. - ISDN on the PC allows one to have Name (via lookup of number) of phone caller & which incoming destination number received call, show up on an X Term - I've had that with FreeBSD over 10+ years now :-) Could easily be hooked to a database springing up a a custome xterm according to calling customer ID, called number & time of day (all being used to select which service info ) But if we drop ISDN ...! Could FreeBSD reinsert ISDN back into current/8/7 support ? Perhaps via: - a student SOC project ? - FreeBSD foundation paying a FreeBSD consultant (I know one who has the expertise already, has the time, & could use some money (I don't mean me, & he didn't aske me to post this, it'll come as a suprise to him :-) - Or whatever other method to get ISDN back in kernel ? Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML, quoted-printable & base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
GSSAPI (for OpenLDAP) on FreeBSD 8?
I have got problems with GSSAPI authentication to OpenLDAP: ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible. (unknown mech-code 0 for mech unknown) There were at least two discussions, multiple bug reports, and patches about broken GSSAPI on FreeBSD 8, the longest (I found) starting here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057734.html After reading through these discussions, I do not know what the proper fix is -- I would like to change as little as possible introducing SASL authentication to a (production) OpenLDAP server. I have got: An i386 kerberos server, a ldap server in a jail on i386, some amd64 clients -- all running 8.1-RELEASE. Eventually there need to be some Debian/Ubuntu clients using GSSAPI/SASL, too. What do I need to "fix"? Just the ldap server? Is it enough to change the jail or does the host needs to be patches, too? Or do I need to fix the client, too? The kerberos server? From the discussion, multiple fixes were possible. Patching libgssapi and reinstalling everything depending on it (what?), installing the heimdal-1.0 port (while FreeBSD 8 comes with heimdal-1.1), installing an unofficial heimdal-1.2 port, ... Is that correct? Anything new after the discussion in July? From the discussion, some patches should already be in 8-STABLE, but I could not find the revision (after 8.1-RELEASE). If I upgraded the ldap jail to 8-STABLE, I guess the host needs to be updated, too. Hence I would prefer to just change ports or update single libraries. Does anyone have OpenLDAP+GSSAPI running on FreeBSD 8? With the libgssapi patch? With the heimdal-1.2 port? Thanks, Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon
> FreeBSD -7 & -8 do not support ISDN I'm told. > So 6.4 is the last working FreeBSD ISDN. > Could FreeBSD reinsert ISDN back into current/8/7 support ? > Perhaps via: > - a student SOC project ? > - FreeBSD foundation paying a FreeBSD consultant (I know one who has the > expertise already, has the time, & could use some money (I don't mean me, > & he didn't aske me to post this, it'll come as a suprise to him :-) > - Or whatever other method to get ISDN back in kernel ? It seems code exists :-) http://old.nabble.com/ISDN4BSD-on-8-current-td23919925.html ISDN4BSD package has been updated to compile on FreeBSD 8-current http://www.selasky.org/hans_petter/isdn4bsd/ Apparently needs massaging into main FreeBSD tree. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML, quoted-printable & base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: page fault in e1000_clear_hw_cntrs_base_generic() during SIOCAIFADDR
On 1 September 2010 20:06, John Baldwin wrote:
> On Wednesday, September 01, 2010 11:53:09 am pluknet wrote:
>> Hi.
>>
>> This is reproducible from time to time on boot when
>> handling SIOCAIFADDR called from ifconfig on igb
>> on fresh (and not so fresh) 8-STABLE.
>>
>> How can I help with debugging?
>>
>> Kernel page fault with the following non-sleepable locks held:
>> exclusive sleep mutex igb0 (IGB Core Lock) r = 0 (0xc2655534) locked @
>> /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:965
>> KDB: stack backtrace:
>> db_trace_self_wrapper(c08b5055,cce577b8,c060db15,3c5,0,...) at
>> db_trace_self_wrapper+0x26
>> kdb_backtrace(3c5,0,,c0a94864,cce577f0,...) at kdb_backtrace+0x29
>> _witness_debugger(c08b74fe,cce57804,4,1,0,...) at _witness_debugger+0x25
>> witness_warn(5,0,c08e3140,cce5782c,c2956000,...) at witness_warn+0x1fe
>> trap(cce57890) at trap+0x195
>> calltrap() at calltrap+0x6
>> --- trap 0xc, eip = 0xc3192477, esp = 0xcce578d0, ebp = 0xcce578e0 ---
>> e1000_clear_hw_cntrs_base_generic(c2651004,64,c3185850,c2651000,0,...)
>> at e1000_clear_hw_cntrs_base_generic+0x3e7
>
> Can you use gdb on your kernel.debug to map this to a source file and line?
>
Here it is (btw, it took about 10-15 reboots to reproduce after adding
swap and dumpon setup).
Hmm.. don't see where it might access an invalid pointer.
#0 doadump () at pcpu.h:231
#1 0xc04a3679 in db_fncall (dummy1=1, dummy2=0, dummy3=-1062122144,
dummy4=0xcce636a8 "") at /usr/src/sys/ddb/db_command.c:548
#2 0xc04a3a71 in db_command (last_cmdp=0xc093d19c, cmd_table=0x0, dopager=1)
at /usr/src/sys/ddb/db_command.c:445
#3 0xc04a3bca in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
#4 0xc04a5aed in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229
#5 0xc05fa64e in kdb_trap (type=12, code=0, tf=0xcce63890)
at /usr/src/sys/kern/subr_kdb.c:535
#6 0xc084dcdf in trap_fatal (frame=0xcce63890, eva=3428511744)
at /usr/src/sys/i386/i386/trap.c:929
#7 0xc084e553 in trap (frame=0xcce63890) at /usr/src/sys/i386/i386/trap.c:328
#8 0xc082f66c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
#9 0xc318c477 in e1000_clear_hw_cntrs_base_generic (hw=0xc2655004)
at /usr/src/sys/modules/igb/../../dev/e1000/e1000_mac.c:643
#10 0xc317ec82 in igb_init_locked (adapter=0xc2655000)
at /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:1202
#11 0xc31801e5 in igb_ioctl (ifp=0xc2943c00, command=2149607692,
data=0xc29db600 "╢╤\235бд╤\235бт╤\235б")
at /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:966
#12 0xc0696c4e in in_ifinit (ifp=0xc2943c00, ia=0xc29db600,
sin=Variable "sin" is not available.
)
at /usr/src/sys/netinet/in.c:848
#13 0xc06980cb in in_control (so=0xc2a5d9a8, cmd=2151704858,
data=0xc2649400 "igb0", ifp=0xc2943c00, td=0xc29b8280)
---Type to continue, or q to quit---
at /usr/src/sys/netinet/in.c:563
#14 0xc067c860 in ifioctl (so=0xc2a5d9a8, cmd=2151704858,
data=0xc2649400 "igb0", td=0xc29b8280) at /usr/src/sys/net/if.c:2523
#15 0xc0617395 in soo_ioctl (fp=0xc29ce310, cmd=2151704858, data=0xc2649400,
active_cred=0xc254b100, td=0xc29b8280)
at /usr/src/sys/kern/sys_socket.c:212
#16 0xc06113dd in kern_ioctl (td=0xc29b8280, fd=3, com=2151704858,
data=0xc2649400 "igb0") at file.h:262
#17 0xc0611564 in ioctl (td=0xc29b8280, uap=0xcce63cf8)
at /usr/src/sys/kern/sys_generic.c:678
#18 0xc084e160 in syscall (frame=0xcce63d38)
at /usr/src/sys/i386/i386/trap.c:
#19 0xc082f6d1 in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:264
#20 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) f 9
#9 0xc318c477 in e1000_clear_hw_cntrs_base_generic (hw=0xc2655004)
at /usr/src/sys/modules/igb/../../dev/e1000/e1000_mac.c:643
643 E1000_READ_REG(hw, E1000_SYMERRS);
(kgdb) list
638 void e1000_clear_hw_cntrs_base_generic(struct e1000_hw *hw)
639 {
640 DEBUGFUNC("e1000_clear_hw_cntrs_base_generic");
641
642 E1000_READ_REG(hw, E1000_CRCERRS);
643 E1000_READ_REG(hw, E1000_SYMERRS);
644 E1000_READ_REG(hw, E1000_MPC);
645 E1000_READ_REG(hw, E1000_SCC);
646 E1000_READ_REG(hw, E1000_ECOL);
647 E1000_READ_REG(hw, E1000_MCC);
(kgdb) p *(struct e1000_osdep *)hw->back
$6 = {mem_bus_space_tag = 1, mem_bus_space_handle = 3428495360,
io_bus_space_tag = 0, io_bus_space_handle = 0, flash_bus_space_tag = 0,
flash_bus_space_handle = 0, dev = 0xc261a600}
(kgdb) p *hw
[...]
power_down = 0xc3186340 }, type = e1000_phy_vf,
[...]
(kgdb) p (struct e1000_mac_info *)hw->mac.type
$8 = (struct e1000_mac_info *) 0x1a
(kgdb) p *(struct e1000_mac_info *)hw->mac
$10 = {ops = {init_params = 0x8be58955, id_led_init = 0x80c70845,
blink_led = 0x390, check_for_link = 0, check_mng_mode = 0x2d480c7,
cleanup_led = 0, clear_hw_cntrs = 0x80c7, clear_vfta = 0x2d0,
get_bus_info = 0, set_lan_id = 0x2c880c7, get_link_up_info = 0,
led_on
Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon
On Wednesday 01 September 2010 18:53:46 Julian H. Stacey wrote: > > FreeBSD -7 & -8 do not support ISDN I'm told. > > So 6.4 is the last working FreeBSD ISDN. > > > > Could FreeBSD reinsert ISDN back into current/8/7 support ? > > Perhaps via: > > - a student SOC project ? > > - FreeBSD foundation paying a FreeBSD consultant (I know one who has the > > > > expertise already, has the time, & could use some money (I don't mean > > me, & he didn't aske me to post this, it'll come as a suprise to him > > :-) > > > > - Or whatever other method to get ISDN back in kernel ? > > It seems code exists :-) > > http://old.nabble.com/ISDN4BSD-on-8-current-td23919925.html > ISDN4BSD package has been updated to compile on FreeBSD > 8-current > > http://www.selasky.org/hans_petter/isdn4bsd/ > > Apparently needs massaging into main FreeBSD tree. I agree that my I4B code should be re-written somewhat before committed. Possibly we should update the API's present too, to support IP-telephony aswell. --HPS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon
"Julian H. Stacey" writes: Hello, > FreeBSD -7 & -8 do not support ISDN I'm told. It seems that hps@ maintains an isdn stack outside of freebsd tree : http://www.selasky.org/hans_petter/isdn4bsd/ Regards Éric Masson -- >Une RedHat (je ne connais pas les autres distributions) ce configure >aussi simplement que windows pour un poste client. Hélas, elle génère un maximum de traffic sur Usenet -+- TP in guide du linuxien pervers - "Je veux revoir ma SLS ! -+- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: page fault in e1000_clear_hw_cntrs_base_generic() during SIOCAIFADDR
On Wednesday, September 01, 2010 1:11:31 pm pluknet wrote:
> On 1 September 2010 20:06, John Baldwin wrote:
> > On Wednesday, September 01, 2010 11:53:09 am pluknet wrote:
> >> Hi.
> >>
> >> This is reproducible from time to time on boot when
> >> handling SIOCAIFADDR called from ifconfig on igb
> >> on fresh (and not so fresh) 8-STABLE.
> >>
> >> How can I help with debugging?
> >>
> >> Kernel page fault with the following non-sleepable locks held:
> >> exclusive sleep mutex igb0 (IGB Core Lock) r = 0 (0xc2655534) locked @
> >> /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:965
> >> KDB: stack backtrace:
> >> db_trace_self_wrapper(c08b5055,cce577b8,c060db15,3c5,0,...) at
> >> db_trace_self_wrapper+0x26
> >> kdb_backtrace(3c5,0,,c0a94864,cce577f0,...) at kdb_backtrace+0x29
> >> _witness_debugger(c08b74fe,cce57804,4,1,0,...) at _witness_debugger+0x25
> >> witness_warn(5,0,c08e3140,cce5782c,c2956000,...) at witness_warn+0x1fe
> >> trap(cce57890) at trap+0x195
> >> calltrap() at calltrap+0x6
> >> --- trap 0xc, eip = 0xc3192477, esp = 0xcce578d0, ebp = 0xcce578e0 ---
> >> e1000_clear_hw_cntrs_base_generic(c2651004,64,c3185850,c2651000,0,...)
> >> at e1000_clear_hw_cntrs_base_generic+0x3e7
> >
> > Can you use gdb on your kernel.debug to map this to a source file and
line?
> >
>
> Here it is (btw, it took about 10-15 reboots to reproduce after adding
> swap and dumpon setup).
> Hmm.. don't see where it might access an invalid pointer.
>
> #0 doadump () at pcpu.h:231
> #1 0xc04a3679 in db_fncall (dummy1=1, dummy2=0, dummy3=-1062122144,
> dummy4=0xcce636a8 "") at /usr/src/sys/ddb/db_command.c:548
> #2 0xc04a3a71 in db_command (last_cmdp=0xc093d19c, cmd_table=0x0,
dopager=1)
> at /usr/src/sys/ddb/db_command.c:445
> #3 0xc04a3bca in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
> #4 0xc04a5aed in db_trap (type=12, code=0) at
/usr/src/sys/ddb/db_main.c:229
> #5 0xc05fa64e in kdb_trap (type=12, code=0, tf=0xcce63890)
> at /usr/src/sys/kern/subr_kdb.c:535
> #6 0xc084dcdf in trap_fatal (frame=0xcce63890, eva=3428511744)
> at /usr/src/sys/i386/i386/trap.c:929
> #7 0xc084e553 in trap (frame=0xcce63890) at
/usr/src/sys/i386/i386/trap.c:328
> #8 0xc082f66c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
> #9 0xc318c477 in e1000_clear_hw_cntrs_base_generic (hw=0xc2655004)
> at /usr/src/sys/modules/igb/../../dev/e1000/e1000_mac.c:643
> #10 0xc317ec82 in igb_init_locked (adapter=0xc2655000)
> at /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:1202
> #11 0xc31801e5 in igb_ioctl (ifp=0xc2943c00, command=2149607692,
> data=0xc29db600 "╢╤\235бд╤\235бт╤\235б")
> at /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:966
> #12 0xc0696c4e in in_ifinit (ifp=0xc2943c00, ia=0xc29db600,
> sin=Variable "sin" is not available.
> )
> at /usr/src/sys/netinet/in.c:848
> #13 0xc06980cb in in_control (so=0xc2a5d9a8, cmd=2151704858,
> data=0xc2649400 "igb0", ifp=0xc2943c00, td=0xc29b8280)
> ---Type to continue, or q to quit---
> at /usr/src/sys/netinet/in.c:563
> #14 0xc067c860 in ifioctl (so=0xc2a5d9a8, cmd=2151704858,
> data=0xc2649400 "igb0", td=0xc29b8280) at /usr/src/sys/net/if.c:2523
> #15 0xc0617395 in soo_ioctl (fp=0xc29ce310, cmd=2151704858, data=0xc2649400,
> active_cred=0xc254b100, td=0xc29b8280)
> at /usr/src/sys/kern/sys_socket.c:212
> #16 0xc06113dd in kern_ioctl (td=0xc29b8280, fd=3, com=2151704858,
> data=0xc2649400 "igb0") at file.h:262
> #17 0xc0611564 in ioctl (td=0xc29b8280, uap=0xcce63cf8)
> at /usr/src/sys/kern/sys_generic.c:678
> #18 0xc084e160 in syscall (frame=0xcce63d38)
> at /usr/src/sys/i386/i386/trap.c:
> #19 0xc082f6d1 in Xint0x80_syscall ()
> at /usr/src/sys/i386/i386/exception.s:264
> #20 0x0033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
>
> (kgdb) f 9
> #9 0xc318c477 in e1000_clear_hw_cntrs_base_generic (hw=0xc2655004)
> at /usr/src/sys/modules/igb/../../dev/e1000/e1000_mac.c:643
> 643 E1000_READ_REG(hw, E1000_SYMERRS);
> (kgdb) list
> 638 void e1000_clear_hw_cntrs_base_generic(struct e1000_hw *hw)
> 639 {
> 640 DEBUGFUNC("e1000_clear_hw_cntrs_base_generic");
> 641
> 642 E1000_READ_REG(hw, E1000_CRCERRS);
> 643 E1000_READ_REG(hw, E1000_SYMERRS);
> 644 E1000_READ_REG(hw, E1000_MPC);
> 645 E1000_READ_REG(hw, E1000_SCC);
> 646 E1000_READ_REG(hw, E1000_ECOL);
> 647 E1000_READ_REG(hw, E1000_MCC);
>
> (kgdb) p *(struct e1000_osdep *)hw->back
> $6 = {mem_bus_space_tag = 1, mem_bus_space_handle = 3428495360,
> io_bus_space_tag = 0, io_bus_space_handle = 0, flash_bus_space_tag = 0,
> flash_bus_space_handle = 0, dev = 0xc261a600}
>
> (kgdb) p *hw
> [...]
> power_down = 0xc3186340 }, type =
e1000_phy_vf,
> [...]
>
> (kgdb) p (struct e1000_mac_info *)hw->mac.type
> $8 = (struct e1000_mac_info *) 0x1a
>
> (kgdb) p *(struct e1000_mac_info *)hw->mac
> $10 = {
Re: page fault in e1000_clear_hw_cntrs_base_generic() during SIOCAIFADDR
LOL, if its the VF its pretty new code, PLEASE anyone, if this is the case
make it clear in the title somewhere, ok? Thanks.
Jack
On Wed, Sep 1, 2010 at 10:24 AM, John Baldwin wrote:
> On Wednesday, September 01, 2010 1:11:31 pm pluknet wrote:
> > On 1 September 2010 20:06, John Baldwin wrote:
> > > On Wednesday, September 01, 2010 11:53:09 am pluknet wrote:
> > >> Hi.
> > >>
> > >> This is reproducible from time to time on boot when
> > >> handling SIOCAIFADDR called from ifconfig on igb
> > >> on fresh (and not so fresh) 8-STABLE.
> > >>
> > >> How can I help with debugging?
> > >>
> > >> Kernel page fault with the following non-sleepable locks held:
> > >> exclusive sleep mutex igb0 (IGB Core Lock) r = 0 (0xc2655534) locked @
> > >> /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:965
> > >> KDB: stack backtrace:
> > >> db_trace_self_wrapper(c08b5055,cce577b8,c060db15,3c5,0,...) at
> > >> db_trace_self_wrapper+0x26
> > >> kdb_backtrace(3c5,0,,c0a94864,cce577f0,...) at
> kdb_backtrace+0x29
> > >> _witness_debugger(c08b74fe,cce57804,4,1,0,...) at
> _witness_debugger+0x25
> > >> witness_warn(5,0,c08e3140,cce5782c,c2956000,...) at witness_warn+0x1fe
> > >> trap(cce57890) at trap+0x195
> > >> calltrap() at calltrap+0x6
> > >> --- trap 0xc, eip = 0xc3192477, esp = 0xcce578d0, ebp = 0xcce578e0 ---
> > >> e1000_clear_hw_cntrs_base_generic(c2651004,64,c3185850,c2651000,0,...)
> > >> at e1000_clear_hw_cntrs_base_generic+0x3e7
> > >
> > > Can you use gdb on your kernel.debug to map this to a source file and
> line?
> > >
> >
> > Here it is (btw, it took about 10-15 reboots to reproduce after adding
> > swap and dumpon setup).
> > Hmm.. don't see where it might access an invalid pointer.
> >
> > #0 doadump () at pcpu.h:231
> > #1 0xc04a3679 in db_fncall (dummy1=1, dummy2=0, dummy3=-1062122144,
> > dummy4=0xcce636a8 "") at /usr/src/sys/ddb/db_command.c:548
> > #2 0xc04a3a71 in db_command (last_cmdp=0xc093d19c, cmd_table=0x0,
> dopager=1)
> > at /usr/src/sys/ddb/db_command.c:445
> > #3 0xc04a3bca in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
> > #4 0xc04a5aed in db_trap (type=12, code=0) at
> /usr/src/sys/ddb/db_main.c:229
> > #5 0xc05fa64e in kdb_trap (type=12, code=0, tf=0xcce63890)
> > at /usr/src/sys/kern/subr_kdb.c:535
> > #6 0xc084dcdf in trap_fatal (frame=0xcce63890, eva=3428511744)
> > at /usr/src/sys/i386/i386/trap.c:929
> > #7 0xc084e553 in trap (frame=0xcce63890) at
> /usr/src/sys/i386/i386/trap.c:328
> > #8 0xc082f66c in calltrap () at /usr/src/sys/i386/i386/exception.s:166
> > #9 0xc318c477 in e1000_clear_hw_cntrs_base_generic (hw=0xc2655004)
> > at /usr/src/sys/modules/igb/../../dev/e1000/e1000_mac.c:643
> > #10 0xc317ec82 in igb_init_locked (adapter=0xc2655000)
> > at /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:1202
> > #11 0xc31801e5 in igb_ioctl (ifp=0xc2943c00, command=2149607692,
> > data=0xc29db600 "╢╤\235бд╤\235бт╤\235б")
> > at /usr/src/sys/modules/igb/../../dev/e1000/if_igb.c:966
> > #12 0xc0696c4e in in_ifinit (ifp=0xc2943c00, ia=0xc29db600,
> > sin=Variable "sin" is not available.
> > )
> > at /usr/src/sys/netinet/in.c:848
> > #13 0xc06980cb in in_control (so=0xc2a5d9a8, cmd=2151704858,
> > data=0xc2649400 "igb0", ifp=0xc2943c00, td=0xc29b8280)
> > ---Type to continue, or q to quit---
> > at /usr/src/sys/netinet/in.c:563
> > #14 0xc067c860 in ifioctl (so=0xc2a5d9a8, cmd=2151704858,
> > data=0xc2649400 "igb0", td=0xc29b8280) at /usr/src/sys/net/if.c:2523
> > #15 0xc0617395 in soo_ioctl (fp=0xc29ce310, cmd=2151704858,
> data=0xc2649400,
> > active_cred=0xc254b100, td=0xc29b8280)
> > at /usr/src/sys/kern/sys_socket.c:212
> > #16 0xc06113dd in kern_ioctl (td=0xc29b8280, fd=3, com=2151704858,
> > data=0xc2649400 "igb0") at file.h:262
> > #17 0xc0611564 in ioctl (td=0xc29b8280, uap=0xcce63cf8)
> > at /usr/src/sys/kern/sys_generic.c:678
> > #18 0xc084e160 in syscall (frame=0xcce63d38)
> > at /usr/src/sys/i386/i386/trap.c:
> > #19 0xc082f6d1 in Xint0x80_syscall ()
> > at /usr/src/sys/i386/i386/exception.s:264
> > #20 0x0033 in ?? ()
> > Previous frame inner to this frame (corrupt stack?)
> >
> > (kgdb) f 9
> > #9 0xc318c477 in e1000_clear_hw_cntrs_base_generic (hw=0xc2655004)
> > at /usr/src/sys/modules/igb/../../dev/e1000/e1000_mac.c:643
> > 643 E1000_READ_REG(hw, E1000_SYMERRS);
> > (kgdb) list
> > 638 void e1000_clear_hw_cntrs_base_generic(struct e1000_hw *hw)
> > 639 {
> > 640 DEBUGFUNC("e1000_clear_hw_cntrs_base_generic");
> > 641
> > 642 E1000_READ_REG(hw, E1000_CRCERRS);
> > 643 E1000_READ_REG(hw, E1000_SYMERRS);
> > 644 E1000_READ_REG(hw, E1000_MPC);
> > 645 E1000_READ_REG(hw, E1000_SCC);
> > 646 E1000_READ_REG(hw, E1000_ECOL);
> > 647 E1000_READ_REG(hw, E1000_MCC);
> >
> > (kgdb) p *(struct e1000_osdep *)hw->back
> > $6 = {mem_bus_space_tag = 1, mem_bus_space_h
Re: page fault in e1000_clear_hw_cntrs_base_generic() during SIOCAIFADDR
On 1 September 2010 21:31, Jack Vogel wrote: > LOL, if its the VF its pretty new code, PLEASE anyone, if this is the case > make it clear in the title somewhere, ok? Thanks. > Sure, this is the VF. I'm sorry, I didn't mention this directly. -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.1-PRERELEASE: CPU packages not detected correctly
On Friday 27 August 2010 03:36 pm, Jung-uk Kim wrote: > [3] AMD is working on an SMT-capable CPU (code-named Bulldozer) and > my patch won't work on them. If anyone has a Bulldozer sample, > please look into it. I checked AMD website today and found out a new CPUID Spec. Rev. 2.34 was just released: http://support.amd.com/us/Embedded_TechDocs/25481.pdf They have added CPUID 0x801d and 0x801e to detect topology, it seems. Also, CPUID 0x8001 %ecx bit 22 (TopologyExtensions) tells you whether the above CPUID functions are supported. Interesting... Jung-uk Kim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon
Hans Petter Selasky wrote: > On Wednesday 01 September 2010 18:53:46 Julian H. Stacey wrote: > > > FreeBSD -7 & -8 do not support ISDN I'm told. > > > So 6.4 is the last working FreeBSD ISDN. > > > > > > Could FreeBSD reinsert ISDN back into current/8/7 support ? > > > Perhaps via: > > > - a student SOC project ? > > > - FreeBSD foundation paying a FreeBSD consultant (I know one who has the > > > > > > expertise already, has the time, & could use some money (I don't mean > > > me, & he didn't aske me to post this, it'll come as a suprise to him > > > :-) > > > > > > - Or whatever other method to get ISDN back in kernel ? > > > > It seems code exists :-) > > > > http://old.nabble.com/ISDN4BSD-on-8-current-td23919925.html > > ISDN4BSD package has been updated to compile on FreeBSD > > 8-current > > > > http://www.selasky.org/hans_petter/isdn4bsd/ > > > > Apparently needs massaging into main FreeBSD tree. > > I agree that my I4B code should be re-written somewhat before committed. > Possibly we should update the API's present too, to support IP-telephony > aswell. > > --HPS Sorry, I didn't know your code existed, till I was told & searched, Great ! I'll build a new PC soonish to try with current (my gates are 6.2 & 6.4 now). i...@freebsd.org : I just re-subscribed (used to be on long ago). Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML, quoted-printable & base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon
[trimmed cc list] Julian, On 09/01/10 18:09, Julian H. Stacey wrote: On November 30th, FreeBSD 6.4 and FreeBSD 8.0 will have reached their FreeBSD -7& -8 do not support ISDN I'm told. So 6.4 is the last working FreeBSD ISDN. Somebody told you wrong. There's still i4b code in 7-STABLE. It's been axed out for 8-CURRENT short before 8.0-R. So you may want to run 7.x if you depend on ISDN (AFAIK it's still in a working condition for 7). Cheers, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon
Hi, Reference: > From: vol...@vwsoft.com > Date: Wed, 01 Sep 2010 23:10:32 +0200 > Message-id: <4c7ec148.9040...@vwsoft.com> vol...@vwsoft.com wrote: > [trimmed cc list] > > Julian, > > On 09/01/10 18:09, Julian H. Stacey wrote: > >> On November 30th, FreeBSD 6.4 and FreeBSD 8.0 will have reached their > > > > FreeBSD -7& -8 do not support ISDN I'm told. > > So 6.4 is the last working FreeBSD ISDN. > > Somebody told you wrong. Or I maybe misheard. > There's still i4b code in 7-STABLE. It's been axed out for 8-CURRENT > short before 8.0-R. So you may want to run 7.x if you depend on ISDN > (AFAIK it's still in a working condition for 7). Thanks Volker, I've started upgrading a box 7.2 to 7.3-rel then will insert card & try. Any tech issues thay may arise I'll raise on isdn@ Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text, Not HTML, quoted-printable & base 64 dumped with spam. Avoid top posting, It cripples itemised cumulative responses. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: if_rtdel: error 47
Hi,
Without seeing your mpd link configuration, I am guessing the IP address
of all of
the local end points of your ppp links is the same IP address. If that's
the case,
the error message is harmless.
The reason being, for ppp links and in pre 8.0 release, if you try
pinging the local
end IP address, you will see packets are leaked out towards the default
gateway.
I fixed this issue by installing a loopback route for the local end.
Since multiple ppp links all having the same local IP address, but only
one such
loopback route is installed, when links are torn down they would try
deleting but
that entry would stay until the final link referring to that
self-pointing route
is gone.
--Qing
> -Original Message-
> From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd-
> sta...@freebsd.org] On Behalf Of Mike Tancsa
> Sent: Tuesday, August 31, 2010 2:02 PM
> To: freebsd-stable@freebsd.org
> Subject: if_rtdel: error 47
>
> On a RELENG_8 box from aug 25th, I started seeing a constant spew of
>
> Aug 31 00:17:46 gate8 kernel: if_rtdel: error 47
> Aug 31 00:18:29 gate8 kernel: ifa_del_loopback_route: deletion failed
> Aug 31 00:18:29 gate8 kernel: if_rtdel: error 3
> Aug 31 00:18:29 gate8 last message repeated 2 times
> Aug 31 00:18:37 gate8 kernel: ifa_del_loopback_route: deletion failed
> Aug 31 00:18:37 gate8 kernel: if_rtdel: error 3
> Aug 31 00:18:37 gate8 last message repeated 2 times
> Aug 31 00:18:38 gate8 kernel: ifa_del_loopback_route: deletion failed
> Aug 31 00:18:38 gate8 kernel: if_rtdel: error 3
> Aug 31 00:18:38 gate8 last message repeated 2 times
>
>
> What do they mean and how can I find the cause of it ? The box acts
> as an LNS with about 700 ng interfaces with mpd5.5. ipv6 is enabled
> on this server as well, so I am guessing it might be related to ipv6
> as I havent seen it on the other LNS boxes that have the same setup,
> except no ipv6. It was happily running for a few days until this
> error started showing up ?
>
> The error seems to be in sys/if.c
>
> if_rtdel(struct radix_node *rn, void *arg)
> {
> struct rtentry *rt = (struct rtentry *)rn;
> struct ifnet*ifp = arg;
> int err;
>
> if (rt->rt_ifp == ifp) {
>
> /*
> * Protect (sorta) against walktree recursion
problems
> * with cloned routes
> */
> if ((rt->rt_flags & RTF_UP) == 0)
> return (0);
>
> err = rtrequest_fib(RTM_DELETE, rt_key(rt), rt-
> >rt_gateway,
> rt_mask(rt), rt-
> >rt_flags|RTF_RNH_LOCKED,
> (struct rtentry **) NULL, rt-
> >rt_fibnum);
> if (err) {
> log(LOG_WARNING, "if_rtdel: error %d\n",
err);
> }
> }
>
> return (0);
> }
>
>
>
> ---Mike
>
>
>
> Mike Tancsa, tel +1 519 651 3400
> Sentex Communications,m...@sentex.net
> Providing Internet since 1994www.sentex.net
> Cambridge, Ontario Canada www.sentex.net/mike
>
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-
> unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: if_rtdel: error 47
At 06:19 PM 9/1/2010, Li, Qing wrote: Hi, Without seeing your mpd link configuration, I am guessing the IP address of all of the local end points of your ppp links is the same IP address. If that's the case, the error message is harmless. Hi, Thanks for looking! Yes, they are the same. However, I dont see this error on the other box which does not have ipv6 negotiation on the line (set bundle enable ipv6cp). Only since enabling ipv6 negotiation and oddly enough only after a few days did the error start happening. # Create clonable bundle template named B create bundle template B set iface idle 1800 set iface enable tcpmssfix set ipcp disable vjcomp set bundle enable ipv6cp set ipcp deny vjcomp set ipcp ranges xx.yy.zz.6/32 ippool pool1 #set ipcp nbns 127.0.0.1 # Set bundle template to use create link template L l2tp set l2tp disable dataseq set link action bundle B # Enable peer authentication set link disable eap set link enable pap set link disable acfcomp set link disable protocomp set link disable check-magic set link deny acfcomp set link keep-alive 10 60 set link deny protocomp load radius set link mtu 1492 set link mru 1492 set link enable incoming set link disable peer-as-calling I also noticed that the odd time I see as a result of ifconfig ifconfig: ioctl(SIOCGIFAFLAG_IN6): Device not configured ifconfig: ioctl(SIOCGIFINFO_IN6): Device not configured The other issue I noticed was that the link local ipv6 stopped working on a test machine. eg pinging the multicast address on the local link stopped working for some reason ie ping ff02::1%ng155 stopped working on a machine I was testing just the day before. Killing the l2tp session and having it reconnect fixed the issue. OK, another issue I am seeing. The routing table seems to have "junk" in it. eg fe80::21b:21ff:fe53:ca87%ng77 link#84UHS 00 16384 lo0 fe80::%ng78/64 link#85U 00 1448 (Hx~^F(l^N(<80>SL^GV (` (^A fe80::21b:21ff:fe53:ca87%ng78 link#85UHS 00 16384 lo0 fe80::%ng79/64 I will send a you a full copy offlist ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: if_rtdel: error 47
> > Hi, > Thanks for looking! Yes, they are the same. However, I > dont see this error on the other box which does not have ipv6 > negotiation on the line (set bundle enable ipv6cp). Only since > enabling ipv6 negotiation and oddly enough only after a few days did > the error start happening. > I went through the change history and noticed I made the following changelist for IPv4, http://svn.freebsd.org/viewvc/base/head/sys/netinet/in.c?r1=201811&r2=20 3401 Maybe related and something similar needs to be done for IPv6 ... > > The other issue I noticed was that the link local ipv6 stopped > working on a test machine. > eg > pinging the multicast address on the local link stopped working for > some reason > ie ping ff02::1%ng155 > stopped working on a machine I was testing just the day > before. Killing the l2tp session and having it reconnect fixed the > issue. > Nothing obvious comes to mind at the moment. > > OK, another issue I am seeing. The routing table seems to have "junk" > in it. eg > That explains the errno = 47, EAFNOSUPPORT. I also noticed in your routing table output that all of entries that have junk are related to the ng interface. -- Qing ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
csup in repomirror mode dumps core @ stable/8
Dear colleagues, some 2 days ago my repo mirror (stable/8...@amd64) starts dumping core on copying repo: ... SetAttrs CVSROOT-src/Emptydir Edit CVSROOT-src/access,v Segmentation fault (core dumped) deleting files from sup/cvsroot-all/ did not help unfortunately, quick usual `make -DDEBUG_FLAGS=-g' in /usr/src/usr.bin/csup does not work, and I did not dig into this deeply yet, so trace are without parameters: (gdb) bt #0 0x00410676 in rcsdelta_addlog () #1 0x00412b15 in rcsparse_run () #2 0x00412453 in rcsfile_frompath () #3 0x00417c45 in updater_rcsedit () #4 0x00419a59 in updater_batch () #5 0x0041a1d1 in updater () #6 0x004158c4 in thread_start () #7 0x000800a1c511 in pthread_getprio () from /lib/libthr.so.3 #8 0x in ?? () Cannot access memory at address 0x7f1fa000 Any hints? -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: if_rtdel: error 47
At 07:24 PM 9/1/2010, Li, Qing wrote: That explains the errno = 47, EAFNOSUPPORT. I also noticed in your routing table output that all of entries that have junk are related to the ng interface. Is it more to do with the interfaces coming and going or ipv6 ? The non ipv6 enabled mpd box doesnt show this behaviour however. ---Mike -- Qing Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: csup in repomirror mode dumps core @ stable/8
On Thu, Sep 02, 2010 at 03:59:07AM +0400, Dmitry Morozovsky wrote: > Dear colleagues, > > some 2 days ago my repo mirror (stable/8...@amd64) starts dumping core on > copying > repo: > > ... > SetAttrs CVSROOT-src/Emptydir > Edit CVSROOT-src/access,v > Segmentation fault (core dumped) > > deleting files from sup/cvsroot-all/ did not help > > unfortunately, quick usual `make -DDEBUG_FLAGS=-g' in /usr/src/usr.bin/csup > does not work, and I did not dig into this deeply yet, so trace are without > parameters: > > (gdb) bt > #0 0x00410676 in rcsdelta_addlog () > #1 0x00412b15 in rcsparse_run () > #2 0x00412453 in rcsfile_frompath () > #3 0x00417c45 in updater_rcsedit () > #4 0x00419a59 in updater_batch () > #5 0x0041a1d1 in updater () > #6 0x004158c4 in thread_start () > #7 0x000800a1c511 in pthread_getprio () from /lib/libthr.so.3 > #8 0x in ?? () > Cannot access memory at address 0x7f1fa000 > I see it here too on both a 7.2 and 8-stable machine. It looks like something in CVSROOT-src/access,v confuse it because moving that file away make the crash go away. I still have the old access,v if somebody is interested. A diff does not show anything wierd that I can see. John -- John Hay -- j...@meraka.csir.co.za / j...@freebsd.org --- /tmp/access,v-csup.crash2010-07-31 16:57:51.0 +0200 +++ /home/freebsd-cvs/CVSROOT-src/access,v 2010-08-30 22:31:11.0 +0200 @@ -1,10 +1,15 @@ -head 1.941; +head 1.942; access; symbols; locks; strict; comment@# @; +1.942 +date 2010.08.30.20.30.48;author rpaulo; state Exp; +branches; +next 1.941; + 1.941 date 2010.07.31.14.57.38;author philip; state Exp; branches; @@ -4715,11 +4720,13 @@ @@ -1.941 +1.942 log -...@svn rev 210685 on 2010-07-31 14:57:38Z by philip +...@svn rev 212009 on 2010-08-30 20:30:48Z by rpaulo -Take cbzimmer's commit bit into safekeeping per his request. +Please welcome Dimitry Andric (dim@@) as a src committer. Dimitry will be +work on Clang for now. +ed@@ is a co-mentor. Approved by: core @ @@ -4789,6 +4796,7 @@ des dfr dg +dim dougb dumbbell dwhite @@ -4972,6 +4980,19 @@ @ +1.941 +log +...@svn rev 210685 on 2010-07-31 14:57:38Z by philip + +Take cbzimmer's commit bit into safekeeping per his request. + +Approved by: core +@ +text +...@d66 1 +@ + + 1.940 log @SVN rev 210462 on 2010-07-25 10:06:56Z by philip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: csup in repomirror mode dumps core @ stable/8
On Thu, Sep 02, 2010 at 07:56:31AM +0200, John Hay wrote: > On Thu, Sep 02, 2010 at 03:59:07AM +0400, Dmitry Morozovsky wrote: > > Dear colleagues, > > > > some 2 days ago my repo mirror (stable/8...@amd64) starts dumping core on > > copying > > repo: > > > > ... > > SetAttrs CVSROOT-src/Emptydir > > Edit CVSROOT-src/access,v > > Segmentation fault (core dumped) > > > > deleting files from sup/cvsroot-all/ did not help > > > > unfortunately, quick usual `make -DDEBUG_FLAGS=-g' in /usr/src/usr.bin/csup > > does not work, and I did not dig into this deeply yet, so trace are without > > parameters: This won't work. You need to do: make DEBUG_FLAGS="-g3 -ggdb -O0" The important part is not using -D. make.conf variables aren't exported into the compiler environment (I'm not phrasing this eloquently because I don't know how to describe it). The rest of the gcc arguments I provided are highly recommended (especially -O0, otherwise you probably won't get access to any variable data). I can confirm this works, by the way. Look closely at the cc line (past the initial -O2 -pipe -march=nocona). cc -O2 -pipe -march=nocona -I. -I/usr/src/usr.bin/csup/../../contrib/csup -DHAVE_FFLAGS -DNDEBUG -ggdb -g3 -O0 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -c /usr/src/usr.bin/csup/../../contrib/csup/updater.c -- | Jeremy Chadwick j...@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-unsubscr...@freebsd.org"
