From marcus at FreeBSD.org Thu Oct 1 04:05:29 2009 From: marcus at FreeBSD.org (Joe Marcus Clarke) Date: Thu Oct 1 04:05:36 2009 Subject: Pthread fix to libc on FreeBSD 9.X, 8.X, 7.X, and 6.X Message-ID: <1254369928.94567.50.camel@shumai.marcuscom.com> Users were reporting a failure with pthread_mutexattr_settype(), and I couldn't figure out why this function would fail. It's quite simple. I tracked down a problem to the pthread stubs in libc. The stub definition for pthread_mutexattr_settype() is wrong. Here is a patch which has been reported to fix the problem users have reported. I'd like to commit it, but I'd really like a review from someone with thread knowledge. Thanks. http://www.marcuscom.com/downloads/_pthread_stubs.c.diff Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091001/e3303672/attachment.pgp From ale at FreeBSD.org Thu Oct 1 05:44:30 2009 From: ale at FreeBSD.org (Alex Dupre) Date: Thu Oct 1 05:44:44 2009 Subject: Pthread fix to libc on FreeBSD 9.X, 8.X, 7.X, and 6.X In-Reply-To: <1254369928.94567.50.camel@shumai.marcuscom.com> References: <1254369928.94567.50.camel@shumai.marcuscom.com> Message-ID: <4AC4410A.1030600@FreeBSD.org> Joe Marcus Clarke wrote: > I'd > like to commit it, but I'd really like a review from someone with thread > knowledge. Thanks. I don't think I can be considered "with thread knowledge", but FWIW the patch looks good. -- Alex Dupre From Alexander at Leidinger.net Thu Oct 1 06:07:08 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Thu Oct 1 06:07:16 2009 Subject: new ACPI warning after update to 9-current In-Reply-To: <200909301918.45942.jkim@FreeBSD.org> References: <20090930135815.15151g7ho1epevgg@webmail.leidinger.net> <200909301918.45942.jkim@FreeBSD.org> Message-ID: <20091001080657.83133zg3oit7zj8k@webmail.leidinger.net> Quoting Jung-uk Kim (from Wed, 30 Sep 2009 19:18:44 -0400): > On Wednesday 30 September 2009 07:58 am, Alexander Leidinger wrote: >> Hi, >> >> after updating form 8-beta2 to current (r197613) I get the >> following new message while booting: >> ---snip--- >> ACPI Warning: Detected an unsupported executable opcode at >> module-level: [0x7B] at table offset 0x94 (20090903/psloop-630) >> ACPI Warning: Detected an unsupported executable opcode at >> module-level: [0x7B] at table offset 0x99 (20090903/psloop-630) >> ---snip--- >> >> Anything I should provide additionally? What does it mean (the >> non-obvious meaning and the implications for the system)? > > New ACPICA added partial support for executable at module level, which > is illegal by specification and previously ignored without warning. > Unfortunately many BIOSes out there has broken DSDT/SSDT because > Windows ACPI interpreter does not care although it is illegal since > ACPI 2.0. I say "partial" because only three opcodes are supported > at module level ATM, i.e., If, Else, and While. Basically, it is > telling you that unsupported opcode is found at module level. For > more info, see the following commit: > > http://git.moblin.org/cgit.cgi/acpica/commit/?id=80d7951177315f70b5ffd8663985fbf725d07799 So - my BIOS is broken - it is doing more than before but not all it should do (according to the BIOS) - as the system was working before and working now, I do not need to worry After reading the commit log it looks like they want to support more in the future. Bye, Alexander. -- Put your best foot forward. Or just call in and say you're sick. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From Alexander at Leidinger.net Thu Oct 1 07:15:22 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Thu Oct 1 07:15:29 2009 Subject: ifconfig_IF_aliasX regression In-Reply-To: <4AC36719.3010607@FreeBSD.org> References: <20090930135327.83446wivezjxxlc8@webmail.leidinger.net> <4AC36719.3010607@FreeBSD.org> Message-ID: <20091001091513.11182ihiv60y2qyo@webmail.leidinger.net> Quoting Alex Dupre (from Wed, 30 Sep 2009 16:11:37 +0200): > Alexander Leidinger ha scritto: >> I know the setup should have been the second one from the beginning (at >> least the manpage gives something like this as an example), but the >> first one worked without problems. The problem is either that it >> (silently?) fails, or that it is not documented in UPDATING. Anyone with >> their hands there recently with an opinion about it? > > The change is recent, to unificate ipv4 and ipv6 rc code. We have > ipv4_addrs_IF that uses the former syntax, but why not ipv6_addrs_IF, too? Is this a question to me? I already expected that this is some regression because of the IPv6 changes, but still: intended or not? If yes -> missing UPDATING entry. Bye, Alexander. -- I saw a subliminal advertising executive, but only for a second. -- Steven Wright http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From ale at FreeBSD.org Thu Oct 1 07:28:57 2009 From: ale at FreeBSD.org (Alex Dupre) Date: Thu Oct 1 07:29:04 2009 Subject: ifconfig_IF_aliasX regression In-Reply-To: <20091001091513.11182ihiv60y2qyo@webmail.leidinger.net> References: <20090930135327.83446wivezjxxlc8@webmail.leidinger.net> <4AC36719.3010607@FreeBSD.org> <20091001091513.11182ihiv60y2qyo@webmail.leidinger.net> Message-ID: <4AC45A35.1070901@FreeBSD.org> Alexander Leidinger ha scritto: >> The change is recent, to unificate ipv4 and ipv6 rc code. We have >> ipv4_addrs_IF that uses the former syntax, but why not ipv6_addrs_IF, >> too? > > Is this a question to me? Of course, no :-) > I already expected that this is some regression because of the IPv6 > changes, but still: intended or not? If yes -> missing UPDATING entry. CCed hrs@ for this regression and brooks@ for the ipv4_addrs_IF change. -- Alex Dupre From dhorn2000 at gmail.com Thu Oct 1 08:38:10 2009 From: dhorn2000 at gmail.com (David Horn) Date: Thu Oct 1 08:38:16 2009 Subject: synaptics touchpad + mouse taps = trouble Message-ID: <25ff90d60910010138l24e83470v390e8c0271f332f7@mail.gmail.com> I currently have a laptop running FreeBSD 8/Stable RC1 r197621 (amd64) that happens to have a synaptics touchpad. On this particular laptop(Inspiron 1520), the placement of the touchpad means that I will inevitably accidentally hit it while typing, and I have found that I always need to disable the "mouse taps" in order to have the touchpad usable for me. So, I figured, no big problem, I can figure out how to set the preference using x11/gsynaptics and x11-drivers/xf86-input-synaptics driver. So, after finding the /etc/xorg.conf: Option "AutoAddDevices" "true" to disable hal input detection, Xorg's synaptics input driver still refuses to attach to my synaptics device. So, I take a look at dmesg, and notice that my touchpad is probed and attached twice. Once as psm0, and once as ums0. I start off trying to see if moused can talk to the mouse, and it does just fine with psm0, but fails with ums0. (Problem 1. Why does ums0 probe/attach and not work with moused/xorg input mouse/xorg input synaptics ?) usbconfig -u 0 -a 5 show_ifdrv ugen0.5: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen0.5.0: ums0: Is there a usb quirk mode I should be trying ? Is there any additional debug output that may help diagnose ? I have not found much about this device, but Xorg and hal detect it as a synaptics device under ubuntu 9.04(as Broadcom 4503) Looking at mousedrv(4x) man page does not have anything useful on mouse taps, so I start looking at psm(4) for some relief on disabling synaptics mouse taps. So, I start trying the instructions for hw.psm.synaptics_support and via the wiki, and I find after much trial and error that I can get a mostly usable configuration using: sysctl.conf entries: hw.psm.synaptics.vscroll_ver_area=-1 hw.psm.synaptics.directional_scrolls=0 hw.psm.tap_timeout=1 loader.conf entry: hw.psm.synaptics_support="1" Although the right mouse button behavior is still quirky compared to default psm behavior (see PR: kern/84411), but hw.synaptics.directional_scrolls=0 makes it mostly tolerable. So, I start thinking about the problem, and take a look at the synaptics programming specs, and find that there is a command byte that can be used to for disabling touchpad taps and gestures in generic mouse mode. I have submitted the patch to GNATS under kern/139272 for anyone interested in disabling mouse taps under psm via tunable. Once I can get ums0 to work with moused, then I can start looking into xf86-input-synaptics and possibly hal config changes. So, I have been having one of those days where nothing is ever simple to debug. I have found that the very common components (like a mouse) can touch so many modules (psm/ums/moused/usb2/hal/Xorg/Xorg-input-mouse/Xorg-input-synaptics), that the potential failure points are many and varied. Thanks in advance. ---Dave H From tinderbox at freebsd.org Thu Oct 1 09:29:52 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Oct 1 09:29:59 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <200910010929.n919TpVX038654@freebsd-current.sentex.ca> TB --- 2009-10-01 08:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-01 08:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-10-01 08:10:00 - cleaning the object tree TB --- 2009-10-01 08:10:18 - cvsupping the source tree TB --- 2009-10-01 08:10:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-10-01 08:17:40 - building world TB --- 2009-10-01 08:17:40 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-01 08:17:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-01 08:17:40 - TARGET=pc98 TB --- 2009-10-01 08:17:40 - TARGET_ARCH=i386 TB --- 2009-10-01 08:17:40 - TZ=UTC TB --- 2009-10-01 08:17:40 - __MAKE_CONF=/dev/null TB --- 2009-10-01 08:17:40 - cd /src TB --- 2009-10-01 08:17:40 - /usr/bin/make -B buildworld >>> World build started on Thu Oct 1 08:17:41 UTC 2009 >>> 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 Thu Oct 1 09:14:43 UTC 2009 TB --- 2009-10-01 09:14:43 - generating LINT kernel config TB --- 2009-10-01 09:14:43 - cd /src/sys/pc98/conf TB --- 2009-10-01 09:14:43 - /usr/bin/make -B LINT TB --- 2009-10-01 09:14:43 - building LINT kernel TB --- 2009-10-01 09:14:43 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-01 09:14:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-01 09:14:43 - TARGET=pc98 TB --- 2009-10-01 09:14:43 - TARGET_ARCH=i386 TB --- 2009-10-01 09:14:43 - TZ=UTC TB --- 2009-10-01 09:14:43 - __MAKE_CONF=/dev/null TB --- 2009-10-01 09:14:43 - cd /src TB --- 2009-10-01 09:14:43 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Oct 1 09:14:43 UTC 2009 >>> 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 [...] ===> if_ndis (all) cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c cc1: warnings being treated as errors /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c: In function 'ndis_inputtask': /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:1537: warning: comparison between pointer and integer /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c: In function 'ndis_ticktask': /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:1749: warning: comparison between pointer and integer /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:1761: warning: comparison between pointer and integer *** Error code 1 Stop in /src/sys/modules/if_ndis. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-01 09:29:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-01 09:29:51 - ERROR: failed to build lint kernel TB --- 2009-10-01 09:29:51 - 3386.35 user 521.69 system 4791.48 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From tinderbox at freebsd.org Thu Oct 1 09:37:38 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Oct 1 09:37:50 2009 Subject: [head tinderbox] failure on i386/i386 Message-ID: <200910010937.n919bbfx093108@freebsd-current.sentex.ca> TB --- 2009-10-01 08:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-01 08:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2009-10-01 08:10:00 - cleaning the object tree TB --- 2009-10-01 08:10:20 - cvsupping the source tree TB --- 2009-10-01 08:10:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2009-10-01 08:26:02 - building world TB --- 2009-10-01 08:26:02 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-01 08:26:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-01 08:26:02 - TARGET=i386 TB --- 2009-10-01 08:26:02 - TARGET_ARCH=i386 TB --- 2009-10-01 08:26:02 - TZ=UTC TB --- 2009-10-01 08:26:02 - __MAKE_CONF=/dev/null TB --- 2009-10-01 08:26:02 - cd /src TB --- 2009-10-01 08:26:02 - /usr/bin/make -B buildworld >>> World build started on Thu Oct 1 08:26:03 UTC 2009 >>> 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 Thu Oct 1 09:24:04 UTC 2009 TB --- 2009-10-01 09:24:04 - generating LINT kernel config TB --- 2009-10-01 09:24:04 - cd /src/sys/i386/conf TB --- 2009-10-01 09:24:04 - /usr/bin/make -B LINT TB --- 2009-10-01 09:24:04 - building LINT kernel TB --- 2009-10-01 09:24:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-01 09:24:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-01 09:24:04 - TARGET=i386 TB --- 2009-10-01 09:24:04 - TARGET_ARCH=i386 TB --- 2009-10-01 09:24:04 - TZ=UTC TB --- 2009-10-01 09:24:04 - __MAKE_CONF=/dev/null TB --- 2009-10-01 09:24:04 - cd /src TB --- 2009-10-01 09:24:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Oct 1 09:24:04 UTC 2009 >>> 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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ichwd/ichwd.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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/if_ndis/if_ndis.c cc1: warnings being treated as errors /src/sys/dev/if_ndis/if_ndis.c: In function 'ndis_inputtask': /src/sys/dev/if_ndis/if_ndis.c:1537: warning: comparison between pointer and integer /src/sys/dev/if_ndis/if_ndis.c: In function 'ndis_ticktask': /src/sys/dev/if_ndis/if_ndis.c:1749: warning: comparison between pointer and integer /src/sys/dev/if_ndis/if_ndis.c:1761: warning: comparison between pointer and integer *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-01 09:37:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-01 09:37:37 - ERROR: failed to build lint kernel TB --- 2009-10-01 09:37:37 - 3349.51 user 508.66 system 5257.24 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From kostikbel at gmail.com Thu Oct 1 09:50:09 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Oct 1 09:50:18 2009 Subject: Pthread fix to libc on FreeBSD 9.X, 8.X, 7.X, and 6.X In-Reply-To: <1254369928.94567.50.camel@shumai.marcuscom.com> References: <1254369928.94567.50.camel@shumai.marcuscom.com> Message-ID: <20091001095002.GQ3130@deviant.kiev.zoral.com.ua> On Thu, Oct 01, 2009 at 12:05:28AM -0400, Joe Marcus Clarke wrote: > Users were reporting a failure with pthread_mutexattr_settype(), and I > couldn't figure out why this function would fail. It's quite simple. I > tracked down a problem to the pthread stubs in libc. The stub > definition for pthread_mutexattr_settype() is wrong. Here is a patch > which has been reported to fix the problem users have reported. I'd > like to commit it, but I'd really like a review from someone with thread > knowledge. Thanks. > > http://www.marcuscom.com/downloads/_pthread_stubs.c.diff The patch looks right. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091001/f468039d/attachment.pgp From tinderbox at freebsd.org Thu Oct 1 11:15:28 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Oct 1 11:15:40 2009 Subject: [head tinderbox] failure on i386/i386 Message-ID: <200910011115.n91BFRBc089508@freebsd-current.sentex.ca> TB --- 2009-10-01 09:55:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-01 09:55:01 - starting HEAD tinderbox run for i386/i386 TB --- 2009-10-01 09:55:01 - cleaning the object tree TB --- 2009-10-01 09:55:01 - cvsupping the source tree TB --- 2009-10-01 09:55:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2009-10-01 10:00:10 - building world TB --- 2009-10-01 10:00:10 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-01 10:00:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-01 10:00:10 - TARGET=i386 TB --- 2009-10-01 10:00:10 - TARGET_ARCH=i386 TB --- 2009-10-01 10:00:10 - TZ=UTC TB --- 2009-10-01 10:00:10 - __MAKE_CONF=/dev/null TB --- 2009-10-01 10:00:10 - cd /src TB --- 2009-10-01 10:00:10 - /usr/bin/make -B buildworld >>> World build started on Thu Oct 1 10:00:11 UTC 2009 >>> 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 Thu Oct 1 11:01:29 UTC 2009 TB --- 2009-10-01 11:01:29 - generating LINT kernel config TB --- 2009-10-01 11:01:29 - cd /src/sys/i386/conf TB --- 2009-10-01 11:01:29 - /usr/bin/make -B LINT TB --- 2009-10-01 11:01:29 - building LINT kernel TB --- 2009-10-01 11:01:29 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-01 11:01:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-01 11:01:29 - TARGET=i386 TB --- 2009-10-01 11:01:29 - TARGET_ARCH=i386 TB --- 2009-10-01 11:01:29 - TZ=UTC TB --- 2009-10-01 11:01:29 - __MAKE_CONF=/dev/null TB --- 2009-10-01 11:01:29 - cd /src TB --- 2009-10-01 11:01:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Oct 1 11:01:30 UTC 2009 >>> 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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ichwd/ichwd.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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/if_ndis/if_ndis.c cc1: warnings being treated as errors /src/sys/dev/if_ndis/if_ndis.c: In function 'ndis_inputtask': /src/sys/dev/if_ndis/if_ndis.c:1537: warning: comparison between pointer and integer /src/sys/dev/if_ndis/if_ndis.c: In function 'ndis_ticktask': /src/sys/dev/if_ndis/if_ndis.c:1749: warning: comparison between pointer and integer /src/sys/dev/if_ndis/if_ndis.c:1761: warning: comparison between pointer and integer *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-01 11:15:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-01 11:15:27 - ERROR: failed to build lint kernel TB --- 2009-10-01 11:15:27 - 3377.94 user 715.67 system 4826.03 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From tinderbox at freebsd.org Thu Oct 1 11:19:47 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Oct 1 11:19:54 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <200910011119.n91BJk3b011461@freebsd-current.sentex.ca> TB --- 2009-10-01 09:55:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-01 09:55:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-10-01 09:55:01 - cleaning the object tree TB --- 2009-10-01 09:55:01 - cvsupping the source tree TB --- 2009-10-01 09:55:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-10-01 10:04:04 - building world TB --- 2009-10-01 10:04:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-01 10:04:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-01 10:04:04 - TARGET=pc98 TB --- 2009-10-01 10:04:04 - TARGET_ARCH=i386 TB --- 2009-10-01 10:04:04 - TZ=UTC TB --- 2009-10-01 10:04:04 - __MAKE_CONF=/dev/null TB --- 2009-10-01 10:04:04 - cd /src TB --- 2009-10-01 10:04:04 - /usr/bin/make -B buildworld >>> World build started on Thu Oct 1 10:04:05 UTC 2009 >>> 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 Thu Oct 1 11:03:52 UTC 2009 TB --- 2009-10-01 11:03:52 - generating LINT kernel config TB --- 2009-10-01 11:03:52 - cd /src/sys/pc98/conf TB --- 2009-10-01 11:03:52 - /usr/bin/make -B LINT TB --- 2009-10-01 11:03:52 - building LINT kernel TB --- 2009-10-01 11:03:52 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-01 11:03:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-01 11:03:52 - TARGET=pc98 TB --- 2009-10-01 11:03:52 - TARGET_ARCH=i386 TB --- 2009-10-01 11:03:52 - TZ=UTC TB --- 2009-10-01 11:03:52 - __MAKE_CONF=/dev/null TB --- 2009-10-01 11:03:52 - cd /src TB --- 2009-10-01 11:03:52 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Oct 1 11:03:52 UTC 2009 >>> 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 [...] ===> if_ndis (all) cc -O2 -pipe -DPC98 -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c cc1: warnings being treated as errors /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c: In function 'ndis_inputtask': /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:1537: warning: comparison between pointer and integer /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c: In function 'ndis_ticktask': /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:1749: warning: comparison between pointer and integer /src/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:1761: warning: comparison between pointer and integer *** Error code 1 Stop in /src/sys/modules/if_ndis. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-01 11:19:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-01 11:19:46 - ERROR: failed to build lint kernel TB --- 2009-10-01 11:19:46 - 3426.22 user 754.00 system 5085.11 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From tinderbox at freebsd.org Thu Oct 1 11:43:23 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Oct 1 11:43:34 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <200910011143.n91BhMmm095348@freebsd-current.sentex.ca> TB --- 2009-10-01 09:55:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-01 09:55:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-10-01 09:55:01 - cleaning the object tree TB --- 2009-10-01 09:55:01 - cvsupping the source tree TB --- 2009-10-01 09:55:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-10-01 10:04:04 - building world TB --- 2009-10-01 10:04:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-01 10:04:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-01 10:04:04 - TARGET=amd64 TB --- 2009-10-01 10:04:04 - TARGET_ARCH=amd64 TB --- 2009-10-01 10:04:04 - TZ=UTC TB --- 2009-10-01 10:04:04 - __MAKE_CONF=/dev/null TB --- 2009-10-01 10:04:04 - cd /src TB --- 2009-10-01 10:04:04 - /usr/bin/make -B buildworld >>> World build started on Thu Oct 1 10:04:05 UTC 2009 >>> 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 Thu Oct 1 11:30:22 UTC 2009 TB --- 2009-10-01 11:30:22 - generating LINT kernel config TB --- 2009-10-01 11:30:22 - cd /src/sys/amd64/conf TB --- 2009-10-01 11:30:22 - /usr/bin/make -B LINT TB --- 2009-10-01 11:30:22 - building LINT kernel TB --- 2009-10-01 11:30:22 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-01 11:30:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-01 11:30:22 - TARGET=amd64 TB --- 2009-10-01 11:30:22 - TARGET_ARCH=amd64 TB --- 2009-10-01 11:30:22 - TZ=UTC TB --- 2009-10-01 11:30:22 - __MAKE_CONF=/dev/null TB --- 2009-10-01 11:30:22 - cd /src TB --- 2009-10-01 11:30:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Oct 1 11:30:22 UTC 2009 >>> 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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ichwd/ichwd.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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/if_ndis/if_ndis.c cc1: warnings being treated as errors /src/sys/dev/if_ndis/if_ndis.c: In function 'ndis_inputtask': /src/sys/dev/if_ndis/if_ndis.c:1537: warning: comparison between pointer and integer /src/sys/dev/if_ndis/if_ndis.c: In function 'ndis_ticktask': /src/sys/dev/if_ndis/if_ndis.c:1749: warning: comparison between pointer and integer /src/sys/dev/if_ndis/if_ndis.c:1761: warning: comparison between pointer and integer *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-01 11:43:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-01 11:43:22 - ERROR: failed to build lint kernel TB --- 2009-10-01 11:43:22 - 4506.61 user 1008.22 system 6501.16 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From kostikbel at gmail.com Thu Oct 1 12:07:35 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Oct 1 12:07:41 2009 Subject: Signals and an exiting thread In-Reply-To: References: Message-ID: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> On Wed, Sep 30, 2009 at 11:02:19AM -0700, Justin Teller wrote: > We're trying to control one process from another process through > signals (I know, revolutionary ;-), and we've found that a signal > occasionally gets lost. ?The process we're signaling is > multi-threaded. ?It looks like the signal is lost when the kernel > decides to post the signal to a thread that is in the process of dying > (calling pthread_exit, etc). > > Is this expected behavior that we should just handle, or is it a race > in the kernel that should be/will be/already is fixed? > > It may be that a fix is already in current, and I just haven't found > it in my searches through the source code (I'm working off of source > code for an older 8.0 image). If it is fixed, I'd appreciate a > pointer to the code that fixes it. When thread enters the kernel last time to be killed, it is very much bad idea to allow it to return to usermode to handle directed signal. And, there would always be window between entering the kernel and marking the thread as exiting. Moving the thread-directed signals back to the process queue is hard and there is no way to distinguish which signals were sent to process or to the thread. Possibly, we could clear the thread signal mask while still in user mode. I think it would still leave a very narrow window when a process signal could be directed to the dying thread and not be delivered to usermode; this happens when signal is generated while sigsetmask already entered the kernel, but did not changed the mask yet. This is worked around by rechecking the pending signals after setting the block mask and releasing it if needed. Consider the patch as experimental. diff --git a/lib/libthr/thread/thr_exit.c b/lib/libthr/thread/thr_exit.c index 33a2451..f0339c5 100644 --- a/lib/libthr/thread/thr_exit.c +++ b/lib/libthr/thread/thr_exit.c @@ -31,6 +31,7 @@ #include "namespace.h" #include +#include #include #include #include @@ -69,6 +70,8 @@ void _pthread_exit(void *status) { struct pthread *curthread = _get_curthread(); + sigset_t block_sig, old_sig, pend_sig; + int i; /* Check if this thread is already in the process of exiting: */ if (curthread->cancelling) { @@ -108,6 +111,30 @@ _pthread_exit(void *status) } THREAD_LIST_UNLOCK(curthread); + /* + * From now on, hint the kernel to not direct signals for + * delivery to this thread. + */ + sigfillset(&block_sig); + for (;;) { + _pthread_sigmask(SIG_SETMASK, &block_sig, &old_sig); + /* + * If the signal was directed to the thread before + * thread sigmask was set to blocked, try to handle + * the signal. + */ + sigpending(&pend_sig); + for (i = 0; i < _SIG_MAXSIG; i++) { + if (!sigismember(&old_sig, i) && + sigismember(&pend_sig, i)) { + _pthread_sigmask(SIG_SETMASK, &old_sig, NULL); + break; + } + } + if (i == _SIG_MAXSIG) + break; + } + /* Tell malloc that the thread is exiting. */ _malloc_thread_cleanup(); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091001/7174274e/attachment.pgp From stephen at missouri.edu Thu Oct 1 12:37:00 2009 From: stephen at missouri.edu (Stephen Montgomery-Smith) Date: Thu Oct 1 12:37:08 2009 Subject: synaptics touchpad + mouse taps = trouble In-Reply-To: <25ff90d60910010138l24e83470v390e8c0271f332f7@mail.gmail.com> References: <25ff90d60910010138l24e83470v390e8c0271f332f7@mail.gmail.com> Message-ID: <4AC4A26A.6040101@missouri.edu> David Horn wrote: > I currently have a laptop running FreeBSD 8/Stable RC1 r197621 (amd64) > that happens to have a synaptics touchpad. On this particular > laptop(Inspiron 1520), the placement of the touchpad means that I will > inevitably accidentally hit it while typing, and I have found that I > always need to disable the "mouse taps" in order to have the touchpad > usable for me. I have an Inspiron 1525. After struggling with this for a long time, I found that the following entry in /etc/rc.conf did the trick moused_flags="-3 -m 11=4 -A 2" It is the "-m 11=4" that did it. On my computer, it isn't really a "synaptics" touchpad, but some other brand. Hopefully it will work for you. Stephen From avg at icyb.net.ua Thu Oct 1 12:53:38 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Oct 1 12:53:52 2009 Subject: Signals and an exiting thread In-Reply-To: References: Message-ID: <4AC4A64E.7060201@icyb.net.ua> on 30/09/2009 21:02 Justin Teller said the following: > We're trying to control one process from another process through > signals (I know, revolutionary ;-), and we've found that a signal > occasionally gets lost. The process we're signaling is > multi-threaded. It looks like the signal is lost when the kernel > decides to post the signal to a thread that is in the process of dying > (calling pthread_exit, etc). > > Is this expected behavior that we should just handle, or is it a race > in the kernel that should be/will be/already is fixed? > > It may be that a fix is already in current, and I just haven't found > it in my searches through the source code (I'm working off of source > code for an older 8.0 image). If it is fixed, I'd appreciate a > pointer to the code that fixes it. > > Thanks in advance for the help Do you allow all/arbitrary threads to catch signals? not sure if the following applies to your case, but for multi-threaded applications we usually designate a dedicated signal handling thread. sigwait(2), pthread_sigmask(2), etc -- Andriy Gapon From jkim at FreeBSD.org Thu Oct 1 15:54:15 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Thu Oct 1 15:54:26 2009 Subject: new ACPI warning after update to 9-current In-Reply-To: <20091001080657.83133zg3oit7zj8k@webmail.leidinger.net> References: <20090930135815.15151g7ho1epevgg@webmail.leidinger.net> <200909301918.45942.jkim@FreeBSD.org> <20091001080657.83133zg3oit7zj8k@webmail.leidinger.net> Message-ID: <200910011154.06892.jkim@FreeBSD.org> On Thursday 01 October 2009 02:06 am, Alexander Leidinger wrote: > Quoting Jung-uk Kim (from Wed, 30 Sep 2009 19:18:44 -0400): > > On Wednesday 30 September 2009 07:58 am, Alexander Leidinger wrote: > >> Hi, > >> > >> after updating form 8-beta2 to current (r197613) I get the > >> following new message while booting: > >> ---snip--- > >> ACPI Warning: Detected an unsupported executable opcode at > >> module-level: [0x7B] at table offset 0x94 (20090903/psloop-630) > >> ACPI Warning: Detected an unsupported executable opcode at > >> module-level: [0x7B] at table offset 0x99 (20090903/psloop-630) > >> ---snip--- > >> > >> Anything I should provide additionally? What does it mean (the > >> non-obvious meaning and the implications for the system)? > > > > New ACPICA added partial support for executable at module level, > > which is illegal by specification and previously ignored without > > warning. Unfortunately many BIOSes out there has broken DSDT/SSDT > > because Windows ACPI interpreter does not care although it is > > illegal since ACPI 2.0. I say "partial" because only three > > opcodes are supported at module level ATM, i.e., If, Else, and > > While. Basically, it is telling you that unsupported opcode is > > found at module level. For more info, see the following commit: > > > > http://git.moblin.org/cgit.cgi/acpica/commit/?id=80d7951177315f70 > >b5ffd8663985fbf725d07799 > > So > - my BIOS is broken Yes (but it's Microsoft Windows logo worthy). ;-) > - it is doing more than before but not all it should do > (according to the BIOS) Correct. > - as the system was working before and working now, I do > not need to worry Correct. > After reading the commit log it looks like they want to support > more in the future. Feel free to implement it and let us know if you find some free time. :-) Jung-uk Kim From gnemmi at gmail.com Thu Oct 1 15:58:38 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Thu Oct 1 15:58:45 2009 Subject: kern/136876: [bge] bge will not resume properly after suspend Message-ID: <200910011258.31967.gnemmi@gmail.com> Following a wise advise I'm pinging the list in order to know if this PR is beign worked on by somebody or if it happens to be on someone's TODO list as I'm willing to apply any patches that might be available, test, report, debug and even give ssh root acces to my hardware so this bug can be squashed before 8.0-RELEASE is out =D Best Regards Gonzalo Nemmi From dhorn2000 at gmail.com Thu Oct 1 16:07:12 2009 From: dhorn2000 at gmail.com (David Horn) Date: Thu Oct 1 16:07:19 2009 Subject: synaptics touchpad + mouse taps = trouble In-Reply-To: <4AC4A26A.6040101@missouri.edu> References: <25ff90d60910010138l24e83470v390e8c0271f332f7@mail.gmail.com> <4AC4A26A.6040101@missouri.edu> Message-ID: <25ff90d60910010907la9f8227oecee2aec0b492572@mail.gmail.com> On Thu, Oct 1, 2009 at 8:36 AM, Stephen Montgomery-Smith wrote: > David Horn wrote: >> >> I currently have a laptop running FreeBSD 8/Stable RC1 r197621 (amd64) >> that happens to have a synaptics touchpad. ?On this particular >> laptop(Inspiron 1520), the placement of the touchpad means that I will >> inevitably accidentally hit it while typing, and I have found that I >> always need to disable the "mouse taps" in order to have the touchpad >> usable for me. > > I have an Inspiron 1525. ?After struggling with this for a long time, I > found that the following entry in /etc/rc.conf did the trick > > moused_flags="-3 -m 11=4 -A 2" Interesting. This maps physical button #4 to buttton #11. I will take a look again, but in my psm device, I never saw button 4 events, just button #1 and button #3 under generic psm mode. Mouse taps always showed up as button #1 so it was impossible to differentiate between tap #1 and real #1. (unless something like moused was mapping #4 to #1, hmm something to investigate) Were you running psm/generic or psm/Extended Synaptics or using ums0 ? Does your ums0 mouse show up as Broadcom 4503 ? > > It is the "-m 11=4" that did it. ?On my computer, it isn't really a > "synaptics" touchpad, but some other brand. > > Hopefully it will work for you. > > Stephen > Here is the hw.usb.ums.debug=99 data after a usbconfig -u 0 -a 5 reset Oct 1 11:33:43 dhorn-1520 kernel: ums0: on usbus0 Oct 1 11:33:43 dhorn-1520 kernel: ums0: 3 buttons and [XY] coordinates ID=2 Oct 1 11:44:56 dhorn-1520 kernel: ums0: at uhub7, port 3, addr 5 (disconnected) Oct 1 11:44:56 dhorn-1520 kernel: ums_detach:661: sc=0xffffff0001feb000 Oct 1 11:44:57 dhorn-1520 kernel: ums_probe:365: Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:503: sc=0xffffff00041d1000 Oct 1 11:44:57 dhorn-1520 kernel: ums0: on usbus0 Oct 1 11:44:57 dhorn-1520 kernel: ums0: 3 buttons and [XY] coordinates ID=2 Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:599: sc=0xffffff00041d1000, index=0 Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:601: X 8/8 id=2 Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:603: Y 16/8 id=2 Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:605: Z 0/0 id=0 Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:607: T 0/0 id=0 Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:609: W 0/0 id=0 Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:614: B1 0/1 id=2 Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:614: B2 1/1 id=2 Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:614: B3 2/1 id=2 Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:599: sc=0xffffff00041d1000, index=1 Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:601: X 0/0 id=0 Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:603: Y 0/0 id=0 Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:605: Z 0/0 id=0 Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:607: T 0/0 id=0 Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:609: W 0/0 id=0 Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:617: size=4, id=2 Oct 1 11:44:57 dhorn-1520 kernel: ums_open:771: Oct 1 11:44:57 dhorn-1520 kernel: ums_open:771: Oct 1 11:44:57 dhorn-1520 kernel: ums_ioctl:808: No additional events on mouse movement/buttons, but on moused startup I get Oct 1 12:01:23 dhorn-1520 kernel: ums_open:771: Oct 1 12:01:23 dhorn-1520 kernel: ums_open:771: Oct 1 12:01:23 dhorn-1520 kernel: ums_ioctl:808: running moused -df -p /dev/ums0 -t auto gives no mouse events to movement/buttons at all. --Dave H From stephen at missouri.edu Thu Oct 1 19:44:02 2009 From: stephen at missouri.edu (Stephen Montgomery-Smith) Date: Thu Oct 1 19:44:09 2009 Subject: synaptics touchpad + mouse taps = trouble In-Reply-To: <25ff90d60910010907la9f8227oecee2aec0b492572@mail.gmail.com> References: <25ff90d60910010138l24e83470v390e8c0271f332f7@mail.gmail.com> <4AC4A26A.6040101@missouri.edu> <25ff90d60910010907la9f8227oecee2aec0b492572@mail.gmail.com> Message-ID: <4AC50680.7070608@missouri.edu> David Horn wrote: > On Thu, Oct 1, 2009 at 8:36 AM, Stephen Montgomery-Smith > wrote: >> David Horn wrote: >>> I currently have a laptop running FreeBSD 8/Stable RC1 r197621 (amd64) >>> that happens to have a synaptics touchpad. On this particular >>> laptop(Inspiron 1520), the placement of the touchpad means that I will >>> inevitably accidentally hit it while typing, and I have found that I >>> always need to disable the "mouse taps" in order to have the touchpad >>> usable for me. >> I have an Inspiron 1525. After struggling with this for a long time, I >> found that the following entry in /etc/rc.conf did the trick >> >> moused_flags="-3 -m 11=4 -A 2" > > Interesting. This maps physical button #4 to buttton #11. I will > take a look again, but in my psm device, I never saw button 4 events, > just button #1 and button #3 under generic psm mode. Mouse taps always > showed up as button #1 so it was impossible to differentiate between > tap #1 and real #1. (unless something like moused was mapping #4 to > #1, hmm something to investigate) > > Were you running psm/generic or psm/Extended Synaptics or using ums0 ? > Does your ums0 mouse show up as Broadcom 4503 ? OK, I have a "Glidepoint." Probably your situation is completely different than mine. psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model GlidePoint, device ID 0 > >> It is the "-m 11=4" that did it. On my computer, it isn't really a >> "synaptics" touchpad, but some other brand. >> >> Hopefully it will work for you. >> >> Stephen >> > > Here is the hw.usb.ums.debug=99 data after a usbconfig -u 0 -a 5 reset > > Oct 1 11:33:43 dhorn-1520 kernel: ums0: 0x4503, class 0/0, rev 2.00/1.00, addr 5> on usbus0 > Oct 1 11:33:43 dhorn-1520 kernel: ums0: 3 buttons and [XY] coordinates ID=2 > Oct 1 11:44:56 dhorn-1520 kernel: ums0: at uhub7, port 3, addr 5 (disconnected) > Oct 1 11:44:56 dhorn-1520 kernel: ums_detach:661: sc=0xffffff0001feb000 > Oct 1 11:44:57 dhorn-1520 kernel: ums_probe:365: > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:503: sc=0xffffff00041d1000 > Oct 1 11:44:57 dhorn-1520 kernel: ums0: 0x4503, class 0/0, rev 2.00/1.00, addr 5> on usbus0 > Oct 1 11:44:57 dhorn-1520 kernel: ums0: 3 buttons and [XY] coordinates ID=2 > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:599: > sc=0xffffff00041d1000, index=0 > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:601: X 8/8 id=2 > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:603: Y 16/8 id=2 > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:605: Z 0/0 id=0 > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:607: T 0/0 id=0 > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:609: W 0/0 id=0 > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:614: B1 0/1 id=2 > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:614: B2 1/1 id=2 > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:614: B3 2/1 id=2 > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:599: > sc=0xffffff00041d1000, index=1 > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:601: X 0/0 id=0 > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:603: Y 0/0 id=0 > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:605: Z 0/0 id=0 > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:607: T 0/0 id=0 > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:609: W 0/0 id=0 > Oct 1 11:44:57 dhorn-1520 kernel: ums_attach:617: size=4, id=2 > Oct 1 11:44:57 dhorn-1520 kernel: ums_open:771: > Oct 1 11:44:57 dhorn-1520 kernel: ums_open:771: > Oct 1 11:44:57 dhorn-1520 kernel: ums_ioctl:808: > > No additional events on mouse movement/buttons, but on moused startup I get > > Oct 1 12:01:23 dhorn-1520 kernel: ums_open:771: > Oct 1 12:01:23 dhorn-1520 kernel: ums_open:771: > Oct 1 12:01:23 dhorn-1520 kernel: ums_ioctl:808: > > > running moused -df -p /dev/ums0 -t auto gives no mouse events to > movement/buttons at all. > > --Dave H > > From masoom.shaikh at gmail.com Thu Oct 1 20:03:48 2009 From: masoom.shaikh at gmail.com (Masoom Shaikh) Date: Thu Oct 1 20:03:55 2009 Subject: bluetooth.h, c++ include error In-Reply-To: References: Message-ID: Hello, while going through bluetooth.h, I observed int bt_devfilter(int s, struct bt_devfilter const *new, struct bt_devfilter *old); this line appears in bluetooth.h @ line # 166, rv197571 see ? the variable named 'new' will cause trouble to c++ source files i honestly believe this is not intentional, c++ programmers will have to perform some acrobats to get past this thanks, Masoom Shaikh From gleb.kurtsou at gmail.com Thu Oct 1 21:44:08 2009 From: gleb.kurtsou at gmail.com (Gleb Kurtsou) Date: Thu Oct 1 21:44:15 2009 Subject: RFC: kernel level cryptographic filesystem (summer of code project) Message-ID: <20091001212342.GA1417@tops> Hi, During Google Summer of Code this year I was working on kernel level cryptographic filesystem pefs. It looks like the project is mature enough to ask for a public review and comments. I'm using it to encrypt my mailbox for some time already without any issues. For testing I use mostly dbench and fsx tools. Some of pefs features (comparing to other stacked filesystems): * Kernel level implementation (no fuse and similar stuff) * Random per file tweak value used for encryption * Saves metadata only in encrypted file name (doesn't change file content) * Doesn't change encrypted file size * Arbitrary number of keys * Mixing files encrypted with different keys in single directory * Transparent mode of operation (no encryption, read-only, allows accessing filesystem snapshots easily) * Key chaining (though user level utility) * Modern encryption algorithms (AES and Camellia in CTR mode, Salsa20) I've tested it on top of ZFS, UFS and tmpfs (it fails on msdosfs). I use amd64 9-CURRENT but it should work on 8- and 7-STABLE (+ i386). For more information, there are several post on my blog regarding pefs: Step-by-step tutorial: http://blogs.freebsdish.org/gleb/2009/10/01/pefs-encrypting-directory/ Description of cryptographic primitives used: http://blogs.freebsdish.org/gleb/2009/09/23/pefs-crypto-primitives/ And a small benchmark: http://blogs.freebsdish.org/gleb/2009/09/16/pefs-benchmark/ I'd appreciate any feedback and testing. Short instructions on how to start with it: 1. Download tarball: http://www.2shared.com/file/8154727/3dc45b66/pefs-2009-10-01tar.html 2. Unpack into /usr/src 3. Compile and install: # make -C /usr/src/sys/modules/salsa20 obj all install clean # make -C /usr/src/sys/modules/pefs obj all install clean # make -C /usr/src/sbin/pefs obj all install clean It installs 2 modules (pefs, salsa20) and user level configuration utility /sbin/pefs (and /sbin/mount_pefs which is link to /sbin/pefs) 4. Mount pefs filesystem: % pefs mount ~/Private ~/Private 5. Set your passphrase: % pefs addkey ~/Private 6. Test it Thanks, Gleb. From doconnor at gsoft.com.au Fri Oct 2 02:11:19 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Fri Oct 2 02:11:26 2009 Subject: RFC: kernel level cryptographic filesystem (summer of code project) In-Reply-To: <20091001212342.GA1417@tops> References: <20091001212342.GA1417@tops> Message-ID: <200910021141.12311.doconnor@gsoft.com.au> On Fri, 2 Oct 2009, Gleb Kurtsou wrote: > I've tested it on top of ZFS, UFS and tmpfs (it fails on msdosfs). > I use amd64 9-CURRENT but it should work on 8- and 7-STABLE (+ i386). Do you think you could make a port? For older systems (pre-8, possibly even pre-9) it is unlikely to be MFC'd, so a port would widen the pool of potential users. I will have a play with it and see what it's like :) -- 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: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091002/70345407/attachment.pgp From john.marshall at riverwillow.com.au Fri Oct 2 04:39:21 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Fri Oct 2 04:39:27 2009 Subject: [SOLVED] sshd GSSAPIAuthentication broken after 8.0-BETA1 upgrade In-Reply-To: <20090714053357.GH982@rwpc12.mby.riverwillow.net.au> References: <20090708085202.GS1025@rwpc12.mby.riverwillow.net.au> <20090714053357.GH982@rwpc12.mby.riverwillow.net.au> Message-ID: <20091002043914.GI37304@rwpc12.mby.riverwillow.net.au> On Tue, 14 Jul 2009, 15:33 +1000, John Marshall wrote: > On Wed, 08 Jul 2009, 18:52 +1000, John Marshall wrote: > > I source upgraded a (test) server here (i386) from 7.2-RELEASE-p2 to > > 8.0-BETA1 this morning. I use GSSAPI as the primary authentication > > method for sshd on that server. After the upgrade GSSAPI authentication > > stopped working and I can't get enough information to figure out why. > > Perhaps the newer version of Heimdal behaves differently? Perhaps the > > newer version of sshd behaves differently? [snip] > > Does anybody know of changes between existing STABLE releases and 8.0 > > which would cause this behaviour - and how to accommodate it? Do any > > strange Kerberos things need to be done as part of the upgrade? > > > > The client still happily authenticates via GSSAPI to sshd on our other > > 7.2-RELEASE servers. Subsequent authentication methods succeed on the > > 8.0-BETA1 sshd server, it's just GSSAPI that isn't working. > > After fallback authentication (e.g. via keyboard-interactive), I can see > in my credentials cache on the server that a tgt was forwarded from the > client. If I look in my credentials cache on the client, I can see that > the service ticket for the server was acquired. See solution posted to my OP in -stable@ Basically, the problem is a gssapi-with-mic compatibility issue between Kerberos versions shipped in FreeBSD 7.2 and FreeBSD 8.0. The 7.2 machines need a [gssapi] section in /etc/krb5.conf in order to be compatible with the FreeBSD 8.0 servers. [gssapi] correct_des3_mic = host/* -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091002/74bb34ef/attachment.pgp From scottl at samsco.org Fri Oct 2 05:11:32 2009 From: scottl at samsco.org (Scott Long) Date: Fri Oct 2 05:14:16 2009 Subject: [PATCH] Moving CAM config to private SYSINIT Message-ID: All, I'm working on fixing the boot-from-USB-doesn't-always work problem, which turns out to be a race between several different threads at boot. As a pre-requisite to controlling the race, I'm moving the CAM bus/device scan to its own private SYSINIT so that its execution is ordered. In practice, it should not affect anything, and systems should continue to boot as normal. That's where I need help in testing. If you have any CAM/SCSI devices that are present when you boot, please test this patch and let me know if it changes anything for you, good or bad. http://people.freebsd.org/~scottl/cam_hook.diff Thanks! Scott From gleb.kurtsou at gmail.com Fri Oct 2 07:30:18 2009 From: gleb.kurtsou at gmail.com (Gleb Kurtsou) Date: Fri Oct 2 07:30:25 2009 Subject: RFC: kernel level cryptographic filesystem (summer of code project) In-Reply-To: <200910021204.38237.doconnor@gsoft.com.au> References: <20091001212342.GA1417@tops> <200910021141.12311.doconnor@gsoft.com.au> <200910021204.38237.doconnor@gsoft.com.au> Message-ID: <20091002072957.GA1251@tops> On (02/10/2009 12:04), Daniel O'Connor wrote: > On Fri, 2 Oct 2009, you wrote: > > On Fri, 2 Oct 2009, Gleb Kurtsou wrote: > > > I've tested it on top of ZFS, UFS and tmpfs (it fails on msdosfs). > > > I use amd64 9-CURRENT but it should work on 8- and 7-STABLE (+ > > > i386). > > > > Do you think you could make a port? > > For older systems (pre-8, possibly even pre-9) it is unlikely to be > > MFC'd, so a port would widen the pool of potential users. > > > > I will have a play with it and see what it's like :) It should just work on 8. I've started development before 9-CURRENT appeared. Tarball contains no patches, just a new sources. But unfortunately I'm not able to test it on 8 (have no system running it). Please let me know if something goes wrong or tweaking is needed to make it run on 8 (or 7). > Hmm I can't download the file (tried FF3 and Konqueror).. Any chance you > can host it elsewhere? (and perhaps sign it). Mirrors: http://rapidshare.com/files/287648214/pefs-2009-10-01.tar.bz2.html http://www.sendspace.com/file/vohwog I can upload only images to blog itself and maillist allows only plain text attachments. From gleb.kurtsou at gmail.com Fri Oct 2 08:10:42 2009 From: gleb.kurtsou at gmail.com (Gleb Kurtsou) Date: Fri Oct 2 08:10:54 2009 Subject: RFC: kernel level cryptographic filesystem (summer of code project) In-Reply-To: <20091002071718.GD69862@unistra.fr> References: <20091001212342.GA1417@tops> <20091002071718.GD69862@unistra.fr> Message-ID: <20091002081022.GA1585@tops> On (02/10/2009 09:17), Guy Brand wrote: > Gleb Kurtsou wrote: > > Hello > > > > During Google Summer of Code this year I was working on kernel level > > cryptographic filesystem pefs. It looks like the project is mature > > enough to ask for a public review and comments. > > Thanks for sharing this work. > > > I've tested it on top of ZFS, UFS and tmpfs (it fails on msdosfs). > > I use amd64 9-CURRENT but it should work on 8- and 7-STABLE (+ i386). > > I(ve grabbed the tarball and followed your installation instructions > on my FreeBSD 9.0-CURRENT #33: Wed Sep 23 10:29:08 CEST 2009 and run > into a: > > 6nq# kldload -v pefs > kldload: can't load pefs: Exec format error > and seeing also: > > link_elf_obj: symbol camellia_encrypt undefined > linker_load_file: Unsupported file type My bad. Dependency on crypto module is missing. Try kldload crypto Please let me know if it fixes the issue for you. > from the logs. > > Are my sources too old? Do I need world rebuild? > All the best > gb > > > -- > Never attribute to malice that which is adequately explained by > stupidity From john.marshall at riverwillow.com.au Fri Oct 2 08:13:31 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Fri Oct 2 08:13:37 2009 Subject: [PATCH] SASL problems with spnego on 8.0-BETA4 In-Reply-To: <20090921222241.GF1001@rwpc12.mby.riverwillow.net.au> References: <4AB27FB6.4010806@eng.auth.gr> <20090918034933.GI1231@rwpc12.mby.riverwillow.net.au> <20090918233157.GK1231@rwpc12.mby.riverwillow.net.au> <20090921012855.GA1001@rwpc12.mby.riverwillow.net.au> <4AB768C3.6030003@eng.auth.gr> <20090921222241.GF1001@rwpc12.mby.riverwillow.net.au> Message-ID: <20091002081319.GN37304@rwpc12.mby.riverwillow.net.au> On Tue, 22 Sep 2009, 08:22 +1000, John Marshall wrote: > On Mon, 21 Sep 2009, 11:26 -0400, Rick Macklem wrote: > > On Mon, 21 Sep 2009, George Mamalakis wrote: > > [snip] > > >> > > >>SUCCESS! > > >> > > >>So, this fix obviates THAT reason for installing the Heimdal port. If > > >>George meets with similar success adding -lgssapi_spnego for his spnego > > >>problem, I suggest that both libraries be added to the list in line 96 > > >>of /usr/bin/krb5-config prior to release of FreeBSD 8.0. > > >> [snip] > > >> > > >>krb5-config. It looks like magic needs to happen somewhere in the base > > >>kerberos build system. > > >> > > >>I notice that the Heimdal port doesn't build the separate libraries and > > >>everything seems to be included in libgssapi (which explains why sasl2 > > >>"works" when linked against the Heimdal port). > > >> > > > > > >I changed my /usr/bin/krb5-config's line 96 to include -lgssapi_spnego and > > >-lgssapi_krb5, and ever since both client and server work correctly!! Of > > >course I get some other error, but at least this must be a configuration > > >error :). > > > [snip] > > > > > Now, hopefully someone who understands enough about dynamic linking will > > know if this is the correct fix for 8.0? (I'm going on a couple of weeks > > vacation at the end of this week, so I won't be around to commit anything > > and don't understand it well enough to know if this is the correct way > > to fix it.) > > > > So, hopefully someone else can pick this one up? > > > > Thanks for testing it, rick > > Thanks Rick for your very valuable guidance on this problem. Have a > great vacation! > > I have submitted a patch to the FreeBSD Makefile which patches the > vendor-supplied template for krb5-config. I should be grateful if dfr@ > or another src committer would please review this with a view to > obtaining re@ approval to commit it before 8.0-RC2. > > Any src committers able to help with this? -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091002/677c1abb/attachment.pgp From john.marshall at riverwillow.com.au Fri Oct 2 08:27:41 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Fri Oct 2 08:27:48 2009 Subject: Heimdal in 8.0 In-Reply-To: <20090820232237.GH2675@rwpc12.mby.riverwillow.net.au> References: <20090820232237.GH2675@rwpc12.mby.riverwillow.net.au> Message-ID: <20091002082737.GO37304@rwpc12.mby.riverwillow.net.au> On Fri, 21 Aug 2009, 09:22 +1000, John Marshall wrote: > Is there a good reason why we don't include the current Heimdal 1.2.1 > release with the FreeBSD 8.0 base? Heimdal 1.2.1 was released just over > 12 months ago and includes fixes to the 1.1.0 version which is currently > included with FreeBSD 8.0. > > I was not able to get gssapi authentication working with an OpenLDAP > server on an 8.0-BETA2 server until I installed Heimdal 1.2.1 (via a > hacked port) and re-built OpenLDAP against that. Note that I have since been able to get the OpenLDAP/gssapi combination working with the 8.0 base Heimdal (1.1.0) by applying the following patch, rebuilding the base Heimdal and rebuilding security/cyrus-sasl2 against the base Heimdal. -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091002/43f06ff3/attachment.pgp From gb at unistra.fr Fri Oct 2 08:34:08 2009 From: gb at unistra.fr (Guy Brand) Date: Fri Oct 2 08:34:15 2009 Subject: RFC: kernel level cryptographic filesystem (summer of code project) In-Reply-To: <20091002081022.GA1585@tops> References: <20091001212342.GA1417@tops> <20091002071718.GD69862@unistra.fr> <20091002081022.GA1585@tops> Message-ID: <20091002081442.GF69862@unistra.fr> Gleb Kurtsou (gleb.kurtsou@gmail.com) on 02/10/2009 at 11:10 wrote: > My bad. Dependency on crypto module is missing. Try > kldload crypto > Please let me know if it fixes the issue for you. Already tried, same issue. gb -- Oops! From gleb.kurtsou at gmail.com Fri Oct 2 08:43:05 2009 From: gleb.kurtsou at gmail.com (Gleb Kurtsou) Date: Fri Oct 2 08:43:12 2009 Subject: RFC: kernel level cryptographic filesystem (summer of code project) In-Reply-To: <20091002081442.GF69862@unistra.fr> References: <20091001212342.GA1417@tops> <20091002071718.GD69862@unistra.fr> <20091002081022.GA1585@tops> <20091002081442.GF69862@unistra.fr> Message-ID: <20091002084244.GA1802@tops> On (02/10/2009 10:14), Guy Brand wrote: > Gleb Kurtsou (gleb.kurtsou@gmail.com) on 02/10/2009 at 11:10 wrote: > > > My bad. Dependency on crypto module is missing. Try > > kldload crypto > > Please let me know if it fixes the issue for you. > > Already tried, same issue. Would you try the patch attached. Another common reason for 'kldload: can't load pefs: Exec format error' is running kernel and sources version mismatch (sources are newer then kernel). -------------- next part -------------- diff --git a/sys/fs/pefs/pefs_vfsops.c b/sys/fs/pefs/pefs_vfsops.c index 0fc4b85..93b2d80 100644 --- a/sys/fs/pefs/pefs_vfsops.c +++ b/sys/fs/pefs/pefs_vfsops.c @@ -322,3 +322,5 @@ static struct vfsops pefs_vfsops = { VFS_SET(pefs_vfsops, pefs, VFCF_LOOPBACK); MODULE_DEPEND(pefs, salsa20, 1, 1, 1); +MODULE_DEPEND(pefs, crypto, 1, 1, 1); + From gb at unistra.fr Fri Oct 2 08:59:55 2009 From: gb at unistra.fr (Guy Brand) Date: Fri Oct 2 09:00:01 2009 Subject: RFC: kernel level cryptographic filesystem (summer of code project) In-Reply-To: <20091002084244.GA1802@tops> References: <20091001212342.GA1417@tops> <20091002071718.GD69862@unistra.fr> <20091002081022.GA1585@tops> <20091002081442.GF69862@unistra.fr> <20091002084244.GA1802@tops> Message-ID: <20091002085835.GH69862@unistra.fr> Gleb Kurtsou (gleb.kurtsou@gmail.com) on 02/10/2009 at 11:42 wrote: > Would you try the patch attached. That fixed the issue. Thanks gb From ggajic at afrodita.rcub.bg.ac.rs Fri Oct 2 08:25:23 2009 From: ggajic at afrodita.rcub.bg.ac.rs (Goran Gajic) Date: Fri Oct 2 11:26:47 2009 Subject: 8.0RC1: Can't mount usb stick Message-ID: Same here: ugen2.2: at usbus2 (disconnected) umass0: at uhub2, port 5, addr 2 (disconnected) (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry ugen2.2: at usbus2 umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:1:0:-1: Attached to scbus1 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) da0 at umass-sim0 bus 0 target 0 lun 0 da0: < USB FLASH DRIVE PMAP> Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 1968MB (4030464 512 byte sectors: 255H 63S/T 250C) # mount -t msdosfs /dev/da0 /mnt mount_msdosfs: /dev/da0: Invalid argument gg. From info at martenvijn.nl Fri Oct 2 11:39:47 2009 From: info at martenvijn.nl (Marten Vijn) Date: Fri Oct 2 11:39:55 2009 Subject: 8.0RC1: Can't mount usb stick In-Reply-To: References: Message-ID: <1254483586.14766.1.camel@polaris> On Fri, 2009-10-02 at 10:25 +0200, Goran Gajic wrote: > Same here: > > ugen2.2: at usbus2 (disconnected) > umass0: at uhub2, port 5, addr 2 (disconnected) > (da0:umass-sim0:0:0:0): lost device > (da0:umass-sim0:0:0:0): removing device entry > ugen2.2: at usbus2 > umass0: > on usbus2 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0:1:0:-1: Attached to scbus1 > (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition > (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 > (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have > changed > (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: < USB FLASH DRIVE PMAP> Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 1968MB (4030464 512 byte sectors: 255H 63S/T 250C) > > # mount -t msdosfs /dev/da0 /mnt > mount_msdosfs: /dev/da0: Invalid argument _and_ booting 8.0RC-1 from a ubs-stick results in a panic..... cheers, Marten > > > gg. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Marten Vijn linux 2.0.18 OpenBSD 3.6 FreeBSD 4.6 http://martenvijn.nl http://opencommunitycamp.org http://wifisoft.org From bms at FreeBSD.org Fri Oct 2 12:22:09 2009 From: bms at FreeBSD.org (Bruce Simpson) Date: Fri Oct 2 12:22:18 2009 Subject: IGMPv3 implementation In-Reply-To: <951619.7835.qm@web52307.mail.re2.yahoo.com> References: <951619.7835.qm@web52307.mail.re2.yahoo.com> Message-ID: <4AC5F06F.9020807@FreeBSD.org> Philip Romanov wrote: > Hello, > > Does the current implement IGMPv3 state machine when it comes to merging interface state changes during retransmissions as per 5.1 of RFC3376: > Yes, the IGMPv3 implementation merges state changes per interface. A per source counter is not used for doing this, rather, if there is a pending state change for the interface, the merge is performed at the level of the outgoing mbuf queue. > Can somebody shed any light on it? What is the compliance of interface state "merge" during report retransmits? > As far as I know, it works. I had a regression test framework for this, but due to some problems with the serial driver in 8.x, I was unable to fully run this test framework. thanks, BMS From hselasky at c2i.net Fri Oct 2 12:29:20 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Oct 2 12:29:27 2009 Subject: 8.0RC1: Can't mount usb stick In-Reply-To: <1254483586.14766.1.camel@polaris> References: <1254483586.14766.1.camel@polaris> Message-ID: <200910021430.01344.hselasky@c2i.net> On Friday 02 October 2009 13:39:46 Marten Vijn wrote: > On Fri, 2009-10-02 at 10:25 +0200, Goran Gajic wrote: > > Same here: > > > > ugen2.2: at usbus2 (disconnected) > > umass0: at uhub2, port 5, addr 2 (disconnected) > > (da0:umass-sim0:0:0:0): lost device > > (da0:umass-sim0:0:0:0): removing device entry > > ugen2.2: at usbus2 > > umass0: > > on usbus2 > > umass0: SCSI over Bulk-Only; quirks = 0x0000 > > umass0:1:0:-1: Attached to scbus1 > > (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > > (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > > (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition > > (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 > > (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have > > changed > > (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) > > da0 at umass-sim0 bus 0 target 0 lun 0 > > da0: < USB FLASH DRIVE PMAP> Removable Direct Access SCSI-0 device > > da0: 40.000MB/s transfers > > da0: 1968MB (4030464 512 byte sectors: 255H 63S/T 250C) > > > > # mount -t msdosfs /dev/da0 /mnt > > mount_msdosfs: /dev/da0: Invalid argument > > _and_ booting 8.0RC-1 from a ubs-stick results in a panic..... > Can you try this patch: http://perforce.freebsd.org/chv.cgi?CH=169085 --HPS From bsdlisten at gmail.com Fri Oct 2 12:31:19 2009 From: bsdlisten at gmail.com (Aioanei Rares) Date: Fri Oct 2 12:31:26 2009 Subject: 8.0RC1: Can't mount usb stick In-Reply-To: References: Message-ID: <4AC73E88.8050109@gmail.com> Goran Gajic wrote: > > Same here: > > ugen2.2: at usbus2 (disconnected) > umass0: at uhub2, port 5, addr 2 (disconnected) > (da0:umass-sim0:0:0:0): lost device > (da0:umass-sim0:0:0:0): removing device entry > ugen2.2: at usbus2 > umass0: 2> on usbus2 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0:1:0:-1: Attached to scbus1 > (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition > (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 > (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have > changed > (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: < USB FLASH DRIVE PMAP> Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 1968MB (4030464 512 byte sectors: 255H 63S/T 250C) > > # mount -t msdosfs /dev/da0 /mnt > mount_msdosfs: /dev/da0: Invalid argument > > > gg. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > try /dev/da0i instead of da0. From hselasky at freebsd.org Fri Oct 2 12:40:06 2009 From: hselasky at freebsd.org (Hans Petter Selasky) Date: Fri Oct 2 12:40:13 2009 Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f In-Reply-To: References: Message-ID: <200910021440.50021.hselasky@freebsd.org> Hi, Can the Apple's "Blocks" C language extension be used when programming in the kernel? Or is this a user-space only feature? --HPS From bms at FreeBSD.org Fri Oct 2 12:53:40 2009 From: bms at FreeBSD.org (Bruce Simpson) Date: Fri Oct 2 12:53:46 2009 Subject: IGMPv3 implementation In-Reply-To: <951619.7835.qm@web52307.mail.re2.yahoo.com> References: <951619.7835.qm@web52307.mail.re2.yahoo.com> Message-ID: <4AC5F7D1.5010404@FreeBSD.org> A bit more technical detail, as I may be taking a break quite soon: IGMPv3 state changes happen on a group-by-group basis. IGMPv3 state change reports, however, are issued on a per-link basis. If the state for a group changes, the pending state change is computed and enqueued to a per-group state-change queue. This involves an RB-tree walk of the source list for the group. Per source counters are not used here -- if a state change happens at t1 *before* a new report is issued, the group's queue will get blown away and the group's state change recomputed. In practice the RB-tree should perform reasonably well,.and for most use cases, this shouldn't present a problem. If a more scalable solution is needed, that's up to the user. The igmp_v3_merge_state_changes() function will cherry-pick from the group's queue, and bundle it into the outgoing per-link queue. To break out from under the locks, a software interrupt is used to actually transmit the outgoing state-change report. There is always room for improvement, though. The main thrust of the project was to get IGMPv3 into the tree in an SMPng compatible way, and time was sadly limited. thanks, BMS From aman.jassal at esigetel.fr Fri Oct 2 13:08:52 2009 From: aman.jassal at esigetel.fr (JASSAL Aman) Date: Fri Oct 2 13:08:59 2009 Subject: 8.0RC1: Can't mount usb stick In-Reply-To: References: Message-ID: <38424.83.206.131.26.1254488924.squirrel@webmail.esigetel.fr> I haven't tried mounting a USB stick on my 9.0-CURRENT just yet, but on 7.1, I used to do : # mount -t msdosfs /dev/da0s1 /"name of your target directory" You can try this, check what's in /dev/ to confirm what's in there, just in case. Aman Jassal Le Ven 2 octobre 2009 10:25, Goran Gajic a ?crit : > > Same here: > > > ugen2.2: at usbus2 (disconnected) > umass0: at uhub2, port 5, addr 2 (disconnected) > (da0:umass-sim0:0:0:0): lost device > (da0:umass-sim0:0:0:0): removing device entry > ugen2.2: at usbus2 > umass0: > on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0:1:0:-1: Attached to scbus1 > (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition > (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 > (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have > changed (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) > da0 at umass-sim0 bus 0 target 0 lun 0 da0: < USB FLASH DRIVE PMAP> > Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 1968MB (4030464 512 byte sectors: 255H 63S/T 250C) > > > # mount -t msdosfs /dev/da0 /mnt > mount_msdosfs: /dev/da0: Invalid argument > > > > gg. _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From bsam at ipt.ru Fri Oct 2 13:13:18 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Fri Oct 2 13:13:25 2009 Subject: 8.0RC1: Can't mount usb stick In-Reply-To: (Goran Gajic's message of "Fri, 2 Oct 2009 10:25:16 +0200 (CEST)") References: Message-ID: <54980020@bb.ipt.ru> On Fri, 2 Oct 2009 10:25:16 +0200 (CEST) Goran Gajic wrote: > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: < USB FLASH DRIVE PMAP> Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 1968MB (4030464 512 byte sectors: 255H 63S/T 250C) > # mount -t msdosfs /dev/da0 /mnt > mount_msdosfs: /dev/da0: Invalid argument Take a look at /dev/da0*. MS DOS usually uses partition s1, so your command should be: ----- # mount -t msdosfs /dev/da0s1 /mnt ----- -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From illoai at gmail.com Fri Oct 2 14:38:22 2009 From: illoai at gmail.com (illoai@gmail.com) Date: Fri Oct 2 14:38:28 2009 Subject: [PATCH] Shutdown cooloff feature In-Reply-To: References: <4AC141B0.4090705@delphij.net> <86fxa6gg8l.fsf@ds4.des.no> Message-ID: 2009/9/29 Daniel Braniss : >> > Xin LI writes: >> > > I'm not sure if anyone would find this useful: >> > > > > > ?- If a shutdown is initiated from a tty -and- >> > > ?- It's not a restart -and- >> > > ?- The time parameter is set to "now" >> > > >> > > Then, the shutdown(8) program would give something like this: >> > > >> > > Shutting down NOW, press ^C within 5 seconds to cancel... >> > > >> > > So the user would get a chance to terminate it before it's too late. >> > I know we are living in a virtual world, where even shutting down >> > a computer is just a 'wish', but lets keep some sanity, now means now. > >> The "now" is not an issue; I think his point is that you *really* don't >> want to accidentally type "shutdown -h now" or "shutdown now" instead of >> "shutdown -r now" in an ssh session to a remote system - especially at 6 >> pm on a Friday night when the machine is in a colo center that's only >> manned during business hours. > > I understand what is at stake, my problem is that in other *Unixes, sysV/Solaris > 'shutdown now' is actually sometime in the future :-), and it does not help > much if you are far away and the link is slow, so the 5 sec. grace is actually > taken up by the bandwidth - or you are connected via an iphone, how do you > hit ^C :-) > > what if the machine is compromised and you really want to power it off, > now the intruder has another 5 seconds ... > > thankfully +0 works, or are there plans to change that too? :-) > > careful! bikeshead ahead % cat ~/bin/bikeshed #!/bin/sh echo "It's all gone pear-shaped!" sleep 5 shutdown -p now -- -- From john at baldwin.cx Fri Oct 2 12:38:07 2009 From: john at baldwin.cx (John Baldwin) Date: Fri Oct 2 15:14:00 2009 Subject: [PATCH] SASL problems with spnego on 8.0-BETA4 In-Reply-To: <20091002081319.GN37304@rwpc12.mby.riverwillow.net.au> References: <4AB27FB6.4010806@eng.auth.gr> <20090921222241.GF1001@rwpc12.mby.riverwillow.net.au> <20091002081319.GN37304@rwpc12.mby.riverwillow.net.au> Message-ID: <200910020824.15488.john@baldwin.cx> On Friday 02 October 2009 4:13:19 am John Marshall wrote: > On Tue, 22 Sep 2009, 08:22 +1000, John Marshall wrote: > > On Mon, 21 Sep 2009, 11:26 -0400, Rick Macklem wrote: > > > On Mon, 21 Sep 2009, George Mamalakis wrote: > > > > [snip] > > > >> > > > >>SUCCESS! > > > >> > > > >>So, this fix obviates THAT reason for installing the Heimdal port. If > > > >>George meets with similar success adding -lgssapi_spnego for his spnego > > > >>problem, I suggest that both libraries be added to the list in line 96 > > > >>of /usr/bin/krb5-config prior to release of FreeBSD 8.0. > > > >> > [snip] > > > >> > > > >>krb5-config. It looks like magic needs to happen somewhere in the base > > > >>kerberos build system. > > > >> > > > >>I notice that the Heimdal port doesn't build the separate libraries and > > > >>everything seems to be included in libgssapi (which explains why sasl2 > > > >>"works" when linked against the Heimdal port). > > > >> > > > > > > > >I changed my /usr/bin/krb5-config's line 96 to include -lgssapi_spnego and > > > >-lgssapi_krb5, and ever since both client and server work correctly!! Of > > > >course I get some other error, but at least this must be a configuration > > > >error :). > > > > > [snip] > > > > > > > Now, hopefully someone who understands enough about dynamic linking will > > > know if this is the correct fix for 8.0? (I'm going on a couple of weeks > > > vacation at the end of this week, so I won't be around to commit anything > > > and don't understand it well enough to know if this is the correct way > > > to fix it.) > > > > > > So, hopefully someone else can pick this one up? > > > > > > Thanks for testing it, rick > > > > Thanks Rick for your very valuable guidance on this problem. Have a > > great vacation! > > > > I have submitted a patch to the FreeBSD Makefile which patches the > > vendor-supplied template for krb5-config. I should be grateful if dfr@ > > or another src committer would please review this with a view to > > obtaining re@ approval to commit it before 8.0-RC2. > > > > > > Any src committers able to help with this? Hmmm, I thought that libgssapi was supposed to use dlopen to load the proper back-end libraries using /etc/gss/mech rather than having applications directly link against them. -- John Baldwin From spambox at haruhiism.net Fri Oct 2 15:40:03 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Fri Oct 2 15:40:11 2009 Subject: Another panic (during netisr?) Message-ID: <4AC61ED6.1090802@haruhiism.net> Hello, hope you're having a nice day, This is on FreeBSD 8.0-BETA3 (Ameagari) #23 r196460: Mon Aug 24 00:36:33 JST 2009; not sure if it has been witnessed or fixed. I've been running it without restarts to test the stability and here we go: Unread portion of the kernel message buffer: panic: tcp_input: so == NULL cpuid = 0 Uptime: 39d15h40m53s (kgdb) #0 doadump () at pcpu.h:223 #1 0xffffffff805ab6d3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xffffffff805abb2c in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xffffffff80725543 in tcp_input (m=0xffffff00672a8300, off0=Variable "off0" is not available. ) at /usr/src/sys/netinet/tcp_input.c:737 #4 0xffffffff806bea9c in ip_input (m=0xffffff00672a8300) at /usr/src/sys/netinet/ip_input.c:775 #5 0xffffffff8065d478 in netisr_dispatch_src (proto=1, source=Variable "source" is not available. ) at /usr/src/sys/net/netisr.c:917 #6 0xffffffff80655b7d in ether_demux (ifp=0xffffff0001656000, m=0xffffff00672a8300) at /usr/src/sys/net/if_ethersubr.c:895 #7 0xffffffff80655fa5 in ether_input (ifp=0xffffff0001656000, m=0xffffff00672a8300) at /usr/src/sys/net/if_ethersubr.c:754 #8 0xffffffff80347f64 in em_rxeof (adapter=0xffffff80002b0000, count=4) at /usr/src/sys/dev/e1000/if_em.c:4605 #9 0xffffffff80349d05 in em_poll (ifp=0xffffff0001656000, cmd=Variable "cmd" is not available. ) at /usr/src/sys/dev/e1000/if_em.c:1657 #10 0xffffffff8059fa17 in netisr_poll () at /usr/src/sys/kern/kern_poll.c:448 #11 0xffffffff8065cd56 in swi_net (arg=0xffffffff80eb7800) at /usr/src/sys/net/netisr.c:748 #12 0xffffffff80585398 in intr_event_execute_handlers (p=Variable "p" is not available. ) at /usr/src/sys/kern/kern_intr.c:1165 #13 0xffffffff80585ff2 in ithread_loop (arg=0xffffff00014d8660) at /usr/src/sys/kern/kern_intr.c:1178 #14 0xffffffff805832ea in fork_exit ( callout=0xffffffff80585f40 , arg=0xffffff00014d8660, frame=0xffffff8000032c80) at /usr/src/sys/kern/kern_fork.c:838 #15 0xffffffff8087a24e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:561 -- Kamigishi Rei KREI-RIPE fujibayashi.jp From imb at protected-networks.net Fri Oct 2 17:01:00 2009 From: imb at protected-networks.net (Michael Butler) Date: Fri Oct 2 17:01:08 2009 Subject: panic using VirtualBox on -current Message-ID: <4AC631C1.9090705@protected-networks.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While installing a guest OS (Centos-5.3) under VirtualBox, I get a panic as below. Any pointers as to how to proceed would be appreciated. I have these defined in the kernel: # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks options WITNESS # Enable checks to detect deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks options KDB_TRACE # print a stack trace on panic options DEBUG_MEMGUARD # detect reads or writes options DIAGNOSTIC Michael panic: uma: item 0xc7efa400 did not belong to zone 64 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c0a94825,0,c0a85c81,e803fbb8,0,...) at db_trace_self_wrapper+0x26 panic(c0a85c81,c7efa400,c0a7dc8d,c7efa400,c148b060,...) at panic+0x106 uma_dbg_free(c148b000,0,c7efa400,7c8,c0a58349,...) at uma_dbg_free uma_zalloc_arg(c148b000,0,2,c0adae6c,2c,...) at uma_zalloc_arg+0x2b7 malloc(2c,c0adae6c,2,0,c0a58349,...) at malloc+0xa4 ioctl(c8f1b690,e803fcf8,c,c0a73dd2,c0ace5a8,...) at ioctl+0xeb syscall(e803fd38) at syscall+0x19e Xint0x80_syscall() at Xint0x80_syscall+0x20 - --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x482a3d0b, esp = 0xbf8bad4c, ebp = 0xbf8bad68 --- KDB: enter: panic exclusive spin mutex allpmaps (allpmaps) r = 0 (0xc0ced570) locked @ /usr/home/imb/svn/head/sys/i386/i386/pmap.c:2461 exclusive lockmgr bufwait (bufwait) r = 0 (0xc52077f0) locked @ /usr/home/imb/svn/head/sys/kern/vfs_bio.c:1835 exclusive lockmgr ufs (ufs) r = 0 (0xc8edb9c4) locked @ /usr/home/imb/svn/head/sys/kern/vfs_vnops.c:607 exclusive sleep mutex 64 (UMA zone) r = 0 (0xc1494888) locked @ /usr/home/imb/svn/head/sys/vm/uma_core.c:1992 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc8b18a34) locked @ /usr/home/imb/svn/head/sys/kern/uipc_sockbuf.c:148 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc7dabbd0) locked @ /usr/home/imb/svn/head/sys/kern/uipc_sockbuf.c:148 exclusive sleep mutex PMAP2 (PMAP2) r = 0 (0xc0ceda44) locked @ /usr/home/imb/svn/head/sys/i386/i386/pmap.c:2411 exclusive sleep mutex vm page queue mutex (vm page queue mutex) r = 0 (0xc0ca4a84) locked @ /usr/home/imb/svn/head/sys/i386/i386/pmap.c:3635 exclusive sleep mutex pmap (pmap) r = 0 (0xc0ced4e0) locked @ /usr/home/imb/svn/head/sys/i386/i386/pmap.c:3629 exclusive sleep mutex system map (system map) r = 0 (0xc14900e8) locked @ /usr/home/imb/svn/head/sys/vm/vm_map.c:2766 exclusive sleep mutex UMA lock (UMA lock) r = 0 (0xc0ca4304) locked @ /usr/home/imb/svn/head/sys/vm/uma_core.c:1565 exclusive spin mutex allpmaps (allpmaps) r = 0 (0xc0ced570) locked @ /usr/home/imb/svn/head/sys/i386/i386/pmap.c:2461 exclusive lockmgr bufwait (bufwait) r = 0 (0xc52077f0) locked @ /usr/home/imb/svn/head/sys/kern/vfs_bio.c:1835 exclusive lockmgr ufs (ufs) r = 0 (0xc8edb9c4) locked @ /usr/home/imb/svn/head/sys/kern/vfs_vnops.c:607 exclusive sleep mutex 64 (UMA zone) r = 0 (0xc1494888) locked @ /usr/home/imb/svn/head/sys/vm/uma_core.c:1992 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc8b18a34) locked @ /usr/home/imb/svn/head/sys/kern/uipc_sockbuf.c:148 exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xc7dabbd0) locked @ /usr/home/imb/svn/head/sys/kern/uipc_sockbuf.c:148 exclusive sleep mutex PMAP2 (PMAP2) r = 0 (0xc0ceda44) locked @ /usr/home/imb/svn/head/sys/i386/i386/pmap.c:2411 exclusive sleep mutex vm page queue mutex (vm page queue mutex) r = 0 (0xc0ca4a84) locked @ /usr/home/imb/svn/head/sys/i386/i386/pmap.c:3635 exclusive sleep mutex pmap (pmap) r = 0 (0xc0ced4e0) locked @ /usr/home/imb/svn/head/sys/i386/i386/pmap.c:3629 exclusive sleep mutex system map (system map) r = 0 (0xc14900e8) locked @ /usr/home/imb/svn/head/sys/vm/vm_map.c:2766 exclusive sleep mutex UMA lock (UMA lock) r = 0 (0xc0ca4304) locked @ /usr/home/imb/svn/head/sys/vm/uma_core.c:1565 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrGMcEACgkQQv9rrgRC1JKHSQCeOhesV8wJjh+RwhF7zgpBEkjc 1goAnjogPfY7b7jfiiObSSv7DgCu0n6a =7Gc6 -----END PGP SIGNATURE----- From dhorn2000 at gmail.com Fri Oct 2 17:43:34 2009 From: dhorn2000 at gmail.com (David Horn) Date: Fri Oct 2 17:43:43 2009 Subject: synaptics touchpad + mouse taps = trouble In-Reply-To: <25ff90d60910010907la9f8227oecee2aec0b492572@mail.gmail.com> References: <25ff90d60910010138l24e83470v390e8c0271f332f7@mail.gmail.com> <4AC4A26A.6040101@missouri.edu> <25ff90d60910010907la9f8227oecee2aec0b492572@mail.gmail.com> Message-ID: <25ff90d60910021043k359c5af8r53f73d4aa210c49@mail.gmail.com> On Thu, Oct 1, 2009 at 12:07 PM, David Horn wrote: > On Thu, Oct 1, 2009 at 8:36 AM, Stephen Montgomery-Smith > wrote: >> David Horn wrote: >>> >>> I currently have a laptop running FreeBSD 8/Stable RC1 r197621 (amd64) >>> that happens to have a synaptics touchpad. ?On this particular >>> laptop(Inspiron 1520), the placement of the touchpad means that I will >>> inevitably accidentally hit it while typing, and I have found that I >>> always need to disable the "mouse taps" in order to have the touchpad >>> usable for me. >> >> I have an Inspiron 1525. ?After struggling with this for a long time, I >> found that the following entry in /etc/rc.conf did the trick >> >> moused_flags="-3 -m 11=4 -A 2" > > Interesting. ?This maps physical button #4 to buttton ?#11. ?I will > take a look again, but in my psm device, I never saw button 4 events, > just button #1 and button #3 under generic psm mode. Mouse taps always > showed up as button #1 so it was impossible to differentiate between > tap #1 and real #1. (unless something like moused was mapping #4 to > #1, hmm something to investigate) > > Were you running psm/generic or psm/Extended Synaptics or using ums0 ? > Does your ums0 mouse show up as Broadcom 4503 ? > >> >> It is the "-m 11=4" that did it. ?On my computer, it isn't really a >> "synaptics" touchpad, but some other brand. >> >> Hopefully it will work for you. >> >> Stephen >> > > Here is the hw.usb.ums.debug=99 data after a usbconfig -u 0 -a 5 reset > > Oct ?1 11:33:43 dhorn-1520 kernel: ums0: 0x4503, class 0/0, rev 2.00/1.00, addr 5> on usbus0 > Oct ?1 11:33:43 dhorn-1520 kernel: ums0: 3 buttons and [XY] coordinates ID=2 > Oct ?1 11:44:56 dhorn-1520 kernel: ums0: at uhub7, port 3, addr 5 (disconnected) > Oct ?1 11:44:56 dhorn-1520 kernel: ums_detach:661: sc=0xffffff0001feb000 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_probe:365: > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:503: sc=0xffffff00041d1000 > Oct ?1 11:44:57 dhorn-1520 kernel: ums0: 0x4503, class 0/0, rev 2.00/1.00, addr 5> on usbus0 > Oct ?1 11:44:57 dhorn-1520 kernel: ums0: 3 buttons and [XY] coordinates ID=2 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:599: > sc=0xffffff00041d1000, index=0 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:601: X ? ?8/8 id=2 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:603: Y ? ?16/8 id=2 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:605: Z ? ?0/0 id=0 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:607: T ? ?0/0 id=0 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:609: W ? ?0/0 id=0 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:614: B1 ? 0/1 id=2 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:614: B2 ? 1/1 id=2 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:614: B3 ? 2/1 id=2 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:599: > sc=0xffffff00041d1000, index=1 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:601: X ? ?0/0 id=0 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:603: Y ? ?0/0 id=0 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:605: Z ? ?0/0 id=0 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:607: T ? ?0/0 id=0 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:609: W ? ?0/0 id=0 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_attach:617: size=4, id=2 > Oct ?1 11:44:57 dhorn-1520 kernel: ums_open:771: > Oct ?1 11:44:57 dhorn-1520 kernel: ums_open:771: > Oct ?1 11:44:57 dhorn-1520 kernel: ums_ioctl:808: > > No additional events on mouse movement/buttons, but on moused startup I get > > Oct ?1 12:01:23 dhorn-1520 kernel: ums_open:771: > Oct ?1 12:01:23 dhorn-1520 kernel: ums_open:771: > Oct ?1 12:01:23 dhorn-1520 kernel: ums_ioctl:808: > > > running moused -df -p /dev/ums0 -t auto gives no mouse events to > movement/buttons at all. > > --Dave H > OK, I figured out the ums0 problem. It seems that Broadcomm 450x is a virtualized HID interface from the BCM 2045B2 Blueooth Chip to provide HID functions (4502 = ukbd, 4503=ums) This is *supposed* to be a method to present simplified interfaces for Bluetooth mouse/kbd via USB rather than the OS having to initialize a bluetooth stack and device. Long story short is that ums0 is not the device I thought it was, and the synaptics touchpad is only exposed via psm device. Still investigating to see if there is a better way to improve the default case of synaptics with hal and xf86-driver-synaptics, Sorry for the noise. ---Dave H From bzeeb-lists at lists.zabbadoz.net Fri Oct 2 19:15:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri Oct 2 19:15:15 2009 Subject: Another panic (during netisr?) In-Reply-To: <4AC61ED6.1090802@haruhiism.net> References: <4AC61ED6.1090802@haruhiism.net> Message-ID: <20091002191255.J26486@maildrop.int.zabbadoz.net> On Fri, 2 Oct 2009, Kamigishi Rei wrote: Hi, > Hello, hope you're having a nice day, > > This is on FreeBSD 8.0-BETA3 (Ameagari) #23 r196460: Mon Aug 24 00:36:33 JST > 2009; not sure if it has been witnessed or fixed. I've been running it > without restarts to test the stability and here we go: > > Unread portion of the kernel message buffer: > panic: tcp_input: so == NULL This looks like an explicit panic unrelated to the netisr in first place. More likely a race condition with socket teardown which should not happen in theory;) /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From kama at pvp.se Fri Oct 2 19:48:40 2009 From: kama at pvp.se (kama) Date: Fri Oct 2 19:48:47 2009 Subject: bge(4) hang on 8.0-RC1 In-Reply-To: <20090922165228.GD54962@droso.net> References: <20090922165228.GD54962@droso.net> Message-ID: <20091002212131.U37424@ns1.as.pvp.se> On Tue, 22 Sep 2009, Erwin Lansing wrote: > Configuring an inet address on bge(4) to up the interface hangs the > system on todays RELENG_8 or leads to an instant reboot. The system > becomes completely unresponsive and I haven't managed to break into the > debugger. Disabling hw.bge.allow_asf fixes the symptoms. Some relevant > information about the hardware: > http://people.freebsd.org/~erwin/bge-20090922.txt I can confirm that this is still an issue on an DL385 (Opteron running i386) and setting hw.bge.allow_asf to 0 make it boot up. /Bjorn bge0: mem 0xf7ff0000-0xf7ffffff irq 28 at device 6.0 on pci3 bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf7ff0000 bge0: CHIP ID 0x21000000; ASIC REV 0x02; CHIP REV 0x21; PCI-X miibus0: on bge0 bge0: bpf attached bge0: Ethernet address: 00:17:a4:8d:f9:2a bge0: [MPSAFE] bge0: [ITHREAD] bge1: mem 0xf7fe0000-0xf7feffff irq 29 at device 6.1 on pci3 bge1: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf7fe0000 bge1: CHIP ID 0x21000000; ASIC REV 0x02; CHIP REV 0x21; PCI-X miibus1: on bge1 bge1: bpf attached bge1: Ethernet address: 00:17:a4:8d:f9:29 bge1: [MPSAFE] bge1: [ITHREAD] From jilles at stack.nl Fri Oct 2 20:12:14 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Fri Oct 2 20:12:41 2009 Subject: Signals and an exiting thread In-Reply-To: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> References: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> Message-ID: <20091002201213.GA16633@stack.nl> On Thu, Oct 01, 2009 at 03:07:30PM +0300, Kostik Belousov wrote: > On Wed, Sep 30, 2009 at 11:02:19AM -0700, Justin Teller wrote: > > We're trying to control one process from another process through > > signals (I know, revolutionary ;-), and we've found that a signal > > occasionally gets lost. ?The process we're signaling is > > multi-threaded. ?It looks like the signal is lost when the kernel > > decides to post the signal to a thread that is in the process of dying > > (calling pthread_exit, etc). > > Is this expected behavior that we should just handle, or is it a race > > in the kernel that should be/will be/already is fixed? > > It may be that a fix is already in current, and I just haven't found > > it in my searches through the source code (I'm working off of source > > code for an older 8.0 image). If it is fixed, I'd appreciate a > > pointer to the code that fixes it. > When thread enters the kernel last time to be killed, it is very much > bad idea to allow it to return to usermode to handle directed signal. > And, there would always be window between entering the kernel and > marking the thread as exiting. > Moving the thread-directed signals back to the process queue is hard > and there is no way to distinguish which signals were sent to process > or to the thread. > Possibly, we could clear the thread signal mask while still in user mode. > I think it would still leave a very narrow window when a process > signal could be directed to the dying thread and not be delivered to > usermode; this happens when signal is generated while sigsetmask already > entered the kernel, but did not changed the mask yet. This is worked > around by rechecking the pending signals after setting the block mask > and releasing it if needed. SIGKILL cannot be masked. Is it possible that a kill(SIGKILL) is assigned to a dying thread and lost? (SIGSTOP cannot be masked either, but its processing is done by the sending thread, so it should be safe.) I suppose that race can also occur in other uses of pthread_sigmask(). If a thread masks a signal for a while, and that signal is assigned to that thread just as it is executing pthread_sigmask(), it will only be processed when that thread unblocks or accepts it, even though other threads may have the signal unmasked or be in a sigwait() for it. Signals sent after pthread_sigmask() has changed the signal mask are likely processed sooner because they will be assigned to a different thread or left in the process queue. POSIX seems to say that signals generated for the process should remain queued for the process and should only be assigned to a thread at time of delivery. This could be implemented by leaving signals in the process queue or by tracking for each signal in the thread queue whether it was directed at the thread and moving the process signals back at sigmask/thr_exit. Either way I am not sure of all the consequences at this time. By the way, SA_PROC in kern_sig.c is bogus, because whether a signal is directed at a specific thread depends on how it was generated and not on the signal number. Fortunately, it is not used. -- Jilles Tjoelker From scottl at samsco.org Fri Oct 2 21:11:25 2009 From: scottl at samsco.org (Scott Long) Date: Fri Oct 2 21:11:36 2009 Subject: [PATCH] Fix for USB media not found at boot Message-ID: <20091002150931.K35591@pooker.samsco.org> All, I have a candidate patch to fix the problem with USB boot media not being found in time at boot, leading to the "mountroot" prompt instead of a booting system. Please apply both patches below and let me know if it works for you. http://people.freebsd.org/~scottl/cam_hook.diff http://people.freebsd.org/~scottl/usb_hook.diff From jhell at DataIX.net Fri Oct 2 21:27:03 2009 From: jhell at DataIX.net (jhell) Date: Fri Oct 2 21:27:12 2009 Subject: MFC of ZFS Warning Removal. Message-ID: Not that this is inconvienent but is this planned on being MFC'd to stable/{6,7} as well ?. - Thanks ------------------------------------------------------------------------ r197221 | pjd | 2009-09-15 08:21:06 -0400 (Tue, 15 Sep 2009) | 7 lines MFC r197218: We believe ZFS is ready for production use. Remove a warning about it being experimental. :) Approved by: re (kib) ------------------------------------------------------------------------ -- %{----------------------------------------------------+ | dataix.net!jhell 2048R/89D8547E 2009-09-30 | | BSD Since FreeBSD 4.2 Linux Since Slackware 2.1 | | 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E | +----------------------------------------------------%} From faber at isi.edu Fri Oct 2 21:31:17 2009 From: faber at isi.edu (Ted Faber) Date: Fri Oct 2 21:31:35 2009 Subject: FreeBSD8-RELENG (sources from this morning) deadlock In-Reply-To: <20090929041407.GA92280@zod.isi.edu> References: <20090929041407.GA92280@zod.isi.edu> Message-ID: <20091002213116.GH88191@zod.isi.edu> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091002/b50980dd/attachment.pgp From justin.teller at gmail.com Fri Oct 2 22:08:18 2009 From: justin.teller at gmail.com (Justin Teller) Date: Fri Oct 2 22:08:25 2009 Subject: Signals and an exiting thread In-Reply-To: <20091002201213.GA16633@stack.nl> References: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> <20091002201213.GA16633@stack.nl> Message-ID: On Fri, Oct 2, 2009 at 1:12 PM, Jilles Tjoelker wrote: --- snip --- > SIGKILL cannot be masked. Is it possible that a kill(SIGKILL) is > assigned to a dying thread and lost? > > (SIGSTOP cannot be masked either, but its processing is done by the > sending thread, so it should be safe.) > > I suppose that race can also occur in other uses of pthread_sigmask(). > If a thread masks a signal for a while, and that signal is assigned to > that thread just as it is executing pthread_sigmask(), it will only be > processed when that thread unblocks or accepts it, even though other > threads may have the signal unmasked or be in a sigwait() for it. > Signals sent after pthread_sigmask() has changed the signal mask are > likely processed sooner because they will be assigned to a different > thread or left in the process queue. > > POSIX seems to say that signals generated for the process should remain > queued for the process and should only be assigned to a thread at time > of delivery. > > This could be implemented by leaving signals in the process queue or by > tracking for each signal in the thread queue whether it was directed at > the thread and moving the process signals back at sigmask/thr_exit. > Either way I am not sure of all the consequences at this time. > > By the way, SA_PROC in kern_sig.c is bogus, because whether a signal is > directed at a specific thread depends on how it was generated and not on > the signal number. Fortunately, it is not used. > > -- > Jilles Tjoelker > Thanks for the helpful tips. Andriy's suggestion to only handle signals from a "sable" thread is a good one -- it would solve some problems. However, we did a little more investigation, and the SIGKILL example Jilles posted happens as well. We post a SIGKILL to a thread, and the thread goes away before it can kill the process. I like the idea of keeping signals like SIGKILL on the process queue so that it will be picked up with SOME thread. The other way is basically what Kostik suggested -- although I like the idea of copying the signal back to the proc queue there as well ... I'll play around with it and see what solves our problem, and I'll post back here with what I find out. -Justin From sean.bruno at dsl-only.net Fri Oct 2 22:14:52 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Fri Oct 2 22:14:59 2009 Subject: FreeBSD8-RELENG (sources from this morning) deadlock In-Reply-To: <20091002213116.GH88191@zod.isi.edu> References: <20090929041407.GA92280@zod.isi.edu> <20091002213116.GH88191@zod.isi.edu> Message-ID: <1254521690.2549.5.camel@Lappy> > I'm still deadlocked, but trying to get more info. I tried a firewire > debugging session using dcons, but that failed for reasons unclear. > dconschat seems to do the right thing: > I'm a bit confused by the dmesg output of the machine. If I read it right, firewire/fwohci isn't loaded in the dmesg output. Am I missing something? Sean From faber at isi.edu Fri Oct 2 22:28:41 2009 From: faber at isi.edu (Ted Faber) Date: Fri Oct 2 22:28:48 2009 Subject: FreeBSD8-RELENG (sources from this morning) deadlock In-Reply-To: <1254521690.2549.5.camel@Lappy> References: <20090929041407.GA92280@zod.isi.edu> <20091002213116.GH88191@zod.isi.edu> <1254521690.2549.5.camel@Lappy> Message-ID: <20091002222753.GI88191@zod.isi.edu> On Fri, Oct 02, 2009 at 03:14:50PM -0700, Sean Bruno wrote: > > > I'm still deadlocked, but trying to get more info. I tried a firewire > > debugging session using dcons, but that failed for reasons unclear. > > dconschat seems to do the right thing: > > > I'm a bit confused by the dmesg output of the machine. If I read it > right, firewire/fwohci isn't loaded in the dmesg output. > > Am I missing something? Crap. That was the dmesg from the original message. There's a certain amount of switching of power supplies and other pain involved in trying to get this board running while not leaving the machine I'm replacing it with down for the count. In the confusion I grabbed the wrong dmesg. I'll send one with the firewire boot ASAP, probably later tonight PDT. Sorry for the confusion. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091002/78c62df7/attachment.pgp From jilles at stack.nl Fri Oct 2 22:31:48 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Fri Oct 2 22:31:55 2009 Subject: Signals and an exiting thread In-Reply-To: References: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> <20091002201213.GA16633@stack.nl> Message-ID: <20091002223147.GA26556@stack.nl> On Fri, Oct 02, 2009 at 03:08:17PM -0700, Justin Teller wrote: > However, we did a little more investigation, and the SIGKILL example > Jilles posted happens as well. We post a SIGKILL to a thread, and the > thread goes away before it can kill the process. If you mean pthread_kill() with "posting to a thread", then that does not seem a bug. I expect that pthread_kill() signals are lost when a thread exits and that pthread_kill() to a thread that has already terminated but has not yet been joined does nothing (possibly returning an error). If a SIGKILL from kill() is lost, that is a bug. -- Jilles Tjoelker From sean.bruno at dsl-only.net Fri Oct 2 22:32:27 2009 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Fri Oct 2 22:32:34 2009 Subject: FreeBSD8-RELENG (sources from this morning) deadlock In-Reply-To: <20091002222753.GI88191@zod.isi.edu> References: <20090929041407.GA92280@zod.isi.edu> <20091002213116.GH88191@zod.isi.edu> <1254521690.2549.5.camel@Lappy> <20091002222753.GI88191@zod.isi.edu> Message-ID: <1254522745.2549.6.camel@Lappy> No sweat. I'll hook up a test box at my house too. What architecture(amd64, i386, sparc) are both of these machines? Sean On Fri, 2009-10-02 at 15:27 -0700, Ted Faber wrote: > On Fri, Oct 02, 2009 at 03:14:50PM -0700, Sean Bruno wrote: > > > > > I'm still deadlocked, but trying to get more info. I tried a firewire > > > debugging session using dcons, but that failed for reasons unclear. > > > dconschat seems to do the right thing: > > > > > I'm a bit confused by the dmesg output of the machine. If I read it > > right, firewire/fwohci isn't loaded in the dmesg output. > > > > Am I missing something? > > Crap. That was the dmesg from the original message. > > There's a certain amount of switching of power supplies and other pain > involved in trying to get this board running while not leaving the > machine I'm replacing it with down for the count. In the confusion I > grabbed the wrong dmesg. > > I'll send one with the firewire boot ASAP, probably later tonight PDT. > Sorry for the confusion. > From faber at isi.edu Fri Oct 2 22:38:16 2009 From: faber at isi.edu (Ted Faber) Date: Fri Oct 2 22:38:46 2009 Subject: FreeBSD8-RELENG (sources from this morning) deadlock In-Reply-To: <1254522745.2549.6.camel@Lappy> References: <20090929041407.GA92280@zod.isi.edu> <20091002213116.GH88191@zod.isi.edu> <1254521690.2549.5.camel@Lappy> <20091002222753.GI88191@zod.isi.edu> <1254522745.2549.6.camel@Lappy> Message-ID: <20091002223729.GK88191@zod.isi.edu> On Fri, Oct 02, 2009 at 03:32:25PM -0700, Sean Bruno wrote: > No sweat. I'll hook up a test box at my house too. > > What architecture(amd64, i386, sparc) are both of these machines? Both i386. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091002/b2309aaa/attachment.pgp From justin.teller at gmail.com Fri Oct 2 22:57:31 2009 From: justin.teller at gmail.com (Justin Teller) Date: Fri Oct 2 22:57:38 2009 Subject: Signals and an exiting thread In-Reply-To: <20091002223147.GA26556@stack.nl> References: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> <20091002201213.GA16633@stack.nl> <20091002223147.GA26556@stack.nl> Message-ID: On Fri, Oct 2, 2009 at 3:31 PM, Jilles Tjoelker wrote: > On Fri, Oct 02, 2009 at 03:08:17PM -0700, Justin Teller wrote: >> However, we did a little more investigation, and the SIGKILL example >> Jilles posted happens as well. ?We post a SIGKILL to a thread, and the >> thread goes away before it can kill the process. > > If you mean pthread_kill() with "posting to a thread", then that does > not seem a bug. I expect that pthread_kill() signals are lost when a > thread exits and that pthread_kill() to a thread that has already > terminated but has not yet been joined does nothing (possibly returning > an error). > > If a SIGKILL from kill() is lost, that is a bug. > > -- > Jilles Tjoelker > It is a SIGKILL from kill(). I'll look at code and see if I can come up with a good patch to fix it. -Justin From weongyo.jeong at gmail.com Sat Oct 3 01:42:34 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Sat Oct 3 01:42:40 2009 Subject: uath0 issues: eject-caused panic, won't work after a restart. In-Reply-To: <90a5caac0907120353k69fb4f23q5e2f0eff35cfa2c5@mail.gmail.com> References: <90a5caac0907120353k69fb4f23q5e2f0eff35cfa2c5@mail.gmail.com> Message-ID: <20091003014251.GI1454@weongyo> Hello Lucius, On Sun, Jul 12, 2009 at 12:53:38PM +0200, Lucius Windschuh wrote: > Hi guys, > I'm using CURRENT r195362MP and have two issues with it. > > 1st: Pulling the device while the kernel was nearly finished shutting > down shutting down resulted in a kernel panic: > > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...2 1 1 1 0 0 done > All buffers synced. > > [LORs: ufs, syncer, defs; ELI detaches] > > ugen3.2: at usbus3 (disconnected) > uath0: at uhub3, port 1, addr 2 (disconnected) > > lock order reversal: > 1st 0xc6793208 if_afdata (if_afdata) @ /usr/src/sys/net/if.c:876 > 2nd 0xc0bf82c8 mld_mtx (mld_mtx) @ /usr/src/sys/netinet6/mld6.c:577 > KDB: stack backtrace: > db_trace_self_wrapper(c09cafad,e8b72a64,c06f0fe5,c06e1d9b,c09cde42,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c06e1d9b,c09cde42,c6113ca0,c610e9c0,e8b72ac0,...) at > kdb_backtrace+0x29 > _witness_debugger(c09cde42,c0bf82c8,c09cdfbe,c610e9c0,c09e6205,...) at > _witness_debugger+0x25 > witness_checkorder(c0bf82c8,9,c09e6205,241,0,...) at witness_checkorder+0x839 > _mtx_lock_flags(c0bf82c8,0,c09e6205,241,c79b6ac0,...) at _mtx_lock_flags+0xc4 > mld_domifdetach(c6793000,c6793208,c0a50c60,e8b72b64,c0755e1c,...) at > mld_domifdetach+0x2c > in6_domifdetach(c6793000,c79b6ac0,36c,440,c679322c,...) at in6_domifdetach+0x15 > if_detach(c6793000,c79de00c,e8b72b9c,c79be200,c79ed000,...) at if_detach+0x85c > ieee80211_ifdetach(c79ed000,0,c79c1c40,201,c6793000,...) at > ieee80211_ifdetach+0x14 > uath_detach(c6e84c00,c67cd860,c0a336c8,a3c,c06d7d89,...) at uath_detach+0x80 > device_detach(c6e84c00,c09b6190,c6773650,1,2,...) at device_detach+0x8c > usb_detach_device(c688c43c,0,c09b5fa1,199,19c1b4f,...) at > usb_detach_device+0x178 > usb_unconfigure(c789d400,c05ef530,c78801e0,7b4,0,...) at usb_unconfigure+0x5a > usb_free_device(c688c400,3,1,10,e8b72ca8,...) at usb_free_device+0x1be > uhub_explore(c6785400,0,c09b5463,e0,c6504d34,...) at uhub_explore+0x2a7 > usb_bus_explore(c6504d34,c6504dac,c09b768a,67,c0a89000,...) at > usb_bus_explore+0xbb > usb_process(c6504cd4,e8b72d38,c09c3242,342,c6744d48,...) at usb_process+0xde > fork_exit(c05faed0,c6504cd4,e8b72d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe8b72d70, ebp = 0 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xdeadc0de > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc074c318 > stack pointer = 0x28:0xc5f3f9e8 > frame pointer = 0x28:0xc5f3f9e8 > 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 = 11 (swi4: clock) > > Held locks: > exclusive sx 123456789ABCDEF - USB config SX lock (123456789ABCDEF - > USB config SX lock) r = 0 (0xc688c43c) locked @ > /usr/src/sys/dev/usb/usb_device.c:409 > exclusive sleep mutex Giant (Giant) r = 0 (0xc0a84a30) locked @ > /usr/src/sys/kern/kern_intr.c:1164 > shared sx module subsystem sx lock (module subsystem sx lock) r = 0 > (0xc0a83fe0) locked @ /usr/src/sys/kern/kern_module.c:103 > > More information from the textdump: > > db:1:locks> show alllocks > Process 29 (usbus3) thread 0xc6742000 (100057) > Process 11 (intr) thread 0xc643f480 (100021) > Process 1 (init) thread 0xc6178000 (100001) > db:1:alllocks> show lockedvnods > Locked vnodes > db:0:kdb.enter.default> show pcpu > cpuid = 0 > dynamic pcpu = 0x5b99f2 > curthread = 0xc6176480: pid 11 "swi4: clock" > curpcb = 0xc5f3fd90 > fpcurthread = none > idlethread = 0xc6176b40: pid 10 "idle: cpu0" > APIC ID = 0 > currentldt = 0x50 > spin locks held: > db:0:kdb.enter.default> bt > Tracing pid 11 tid 100006 td 0xc6176480 > strlen(deadc0de,c5f3fb38,4,80000000,c5f3fa7c,...) at strlen+0x8 > kvprintf(c09c6735,c06e0520,c5f3fb38,a,c5f3fb78,...) at kvprintf+0x8fe > vsnprintf(c0a84d00,100,c09c6735,c5f3fb78,0,...) at vsnprintf+0x3b > panic(c09c6735,deadc0de,c09ddcd9,645,c0a83210,...) at panic+0x8d > _mtx_lock_flags(c67e0000,0,c09ddcd9,645,c67e0000,...) at _mtx_lock_flags+0x9a > adhoc_age(c67f2800,c5f3fbe8,c06d2e0c,c0a83210,0,...) at adhoc_age+0x32 > sta_age(c67f2800,c5f3fc48,c078dd71,c79ed000,c6176480,...) at sta_age+0x1c > ieee80211_scan_timeout(c79ed000,c6176480,c0a852c0,c6176480,c5f3fc2c,...) > at ieee80211_scan_timeout+0x1c > ieee80211_node_timeout(c79ed000,0,c09c8fe3,176,c0a852f4,...) at > ieee80211_node_timeout+0x21 > softclock(c0a852c0,c5f3fcc8,c06a0834,c0a89680,c61b6b38,...) at softclock+0x24a > intr_event_execute_handlers(c6174aa0,c61b6b00,c09c34c7,4fc,c61b6b70,...) > at intr_event_execute_handlers+0x125 > ithread_loop(c610bbc0,c5f3fd38,c09c3242,342,c6174aa0,...) at ithread_loop+0x9f > fork_exit(c0689950,c610bbc0,c5f3fd38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc5f3fd70, ebp = 0 --- > > PID 11 is the "intr" process. > > A textdump (vm6.tar.gz) is available: > http://sites.google.com/site/lwfreebsd/Home/files/vm6.tar.gz?attredirects=0 Already passed about 3 months. :-) Could you please test with CURRENT to reproduce this problem? On my environment it doesn't happen anymore. I'd like to know this issue is still valid. > 2nd issue: > > With an plugged and firmware-loaded uath device (TRENDnet TEW-504UB in > my case), reboot the system. It is not initialized by uath until you > pull and plug it back in. > The USB descriptors, obtained by usbconfig dump_device_desc, are the > same before pulling and after reinitializing the device. > > Is there anything I can do to help fixing these issues? I tried to solve this issue on my amd64 machine but could not find a way to fix. It looks HAL interface doesn't have a API to reset full H/W and endpoint 0 also don't have a such feature. Only a way looks a bus reset event (EHCI_STS_RESET) currently depending on the system for example, powerpc I have seems it hasn't this problem but amd64 has. regards, Weongyo Jeong From faber at isi.edu Sat Oct 3 01:58:58 2009 From: faber at isi.edu (Ted Faber) Date: Sat Oct 3 01:59:06 2009 Subject: FreeBSD8-RELENG (sources from this morning) deadlock In-Reply-To: <1254522745.2549.6.camel@Lappy> References: <20090929041407.GA92280@zod.isi.edu> <20091002213116.GH88191@zod.isi.edu> <1254521690.2549.5.camel@Lappy> <20091002222753.GI88191@zod.isi.edu> <1254522745.2549.6.camel@Lappy> Message-ID: <20091003015810.GA1661@zod.isi.edu> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091003/982e26de/attachment.pgp From hselasky at c2i.net Sat Oct 3 07:52:32 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Oct 3 07:52:39 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: <20091002150931.K35591@pooker.samsco.org> References: <20091002150931.K35591@pooker.samsco.org> Message-ID: <200910030953.17359.hselasky@c2i.net> On Friday 02 October 2009 23:11:21 Scott Long wrote: > All, > > I have a candidate patch to fix the problem with USB boot media not being > found in time at boot, leading to the "mountroot" prompt instead of a > booting system. Please apply both patches below and let me know if it > works for you. Hi, Your patch looks OK. Some checkpoints however: Does your patch work if ehci/ohci/uhci is kldloaded after system startup? Does your patch work if CAM is not in the kernel? I have a simple imporovement to your patch: I would just add a synchronously blocking call to the end of "usb_bus_attach". Something like: #ifdef USB_HAVE_CAM static void usb_cam_wait_cb(void *arg) { struct usb_bus *bus = *(struct usb_bus **)arg; USB_BUS_LOCK(bus); *(struct usb_bus **)arg = NULL; wakeup(arg); USB_BUS_UNLOCK(bus); } static void usb_wait_cam(struct usb_bus *bus) { struct intr_config_hook *hook; void *temp = bus; hook = malloc(sizeof(*hook), M_TEMP, M_ZERO); hook->ich_func = usb_wait_cam_cb; hook->ich_arg = &temp; config_intrhook_establish(hook); USB_BUS_LOCK(bus); if (temp != NULL) mtx_sleep(&temp, &bus->bus_mtx, 0, "WCAM", 0); USB_BUS_UNLOCK(bus); } #endif That way makes the code more simple and avoids a race with the CAM callback being called after that the hardware is detached. For example if the Host Controller resides on a removable device. There are some more USB_HAVE_XXX in sys/dev/usb/usb_freebsd.h . --HPS From scottl at samsco.org Sat Oct 3 08:20:04 2009 From: scottl at samsco.org (Scott Long) Date: Sat Oct 3 08:20:11 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: <200910030953.17359.hselasky@c2i.net> References: <20091002150931.K35591@pooker.samsco.org> <200910030953.17359.hselasky@c2i.net> Message-ID: <3307DF7C-2FEF-468B-85F4-095BB7E3EE8F@samsco.org> On Oct 3, 2009, at 1:53 AM, Hans Petter Selasky wrote: > On Friday 02 October 2009 23:11:21 Scott Long wrote: >> All, >> >> I have a candidate patch to fix the problem with USB boot media not >> being >> found in time at boot, leading to the "mountroot" prompt instead of a >> booting system. Please apply both patches below and let me know if >> it >> works for you. > > Hi, > > Your patch looks OK. Some checkpoints however: > > Does your patch work if ehci/ohci/uhci is kldloaded after system > startup? > That's a good question, I forgot to check that case. It should, though, given how the config_intrhook API is designed to work. > Does your patch work if CAM is not in the kernel? > The change has no dependence on CAM. > I have a simple imporovement to your patch: > > I would just add a synchronously blocking call to the end of > "usb_bus_attach". > This isn't needed. The config_intrhook system will sleep after all hooks have been launched, and will wakeup as needed. There is no longer a race with CAM as CAM no longer uses the config_intrhook system, and is explicitly placed in order after it. Unfortunately, my patch doesn't solve the problem. It holds off the boot only while the root hub is explored. Hubs below the root get queued back to the explore thread and enumerated after the root hub has signaled to disestablish the config hook, leading to devices further down the chain getting discovered late. It's no better than the code that I deleted. I'm thinking through how to solve this. Ideally, a refcount/semaphore is kept during discovery. Every time a new hub is found, the semaphore is increased, the hub is reset/ configured, and control returns upwards until a config interrupt comes in. Then we look at each port on the hub, probe/attach new devices, and then down the semaphore at the conclusion. If one or more ports had hubs on them, then they would recurse this process. I'm not familiar enough with USB to know if this is even possible. I assume that a hub has to be reset before its ports can be probed, but I have no idea if there's a reliable way to know when the reset action has started and ended, other than to hope to get a config interrupt for one or more of the ports. But if a hub is empty of child devices, will any interrupts be generated? Maybe instead of relying on interrupts, we should just poll the ports for a period of time to see if they come alive. Dunno. I need to start reading specs. Scott From hselasky at c2i.net Sat Oct 3 10:30:06 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Oct 3 10:30:13 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: <3307DF7C-2FEF-468B-85F4-095BB7E3EE8F@samsco.org> References: <20091002150931.K35591@pooker.samsco.org> <200910030953.17359.hselasky@c2i.net> <3307DF7C-2FEF-468B-85F4-095BB7E3EE8F@samsco.org> Message-ID: <200910031230.51044.hselasky@c2i.net> On Saturday 03 October 2009 10:19:57 Scott Long wrote: > config_intrhook system will sleep after all Then why do you need the intr hook callback? --HPS From bofh at redwerk.com Sat Oct 3 11:40:05 2009 From: bofh at redwerk.com (Eugene Dzhurinsky) Date: Sat Oct 3 11:40:12 2009 Subject: Atheros WIFI is not recognized on FreeBSD 8.0-RC1 Message-ID: <20091003110914.GB71004@office.redwerk.com> Hi there! I am facing some strange issue with recognizing the wifi card on my ASUS K40IN laptop. pciconf -lv shows me the following: none5@pci0:5:0:0: class=0x028000 card=0x10891a3b chip=0x002b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' class = network On wiki page http://wiki.freebsd.org/AsusEee#head-47f2e69f1dd87ec8920929cef682552933095ce6 there is the statement: Wireless Atheros 9285 (supported in 8.0 only?) class=0x028000 card=0x10891a3b chip=0x002b168c rev=0xc0 hdr=0x00 the only difference is in "rev" property - 0x01 != 0xc0 The question is - is it possible to change something in the sources of kernel so the card will be recognized? And can somebody please explain what I should to try out? Thank you in advance! -- Eugene N Dzhurinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091003/f77e849d/attachment.pgp From gavin at FreeBSD.org Sat Oct 3 13:24:16 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Sat Oct 3 13:24:23 2009 Subject: FreeBSD8-RELENG (sources from this morning) deadlock In-Reply-To: <20091002213116.GH88191@zod.isi.edu> References: <20090929041407.GA92280@zod.isi.edu> <20091002213116.GH88191@zod.isi.edu> Message-ID: <20091003142303.L14313@ury.york.ac.uk> On Fri, 2 Oct 2009, Ted Faber wrote: > On Mon, Sep 28, 2009 at 09:14:07PM -0700, Ted Faber wrote: >> I've been havinhard time getting this motherboard to work under FreeBSD >> 8.0. It comes up fairly fine (though I didn't get the PATA disk >> identified under 7-STABLE so it may also be shaky under 8), but after >> between 3 and 10 minutes of running multi user it locks up hard, and >> wont respond to input at all. No keyboard response, couldn't get into a >> kernel debugger, nothing. I couldn't get a kernel dump for that reason. > > I'm still deadlocked, but trying to get more info. I tried a firewire > debugging session using dcons, but that failed for reasons unclear. > dconschat seems to do the right thing: > > --- > musicbox:~$ sudo dconschat -v ‐br ‐G 12345 ‐t 00-00-4c-01-00-00-3b-c7 > dconschat: kvm_nlist: No such file or directory > dcons_buf: 0xc0d74740 > port 0 size offset gen pos > output: 9184 56 1 1550 > input : 3062 9240 0 106 > port 1 size offset gen pos > output: 3061 12302 0 0 > input : 1021 15363 0 0 > [dcons connected] > (1)(1)(1)(1)(1) > --- > > But the gdb fails to connect: > > ---- > musicbox:~$ kgdb kernel > 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"...(no debugging symbols found)... > (kgdb) target remote :12345 > :12345: Connection refused. > ---- Do you have options GDB/DDB/KDB in your kernel? Gavin From lotte at winnipeg.nl Sat Oct 3 14:21:05 2009 From: lotte at winnipeg.nl (Lotte-Sara Laan) Date: Sat Oct 3 14:26:36 2009 Subject: xenU - FreeBSD 8.0 CURRENT rev. 197720 kernel panic Message-ID: <4AC7578A.4060400@winnipeg.nl> I'm trying to get FreeBSD CURRENT working under Xen 3.4.1 using the Gentoo dom0 kernel 2.6.29.6 I downloaded and compiled the 8.0 svn version revision 197720 from http://svn.freebsd.org/base/head with the KERNCONF=XEN option but when I'm starting my domU I'm getting the following panic: WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #1 r197720: Sat Oct 3 14:09:31 CEST 2009 root@freebsd.winnipeg.nl:/usr/local/xen/current-obj/usr/src/sys/XEN-LOTJUH i386 WARNING: WITNESS option enabled, expect reduced performance. Xen reported: 2611.800 MHz processor. Timecounter "ixen" frequency 1000000000 Hz quality 0 CPU: AMD Phenom(tm) II X4 810 Processor (2611.80-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant Data TLB: 48 entries, fully associative Instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 1073741824 (1024 MB) Physical memory chunk(s): 0x00000000008ab000 - 0x000000003ecb2fff, 1044414464 bytes (254984 pages) avail memory = 1040429056 (992 MB) APIC: Using the MPTable enumerator. SMP: Added CPU 0 (BSP) SMP: Added CPU 1 (AP) SMP: Added CPU 2 (AP) SMP: Added CPU 3 (AP) panic: HYPERVISOR_update_va_mapping(((unsigned long)(va)), (pa | 0x002 | 0x001 | pgeflag | pmap_cache_bits(mode, 0)), UVMF_INVLPG| UVMF_ALL) < 0: /usr/src/sys/i386/xen/pmap.c:1269 cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 0 tid 0 td 0xc03e10f0 kdb_enter(c03698a8,c03698a8,c038e3f1,c06f9cd4,0,...) at kdb_enter+0x3a panic(c038e3f1,c0396429,c0396207,4f5,0,...) at panic+0x136 pmap_mapdev_attr(0,0,100000,6,c06f9d44,...) at pmap_mapdev_attr+0x13d pmap_mapbios(0,0,100000,1,c03c946c,...) at pmap_mapbios+0x27 x86bios_intr(c36e4840,0,0,76,c0395e2b,...) at x86bios_intr+0x1b0 module_register_init(c03dbe88,3040800,3040800,6fe000,0,...) at module_register_init+0xa7 mi_startup(6fe000,0,0,0,0,...) at mi_startup+0x96 btext() at btext+0x95 db> I'm getting the same panic when I add only 1 cpu. I'm using the following boot line for pygrub: kernel /boot/kernel/kernel vfs.root.mountfrom=ufs:xbd0,kern.hz=100,kern.smp.disabled=1,boot_verbose=1,boot_single=1 I've tried it with and without the kern.smp.disabled option Does anyone have any ideas about what's going wrong? Lotte-Sara Laan From scottl at samsco.org Sat Oct 3 15:05:46 2009 From: scottl at samsco.org (Scott Long) Date: Sat Oct 3 15:05:53 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: <200910031230.51044.hselasky@c2i.net> References: <20091002150931.K35591@pooker.samsco.org> <200910030953.17359.hselasky@c2i.net> <3307DF7C-2FEF-468B-85F4-095BB7E3EE8F@samsco.org> <200910031230.51044.hselasky@c2i.net> Message-ID: On Oct 3, 2009, at 4:30 AM, Hans Petter Selasky wrote: > On Saturday 03 October 2009 10:19:57 Scott Long wrote: >> config_intrhook system will sleep after all > > Then why do you need the intr hook callback? > The config_intrhook lets you know that interrupts are enabled, the scheduler is running, and mountroot hasn't run yet. It provides a very convenient and standard way to do exactly what we want with USB enumeration. Scott From gary.jennejohn at freenet.de Sat Oct 3 15:09:58 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sat Oct 3 15:10:04 2009 Subject: Atheros WIFI is not recognized on FreeBSD 8.0-RC1 In-Reply-To: <20091003110914.GB71004@office.redwerk.com> References: <20091003110914.GB71004@office.redwerk.com> Message-ID: <20091003170955.0667edba@ernst.jennejohn.org> On Sat, 3 Oct 2009 14:09:14 +0300 Eugene Dzhurinsky wrote: > Hi there! > > I am facing some strange issue with recognizing the wifi card on my ASUS K40IN > laptop. > > pciconf -lv shows me the following: > > none5@pci0:5:0:0: class=0x028000 card=0x10891a3b chip=0x002b168c rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > class = network > > On wiki page http://wiki.freebsd.org/AsusEee#head-47f2e69f1dd87ec8920929cef682552933095ce6 > > there is the statement: > > Wireless Atheros 9285 (supported in 8.0 only?) class=0x028000 card=0x10891a3b chip=0x002b168c rev=0xc0 hdr=0x00 > > the only difference is in "rev" property - 0x01 != 0xc0 > > The question is - is it possible to change something in the sources of kernel > so the card will be recognized? And can somebody please explain what I should > to try out? > I'm no expert on Atheros. In /sys/dev/ath/ath_hal/ah_devid.h there's a #define AR9285_DEVID_PCIE 0x002b /* AR9285 PCI-E Kite */ but it isn't used in any C source file. Note that the entry in the Wiki isn't claiming that this chip works. The poster is merely wondering whether it might be supported in 8.0 and later FreeBSD versions. Looks like it isn't. --- Gary Jennejohn From scottl at samsco.org Sat Oct 3 15:45:10 2009 From: scottl at samsco.org (Scott Long) Date: Sat Oct 3 15:45:21 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: References: <20091002150931.K35591@pooker.samsco.org> <200910030953.17359.hselasky@c2i.net> <3307DF7C-2FEF-468B-85F4-095BB7E3EE8F@samsco.org> <200910031230.51044.hselasky@c2i.net> Message-ID: <3D59CB10-7589-41F7-A00F-73224F16C6A7@samsco.org> On Oct 3, 2009, at 9:05 AM, Scott Long wrote: > On Oct 3, 2009, at 4:30 AM, Hans Petter Selasky wrote: >> On Saturday 03 October 2009 10:19:57 Scott Long wrote: >>> config_intrhook system will sleep after all >> >> Then why do you need the intr hook callback? >> > > The config_intrhook lets you know that interrupts are enabled, the > scheduler is running, and mountroot hasn't run yet. It provides a > very convenient and standard way to do exactly what we want with USB > enumeration. > Now that I'm awake, let me explain more. I'm moving USB from the mount_root_hold() API to the config_intrhook() API because the latter provides proper boot ordering with CAM, which the former does not. Though my published patch doesn't rely on the CAM system in order to function, if you want umass devices to be discovered in time, you need it. What I didn't realize when I published my patch is that my approach is incomplete; I'm working to fix that, but it will likely require some significant work inside of USB. Scott From hselasky at c2i.net Sat Oct 3 15:59:40 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Oct 3 15:59:48 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: References: <20091002150931.K35591@pooker.samsco.org> <200910031230.51044.hselasky@c2i.net> Message-ID: <200910031800.24896.hselasky@c2i.net> On Saturday 03 October 2009 17:05:35 Scott Long wrote: > On Oct 3, 2009, at 4:30 AM, Hans Petter Selasky wrote: > > On Saturday 03 October 2009 10:19:57 Scott Long wrote: > >> config_intrhook system will sleep after all > > > > Then why do you need the intr hook callback? > > The config_intrhook lets you know that interrupts are enabled, the > scheduler is running, and mountroot hasn't run yet. It provides a > very convenient and standard way to do exactly what we want with USB > enumeration. Hi, The root HUB attach and explore code is already running from a separate thread, so won't that be superfluous? I mean, the HUB explore code for any USB HUB will not run until the scheduler is running anyway. In my opinion delaying the system until the boot disk is present is just not good. We should rather be event driven, so that every time a new disk becomes present it checks it for mountroot. while (1) { if (mountroot is successful) break; if (ctrl+c is pressed) manual_mountroot(); printf("Waiting 1 second for root-disk to appear. Press CTRL+C to abort.\n"); sleep(1); } --HPS From scottl at samsco.org Sat Oct 3 16:05:42 2009 From: scottl at samsco.org (Scott Long) Date: Sat Oct 3 16:05:48 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: <200910031800.24896.hselasky@c2i.net> References: <20091002150931.K35591@pooker.samsco.org> <200910031230.51044.hselasky@c2i.net> <200910031800.24896.hselasky@c2i.net> Message-ID: On Oct 3, 2009, at 10:00 AM, Hans Petter Selasky wrote: > On Saturday 03 October 2009 17:05:35 Scott Long wrote: >> On Oct 3, 2009, at 4:30 AM, Hans Petter Selasky wrote: >>> On Saturday 03 October 2009 10:19:57 Scott Long wrote: >>>> config_intrhook system will sleep after all >>> >>> Then why do you need the intr hook callback? >> >> The config_intrhook lets you know that interrupts are enabled, the >> scheduler is running, and mountroot hasn't run yet. It provides a >> very convenient and standard way to do exactly what we want with USB >> enumeration. > > Hi, > > The root HUB attach and explore code is already running from a > separate > thread, so won't that be superfluous? I mean, the HUB explore code > for any USB > HUB will not run until the scheduler is running anyway. > > In my opinion delaying the system until the boot disk is present is > just not > good. We should rather be event driven, so that every time a new > disk becomes > present it checks it for mountroot. > > while (1) { > if (mountroot is successful) > break; > if (ctrl+c is pressed) > manual_mountroot(); > printf("Waiting 1 second for root-disk to appear. Press CTRL+C > to > abort.\n"); > sleep(1); > } > That's an interesting idea. If you can make this work, go for it. Meanwhile, I'm going to continue to look at the usb enumeration code. Scott From scottl at samsco.org Sat Oct 3 16:13:58 2009 From: scottl at samsco.org (Scott Long) Date: Sat Oct 3 16:14:19 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: <200910031800.24896.hselasky@c2i.net> References: <20091002150931.K35591@pooker.samsco.org> <200910031230.51044.hselasky@c2i.net> <200910031800.24896.hselasky@c2i.net> Message-ID: On Oct 3, 2009, at 10:00 AM, Hans Petter Selasky wrote: > On Saturday 03 October 2009 17:05:35 Scott Long wrote: >> On Oct 3, 2009, at 4:30 AM, Hans Petter Selasky wrote: >>> On Saturday 03 October 2009 10:19:57 Scott Long wrote: >>>> config_intrhook system will sleep after all >>> >>> Then why do you need the intr hook callback? >> >> The config_intrhook lets you know that interrupts are enabled, the >> scheduler is running, and mountroot hasn't run yet. It provides a >> very convenient and standard way to do exactly what we want with USB >> enumeration. > > Hi, > > The root HUB attach and explore code is already running from a > separate > thread, so won't that be superfluous? I mean, the HUB explore code > for any USB > HUB will not run until the scheduler is running anyway. > > In my opinion delaying the system until the boot disk is present is > just not > good. We should rather be event driven, so that every time a new > disk becomes > present it checks it for mountroot. > > while (1) { > if (mountroot is successful) > break; > if (ctrl+c is pressed) > manual_mountroot(); > printf("Waiting 1 second for root-disk to appear. Press CTRL+C > to > abort.\n"); > sleep(1); > } > Actually, if you want to truly be event based, then instead of sleeping for a fixed time and then polling for devices, go to sleep and have GEOM wake you up when a disk device arrives. You can still wake up periodically to provide status to the user (or not, it might get too noisy). Scott From bofh at redwerk.com Sat Oct 3 16:41:13 2009 From: bofh at redwerk.com (Eugene Dzhurinsky) Date: Sat Oct 3 16:41:20 2009 Subject: Atheros WIFI is not recognized on FreeBSD 8.0-RC1 In-Reply-To: <20091003170955.0667edba@ernst.jennejohn.org> References: <20091003110914.GB71004@office.redwerk.com> <20091003170955.0667edba@ernst.jennejohn.org> Message-ID: <20091003164110.GA13415@office.redwerk.com> On Sat, Oct 03, 2009 at 05:09:55PM +0200, Gary Jennejohn wrote: > On Sat, 3 Oct 2009 14:09:14 +0300 > Eugene Dzhurinsky wrote: > > I'm no expert on Atheros. In /sys/dev/ath/ath_hal/ah_devid.h there's a > #define AR9285_DEVID_PCIE 0x002b /* AR9285 PCI-E Kite */ > but it isn't used in any C source file. > > Note that the entry in the Wiki isn't claiming that this chip works. > The poster is merely wondering whether it might be supported in 8.0 > and later FreeBSD versions. > > Looks like it isn't. That's too bad. Allright, than I'll wait until this chip will get support for FreeBSD. Thank you for the quick and prompt response! -- Eugene N Dzhurinsky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091003/c5badfa3/attachment.pgp From hselasky at c2i.net Sat Oct 3 17:30:41 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Oct 3 17:30:48 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: References: <20091002150931.K35591@pooker.samsco.org> <200910031800.24896.hselasky@c2i.net> Message-ID: <200910031931.24600.hselasky@c2i.net> On Saturday 03 October 2009 18:05:32 Scott Long wrote: > That's an interesting idea. If you can make this work, go for it. > Meanwhile, I'm going to continue to look at the usb enumeration code. Please find attached an outline. I need one more hour to finalize the patch. All existing mount root features have been kept. The only difference is that the system will not panic before 3 minutes, if no root disk is present. I think that is acceptable. --HPS -------------- next part -------------- A non-text attachment was scrubbed... Name: mount_root_outline.diff Type: text/x-patch Size: 14770 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091003/7baf85aa/mount_root_outline.bin From xcllnt at mac.com Sat Oct 3 18:51:19 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Oct 3 18:51:25 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: <200910031800.24896.hselasky@c2i.net> References: <20091002150931.K35591@pooker.samsco.org> <200910031230.51044.hselasky@c2i.net> <200910031800.24896.hselasky@c2i.net> Message-ID: On Oct 3, 2009, at 9:00 AM, Hans Petter Selasky wrote: > On Saturday 03 October 2009 17:05:35 Scott Long wrote: >> On Oct 3, 2009, at 4:30 AM, Hans Petter Selasky wrote: >>> On Saturday 03 October 2009 10:19:57 Scott Long wrote: >>>> config_intrhook system will sleep after all >>> >>> Then why do you need the intr hook callback? >> >> The config_intrhook lets you know that interrupts are enabled, the >> scheduler is running, and mountroot hasn't run yet. It provides a >> very convenient and standard way to do exactly what we want with USB >> enumeration. > > Hi, > > The root HUB attach and explore code is already running from a > separate > thread, so won't that be superfluous? I mean, the HUB explore code > for any USB > HUB will not run until the scheduler is running anyway. > > In my opinion delaying the system until the boot disk is present is > just not > good. We should rather be event driven, so that every time a new > disk becomes > present it checks it for mountroot. > > while (1) { > if (mountroot is successful) > break; > if (ctrl+c is pressed) > manual_mountroot(); > printf("Waiting 1 second for root-disk to appear. Press CTRL+C > to > abort.\n"); > sleep(1); > } Yes. The mount root code should keep a list of potential root devices to try and it should try a device as soon as it appears. The current approach to block the root mount simply because we want everything to be discovered before we try to mount the root is preventing fast boots -- such as when the root is a memory disk and you don't need to wait for anything... Put differently: it's rather odd to hold off the root mount when the root device is already present... An approach like this also allows one to indefinitely wait for the root device, which is a good feature to have... -- Marcel Moolenaar xcllnt@mac.com From spambox at haruhiism.net Sat Oct 3 18:58:26 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Sat Oct 3 18:58:33 2009 Subject: Another panic (during netisr?) In-Reply-To: <20091002191255.J26486@maildrop.int.zabbadoz.net> References: <4AC61ED6.1090802@haruhiism.net> <20091002191255.J26486@maildrop.int.zabbadoz.net> Message-ID: <4AC79ED2.5060507@haruhiism.net> Hello, On 02.10.2009 23:14, Bjoern A. Zeeb wrote: >> This is on FreeBSD 8.0-BETA3 (Ameagari) #23 r196460: Mon Aug 24 >> 00:36:33 JST 2009; not sure if it has been witnessed or fixed. I've >> been running it without restarts to test the stability and here we go: >> >> Unread portion of the kernel message buffer: >> panic: tcp_input: so == NULL > > This looks like an explicit panic unrelated to the netisr in first > place. > > More likely a race condition with socket teardown which should not > happen in theory;) Oh, so it's just like that panic in tcp_sack then. ;) I've replaced the CPU in the server (was: dual core, now: quad core) for even more chances for a race condition to strike; waiting for this one to re-appear again now on 8.0-RC1 ;) (Though 39 days of uptime was a pretty good result for BETA3, I can't say I'm satisfied, as I have yet to see my 7.2-STABLE server panic; 39 days is not impressive when it comes to production use including running ircd for a large network.) I do indeed hope that it will never happen again. -- Kamigishi Rei KREI-RIPE fujibayashi.jp From dougb at FreeBSD.org Sat Oct 3 19:04:38 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sat Oct 3 19:04:46 2009 Subject: Another panic (during netisr?) In-Reply-To: <4AC79ED2.5060507@haruhiism.net> References: <4AC61ED6.1090802@haruhiism.net> <20091002191255.J26486@maildrop.int.zabbadoz.net> <4AC79ED2.5060507@haruhiism.net> Message-ID: <4AC7A043.6030404@FreeBSD.org> Kamigishi Rei wrote: > I've replaced the CPU in the server (was: dual core, now: quad core) for > even more chances for a race condition to strike; waiting for this one > to re-appear again now on 8.0-RC1 ;) (Though 39 days of uptime was a > pretty good result for BETA3, I can't say I'm satisfied, as I have yet > to see my 7.2-STABLE server panic; 39 days is not impressive when it > comes to production use including running ircd for a large network.) As a former IRC server operator I completely agree with you. :) However this is why testing of the sort that you are doing is SO critical to the success of a new release. Please accept our sincere gratitude for the testing, feedback, and testing of new patches. Without users like you we would not be even a fraction as successful as we have been to date. Doug -- This .signature sanitized for your protection From ggajic at afrodita.rcub.bg.ac.rs Sat Oct 3 17:01:41 2009 From: ggajic at afrodita.rcub.bg.ac.rs (Goran Gajic) Date: Sat Oct 3 19:35:26 2009 Subject: 8.0RC1: Can't mount usb stick In-Reply-To: <54980020@bb.ipt.ru> References: <54980020@bb.ipt.ru> Message-ID: No this one is formated in XP style, so there is no /dev/da0s1. But that is not the only problem I have noticed. I wanted to take image of USB stick just in case I might need it, since I did newfs_msdos /dev/da0.. However during cat /dev/da0 > usb.img read seems to hang.. Also, when I have tried to put some image (in FreeBSD 8.0RC1) on that same stick, when I did cat usb_old.img > /dev/da0 same happens - system hangs. When I have tried same thing under Linux it worked with no problems. gg. On Fri, 2 Oct 2009, Boris Samorodov wrote: > On Fri, 2 Oct 2009 10:25:16 +0200 (CEST) Goran Gajic wrote: > >> da0 at umass-sim0 bus 0 target 0 lun 0 >> da0: < USB FLASH DRIVE PMAP> Removable Direct Access SCSI-0 device >> da0: 40.000MB/s transfers >> da0: 1968MB (4030464 512 byte sectors: 255H 63S/T 250C) > >> # mount -t msdosfs /dev/da0 /mnt >> mount_msdosfs: /dev/da0: Invalid argument > > Take a look at /dev/da0*. MS DOS usually uses partition s1, > so your command should be: > ----- > # mount -t msdosfs /dev/da0s1 /mnt > ----- > > From hselasky at c2i.net Sat Oct 3 21:05:16 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Oct 3 21:05:24 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: References: <20091002150931.K35591@pooker.samsco.org> <200910031800.24896.hselasky@c2i.net> Message-ID: <200910032306.01529.hselasky@c2i.net> On Saturday 03 October 2009 20:51:07 Marcel Moolenaar wrote: > On Oct 3, 2009, at 9:00 AM, Hans Petter Selasky wrote: > > An approach like this also allows one to indefinitely wait for the root > device, which is a good feature to have... Here is a patch you can try: http://perforce.freebsd.org/chv.cgi?CH=169183 NOTE: I was not able to get any characters from gets() nor cncheckc(), so there seems to be a bug somewhere. This used to work before at mount-root time. --HPS From scottl at samsco.org Sat Oct 3 23:52:56 2009 From: scottl at samsco.org (Scott Long) Date: Sat Oct 3 23:53:08 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: References: <20091002150931.K35591@pooker.samsco.org> <200910031230.51044.hselasky@c2i.net> <200910031800.24896.hselasky@c2i.net> Message-ID: <30F3E66A-4A69-46CE-96F4-44B4049722E2@samsco.org> On Oct 3, 2009, at 12:51 PM, Marcel Moolenaar wrote: > > On Oct 3, 2009, at 9:00 AM, Hans Petter Selasky wrote: > >> On Saturday 03 October 2009 17:05:35 Scott Long wrote: >>> On Oct 3, 2009, at 4:30 AM, Hans Petter Selasky wrote: >>>> On Saturday 03 October 2009 10:19:57 Scott Long wrote: >>>>> config_intrhook system will sleep after all >>>> >>>> Then why do you need the intr hook callback? >>> >>> The config_intrhook lets you know that interrupts are enabled, the >>> scheduler is running, and mountroot hasn't run yet. It provides a >>> very convenient and standard way to do exactly what we want with USB >>> enumeration. >> >> Hi, >> >> The root HUB attach and explore code is already running from a >> separate >> thread, so won't that be superfluous? I mean, the HUB explore code >> for any USB >> HUB will not run until the scheduler is running anyway. >> >> In my opinion delaying the system until the boot disk is present is >> just not >> good. We should rather be event driven, so that every time a new >> disk becomes >> present it checks it for mountroot. >> >> while (1) { >> if (mountroot is successful) >> break; >> if (ctrl+c is pressed) >> manual_mountroot(); >> printf("Waiting 1 second for root-disk to appear. Press CTRL+C >> to >> abort.\n"); >> sleep(1); >> } > > Yes. > > The mount root code should keep a list of potential root devices to > try and > it should try a device as soon as it appears. The current approach > to block > the root mount simply because we want everything to be discovered > before we > try to mount the root is preventing fast boots -- such as when the > root is > a memory disk and you don't need to wait for anything... > > Put differently: it's rather odd to hold off the root mount when the > root > device is already present... > > An approach like this also allows one to indefinitely wait for the > root > device, which is a good feature to have... > > When /etc/rc tries to mount everything in the fstab, it'll fail the boot if some of the devices haven't arrived in time. An argument can be made for fixing that as well, but we're starting to get beyond on the scope of fixing what is needed for 8.0-RELEASE. Scott From xcllnt at mac.com Sat Oct 3 23:54:16 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Oct 3 23:54:22 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: <30F3E66A-4A69-46CE-96F4-44B4049722E2@samsco.org> References: <20091002150931.K35591@pooker.samsco.org> <200910031230.51044.hselasky@c2i.net> <200910031800.24896.hselasky@c2i.net> <30F3E66A-4A69-46CE-96F4-44B4049722E2@samsco.org> Message-ID: <298411E4-5B6D-4FB1-B7A9-3170D715180B@mac.com> On Oct 3, 2009, at 4:52 PM, Scott Long wrote: > > When /etc/rc tries to mount everything in the fstab, it'll fail the > boot if some of the devices haven't arrived in time. An argument > can be made for fixing that as well, but we're starting to get > beyond on the scope of fixing what is needed for 8.0-RELEASE. Agreed. -- Marcel Moolenaar xcllnt@mac.com From faber at isi.edu Sun Oct 4 01:47:21 2009 From: faber at isi.edu (Ted Faber) Date: Sun Oct 4 01:47:30 2009 Subject: FreeBSD8-RELENG (sources from this morning) deadlock In-Reply-To: <20091003142303.L14313@ury.york.ac.uk> References: <20090929041407.GA92280@zod.isi.edu> <20091002213116.GH88191@zod.isi.edu> <20091003142303.L14313@ury.york.ac.uk> Message-ID: <20091004014720.GA23086@zod.isi.edu> On Sat, Oct 03, 2009 at 02:24:11PM +0100, Gavin Atkinson wrote: > Do you have options GDB/DDB/KDB in your kernel? On the target but not the debugging host. Do both need it? -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091004/7fa9bb71/attachment.pgp From gary.jennejohn at freenet.de Sun Oct 4 07:48:36 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sun Oct 4 07:48:43 2009 Subject: 8.0RC1: Can't mount usb stick In-Reply-To: References: <54980020@bb.ipt.ru> Message-ID: <20091004094833.2a28c12f@ernst.jennejohn.org> On Sat, 3 Oct 2009 19:01:35 +0200 (CEST) Goran Gajic wrote: > No this one is formated in XP style, so there is no /dev/da0s1. But that > is not the only problem I have noticed. I wanted to take image of USB > stick just in case I might need it, since I did newfs_msdos /dev/da0.. However > during cat /dev/da0 > usb.img read seems to hang.. Also, when I have tried > to put some image (in FreeBSD 8.0RC1) on that same stick, when I did > cat usb_old.img > /dev/da0 same happens - system hangs. When I have tried > same thing under Linux it worked with no problems. > cat is the wrong thing to use for making/copying images. Use dd instead with e.g. conv=sync. --- Gary Jennejohn From gavin.atkinson at ury.york.ac.uk Sun Oct 4 12:41:31 2009 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Sun Oct 4 12:41:38 2009 Subject: FreeBSD8-RELENG (sources from this morning) deadlock In-Reply-To: <20091004014720.GA23086@zod.isi.edu> References: <20090929041407.GA92280@zod.isi.edu> <20091002213116.GH88191@zod.isi.edu> <20091003142303.L14313@ury.york.ac.uk> <20091004014720.GA23086@zod.isi.edu> Message-ID: <20091004133702.L14313@ury.york.ac.uk> On Sat, 3 Oct 2009, Ted Faber wrote: > On Sat, Oct 03, 2009 at 02:24:11PM +0100, Gavin Atkinson wrote: >> Do you have options GDB/DDB/KDB in your kernel? > > On the target but not the debugging host. Do both need it? No, just the target should be fine. Last time I needed to do anything like this, I just followed the instructions at http://wiki.freebsd.org/DebugWithDcons and it worked fine. I'm guessing that's the article you also followed? Sorry I can't help more! Gavin From taku at tackymt.homeip.net Sun Oct 4 13:50:05 2009 From: taku at tackymt.homeip.net (Taku YAMAMOTO) Date: Sun Oct 4 13:50:12 2009 Subject: pam_ssh no longer works after r197679 Message-ID: <20091004225000.6a1a6262.taku@tackymt.homeip.net> Greetings, After the upgrade to OpenSSH 5.3p1 in r197679, pam_ssh doesn't seem to work any longer. In /var/log/messages: Oct 4 10:39:09 basalt xdm: in openpam_load_module(): no pam_ssh.so found # I use pam_ssh for graphical login. A quick investigation revailed that libssh.so.5 had some symbols undefined, which prevented pam_ssh.so.5 from being loaded. # FYI: openpam dlopen()s modules with RTLD_NOW. Here's interesting bits from nm -D /usr/lib/libssh.so.5 | fgrep U U roaming_read U roaming_write Virtually yours, -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From danny at cs.huji.ac.il Sun Oct 4 13:58:19 2009 From: danny at cs.huji.ac.il (Daniel Braniss) Date: Sun Oct 4 13:58:25 2009 Subject: 8.0RC1 and BOOTP_NFSV3 regression? Message-ID: I'm not sure when this happened, but a kernel compiled with BOOTP_NFSV3 fails when the server is not FreeBSD (ie NetAPP). before, with the option set, only when kernel_options="nfsv3" was set it would fail/panic, this way, I could control which diskless, shearing the same kernel, would boot with nfsv3 and which not, dependig on the server. there is hope! before it would panic when receiving a v3 file handle, now it fails, but panics later when no init is found :-) is anyone with enough nfs v2/v3 knowledge willing to fix this? cheers, danny From danger at FreeBSD.org Sun Oct 4 14:44:59 2009 From: danger at FreeBSD.org (Daniel Gerzo) Date: Sun Oct 4 14:45:06 2009 Subject: [Fwd: HEADSUP: Call for FreeBSD Status Reports] Message-ID: <4AC8B4E8.7080106@FreeBSD.org> Hello guys, I would like to remind you about the FreeBSD Status Reports. The deadline is set to October 7th, and to date I have received only 5 reports, which is very little (considering the fact we are now covering almost 6 months). If you think you have anything to share with the community through the status report entry, please email us at monthly@freebsd.org as soon as possible. It really doesn't have to be a whole article, just a few lines about what you are working on. Thank you! -------- Original Message -------- Subject: HEADSUP: Call for FreeBSD Status Reports Date: Thu, 24 Sep 2009 17:07:29 +0200 From: Daniel Gerzo Organization: The FreeBSD Project To: current@freebsd.org, hackers@freebsd.org, stable@freebsd.org Dear all, I would like to remind you to submit your status reports as soon as possible. Long time has passed since the last status reports were released; and surely a lot has had happened since then. Our developers are relaxed after DevSummit and EuroBSDCon in Cambridge, which both were great! I believe a lot of stuff has been discussed during these events (I hope we will have reports covering this too) and since the last report a lot of things have happened. During that time, two other conferences have been held (BSDCan and AsiaBSDCon), we have released 7.2, not to mention that 8.0 is behind the door. Google Summer of Code should be finished by now too, and we would like to hear about its results. Surely there are a lot more projects which are currently being worked on, so please do not hesitate and write us a few lines - a short description about what you are working on, what are the plans and goals, so we can inform our community about your great work! It's useful for you as well as our users! Please note, the submissions for this quarter (well...rather halfyear, because we should now cover 4-9/2009) are due by October 7th, 2009. Please post the filled-in XML template to be found at http://www.freebsd.org/news/status/report-sample.xml to monthly@FreeBSD.org, or alternatively use our web based form at http://www.freebsd.org/cgi/monthly.cgi. We are looking forward to see your submissions! -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From vinnix.bsd at gmail.com Sun Oct 4 15:14:06 2009 From: vinnix.bsd at gmail.com (Vinicius Abrahao) Date: Sun Oct 4 15:14:18 2009 Subject: CFH: fix multimedia/pwcbsd with usb2 In-Reply-To: <200909131508.05025.hselasky@c2i.net> References: <20090908201713.GD41185@e.0x20.net> <1e31c7980909130516g1b3cb9fn5df77c23ec072413@mail.gmail.com> <200909131508.05025.hselasky@c2i.net> Message-ID: <1e31c7980910040814o48a1a57bgde86571fa3265c4c@mail.gmail.com> Hi Hans, Thanks for your help! I try to do exactly what you say, but without success. When I attach my camera I see at dmesg: ugen2.3: at usbus2 Trying pwcview: #./pwcview -d /dev/ugen2.3 Failed to access webcam: Operation not supported by device *********************************************************** Make sure you have connected your webcam to the root hub or to a USB 1.1 hub, also check your dmesg for any errors. *********************************************************** What I'm doing wrong? Thanks again, Best regards, Vin?cius On 9/13/09, Hans Petter Selasky wrote: > On Sunday 13 September 2009 14:16:10 Vinicius Abrahao wrote: >> Thanks Florent, >> >> That's it for sure. I recompile my kernel yesterday and now pwcbsd is >> loading normally. >> Therefore, now I see that pwc is the wrong driver for me. My webcam is >> a Philips SPC500NC. >> ID 093a:2603 Pixart Imaging, Inc. >> >> At Google I found that linux-gspca-kmod is the right driver for me. >> But this seen broken as >> pwcbsd was in the past. > > Hi, > > The closes you will currently get is: > > svn --username anonsvn --password anonsvn \ > checkout svn://svn.turbocat.net/i4b/trunk/usbcam/ulinux > > As root: > > make fetch > make patch > make > > You manually have to patch: > > ee libv4l/v4l2-apps/libv4l/libv4lconvert/control/libv4lcontrol.c > > control/libv4lcontrol.c: In function 'v4lcontrol_vidioc_queryctrl': > control/libv4lcontrol.c:586: error: '__u32' undeclared (first use in this > function) > control/libv4lcontrol.c:586: error: (Each undeclared identifier is reported > only once > control/libv4lcontrol.c:586: error: for each function it appears in.) > control/libv4lcontrol.c:586: error: expected ';' before 'orig_id' > control/libv4lcontrol.c:600: error: 'orig_id' undeclared (first use in this > function) > > __u32 to uint32_t > > In the end: > > cd pwcview > > ./pwcview > > > Should bring your webcam right up in userland though. > > --HPS > > From lwindschuh at googlemail.com Sun Oct 4 15:15:16 2009 From: lwindschuh at googlemail.com (Lucius Windschuh) Date: Sun Oct 4 15:15:26 2009 Subject: uath0 issues: eject-caused panic, won't work after a restart. In-Reply-To: <20091003014251.GI1454@weongyo> References: <90a5caac0907120353k69fb4f23q5e2f0eff35cfa2c5@mail.gmail.com> <20091003014251.GI1454@weongyo> Message-ID: <90a5caac0910040815l1f8a4d8dj3352568227c3c386@mail.gmail.com> Hi. 2009/10/3 Weongyo Jeong : > On Sun, Jul 12, 2009 at 12:53:38PM +0200, Lucius Windschuh wrote: >> Hi guys, >> I'm using CURRENT r195362MP and have two issues with it. >> >> 1st: Pulling the device while the kernel was nearly finished shutting >> down shutting down resulted in a kernel panic: >> > [...] > Already passed about 3 months. ?:-) > > Could you please test with CURRENT to reproduce this problem? ?On my > environment it doesn't happen anymore. ?I'd like to know this issue is > still valid. I can't reproduce this problem either. It seems that this problem is fixed: Pulling the device out in different stages of the shutdown process did not result in a panic. Fine, when time destroys bugs. :-D >> 2nd issue: >> >> With an plugged and firmware-loaded uath device (TRENDnet TEW-504UB in >> my case), reboot the system. It is not initialized by uath until you >> pull and plug it back in. >> The USB descriptors, obtained by usbconfig dump_device_desc, are the >> same before pulling and after reinitializing the device. >> >> Is there anything I can do to help fixing these issues? > > I tried to solve this issue on my amd64 machine but could not find a way > to fix. ?It looks HAL interface doesn't have a API to reset full H/W and > endpoint 0 also don't have a such feature. ?Only a way looks a bus reset > event (EHCI_STS_RESET) currently depending on the system for example, > powerpc I have seems it hasn't this problem but amd64 has. If a bus reset only affects the device and not a whole bus, this is worth a try. Regards Lucius From arno at heho.snv.jussieu.fr Sun Oct 4 15:33:53 2009 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Sun Oct 4 15:34:00 2009 Subject: Data corruption with checksum offloading enabled In-Reply-To: <20090814021340.GA1275@hades.panopticon> (Dmitry Marakasov's message of "Fri\, 14 Aug 2009 06\:13\:40 +0400") References: <20090123221826.GB30982@deprived.panopticon> <20090126144044.GB6054@hades.panopticon> <20090127164617.GA93440@hades.panopticon> <20090128042148.GA1256@hades.panopticon> <20090814021340.GA1275@hades.panopticon> Message-ID: Hello, Dmitry Marakasov writes: > * Dmitry Marakasov (amdmi3@amdmi3.ru) wrote: > >> 3. 512MB random bytes with NFS: 2/5 correct > > Just for the record: this no longer seems to be a problem. Recent > 8-STABLE, ale works fine with rxcsum/txcsum, at least I could not > reproduce the problem with similar tests as before. bon, I upgraded the box with this problem to *7*-STABLE this weekend, and no luck, the problem still persists. To refresh memory, nfs-client has data corrupt in a particular way : - just one byte (per file) in my case, a single 128 byte block for Dimitry - independent of network driver and NFS-[options|client versions] - seems nfs-limited (netcat file transfers work OK (zero-only nfs as well)) - disabling checksum offloading at least makes it much harder to provoke (cann't remembre whether everyone confirmed this) - disabling cpufreq makes it impossible to provoke (at least for me) So far the bad news, the better news is that I cannot reproduce this problem on a similar setup running *8*-STABLE indeed. The 7-STABLE box is in production, but involved in some maintenaince/upgrade-shuffle I am responsable for, I will try to let it at least boot a 8-kernel and 7-world sometime next week and see if I can still reproduce the problem. Best, Arno From vinnix.bsd at gmail.com Sun Oct 4 16:26:15 2009 From: vinnix.bsd at gmail.com (Vinicius Abrahao) Date: Sun Oct 4 16:26:28 2009 Subject: CFH: fix multimedia/pwcbsd with usb2 In-Reply-To: <1e31c7980910040814o48a1a57bgde86571fa3265c4c@mail.gmail.com> References: <20090908201713.GD41185@e.0x20.net> <1e31c7980909130516g1b3cb9fn5df77c23ec072413@mail.gmail.com> <200909131508.05025.hselasky@c2i.net> <1e31c7980910040814o48a1a57bgde86571fa3265c4c@mail.gmail.com> Message-ID: <1e31c7980910040926s35b01c5dn3e31d6b1509d1c76@mail.gmail.com> Trying multimedia/pwcbwd-1.4.1_6 I added a line at multimedia/pwcbsd/work/pwcbsd/pwc.c # diff pwc.c /root/pwc.c --normal 94a95 > {USB_VPI(0x093a, 0x2603, 720)}, /* Philips SPC500NC */ But the problem now is that pwcview don't recognize and "operation" mode for this camera. I try setting 720, but I'll try with others. # /usr/local/bin/pwcview Failed to access webcam: Not a directory *********************************************************** Make sure you have connected your webcam to the root hub or to a USB 1.1 hub, also check your dmesg for any errors. *********************************************************** At /var/log/messages: vinnix kernel: pwc0: Failed to set video mode to SIF@10 fps; return code = 20 vinnix kernel: pwc0: Failed to set video mode to QSIF@10 fps; return code = 20 Thanks, Vin?cius On 10/4/09, Vinicius Abrahao wrote: > Hi Hans, > > Thanks for your help! I try to do exactly what you say, but without > success. > When I attach my camera I see at dmesg: > ugen2.3: at usbus2 > > Trying pwcview: > > #./pwcview -d /dev/ugen2.3 > Failed to access webcam: Operation not supported by device > *********************************************************** > Make sure you have connected your webcam to the root hub > or to a USB 1.1 hub, also check your dmesg for any errors. > *********************************************************** > > > What I'm doing wrong? > > Thanks again, > Best regards, > Vin?cius > > On 9/13/09, Hans Petter Selasky wrote: >> On Sunday 13 September 2009 14:16:10 Vinicius Abrahao wrote: >>> Thanks Florent, >>> >>> That's it for sure. I recompile my kernel yesterday and now pwcbsd is >>> loading normally. >>> Therefore, now I see that pwc is the wrong driver for me. My webcam is >>> a Philips SPC500NC. >>> ID 093a:2603 Pixart Imaging, Inc. >>> >>> At Google I found that linux-gspca-kmod is the right driver for me. >>> But this seen broken as >>> pwcbsd was in the past. >> >> Hi, >> >> The closes you will currently get is: >> >> svn --username anonsvn --password anonsvn \ >> checkout svn://svn.turbocat.net/i4b/trunk/usbcam/ulinux >> >> As root: >> >> make fetch >> make patch >> make >> >> You manually have to patch: >> >> ee libv4l/v4l2-apps/libv4l/libv4lconvert/control/libv4lcontrol.c >> >> control/libv4lcontrol.c: In function 'v4lcontrol_vidioc_queryctrl': >> control/libv4lcontrol.c:586: error: '__u32' undeclared (first use in this >> function) >> control/libv4lcontrol.c:586: error: (Each undeclared identifier is >> reported >> only once >> control/libv4lcontrol.c:586: error: for each function it appears in.) >> control/libv4lcontrol.c:586: error: expected ';' before 'orig_id' >> control/libv4lcontrol.c:600: error: 'orig_id' undeclared (first use in >> this >> function) >> >> __u32 to uint32_t >> >> In the end: >> >> cd pwcview >> >> ./pwcview >> >> >> Should bring your webcam right up in userland though. >> >> --HPS >> >> > From uqs at spoerlein.net Sun Oct 4 16:52:20 2009 From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=) Date: Sun Oct 4 16:52:27 2009 Subject: Update to OpenSSH 5.3p1 broke pam_ssh.so ? Message-ID: <20091004165217.GS69612@acme.spoerlein.net> Hi Dag-Erling, is it possible, that the recent update causes my -CURRENT box to no longer allow for pam_ssh.so references in /etc/pam.d/{login,sshd}? I usually use auth sufficient pam_ssh.so no_warn try_first_pass session optional pam_ssh.so want_agent which results in the login aborting/breaking with strange pam_ssh errors. Could someone try this, not sure if I messed something up at my end, though the config has not changed in years. Regards, Uli From faber at isi.edu Sun Oct 4 17:20:08 2009 From: faber at isi.edu (Ted Faber) Date: Sun Oct 4 17:20:14 2009 Subject: FreeBSD8-RELENG (sources from this morning) deadlock In-Reply-To: <20091004133702.L14313@ury.york.ac.uk> References: <20090929041407.GA92280@zod.isi.edu> <20091002213116.GH88191@zod.isi.edu> <20091003142303.L14313@ury.york.ac.uk> <20091004014720.GA23086@zod.isi.edu> <20091004133702.L14313@ury.york.ac.uk> Message-ID: <20091004172006.GA28914@zod.isi.edu> On Sun, Oct 04, 2009 at 01:41:26PM +0100, Gavin Atkinson wrote: > On Sat, 3 Oct 2009, Ted Faber wrote: > > >On Sat, Oct 03, 2009 at 02:24:11PM +0100, Gavin Atkinson wrote: > >>Do you have options GDB/DDB/KDB in your kernel? > > > >On the target but not the debugging host. Do both need it? > > No, just the target should be fine. > > Last time I needed to do anything like this, I just followed the > instructions at http://wiki.freebsd.org/DebugWithDcons and it worked fine. > I'm guessing that's the article you also followed? That and the examples in the dcons/dconschat man pages, yeah. > > Sorry I can't help more! Thanks for looking at it. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091004/58b4ba87/attachment.pgp From hselasky at c2i.net Sun Oct 4 18:10:06 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Oct 4 18:10:13 2009 Subject: CFH: fix multimedia/pwcbsd with usb2 In-Reply-To: <1e31c7980910040814o48a1a57bgde86571fa3265c4c@mail.gmail.com> References: <20090908201713.GD41185@e.0x20.net> <200909131508.05025.hselasky@c2i.net> <1e31c7980910040814o48a1a57bgde86571fa3265c4c@mail.gmail.com> Message-ID: <200910042010.49054.hselasky@c2i.net> On Sunday 04 October 2009 17:14:04 Vinicius Abrahao wrote: > ./pwcview Try to run without -d /dev/ugenX.Y. Which pwcview did you build? The one from ports or I4B SVN? --HPS From amdmi3 at amdmi3.ru Sun Oct 4 19:03:51 2009 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Sun Oct 4 19:04:12 2009 Subject: Data corruption with checksum offloading enabled In-Reply-To: References: <20090123221826.GB30982@deprived.panopticon> <20090126144044.GB6054@hades.panopticon> <20090127164617.GA93440@hades.panopticon> <20090128042148.GA1256@hades.panopticon> <20090814021340.GA1275@hades.panopticon> Message-ID: <20091004190347.GC64567@hades.panopticon> * Arno J. Klaassen (arno@heho.snv.jussieu.fr) wrote: I had no problems since my previous message, however I've just noticed that rxcsum is disabled by default on 8.x. So this should really be tested after explicitely enabling it with ifconfig +rxcsum. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From bsam at ipt.ru Sun Oct 4 19:05:31 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Sun Oct 4 19:05:38 2009 Subject: 8.0RC1: Can't mount usb stick In-Reply-To: (Goran Gajic's message of "Sat, 3 Oct 2009 19:01:35 +0200 (CEST)") References: <54980020@bb.ipt.ru> Message-ID: <12071447@h30.sp.ipt.ru> (reformatted, please don't top-post) On Sat, 3 Oct 2009 19:01:35 +0200 (CEST) Goran Gajic wrote: > On Fri, 2 Oct 2009, Boris Samorodov wrote: > > On Fri, 2 Oct 2009 10:25:16 +0200 (CEST) Goran Gajic wrote: > > > >> da0 at umass-sim0 bus 0 target 0 lun 0 > >> da0: < USB FLASH DRIVE PMAP> Removable Direct Access SCSI-0 device > >> da0: 40.000MB/s transfers > >> da0: 1968MB (4030464 512 byte sectors: 255H 63S/T 250C) > > > >> # mount -t msdosfs /dev/da0 /mnt > >> mount_msdosfs: /dev/da0: Invalid argument > > > > Take a look at /dev/da0*. MS DOS usually uses partition s1, > > so your command should be: > > ----- > > # mount -t msdosfs /dev/da0s1 /mnt > > ----- > > > No this one is formated in XP style, so there is no /dev/da0s1. But Sorry, I'm unaware of this disk styles. Google seems to not be very helpful. Can you post an URL? > that is not the only problem I have noticed. I wanted to take image > of USB stick just in case I might need it, since I did newfs_msdos > /dev/da0.. However Hm, what was the actual command? I'm not sure if one can newfs a disk but not slice. I would say that at least /dev/ad0a is needed. > during cat /dev/da0 > usb.img read seems to hang.. Also, when I have tried > to put some image (in FreeBSD 8.0RC1) on that same stick, when I did > cat usb_old.img > /dev/da0 same happens - system hangs. When I have > tried same thing under Linux it worked with no problems. Don't know if cat should work but dd should. Can you try one? -- WBR, bsam From arno at heho.snv.jussieu.fr Sun Oct 4 21:39:30 2009 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Sun Oct 4 21:39:37 2009 Subject: Data corruption with checksum offloading enabled In-Reply-To: <20091004190347.GC64567@hades.panopticon> (Dmitry Marakasov's message of "Sun\, 4 Oct 2009 23\:03\:47 +0400") References: <20090123221826.GB30982@deprived.panopticon> <20090126144044.GB6054@hades.panopticon> <20090127164617.GA93440@hades.panopticon> <20090128042148.GA1256@hades.panopticon> <20090814021340.GA1275@hades.panopticon> <20091004190347.GC64567@hades.panopticon> Message-ID: Hello, Dmitry Marakasov writes: > * Arno J. Klaassen (arno@heho.snv.jussieu.fr) wrote: > > I had no problems since my previous message, however I've just noticed > that rxcsum is disabled by default on 8.x. So this should really be > tested after explicitely enabling it with ifconfig +rxcsum. it is on on my 8-box : [root@siamesetwins ~]# uname -a FreeBSD siamesetwins 8.0-RC1 FreeBSD 8.0-RC1 #0: Sat Oct 3 19:22:51 CEST 2009 toor@siamesetwins:/zfiles/obj/raid1/bsd/8/src/sys/S3992-E amd64 [root@siamesetwins ~]# ifconfig bge0 bge0: flags=8843 metric 0 mtu 1500 options=9b That said, I will test with explicit enabling and disabling ?xcsum on my troublesome box (which is a lab-fileserver, I doubt a bit the performance penalty (though most clients are 100Mbps linux)) Best, Arno From michio.jinbo at gmail.com Sun Oct 4 22:45:58 2009 From: michio.jinbo at gmail.com (Michio "Karl" Jinbo) Date: Sun Oct 4 22:46:05 2009 Subject: pmap_invalidate_cache_range() panic on Xen Server In-Reply-To: <200910041220.n94CKxTH073639@svn.freebsd.org> References: <200910041220.n94CKxTH073639@svn.freebsd.org> Message-ID: <20091005072515.3622.22FF24F1@gmail.com> On Sun, 4 Oct 2009 12:20:59 +0000 (UTC) Konstantin Belousov wrote: > Log: > MFC r197663: > As a workaround, for Intel CPUs, do not use CLFLUSH in > pmap_invalidate_cache_range() when self-snoop is apparently not reported > in cpu features. > > Approved by: re (bz, kensmith) I was tested r197663/r197744, but kernel panic again on Citrix Xen Server. using 8.0-RC1 install cd, results are 1. INTEL SU9400+HYPER-V(Windows2008 R2) -> boot OK. 2. AMD Athlon X2 TK-55+HYPER-V(Windows2008 R2) -> boot NG. 3. AMD PhenomII 940BK+Citrix Xen Server -> boot NG. I think INTEL CPUs are no problem, but AMD CPUs appear the problem. So I tested the following patch, kernel boot was successed on recent 9-CURRENT and environment 3. sorry, poor English. --- sys/i386/i386/initcpu.c.original 2009-10-01 21:52:48.000000000 +0900 +++ sys/i386/i386/initcpu.c 2009-10-05 08:29:45.000000000 +0900 @@ -721,7 +721,7 @@ * XXXKIB: (temporary) hack to work around traps generated when * CLFLUSHing APIC registers window. */ - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS)) + if (cpu_vendor_id == CPU_VENDOR_AMD && !(cpu_feature & CPUID_SS)) cpu_feature &= ~CPUID_CLFSH; #if defined(PC98) && !defined(CPU_UPGRADE_HW_CACHE) -- Michio Jinbo From john.marshall at riverwillow.com.au Sun Oct 4 23:07:38 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Sun Oct 4 23:07:45 2009 Subject: 8.0 Dynamic Linker Broken? (Was: [PATCH] SASL problems with spnego on 8.0-BETA4) In-Reply-To: <200910020824.15488.john@baldwin.cx> References: <4AB27FB6.4010806@eng.auth.gr> <20090921222241.GF1001@rwpc12.mby.riverwillow.net.au> <20091002081319.GN37304@rwpc12.mby.riverwillow.net.au> <200910020824.15488.john@baldwin.cx> Message-ID: <20091004230720.GA1086@rwpc12.mby.riverwillow.net.au> On Fri, 02 Oct 2009, 08:24 -0400, John Baldwin wrote: > On Friday 02 October 2009 4:13:19 am John Marshall wrote: > > On Tue, 22 Sep 2009, 08:22 +1000, John Marshall wrote: > > > On Mon, 21 Sep 2009, 11:26 -0400, Rick Macklem wrote: > > > [snip] > > > > > > > > Now, hopefully someone who understands enough about dynamic linking will > > > > know if this is the correct fix for 8.0? (I'm going on a couple of weeks > > > > vacation at the end of this week, so I won't be around to commit > > > > anything > > > > and don't understand it well enough to know if this is the correct way > > > > to fix it.) > > > > > > > > So, hopefully someone else can pick this one up? > > > > [snip] > > > > > > I have submitted a patch to the FreeBSD Makefile which patches the > > > vendor-supplied template for krb5-config. I should be grateful if dfr@ > > > or another src committer would please review this with a view to > > > obtaining re@ approval to commit it before 8.0-RC2. > > > > > > > > > > Any src committers able to help with this? > > Hmmm, I thought that libgssapi was supposed to use dlopen to load the proper > back-end libraries using /etc/gss/mech rather than having applications > directly link against them. OK, so if my proposed solution is, in fact, only masking a symptom of a broken dynamic linker, would somebody who understands this stuff please weigh in on this with some debugging suggestions or with a patch to address this problem? I'm able to help with testing but I'm not a programmer and know nothing about the FreeBSD dynamic linker. Thanks. -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091004/75f83940/attachment.pgp From arno at heho.snv.jussieu.fr Sun Oct 4 23:35:20 2009 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Sun Oct 4 23:35:26 2009 Subject: Data corruption with checksum offloading enabled In-Reply-To: <20091004190347.GC64567@hades.panopticon> (Dmitry Marakasov's message of "Sun\, 4 Oct 2009 23\:03\:47 +0400") References: <20090123221826.GB30982@deprived.panopticon> <20090126144044.GB6054@hades.panopticon> <20090127164617.GA93440@hades.panopticon> <20090128042148.GA1256@hades.panopticon> <20090814021340.GA1275@hades.panopticon> <20091004190347.GC64567@hades.panopticon> Message-ID: Dmitry Marakasov writes: > * Arno J. Klaassen (arno@heho.snv.jussieu.fr) wrote: > > I had no problems since my previous message, however I've just noticed > that rxcsum is disabled by default on 8.x. So this should really be > tested after explicitely enabling it with ifconfig +rxcsum. if ever this helps, I just came accross these messages on a (7-stable) nfs-client against my 8-stable server which passes the test : Oct 3 17:25:05 push kernel: nfs_getpages: error 1433597680 Oct 3 17:25:05 push kernel: vm_fault: pager read error, pid 26821 (cmp) Oct 3 17:28:25 push kernel: nfs_getpages: error 1435664464 Oct 3 17:28:25 push kernel: vm_fault: pager read error, pid 27017 (cp) IMHO looks like some rare nfs-miss-communication which passes silently against a 7-nfssrver but gets noticed (and corrected ..) against a 8-nfsserver /disclaimer it is late (here) and I need sleep Arno From hrs at FreeBSD.org Mon Oct 5 03:54:21 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Mon Oct 5 03:54:28 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration (was: Re: svn commit: r197145 - in head: etc/defaults share/man/man5) In-Reply-To: <20090920.224018.16368211.hrs@allbsd.org> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> Message-ID: <20091005.123427.227628092.hrs@allbsd.org> Hi, I would like your comments about merging the network_ipv6 -> netif integration to stable/8. The issue of this rc.d script change is it involves user-visible changes in rc.conf(5) variables as described in UPDATING. I still want to do so before 8.0-R because the ND6 change in -CURRENT needs updating IPv6-related rc.d scripts first. While the ND6 change is not harmful from viewpoint of compatibility because basically it just converts a global knob to a per-interface flag, handling it in the rc.d scripts needs a kind of overhaul of rc.d/network_ipv6 and rc.d/netif. The necessary changes have already been committed into -CURRENT. It displays a warning to inform the users what is old in the rc.conf if the user uses rc.d variables that have been changed, and at the same time it keeps backward compatibility so that the old variables also work. So, I think the impact is small enough, and this sort of visible changes should be included in the .0 release rather than in the middle of future 8.x releases. The patch for stable/8 can be found at: http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff This includes both of the ND6 kernel change and the rc.d script change. If there is an objection from someone here I will put off the merge until after 8.0-R. -- Hiroki -------------- 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-current/attachments/20091005/a6a15177/attachment.pgp From bland at FreeBSD.org Mon Oct 5 05:08:24 2009 From: bland at FreeBSD.org (Alexander Nedotsukov) Date: Mon Oct 5 05:08:31 2009 Subject: 8.0 Dynamic Linker Broken? (Was: [PATCH] SASL problems with spnego on 8.0-BETA4) Message-ID: <54ee35ff63fa25ea4c082134892835fb@mail> Actually this may mean quite otherwise. What I saying is if some code (eg. libsasl) dlopen() libgssapi as RTLD_LOCAL then later attempt to load libgssapi_xxx inside libgssapi may fail because of this: $ldd /usr/lib/libgssapi_spnego.so /usr/lib/libgssapi_spnego.so: libasn1.so.10 => /usr/lib/libasn1.so.10 (0x28300000) libc.so.7 => /lib/libc.so.7 (0x2808f000) I would expect to see libgssapi.so.10 dependency here. On Mon, 5 Oct 2009 10:07:20 +1100, John Marshall wrote: > On Fri, 02 Oct 2009, 08:24 -0400, John Baldwin wrote: >> On Friday 02 October 2009 4:13:19 am John Marshall wrote: >> > On Tue, 22 Sep 2009, 08:22 +1000, John Marshall wrote: >> > > On Mon, 21 Sep 2009, 11:26 -0400, Rick Macklem wrote: >> > > > [snip] >> > > > >> > > > Now, hopefully someone who understands enough about dynamic >> > > > linking will >> > > > know if this is the correct fix for 8.0? (I'm going on a couple of >> > > > weeks >> > > > vacation at the end of this week, so I won't be around to commit >> > > > anything >> > > > and don't understand it well enough to know if this is the correct >> > > > way >> > > > to fix it.) >> > > > >> > > > So, hopefully someone else can pick this one up? >> > > > > [snip] >> > > >> > > I have submitted a patch to the FreeBSD Makefile which patches the >> > > vendor-supplied template for krb5-config. I should be grateful if >> > > dfr@ >> > > or another src committer would please review this with a view to >> > > obtaining re@ approval to commit it before 8.0-RC2. >> > > >> > > >> > >> > Any src committers able to help with this? >> >> Hmmm, I thought that libgssapi was supposed to use dlopen to load the >> proper >> back-end libraries using /etc/gss/mech rather than having applications >> directly link against them. > > OK, so if my proposed solution is, in fact, only masking a symptom of a > broken dynamic linker, would somebody who understands this stuff please > weigh in on this with some debugging suggestions or with a patch to > address this problem? > > I'm able to help with testing but I'm not a programmer and know nothing > about the FreeBSD dynamic linker. > > Thanks. From jhay at meraka.org.za Mon Oct 5 05:58:09 2009 From: jhay at meraka.org.za (John Hay) Date: Mon Oct 5 05:58:21 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration (was: Re: svn commit: r197145 - in head: etc/defaults share/man/man5) In-Reply-To: <20091005.123427.227628092.hrs@allbsd.org> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> Message-ID: <20091005055806.GB58246@zibbi.meraka.csir.co.za> On Mon, Oct 05, 2009 at 12:34:27PM +0900, Hiroki Sato wrote: > Hi, > > I would like your comments about merging the network_ipv6 -> netif > integration to stable/8. The issue of this rc.d script change is it > involves user-visible changes in rc.conf(5) variables as described in > UPDATING. > > I still want to do so before 8.0-R because the ND6 change in -CURRENT > needs updating IPv6-related rc.d scripts first. While the ND6 change > is not harmful from viewpoint of compatibility because basically it > just converts a global knob to a per-interface flag, handling it in > the rc.d scripts needs a kind of overhaul of rc.d/network_ipv6 and > rc.d/netif. > > The necessary changes have already been committed into -CURRENT. It > displays a warning to inform the users what is old in the rc.conf if > the user uses rc.d variables that have been changed, and at the same > time it keeps backward compatibility so that the old variables also > work. So, I think the impact is small enough, and this sort of > visible changes should be included in the .0 release rather than in > the middle of future 8.x releases. > > The patch for stable/8 can be found at: > > http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff > > This includes both of the ND6 kernel change and the rc.d script > change. If there is an objection from someone here I will put off > the merge until after 8.0-R. Is there a good reason why we still ship with ipv6 off by default? Most others seem to ship with ipv6 on. At least Windows, most linux flavours and Mac OS X which make out the rest of the machines on our network here at Meraka Institute. One thing that I have against the way the stuff in -current is done at the moment, is that it seems to be a lot more work to just get ipv6 to work. Either I did things wrong or we are taking a step backward. Make no mistake, I like the idea of being able to control it per interface, but it seems that you have to enable it per interface with a long string for each... I would rather that it is enabled everywhere by default and then you disbale it where you do not want it. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From dfr at rabson.org Mon Oct 5 07:30:10 2009 From: dfr at rabson.org (Doug Rabson) Date: Mon Oct 5 07:30:19 2009 Subject: 8.0 Dynamic Linker Broken? (Was: [PATCH] SASL problems with spnego on 8.0-BETA4) In-Reply-To: <54ee35ff63fa25ea4c082134892835fb@mail> References: <54ee35ff63fa25ea4c082134892835fb@mail> Message-ID: <0EA2E119-29DF-4DDE-84C3-432E35D61C76@rabson.org> This is the core of the problem, I think. There are two possible solutions: 1. Link libgssapi_foo.so against libgssapi.so. I'm not a fan of this because it will encourage people to link with libgssapi_krb5.so when they really ought to be linking with libgssapi.so to give them mechanism independance. 2. Split the various mechanism libs in to two parts, mech_foo.so which will contain the actual mechanism implementation (this can link with libgssapi.so to handle the RTLD_LOCAL issue) and optionally libgssapi_foo.so to contain any mechanism-specific extensions. Clearly (2) is unsuitable for 8.0 but could happen in current. I guess we could use (1) as a band-aid fix for 8.0. On 5 Oct 2009, at 05:50, Alexander Nedotsukov wrote: > > Actually this may mean quite otherwise. > What I saying is if some code (eg. libsasl) dlopen() libgssapi as > RTLD_LOCAL then later attempt to load libgssapi_xxx inside libgssapi > may > fail because of this: > > $ldd /usr/lib/libgssapi_spnego.so > /usr/lib/libgssapi_spnego.so: > libasn1.so.10 => /usr/lib/libasn1.so.10 (0x28300000) > libc.so.7 => /lib/libc.so.7 (0x2808f000) > > I would expect to see libgssapi.so.10 dependency here. > > On Mon, 5 Oct 2009 10:07:20 +1100, John Marshall > wrote: >> On Fri, 02 Oct 2009, 08:24 -0400, John Baldwin wrote: >>> On Friday 02 October 2009 4:13:19 am John Marshall wrote: >>>> On Tue, 22 Sep 2009, 08:22 +1000, John Marshall wrote: >>>>> On Mon, 21 Sep 2009, 11:26 -0400, Rick Macklem wrote: >>>>> >> [snip] >>>>>> >>>>>> Now, hopefully someone who understands enough about dynamic >>>>>> linking will >>>>>> know if this is the correct fix for 8.0? (I'm going on a couple > of >>>>>> weeks >>>>>> vacation at the end of this week, so I won't be around to commit >>>>>> anything >>>>>> and don't understand it well enough to know if this is the > correct >>>>>> way >>>>>> to fix it.) >>>>>> >>>>>> So, hopefully someone else can pick this one up? >>>>>> >> [snip] >>>>> >>>>> I have submitted a patch to the FreeBSD Makefile which patches the >>>>> vendor-supplied template for krb5-config. I should be grateful if >>>>> dfr@ >>>>> or another src committer would please review this with a view to >>>>> obtaining re@ approval to commit it before 8.0-RC2. >>>>> >>>>> >>>> >>>> Any src committers able to help with this? >>> >>> Hmmm, I thought that libgssapi was supposed to use dlopen to load >>> the >>> proper >>> back-end libraries using /etc/gss/mech rather than having >>> applications >>> directly link against them. >> >> OK, so if my proposed solution is, in fact, only masking a symptom >> of a >> broken dynamic linker, would somebody who understands this stuff >> please >> weigh in on this with some debugging suggestions or with a patch to >> address this problem? >> >> I'm able to help with testing but I'm not a programmer and know >> nothing >> about the FreeBSD dynamic linker. >> >> Thanks. From vinnix.bsd at gmail.com Mon Oct 5 09:21:52 2009 From: vinnix.bsd at gmail.com (Vinicius Abrahao) Date: Mon Oct 5 09:22:08 2009 Subject: CFH: fix multimedia/pwcbsd with usb2 In-Reply-To: <200910042010.49054.hselasky@c2i.net> References: <20090908201713.GD41185@e.0x20.net> <200909131508.05025.hselasky@c2i.net> <1e31c7980910040814o48a1a57bgde86571fa3265c4c@mail.gmail.com> <200910042010.49054.hselasky@c2i.net> Message-ID: <1e31c7980910050221u11b93be9ye390bad8b6857c0b@mail.gmail.com> Hi Hans, With the pwcview from I4B SVN: Did not recognize my device at all, with or without -d option. With pwcbsd from ports: The pwc.ko only recognize my cam If I apply this patch in pwc.c: 94a95 > {USB_VPI(0x093a, 0x2603, 675)}, /* Philips SPC500NC */ Note that 675 (type field) is just my guess. I try some others without success. But only appears a green or black screen. Research more about this cam I found that it uses a sensor: PAC7311 [1]. Cause this problems I'm wondering buy a new camera (better quality) and default support by pwc.ko. For the other side, put this camera to work, seens a cool opportunity to learn more about drivers at FreeBSD environment. [1] http://www.pixart.com.tw/upload/PAC7311%20Spec%20V15_20051122092509.pdf Thanks for your help, Vinnix On 10/4/09, Hans Petter Selasky wrote: > On Sunday 04 October 2009 17:14:04 Vinicius Abrahao wrote: >> ./pwcview > > Try to run without -d /dev/ugenX.Y. > > Which pwcview did you build? The one from ports or I4B SVN? > > --HPS > > From des at des.no Mon Oct 5 09:22:15 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Oct 5 09:22:24 2009 Subject: Update to OpenSSH 5.3p1 broke pam_ssh.so ? In-Reply-To: <20091004165217.GS69612@acme.spoerlein.net> ("Ulrich =?utf-8?Q?Sp=C3=B6rlein=22's?= message of "Sun, 4 Oct 2009 18:52:18 +0200") References: <20091004165217.GS69612@acme.spoerlein.net> Message-ID: <86my46xkje.fsf@ds4.des.no> Ulrich Sp?rlein writes: > is it possible, that the recent update causes my -CURRENT box to no > longer allow for pam_ssh.so references in /etc/pam.d/{login,sshd}? Weird, can you send me the error messages? DES -- Dag-Erling Sm?rgrav - des@des.no From hrs at FreeBSD.org Mon Oct 5 09:24:33 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Mon Oct 5 09:24:45 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <20091005055806.GB58246@zibbi.meraka.csir.co.za> References: <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <20091005055806.GB58246@zibbi.meraka.csir.co.za> Message-ID: <20091005.182342.167950100.hrs@allbsd.org> John Hay wrote in <20091005055806.GB58246@zibbi.meraka.csir.co.za>: jh> Is there a good reason why we still ship with ipv6 off by default? Most jh> others seem to ship with ipv6 on. At least Windows, most linux flavours jh> and Mac OS X which make out the rest of the machines on our network here jh> at Meraka Institute. What do you mean by "off by default"? I think IPv6 is not disabled by default with the patch. Re-enabling of "automatic assignment of a link-local address by default" has been a big step for IPv6 ready out of the box. jh> One thing that I have against the way the stuff in -current is done at jh> the moment, is that it seems to be a lot more work to just get ipv6 to jh> work. Either I did things wrong or we are taking a step backward. Make jh> no mistake, I like the idea of being able to control it per interface, jh> but it seems that you have to enable it per interface with a long string jh> for each... I would rather that it is enabled everywhere by default and jh> then you disbale it where you do not want it. The initial patch had several regressions to mistakenly disable the functionality, but the current one should work by just adding an $ifconfig_IF_ipv6 line to rc.conf. The intention of my patch is to set $ipv6_enable=YES automatically (in more modular manner) when an IPv6 configuration is specified for an interface. Even with no per-interface configuration, when $ipv6_prefer=YES, IPv6 communication by using link-local addresses works. I believe it does not make it so complex compared with the old $ipv6_enable=YES model. I feel there is some difference between my understanding of "enable by default" and yours. Do you elaborate the word "enable" a bit more, please? -- Hiroki -------------- 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-current/attachments/20091005/7186ff99/attachment.pgp From bzeeb-lists at lists.zabbadoz.net Mon Oct 5 09:30:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Oct 5 09:30:15 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration (was: Re: svn commit: r197145 - in head: etc/defaults share/man/man5) In-Reply-To: <20091005055806.GB58246@zibbi.meraka.csir.co.za> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <20091005055806.GB58246@zibbi.meraka.csir.co.za> Message-ID: <20091005091708.J26486@maildrop.int.zabbadoz.net> On Mon, 5 Oct 2009, John Hay wrote: Hi, > On Mon, Oct 05, 2009 at 12:34:27PM +0900, Hiroki Sato wrote: >> Hi, >> >> I would like your comments about merging the network_ipv6 -> netif >> integration to stable/8. The issue of this rc.d script change is it >> involves user-visible changes in rc.conf(5) variables as described in >> UPDATING. >> >> I still want to do so before 8.0-R because the ND6 change in -CURRENT >> needs updating IPv6-related rc.d scripts first. While the ND6 change >> is not harmful from viewpoint of compatibility because basically it >> just converts a global knob to a per-interface flag, handling it in >> the rc.d scripts needs a kind of overhaul of rc.d/network_ipv6 and >> rc.d/netif. >> >> The necessary changes have already been committed into -CURRENT. It >> displays a warning to inform the users what is old in the rc.conf if >> the user uses rc.d variables that have been changed, and at the same >> time it keeps backward compatibility so that the old variables also >> work. So, I think the impact is small enough, and this sort of >> visible changes should be included in the .0 release rather than in >> the middle of future 8.x releases. >> >> The patch for stable/8 can be found at: >> >> http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff >> >> This includes both of the ND6 kernel change and the rc.d script >> change. If there is an objection from someone here I will put off >> the merge until after 8.0-R. > > Is there a good reason why we still ship with ipv6 off by default? Most > others seem to ship with ipv6 on. At least Windows, most linux flavours > and Mac OS X which make out the rest of the machines on our network here > at Meraka Institute. > > One thing that I have against the way the stuff in -current is done at > the moment, is that it seems to be a lot more work to just get ipv6 to > work. Either I did things wrong or we are taking a step backward. Make > no mistake, I like the idea of being able to control it per interface, > but it seems that you have to enable it per interface with a long string > for each... I would rather that it is enabled everywhere by default and > then you disbale it where you do not want it. link-local had been enabled by default in the past and I am not sure if we had a SA or EN for that or that it was just preemptively disabled. The problem is that if it is enabled by default you are exposing yourself to others on the same network. That is of course especially bad if you are in untrusted environments like conferences, ... or on a public LAN. If we'd support IPv4 link-local addresses by default we would have to apply the same logic there. I am not sure about OSX but at least Windows has a firewall set to deny any unrelated incoming things by default these days. Just because others haven't yet (really) thought about the problems doesn't mean they aren't there. If you want to use IPv4 you either add an address or start DHCP or .. and you have to configure that. If you want IPv6, you configure that as well. You shall not have anything enbaled by default that people can use to attack you and you don't know about because you didn't configure. While (we) IPv6 people know that it would be there a lot of people are still totally unaware of IPv6 and they would be surprised. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From des at des.no Mon Oct 5 11:05:07 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Oct 5 11:05:14 2009 Subject: pam_ssh no longer works after r197679 In-Reply-To: <20091004225000.6a1a6262.taku@tackymt.homeip.net> (Taku YAMAMOTO's message of "Sun, 4 Oct 2009 22:50:00 +0900") References: <20091004225000.6a1a6262.taku@tackymt.homeip.net> Message-ID: <86fx9yxfrz.fsf@ds4.des.no> Taku YAMAMOTO writes: > A quick investigation revailed that libssh.so.5 had some symbols undefined, > which prevented pam_ssh.so.5 from being loaded. > # FYI: openpam dlopen()s modules with RTLD_NOW. > > Here's interesting bits from nm -D /usr/lib/libssh.so.5 | fgrep U > U roaming_read > U roaming_write This is weird - I understand what the problem is, but I don't understand why it didn't break the build. As a workaround, try adding roaming_dummy.c to SRCS in pam_ssh's Makefile. DES -- Dag-Erling Sm?rgrav - des@des.no From bland at freebsd.org Mon Oct 5 11:07:27 2009 From: bland at freebsd.org (Alexander Nedotsukov) Date: Mon Oct 5 11:10:24 2009 Subject: 8.0 Dynamic Linker Broken? (Was: [PATCH] SASL problems with spnego on 8.0-BETA4) In-Reply-To: <0EA2E119-29DF-4DDE-84C3-432E35D61C76@rabson.org> References: <54ee35ff63fa25ea4c082134892835fb@mail> <0EA2E119-29DF-4DDE-84C3-432E35D61C76@rabson.org> Message-ID: Doug, I share your concerns about wrong libgssapi_foo usage. Do you see any possible drawbacks of: 3) Move libgssapi_foo into gssapi/libfoo_mech and link libgoo_mech against libgssapi Thanks, Alexander On 05.10.2009, at 16:29, Doug Rabson wrote: > This is the core of the problem, I think. There are two possible > solutions: > > 1. Link libgssapi_foo.so against libgssapi.so. I'm not a fan of this > because it will encourage people to link with libgssapi_krb5.so when > they really ought to be linking with libgssapi.so to give them > mechanism independance. > > 2. Split the various mechanism libs in to two parts, mech_foo.so > which will contain the actual mechanism implementation (this can > link with libgssapi.so to handle the RTLD_LOCAL issue) and > optionally libgssapi_foo.so to contain any mechanism-specific > extensions. > > Clearly (2) is unsuitable for 8.0 but could happen in current. I > guess we could use (1) as a band-aid fix for 8.0. > > On 5 Oct 2009, at 05:50, Alexander Nedotsukov wrote: > >> >> Actually this may mean quite otherwise. >> What I saying is if some code (eg. libsasl) dlopen() libgssapi as >> RTLD_LOCAL then later attempt to load libgssapi_xxx inside >> libgssapi may >> fail because of this: >> >> $ldd /usr/lib/libgssapi_spnego.so >> /usr/lib/libgssapi_spnego.so: >> libasn1.so.10 => /usr/lib/libasn1.so.10 (0x28300000) >> libc.so.7 => /lib/libc.so.7 (0x2808f000) >> >> I would expect to see libgssapi.so.10 dependency here. >> >> On Mon, 5 Oct 2009 10:07:20 +1100, John Marshall >> wrote: >>> On Fri, 02 Oct 2009, 08:24 -0400, John Baldwin wrote: >>>> On Friday 02 October 2009 4:13:19 am John Marshall wrote: >>>>> On Tue, 22 Sep 2009, 08:22 +1000, John Marshall wrote: >>>>>> On Mon, 21 Sep 2009, 11:26 -0400, Rick Macklem wrote: >>>>>> >>> [snip] >>>>>>> >>>>>>> Now, hopefully someone who understands enough about dynamic >>>>>>> linking will >>>>>>> know if this is the correct fix for 8.0? (I'm going on a couple >> of >>>>>>> weeks >>>>>>> vacation at the end of this week, so I won't be around to commit >>>>>>> anything >>>>>>> and don't understand it well enough to know if this is the >> correct >>>>>>> way >>>>>>> to fix it.) >>>>>>> >>>>>>> So, hopefully someone else can pick this one up? >>>>>>> >>> [snip] >>>>>> >>>>>> I have submitted a patch to the FreeBSD Makefile which patches >>>>>> the >>>>>> vendor-supplied template for krb5-config. I should be grateful >>>>>> if >>>>>> dfr@ >>>>>> or another src committer would please review this with a view to >>>>>> obtaining re@ approval to commit it before 8.0-RC2. >>>>>> >>>>>> >>>>> >>>>> Any src committers able to help with this? >>>> >>>> Hmmm, I thought that libgssapi was supposed to use dlopen to load >>>> the >>>> proper >>>> back-end libraries using /etc/gss/mech rather than having >>>> applications >>>> directly link against them. >>> >>> OK, so if my proposed solution is, in fact, only masking a symptom >>> of a >>> broken dynamic linker, would somebody who understands this stuff >>> please >>> weigh in on this with some debugging suggestions or with a patch to >>> address this problem? >>> >>> I'm able to help with testing but I'm not a programmer and know >>> nothing >>> about the FreeBSD dynamic linker. >>> >>> Thanks. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " From hselasky at c2i.net Mon Oct 5 11:17:25 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Oct 5 11:17:33 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: <200910032306.01529.hselasky@c2i.net> References: <20091002150931.K35591@pooker.samsco.org> <200910032306.01529.hselasky@c2i.net> Message-ID: <200910051318.11111.hselasky@c2i.net> On Saturday 03 October 2009 23:06:00 Hans Petter Selasky wrote: > On Saturday 03 October 2009 20:51:07 Marcel Moolenaar wrote: > > On Oct 3, 2009, at 9:00 AM, Hans Petter Selasky wrote: > > > > An approach like this also allows one to indefinitely wait for the root > > device, which is a good feature to have... > > Here is a patch you can try: > > http://perforce.freebsd.org/chv.cgi?CH=169183 > > NOTE: I was not able to get any characters from gets() nor cncheckc(), so > there seems to be a bug somewhere. This used to work before at mount-root > time. > Hi, I currently only see one problem. If any partitions that should be automounted by /etc/fstab are not on the root disk, then /etc/fstab will fail, because the current code will only wait for for the root mount partition. Probably the script executing /etc/fstab should be updated to wait for disks aswell. --HPS From michio.jinbo at gmail.com Mon Oct 5 11:39:24 2009 From: michio.jinbo at gmail.com (Michio "Karl" Jinbo) Date: Mon Oct 5 11:39:36 2009 Subject: svn commit: r197744 - in stable/8/sys: . amd64/amd64 amd64/include/xen cddl/contrib/opensolaris contrib/dev/acpica contrib/pf dev/xen/xenpci i386/i386 In-Reply-To: <200910041220.n94CKxTH073639@svn.freebsd.org> References: <200910041220.n94CKxTH073639@svn.freebsd.org> Message-ID: <20091005203920.1278.22FF24F1@gmail.com> On Sun, 4 Oct 2009 12:20:59 +0000 (UTC) Konstantin Belousov wrote: > Log: > MFC r197663: > As a workaround, for Intel CPUs, do not use CLFLUSH in > pmap_invalidate_cache_range() when self-snoop is apparently not reported > in cpu features. > > Approved by: re (bz, kensmith) I was tested r197663/r197744, but kernel panic again on Citrix Xen Server. using 8.0-RC1 install cd, results are 1. INTEL SU9400+HYPER-V(Windows2008 R2) -> boot OK. 2. AMD Athlon X2 TK-55+HYPER-V(Windows2008 R2) -> boot NG. 3. AMD PhenomII 940BK+Citrix Xen Server -> boot NG. I think INTEL CPUs are no problem, but AMD CPUs appear the problem. So I tested the following patch, kernel boot was successed on recent 9-CURRENT and environment 3. sorry, poor English. --- sys/i386/i386/initcpu.c.original 2009-10-01 21:52:48.000000000 +0900 +++ sys/i386/i386/initcpu.c 2009-10-05 08:29:45.000000000 +0900 @@ -721,7 +721,7 @@ * XXXKIB: (temporary) hack to work around traps generated when * CLFLUSHing APIC registers window. */ - if (cpu_vendor_id == CPU_VENDOR_INTEL && !(cpu_feature & CPUID_SS)) + if (cpu_vendor_id == CPU_VENDOR_AMD && !(cpu_feature & CPUID_SS)) cpu_feature &= ~CPUID_CLFSH; #if defined(PC98) && !defined(CPU_UPGRADE_HW_CACHE) -- Michio "Karl" Jinbo From minotaur at crete.org.ua Mon Oct 5 13:06:45 2009 From: minotaur at crete.org.ua (Alexander Shikoff) Date: Mon Oct 5 13:07:18 2009 Subject: 'ee' editor prints cyrillic characters on white background Message-ID: <20091004090156.GA85409@crete.org.ua> Hello, I've upgraded my 7.2-RELEASE to 8.0-RC1. ee editor began to highlight cyrillic characters (locale uk_UA.KOI8-U) with white background and underscoring. Does anyone know how to disable this? Thanks. -- MINO-RIPE From nyan at jp.FreeBSD.org Mon Oct 5 14:37:50 2009 From: nyan at jp.FreeBSD.org (Takahashi Yoshihiro) Date: Mon Oct 5 14:37:57 2009 Subject: de(4) does not work on 8.0-RC1 In-Reply-To: <20090924175312.GA5572@michelle.cdnetworks.com> References: <20090924112533.1377D83D2D@mail1.asahi-net.or.jp> <20090924.210712.162012268.nyan@jp.FreeBSD.org> <20090924175312.GA5572@michelle.cdnetworks.com> Message-ID: <20091005.233648.263895250.nyan@jp.FreeBSD.org> In article <20090924175312.GA5572@michelle.cdnetworks.com> Pyun YongHyeon writes: >> > Thanks for your reply. They works well again on 8.0-RC1 with your >> > patch. >> >> I also use a NIC supported by de(4). The patch works fine for it. > > Thanks for testing! Patch committed to HEAD(r197465). Do you have a plan to merge this patch into stable/8? I wish that the de(4) works in 8.0R. --- TAKAHASHI Yoshihiro From tom at tomjudge.com Mon Oct 5 14:40:46 2009 From: tom at tomjudge.com (Tom Judge) Date: Mon Oct 5 14:40:54 2009 Subject: Per Jail Memory Limits Message-ID: <4ACA0549.7030404@tomjudge.com> Hi, Does anyone know of a patch that will add per jail memory limits so that a jail can't swallow the resources of the entire box? Thanks Tom From john at baldwin.cx Mon Oct 5 13:54:29 2009 From: john at baldwin.cx (John Baldwin) Date: Mon Oct 5 15:22:00 2009 Subject: 8.0 Dynamic Linker Broken? (Was: [PATCH] SASL problems with spnego on 8.0-BETA4) In-Reply-To: <20091004230720.GA1086@rwpc12.mby.riverwillow.net.au> References: <4AB27FB6.4010806@eng.auth.gr> <20090921222241.GF1001@rwpc12.mby.riverwillow.net.au> <20091002081319.GN37304@rwpc12.mby.riverwillow.net.au> <200910020824.15488.john@baldwin.cx> <20091004230720.GA1086@rwpc12.mby.riverwillow.net.au> Message-ID: <4AC9FA92.70903@baldwin.cx> John Marshall wrote: > On Fri, 02 Oct 2009, 08:24 -0400, John Baldwin wrote: >> On Friday 02 October 2009 4:13:19 am John Marshall wrote: >>> On Tue, 22 Sep 2009, 08:22 +1000, John Marshall wrote: >>>> On Mon, 21 Sep 2009, 11:26 -0400, Rick Macklem wrote: >>>> > [snip] >>>>> Now, hopefully someone who understands enough about dynamic linking will >>>>> know if this is the correct fix for 8.0? (I'm going on a couple of weeks >>>>> vacation at the end of this week, so I won't be around to commit >>>>> anything >>>>> and don't understand it well enough to know if this is the correct way >>>>> to fix it.) >>>>> >>>>> So, hopefully someone else can pick this one up? >>>>> > [snip] >>>> I have submitted a patch to the FreeBSD Makefile which patches the >>>> vendor-supplied template for krb5-config. I should be grateful if dfr@ >>>> or another src committer would please review this with a view to >>>> obtaining re@ approval to commit it before 8.0-RC2. >>>> >>>> >>> Any src committers able to help with this? >> Hmmm, I thought that libgssapi was supposed to use dlopen to load the proper >> back-end libraries using /etc/gss/mech rather than having applications >> directly link against them. > > OK, so if my proposed solution is, in fact, only masking a symptom of a > broken dynamic linker, would somebody who understands this stuff please > weigh in on this with some debugging suggestions or with a patch to > address this problem? > > I'm able to help with testing but I'm not a programmer and know nothing > about the FreeBSD dynamic linker. I don't think the dynamic linker is broken. I would suspect a bug in libgssapi itself instead. -- John Baldwin From julian at elischer.org Mon Oct 5 17:34:05 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 5 17:34:12 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACA0549.7030404@tomjudge.com> References: <4ACA0549.7030404@tomjudge.com> Message-ID: <4ACA2E0F.5010800@elischer.org> Tom Judge wrote: > Hi, > > Does anyone know of a patch that will add per jail memory limits so that > a jail can't swallow the resources of the entire box? > > > Thanks > > Tom > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" not yet.. From lehmann at ans-netz.de Mon Oct 5 17:33:35 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Mon Oct 5 17:38:28 2009 Subject: glabel+gmirror (8.0-RC1 problem) In-Reply-To: <20090928184926.GA2016@garage.freebsd.pl> References: <20090927170244.0980d699.lehmann@ans-netz.de> <20090927223725.5893371f.lehmann@ans-netz.de> <20090928084035.GB1659@garage.freebsd.pl> <20090928203756.ef70e0c6.lehmann@ans-netz.de> <20090928184926.GA2016@garage.freebsd.pl> Message-ID: <20091005193340.cd84f0ec.lehmann@ans-netz.de> Pawel Jakub Dawidek wrote: > On Mon, Sep 28, 2009 at 08:37:56PM +0200, Oliver Lehmann wrote: > > Hi Pawel, > > > > Pawel Jakub Dawidek wrote: > > > > > Does anything change between you upgrade from BETA3 and RC1? For example > > > gmirror was compiled into the kernel before and now is loaded as module > > > or something similar? > > > > Nope, it was a clean BETA3 installation with the default GENERIC kernel > > which has afaik geom_label in kernel, but not geom_mirror (nevertheless I > > loaded geom_label.ko at boottime as well as geom_mirror) > > The same with RC1 - clean and fresh installation with the default GENERIC > > kernel and geom_label in kernel (default), but still loaded as module at > > boottime as well as geom_mirror. > > > > > Could you test this patch: > > > > > > http://people.freebsd.org/~pjd/patches/improved_taste.patch > > > > This makes gmirror+glabel work again on RC1 > > Thanks for confirmation. gjorunal is also affected. I tried to use one partition of my gmirror disk as journal device for my 3ware raid-5 device which works until I reboot - the journal is then gone as well. Is this patch likly to fix this as well? Will it be included in a future RC? Until now I've stayed away using glabel+gmirror but I didn't knew that gjournal is affected as well so I'm now left with warning that the journal provider is gone wile booting - and more tragically I'm left without journaling at all (which hurts on a 2.7TB partition when the system was not cleanly shut down) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From tom at tomjudge.com Mon Oct 5 17:48:28 2009 From: tom at tomjudge.com (Tom Judge) Date: Mon Oct 5 17:48:34 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACA2E0F.5010800@elischer.org> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> Message-ID: <4ACA3146.9090402@tomjudge.com> Julian Elischer wrote: > Tom Judge wrote: >> Hi, >> >> Does anyone know of a patch that will add per jail memory limits so >> that a jail can't swallow the resources of the entire box? >> >> >> Thanks >> >> Tom >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" > > > not yet.. > I started to port this to 7.1 today: http://wiki.freebsd.org/JailResourceLimits What are the peoples opinions on this patch? Tom From des at des.no Mon Oct 5 18:08:42 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Oct 5 18:08:49 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <20091005.182342.167950100.hrs@allbsd.org> (Hiroki Sato's message of "Mon, 05 Oct 2009 18:23:42 +0900 (JST)") References: <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <20091005055806.GB58246@zibbi.meraka.csir.co.za> <20091005.182342.167950100.hrs@allbsd.org> Message-ID: <86my45vhlj.fsf@ds4.des.no> Hiroki Sato writes: > John Hay writes: > > Is there a good reason why we still ship with ipv6 off by default? > What do you mean by "off by default"? I think IPv6 is not disabled by > default with the patch. % ident /usr/src/etc/defaults/rc.conf /usr/src/etc/defaults/rc.conf: $FreeBSD: head/etc/defaults/rc.conf 197619 2009-09-29 16:49:10Z dougb $ % grep ipv6_network_interfaces /usr/src/etc/defaults/rc.conf ipv6_network_interfaces="none" # List of IPv6 network interfaces #ipv6_network_interfaces="ed0 ep0" # Examples for router % grep ipv6_prefer /usr/src/etc/defaults/rc.conf ipv6_prefer="NO" # Use IPv6 when both IPv4 and IPv6 can be used Does mean that IPv6 is disabled by default? Who knows? There is no coherent explanation *anywhere* of what these variables mean, and rc.conf(5) does not mention them at all. In fact, the first hit for "ipv6" in rc.conf(5) is this: ipv6_enable (bool) Enable support for IPv6 networking. Note that this requires that the kernel has been compiled with options INET6. DES -- Dag-Erling Sm?rgrav - des@des.no From mav at FreeBSD.org Mon Oct 5 18:29:58 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon Oct 5 18:30:05 2009 Subject: 8-current + USB CD-ROM drive + CAM layer audio extraction from CD In-Reply-To: <200909261239.52792.hselasky@c2i.net> References: <200909261239.52792.hselasky@c2i.net> Message-ID: <4ACA3B21.40700@FreeBSD.org> Hi. Hans Petter Selasky wrote: > It turns out the xmms is not able to read audio from CD's due to a removed > IOCTL. cdparanoia is however able to read audio from CD's after a recompile > including libcam. > > The "CDIOCREADAUDIO" is not implemented in the FreeBSD 8/9-current kernel from > what I can see. cdio.h Revision 1.25 Mon Oct 20 09:29:40 2003 UTC (5 years, 11 months ago) by sos Remove no longer existant CDIOCREADAUDIO ioctl. -- Alexander Motin From uqs at spoerlein.net Mon Oct 5 18:35:35 2009 From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=) Date: Mon Oct 5 18:36:10 2009 Subject: pam_ssh no longer works after r197679 In-Reply-To: <86fx9yxfrz.fsf@ds4.des.no> References: <20091004225000.6a1a6262.taku@tackymt.homeip.net> <86fx9yxfrz.fsf@ds4.des.no> Message-ID: <20091005183526.GA3230@elmar.spoerlein.net> On Mon, 05.10.2009 at 13:05:04 +0200, Dag-Erling Sm?rgrav wrote: > Taku YAMAMOTO writes: > > A quick investigation revailed that libssh.so.5 had some symbols undefined, > > which prevented pam_ssh.so.5 from being loaded. > > # FYI: openpam dlopen()s modules with RTLD_NOW. > > > > Here's interesting bits from nm -D /usr/lib/libssh.so.5 | fgrep U > > U roaming_read > > U roaming_write > > This is weird - I understand what the problem is, but I don't understand > why it didn't break the build. > > As a workaround, try adding roaming_dummy.c to SRCS in pam_ssh's > Makefile. Did the following and everything is back to normal: # cd /usr/src/lib/libpam/modules/pam_ssh # make "SRCS=pam_ssh.c roaming_dummy.c" # make "SRCS=pam_ssh.c roaming_dummy.c" install Cheers, Uli From amvandemore at gmail.com Mon Oct 5 18:42:08 2009 From: amvandemore at gmail.com (Adam Vande More) Date: Mon Oct 5 18:42:14 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACA3146.9090402@tomjudge.com> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> Message-ID: <6201873e0910051142q58e7563fqc7735261ea9ab3c6@mail.gmail.com> On Mon, Oct 5, 2009 at 12:47 PM, Tom Judge wrote: > Julian Elischer wrote: > >> Tom Judge wrote: >> >>> Hi, >>> >>> Does anyone know of a patch that will add per jail memory limits so that >>> a jail can't swallow the resources of the entire box? >>> >>> >>> Thanks >>> >>> Tom >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to " >>> freebsd-current-unsubscribe@freebsd.org" >>> >> >> >> not yet.. >> >> > I started to port this to 7.1 today: > > http://wiki.freebsd.org/JailResourceLimits > > > What are the peoples opinions on this patch? > > > Tom > If you're soliciting opinions if this will be used and is needed, I would love to see this functionality. This is the main reason I've had to chose XEN over jails. If you need some help testing, let me know. -- Adam Vande More From des at des.no Mon Oct 5 18:46:37 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Oct 5 18:46:43 2009 Subject: pam_ssh no longer works after r197679 In-Reply-To: <20091005183526.GA3230@elmar.spoerlein.net> ("Ulrich =?utf-8?Q?Sp=C3=B6rlein=22's?= message of "Mon, 5 Oct 2009 20:35:26 +0200") References: <20091004225000.6a1a6262.taku@tackymt.homeip.net> <86fx9yxfrz.fsf@ds4.des.no> <20091005183526.GA3230@elmar.spoerlein.net> Message-ID: <86iqetvfuc.fsf@ds4.des.no> Ulrich Sp?rlein writes: > Did the following and everything is back to normal: > > # cd /usr/src/lib/libpam/modules/pam_ssh > # make "SRCS=pam_ssh.c roaming_dummy.c" > # make "SRCS=pam_ssh.c roaming_dummy.c" install Thanks, I'll commit the proper fix right away. DES -- Dag-Erling Sm?rgrav - des@des.no From bsam at ipt.ru Mon Oct 5 18:46:53 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Mon Oct 5 18:47:01 2009 Subject: abort acroread at today's -current, but OK at 03-Oct -current Message-ID: <78132948@bb.ipt.ru> Hello List, today I updated my computer from 03-Oct CURRENT to -current and some ports were updated. And have got an error: ----- % acroread zsh: abort acroread % /bin/sh -x `which acroread` + echo '' + tr a-z A-Z + ADOBE_LANG='' + : ENU + BN=acroread + VN='' + [ -d /usr/local/Adobe/Reader8 ] + ADOBE_VER=8 + [ -d /usr/local/Adobe/Reader9 ] + ACROBASE=Adobe/Reader8 + BINPREFIX=Adobe/Reader8/bin + MOZILLA_COMP_PATH=/..//usr/local/lib/linux-nvu + export MOZILLA_COMP_PATH + GTK_IM_MODULE=xim + export GTK_IM_MODULE + UNAME_s=Linux + export UNAME_s + [ -x /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread ] + exec /compat/linux/bin/sh /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread zsh: abort /bin/sh -x `which acroread` ----- Loading old kernel gives a working acroread. What did I miss? Thanks. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From oberman at es.net Mon Oct 5 18:54:13 2009 From: oberman at es.net (Kevin Oberman) Date: Mon Oct 5 18:54:20 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: Your message of "Mon, 05 Oct 2009 20:08:40 +0200." <86my45vhlj.fsf@ds4.des.no> Message-ID: <20091005185408.728471CC0E@ptavv.es.net> > From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= > Date: Mon, 05 Oct 2009 20:08:40 +0200 > Sender: owner-freebsd-current@freebsd.org > > Hiroki Sato writes: > > John Hay writes: > > > Is there a good reason why we still ship with ipv6 off by default? > > What do you mean by "off by default"? I think IPv6 is not disabled by > > default with the patch. > > % ident /usr/src/etc/defaults/rc.conf > /usr/src/etc/defaults/rc.conf: > $FreeBSD: head/etc/defaults/rc.conf 197619 2009-09-29 16:49:10Z dougb $ > % grep ipv6_network_interfaces /usr/src/etc/defaults/rc.conf > ipv6_network_interfaces="none" # List of IPv6 network interfaces > #ipv6_network_interfaces="ed0 ep0" # Examples for router > % grep ipv6_prefer /usr/src/etc/defaults/rc.conf > ipv6_prefer="NO" # Use IPv6 when both IPv4 and IPv6 can be used > > Does mean that IPv6 is disabled by default? Who knows? There is no > coherent explanation *anywhere* of what these variables mean, and > rc.conf(5) does not mention them at all. In fact, the first hit for > "ipv6" in rc.conf(5) is this: > > ipv6_enable > (bool) Enable support for IPv6 networking. Note that this > requires that the kernel has been compiled with options > INET6. Am I missing something here? From the same /etc/defaults/rc.conf: ### IPv6 options: ### ipv6_enable="NO" # Set to YES to set up for IPv6. That looks about a "disabled out of the box" as it gets. As far as I can see (which may not be far), ipv6_network_interfaces is only relevant to IPv6 routing. I believe that ipv6_prefer controls the default behavior when DNS returns both IPv4 and IPv6 addresses for a host. If it is set to "NO", IPv4 will be tried first (preferred). If set to "YES", the IPv6 address will be preferred. I strongly recommend keeping ipv6_prefer set to "NO". -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From bzeeb-lists at lists.zabbadoz.net Mon Oct 5 18:55:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Oct 5 18:55:15 2009 Subject: abort acroread at today's -current, but OK at 03-Oct -current In-Reply-To: <78132948@bb.ipt.ru> References: <78132948@bb.ipt.ru> Message-ID: <20091005185230.K5956@maildrop.int.zabbadoz.net> On Mon, 5 Oct 2009, Boris Samorodov wrote: Hi, > today I updated my computer from 03-Oct CURRENT to -current and > some ports were updated. And have got an error: > ----- > % acroread > zsh: abort acroread > % /bin/sh -x `which acroread` > + echo '' > + tr a-z A-Z > + ADOBE_LANG='' > + : ENU > + BN=acroread > + VN='' > + [ -d /usr/local/Adobe/Reader8 ] > + ADOBE_VER=8 > + [ -d /usr/local/Adobe/Reader9 ] > + ACROBASE=Adobe/Reader8 > + BINPREFIX=Adobe/Reader8/bin > + MOZILLA_COMP_PATH=/..//usr/local/lib/linux-nvu > + export MOZILLA_COMP_PATH > + GTK_IM_MODULE=xim > + export GTK_IM_MODULE > + UNAME_s=Linux > + export UNAME_s > + [ -x /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread ] > + exec /compat/linux/bin/sh /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread > zsh: abort /bin/sh -x `which acroread` > ----- > > Loading old kernel gives a working acroread. What did I miss? > Thanks. The euqivalent patch of: http://security.freebsd.org/advisories/FreeBSD-EN-09:05.null.asc See the thread on stable@ for more background. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From hselasky at c2i.net Mon Oct 5 19:00:07 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Oct 5 19:00:14 2009 Subject: 8-current + USB CD-ROM drive + CAM layer audio extraction from CD In-Reply-To: <4ACA3B21.40700@FreeBSD.org> References: <200909261239.52792.hselasky@c2i.net> <4ACA3B21.40700@FreeBSD.org> Message-ID: <200910052100.53186.hselasky@c2i.net> On Monday 05 October 2009 20:29:53 Alexander Motin wrote: > Hi. > > Hans Petter Selasky wrote: > > It turns out the xmms is not able to read audio from CD's due to a > > removed IOCTL. cdparanoia is however able to read audio from CD's after a > > recompile including libcam. > > > > The "CDIOCREADAUDIO" is not implemented in the FreeBSD 8/9-current kernel > > from what I can see. > > cdio.h Revision 1.25 > Mon Oct 20 09:29:40 2003 UTC (5 years, 11 months ago) by sos > > Remove no longer existant CDIOCREADAUDIO ioctl. Ok, maybe I have some old sources left in my tree then :-) --HPS From tom at tomjudge.com Mon Oct 5 19:00:14 2009 From: tom at tomjudge.com (Tom Judge) Date: Mon Oct 5 19:00:24 2009 Subject: Per Jail Memory Limits In-Reply-To: <6201873e0910051142q58e7563fqc7735261ea9ab3c6@mail.gmail.com> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <6201873e0910051142q58e7563fqc7735261ea9ab3c6@mail.gmail.com> Message-ID: <4ACA4216.9060008@tomjudge.com> Adam Vande More wrote: > On Mon, Oct 5, 2009 at 12:47 PM, Tom Judge > wrote: > > Julian Elischer wrote: > > Tom Judge wrote: > > Hi, > > Does anyone know of a patch that will add per jail memory > limits so that a jail can't swallow the resources of the > entire box? > > > Thanks > > Tom > _______________________________________________ > freebsd-current@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org > " > > > > not yet.. > > > I started to port this to 7.1 today: > > http://wiki.freebsd.org/JailResourceLimits > > > What are the peoples opinions on this patch? > > > Tom > > > If you're soliciting opinions if this will be used and is needed, I > would love to see this functionality. This is the main reason I've > had to chose XEN over jails. If you need some help testing, let me know. > > -- > Adam Vande More Hi Adam, I have a patch against 7.1 here: http://svn.tomjudge.com/freebsd/patches/jail-resource-limits/jail-limits.patch I will try to bring the patch up to current when I get a chance but I have no real need to do this as we use 7.1 in production. Notes: * CPU limiting is not support is not supported unless you use shecd_4bsd. * I have not tested this on any system yet, just compile tested, I am putting it though its paces right now. Tom From kostikbel at gmail.com Mon Oct 5 19:02:26 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon Oct 5 19:02:40 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACA3146.9090402@tomjudge.com> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> Message-ID: <20091005190213.GV2259@deviant.kiev.zoral.com.ua> On Mon, Oct 05, 2009 at 05:47:50PM +0000, Tom Judge wrote: > Julian Elischer wrote: > >Tom Judge wrote: > >>Hi, > >> > >>Does anyone know of a patch that will add per jail memory limits so > >>that a jail can't swallow the resources of the entire box? > >> > >> > >>Thanks > >> > >>Tom > >>_______________________________________________ > >>freebsd-current@freebsd.org mailing list > >>http://lists.freebsd.org/mailman/listinfo/freebsd-current > >>To unsubscribe, send any mail to > >>"freebsd-current-unsubscribe@freebsd.org" > > > > > >not yet.. > > > > I started to port this to 7.1 today: > > http://wiki.freebsd.org/JailResourceLimits > > > What are the peoples opinions on this patch? Since r194766, we have precise accounting for the anonymous memory, both globally and per-uid. If current jails infrastructure allows to set per-jail limits (and I suspect that it is), then you should just match these two facilities. The seemingly problematic thing is processes changing their jails. It can be done similar to how the uid accounting is done currently, by remembering which jail was charged in corresponding vm map entry and object. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091005/7bcad564/attachment.pgp From bsam at ipt.ru Mon Oct 5 19:02:26 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Mon Oct 5 19:02:40 2009 Subject: abort acroread at today's -current, but OK at 03-Oct -current In-Reply-To: <20091005185230.K5956@maildrop.int.zabbadoz.net> (Bjoern A. Zeeb's message of "Mon, 5 Oct 2009 18:53:18 +0000 (UTC)") References: <78132948@bb.ipt.ru> <20091005185230.K5956@maildrop.int.zabbadoz.net> Message-ID: <12055407@bb.ipt.ru> On Mon, 5 Oct 2009 18:53:18 +0000 (UTC) Bjoern A. Zeeb wrote: > The euqivalent patch of: > http://security.freebsd.org/advisories/FreeBSD-EN-09:05.null.asc > See the thread on stable@ for more background. Well, I've read about it at stable@, security@, etc. Couldn't imagine that that's the case here. Setting security.bsd.map_at_zero=1 helps here. Thanks for the quick answer! -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From tom at tomjudge.com Mon Oct 5 19:06:31 2009 From: tom at tomjudge.com (Tom Judge) Date: Mon Oct 5 19:06:40 2009 Subject: Per Jail Memory Limits In-Reply-To: <20091005190213.GV2259@deviant.kiev.zoral.com.ua> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <20091005190213.GV2259@deviant.kiev.zoral.com.ua> Message-ID: <4ACA4391.6020607@tomjudge.com> Kostik Belousov wrote: > On Mon, Oct 05, 2009 at 05:47:50PM +0000, Tom Judge wrote: > >> I started to port this to 7.1 today: >> >> http://wiki.freebsd.org/JailResourceLimits >> >> >> What are the peoples opinions on this patch? >> > > Since r194766, we have precise accounting for the anonymous memory, > both globally and per-uid. If current jails infrastructure allows to > set per-jail limits (and I suspect that it is), then you should > just match these two facilities. > > The seemingly problematic thing is processes changing their jails. > It can be done similar to how the uid accounting is done currently, > by remembering which jail was charged in corresponding vm map > entry and object. > Did this get MFC'd to stable/7? I have a requirement to implement this for 7.1. Thanks From kostikbel at gmail.com Mon Oct 5 19:07:17 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon Oct 5 19:07:26 2009 Subject: abort acroread at today's -current, but OK at 03-Oct -current In-Reply-To: <78132948@bb.ipt.ru> References: <78132948@bb.ipt.ru> Message-ID: <20091005190710.GW2259@deviant.kiev.zoral.com.ua> On Mon, Oct 05, 2009 at 10:46:51PM +0400, Boris Samorodov wrote: > Hello List, > > today I updated my computer from 03-Oct CURRENT to -current and > some ports were updated. And have got an error: > ----- > % acroread > zsh: abort acroread > % /bin/sh -x `which acroread` > + echo '' > + tr a-z A-Z > + ADOBE_LANG='' > + : ENU > + BN=acroread > + VN='' > + [ -d /usr/local/Adobe/Reader8 ] > + ADOBE_VER=8 > + [ -d /usr/local/Adobe/Reader9 ] > + ACROBASE=Adobe/Reader8 > + BINPREFIX=Adobe/Reader8/bin > + MOZILLA_COMP_PATH=/..//usr/local/lib/linux-nvu > + export MOZILLA_COMP_PATH > + GTK_IM_MODULE=xim > + export GTK_IM_MODULE > + UNAME_s=Linux > + export UNAME_s > + [ -x /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread ] > + exec /compat/linux/bin/sh /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread > zsh: abort /bin/sh -x `which acroread` > ----- > > Loading old kernel gives a working acroread. What did I miss? > Thanks. Try this. diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index 4ed7382..e958214 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -635,7 +635,8 @@ __elfN(load_file)(struct proc *p, const char *file, u_long *addr, } for (i = 0, numsegs = 0; i < hdr->e_phnum; i++) { - if (phdr[i].p_type == PT_LOAD) { /* Loadable segment */ + if (phdr[i].p_type == PT_LOAD && phdr[i].p_memsz != 0) { + /* Loadable segment */ prot = 0; if (phdr[i].p_flags & PF_X) prot |= VM_PROT_EXECUTE; @@ -764,6 +768,8 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *imgp) for (i = 0; i < hdr->e_phnum; i++) { switch (phdr[i].p_type) { case PT_LOAD: /* Loadable segment */ + if (phdr[i].p_memsz == 0) + break; prot = 0; if (phdr[i].p_flags & PF_X) prot |= VM_PROT_EXECUTE; -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091005/0aa05e9b/attachment.pgp From kostikbel at gmail.com Mon Oct 5 19:09:40 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon Oct 5 19:09:47 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACA4391.6020607@tomjudge.com> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <20091005190213.GV2259@deviant.kiev.zoral.com.ua> <4ACA4391.6020607@tomjudge.com> Message-ID: <20091005190934.GX2259@deviant.kiev.zoral.com.ua> On Mon, Oct 05, 2009 at 07:05:53PM +0000, Tom Judge wrote: > Kostik Belousov wrote: > >On Mon, Oct 05, 2009 at 05:47:50PM +0000, Tom Judge wrote: > > > >>I started to port this to 7.1 today: > >> > >>http://wiki.freebsd.org/JailResourceLimits > >> > >> > >>What are the peoples opinions on this patch? > >> > > > >Since r194766, we have precise accounting for the anonymous memory, > >both globally and per-uid. If current jails infrastructure allows to > >set per-jail limits (and I suspect that it is), then you should > >just match these two facilities. > > > >The seemingly problematic thing is processes changing their jails. > >It can be done similar to how the uid accounting is done currently, > >by remembering which jail was charged in corresponding vm map > >entry and object. > > > > Did this get MFC'd to stable/7? No, and never will be. > > I have a requirement to implement this for 7.1. > > Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091005/825f0e9b/attachment.pgp From des at des.no Mon Oct 5 19:12:35 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Oct 5 19:12:42 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <20091005185408.728471CC0E@ptavv.es.net> (Kevin Oberman's message of "Mon, 05 Oct 2009 11:54:08 -0700") References: <20091005185408.728471CC0E@ptavv.es.net> Message-ID: <86ab05ven2.fsf@ds4.des.no> "Kevin Oberman" writes: > Am I missing something here? From the same /etc/defaults/rc.conf: > ### IPv6 options: ### > ipv6_enable="NO" # Set to YES to set up for IPv6. > > That looks about a "disabled out of the box" as it gets. AFAIK, ipv6_enable has no effect. DES -- Dag-Erling Sm?rgrav - des@des.no From tom at tomjudge.com Mon Oct 5 19:13:29 2009 From: tom at tomjudge.com (Tom Judge) Date: Mon Oct 5 19:13:38 2009 Subject: Per Jail Memory Limits In-Reply-To: <20091005190934.GX2259@deviant.kiev.zoral.com.ua> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <20091005190213.GV2259@deviant.kiev.zoral.com.ua> <4ACA4391.6020607@tomjudge.com> <20091005190934.GX2259@deviant.kiev.zoral.com.ua> Message-ID: <4ACA4532.5000303@tomjudge.com> Kostik Belousov wrote: > On Mon, Oct 05, 2009 at 07:05:53PM +0000, Tom Judge wrote: > >> Kostik Belousov wrote: >> >>> On Mon, Oct 05, 2009 at 05:47:50PM +0000, Tom Judge wrote: >>> >>> >>>> I started to port this to 7.1 today: >>>> >>>> http://wiki.freebsd.org/JailResourceLimits >>>> >>>> >>>> What are the peoples opinions on this patch? >>>> >>>> >>> Since r194766, we have precise accounting for the anonymous memory, >>> both globally and per-uid. If current jails infrastructure allows to >>> set per-jail limits (and I suspect that it is), then you should >>> just match these two facilities. >>> >>> The seemingly problematic thing is processes changing their jails. >>> It can be done similar to how the uid accounting is done currently, >>> by remembering which jail was charged in corresponding vm map >>> entry and object. >>> >>> >> Did this get MFC'd to stable/7? >> > No, and never will be. > Could you possibly expand on the reasons why this will never be MFC'd? Thanks Tom From kostikbel at gmail.com Mon Oct 5 19:17:59 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon Oct 5 19:18:06 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACA4532.5000303@tomjudge.com> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <20091005190213.GV2259@deviant.kiev.zoral.com.ua> <4ACA4391.6020607@tomjudge.com> <20091005190934.GX2259@deviant.kiev.zoral.com.ua> <4ACA4532.5000303@tomjudge.com> Message-ID: <20091005191753.GZ2259@deviant.kiev.zoral.com.ua> On Mon, Oct 05, 2009 at 07:12:50PM +0000, Tom Judge wrote: > Kostik Belousov wrote: > >On Mon, Oct 05, 2009 at 07:05:53PM +0000, Tom Judge wrote: > > > >>Kostik Belousov wrote: > >> > >>>On Mon, Oct 05, 2009 at 05:47:50PM +0000, Tom Judge wrote: > >>> > >>> > >>>>I started to port this to 7.1 today: > >>>> > >>>>http://wiki.freebsd.org/JailResourceLimits > >>>> > >>>> > >>>>What are the peoples opinions on this patch? > >>>> > >>>> > >>>Since r194766, we have precise accounting for the anonymous memory, > >>>both globally and per-uid. If current jails infrastructure allows to > >>>set per-jail limits (and I suspect that it is), then you should > >>>just match these two facilities. > >>> > >>>The seemingly problematic thing is processes changing their jails. > >>>It can be done similar to how the uid accounting is done currently, > >>>by remembering which jail was charged in corresponding vm map > >>>entry and object. > >>> > >>> > >>Did this get MFC'd to stable/7? > >> > >No, and never will be. > > > > Could you possibly expand on the reasons why this will never be MFC'd? One reason is that r194766 is intrusive patch. Another issue is that some VM algorithms are different in 7 and 8/HEAD, and I have no intent or incentive to do backporting. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091005/73ed28f1/attachment.pgp From jamie at FreeBSD.org Mon Oct 5 19:19:59 2009 From: jamie at FreeBSD.org (Jamie Gritton) Date: Mon Oct 5 19:20:06 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACA0549.7030404@tomjudge.com> References: <4ACA0549.7030404@tomjudge.com> Message-ID: <4ACA46D8.8010504@FreeBSD.org> Tom Judge wrote: > Does anyone know of a patch that will add per jail memory limits so that > a jail can't swallow the resources of the entire box? Edward Tomasz Napierala has been working on a general resource limit framework, including jails and memory limits. You can find it at: http://p4db.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2009/trasz_limits - Jamie From kostikbel at gmail.com Mon Oct 5 19:21:51 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon Oct 5 19:21:58 2009 Subject: Signals and an exiting thread In-Reply-To: <20091002201213.GA16633@stack.nl> References: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> <20091002201213.GA16633@stack.nl> Message-ID: <20091005192144.GA2259@deviant.kiev.zoral.com.ua> On Fri, Oct 02, 2009 at 10:12:13PM +0200, Jilles Tjoelker wrote: > On Thu, Oct 01, 2009 at 03:07:30PM +0300, Kostik Belousov wrote: > > On Wed, Sep 30, 2009 at 11:02:19AM -0700, Justin Teller wrote: > > > We're trying to control one process from another process through > > > signals (I know, revolutionary ;-), and we've found that a signal > > > occasionally gets lost. ?The process we're signaling is > > > multi-threaded. ?It looks like the signal is lost when the kernel > > > decides to post the signal to a thread that is in the process of dying > > > (calling pthread_exit, etc). > > > > Is this expected behavior that we should just handle, or is it a race > > > in the kernel that should be/will be/already is fixed? > > > > It may be that a fix is already in current, and I just haven't found > > > it in my searches through the source code (I'm working off of source > > > code for an older 8.0 image). If it is fixed, I'd appreciate a > > > pointer to the code that fixes it. > > > When thread enters the kernel last time to be killed, it is very much > > bad idea to allow it to return to usermode to handle directed signal. > > And, there would always be window between entering the kernel and > > marking the thread as exiting. > > > Moving the thread-directed signals back to the process queue is hard > > and there is no way to distinguish which signals were sent to process > > or to the thread. > > > Possibly, we could clear the thread signal mask while still in user mode. > > I think it would still leave a very narrow window when a process > > signal could be directed to the dying thread and not be delivered to > > usermode; this happens when signal is generated while sigsetmask already > > entered the kernel, but did not changed the mask yet. This is worked > > around by rechecking the pending signals after setting the block mask > > and releasing it if needed. > > SIGKILL cannot be masked. Is it possible that a kill(SIGKILL) is > assigned to a dying thread and lost? > > (SIGSTOP cannot be masked either, but its processing is done by the > sending thread, so it should be safe.) > > I suppose that race can also occur in other uses of pthread_sigmask(). > If a thread masks a signal for a while, and that signal is assigned to > that thread just as it is executing pthread_sigmask(), it will only be > processed when that thread unblocks or accepts it, even though other > threads may have the signal unmasked or be in a sigwait() for it. > Signals sent after pthread_sigmask() has changed the signal mask are > likely processed sooner because they will be assigned to a different > thread or left in the process queue. > > POSIX seems to say that signals generated for the process should remain > queued for the process and should only be assigned to a thread at time > of delivery. > > This could be implemented by leaving signals in the process queue or by > tracking for each signal in the thread queue whether it was directed at > the thread and moving the process signals back at sigmask/thr_exit. > Either way I am not sure of all the consequences at this time. I agree that postponing assignment of the thread for signal delivery till the actual delivery occurs is the proper fix. I tried to cheat in my previous patch. Below is an experimental change that did very minimal testing. diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 0386fc4..abd9714 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -581,20 +581,11 @@ void signotify(struct thread *td) { struct proc *p; - sigset_t set; p = td->td_proc; PROC_LOCK_ASSERT(p, MA_OWNED); - /* - * If our mask changed we may have to move signal that were - * previously masked by all threads to our sigqueue. - */ - set = p->p_sigqueue.sq_signals; - SIGSETNAND(set, td->td_sigmask); - if (! SIGISEMPTY(set)) - sigqueue_move_set(&p->p_sigqueue, &td->td_sigqueue, &set); if (SIGPENDING(td)) { thread_lock(td); td->td_flags |= TDF_NEEDSIGCHK | TDF_ASTPENDING; @@ -1985,17 +1976,9 @@ tdsignal(struct proc *p, struct thread *td, int sig, ksiginfo_t *ksi) KNOTE_LOCKED(&p->p_klist, NOTE_SIGNAL | sig); prop = sigprop(sig); - /* - * If the signal is blocked and not destined for this thread, then - * assign it to the process so that we can find it later in the first - * thread that unblocks it. Otherwise, assign it to this thread now. - */ if (td == NULL) { td = sigtd(p, sig, prop); - if (SIGISMEMBER(td->td_sigmask, sig)) - sigqueue = &p->p_sigqueue; - else - sigqueue = &td->td_sigqueue; + sigqueue = &p->p_sigqueue; } else { KASSERT(td->td_proc == p, ("invalid thread")); sigqueue = &td->td_sigqueue; @@ -2409,8 +2392,9 @@ issignal(struct thread *td, int stop_allowed) { struct proc *p; struct sigacts *ps; + struct sigqueue *queue; sigset_t sigpending; - int sig, prop, newsig; + int sig, prop, newsig, signo; p = td->td_proc; ps = p->p_sigacts; @@ -2420,6 +2404,7 @@ issignal(struct thread *td, int stop_allowed) int traced = (p->p_flag & P_TRACED) || (p->p_stops & S_SIG); sigpending = td->td_sigqueue.sq_signals; + SIGSETOR(sigpending, p->p_sigqueue.sq_signals); SIGSETNAND(sigpending, td->td_sigmask); if (p->p_flag & P_PPWAIT) @@ -2440,6 +2425,7 @@ issignal(struct thread *td, int stop_allowed) */ if (SIGISMEMBER(ps->ps_sigignore, sig) && (traced == 0)) { sigqueue_delete(&td->td_sigqueue, sig); + sigqueue_delete(&p->p_sigqueue, sig); continue; } if (p->p_flag & P_TRACED && (p->p_flag & P_PPWAIT) == 0) { @@ -2452,12 +2438,18 @@ issignal(struct thread *td, int stop_allowed) if (sig != newsig) { ksiginfo_t ksi; + + queue = &td->td_sigqueue; /* * clear old signal. * XXX shrug off debugger, it causes siginfo to * be thrown away. */ - sigqueue_get(&td->td_sigqueue, sig, &ksi); + if (sigqueue_get(queue, sig, &ksi) == 0) { + queue = &p->p_sigqueue; + signo = sigqueue_get(queue, sig, &ksi); + KASSERT(signo == sig, ("signo != sig")); + } /* * If parent wants us to take the signal, @@ -2472,7 +2464,7 @@ issignal(struct thread *td, int stop_allowed) * Put the new signal into td_sigqueue. If the * signal is being masked, look for other signals. */ - SIGADDSET(td->td_sigqueue.sq_signals, sig); + SIGADDSET(queue->sq_signals, sig); if (SIGISMEMBER(td->td_sigmask, sig)) continue; signotify(td); @@ -2567,6 +2559,7 @@ issignal(struct thread *td, int stop_allowed) return (sig); } sigqueue_delete(&td->td_sigqueue, sig); /* take the signal! */ + sigqueue_delete(&p->p_sigqueue, sig); } /* NOTREACHED */ } @@ -2613,7 +2606,9 @@ postsig(sig) ps = p->p_sigacts; mtx_assert(&ps->ps_mtx, MA_OWNED); ksiginfo_init(&ksi); - sigqueue_get(&td->td_sigqueue, sig, &ksi); + if (sigqueue_get(&td->td_sigqueue, sig, &ksi) == 0 && + sigqueue_get(&p->p_sigqueue, sig, &ksi) == 0) + return; ksi.ksi_signo = sig; if (ksi.ksi_code == SI_TIMER) itimer_accept(p, ksi.ksi_timerid, &ksi); diff --git a/sys/kern/subr_trap.c b/sys/kern/subr_trap.c index 6d60ddb..ccf6479 100644 --- a/sys/kern/subr_trap.c +++ b/sys/kern/subr_trap.c @@ -90,6 +90,7 @@ userret(struct thread *td, struct trapframe *frame) CTR3(KTR_SYSC, "userret: thread %p (pid %d, %s)", td, p->p_pid, td->td_name); +#if 0 #ifdef DIAGNOSTIC /* Check that we called signotify() enough. */ PROC_LOCK(p); @@ -100,6 +101,7 @@ userret(struct thread *td, struct trapframe *frame) thread_unlock(td); PROC_UNLOCK(p); #endif +#endif #ifdef KTRACE KTRUSERRET(td); #endif @@ -218,7 +220,14 @@ ast(struct trapframe *framep) ktrcsw(0, 1); #endif } - if (flags & TDF_NEEDSIGCHK) { + + /* + * Check for signals. Unlocked reads of p_pendingcnt or + * p_siglist might cause process-directed signal to be handled + * later. + */ + if (flags & TDF_NEEDSIGCHK || p->p_pendingcnt > 0 || + !SIGISEMPTY(p->p_siglist)) { PROC_LOCK(p); mtx_lock(&p->p_sigacts->ps_mtx); while ((sig = cursig(td, SIG_STOP_ALLOWED)) != 0) diff --git a/sys/sys/signalvar.h b/sys/sys/signalvar.h index 89b40f0..680da40 100644 --- a/sys/sys/signalvar.h +++ b/sys/sys/signalvar.h @@ -252,9 +252,10 @@ typedef struct sigqueue { /* Return nonzero if process p has an unmasked pending signal. */ #define SIGPENDING(td) \ - (!SIGISEMPTY((td)->td_siglist) && \ - !sigsetmasked(&(td)->td_siglist, &(td)->td_sigmask)) - + ((!SIGISEMPTY((td)->td_siglist) && \ + !sigsetmasked(&(td)->td_siglist, &(td)->td_sigmask)) || \ + (!SIGISEMPTY((td)->td_proc->p_siglist) && \ + !sigsetmasked(&(td)->td_proc->p_siglist, &(td)->td_sigmask))) /* * Return the value of the pseudo-expression ((*set & ~*mask) != 0). This * is an optimized version of SIGISEMPTY() on a temporary variable diff --git a/tools/regression/sigqueue/sigqtest1/sigqtest1.c b/tools/regression/sigqueue/sigqtest1/sigqtest1.c index 0f40021..f0201c3 100644 --- a/tools/regression/sigqueue/sigqtest1/sigqtest1.c +++ b/tools/regression/sigqueue/sigqtest1/sigqtest1.c @@ -1,12 +1,14 @@ /* $FreeBSD$ */ -#include -#include #include #include +#include +#include +#include int received; -void handler(int sig, siginfo_t *si, void *ctx) +void +handler(int sig, siginfo_t *si, void *ctx) { if (si->si_code != SI_QUEUE) errx(1, "si_code != SI_QUEUE"); @@ -15,7 +17,8 @@ void handler(int sig, siginfo_t *si, void *ctx) received++; } -int main() +int +main() { struct sigaction sa; union sigval val; diff --git a/tools/regression/sigqueue/sigqtest2/sigqtest2.c b/tools/regression/sigqueue/sigqtest2/sigqtest2.c index 078ea81..50b579d 100644 --- a/tools/regression/sigqueue/sigqtest2/sigqtest2.c +++ b/tools/regression/sigqueue/sigqtest2/sigqtest2.c @@ -1,24 +1,29 @@ /* $FreeBSD$ */ -#include -#include -#include -#include #include #include +#include +#include +#include +#include +#include +#include int stop_received; int exit_received; int cont_received; -void job_handler(int sig, siginfo_t *si, void *ctx) +void +job_handler(int sig, siginfo_t *si, void *ctx) { int status; int ret; if (si->si_code == CLD_STOPPED) { + printf("%d: stop received\n", si->si_pid); stop_received = 1; kill(si->si_pid, SIGCONT); } else if (si->si_code == CLD_EXITED) { + printf("%d: exit received\n", si->si_pid); ret = waitpid(si->si_pid, &status, 0); if (ret == -1) errx(1, "waitpid"); @@ -26,11 +31,13 @@ void job_handler(int sig, siginfo_t *si, void *ctx) errx(1, "!WIFEXITED(status)"); exit_received = 1; } else if (si->si_code == CLD_CONTINUED) { + printf("%d: cont received\n", si->si_pid); cont_received = 1; } } -void job_control_test() +void +job_control_test(void) { struct sigaction sa; pid_t pid; @@ -43,9 +50,12 @@ void job_control_test() stop_received = 0; cont_received = 0; exit_received = 0; + fflush(stdout); pid = fork(); if (pid == 0) { + printf("child %d\n", getpid()); kill(getpid(), SIGSTOP); + sleep(2); exit(1); } @@ -60,11 +70,13 @@ void job_control_test() printf("job control test OK.\n"); } -void rtsig_handler(int sig, siginfo_t *si, void *ctx) +void +rtsig_handler(int sig, siginfo_t *si, void *ctx) { } -int main() +int +main() { struct sigaction sa; sigset_t set; -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091005/e9aeadff/attachment.pgp From 000.fbsd at quip.cz Mon Oct 5 19:38:57 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Mon Oct 5 19:39:04 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACA3146.9090402@tomjudge.com> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> Message-ID: <4ACA4B49.70702@quip.cz> Tom Judge wrote: > Julian Elischer wrote: > >> Tom Judge wrote: >> >>> >>> Does anyone know of a patch that will add per jail memory limits so >>> that a jail can't swallow the resources of the entire box? >> >> not yet.. >> > > I started to port this to 7.1 today: > > http://wiki.freebsd.org/JailResourceLimits > > > What are the peoples opinions on this patch? The original JailResourceLimits patch was never 100% functional. Please see this page http://wiki.freebsd.org/Jails with links to newer attempts for 7.x and 8.x. It is also better to discuss it on Jail mailinglist freebsd-jail@freebsd.org and you can find some useful informations in archive http://lists.freebsd.org/pipermail/freebsd-jail/ I am unhappy that there are people with some interest in to jail resource limits, some patches floating around, but it never arive at final stage and production quality, and never get committed. :( It would be nice to have jails with CPU / memory / FD / disk IO / bandwidth limits connected to SNMP monitoring of these resources. Unfortunately I have zero C coding skills, so I can just wait if somebody... Miroslav Lachman From dimitry at andric.com Mon Oct 5 19:39:40 2009 From: dimitry at andric.com (Dimitry Andric) Date: Mon Oct 5 19:39:48 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <20091005.123427.227628092.hrs@allbsd.org> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> Message-ID: <4ACA4B81.3090105@andric.com> On 2009-10-05 05:34, Hiroki Sato wrote: > The patch for stable/8 can be found at: > > http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff Hmm, build bombs out at sbin/ifconfig: ===> sbin/ifconfig (depend) make: don't know how to make af_nd6.c. Stop *** Error code 2 This is because the patch doesn't seem to contain sbin/ifconfig/af_nd6.c. Can I just use the version from head? From pyunyh at gmail.com Mon Oct 5 19:42:54 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Oct 5 19:43:01 2009 Subject: de(4) does not work on 8.0-RC1 In-Reply-To: <20091005.233648.263895250.nyan@jp.FreeBSD.org> References: <20090924112533.1377D83D2D@mail1.asahi-net.or.jp> <20090924.210712.162012268.nyan@jp.FreeBSD.org> <20090924175312.GA5572@michelle.cdnetworks.com> <20091005.233648.263895250.nyan@jp.FreeBSD.org> Message-ID: <20091005194134.GF1406@michelle.cdnetworks.com> On Mon, Oct 05, 2009 at 11:36:48PM +0900, Takahashi Yoshihiro wrote: > In article <20090924175312.GA5572@michelle.cdnetworks.com> > Pyun YongHyeon writes: > > >> > Thanks for your reply. They works well again on 8.0-RC1 with your > >> > patch. > >> > >> I also use a NIC supported by de(4). The patch works fine for it. > > > > Thanks for testing! Patch committed to HEAD(r197465). > > Do you have a plan to merge this patch into stable/8? > I wish that the de(4) works in 8.0R. > MFC done(r197787). > --- > TAKAHASHI Yoshihiro From kostikbel at gmail.com Mon Oct 5 19:59:19 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon Oct 5 19:59:26 2009 Subject: pmap_invalidate_cache_range() panic on Xen Server In-Reply-To: <20091005072515.3622.22FF24F1@gmail.com> References: <200910041220.n94CKxTH073639@svn.freebsd.org> <20091005072515.3622.22FF24F1@gmail.com> Message-ID: <20091005195855.GC2259@deviant.kiev.zoral.com.ua> On Mon, Oct 05, 2009 at 07:25:18AM +0900, Michio Karl Jinbo wrote: > On Sun, 4 Oct 2009 12:20:59 +0000 (UTC) > Konstantin Belousov wrote: > > > Log: > > MFC r197663: > > As a workaround, for Intel CPUs, do not use CLFLUSH in > > pmap_invalidate_cache_range() when self-snoop is apparently not reported > > in cpu features. > > > > Approved by: re (bz, kensmith) > > I was tested r197663/r197744, but kernel panic again on Citrix Xen Server. > > using 8.0-RC1 install cd, results are > 1. INTEL SU9400+HYPER-V(Windows2008 R2) -> boot OK. > 2. AMD Athlon X2 TK-55+HYPER-V(Windows2008 R2) -> boot NG. > 3. AMD PhenomII 940BK+Citrix Xen Server -> boot NG. > > I think INTEL CPUs are no problem, but AMD CPUs appear the problem. So I tested > the following patch, kernel boot was successed on recent 9-CURRENT and environment 3. > > sorry, poor English. Does the GENERIC kernel after r197744 boots on your plain hardware, without any hypervisor ? Also, please provide the lines from dmesg with CPU features lists, both from boot on plain hardware and under XEN. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091005/4ff30b5f/attachment.pgp From hrs at FreeBSD.org Mon Oct 5 20:03:52 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Mon Oct 5 20:04:06 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <86my45vhlj.fsf@ds4.des.no> References: <20091005055806.GB58246@zibbi.meraka.csir.co.za> <20091005.182342.167950100.hrs@allbsd.org> <86my45vhlj.fsf@ds4.des.no> Message-ID: <20091006.045043.187164797.hrs@allbsd.org> Dag-Erling Sm?rgrav wrote in <86my45vhlj.fsf@ds4.des.no>: de> Hiroki Sato writes: de> > John Hay writes: de> > > Is there a good reason why we still ship with ipv6 off by default? de> > What do you mean by "off by default"? I think IPv6 is not disabled by de> > default with the patch. de> de> % ident /usr/src/etc/defaults/rc.conf de> /usr/src/etc/defaults/rc.conf: de> $FreeBSD: head/etc/defaults/rc.conf 197619 2009-09-29 16:49:10Z dougb $ de> % grep ipv6_network_interfaces /usr/src/etc/defaults/rc.conf de> ipv6_network_interfaces="none" # List of IPv6 network interfaces de> #ipv6_network_interfaces="ed0 ep0" # Examples for router de> % grep ipv6_prefer /usr/src/etc/defaults/rc.conf de> ipv6_prefer="NO" # Use IPv6 when both IPv4 and IPv6 can be used de> de> Does mean that IPv6 is disabled by default? Who knows? There is no de> coherent explanation *anywhere* of what these variables mean, and de> rc.conf(5) does not mention them at all. In fact, the first hit for de> "ipv6" in rc.conf(5) is this: de> de> ipv6_enable de> (bool) Enable support for IPv6 networking. Note that this de> requires that the kernel has been compiled with options de> INET6. No, the rc.conf(5) has been updated in r197526: ipv6_enable (bool) If the variable is ``YES'', ``inet6 accept_rtadv'' is added to all of ifconfig__ipv6 and the ipv6_prefer is defined as ``YES''. This variable is deprecated. Use ipv6_prefer and ifconfig__ipv6. and UPDATING also explains the relationship between the $ipv6_enable and the other variables. IMHO "Enabling (or disabling) IPv6" is not a correct expression for $ipv6_enable and $ipv6_prefer. If you use a kernel with "options INET6" (GENERIC has it) IPv6 is enabled, and $ipv6_enable=NO in the old releases does not disable the functionality. It just controlled whether $ipv6_* in rc.conf are ignored or not. -- Hiroki -------------- 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-current/attachments/20091005/24619684/attachment-0001.pgp From tom at tomjudge.com Mon Oct 5 20:06:26 2009 From: tom at tomjudge.com (Tom Judge) Date: Mon Oct 5 20:06:32 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACA4B49.70702@quip.cz> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <4ACA4B49.70702@quip.cz> Message-ID: <4ACA519B.1040907@tomjudge.com> Miroslav Lachman wrote: > > The original JailResourceLimits patch was never 100% functional. > > Please see this page http://wiki.freebsd.org/Jails with links to newer > attempts for 7.x and 8.x. > > It is also better to discuss it on Jail mailinglist > freebsd-jail@freebsd.org and you can find some useful informations in > archive http://lists.freebsd.org/pipermail/freebsd-jail/ > > I am unhappy that there are people with some interest in to jail > resource limits, some patches floating around, but it never arive at > final stage and production quality, and never get committed. :( > > It would be nice to have jails with CPU / memory / FD / disk IO / > bandwidth limits connected to SNMP monitoring of these resources. > Unfortunately I have zero C coding skills, so I can just wait if > somebody... > > Miroslav Lachman Thanks, I will take a look at the patches here (just testing the 7.0 patch on 7.1 now). It would be nice to see some of this functionality, in the base system. Tom From swehack at gmail.com Mon Oct 5 20:17:04 2009 From: swehack at gmail.com (nocturnal) Date: Mon Oct 5 20:17:13 2009 Subject: Updating FreeBSD 7.0-RELEASE i386 to 7.2 amd64? Message-ID: <9aed80930910051249ocfcf946o2341c653d16b8e24@mail.gmail.com> Can it be done with a simple cvs or binary update of FreeBSD or must i re-install using some media? If i kept my /usr partition intact and just overwrote the important stuff with new files from the CD it wouldn't be so bad with a re-install but it would be nice if large parts of it could be done remote. What is your suggestion for this? -- Med v?nliga h?lsningar Stefan Midjich aka nocturnal [SWEHACK] http://swehack.se From julian at elischer.org Mon Oct 5 20:28:50 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 5 20:29:04 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACA4216.9060008@tomjudge.com> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <6201873e0910051142q58e7563fqc7735261ea9ab3c6@mail.gmail.com> <4ACA4216.9060008@tomjudge.com> Message-ID: <4ACA5704.2070404@elischer.org> Tom Judge wrote: > Adam Vande More wrote: >> On Mon, Oct 5, 2009 at 12:47 PM, Tom Judge > > wrote: >> >> Julian Elischer wrote: >> >> Tom Judge wrote: >> >> Hi, >> >> Does anyone know of a patch that will add per jail memory >> limits so that a jail can't swallow the resources of the >> entire box? >> >> >> Thanks >> >> Tom >> _______________________________________________ >> freebsd-current@freebsd.org >> mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org >> " >> >> >> >> not yet.. >> >> >> I started to port this to 7.1 today: >> >> http://wiki.freebsd.org/JailResourceLimits >> >> >> What are the peoples opinions on this patch? >> >> >> Tom >> >> >> If you're soliciting opinions if this will be used and is needed, I >> would love to see this functionality. This is the main reason I've >> had to chose XEN over jails. If you need some help testing, let me know. >> >> -- >> Adam Vande More > Hi Adam, > > I have a patch against 7.1 here: > http://svn.tomjudge.com/freebsd/patches/jail-resource-limits/jail-limits.patch probably the person who should work with this in -current is james (CC'd) > > > I will try to bring the patch up to current when I get a chance but I > have no real need to do this as we use 7.1 in production. > > Notes: > > * CPU limiting is not support is not supported unless you use > shecd_4bsd. > * I have not tested this on any system yet, just compile tested, I am > putting it though its paces right now. > > Tom > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From hrs at FreeBSD.org Mon Oct 5 20:36:59 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Mon Oct 5 20:37:12 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <4ACA4B81.3090105@andric.com> References: <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <4ACA4B81.3090105@andric.com> Message-ID: <20091006.053611.25963972.hrs@allbsd.org> Dimitry Andric wrote in <4ACA4B81.3090105@andric.com>: di> On 2009-10-05 05:34, Hiroki Sato wrote: di> > The patch for stable/8 can be found at: di> > di> > http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff di> di> Hmm, build bombs out at sbin/ifconfig: di> di> ===> sbin/ifconfig (depend) di> make: don't know how to make af_nd6.c. Stop di> *** Error code 2 di> di> This is because the patch doesn't seem to contain di> sbin/ifconfig/af_nd6.c. Can I just use the version from head? Yes, you can use the file in HEAD. I do not know why but "svn diff" seems not to generate a diff delta for a newly-added file by "svn merge"... The missing delta can also be found at: http://people.freebsd.org/~hrs/af_nd6.c.diff -- Hiroki -------------- 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-current/attachments/20091005/a76b54d0/attachment.pgp From tinderbox at freebsd.org Mon Oct 5 20:52:20 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 5 20:52:27 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <200910052052.n95KqIg7010977@freebsd-current.sentex.ca> TB --- 2009-10-05 19:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-05 19:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-10-05 19:15:00 - cleaning the object tree TB --- 2009-10-05 19:15:26 - cvsupping the source tree TB --- 2009-10-05 19:15:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-10-05 19:15:42 - building world TB --- 2009-10-05 19:15:42 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-05 19:15:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-05 19:15:42 - TARGET=amd64 TB --- 2009-10-05 19:15:42 - TARGET_ARCH=amd64 TB --- 2009-10-05 19:15:42 - TZ=UTC TB --- 2009-10-05 19:15:42 - __MAKE_CONF=/dev/null TB --- 2009-10-05 19:15:42 - cd /src TB --- 2009-10-05 19:15:42 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 5 19:15:42 UTC 2009 >>> 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 Mon Oct 5 20:42:07 UTC 2009 TB --- 2009-10-05 20:42:07 - generating LINT kernel config TB --- 2009-10-05 20:42:07 - cd /src/sys/amd64/conf TB --- 2009-10-05 20:42:07 - /usr/bin/make -B LINT TB --- 2009-10-05 20:42:07 - building LINT kernel TB --- 2009-10-05 20:42:07 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-05 20:42:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-05 20:42:07 - TARGET=amd64 TB --- 2009-10-05 20:42:07 - TARGET_ARCH=amd64 TB --- 2009-10-05 20:42:07 - TZ=UTC TB --- 2009-10-05 20:42:07 - __MAKE_CONF=/dev/null TB --- 2009-10-05 20:42:07 - cd /src TB --- 2009-10-05 20:42:07 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 5 20:42:07 UTC 2009 >>> 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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/uipc_shm.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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/uipc_sockbuf.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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/uipc_socket.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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/uipc_syscalls.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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/kern/uipc_usrreq.c cc1: warnings being treated as errors /src/sys/kern/uipc_usrreq.c: In function 'unp_pcblist': /src/sys/kern/uipc_usrreq.c:1471: warning: format '%d' expects type 'int', but argument 2 has type 'long int' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-05 20:52:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-05 20:52:18 - ERROR: failed to build lint kernel TB --- 2009-10-05 20:52:18 - 4321.98 user 988.80 system 5838.36 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From des at des.no Mon Oct 5 21:06:03 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Oct 5 21:06:15 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <20091006.045043.187164797.hrs@allbsd.org> (Hiroki Sato's message of "Tue, 06 Oct 2009 04:50:43 +0900 (JST)") References: <20091005055806.GB58246@zibbi.meraka.csir.co.za> <20091005.182342.167950100.hrs@allbsd.org> <86my45vhlj.fsf@ds4.des.no> <20091006.045043.187164797.hrs@allbsd.org> Message-ID: <8663atv9dz.fsf@ds4.des.no> Hiroki Sato writes: > No, the rc.conf(5) has been updated in r197526: > > ipv6_enable > (bool) If the variable is ``YES'', ``inet6 accept_rtadv'' is > added to all of ifconfig__ipv6 and the ipv6_prefer > is defined as ``YES''. > > This variable is deprecated. Use ipv6_prefer and > ifconfig__ipv6. Still not very helpful. If I install FreeBSD from a release CD and use the GENERIC kernel and do *not* want to use IPv6, what do I do? Please don't answer "compile a custom kernel". DES -- Dag-Erling Sm?rgrav - des@des.no From tinderbox at freebsd.org Mon Oct 5 21:33:50 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 5 21:34:02 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <200910052133.n95LXnNQ013666@freebsd-current.sentex.ca> TB --- 2009-10-05 20:04:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-05 20:04:20 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-10-05 20:04:20 - cleaning the object tree TB --- 2009-10-05 20:04:41 - cvsupping the source tree TB --- 2009-10-05 20:04:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-10-05 20:04:55 - building world TB --- 2009-10-05 20:04:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-05 20:04:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-05 20:04:55 - TARGET=ia64 TB --- 2009-10-05 20:04:55 - TARGET_ARCH=ia64 TB --- 2009-10-05 20:04:55 - TZ=UTC TB --- 2009-10-05 20:04:55 - __MAKE_CONF=/dev/null TB --- 2009-10-05 20:04:55 - cd /src TB --- 2009-10-05 20:04:55 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 5 20:04:56 UTC 2009 >>> 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 Oct 5 21:22:27 UTC 2009 TB --- 2009-10-05 21:22:27 - generating LINT kernel config TB --- 2009-10-05 21:22:27 - cd /src/sys/ia64/conf TB --- 2009-10-05 21:22:27 - /usr/bin/make -B LINT TB --- 2009-10-05 21:22:27 - building LINT kernel TB --- 2009-10-05 21:22:27 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-05 21:22:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-05 21:22:27 - TARGET=ia64 TB --- 2009-10-05 21:22:27 - TARGET_ARCH=ia64 TB --- 2009-10-05 21:22:27 - TZ=UTC TB --- 2009-10-05 21:22:27 - __MAKE_CONF=/dev/null TB --- 2009-10-05 21:22:27 - cd /src TB --- 2009-10-05 21:22:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 5 21:22:27 UTC 2009 >>> 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/kern/uipc_shm.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/kern/uipc_sockbuf.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/kern/uipc_socket.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/kern/uipc_syscalls.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/kern/uipc_usrreq.c cc1: warnings being treated as errors /src/sys/kern/uipc_usrreq.c: In function 'unp_pcblist': /src/sys/kern/uipc_usrreq.c:1471: warning: format '%d' expects type 'int', but argument 2 has type 'long int' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-05 21:33:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-05 21:33:49 - ERROR: failed to build lint kernel TB --- 2009-10-05 21:33:49 - 4262.91 user 700.97 system 5368.50 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From hrs at FreeBSD.org Mon Oct 5 22:09:37 2009 From: hrs at FreeBSD.org (Hiroki Sato) Date: Mon Oct 5 22:09:45 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <8663atv9dz.fsf@ds4.des.no> References: <86my45vhlj.fsf@ds4.des.no> <20091006.045043.187164797.hrs@allbsd.org> <8663atv9dz.fsf@ds4.des.no> Message-ID: <20091006.070714.233607520.hrs@allbsd.org> Dag-Erling Sm?rgrav wrote in <8663atv9dz.fsf@ds4.des.no>: de> Hiroki Sato writes: de> > No, the rc.conf(5) has been updated in r197526: de> > de> > ipv6_enable de> > (bool) If the variable is ``YES'', ``inet6 accept_rtadv'' is de> > added to all of ifconfig__ipv6 and the ipv6_prefer de> > is defined as ``YES''. de> > de> > This variable is deprecated. Use ipv6_prefer and de> > ifconfig__ipv6. de> de> Still not very helpful. de> de> If I install FreeBSD from a release CD and use the GENERIC kernel and do de> *not* want to use IPv6, what do I do? de> de> Please don't answer "compile a custom kernel". It depends on the definition of "use", but the answer is "do not put any $ifconfig_IF_ipv6 or $ipv6_prefer to your rc.conf". If so, IPv6 will be "disabled" (including communication using link-local addresses) on all of interfaces except lo0. It is the default behavior now. I do not think this means "IPv6 is disabled by default". By adding an IPv6 address by using ifconfig(8) after boot you can still use IPv6 on that interface. This is almost the same as IPv4 does. When I do not want to use IPv4, I do not put any IPv4 addresses to $ifconfig_IF. Strictly speaking the address ::1/128 on lo0 cannot be removed because it is assigned by the kernel itself unlike IPv4's 127.0.0.1, so you can use the loopback address without knowing it. If you do not want to use it, you can disable IPv6 on lo0 manually by "ifconfig lo0 inet6 ifdisabled". Anyway, the existence of this loopback address has not been changed for a long time. -- Hiroki -------------- 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-current/attachments/20091005/ed798d49/attachment.pgp From tinderbox at freebsd.org Mon Oct 5 22:16:48 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 5 22:16:55 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <200910052216.n95MGkrU079646@freebsd-current.sentex.ca> TB --- 2009-10-05 21:12:52 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-05 21:12:52 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-10-05 21:12:52 - cleaning the object tree TB --- 2009-10-05 21:13:13 - cvsupping the source tree TB --- 2009-10-05 21:13:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-10-05 21:13:26 - building world TB --- 2009-10-05 21:13:26 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-05 21:13:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-05 21:13:26 - TARGET=sparc64 TB --- 2009-10-05 21:13:26 - TARGET_ARCH=sparc64 TB --- 2009-10-05 21:13:26 - TZ=UTC TB --- 2009-10-05 21:13:26 - __MAKE_CONF=/dev/null TB --- 2009-10-05 21:13:26 - cd /src TB --- 2009-10-05 21:13:26 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 5 21:13:26 UTC 2009 >>> 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 Oct 5 22:08:54 UTC 2009 TB --- 2009-10-05 22:08:54 - generating LINT kernel config TB --- 2009-10-05 22:08:54 - cd /src/sys/sparc64/conf TB --- 2009-10-05 22:08:54 - /usr/bin/make -B LINT TB --- 2009-10-05 22:08:54 - building LINT kernel TB --- 2009-10-05 22:08:54 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-05 22:08:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-05 22:08:54 - TARGET=sparc64 TB --- 2009-10-05 22:08:54 - TARGET_ARCH=sparc64 TB --- 2009-10-05 22:08:54 - TZ=UTC TB --- 2009-10-05 22:08:54 - __MAKE_CONF=/dev/null TB --- 2009-10-05 22:08:54 - cd /src TB --- 2009-10-05 22:08:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 5 22:08:54 UTC 2009 >>> 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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_shm.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_sockbuf.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_socket.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_syscalls.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_usrreq.c cc1: warnings being treated as errors /src/sys/kern/uipc_usrreq.c: In function 'unp_pcblist': /src/sys/kern/uipc_usrreq.c:1471: warning: format '%d' expects type 'int', but argument 2 has type 'long int' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-05 22:16:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-05 22:16:46 - ERROR: failed to build lint kernel TB --- 2009-10-05 22:16:46 - 2986.88 user 636.63 system 3834.07 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From dougb at FreeBSD.org Mon Oct 5 22:23:22 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Oct 5 22:23:35 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <20091005.123427.227628092.hrs@allbsd.org> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> Message-ID: <4ACA71D4.6010502@FreeBSD.org> Hiroki Sato wrote: > Hi, > > I would like your comments about merging the network_ipv6 -> netif > integration to stable/8. I maintain my objection to MFC'ing this prior to the 8.0-RELEASE. As stated previously my objections are as follows (in decreasing order of general importance): 1. It is a fairly significant change happening too late in the release cycle. IMO that is reason enough to not allow the change. 2. Although 8.0 seems to be getting more beta/rc testing than previous .0 releases, the overall number of users testing it is still a small percentage of the userbase. 3. A dramatically smaller percentage of those users who are actually doing the testing is also using IPv6. 4. There are still rough edges to the changes. 5. I personally disagree with some of the choices you've made and would like to see more discussion about them. (More about 4 and 5 below.) The rough edges I've noticed have to do with the various problems people have reported to the lists, including what seems to be a lack of testing without IPv6 in the kernel, continuing evolution of how to deal with the afnet tests, and personally I've noticed the following on my console, although I haven't had time to research yet whether it's definitely coming from your changes: in6_ifattach_linklocal: failed to add a link-local addr to wpi0 In terms of design decisions you've made, I am still confused about why you insist on deprecating ipv6_enable. Recent discussion on the lists indicates to me that I'm not alone in thinking that this is a valuable mechanism and that there is not only no reason to deprecate it, to do so is not desirable. I'd also like to explore further the idea that I suggested in a previous thread that it should not be necessary to specify ifconfig_IF_ipv6 at all. The vast majority of users will be using RA for the next couple of years at least, so in my mind it makes sense to default to using ipv6_network_interfaces=$network_interfaces and RA by default. If the user has a need to configure something explicitly then you've provided the mechanism for them to do that, but they shouldn't be forced to use it. This is another reason that I think ipv6_enable should be the "master" knob. I like the idea of the ipv6_prefer knob, but I do not like the idea of overloading it with the function of ipv6_enable too. I can certainly understand why you are eager to get these changes into 8.0, however if we do a proper job of maintaining backwards compatibility (which I think we should do anyway) I don't see any reason that they cannot be merged after 8.0, and more importantly after they have had a proper opportunity to shake out in HEAD. Doug -- This .signature sanitized for your protection From justin.teller at gmail.com Mon Oct 5 22:30:45 2009 From: justin.teller at gmail.com (Justin Teller) Date: Mon Oct 5 22:30:53 2009 Subject: Signals and an exiting thread In-Reply-To: <20091005192144.GA2259@deviant.kiev.zoral.com.ua> References: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> <20091002201213.GA16633@stack.nl> <20091005192144.GA2259@deviant.kiev.zoral.com.ua> Message-ID: 2009/10/5 Kostik Belousov : -- snip -- > > I agree that postponing assignment of the thread for signal delivery > till the actual delivery occurs is the proper fix. I tried to cheat > in my previous patch. Below is an experimental change that did very > minimal testing. > -- snip diff -- I like where you're going with the patch. I'll test it out as well and let you know what I find. Thanks! -Justin From tinderbox at freebsd.org Mon Oct 5 22:35:33 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 5 22:35:45 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <200910052235.n95MZWlA024807@freebsd-current.sentex.ca> TB --- 2009-10-05 21:33:49 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-05 21:33:49 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-10-05 21:33:49 - cleaning the object tree TB --- 2009-10-05 21:34:02 - cvsupping the source tree TB --- 2009-10-05 21:34:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-10-05 21:34:15 - building world TB --- 2009-10-05 21:34:15 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-05 21:34:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-05 21:34:15 - TARGET=sun4v TB --- 2009-10-05 21:34:15 - TARGET_ARCH=sparc64 TB --- 2009-10-05 21:34:15 - TZ=UTC TB --- 2009-10-05 21:34:15 - __MAKE_CONF=/dev/null TB --- 2009-10-05 21:34:15 - cd /src TB --- 2009-10-05 21:34:15 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 5 21:34:15 UTC 2009 >>> 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 Oct 5 22:27:48 UTC 2009 TB --- 2009-10-05 22:27:48 - generating LINT kernel config TB --- 2009-10-05 22:27:48 - cd /src/sys/sun4v/conf TB --- 2009-10-05 22:27:48 - /usr/bin/make -B LINT TB --- 2009-10-05 22:27:48 - building LINT kernel TB --- 2009-10-05 22:27:48 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-05 22:27:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-05 22:27:48 - TARGET=sun4v TB --- 2009-10-05 22:27:48 - TARGET_ARCH=sparc64 TB --- 2009-10-05 22:27:48 - TZ=UTC TB --- 2009-10-05 22:27:48 - __MAKE_CONF=/dev/null TB --- 2009-10-05 22:27:48 - cd /src TB --- 2009-10-05 22:27:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 5 22:27:48 UTC 2009 >>> 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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_shm.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_sockbuf.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_socket.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_syscalls.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/uipc_usrreq.c cc1: warnings being treated as errors /src/sys/kern/uipc_usrreq.c: In function 'unp_pcblist': /src/sys/kern/uipc_usrreq.c:1471: warning: format '%d' expects type 'int', but argument 2 has type 'long int' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-05 22:35:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-05 22:35:32 - ERROR: failed to build lint kernel TB --- 2009-10-05 22:35:32 - 2979.51 user 611.90 system 3703.13 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From qing.li at bluecoat.com Mon Oct 5 22:57:18 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Mon Oct 5 22:57:24 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <4ACA71D4.6010502@FreeBSD.org> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org><20091005.123427.227628092.hrs@allbsd.org> <4ACA71D4.6010502@FreeBSD.org> Message-ID: I agree with Doug and I'd prefer getting more runtime cycles out of these changes before MFC into stable/8. On a semi-related topic, I like the features developed in r197138. The changes are significant enough that having a MFC of 3 days is way too short. This changelist should also be postponed to post REL_8. -- Qing > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Doug Barton > Sent: Monday, October 05, 2009 3:23 PM > To: Hiroki Sato > Cc: freebsd-current@freebsd.org; freebsd-rc@freebsd.org > Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration > > Hiroki Sato wrote: > > Hi, > > > > I would like your comments about merging the network_ipv6 -> netif > > integration to stable/8. > > I maintain my objection to MFC'ing this prior to the 8.0-RELEASE. As > stated previously my objections are as follows (in decreasing order of > general importance): > > 1. It is a fairly significant change happening too late in the release > cycle. IMO that is reason enough to not allow the change. > 2. Although 8.0 seems to be getting more beta/rc testing than previous > .0 releases, the overall number of users testing it is still a small > percentage of the userbase. > 3. A dramatically smaller percentage of those users who are actually > doing the testing is also using IPv6. > 4. There are still rough edges to the changes. > 5. I personally disagree with some of the choices you've made and > would like to see more discussion about them. (More about 4 and 5 > below.) > > The rough edges I've noticed have to do with the various problems > people have reported to the lists, including what seems to be a lack > of testing without IPv6 in the kernel, continuing evolution of how to > deal with the afnet tests, and personally I've noticed the following > on my console, although I haven't had time to research yet whether > it's definitely coming from your changes: > > in6_ifattach_linklocal: failed to add a link-local addr to wpi0 > > In terms of design decisions you've made, I am still confused about > why you insist on deprecating ipv6_enable. Recent discussion on the > lists indicates to me that I'm not alone in thinking that this is a > valuable mechanism and that there is not only no reason to deprecate > it, to do so is not desirable. > > I'd also like to explore further the idea that I suggested in a > previous thread that it should not be necessary to specify > ifconfig_IF_ipv6 at all. The vast majority of users will be using RA > for the next couple of years at least, so in my mind it makes sense to > default to using ipv6_network_interfaces=$network_interfaces and RA by > default. If the user has a need to configure something explicitly then > you've provided the mechanism for them to do that, but they shouldn't > be forced to use it. This is another reason that I think ipv6_enable > should be the "master" knob. I like the idea of the ipv6_prefer knob, > but I do not like the idea of overloading it with the function of > ipv6_enable too. > > I can certainly understand why you are eager to get these changes into > 8.0, however if we do a proper job of maintaining backwards > compatibility (which I think we should do anyway) I don't see any > reason that they cannot be merged after 8.0, and more importantly > after they have had a proper opportunity to shake out in HEAD. > > > Doug > > -- > > This .signature sanitized for your protection > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" From taku at tackymt.homeip.net Tue Oct 6 05:59:08 2009 From: taku at tackymt.homeip.net (Taku YAMAMOTO) Date: Tue Oct 6 05:59:16 2009 Subject: pam_ssh no longer works after r197679 In-Reply-To: <86iqetvfuc.fsf@ds4.des.no> References: <20091004225000.6a1a6262.taku@tackymt.homeip.net> <86fx9yxfrz.fsf@ds4.des.no> <20091005183526.GA3230@elmar.spoerlein.net> <86iqetvfuc.fsf@ds4.des.no> Message-ID: <20091006145851.ef531ab9.taku@tackymt.homeip.net> On Mon, 05 Oct 2009 20:46:35 +0200 Dag-Erling Sm?rgrav wrote: > Ulrich Sp?rlein writes: > > Did the following and everything is back to normal: > > > > # cd /usr/src/lib/libpam/modules/pam_ssh > > # make "SRCS=pam_ssh.c roaming_dummy.c" > > # make "SRCS=pam_ssh.c roaming_dummy.c" install > > Thanks, I'll commit the proper fix right away. Cherry-picking r197785 and r197786 fixed the problem. Thanks! -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From kenyon at kenyonralph.com Tue Oct 6 07:15:08 2009 From: kenyon at kenyonralph.com (Kenyon Ralph) Date: Tue Oct 6 07:15:15 2009 Subject: de(4) does not work on 8.0-RC1 In-Reply-To: <20091005194134.GF1406@michelle.cdnetworks.com> References: <20090924112533.1377D83D2D@mail1.asahi-net.or.jp> <20090924.210712.162012268.nyan@jp.FreeBSD.org> <20090924175312.GA5572@michelle.cdnetworks.com> <20091005.233648.263895250.nyan@jp.FreeBSD.org> <20091005194134.GF1406@michelle.cdnetworks.com> Message-ID: <20091006062253.GZ17603@kenyonralph.com> On 2009-10-05T12:41:34-0700, Pyun YongHyeon wrote: > On Mon, Oct 05, 2009 at 11:36:48PM +0900, Takahashi Yoshihiro wrote: > > In article <20090924175312.GA5572@michelle.cdnetworks.com> > > Pyun YongHyeon writes: > > > > >> > Thanks for your reply. They works well again on 8.0-RC1 with your > > >> > patch. > > >> > > >> I also use a NIC supported by de(4). The patch works fine for it. > > > > > > Thanks for testing! Patch committed to HEAD(r197465). > > > > Do you have a plan to merge this patch into stable/8? > > I wish that the de(4) works in 8.0R. > > > > MFC done(r197787). This is not working for me: de0: port 0xa400-0xa47f mem 0xf1000000-0xf100007f irq 23 at device 7.0 on pci2 de0: can't read ENET ROM (why=-4) (ff7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff de0: 21140A [10-100Mb/s] pass 2.2 de0: address unknown Also, ifconfig does not show de0. FreeBSD ohm.kenyonralph.com 8.0-RC1 FreeBSD 8.0-RC1 #0 r197797: Mon Oct 5 21:40:16 PDT 2009 root@ohm.kenyonralph.com:/usr/obj/usr/src/sys/KRZFSOHM i386 de0 did appear in ifconfig on this machine with a stable/8 kernel and world built sometime in the past, but I don't know when exactly it stopped working (I haven't been using de0, but am planning to). Thanks, Kenyon Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091006/a8a5e2b2/attachment.pgp From kenyon at kenyonralph.com Tue Oct 6 07:34:18 2009 From: kenyon at kenyonralph.com (Kenyon Ralph) Date: Tue Oct 6 07:34:25 2009 Subject: de(4) does not work on 8.0-RC1 In-Reply-To: <20091006062253.GZ17603@kenyonralph.com> References: <20090924112533.1377D83D2D@mail1.asahi-net.or.jp> <20090924.210712.162012268.nyan@jp.FreeBSD.org> <20090924175312.GA5572@michelle.cdnetworks.com> <20091005.233648.263895250.nyan@jp.FreeBSD.org> <20091005194134.GF1406@michelle.cdnetworks.com> <20091006062253.GZ17603@kenyonralph.com> Message-ID: <20091006073415.GA17603@kenyonralph.com> On 2009-10-05T23:22:53-0700, Kenyon Ralph wrote: > de0: port 0xa400-0xa47f mem 0xf1000000-0xf100007f irq 23 at device 7.0 on pci2 > de0: can't read ENET ROM (why=-4) (ff7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff > de0: 21140A [10-100Mb/s] pass 2.2 > de0: address unknown > > Also, ifconfig does not show de0. > > FreeBSD ohm.kenyonralph.com 8.0-RC1 FreeBSD 8.0-RC1 #0 r197797: Mon > Oct 5 21:40:16 PDT 2009 > root@ohm.kenyonralph.com:/usr/obj/usr/src/sys/KRZFSOHM i386 Nevermind, I think this box has hardware problems. I plugged an Ethernet cable into de0 and the system locked up hard after a few minutes. Now the system won't even boot, even without the de0 card installed in the PCI slot. Kenyon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091006/f2051f9a/attachment.pgp From schmidt_chr at gmx.net Tue Oct 6 08:19:13 2009 From: schmidt_chr at gmx.net (Christian Schmidt) Date: Tue Oct 6 08:19:19 2009 Subject: Boot issues with a Dell Inspiron 530 and 8.0 RC1 Message-ID: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> Hello list, I am seeing a strange issue with my Dell Inspiron 530 with 8.0 RC1-p1 at around 50-75% percent of all boots. It all boils down to GENERIC throwing the following: AP #1 (PHY #1) failed! panic y/n? [y] panic: bye-bye cpuid = 0 However, this only happens when booting from the hard disk. A boot from the install CD works perfectly every time. Testing the machine with 7.2 last night revealed the same issue, so this is not specific to 8.0 As an interesting side-note: the odds of a successful boot increase dramtically when cold-booting. Rebooting from e.g. Linux or Windows seems to push the failure-rate to around a 100% every time. The system itself is almost completely Intel. Some specifications: Intel 82801 PCI Bridge Intel G33/G31/P35/P31 PCIe Intel ICH9 SMBus If anyone needs any more information just let me know. My incentive to provide the information that is needed to get a fix for this is rather high as this problem stops me from using FreeBSD on a machine that shows no other problems with either Linux or Windows. :-) Thank you, Christian From des at des.no Tue Oct 6 08:26:13 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Oct 6 08:26:25 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <20091006.070714.233607520.hrs@allbsd.org> (Hiroki Sato's message of "Tue, 06 Oct 2009 07:07:14 +0900 (JST)") References: <86my45vhlj.fsf@ds4.des.no> <20091006.045043.187164797.hrs@allbsd.org> <8663atv9dz.fsf@ds4.des.no> <20091006.070714.233607520.hrs@allbsd.org> Message-ID: <864oqd9bdn.fsf@ds4.des.no> Hiroki Sato writes: > Dag-Erling Sm?rgrav writes: > > If I install FreeBSD from a release CD and use the GENERIC kernel > > and do *not* want to use IPv6, what do I do? > It depends on the definition of "use", but the answer is "do not put > any $ifconfig_IF_ipv6 or $ipv6_prefer to your rc.conf". If so, IPv6 > will be "disabled" (including communication using link-local > addresses) on all of interfaces except lo0. It is the default > behavior now. > > I do not think this means "IPv6 is disabled by default". Close enough from my POV... thanks. Network configuration is complicated enough that I think we should have a separate man page for it; rc.conf is pretty much useless unless you already know what you're looking for. DES -- Dag-Erling Sm?rgrav - des@des.no From bsam at ipt.ru Tue Oct 6 08:49:12 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Tue Oct 6 08:49:19 2009 Subject: abort acroread at today's -current, but OK at 03-Oct -current In-Reply-To: <20091005190710.GW2259@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Mon, 5 Oct 2009 22:07:10 +0300") References: <78132948@bb.ipt.ru> <20091005190710.GW2259@deviant.kiev.zoral.com.ua> Message-ID: <22767770@bb.ipt.ru> On Mon, 5 Oct 2009 22:07:10 +0300 Kostik Belousov wrote: > On Mon, Oct 05, 2009 at 10:46:51PM +0400, Boris Samorodov wrote: > > > > today I updated my computer from 03-Oct CURRENT to -current and > > some ports were updated. And have got an error: > > ----- > > % acroread > > zsh: abort acroread > > % /bin/sh -x `which acroread` > > + echo '' > > + tr a-z A-Z > > + ADOBE_LANG='' > > + : ENU > > + BN=acroread > > + VN='' > > + [ -d /usr/local/Adobe/Reader8 ] > > + ADOBE_VER=8 > > + [ -d /usr/local/Adobe/Reader9 ] > > + ACROBASE=Adobe/Reader8 > > + BINPREFIX=Adobe/Reader8/bin > > + MOZILLA_COMP_PATH=/..//usr/local/lib/linux-nvu > > + export MOZILLA_COMP_PATH > > + GTK_IM_MODULE=xim > > + export GTK_IM_MODULE > > + UNAME_s=Linux > > + export UNAME_s > > + [ -x /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread ] > > + exec /compat/linux/bin/sh /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread > > zsh: abort /bin/sh -x `which acroread` > > ----- > > > > Loading old kernel gives a working acroread. What did I miss? > > Thanks. > Try this. > diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c > index 4ed7382..e958214 100644 > --- a/sys/kern/imgact_elf.c > +++ b/sys/kern/imgact_elf.c > @@ -635,7 +635,8 @@ __elfN(load_file)(struct proc *p, const char *file, u_long *addr, > } > > for (i = 0, numsegs = 0; i < hdr->e_phnum; i++) { > - if (phdr[i].p_type == PT_LOAD) { /* Loadable segment */ > + if (phdr[i].p_type == PT_LOAD && phdr[i].p_memsz != 0) { > + /* Loadable segment */ > prot = 0; > if (phdr[i].p_flags & PF_X) > prot |= VM_PROT_EXECUTE; > @@ -764,6 +768,8 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *imgp) > for (i = 0; i < hdr->e_phnum; i++) { > switch (phdr[i].p_type) { > case PT_LOAD: /* Loadable segment */ > + if (phdr[i].p_memsz == 0) > + break; > prot = 0; > if (phdr[i].p_flags & PF_X) > prot |= VM_PROT_EXECUTE; Thanks. Unfortunately there is no changes. Acroread works only with security.bsd.map_at_zero=1. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From pluknet at gmail.com Tue Oct 6 09:08:10 2009 From: pluknet at gmail.com (pluknet) Date: Tue Oct 6 09:08:17 2009 Subject: Boot issues with a Dell Inspiron 530 and 8.0 RC1 In-Reply-To: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> References: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> Message-ID: 2009/10/6 Christian Schmidt : > Hello list, > > I am seeing a strange issue with my Dell Inspiron 530 with 8.0 RC1-p1 > at around 50-75% percent of all boots. It all boils down to GENERIC > throwing the following: > > AP #1 (PHY #1) failed! > panic y/n? [y] panic: bye-bye > cpuid = 0 > > However, this only happens when booting from the hard disk. A boot > from the install CD works perfectly every time. Testing the machine > with 7.2 last night revealed the same issue, so this is not specific > to 8.0 > As an interesting side-note: the odds of a successful boot increase > dramtically when cold-booting. Rebooting from e.g. Linux or Windows > seems to push the failure-rate to around a 100% every time. > > The system itself is almost completely Intel. Some specifications: > Intel 82801 PCI Bridge > Intel G33/G31/P35/P31 PCIe > Intel ICH9 SMBus > I got an advice to try to update BIOS for a similar problem (visible in 6.x). Unfortunately it's not easy in my environment. Could you try that way and report? -- wbr, pluknet From schmidt_chr at gmx.net Tue Oct 6 09:18:16 2009 From: schmidt_chr at gmx.net (Christian Schmidt) Date: Tue Oct 6 09:18:23 2009 Subject: Boot issues with a Dell Inspiron 530 and 8.0 RC1 In-Reply-To: References: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> Message-ID: <309b65830910060217m51d18e8do5224aabb66ee0182@mail.gmail.com> On Tue, Oct 6, 2009 at 11:08, pluknet wrote: [...] > > I got an advice to try to update BIOS for a similar problem (visible in 6.x). > Unfortunately it's not easy in my environment. > Could you try that way and report? The BIOS is on the newest possible version. If it was that simple, I wouldn't have bothered writing to the list. :-) Thank you anyway. From bzeeb-lists at lists.zabbadoz.net Tue Oct 6 10:50:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Oct 6 10:50:18 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACA5704.2070404@elischer.org> References: <4ACA0549.7030404@tomjudge.com> <4ACA2E0F.5010800@elischer.org> <4ACA3146.9090402@tomjudge.com> <6201873e0910051142q58e7563fqc7735261ea9ab3c6@mail.gmail.com> <4ACA4216.9060008@tomjudge.com> <4ACA5704.2070404@elischer.org> Message-ID: <20091006104529.B5956@maildrop.int.zabbadoz.net> On Mon, 5 Oct 2009, Julian Elischer wrote: > Tom Judge wrote: >> Adam Vande More wrote: >>> On Mon, Oct 5, 2009 at 12:47 PM, Tom Judge >> > wrote: >>> >>> Julian Elischer wrote: >>> >>> Tom Judge wrote: >>> >>> Hi, >>> >>> Does anyone know of a patch that will add per jail memory >>> limits so that a jail can't swallow the resources of the >>> entire box? >>> >>> >>> Thanks >>> >>> Tom >>> >>> not yet.. >>> >>> >>> I started to port this to 7.1 today: >>> >>> http://wiki.freebsd.org/JailResourceLimits >>> >>> >>> What are the peoples opinions on this patch? >>> >>> >>> Tom >>> >>> >>> If you're soliciting opinions if this will be used and is needed, I would >>> love to see this functionality. This is the main reason I've had to chose >>> XEN over jails. If you need some help testing, let me know. >>> >>> -- >>> Adam Vande More >> Hi Adam, >> >> I have a patch against 7.1 here: >> http://svn.tomjudge.com/freebsd/patches/jail-resource-limits/jail-limits.patch > > > > probably the person who should work with this in -current is james (CC'd) Probably the person who should be contacted is trasz who worked on hierachical resource limit per .., jail in p4. Though this is slightly different. I think it's ok if people need those things to update the pathes but I doubt any will probably ever make it into FreeBSD as those things are kind of contrary to the V_ plans. BTW, I think the patch referenced is not the latest I had seen and I thought that we also had one for 7.x or even for 8 already floating around. Maybe some investigation on list archives etc. might be helpful before starting to hack things. Maybe also check the links on http://wiki.freebsd.org/Jails >> >> >> I will try to bring the patch up to current when I get a chance but I have >> no real need to do this as we use 7.1 in production. >> >> Notes: >> >> * CPU limiting is not support is not supported unless you use >> shecd_4bsd. >> * I have not tested this on any system yet, just compile tested, I am >> putting it though its paces right now. >> >> Tom -- Bjoern A. Zeeb It will not break if you know what you are doing. From kostikbel at gmail.com Tue Oct 6 11:04:04 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Oct 6 11:04:12 2009 Subject: abort acroread at today's -current, but OK at 03-Oct -current In-Reply-To: <22767770@bb.ipt.ru> References: <78132948@bb.ipt.ru> <20091005190710.GW2259@deviant.kiev.zoral.com.ua> <22767770@bb.ipt.ru> Message-ID: <20091006110359.GH2259@deviant.kiev.zoral.com.ua> On Tue, Oct 06, 2009 at 12:49:09PM +0400, Boris Samorodov wrote: > On Mon, 5 Oct 2009 22:07:10 +0300 Kostik Belousov wrote: > > On Mon, Oct 05, 2009 at 10:46:51PM +0400, Boris Samorodov wrote: > > > > > > today I updated my computer from 03-Oct CURRENT to -current and > > > some ports were updated. And have got an error: > > > ----- > > > % acroread > > > zsh: abort acroread > > > % /bin/sh -x `which acroread` > > > + echo '' > > > + tr a-z A-Z > > > + ADOBE_LANG='' > > > + : ENU > > > + BN=acroread > > > + VN='' > > > + [ -d /usr/local/Adobe/Reader8 ] > > > + ADOBE_VER=8 > > > + [ -d /usr/local/Adobe/Reader9 ] > > > + ACROBASE=Adobe/Reader8 > > > + BINPREFIX=Adobe/Reader8/bin > > > + MOZILLA_COMP_PATH=/..//usr/local/lib/linux-nvu > > > + export MOZILLA_COMP_PATH > > > + GTK_IM_MODULE=xim > > > + export GTK_IM_MODULE > > > + UNAME_s=Linux > > > + export UNAME_s > > > + [ -x /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread ] > > > + exec /compat/linux/bin/sh /usr/local/Adobe/Reader8/ENU/Adobe/Reader8/bin/acroread > > > zsh: abort /bin/sh -x `which acroread` > > > ----- > > > > > > Loading old kernel gives a working acroread. What did I miss? > > > Thanks. > > > Try this. > > > diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c > > index 4ed7382..e958214 100644 > > --- a/sys/kern/imgact_elf.c > > +++ b/sys/kern/imgact_elf.c > > @@ -635,7 +635,8 @@ __elfN(load_file)(struct proc *p, const char *file, u_long *addr, > > } > > > > for (i = 0, numsegs = 0; i < hdr->e_phnum; i++) { > > - if (phdr[i].p_type == PT_LOAD) { /* Loadable segment */ > > + if (phdr[i].p_type == PT_LOAD && phdr[i].p_memsz != 0) { > > + /* Loadable segment */ > > prot = 0; > > if (phdr[i].p_flags & PF_X) > > prot |= VM_PROT_EXECUTE; > > @@ -764,6 +768,8 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *imgp) > > for (i = 0; i < hdr->e_phnum; i++) { > > switch (phdr[i].p_type) { > > case PT_LOAD: /* Loadable segment */ > > + if (phdr[i].p_memsz == 0) > > + break; > > prot = 0; > > if (phdr[i].p_flags & PF_X) > > prot |= VM_PROT_EXECUTE; > > Thanks. Unfortunately there is no changes. Acroread works only with > security.bsd.map_at_zero=1. I see, with the help from bz@. Do you have amd64 or i386 system ? Anyway, please try http://people.freebsd.org/~kib/misc/pie.3.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091006/a13b8328/attachment.pgp From michio.jinbo at gmail.com Tue Oct 6 12:26:34 2009 From: michio.jinbo at gmail.com (Michio "Karl" Jinbo) Date: Tue Oct 6 12:26:42 2009 Subject: pmap_invalidate_cache_range() panic on Xen Server In-Reply-To: <20091005195855.GC2259@deviant.kiev.zoral.com.ua> References: <20091005072515.3622.22FF24F1@gmail.com> <20091005195855.GC2259@deviant.kiev.zoral.com.ua> Message-ID: <20091006212622.0699.22FF24F1@gmail.com> On Mon, 5 Oct 2009 22:58:55 +0300 Kostik Belousov wrote: > On Mon, Oct 05, 2009 at 07:25:18AM +0900, Michio Karl Jinbo wrote: > > On Sun, 4 Oct 2009 12:20:59 +0000 (UTC) > > Konstantin Belousov wrote: > > > > > Log: > > > MFC r197663: > > > As a workaround, for Intel CPUs, do not use CLFLUSH in > > > pmap_invalidate_cache_range() when self-snoop is apparently not reported > > > in cpu features. > > > > > > Approved by: re (bz, kensmith) > > > > I was tested r197663/r197744, but kernel panic again on Citrix Xen Server. > > > > using 8.0-RC1 install cd, results are > > 1. INTEL SU9400+HYPER-V(Windows2008 R2) -> boot OK. > > 2. AMD Athlon X2 TK-55+HYPER-V(Windows2008 R2) -> boot NG. > > 3. AMD PhenomII 940BK+Citrix Xen Server -> boot NG. > > > > I think INTEL CPUs are no problem, but AMD CPUs appear the problem. So I tested > > the following patch, kernel boot was successed on recent 9-CURRENT and environment 3. > > > > sorry, poor English. > Does the GENERIC kernel after r197744 boots on your plain hardware, > without any hypervisor ? > > Also, please provide the lines from dmesg with CPU features lists, > both from boot on plain hardware and under XEN. See attached 3files. as3810t.log is environment 1. vostro1000.log is environment 2. m4a78pro.log is environment 3. -- Michio "Karl" Jinbo -------------- next part -------------- A non-text attachment was scrubbed... Name: as3810t.log Type: application/octet-stream Size: 31896 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091006/f6eba514/as3810t-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: vostro1000.log Type: application/octet-stream Size: 30861 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091006/f6eba514/vostro1000-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: m4a78pro.log Type: application/octet-stream Size: 33695 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091006/f6eba514/m4a78pro-0001.obj From dimitry at andric.com Tue Oct 6 12:37:21 2009 From: dimitry at andric.com (Dimitry Andric) Date: Tue Oct 6 12:37:35 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <4ACA4B81.3090105@andric.com> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <4ACA4B81.3090105@andric.com> Message-ID: <4ACB3A08.9030109@andric.com> On 2009-10-05 21:39, Dimitry Andric wrote: >> http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff > Hmm, build bombs out at sbin/ifconfig: ... > This is because the patch doesn't seem to contain > sbin/ifconfig/af_nd6.c. Can I just use the version from head? FYI, the patch also misses etc/rc.d/{faith,stf}. Without these, mergemaster fails; again, taking them from head fixes it. From bsam at ipt.ru Tue Oct 6 13:22:02 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Tue Oct 6 13:22:09 2009 Subject: abort acroread at today's -current, but OK at 03-Oct -current In-Reply-To: <20091006110359.GH2259@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Tue, 6 Oct 2009 14:03:59 +0300") References: <78132948@bb.ipt.ru> <20091005190710.GW2259@deviant.kiev.zoral.com.ua> <22767770@bb.ipt.ru> <20091006110359.GH2259@deviant.kiev.zoral.com.ua> Message-ID: <35241576@bb.ipt.ru> On Tue, 6 Oct 2009 14:03:59 +0300 Kostik Belousov wrote: > Do you have amd64 or i386 system ? i386. > Anyway, please try http://people.freebsd.org/~kib/misc/pie.3.patch That did it, thanks! Not only acroread works but even skype (the latter didn't work either but didn't complain as opposed to acroread). -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From gavin.atkinson at ury.york.ac.uk Tue Oct 6 15:22:42 2009 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Tue Oct 6 15:22:49 2009 Subject: Boot issues with a Dell Inspiron 530 and 8.0 RC1 In-Reply-To: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> References: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> Message-ID: <1254842240.23831.22.camel@buffy.york.ac.uk> On Tue, 2009-10-06 at 09:54 +0200, Christian Schmidt wrote: > Hello list, > > I am seeing a strange issue with my Dell Inspiron 530 with 8.0 RC1-p1 > at around 50-75% percent of all boots. It all boils down to GENERIC > throwing the following: > > AP #1 (PHY #1) failed! > panic y/n? [y] panic: bye-bye > cpuid = 0 If you answer no, does it work? There are a couple of things that might be worth trying. Firstly, try playing with any USB-related options in the BIOS (especially "legacy emulation" or similar. Secondly, try editing src/sys/amd64/amd64/machdep.c (or /sys/i386/i386/machdep.c if you are using i386), search for "MacBook", and adding the output of the command "kenv smbios.system.product" to the list of strings compared. This may not make any difference, or may even make things worse (so keep your backup kernel ready:) but it's worth a try. Gavin From dhorn2000 at gmail.com Tue Oct 6 16:21:07 2009 From: dhorn2000 at gmail.com (David Horn) Date: Tue Oct 6 16:21:14 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <4ACB3A08.9030109@andric.com> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <4ACA4B81.3090105@andric.com> <4ACB3A08.9030109@andric.com> Message-ID: <25ff90d60910060921k2118994aq1f5b0431868ec800@mail.gmail.com> On Tue, Oct 6, 2009 at 8:37 AM, Dimitry Andric wrote: > On 2009-10-05 21:39, Dimitry Andric wrote: >>> ? http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff >> Hmm, build bombs out at sbin/ifconfig: > ... >> This is because the patch doesn't seem to contain >> sbin/ifconfig/af_nd6.c. ?Can I just use the version from head? > > FYI, the patch also misses etc/rc.d/{faith,stf}. ?Without these, > mergemaster fails; again, taking them from head fixes it. Hiroki -- I also attempted to use your patch against 8/Stable svn, and wanted to give some feedback. svn add before doing the svn diff will ensure that files you want to add to a patch get noticed. svn diff will only look at files under version control. 1) Patchset is missing examples and defaults for new rc.conf variables to /etc/defaults/rc.conf. (The defaults/rc.conf has been updated in -current, although perhaps once everything settles, it would help to expand the examples in comments) 2) I really like the changes to ifconfig and kernel for exposing per-interface flags for "accept_rtadv" and other ndp flags to ifconfig (and inherently rc.conf). I previously had to do some hackery to disable "accept_rtadv" at boot time for just one interface within rc.conf. 3) I would prefer that ipv6_enable remain a global flag in rc.conf, and NOT be obsoleted. I would also prefer that ipv6_network_interfaces="auto" as in the past by default. Again, I like the logic changes and the flexibility it provides, it is just the default/obsolete that I am interested in changing. 4) Personal opinion time: change the "accept_rtadv" token to "autoconf" in ifconfig and rc.conf, as this it is a better self-description. Just one persons opinion. 5) I noticed in the comments that you are considering allowing autoconf+router in a future advanced configuration. I completely agree with adding this functionality to -current (for ipv6 router cpe needs), we just need a new knob when this gets added. I had code around somewhere at one point. I'll see if I can find it still. There is a PR (conf/121812) on this as well. Given the timing, +1 for letting this bake in -current until after 8.0 release. If you want any early feedback for a future MFC of this code, feel free to email me and I will gladly test the patch. Thanks for the changes. ---Dave H From schmidt_chr at gmx.net Tue Oct 6 16:27:09 2009 From: schmidt_chr at gmx.net (Christian Schmidt) Date: Tue Oct 6 16:27:24 2009 Subject: Boot issues with a Dell Inspiron 530 and 8.0 RC1 In-Reply-To: <1254842240.23831.22.camel@buffy.york.ac.uk> References: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> <1254842240.23831.22.camel@buffy.york.ac.uk> Message-ID: <309b65830910060926x5842b05cw976942e76b13cfe9@mail.gmail.com> On Tue, Oct 6, 2009 at 17:17, Gavin Atkinson wrote: [...] > > If you answer no, does it work? I am not really given the choice here. It's always y. FreeBSD-Devs have a great sense of humor. :-) > There are a couple of things that might be worth trying. ?Firstly, try > playing with any USB-related options in the BIOS (especially "legacy > emulation" or similar. Alright, I will try that and give some feedback. > Secondly, try editing src/sys/amd64/amd64/machdep.c > (or /sys/i386/i386/machdep.c if you are using i386), search for > "MacBook", and adding the output of the command > "kenv smbios.system.product" > to the list of strings compared. Just for some understanding: what will that exactly do and why "MacBook"? > This may not make any difference, or may even make things worse (so keep > your backup kernel ready:) but it's worth a try. Good to know. :-) Thanks. > Gavin Christian -- Todays mistakes are tomorrows catastrophes. From gary.jennejohn at freenet.de Tue Oct 6 17:50:25 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Tue Oct 6 17:51:05 2009 Subject: Boot issues with a Dell Inspiron 530 and 8.0 RC1 In-Reply-To: <309b65830910060926x5842b05cw976942e76b13cfe9@mail.gmail.com> References: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> <1254842240.23831.22.camel@buffy.york.ac.uk> <309b65830910060926x5842b05cw976942e76b13cfe9@mail.gmail.com> Message-ID: <20091006195021.00b828f6@ernst.jennejohn.org> On Tue, 6 Oct 2009 18:26:47 +0200 Christian Schmidt wrote: > On Tue, Oct 6, 2009 at 17:17, Gavin Atkinson > > Secondly, try editing src/sys/amd64/amd64/machdep.c > > (or /sys/i386/i386/machdep.c if you are using i386), search for > > "MacBook", and adding the output of the command > > "kenv smbios.system.product" > > to the list of strings compared. > > Just for some understanding: what will that exactly do and why "MacBook"? > MacBook is in a comment near the code you should modifiy. If you were to look at the code you would see that it disables the LEGACY_USB_EN bit on the Intel ICH. --- Gary Jennejohn From cswiger at mac.com Tue Oct 6 18:50:25 2009 From: cswiger at mac.com (Chuck Swiger) Date: Tue Oct 6 18:50:37 2009 Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f In-Reply-To: <200910021440.50021.hselasky@freebsd.org> References: <200910021440.50021.hselasky@freebsd.org> Message-ID: <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Hi, Hans-- On Oct 2, 2009, at 5:40 AM, Hans Petter Selasky wrote: > Can the Apple's "Blocks" C language extension be used when > programming in the kernel? Or is this a user-space only feature? While the main benefit of blocks is in conjunction with libdispatch for userland apps, they can be used by themselves, in the kernel or elsewhere. A block is a closure and starts off living on the stack (although, a block can outlive the stack frame of the caller by being copied over to the heap if needed); the compiler wraps automatic variables which were around in the scope of the caller, turns their type into const (unless you explicitly declare that you need to change a variable by using __block storage keyword, in which case that variable is kept on the heap and accessed by reference) in order to preserve the state until the block runs. In effect, blocks are normal function invocations which also have an extra argument which is the context or pointer to the saved environment state. They can be used to implement callbacks and continuations in a clean way, although you do have some overhead with accessing mutable variables via pointer dereference to the struct holding your saved context. However, most uses of callbacks in C are implemented as functions which accept a void *, which is used to feed the callback function a struct * of some sort, so the end result is fairly similar. Regards, -- -Chuck From rwatson at freebsd.org Tue Oct 6 20:29:55 2009 From: rwatson at freebsd.org (Robert N. M. Watson) Date: Tue Oct 6 20:30:06 2009 Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f In-Reply-To: <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Message-ID: On 6 Oct 2009, at 19:50, Chuck Swiger wrote: > Hi, Hans-- > > On Oct 2, 2009, at 5:40 AM, Hans Petter Selasky wrote: >> Can the Apple's "Blocks" C language extension be used when >> programming in the kernel? Or is this a user-space only feature? > > While the main benefit of blocks is in conjunction with libdispatch > for userland apps, they can be used by themselves, in the kernel or > elsewhere. When a block is instantiated (perhaps not the formal terminology), the blocks runtime allocates memory to hold copies of relevant variables from the calling scope. This memory allocation may present an issue in some calling contexts in the kernel -- in particular, it won't be appropriate in contexts were non-sleepable locks are held, interrupt threads, etc. While it should be possible to use the primitive in the kernel, we may want to think carefully about these implications. Also, blocks are currently specific to clang, although with any luck gcc will grow them also. Robert > > A block is a closure and starts off living on the stack (although, a > block can outlive the stack frame of the caller by being copied over > to the heap if needed); the compiler wraps automatic variables which > were around in the scope of the caller, turns their type into const > (unless you explicitly declare that you need to change a variable by > using __block storage keyword, in which case that variable is kept > on the heap and accessed by reference) in order to preserve the > state until the block runs. > > In effect, blocks are normal function invocations which also have an > extra argument which is the context or pointer to the saved > environment state. They can be used to implement callbacks and > continuations in a clean way, although you do have some overhead > with accessing mutable variables via pointer dereference to the > struct holding your saved context. However, most uses of callbacks > in C are implemented as functions which accept a void *, which is > used to feed the callback function a struct * of some sort, so the > end result is fairly similar. > > Regards, > -- > -Chuck > From sgk at troutmask.apl.washington.edu Tue Oct 6 20:35:18 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Tue Oct 6 20:35:32 2009 Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f In-Reply-To: References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Message-ID: <20091006203518.GA26478@troutmask.apl.washington.edu> On Tue, Oct 06, 2009 at 09:29:50PM +0100, Robert N. M. Watson wrote: > > On 6 Oct 2009, at 19:50, Chuck Swiger wrote: > > >Hi, Hans-- > > > >On Oct 2, 2009, at 5:40 AM, Hans Petter Selasky wrote: > >>Can the Apple's "Blocks" C language extension be used when > >>programming in the kernel? Or is this a user-space only feature? > > > >While the main benefit of blocks is in conjunction with libdispatch > >for userland apps, they can be used by themselves, in the kernel or > >elsewhere. > > When a block is instantiated (perhaps not the formal terminology), the > blocks runtime allocates memory to hold copies of relevant variables > from the calling scope. This memory allocation may present an issue in > some calling contexts in the kernel -- in particular, it won't be > appropriate in contexts were non-sleepable locks are held, interrupt > threads, etc. While it should be possible to use the primitive in the > kernel, we may want to think carefully about these implications. Also, > blocks are currently specific to clang, although with any luck gcc > will grow them also. > It is unlikely that gcc will grow support for block any time soon. http://gcc.gnu.org/ml/gcc/2009-09/msg00272.html -- Steve From rdivacky at freebsd.org Tue Oct 6 20:42:09 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Tue Oct 6 20:42:16 2009 Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f In-Reply-To: References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Message-ID: <20091006204152.GA37998@freebsd.org> On Tue, Oct 06, 2009 at 09:29:50PM +0100, Robert N. M. Watson wrote: > > On 6 Oct 2009, at 19:50, Chuck Swiger wrote: > > >Hi, Hans-- > > > >On Oct 2, 2009, at 5:40 AM, Hans Petter Selasky wrote: > >>Can the Apple's "Blocks" C language extension be used when > >>programming in the kernel? Or is this a user-space only feature? > > > >While the main benefit of blocks is in conjunction with libdispatch > >for userland apps, they can be used by themselves, in the kernel or > >elsewhere. > > When a block is instantiated (perhaps not the formal terminology), the > blocks runtime allocates memory to hold copies of relevant variables > from the calling scope. This memory allocation may present an issue in > some calling contexts in the kernel -- in particular, it won't be > appropriate in contexts were non-sleepable locks are held, interrupt > threads, etc. While it should be possible to use the primitive in the > kernel, we may want to think carefully about these implications. Also, > blocks are currently specific to clang, although with any luck gcc > will grow them also. apple-gcc can do blocks iirc not that it matters for us. judging from the discussion on gcc ML they dont like this feature (they prefer C++0x lambdas and the thing from the new C standard iirc) From csjp at freebsd.org Tue Oct 6 21:10:47 2009 From: csjp at freebsd.org (Christian Peron) Date: Tue Oct 6 21:10:54 2009 Subject: XEN 5.5.0 and clflush In-Reply-To: <20090921153655.GA37236@gta.com> References: <20090921153655.GA37236@gta.com> Message-ID: <20091006205458.GA15679@movsx> This has been fixed. Update your kernel On Mon, Sep 21, 2009 at 11:36:55AM -0400, Larry Baird wrote: > Since the end of August I have been unable to boot a generic kernel from > FreeBSD current or 8 under XEN 5.5.0. Finally had a chance to briefly look > at the problem. If I apply attached patch to remove calls to clflush() I > am able to boot current. Hopefully somebody can shed some light. Is > XEN incorrecty reporting CPUID_CLFSH or is XEN not correctly virtualizing > this option. Or is the issue someplace else? I have also attached the > dmesg from a successful boot. This issue seems to be same as > http://www.freebsd.org/cgi/query-pr.cgi?pr=138863 > > > Here is an attempt to type backtrace from non-booting kernel: > pmap_invalidate_cache_range(c3252000,c3253000,c3253000,0,fee00000,...) at pamp_invalidate_cache_range+0x60 > pmap_mapdev_attr(fee00000,400,0,c1420d34,c0ba7a72,...) at pmap_mapdev_attr+0xec > pmap_mapdev() at pmap_mapdev+0x20 > lapic_init() at lapic_init+0x32 > madt_setup_local() at madt_setup_local+0x2c > apic_init() at apic_init+0x11a > mistartup() at mi_startup+0x96 > begin() at begin+0x2c > > Larry > > > -- > ------------------------------------------------------------------------ > Larry Baird | http://www.gta.com > Global Technology Associates, Inc. | Orlando, FL > Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-CURRENT #2: Mon Sep 21 11:00:46 EDT 2009 > lab@sw-xenoss.gta.com:/usr/src/sys/i386/compile/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Xeon(R) CPU 5110 @ 1.60GHz (1691.83-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > Features=0x789fbff > Features2=0x80002201> > AMD Features=0x20000000 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 536870912 (512 MB) > avail memory = 493977600 (471 MB) > ACPI APIC Table: > ioapic0: Changing APIC ID to 1 > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0 irqs 0-47 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x1f48-0x1f4b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 62500000 Hz quality 900 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > isab0: at device 1.0 on pci0 > isa0: on isab0 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc220-0xc22f at device 1.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > uhci0: port 0xc200-0xc21f irq 23 at device 1.2 on pci0 > uhci0: [ITHREAD] > uhci0: LegSup = 0x0000 > usbus0: controller did not stop > usbus0: on uhci0 > pci0: at device 1.3 (no driver attached) > vgapci0: mem 0xf0000000-0xf1ffffff,0xf3000000-0xf3000fff at device 2.0 on pci0 > pci0: at device 3.0 (no driver attached) > re0: port 0xc100-0xc1ff mem 0xf3001000-0xf30010ff irq 32 at device 4.0 on pci0 > re0: Chip rev. 0x74800000 > re0: MAC rev. 0x00000000 > miibus0: on re0 > rlphy0: PHY 0 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > re0: Ethernet address: 4e:c4:60:ce:d0:72 > re0: [FILTER] > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model IntelliMouse Explorer, device ID 4 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: does not respond > device_attach: fdc0 attach returned 6 > uart0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > ppc0: port 0x378-0x37f irq 7 on acpi0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppc0: [ITHREAD] > ppbus0: on ppc0 > plip0: on ppbus0 > plip0: [ITHREAD] > lpt0: on ppbus0 > lpt0: [ITHREAD] > lpt0: Interrupt-driven port > ppi0: on ppbus0 > cpu0: on acpi0 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: does not respond > device_attach: fdc0 attach returned 6 > pmtimer0 on isa0 > orm0: at iomem 0xd0000-0xd7fff 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 > Timecounter "TSC" frequency 1691834274 Hz quality 800 > Timecounters tick every 10.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > ad0: 20480MB at ata0-master WDMA2 > ugen0.1: at usbus0 > uhub0: on usbus0 > GEOM: ad0s1: geometry does not match label (255h,63s != 16h,63s). > uhub0: 2 ports with 2 removable, self powered > ugen0.2: at usbus0 > ums0: on usbus0 > ums0: 3 buttons and [Z] coordinates ID=0 > acd0: CDROM at ata1-slave WDMA2 > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from ufs:/dev/ad0s1a > lock order reversal: (sleepable after non-sleepable) > 1st 0xc390a058 rtentry (rtentry) @ net/route.c:1409 > 2nd 0xc0f433b8 ifnet_sx (ifnet_sx) @ netinet/sctp_bsd_addr.c:211 > KDB: stack backtrace: > db_trace_self_wrapper(c0c828bc,d6957788,c08c2725,c08b354b,c0c85715,...) at db_trace_self_wrapper+0x26 > kdb_backtrace(c08b354b,c0c85715,c35286e8,c352c8b8,d69577e4,...) at kdb_backtrace+0x29 > _witness_debugger(c0c85715,c0f433b8,c0c8e50e,c352c8b8,c0c9865e,...) at _witness_debugger+0x25 > witness_checkorder(c0f433b8,1,c0c98655,d3,0,...) at witness_checkorder+0x839 > _sx_slock(c0f433b8,0,c0c98655,d3,d6957878,...) at _sx_slock+0x85 > sctp_init_ifns_for_vrf(3,c39018c0,d69578c0,c08c3178,c3901964,...) at sctp_init_ifns_for_vrf+0x30 > sctp_addr_change(c38ffa00,1,d69578c0,c08c256c,d695791c,...) at sctp_addr_change+0x2c > rt_newaddrmsg(1,c38ffa00,0,c390a000,c38ffa00,...) at rt_newaddrmsg+0x3f > rtinit(c38ffa00,1,5,c0de9cfc,51573592,...) at rtinit+0x381 > in_ifinit(0,c0c96ee7,1aa,1a6,c3814800,...) at in_ifinit+0x8f6 > in_control(c38f7000,8040691a,c3907dc0,c3814800,c39018c0,...) at in_control+0xccb > ifioctl(c38f7000,8040691a,c3907dc0,c39018c0,c38ff200,...) at ifioctl+0x14f0 > soo_ioctl(c385f540,8040691a,c3907dc0,c356e100,c39018c0,...) at soo_ioctl+0x415 > kern_ioctl(c39018c0,3,8040691a,c3907dc0,8bc060,...) at kern_ioctl+0x1fd > ioctl(c39018c0,d6957cf8,c,c0c96f81,c0d665c8,...) at ioctl+0x134 > syscall(d6957d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281bf513, esp = 0xbfbfe61c, ebp = 0xbfbfe658 --- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -------------- 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-current/attachments/20091006/f926e529/attachment.pgp From lists at rhavenn.net Tue Oct 6 22:17:26 2009 From: lists at rhavenn.net (Henrik Hudson) Date: Tue Oct 6 22:17:39 2009 Subject: Updating FreeBSD 7.0-RELEASE i386 to 7.2 amd64? In-Reply-To: <9aed80930910051249ocfcf946o2341c653d16b8e24@mail.gmail.com> References: <9aed80930910051249ocfcf946o2341c653d16b8e24@mail.gmail.com> Message-ID: <20091006221719.GA5942@alucard.int.rhavenn.net> On Mon, 05 Oct 2009, nocturnal wrote: > Can it be done with a simple cvs or binary update of FreeBSD or must i > re-install using some media? > > If i kept my /usr partition intact and just overwrote the important stuff > with new files from the CD it wouldn't be so bad with a re-install but it > would be nice if large parts of it could be done remote. > > What is your suggestion for this? You will have to recompile all ports (/usr/local ) and any manually installed apps due to the changes in the system libs. Personally, it's not worth the headache of trying to do a "upgrade" across architectures like this. Most of the items in /usr (outside of /usr/local) are part of the base system and should update "okay", but I don't know if you will be able to boot a x64 kernel into a x86 system, assuming you try a reboot between make installkernel and make installworld . I don't think a binary upgrade would work at all, but I've never actually done a binary upgrade. I always csup. On that note, I've never tried this, but I would recommend against it. Henrik -- Henrik Hudson lists@rhavenn.net ----------------------------------------- "God, root, what is difference?" Pitr; UF From lab at gta.com Tue Oct 6 22:17:32 2009 From: lab at gta.com (Larry Baird) Date: Tue Oct 6 22:17:40 2009 Subject: XEN 5.5.0 and clflush In-Reply-To: <20091006205458.GA15679@movsx> References: <20090921153655.GA37236@gta.com> <20091006205458.GA15679@movsx> Message-ID: <20091006221731.GA18178@gta.com> On Tue, Oct 06, 2009 at 08:54:58PM +0000, Christian Peron wrote: > This has been fixed. Update your kernel I have verified I can now boot FreeBSD 9 under Xen. -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From rmacklem at uoguelph.ca Tue Oct 6 22:55:13 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Tue Oct 6 22:55:20 2009 Subject: [PATCH] SASL problems with spnego on 8.0-BETA4 In-Reply-To: <200910020824.15488.john@baldwin.cx> References: <4AB27FB6.4010806@eng.auth.gr> <20090921222241.GF1001@rwpc12.mby.riverwillow.net.au> <20091002081319.GN37304@rwpc12.mby.riverwillow.net.au> <200910020824.15488.john@baldwin.cx> Message-ID: On Fri, 2 Oct 2009, John Baldwin wrote: > > Hmmm, I thought that libgssapi was supposed to use dlopen to load the proper > back-end libraries using /etc/gss/mech rather than having applications > directly link against them. > I think the problem is that the global var. defined in -lgssapi doesn't get used by the app. so the .o file in -lgssapi where it's defined doesn't get loaded. (Can't remember the exact name, but it's something like GSS_C_HOST_BASED_NAME.) Then, when -lgssapi-spengo gets loaded, it can't resolve it. (I don't know enough about dynamic linking to know the correct way to fix this. The patch I suggested got it working...) rick From rmacklem at uoguelph.ca Tue Oct 6 23:15:16 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Tue Oct 6 23:15:23 2009 Subject: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS related?) In-Reply-To: References: <4ABD4BB9.1030804@FreeBSD.org> Message-ID: On Sun, 27 Sep 2009, Robert Watson wrote: > > On Fri, 25 Sep 2009, Jamie Gritton wrote: > >> It seems to be NFS related. I think the null pointer in question is from >> the export's anonymous credential. Try the patch below and see if it helps >> (which I guess means run it overnight and see if it crashes again). I've >> also patched a similar missing cred prison in GSS_SVC, since I'm not versed >> enough in NFS/RPC stuff to know if it might be the problem. > > This is one of the reasons I really dislike "magic" credentials and special > handling of NULL credentials -- they always get into code the author doesn't > expect, and either there are bad pointer dereferences, or incorrect security > decisions. It's almost always the case that a correct credential should have > been cached or generated at some earlier point to represent the security > context... > I don't really understand prisons/jails, but would creating these credentials via: crdup(td->td_ucred); // duplicating the daemon thread's cred - and then replacing the make sense as an alternative to starting with crget()? (ie. All the other stuff except would be "inherited" from the credential for the daemon thread.) rick From spambox at haruhiism.net Tue Oct 6 23:37:47 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Tue Oct 6 23:37:54 2009 Subject: ZFS-related panic, 8.0-RC1 Message-ID: <4ACBD4CA.3070300@haruhiism.net> Hello, hope you're having a nice day, Alas, this time I didn't manage to get a dump, so only the panic message is available: panic: _sx_xlock_hard: recursed on non-recursive sx zfsvfs->z_hold_mtx[i] @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1023 -- Kamigishi Rei KREI-RIPE From bland at FreeBSD.org Tue Oct 6 23:45:37 2009 From: bland at FreeBSD.org (Alexander Nedotsukov) Date: Tue Oct 6 23:45:44 2009 Subject: [PATCH] SASL problems with spnego on 8.0-BETA4 In-Reply-To: References: <4AB27FB6.4010806@eng.auth.gr> <20090921222241.GF1001@rwpc12.mby.riverwillow.net.au> <20091002081319.GN37304@rwpc12.mby.riverwillow.net.au> <200910020824.15488.john@baldwin.cx> Message-ID: <19306024-4C3D-41EC-A198-1652B047DF1A@FreeBSD.org> Use this patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: libgssapi_foo.patch Type: application/octet-stream Size: 899 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091006/2ce3bf0f/libgssapi_foo.obj -------------- next part -------------- On 07.10.2009, at 8:01, Rick Macklem wrote: > > > On Fri, 2 Oct 2009, John Baldwin wrote: > >> >> Hmmm, I thought that libgssapi was supposed to use dlopen to load >> the proper >> back-end libraries using /etc/gss/mech rather than having >> applications >> directly link against them. >> > I think the problem is that the global var. defined in -lgssapi > doesn't > get used by the app. so the .o file in -lgssapi where it's defined > doesn't > get loaded. (Can't remember the exact name, but it's something like > GSS_C_HOST_BASED_NAME.) Then, when -lgssapi-spengo gets loaded, it > can't > resolve it. (I don't know enough about dynamic linking to know the > correct way to fix this. The patch I suggested got it working...) > > rick > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " From csjp at freebsd.org Wed Oct 7 00:01:19 2009 From: csjp at freebsd.org (Christian Peron) Date: Wed Oct 7 00:01:26 2009 Subject: XEN 5.5.0 and clflush In-Reply-To: <20091006221731.GA18178@gta.com> References: <20090921153655.GA37236@gta.com> <20091006205458.GA15679@movsx> <20091006221731.GA18178@gta.com> Message-ID: <20091007000117.GA17855@movsx> K.. pretty sure there are plans to MFC this for 8 (assuming it has not been done already.) I will check. On Tue, Oct 06, 2009 at 06:17:31PM -0400, Larry Baird wrote: > On Tue, Oct 06, 2009 at 08:54:58PM +0000, Christian Peron wrote: > > This has been fixed. Update your kernel > I have verified I can now boot FreeBSD 9 under Xen. > > > -- > ------------------------------------------------------------------------ > Larry Baird | http://www.gta.com > Global Technology Associates, Inc. | Orlando, FL > Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 -------------- 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-current/attachments/20091007/236d7e09/attachment.pgp From tom at tomjudge.com Wed Oct 7 01:40:00 2009 From: tom at tomjudge.com (Tom Judge) Date: Wed Oct 7 01:40:06 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACA0549.7030404@tomjudge.com> References: <4ACA0549.7030404@tomjudge.com> Message-ID: <4ACBF147.1030002@tomjudge.com> Tom Judge wrote: > Hi, > > Does anyone know of a patch that will add per jail memory limits so > that a jail can't swallow the resources of the entire box? > So I have worked up some thing usable fore us based on the 7.0 code from the wiki. This patch is for 7.1 in implements both soft and hard memory limits. Details are here: http://www.tomjudge.com/index.php/FreeBSD/Jails/MemoryLimits Changes that add supporting infrastructure for cpu limiting are in the patch but changes to the schedulers have not been included. If you need the scheduling support you will need to patch sched_4bsd with the code from the original patch set here: http://lists.freebsd.org/pipermail/freebsd-jail/2008-June/000333.html Hope this is useful for some people. Tom From tom at tomjudge.com Wed Oct 7 01:46:19 2009 From: tom at tomjudge.com (Tom Judge) Date: Wed Oct 7 01:46:26 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACA46D8.8010504@FreeBSD.org> References: <4ACA0549.7030404@tomjudge.com> <4ACA46D8.8010504@FreeBSD.org> Message-ID: <4ACBF2C2.4040004@tomjudge.com> Jamie Gritton wrote: > Tom Judge wrote: >> Does anyone know of a patch that will add per jail memory limits so >> that a jail can't swallow the resources of the entire box? > > Edward Tomasz Napierala has been working on a general resource limit > framework, including jails and memory limits. You can find it at: > http://p4db.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2009/trasz_limits > > > - Jamie Is this in the subversion projects tree? It seems the p4 is not very easy to access unless you have access server. Tom From john.marshall at riverwillow.com.au Wed Oct 7 04:38:23 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Wed Oct 7 04:38:40 2009 Subject: [PATCH] SASL problems with spnego on 8.0-BETA4 In-Reply-To: <19306024-4C3D-41EC-A198-1652B047DF1A@FreeBSD.org> References: <4AB27FB6.4010806@eng.auth.gr> <20090921222241.GF1001@rwpc12.mby.riverwillow.net.au> <20091002081319.GN37304@rwpc12.mby.riverwillow.net.au> <200910020824.15488.john@baldwin.cx> <19306024-4C3D-41EC-A198-1652B047DF1A@FreeBSD.org> Message-ID: <20091007043806.GN1086@rwpc12.mby.riverwillow.net.au> On Wed, 07 Oct 2009, 08:45 +0900, Alexander Nedotsukov wrote: > Use this patch. It worked for me (for _krb5 case). FreeBSD 8.0-RC1 #0: Fri Sep 18 13:35:00 AEST 2009 i386 cyrus-sasl-2.1.23 openldap-sasl-server-2.4.18_1 - Restored original /usr/bin/krb5-config - Stopped LDAP server - Re-built port security/cyrus-sasl2 - Started LDAP server - Confirmed that attempted LDAP access with gssapi auth from a client failed and made the LDAP server die. - Applied libgssapi_foo.patch and re-built kerberos5 - Re-built port security/cyrus-sasl2 - Started LDAP server - LDAP access with gssapi auth from a client succeeded. Perhaps George Mamalakis could test the _spnego case? -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091007/8374e3b7/attachment.pgp From cswiger at mac.com Wed Oct 7 05:42:21 2009 From: cswiger at mac.com (Chuck Swiger) Date: Wed Oct 7 05:42:34 2009 Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on FreeBSD In-Reply-To: References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Message-ID: <6E3505F9-C73D-480A-9304-890BF153983E@mac.com> Hi, Robert-- On Oct 6, 2009, at 1:29 PM, Robert N. M. Watson wrote: >> While the main benefit of blocks is in conjunction with libdispatch >> for userland apps, they can be used by themselves, in the kernel or >> elsewhere. > > When a block is instantiated (perhaps not the formal terminology), > the blocks runtime allocates memory to hold copies of relevant > variables from the calling scope. This memory allocation may present > an issue in some calling contexts in the kernel -- in particular, it > won't be appropriate in contexts were non-sleepable locks are held, > interrupt threads, etc. While it should be possible to use the > primitive in the kernel, we may want to think carefully about these > implications. Also, blocks are currently specific to clang, although > with any luck gcc will grow them also. Yes, you bring up some good points. Blocks haven't been around for long enough to have a widely visible track record as to their benefits and tradeoffs, and the compiler toolchain support is not too widely present, either. While I am confident that blocks could be used in the kernel (and so answered the question which Hans asked), whether the FreeBSD kernel should attempt to use them (much less right away) is more complex topic. Apple's changes to gcc-4.2 to add support for blocks is likely to be available here: http://opensource.apple.com/source/gcc/gcc-5646, or perhaps nearby in a sibling directory [1]. Blocks are normally allocated on the stack, unless you decide to copy them to the heap [2]. If do you need to put a block onto the heap, you shouldn't try to do so in a situation where you aren't OK to call malloc(9) or whatever Block_copy() would use. On the other hand, it's entirely possible that using blocks and dispatch queues would help identify and/ or resolve some of hard-to-reproduce race condition bugs or even deadlocks lurking in the depths of recursive locking/lock-order reversals. To address the other point made by Steve and Roman; the proposed C++0x lambda syntax using [] brackets conflicts with existing code written in ObjC++, so that is likely going to be a non-starter for some folks. Also, the ^ operator can't be overloaded in C++, whereas you can overload the array access operator (aka []). Regards, -- -Chuck [1]: There are a bunch of test cases under http://opensource.apple.com/source/gcc/gcc-5646/gcc/testsuite/gcc.apple/block-* , so I think I've found the right place. :-) [2]: Such as when you are returning a block, or you have a __block variable which itself is a block, or you are using C++ or ObjC and have GC or some sort of reference counting in use, as discussed here: http://clang.llvm.org/docs/BlockLanguageSpec.txt or here: http://thirdcog.eu/pwcblocks/ From ianf at clue.co.za Wed Oct 7 06:00:48 2009 From: ianf at clue.co.za (Ian Freislich) Date: Wed Oct 7 06:00:56 2009 Subject: alc(4) link autoselect problem Message-ID: Hi On my recently acquired netbook (compaq mini-110), the ethernet doesn't autoselect the link speed properly. I think this is because HP chose the cheapest ethernet controler and the cheapest PHY and there's a speed missmatch (or the PHY isn't correctly detected): alc0: port 0xec80-0xecff mem 0xfebc0000-0xfebfffff irq 17 at device 0.0 on pci2 alc0: 15872 Tx FIFO, 15360 Rx FIFO alc0: Using 1 MSI message(s). miibus0: on alc0 atphy0: PHY 0 on miibus0 atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto alc0: Ethernet address: 00:25:b3:6f:ab:9a alc0: [FILTER] alc0@pci0:2:0:0: class=0x020000 card=0x308f103c chip=0x10621969 rev=0xc0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[48] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[58] = PCI-Express 1 endpoint max data 128(4096) link x1(x1) cap 03[6c] = VPD The AR8132 is Fast Ethernet, but the Atheros F1 is gigabit capable. If I set the media to 100BaseTX full-duplex it works. Ian -- Ian Freislich From bofh at redwerk.com Wed Oct 7 07:31:27 2009 From: bofh at redwerk.com (Eugene Dzhurinsky) Date: Wed Oct 7 07:31:34 2009 Subject: FreeBSD 8.0 RC1 does not recognize dvd rw controller when enhanced IDE mode is used Message-ID: <20091007073120.GA11667@office.redwerk.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091007/4f2ed939/attachment.pgp From hselasky at freebsd.org Wed Oct 7 08:45:17 2009 From: hselasky at freebsd.org (Hans Petter Selasky) Date: Wed Oct 7 08:45:29 2009 Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f In-Reply-To: <20091006204152.GA37998@freebsd.org> References: <20091006204152.GA37998@freebsd.org> Message-ID: <200910071046.01595.hselasky@freebsd.org> On Tuesday 06 October 2009 22:41:52 Roman Divacky wrote: > On Tue, Oct 06, 2009 at 09:29:50PM +0100, Robert N. M. Watson wrote: > > On 6 Oct 2009, at 19:50, Chuck Swiger wrote: > > >Hi, Hans-- > > > > > >On Oct 2, 2009, at 5:40 AM, Hans Petter Selasky wrote: > > >>Can the Apple's "Blocks" C language extension be used when > > >>programming in the kernel? Or is this a user-space only feature? > > > > > >While the main benefit of blocks is in conjunction with libdispatch > > >for userland apps, they can be used by themselves, in the kernel or > > >elsewhere. > > > > When a block is instantiated (perhaps not the formal terminology), the > > blocks runtime allocates memory to hold copies of relevant variables > > from the calling scope. This memory allocation may present an issue in > > some calling contexts in the kernel Hi Robert, I would argue that it is highly desirable to be able to pre-allocate memory for the given "callbacks" [here: Apple's "Blocks"]. Apple's "Blocks" reminds me of the USB stack's "msignal" system. "msignal" associates a piece of code with some data structure, and executes it for callback. Memory allocation is always a challenge. To allocate memory on the fly can also be a performance issue, and not at least make problems for realtime systems. I would suggest that the language is extended so that the elements that gets allocated are in the form of a structure. Example pseudo code: struct async_callback_001 { struct libdispatch_data xxx; int x; int y; }; void my_func(int x, int y) { static struct queue pq; static struct async_callback_001 data; init_queue(&pq); queue(&pq, &data, ^{ block of code which can only access parent fields that are given through the "data" structure. }); } Also there should be the possibility to lock the queue and test if an instance of a Apple Block has been queued for execution, because it is not just about paralell execution, but also about being able to drain/stop a system without polling. I admit I haven't looked too closely at the Apple Block's system yet, so maybe some of the features I'm asking for are already present. > > -- in particular, it won't be > > appropriate in contexts were non-sleepable locks are held, interrupt > > threads, etc. While it should be possible to use the primitive in the > > kernel, we may want to think carefully about these implications. Maybe that suggests that malloc() is the wrong way forward for keeping the temporary variable storage. Like I state in my example above, maybe the temporary variable storage should be separated out, so that for instance in a critical context, pre-allocated or static memory can be used instead?! > > Also, > > blocks are currently specific to clang, although with any luck gcc > > will grow them also. --HPS From 000.fbsd at quip.cz Wed Oct 7 09:35:48 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Wed Oct 7 09:36:01 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACBF147.1030002@tomjudge.com> References: <4ACA0549.7030404@tomjudge.com> <4ACBF147.1030002@tomjudge.com> Message-ID: <4ACC60EF.50104@quip.cz> Tom Judge wrote: > So I have worked up some thing usable fore us based on the 7.0 code from > the wiki. > > This patch is for 7.1 in implements both soft and hard memory limits. > > Details are here: > http://www.tomjudge.com/index.php/FreeBSD/Jails/MemoryLimits > > Changes that add supporting infrastructure for cpu limiting are in the > patch but changes to the schedulers have not been included. If you need > the scheduling support you will need to patch sched_4bsd with the code > from the original patch set here: > > http://lists.freebsd.org/pipermail/freebsd-jail/2008-June/000333.html > > Hope this is useful for some people. I added links to this thread and to your patch into wiki page http://wiki.freebsd.org/Jails. I hope it will help people to find your work. Do you plan to make it for 7.2 and other future releases? Miroslav Lachman From ianf at clue.co.za Wed Oct 7 10:43:36 2009 From: ianf at clue.co.za (Ian FREISLICH) Date: Wed Oct 7 10:43:45 2009 Subject: alc(4) link handling [was: Re: ath(4) Atheros AR9285 support] In-Reply-To: <20090914173805.GB1155@michelle.cdnetworks.com> References: <20090914173805.GB1155@michelle.cdnetworks.com> <4AA65ABE.4000207@lazybytes.org> <4AA668E0.1010305@FreeBSD.org> <4AA6ACF1.3040501@lazybytes.org> <20090908204520.GC1520@michelle.cdnetworks.com> <20090913202710.21762fa7@lazybytes.org> Message-ID: Pyun YongHyeon wrote: > Hmm, AR8132 uses F1 gigabit PHY but Atheros changed its internal > circuit such that it operates as 10/100 PHY. I guess it's more > appropriate to disable advertisement of 1000baseT capability for > AR8132 case. Would you try attached patch? I've tried this patch (actually committed) but my adapter which uses the same chip/phy doesn't auto negotiate when plugged into a gigabit port on my switch. Ian -- Ian Freislich From ray at dlink.ua Wed Oct 7 09:15:36 2009 From: ray at dlink.ua (Alexandr Rybalko) Date: Wed Oct 7 11:37:02 2009 Subject: [ARM+NFS] panic while copying across NFS In-Reply-To: <9BAB53FC-022B-4AA8-B29A-4B7428B5CC74@mac.com> References: <9BAB53FC-022B-4AA8-B29A-4B7428B5CC74@mac.com> Message-ID: <20091007114612.00408f53.ray@dlink.ua> Hi All! Testing on Orion like board (D-Link DNS-323) I get same result, panic on copy file across NFS. panic: vm_page_insert: offset already allocated backtrace - same. On Fri, 12 Jun 2009 13:19:22 -0700 Marcel Moolenaar wrote: >> I just ran into the following panic: >> >> panic: vm_page_insert: offset already allocated >> >> I was copying a kernel across NFS at the time: >> >> orion% cd /nfs/netboot/arm >> orion% ls >> kernel-save.bin kernel.bin ubldr >> orion% sudo cp kernel.bin kernel-save.bin >> orion% sudo cp /usr/obj/nfs/freebsd/base/head/sys/ORION/kernel.bin >> kernel.bin >> >> (/usr/obj is on a local disk) >> >> With this backtrace: >> >> db> bt >> Tracing pid 26585 tid 100073 td 0xc22bd6f0 >> db_trace_thread() at db_trace_thread+0x10 >> scp=0xc0ae66e8 rlv=0xc0914d78 (db_command_init+0x484) >> rsp=0xc8492878 rfp=0xc8492898 >> r10=0x00000001 r9=0xc0bb3e94 >> r8=0xc0babdc8 r7=0xc0bab59c r6=0x00000010 r5=0x00000000 >> r4=0xc22bd6f0 >> db_command_init() at db_command_init+0x404 >> scp=0xc0914cf8 rlv=0xc09145b4 (db_skip_to_eol+0x38c) >> rsp=0xc849289c rfp=0xc8492940 >> r6=0x00000002 r5=0x00000000 >> r4=0xc0b8bb80 >> db_skip_to_eol() at db_skip_to_eol+0x1d0 >> scp=0xc09143f8 rlv=0xc09147d0 (db_command_loop+0x50) >> rsp=0xc8492944 rfp=0xc8492954 >> r10=0x00000001 r8=0x00000000 >> r7=0xc8492b1c r6=0xc0bb3e90 r5=0x00000000 r4=0xc0bab598 >> db_command_loop() at db_command_loop+0x18 >> scp=0xc0914798 rlv=0xc0916960 (X_db_sym_numargs+0xa0) >> rsp=0xc8492958 rfp=0xc8492a74 >> r4=0xc849295c >> X_db_sym_numargs() at X_db_sym_numargs+0x18 >> scp=0xc09168d8 rlv=0xc09bcb98 (kdb_trap+0xb0) >> rsp=0xc8492a78 rfp=0xc8492aa0 >> r4=0x000000c0 >> kdb_trap() at kdb_trap+0x10 >> scp=0xc09bcaf8 rlv=0xc0af76cc (undefinedinstruction+0x124) >> rsp=0xc8492aa4 rfp=0xc8492b18 >> r10=0xc22bd6f0 r9=0x00000000 >> r8=0xc09bc88c r7=0xe7ffffff r6=0xc8492b1c r5=0x00000000 >> r4=0x00000000 >> undefinedinstruction() at undefinedinstruction+0x10 >> scp=0xc0af75b8 rlv=0xc0ae8174 (address_exception_entry+0x50) >> rsp=0xc8492b1c rfp=0xc8492b7c >> r10=0xc0d147c8 r8=0x00000000 >> r7=0xc22bd6f0 r6=0xc0bb00c0 r5=0xffff1004 r4=0x00000000 >> kdb_enter() at kdb_enter+0x14 >> scp=0xc09bc858 rlv=0xc09955f4 (panic+0xa0) >> rsp=0xc8492b80 rfp=0xc8492b94 >> r5=0xc0b4c994 r4=0x00000100 >> panic() at panic+0x1c >> scp=0xc0995570 rlv=0xc0ad8de0 (vm_page_insert+0x164) >> rsp=0xc8492ba8 rfp=0xc8492bc8 >> vm_page_insert() at vm_page_insert+0x10 >> scp=0xc0ad8c8c rlv=0xc0ad90f4 (vm_page_alloc+0x304) >> rsp=0xc8492bcc rfp=0xc8492bf4 >> r8=0x00001e03 r7=0x00000061 >> r6=0x00000001 r5=0xc0fe25c8 r4=0x00000000 >> vm_page_alloc() at vm_page_alloc+0x10 >> scp=0xc0ad8e00 rlv=0xc0acd740 (kmem_malloc+0x2b4) >> rsp=0xc8492bf8 rfp=0xc8492c48 >> r10=0x00000000 r9=0x00001000 >> r8=0x00000103 r7=0xc0e3a088 r6=0x01e03000 r5=0x00000061 >> r4=0xc1e03000 >> kmem_malloc() at kmem_malloc+0x14 >> scp=0xc0acd4a0 rlv=0xc0ac77bc (uma_zcreate+0xd0) >> rsp=0xc8492c4c rfp=0xc8492c88 >> r10=0xc0ac5efc r9=0xc0e36640 >> r8=0x00000103 r7=0xc1dfd000 r6=0xc1dfd000 r5=0x00000003 >> r4=0xc0e2d280 >> uma_zcreate() at uma_zcreate+0x70 >> scp=0xc0ac775c rlv=0xc0ac7d28 (uma_prealloc+0x198) >> rsp=0xc8492c8c rfp=0xc8492cac >> r10=0xc0e319d8 r9=0x00000020 >> r8=0xc0e36640 r7=0x00000000 r6=0xc0e36640 r5=0x00000203 >> r4=0xc0e2d280 >> uma_prealloc() at uma_prealloc+0xd4 >> scp=0xc0ac7c64 rlv=0xc0ac7fe8 (uma_prealloc+0x458) >> rsp=0xc8492cb0 rfp=0xc8492cc8 >> r7=0x00000002 r6=0xc0e36640 >> r5=0x00000003 r4=0xc0e2d280 >> uma_prealloc() at uma_prealloc+0x42c >> scp=0xc0ac7fbc rlv=0xc0ac9230 (uma_zalloc_arg+0x32c) >> rsp=0xc8492ccc rfp=0xc8492d10 >> r6=0xc1a5dcc0 r5=0x00000013 >> r4=0x00000013 >> uma_zalloc_arg() at uma_zalloc_arg+0x10 >> scp=0xc0ac8f14 rlv=0xc0a86710 (nfsm_uiotombuf+0xec) >> rsp=0xc8492d14 rfp=0xc8492d5c >> r10=0xc4bc0fcc r9=0x00008000 >> r8=0x00006034 r7=0xc8492df4 r6=0xc1976800 r5=0x00000800 >> r4=0x00000000 >> nfsm_uiotombuf() at nfsm_uiotombuf+0x10 >> scp=0xc0a86634 rlv=0xc0a8e8f4 (nfs_writerpc+0x1a8) >> rsp=0xc8492d60 rfp=0xc8492ddc >> r10=0xc3884910 r9=0x00008000 >> r8=0xc1acb000 r7=0x00008000 r6=0xc8492df4 r5=0xc1979900 >> r4=0x00000000 >> nfs_writerpc() at nfs_writerpc+0x10 >> scp=0xc0a8e75c rlv=0xc0a7f680 (nfs_doio+0x204) >> rsp=0xc8492de0 rfp=0xc8492e4c >> r10=0xc3884910 r9=0xc235cca8 >> r8=0x00008000 r7=0x00000000 r6=0x00000000 r5=0x000000c0 >> r4=0x00000000 >> nfs_doio() at nfs_doio+0x10 >> scp=0xc0a7f48c rlv=0xc0a871d8 (nfs_nfsiodnew+0x3c4) >> rsp=0xc8492e50 rfp=0xc8492e80 >> r10=0x00000000 r9=0xc0d13ab4 >> r8=0xc0d13990 r7=0x00000006 r6=0x00000000 r5=0xc1acb000 >> r4=0xc3884910 >> nfs_nfsiodnew() at nfs_nfsiodnew+0x2ac >> scp=0xc0a870c0 rlv=0xc0974b84 (fork_exit+0x64) >> rsp=0xc8492e84 rfp=0xc8492ea8 >> r10=0xc0a870b0 r9=0xc0d1f6c0 >> r8=0xc0d13368 r7=0xc1c6a828 r6=0xc8492eac r5=0xc0d1f6c0 >> r4=0xc22bd6f0 >> fork_exit() at fork_exit+0x10 >> scp=0xc0974b30 rlv=0xc0af6190 (fork_trampoline+0x14) >> rsp=0xc8492eac rfp=0x00000000 >> r10=0xc0d1f6c0 r8=0x00000104 >> r7=0xc0ae7f4c r6=0xc8492eac r5=0xc0d13368 r4=0xc0a870b0 >> >> >> FYI, >> >> -- >> Marcel Moolenaar >> xcllnt@mac.com >> >> >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- Alexandr Rybalko From kostjn at peterhost.ru Wed Oct 7 10:30:58 2009 From: kostjn at peterhost.ru (Menshikov Konstantin) Date: Wed Oct 7 11:37:14 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACC60EF.50104@quip.cz> References: <4ACA0549.7030404@tomjudge.com> <4ACBF147.1030002@tomjudge.com> <4ACC60EF.50104@quip.cz> Message-ID: <4ACC6C01.80106@peterhost.ru> Miroslav Lachman wrote: > Tom Judge wrote: > >> So I have worked up some thing usable fore us based on the 7.0 code >> from the wiki. >> >> This patch is for 7.1 in implements both soft and hard memory limits. >> >> Details are here: >> http://www.tomjudge.com/index.php/FreeBSD/Jails/MemoryLimits >> >> Changes that add supporting infrastructure for cpu limiting are in >> the patch but changes to the schedulers have not been included. If >> you need the scheduling support you will need to patch sched_4bsd >> with the code from the original patch set here: >> >> http://lists.freebsd.org/pipermail/freebsd-jail/2008-June/000333.html >> >> Hope this is useful for some people. > > I added links to this thread and to your patch into wiki page > http://wiki.freebsd.org/Jails. I hope it will help people to find your > work. > Do you plan to make it for 7.2 and other future releases? > > Miroslav Lachman > _______________________________________________ > freebsd-jail@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-jail > To unsubscribe, send any mail to "freebsd-jail-unsubscribe@freebsd.org" > It is good that people work in this direction! At present there are some patches, however any of them is not finished. I suggest to discuss in details a problem. The most important questions. 1. It is necessary to limit what resources? 2. How resources should be limited? Soft and hard limits. 3. How to count memory occupied with group of processes? 4. How to limit memory use? Whether correctly to kill processes? 5. How to limit use of processor time at absence in ULE separate turns of performance for jails? 6. Whether limits should be inherited at creation jails? etc. -- Menshikov Konstantin From ggajic at afrodita.rcub.bg.ac.rs Wed Oct 7 10:44:31 2009 From: ggajic at afrodita.rcub.bg.ac.rs (Goran Gajic) Date: Wed Oct 7 11:37:23 2009 Subject: cdrom and freebsd 8.0-rc1 Message-ID: Hi, This is quite strange, but this is what I'm getting: gbsd# mount /cdrom gbsd# ls -al /cdrom/ total 687895 dr-xr-xr-x 2 root wheel 2048 Oct 7 11:02 . drwxr-xr-x 25 root wheel 1024 Oct 7 11:30 .. -rw-rw-r-- 1 ggajic black 704400540 Oct 7 02:04 2.avi gbsd# umount /cdrom gbsd# mount /cdrom info: [drm] Loading R300 Microcode info: [drm] Num pipes: 4 g_vfs_done():acd0[READ(offset=32768, length=2048)]error = 5 mount_cd9660: /dev/acd0: Input/output error gbsd# mount /cdrom Until I reboot computer I can't mount cdrom back.. FreeBSD gbsd.interex-pla.net 8.0-RC1 FreeBSD 8.0-RC1 #0 r197801M: Tue Oct 6 10:32:11 CEST 2009 root@gbsd.interex-pla.net:/usr/src/sys/i386/compile/GENERIC i386 regards, gg. From ggajic at afrodita.rcub.bg.ac.rs Wed Oct 7 11:21:44 2009 From: ggajic at afrodita.rcub.bg.ac.rs (Goran Gajic) Date: Wed Oct 7 11:37:34 2009 Subject: cdrom and freebsd 8.0-rc1 In-Reply-To: References: Message-ID: I forgot to mention that this happens after usage of burncd utility. However, after few minutes problem goes away. I have tried this with several cds and it is always happening. gg. On Wed, 7 Oct 2009, Goran Gajic wrote: > > > Hi, > > This is quite strange, but this is what I'm getting: > > gbsd# mount /cdrom > gbsd# ls -al /cdrom/ > total 687895 > dr-xr-xr-x 2 root wheel 2048 Oct 7 11:02 . > drwxr-xr-x 25 root wheel 1024 Oct 7 11:30 .. > -rw-rw-r-- 1 ggajic black 704400540 Oct 7 02:04 2.avi > gbsd# umount /cdrom > gbsd# mount /cdrom > info: [drm] Loading R300 Microcode > info: [drm] Num pipes: 4 > g_vfs_done():acd0[READ(offset=32768, length=2048)]error = 5 > mount_cd9660: /dev/acd0: Input/output error > gbsd# mount /cdrom > > Until I reboot computer I can't mount cdrom back.. > FreeBSD gbsd.interex-pla.net 8.0-RC1 FreeBSD 8.0-RC1 #0 r197801M: Tue Oct 6 > 10:32:11 CEST 2009 > root@gbsd.interex-pla.net:/usr/src/sys/i386/compile/GENERIC i386 > > regards, > gg. > From bofh at redwerk.com Wed Oct 7 11:53:38 2009 From: bofh at redwerk.com (Eugene Dzhurinsky) Date: Wed Oct 7 11:53:45 2009 Subject: FreeBSD 8.0 RC1 does not recognize dvd rw controller when enhanced IDE mode is used In-Reply-To: <20091007073120.GA11667@office.redwerk.com> References: <20091007073120.GA11667@office.redwerk.com> Message-ID: <20091007115333.GA81330@office.redwerk.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091007/77298f41/attachment.pgp From ianf at clue.co.za Wed Oct 7 12:23:16 2009 From: ianf at clue.co.za (Ian Freislich) Date: Wed Oct 7 12:23:22 2009 Subject: urtw(4) feedback. Message-ID: Hi FWIW, the manual can be updated to include support for the Linksys WG111v3 adapter. Mine detects as follows: ugen4.3: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON urtw0: on usbus4 urtw0: rtl8187b rf rtl8225z2 hwrev e Opening it up confirms the presence of a RTL8187B. However throughput is very poor, I haven't been able to get more than about 130kB/s and pings seem to be timed every 1.5 seconds. Ian -- Ian Freislich From swehack at gmail.com Wed Oct 7 13:03:06 2009 From: swehack at gmail.com (nocturnal) Date: Wed Oct 7 13:03:13 2009 Subject: Updating FreeBSD 7.0-RELEASE i386 to 7.2 amd64? In-Reply-To: <20091006221719.GA5942@alucard.int.rhavenn.net> References: <9aed80930910051249ocfcf946o2341c653d16b8e24@mail.gmail.com> <20091006221719.GA5942@alucard.int.rhavenn.net> Message-ID: <9aed80930910070602o76ac20f4u900098f1d0c32080@mail.gmail.com> Thanks for the pointers Henrik. I have decided that you are right, it's too much of a headache. I would rather just re-install and restore backups. 2009/10/7 Henrik Hudson > On Mon, 05 Oct 2009, nocturnal wrote: > > > Can it be done with a simple cvs or binary update of FreeBSD or must i > > re-install using some media? > > > > If i kept my /usr partition intact and just overwrote the important stuff > > with new files from the CD it wouldn't be so bad with a re-install but it > > would be nice if large parts of it could be done remote. > > > > What is your suggestion for this? > > You will have to recompile all ports (/usr/local ) and any manually > installed apps due > to the changes in the system libs. Personally, it's not worth the > headache of trying to do a "upgrade" across architectures like this. > > Most of the items in /usr (outside of /usr/local) are part of the > base system and should update "okay", but I don't know if you will > be able to boot a x64 kernel into a x86 system, assuming you try a > reboot between make installkernel and make installworld . > > I don't think a binary upgrade would work at all, but I've never > actually done a binary upgrade. I always csup. > > On that note, I've never tried this, but I would recommend against it. > > Henrik > -- > Henrik Hudson > lists@rhavenn.net > ----------------------------------------- > "God, root, what is difference?" Pitr; UF > > -- Med v?nliga h?lsningar Stefan Midjich aka nocturnal [SWEHACK] http://swehack.se From ianf at clue.co.za Wed Oct 7 14:20:54 2009 From: ianf at clue.co.za (Ian FREISLICH) Date: Wed Oct 7 14:21:01 2009 Subject: urtw(4) feedback. In-Reply-To: References: Message-ID: "Ian Freislich" wrote: > Hi > > FWIW, the manual can be updated to include support for the Linksys > WG111v3 adapter. Mine detects as follows: Umm. typo. That should be "Netgear WG111v3" Ian -- Ian Freislich From ianf at clue.co.za Wed Oct 7 15:11:05 2009 From: ianf at clue.co.za (Ian FREISLICH) Date: Wed Oct 7 15:11:12 2009 Subject: urtw(4) feedback. In-Reply-To: References: Message-ID: Rui Paulo wrote: > On 7 Oct 2009, at 13:23, Ian Freislich wrote: > > urtw0: rtl8187b rf rtl8225z2 hwrev e > > > > Opening it up confirms the presence of a RTL8187B. > > > > However throughput is very poor, I haven't been able to get more > > than about 130kB/s and pings seem to be timed every 1.5 seconds. > > > > This might help: > http://p4db.freebsd.org/chv.cgi?CH=169276 Not significantly. The stability of the wireless association is improved throughput is nearly doubled to 240kB/s, but there's some wierdness: it responds to ping from "outside" almost immediately, but when the host pings out, it spaces requests at about 1.6 seconds (which it doesn't do on the alc0 interface). [mini] /usr/src/sys/modules/usb/urtw # time ping -c2 10.0.2.1 PING 10.0.2.1 (10.0.2.1): 56 data bytes 64 bytes from 10.0.2.1: icmp_seq=0 ttl=64 time=36.176 ms 64 bytes from 10.0.2.1: icmp_seq=1 ttl=64 time=44.282 ms --- 10.0.2.1 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 36.176/40.229/44.282/4.053 ms real 0m1.696s user 0m0.000s sys 0m0.001s It also takes about 10 seconds for the wlan0 interface to appear after insertion. Ian -- Ian Freislich From rpaulo at gmail.com Wed Oct 7 14:46:20 2009 From: rpaulo at gmail.com (Rui Paulo) Date: Wed Oct 7 15:55:56 2009 Subject: urtw(4) feedback. In-Reply-To: References: Message-ID: On 7 Oct 2009, at 13:23, Ian Freislich wrote: > Hi > > FWIW, the manual can be updated to include support for the Linksys > WG111v3 adapter. Mine detects as follows: > > ugen4.3: at usbus4, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=ON > > urtw0: 3> on usbus4 > urtw0: rtl8187b rf rtl8225z2 hwrev e > > Opening it up confirms the presence of a RTL8187B. > > However throughput is very poor, I haven't been able to get more > than about 130kB/s and pings seem to be timed every 1.5 seconds. > This might help: http://p4db.freebsd.org/chv.cgi?CH=169276 -- Rui Paulo From hselasky at c2i.net Wed Oct 7 16:04:23 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Oct 7 16:04:30 2009 Subject: urtw(4) feedback. In-Reply-To: References: Message-ID: <200910071805.09153.hselasky@c2i.net> On Wednesday 07 October 2009 17:10:58 Ian FREISLICH wrote: > Rui Paulo wrote: > > On 7 Oct 2009, at 13:23, Ian Freislich wrote: > > > urtw0: rtl8187b rf rtl8225z2 hwrev e > > > > > > Opening it up confirms the presence of a RTL8187B. > > > > > > However throughput is very poor, I haven't been able to get more > > > than about 130kB/s and pings seem to be timed every 1.5 seconds. > > > > This might help: > > http://p4db.freebsd.org/chv.cgi?CH=169276 > > Not significantly. The stability of the wireless association is > improved throughput is nearly doubled to 240kB/s, but there's some > wierdness: it responds to ping from "outside" almost immediately, > but when the host pings out, it spaces requests at about 1.6 seconds > (which it doesn't do on the alc0 interface). > > [mini] /usr/src/sys/modules/usb/urtw # time ping -c2 10.0.2.1 > PING 10.0.2.1 (10.0.2.1): 56 data bytes > 64 bytes from 10.0.2.1: icmp_seq=0 ttl=64 time=36.176 ms > 64 bytes from 10.0.2.1: icmp_seq=1 ttl=64 time=44.282 ms > > --- 10.0.2.1 ping statistics --- > 2 packets transmitted, 2 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 36.176/40.229/44.282/4.053 ms > > real 0m1.696s > user 0m0.000s > sys 0m0.001s > > It also takes about 10 seconds for the wlan0 interface to appear > after insertion. And if you use "ping -f" ? Could it be that it is only the last packet sent that is not flushed out? --HPS From schmidt_chr at gmx.net Wed Oct 7 17:36:35 2009 From: schmidt_chr at gmx.net (Christian Schmidt) Date: Wed Oct 7 17:36:41 2009 Subject: Boot issues with a Dell Inspiron 530 and 8.0 RC1 In-Reply-To: <1254842240.23831.22.camel@buffy.york.ac.uk> References: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> <1254842240.23831.22.camel@buffy.york.ac.uk> Message-ID: <309b65830910071036h77276ee2jb2a9c7e82fe7ba9d@mail.gmail.com> On Tue, Oct 6, 2009 at 17:17, Gavin Atkinson wrote: > On Tue, 2009-10-06 at 09:54 +0200, Christian Schmidt wrote: >> Hello list, >> >> I am seeing a strange issue with my Dell Inspiron 530 with 8.0 RC1-p1 >> at around 50-75% percent of all boots. It all boils down to GENERIC >> throwing the following: >> >> AP #1 (PHY #1) failed! >> panic y/n? [y] panic: bye-bye >> cpuid = 0 [...] > There are a couple of things that might be worth trying. ?Firstly, try > playing with any USB-related options in the BIOS (especially "legacy > emulation" or similar. Okay, I had a look at that one but the BIOS does not feature a lot of options concerning USB. There was nothing about legacy emulation or anything remotely similar, so that was a dead-end. > Secondly, try editing src/sys/amd64/amd64/machdep.c > (or /sys/i386/i386/machdep.c if you are using i386), search for > "MacBook", and adding the output of the command > "kenv smbios.system.product" > to the list of strings compared. I tried that (with the help of some of the kind people from bsdforen.de ;-)) but that didn't fix the issue at all. Rebooting resulted in panic. Oddly enough, a complete poweroff and reboot from the old kernel worked well enough. Like I said: a cold-boot increases the chances significantly while a reboot is almost always bound to fail. > This may not make any difference, or may even make things worse (so keep > your backup kernel ready:) but it's worth a try. Well, it didn't immolate my machine so I'm fine. ;-) Thanks, Christian -- Todays mistakes are tomorrows catastrophes. From gleb.kurtsou at gmail.com Wed Oct 7 17:37:17 2009 From: gleb.kurtsou at gmail.com (Gleb Kurtsou) Date: Wed Oct 7 17:37:25 2009 Subject: ZFS-related panic, 8.0-RC1 In-Reply-To: <4ACBD4CA.3070300@haruhiism.net> References: <4ACBD4CA.3070300@haruhiism.net> Message-ID: <20091007173655.GA11144@tops> On (07/10/2009 03:37), Kamigishi Rei wrote: > Hello, hope you're having a nice day, > > Alas, this time I didn't manage to get a dump, so only the panic message > is available: > panic: _sx_xlock_hard: recursed on non-recursive sx > zfsvfs->z_hold_mtx[i] @ > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1023 Do you run nullfs on top of zfs by any chance? I've seen something similar. It was caused by zfs -> getnewvnode -> zfs_inactive But information provided is not enough for debugging. Can you get full backtrace? > > -- > Kamigishi Rei > KREI-RIPE > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From pyunyh at gmail.com Wed Oct 7 18:04:18 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Oct 7 18:04:25 2009 Subject: alc(4) link autoselect problem In-Reply-To: References: Message-ID: <20091007180257.GA3843@michelle.cdnetworks.com> On Wed, Oct 07, 2009 at 08:00:42AM +0200, Ian Freislich wrote: > Hi > > On my recently acquired netbook (compaq mini-110), the ethernet > doesn't autoselect the link speed properly. I think this is because > HP chose the cheapest ethernet controler and the cheapest PHY and Don't know it's cheapest controller but alc(4) hardwares would be better than ale(4) hardwares. Due to lack of documentation I'm not sure but alc(4) seems to have a header split feature which I don't know how to enable the feature. > there's a speed missmatch (or the PHY isn't correctly detected): > > alc0: port 0xec80-0xecff mem 0xfebc0000-0xfebfffff irq 17 at device 0.0 on pci2 > alc0: 15872 Tx FIFO, 15360 Rx FIFO > alc0: Using 1 MSI message(s). > miibus0: on alc0 > atphy0: PHY 0 on miibus0 > atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > alc0: Ethernet address: 00:25:b3:6f:ab:9a > alc0: [FILTER] > > alc0@pci0:2:0:0: class=0x020000 card=0x308f103c chip=0x10621969 rev=0xc0 hdr=0x00 > vendor = 'Attansic (Now owned by Atheros)' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D3 current D0 > cap 05[48] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[58] = PCI-Express 1 endpoint max data 128(4096) link x1(x1) > cap 03[6c] = VPD > > The AR8132 is Fast Ethernet, but the Atheros F1 is gigabit capable. The atphy(4) recognizes PHY as F1 gigabit PHY because AR8132 uses the same PHY id of F1 gigabit PHY. There is no way to know whether it really has F1 gigabit PHY in driver's view. > If I set the media to 100BaseTX full-duplex it works. If link parter used auto-negotiation, this forced media selection shall make your link partner select half-duplex mode instead of full-duplex due to the nature of parallel detection. > I couldn't see link establishment issues on AR8132 sample board. Does link partner also see no link when you use auto-negotiation on alc(4)? Does your link partner support 1000baseT link? Can you see blinking LED of AR8132 when link was not established? How about unplugging UTP cable and then replug the cable after a couple of seconds? Does it make any difference? How about checking MIB statistics of controller? (sysctl dev.alc.0.stats) From ianf at clue.co.za Wed Oct 7 18:05:33 2009 From: ianf at clue.co.za (Ian FREISLICH) Date: Wed Oct 7 18:05:40 2009 Subject: urtw(4) feedback. In-Reply-To: <200910071805.09153.hselasky@c2i.net> References: <200910071805.09153.hselasky@c2i.net> Message-ID: Hans Petter Selasky wrote: > On Wednesday 07 October 2009 17:10:58 Ian FREISLICH wrote: > > [mini] /usr/src/sys/modules/usb/urtw # time ping -c2 10.0.2.1 > > PING 10.0.2.1 (10.0.2.1): 56 data bytes > > 64 bytes from 10.0.2.1: icmp_seq=0 ttl=64 time=36.176 ms > > 64 bytes from 10.0.2.1: icmp_seq=1 ttl=64 time=44.282 ms > > > > --- 10.0.2.1 ping statistics --- > > 2 packets transmitted, 2 packets received, 0.0% packet loss > > round-trip min/avg/max/stddev = 36.176/40.229/44.282/4.053 ms > > > > real 0m1.696s > > user 0m0.000s > > sys 0m0.001s > > > > It also takes about 10 seconds for the wlan0 interface to appear > > after insertion. > > And if you use "ping -f" ? > > Could it be that it is only the last packet sent that is not flushed out? [mini] /usr/src # time ping -f -c2 10.0.2.1 PING 10.0.2.1 (10.0.2.1): 56 data bytes . --- 10.0.2.1 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 9.752/9.934/10.115/0.182 ms real 0m0.024s user 0m0.008s sys 0m0.001s however, 200 results in packet loss: [mini] /usr/src # time ping -f -c200 10.0.2.1 PING 10.0.2.1 (10.0.2.1): 56 data bytes .............. --- 10.0.2.1 ping statistics --- 200 packets transmitted, 187 packets received, 6.5% packet loss round-trip min/avg/max/stddev = 3.782/10.161/15.065/2.029 ms real 0m3.866s user 0m0.000s sys 0m0.034s Ian -- Ian Freislich From spambox at haruhiism.net Wed Oct 7 18:07:23 2009 From: spambox at haruhiism.net (Kamigishi Rei) Date: Wed Oct 7 18:07:32 2009 Subject: ZFS-related panic, 8.0-RC1 In-Reply-To: <20091007173655.GA11144@tops> References: <4ACBD4CA.3070300@haruhiism.net> <20091007173655.GA11144@tops> Message-ID: <4ACCD8DC.1030403@haruhiism.net> On 07.10.2009 21:36, Gleb Kurtsou wrote: > panic: _sx_xlock_hard: recursed on non-recursive sx >> zfsvfs->z_hold_mtx[i] @ >> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c:1023 >> > Do you run nullfs on top of zfs by any chance? > Indeed. I'm using ezjail suite, and it uses nullfs to link jail subdirectories to the base structure. > I've seen something similar. It was caused by > zfs -> getnewvnode -> zfs_inactive > But information provided is not enough for debugging. Can you get full > backtrace? > I've disabled gmirror so next time I'll probably get the backtrace. Note that with 8.0-BETA3, the previous revision I ran, nothing happened through 39+ days uptime with the same ezjail-based structure. -- Kamigishi Rei KREI-RIPE From jhay at meraka.org.za Wed Oct 7 19:12:08 2009 From: jhay at meraka.org.za (John Hay) Date: Wed Oct 7 19:12:15 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration (was: Re: svn commit: r197145 - in head: etc/defaults share/man/man5) In-Reply-To: <20091005091708.J26486@maildrop.int.zabbadoz.net> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <20091005055806.GB58246@zibbi.meraka.csir.co.za> <20091005091708.J26486@maildrop.int.zabbadoz.net> Message-ID: <20091007191203.GA24065@zibbi.meraka.csir.co.za> Hi, Sorry I was away from keyboard for a few days. On Mon, Oct 05, 2009 at 09:25:18AM +0000, Bjoern A. Zeeb wrote: > On Mon, 5 Oct 2009, John Hay wrote: > > Hi, > > >On Mon, Oct 05, 2009 at 12:34:27PM +0900, Hiroki Sato wrote: > >>Hi, > >> > >> I would like your comments about merging the network_ipv6 -> netif > >> integration to stable/8. The issue of this rc.d script change is it > >> involves user-visible changes in rc.conf(5) variables as described in > >> UPDATING. > >> > >> I still want to do so before 8.0-R because the ND6 change in -CURRENT > >> needs updating IPv6-related rc.d scripts first. While the ND6 change > >> is not harmful from viewpoint of compatibility because basically it > >> just converts a global knob to a per-interface flag, handling it in > >> the rc.d scripts needs a kind of overhaul of rc.d/network_ipv6 and > >> rc.d/netif. > >> > >> The necessary changes have already been committed into -CURRENT. It > >> displays a warning to inform the users what is old in the rc.conf if > >> the user uses rc.d variables that have been changed, and at the same > >> time it keeps backward compatibility so that the old variables also > >> work. So, I think the impact is small enough, and this sort of > >> visible changes should be included in the .0 release rather than in > >> the middle of future 8.x releases. > >> > >> The patch for stable/8 can be found at: > >> > >> http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff > >> > >> This includes both of the ND6 kernel change and the rc.d script > >> change. If there is an objection from someone here I will put off > >> the merge until after 8.0-R. > > > >Is there a good reason why we still ship with ipv6 off by default? Most > >others seem to ship with ipv6 on. At least Windows, most linux flavours > >and Mac OS X which make out the rest of the machines on our network here > >at Meraka Institute. > > > >One thing that I have against the way the stuff in -current is done at > >the moment, is that it seems to be a lot more work to just get ipv6 to > >work. Either I did things wrong or we are taking a step backward. Make > >no mistake, I like the idea of being able to control it per interface, > >but it seems that you have to enable it per interface with a long string > >for each... I would rather that it is enabled everywhere by default and > >then you disbale it where you do not want it. > > > link-local had been enabled by default in the past and I am not sure > if we had a SA or EN for that or that it was just preemptively > disabled. > > The problem is that if it is enabled by default you are exposing > yourself to others on the same network. That is of course especially > bad if you are in untrusted environments like conferences, ... or on a > public LAN. For a while I hoped that we could return to the good old days, but I guess it is fear and terror nowadays. :-/ > If we'd support IPv4 link-local addresses by default we would have to > apply the same logic there. > > I am not sure about OSX but at least Windows has a firewall set to > deny any unrelated incoming things by default these days. Well depending on how narrow you look at it, we are not that far away from that. We have all network services off by default and if you install via sysinstall, you get a chance to enable the ones you want. :-) > > Just because others haven't yet (really) thought about the problems > doesn't mean they aren't there. > > If you want to use IPv4 you either add an address or start DHCP or .. > and you have to configure that. If you want IPv6, you configure that > as well. You shall not have anything enbaled by default that people > can use to attack you and you don't know about because you didn't > configure. > > While (we) IPv6 people know that it would be there a lot of people are > still totally unaware of IPv6 and they would be surprised. Ok I can understand why not have it totally enabled by default, but why not keep ipv6_enabled and let the user only have to add ipv6_enabled="YES" to his rc.conf and have the "normal" case of a client ipv6 box just work? Either on all interfaces or limited to maybe network_interfaces. After all, one of the aims of IPv6 was to make configuration easier for the "normal" client case. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From jamie at FreeBSD.org Wed Oct 7 20:08:47 2009 From: jamie at FreeBSD.org (Jamie Gritton) Date: Wed Oct 7 20:08:53 2009 Subject: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS related?) In-Reply-To: References: <4ABD4BB9.1030804@FreeBSD.org> Message-ID: <4ACCF548.2070200@FreeBSD.org> Rick Macklem wrote: > On Sun, 27 Sep 2009, Robert Watson wrote: >> On Fri, 25 Sep 2009, Jamie Gritton wrote: >> >>> It seems to be NFS related. I think the null pointer in question is >>> from the export's anonymous credential. Try the patch below and see >>> if it helps (which I guess means run it overnight and see if it >>> crashes again). I've also patched a similar missing cred prison in >>> GSS_SVC, since I'm not versed enough in NFS/RPC stuff to know if it >>> might be the problem. >> >> This is one of the reasons I really dislike "magic" credentials and >> special handling of NULL credentials -- they always get into code the >> author doesn't expect, and either there are bad pointer dereferences, >> or incorrect security decisions. It's almost always the case that a >> correct credential should have been cached or generated at some >> earlier point to represent the security context... >> > I don't really understand prisons/jails, but would creating these > credentials via: > crdup(td->td_ucred); // duplicating the daemon thread's cred > - and then replacing the > make sense as an alternative to starting with crget()? > (ie. All the other stuff except would be "inherited" from the > credential for the daemon thread.) That sounds right to me for cases when the cred is based on passed UID/GIDs. Perhaps you'd want to use the UID-changing helper functions on kern_prot.c, or perhaps a new helper or helpers just for the circumstance. - Jamie From jamie at FreeBSD.org Wed Oct 7 20:09:46 2009 From: jamie at FreeBSD.org (Jamie Gritton) Date: Wed Oct 7 20:09:53 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACBF2C2.4040004@tomjudge.com> References: <4ACA0549.7030404@tomjudge.com> <4ACA46D8.8010504@FreeBSD.org> <4ACBF2C2.4040004@tomjudge.com> Message-ID: <4ACCF583.9030004@FreeBSD.org> Tom Judge wrote: > Jamie Gritton wrote: >> Tom Judge wrote: >>> Does anyone know of a patch that will add per jail memory limits so >>> that a jail can't swallow the resources of the entire box? >> >> Edward Tomasz Napierala has been working on a general resource limit >> framework, including jails and memory limits. You can find it at: >> http://p4db.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/soc2009/trasz_limits >> >> >> - Jamie > Is this in the subversion projects tree? > > It seems the p4 is not very easy to access unless you have access server. Quite true - sorry I totally forgot that detail. Perhaps trasz has some tarballs or patches available. - Jamie From tom at tomjudge.com Wed Oct 7 20:49:31 2009 From: tom at tomjudge.com (Tom Judge) Date: Wed Oct 7 20:49:38 2009 Subject: Per Jail Memory Limits In-Reply-To: <4ACC60EF.50104@quip.cz> References: <4ACA0549.7030404@tomjudge.com> <4ACBF147.1030002@tomjudge.com> <4ACC60EF.50104@quip.cz> Message-ID: <4ACCFEB1.1010306@tomjudge.com> Miroslav Lachman wrote: > Tom Judge wrote: > >> So I have worked up some thing usable fore us based on the 7.0 code >> from the wiki. >> >> This patch is for 7.1 in implements both soft and hard memory limits. >> >> Details are here: >> http://www.tomjudge.com/index.php/FreeBSD/Jails/MemoryLimits >> >> Changes that add supporting infrastructure for cpu limiting are in >> the patch but changes to the schedulers have not been included. If >> you need the scheduling support you will need to patch sched_4bsd >> with the code from the original patch set here: >> >> http://lists.freebsd.org/pipermail/freebsd-jail/2008-June/000333.html >> >> Hope this is useful for some people. > > I added links to this thread and to your patch into wiki page > http://wiki.freebsd.org/Jails. I hope it will help people to find your > work. > Do you plan to make it for 7.2 and other future releases? Thanks for adding it to the wiki. It should be simple to apply to 7.2, I can try to knock out a patch in my spare time for this. However at this time I have no plans to take this any further, it seems plenty of people are working on this problem. Maybe one day there will be an in tree solution. Tom From ianf at clue.co.za Thu Oct 8 10:38:58 2009 From: ianf at clue.co.za (Ian FREISLICH) Date: Thu Oct 8 10:39:06 2009 Subject: alc(4) link autoselect problem In-Reply-To: <20091007180257.GA3843@michelle.cdnetworks.com> References: <20091007180257.GA3843@michelle.cdnetworks.com> Message-ID: Pyun YongHyeon wrote: > The atphy(4) recognizes PHY as F1 gigabit PHY because AR8132 uses > the same PHY id of F1 gigabit PHY. There is no way to know whether > it really has F1 gigabit PHY in driver's view. > > > If I set the media to 100BaseTX full-duplex it works. > > If link parter used auto-negotiation, this forced media selection > shall make your link partner select half-duplex mode instead of > full-duplex due to the nature of parallel detection. When I do this: [mini] /usr/home/ianf # ifconfig alc0 media 100BaseTX mediaopt full-duplex I get this on the switch: 08-Oct-2009 12:26:42 %STP-W-PORTSTATUS: g14 of instance 0: STP status Forwarding 08-Oct-2009 12:26:42 %STP-W-PORTSTATUS: g14 of instance 1: STP status Forwarding 08-Oct-2009 12:26:42 %STP-W-PORTSTATUS: g14 of instance 2: STP status Forwarding 08-Oct-2009 12:26:42 %LINK-I-Up: g14 wgsw-24010# sh interfaces status ethernet g14 Flow Link Back Mdix Port Type Duplex Speed Neg ctrl State Pressure Mode -------- ------------ ------ ----- -------- ---- ----------- -------- ------- g14 1G-Copper Full 100 Enabled Off Up Disabled Off So, it correctly detects full duplex. The cable tester still reports the cable os open at 2m, probably because it expects all 4 pairs to be terminated. > I couldn't see link establishment issues on AR8132 sample board. > Does link partner also see no link when you use auto-negotiation on > alc(4)? I get no link, not even temporary blips on the link light. When I invoke the cable tester, this is what I see: wgsw-24010# test copper-port tdr g14 .. Cable on port g14 is open at 2 m > Does your link partner support 1000baseT link? Yes, it does. > Can you see blinking LED of AR8132 when link was not established? No. > How about unplugging UTP cable and then replug the cable after > a couple of seconds? Does it make any difference? No difference either. > How about checking MIB statistics of controller? > (sysctl dev.alc.0.stats) This is after a reboot, but the link was up for a short while to do the above testing. rx.good_frames looks a bit high for "up 21 mins". dev.alc.0.stats.rx.good_frames: 3348588249 dev.alc.0.stats.rx.good_bcast_frames: 0 dev.alc.0.stats.rx.good_mcast_frames: 0 dev.alc.0.stats.rx.pause_frames: 0 dev.alc.0.stats.rx.control_frames: 0 dev.alc.0.stats.rx.crc_errs: 0 dev.alc.0.stats.rx.len_errs: 0 dev.alc.0.stats.rx.good_octets: 0 dev.alc.0.stats.rx.good_bcast_octets: 0 dev.alc.0.stats.rx.good_mcast_octets: 0 dev.alc.0.stats.rx.runts: 0 dev.alc.0.stats.rx.fragments: 0 dev.alc.0.stats.rx.frames_64: 13 dev.alc.0.stats.rx.frames_65_127: 5 dev.alc.0.stats.rx.frames_128_255: 181 dev.alc.0.stats.rx.frames_256_511: 2 dev.alc.0.stats.rx.frames_512_1023: 0 dev.alc.0.stats.rx.frames_1024_1518: 0 dev.alc.0.stats.rx.frames_1519_max: 0 dev.alc.0.stats.rx.trunc_errs: 0 dev.alc.0.stats.rx.fifo_oflows: 0 dev.alc.0.stats.rx.rrs_errs: 0 dev.alc.0.stats.rx.align_errs: 0 dev.alc.0.stats.rx.filtered: 201 dev.alc.0.stats.tx.good_frames: 0 dev.alc.0.stats.tx.good_bcast_frames: 0 dev.alc.0.stats.tx.good_mcast_frames: 0 dev.alc.0.stats.tx.pause_frames: 0 dev.alc.0.stats.tx.control_frames: 0 dev.alc.0.stats.tx.excess_defers: 0 dev.alc.0.stats.tx.defers: 0 dev.alc.0.stats.tx.good_octets: 0 dev.alc.0.stats.tx.good_bcast_octets: 0 dev.alc.0.stats.tx.good_mcast_octets: 0 dev.alc.0.stats.tx.frames_64: 0 dev.alc.0.stats.tx.frames_65_127: 0 dev.alc.0.stats.tx.frames_128_255: 0 dev.alc.0.stats.tx.frames_256_511: 0 dev.alc.0.stats.tx.frames_512_1023: 0 dev.alc.0.stats.tx.frames_1024_1518: 0 dev.alc.0.stats.tx.frames_1519_max: 0 dev.alc.0.stats.tx.single_colls: 0 dev.alc.0.stats.tx.multi_colls: 0 dev.alc.0.stats.tx.late_colls: 0 dev.alc.0.stats.tx.excess_colls: 0 dev.alc.0.stats.tx.abort: 0 dev.alc.0.stats.tx.underruns: 0 dev.alc.0.stats.tx.desc_underruns: 0 dev.alc.0.stats.tx.len_errs: 0 dev.alc.0.stats.tx.trunc_errs: 0 dev.alc.0.stats.rx.filtered is not climbing with outo-negotiate enabled. Ian -- Ian Freislich From ache at nagual.pp.ru Thu Oct 8 12:42:26 2009 From: ache at nagual.pp.ru (Andrey Chernov) Date: Thu Oct 8 12:42:44 2009 Subject: 'ee' editor prints cyrillic characters on white background In-Reply-To: <20091004090156.GA85409@crete.org.ua> References: <20091004090156.GA85409@crete.org.ua> Message-ID: <20091008123001.GA82997@nagual.pp.ru> On Sun, Oct 04, 2009 at 12:01:56PM +0300, Alexander Shikoff wrote: > Hello, > > I've upgraded my 7.2-RELEASE to 8.0-RC1. ee editor began to highlight > cyrillic characters (locale uk_UA.KOI8-U) with white background and > underscoring. Does anyone know how to disable this? Thanks. Fixed in -current. -- http://ache.pp.ru/ From ianf at clue.co.za Thu Oct 8 13:08:39 2009 From: ianf at clue.co.za (Ian FREISLICH) Date: Thu Oct 8 13:08:46 2009 Subject: Nagios SIGSEGV on FreeBSD 8 In-Reply-To: <4ABAF113.9030904@freebsd.org> References: <4ABAF113.9030904@freebsd.org> <20090922212905.GA77503@sysmon.tcworks.net> Message-ID: Tim Kientzle wrote: > Scott Lambert wrote: > > I've posted this to FreeBSD-ports and Nagios-Users without a nibble. > > > > [New Thread 28326280 (LWP 100051)] > > [New Thread 28301140 (LWP 100222)] > > (gdb) bt > > #0 0x0807fe8b in get_next_comment_by_host () > > #1 0x08080940 in delete_host_acknowledgement_comments () > > #2 0x28331180 in ?? () > > #3 0x4aaac053 in ?? () > > #4 0x080cc394 in __JCR_LIST__ () > > Build with debug symbols and try again; maybe you can get > more detail. Also, check a couple of core dumps to > see if it's crashing in the same place; that might > also give a clue. > > Do the "New Thread" messages mean that Nagios is running > multiple threads? If so, I wonder what the other > thread is doing? > We've been trying to combat a performance issue in Nagios. One thread handles incoming events (nsca etc) and data from the nagios.cmd pipe file and writes files for processing in /var/spool/nagios/checkresults. The other thread processes these files and updates the host state and other data. The threading broke profiling (I think) because when Nagios was compiled with -pg it did no more than read its configuration, but this alone was a pointer to the area that Nagios is poorly optimised - string processing. Reading our configuration resulted in 65000000 calls to strcmp. 65 Million!! We're battling to keep up with passive events from about 5000 hosts every few minutes. The nagios.cmd thread struggles to keep up reading from the fifo when there a about 4000 writers. And the worker thread struggles parse the checkresults files - they're big, but not *that* big, maybe 80k to 120k lines which it takes about 7 minutes to parse. We also had to up kern.maxusers="1024" and kern.ipc.nmbclusters="131072" to prevent the system starving network resources. Ian -- Ian Freislich From rwatson at FreeBSD.org Thu Oct 8 13:56:48 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Oct 8 13:57:22 2009 Subject: Believed fixed (was: Re: Another panic (during netisr?)) In-Reply-To: <4AC61ED6.1090802@haruhiism.net> References: <4AC61ED6.1090802@haruhiism.net> Message-ID: On Fri, 2 Oct 2009, Kamigishi Rei wrote: > Hello, hope you're having a nice day, > > This is on FreeBSD 8.0-BETA3 (Ameagari) #23 r196460: Mon Aug 24 00:36:33 JST > 2009; not sure if it has been witnessed or fixed. I've been running it > without restarts to test the stability and here we go: Since debugging this went offline, the quick summary for the list is: it looks like a race condition in the read-write locking for tcbinfo in 8.x/9.x was responsible, and I've now committed a fix to head and merged to stable/8 this morning. If this recurs with the fix, please let me know, because that would mean we fixed the wrong bug. :-) Robert > > Unread portion of the kernel message buffer: > panic: tcp_input: so == NULL > cpuid = 0 > Uptime: 39d15h40m53s > > (kgdb) #0 doadump () at pcpu.h:223 > #1 0xffffffff805ab6d3 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:416 > #2 0xffffffff805abb2c in panic (fmt=Variable "fmt" is not available. > ) > at /usr/src/sys/kern/kern_shutdown.c:579 > #3 0xffffffff80725543 in tcp_input (m=0xffffff00672a8300, off0=Variable > "off0" is not available. > ) > at /usr/src/sys/netinet/tcp_input.c:737 > #4 0xffffffff806bea9c in ip_input (m=0xffffff00672a8300) > at /usr/src/sys/netinet/ip_input.c:775 > #5 0xffffffff8065d478 in netisr_dispatch_src (proto=1, source=Variable > "source" is not available. > ) > at /usr/src/sys/net/netisr.c:917 > #6 0xffffffff80655b7d in ether_demux (ifp=0xffffff0001656000, > m=0xffffff00672a8300) at /usr/src/sys/net/if_ethersubr.c:895 > #7 0xffffffff80655fa5 in ether_input (ifp=0xffffff0001656000, > m=0xffffff00672a8300) at /usr/src/sys/net/if_ethersubr.c:754 > #8 0xffffffff80347f64 in em_rxeof (adapter=0xffffff80002b0000, count=4) > at /usr/src/sys/dev/e1000/if_em.c:4605 > #9 0xffffffff80349d05 in em_poll (ifp=0xffffff0001656000, cmd=Variable "cmd" > is not available. > ) > at /usr/src/sys/dev/e1000/if_em.c:1657 > #10 0xffffffff8059fa17 in netisr_poll () at /usr/src/sys/kern/kern_poll.c:448 > #11 0xffffffff8065cd56 in swi_net (arg=0xffffffff80eb7800) > at /usr/src/sys/net/netisr.c:748 > #12 0xffffffff80585398 in intr_event_execute_handlers (p=Variable "p" is not > available. > ) > at /usr/src/sys/kern/kern_intr.c:1165 > #13 0xffffffff80585ff2 in ithread_loop (arg=0xffffff00014d8660) > at /usr/src/sys/kern/kern_intr.c:1178 > #14 0xffffffff805832ea in fork_exit ( > callout=0xffffffff80585f40 , arg=0xffffff00014d8660, > frame=0xffffff8000032c80) at /usr/src/sys/kern/kern_fork.c:838 > #15 0xffffffff8087a24e in fork_trampoline () > at /usr/src/sys/amd64/amd64/exception.S:561 > > -- > Kamigishi Rei > KREI-RIPE > fujibayashi.jp > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From kostikbel at gmail.com Thu Oct 8 14:59:04 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Oct 8 14:59:11 2009 Subject: PIE support Message-ID: <20091008145900.GK2259@deviant.kiev.zoral.com.ua> There is a patch, that should provide more or less proper support for PIE (Position Independent Executables). Besides being desirable feature itself, this is needed to be able to execute PIE binaries, both native FreeBSD and Linux images, with sysctl security.bsd.map_at_zero=0. In particular, Samba port is affected. gdb does not work for PIE binaries, I believe this is a gdb shortcoming. Patch was reviewed by Alexander Kabaev, discussed with Bjoern A. Zeeb, who tested i386 and amd64, and tested by Boris Samorodov for Linux binaries. I am asking for general testing for the patch. Also, I would ask the architecture maintainers to look for the per-arch mapbase address selected for the PIE binaries. http://people.freebsd.org/~kib/misc/pie.5.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091008/78ba254b/attachment.pgp From sgk at troutmask.apl.washington.edu Thu Oct 8 17:02:30 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Thu Oct 8 17:02:42 2009 Subject: PIE support In-Reply-To: <20091008145900.GK2259@deviant.kiev.zoral.com.ua> References: <20091008145900.GK2259@deviant.kiev.zoral.com.ua> Message-ID: <20091008170229.GA75042@troutmask.apl.washington.edu> On Thu, Oct 08, 2009 at 05:59:00PM +0300, Kostik Belousov wrote: > > gdb does not work for PIE binaries, I believe this is a gdb shortcoming. > gdb 7.0 was released on Oct 6th. It appears to work fine with PIE. (Yes, I know that gdb 7.0 is unlikely to appear in FreeBSD.) -- Steve From pyunyh at gmail.com Thu Oct 8 17:06:14 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Oct 8 17:06:22 2009 Subject: alc(4) link autoselect problem In-Reply-To: References: <20091007180257.GA3843@michelle.cdnetworks.com> Message-ID: <20091008170458.GC3843@michelle.cdnetworks.com> On Thu, Oct 08, 2009 at 12:38:45PM +0200, Ian FREISLICH wrote: > Pyun YongHyeon wrote: > > The atphy(4) recognizes PHY as F1 gigabit PHY because AR8132 uses > > the same PHY id of F1 gigabit PHY. There is no way to know whether > > it really has F1 gigabit PHY in driver's view. > > > > > If I set the media to 100BaseTX full-duplex it works. > > > > If link parter used auto-negotiation, this forced media selection > > shall make your link partner select half-duplex mode instead of > > full-duplex due to the nature of parallel detection. > > When I do this: > [mini] /usr/home/ianf # ifconfig alc0 media 100BaseTX mediaopt full-duplex > > I get this on the switch: > > 08-Oct-2009 12:26:42 %STP-W-PORTSTATUS: g14 of instance 0: STP status Forwarding > 08-Oct-2009 12:26:42 %STP-W-PORTSTATUS: g14 of instance 1: STP status Forwarding > 08-Oct-2009 12:26:42 %STP-W-PORTSTATUS: g14 of instance 2: STP status Forwarding > 08-Oct-2009 12:26:42 %LINK-I-Up: g14 > > wgsw-24010# sh interfaces status ethernet g14 > Flow Link Back Mdix > Port Type Duplex Speed Neg ctrl State Pressure Mode > -------- ------------ ------ ----- -------- ---- ----------- -------- ------- > g14 1G-Copper Full 100 Enabled Off Up Disabled Off > Hmm, does your switch have an option to enable/disable downshifting feature? If so, how about toggling the option? > So, it correctly detects full duplex. > > The cable tester still reports the cable os open at 2m, probably > because it expects all 4 pairs to be terminated. > [...] > > How about checking MIB statistics of controller? > > (sysctl dev.alc.0.stats) > > This is after a reboot, but the link was up for a short while to > do the above testing. rx.good_frames looks a bit high for "up 21 > mins". > > dev.alc.0.stats.rx.good_frames: 3348588249 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > dev.alc.0.stats.rx.good_bcast_frames: 0 > dev.alc.0.stats.rx.good_mcast_frames: 0 > dev.alc.0.stats.rx.pause_frames: 0 > dev.alc.0.stats.rx.control_frames: 0 > dev.alc.0.stats.rx.crc_errs: 0 > dev.alc.0.stats.rx.len_errs: 0 > dev.alc.0.stats.rx.good_octets: 0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Yeah, that looks odd, it seemed controller received a lot of good frames but none were meaningful packets so I guess there are link establishment issues. I still have no clue but if I manage to find more test case I will let you know. > dev.alc.0.stats.rx.good_bcast_octets: 0 > dev.alc.0.stats.rx.good_mcast_octets: 0 [...] From hselasky at freebsd.org Thu Oct 8 19:09:49 2009 From: hselasky at freebsd.org (Hans Petter Selasky) Date: Thu Oct 8 19:09:56 2009 Subject: Polling support for USB serial port adapters [patches] In-Reply-To: <200909271950.55189.hselasky@freebsd.org> References: <200909251909.31503.hselasky@freebsd.org> <4ABE2B4F.6080104@tomjudge.com> <200909271950.55189.hselasky@freebsd.org> Message-ID: <200910082010.36621.hselasky@freebsd.org> On Sunday 27 September 2009 19:50:54 Hans Petter Selasky wrote: > Hi, > > Here is a patchset which you can try. > > http://perforce.freebsd.org/chv.cgi?CH=168932 > > You need to download at least: > > usb_serial.h > and > usb_serial.c > > Download serial port drivers as needed. > > You need to at least recompile all USB serial modules. > > To enable you set: > > hw.usb.ucom.cons_unit=0 > hw.usb.ucom.cons_baud=9600 > > In /boot/loader.conf > > NOTE: The patches have not been tested yet, only carefully reviewed. If you > experience any problems, please debug and send patch to me. > Has anyone tried this out? --HPS From ehrmann at gmail.com Thu Oct 8 23:09:38 2009 From: ehrmann at gmail.com (David Ehrmann) Date: Thu Oct 8 23:31:15 2009 Subject: 8.0rc1 not recognizing partitions on EPIA SN Message-ID: <4ACE6D84.3000209@gmail.com> First, I tried to upgrade the normal way. I built my own kernel and installed it, but when I tried to boot it, I got a mountroot> prompt. When I printed the devices, instead of seeing ad0s1a and friends, I saw ad0a and ad0d (just those two for ad0). I was still able to use the old (7.1) kernel fine. Thinking it was something to do with the upgrade, I tried to do a reinstall. I chose the default options, but once it got to the "last chance..." screen, this happened: Unable to find device node for /dev/ad0s1b in /dev! The creation of filesystems will be aborted. Needless to say, the installation failed. Like I said in the subject, this is with a VIA EPIA SN motherboard. The hard drive is a CF card in a slot on the board. The card's worked fine in the past, and was detected fine at partitioning time. Forgive me if this is the wrong list, and please CC me as I am not on the mailing list. From tom at uffner.com Fri Oct 9 00:37:45 2009 From: tom at uffner.com (Tom Uffner) Date: Fri Oct 9 00:37:54 2009 Subject: 8.0rc1 not recognizing partitions on EPIA SN In-Reply-To: <4ACE6D84.3000209@gmail.com> References: <4ACE6D84.3000209@gmail.com> Message-ID: <4ACE833A.3030506@uffner.com> David Ehrmann wrote: > First, I tried to upgrade the normal way. I built my own kernel and > installed it, but when I tried to boot it, I got a mountroot> prompt. > When I printed the devices, instead of seeing ad0s1a and friends, I saw > ad0a and ad0d (just those two for ad0). I was still able to use the old > (7.1) kernel fine. Thinking it was something to do with the upgrade, I > tried to do a reinstall. I chose the default options, but once it got > to the "last chance..." screen, this happened: > > Unable to find device node for /dev/ad0s1b in /dev! > The creation of filesystems will be aborted. this is becoming an FAQ for 8.0 the short answer is "dangerously dedicated" partitions are not supported by the 8.0 installer. back up your data. zero the MBR & partition table with dd, and re-slice & partition your disk. after the install, restore from your backups. search the freebsd-current archives for full details. From james-freebsd-current at jrv.org Fri Oct 9 03:23:18 2009 From: james-freebsd-current at jrv.org (James R. Van Artsdalen) Date: Fri Oct 9 03:23:25 2009 Subject: [Fwd: siis change] Message-ID: <4ACEACA3.9070702@jrv.org> mav committed a change to SIIS so I tried it but still get the device hangs as before. I should have sent that report here instead of to mav. ch1 below connects to a port multiplier and ada3 is one of four disks behind ch1. Does disk ada3 ever get reset, or the link between the port multiplier behind ch1 and ada3 ever get reinitialized? I'm wondering if the port multiplier is the key. I don't see any code to reset ada3 or at least stop/start its PHY link. It takes about an hour for "zpool scrub" to hang. -------- Original Message -------- Subject: siis change Date: Thu, 08 Oct 2009 18:06:01 -0500 From: James R. Van Artsdalen To: Alexander Motin I see you dropped in a change to SIIS for timeout errors so I decided to give it a try. It still hangs for me. FreeBSD pygmy.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r197866: Thu Oct 8 16:32:18 CDT 2009 root@pygmy.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 I did a "zpool scrub" which was generally running at about 100 MB/s across six 2 TB disks in two port multiplier enclosures. Here is that complete /var/log/messages. Oct 8 17:47:54 pygmy kernel: siisch1: Timeout on slot 3 Oct 8 17:47:54 pygmy kernel: siisch1: siis_timeout is 00000000 ss 00028308 rs 00028308 es 00000000 sts 80032000 serr 00000000 Oct 8 17:47:54 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:47:54 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:24 pygmy kernel: siisch1: Timeout on slot 29 Oct 8 17:48:24 pygmy kernel: siisch1: siis_timeout is 00040000 ss 60000007 rs 60000007 es 00000000 sts 801d2000 serr 00000000 Oct 8 17:48:24 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:48:24 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:54 pygmy kernel: siisch1: Timeout on slot 3 Oct 8 17:48:54 pygmy kernel: siisch1: siis_timeout is 00040000 ss 000000f8 rs 000000f8 es 00000000 sts 80032000 serr 00000000 Oct 8 17:48:54 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:48:54 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:48:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:24 pygmy kernel: siisch1: Timeout on slot 8 Oct 8 17:49:24 pygmy kernel: siisch1: siis_timeout is 00040000 ss 00001f00 rs 00001f00 es 00000000 sts 80082000 serr 00000000 Oct 8 17:49:24 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:49:24 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:49:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:54 pygmy kernel: siisch1: Timeout on slot 13 Oct 8 17:49:54 pygmy kernel: siisch1: siis_timeout is 00040000 ss 0003e000 rs 0003e000 es 00000000 sts 800d2000 serr 00000000 Oct 8 17:49:54 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:49:54 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): error 5 Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Retries Exhausted Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:49:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:24 pygmy kernel: siisch1: Timeout on slot 18 Oct 8 17:50:24 pygmy kernel: siisch1: siis_timeout is 00040000 ss 00fc0000 rs 00fc0000 es 00000000 sts 80122000 serr 00000000 Oct 8 17:50:24 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:50:24 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:54 pygmy kernel: siisch1: Timeout on slot 24 Oct 8 17:50:54 pygmy kernel: siisch1: siis_timeout is 00040000 ss 3f000000 rs 3f000000 es 00000000 sts 80182000 serr 00000000 Oct 8 17:50:54 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:50:54 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:50:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:24 pygmy kernel: siisch1: Timeout on slot 30 Oct 8 17:51:24 pygmy kernel: siisch1: siis_timeout is 00040000 ss 4000001f rs 4000001f es 00000000 sts 801e2000 serr 00000000 Oct 8 17:51:24 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:51:24 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:54 pygmy kernel: siisch1: Timeout on slot 5 Oct 8 17:51:54 pygmy kernel: siisch1: siis_timeout is 00040000 ss 000007e0 rs 000007e0 es 00000000 sts 80052000 serr 00000000 Oct 8 17:51:54 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:51:54 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:51:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:24 pygmy kernel: siisch1: Timeout on slot 11 Oct 8 17:52:24 pygmy kernel: siisch1: siis_timeout is 00040000 ss 0001f800 rs 0001f800 es 00000000 sts 800b2000 serr 00000000 Oct 8 17:52:24 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:52:24 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:54 pygmy kernel: siisch1: Timeout on slot 17 Oct 8 17:52:54 pygmy kernel: siisch1: siis_timeout is 00040000 ss 007e0000 rs 007e0000 es 00000000 sts 80112000 serr 00000000 Oct 8 17:52:54 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:52:54 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): error 5 Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Retries Exhausted Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:52:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:53:24 pygmy kernel: siisch1: Timeout on slot 23 Oct 8 17:53:24 pygmy kernel: siisch1: siis_timeout is 00040000 ss 3f800000 rs 3f800000 es 00000000 sts 80172000 serr 00000000 Oct 8 17:53:24 pygmy kernel: siisch1: ready wait time=0ms Oct 8 17:53:24 pygmy kernel: siisch1: ready wait time=1ms Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued Oct 8 17:53:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command [root@pygmy ~]# From ehrmann at gmail.com Fri Oct 9 02:21:06 2009 From: ehrmann at gmail.com (David Ehrmann) Date: Fri Oct 9 04:57:39 2009 Subject: 8.0rc1 not recognizing partitions on EPIA SN In-Reply-To: <4ACE833A.3030506@uffner.com> References: <4ACE6D84.3000209@gmail.com> <4ACE833A.3030506@uffner.com> Message-ID: <4ACE9DFD.3010207@gmail.com> Tom Uffner wrote: > David Ehrmann wrote: >> First, I tried to upgrade the normal way. I built my own kernel and >> installed it, but when I tried to boot it, I got a mountroot> >> prompt. When I printed the devices, instead of seeing ad0s1a and >> friends, I saw ad0a and ad0d (just those two for ad0). I was still >> able to use the old (7.1) kernel fine. Thinking it was something to >> do with the upgrade, I tried to do a reinstall. I chose the default >> options, but once it got to the "last chance..." screen, this happened: >> >> Unable to find device node for /dev/ad0s1b in /dev! >> The creation of filesystems will be aborted. > > this is becoming an FAQ for 8.0 > > the short answer is "dangerously dedicated" partitions are not supported > by the 8.0 installer. back up your data. zero the MBR & partition table > with dd, and re-slice & partition your disk. after the install, restore > from your backups. > > search the freebsd-current archives for full details. dd did the trick. I understand why this was done, but at the same time, upgrading is now impractical for some users, and what looks like a fresh installation (repartitioned, resliced) can even fail. Is there a change that could be made to the partitioning process that would fix this? From ianf at clue.co.za Fri Oct 9 05:29:15 2009 From: ianf at clue.co.za (Ian FREISLICH) Date: Fri Oct 9 05:29:22 2009 Subject: alc(4) link autoselect problem In-Reply-To: <20091008170458.GC3843@michelle.cdnetworks.com> References: <20091008170458.GC3843@michelle.cdnetworks.com> <20091007180257.GA3843@michelle.cdnetworks.com> Message-ID: Pyun YongHyeon wrote: > On Thu, Oct 08, 2009 at 12:38:45PM +0200, Ian FREISLICH wrote: > > wgsw-24010# sh interfaces status ethernet g14 > > Flow Link Back Mdix > > Port Type Duplex Speed Neg ctrl State Pressure Mode > > -------- ------------ ------ ----- -------- ---- ----------- -------- ---- --- > > g14 1G-Copper Full 100 Enabled Off Up Disabled Off > > > > Hmm, does your switch have an option to enable/disable downshifting > feature? If so, how about toggling the option? I'm not sure exactly what you mean. There's no configuration options that obviously match. > > > How about checking MIB statistics of controller? > > > (sysctl dev.alc.0.stats) > > > > This is after a reboot, but the link was up for a short while to > > do the above testing. rx.good_frames looks a bit high for "up 21 > > mins". > > > > dev.alc.0.stats.rx.good_frames: 3348588249 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > dev.alc.0.stats.rx.good_octets: 0 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Yeah, that looks odd, it seemed controller received a lot of good > frames but none were meaningful packets so I guess there are link > establishment issues. I still have no clue but if I manage to find > more test case I will let you know. That number is bogus. It's currently incrementing by approximately 33435108 per second without a cable plugged in. Ian -- Ian Freislich From mav at FreeBSD.org Fri Oct 9 06:35:34 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Oct 9 06:35:41 2009 Subject: [Fwd: siis change] In-Reply-To: <4ACEACA3.9070702@jrv.org> References: <4ACEACA3.9070702@jrv.org> Message-ID: <4ACED9B2.8060203@FreeBSD.org> James R. Van Artsdalen wrote: > mav committed a change to SIIS so I tried it but still get the device > hangs as before. I should have sent that report here instead of to mav. This change just fixes possible problem inside CAM, but it does nothing to hardware. > ch1 below connects to a port multiplier and ada3 is one of four disks > behind ch1. > > Does disk ada3 ever get reset, or the link between the port multiplier > behind ch1 and ada3 ever get reinitialized? I'm wondering if the port > multiplier is the key. I don't see any code to reset ada3 or at least > stop/start its PHY link. It is still not implemented. I am going to start working on it now. > It takes about an hour for "zpool scrub" to hang. > > -------- Original Message -------- > Subject: siis change > Date: Thu, 08 Oct 2009 18:06:01 -0500 > From: James R. Van Artsdalen > To: Alexander Motin > > I see you dropped in a change to SIIS for timeout errors so I decided to > give it a try. It still hangs for me. > > FreeBSD pygmy.housenet.jrv 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r197866: > Thu Oct 8 16:32:18 CDT 2009 > root@pygmy.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64 > > I did a "zpool scrub" which was generally running at about 100 MB/s > across six 2 TB disks in two port multiplier enclosures. > > Here is that complete /var/log/messages. > > Oct 8 17:47:54 pygmy kernel: siisch1: Timeout on slot 3 > Oct 8 17:47:54 pygmy kernel: siisch1: siis_timeout is 00000000 ss > 00028308 rs 00028308 es 00000000 sts 80032000 serr 00000000 > Oct 8 17:47:54 pygmy kernel: siisch1: ready wait time=0ms > Oct 8 17:47:54 pygmy kernel: siisch1: ready wait time=1ms > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued > Oct 8 17:47:54 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:48:24 pygmy kernel: siisch1: Timeout on slot 29 > Oct 8 17:48:24 pygmy kernel: siisch1: siis_timeout is 00040000 ss > 60000007 rs 60000007 es 00000000 sts 801d2000 serr 00000000 > Oct 8 17:48:24 pygmy kernel: siisch1: ready wait time=1ms > Oct 8 17:48:24 pygmy kernel: siisch1: ready wait time=0ms > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Command timed out > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Request Requeued > Oct 8 17:48:24 pygmy kernel: (ada3:siisch1:0:2:0): Retrying Command -- Alexander Motin From pjd at FreeBSD.org Fri Oct 9 09:55:01 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Fri Oct 9 09:55:15 2009 Subject: glabel+gmirror (8.0-RC1 problem) In-Reply-To: <20091005193340.cd84f0ec.lehmann@ans-netz.de> References: <20090927170244.0980d699.lehmann@ans-netz.de> <20090927223725.5893371f.lehmann@ans-netz.de> <20090928084035.GB1659@garage.freebsd.pl> <20090928203756.ef70e0c6.lehmann@ans-netz.de> <20090928184926.GA2016@garage.freebsd.pl> <20091005193340.cd84f0ec.lehmann@ans-netz.de> Message-ID: <20091009095453.GE1725@garage.freebsd.pl> On Mon, Oct 05, 2009 at 07:33:40PM +0200, Oliver Lehmann wrote: > gjorunal is also affected. I tried to use one partition of my gmirror > disk as journal device for my 3ware raid-5 device which works until I > reboot - the journal is then gone as well. > Is this patch likly to fix this as well? Will it be included in a future > RC? Until now I've stayed away using glabel+gmirror but I didn't knew > that gjournal is affected as well so I'm now left with warning that the > journal provider is gone wile booting - and more tragically I'm left > without journaling at all (which hurts on a 2.7TB partition when the > system was not cleanly shut down) I just committed the patch. Yes, it should fix gjournal case as well. I want to merge it before 8.0-RELEASE. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- 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-current/attachments/20091009/4bc11807/attachment.pgp From dimitry at andric.com Fri Oct 9 10:21:23 2009 From: dimitry at andric.com (Dimitry Andric) Date: Fri Oct 9 10:21:30 2009 Subject: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration In-Reply-To: <25ff90d60910060921k2118994aq1f5b0431868ec800@mail.gmail.com> References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org> <20091005.123427.227628092.hrs@allbsd.org> <4ACA4B81.3090105@andric.com> <4ACB3A08.9030109@andric.com> <25ff90d60910060921k2118994aq1f5b0431868ec800@mail.gmail.com> Message-ID: <4ACF0EA0.9070401@andric.com> On 2009-10-06 18:21, David Horn wrote: > 1) Patchset is missing examples and defaults for new rc.conf > variables to /etc/defaults/rc.conf. (The defaults/rc.conf has been > updated in -current, although perhaps once everything settles, it > would help to expand the examples in comments) Not only that, it would prevent the following needless warnings, which are printed at every boot: [...] /etc/rc: WARNING: $ipv6_enable is obsolete. Use $ipv6_prefer instead. /etc/rc: WARNING: $ipv6_enable is obsolete. Use $ipv6_prefer instead. [...] /etc/rc: WARNING: $ipv6_router_enable is obsolete. Use $route6d_enable instead. /etc/rc: WARNING: $ipv6_router is obsolete. Use $route6d_program instead. /etc/rc: WARNING: $router_enable is obsolete. Use $routed_enable instead. /etc/rc: WARNING: $router is obsolete. Use $routed_program instead. /etc/rc: WARNING: $router_flags is obsolete. Use $routed_flags instead. Although the warning about ipv6_enable could be considered right, there's no need to print it twice, and I never touched any of the other ipv6_* or router_* variables. Those are from /etc/defaults/rc.conf. > 2) I really like the changes to ifconfig and kernel for exposing > per-interface flags for "accept_rtadv" and other ndp flags to ifconfig > (and inherently rc.conf). I previously had to do some hackery to > disable "accept_rtadv" at boot time for just one interface within > rc.conf. I'm not entirely sure if this is a sensible default. I would guess that for most users (80%? 90%?) the choice is only to have IPv6 "globally" disabled or enabled, and only a small percentage of users will need per-interface enabling/disabling of IPv4. Since it's now 2009 and everybody should start using IPv6 ASAP, it might make sense to have IPv6 globally enabled by default, with additional options for users like David to selectively disable it for individual interfaces. > 3) I would prefer that ipv6_enable remain a global flag in rc.conf, > and NOT be obsoleted. I would also prefer that > ipv6_network_interfaces="auto" as in the past by default. Again, I > like the logic changes and the flexibility it provides, it is just the > default/obsolete that I am interested in changing. Seconded. Even Windows defaults to enabling IPv6 globally for all interfaces these days. :) > 4) Personal opinion time: change the "accept_rtadv" token to > "autoconf" in ifconfig and rc.conf, as this it is a better > self-description. Just one persons opinion. Since the old "global" sysctl was also called accept_rtadv, I understand the same name was chosen for the per-interface option. People might confuse "autoconf" with "zeroconf" or other automatic configuration systems. Since the option means to accept router advertisements, accept_rtadv seems not a very bad name to me... :) > Given the timing, +1 for letting this bake in -current until after 8.0 > release. Yes. A few weeks at least. From syso.fml at ext.no-route.org Fri Oct 9 10:58:28 2009 From: syso.fml at ext.no-route.org (Sylwester Sosnowski) Date: Fri Oct 9 10:58:38 2009 Subject: Support for PC Engines ALIX2 reset pushbutton. Message-ID: <4ACF131C.1060201@ext.no-route.org> Hello, I've just written an user-space utility for handling the PC Enginges ALIX' reset-pushbutton. It's a quick-and-dirty prototype and does the same what "shutdown -h now" does. I'll do a clean rewrite later. Any comments or suggestions appreciated. Here is the prototype: ----- BEGIN ----- /* * User-space reset-button support for PC Engines ALIX boards. * This is a prototype. * * Usage: * Use from rc(8). */ #include #include #include #include #include #include #include #include #include #include #include #include // MY_NAME is the process name used in syslog. #define MY_NAME "resetguard" // GPIO_RESET u_int32_t switchAddr = 0x61b0; int switchBit = 8; // GPIO_LED3 u_int32_t ledAddr = 0x6180; int ledBit = 11; // Blink GPIO_LED3. void blinkLed(int times) { int i; for (i=0; i Hello, I have ported run (ru'N' not ru'M') driver and posted on freebsd forum. http://forums.freebsd.org/showthread.php?s=91e5d3d58be54728b80686a77c8428cd&t=7562 Then, one member suggested to email you so some developers can review the code. Also, one of mailing list subscribers recommended to port to current, so I'm planing to do that. I'm new to freebsd. Any comments/suggestions would be appreciated. Thank you. Akinori __________________________________________________________________ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca From sean at seanmcollins.com Fri Oct 9 18:34:28 2009 From: sean at seanmcollins.com (Sean Collins) Date: Fri Oct 9 18:36:01 2009 Subject: ported run driver In-Reply-To: <989483.352.qm@web51802.mail.re2.yahoo.com> References: <989483.352.qm@web51802.mail.re2.yahoo.com> Message-ID: <20091009143426.21228n4sedds0je8@masakari.coreitpro.com> Awesome! Thank you for the contribution! Thank You, Sean Collins ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From pyunyh at gmail.com Fri Oct 9 19:41:52 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Oct 9 19:41:59 2009 Subject: alc(4) link autoselect problem In-Reply-To: References: <20091008170458.GC3843@michelle.cdnetworks.com> <20091007180257.GA3843@michelle.cdnetworks.com> Message-ID: <20091009194037.GI3843@michelle.cdnetworks.com> On Fri, Oct 09, 2009 at 07:29:08AM +0200, Ian FREISLICH wrote: > Pyun YongHyeon wrote: > > On Thu, Oct 08, 2009 at 12:38:45PM +0200, Ian FREISLICH wrote: > > > wgsw-24010# sh interfaces status ethernet g14 > > > Flow Link Back Mdix > > > Port Type Duplex Speed Neg ctrl State Pressure Mode > > > -------- ------------ ------ ----- -------- ---- ----------- -------- ---- > --- > > > g14 1G-Copper Full 100 Enabled Off Up Disabled Off > > > > > > > Hmm, does your switch have an option to enable/disable downshifting > > feature? If so, how about toggling the option? > > I'm not sure exactly what you mean. There's no configuration options > that obviously match. > Modern PHYs have ability to correct several cabling problems, for example, - pair swaps - pair skews - pair polarity - automatic MDI/MDIX - downshift to enable 10/100Mps link establishment with two pairs by downgrading the link speed to 10/100Mbps during auto-negotiation process when it can't establish 1000Mbps link. Existing cables used to connect 10/100Mbps link partners may have only two pairs. With two pairs PHYs can announce 1000Mbps capability to link partner but it can't establish the link as 1000Mbps link requires 4 pairs. Since F1 PHY seems to have above capability I just wanted to see whether disabling downshifting on link partner makes any difference. > > > > How about checking MIB statistics of controller? > > > > (sysctl dev.alc.0.stats) > > > > > > This is after a reboot, but the link was up for a short while to > > > do the above testing. rx.good_frames looks a bit high for "up 21 > > > mins". > > > > > > dev.alc.0.stats.rx.good_frames: 3348588249 > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > dev.alc.0.stats.rx.good_octets: 0 > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > Yeah, that looks odd, it seemed controller received a lot of good > > frames but none were meaningful packets so I guess there are link > > establishment issues. I still have no clue but if I manage to find > > more test case I will let you know. > > That number is bogus. It's currently incrementing by approximately > 33435108 per second without a cable plugged in. > Hmm, I have to test this case. Thanks. > Ian > > -- > Ian Freislich From tom at tomjudge.com Fri Oct 9 20:29:07 2009 From: tom at tomjudge.com (Tom Judge) Date: Fri Oct 9 20:29:14 2009 Subject: Support for PC Engines ALIX2 reset pushbutton. In-Reply-To: <4ACF131C.1060201@ext.no-route.org> References: <4ACF131C.1060201@ext.no-route.org> Message-ID: <4ACF9CE7.30808@tomjudge.com> Hi Sylwester, This is interesting, what boards should be supported? (I have a couple of 2d3's) I will be needing something like this for my current project as well. Thanks TJ Sylwester Sosnowski wrote: > Hello, > > I've just written an user-space utility for handling the PC Enginges ALIX' > reset-pushbutton. It's a quick-and-dirty prototype and does the same what > "shutdown -h now" does. I'll do a clean rewrite later. > > Any comments or suggestions appreciated. > > > Here is the prototype: > > ----- BEGIN ----- > > /* > * User-space reset-button support for PC Engines ALIX boards. > * This is a prototype. > * > * Usage: > * Use from rc(8). > */ > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > // MY_NAME is the process name used in syslog. > #define MY_NAME "resetguard" > > // GPIO_RESET > u_int32_t switchAddr = 0x61b0; > int switchBit = 8; > > // GPIO_LED3 > u_int32_t ledAddr = 0x6180; > int ledBit = 11; > > > // Blink GPIO_LED3. > void blinkLed(int times) > { > int i; > > for (i=0; i { > outl(ledAddr, 1 << (ledBit + 16)); > usleep(80000); > outl(ledAddr, 1 << ledBit); > usleep(80000); > } > } > > // Return GPIO_RESET state. > char isResetPressed() { > return ((inl(switchAddr) & (1 << switchBit)) == 0); > } > > int main() { > int fd; // Define our file descriptor > char *empty_environ[] = { NULL }; // Environment for halt(8) > > if(geteuid()) > { > errx(1, "You're not super-user."); // Show error and exit. > } > > > fd = open("/dev/io", O_RDONLY); // Read-only file descriptor for /dev/io > > if (fd == -1) { // On error (e.g. wrong permissions) > perror("Cannot open /dev/io."); // Print error message > exit(1); // and exit with status 1 > } > > /* > * At this point we'll be polling the GPIO-Pin of the Reset-button > * at the front of the PC Engines Alix board every 450ms. > * If the pin is HIGH, resetBoard() will be called. > */ > > while(1) // Infinite loop > { > usleep(4000000); // Wait ca. 450ms before probing again > if(isResetPressed()) { // If resetPressed() returns 1.. > blinkLed(4); // Blink GPIO_LED3 4 times > > setlogmask(LOG_UPTO (LOG_NOTICE)); // LOG_NOTICE > > // We'll be logging to LOG_LOCAL1 > openlog(MY_NAME, LOG_CONS | LOG_NDELAY, LOG_LOCAL1); > > // Write message to syslog > syslog(LOG_NOTICE, "Event detected on GPIO_RESET (UID %d)", getuid()); > > // Close Log > closelog(); > > // Halt system (like "shutdown -h now" does) > execle(_PATH_HALT, "halt", "-l", sync, (char *)NULL, empty_environ); > > // Exit with status 0 > exit(0); > } > } > > exit(0); // This should never be reached (exit 0) > } > > > ----- END ----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From davidxu at freebsd.org Sat Oct 10 05:25:18 2009 From: davidxu at freebsd.org (David Xu) Date: Sat Oct 10 05:25:47 2009 Subject: Signals and an exiting thread In-Reply-To: <20091005192144.GA2259@deviant.kiev.zoral.com.ua> References: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> <20091002201213.GA16633@stack.nl> <20091005192144.GA2259@deviant.kiev.zoral.com.ua> Message-ID: <4AD01ABC.50901@freebsd.org> Kostik Belousov wrote: > I agree that postponing assignment of the thread for signal delivery > till the actual delivery occurs is the proper fix. I tried to cheat > in my previous patch. Below is an experimental change that did very > minimal testing. > Even if the signal is put into process's signal queue, it is still possible that signal notification is lost because selected thread exits before seeing it, if other threads are sleeping, they are not notified, this leaves signal in process queue long time before it can be delivered to userland. From patfbsd at davenulle.org Sat Oct 10 09:41:03 2009 From: patfbsd at davenulle.org (Patrick Lamaiziere) Date: Sat Oct 10 09:41:09 2009 Subject: Polling support for USB serial port adapters [patches] In-Reply-To: <200910082010.36621.hselasky@freebsd.org> References: <200909251909.31503.hselasky@freebsd.org> <4ABE2B4F.6080104@tomjudge.com> <200909271950.55189.hselasky@freebsd.org> <200910082010.36621.hselasky@freebsd.org> Message-ID: <20091010114100.51b67abd@baby-jane.lamaiziere.net> Le Thu, 8 Oct 2009 20:10:34 +0200, Hans Petter Selasky a ?crit : Hello, > > hw.usb.ucom.cons_unit=0 > > hw.usb.ucom.cons_baud=9600 > > > > In /boot/loader.conf > > > > NOTE: The patches have not been tested yet, only carefully > > reviewed. If you experience any problems, please debug and send > > patch to me. I'm trying with uplcom (Prolific chipset) but I'm not familiar with serial debuging. Shall I use a remote gdb. Or should it work if I set a serial console on the machine (like with uart)? I'm testing on 8.0. Regards. From hselasky at freebsd.org Sat Oct 10 10:38:16 2009 From: hselasky at freebsd.org (Hans Petter Selasky) Date: Sat Oct 10 10:38:23 2009 Subject: Polling support for USB serial port adapters [patches] In-Reply-To: <20091010114100.51b67abd@baby-jane.lamaiziere.net> References: <200909251909.31503.hselasky@freebsd.org> <200910082010.36621.hselasky@freebsd.org> <20091010114100.51b67abd@baby-jane.lamaiziere.net> Message-ID: <200910101239.02783.hselasky@freebsd.org> On Saturday 10 October 2009 11:41:00 Patrick Lamaiziere wrote: > Le Thu, 8 Oct 2009 20:10:34 +0200, > Hans Petter Selasky a ?crit : > > Hello, > > > > hw.usb.ucom.cons_unit=0 > > > hw.usb.ucom.cons_baud=9600 > > > > > > In /boot/loader.conf > > > > > > NOTE: The patches have not been tested yet, only carefully > > > reviewed. If you experience any problems, please debug and send > > > patch to me. > > I'm trying with uplcom (Prolific chipset) but I'm not familiar with > serial debuging. Shall I use a remote gdb. Or should it work if I > set a serial console on the machine (like with uart)? > > I'm testing on 8.0. It should work with both GDB and the console driver. --HPS From kris at FreeBSD.org Sat Oct 10 11:26:16 2009 From: kris at FreeBSD.org (Kris Kennaway) Date: Sat Oct 10 11:26:25 2009 Subject: odd make/build output on ^Z / fg In-Reply-To: <3a142e750909301035m4a08d71as3e0175d0726038a8@mail.gmail.com> References: <3a142e750909301035m4a08d71as3e0175d0726038a8@mail.gmail.com> Message-ID: <4AD06F62.50800@FreeBSD.org> Pavo Banicevic wrote: > On 7/9/09, Robert Watson wrote: >> Today I suspended a kernel build with ^Z to free up a bit of I/O bandwidth >> on >> a box. When I re-foregrounded, all appeared fine for a bit, but later when >> I >> switched back to the xterm I found this: >> >> ototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef >> -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I../../.. >> -I../../../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 -mno-align-long-strings >> -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >> -mno-sse3 >> -ffreestanding -fstack-protector -Werror ../../../i386/acpica/acpi_wakeup.c >> couldn't resume mac_pipe.o: No such process >> *** Signal 1 >> couldn't resume audit_arg.o: No such process >> *** Signal 1 >> couldn't resume nlm_prot_impl.o: No such process >> *** Signal 1 >> couldn't resume nfs_serv.o: No such process >> *** Signal 1 >> couldn't resume nfs_vnops.o: No such process >> *** Signal 1 >> couldn't resume modules-obj: No such process >> ===> usb/uether (obj) >> ===> usb/aue (obj) >> ... >> ===> xfs (obj) >> ===> xl (obj) >> ===> zfs (obj) >> ===> zlib (obj) >> *** Signal 1 >> 6 errors >> >> I've never seen that before, but I also don't suspend builds all that >> frequently. New bug? Old bug? > > Today I got this when building kernel: > > # fg > make -j6 buildkernel > *** Stopped -- signal 18 > Child (49737) not in table? > couldn't resume aicasm_macro_gram.o: No such process > *** Signal 1 > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error > > > I have kern.randompid=777, and I did stopped buildworld just before > building kernel. Maybe this is (tcsh) shell issue? It's a very old bug. I first saw it after changes made by phk to the way make communicates with its child processes several years ago, but it's not clear where the problem lies. Kris From johny-freebsd at earthmagic.org Sat Oct 10 11:28:28 2009 From: johny-freebsd at earthmagic.org (Johny Mattsson) Date: Sat Oct 10 11:28:35 2009 Subject: zfsboot insists on /boot.config being >=512 bytes to not be "invalid format" Message-ID: <4AD06FD9.20206@earthmagic.org> Hi all, Just came across a tiny annoyance on 8.0-RC1-p1 - when booting off a zfs root and using a /boot.config file, zfsboot prints "Invalid format" unless /boot.config is at least 512 bytes. Everything still works, so this is a cosmetic/user-friendliness bug only. Looking at /sys/boot/i386/zfsboot/zfsboot.c, this appears to stem from xfsread() being used to load in /boot.config, and xfsread() wants to be able to read in a full buffer. Switching to using plain zfs_read() should fix it. Below is a one-liner patch to do so. Cheers, /Johny --- zfsboot.c.orig 2009-10-10 22:04:29.464823028 +1100 +++ zfsboot.c 2009-10-10 22:05:06.766834831 +1100 @@ -609,7 +609,7 @@ if (zfs_lookup(spa, PATH_CONFIG, &dn) == 0) { off = 0; - xfsread(&dn, &off, cmd, sizeof(cmd)); + zfs_read(spa, &dn, &off, cmd, sizeof(cmd)); } if (*cmd) { From jrh29 at alumni.cwru.edu Sat Oct 10 13:39:39 2009 From: jrh29 at alumni.cwru.edu (Justin Hibbits) Date: Sat Oct 10 13:39:46 2009 Subject: Fwd: Signals and an exiting thread In-Reply-To: References: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> <20091002201213.GA16633@stack.nl> <20091005192144.GA2259@deviant.kiev.zoral.com.ua> <4AD01ABC.50901@freebsd.org> Message-ID: I really need to change gmail to reply to all by default. ---------- Forwarded message ---------- From: Justin Hibbits Date: Sat, Oct 10, 2009 at 9:38 AM Subject: Re: Signals and an exiting thread To: David Xu On Sat, Oct 10, 2009 at 1:25 AM, David Xu wrote: > Kostik Belousov wrote: > > I agree that postponing assignment of the thread for signal delivery >> till the actual delivery occurs is the proper fix. I tried to cheat >> in my previous patch. Below is an experimental change that did very >> minimal testing. >> >> > > Even if the signal is put into process's signal queue, it is still > possible that signal notification is lost because selected thread > exits before seeing it, if other threads are sleeping, they are > not notified, this leaves signal in process queue long time before > it can be delivered to userland. Unless they're in an uninterruptible sleep, wouldn't they be woken when the signal is processed? It might need work to give a second pass over the threads after one dies, but I think that could be done when handling the next task schedule. - Justin From ganbold at micom.mng.net Sat Oct 10 14:14:51 2009 From: ganbold at micom.mng.net (Ganbold) Date: Sat Oct 10 14:14:58 2009 Subject: ported run driver In-Reply-To: <989483.352.qm@web51802.mail.re2.yahoo.com> References: <989483.352.qm@web51802.mail.re2.yahoo.com> Message-ID: <4AD090CA.9000503@micom.mng.net> Tango wrote: > Hello, > > I have ported run (ru'N' not ru'M') driver and posted on freebsd forum. > http://forums.freebsd.org/showthread.php?s=91e5d3d58be54728b80686a77c8428cd&t=7562 > Then, one member suggested to email you so some developers can review the code. > That is great. I have one these small USB device Planex GW-USMicroN and I was thinking to work on openbsd if_run driver, but somehow couldn't allocate the time for it :( I will definitely test if_run driver that you ported, however my laptop's CURRENT is really old so I have to update that one first :) Let us know once you port it to CURRENT. thanks, Ganbold Ts. > Also, one of mailing list subscribers recommended to port to current, so I'm planing to do that. > > I'm new to freebsd. Any comments/suggestions would be appreciated. > > Thank you. > Akinori > > > __________________________________________________________________ > Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > -- He who spends a storm beneath a tree, takes life with a grain of TNT. From hselasky at c2i.net Sat Oct 10 14:30:01 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Oct 10 14:30:07 2009 Subject: ported run driver In-Reply-To: <4AD090CA.9000503@micom.mng.net> References: <989483.352.qm@web51802.mail.re2.yahoo.com> <4AD090CA.9000503@micom.mng.net> Message-ID: <200910101630.50752.hselasky@c2i.net> On Saturday 10 October 2009 15:48:58 Ganbold wrote: > Tango wrote: > > Hello, > > > > I have ported run (ru'N' not ru'M') driver and posted on freebsd forum. > > http://forums.freebsd.org/showthread.php?s=91e5d3d58be54728b80686a77c8428 > >cd&t=7562 Then, one member suggested to email you so some developers can > > review the code. > > That is great. I have one these small USB device Planex GW-USMicroN and > I was thinking to work on openbsd if_run driver, but somehow couldn't > allocate the time for it :( > I will definitely test if_run driver that you ported, however my > laptop's CURRENT is really old so I have to update that one first :) > Let us know once you port it to CURRENT. > > thanks, > > Ganbold Ts. Hi, Regarding -current, there should be plenty of Wireless USB device drivers to look at! --HPS From kostikbel at gmail.com Sat Oct 10 14:36:50 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Oct 10 14:36:58 2009 Subject: Signals and an exiting thread In-Reply-To: <4AD01ABC.50901@freebsd.org> References: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> <20091002201213.GA16633@stack.nl> <20091005192144.GA2259@deviant.kiev.zoral.com.ua> <4AD01ABC.50901@freebsd.org> Message-ID: <20091010143643.GA2259@deviant.kiev.zoral.com.ua> On Sat, Oct 10, 2009 at 01:25:16PM +0800, David Xu wrote: > Kostik Belousov wrote: > > >I agree that postponing assignment of the thread for signal delivery > >till the actual delivery occurs is the proper fix. I tried to cheat > >in my previous patch. Below is an experimental change that did very > >minimal testing. > > > > Even if the signal is put into process's signal queue, it is still > possible that signal notification is lost because selected thread > exits before seeing it, if other threads are sleeping, they are > not notified, this leaves signal in process queue long time before > it can be delivered to userland. > Agreed. Actually, there is one more race. Namely, when thread enters kernel for executing sigprocmask syscall, but still did not acquired process mutex, some signal may be scheduled for the thread which will block it later while still in kernel, so wakeup is lost again. I did fixed that in later version of the patch, by waking up possible target threads that have newly blocked signals unblocked. Resulting code seems to be relevant for exiting thread as well, where we also shall set sigmask to indicate that thread is not willing (cannot) handle any further signals. Updated patch below. diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 0386fc4..9e61ea8 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -220,6 +220,8 @@ static int sigproptbl[NSIG] = { SA_KILL|SA_PROC, /* SIGUSR2 */ }; +static void reschedule_signals(struct proc *p, sigset_t block); + static void sigqueue_start(void) { @@ -581,20 +583,11 @@ void signotify(struct thread *td) { struct proc *p; - sigset_t set; p = td->td_proc; PROC_LOCK_ASSERT(p, MA_OWNED); - /* - * If our mask changed we may have to move signal that were - * previously masked by all threads to our sigqueue. - */ - set = p->p_sigqueue.sq_signals; - SIGSETNAND(set, td->td_sigmask); - if (! SIGISEMPTY(set)) - sigqueue_move_set(&p->p_sigqueue, &td->td_sigqueue, &set); if (SIGPENDING(td)) { thread_lock(td); td->td_flags |= TDF_NEEDSIGCHK | TDF_ASTPENDING; @@ -976,24 +969,28 @@ execsigs(struct proc *p) * Manipulate signal mask. */ int -kern_sigprocmask(td, how, set, oset, old) - struct thread *td; - int how; - sigset_t *set, *oset; - int old; +kern_sigprocmask(struct thread *td, int how, sigset_t *set, sigset_t *oset, + int old) { + sigset_t new_block, oset1; + struct proc *p; int error; - PROC_LOCK(td->td_proc); + p = td->td_proc; + PROC_LOCK(p); if (oset != NULL) *oset = td->td_sigmask; error = 0; + SIGEMPTYSET(new_block); if (set != NULL) { switch (how) { case SIG_BLOCK: SIG_CANTMASK(*set); + oset1 = td->td_sigmask; SIGSETOR(td->td_sigmask, *set); + new_block = td->td_sigmask; + SIGSETNAND(new_block, oset1); break; case SIG_UNBLOCK: SIGSETNAND(td->td_sigmask, *set); @@ -1001,10 +998,13 @@ kern_sigprocmask(td, how, set, oset, old) break; case SIG_SETMASK: SIG_CANTMASK(*set); + oset1 = td->td_sigmask; if (old) SIGSETLO(td->td_sigmask, *set); else td->td_sigmask = *set; + new_block = td->td_sigmask; + SIGSETNAND(new_block, oset1); signotify(td); break; default: @@ -1012,7 +1012,20 @@ kern_sigprocmask(td, how, set, oset, old) break; } } - PROC_UNLOCK(td->td_proc); + + /* + * The new_block set contains signals that were not previosly + * blocked, but are blocked now. + * + * In case we block any signal that was not previously blocked + * for td, and process has the signal pending, try to schedule + * signal delivery to some thread that does not block the signal, + * possibly waking it up. + */ + if (p->p_numthreads != 1) + reschedule_signals(p, new_block); + + PROC_UNLOCK(p); return (error); } @@ -1985,17 +1998,9 @@ tdsignal(struct proc *p, struct thread *td, int sig, ksiginfo_t *ksi) KNOTE_LOCKED(&p->p_klist, NOTE_SIGNAL | sig); prop = sigprop(sig); - /* - * If the signal is blocked and not destined for this thread, then - * assign it to the process so that we can find it later in the first - * thread that unblocks it. Otherwise, assign it to this thread now. - */ if (td == NULL) { td = sigtd(p, sig, prop); - if (SIGISMEMBER(td->td_sigmask, sig)) - sigqueue = &p->p_sigqueue; - else - sigqueue = &td->td_sigqueue; + sigqueue = &p->p_sigqueue; } else { KASSERT(td->td_proc == p, ("invalid thread")); sigqueue = &td->td_sigqueue; @@ -2392,6 +2397,62 @@ stopme: return (td->td_xsig); } +static void +reschedule_signals(struct proc *p, sigset_t block) +{ + struct sigacts *ps; + struct thread *td; + int i; + + PROC_LOCK_ASSERT(p, MA_OWNED); + + ps = p->p_sigacts; + for (i = 0; !SIGISEMPTY(block); i++) { + if (!SIGISMEMBER(block, i)) + continue; + SIGDELSET(block, i); + if (!SIGISMEMBER(p->p_siglist, i)) + continue; + + td = sigtd(p, i, 0); + signotify(td); + mtx_lock(&ps->ps_mtx); + if (p->p_flag & P_TRACED || SIGISMEMBER(ps->ps_sigcatch, i)) + tdsigwakeup(td, i, SIG_CATCH, + (SIGISMEMBER(ps->ps_sigintr, i) ? EINTR : + ERESTART)); + mtx_unlock(&ps->ps_mtx); + } +} + +void +tdsigcleanup(struct thread *td) +{ + struct proc *p; + sigset_t unblocked; + + p = td->td_proc; + PROC_LOCK_ASSERT(p, MA_OWNED); + + sigqueue_flush(&td->td_sigqueue); + if (p->p_numthreads == 1) + return; + + /* + * Since we cannot handle signals, notify signal post code + * about this by filling the sigmask. + * + * Also, if needed, wake up thread(s) that do not block the + * same signals as the exiting thread, since the thread might + * have been selected for delivery and woken up. + */ + SIGFILLSET(unblocked); + SIGSETNAND(unblocked, td->td_sigmask); + SIGFILLSET(td->td_sigmask); + reschedule_signals(p, unblocked); + +} + /* * If the current process has received a signal (should be caught or cause * termination, should interrupt current syscall), return the signal number. @@ -2409,8 +2470,9 @@ issignal(struct thread *td, int stop_allowed) { struct proc *p; struct sigacts *ps; + struct sigqueue *queue; sigset_t sigpending; - int sig, prop, newsig; + int sig, prop, newsig, signo; p = td->td_proc; ps = p->p_sigacts; @@ -2420,6 +2482,7 @@ issignal(struct thread *td, int stop_allowed) int traced = (p->p_flag & P_TRACED) || (p->p_stops & S_SIG); sigpending = td->td_sigqueue.sq_signals; + SIGSETOR(sigpending, p->p_sigqueue.sq_signals); SIGSETNAND(sigpending, td->td_sigmask); if (p->p_flag & P_PPWAIT) @@ -2440,6 +2503,7 @@ issignal(struct thread *td, int stop_allowed) */ if (SIGISMEMBER(ps->ps_sigignore, sig) && (traced == 0)) { sigqueue_delete(&td->td_sigqueue, sig); + sigqueue_delete(&p->p_sigqueue, sig); continue; } if (p->p_flag & P_TRACED && (p->p_flag & P_PPWAIT) == 0) { @@ -2452,12 +2516,18 @@ issignal(struct thread *td, int stop_allowed) if (sig != newsig) { ksiginfo_t ksi; + + queue = &td->td_sigqueue; /* * clear old signal. * XXX shrug off debugger, it causes siginfo to * be thrown away. */ - sigqueue_get(&td->td_sigqueue, sig, &ksi); + if (sigqueue_get(queue, sig, &ksi) == 0) { + queue = &p->p_sigqueue; + signo = sigqueue_get(queue, sig, &ksi); + KASSERT(signo == sig, ("signo != sig")); + } /* * If parent wants us to take the signal, @@ -2472,7 +2542,7 @@ issignal(struct thread *td, int stop_allowed) * Put the new signal into td_sigqueue. If the * signal is being masked, look for other signals. */ - SIGADDSET(td->td_sigqueue.sq_signals, sig); + SIGADDSET(queue->sq_signals, sig); if (SIGISMEMBER(td->td_sigmask, sig)) continue; signotify(td); @@ -2567,6 +2637,7 @@ issignal(struct thread *td, int stop_allowed) return (sig); } sigqueue_delete(&td->td_sigqueue, sig); /* take the signal! */ + sigqueue_delete(&p->p_sigqueue, sig); } /* NOTREACHED */ } @@ -2613,7 +2684,9 @@ postsig(sig) ps = p->p_sigacts; mtx_assert(&ps->ps_mtx, MA_OWNED); ksiginfo_init(&ksi); - sigqueue_get(&td->td_sigqueue, sig, &ksi); + if (sigqueue_get(&td->td_sigqueue, sig, &ksi) == 0 && + sigqueue_get(&p->p_sigqueue, sig, &ksi) == 0) + return; ksi.ksi_signo = sig; if (ksi.ksi_code == SI_TIMER) itimer_accept(p, ksi.ksi_timerid, &ksi); diff --git a/sys/kern/kern_thr.c b/sys/kern/kern_thr.c index 630069b..3159a91 100644 --- a/sys/kern/kern_thr.c +++ b/sys/kern/kern_thr.c @@ -282,7 +282,7 @@ thr_exit(struct thread *td, struct thr_exit_args *uap) } PROC_LOCK(p); - sigqueue_flush(&td->td_sigqueue); + tdsigcleanup(td); PROC_SLOCK(p); /* diff --git a/sys/kern/subr_trap.c b/sys/kern/subr_trap.c index 6d60ddb..ccf6479 100644 --- a/sys/kern/subr_trap.c +++ b/sys/kern/subr_trap.c @@ -90,6 +90,7 @@ userret(struct thread *td, struct trapframe *frame) CTR3(KTR_SYSC, "userret: thread %p (pid %d, %s)", td, p->p_pid, td->td_name); +#if 0 #ifdef DIAGNOSTIC /* Check that we called signotify() enough. */ PROC_LOCK(p); @@ -100,6 +101,7 @@ userret(struct thread *td, struct trapframe *frame) thread_unlock(td); PROC_UNLOCK(p); #endif +#endif #ifdef KTRACE KTRUSERRET(td); #endif @@ -218,7 +220,14 @@ ast(struct trapframe *framep) ktrcsw(0, 1); #endif } - if (flags & TDF_NEEDSIGCHK) { + + /* + * Check for signals. Unlocked reads of p_pendingcnt or + * p_siglist might cause process-directed signal to be handled + * later. + */ + if (flags & TDF_NEEDSIGCHK || p->p_pendingcnt > 0 || + !SIGISEMPTY(p->p_siglist)) { PROC_LOCK(p); mtx_lock(&p->p_sigacts->ps_mtx); while ((sig = cursig(td, SIG_STOP_ALLOWED)) != 0) diff --git a/sys/sys/signalvar.h b/sys/sys/signalvar.h index 89b40f0..b39f2bf 100644 --- a/sys/sys/signalvar.h +++ b/sys/sys/signalvar.h @@ -252,9 +252,10 @@ typedef struct sigqueue { /* Return nonzero if process p has an unmasked pending signal. */ #define SIGPENDING(td) \ - (!SIGISEMPTY((td)->td_siglist) && \ - !sigsetmasked(&(td)->td_siglist, &(td)->td_sigmask)) - + ((!SIGISEMPTY((td)->td_siglist) && \ + !sigsetmasked(&(td)->td_siglist, &(td)->td_sigmask)) || \ + (!SIGISEMPTY((td)->td_proc->p_siglist) && \ + !sigsetmasked(&(td)->td_proc->p_siglist, &(td)->td_sigmask))) /* * Return the value of the pseudo-expression ((*set & ~*mask) != 0). This * is an optimized version of SIGISEMPTY() on a temporary variable @@ -336,6 +337,7 @@ void sigexit(struct thread *td, int signum) __dead2; int sig_ffs(sigset_t *set); void siginit(struct proc *p); void signotify(struct thread *td); +void tdsigcleanup(struct thread *td); int tdsignal(struct proc *p, struct thread *td, int sig, ksiginfo_t *ksi); void trapsignal(struct thread *td, ksiginfo_t *); diff --git a/tools/regression/sigqueue/sigqtest1/sigqtest1.c b/tools/regression/sigqueue/sigqtest1/sigqtest1.c index 0f40021..f0201c3 100644 --- a/tools/regression/sigqueue/sigqtest1/sigqtest1.c +++ b/tools/regression/sigqueue/sigqtest1/sigqtest1.c @@ -1,12 +1,14 @@ /* $FreeBSD$ */ -#include -#include #include #include +#include +#include +#include int received; -void handler(int sig, siginfo_t *si, void *ctx) +void +handler(int sig, siginfo_t *si, void *ctx) { if (si->si_code != SI_QUEUE) errx(1, "si_code != SI_QUEUE"); @@ -15,7 +17,8 @@ void handler(int sig, siginfo_t *si, void *ctx) received++; } -int main() +int +main() { struct sigaction sa; union sigval val; diff --git a/tools/regression/sigqueue/sigqtest2/sigqtest2.c b/tools/regression/sigqueue/sigqtest2/sigqtest2.c index 078ea81..50b579d 100644 --- a/tools/regression/sigqueue/sigqtest2/sigqtest2.c +++ b/tools/regression/sigqueue/sigqtest2/sigqtest2.c @@ -1,24 +1,29 @@ /* $FreeBSD$ */ -#include -#include -#include -#include #include #include +#include +#include +#include +#include +#include +#include int stop_received; int exit_received; int cont_received; -void job_handler(int sig, siginfo_t *si, void *ctx) +void +job_handler(int sig, siginfo_t *si, void *ctx) { int status; int ret; if (si->si_code == CLD_STOPPED) { + printf("%d: stop received\n", si->si_pid); stop_received = 1; kill(si->si_pid, SIGCONT); } else if (si->si_code == CLD_EXITED) { + printf("%d: exit received\n", si->si_pid); ret = waitpid(si->si_pid, &status, 0); if (ret == -1) errx(1, "waitpid"); @@ -26,11 +31,13 @@ void job_handler(int sig, siginfo_t *si, void *ctx) errx(1, "!WIFEXITED(status)"); exit_received = 1; } else if (si->si_code == CLD_CONTINUED) { + printf("%d: cont received\n", si->si_pid); cont_received = 1; } } -void job_control_test() +void +job_control_test(void) { struct sigaction sa; pid_t pid; @@ -43,9 +50,12 @@ void job_control_test() stop_received = 0; cont_received = 0; exit_received = 0; + fflush(stdout); pid = fork(); if (pid == 0) { + printf("child %d\n", getpid()); kill(getpid(), SIGSTOP); + sleep(2); exit(1); } @@ -60,11 +70,13 @@ void job_control_test() printf("job control test OK.\n"); } -void rtsig_handler(int sig, siginfo_t *si, void *ctx) +void +rtsig_handler(int sig, siginfo_t *si, void *ctx) { } -int main() +int +main() { struct sigaction sa; sigset_t set; -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091010/5d19b3de/attachment.pgp From syso.fml at ext.no-route.org Sat Oct 10 14:41:22 2009 From: syso.fml at ext.no-route.org (Sylwester Sosnowski) Date: Sat Oct 10 14:41:37 2009 Subject: Support for PC Engines ALIX2 reset pushbutton. In-Reply-To: <4ACF9CE7.30808@tomjudge.com> References: <4ACF131C.1060201@ext.no-route.org> <4ACF9CE7.30808@tomjudge.com> Message-ID: <4AD09D0F.5030700@ext.no-route.org> Tom Judge schrieb: > Hi Sylwester, Hi, > > This is interesting, what boards should be supported? (I have a couple > of 2d3's) As far as I can see this should work with any Alix2xx boards (I'm using a 2d13, which is a new version of the 2d3 with a RTC-Battery, some extra Pin headers, ..) but maybe it's also compatible with Alix6xx. I guess you can check out the schematic on the vendor's site. > I will be needing something like this for my current project as well. Well, feel free to use it. > Thanks You're welcome. > TJ Regards, Sylwester From bsam at ipt.ru Sat Oct 10 15:08:07 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Sat Oct 10 15:08:13 2009 Subject: [amd64, lib32] ccache and buldworld: suffix or operands invalid for `mov' In-Reply-To: <10236192@bb.ipt.ru> (Boris Samorodov's message of "Sat, 10 Oct 2009 19:05:35 +0400") References: <10236192@bb.ipt.ru> Message-ID: <22716042@bb.ipt.ru> Hello List, I'm new to using devel/ccache, so need help how to further diagnose the problem. The world builds fine without ccache. But with ccache enabled the following error occures: ----- ===> lib/csu/i386-elf (obj,depend,all,install) rm -f .depend CC='/usr/local/libexec/ccache/world-cc' mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include /usr/src/lib/csu/i386-elf/crt1.c /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S /usr/local/libexec/ccache/world-cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crt1.c {standard input}: Assembler messages: {standard input}:27: Error: suffix or operands invalid for `mov' *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 ----- That is for: ----- % uname -a FreeBSD tba.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon Oct 5 19:56:42 MSD 2009 root@tba.ipt.ru:/usr/obj/usr/src/sys/TBA amd64 % ccache -V ccache version 2.4 ----- So is it a ccache or FreeBSD sources or /dev/hands to blame? What to do further? Thanks. -- 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 Sat Oct 10 16:08:10 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Sat Oct 10 16:08:18 2009 Subject: [amd64, lib32] ccache and buldworld: suffix or operands invalid for `mov' In-Reply-To: <22716042@bb.ipt.ru> (Boris Samorodov's message of "Sat, 10 Oct 2009 19:08:05 +0400") References: <10236192@bb.ipt.ru> <22716042@bb.ipt.ru> Message-ID: <90552439@bb.ipt.ru> On Sat, 10 Oct 2009 19:08:05 +0400 Boris Samorodov wrote: > I'm new to using devel/ccache, so need help how to further diagnose > the problem. The world builds fine without ccache. But with ccache > enabled the following error occures: > ----- > ===> lib/csu/i386-elf (obj,depend,all,install) > rm -f .depend > CC='/usr/local/libexec/ccache/world-cc' mkdep -f .depend -a -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include /usr/src/lib/csu/i386-elf/crt1.c /usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S > /usr/local/libexec/ccache/world-cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /usr/src/lib/csu/i386-elf/crt1.c > {standard input}: Assembler messages: > {standard input}:27: Error: suffix or operands invalid for `mov' > *** Error code 1 > Stop in /usr/src/lib/csu/i386-elf. > *** Error code 1 > ----- > That is for: > ----- > % uname -a > FreeBSD tba.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon Oct 5 19:56:42 MSD 2009 root@tba.ipt.ru:/usr/obj/usr/src/sys/TBA amd64 > % ccache -V > ccache version 2.4 > ----- > So is it a ccache or FreeBSD sources or /dev/hands to blame? > What to do further? Thanks. David Wolfskill adviced to clean the cache. That didn't work, the same error. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From h.schmalzbauer at omnilan.de Sat Oct 10 16:49:12 2009 From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer) Date: Sat Oct 10 16:49:19 2009 Subject: shutdown not working with uart console Message-ID: <4AD0BAFB.6020207@omnilan.de> Dear coders, I recognized one RELENG_8 problem when trying to shutdown via serial console. While shutdown via SSH works like expected, when called via serial console it keeps hanging forever. I compiled a debug kernel for my embedded device and got the following backtrace: ~KDB: enter: Line break on console [thread pid 1102 tid 100074 ] Stopped at kdb_enter+0x3b: movl $0,kdb_why db> bt Tracing pid 1102 tid 100074 td 0xc36c26c0 kdb_enter(c08aca1d,c08b61ae,d5c5e894,c35a0180,0,...) at kdb_enter+0x3b uart_intr(c35a0100,c36c26c0,c344a900,c347b0d0,4,...) at uart_intr+0x298 intr_event_handle(c344a900,d5c5e8ac,c36c26c0,c37a9ad0,1ce,...) at intr_event_handle+0x4b intr_execute_handlers(c347b0d0,d5c5e8ac,0,d5c5e90c,c0852ed4,...) at intr_execute_handlers+0x48 lapic_handle_intr(38,d5c5e8ac) at lapic_handle_intr+0x3a Xapic_isr1() at Xapic_isr1+0x34 --- interrupt, eip = 0xc05d0814, esp = 0xd5c5e8ec, ebp = 0xd5c5e90c --- _lockmgr_assert(c37a9ad0,1,c08d41d6,1ce,d5c5e940,...) at _lockmgr_assert+0x13e __lockmgr_args(c37a9ad0,100000,c37a9aec,0,0,...) at __lockmgr_args+0x16b vop_stdunlock(d5c5e9ec,0,c36c26c0,80000,c37a9a78,...) at vop_stdunlock+0x55 VOP_UNLOCK_APV(c0912b40,d5c5e9ec,c091d71c,c09477e0,c37a9a78,...) at VOP_UNLOCK_APV+0x9a _vn_lock(c37a9a78,80100,c08d4ec2,823,c08c5fec,...) at _vn_lock+0xbc vget(c37a9a78,80100,c36c26c0,4f3,c37a9a78,...) at vget+0x61 devfs_revoke(d5c5eaa4,d5c5eaa4,c08c2b09,157,c36cf330,...) at devfs_revoke+0x210 exit1(c36c26c0,1,c08c78e8,ab6,3,...) at exit1+0x9ff sigexit(c36c26c0,1,c08c78e8,a49,0,...) at sigexit+0x84 postsig(1,64,c08cc013,df,c36cf2a8,...) at postsig+0x34d ast(d5c5ed38) at ast+0x42f doreti_ast() at doreti_ast+0x17 I have no idea where the problem is, nor how to get more info. Any help appreciated. Thanks in advance, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091010/3ec5df57/signature.pgp From miki.bsd at gmail.com Sat Oct 10 16:58:07 2009 From: miki.bsd at gmail.com (Miki) Date: Sat Oct 10 16:58:14 2009 Subject: SIGBUS with sftp from OpenSSH 5.3 Message-ID: <261c29700910100933ked4245bg47f0cf826a1c3a10@mail.gmail.com> Hi all, sftp from OpenSSH 5.3 exit on a SIGBUS when trying to fetch a file. sftp from OpenSSH 5.2 worked fine. here is a backtrace : #0 0x000000000040b3cf in ?? () #1 0x0000000800efb8b0 in globfree () from /lib/libc.so.7 #2 0x0000000800efbe01 in globfree () from /lib/libc.so.7 #3 0x0000000800efc491 in glob () from /lib/libc.so.7 #4 0x000000000040a77f in remote_glob (conn=0x801a08740, pattern=0x801a0b080 "/home/miki/mech", flags=0, errfunc=0, pglob=0x7fffffffd680) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp-glob.c:148 #5 0x00000000004038f4 in process_get (conn=0x801a08740, src=0x801a0b070 "/home/miki/mech", dst=0x801a04080 "/tmp/", pwd=0x801a0b050 "/home/miki", pflag=0) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:507 #6 0x00000000004059c7 in parse_dispatch_command (conn=0x801a08740, cmd=0x7fffffffdcb0 "get /home/miki/mech /tmp/", pwd=0x7fffffffdc98, err_abort=1) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:1264 #7 0x00000000004067ec in interactive_loop (fd_in=3, fd_out=3, file1=0x801a0b04a "mech", file2=0x7fffffffe981 "/tmp/") at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:1531 #8 0x000000000040733b in main (argc=3, argv=0x7fffffffe5c8) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:1825 I'm running FreeBSD cocyte.homeunix.org 9.0-CURRENT FreeBSD 9.0-CURRENT #6 r197928M: Sat Oct 10 13:37:22 CEST 2009 miki@cocyte.homeunix.org:/usr/obj/usr/src/sys/COCYTE amd64 Kernel and userland are in sync. I can provide full backtrace or more debugging information if necessary. Thanks. Miki From kostikbel at gmail.com Sat Oct 10 17:51:20 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Oct 10 17:51:27 2009 Subject: shutdown not working with uart console In-Reply-To: <4AD0BAFB.6020207@omnilan.de> References: <4AD0BAFB.6020207@omnilan.de> Message-ID: <20091010175115.GC2259@deviant.kiev.zoral.com.ua> On Sat, Oct 10, 2009 at 06:48:59PM +0200, Harald Schmalzbauer wrote: > Dear coders, > > I recognized one RELENG_8 problem when trying to shutdown via serial > console. While shutdown via SSH works like expected, when called via > serial console it keeps hanging forever. > I compiled a debug kernel for my embedded device and got the following > backtrace: > ~KDB: enter: Line break on console > [thread pid 1102 tid 100074 ] > Stopped at kdb_enter+0x3b: movl $0,kdb_why > db> bt > Tracing pid 1102 tid 100074 td 0xc36c26c0 > kdb_enter(c08aca1d,c08b61ae,d5c5e894,c35a0180,0,...) at kdb_enter+0x3b > uart_intr(c35a0100,c36c26c0,c344a900,c347b0d0,4,...) at uart_intr+0x298 > intr_event_handle(c344a900,d5c5e8ac,c36c26c0,c37a9ad0,1ce,...) at > intr_event_handle+0x4b > intr_execute_handlers(c347b0d0,d5c5e8ac,0,d5c5e90c,c0852ed4,...) at > intr_execute_handlers+0x48 > lapic_handle_intr(38,d5c5e8ac) at lapic_handle_intr+0x3a > Xapic_isr1() at Xapic_isr1+0x34 > --- interrupt, eip = 0xc05d0814, esp = 0xd5c5e8ec, ebp = 0xd5c5e90c --- > _lockmgr_assert(c37a9ad0,1,c08d41d6,1ce,d5c5e940,...) at > _lockmgr_assert+0x13e > __lockmgr_args(c37a9ad0,100000,c37a9aec,0,0,...) at __lockmgr_args+0x16b > vop_stdunlock(d5c5e9ec,0,c36c26c0,80000,c37a9a78,...) at vop_stdunlock+0x55 > VOP_UNLOCK_APV(c0912b40,d5c5e9ec,c091d71c,c09477e0,c37a9a78,...) at > VOP_UNLOCK_APV+0x9a > _vn_lock(c37a9a78,80100,c08d4ec2,823,c08c5fec,...) at _vn_lock+0xbc > vget(c37a9a78,80100,c36c26c0,4f3,c37a9a78,...) at vget+0x61 > devfs_revoke(d5c5eaa4,d5c5eaa4,c08c2b09,157,c36cf330,...) at > devfs_revoke+0x210 > exit1(c36c26c0,1,c08c78e8,ab6,3,...) at exit1+0x9ff > sigexit(c36c26c0,1,c08c78e8,a49,0,...) at sigexit+0x84 > postsig(1,64,c08cc013,df,c36cf2a8,...) at postsig+0x34d > ast(d5c5ed38) at ast+0x42f > doreti_ast() at doreti_ast+0x17 > > I have no idea where the problem is, nor how to get more info. > Any help appreciated. I wondering whether I was too conservative in r195509. Please try this. diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c index 39b48e0..b96cdbf 100644 --- a/sys/kern/kern_exit.c +++ b/sys/kern/kern_exit.c @@ -340,10 +340,10 @@ exit1(struct thread *td, int rv) if (ttyvp != NULL) { sx_xunlock(&proctree_lock); - vn_lock(ttyvp, LK_EXCLUSIVE | LK_RETRY); - if (ttyvp->v_type != VBAD) + if (vn_lock(ttyvp, LK_EXCLUSIVE) == 0) { VOP_REVOKE(ttyvp, REVOKEALL); - VOP_UNLOCK(ttyvp, 0); + VOP_UNLOCK(ttyvp, 0); + } sx_xlock(&proctree_lock); } } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091010/ceea8b2e/attachment.pgp From ehrmann at gmail.com Sat Oct 10 19:38:17 2009 From: ehrmann at gmail.com (David Ehrmann) Date: Sat Oct 10 19:38:24 2009 Subject: Strange md/unionfs issue Message-ID: <4AD0E286.9030508@gmail.com> I have a system running on a flash disk. To prevent it from wearing out quickly, I don't run with a swap and mount /tmp and /var from memory. Because /var needs some directories and contains files I probably should save from time to time, I mount it from flash, mount /var to /var_real so I can access the underlying files, and then I mount an md device on top of /var as a unionfs. Initially, it seems to work, but seconds later, the unionfs seems to fail. server# cd /var server# ls .snap crash heimdal preserve yp account cron log run at db mail rwho audit empty msgs spool backups games named tmp server# mount /dev/ad0s1a on / (ufs, NFS exported, local) devfs on /dev (devfs, local, multilabel) /dev/ad0s1f on /usr (ufs, local, soft-updates) /dev/ad0s1e on /var (ufs, local, soft-updates) /var on /var_real (nullfs, local, noatime) /dev/md0 on /var (ufs, local, union, soft-updates) /dev/md1 on /tmp (ufs, local, soft-updates) server# cd /var_real/ server# ls .snap crash heimdal preserve yp account cron log run at db mail rwho audit empty msgs spool backups games named tmp server# cd /var server# ls .snap server# Removing /var_real from the fstab didn't help. Here's the full version: # Device Mountpoint FStype Options Dump Pass# /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1f /usr ufs rw 2 2 /dev/ad0s1e /var ufs rw 2 2 /var /var_real nullfs rw,noatime md /var mfs rw,union,-s128M md /tmp mfs rw,-s128M Ideas? From h.schmalzbauer at omnilan.de Sat Oct 10 20:14:37 2009 From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer) Date: Sat Oct 10 20:14:44 2009 Subject: shutdown not working with uart console In-Reply-To: <20091010175115.GC2259@deviant.kiev.zoral.com.ua> References: <4AD0BAFB.6020207@omnilan.de> <20091010175115.GC2259@deviant.kiev.zoral.com.ua> Message-ID: <4AD0EB24.5020700@omnilan.de> Kostik Belousov schrieb am 10.10.2009 19:51 (localtime): ... > I wondering whether I was too conservative in r195509. > Please try this. > > diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c > index 39b48e0..b96cdbf 100644 > --- a/sys/kern/kern_exit.c > +++ b/sys/kern/kern_exit.c > @@ -340,10 +340,10 @@ exit1(struct thread *td, int rv) > > if (ttyvp != NULL) { > sx_xunlock(&proctree_lock); > - vn_lock(ttyvp, LK_EXCLUSIVE | LK_RETRY); > - if (ttyvp->v_type != VBAD) > + if (vn_lock(ttyvp, LK_EXCLUSIVE) == 0) { > VOP_REVOKE(ttyvp, REVOKEALL); > - VOP_UNLOCK(ttyvp, 0); > + VOP_UNLOCK(ttyvp, 0); > + } > sx_xlock(&proctree_lock); > } > } Great, thanks a lot, this fixes my problem :) There's one LOR left at shutdown (vfs_mount+ffs_vfsops) and one at startup (unionfs+ufs) but that's completele unrelated I guess. Thanks, -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091010/7a1dde31/signature.pgp From h.schmalzbauer at omnilan.de Sat Oct 10 20:25:06 2009 From: h.schmalzbauer at omnilan.de (Harald Schmalzbauer) Date: Sat Oct 10 20:25:13 2009 Subject: Where to report LORs? (ffs and unionfs LORs included In-Reply-To: References: Message-ID: <4AD0ED9F.3080706@omnilan.de> Alexander Best schrieb am 07.07.2009 21:33 (localtime): > try http://sources.zabbadoz.net/freebsd/lor.html I still see a unionfs LOR with RELENG_8 which is not listed, so I'd like to report it again. lock order reversal: 1st 0xc372c488 unionfs (unionfs) @ /FlashBSD/src/sys/fs/unionfs/union_subr.c:356 2nd 0xc372c594 ufs (ufs) @ /FlashBSD/src/sys/kern/vfs_subr.c:2188 KDB: stack backtrace: db_trace_self_wrapper(c0616390,c08cd5d5,c3416770,c3416500,d5c42864,...) at db_trace_self_wrapper+0x26 _witness_debugger(c08cd5d5,c372c594,c08c0703,c3416500,c08d4ec2,...) at _witness_debugger+0x49 witness_checkorder(c372c594,9,c08d4ec2,88c,0,...) at witness_checkorder+0x6ec __lockmgr_args(c372c594,80100,c372c5b0,0,0,...) at __lockmgr_args+0xc97 ffs_lock(d5c42958,8,c36c4764,80100,c372c53c,...) at ffs_lock+0x96 VOP_LOCK1_APV(c09374a0,d5c42958,c05d89e9,c09477c0,c372c53c,...) at VOP_LOCK1_APV+0x9a _vn_lock(c372c53c,80100,c08d4ec2,88c,c0877c6e,...) at _vn_lock+0x46 vrele(c372c53c,d5c429d8,c372c4a4,0,0,...) at vrele+0x12a unionfs_noderem(c372c430,c36c46c0,d5c42a44,c06764fc,d5c42a20,...) at unionfs_noderem+0x1e5 unionfs_reclaim(d5c42a20,d5c42a20,0,0,c372c4a4,...) at unionfs_reclaim+0x1b vgonel(c372c4a4,0,c08d4ec2,9c5,c372c4a4,...) at vgonel+0x100 vrecycle(c372c430,c36c46c0,d5c42aa4,c0675c29,d5c42a8c,...) at vrecycle+0x6a unionfs_inactive(d5c42a8c,d5c42a8c,c08d4ec2,924,c0947780,...) at unionfs_inactive+0x28 vinactive(c372c594,d5c42ac0,c08d4ec2,8aa,c3451de0,...) at vinactive+0x6a vput(c372c430,ffffffdf,c344ab80,0,c36c46c0,...) at vput+0x205 kern_statat_vnhook(c36c46c0,0,ffffff9c,28209e1c,0,...) at kern_statat_vnhook+0xe0 kern_statat(c36c46c0,0,ffffff9c,28209e1c,0,...) at kern_statat+0x3c kern_stat(c36c46c0,28209e1c,0,d5c42c18,c0a83a18,...) at kern_stat+0x36 stat(c36c46c0,d5c42cf8,8,d5c42d38,c0916cd0,...) at stat+0x2b syscall(d5c42d38) at syscall+0x176 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (188, FreeBSD ELF32, stat), eip = 0x281c6c2b, esp = 0xbfbfe96c, ebp = 0xbfbfea68 --- So far I couldn't notice any deadlock, but the box is not in production yet. -Harry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091010/d648b52f/signature.pgp From ehrmann at gmail.com Sat Oct 10 21:49:09 2009 From: ehrmann at gmail.com (David Ehrmann) Date: Sat Oct 10 21:49:24 2009 Subject: Strange md/unionfs issue In-Reply-To: <4AD0E286.9030508@gmail.com> References: <4AD0E286.9030508@gmail.com> Message-ID: <4AD10135.9050002@gmail.com> David Ehrmann wrote: > I have a system running on a flash disk. To prevent it from wearing > out quickly, I don't run with a swap and mount /tmp and /var from > memory. Because /var needs some directories and contains files I > probably should save from time to time, I mount it from flash, mount > /var to /var_real so I can access the underlying files, and then I > mount an md device on top of /var as a unionfs. Initially, it seems > to work, but seconds later, the unionfs seems to fail. > > server# cd /var > server# ls > .snap crash heimdal preserve yp > account cron log run > at db mail rwho > audit empty msgs spool > backups games named tmp > server# mount > /dev/ad0s1a on / (ufs, NFS exported, local) > devfs on /dev (devfs, local, multilabel) > /dev/ad0s1f on /usr (ufs, local, soft-updates) > /dev/ad0s1e on /var (ufs, local, soft-updates) > /var on /var_real (nullfs, local, noatime) > /dev/md0 on /var (ufs, local, union, soft-updates) > /dev/md1 on /tmp (ufs, local, soft-updates) > server# cd /var_real/ > server# ls > .snap crash heimdal preserve yp > account cron log run > at db mail rwho > audit empty msgs spool > backups games named tmp > server# cd /var > server# ls > .snap > server# > > Removing /var_real from the fstab didn't help. Here's the full version: > > # Device Mountpoint FStype Options > Dump Pass# > /dev/ad0s1a / ufs rw 1 1 > /dev/ad0s1f /usr ufs rw 2 2 > > /dev/ad0s1e /var ufs rw 2 2 > /var /var_real nullfs rw,noatime > md /var mfs rw,union,-s128M > > md /tmp mfs rw,-s128M > > Ideas? > It looks like I don't have the problem if I mount the md on top of /var if /var is really on /, i.e. not a mount point. From dimitry at andric.com Sat Oct 10 22:04:22 2009 From: dimitry at andric.com (Dimitry Andric) Date: Sat Oct 10 22:04:29 2009 Subject: shutdown not working with uart console In-Reply-To: <4AD0EB24.5020700@omnilan.de> References: <4AD0BAFB.6020207@omnilan.de> <20091010175115.GC2259@deviant.kiev.zoral.com.ua> <4AD0EB24.5020700@omnilan.de> Message-ID: <4AD104E4.2070009@andric.com> On 2009-10-10 22:14, Harald Schmalzbauer wrote: >> I wondering whether I was too conservative in r195509. >> Please try this. >> >> diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c >> index 39b48e0..b96cdbf 100644 >> --- a/sys/kern/kern_exit.c >> +++ b/sys/kern/kern_exit.c >> @@ -340,10 +340,10 @@ exit1(struct thread *td, int rv) >> >> if (ttyvp != NULL) { >> sx_xunlock(&proctree_lock); >> - vn_lock(ttyvp, LK_EXCLUSIVE | LK_RETRY); >> - if (ttyvp->v_type != VBAD) >> + if (vn_lock(ttyvp, LK_EXCLUSIVE) == 0) { >> VOP_REVOKE(ttyvp, REVOKEALL); >> - VOP_UNLOCK(ttyvp, 0); >> + VOP_UNLOCK(ttyvp, 0); >> + } >> sx_xlock(&proctree_lock); >> } >> } > > Great, thanks a lot, this fixes my problem :) I had seen this issue too, some time ago, but disregarded it as just some anomaly. In any case, the above patch also fixes it for me. From faber at isi.edu Sun Oct 11 05:27:42 2009 From: faber at isi.edu (Ted Faber) Date: Sun Oct 11 05:27:51 2009 Subject: 80RC1 can't find onboard Intel PRO (pciconf & dmesg attached) Message-ID: <20091011052741.GA46868@zod.isi.edu> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091011/47b21206/attachment.pgp From davidxu at freebsd.org Sun Oct 11 06:33:08 2009 From: davidxu at freebsd.org (David Xu) Date: Sun Oct 11 06:33:15 2009 Subject: Signals and an exiting thread In-Reply-To: <20091010143643.GA2259@deviant.kiev.zoral.com.ua> References: <20091001120730.GR3130@deviant.kiev.zoral.com.ua> <20091002201213.GA16633@stack.nl> <20091005192144.GA2259@deviant.kiev.zoral.com.ua> <4AD01ABC.50901@freebsd.org> <20091010143643.GA2259@deviant.kiev.zoral.com.ua> Message-ID: <4AD17C1F.8020709@freebsd.org> Kostik Belousov wrote: > On Sat, Oct 10, 2009 at 01:25:16PM +0800, David Xu wrote: > >> Kostik Belousov wrote: >> >> >>> I agree that postponing assignment of the thread for signal delivery >>> till the actual delivery occurs is the proper fix. I tried to cheat >>> in my previous patch. Below is an experimental change that did very >>> minimal testing. >>> >>> >> Even if the signal is put into process's signal queue, it is still >> possible that signal notification is lost because selected thread >> exits before seeing it, if other threads are sleeping, they are >> not notified, this leaves signal in process queue long time before >> it can be delivered to userland. >> >> > > Agreed. Actually, there is one more race. Namely, when thread enters > kernel for executing sigprocmask syscall, but still did not acquired > process mutex, some signal may be scheduled for the thread which will > block it later while still in kernel, so wakeup is lost again. I did > fixed that in later version of the patch, by waking up possible target > threads that have newly blocked signals unblocked. > > Resulting code seems to be relevant for exiting thread as well, where > we also shall set sigmask to indicate that thread is not willing (cannot) > handle any further signals. > > Updated patch below. > The patch looks fine to me. From guru at unixarea.de Sun Oct 11 06:50:06 2009 From: guru at unixarea.de (Matthias Apitz) Date: Sun Oct 11 06:50:13 2009 Subject: 9-CURRENT (r197801) && artsd of kde-3.5.10_2 gives SIGSEGV Message-ID: <20091011062419.GA2168@current.Sisis.de> Hello, I've compiled 9-CURRENT from SVN (r197801) and CVS'uped /usr/ports at the same day (October, 6) to compile KDE and a lot of other stuff. The artsd of KDE reproduceable crashes on 'test sound' with: $ gdb /usr/local/bin/artsd 2650 ... (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x28144166 in Arts::PlayObject_base::_create () from /usr/local/lib/libkmedia2_idl.so.1 (gdb) bt #0 0x28144166 in Arts::PlayObject_base::_create () from /usr/local/lib/libkmedia2_idl.so.1 #1 0x08063bd1 in Arts::SimpleSoundServer_impl::createPlayObject () #2 0x08061288 in Arts::SimpleSoundServer_impl::play () #3 0x280f7103 in _dispatch_Arts_SimpleSoundServer_00 () from /usr/local/lib/libsoundserver_idl.so.1 #4 0x28579df6 in Arts::Object_skel::_dispatch () from /usr/local/lib/libmcop.so.1 #5 0x2856fae8 in Arts::Dispatcher::handle () from /usr/local/lib/libmcop.so.1 #6 0x2853e371 in Arts::Connection::receive () from /usr/local/lib/libmcop.so.1 #7 0x2857d4fe in Arts::SocketConnection::notifyIO () from /usr/local/lib/libmcop.so.1 #8 0x2857281f in Arts::StdIOManager::processOneEvent () from /usr/local/lib/libmcop.so.1 #9 0x28571e70 in Arts::StdIOManager::run () from /usr/local/lib/libmcop.so.1 #10 0x28568447 in Arts::Dispatcher::run () from /usr/local/lib/libmcop.so.1 #11 0x0806a307 in main () Other applications, for example mplayer, play sound fine. The sound driver is snd_ich.ko. Any ideas what to do? matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ Vote NO to EU The Lisbon Treaty: http://www.no-means-no.eu From hselasky at freebsd.org Sun Oct 11 09:57:25 2009 From: hselasky at freebsd.org (Hans Petter Selasky) Date: Sun Oct 11 09:57:32 2009 Subject: [patch] USB video support in KDE4 + sane + more under FreeBSD Message-ID: <200910111158.14692.hselasky@freebsd.org> Hi, I was compiling the latest version of KDE4 on my box and I noticed it picked up my installed libv4l2. The only problem is that you need some patches before everything is compiling :-) About libv4lX on FreeBSD, please see: http://lists.freebsd.org/pipermail/freebsd-emulation/2009-June/006231.html Only USB webcams supported yet. After installation manually add -lv4lxdrivers to all the libv4l*.pc files! I will try to get this included into my ulinux distribution soon. Before: Libs: -L${libdir} -lv4lconvert After: Libs: -L${libdir} -lv4lconvert -lv4lxdrivers /usr/local/lib/pkgconfig/libv4lconvert.pc /usr/local/lib/pkgconfig/libv4l2.pc /usr/local/lib/pkgconfig/libv4l1.pc Then patch KDE4 like this: --- /usr/ports/net/kdenetwork4/work/kdenetwork-4.3.1/kopete/libkopete/avdevice/videodevice.h.orig 2009-10-11 11:41:54.000000000 +0200 +++ /usr/ports/net/kdenetwork4/work/kdenetwork-4.3.1/kopete/libkopete/avdevice/videodevice.h 2009-10-11 11:44:34.000000000 +0200 @@ -62,6 +62,13 @@ #endif // __linux__ +#if defined(__FreeBSD__) && defined(ENABLE_AV) +#include +#ifdef HAVE_LIBV4L2 +#include +#endif // HAVE_V4L2 +#endif + #include #include #include FYI for those tracking the 8.0 release: after a haitus of about a month around the FreeBSD Developer Summit and EuroBSDCon 2009 here in Cambridge, and with the help of Colin Percival, the 8.0TODO wiki page is now up-to-date: http://wiki.FreeBSD.org/8.0TODO We'll endeavour to keep it more up-to-date going forward; there's nothing like hosting a conference to get you behind on e-mail :-). Robert N M Watson Computer Laboratory University of Cambridge From gavin at FreeBSD.org Sun Oct 11 12:51:00 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Sun Oct 11 12:51:07 2009 Subject: Strange md/unionfs issue In-Reply-To: <4AD0E286.9030508@gmail.com> References: <4AD0E286.9030508@gmail.com> Message-ID: <20091011133411.A80896@ury.york.ac.uk> On Sat, 10 Oct 2009, David Ehrmann wrote: > I have a system running on a flash disk. To prevent it from wearing out > quickly, I don't run with a swap and mount /tmp and /var from memory. > Because /var needs some directories and contains files I probably should save > from time to time, I mount it from flash, mount /var to /var_real so I can > access the underlying files, and then I mount an md device on top of /var as > a unionfs. Initially, it seems to work, but seconds later, the unionfs seems > to fail. When the mount "fails", is it still shown in the output of mount(1)? It appears that this problem is the same as is reported in PR kern/131441, which has so far not had any activity. It appears that this bug has existed since at least 7.1-RELEASE. I've included Goto-san in the CC-list, as he may be able to see if this is a bug in unionfs or in nullfs. Thanks, Gavin From uqs at spoerlein.net Sun Oct 11 14:23:00 2009 From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=) Date: Sun Oct 11 14:23:08 2009 Subject: ACPI Warning: Converted Buffer to expected String Message-ID: <20091011142256.GA3770@roadrunner.spoerlein.net> Just FYI, Dell Inspiron 8600c laptop, semi-recent CURRENT, latest BIOS (A14), machine is 5 years old and producing these warnings when inserting a battery (or booting with one inserted) ACPI Warning for \\_SB_.BAT0._BIF: Converted Buffer to expected String at index 9 (20090903/nsrepair-215) ACPI Warning for \\_SB_.BAT0._BIF: Converted Buffer to expected String at index 10 (20090903/nsrepair-215) ACPI Warning for \\_SB_.BAT0._BIF: Converted Buffer to expected String at index 11 (20090903/nsrepair-215) ACPI Warning for \\_SB_.BAT0._BIF: Converted Buffer to expected String at index 12 (20090903/nsrepair-215) Everything works just before the ACPI import, there's also another bunch of (harmless) errors during boot. acpi0: on motherboard acpi0: [ITHREAD] acpi0: reservation of 0, 9fc00 (3) failed acpi0: reservation of 100000, 3fef0000 (3) failed This is just for reference, perhaps someone wants to know. Cheers, Uli From rwatson at FreeBSD.org Sun Oct 11 14:51:18 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Oct 11 14:51:51 2009 Subject: FYI: "8.0TODO" wiki page updated In-Reply-To: References: Message-ID: On Sun, 11 Oct 2009, Robert Watson wrote: > FYI for those tracking the 8.0 release: after a haitus of about a month > around the FreeBSD Developer Summit and EuroBSDCon 2009 here in Cambridge, > and with the help of Colin Percival, the 8.0TODO wiki page is now > up-to-date: > > http://wiki.FreeBSD.org/8.0TODO > > We'll endeavour to keep it more up-to-date going forward; there's nothing > like hosting a conference to get you behind on e-mail :-). And, BTW, during the month's worth of updates, I counted approx 135 approved changes, many quite important fixes, at an average of about 4-5 per day. The rush has definitely slowed down, but the 2-3 critical things left are pretty important. Robert From stefan.hegnauer at gmx.ch Sun Oct 11 15:57:17 2009 From: stefan.hegnauer at gmx.ch (Stefan Hegnauer) Date: Sun Oct 11 15:57:50 2009 Subject: [patch] typo in portaudit - fails with latest /bin/sh Message-ID: <503AFE6B3CD0492BA2DFE6ED41691A1A@inspiron> Hi, portaudit (/usr/ports/ports-mgmt/portaudit) did not work anymore on a recent build of FreeBSD 9.0-CURRENT #0 as of Fri Oct 9 09:27:54 CEST 2009. As it turns out there seems to be a typo in the portaudit script which manifests itself since the changes applied to /bin/sh in http://svn.freebsd.org/viewvc/base?view=revision&sortby=date&revision=197691 The following patch cures this typo: --- /usr/local/sbin/portaudit.orig 2009-10-09 12:36:10.000000000 +0200 +++ /usr/local/sbin/portaudit 2009-10-09 12:39:11.000000000 +0200 @@ -264,7 +264,7 @@ return 2 fi - PKGNAME=`make -VPKGNAME 2>/dev/null || true"` + PKGNAME=`make -VPKGNAME 2>/dev/null || true` if [ -z "$PKGNAME" ]; then echo "portaudit: Can't determine the package name" >&2 If somebody (eik@FreeBSD.org ?) could merge this in, please ... --SH From danger at FreeBSD.org Sun Oct 11 17:54:29 2009 From: danger at FreeBSD.org (Daniel Gerzo) Date: Sun Oct 11 17:54:38 2009 Subject: FreeBSD Status Reports April - September, 2009 Message-ID: <20091011175428.GA3626@freefall.freebsd.org> FreeBSD Quarterly Status Report Introduction This report covers FreeBSD related projects between April and September 2009. During that time a lot of work has been done on wide variety of projects, including the Google Summer of Code projects. The BSDCan conference was held in Ottawa, CA, in May. The EuroBSDCon conference was held in Cambridge, UK, in September. Both events were very successful. A new major version of FreeBSD, 8.0 is to be released soon. If you are wondering what's new in this long-awaited release, read Ivan Voras' excellent summary. Thanks to all the reporters for the excellent work! We hope you enjoy the reading. Please note that the next deadline for submissions covering reports between October and December 2009 is January 15th, 2010. __________________________________________________________________ Google Summer of Code * About Google Summer of Code 2009 * BSD-licensed iconv (Summer of Code 2009) * BSD-licensed text-processing tools (Summer of Code 2008) * Ext2fs Status report (Summer of Code 2009) * libnetstat(3) - networking statistics (Summer of Code 2009) * pefs - stacked cryptographic filesystem (Summer of Code 2009) Projects * BSD# Project * Clang replacing GCC in the base system * FreeBSD TDM Framework * Grand Central Dispatch - FreeBSD port * libprocstat(3) - process statistics * New BSD licensed debugger * NFSv4 ACLs * The Newcons project * VirtualBox on FreeBSD FreeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD KDE Team * FreeBSD Ports Management Team * Release Engineering Status Report * The FreeBSD Foundation Status Report Network Infrastructure * Enhancing the FreeBSD TCP Implementation * Modular Congestion Control * Network Stack Virtualization * Stream Control Transmission Protocol (SCTP) Kernel * FreeBSD/ZFS * hwpmc for MIPS Documentation * The FreeBSD Dutch Documentation Project * The FreeBSD German Documentation Project * The FreeBSD Hungarian Documentation Project * The FreeBSD Spanish Documentation Project Architectures * FreeBSD/sparc64 Ports * FreeBSD Gecko Project * Portmaster - utility to assist users with managing ports * Valgrind suite on FreeBSD Miscellaneous * EuroBSDcon 2009 * FreeBSD Developer Summit, Cambridge UK * New approach to the locale database * The FreeBSD Forums __________________________________________________________________ About Google Summer of Code 2009 URL: http://socghop.appspot.com/org/home/google/gsoc2009/freebsd URL: http://wiki.freebsd.org/SummerOfCode2009Projects Contact: Brooks Davis Contact: Tim Kientzle Contact: Robert Watson 2009 was The FreeBSD Project's fifth year of participation in the Google Summer of Code. We had a total of 17 successful projects. Some GSoC code will be shipping with FreeBSD 8.0-RELEASE and others will be integrated into future releases. The FreeBSD GSoC admin team would like to thank Google and our students and mentors of another great year! __________________________________________________________________ BSD# Project URL: http://code.google.com/p/bsd-sharp/ URL: http://www.mono-project.org/ Contact: Romain Tarti?re The BSD# Project is devoted to porting the Mono .NET framework and applications to the FreeBSD operating system. During the past year, the BSD# Team continued to track the Mono development and the lang/mono port have almost always been up-to-date (we however had to skip mono-2.2 because of some regression issues in this release). Most of our patches have been merged in the mono trunk upstream, and should be included in the upcoming mono-2.6 release. In the meantime, a few more .NET related ports have been updated or added to the FreeBSD ports tree. These ports include: * www/xsp and www/mod_mono that make it possible to use FreeBSD for hosting ASP.NET application; * lang/boo, a CLI-targeted programming language similar to Python; * lang/mono-basic, the Visual Basic .NET Framework for Mono; * devel/monodevelop, an Integrated Development Environment for .NET; * and much more... Open tasks: 1. Test mono ports and send feedback (we are especially interested in tests where NOPORTDOCS / WITH_DEBUG is enabled). 2. Port the mono-debugger to FreeBSD. 3. Build a debug live-image of FreeBSD so that Mono hackers without a FreeBSD box can help us fixing bugs more efficiently. __________________________________________________________________ BSD-licensed iconv (Summer of Code 2009) URL: http://wiki.freebsd.org/G%C3%A1borSoC2009 Contact: G?bor K?vesd?n The code has been extracted from NetBSD and has been transformed into an independent shared library. The basic encodings are well supported. Almost all forward conversions (foo -> UTF-32) are compatible with GNU but the reverse ones are not so accurate because of GNU's advanced transliteration. Some extra encodings have also been added. There are two modules, which segfault; they need some debugging. I can keep working on this project as part of my BSc thesis, so I hope to be able to solve the remaining issues. Improved GNU compatibility is also very desired (extra command line options for iconv(1), iconvctl(), private interfaces, etc.). Open tasks: 1. Fix segfaults in Big5 and HZ modules 2. Improve transliteration in reverse encodings 3. Improve GNU compatibility by implementing extra features 4. Verify POSIX compatibility 5. Verify GNU compatibility 6. Check performance __________________________________________________________________ BSD-licensed text-processing tools (Summer of Code 2008) URL: http://wiki.freebsd.org/G%C3%A1borSoC2008 Contact: G?bor K?vesd?n This project was started as part of Google Summer of Code 2008 but there is still a bit of work to complete some missing parts. The BSD-licensed grep implementation is feature-complete and has a good level of GNU compatibility. Our only current concern about the BSD-licensed version is to improve its performance. The GNU variant is much more complex, has about 8 KSLOC, while BSD grep is tiny, has only 1.5 KSLOC. GNU uses some shortcuts and optimizations to speed-up calls to the regex library; that is why it is significantly faster. My point of view is that such optimizations must be implemented in the regex library, keeping the dependent utilities clean and easy to read. BSD grep is so tiny that there is hardly any optimization opportunity by simplifying the code, so the regex library is the next important TODO. There is another issue with the current regex library. It does not support some invalid regular expressions, which work in GNU. We need to maintain compatibility, so we cannot just drop this feature. Actually, BSD grep is linked to the GNU regex library to maintain this feature but due to the lack of the mentioned shortcuts, it is still slower than GNU. Anyway, if we can live with this little performance hit until we get a modern regex library, I think grep is ready to enter HEAD. As for the regex library, NetBSD's result of the last SoC is worth taking a look. The sort utility has been rewritten from scratch. The existing BSD-licensed implementation could not deal with wide characters by design. The new implementation is still lacking some features but is quite complete. There is a performance issue, though. Sorting is a typical algorithmic subject but I am not an algorithmic expert, so my implementation is not completely optimal. Some help would be welcome with this part. The bc/dc utilities have been ported from OpenBSD. They pass OpenBSD's and GNU's regression tests but they arrived too late to catch 8.X, so they will go to HEAD after the release. Open tasks: 1. Improve sort's sorting and file merging algorithms 2. Complete missing features for sort 3. Get a modern regex library for FreeBSD __________________________________________________________________ Clang replacing GCC in the base system URL: http://wiki.freebsd.org/BuildingFreeBSDWithClang Contact: Ed Schouten Contact: Roman Divacky Contact: Brooks Davis Contact: Pawel Worach The clang@FreeBSD team presents the status of clang/LLVM being able to compile FreeBSD system. The current status is: * i386 - kernel boots, world needs little hacks but works * amd64 - kernel boots, world needs little hacks but works * ppc - broken because of unknown RTLD bug * other - unknown All other platforms are untested. A lot has happened over the spring/summer: amd64 got proper mcmodel=kernel support, compiler-rt has been introduced (paving the way for libgcc replacement), we have run two experimental port builds to see how clang does there. The C++ support is able to parse devd.cc without warnings. We have got the kernel working with -O2. FreeBSD has been promoted to be an officially supported plaform in LLVM. As a result of all this work, many parts of FreeBSD that did not compile before now build without problems. Open tasks: 1. The "ClangBSD" branch of FreeBSD got a little stale and has not been updated for a while. 2. We also need to get some important fixes into LLVM to get libc compiling and some other smaller issues. 3. We can still appreciate more testers on minor platforms (mostly on ARM, PPC and MIPS, but testing on other platforms is also welcome). __________________________________________________________________ Enhancing the FreeBSD TCP Implementation URL: http://caia.swin.edu.au/freebsd/etcp09/ URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://www.freebsdfoundation.org/projects.shtml URL: http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/ Contact: Lawrence Stewart TCP appropriate byte counting (RFC 3465) support has been merged into the FreeBSD 8 branch and will ship in FreeBSD 8.0-RELEASE. The reassembly queue auto-tuning and SIFTR work was not ready in time to safely integrate for 8.0-RELEASE. Padding has been added to necessary TCP structs to facilitate MFCing features back to the 8-STABLE branch after 8.0 is released. Candidate patches against FreeBSD-CURRENT will be ready for wider testing in the coming weeks. The freebsd-net mailing list will be solicited for testing/feedback when everything is ready. Open tasks: 1. Solicit review/testing and integrate the ALQ kld and variable length message support patch into FreeBSD-CURRENT. 2. Solicit review/testing and integrate the SIFTR tool into FreeBSD-CURRENT. 3. Complete dynamic reassembly queue auto-tuning patch for FreeBSD-CURRENT. 4. Fix an identified bug in the SACK implementation's fast retransmit/fast recovery behavior. 5. Profit! __________________________________________________________________ EuroBSDcon 2009 URL: http://2009.eurobsdcon.org/ URL: http://2010.eurobsdcon.org/ Contact: Sam Smith Contact: Robert Watson EuroBSDcon 2009 happened in Cambridge, with over 160 users, developers, friends and others. Slides, papers and audio are now up on the website for those who could not make it to Cambridge. Next year's event in 2010 will take place in Karlsruhe from 8 to 10 October 2010. If you are interested in what you missed in 2009, or to join the mailing list so you do not miss out next year, visit http://2009.eurosbsdcon.org. __________________________________________________________________ Ext2fs Status report (Summer of Code 2009) URL: http://wiki.freebsd.org/SOC2009AdityaSarawgi Contact: Aditya Sarawgi FreeBSD's ext2fs had some parts under GPL. The aim of my project was to rewrite those parts and free ext2fs from GPL. I have been successful in rewriting the parts and NetBSD's ext2fs was a great help in this. Certain critical parts under GPL were also removed due to which the write performance suffered. I also implemented Orlov Block Allocator for ext2fs. Currently I am planning to make ext2fs Multiprocessor Safe (MPSAFE). My work resides in truncs_ext2fs branch of Perforce. Open tasks: 1. Ext4 support for FreeBSD 2. Directory indexing for ext2fs 3. Journaling in ext2fs using gjournal __________________________________________________________________ FreeBSD Bugbusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: http://wiki.FreeBSD.org/BugBusting URL: http://people.FreeBSD.org/~linimon/studies/prs/ URL: http://people.FreeBSD.org/~linimon/studies/prs/recommended_prs.html Contact: Gavin Atkinson Contact: Mark Linimon Contact: Remko Lodder Contact: Volker Werth We continue to classify PRs as they arrive, adding 'tags' to the subject lines corresponding to the kernel subsystem involved, or man page references for userland PRs. These tags, in turn, produce lists of PRs sorted both by tag and by manpage. The list of PRs recommended for committer evaluation by the Bugbusting Team continues to receive new additions. This list contains PRs, mostly with patches, that the Bugbusting Team feel are probably ready to be committed as-is, or are probably trivially resolved in the hands of a committer with knowledge of the particular subsystem. All committers are invited to take a look at this list whenever they have a spare 5 minutes and wish to close a PR. A full list of all the automatically generated reports is also available at one of the cited URLs. Any recommendations for reports which not currently exist but which would be beneficial are welcomed. Gavin Atkinson gave a presentation on "The PR Collection Status" at the EuroBSDCon 2009 DevSummit, and discussed with other participants several other ideas to make the PR database more useful and usable. Several good ideas came from this, and will hopefully lead to more useful tools in the near future. Discussions also took place on how it may be possible to automatically classify non-ports PRs with a view towards notifying interested parties, although investigations into this have not yet begun. Mark Linimon also continues attempting to define the general problem and investigating possible new workflow models, and presented work on this at BSDCan 2009. Since the last status report, the number of open bugs has increased to around the 5900 mark, partially because of an increased focus on getting more information into the existing PRs, in an attempt to make sure all the information required is now available. As a result, although the number of open PRs has increased, they are hopefully of better quality. As always, more help is appreciated, and committers and non-committers alike are always invited to join us on #freebsd-bugbusters on EFnet and help close stale PRs or commit patches from valid PRs. Open tasks: 1. Work on suggestions from developers who were at the EuroBSDCon DevSummit. 2. Try to find ways to get more committers helping us with closing the PRs that the team has already analyzed. __________________________________________________________________ FreeBSD Developer Summit, Cambridge UK URL: http://wiki.FreeBSD.org/200909DevSummit Contact: Robert Watson Around 70 FreeBSD developers and guests attended the FreeBSD developer summit prior to EuroBSDCon 2009 in Cambridge, UK. Hosted at the University of Cambridge Computer Laboratory, the workshop-style event consisted of prepared presentations, as well as group hacking and discussion sessions. Talks covered topics including 802.11 mesh networking, virtual network stacks and kernels, a new BSD-licensed debugger, benchmarking, bugbusting, NetFPGA, a port of Apple's GCD (Grand Central Dispatch) to FreeBSD, security policy work, cryptographic signatures, FreeBSD.org system administration, time geeks, a new console driver, and the FreeBSD subversion migration. Slides for many talks are now available on the wiki page. A good time was had by all, including a punting outing on the River Cam! __________________________________________________________________ FreeBSD Gecko Project URL: https://trillian.chruetertee.ch/freebsd-gecko/wiki/TODO Contact: Beat Gaetzi Contact: Martin Wilke Contact: Andreas Tobler Andreas Tobler made the classic mistake of sending us a lot of powerpc and sparc64 related patches. The usual punishment, of giving him a commit bit to the Gecko repository, has been applied. We currently have some old ports in the ports tree: * www/mozilla is 5 year old now, no longer supported upstream, and has a lot of security vulnerabilities. We can use www/seamonkey instead. * www/xulrunner is superseeded by www/libxul. A patch that includes the following changes has been tested on pointyhat and is ready for commit: * Remove references to www/mozilla/Makefile.common and www/mozilla/bsd.gecko.mk * Switch USE_GECKO= xulrunner firefox mozilla to USE_GECKO= libxul and remove www/xulrunner We are also working on Firefox 3.6 (Alpha 2), Thunderbird 3.0 (Beta 4), new libxul 1.9.1.3 and Seamonkey 2.0 (Beta 2) ports. All of them are already committed to our Gecko repository. A current status and todo list can be found at http://trillian.chruetertee.ch/freebsd-gecko/wiki/TODO. Open tasks: 1. Remove mozilla, xulrunner and firefox2 from the ports tree. 2. The www/firefox35 port should be moved to www/firefox. 3. The old (and somewhat stale) Gecko providers mozilla, nvu, xulrunner, flock and firefox also need to be removed. __________________________________________________________________ FreeBSD KDE Team URL: http://freebsd.kde.org URL: http://miwi.bsdcrew.de/category/kde/ URL: http://blogs.freebsdish.org/tabthorpe/category/kde Contact: Thomas Abthorpe Contact: Max Brazhnikov Contact: Martin Wilke Since the spring, the FreeBSD KDE team has been busy upgrading KDE from 4.2.0 up through to 4.3.1. As part of the ongoing maintenance of KDE, the team also updated Qt4 from 4.4.3 through to 4.5.2 We added two new committers/maintainers to the team, Kris Moore (kmoore@) and Dima Panov (fluffy@). We also granted enhanced area51 access to contributors Alberto Villa and Raphael Kubo da Costa. Alberto has been our key contributor updating and testing Qt 4.6.0-tp1. Raphael is a KDE developer, who has become our Gitorious liaison, he has been responsible for getting FreeBSD Qt patches merged in upstream. Markus Br?ffer (markus@) spent a lot of time patching widgets and system plugins so they would work under FreeBSD. We would like to thank him for all his effort! Open tasks: 1. Update to Qt 4.6.0 2. Update to KDE 4.4.0 3. Work with our userbase on fixing an EOL for KDE3 in the ports tree __________________________________________________________________ FreeBSD Ports Management Team URL: http://www.freebsd.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://tinderbox.marcuscom.com Contact: Mark Linimon The ports count has soared to over 20,700. The PR count had been driven below 800 by some extraordinary effort, but once again is back to its usual count of around 900. We are currently building packages for amd64-6, amd64-7, amd64-8, i386-6, i386-7, i386-8, sparc64-7, and sparc64-8. There have been preliminary runs of i386-9; however, to be able to continue builds on -9, we will either need to find places to host a number of new machines, or drop package building for -6. The mailing list discussion of the latter proved quite controversial. We have added some new i386 machines to help speed up the builds, but this only makes up for the disk failures on some of our older, slower, i386 nodes. We also appreciate the loan of more package build machines from several committers, including pgollucci@, gahr@, erwin@, Boris Kochergin, and Craig Butler. The portmgr@ team has also welcomed new members Ion-Mihai Tetcu (itetcu@) and Martin Wilke (miwi@). We also thank departing member Kirill Ponomarew (krion@) for his long service. Ion-Mihai has spent much time working on a system that does automatic Quality Assurance on new commits, called QAT. A second tinderbox called QATty has helped us to fix many problems, especially those involving custom PREFIX and LOCALBASE settings, and documentation inclusion options. Ports conformance to documented features / non-default configuration will follow. Between pav and miwi, over 2 dozen experimental ports runs have been completed and committed. We have added 5 new committers since the last report, and 2 older ones have rejoined. Open tasks: 1. We are currently trying to set up ports tinderboxes that can be made available to committers for pre-testing; those who can loan machines for this should contact Ion-Mihai (itetcu@) with details regarding the hardware and bandwidth. 2. Most of the remaining ports PRs are "existing port/PR assigned to committer". Although the maintainer-timeout policy is helping to keep the backlog down, we are going to need to do more to get the ports in the shape they really need to be in. 3. Although we have added many maintainers, we still have almost 4,700 unmaintained ports (see, for instance, the list on portsmon). (The percentage is down to 22%.) We are always looking for dedicated volunteers to adopt at least a few unmaintained ports. As well, the packages on amd64 and sparc64 lag behind i386, and we need more testers for those. __________________________________________________________________ FreeBSD TDM Framework Contact: Rafal Czubak Contact: Michal Hajduk This work's purpose is a generic and flexible framework for systems equipped with Time Division Multiplexing (TDM) units, often found on embedded telecom chips. The framework is designed to support various controllers and many types of TDM channels e.g. voiceband, sound and miscellaneous data channels. Currently, voiceband infrastructure is being developed on Marvell RD-88F6281 reference board. It will serve as an example of how to use the TDM framework for other channel types. The direct objective of using TDM with voiceband channels is bringing a FreeBSD based VoIP system, capable of bridging analog telephone world with digital IP telephony. Together with third party VoIP software (e.g. Asterisk), the design can serve as VoIP Private Branch Exchange (PBX). Current state highlights: * TDM controller interface * TDM channel interface * TDM channel API for kernel modules * codec interface * voiceband channel character device driver * TDM controller driver for Marvell Kirkwood and Discovery SoCs * Si3215 SLIC driver * Si3050 DAA driver Open tasks: 1. Develop demo application showing example usage of voiceband channel. 2. Integrate voiceband infrastructure with Zaptel/DAHDI telephony hardware drivers. __________________________________________________________________ FreeBSD/sparc64 Contact: Marius Strobl Noteworthy developments regarding FreeBSD/sparc64 since the last Status Reports are: * Cas(4), a driver for Sun Cassini/Cassini+, as well as National Semiconductor DP83065 Saturn Gigabit NICs has been committed and thus will be part of FreeBSD beginning with 8.0-RELEASE and 7.3-RELEASE, respectively. This means that the on-board NICs found in Fire V440, as well as the add-on cards based on these chips, are now supported, including on non-sparc64 machines. Unfortunately, the cas(4) driver triggers what seem to be secondary problems with the on-board NICs found in B100 blades and Fire V480, which due to lack of access to such systems could not be fixed so far. * Initial support for sun4u machines based on the "Fire" Host-PCI-Express bridge like Fire V215, V245, etc. has been completed (including support for the on-board ATA controller, which caused several problems at first, and MSI/MSI-X). Some code like the quirk handling for the ALi/ULi chips found in these machines needs to be revisited though and no stability tests have been conducted so far. If all goes well, the code will hit HEAD some time after FreeBSD 8.0-RELEASE has been released. In theory, machines based on the "Oberon" Host-PCI-Express bridge, at least for the most part, should also be supported with these changes, but due to lack of access to a Mx000 series machine the code could not be tested with these so far. * Some bugs in the snd_t4dwave(4) driver have been fixed, as well as some special handling for sparc64 has been added so it does 32-bit DMA and now generally works with the on-board ALi M5451 found for example in Blade 100 and Blade 1500. Unfortunately, it was only tested to work correctly in two out of three Blade 100. Why it still does not work correctly in the remaining one is currently unknown but at least no longer causes IOMMU-panics so testing snd_t4dwave(4) on sparc64 is no longer harmful. These changes will be part of FreeBSD 8.0-RELEASE and 7.3-RELEASE. * Ata-marvell(4) has been fixed to work on sparc64 (actually also on anything that is not x86 with less than 4GB of RAM). These fixes will be part of FreeBSD 8.0-RELEASE and 7.3-RELEASE. * A proper and machine-independent fix for the old problem that the loader leaves the NIC opened by the firmware, which could lead to panics during boot when netbooting, has been developed but not committed yet. Open tasks: __________________________________________________________________ FreeBSD/ZFS Contact: Pawel Dawidek We believe that the ZFS file system is now production-ready in FreeBSD 8.0. Most (if not all) reported bugs were fixed and ZFS is no longer tagged as experimental. There is also ongoing work in Perforce to bring the latest ZFS version (v19) to FreeBSD. Open tasks: 1. Download 8.0 release candidates and test, test, test and report any problems to the freebsd-fs@FreeBSD.org mailing list. __________________________________________________________________ Grand Central Dispatch - FreeBSD port URL: http://libdispatch.macosforge.org/ Contact: Robert Watson Contact: Stacey Son Contact: libdispatch mailing list We have ported libdispatch, Apple's Grand Central Dispatch event and concurrency framework to FreeBSD: * Added new kqueue primitives required to support GCD, such as EVFILT_USER and EV_TRIGGER * Created autoconf and automake build framework for libdispatch * Modified libdispatch to use POSIX semaphores instead of Mach semaphores * Adapted libdispatch to use portable POSIX time routines Jordan Hubbard has also prepared a blocks-aware clang compiler package for FreeBSD. When compiled with clang, libdispatch provides blocks-based, as well as function-based callbacks. The port was presented at the FreeBSD Developer Summit in Cambridge, UK in September, and slides are online on the devsummit wiki page. A FreeBSD port is now available in the Ports Collection. After FreeBSD 8.0-RELEASE has shipped, the new kqueue primitives will be MFC'd so that libdispatch works out of the box on FreeBSD 8.1-RELEASE. Open tasks: 1. Complete porting of libdispatch test suite to FreeBSD. 2. Investigate pthread work queue implementation for FreeBSD. 3. Evaluate performance impact of some machine-dependent and OS-dependent optimizations present in the Mac OS X version of libdispatch to decide if they should be done for other platforms and OS's. 4. Explore whether FreeBSD base operating system tools would benefit from being modified to use libdispatch. __________________________________________________________________ hwpmc for MIPS URL: http://wiki.freebsd.org/FreeBSD/mips URL: http://wiki.freebsd.org/FreeBSD/mips/UBNT-RouterStationPro Contact: George Neville-Neil Currently working on board bringup. I have looked over the docs for how MIPS provides performance counters and will begin adding code soon. __________________________________________________________________ libnetstat(3) - networking statistics (Summer of Code 2009) URL: http://wiki.FreeBSD.org/PGJSoc2009 URL: http://p4web.freebsd.org/@md=d&cd=//&c=McZ@//depot/projects/soc2009/pgj _libstat/?ac=83 Contact: G?bor P?li The libnetstat(3) project provides a user-space library API to monitor networking functions with the following benefits: * ABI-robust interface making use of accessor functions in order to divorce monitoring applications from kernel or user ABI changes. * Supports running 32-bit monitoring tools on top of a 64-bit kernel. * Improved consistency for both kvm(3) and sysctl(3) when retrieving information. The supported abstractions are as follows: * Active sockets and socket buffers * Network interfaces and multicast interfaces * mbuf(9) statistics * bpf(4) statistics * Routing statistics, routing tables, multicast routing * Protocol-dependent statistics There is a sample application, called nettop(8), which provides a simple ncurses-based top(1)-like interface for monitoring active connections and network buffer allocations via the library. A modified version of netstat(1) has also been created to use libnetstat(3) as much as possible. __________________________________________________________________ libprocstat(3) - process statistics URL: http://svn.freebsd.org/viewvc/base/projects/libprocstat/ Contact: Stanislav Sedov Contact: Ulf Lilleengen The libprocstat project is an ongoing effort to develop a library that can be used to retrieve information about running processes and open files in the uniform and platform-independent way both from a running system or from core files. This will facilitate the implementation of file- or process-monitoring applications like lsof(1), fstat(1), fuser, etc. The libprocstat repository contains a preliminary version of the library. It also includes rewrites of the fstat and the fuser utilities ported to use this library instead of retrieving all the required information via the kvm(3) interface; one of the important advantages of the versions that use libprocstat is that these utilities are ABI independent. Open tasks: 1. Implement KVM-based namecache lookup to retrieve filesystem paths associated with file descriptors and VM objects. 2. Analyze possible ways of exporting file and process information from the kernel in an extensible and ABI-independent way. __________________________________________________________________ Modular Congestion Control URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://svn.freebsd.org/viewvc/base/projects/tcp_cc_8.x/ Contact: Lawrence Stewart The patch has received some significant rototilling in the past few months to prepare it for merging to FreeBSD-CURRENT. Additionally, I completed an implementation of the CUBIC congestion control algorithm to complement the existing NewReno and H-TCP algorithm implementations already available. I have one further intrusive change to make, which will allow congestion control modules to be shared between the TCP and SCTP stacks. Once this is complete, I will be soliciting for review/testing in the hope of committing the patch to FreeBSD-CURRENT in time to be able to backport it for 8.1-RELEASE. Open tasks: 1. Abstract the congestion control specific variables out of the TCP and SCTP control blocks into a new struct that can be passed into the API instead of the control block itself. __________________________________________________________________ Network Stack Virtualization URL: http://wiki.freebsd.org/Image URL: http://wiki.freebsd.org/200909DevSummit Contact: Bjoern A. Zeeb Contact: Marko Zec Contact: Robert Watson The network stack virtualization project aims at extending the FreeBSD kernel to maintain multiple independent instances of networking state. This allows for networking independence between jail environment, each maintaining its private network interfaces, IPv4 and IPv6 network and port address space, routing tables, IPSec configuration, firewalls, and more. During the last months the remaining pieces of the VIMAGE work were merged by Marko, Julian and Bjoern. Robert Watson developed a vnet allocator to overcome ABI issues. Jamie Gritton merged his hierachical jail framework that now also is the management interface for virtual network stacks. During the FreeBSD Developer Summit that took place at EuroBSDCon 2009 in Cambridge, UK, people virtualized more code. As a result SCTP and another accept filter were virtualized and more people became familiar with the design of VImage and the underlying concepts. Finally getting more hands involved was a crucial first step for the long term success of kernel virtualization. The next steps will be to finish the network stack virtualization, generalize the allocator framework before thinking of virtualizing further subsystems and to update the related documentation. Along with that a proper jail management framework will be worked on. Long term goals, amongst others, will be to virtualize more subsystems like SYS-V IPC, better privilege handling, and resource limits. In the upcoming FreeBSD 8.0 Release, vnets are treated as an experimental feature. As a result, they are not yet recommended for use in production environments. There was lots of time spent to finalize the infrastructure for vnets though, so that further changes can be merged and we are aiming to have things production ready for 8.2. In case you want to help to achieve this goal, feel free to contact us and support or help virtualizing outstanding parts like two firewalls, appletalk, netipx, ... as well as generating regression tests. __________________________________________________________________ New approach to the locale database URL: http://wiki.freebsd.org/LocaleNewApproach URL: svn://svn.freebsd.org/base/user/edwin/locale Contact: Edwin Groothuis Contact: i18n mailinglist Problem: Over the years the FreeBSD locale database (share/colldef, share/monetdef, share/msgdef, share/numericdef, share/timedef) has accumulated a total of 165 definitions (language - country-code - character-set triplets). The contents of the files for Western European languages are often low-ASCII but for Eastern European and Asian languages partly or fully high-ASCII. Without knowing how to display or interpret the character-sets, it is difficult to make sure by the general audience that the local language (language - country-code) definitions are displayed properly in various character-sets. Suggested approach: With the combination of the data in the Unicode project (whose goal is to define all the possible written characters and symbols on this planet) and the Common Locale Data Repository (whose goal is to document all the different data and definitions needed for the locale database), we can easily keep track of the data, without the need of being able to display the data in the required character sets or understand them fully when updates are submitted by third parties. Current status: Conversion of share/monetdef, share/msgdef, share/numericdef, share/timedef to the new design is completed. The Makefile infrastructure is converted. Regression checks are done. Most of the tools are in place, waiting on the import of bsdiconv to the base system. Open tasks: 1. At this moment the system is not self-hosted yet, because of the lack of an iconv-kind of program in the base operating system. Gabor@ is working on bsdiconv as a GSoC project and once that has been imported we will be able to perform a clean install from the definitions in Unicode text format to the required formats and character sets. __________________________________________________________________ New BSD licensed debugger URL: http://wiki.freebsd.org/TheBsdDebugger URL: http://people.freebsd.org/~dfr/ngdb.git URL: http://wiki.freebsd.org/200909DevSummit?action=AttachFile&do=view&targe t=NGDB-200909.pdf Contact: Doug Rabson <> I have been working recently on writing a new debugger, primarily for the FreeBSD platform. For various reasons, I have been writing it in a relatively obscure C-like language called D. So far, I have a pretty useful (if a little raw at the edges) command line debugger which supports ELF, Dwarf debugging information and (currently) 32 bit FreeBSD and Linux. The engine includes parsing and evaluation of arbitrary C expressions along with the usual debugging tools such as breakpoints, source code listing, single-step etc. All the code is new and BSD licensed. Currently, the thing supports userland debugging of i386 targets via ptrace and post-mortem core file debugging of the same. I will be adding amd64 support real soon (TM) and maybe support for GDB's remote debugging protocol later. __________________________________________________________________ NFSv4 ACLs URL: http://wiki.freebsd.org/NFSv4_ACLs Contact: Edward Tomasz Napierala During Google Summer of Code 2008, I have implemented native support for NFSv4 ACLs for both ZFS and UFS. Most of the code has already been merged to CURRENT. NFSv4 ACLs are unconditionally enabled in ZFS and the usual tools, like getfacl(1) and setfacl(1) can be used to view and change them. I plan to merge the remaining bits (UFS support) this month. It should be possible to MFC it in order to ship in FreeBSD 8.1-RELEASE. Open tasks: 1. UFS changes review 2. Support for NFSv4 ACLs in tar(1) __________________________________________________________________ pefs - stacked cryptographic filesystem (Summer of Code 2009) URL: http://blogs.freebsdish.org/gleb/ URL: http://wiki.freebsd.org/SOC2009GlebKurtsov Contact: Gleb Kurtsou Contact: Stanislav Sedov Pefs is a kernel level filesystem for transparently encrypting files on top of other filesystems (like zfs or ufs). It adds no extra information into files (unlike others), doesn't require cipher block sized io operations, supports per directory/file keys and key chaining, uses unique per file tweak for encryption. Supported algorithms: AES, Camellia, Salsa20. The code is ready for testing. Open tasks: 1. Implement encrypted name lookup/readir cache 2. Optimize sparse files handling and file resizing __________________________________________________________________ Portmaster - utility to assist users with managing ports URL: http://dougbarton.us/portmaster.html Contact: Doug Barton I am currently seeking funding for further development work on portmaster. There are several features that are regularly requested by the community (such as support for installing packages) that I would very much like to implement but that will take more time than I can reasonably volunteer to implement correctly. There is information about the funding proposal available at the link above. Meanwhile I have recently completed another round of bug fixes and feature enhancements. The often-requested ability to specify the -x (exclude) option more than once on the command line was added in version 2.12. Also in that version I added the --list-origins option to make it easier to reinstall ports after a major version upgrade, or install the same set of ports on another system. Open tasks: 1. See the funding proposal. __________________________________________________________________ Release Engineering Status Report URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team continues to work on FreeBSD 8.0-RELEASE. Public testing has turned up quite a few problems, many related to the low-level network (routing/ARP table) changes and their interactions with IPv6. Progress continues to be made on fixing up the issues that have been identified during the public testing. At this point in time we are shooting for two more public test builds (RC2 and RC3) followed by the release late October or early November. __________________________________________________________________ Stream Control Transmission Protocol (SCTP) Contact: Randall Stewart SCTP continues to have minor fixes added to it as well as some new features. First and foremost, we now have VIMAGE and SCTP working and playing together. This goal was accomplished with the help of bz@, my new mentee tuexen@ and myself working together at the FreeBSD DevSummit in Cambridge, UK. Also the non-renegable SACK feature contributed by the university of Delaware was fixed so that now its safe to turn on (its sysctl). If you are using SCTP with CMT (Conncurrent Multipath Transfer) you will want to enable this option (CMT is also a sysctl). With CMT enabled you will be able to send data to all the destinations of an SCTP peer. We welcomed a new mentee (soon to be a commiter) to FreeBSD. Michael Tuexen is now a mentee of rrs@. Michael has been contributing to the SCTP work for quite some time and also moonlights as a Professor at the University of Muenster in Germany (when not doing SCTP coding). __________________________________________________________________ The FreeBSD Dutch Documentation Project URL: http://www.freebsd.org/docproj/translations.html#dutch Contact: Ren? Ladan Contact: Remko Lodder The current translations (Handbook and some articles) are kept up to date with the English versions. Some parts of the website have been translated, more work is in progress. Open tasks: 1. Find more volunteers for translating the remaining parts of the website and the FAQ. __________________________________________________________________ The FreeBSD Forums URL: http://forums.freebsd.org/ Contact: FreeBSD Forums Admins Contact: FreeBSD Forums Moderators Since their public launch in November 2008, the FreeBSD Forums (the most recent addition to the user community and support channels for the FreeBSD Operating System) have witnessed a healthy and steady growth. The user population is now at over 8,000 registered users, who have participated in over 6,000 topics, containing over 40,000 posts in total. The sign-up rate hovers between 50-100 each week. The total number of visitors (including 'guests') is hard to gauge but is likely to be a substantial multiple of the registered userbase. New topics and posts are actively 'pushed out' to search engines. This in turn makes the Forums show up in search results more and more often, making it a valuable and very accessible source of information for the FreeBSD community. One of the contributing factors to the Forums' success is their 'BSD-style' approach when it comes to administration and moderation. The Forums have a strong and unified identity, they are neatly divided into sub-forums (like 'Networking', 'Installing & Upgrading', etc.), very actively moderated, spam-free, and with a core group of very active and helpful members, dispensing many combined decades' worth of knowledge to starting, intermediate and professional users of FreeBSD. We expect the Forums to be, and to remain, a central hub in FreeBSD's community and support efforts. __________________________________________________________________ The FreeBSD Foundation Status Report URL: http://www.freebsdfoundation.org Contact: Deb Goodkin Kicking off our fall fund-raising campaign! Find out more at http://www.freebsdfoundation.org/donate/. We were a sponsor for EuroBSDCon 2009, and provided travel grants to 8 FreeBSD developers and users. We sponsored Kyiv BSD 2009, in Kiev Ukraine. We were also a sponsor of BSDCan, and sponsored 7 developers. We funded three new projects, New Console Driver by Ed Schouten, AVR32 Support by Arnar Mar Sig, and Wireless Mesh Support by Rui Paulo, which has completed. We continued funding a project that is making improvements to the FreeBSD TCP Stack by Lawrence Stewart. The project that made removing disk devices with mounted filesystems on them safe, by Edward Napierala, is now complete. We recognized the following FreeBSD developers at EuroBSDCon 2009: Poul-Henning Kamp, Bjoern Zeeb, and Simon Nielsen. These developers received limited edition FreeBSD Foundation vests. Follow us on Twitter now! __________________________________________________________________ The FreeBSD German Documentation Project URL: https://doc.bsdgroup.de URL: http://code.google.com/p/bsdcg-trans/wiki/BSDPJTAdede Contact: Johann Kois Contact: Benedict Reuschling Contact: Martin Wilke In May 2009, Benedict Reuschling received his commit bit to the www/de and doc/de_DE.ISO8859-1 trees under the mentorship of Johann Kois. Since then, he has been working primarily on the Handbook, updating existing chapters and translating new ones. Most notably, the filesystems and DTrace chapters have been recently translated. Bugs found in the original documents along the way were reported back so that the other translation teams could incorporate them, as well. Christoph Sold has put his time in translating the wiki pages of the BSD Certification Group into the German language. This is very helpful for all German people who want to take the exam and like to read the information about it in their native language. Daniel Seuffert has sent valuable corrections and bugfixes. Thanks to both of them for their time and efforts! The website is translated and updated constantly. Missing parts will be translated as time permits. We appreciate any help from volunteers in proofreading documents, translating new ones and keeping them up to date. Even small error reports are of great help for us. You can find contact information at the above URL. Open tasks: 1. Update the existing documentation set (especially the Handbook). 2. Translate more articles to German. 3. Read the translations. Check for problems and mistakes. Send feedback. __________________________________________________________________ The FreeBSD Hungarian Documentation Project URL: http://www.FreeBSD.org/hu URL: http://www.FreeBSD.org/doc/hu URL: http://wiki.FreeBSD.org/HungarianDocumentationProject URL: http://p4web.freebsd.org/@md=d&cd=//depot/projects/docproj_hu/&c=aXw@// depot/projects/docproj_hu/?ac=83 Contact: G?bor K?vesd?n Contact: G?bor P?li In the last months, we have not added new translations, although we have been working on the existing ones to have them updated. We need more translators and volunteers to keep the amount of the translated documentation growing, so feel free to contribute. Every line of submission or feedback is appreciated and highly welcome. If you want to join our work, please read the introduction to the project as well as the FDP Primer (both of them are available in Hungarian). Open tasks: 1. Translate news entries, press releases 2. Translate Release Notes for -CURRENT and 8.X 3. Translate articles 4. Translate web pages 5. Read the translations, send feedback __________________________________________________________________ The FreeBSD Spanish Documentation Project URL: http://www.FreeBSD.org/es URL: http://www.FreeBSD.org/doc/es URL: http://www.freebsd.org/doc/es/articles/fdp-es/ Contact: Jos? Vicente Carrasco Vay? Contact: G?bor K?vesd?n Recently, we have added one new article translation. The existing translations have not been updated, though. We need more human resources to keep up with the work and keep the translations up-to-date. Open tasks: 1. Update the Handbook translation 2. Update the web page translation __________________________________________________________________ The Newcons project URL: http://wiki.FreeBSD.org/Newcons URL: http://people.freebsd.org/~ed/newcons/patches/ Contact: Ed Schouten Some time ago I started writing a new driver for the FreeBSD kernel called vt(4), which is basically a replacement of syscons. There is still a lot of work that needs to be done but it is probably useful to mention what it does (and what does not). Right now there are just two graphics drivers for vt(4), namely a VGA driver for i386 and amd64 and a Microsoft Xbox graphics driver (because it was so easy to implement). I still have to figure out what I am going to do with VESA, because maybe it is better to just ignore VESA and figure out how hard it is to extend DRM to interact with vt(4). Some random features: it already supports both Unicode (UTF-8) input and output, it is MPSAFE and supports per-window graphical fonts of variable dimensions, containing an almost infinite amount of glyphs (both bold and regular). Open tasks: 1. Research needs to be done on DRM's codebase. 2. Syscons should already be migrated to TERM=xterm to make switching between drivers a bit easier. __________________________________________________________________ Valgrind suite on FreeBSD URL: http://wiki.freebsd.org/Valgrind Contact: Stanislav Sedov The Valgrind suite in the FreeBSD ports collection has been updated to version 3.5.0 (the latest available version). Most of the issues of the previous version should be resolved now: we expect memcheck, callgrind and cachegrind to be fully functional on both i386 and amd64 platforms as well as for i386 binaries running on amd64 system. DRD/hellgrind should work too, though they generate a lot of false-positives for now, so their output is a bit messy. Open tasks: 1. Port exp-ptrcheck valgrind tool and fix outstanding issues that show up in memcheck/helgrind/DRD in the Valgrind regression tests suite. 2. More testing (please, help). 3. Integrate our patches upstream. __________________________________________________________________ VirtualBox on FreeBSD URL: http://wiki.freebsd.org/VirtualBox Contact: Beat Gaetzi Contact: Bernhard Froehlich Contact: Dennis Herrmann Contact: Juergen Lock Contact: Martin Wilke VirtualBox has been committed to the Ports tree and synchronized with the latest trunk version from Sun. Several known problems are already fixed and some new features have been added: * VT-x support * Bridging support (Big Thanks to Fredrik Lindberg) * Host Serial Support * ACPI Support * Host DVD/CD access * SMP Support We would like to say thanks to all the people who helped us by reporting bugs and submitting fixes. We also thank the VirtualBox developers for their help with the ongoing effort to port VirtualBox on FreeBSD. From andy at neu.net Sun Oct 11 18:32:46 2009 From: andy at neu.net (AN) Date: Sun Oct 11 18:32:53 2009 Subject: ELF interpreter /libexec/ld-elf.so.1 not found Message-ID: On a recently installed 8.0RC1 system I am getting this when trying to start the cups printing daemon: # cupsd ELF interpreter /libexec/ld-elf.so.1 not found Abort trap: 6 A listing of the directory shows the following: ls -l /libexec/ total 544 -r-xr-xr-x 1 root wheel 249544 Oct 10 07:14 ld-elf.so.1 It also happened when I tried to start firefox35 that was installed as a package. After deleting the package and installing from ports, firefox now works. I tried to install cups from ports, but I still have the problem. Any help is appreciated. TIA From onemda at gmail.com Sun Oct 11 19:14:23 2009 From: onemda at gmail.com (Paul B Mahol) Date: Sun Oct 11 19:14:55 2009 Subject: 9-CURRENT (r197801) && artsd of kde-3.5.10_2 gives SIGSEGV In-Reply-To: <20091011062419.GA2168@current.Sisis.de> References: <20091011062419.GA2168@current.Sisis.de> Message-ID: <3a142e750910111214rb75f185k12b2cc7e1aba59d9@mail.gmail.com> On 10/11/09, Matthias Apitz wrote: > > Hello, > > I've compiled 9-CURRENT from SVN (r197801) and CVS'uped /usr/ports at > the same day (October, 6) to compile KDE and a lot of other stuff. > > The artsd of KDE reproduceable crashes on 'test sound' with: > > $ gdb /usr/local/bin/artsd 2650 > ... > (gdb) c > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > 0x28144166 in Arts::PlayObject_base::_create () from > /usr/local/lib/libkmedia2_idl.so.1 > (gdb) bt > #0 0x28144166 in Arts::PlayObject_base::_create () from > /usr/local/lib/libkmedia2_idl.so.1 > #1 0x08063bd1 in Arts::SimpleSoundServer_impl::createPlayObject () > #2 0x08061288 in Arts::SimpleSoundServer_impl::play () > #3 0x280f7103 in _dispatch_Arts_SimpleSoundServer_00 () from > /usr/local/lib/libsoundserver_idl.so.1 > #4 0x28579df6 in Arts::Object_skel::_dispatch () from > /usr/local/lib/libmcop.so.1 > #5 0x2856fae8 in Arts::Dispatcher::handle () from > /usr/local/lib/libmcop.so.1 > #6 0x2853e371 in Arts::Connection::receive () from > /usr/local/lib/libmcop.so.1 > #7 0x2857d4fe in Arts::SocketConnection::notifyIO () from > /usr/local/lib/libmcop.so.1 > #8 0x2857281f in Arts::StdIOManager::processOneEvent () from > /usr/local/lib/libmcop.so.1 > #9 0x28571e70 in Arts::StdIOManager::run () from > /usr/local/lib/libmcop.so.1 > #10 0x28568447 in Arts::Dispatcher::run () from /usr/local/lib/libmcop.so.1 > #11 0x0806a307 in main () > > Other applications, for example mplayer, play sound fine. The sound > driver is snd_ich.ko. > > Any ideas what to do? Make sure that all libraries and binarys are rebuild, thare may be ABI changes and not support for older code .... From inpcb.harsha at gmail.com Sun Oct 11 19:40:20 2009 From: inpcb.harsha at gmail.com (Harsha Srinath) Date: Sun Oct 11 19:40:27 2009 Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] Message-ID: Hi all, I'm running an updated HEAD kernel and got a page fault in ifindex_alloc_locked() in if.c. I figured that the problem was caused by the (pluggable) network card of my laptop and found that during the initialization of the interface, cb_event_thread() takes the giant lock and up the call chain in if_alloc(), we call IFNET_WLOCK() and assert on the RW locks in ifindex_alloc_locked(). It is in the asset macro IFNET_WLOCK_ASSERT() I see the page fault. I looked up some recent related changes and noticed the following comment in one of the check-ins in- http://svn.freebsd.org/viewvc/base/head/sys/net/if.c "Break out allocation of new ifindex values from if_alloc() and if_vmove(), and centralize in a single function ifindex_alloc(). Assert the IFNET_WLOCK, and add missing IFNET_WLOCK in if_alloc(). This does not close all known races in this code." So I think I have hit one of those fault conditions. Apparently the giant lock code was removed and added back recently - http://svn.freebsd.org/viewvc/base/head/sys/dev/pccbb/pccbb.c I believe that the root cause is that ifnet_rw is a non sleepable exclusive RW lock and we have taken the exclusive sleep mutex Giant before that. Any pointers and suggestions are welcome. Many thanks, Harsha From rwatson at FreeBSD.org Sun Oct 11 20:30:58 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Oct 11 20:31:37 2009 Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] In-Reply-To: References: Message-ID: On Sun, 11 Oct 2009, Harsha Srinath wrote: > I'm running an updated HEAD kernel and got a page fault in > ifindex_alloc_locked() in if.c. I figured that the problem was caused by the > (pluggable) network card of my laptop and found that during the > initialization of the interface, cb_event_thread() takes the giant lock and > up the call chain in if_alloc(), we call IFNET_WLOCK() and assert on the RW > locks in ifindex_alloc_locked(). It is in the asset macro > IFNET_WLOCK_ASSERT() I see the page fault. > > I looked up some recent related changes and noticed the following comment in > one of the check-ins in- > http://svn.freebsd.org/viewvc/base/head/sys/net/if.c > > "Break out allocation of new ifindex values from if_alloc() and if_vmove(), > and centralize in a single function ifindex_alloc(). Assert the IFNET_WLOCK, > and add missing IFNET_WLOCK in if_alloc(). This does not close all known > races in this code." > > So I think I have hit one of those fault conditions. > > Apparently the giant lock code was removed and added back recently - > http://svn.freebsd.org/viewvc/base/head/sys/dev/pccbb/pccbb.c > > I believe that the root cause is that ifnet_rw is a non sleepable exclusive > RW lock and we have taken the exclusive sleep mutex Giant before that. > > Any pointers and suggestions are welcome. Hi Harsha-- Giant is a bit special in that the long-term sleep code in the kernel knows to drop it when sleeping, and re-acquire when waking up. So, unlike all other mutexes, it should be OK to hold it in this case, as Giant will simply get dropped if the kernel has to sleep waiting on a sleepable lock. This is because, historically in FreeBSD 3.x/4.x, the kernel was protected by a single spinlock, which would get released whenever the kernel stopped executing, such as during an I/O sleep. On the whole, Giant has disappeared from the modern kernel, but where it is used, it retains those curious historic properties. To break things down a bit further, IFNET_WLOCK is, itself, a bit special: notice that in FreeBSD 8, it's actually two locks, a sleep lock, and a mutex, which must both be acquired exclusively to ensure mutual exclusion. if_alloc() and associated calls are also sleepable because they perform potentially sleeping memory allocation (M_WAITOK), so it's an invariant of any code calling interface allocation that it must be able to tolerate a sleep. Do you have a copy of the stack trace and fault information handy? In my experience, a NULL pointer deref or other page fault in the locking code for a global lock is almost always corrupted thread state, perhaps due to tripping over another thread having locked a corrupted/freed/uninitialized lock. We might be able to track that down by tracing other threads that were in execution at the time of the panic. Robert From gavin at FreeBSD.org Sun Oct 11 21:05:31 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Sun Oct 11 21:05:38 2009 Subject: ELF interpreter /libexec/ld-elf.so.1 not found In-Reply-To: References: Message-ID: <20091011220341.U7003@ury.york.ac.uk> On Sun, 11 Oct 2009, AN wrote: > On a recently installed 8.0RC1 system I am getting this when trying to start > the cups printing daemon: > > # cupsd > ELF interpreter /libexec/ld-elf.so.1 not found > Abort trap: 6 > > A listing of the directory shows the following: > ls -l /libexec/ > total 544 > -r-xr-xr-x 1 root wheel 249544 Oct 10 07:14 ld-elf.so.1 I'm assuming there are a lot more files than this in there? Can you show the following output: uname -a file `which cupsd` file /libexec/ld-elf.so.1 ldd `which cupsd` Is it possible you've somehow installed amd64 packages on an i386 system? Gavin From gnemmi at gmail.com Sun Oct 11 21:09:47 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Sun Oct 11 21:09:54 2009 Subject: FYI: "8.0TODO" wiki page updated In-Reply-To: References: Message-ID: <19e9a5dc0910111409l6e9b80a3rafaca3abe6d63e32@mail.gmail.com> On Sun, Oct 11, 2009 at 9:34 AM, Robert Watson wrote: > > FYI for those tracking the 8.0 release: after a haitus of about a month > around the FreeBSD Developer Summit and EuroBSDCon 2009 here in Cambridge, > and with the help of Colin Percival, the 8.0TODO wiki page is now > up-to-date: > > http://wiki.FreeBSD.org/8.0TODO > > We'll endeavour to keep it more up-to-date going forward; there's nothing > like hosting a conference to get you behind on e-mail :-). > > Robert N M Watson > Computer Laboratory > University of Cambridge > Hello Mr. Watson! I just took a look at the recently anounced updated TODO lists for 8.0 ( http://wiki.freebsd.org/8.0TODO) but couldn't find a anything about PR kern/136876: [bge] bge will not resume properly after suspend. Does that mean that 8.0 will be released without a fix for kern/136876? Thanks in advanced Gonzalo Nemmi From ler at lerctr.org Sun Oct 11 22:59:54 2009 From: ler at lerctr.org (Larry Rosenman) Date: Sun Oct 11 23:00:00 2009 Subject: Scheduler weirdness Message-ID: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> Ok, running RELENG_8 from Friday (10/9/2009). If I have 4 Folding-at-home processes running (they nice themselves) the system is slow as a dog. If I stop them, it's speedy. This is running SCHED_ULE is this expected? What can I do to help? These are Linux binaries. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From attilio at freebsd.org Sun Oct 11 23:11:17 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sun Oct 11 23:11:24 2009 Subject: Scheduler weirdness In-Reply-To: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> References: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> Message-ID: <3bbf2fe10910111611p2f48d89cpa80350980f4f03e4@mail.gmail.com> 2009/10/12 Larry Rosenman : > > Ok, running RELENG_8 from Friday (10/9/2009). > > If I have 4 Folding-at-home processes running (they nice themselves) the > system is slow as a dog. > > If I stop them, it's speedy. > > This is running SCHED_ULE > > is this expected? > > What can I do to help? Can you please produce the schedgraph output for this workload? Do you know how to setup it? Attilio -- Peace can only be achieved by understanding - A. Einstein From ler at lerctr.org Sun Oct 11 23:13:53 2009 From: ler at lerctr.org (Larry Rosenman) Date: Sun Oct 11 23:14:00 2009 Subject: Scheduler weirdness In-Reply-To: <3bbf2fe10910111611p2f48d89cpa80350980f4f03e4@mail.gmail.com> References: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> <3bbf2fe10910111611p2f48d89cpa80350980f4f03e4@mail.gmail.com> Message-ID: <100658409950385d656fb5d8030af744.squirrel@webmail.lerctr.org> On Sun, October 11, 2009 6:11 pm, Attilio Rao wrote: > 2009/10/12 Larry Rosenman : >> >> Ok, running RELENG_8 from Friday (10/9/2009). >> >> If I have 4 Folding-at-home processes running (they nice themselves) the >> system is slow as a dog. >> >> If I stop them, it's speedy. >> >> This is running SCHED_ULE >> >> is this expected? >> >> What can I do to help? > > Can you please produce the schedgraph output for this workload? > Do you know how to setup it? I'm not familiar with this. What do I need to do? > > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From attilio at freebsd.org Sun Oct 11 23:20:50 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sun Oct 11 23:20:58 2009 Subject: Scheduler weirdness In-Reply-To: <100658409950385d656fb5d8030af744.squirrel@webmail.lerctr.org> References: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> <3bbf2fe10910111611p2f48d89cpa80350980f4f03e4@mail.gmail.com> <100658409950385d656fb5d8030af744.squirrel@webmail.lerctr.org> Message-ID: <3bbf2fe10910111620p3aa5d4cbgb5db2659d8477142@mail.gmail.com> 2009/10/12 Larry Rosenman : > > On Sun, October 11, 2009 6:11 pm, Attilio Rao wrote: >> 2009/10/12 Larry Rosenman : >>> >>> Ok, running RELENG_8 from Friday (10/9/2009). >>> >>> If I have 4 Folding-at-home processes running (they nice themselves) the >>> system is slow as a dog. >>> >>> If I stop them, it's speedy. >>> >>> This is running SCHED_ULE >>> >>> is this expected? >>> >>> What can I do to help? >> >> Can you please produce the schedgraph output for this workload? >> Do you know how to setup it? > > I'm not familiar with this. What do I need to do? - Recompile your kernel with the following options: KTR KTR_COMPILE=(KTR_SCHED) KTR_MASK=(KTR_SCHED) KTR_ENTRIES=262144 - Run the buggy workload - When the slowness has been experienced a bit (a reasonable timeframe is within 10/20 secs) do: sysctl debug.ktr.mask=0 - do: ktrdump -ct > ktr.out - send here this file along with the number and frequency of your CPUs Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From ehrmann at gmail.com Sun Oct 11 23:38:27 2009 From: ehrmann at gmail.com (David Ehrmann) Date: Sun Oct 11 23:38:34 2009 Subject: Strange md/unionfs issue In-Reply-To: <20091011133411.A80896@ury.york.ac.uk> References: <4AD0E286.9030508@gmail.com> <20091011133411.A80896@ury.york.ac.uk> Message-ID: <4AD26C69.4040202@gmail.com> Gavin Atkinson wrote: > > On Sat, 10 Oct 2009, David Ehrmann wrote: > >> I have a system running on a flash disk. To prevent it from wearing >> out quickly, I don't run with a swap and mount /tmp and /var from >> memory. Because /var needs some directories and contains files I >> probably should save from time to time, I mount it from flash, mount >> /var to /var_real so I can access the underlying files, and then I >> mount an md device on top of /var as a unionfs. Initially, it seems >> to work, but seconds later, the unionfs seems to fail. > > When the mount "fails", is it still shown in the output of mount(1)? The output of mount is the same; it reports that a md-backed unionfs is on top of /var. > > It appears that this problem is the same as is reported in PR > kern/131441, which has so far not had any activity. It appears that > this bug has existed since at least 7.1-RELEASE. It does seem to be the same bug (or similar). With mine, I mounted a unionfs on top of a mount point that a nullfs was based on, not the nullfs's mount point. I think the bug in kern/131441 was with a unionfs over a nullfs. This probably means md's off the hook as the culprit, and the same thing would happen with ufs on /dev/foo. From ler at lerctr.org Mon Oct 12 01:43:30 2009 From: ler at lerctr.org (Larry Rosenman) Date: Mon Oct 12 01:43:37 2009 Subject: Scheduler weirdness In-Reply-To: <3bbf2fe10910111620p3aa5d4cbgb5db2659d8477142@mail.gmail.com> References: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> <3bbf2fe10910111611p2f48d89cpa80350980f4f03e4@mail.gmail.com> <100658409950385d656fb5d8030af744.squirrel@webmail.lerctr.org> <3bbf2fe10910111620p3aa5d4cbgb5db2659d8477142@mail.gmail.com> Message-ID: <6495ee63c0e2b33aded5d63decbaff02.squirrel@webmail.lerctr.org> On Sun, October 11, 2009 6:20 pm, Attilio Rao wrote: > 2009/10/12 Larry Rosenman : >> >> On Sun, October 11, 2009 6:11 pm, Attilio Rao wrote: >>> 2009/10/12 Larry Rosenman : >>>> >>>> Ok, running RELENG_8 from Friday (10/9/2009). >>>> >>>> If I have 4 Folding-at-home processes running (they nice themselves) >>>> the >>>> system is slow as a dog. >>>> >>>> If I stop them, it's speedy. >>>> >>>> This is running SCHED_ULE >>>> >>>> is this expected? >>>> >>>> What can I do to help? >>> >>> Can you please produce the schedgraph output for this workload? >>> Do you know how to setup it? >> >> I'm not familiar with this. What do I need to do? > > - Recompile your kernel with the following options: > KTR > KTR_COMPILE=(KTR_SCHED) > KTR_MASK=(KTR_SCHED) > KTR_ENTRIES=262144 > > - Run the buggy workload > - When the slowness has been experienced a bit (a reasonable timeframe > is within 10/20 secs) do: sysctl debug.ktr.mask=0 > - do: ktrdump -ct > ktr.out > - send here this file along with the number and frequency of your CPUs Sent under separate cover direct to Attilio. Thanks, Attilio! > > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From sgk at troutmask.apl.washington.edu Mon Oct 12 01:48:48 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Mon Oct 12 01:48:55 2009 Subject: Scheduler weirdness In-Reply-To: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> References: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> Message-ID: <20091012014846.GB38325@troutmask.apl.washington.edu> On Sun, Oct 11, 2009 at 05:59:52PM -0500, Larry Rosenman wrote: > > Ok, running RELENG_8 from Friday (10/9/2009). > > If I have 4 Folding-at-home processes running (they nice themselves) the > system is slow as a dog. > > If I stop them, it's speedy. > > This is running SCHED_ULE > > is this expected? > > What can I do to help? > How many cpus are available on your system? If you're in an over-commit situation with numerical intensive applications, you may find 4BSD to be a better option. -- Steve From ler at lerctr.org Mon Oct 12 01:51:50 2009 From: ler at lerctr.org (Larry Rosenman) Date: Mon Oct 12 01:52:02 2009 Subject: Scheduler weirdness In-Reply-To: <20091012014846.GB38325@troutmask.apl.washington.edu> References: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> <20091012014846.GB38325@troutmask.apl.washington.edu> Message-ID: On Sun, October 11, 2009 8:48 pm, Steve Kargl wrote: > On Sun, Oct 11, 2009 at 05:59:52PM -0500, Larry Rosenman wrote: >> >> Ok, running RELENG_8 from Friday (10/9/2009). >> >> If I have 4 Folding-at-home processes running (they nice themselves) the >> system is slow as a dog. >> >> If I stop them, it's speedy. >> >> This is running SCHED_ULE >> >> is this expected? >> >> What can I do to help? >> > > How many cpus are available on your system? If you're in an > over-commit situation with numerical intensive applications, > you may find 4BSD to be a better option. 4 cpu's. $ sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.temperature: 50.0C dev.cpu.0.freq: 1867 dev.cpu.0.freq_levels: 1867/35000 1633/30625 1400/26250 1166/21875 933/17500 700/13125 466/8750 233/4375 dev.cpu.0.cx_supported: C1/1 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% last 500us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.temperature: 53.0C dev.cpu.1.cx_supported: C1/1 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% last 500us dev.cpu.2.%desc: ACPI CPU dev.cpu.2.%driver: cpu dev.cpu.2.%location: handle=\_PR_.CPU2 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%parent: acpi0 dev.cpu.2.temperature: 54.0C dev.cpu.2.cx_supported: C1/1 dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_usage: 100.00% last 500us dev.cpu.3.%desc: ACPI CPU dev.cpu.3.%driver: cpu dev.cpu.3.%location: handle=\_PR_.CPU3 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%parent: acpi0 dev.cpu.3.temperature: 55.0C dev.cpu.3.cx_supported: C1/1 dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_usage: 100.00% last 500us $ > > -- > Steve > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From sgk at troutmask.apl.washington.edu Mon Oct 12 02:39:13 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Mon Oct 12 02:39:19 2009 Subject: Scheduler weirdness In-Reply-To: References: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> <20091012014846.GB38325@troutmask.apl.washington.edu> Message-ID: <20091012023912.GA38822@troutmask.apl.washington.edu> On Sun, Oct 11, 2009 at 08:51:48PM -0500, Larry Rosenman wrote: > > On Sun, October 11, 2009 8:48 pm, Steve Kargl wrote: > > On Sun, Oct 11, 2009 at 05:59:52PM -0500, Larry Rosenman wrote: > >> > >> Ok, running RELENG_8 from Friday (10/9/2009). > >> > >> If I have 4 Folding-at-home processes running (they nice themselves) the > >> system is slow as a dog. > >> > >> If I stop them, it's speedy. > >> > >> This is running SCHED_ULE > >> > >> is this expected? > >> > >> What can I do to help? > >> > > > > How many cpus are available on your system? If you're in an > > over-commit situation with numerical intensive applications, > > you may find 4BSD to be a better option. > 4 cpu's. > So, you have 4 cpus and 4 folding-at-home processes and you're trying to use the system with other apps? Switch to 4BSD. -- Steve From alex at mailinglist.ahhyes.net Mon Oct 12 04:06:19 2009 From: alex at mailinglist.ahhyes.net (Alex R) Date: Mon Oct 12 04:06:26 2009 Subject: Scheduler weirdness In-Reply-To: <20091012023912.GA38822@troutmask.apl.washington.edu> References: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> <20091012014846.GB38325@troutmask.apl.washington.edu> <20091012023912.GA38822@troutmask.apl.washington.edu> Message-ID: <4AD29937.2040004@mailinglist.ahhyes.net> Steve Kargl wrote: > So, you have 4 cpus and 4 folding-at-home processes and you're > trying to use the system with other apps? Switch to 4BSD. > > I thought SCHED_ULE was meant to be a much better choice under an SMP environment. Why are you suggesting he rebuild his kernel and use the legacy scheduler? From sgk at troutmask.apl.washington.edu Mon Oct 12 04:33:59 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Mon Oct 12 04:34:05 2009 Subject: Scheduler weirdness In-Reply-To: <4AD29937.2040004@mailinglist.ahhyes.net> References: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> <20091012014846.GB38325@troutmask.apl.washington.edu> <20091012023912.GA38822@troutmask.apl.washington.edu> <4AD29937.2040004@mailinglist.ahhyes.net> Message-ID: <20091012043358.GA39364@troutmask.apl.washington.edu> On Mon, Oct 12, 2009 at 01:49:27PM +1100, Alex R wrote: > Steve Kargl wrote: > >So, you have 4 cpus and 4 folding-at-home processes and you're > >trying to use the system with other apps? Switch to 4BSD. > > > > > > I thought SCHED_ULE was meant to be a much better choice under an SMP > environment. Why are you suggesting he rebuild his kernel and use the > legacy scheduler? > If you have N cpus and N+1 numerical intensitive applications, ULE may have poor performance compared to 4BSD. In OP's case, he has 4 cpus and 4 numerical intensity (?) applications. He, however, also is trying to use the system in some interactive way. -- Steve From alex at mailinglist.ahhyes.net Mon Oct 12 04:35:29 2009 From: alex at mailinglist.ahhyes.net (Alex R) Date: Mon Oct 12 04:35:37 2009 Subject: Scheduler weirdness In-Reply-To: <20091012043358.GA39364@troutmask.apl.washington.edu> References: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> <20091012014846.GB38325@troutmask.apl.washington.edu> <20091012023912.GA38822@troutmask.apl.washington.edu> <4AD29937.2040004@mailinglist.ahhyes.net> <20091012043358.GA39364@troutmask.apl.washington.edu> Message-ID: <4AD2B203.8030405@mailinglist.ahhyes.net> Steve Kargl wrote: > On Mon, Oct 12, 2009 at 01:49:27PM +1100, Alex R wrote: > >> Steve Kargl wrote: >> >>> So, you have 4 cpus and 4 folding-at-home processes and you're >>> trying to use the system with other apps? Switch to 4BSD. >>> >>> >>> >> I thought SCHED_ULE was meant to be a much better choice under an SMP >> environment. Why are you suggesting he rebuild his kernel and use the >> legacy scheduler? >> >> > > If you have N cpus and N+1 numerical intensitive applications, > ULE may have poor performance compared to 4BSD. In OP's case, > he has 4 cpus and 4 numerical intensity (?) applications. He, > however, also is trying to use the system in some interactive > way. > > Ah ok. Is this just an accepted thing by the freebsd dev's or are they trying to fix it? From inpcb.harsha at gmail.com Mon Oct 12 04:38:34 2009 From: inpcb.harsha at gmail.com (Harsha) Date: Mon Oct 12 04:38:46 2009 Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] In-Reply-To: References: Message-ID: Hi Robert, On Sun, Oct 11, 2009 at 1:30 PM, Robert Watson wrote: > Giant is a bit special in that the long-term sleep code in the kernel knows > to drop it when sleeping, and re-acquire when waking up. ?So, unlike all > other mutexes, it should be OK to hold it in this case, as Giant will simply > get dropped if the kernel has to sleep waiting on a sleepable lock. ?This is > because, historically in FreeBSD 3.x/4.x, the kernel was protected by a > single spinlock, which would get released whenever the kernel stopped > executing, such as during an I/O sleep. ?On the whole, Giant has disappeared > from the modern kernel, but where it is used, it retains those curious > historic properties. > > To break things down a bit further, IFNET_WLOCK is, itself, a bit special: > notice that in FreeBSD 8, it's actually two locks, a sleep lock, and a > mutex, which must both be acquired exclusively to ensure mutual exclusion. > if_alloc() and associated calls are also sleepable because they perform > potentially sleeping memory allocation (M_WAITOK), so it's an invariant of > any code calling interface allocation that it must be able to tolerate a > sleep. Thanks a lot for the clarification. I had assumed that the lock was non-sleepable looking at this log - Kernel page fault with the following non-sleepable locks held: exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0f63464) locked @ /usr/src/sys/net/if.c:409 > Do you have a copy of the stack trace and fault information handy? ?In my > experience, a NULL pointer deref or other page fault in the locking code for > a global lock is almost always corrupted thread state, perhaps due to > tripping over another thread having locked a corrupted/freed/uninitialized > lock. ?We might be able to track that down by tracing other threads that > were in execution at the time of the panic. I just tried the textdump feature and I think its an awesome tool. Here is ddb.txt- http://docs.google.com/View?id=dddwnxfj_0dh4x58hc And msgbuf.txt- http://docs.google.com/View?id=dddwnxfj_1cnmrb8fw For some reason the output of show alllocks is not written into ddb.txt, though I have increased the buffer size to 2MB. Thanks, Harsha From taku at tackymt.homeip.net Mon Oct 12 04:42:05 2009 From: taku at tackymt.homeip.net (Taku YAMAMOTO) Date: Mon Oct 12 04:42:12 2009 Subject: Scheduler weirdness In-Reply-To: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> References: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> Message-ID: <20091012134159.8f6e4d66.taku@tackymt.homeip.net> On Sun, 11 Oct 2009 17:59:52 -0500 "Larry Rosenman" wrote: > > Ok, running RELENG_8 from Friday (10/9/2009). > > If I have 4 Folding-at-home processes running (they nice themselves) the > system is slow as a dog. Ah, I reminded a local patch regarding SCHED_ULE against niced threads. Something like this: --- sys/kern/sched_ule.c.orig 2009-04-29 12:26:30.000000000 +0900 +++ sys/kern/sched_ule.c 2009-04-30 08:13:30.951440396 +0900 @@ -1406,7 +1406,7 @@ sched_priority(struct thread *td) * score. Negative nice values make it easier for a thread to be * considered interactive. */ - score = imax(0, sched_interact_score(td) - td->td_proc->p_nice); + score = imax(0, sched_interact_score(td) + td->td_proc->p_nice); if (score < sched_interact) { pri = PRI_MIN_REALTIME; pri += ((PRI_MAX_REALTIME - PRI_MIN_REALTIME) / sched_interact) > > If I stop them, it's speedy. > > This is running SCHED_ULE > > is this expected? > > What can I do to help? > > These are Linux binaries. -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From sgk at troutmask.apl.washington.edu Mon Oct 12 04:49:12 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Mon Oct 12 04:49:18 2009 Subject: Scheduler weirdness In-Reply-To: <4AD2B203.8030405@mailinglist.ahhyes.net> References: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> <20091012014846.GB38325@troutmask.apl.washington.edu> <20091012023912.GA38822@troutmask.apl.washington.edu> <4AD29937.2040004@mailinglist.ahhyes.net> <20091012043358.GA39364@troutmask.apl.washington.edu> <4AD2B203.8030405@mailinglist.ahhyes.net> Message-ID: <20091012044911.GA39479@troutmask.apl.washington.edu> On Mon, Oct 12, 2009 at 03:35:15PM +1100, Alex R wrote: > Steve Kargl wrote: > >On Mon, Oct 12, 2009 at 01:49:27PM +1100, Alex R wrote: > > > >>Steve Kargl wrote: > >> > >>>So, you have 4 cpus and 4 folding-at-home processes and you're > >>>trying to use the system with other apps? Switch to 4BSD. > >>> > >>> > >>> > >>I thought SCHED_ULE was meant to be a much better choice under an SMP > >>environment. Why are you suggesting he rebuild his kernel and use the > >>legacy scheduler? > >> > >> > > > >If you have N cpus and N+1 numerical intensitive applications, > >ULE may have poor performance compared to 4BSD. In OP's case, > >he has 4 cpus and 4 numerical intensity (?) applications. He, > >however, also is trying to use the system in some interactive > >way. > > > > > Ah ok. Is this just an accepted thing by the freebsd dev's or are they > trying to fix it? > Jeff appears to be extremely busy with other projects. He is aware of the problem, and I have set up my system to give him access when/if it is so desired. Here's the text of my last set of tests that I sent to him OK, I've manage to recreate the problem. User kargl launches a mpi job on node10 that creates two images on node20. This is command z in the top(1) info. 30 seconds later, user sgk lauches a mpi process on node10 that creates 8 images on node20. This is command rivmp in top(1) info. With 8 available cpus, this is a (slightly) oversubscribed node. For 4BSD, I see last pid: 1432; load averages: 8.68, 5.65, 2.82 up 0+01:52:14 17:07:22 40 processes: 11 running, 29 sleeping CPU: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle Mem: 32M Active, 12M Inact, 203M Wired, 424K Cache, 29M Buf, 31G Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 1428 sgk 1 124 0 81788K 5848K CPU3 6 1:13 78.81% rivmp 1431 sgk 1 124 0 81788K 5652K RUN 1 1:13 78.52% rivmp 1415 kargl 1 124 0 78780K 4668K CPU7 1 1:38 78.42% z 1414 kargl 1 124 0 78780K 4664K CPU0 0 1:37 77.25% z 1427 sgk 1 124 0 81788K 5852K CPU4 3 1:13 78.42% rivmp 1432 sgk 1 124 0 81788K 5652K CPU2 4 1:13 78.27% rivmp 1425 sgk 1 124 0 81788K 6004K CPU5 5 1:12 78.17% rivmp 1426 sgk 1 124 0 81788K 5832K RUN 6 1:13 78.03% rivmp 1429 sgk 1 124 0 81788K 5788K CPU6 7 1:12 77.98% rivmp 1430 sgk 1 124 0 81788K 5764K RUN 2 1:13 77.93% rivmp Notice, the accumulated times appear reasonable. At this point in the computations, rivmp is doing no communication between processes. z is the netpipe benchmark and is essentially sending messages between the two processes over the memory bus. For ULE, I see last pid: 1169; load averages: 7.56, 2.61, 1.02 up 0+00:03:15 17:13:01 40 processes: 11 running, 29 sleeping CPU: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle Mem: 31M Active, 9392K Inact, 197M Wired, 248K Cache, 26M Buf, 31G Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 1168 sgk 1 118 0 81788K 5472K CPU6 6 1:18 100.00% rivmp 1169 sgk 1 118 0 81788K 5416K CPU7 7 1:18 100.00% rivmp 1167 sgk 1 118 0 81788K 5496K CPU5 5 1:18 100.00% rivmp 1166 sgk 1 118 0 81788K 5564K RUN 4 1:18 100.00% rivmp 1151 kargl 1 118 0 78780K 4464K CPU3 3 1:48 99.27% z 1152 kargl 1 110 0 78780K 4464K CPU0 0 1:18 62.89% z 1164 sgk 1 113 0 81788K 5592K CPU1 1 0:55 80.76% rivmp 1165 sgk 1 110 0 81788K 5544K RUN 0 0:52 62.16% rivmp 1163 sgk 1 107 0 81788K 5624K RUN 2 0:40 50.68% rivmp 1162 sgk 1 107 0 81788K 5824K CPU2 2 0:39 50.49% rivmp In the above, processes 1162-1165 are clearly not receiving sufficient time slices to keep up with the other 4 rivmp images. From watching top at a 1 second interval, once the 4 rivmp hit 100% CPU, they stayed pinned to their cpu and stay at 100% CPU. It is also seen that processes 1152, 1165 and 1162, 1163 are stuck on cpus 0 and 2, respectively. -- Steve From ohartman at zedat.fu-berlin.de Mon Oct 12 07:44:38 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Mon Oct 12 07:44:45 2009 Subject: Scheduler weirdness In-Reply-To: <20091012044911.GA39479@troutmask.apl.washington.edu> References: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> <20091012014846.GB38325@troutmask.apl.washington.edu> <20091012023912.GA38822@troutmask.apl.washington.edu> <4AD29937.2040004@mailinglist.ahhyes.net> <20091012043358.GA39364@troutmask.apl.washington.edu> <4AD2B203.8030405@mailinglist.ahhyes.net> <20091012044911.GA39479@troutmask.apl.washington.edu> Message-ID: <4AD2DE71.5060601@zedat.fu-berlin.de> Steve Kargl wrote: > On Mon, Oct 12, 2009 at 03:35:15PM +1100, Alex R wrote: >> Steve Kargl wrote: >>> On Mon, Oct 12, 2009 at 01:49:27PM +1100, Alex R wrote: >>> >>>> Steve Kargl wrote: >>>> >>>>> So, you have 4 cpus and 4 folding-at-home processes and you're >>>>> trying to use the system with other apps? Switch to 4BSD. >>>>> >>>>> >>>>> >>>> I thought SCHED_ULE was meant to be a much better choice under an SMP >>>> environment. Why are you suggesting he rebuild his kernel and use the >>>> legacy scheduler? >>>> >>>> >>> If you have N cpus and N+1 numerical intensitive applications, >>> ULE may have poor performance compared to 4BSD. In OP's case, >>> he has 4 cpus and 4 numerical intensity (?) applications. He, >>> however, also is trying to use the system in some interactive >>> way. >>> >>> >> Ah ok. Is this just an accepted thing by the freebsd dev's or are they >> trying to fix it? >> > > Jeff appears to be extremely busy with other projects. He is aware of > the problem, and I have set up my system to give him access when/if it > is so desired. > > Here's the text of my last set of tests that I sent to him > > OK, I've manage to recreate the problem. User kargl launches a mpi > job on node10 that creates two images on node20. This is command z > in the top(1) info. 30 seconds later, user sgk lauches a mpi process > on node10 that creates 8 images on node20. This is command rivmp in > top(1) info. With 8 available cpus, this is a (slightly) oversubscribed > node. > > For 4BSD, I see > > last pid: 1432; load averages: 8.68, 5.65, 2.82 up 0+01:52:14 17:07:22 > 40 processes: 11 running, 29 sleeping > CPU: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle > Mem: 32M Active, 12M Inact, 203M Wired, 424K Cache, 29M Buf, 31G Free > Swap: 4096M Total, 4096M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND > 1428 sgk 1 124 0 81788K 5848K CPU3 6 1:13 78.81% rivmp > 1431 sgk 1 124 0 81788K 5652K RUN 1 1:13 78.52% rivmp > 1415 kargl 1 124 0 78780K 4668K CPU7 1 1:38 78.42% z > 1414 kargl 1 124 0 78780K 4664K CPU0 0 1:37 77.25% z > 1427 sgk 1 124 0 81788K 5852K CPU4 3 1:13 78.42% rivmp > 1432 sgk 1 124 0 81788K 5652K CPU2 4 1:13 78.27% rivmp > 1425 sgk 1 124 0 81788K 6004K CPU5 5 1:12 78.17% rivmp > 1426 sgk 1 124 0 81788K 5832K RUN 6 1:13 78.03% rivmp > 1429 sgk 1 124 0 81788K 5788K CPU6 7 1:12 77.98% rivmp > 1430 sgk 1 124 0 81788K 5764K RUN 2 1:13 77.93% rivmp > > > Notice, the accumulated times appear reasonable. At this point in the > computations, rivmp is doing no communication between processes. z is > the netpipe benchmark and is essentially sending messages between the > two processes over the memory bus. > > > For ULE, I see > > last pid: 1169; load averages: 7.56, 2.61, 1.02 up 0+00:03:15 17:13:01 > 40 processes: 11 running, 29 sleeping > CPU: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle > Mem: 31M Active, 9392K Inact, 197M Wired, 248K Cache, 26M Buf, 31G Free > Swap: 4096M Total, 4096M Free > > PID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND > 1168 sgk 1 118 0 81788K 5472K CPU6 6 1:18 100.00% rivmp > 1169 sgk 1 118 0 81788K 5416K CPU7 7 1:18 100.00% rivmp > 1167 sgk 1 118 0 81788K 5496K CPU5 5 1:18 100.00% rivmp > 1166 sgk 1 118 0 81788K 5564K RUN 4 1:18 100.00% rivmp > 1151 kargl 1 118 0 78780K 4464K CPU3 3 1:48 99.27% z > 1152 kargl 1 110 0 78780K 4464K CPU0 0 1:18 62.89% z > 1164 sgk 1 113 0 81788K 5592K CPU1 1 0:55 80.76% rivmp > 1165 sgk 1 110 0 81788K 5544K RUN 0 0:52 62.16% rivmp > 1163 sgk 1 107 0 81788K 5624K RUN 2 0:40 50.68% rivmp > 1162 sgk 1 107 0 81788K 5824K CPU2 2 0:39 50.49% rivmp > > > In the above, processes 1162-1165 are clearly not receiving sufficient time > slices to keep up with the other 4 rivmp images. From watching top at a > 1 second interval, once the 4 rivmp hit 100% CPU, they stayed pinned to > their cpu and stay at 100% CPU. It is also seen that processes 1152, 1165 > and 1162, 1163 are stuck on cpus 0 and 2, respectively. > This isn't only bound to floating-point intense applications, even the operating system itselfs seems to suffer from SCHED_ULE. I saw, see and reported several performance issue under heavy load and for seconds (if not minutes!) 4+ CPU boxes get as stuck as a UP box does. Those sticky sitiuations are painful in cases where the box needs to be accessed via X11. The remaining four FreeBSD 8.0-boxes used for numerical applications in our lab (others switched to Linux a long time ago) all uses SCHED_ULE, as this scheduler was introduced to be the superior scheduler over the legacy 4BSD. Well, I'll give 4BSD a chance again. At the moment, even our 8-core DELL Poweredge box is in production use, but if there is something I can do, menas: benchmarking, I'll give it a try. Regards, Oliver From ianf at clue.co.za Mon Oct 12 07:52:55 2009 From: ianf at clue.co.za (Ian FREISLICH) Date: Mon Oct 12 07:53:02 2009 Subject: alc(4) link autoselect problem In-Reply-To: <20091009194037.GI3843@michelle.cdnetworks.com> References: <20091009194037.GI3843@michelle.cdnetworks.com> <20091008170458.GC3843@michelle.cdnetworks.com> <20091007180257.GA3843@michelle.cdnetworks.com> Message-ID: Pyun YongHyeon wrote: > On Fri, Oct 09, 2009 at 07:29:08AM +0200, Ian FREISLICH wrote: > > Pyun YongHyeon wrote: > > > On Thu, Oct 08, 2009 at 12:38:45PM +0200, Ian FREISLICH wrote: > > > > wgsw-24010# sh interfaces status ethernet g14 > > > > Flow Link Back Mdix > > > > Port Type Duplex Speed Neg ctrl State Pressure Mode > > > > -------- ------------ ------ ----- -------- ---- ----------- -------- ---- > > --- > > > > g14 1G-Copper Full 100 Enabled Off Up Disabled Off > > > > > > > > > > Hmm, does your switch have an option to enable/disable downshifting > > > feature? If so, how about toggling the option? > > > > I'm not sure exactly what you mean. There's no configuration options > > that obviously match. > > > > Modern PHYs have ability to correct several cabling problems, for > example, > - pair swaps > - pair skews > - pair polarity > - automatic MDI/MDIX > - downshift to enable 10/100Mps link establishment with two > pairs by downgrading the link speed to 10/100Mbps during > auto-negotiation process when it can't establish 1000Mbps link. > Existing cables used to connect 10/100Mbps link partners may > have only two pairs. With two pairs PHYs can announce 1000Mbps > capability to link partner but it can't establish the link as > 1000Mbps link requires 4 pairs. > > Since F1 PHY seems to have above capability I just wanted to see > whether disabling downshifting on link partner makes any > difference. Yes, if I tell the switch to negotiate but not to advertise 1000f, link negotiation works with this PHY: wgsw-24010# sh interfaces advertise ethernet g14 Port: g14 Type: 1G-Copper Link state: Up Auto negotiation: Enabled 1000f 1000h 100f 100h 10f 10h ----- ----- ---- ---- --- --- Admin Local link Advertisement no no yes yes yes yes Oper Local link Advertisement no no yes yes yes yes Oper Remote link Advertisement no no yes yes yes yes Priority Resolution - - yes - - - alc0: flags=8843 metric 0 mtu 1500 options=3198 ether 00:25:b3:6f:ab:9a media: Ethernet autoselect (100baseTX ) status: active Ian -- Ian Freislich From jh at sandstorm.net Mon Oct 12 05:21:38 2009 From: jh at sandstorm.net (john hood) Date: Mon Oct 12 11:10:23 2009 Subject: Boot issues with a Dell Inspiron 530 and 8.0 RC1 In-Reply-To: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> References: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> Message-ID: <4AD2BCD9.2090904@sandstorm.net> Christian Schmidt wrote: > Hello list, > > I am seeing a strange issue with my Dell Inspiron 530 with 8.0 RC1-p1 > at around 50-75% percent of all boots. It all boils down to GENERIC > throwing the following: > > AP #1 (PHY #1) failed! > panic y/n? [y] panic: bye-bye > cpuid = 0 > > However, this only happens when booting from the hard disk. A boot > from the install CD works perfectly every time. Testing the machine > with 7.2 last night revealed the same issue, so this is not specific > to 8.0 > As an interesting side-note: the odds of a successful boot increase > dramtically when cold-booting. Rebooting from e.g. Linux or Windows > seems to push the failure-rate to around a 100% every time. > We have 3 of these machines. In my experience, keyboard activity triggers the problem. If I boot the machine without any keyboard presses/releases between the time the loader starts the kernel and some time later, definitely by the time the USB keyboard driver attaches, then I don't get this problem. This includes any key-up (and maybe key repeat) events you may generate after typing a key at the boot menu, or after typing enter at the OK prompt, or pressing a key to bypass the autoboot timeout that counts down by seconds. If you let the machine start from cold without touching the keyboard, what happens? If you get to the loader "ok " prompt, then enter "autoboot" and wait for it to time out and boot, what happens? If you press a key or type "boot" to boot the machine while in the loader, what happens? There's been some discussion of SMI-related problems and the long time SMI interrupts take on some machines; my guess is that this is related to that. --jh From patfbsd at davenulle.org Mon Oct 12 11:19:06 2009 From: patfbsd at davenulle.org (Patrick Lamaiziere) Date: Mon Oct 12 11:19:13 2009 Subject: 'ee' editor prints cyrillic characters on white background In-Reply-To: <20091008123001.GA82997@nagual.pp.ru> References: <20091004090156.GA85409@crete.org.ua> <20091008123001.GA82997@nagual.pp.ru> Message-ID: <20091012131901.6421666b@baby-jane.lamaiziere.net> Le Thu, 8 Oct 2009 16:30:01 +0400, Andrey Chernov a ?crit : > > I've upgraded my 7.2-RELEASE to 8.0-RC1. ee editor began to > > highlight cyrillic characters (locale uk_UA.KOI8-U) with white > > background and underscoring. Does anyone know how to disable this? > > Thanks. > > Fixed in -current. It would be nice to have this fixed in 8.0 too :-) Is it planned? Thanks, regards. From guru at unixarea.de Mon Oct 12 12:03:55 2009 From: guru at unixarea.de (Matthias Apitz) Date: Mon Oct 12 12:04:02 2009 Subject: kernel && SVN rev. number in 'uname -a' Message-ID: <20091012120352.GA3722@current.Sisis.de> Hello, I've build a kernel based on SVN checkout of head and compiled/installed the kernel with: # cd /usr # rm -rf src # svn co svn://.... # cd /usr/src # make buildkernel KERNCONF=GENERIC # make installkernel KERNCONF=GENERIC # shutdown -r now the booting kernel says: $ uname -a FreeBSD vm-azul.Sisis.de 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r197801: Mon Oct 12 13:33:32 CEST 2009 guru@vm-azul.Sisis.de:/usr/obj/usr/src/sys/GENERIC i386 i.e. does contain the SVN rev. number r197801, so far so good: when I now move the /usr/src to some other machine with: # cd /usr # tar cf src.tar src ... # cd /usr # rm -rf src # tar --unlink -xpf src.tar and build the kernel there exact the same way as on the originating machine, the output of 'uname -a' does not contain the SVN revision number. Any idea why is that? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ Vote NO to EU The Lisbon Treaty: http://www.no-means-no.eu From avg at icyb.net.ua Mon Oct 12 12:18:00 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Oct 12 12:18:08 2009 Subject: kernel && SVN rev. number in 'uname -a' In-Reply-To: <20091012120352.GA3722@current.Sisis.de> References: <20091012120352.GA3722@current.Sisis.de> Message-ID: <4AD31E6E.5020504@icyb.net.ua> on 12/10/2009 15:03 Matthias Apitz said the following: [snip] > and build the kernel there exact the same way as on the originating > machine, the output of 'uname -a' does not contain the SVN revision > number. Any idea why is that? Thanks Perhaps svn client is not installed there? -- Andriy Gapon From avg at icyb.net.ua Mon Oct 12 12:33:18 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Oct 12 12:33:29 2009 Subject: zfs boot vs loader Message-ID: <4AD3220B.5030502@icyb.net.ua> I am using ZFS for boot-and-root filesystem. gptzfsboot is used for bootstrapping, if that matters. Maybe the following is some kind of a pilot error, but I think that I see a problem with selecting a different kernel using loader prompt. That is, I escape to a loader prompt from boot menu. There I do 'unload'. Then I 'load' a different kernel, opensolaris.ko and zfs.ko. Then I 'boot'. Then root mounting inevitably fails because ZFS root filesystem can not be found. This is an unexpected result for me. I wonder if something important for ZFS get unloaded when I unload preloaded kernel and modules. Perhaps I have to manually re-load zpool.cache? This happens with recent CURRENT, amd64. What's strange is that I think that I can switch kernels from loader prompt without any problems when using RELENG_7 and UFS-boot-plus-ZFS-root approach. -- Andriy Gapon From guru at unixarea.de Mon Oct 12 12:35:52 2009 From: guru at unixarea.de (Matthias Apitz) Date: Mon Oct 12 12:35:59 2009 Subject: kernel && SVN rev. number in 'uname -a' In-Reply-To: <4AD31E6E.5020504@icyb.net.ua> References: <20091012120352.GA3722@current.Sisis.de> <4AD31E6E.5020504@icyb.net.ua> Message-ID: <20091012123550.GB3882@current.Sisis.de> El d?a Monday, October 12, 2009 a las 03:17:50PM +0300, Andriy Gapon escribi?: > on 12/10/2009 15:03 Matthias Apitz said the following: > [snip] > > and build the kernel there exact the same way as on the originating > > machine, the output of 'uname -a' does not contain the SVN revision > > number. Any idea why is that? Thanks > > Perhaps svn client is not installed there? Thanks for your hint. Ofc, the svn client is not installed on the 2nd machine (which has no access to Internet). Do you know how this, picking up the SVN rev. number during 'make buildkernel', is done exactly? I did a 2nd kernel build on the primary host, but the SVN cmd /usr/local/bin/svn is not touched as a 'ls -lu' shows ... As well I don't see any svn usage in the Makefiles to pick up a revision number; Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ Vote NO to EU The Lisbon Treaty: http://www.no-means-no.eu From avg at icyb.net.ua Mon Oct 12 12:43:33 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Oct 12 12:43:40 2009 Subject: kernel && SVN rev. number in 'uname -a' In-Reply-To: <20091012123550.GB3882@current.Sisis.de> References: <20091012120352.GA3722@current.Sisis.de> <4AD31E6E.5020504@icyb.net.ua> <20091012123550.GB3882@current.Sisis.de> Message-ID: <4AD32467.7020404@icyb.net.ua> on 12/10/2009 15:35 Matthias Apitz said the following: > El d?a Monday, October 12, 2009 a las 03:17:50PM +0300, Andriy Gapon escribi?: > >> on 12/10/2009 15:03 Matthias Apitz said the following: >> [snip] >>> and build the kernel there exact the same way as on the originating >>> machine, the output of 'uname -a' does not contain the SVN revision >>> number. Any idea why is that? Thanks >> Perhaps svn client is not installed there? > > Thanks for your hint. Ofc, the svn client is not installed on the 2nd > machine (which has no access to Internet). Do you know how this, picking > up the SVN rev. number during 'make buildkernel', is done exactly? I did > a 2nd kernel build on the primary host, but the SVN cmd > /usr/local/bin/svn is not touched as a 'ls -lu' shows ... > As well I don't see any svn usage in the Makefiles to pick up a revision > number; See sys/conf/newvers.sh. -- Andriy Gapon From des at des.no Mon Oct 12 12:44:51 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Oct 12 12:44:57 2009 Subject: kernel && SVN rev. number in 'uname -a' In-Reply-To: <20091012123550.GB3882@current.Sisis.de> (Matthias Apitz's message of "Mon, 12 Oct 2009 14:35:50 +0200") References: <20091012120352.GA3722@current.Sisis.de> <4AD31E6E.5020504@icyb.net.ua> <20091012123550.GB3882@current.Sisis.de> Message-ID: <86k4z0rdby.fsf@ds4.des.no> Matthias Apitz writes: > Thanks for your hint. Ofc, the svn client is not installed on the 2nd > machine (which has no access to Internet). Do you know how this, picking > up the SVN rev. number during 'make buildkernel', is done exactly? /usr/local/bin/svnversion > As well I don't see any svn usage in the Makefiles to pick up a revision > number; grep svn /sys/conf/newvers.sh I wish there were a way to disable this; it's slow and meaningless. DES -- Dag-Erling Sm?rgrav - des@des.no From tinderbox at freebsd.org Mon Oct 12 13:00:02 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 12 13:00:13 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <200910121300.n9CD002u051427@freebsd-current.sentex.ca> TB --- 2009-10-12 12:02:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 12:02:58 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-10-12 12:02:58 - cleaning the object tree TB --- 2009-10-12 12:03:21 - cvsupping the source tree TB --- 2009-10-12 12:03:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-10-12 12:03:43 - building world TB --- 2009-10-12 12:03:43 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 12:03:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 12:03:43 - TARGET=ia64 TB --- 2009-10-12 12:03:43 - TARGET_ARCH=ia64 TB --- 2009-10-12 12:03:43 - TZ=UTC TB --- 2009-10-12 12:03:43 - __MAKE_CONF=/dev/null TB --- 2009-10-12 12:03:43 - cd /src TB --- 2009-10-12 12:03:43 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 12:03:44 UTC 2009 >>> 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 [...] /src/sbin/ifconfig/ifieee80211.c:2634: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2636: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2638: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2639: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2641: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2642: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2644: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2645: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast *** Error code 1 Stop in /src/sbin/ifconfig. *** Error code 1 Stop in /obj/ia64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-12 13:00:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-12 13:00:00 - ERROR: failed to build world TB --- 2009-10-12 13:00:00 - 2693.48 user 431.46 system 3421.80 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From guru at unixarea.de Mon Oct 12 13:09:17 2009 From: guru at unixarea.de (Matthias Apitz) Date: Mon Oct 12 13:09:24 2009 Subject: 9-CURRENT (r197801) && artsd of kde-3.5.10_2 gives SIGSEGV In-Reply-To: <3a142e750910111214rb75f185k12b2cc7e1aba59d9@mail.gmail.com> References: <20091011062419.GA2168@current.Sisis.de> <3a142e750910111214rb75f185k12b2cc7e1aba59d9@mail.gmail.com> Message-ID: <20091012130914.GA4180@current.Sisis.de> El d?a Sunday, October 11, 2009 a las 07:14:21PM +0000, Paul B Mahol escribi?: > Make sure that all libraries and binarys are rebuild, thare may be ABI > changes and not > support for older code .... Hi Paul, I've compiled all (kernel, user land and the ports) in a virtual machine I'm using for preparing binary installation, i.e. after compiling the ports I create packages to install them on machines where you either can't compile for being to small/slow (like my EeePC 900) or to give a binary set away for installation where machines have limited access to Internet. I've build and installed kernel and user land based on SVN checkout: # svn info Path: . URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 197801 Node Kind: directory Schedule: normal Last Changed Author: maxim Last Changed Rev: 197799 Last Changed Date: 2009-10-06 06:57:18 +0200 (Tue, 06 Oct 2009) # uname -a FreeBSD vm-azul.Sisis.de 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r197801: Tue Oct 6 13:57:38 CEST 2009 guru@vm-azul.Sisis.de:/usr/obj/usr/src/sys/REBELION-HEAD i386 When kernel and user land have been on 9-CURRENT, I removed /usr/ports, checked them out with CVS and build all my ports, especially KDE3. I don't see how an old library or binary can cause this. Only some ABI change which is not supported in the KDE sources... Don't know if someone from FreeBSD's KDE team can (or will) comment on it. It seems to me that they all went away (to KDE4 :-)). Thx matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ Vote NO to EU The Lisbon Treaty: http://www.no-means-no.eu From tinderbox at freebsd.org Mon Oct 12 13:29:00 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 12 13:29:07 2009 Subject: [head tinderbox] failure on mips/mips Message-ID: <200910121328.n9CDSxCG092752@freebsd-current.sentex.ca> TB --- 2009-10-12 12:49:04 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 12:49:04 - starting HEAD tinderbox run for mips/mips TB --- 2009-10-12 12:49:04 - cleaning the object tree TB --- 2009-10-12 12:49:14 - cvsupping the source tree TB --- 2009-10-12 12:49:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2009-10-12 12:49:39 - building world TB --- 2009-10-12 12:49:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 12:49:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 12:49:39 - TARGET=mips TB --- 2009-10-12 12:49:39 - TARGET_ARCH=mips TB --- 2009-10-12 12:49:39 - TZ=UTC TB --- 2009-10-12 12:49:39 - __MAKE_CONF=/dev/null TB --- 2009-10-12 12:49:39 - cd /src TB --- 2009-10-12 12:49:39 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 12:49:39 UTC 2009 >>> 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 [...] /src/sbin/ifconfig/ifieee80211.c:2634: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2636: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2638: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2639: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2641: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2642: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2644: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2645: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast *** Error code 1 Stop in /src/sbin/ifconfig. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-12 13:28:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-12 13:28:59 - ERROR: failed to build world TB --- 2009-10-12 13:28:59 - 1713.18 user 395.52 system 2395.04 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From rwatson at freebsd.org Mon Oct 12 13:44:06 2009 From: rwatson at freebsd.org (Robert N. M. Watson) Date: Mon Oct 12 13:44:12 2009 Subject: FYI: "8.0TODO" wiki page updated In-Reply-To: <19e9a5dc0910111409l6e9b80a3rafaca3abe6d63e32@mail.gmail.com> References: <19e9a5dc0910111409l6e9b80a3rafaca3abe6d63e32@mail.gmail.com> Message-ID: <0037C4F1-7AA4-4010-AE7B-75360EA17D2D@freebsd.org> On 11 Oct 2009, at 22:09, Gonzalo Nemmi wrote: > On Sun, Oct 11, 2009 at 9:34 AM, Robert Watson > wrote: > > FYI for those tracking the 8.0 release: after a haitus of about a > month around the FreeBSD Developer Summit and EuroBSDCon 2009 here > in Cambridge, and with the help of Colin Percival, the 8.0TODO wiki > page is now up-to-date: > > http://wiki.FreeBSD.org/8.0TODO > > We'll endeavour to keep it more up-to-date going forward; there's > nothing like hosting a conference to get you behind on e-mail :-). > I just took a look at the recently anounced updated TODO lists for > 8.0 (http://wiki.freebsd.org/8.0TODO) but couldn't find a anything > about PR kern/136876: [bge] bge will not resume properly after > suspend. > Does that mean that 8.0 will be released without a fix for kern/ > 136876? Hi Gonzalo-- I'm not aware of the status of this bug, but have CC'd Stanislav Sedov, who has recently been working on other known if_bge issues for 8.0. At this point things are pretty late in the cycle, and device driver modifications (especially for sensitive drivers such as bge) represent a significant risk, so things may not change; however, perhaps he has some thoughts along these lines? Thanks, Robert From rwatson at freebsd.org Mon Oct 12 13:46:06 2009 From: rwatson at freebsd.org (Robert N. M. Watson) Date: Mon Oct 12 13:46:13 2009 Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] In-Reply-To: References: Message-ID: On 12 Oct 2009, at 05:38, Harsha wrote: > Thanks a lot for the clarification. > > I had assumed that the lock was non-sleepable looking at this log - > Kernel page fault with the following non-sleepable locks held: > exclusive rw ifnet_rw (ifnet_rw) r = 0 (0xc0f63464) locked @ > /usr/src/sys/net/if.c:409 Looks like a NULL pointer dereference, so perhaps a more traditional bug -- could you convert ifindex_alloc_locked+0x71 to a line of code? You can do this using kgdb on the kernel symbols file, perhaps "l *ifindex_alloc_locked+0x71". Robert From tinderbox at freebsd.org Mon Oct 12 13:47:07 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 12 13:47:19 2009 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <200910121347.n9CDl6Ur007443@freebsd-current.sentex.ca> TB --- 2009-10-12 13:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 13:00:00 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-10-12 13:00:00 - cleaning the object tree TB --- 2009-10-12 13:00:18 - cvsupping the source tree TB --- 2009-10-12 13:00:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-10-12 13:00:44 - building world TB --- 2009-10-12 13:00:44 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 13:00:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 13:00:44 - TARGET=powerpc TB --- 2009-10-12 13:00:44 - TARGET_ARCH=powerpc TB --- 2009-10-12 13:00:44 - TZ=UTC TB --- 2009-10-12 13:00:44 - __MAKE_CONF=/dev/null TB --- 2009-10-12 13:00:44 - cd /src TB --- 2009-10-12 13:00:44 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 13:00:44 UTC 2009 >>> 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 [...] /src/sbin/ifconfig/ifieee80211.c:2634: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2636: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2638: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2639: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2641: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2642: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2644: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2645: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast *** Error code 1 Stop in /src/sbin/ifconfig. *** Error code 1 Stop in /obj/powerpc/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-12 13:47:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-12 13:47:06 - ERROR: failed to build world TB --- 2009-10-12 13:47:06 - 2190.93 user 424.20 system 2825.24 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From tinderbox at freebsd.org Mon Oct 12 13:53:13 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 12 13:53:20 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <200910121353.n9CDrBvV036530@freebsd-current.sentex.ca> TB --- 2009-10-12 13:09:14 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 13:09:14 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-10-12 13:09:14 - cleaning the object tree TB --- 2009-10-12 13:09:29 - cvsupping the source tree TB --- 2009-10-12 13:09:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-10-12 13:09:54 - building world TB --- 2009-10-12 13:09:54 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 13:09:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 13:09:54 - TARGET=sparc64 TB --- 2009-10-12 13:09:54 - TARGET_ARCH=sparc64 TB --- 2009-10-12 13:09:54 - TZ=UTC TB --- 2009-10-12 13:09:54 - __MAKE_CONF=/dev/null TB --- 2009-10-12 13:09:54 - cd /src TB --- 2009-10-12 13:09:54 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 13:09:55 UTC 2009 >>> 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 [...] /src/sbin/ifconfig/ifieee80211.c:2634: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2636: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2638: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2639: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2641: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2642: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2644: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2645: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast *** Error code 1 Stop in /src/sbin/ifconfig. *** Error code 1 Stop in /obj/sparc64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-12 13:53:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-12 13:53:11 - ERROR: failed to build world TB --- 2009-10-12 13:53:11 - 2032.88 user 417.82 system 2637.34 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From stas at deglitch.com Mon Oct 12 13:55:01 2009 From: stas at deglitch.com (Stanislav Sedov) Date: Mon Oct 12 14:01:15 2009 Subject: FYI: "8.0TODO" wiki page updated In-Reply-To: <0037C4F1-7AA4-4010-AE7B-75360EA17D2D@freebsd.org> References: <19e9a5dc0910111409l6e9b80a3rafaca3abe6d63e32@mail.gmail.com> <0037C4F1-7AA4-4010-AE7B-75360EA17D2D@freebsd.org> Message-ID: <20091012175457.4ea1bf2e.stas@deglitch.com> On Mon, 12 Oct 2009 14:44:03 +0100 "Robert N. M. Watson" mentioned: > Hi Gonzalo-- > > I'm not aware of the status of this bug, but have CC'd Stanislav > Sedov, who has recently been working on other known if_bge issues for > 8.0. At this point things are pretty late in the cycle, and device > driver modifications (especially for sensitive drivers such as bge) > represent a significant risk, so things may not change; however, > perhaps he has some thoughts along these lines? > Hi, Gonzalo! I've not looked into this issue yet, but I'll do it in the near future. Unfortunatly, I believe it is too late to expect the fix to be present in 8.x, but I'll look what I can do wrt. this issue. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091012/de58d77c/attachment.pgp From tinderbox at freebsd.org Mon Oct 12 14:08:19 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 12 14:08:27 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <200910121408.n9CE8Itx062663@freebsd-current.sentex.ca> TB --- 2009-10-12 13:26:06 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 13:26:06 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-10-12 13:26:06 - cleaning the object tree TB --- 2009-10-12 13:26:19 - cvsupping the source tree TB --- 2009-10-12 13:26:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-10-12 13:26:44 - building world TB --- 2009-10-12 13:26:44 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 13:26:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 13:26:44 - TARGET=sun4v TB --- 2009-10-12 13:26:44 - TARGET_ARCH=sparc64 TB --- 2009-10-12 13:26:44 - TZ=UTC TB --- 2009-10-12 13:26:44 - __MAKE_CONF=/dev/null TB --- 2009-10-12 13:26:44 - cd /src TB --- 2009-10-12 13:26:44 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 13:26:44 UTC 2009 >>> 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 [...] /src/sbin/ifconfig/ifieee80211.c:2634: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2636: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2638: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2639: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2641: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2642: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2644: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast /src/sbin/ifconfig/ifieee80211.c:2645: warning: passing argument 1 of 'memcmp' makes pointer from integer without a cast *** Error code 1 Stop in /src/sbin/ifconfig. *** Error code 1 Stop in /obj/sun4v/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-12 14:08:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-12 14:08:18 - ERROR: failed to build world TB --- 2009-10-12 14:08:18 - 2047.42 user 399.23 system 2531.70 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From kraduk at googlemail.com Mon Oct 12 14:55:02 2009 From: kraduk at googlemail.com (krad) Date: Mon Oct 12 14:55:09 2009 Subject: zfs boot vs loader In-Reply-To: <4AD3220B.5030502@icyb.net.ua> References: <4AD3220B.5030502@icyb.net.ua> Message-ID: 2009/10/12 Andriy Gapon > > I am using ZFS for boot-and-root filesystem. gptzfsboot is used for > bootstrapping, > if that matters. > Maybe the following is some kind of a pilot error, but I think that I see a > problem with selecting a different kernel using loader prompt. > That is, I escape to a loader prompt from boot menu. There I do 'unload'. > Then I > 'load' a different kernel, opensolaris.ko and zfs.ko. Then I 'boot'. Then > root > mounting inevitably fails because ZFS root filesystem can not be found. > > This is an unexpected result for me. > I wonder if something important for ZFS get unloaded when I unload > preloaded > kernel and modules. Perhaps I have to manually re-load zpool.cache? > > This happens with recent CURRENT, amd64. > What's strange is that I think that I can switch kernels from loader prompt > without any problems when using RELENG_7 and UFS-boot-plus-ZFS-root > approach. > > -- > Andriy Gapon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > before you boot the kernels check the values of the following are still set eg vfs.root.mountfrom="zfs:system/root" vfs.root.mountfrom.options=rw From ckane at colemankane.org Mon Oct 12 15:00:48 2009 From: ckane at colemankane.org (Coleman Kane) Date: Mon Oct 12 16:19:57 2009 Subject: FYI: "8.0TODO" wiki page updated In-Reply-To: <20091012175457.4ea1bf2e.stas@deglitch.com> References: <19e9a5dc0910111409l6e9b80a3rafaca3abe6d63e32@mail.gmail.com> <0037C4F1-7AA4-4010-AE7B-75360EA17D2D@freebsd.org> <20091012175457.4ea1bf2e.stas@deglitch.com> Message-ID: <1255358681.10169.2.camel@localhost> On Mon, 2009-10-12 at 17:54 +0400, Stanislav Sedov wrote: > On Mon, 12 Oct 2009 14:44:03 +0100 > "Robert N. M. Watson" mentioned: > > > Hi Gonzalo-- > > > > I'm not aware of the status of this bug, but have CC'd Stanislav > > Sedov, who has recently been working on other known if_bge issues for > > 8.0. At this point things are pretty late in the cycle, and device > > driver modifications (especially for sensitive drivers such as bge) > > represent a significant risk, so things may not change; however, > > perhaps he has some thoughts along these lines? > > > > Hi, Gonzalo! > > I've not looked into this issue yet, but I'll do it in the near future. > Unfortunatly, I believe it is too late to expect the fix to be present > in 8.x, but I'll look what I can do wrt. this issue. > Hi guys, Please send any fix or potential fix for evaluation my way. I attempted to fix this bug awhile back myself, but was unable to pin down what was going on. FreeBSD 9-CURRENT/amd64. This one is particularly a nuisance for me, as is the last thing that prevents me from using Suspend on my HP notebook for anything. (Well, I still need to fix whatever causes NDIS to break as well, but that's less important, and I suspect partly a Win32 API issue). -- Coleman Kane From gnemmi at gmail.com Mon Oct 12 17:27:44 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Mon Oct 12 17:27:50 2009 Subject: FYI: "8.0TODO" wiki page updated In-Reply-To: <1255358681.10169.2.camel@localhost> References: <19e9a5dc0910111409l6e9b80a3rafaca3abe6d63e32@mail.gmail.com> <0037C4F1-7AA4-4010-AE7B-75360EA17D2D@freebsd.org> <20091012175457.4ea1bf2e.stas@deglitch.com> <1255358681.10169.2.camel@localhost> Message-ID: <19e9a5dc0910121027l597697a9j48a17fde6da28aa4@mail.gmail.com> On Mon, Oct 12, 2009 at 11:44 AM, Coleman Kane wrote: > On Mon, 2009-10-12 at 17:54 +0400, Stanislav Sedov wrote: > > On Mon, 12 Oct 2009 14:44:03 +0100 > > "Robert N. M. Watson" mentioned: > > > > > Hi Gonzalo-- > > > > > > I'm not aware of the status of this bug, but have CC'd Stanislav > > > Sedov, who has recently been working on other known if_bge issues for > > > 8.0. At this point things are pretty late in the cycle, and device > > > driver modifications (especially for sensitive drivers such as bge) > > > represent a significant risk, so things may not change; however, > > > perhaps he has some thoughts along these lines? > > > > > > > Hi, Gonzalo! > > > > I've not looked into this issue yet, but I'll do it in the near future. > > Unfortunatly, I believe it is too late to expect the fix to be present > > in 8.x, but I'll look what I can do wrt. this issue. > > > > Hi guys, > > Please send any fix or potential fix for evaluation my way. I attempted > to fix this bug awhile back myself, but was unable to pin down what was > going on. FreeBSD 9-CURRENT/amd64. > > This one is particularly a nuisance for me, as is the last thing that > prevents me from using Suspend on my HP notebook for anything. (Well, I > still need to fix whatever causes NDIS to break as well, but that's less > important, and I suspect partly a Win32 API issue). > > -- > Coleman Kane > > Same in here, please send any fix or potential fix for evaluation my way ... if_bge not waking up is the only thing preventing me from resuming (regardless of kern/136946 which doesn't affect me that much as I don't own or use firewire dongles .. I even comment the driver out ouf my kernel) on my i386 8.0-RC1, so .. if_bge waking up makes a lot of difference for me Thanks Robert and Stanislav for you kind and prompt answers. Thanks Coleman for pitching in. Best Regards Gonzalo Nemmi From bland at bbnest.net Mon Oct 12 17:41:07 2009 From: bland at bbnest.net (Alexander Nedotsukov) Date: Mon Oct 12 17:56:33 2009 Subject: 8.0 Dynamic Linker Broken? (Was: [PATCH] SASL problems with spnego on 8.0-BETA4) In-Reply-To: References: <54ee35ff63fa25ea4c082134892835fb@mail> <0EA2E119-29DF-4DDE-84C3-432E35D61C76@rabson.org> Message-ID: On 05.10.2009, at 20:07, Alexander Nedotsukov wrote: > Doug, > > I share your concerns about wrong libgssapi_foo usage. > Do you see any possible drawbacks of: > 3) Move libgssapi_foo into gssapi/libfoo_mech and link libgoo_mech > against libgssapi Well after reading about GSSAPI private extensions. I'd say this was not a good idea. If it even can be considered an idea at all. > > Thanks, > Alexander > > On 05.10.2009, at 16:29, Doug Rabson wrote: > >> This is the core of the problem, I think. There are two possible >> solutions: >> >> 1. Link libgssapi_foo.so against libgssapi.so. I'm not a fan of >> this because it will encourage people to link with >> libgssapi_krb5.so when they really ought to be linking with >> libgssapi.so to give them mechanism independance. >> >> 2. Split the various mechanism libs in to two parts, mech_foo.so >> which will contain the actual mechanism implementation (this can >> link with libgssapi.so to handle the RTLD_LOCAL issue) and >> optionally libgssapi_foo.so to contain any mechanism-specific >> extensions. >> >> Clearly (2) is unsuitable for 8.0 but could happen in current. I >> guess we could use (1) as a band-aid fix for 8.0. >> >> On 5 Oct 2009, at 05:50, Alexander Nedotsukov wrote: >> >>> >>> Actually this may mean quite otherwise. >>> What I saying is if some code (eg. libsasl) dlopen() libgssapi as >>> RTLD_LOCAL then later attempt to load libgssapi_xxx inside >>> libgssapi may >>> fail because of this: >>> >>> $ldd /usr/lib/libgssapi_spnego.so >>> /usr/lib/libgssapi_spnego.so: >>> libasn1.so.10 => /usr/lib/libasn1.so.10 (0x28300000) >>> libc.so.7 => /lib/libc.so.7 (0x2808f000) >>> >>> I would expect to see libgssapi.so.10 dependency here. >>> >>> On Mon, 5 Oct 2009 10:07:20 +1100, John Marshall >>> wrote: >>>> On Fri, 02 Oct 2009, 08:24 -0400, John Baldwin wrote: >>>>> On Friday 02 October 2009 4:13:19 am John Marshall wrote: >>>>>> On Tue, 22 Sep 2009, 08:22 +1000, John Marshall wrote: >>>>>>> On Mon, 21 Sep 2009, 11:26 -0400, Rick Macklem wrote: >>>>>>> >>>> [snip] >>>>>>>> >>>>>>>> Now, hopefully someone who understands enough about dynamic >>>>>>>> linking will >>>>>>>> know if this is the correct fix for 8.0? (I'm going on a couple >>> of >>>>>>>> weeks >>>>>>>> vacation at the end of this week, so I won't be around to >>>>>>>> commit >>>>>>>> anything >>>>>>>> and don't understand it well enough to know if this is the >>> correct >>>>>>>> way >>>>>>>> to fix it.) >>>>>>>> >>>>>>>> So, hopefully someone else can pick this one up? >>>>>>>> >>>> [snip] >>>>>>> >>>>>>> I have submitted a patch to the FreeBSD Makefile which patches >>>>>>> the >>>>>>> vendor-supplied template for krb5-config. I should be >>>>>>> grateful if >>>>>>> dfr@ >>>>>>> or another src committer would please review this with a view to >>>>>>> obtaining re@ approval to commit it before 8.0-RC2. >>>>>>> >>>>>>> >>>>>> >>>>>> Any src committers able to help with this? >>>>> >>>>> Hmmm, I thought that libgssapi was supposed to use dlopen to >>>>> load the >>>>> proper >>>>> back-end libraries using /etc/gss/mech rather than having >>>>> applications >>>>> directly link against them. >>>> >>>> OK, so if my proposed solution is, in fact, only masking a >>>> symptom of a >>>> broken dynamic linker, would somebody who understands this stuff >>>> please >>>> weigh in on this with some debugging suggestions or with a patch to >>>> address this problem? >>>> >>>> I'm able to help with testing but I'm not a programmer and know >>>> nothing >>>> about the FreeBSD dynamic linker. >>>> >>>> Thanks. >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " From tinderbox at freebsd.org Mon Oct 12 18:51:27 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 12 18:51:34 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <200910121851.n9CIpQLI073656@freebsd-current.sentex.ca> TB --- 2009-10-12 18:33:09 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 18:33:09 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-10-12 18:33:09 - cleaning the object tree TB --- 2009-10-12 18:33:16 - cvsupping the source tree TB --- 2009-10-12 18:33:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-10-12 18:33:44 - building world TB --- 2009-10-12 18:33:44 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 18:33:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 18:33:44 - TARGET=ia64 TB --- 2009-10-12 18:33:44 - TARGET_ARCH=ia64 TB --- 2009-10-12 18:33:44 - TZ=UTC TB --- 2009-10-12 18:33:44 - __MAKE_CONF=/dev/null TB --- 2009-10-12 18:33:44 - cd /src TB --- 2009-10-12 18:33:44 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 18:33:44 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/ia64/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-12 18:51:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-12 18:51:26 - ERROR: failed to build world TB --- 2009-10-12 18:51:26 - 811.99 user 156.52 system 1096.90 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From tinderbox at freebsd.org Mon Oct 12 19:07:00 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 12 19:07:06 2009 Subject: [head tinderbox] failure on mips/mips Message-ID: <200910121906.n9CJ6xjP097300@freebsd-current.sentex.ca> TB --- 2009-10-12 18:51:26 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 18:51:26 - starting HEAD tinderbox run for mips/mips TB --- 2009-10-12 18:51:26 - cleaning the object tree TB --- 2009-10-12 18:51:32 - cvsupping the source tree TB --- 2009-10-12 18:51:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2009-10-12 18:51:57 - building world TB --- 2009-10-12 18:51:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 18:51:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 18:51:57 - TARGET=mips TB --- 2009-10-12 18:51:57 - TARGET_ARCH=mips TB --- 2009-10-12 18:51:57 - TZ=UTC TB --- 2009-10-12 18:51:57 - __MAKE_CONF=/dev/null TB --- 2009-10-12 18:51:57 - cd /src TB --- 2009-10-12 18:51:57 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 18:51:58 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/mips/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-12 19:06:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-12 19:06:59 - ERROR: failed to build world TB --- 2009-10-12 19:06:59 - 664.40 user 150.72 system 932.48 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From tinderbox at freebsd.org Mon Oct 12 19:24:15 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 12 19:24:21 2009 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <200910121924.n9CJOE4X037979@freebsd-current.sentex.ca> TB --- 2009-10-12 19:06:59 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 19:06:59 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-10-12 19:06:59 - cleaning the object tree TB --- 2009-10-12 19:07:06 - cvsupping the source tree TB --- 2009-10-12 19:07:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-10-12 19:07:31 - building world TB --- 2009-10-12 19:07:31 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 19:07:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 19:07:31 - TARGET=powerpc TB --- 2009-10-12 19:07:31 - TARGET_ARCH=powerpc TB --- 2009-10-12 19:07:31 - TZ=UTC TB --- 2009-10-12 19:07:31 - __MAKE_CONF=/dev/null TB --- 2009-10-12 19:07:31 - cd /src TB --- 2009-10-12 19:07:31 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 19:07:32 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/powerpc/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-12 19:24:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-12 19:24:14 - ERROR: failed to build world TB --- 2009-10-12 19:24:14 - 748.28 user 155.19 system 1035.12 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From marius at alchemy.franken.de Mon Oct 12 19:25:16 2009 From: marius at alchemy.franken.de (Marius Strobl) Date: Mon Oct 12 19:25:23 2009 Subject: [STATUS]: clang/llvm support on FreeBSD In-Reply-To: <20090924192103.GA84535@freebsd.org> References: <20090924192103.GA84535@freebsd.org> Message-ID: <20091012191305.GA9480@alchemy.franken.de> On Thu, Sep 24, 2009 at 09:21:03PM +0200, Roman Divacky wrote: > Hi, > > The clang@freebsd team presents the status of clang/llvm being > able to compile FreeBSD system. The situation as of today > (Sep 24th) is: > > > i386 - kernel boots, world needs little hacks but works > > amd64 - kernel compiles but does not boot, world needs > little hacks > > ppc - broken because of unknown RTLD bug > > other - unknown > > > all other platforms are untested. Ie. this is a regression from the > situation in early spring when we could boot amd64 as well... > > A lot has happened over the spring/summer - amd64 got proper mcmodel=kernel > support, compiler-rt was introduced (paving the way for libgcc replacement), > we ran two experimental ports build to see how clang does there, C++ support > is able to parse devd.cc without warnings, we got kernel working with -O2, > we promoted FreeBSD to be officially supported plaform in LLVM etc. etc. > > We have problems though: we don't have manpower for testing (thats why amd64 > kernel stopped booting) and developers for integrating stuff into FreeBSD > (maintaining ports etc.). So if you are interested in helping please contact > me or join us on IRC in #freebsd-clang on irc.oftc.net. We especially need > amd64 testers (because of the amd64 kernel bug) and people with minor platforms > like arm/mips/sparc to see how clang/llvm performs there and improve that > situation. > Is there any progress on support for 64-bit SPARC-V9 in LLVM as required for sparc64? Marius From marcus at freebsd.org Mon Oct 12 19:26:25 2009 From: marcus at freebsd.org (Joe Marcus Clarke) Date: Mon Oct 12 19:26:32 2009 Subject: sbsndptr panic on recent 9-CURRENT Message-ID: <4AD382DF.3040105@freebsd.org> I just upgraded to: FreeBSD jclarke-pc.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #6: Mon Oct 12 14:23:45 EDT 2009 marcus@jclarke-pc.cisco.com:/usr/obj/usr/src/sys/JCLARKE-PC i386 A few minutes after a reboot, I see: panic: sbsndptr: sockbuf 0xc5ba7c2c and mbuf 0xc5471300 clashing #3 0xc0667c1a in sbsndptr (sb=0xc5ba7c2c, off=Variable "off" is not available. ) at /usr/src/sys/kern/uipc_sockbuf.c:954 #4 0xc0755724 in tcp_output (tp=0xc5ab2000) at /usr/src/sys/netinet/tcp_output.c:814 #5 0xc0762b4a in tcp_usr_send (so=0xc5ba7b44, flags=0, m=0xc5471300, nam=0x0, control=0x0, td=0xc55ef8c0) at tcp_offload.h:282 #6 0xc066ded5 in sosend_generic (so=0xc5ba7b44, addr=0x0, uio=0xe7a62c58, top=0xc5471300, control=0x0, flags=0, td=0xc55ef8c0) at /usr/src/sys/kern/uipc_socket.c:1265 #7 0xc06697df in sosend (so=0xc5ba7b44, addr=0x0, uio=0xe7a62c58, top=0x0, control=0x0, flags=0, td=0xc55ef8c0) at /usr/src/sys/kern/uipc_socket.c:1309 #8 0xc064f343 in soo_write (fp=0xc5ad84d0, uio=0xe7a62c58, active_cred=0xc5bb4600, flags=0, td=0xc55ef8c0) at /usr/src/sys/kern/sys_socket.c:102 #9 0xc0648dd7 in dofilewrite (td=0xc55ef8c0, fd=3, fp=0xc5ad84d0, auio=0xe7a62c58, offset=-1, flags=0) at file.h:239 #10 0xc06490c8 in kern_writev (td=0xc55ef8c0, fd=3, auio=0xe7a62c58) at /usr/src/sys/kern/sys_generic.c:446 #11 0xc064914f in write (td=0xc55ef8c0, uap=0xe7a62cf8) at /usr/src/sys/kern/sys_generic.c:362 #12 0xc089f765 in syscall (frame=0xe7a62d38) at /usr/src/sys/i386/i386/trap.c:1078 #13 0xc0882440 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #14 0x00000033 in ?? () This machine uses em, gif, and PPP (tun) interfaces (with IPv4 and v6 addresses). I have since rebooted, so it may not be possible to provide many more details from this crash. However, if I see the crash again, is there anything more I should provide? Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome From tinderbox at freebsd.org Mon Oct 12 19:35:01 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 12 19:35:15 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <200910121935.n9CJZ0CH015449@freebsd-current.sentex.ca> TB --- 2009-10-12 19:18:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 19:18:58 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-10-12 19:18:58 - cleaning the object tree TB --- 2009-10-12 19:19:05 - cvsupping the source tree TB --- 2009-10-12 19:19:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-10-12 19:19:29 - building world TB --- 2009-10-12 19:19:29 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 19:19:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 19:19:29 - TARGET=sparc64 TB --- 2009-10-12 19:19:29 - TARGET_ARCH=sparc64 TB --- 2009-10-12 19:19:29 - TZ=UTC TB --- 2009-10-12 19:19:29 - __MAKE_CONF=/dev/null TB --- 2009-10-12 19:19:29 - cd /src TB --- 2009-10-12 19:19:29 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 19:19:30 UTC 2009 >>> 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 [...] cc -fPIC -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fPIC -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/sparc64/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-12 19:35:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-12 19:35:00 - ERROR: failed to build world TB --- 2009-10-12 19:35:00 - 680.11 user 150.86 system 961.63 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Mon Oct 12 19:40:01 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 12 19:40:13 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <200910121940.n9CJe0mH050057@freebsd-current.sentex.ca> TB --- 2009-10-12 19:24:14 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 19:24:14 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-10-12 19:24:14 - cleaning the object tree TB --- 2009-10-12 19:24:21 - cvsupping the source tree TB --- 2009-10-12 19:24:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-10-12 19:24:57 - building world TB --- 2009-10-12 19:24:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 19:24:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 19:24:57 - TARGET=sun4v TB --- 2009-10-12 19:24:57 - TARGET_ARCH=sparc64 TB --- 2009-10-12 19:24:57 - TZ=UTC TB --- 2009-10-12 19:24:57 - __MAKE_CONF=/dev/null TB --- 2009-10-12 19:24:57 - cd /src TB --- 2009-10-12 19:24:57 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 19:24:58 UTC 2009 >>> 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 [...] cc -fPIC -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fPIC -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/sun4v/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-12 19:40:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-12 19:40:00 - ERROR: failed to build world TB --- 2009-10-12 19:40:00 - 677.78 user 150.29 system 945.77 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From rdivacky at freebsd.org Mon Oct 12 20:53:22 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Mon Oct 12 20:53:28 2009 Subject: [STATUS]: clang/llvm support on FreeBSD In-Reply-To: <20091012191305.GA9480@alchemy.franken.de> References: <20090924192103.GA84535@freebsd.org> <20091012191305.GA9480@alchemy.franken.de> Message-ID: <20091012205254.GA86649@freebsd.org> On Mon, Oct 12, 2009 at 09:13:05PM +0200, Marius Strobl wrote: > On Thu, Sep 24, 2009 at 09:21:03PM +0200, Roman Divacky wrote: > > Hi, > > > > The clang@freebsd team presents the status of clang/llvm being > > able to compile FreeBSD system. The situation as of today > > (Sep 24th) is: > > > > > > i386 - kernel boots, world needs little hacks but works > > > > amd64 - kernel compiles but does not boot, world needs > > little hacks > > > > ppc - broken because of unknown RTLD bug > > > > other - unknown > > > > > > all other platforms are untested. Ie. this is a regression from the > > situation in early spring when we could boot amd64 as well... > > > > A lot has happened over the spring/summer - amd64 got proper mcmodel=kernel > > support, compiler-rt was introduced (paving the way for libgcc replacement), > > we ran two experimental ports build to see how clang does there, C++ support > > is able to parse devd.cc without warnings, we got kernel working with -O2, > > we promoted FreeBSD to be officially supported plaform in LLVM etc. etc. > > > > We have problems though: we don't have manpower for testing (thats why amd64 > > kernel stopped booting) and developers for integrating stuff into FreeBSD > > (maintaining ports etc.). So if you are interested in helping please contact > > me or join us on IRC in #freebsd-clang on irc.oftc.net. We especially need > > amd64 testers (because of the amd64 kernel bug) and people with minor platforms > > like arm/mips/sparc to see how clang/llvm performs there and improve that > > situation. > > > > Is there any progress on support for 64-bit SPARC-V9 in LLVM as > required for sparc64? unfortunately no. at least I am not aware of any such effort From rwatson at FreeBSD.org Mon Oct 12 23:13:54 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Oct 12 23:14:01 2009 Subject: sbsndptr panic on recent 9-CURRENT In-Reply-To: <4AD382DF.3040105@freebsd.org> References: <4AD382DF.3040105@freebsd.org> Message-ID: On Mon, 12 Oct 2009, Joe Marcus Clarke wrote: > This machine uses em, gif, and PPP (tun) interfaces (with IPv4 and v6 > addresses). I have since rebooted, so it may not be possible to provide > many more details from this crash. However, if I see the crash again, is > there anything more I should provide? Looks like you have a crashdump, though. Could you paste into an e-mail dumps of various relevant variables, especially *so, *inp, *tp at various stack frames? Robert From marcus at FreeBSD.org Mon Oct 12 23:42:24 2009 From: marcus at FreeBSD.org (Joe Marcus Clarke) Date: Mon Oct 12 23:42:31 2009 Subject: sbsndptr panic on recent 9-CURRENT In-Reply-To: References: <4AD382DF.3040105@freebsd.org> Message-ID: <1255390955.22880.15.camel@shumai.marcuscom.com> On Tue, 2009-10-13 at 00:13 +0100, Robert Watson wrote: > On Mon, 12 Oct 2009, Joe Marcus Clarke wrote: > > > This machine uses em, gif, and PPP (tun) interfaces (with IPv4 and v6 > > addresses). I have since rebooted, so it may not be possible to provide > > many more details from this crash. However, if I see the crash again, is > > there anything more I should provide? > > Looks like you have a crashdump, though. Could you paste into an e-mail dumps > of various relevant variables, especially *so, *inp, *tp at various stack > frames? Yep: frame 3: print *sb: $1 = {sb_sel = {si_tdlist = {tqh_first = 0x0, tqh_last = 0x0}, si_note = { kl_list = {slh_first = 0x0}, kl_lock = 0xc05d7f30 , kl_unlock = 0xc05d7ee0 , kl_assert_locked = 0xc05d50b0 , kl_assert_unlocked = 0xc05d50c0 , kl_lockarg = 0xc5ba7c50}, si_mtx = 0x0}, sb_mtx = {lock_object = { lo_name = 0xc0902cd1 "so_snd", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 3311335616}, sb_sx = {lock_object = { lo_name = 0xc09031f9 "so_snd_sx", lo_flags = 36896768, lo_data = 0, lo_witness = 0x0}, sx_lock = 3311335616}, sb_state = 0, sb_mb = 0xc5471300, sb_mbtail = 0xc5471300, sb_lastrecord = 0xc5471300, sb_sndptr = 0xc5471300, sb_sndptroff = 160, sb_cc = 224, sb_hiwat = 33304, sb_mbcnt = 256, sb_mcnt = 1, sb_ccnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 2048, sb_timeo = 0, sb_flags = 2048, sb_upcall = 0, sb_upcallarg = 0x0} frame 4: print *so: $3 = {so_count = 1, so_type = 1, so_options = 12, so_linger = 0, so_state = 258, so_qstate = 0, so_pcb = 0xc5ab1000, so_vnet = 0x0, so_proto = 0xc0956a48, so_head = 0x0, so_incomp = {tqh_first = 0x0, tqh_last = 0x0}, so_comp = {tqh_first = 0x0, tqh_last = 0x0}, so_list = {tqe_next = 0x0, tqe_prev = 0xc5779d08}, so_qlen = 0, so_incqlen = 0, so_qlimit = 0, so_timeo = 0, so_error = 0, so_sigio = 0x0, so_oobmark = 0, so_aiojobq = {tqh_first = 0x0, tqh_last = 0xc5ba7b90}, so_rcv = {sb_sel = {si_tdlist = {tqh_first = 0x0, tqh_last = 0xc5ba7b98}, si_note = {kl_list = {slh_first = 0x0}, kl_lock = 0xc05d7f30 , kl_unlock = 0xc05d7ee0 , kl_assert_locked = 0xc05d50b0 , kl_assert_unlocked = 0xc05d50c0 , kl_lockarg = 0xc5ba7bbc}, si_mtx = 0xc55103f8}, sb_mtx = {lock_object = {lo_name = 0xc0902cca "so_rcv", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, sb_sx = {lock_object = {lo_name = 0xc0903203 "so_rcv_sx", lo_flags = 36896768, lo_data = 0, lo_witness = 0x0}, sx_lock = 1}, sb_state = 0, sb_mb = 0x0, sb_mbtail = 0x0, sb_lastrecord = 0x0, sb_sndptr = 0x0, sb_sndptroff = 0, sb_cc = 0, sb_hiwat = 66608, sb_mbcnt = 0, sb_mcnt = 0, sb_ccnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 1, sb_timeo = 0, sb_flags = 2056, sb_upcall = 0, sb_upcallarg = 0x0}, so_snd = {sb_sel = {si_tdlist = {tqh_first = 0x0, tqh_last = 0x0}, si_note = {kl_list = {slh_first = 0x0}, kl_lock = 0xc05d7f30 , kl_unlock = 0xc05d7ee0 , kl_assert_locked = 0xc05d50b0 , kl_assert_unlocked = 0xc05d50c0 , kl_lockarg = 0xc5ba7c50}, si_mtx = 0x0}, sb_mtx = {lock_object = {lo_name = 0xc0902cd1 "so_snd", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 3311335616}, sb_sx = {lock_object = {lo_name = 0xc09031f9 "so_snd_sx", lo_flags = 36896768, lo_data = 0, lo_witness = 0x0}, sx_lock = 3311335616}, sb_state = 0, sb_mb = 0xc5471300, sb_mbtail = 0xc5471300, sb_lastrecord = 0xc5471300, sb_sndptr = 0xc5471300, sb_sndptroff = 160, sb_cc = 224, sb_hiwat = 33304, sb_mbcnt = 256, sb_mcnt = 1, sb_ccnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 2048, sb_timeo = 0, sb_flags = 2048, sb_upcall = 0, sb_upcallarg = 0x0}, so_cred = 0xc574a300, so_label = 0x0, so_peerlabel = 0x0, so_gencnt = 672, so_emuldata = 0x0, so_accf = 0x0, so_fibnum = 0} print *tp $4 = {t_segq = {lh_first = 0x0}, t_pspare = {0x0, 0x0}, t_segqlen = 0, t_dupacks = 0, t_timers = 0xc5ab21d8, t_inpcb = 0xc5ab1000, t_state = 4, t_flags = 996, t_vnet = 0x0, snd_una = 345532936, snd_max = 345533000, snd_nxt = 345533000, snd_up = 345532936, snd_wl1 = 833432065, snd_wl2 = 345532936, iss = 345516135, irs = 833424923, rcv_nxt = 833432113, rcv_adv = 833498721, rcv_wnd = 66608, rcv_up = 833432113, snd_wnd = 524280, snd_cwnd = 6472, snd_bwnd = 1073725440, snd_ssthresh = 1073725440, snd_bandwidth = 0, snd_recover = 345532936, t_maxopd = 1460, t_rcvtime = 161476, t_starttime = 45672, t_rtttime = 161476, t_rtseq = 345532936, t_bw_rtttime = 45672, t_bw_rtseq = 0, t_rxtcur = 230, t_maxseg = 1448, t_srtt = 48, t_rttvar = 9, t_rxtshift = 0, t_rttmin = 30, t_rttbest = 53, t_rttupdated = 169, max_sndwnd = 524280, t_softerror = 0, t_oobflags = 0 '\0', t_iobc = 0 '\0', snd_scale = 3 '\003', rcv_scale = 3 '\003', request_r_scale = 3 '\003', ts_recent = 467713397, ts_recent_age = 161476, ts_offset = 2129190315, last_ack_sent = 833432113, snd_cwnd_prev = 0, snd_ssthresh_prev = 0, snd_recover_prev = 0, t_badrxtwin = 0, snd_limited = 0 '\0', snd_numholes = 0, snd_holes = {tqh_first = 0x0, tqh_last = 0xc5ab20e4}, snd_fack = 0, rcv_numsacks = 0, sackblks = {{start = 0, end = 0}, {start = 0, end = 0}, {start = 0, end = 0}, {start = 0, end = 0}, {start = 0, end = 0}, {start = 0, end = 0}}, sack_newdata = 0, sackhint = {nexthole = 0x0, sack_bytes_rexmit = 0, ispare = 0, _pad = {0, 0}}, t_rttlow = 1, rfbuf_ts = 161476, rfbuf_cnt = 48, t_tu = 0x0, t_toe = 0x0, t_bytes_acked = 0, t_ispare = 0, t_pspare2 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, _pad = {0 }} frame 5: print *so: $5 = {so_count = 1, so_type = 1, so_options = 12, so_linger = 0, so_state = 258, so_qstate = 0, so_pcb = 0xc5ab1000, so_vnet = 0x0, so_proto = 0xc0956a48, so_head = 0x0, so_incomp = {tqh_first = 0x0, tqh_last = 0x0}, so_comp = {tqh_first = 0x0, tqh_last = 0x0}, so_list = {tqe_next = 0x0, tqe_prev = 0xc5779d08}, so_qlen = 0, so_incqlen = 0, so_qlimit = 0, so_timeo = 0, so_error = 0, so_sigio = 0x0, so_oobmark = 0, so_aiojobq = {tqh_first = 0x0, tqh_last = 0xc5ba7b90}, so_rcv = {sb_sel = {si_tdlist = {tqh_first = 0x0, tqh_last = 0xc5ba7b98}, si_note = {kl_list = {slh_first = 0x0}, kl_lock = 0xc05d7f30 , kl_unlock = 0xc05d7ee0 , kl_assert_locked = 0xc05d50b0 , kl_assert_unlocked = 0xc05d50c0 , kl_lockarg = 0xc5ba7bbc}, si_mtx = 0xc55103f8}, sb_mtx = {lock_object = {lo_name = 0xc0902cca "so_rcv", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, sb_sx = {lock_object = {lo_name = 0xc0903203 "so_rcv_sx", lo_flags = 36896768, lo_data = 0, lo_witness = 0x0}, sx_lock = 1}, sb_state = 0, sb_mb = 0x0, sb_mbtail = 0x0, sb_lastrecord = 0x0, sb_sndptr = 0x0, sb_sndptroff = 0, sb_cc = 0, sb_hiwat = 66608, sb_mbcnt = 0, sb_mcnt = 0, sb_ccnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 1, sb_timeo = 0, sb_flags = 2056, sb_upcall = 0, sb_upcallarg = 0x0}, so_snd = {sb_sel = {si_tdlist = {tqh_first = 0x0, tqh_last = 0x0}, si_note = {kl_list = {slh_first = 0x0}, kl_lock = 0xc05d7f30 , kl_unlock = 0xc05d7ee0 , kl_assert_locked = 0xc05d50b0 , kl_assert_unlocked = 0xc05d50c0 , kl_lockarg = 0xc5ba7c50}, si_mtx = 0x0}, sb_mtx = {lock_object = {lo_name = 0xc0902cd1 "so_snd", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 3311335616}, sb_sx = {lock_object = {lo_name = 0xc09031f9 "so_snd_sx", lo_flags = 36896768, lo_data = 0, lo_witness = 0x0}, sx_lock = 3311335616}, sb_state = 0, sb_mb = 0xc5471300, sb_mbtail = 0xc5471300, sb_lastrecord = 0xc5471300, sb_sndptr = 0xc5471300, sb_sndptroff = 160, sb_cc = 224, sb_hiwat = 33304, sb_mbcnt = 256, sb_mcnt = 1, sb_ccnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 2048, sb_timeo = 0, sb_flags = 2048, sb_upcall = 0, sb_upcallarg = 0x0}, so_cred = 0xc574a300, so_label = 0x0, so_peerlabel = 0x0, so_gencnt = 672, so_emuldata = 0x0, so_accf = 0x0, so_fibnum = 0} print *inp: $6 = {inp_hash = {le_next = 0x0, le_prev = 0xc5304294}, inp_list = {le_next = 0xc5a487bc, le_prev = 0xc09a9a04}, inp_ppcb = 0xc5ab2000, inp_pcbinfo = 0xc09a9a20, inp_socket = 0xc5ba7b44, inp_cred = 0xc574a300, inp_flow = 0, inp_flags = 8396800, inp_flags2 = 0, inp_vflag = 1 '\001', inp_ip_ttl = 64 '@', inp_ip_p = 0 '\0', inp_ip_minttl = 0 '\0', inp_flowid = 0, inp_refcount = 1, inp_pspare = {0x0, 0x0, 0x0, 0x0}, inp_ispare = {0, 0, 0, 0}, inp_inc = {inc_flags = 0 '\0', inc_len = 0 '\0', inc_fibnum = 0, inc_ie = {ie_fport = 11973, ie_lport = 5632, ie_dependfaddr = {ie46_foreign = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 2715641408}}, ie6_foreign = {__u6_addr = {__u6_addr8 = '\0' , "@f?", __u6_addr16 = {0, 0, 0, 0, 0, 0, 26176, 41437}, __u6_addr32 = {0, 0, 0, 2715641408}}}}, ie_dependladdr = {ie46_local = {ia46_pad32 = {0, 0, 0}, ia46_addr4 = {s_addr = 3976073900}}, ie6_local = {__u6_addr = {__u6_addr8 = '\0' , "?\022??", __u6_addr16 = {0, 0, 0, 0, 0, 0, 4780, 60670}, __u6_addr32 = {0, 0, 0, 3976073900}}}}}}, inp_label = 0x0, inp_sp = 0x0, inp_depend4 = {inp4_ip_tos = 16 '\020', inp4_options = 0x0, inp4_moptions = 0x0}, inp_depend6 = {inp6_options = 0x0, inp6_outputopts = 0x0, inp6_moptions = 0x0, inp6_icmp6filt = 0x0, inp6_cksum = 0, inp6_hops = 0}, inp_portlist = {le_next = 0xc5a487bc, le_prev = 0xc54f8428}, inp_phd = 0xc54f8420, inp_gencnt = 21, inp_lle = 0x0, inp_rt = 0x0, inp_lock = {lock_object = {lo_name = 0xc090c024 "tcpinp", lo_flags = 74121216, lo_data = 0, lo_witness = 0x0}, rw_lock = 3311335616}} print *tp: $7 = {t_segq = {lh_first = 0x0}, t_pspare = {0x0, 0x0}, t_segqlen = 0, t_dupacks = 0, t_timers = 0xc5ab21d8, t_inpcb = 0xc5ab1000, t_state = 4, t_flags = 996, t_vnet = 0x0, snd_una = 345532936, snd_max = 345533000, snd_nxt = 345533000, snd_up = 345532936, snd_wl1 = 833432065, snd_wl2 = 345532936, iss = 345516135, irs = 833424923, rcv_nxt = 833432113, rcv_adv = 833498721, rcv_wnd = 66608, rcv_up = 833432113, snd_wnd = 524280, snd_cwnd = 6472, snd_bwnd = 1073725440, snd_ssthresh = 1073725440, snd_bandwidth = 0, snd_recover = 345532936, t_maxopd = 1460, t_rcvtime = 161476, t_starttime = 45672, t_rtttime = 161476, t_rtseq = 345532936, t_bw_rtttime = 45672, t_bw_rtseq = 0, t_rxtcur = 230, t_maxseg = 1448, t_srtt = 48, t_rttvar = 9, t_rxtshift = 0, t_rttmin = 30, t_rttbest = 53, t_rttupdated = 169, max_sndwnd = 524280, t_softerror = 0, t_oobflags = 0 '\0', t_iobc = 0 '\0', snd_scale = 3 '\003', rcv_scale = 3 '\003', request_r_scale = 3 '\003', ts_recent = 467713397, ts_recent_age = 161476, ts_offset = 2129190315, last_ack_sent = 833432113, snd_cwnd_prev = 0, snd_ssthresh_prev = 0, snd_recover_prev = 0, t_badrxtwin = 0, snd_limited = 0 '\0', snd_numholes = 0, snd_holes = {tqh_first = 0x0, tqh_last = 0xc5ab20e4}, snd_fack = 0, rcv_numsacks = 0, sackblks = {{start = 0, end = 0}, {start = 0, end = 0}, {start = 0, end = 0}, {start = 0, end = 0}, {start = 0, end = 0}, {start = 0, end = 0}}, sack_newdata = 0, sackhint = {nexthole = 0x0, sack_bytes_rexmit = 0, ispare = 0, _pad = {0, 0}}, t_rttlow = 1, rfbuf_ts = 161476, rfbuf_cnt = 48, t_tu = 0x0, t_toe = 0x0, t_bytes_acked = 0, t_ispare = 0, t_pspare2 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, _pad = {0 }} frame 6: print *so: $8 = {so_count = 1, so_type = 1, so_options = 12, so_linger = 0, so_state = 258, so_qstate = 0, so_pcb = 0xc5ab1000, so_vnet = 0x0, so_proto = 0xc0956a48, so_head = 0x0, so_incomp = {tqh_first = 0x0, tqh_last = 0x0}, so_comp = {tqh_first = 0x0, tqh_last = 0x0}, so_list = {tqe_next = 0x0, tqe_prev = 0xc5779d08}, so_qlen = 0, so_incqlen = 0, so_qlimit = 0, so_timeo = 0, so_error = 0, so_sigio = 0x0, so_oobmark = 0, so_aiojobq = {tqh_first = 0x0, tqh_last = 0xc5ba7b90}, so_rcv = {sb_sel = {si_tdlist = {tqh_first = 0x0, tqh_last = 0xc5ba7b98}, si_note = {kl_list = {slh_first = 0x0}, kl_lock = 0xc05d7f30 , kl_unlock = 0xc05d7ee0 , kl_assert_locked = 0xc05d50b0 , kl_assert_unlocked = 0xc05d50c0 , kl_lockarg = 0xc5ba7bbc}, si_mtx = 0xc55103f8}, sb_mtx = {lock_object = {lo_name = 0xc0902cca "so_rcv", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, sb_sx = {lock_object = {lo_name = 0xc0903203 "so_rcv_sx", lo_flags = 36896768, lo_data = 0, lo_witness = 0x0}, sx_lock = 1}, sb_state = 0, sb_mb = 0x0, sb_mbtail = 0x0, sb_lastrecord = 0x0, sb_sndptr = 0x0, sb_sndptroff = 0, sb_cc = 0, sb_hiwat = 66608, sb_mbcnt = 0, sb_mcnt = 0, sb_ccnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 1, sb_timeo = 0, sb_flags = 2056, sb_upcall = 0, sb_upcallarg = 0x0}, so_snd = {sb_sel = {si_tdlist = {tqh_first = 0x0, tqh_last = 0x0}, si_note = {kl_list = {slh_first = 0x0}, kl_lock = 0xc05d7f30 , kl_unlock = 0xc05d7ee0 , kl_assert_locked = 0xc05d50b0 , kl_assert_unlocked = 0xc05d50c0 , kl_lockarg = 0xc5ba7c50}, si_mtx = 0x0}, sb_mtx = {lock_object = {lo_name = 0xc0902cd1 "so_snd", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 3311335616}, sb_sx = {lock_object = {lo_name = 0xc09031f9 "so_snd_sx", lo_flags = 36896768, lo_data = 0, lo_witness = 0x0}, sx_lock = 3311335616}, sb_state = 0, sb_mb = 0xc5471300, sb_mbtail = 0xc5471300, sb_lastrecord = 0xc5471300, sb_sndptr = 0xc5471300, sb_sndptroff = 160, sb_cc = 224, sb_hiwat = 33304, sb_mbcnt = 256, sb_mcnt = 1, sb_ccnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 2048, sb_timeo = 0, sb_flags = 2048, sb_upcall = 0, sb_upcallarg = 0x0}, so_cred = 0xc574a300, so_label = 0x0, so_peerlabel = 0x0, so_gencnt = 672, so_emuldata = 0x0, so_accf = 0x0, so_fibnum = 0} frame 7: print *so: $9 = {so_count = 1, so_type = 1, so_options = 12, so_linger = 0, so_state = 258, so_qstate = 0, so_pcb = 0xc5ab1000, so_vnet = 0x0, so_proto = 0xc0956a48, so_head = 0x0, so_incomp = {tqh_first = 0x0, tqh_last = 0x0}, so_comp = {tqh_first = 0x0, tqh_last = 0x0}, so_list = {tqe_next = 0x0, tqe_prev = 0xc5779d08}, so_qlen = 0, so_incqlen = 0, so_qlimit = 0, so_timeo = 0, so_error = 0, so_sigio = 0x0, so_oobmark = 0, so_aiojobq = {tqh_first = 0x0, tqh_last = 0xc5ba7b90}, so_rcv = {sb_sel = {si_tdlist = {tqh_first = 0x0, tqh_last = 0xc5ba7b98}, si_note = {kl_list = {slh_first = 0x0}, kl_lock = 0xc05d7f30 , kl_unlock = 0xc05d7ee0 , kl_assert_locked = 0xc05d50b0 , kl_assert_unlocked = 0xc05d50c0 , kl_lockarg = 0xc5ba7bbc}, si_mtx = 0xc55103f8}, sb_mtx = {lock_object = {lo_name = 0xc0902cca "so_rcv", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, sb_sx = {lock_object = {lo_name = 0xc0903203 "so_rcv_sx", lo_flags = 36896768, lo_data = 0, lo_witness = 0x0}, sx_lock = 1}, sb_state = 0, sb_mb = 0x0, sb_mbtail = 0x0, sb_lastrecord = 0x0, sb_sndptr = 0x0, sb_sndptroff = 0, sb_cc = 0, sb_hiwat = 66608, sb_mbcnt = 0, sb_mcnt = 0, sb_ccnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 1, sb_timeo = 0, sb_flags = 2056, sb_upcall = 0, sb_upcallarg = 0x0}, so_snd = {sb_sel = {si_tdlist = {tqh_first = 0x0, tqh_last = 0x0}, si_note = {kl_list = {slh_first = 0x0}, kl_lock = 0xc05d7f30 , kl_unlock = 0xc05d7ee0 , kl_assert_locked = 0xc05d50b0 , kl_assert_unlocked = 0xc05d50c0 , kl_lockarg = 0xc5ba7c50}, si_mtx = 0x0}, sb_mtx = {lock_object = {lo_name = 0xc0902cd1 "so_snd", lo_flags = 16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 3311335616}, sb_sx = {lock_object = {lo_name = 0xc09031f9 "so_snd_sx", lo_flags = 36896768, lo_data = 0, lo_witness = 0x0}, sx_lock = 3311335616}, sb_state = 0, sb_mb = 0xc5471300, sb_mbtail = 0xc5471300, sb_lastrecord = 0xc5471300, sb_sndptr = 0xc5471300, sb_sndptroff = 160, sb_cc = 224, sb_hiwat = 33304, sb_mbcnt = 256, sb_mcnt = 1, sb_ccnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 2048, sb_timeo = 0, sb_flags = 2048, sb_upcall = 0, sb_upcallarg = 0x0}, so_cred = 0xc574a300, so_label = 0x0, so_peerlabel = 0x0, so_gencnt = 672, so_emuldata = 0x0, so_accf = 0x0, so_fibnum = 0} Joe > > Robert > -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091012/0b6e3238/attachment-0001.pgp From tinderbox at freebsd.org Mon Oct 12 23:44:47 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 12 23:45:04 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> TB --- 2009-10-12 23:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 23:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-10-12 23:30:00 - cleaning the object tree TB --- 2009-10-12 23:30:11 - cvsupping the source tree TB --- 2009-10-12 23:30:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2009-10-12 23:30:42 - building world TB --- 2009-10-12 23:30:42 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 23:30:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 23:30:42 - TARGET=arm TB --- 2009-10-12 23:30:42 - TARGET_ARCH=arm TB --- 2009-10-12 23:30:42 - TZ=UTC TB --- 2009-10-12 23:30:42 - __MAKE_CONF=/dev/null TB --- 2009-10-12 23:30:42 - cd /src TB --- 2009-10-12 23:30:42 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 23:30:42 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/arm/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-12 23:44:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-12 23:44:45 - ERROR: failed to build world TB --- 2009-10-12 23:44:45 - 645.96 user 159.28 system 885.73 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From tinderbox at freebsd.org Mon Oct 12 23:46:57 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 12 23:47:15 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <200910122346.n9CNkui1072625@freebsd-current.sentex.ca> TB --- 2009-10-12 23:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 23:30:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-10-12 23:30:00 - cleaning the object tree TB --- 2009-10-12 23:30:19 - cvsupping the source tree TB --- 2009-10-12 23:30:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-10-12 23:30:47 - building world TB --- 2009-10-12 23:30:47 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 23:30:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 23:30:47 - TARGET=pc98 TB --- 2009-10-12 23:30:47 - TARGET_ARCH=i386 TB --- 2009-10-12 23:30:47 - TZ=UTC TB --- 2009-10-12 23:30:47 - __MAKE_CONF=/dev/null TB --- 2009-10-12 23:30:47 - cd /src TB --- 2009-10-12 23:30:47 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 23:30:48 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/pc98/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-12 23:46:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-12 23:46:56 - ERROR: failed to build world TB --- 2009-10-12 23:46:56 - 740.84 user 166.48 system 1016.52 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From tinderbox at freebsd.org Mon Oct 12 23:52:34 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 12 23:52:41 2009 Subject: [head tinderbox] failure on i386/i386 Message-ID: <200910122352.n9CNqXDO014823@freebsd-current.sentex.ca> TB --- 2009-10-12 23:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 23:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2009-10-12 23:30:00 - cleaning the object tree TB --- 2009-10-12 23:30:22 - cvsupping the source tree TB --- 2009-10-12 23:30:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2009-10-12 23:36:00 - building world TB --- 2009-10-12 23:36:00 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 23:36:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 23:36:00 - TARGET=i386 TB --- 2009-10-12 23:36:00 - TARGET_ARCH=i386 TB --- 2009-10-12 23:36:00 - TZ=UTC TB --- 2009-10-12 23:36:00 - __MAKE_CONF=/dev/null TB --- 2009-10-12 23:36:00 - cd /src TB --- 2009-10-12 23:36:00 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 23:36:01 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/i386/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-12 23:52:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-12 23:52:33 - ERROR: failed to build world TB --- 2009-10-12 23:52:33 - 746.54 user 167.70 system 1353.45 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From tinderbox at freebsd.org Mon Oct 12 23:53:26 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Oct 12 23:53:44 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <200910122353.n9CNrPiS021777@freebsd-current.sentex.ca> TB --- 2009-10-12 23:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 23:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-10-12 23:30:00 - cleaning the object tree TB --- 2009-10-12 23:30:24 - cvsupping the source tree TB --- 2009-10-12 23:30:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-10-12 23:36:00 - building world TB --- 2009-10-12 23:36:00 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 23:36:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 23:36:00 - TARGET=amd64 TB --- 2009-10-12 23:36:00 - TARGET_ARCH=amd64 TB --- 2009-10-12 23:36:00 - TZ=UTC TB --- 2009-10-12 23:36:00 - __MAKE_CONF=/dev/null TB --- 2009-10-12 23:36:00 - cd /src TB --- 2009-10-12 23:36:00 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 23:36:01 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-12 23:53:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-12 23:53:25 - ERROR: failed to build world TB --- 2009-10-12 23:53:25 - 782.88 user 178.35 system 1405.22 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Tue Oct 13 00:02:38 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 13 00:02:50 2009 Subject: [head tinderbox] failure on mips/mips Message-ID: <200910130002.n9D02beC015527@freebsd-current.sentex.ca> TB --- 2009-10-12 23:46:57 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 23:46:57 - starting HEAD tinderbox run for mips/mips TB --- 2009-10-12 23:46:57 - cleaning the object tree TB --- 2009-10-12 23:47:00 - cvsupping the source tree TB --- 2009-10-12 23:47:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2009-10-12 23:47:23 - building world TB --- 2009-10-12 23:47:23 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 23:47:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 23:47:23 - TARGET=mips TB --- 2009-10-12 23:47:23 - TARGET_ARCH=mips TB --- 2009-10-12 23:47:23 - TZ=UTC TB --- 2009-10-12 23:47:23 - __MAKE_CONF=/dev/null TB --- 2009-10-12 23:47:23 - cd /src TB --- 2009-10-12 23:47:23 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 23:47:23 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/mips/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-13 00:02:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-13 00:02:37 - ERROR: failed to build world TB --- 2009-10-13 00:02:37 - 663.36 user 153.65 system 940.77 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From tinderbox at freebsd.org Tue Oct 13 00:02:42 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 13 00:03:02 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <200910130002.n9D02fVh015854@freebsd-current.sentex.ca> TB --- 2009-10-12 23:44:46 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 23:44:46 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-10-12 23:44:46 - cleaning the object tree TB --- 2009-10-12 23:44:49 - cvsupping the source tree TB --- 2009-10-12 23:44:49 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-10-12 23:45:14 - building world TB --- 2009-10-12 23:45:14 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 23:45:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 23:45:14 - TARGET=ia64 TB --- 2009-10-12 23:45:14 - TARGET_ARCH=ia64 TB --- 2009-10-12 23:45:14 - TZ=UTC TB --- 2009-10-12 23:45:14 - __MAKE_CONF=/dev/null TB --- 2009-10-12 23:45:14 - cd /src TB --- 2009-10-12 23:45:14 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 23:45:14 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/ia64/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-13 00:02:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-13 00:02:41 - ERROR: failed to build world TB --- 2009-10-13 00:02:41 - 814.25 user 157.41 system 1075.65 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From tinderbox at freebsd.org Tue Oct 13 00:08:43 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 13 00:08:55 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <200910130008.n9D08gsb061099@freebsd-current.sentex.ca> TB --- 2009-10-12 23:53:25 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 23:53:25 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-10-12 23:53:25 - cleaning the object tree TB --- 2009-10-12 23:53:29 - cvsupping the source tree TB --- 2009-10-12 23:53:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-10-12 23:53:52 - building world TB --- 2009-10-12 23:53:52 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 23:53:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 23:53:52 - TARGET=sparc64 TB --- 2009-10-12 23:53:52 - TARGET_ARCH=sparc64 TB --- 2009-10-12 23:53:52 - TZ=UTC TB --- 2009-10-12 23:53:52 - __MAKE_CONF=/dev/null TB --- 2009-10-12 23:53:52 - cd /src TB --- 2009-10-12 23:53:52 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 23:53:53 UTC 2009 >>> 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 [...] cc -fPIC -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fPIC -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/sparc64/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-13 00:08:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-13 00:08:42 - ERROR: failed to build world TB --- 2009-10-13 00:08:42 - 679.28 user 154.27 system 916.70 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Tue Oct 13 00:08:53 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 13 00:09:23 2009 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <200910130008.n9D08pC8061367@freebsd-current.sentex.ca> TB --- 2009-10-12 23:52:33 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-12 23:52:33 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-10-12 23:52:33 - cleaning the object tree TB --- 2009-10-12 23:52:37 - cvsupping the source tree TB --- 2009-10-12 23:52:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-10-12 23:52:59 - building world TB --- 2009-10-12 23:52:59 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-12 23:52:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-12 23:52:59 - TARGET=powerpc TB --- 2009-10-12 23:52:59 - TARGET_ARCH=powerpc TB --- 2009-10-12 23:52:59 - TZ=UTC TB --- 2009-10-12 23:52:59 - __MAKE_CONF=/dev/null TB --- 2009-10-12 23:52:59 - cd /src TB --- 2009-10-12 23:52:59 - /usr/bin/make -B buildworld >>> World build started on Mon Oct 12 23:53:00 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/powerpc/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-13 00:08:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-13 00:08:51 - ERROR: failed to build world TB --- 2009-10-13 00:08:51 - 744.22 user 158.32 system 977.60 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From tinderbox at freebsd.org Tue Oct 13 00:16:56 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 13 00:17:05 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <200910130016.n9D0Gtk6085236@freebsd-current.sentex.ca> TB --- 2009-10-13 00:02:38 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-13 00:02:38 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-10-13 00:02:38 - cleaning the object tree TB --- 2009-10-13 00:02:41 - cvsupping the source tree TB --- 2009-10-13 00:02:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-10-13 00:03:05 - building world TB --- 2009-10-13 00:03:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-13 00:03:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-13 00:03:05 - TARGET=sun4v TB --- 2009-10-13 00:03:05 - TARGET_ARCH=sparc64 TB --- 2009-10-13 00:03:05 - TZ=UTC TB --- 2009-10-13 00:03:05 - __MAKE_CONF=/dev/null TB --- 2009-10-13 00:03:05 - cd /src TB --- 2009-10-13 00:03:05 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 13 00:03:06 UTC 2009 >>> 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 [...] cc -fPIC -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fPIC -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/sun4v/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-13 00:16:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-13 00:16:55 - ERROR: failed to build world TB --- 2009-10-13 00:16:55 - 682.57 user 145.23 system 857.38 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From quickembed at gmail.com Tue Oct 13 00:43:04 2009 From: quickembed at gmail.com (quickembed) Date: Tue Oct 13 01:15:04 2009 Subject: [head tinderbox] failure on arm/arm In-Reply-To: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> Message-ID: this error shows you have not indicate how to compile libgssapi.a file. CC is for .c file, you need to tell what's for .a (assembly) file. On Tue, Oct 13, 2009 at 7:44 AM, FreeBSD Tinderbox wrote: > TB --- 2009-10-12 23:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca > TB --- 2009-10-12 23:30:00 - starting HEAD tinderbox run for arm/arm > TB --- 2009-10-12 23:30:00 - cleaning the object tree > TB --- 2009-10-12 23:30:11 - cvsupping the source tree > TB --- 2009-10-12 23:30:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile > TB --- 2009-10-12 23:30:42 - building world > TB --- 2009-10-12 23:30:42 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-10-12 23:30:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-10-12 23:30:42 - TARGET=arm > TB --- 2009-10-12 23:30:42 - TARGET_ARCH=arm > TB --- 2009-10-12 23:30:42 - TZ=UTC > TB --- 2009-10-12 23:30:42 - __MAKE_CONF=/dev/null > TB --- 2009-10-12 23:30:42 - cd /src > TB --- 2009-10-12 23:30:42 - /usr/bin/make -B buildworld >>>> World build started on Mon Oct 12 23:30:42 UTC 2009 >>>> 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 > [...] > cc -fpic -DPIC -O -pipe ?-I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 ?-c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So > cc -fpic -DPIC -O -pipe ?-I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 ?-c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' > make: don't know how to make /obj/arm/src/tmp/usr/lib/libgssapi.a. Stop > *** Error code 2 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2009-10-12 23:44:45 - WARNING: /usr/bin/make returned exit code ?1 > TB --- 2009-10-12 23:44:45 - ERROR: failed to build world > TB --- 2009-10-12 23:44:45 - 645.96 user 159.28 system 885.73 real > > > http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From bland at bbnest.net Tue Oct 13 00:45:27 2009 From: bland at bbnest.net (Alexander Nedotsukov) Date: Tue Oct 13 01:15:18 2009 Subject: [head tinderbox] failure on i386/i386 In-Reply-To: <200910122352.n9CNqXDO014823@freebsd-current.sentex.ca> References: <200910122352.n9CNqXDO014823@freebsd-current.sentex.ca> Message-ID: <8208113B-5BD3-4606-B6D3-6C19931B0E23@bbnest.net> This will fix it: Index: libgssapi_krb5/gss_krb5.c =================================================================== --- libgssapi_krb5/gss_krb5.c (revision 198008) +++ libgssapi_krb5/gss_krb5.c (working copy) @@ -31,6 +31,7 @@ /* RCSID("$Id: gss_krb5.c 21889 2007-08-09 07:43:24Z lha $"); */ +#include #include #include However I can't see yet how my commit triggered the problem. Sorry for the breakage. On 13.10.2009, at 8:52, FreeBSD Tinderbox wrote: > TB --- 2009-10-12 23:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca > TB --- 2009-10-12 23:30:00 - starting HEAD tinderbox run for i386/i386 > TB --- 2009-10-12 23:30:00 - cleaning the object tree > TB --- 2009-10-12 23:30:22 - cvsupping the source tree > TB --- 2009-10-12 23:30:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca > /tinderbox/HEAD/i386/i386/supfile > TB --- 2009-10-12 23:36:00 - building world > TB --- 2009-10-12 23:36:00 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-10-12 23:36:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-10-12 23:36:00 - TARGET=i386 > TB --- 2009-10-12 23:36:00 - TARGET_ARCH=i386 > TB --- 2009-10-12 23:36:00 - TZ=UTC > TB --- 2009-10-12 23:36:00 - __MAKE_CONF=/dev/null > TB --- 2009-10-12 23:36:00 - cd /src > TB --- 2009-10-12 23:36:00 - /usr/bin/make -B buildworld >>>> World build started on Mon Oct 12 23:36:01 UTC 2009 >>>> 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 > [...] > cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/ > libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/ > lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/ > kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/ > kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/ > kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. - > DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include - > std=gnu99 -fstack-protector -c /src/kerberos5/lib/ > libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o > wrap.So > cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/ > libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/ > lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/ > kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/ > kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/ > kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. - > DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include - > std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/ > gss_krb5.c -o gss_krb5.So > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function > 'gsskrb5_extract_authz_data_from_sec_context': > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit > declaration of function 'der_get_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit > declaration of function 'der_free_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit > declaration of function 'der_length_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit > declaration of function 'der_put_oid' > make: don't know how to make /obj/i386/src/tmp/usr/lib/libgssapi.a. > Stop > *** Error code 2 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2009-10-12 23:52:33 - WARNING: /usr/bin/make returned exit > code 1 > TB --- 2009-10-12 23:52:33 - ERROR: failed to build world > TB --- 2009-10-12 23:52:33 - 746.54 user 167.70 system 1353.45 real > > > http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " From tinderbox at freebsd.org Tue Oct 13 04:09:39 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 13 04:09:51 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <200910130409.n9D49c48060977@freebsd-current.sentex.ca> TB --- 2009-10-13 03:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-13 03:55:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-10-13 03:55:00 - cleaning the object tree TB --- 2009-10-13 03:55:05 - cvsupping the source tree TB --- 2009-10-13 03:55:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2009-10-13 03:55:29 - building world TB --- 2009-10-13 03:55:29 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-13 03:55:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-13 03:55:29 - TARGET=arm TB --- 2009-10-13 03:55:29 - TARGET_ARCH=arm TB --- 2009-10-13 03:55:29 - TZ=UTC TB --- 2009-10-13 03:55:29 - __MAKE_CONF=/dev/null TB --- 2009-10-13 03:55:29 - cd /src TB --- 2009-10-13 03:55:29 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 13 03:55:29 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/arm/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-13 04:09:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-13 04:09:38 - ERROR: failed to build world TB --- 2009-10-13 04:09:38 - 644.73 user 158.41 system 878.05 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From tinderbox at freebsd.org Tue Oct 13 04:11:35 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 13 04:11:45 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <200910130411.n9D4BYFV093839@freebsd-current.sentex.ca> TB --- 2009-10-13 03:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-13 03:55:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-10-13 03:55:00 - cleaning the object tree TB --- 2009-10-13 03:55:05 - cvsupping the source tree TB --- 2009-10-13 03:55:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-10-13 03:55:29 - building world TB --- 2009-10-13 03:55:29 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-13 03:55:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-13 03:55:29 - TARGET=pc98 TB --- 2009-10-13 03:55:29 - TARGET_ARCH=i386 TB --- 2009-10-13 03:55:29 - TZ=UTC TB --- 2009-10-13 03:55:29 - __MAKE_CONF=/dev/null TB --- 2009-10-13 03:55:29 - cd /src TB --- 2009-10-13 03:55:29 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 13 03:55:29 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/pc98/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-13 04:11:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-13 04:11:34 - ERROR: failed to build world TB --- 2009-10-13 04:11:34 - 741.07 user 159.47 system 994.31 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From tinderbox at freebsd.org Tue Oct 13 04:16:59 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 13 04:17:06 2009 Subject: [head tinderbox] failure on i386/i386 Message-ID: <200910130416.n9D4GwVd036048@freebsd-current.sentex.ca> TB --- 2009-10-13 03:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-13 03:55:00 - starting HEAD tinderbox run for i386/i386 TB --- 2009-10-13 03:55:00 - cleaning the object tree TB --- 2009-10-13 03:55:05 - cvsupping the source tree TB --- 2009-10-13 03:55:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2009-10-13 04:00:33 - building world TB --- 2009-10-13 04:00:33 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-13 04:00:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-13 04:00:33 - TARGET=i386 TB --- 2009-10-13 04:00:33 - TARGET_ARCH=i386 TB --- 2009-10-13 04:00:33 - TZ=UTC TB --- 2009-10-13 04:00:33 - __MAKE_CONF=/dev/null TB --- 2009-10-13 04:00:33 - cd /src TB --- 2009-10-13 04:00:33 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 13 04:00:34 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/i386/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-13 04:16:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-13 04:16:58 - ERROR: failed to build world TB --- 2009-10-13 04:16:58 - 746.29 user 158.54 system 1318.54 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From tinderbox at freebsd.org Tue Oct 13 04:18:00 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 13 04:18:17 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <200910130417.n9D4Hx6r040179@freebsd-current.sentex.ca> TB --- 2009-10-13 03:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-13 03:55:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-10-13 03:55:00 - cleaning the object tree TB --- 2009-10-13 03:55:05 - cvsupping the source tree TB --- 2009-10-13 03:55:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-10-13 04:00:33 - building world TB --- 2009-10-13 04:00:33 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-13 04:00:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-13 04:00:33 - TARGET=amd64 TB --- 2009-10-13 04:00:33 - TARGET_ARCH=amd64 TB --- 2009-10-13 04:00:33 - TZ=UTC TB --- 2009-10-13 04:00:33 - __MAKE_CONF=/dev/null TB --- 2009-10-13 04:00:33 - cd /src TB --- 2009-10-13 04:00:33 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 13 04:00:33 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-13 04:17:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-13 04:17:59 - ERROR: failed to build world TB --- 2009-10-13 04:17:59 - 783.20 user 167.37 system 1379.09 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From tinderbox at freebsd.org Tue Oct 13 04:27:21 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 13 04:27:28 2009 Subject: [head tinderbox] failure on mips/mips Message-ID: <200910130427.n9D4RKUj037271@freebsd-current.sentex.ca> TB --- 2009-10-13 04:11:34 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-13 04:11:34 - starting HEAD tinderbox run for mips/mips TB --- 2009-10-13 04:11:34 - cleaning the object tree TB --- 2009-10-13 04:11:37 - cvsupping the source tree TB --- 2009-10-13 04:11:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2009-10-13 04:12:04 - building world TB --- 2009-10-13 04:12:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-13 04:12:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-13 04:12:04 - TARGET=mips TB --- 2009-10-13 04:12:04 - TARGET_ARCH=mips TB --- 2009-10-13 04:12:04 - TZ=UTC TB --- 2009-10-13 04:12:04 - __MAKE_CONF=/dev/null TB --- 2009-10-13 04:12:04 - cd /src TB --- 2009-10-13 04:12:04 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 13 04:12:05 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/mips/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-13 04:27:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-13 04:27:19 - ERROR: failed to build world TB --- 2009-10-13 04:27:19 - 664.61 user 152.35 system 945.26 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From tinderbox at freebsd.org Tue Oct 13 04:27:38 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 13 04:27:50 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <200910130427.n9D4RbRG038774@freebsd-current.sentex.ca> TB --- 2009-10-13 04:09:38 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-13 04:09:38 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-10-13 04:09:38 - cleaning the object tree TB --- 2009-10-13 04:09:41 - cvsupping the source tree TB --- 2009-10-13 04:09:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-10-13 04:10:09 - building world TB --- 2009-10-13 04:10:09 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-13 04:10:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-13 04:10:09 - TARGET=ia64 TB --- 2009-10-13 04:10:09 - TARGET_ARCH=ia64 TB --- 2009-10-13 04:10:09 - TZ=UTC TB --- 2009-10-13 04:10:09 - __MAKE_CONF=/dev/null TB --- 2009-10-13 04:10:09 - cd /src TB --- 2009-10-13 04:10:09 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 13 04:10:10 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/ia64/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-13 04:27:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-13 04:27:37 - ERROR: failed to build world TB --- 2009-10-13 04:27:37 - 811.72 user 160.23 system 1078.49 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From tinderbox at freebsd.org Tue Oct 13 04:33:17 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 13 04:33:35 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <200910130433.n9D4XGiI082632@freebsd-current.sentex.ca> TB --- 2009-10-13 04:17:59 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-13 04:17:59 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-10-13 04:17:59 - cleaning the object tree TB --- 2009-10-13 04:18:02 - cvsupping the source tree TB --- 2009-10-13 04:18:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-10-13 04:18:27 - building world TB --- 2009-10-13 04:18:27 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-13 04:18:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-13 04:18:27 - TARGET=sparc64 TB --- 2009-10-13 04:18:27 - TARGET_ARCH=sparc64 TB --- 2009-10-13 04:18:27 - TZ=UTC TB --- 2009-10-13 04:18:27 - __MAKE_CONF=/dev/null TB --- 2009-10-13 04:18:27 - cd /src TB --- 2009-10-13 04:18:27 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 13 04:18:28 UTC 2009 >>> 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 [...] cc -fPIC -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fPIC -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/sparc64/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-13 04:33:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-13 04:33:16 - ERROR: failed to build world TB --- 2009-10-13 04:33:16 - 678.41 user 155.45 system 916.56 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From tinderbox at freebsd.org Tue Oct 13 04:33:27 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 13 04:33:45 2009 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <200910130433.n9D4XQ9V082891@freebsd-current.sentex.ca> TB --- 2009-10-13 04:16:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-13 04:16:58 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-10-13 04:16:58 - cleaning the object tree TB --- 2009-10-13 04:17:03 - cvsupping the source tree TB --- 2009-10-13 04:17:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-10-13 04:17:31 - building world TB --- 2009-10-13 04:17:31 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-13 04:17:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-13 04:17:31 - TARGET=powerpc TB --- 2009-10-13 04:17:31 - TARGET_ARCH=powerpc TB --- 2009-10-13 04:17:31 - TZ=UTC TB --- 2009-10-13 04:17:31 - __MAKE_CONF=/dev/null TB --- 2009-10-13 04:17:31 - cd /src TB --- 2009-10-13 04:17:31 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 13 04:17:32 UTC 2009 >>> 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 [...] cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fpic -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/powerpc/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-13 04:33:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-13 04:33:26 - ERROR: failed to build world TB --- 2009-10-13 04:33:26 - 747.34 user 154.41 system 987.07 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From tinderbox at freebsd.org Tue Oct 13 04:41:38 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Tue Oct 13 04:41:50 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <200910130441.n9D4fa8c006908@freebsd-current.sentex.ca> TB --- 2009-10-13 04:27:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-13 04:27:20 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-10-13 04:27:20 - cleaning the object tree TB --- 2009-10-13 04:27:23 - cvsupping the source tree TB --- 2009-10-13 04:27:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-10-13 04:27:50 - building world TB --- 2009-10-13 04:27:50 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-13 04:27:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-13 04:27:50 - TARGET=sun4v TB --- 2009-10-13 04:27:50 - TARGET_ARCH=sparc64 TB --- 2009-10-13 04:27:50 - TZ=UTC TB --- 2009-10-13 04:27:50 - __MAKE_CONF=/dev/null TB --- 2009-10-13 04:27:50 - cd /src TB --- 2009-10-13 04:27:50 - /usr/bin/make -B buildworld >>> World build started on Tue Oct 13 04:27:50 UTC 2009 >>> 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 [...] cc -fPIC -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5/wrap.c -o wrap.So cc -fPIC -DPIC -O2 -pipe -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/gssapi/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/krb5 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/lib/libgssapi_krb5/../../../crypto/heimdal/lib/roken -I. -DHAVE_CONFIG_H -I/src/kerberos5/lib/libgssapi_krb5/../../include -std=gnu99 -fstack-protector -c /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c -o gss_krb5.So /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' make: don't know how to make /obj/sun4v/src/tmp/usr/lib/libgssapi.a. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-13 04:41:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-13 04:41:36 - ERROR: failed to build world TB --- 2009-10-13 04:41:36 - 682.20 user 145.82 system 856.61 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From avg at icyb.net.ua Tue Oct 13 10:46:40 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Oct 13 10:46:48 2009 Subject: zfs boot vs loader In-Reply-To: <86ws30ikfw.fsf@gmail.com> References: <4AD3220B.5030502@icyb.net.ua> <86ws30ikfw.fsf@gmail.com> Message-ID: <4AD45A8D.4070605@icyb.net.ua> Thanks to all who replied! I think that I figured it out with your help. 'unload' does indeed unload zpool.cache and the latter is needed for proper zfs root mounting. 'boot /other/kernel' executes some loader scripts and zpool.cache gets loaded in this case (because of the settings in defaults/loader.conf). When doing manual 'load xxx' and then just 'boot' no loader scripts are executed and zpool.cache does not get loaded. In this case one has to load it manually using the suggested 'load -t xxx' approach. -- Andriy Gapon From rdivacky at freebsd.org Tue Oct 13 11:38:46 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Tue Oct 13 11:38:52 2009 Subject: unifdef crashes Message-ID: <20091013113813.GA2478@freebsd.org> just to not lost it: unifdef -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -DDT_CONFIG -D__GLIBC__=3 -DCRT_BEGIN -DOBJECT_FORMAT_ELF /usr/src/contrib/gcc/crtstuff.c this crashes our unifdef if someone wants to look at it, you're welcome roman From rdivacky at freebsd.org Tue Oct 13 13:50:43 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Tue Oct 13 13:50:49 2009 Subject: unifdef crashes In-Reply-To: <20091013113813.GA2478@freebsd.org> References: <20091013113813.GA2478@freebsd.org> Message-ID: <20091013135013.GA90731@freebsd.org> On Tue, Oct 13, 2009 at 01:38:13PM +0200, Roman Divacky wrote: > just to not lost it: > > unifdef -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -DDT_CONFIG -D__GLIBC__=3 -DCRT_BEGIN -DOBJECT_FORMAT_ELF > /usr/src/contrib/gcc/crtstuff.c > > this crashes our unifdef > > if someone wants to look at it, you're welcome this is already fixed in -current and 8.x by fanf@ sorry for the noise From minotaur at crete.org.ua Tue Oct 13 14:11:47 2009 From: minotaur at crete.org.ua (Alexander Shikoff) Date: Tue Oct 13 14:11:59 2009 Subject: 'ee' editor prints cyrillic characters on white background In-Reply-To: <20091012131901.6421666b@baby-jane.lamaiziere.net> References: <20091004090156.GA85409@crete.org.ua> <20091008123001.GA82997@nagual.pp.ru> <20091012131901.6421666b@baby-jane.lamaiziere.net> Message-ID: <20091013141144.GA54420@crete.org.ua> On Mon, Oct 12, 2009 at 01:19:01PM +0200, Patrick Lamaiziere wrote: > Le Thu, 8 Oct 2009 16:30:01 +0400, > Andrey Chernov a ?crit : > > > > I've upgraded my 7.2-RELEASE to 8.0-RC1. ee editor began to > > > highlight cyrillic characters (locale uk_UA.KOI8-U) with white > > > background and underscoring. Does anyone know how to disable this? > > > Thanks. > > > > Fixed in -current. > > It would be nice to have this fixed in 8.0 too :-) > Is it planned? It will be great if these changes be committed in 8-STABLE. But while they are only in -current you can easily edit sources by hands, look at http://svn.freebsd.org/viewvc/base/head/contrib/ee/ee.c?r1=196750&r2=196749&pathrev=196750 Just edit proper lines (with waddch) in your sources. I fixed it in my sources. Andrey, thanks a lot! -- MINO-RIPE From jkim at FreeBSD.org Tue Oct 13 15:33:33 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Tue Oct 13 15:33:40 2009 Subject: ACPI Warning: Converted Buffer to expected String In-Reply-To: <20091011142256.GA3770@roadrunner.spoerlein.net> References: <20091011142256.GA3770@roadrunner.spoerlein.net> Message-ID: <200910131133.16487.jkim@FreeBSD.org> On Sunday 11 October 2009 10:22 am, Ulrich Sp?rlein wrote: > Just FYI, > > Dell Inspiron 8600c laptop, semi-recent CURRENT, latest BIOS (A14), > machine is 5 years old and producing these warnings when inserting > a battery (or booting with one inserted) > > ACPI Warning for \\_SB_.BAT0._BIF: Converted Buffer to expected > String at index 9 (20090903/nsrepair-215) ACPI Warning for > \\_SB_.BAT0._BIF: Converted Buffer to expected String at index 10 > (20090903/nsrepair-215) ACPI Warning for \\_SB_.BAT0._BIF: > Converted Buffer to expected String at index 11 > (20090903/nsrepair-215) ACPI Warning for \\_SB_.BAT0._BIF: > Converted Buffer to expected String at index 12 > (20090903/nsrepair-215) These are just informational. FYI, new ACPICA checks predefined method/object types per spec. and tries to correct common DSDT errors. Previously these "quirks" were handled by OS layer case by case. The warning message is telling you that _BIF method (get battery information) returned Buffer object instead of String object and ACPICA corrected the errors. In fact, this is a very common mistake by laptop BIOS writers. Thus, it is automatically corrected by new ACPICA. However, if you see "ACPI Error", that's something to worry about, e.g., cannot convert predefined types. > Everything works just before the ACPI import, there's also another > bunch of (harmless) errors during boot. > > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: reservation of 0, 9fc00 (3) failed > acpi0: reservation of 100000, 3fef0000 (3) failed > > This is just for reference, perhaps someone wants to know. It is harmless. Jung-uk Kim From miwi at FreeBSD.org Tue Oct 13 15:38:19 2009 From: miwi at FreeBSD.org (Martin Wilke) Date: Tue Oct 13 15:38:26 2009 Subject: [kde-freebsd] 9-CURRENT (r197801) && artsd of kde-3.5.10_2 gives SIGSEGV In-Reply-To: <20091012130914.GA4180@current.Sisis.de> References: <20091011062419.GA2168@current.Sisis.de> <3a142e750910111214rb75f185k12b2cc7e1aba59d9@mail.gmail.com> <20091012130914.GA4180@current.Sisis.de> Message-ID: <20091013153815.GA88394@bsdcrew.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Oct 12, 2009 at 03:09:15PM +0200, Matthias Apitz wrote: > El d?a Sunday, October 11, 2009 a las 07:14:21PM +0000, Paul B Mahol escribi?: > > > Make sure that all libraries and binarys are rebuild, thare may be ABI > > changes and not > > support for older code .... > > Hi Paul, > > I've compiled all (kernel, user land and the ports) in a virtual machine > I'm using for preparing binary installation, i.e. after compiling the > ports I create packages to install them on machines where you either > can't compile for being to small/slow (like my EeePC 900) or to give a > binary set away for installation where machines have limited access to > Internet. > > I've build and installed kernel and user land based on SVN checkout: > > # svn info > Path: . > URL: svn://svn.freebsd.org/base/head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 197801 > Node Kind: directory > Schedule: normal > Last Changed Author: maxim > Last Changed Rev: 197799 > Last Changed Date: 2009-10-06 06:57:18 +0200 (Tue, 06 Oct 2009) > > # uname -a > FreeBSD vm-azul.Sisis.de 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r197801: Tue > Oct 6 13:57:38 CEST 2009 > guru@vm-azul.Sisis.de:/usr/obj/usr/src/sys/REBELION-HEAD i386 > > When kernel and user land have been on 9-CURRENT, I removed /usr/ports, > checked them out with CVS and build all my ports, especially KDE3. > > I don't see how an old library or binary can cause this. Only some ABI > change which is not supported in the KDE sources... > > Don't know if someone from FreeBSD's KDE team can (or will) comment on it. It > seems to me that they all went away (to KDE4 :-)). > > Thx unfortunately you're right, we're a small team, we spend all our energy to KDE4. Sorry but so is the life. - - Martin > > matthias > -- > Matthias Apitz > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.unixarea.de/ > Vote NO to EU The Lisbon Treaty: http://www.no-means-no.eu > _______________________________________________ > kde-freebsd mailing list > kde-freebsd@kde.org > https://mail.kde.org/mailman/listinfo/kde-freebsd > See also http://freebsd.kde.org/ for latest information > - -- +-----------------------+-------------------------------+ | PGP : 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkrUnucACgkQdLJIhLHm/Onz5ACg4bMNlKipfAGDsjm2saXg4W2i pfEAn2f+DbYaMq0WjxAZcc6L55Evi5Iq =L81j -----END PGP SIGNATURE----- From weongyo.jeong at gmail.com Tue Oct 13 17:41:31 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Tue Oct 13 17:41:37 2009 Subject: if_rum dies on transmit... In-Reply-To: <86051.1254232666@critter.freebsd.dk> References: <86051.1254232666@critter.freebsd.dk> Message-ID: <20091013174201.GC67082@weongyo> On Tue, Sep 29, 2009 at 01:57:46PM +0000, Poul-Henning Kamp wrote: > > Has anybody else seen if_rum die when you try to transmit a file over > a TCP connection ? > > If I try to print across the network, upload a file with ftp or anything > else of that general tenor, if_rum seems to hang the output queue and > stops transmitting packets. > > Restarting wpa_supplicant mostly resolves the issue, but it does not > on its own discover the problem. > > According to tcpdump(8), packets are still received. > > Any ideas ? Could you please test with attached patch? regards, Weongyo Jeong -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_rum_20091013.diff Type: text/x-diff Size: 883 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091013/f8f0ea86/patch_rum_20091013.bin From des at des.no Tue Oct 13 18:32:38 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Oct 13 18:32:45 2009 Subject: [head tinderbox] failure on arm/arm In-Reply-To: (quickembed@gmail.com's message of "Tue, 13 Oct 2009 08:19:06 +0800") References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> Message-ID: <86vdijdu0r.fsf@ds4.des.no> quickembed writes: > this error shows you have not indicate how to compile libgssapi.a file. > CC is for .c file, you need to tell what's for .a (assembly) file. No, the command line is correct. Assembler sources end in .s or .S; .a is a static library. DES -- Dag-Erling Sm?rgrav - des@des.no From alexbestms at math.uni-muenster.de Tue Oct 13 21:27:30 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Tue Oct 13 21:27:37 2009 Subject: Where to report LORs? (ffs and unionfs LORs included In-Reply-To: <4AD0ED9F.3080706@omnilan.de> Message-ID: Harald Schmalzbauer schrieb am 2009-10-10: > Alexander Best schrieb am 07.07.2009 21:33 (localtime): > >try http://sources.zabbadoz.net/freebsd/lor.html > I still see a unionfs LOR with RELENG_8 which is not listed, so I'd > like to report it again. > lock order reversal: > 1st 0xc372c488 unionfs (unionfs) @ > /FlashBSD/src/sys/fs/unionfs/union_subr.c:356 > 2nd 0xc372c594 ufs (ufs) @ /FlashBSD/src/sys/kern/vfs_subr.c:2188 > KDB: stack backtrace: > db_trace_self_wrapper(c0616390,c08cd5d5,c3416770,c3416500,d5c42864,.. > .) at db_trace_self_wrapper+0x26 > _witness_debugger(c08cd5d5,c372c594,c08c0703,c3416500,c08d4ec2,...) > at _witness_debugger+0x49 > witness_checkorder(c372c594,9,c08d4ec2,88c,0,...) at > witness_checkorder+0x6ec > __lockmgr_args(c372c594,80100,c372c5b0,0,0,...) at > __lockmgr_args+0xc97 > ffs_lock(d5c42958,8,c36c4764,80100,c372c53c,...) at ffs_lock+0x96 > VOP_LOCK1_APV(c09374a0,d5c42958,c05d89e9,c09477c0,c372c53c,...) at > VOP_LOCK1_APV+0x9a > _vn_lock(c372c53c,80100,c08d4ec2,88c,c0877c6e,...) at _vn_lock+0x46 > vrele(c372c53c,d5c429d8,c372c4a4,0,0,...) at vrele+0x12a > unionfs_noderem(c372c430,c36c46c0,d5c42a44,c06764fc,d5c42a20,...) at > unionfs_noderem+0x1e5 > unionfs_reclaim(d5c42a20,d5c42a20,0,0,c372c4a4,...) at > unionfs_reclaim+0x1b > vgonel(c372c4a4,0,c08d4ec2,9c5,c372c4a4,...) at vgonel+0x100 > vrecycle(c372c430,c36c46c0,d5c42aa4,c0675c29,d5c42a8c,...) at > vrecycle+0x6a > unionfs_inactive(d5c42a8c,d5c42a8c,c08d4ec2,924,c0947780,...) at > unionfs_inactive+0x28 > vinactive(c372c594,d5c42ac0,c08d4ec2,8aa,c3451de0,...) at > vinactive+0x6a > vput(c372c430,ffffffdf,c344ab80,0,c36c46c0,...) at vput+0x205 > kern_statat_vnhook(c36c46c0,0,ffffff9c,28209e1c,0,...) at > kern_statat_vnhook+0xe0 > kern_statat(c36c46c0,0,ffffff9c,28209e1c,0,...) at kern_statat+0x3c > kern_stat(c36c46c0,28209e1c,0,d5c42c18,c0a83a18,...) at > kern_stat+0x36 > stat(c36c46c0,d5c42cf8,8,d5c42d38,c0916cd0,...) at stat+0x2b > syscall(d5c42d38) at syscall+0x176 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (188, FreeBSD ELF32, stat), eip = 0x281c6c2b, esp = > 0xbfbfe96c, ebp = 0xbfbfea68 --- > So far I couldn't notice any deadlock, but the box is not in > production yet. > -Harry you might also want to write Bjoern Zeeb (http://wiki.freebsd.org/BjoernZeeb) with a link to your report. he's the guy maintaining the lor page. cheers. alex From john at baldwin.cx Tue Oct 13 21:18:35 2009 From: john at baldwin.cx (John Baldwin) Date: Tue Oct 13 21:47:21 2009 Subject: 8.0rc1 not recognizing partitions on EPIA SN In-Reply-To: <4ACE9DFD.3010207@gmail.com> References: <4ACE6D84.3000209@gmail.com> <4ACE833A.3030506@uffner.com> <4ACE9DFD.3010207@gmail.com> Message-ID: <200910131644.04358.john@baldwin.cx> On Thursday 08 October 2009 10:20:45 pm David Ehrmann wrote: > Tom Uffner wrote: > > David Ehrmann wrote: > >> First, I tried to upgrade the normal way. I built my own kernel and > >> installed it, but when I tried to boot it, I got a mountroot> > >> prompt. When I printed the devices, instead of seeing ad0s1a and > >> friends, I saw ad0a and ad0d (just those two for ad0). I was still > >> able to use the old (7.1) kernel fine. Thinking it was something to > >> do with the upgrade, I tried to do a reinstall. I chose the default > >> options, but once it got to the "last chance..." screen, this happened: > >> > >> Unable to find device node for /dev/ad0s1b in /dev! > >> The creation of filesystems will be aborted. > > > > this is becoming an FAQ for 8.0 > > > > the short answer is "dangerously dedicated" partitions are not supported > > by the 8.0 installer. back up your data. zero the MBR & partition table > > with dd, and re-slice & partition your disk. after the install, restore > > from your backups. > > > > search the freebsd-current archives for full details. > dd did the trick. > > I understand why this was done, but at the same time, upgrading is now > impractical for some users, and what looks like a fresh installation > (repartitioned, resliced) can even fail. Is there a change that could > be made to the partitioning process that would fix this? E-mail marcel@. -- John Baldwin From lstewart at freebsd.org Tue Oct 13 21:50:25 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Tue Oct 13 21:50:33 2009 Subject: ACPI Warning: Converted Buffer to expected String In-Reply-To: <200910131133.16487.jkim@FreeBSD.org> References: <20091011142256.GA3770@roadrunner.spoerlein.net> <200910131133.16487.jkim@FreeBSD.org> Message-ID: <4AD4F611.6080504@freebsd.org> Jung-uk Kim wrote: [snip] > by new ACPICA. However, if you see "ACPI Error", that's something to > worry about, e.g., cannot convert predefined types. > So I should be worried about this line from my Toshiba R600 laptop's dmesg? ACPI Error: Package List length (0xC) larger than NumElements count (0x4), truncated Cheers, Lawrence From jkim at FreeBSD.org Tue Oct 13 22:16:13 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Tue Oct 13 22:16:20 2009 Subject: ACPI Warning: Converted Buffer to expected String In-Reply-To: <4AD4F611.6080504@freebsd.org> References: <20091011142256.GA3770@roadrunner.spoerlein.net> <200910131133.16487.jkim@FreeBSD.org> <4AD4F611.6080504@freebsd.org> Message-ID: <200910131815.53053.jkim@FreeBSD.org> On Tuesday 13 October 2009 05:50 pm, Lawrence Stewart wrote: > Jung-uk Kim wrote: > > [snip] > > > by new ACPICA. However, if you see "ACPI Error", that's > > something to worry about, e.g., cannot convert predefined types. > > So I should be worried about this line from my Toshiba R600 > laptop's dmesg? > > ACPI Error: Package List length (0xC) larger than NumElements count > (0x4), truncated Strictly speaking, it is an error because ACPI specification says so (hence the error message). However, no exception is returned because of Windows compatibility according to the comments in the source. If everything is working fine, just ignore it. :-) Jung-uk Kim From robert.moore at intel.com Tue Oct 13 22:50:08 2009 From: robert.moore at intel.com (Moore, Robert) Date: Tue Oct 13 22:56:43 2009 Subject: ACPI Warning: Converted Buffer to expected String In-Reply-To: <200910131815.53053.jkim@FreeBSD.org> References: <20091011142256.GA3770@roadrunner.spoerlein.net> <200910131133.16487.jkim@FreeBSD.org> <4AD4F611.6080504@freebsd.org> <200910131815.53053.jkim@FreeBSD.org> Message-ID: <4911F71203A09E4D9981D27F9D8308583B31B180@orsmsx503.amr.corp.intel.com> Probably should be dropped down to a warning. This is usually caused by the BIOS modifying the package length on the fly. No ASL compiler would do this. >-----Original Message----- >From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >acpi@freebsd.org] On Behalf Of Jung-uk Kim >Sent: Tuesday, October 13, 2009 3:16 PM >To: freebsd-current@FreeBSD.org >Cc: Lawrence Stewart; freebsd-acpi@freebsd.org >Subject: Re: ACPI Warning: Converted Buffer to expected String > >On Tuesday 13 October 2009 05:50 pm, Lawrence Stewart wrote: >> Jung-uk Kim wrote: >> >> [snip] >> >> > by new ACPICA. However, if you see "ACPI Error", that's >> > something to worry about, e.g., cannot convert predefined types. >> >> So I should be worried about this line from my Toshiba R600 >> laptop's dmesg? >> >> ACPI Error: Package List length (0xC) larger than NumElements count >> (0x4), truncated > >Strictly speaking, it is an error because ACPI specification says so >(hence the error message). However, no exception is returned because >of Windows compatibility according to the comments in the source. > >If everything is working fine, just ignore it. :-) > >Jung-uk Kim >_______________________________________________ >freebsd-acpi@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From delphij at delphij.net Tue Oct 13 23:03:37 2009 From: delphij at delphij.net (Xin LI) Date: Tue Oct 13 23:03:44 2009 Subject: sftp broken? Message-ID: <4AD5073B.5030100@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Anyone noticed that sftp does not work anymore in recent -CURRENT? i.e. > sftp freefall.freebsd.org Connecting to freefall.freebsd.org... ls sftp> ls Segmentation fault The backtrace shows that the access violation happen inside libc (glob*) but I have not yet got a clue why this would ever happen. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkrVBzoACgkQi+vbBBjt66ByMQCfYEmnGHZXQILM2pzaF4mkSjgB q0wAoLeLRT5jJWwkaIHNdKeBjU+7vdek =fe9C -----END PGP SIGNATURE----- From quickembed at gmail.com Tue Oct 13 23:28:30 2009 From: quickembed at gmail.com (quickembed) Date: Tue Oct 13 23:33:11 2009 Subject: [head tinderbox] failure on arm/arm In-Reply-To: <86vdijdu0r.fsf@ds4.des.no> References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> <86vdijdu0r.fsf@ds4.des.no> Message-ID: Then it should be indicated how to "link". 2009/10/14 Dag-Erling Sm?rgrav : > quickembed writes: >> this error shows you have not indicate how to compile libgssapi.a file. >> CC is for .c file, you need to tell what's for .a (assembly) file. > > No, the command line is correct. ?Assembler sources end in .s or .S; .a > is a static library. > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > From lstewart at freebsd.org Tue Oct 13 23:43:05 2009 From: lstewart at freebsd.org (Lawrence Stewart) Date: Tue Oct 13 23:43:13 2009 Subject: ACPI Warning: Converted Buffer to expected String In-Reply-To: <200910131815.53053.jkim@FreeBSD.org> References: <20091011142256.GA3770@roadrunner.spoerlein.net> <200910131133.16487.jkim@FreeBSD.org> <4AD4F611.6080504@freebsd.org> <200910131815.53053.jkim@FreeBSD.org> Message-ID: <4AD51077.1030603@freebsd.org> Jung-uk Kim wrote: > On Tuesday 13 October 2009 05:50 pm, Lawrence Stewart wrote: >> Jung-uk Kim wrote: >> >> [snip] >> >>> by new ACPICA. However, if you see "ACPI Error", that's >>> something to worry about, e.g., cannot convert predefined types. >> So I should be worried about this line from my Toshiba R600 >> laptop's dmesg? >> >> ACPI Error: Package List length (0xC) larger than NumElements count >> (0x4), truncated > > Strictly speaking, it is an error because ACPI specification says so > (hence the error message). However, no exception is returned because > of Windows compatibility according to the comments in the source. > Ok thanks for explaining. > If everything is working fine, just ignore it. :-) When I boot this particular laptop into windows and then back into FreeBSD (even after a power down in between), I get a reproducible panic while the kernel is booting and probing devices which can only be fixed by going into the BIOS config screen and restoring to defaults. I suspect the Windows drivers are leaving the hardware in some fancy state the FreeBSD kernel doesn't like. I have a hunch it is ACPI related. Is there some way I can tell? The panic/backtrace is always the same as follows: Slab at 0xffffff00025d5b18, freei 3 = 0. panic: Duplicate free of item 0xffffff00025f8c00 from zone 0xffffff00b697d400(1024) Backtrace at the ddb prompt looks like this: db> bt kdb_enter()+0x3d panic()+0x17b uma_dbg_free()+0x171 uma_zfree_arg()+0x68 free()+0xbd device_set_driver()+0x8e device_attach()+0x19b bus_generic_attach()+0x1a acpi_pci_attach()+0x147 device_attach()+0x69 bus_generic_attach()+0x1a acpi_pcib_attach()+0x1a7 acpi_pcib_acpi_attach()+0x1a5 device_attach()+0x69 bus_generic_attach()+0x1a acpi_attach()+0x9e4 device_attach()+0x69 bus_generic_attach()+0x1a device_attach()+0x69 root_bus_configure()+0x28 configure()+0xa mi_startup()+0x59 btext()+0x2c Cheers, Lawrence From des at des.no Tue Oct 13 23:47:53 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Oct 13 23:48:11 2009 Subject: [head tinderbox] failure on arm/arm In-Reply-To: (quickembed@gmail.com's message of "Wed, 14 Oct 2009 07:28:29 +0800") References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> <86vdijdu0r.fsf@ds4.des.no> Message-ID: <86my3uetzr.fsf@ds4.des.no> quickembed writes: > Dag-Erling Sm?rgrav writes: > > quickembed writes: > > > this error shows you have not indicate how to compile libgssapi.a > > > file. CC is for .c file, you need to tell what's for .a > > > (assembly) file. > > No, the command line is correct. Assembler sources end in .s or .S; > > .a is a static library. > Then it should be indicated how to "link". No. The Makefile is fine. One of the source files was missing an #include that contained inline functions or macros, which the compiler then assumed were external functions. DES -- Dag-Erling Sm?rgrav - des@des.no From bsd at acd.homelinux.org Tue Oct 13 23:54:12 2009 From: bsd at acd.homelinux.org (bsduser) Date: Tue Oct 13 23:54:19 2009 Subject: if_rum dies on transmit... In-Reply-To: <20091013174201.GC67082@weongyo> (Weongyo Jeong's message of "Tue, 13 Oct 2009 10:42:01 -0700") References: <86051.1254232666@critter.freebsd.dk> <20091013174201.GC67082@weongyo> Message-ID: <86iqei7tgq.fsf@jodie.vectavision.com> Weongyo Jeong writes: > On Tue, Sep 29, 2009 at 01:57:46PM +0000, Poul-Henning Kamp wrote: >> >> Has anybody else seen if_rum die when you try to transmit a file over >> a TCP connection ? >> >> If I try to print across the network, upload a file with ftp or anything >> else of that general tenor, if_rum seems to hang the output queue and >> stops transmitting packets. >> >> Restarting wpa_supplicant mostly resolves the issue, but it does not >> on its own discover the problem. >> >> According to tcpdump(8), packets are still received. >> >> Any ideas ? > > Could you please test with attached patch? > > regards, > Weongyo Jeong > > I had the same issues with if_rum at least while using WPA and your patch made them go away.... ( although removing and plugging back in does not quite work ) # scp INDEX-8* cookie:/usr/ports INDEX-8 100% 19MB 2.1MB/s 00:09 INDEX-8.db 100% 34MB 2.4MB/s 00:14 before the patch this would just hang. Another quick test using rsync on a bunch of files worked flawless too. usbconfig list: ugen7.2: at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON The adapter is a WUSB54GC and yes, you made my day :-) From des at des.no Wed Oct 14 00:06:45 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Oct 14 00:06:51 2009 Subject: [head tinderbox] failure on arm/arm In-Reply-To: (quickembed@gmail.com's message of "Wed, 14 Oct 2009 07:53:23 +0800") References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> <86vdijdu0r.fsf@ds4.des.no> <86my3uetzr.fsf@ds4.des.no> Message-ID: <86aazuet4c.fsf@ds4.des.no> quickembed writes: > should not it say "unresolved external function...." etc if the > compiler can not find the function body? Yes, that's exactly what it does: /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function 'gsskrb5_extract_authz_data_from_sec_context': /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit declaration of function 'der_get_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit declaration of function 'der_free_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit declaration of function 'der_length_oid' /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit declaration of function 'der_put_oid' DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Wed Oct 14 00:35:08 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Oct 14 00:35:14 2009 Subject: sftp broken? In-Reply-To: <4AD5073B.5030100@delphij.net> (Xin LI's message of "Tue, 13 Oct 2009 16:03:23 -0700") References: <4AD5073B.5030100@delphij.net> Message-ID: <8663aiert1.fsf@ds4.des.no> Xin LI writes: > The backtrace shows that the access violation happen inside libc > (glob*) but I have not yet got a clue why this would ever happen. It's trying to dereference a NULL function pointer: (gdb) frame 1 #1 0x0000000800ef9920 in glob2 (pathbuf=0x7fffffff5660, pathend=0x7fffffff56a8, pathend_last=0x7fffffff7658, pattern=0x7fffffff76a8, pglob=0x7fffffffd8d0, limit=0x7fffffffd720) at /usr/src/lib/libc/gen/glob.c:844 844 return((*pglob->gl_lstat)(buf, sb)); (gdb) p pglob $1 = (glob_t *) 0x7fffffffd8d0 (gdb) p *pglob $2 = {gl_pathc = 0, gl_matchc = 0, gl_offs = 0, gl_flags = 216, gl_pathv = 0x0, gl_errfunc = 0, gl_closedir = 0x408bfb , gl_readdir = 0x408b50 , gl_opendir = 0x408b20 , gl_lstat = 0, gl_stat = 0x7fffffffda00} The problem is that OpenSSH wants to use its own version of glob(3), but we don't compile it or link it in, so it calls ours with a struct pglob that has the wrong layout. The attached patch should fix that, I will commit it when I've tested it more thoroughly. DES -- Dag-Erling Sm?rgrav - des@des.no -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-glob.diff Type: text/x-patch Size: 1012 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091014/2f5a0b6f/openssh-glob.bin From quickembed at gmail.com Tue Oct 13 23:53:24 2009 From: quickembed at gmail.com (quickembed) Date: Wed Oct 14 01:37:18 2009 Subject: [head tinderbox] failure on arm/arm In-Reply-To: <86my3uetzr.fsf@ds4.des.no> References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> <86vdijdu0r.fsf@ds4.des.no> <86my3uetzr.fsf@ds4.des.no> Message-ID: should not it say "unresolved external function...." etc if the compiler can not find the function body? 2009/10/14 Dag-Erling Sm?rgrav : > quickembed writes: >> Dag-Erling Sm?rgrav writes: >> > quickembed writes: >> > > this error shows you have not indicate how to compile libgssapi.a >> > > file. ?CC is for .c file, you need to tell what's for .a >> > > (assembly) file. >> > No, the command line is correct. ?Assembler sources end in .s or .S; >> > .a is a static library. >> Then it should be indicated how to "link". > > No. ?The Makefile is fine. ?One of the source files was missing an > #include that contained inline functions or macros, which the compiler > then assumed were external functions. > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > From pjd at FreeBSD.org Wed Oct 14 06:28:35 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Wed Oct 14 06:28:47 2009 Subject: zfs boot vs loader In-Reply-To: <4AD45A8D.4070605@icyb.net.ua> References: <4AD3220B.5030502@icyb.net.ua> <86ws30ikfw.fsf@gmail.com> <4AD45A8D.4070605@icyb.net.ua> Message-ID: <20091014062827.GC1696@garage.freebsd.pl> On Tue, Oct 13, 2009 at 01:46:37PM +0300, Andriy Gapon wrote: > > Thanks to all who replied! > I think that I figured it out with your help. > > 'unload' does indeed unload zpool.cache and the latter is needed for proper zfs > root mounting. > 'boot /other/kernel' executes some loader scripts and zpool.cache gets loaded in > this case (because of the settings in defaults/loader.conf). > When doing manual 'load xxx' and then just 'boot' no loader scripts are executed > and zpool.cache does not get loaded. In this case one has to load it manually > using the suggested 'load -t xxx' approach. Could you repeat what you were doing but with vfs.zfs.debug set to 1 from the loader? You should see some messages about missing file, maybe we should do them visible always and not after increasing debug level? -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- 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-current/attachments/20091014/a180eeb9/attachment.pgp From guru at unixarea.de Wed Oct 14 06:32:20 2009 From: guru at unixarea.de (Matthias Apitz) Date: Wed Oct 14 06:32:27 2009 Subject: [kde-freebsd] 9-CURRENT (r197801) && artsd of kde-3.5.10_2 gives SIGSEGV In-Reply-To: <20091013153815.GA88394@bsdcrew.de> References: <20091011062419.GA2168@current.Sisis.de> <3a142e750910111214rb75f185k12b2cc7e1aba59d9@mail.gmail.com> <20091012130914.GA4180@current.Sisis.de> <20091013153815.GA88394@bsdcrew.de> Message-ID: <20091014063221.GA2301@current.Sisis.de> El d?a Tuesday, October 13, 2009 a las 05:38:15PM +0200, Martin Wilke escribi?: > > # uname -a > > FreeBSD vm-azul.Sisis.de 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r197801: Tue > > Oct 6 13:57:38 CEST 2009 > > guru@vm-azul.Sisis.de:/usr/obj/usr/src/sys/REBELION-HEAD i386 > > > > When kernel and user land have been on 9-CURRENT, I removed /usr/ports, > > checked them out with CVS and build all my ports, especially KDE3. > > > > I don't see how an old library or binary can cause this. Only some ABI > > change which is not supported in the KDE sources... > > > > Don't know if someone from FreeBSD's KDE team can (or will) comment on it. It > > seems to me that they all went away (to KDE4 :-)). > > > > Thx > > unfortunately you're right, we're a small team, > we spend all our energy to KDE4. Sorry but > so is the life. > > - - Martin Hi Martin, I understand the situation and I fully appreciate your work (and the work of others) to bring KDE to FreeBSD. Don't get me wrong with the following I'd like to say. I think only supporting KDE4 is not a good idea. IMHO, KDE4 is a bit heading in the wrong direction. KDE4 is unusable for a lot of (older) hardware and is unusable, at least, for smaller laptops or netbooks, just because of the resources it is consuming. If the KDE team is leaving KDE3, and I don't expect further development, but only compability with upcoming FreeBSD ABI changes (or whatever), than we will not have KDE3 anymore from 9-CURRENT (or even from 8.0-RELEASE) anymore. Which would be a real pity :-( I'm willing to nail this small issue down. I've already compiled the arts-1.5.10_2,1 port with --enable-debug=full and will test it the upcoming weekend. Do you have any hints for me on debugging? I have had already a look into the code where it crashes in soundserver/kmedia2.cc: ... unsigned long Arts::PlayObject_private_base::_IID = Arts::MCOPUtils::makeIID("Arts::PlayObject_private"); Arts::PlayObject_base *Arts::PlayObject_base::_create(const std::string& subClass) { Arts::Object_skel *skel = Arts::ObjectManager::the()->create(subClass); assert(skel); Arts::PlayObject_base *castedObject = (Arts::PlayObject_base *)skel->_cast(Arts::PlayObject_base::_IID); assert(castedObject); return castedObject; } ... but can't see anything what could cause this SIGSEGV; as well I have fetched the 8.0-RC1 precompiled package arts-1.5.10_2,1.tbz and will give it a try in 9-CURRENT. Will let you know what I can find out. Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ Vote NO to EU The Lisbon Treaty: http://www.no-means-no.eu From bzeeb-lists at lists.zabbadoz.net Wed Oct 14 06:40:09 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Oct 14 06:40:16 2009 Subject: Where to report LORs? (ffs and unionfs LORs included In-Reply-To: References: Message-ID: <20091014063657.Q5956@maildrop.int.zabbadoz.net> On Tue, 13 Oct 2009, Alexander Best wrote: > Harald Schmalzbauer schrieb am 2009-10-10: >> Alexander Best schrieb am 07.07.2009 21:33 (localtime): >>> try http://sources.zabbadoz.net/freebsd/lor.html > >> I still see a unionfs LOR with RELENG_8 which is not listed, so I'd >> like to report it again. >> lock order reversal: >> 1st 0xc372c488 unionfs (unionfs) @ >> /FlashBSD/src/sys/fs/unionfs/union_subr.c:356 >> 2nd 0xc372c594 ufs (ufs) @ /FlashBSD/src/sys/kern/vfs_subr.c:2188 >> KDB: stack backtrace: >> db_trace_self_wrapper(c0616390,c08cd5d5,c3416770,c3416500,d5c42864,.. >> .) at db_trace_self_wrapper+0x26 >> _witness_debugger(c08cd5d5,c372c594,c08c0703,c3416500,c08d4ec2,...) >> at _witness_debugger+0x49 >> witness_checkorder(c372c594,9,c08d4ec2,88c,0,...) at >> witness_checkorder+0x6ec >> __lockmgr_args(c372c594,80100,c372c5b0,0,0,...) at >> __lockmgr_args+0xc97 >> ffs_lock(d5c42958,8,c36c4764,80100,c372c53c,...) at ffs_lock+0x96 >> VOP_LOCK1_APV(c09374a0,d5c42958,c05d89e9,c09477c0,c372c53c,...) at >> VOP_LOCK1_APV+0x9a >> _vn_lock(c372c53c,80100,c08d4ec2,88c,c0877c6e,...) at _vn_lock+0x46 >> vrele(c372c53c,d5c429d8,c372c4a4,0,0,...) at vrele+0x12a >> unionfs_noderem(c372c430,c36c46c0,d5c42a44,c06764fc,d5c42a20,...) at >> unionfs_noderem+0x1e5 >> unionfs_reclaim(d5c42a20,d5c42a20,0,0,c372c4a4,...) at >> unionfs_reclaim+0x1b >> vgonel(c372c4a4,0,c08d4ec2,9c5,c372c4a4,...) at vgonel+0x100 >> vrecycle(c372c430,c36c46c0,d5c42aa4,c0675c29,d5c42a8c,...) at >> vrecycle+0x6a >> unionfs_inactive(d5c42a8c,d5c42a8c,c08d4ec2,924,c0947780,...) at >> unionfs_inactive+0x28 >> vinactive(c372c594,d5c42ac0,c08d4ec2,8aa,c3451de0,...) at >> vinactive+0x6a >> vput(c372c430,ffffffdf,c344ab80,0,c36c46c0,...) at vput+0x205 >> kern_statat_vnhook(c36c46c0,0,ffffff9c,28209e1c,0,...) at >> kern_statat_vnhook+0xe0 >> kern_statat(c36c46c0,0,ffffff9c,28209e1c,0,...) at kern_statat+0x3c >> kern_stat(c36c46c0,28209e1c,0,d5c42c18,c0a83a18,...) at >> kern_stat+0x36 >> stat(c36c46c0,d5c42cf8,8,d5c42d38,c0916cd0,...) at stat+0x2b >> syscall(d5c42d38) at syscall+0x176 >> Xint0x80_syscall() at Xint0x80_syscall+0x20 >> --- syscall (188, FreeBSD ELF32, stat), eip = 0x281c6c2b, esp = >> 0xbfbfe96c, ebp = 0xbfbfea68 --- > >> So far I couldn't notice any deadlock, but the box is not in >> production yet. > >> -Harry > > you might also want to write Bjoern Zeeb (http://wiki.freebsd.org/BjoernZeeb) > with a link to your report. he's the guy maintaining the lor page. preferably use the reference already give in this thread at the top: http://sources.zabbadoz.net/freebsd/lor.html /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From bland at FreeBSD.org Wed Oct 14 07:05:44 2009 From: bland at FreeBSD.org (Alexander Nedotsukov) Date: Wed Oct 14 07:06:01 2009 Subject: [head tinderbox] failure on arm/arm In-Reply-To: <86aazuet4c.fsf@ds4.des.no> References: <200910122344.n9CNijv9037645@freebsd-current.sentex.ca> <86vdijdu0r.fsf@ds4.des.no> <86my3uetzr.fsf@ds4.des.no> <86aazuet4c.fsf@ds4.des.no> Message-ID: Heh. You just repeat my mistake (presumably with a bit of help from my side though). Those warning lines are really provoking :-) While missed #include issue still true it was not a source of build failure. libgssapi_krb5 now have libgssapi as a dependency but stay first in the _prebuild_libs list and nothing said build framework why it must build it in a different order. I committed the fix yesterday: http://svn.freebsd.org/viewvc/base?view=revision&revision=198020 Alexander. ps. I noticed that mails from tinderbox.freebsd.org contains link to not existed tinderbox.des.no host. On Wed, 14 Oct 2009 02:06:43 +0200, Dag-Erling Sm?rgrav wrote: > quickembed writes: >> should not it say "unresolved external function...." etc if the >> compiler can not find the function body? > > Yes, that's exactly what it does: > > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c: In function > 'gsskrb5_extract_authz_data_from_sec_context': > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:591: warning: implicit > declaration of function 'der_get_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:601: warning: implicit > declaration of function 'der_free_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:614: warning: implicit > declaration of function 'der_length_oid' > /src/kerberos5/lib/libgssapi_krb5/gss_krb5.c:622: warning: implicit > declaration of function 'der_put_oid' > > DES From hselasky at c2i.net Wed Oct 14 07:36:38 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Oct 14 07:36:45 2009 Subject: if_rum dies on transmit... In-Reply-To: <86iqei7tgq.fsf@jodie.vectavision.com> References: <86051.1254232666@critter.freebsd.dk> <20091013174201.GC67082@weongyo> <86iqei7tgq.fsf@jodie.vectavision.com> Message-ID: <200910140935.46509.hselasky@c2i.net> On Wednesday 14 October 2009 01:41:09 bsduser wrote: > Weongyo Jeong writes: > > On Tue, Sep 29, 2009 at 01:57:46PM +0000, Poul-Henning Kamp wrote: > >> Has anybody else seen if_rum die when you try to transmit a file over > >> a TCP connection ? > >> > >> If I try to print across the network, upload a file with ftp or anything > >> else of that general tenor, if_rum seems to hang the output queue and > >> stops transmitting packets. > >> > >> Restarting wpa_supplicant mostly resolves the issue, but it does not > >> on its own discover the problem. > >> > >> According to tcpdump(8), packets are still received. > >> > >> Any ideas ? > > > > Could you please test with attached patch? > > > > regards, > > Weongyo Jeong > > I had the same issues with if_rum at least while using WPA and your patch > made them go away.... ( although removing and plugging back in does not > quite work ) > > # scp INDEX-8* cookie:/usr/ports > INDEX-8 100% 19MB 2.1MB/s 00:09 > INDEX-8.db 100% 34MB 2.4MB/s 00:14 > > before the patch this would just hang. > > Another quick test using rsync on a bunch of files worked flawless too. > > usbconfig list: > > ugen7.2: at usbus7, cfg=0 > md=HOST spd=HIGH (480Mbps) pwr=ON > > The adapter is a WUSB54GC and yes, you made my day :-) Weongyo: Is the problem that some ifqueues go full and then the USB transfers are not restarted properly? Probably the other wlan network adapters have the same problem too and should be patched similarly. --HPS From alexbestms at math.uni-muenster.de Wed Oct 14 10:49:57 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Wed Oct 14 10:50:04 2009 Subject: buffers not syncing correctly during shutdown Message-ID: hi there, to keep it short: 1. mount a removable device (e.g. an usb stick) (better use -r to prevent data loss) 2. unplug the device (without unmounting it) 3. `shutdown -r now` what happens is that the usual shutdown routine gets processed until all buffers are synced, but then the system stalls. after resetting the system all devices (which were supposed to be synced) are marked dirty and are being fsck'ed. cheers. alex oh...and i'm running FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r197914: Sat Oct 10 02:58:19 CEST 2009 root@otaku:/usr/obj/usr/src/sys/ARUNDEL i386 From alexbestms at math.uni-muenster.de Wed Oct 14 11:21:52 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Wed Oct 14 11:21:59 2009 Subject: panic when mounting device >= 2 times Message-ID: could somebody have a look at this PR please: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108968 this still exists in -CURRENT. cheers. alex From avg at icyb.net.ua Wed Oct 14 11:59:01 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Oct 14 11:59:08 2009 Subject: panic when mounting device >= 2 times In-Reply-To: References: Message-ID: <4AD5BD00.4050700@icyb.net.ua> on 14/10/2009 14:21 Alexander Best said the following: > could somebody have a look at this PR please: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108968 > > this still exists in -CURRENT. This is because of serious and long-standing brokenness (probably from time of introduction of GEOM) in g_vfs_open/g_vfs_close. The essence: 1. we allow multiple concurrent read-only mounts of a device 2. but even a read-only mount mangles bufobj of device vnode 3. Bug! Trivial fix with POLA violation - prohibit concurrent RO mounts. Non-trivial fix - _somehow_ avoid changing or depending on device vnode bufobj. See this for even more evil example of this problem: http://lists.freebsd.org/pipermail/freebsd-fs/2009-February/005676.html -- Andriy Gapon From pieter at degoeje.nl Wed Oct 14 12:33:26 2009 From: pieter at degoeje.nl (Pieter de Goeje) Date: Wed Oct 14 12:33:33 2009 Subject: [kde-freebsd] 9-CURRENT (r197801) && artsd of kde-3.5.10_2 gives SIGSEGV In-Reply-To: <20091014063221.GA2301@current.Sisis.de> References: <20091011062419.GA2168@current.Sisis.de> <20091013153815.GA88394@bsdcrew.de> <20091014063221.GA2301@current.Sisis.de> Message-ID: <200910141433.10715.pieter@degoeje.nl> On Wednesday 14 October 2009 08:32:21 Matthias Apitz wrote: > I think only supporting KDE4 is not a good idea. IMHO, KDE4 is a bit > heading in the wrong direction. KDE4 is unusable for a lot of (older) > hardware and is unusable, at least, for smaller laptops or netbooks, > just because of the resources it is consuming. If the KDE team is > leaving KDE3, and I don't expect further development, but only > compability with upcoming FreeBSD ABI changes (or whatever), than we > will not have KDE3 anymore from 9-CURRENT (or even from 8.0-RELEASE) > anymore. Which would be a real pity :-( I'm suprised someone actually uses artsd. As a fellow KDE3 user on 9-CURRENT (on beefy hardware btw), I didn't have this issue because I always disable artsd because I don't want sound notifications. As long as people are using KDE3 I don't think it will die because people just like you will find the problem(s) and fix it. That said, I couldn't reproduce the problem (artsd works fine if I enable it). Uname: FreeBSD 9.0-CURRENT #2: Fri Oct 9 08:37:37 CEST 2009 i386 - Pieter > > I'm willing to nail this small issue down. I've already compiled the > arts-1.5.10_2,1 port with --enable-debug=full and will test it the > upcoming weekend. Do you have any hints for me on debugging? > I have had already a look into the code where it crashes in > soundserver/kmedia2.cc: > > ... > unsigned long Arts::PlayObject_private_base::_IID = > Arts::MCOPUtils::makeIID("Arts::PlayObject_private"); > > Arts::PlayObject_base *Arts::PlayObject_base::_create(const std::string& > subClass) { > Arts::Object_skel *skel = > Arts::ObjectManager::the()->create(subClass); assert(skel); > Arts::PlayObject_base *castedObject = (Arts::PlayObject_base > *)skel->_cast(Arts::PlayObject_base::_IID); assert(castedObject); > return castedObject; > } > ... > > but can't see anything what could cause this SIGSEGV; > > as well I have fetched the 8.0-RC1 precompiled package arts-1.5.10_2,1.tbz > and will give it a try in 9-CURRENT. > > Will let you know what I can find out. > > Thanks > > matthias From guru at unixarea.de Wed Oct 14 12:44:12 2009 From: guru at unixarea.de (Matthias Apitz) Date: Wed Oct 14 12:44:19 2009 Subject: [kde-freebsd] 9-CURRENT (r197801) && artsd of kde-3.5.10_2 gives SIGSEGV In-Reply-To: <200910141433.10715.pieter@degoeje.nl> References: <20091011062419.GA2168@current.Sisis.de> <20091013153815.GA88394@bsdcrew.de> <20091014063221.GA2301@current.Sisis.de> <200910141433.10715.pieter@degoeje.nl> Message-ID: <20091014124410.GA4606@current.Sisis.de> El d?a Wednesday, October 14, 2009 a las 02:33:10PM +0200, Pieter de Goeje escribi?: > On Wednesday 14 October 2009 08:32:21 Matthias Apitz wrote: > > I think only supporting KDE4 is not a good idea. IMHO, KDE4 is a bit > > heading in the wrong direction. KDE4 is unusable for a lot of (older) > > hardware and is unusable, at least, for smaller laptops or netbooks, > > just because of the resources it is consuming. If the KDE team is > > leaving KDE3, and I don't expect further development, but only > > compability with upcoming FreeBSD ABI changes (or whatever), than we > > will not have KDE3 anymore from 9-CURRENT (or even from 8.0-RELEASE) > > anymore. Which would be a real pity :-( > > I'm suprised someone actually uses artsd. As a fellow KDE3 user on 9-CURRENT > (on beefy hardware btw), I didn't have this issue because I always disable (btw: I'm using KDE3 on 8-CURRENT on my beefy laptop too); > artsd because I don't want sound notifications. As long as people are using > KDE3 I don't think it will die because people just like you will find the > problem(s) and fix it. > > That said, I couldn't reproduce the problem (artsd works fine if I enable it). > Uname: FreeBSD 9.0-CURRENT #2: Fri Oct 9 08:37:37 CEST 2009 i386 what is the SVN rev number of your kernel (mine is r197801) and how aRts came to your system, via /usr/ports or how? matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ Vote NO to EU The Lisbon Treaty: http://www.no-means-no.eu From pieter at degoeje.nl Wed Oct 14 13:06:47 2009 From: pieter at degoeje.nl (Pieter de Goeje) Date: Wed Oct 14 13:06:53 2009 Subject: [kde-freebsd] 9-CURRENT (r197801) && artsd of kde-3.5.10_2 gives SIGSEGV In-Reply-To: <20091014124410.GA4606@current.Sisis.de> References: <20091011062419.GA2168@current.Sisis.de> <200910141433.10715.pieter@degoeje.nl> <20091014124410.GA4606@current.Sisis.de> Message-ID: <200910141504.19965.pieter@degoeje.nl> On Wednesday 14 October 2009 14:44:10 Matthias Apitz wrote: > El d?a Wednesday, October 14, 2009 a las 02:33:10PM +0200, Pieter de Goeje escribi?: > > On Wednesday 14 October 2009 08:32:21 Matthias Apitz wrote: > > > I think only supporting KDE4 is not a good idea. IMHO, KDE4 is a bit > > > heading in the wrong direction. KDE4 is unusable for a lot of (older) > > > hardware and is unusable, at least, for smaller laptops or netbooks, > > > just because of the resources it is consuming. If the KDE team is > > > leaving KDE3, and I don't expect further development, but only > > > compability with upcoming FreeBSD ABI changes (or whatever), than we > > > will not have KDE3 anymore from 9-CURRENT (or even from 8.0-RELEASE) > > > anymore. Which would be a real pity :-( > > > > I'm suprised someone actually uses artsd. As a fellow KDE3 user on > > 9-CURRENT (on beefy hardware btw), I didn't have this issue because I > > always disable > > (btw: I'm using KDE3 on 8-CURRENT on my beefy laptop too); > > > artsd because I don't want sound notifications. As long as people are > > using KDE3 I don't think it will die because people just like you will > > find the problem(s) and fix it. > > > > That said, I couldn't reproduce the problem (artsd works fine if I enable > > it). Uname: FreeBSD 9.0-CURRENT #2: Fri Oct 9 08:37:37 CEST 2009 i386 > > what is the SVN rev number of your kernel (mine is r197801) and how aRts > came to your system, via /usr/ports or how? I can't give you an exact revision (sources were obtained with csup) but r197869 should be pretty close. Arts was build using ports/audio/arts (version 1.5.10_2,1). Another PC running RELENG_8 (amd64) from Sep. 24 also has a working arts (same version, also compiled/installed via ports). - Pieter From gary.jennejohn at freenet.de Wed Oct 14 13:10:29 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Wed Oct 14 13:10:36 2009 Subject: buffers not syncing correctly during shutdown In-Reply-To: References: Message-ID: <20091014151026.699a5765@ernst.jennejohn.org> On Wed, 14 Oct 2009 12:49:54 +0200 (CEST) Alexander Best wrote: > hi there, > > to keep it short: > > 1. mount a removable device (e.g. an usb stick) (better use -r to prevent data > loss) > 2. unplug the device (without unmounting it) > 3. `shutdown -r now` > > what happens is that the usual shutdown routine gets processed until all > buffers are synced, but then the system stalls. > > after resetting the system all devices (which were supposed to be synced) are > marked dirty and are being fsck'ed. > > cheers. > alex > > oh...and i'm running FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r197914: > Sat Oct 10 02:58:19 CEST 2009 root@otaku:/usr/obj/usr/src/sys/ARUNDEL > i386 > I'm inclined to say that umount'ing the file systems is failing because you pulled the USB stick out without doing umount. Of course, that results in all file systems still being marked dirty. Obviously, this pathological case isn't being handled. I personally don't see why it ever should be handled. This is UNIX not Windows and users should be smart enough to know that they umount such devices before removing them otherwise nasty things can happen. --- Gary Jennejohn From ivoras at freebsd.org Wed Oct 14 13:13:37 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Oct 14 13:13:44 2009 Subject: buffers not syncing correctly during shutdown In-Reply-To: <20091014151026.699a5765@ernst.jennejohn.org> References: <20091014151026.699a5765@ernst.jennejohn.org> Message-ID: Gary Jennejohn wrote: > I personally don't see why it ever should be handled. This is UNIX not > Windows and users should be smart enough to know that they umount such > devices before removing them otherwise nasty things can happen. Yes, but this is 2009 not 1978. From alexbestms at math.uni-muenster.de Wed Oct 14 13:30:45 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Wed Oct 14 13:31:03 2009 Subject: buffers not syncing correctly during shutdown In-Reply-To: <20091014151026.699a5765@ernst.jennejohn.org> Message-ID: Gary Jennejohn schrieb am 2009-10-14: > On Wed, 14 Oct 2009 12:49:54 +0200 (CEST) > Alexander Best wrote: > > hi there, > > to keep it short: > > 1. mount a removable device (e.g. an usb stick) (better use -r to > > prevent data > > loss) > > 2. unplug the device (without unmounting it) > > 3. `shutdown -r now` > > what happens is that the usual shutdown routine gets processed > > until all > > buffers are synced, but then the system stalls. > > after resetting the system all devices (which were supposed to be > > synced) are > > marked dirty and are being fsck'ed. > > cheers. > > alex > > oh...and i'm running FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT > > #0 r197914: > > Sat Oct 10 02:58:19 CEST 2009 > > root@otaku:/usr/obj/usr/src/sys/ARUNDEL > > i386 > I'm inclined to say that umount'ing the file systems is failing > because > you pulled the USB stick out without doing umount. Of course, that > results in all file systems still being marked dirty. Obviously, > this > pathological case isn't being handled. > I personally don't see why it ever should be handled. This is UNIX > not > Windows and users should be smart enough to know that they umount > such > devices before removing them otherwise nasty things can happen. > --- > Gary Jennejohn this is 2009 and not the 70s/80s. the amount or non-removable devices is declining day by day. eventually all storage devices will become removable and freebsd should keep up with this development. i don't think labelling this obvious bug as a grand unix feature is valid. also there are other scenarios where this problem can occur. if the device produces i/o errors you won't be able to unmount it even with the -f switch. alex From alexbestms at math.uni-muenster.de Wed Oct 14 13:35:29 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Wed Oct 14 13:35:36 2009 Subject: panic when mounting device >= 2 times In-Reply-To: <4AD5BD00.4050700@icyb.net.ua> Message-ID: Andriy Gapon schrieb am 2009-10-14: > on 14/10/2009 14:21 Alexander Best said the following: > > could somebody have a look at this PR please: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108968 > > this still exists in -CURRENT. > This is because of serious and long-standing brokenness (probably > from time of > introduction of GEOM) in g_vfs_open/g_vfs_close. > The essence: > 1. we allow multiple concurrent read-only mounts of a device > 2. but even a read-only mount mangles bufobj of device vnode > 3. Bug! > Trivial fix with POLA violation - prohibit concurrent RO mounts. > Non-trivial fix - _somehow_ avoid changing or depending on device > vnode bufobj. > See this for even more evil example of this problem: > http://lists.freebsd.org/pipermail/freebsd-fs/2009-February/005676.html thanks a lot for the hint. unfortunately i'm not a programmer and thus won't be able to help with this problem. :-( cheers. alex From avg at icyb.net.ua Wed Oct 14 13:43:29 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Oct 14 13:43:35 2009 Subject: buffers not syncing correctly during shutdown In-Reply-To: <20091014151026.699a5765@ernst.jennejohn.org> References: <20091014151026.699a5765@ernst.jennejohn.org> Message-ID: <4AD5D57A.9090900@icyb.net.ua> on 14/10/2009 16:10 Gary Jennejohn said the following: > > I'm inclined to say that umount'ing the file systems is failing because > you pulled the USB stick out without doing umount. Of course, that > results in all file systems still being marked dirty. Obviously, this > pathological case isn't being handled. > > I personally don't see why it ever should be handled. This is UNIX not > Windows and users should be smart enough to know that they umount such > devices before removing them otherwise nasty things can happen. There was a specific project funded by FreeBSD Foundation to handle issues like this. UNIX does not have to have deficiencies in comparison with Windows, and mistakes / emergency situations do happen. Developer who worked on the mentioned above project has expressed interest in resolving this issue. -- Andriy Gapon From mlobo at digiart.art.br Wed Oct 14 13:54:04 2009 From: mlobo at digiart.art.br (Mario Lobo) Date: Wed Oct 14 13:54:10 2009 Subject: buffers not syncing correctly during shutdown In-Reply-To: <20091014151026.699a5765@ernst.jennejohn.org> References: <20091014151026.699a5765@ernst.jennejohn.org> Message-ID: <18175.200.249.56.17.1255528438.squirrel@squirrel.sv4.hmnoc.net> > On Wed, 14 Oct 2009 12:49:54 +0200 (CEST) > Alexander Best wrote: > >> hi there, >> >> to keep it short: >> >> 1. mount a removable device (e.g. an usb stick) (better use -r to >> prevent data >> loss) >> 2. unplug the device (without unmounting it) >> 3. `shutdown -r now` >> >> what happens is that the usual shutdown routine gets processed until all >> buffers are synced, but then the system stalls. >> >> after resetting the system all devices (which were supposed to be >> synced) are >> marked dirty and are being fsck'ed. >> >> cheers. >> alex >> >> oh...and i'm running FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT #0 >> r197914: >> Sat Oct 10 02:58:19 CEST 2009 >> root@otaku:/usr/obj/usr/src/sys/ARUNDEL >> i386 >> > > I'm inclined to say that umount'ing the file systems is failing because > you pulled the USB stick out without doing umount. Of course, that > results in all file systems still being marked dirty. Obviously, this > pathological case isn't being handled. > > I personally don't see why it ever should be handled. This is UNIX not > Windows and users should be smart enough to know that they umount such > devices before removing them otherwise nasty things can happen. > > --- > Gary Jennejohn > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I must add that even windows has a "Safely Remove Hardware" before unplugging the usb device. Mario From des at des.no Wed Oct 14 16:37:36 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Oct 14 16:37:43 2009 Subject: buffers not syncing correctly during shutdown In-Reply-To: <18175.200.249.56.17.1255528438.squirrel@squirrel.sv4.hmnoc.net> (Mario Lobo's message of "Wed, 14 Oct 2009 10:53:58 -0300 (BRT)") References: <20091014151026.699a5765@ernst.jennejohn.org> <18175.200.249.56.17.1255528438.squirrel@squirrel.sv4.hmnoc.net> Message-ID: <86vdiix775.fsf@ds4.des.no> "Mario Lobo" writes: > I must add that even windows has a "Safely Remove Hardware" before > unplugging the usb device. What it really means is "sync the filesystem and tell me if there are any open or locked files". In most cases, you can yank the USB stick out without adverse consequences. DES -- Dag-Erling Sm?rgrav - des@des.no From wblock at wonkity.com Wed Oct 14 17:04:08 2009 From: wblock at wonkity.com (Warren Block) Date: Wed Oct 14 17:04:15 2009 Subject: Why does hal think my USB devices are fixed? Message-ID: Fixed as opposed to removable. hal used to see these USB devices--USB memory sticks, memory cards in a reader--as removable devices. Which they are. Same computer, same config that used to automount these devices as removable, but now FreeBSD 8.0-RC1 and hal says they are fixed devices: org.freedesktop.hal.storage.mount-fixed no <-- (action, result). Is this be due to the USB system? -Warren Block * Rapid City, South Dakota USA From mlobo at digiart.art.br Wed Oct 14 17:16:16 2009 From: mlobo at digiart.art.br (Mario Lobo) Date: Wed Oct 14 17:16:22 2009 Subject: buffers not syncing correctly during shutdown In-Reply-To: <86vdiix775.fsf@ds4.des.no> References: <20091014151026.699a5765@ernst.jennejohn.org> <18175.200.249.56.17.1255528438.squirrel@squirrel.sv4.hmnoc.net> <86vdiix775.fsf@ds4.des.no> Message-ID: <26594.200.249.56.17.1255540574.squirrel@squirrel.sv4.hmnoc.net> > "Mario Lobo" writes: >> I must add that even windows has a "Safely Remove Hardware" before >> unplugging the usb device. > > What it really means is "sync the filesystem and tell me if there are > any open or locked files". In most cases, you can yank the USB stick > out without adverse consequences. > > DES > -- > Dag-Erling Sm??rgrav - des@des.no > That IS true ! but like you said, "most cases" <> "all cases". Once, on a company I was doing work at, I clicked on "Safely Remove Hardware" and it said "can?t do it. device busy", although there was (apparently) nothing using any files from the stick. I yanked it out anyway. result: the 3 files I edited from the stick were gone :(. Since I don?t know when I am gonna hit a case that doesn?t belong to "most", I always try to remember to unmount (i.e. Safely Remove Hardware) the stick before unplugging it. Mario From hselasky at c2i.net Wed Oct 14 17:44:15 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Oct 14 17:44:22 2009 Subject: Why does hal think my USB devices are fixed? In-Reply-To: References: Message-ID: <200910141945.09311.hselasky@c2i.net> On Wednesday 14 October 2009 19:04:07 Warren Block wrote: > Fixed as opposed to removable. hal used to see these USB > devices--USB memory sticks, memory cards in a reader--as removable > devices. Which they are. > > Same computer, same config that used to automount these devices as > removable, but now FreeBSD 8.0-RC1 and hal says they are fixed devices: > > org.freedesktop.hal.storage.mount-fixed no <-- (action, result). > > Is this be due to the USB system? Hi Warren, The fixed/removable information is transferred to the PC using a SCSI INQUIRY command. What the device reports or what the CAM layer reports to HAL is not up to the USB stack. The most significant bit of second byte of the INQUIRY response decides if the medium is removable or not. See: ustorage_fs_inquiry() in src/sys/dev/usb/storage/ustorage_fs.c --HPS From marcus at marcuscom.com Wed Oct 14 17:46:47 2009 From: marcus at marcuscom.com (Joe Marcus Clarke) Date: Wed Oct 14 17:46:54 2009 Subject: Why does hal think my USB devices are fixed? In-Reply-To: References: Message-ID: <1255542419.22880.131.camel@shumai.marcuscom.com> On Wed, 2009-10-14 at 11:04 -0600, Warren Block wrote: > Fixed as opposed to removable. hal used to see these USB > devices--USB memory sticks, memory cards in a reader--as removable > devices. Which they are. > > Same computer, same config that used to automount these devices as > removable, but now FreeBSD 8.0-RC1 and hal says they are fixed devices: > > org.freedesktop.hal.storage.mount-fixed no <-- (action, result). > > Is this be due to the USB system? I have stopped development of hal-0.5.11. I have put a lot of work into the upcoming 0.5.13 release to fix numerous issues with USB detection. I have been getting good results on -CURRENT with various USB sticks. You may want to give that a try. You can get the port from the ports module at http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi . Joe -- PGP Key : http://www.marcuscom.com/pgp.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091014/901b3ca3/attachment.pgp From amvandemore at gmail.com Wed Oct 14 17:53:00 2009 From: amvandemore at gmail.com (Adam Vande More) Date: Wed Oct 14 17:53:07 2009 Subject: Why does hal think my USB devices are fixed? In-Reply-To: References: Message-ID: <6201873e0910141029r75cad42fk55c92cf25bbef340@mail.gmail.com> On Wed, Oct 14, 2009 at 12:04 PM, Warren Block wrote: > Fixed as opposed to removable. hal used to see these USB devices--USB > memory sticks, memory cards in a reader--as removable devices. Which they > are. > > Same computer, same config that used to automount these devices as > removable, but now FreeBSD 8.0-RC1 and hal says they are fixed devices: > > org.freedesktop.hal.storage.mount-fixed no <-- (action, result). > > Is this be due to the USB system? > > -Warren Block * Rapid City, South Dakota USA > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > It's a config option in /usr/ports/sysutils/hal -- Adam Vande More From fjwcash at gmail.com Wed Oct 14 17:53:41 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Wed Oct 14 17:53:48 2009 Subject: buffers not syncing correctly during shutdown In-Reply-To: <26594.200.249.56.17.1255540574.squirrel@squirrel.sv4.hmnoc.net> References: <20091014151026.699a5765@ernst.jennejohn.org> <18175.200.249.56.17.1255528438.squirrel@squirrel.sv4.hmnoc.net> <86vdiix775.fsf@ds4.des.no> <26594.200.249.56.17.1255540574.squirrel@squirrel.sv4.hmnoc.net> Message-ID: 2009/10/14 Mario Lobo > > "Mario Lobo" writes: > >> I must add that even windows has a "Safely Remove Hardware" before > >> unplugging the usb device. > > > > What it really means is "sync the filesystem and tell me if there are > > any open or locked files". In most cases, you can yank the USB stick > > out without adverse consequences. > > > > DES > > -- > > Dag-Erling Sm?rgrav - des@des.no > > > That IS true ! but like you said, "most cases" <> "all cases". Once, on a > company I was doing work at, I clicked on "Safely Remove Hardware" and it > said "can? do it. device busy", although there was (apparently) nothing > using any files from the stick. I yanked it out anyway. result: the 3 > files I edited from the stick were gone :(. Since I don? know when I am > gonna hit a case that doesn? belong to "most", I always try to remember > to unmount (i.e. Safely Remove Hardware) the stick before unplugging it. > > How Windows deals with USB removable storage depends on how you configure the storage policy for the individual device, and globally for all removable storage devices. The default in Windows XP is "Optimise for performance", which requires the use of the "Safely remove hardware" feature. This enables write caching on the device, which can lead to data loss if you remove the device before data is actually flushed/written. You can change it to "Optimise for quick removal", which disables write caching, so you can remove the device at pretty much any time. It's all done via the Policies tab in the Device Properties, accessible via the Device Manager or by right-clicking->Properties on the device in Windows Explorer. I believe the default was switched at some point, though, so that the Safely Remove isn't always needed. -- Freddie Cash fjwcash@gmail.com From shuvaev at physik.uni-wuerzburg.de Wed Oct 14 17:56:04 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Wed Oct 14 17:56:11 2009 Subject: buffers not syncing correctly during shutdown In-Reply-To: References: <20091014151026.699a5765@ernst.jennejohn.org> Message-ID: <20091014175600.GA55864@wep4035.physik.uni-wuerzburg.de> On Wed, Oct 14, 2009 at 03:13:00PM +0200, Ivan Voras wrote: > Gary Jennejohn wrote: > > >I personally don't see why it ever should be handled. This is UNIX not > >Windows and users should be smart enough to know that they umount such > >devices before removing them otherwise nasty things can happen. > > Yes, but this is 2009 not 1978. > Well, the other side of being in 2009 is that filesystems have evolved too. For example, I have UFS2 + SU on most of my removable media (sticks and external hard drives). I was always interested how this new "feature" of FreeBSD, to allow removable media disappear almost silently, plays in this case? I've had one case when I lost my external hard drive during tar -xvf ports.tar.bz2 into it. I haven't touched it at the moment (voltage spikes?). It was quite funny trying to browse through the half-cached content then... have spent ~5 minutes before noticing kernel message. Re-plugging the drive has brought it back, with dirty filesystem, of course. Maybe it would be better if the system paniced then :/) Anyway, my point is that removing the media with most of modern filesystems on it without unmounting is an operator error. IMHO, the system should warn such an operators in one or the other way... 0.00$, Alexey. From wblock at wonkity.com Wed Oct 14 18:02:11 2009 From: wblock at wonkity.com (Warren Block) Date: Wed Oct 14 18:02:17 2009 Subject: Why does hal think my USB devices are fixed? In-Reply-To: <6201873e0910141029r75cad42fk55c92cf25bbef340@mail.gmail.com> References: <6201873e0910141029r75cad42fk55c92cf25bbef340@mail.gmail.com> Message-ID: On Wed, 14 Oct 2009, Adam Vande More wrote: > On Wed, Oct 14, 2009 at 12:04 PM, Warren Block wrote: > Fixed as opposed to removable. ?hal used to see these USB > devices--USB memory sticks, memory cards in a reader--as > removable devices. ?Which they are. > > Same computer, same config that used to automount these devices > as removable, but now FreeBSD 8.0-RC1 and hal says they are > fixed devices: > > org.freedesktop.hal.storage.mount-fixed no <-- (action, result). > > Is this be due to the USB system? > > It's a config option in /usr/ports/sysutils/hal "fixed mountpoints" is off, but I think that's "fixed" as in "use the same mountpoint every time", not fixed as in non-removable. -Warren Block * Rapid City, South Dakota USA From wblock at wonkity.com Wed Oct 14 18:46:46 2009 From: wblock at wonkity.com (Warren Block) Date: Wed Oct 14 18:46:53 2009 Subject: Why does hal think my USB devices are fixed? In-Reply-To: <1255542419.22880.131.camel@shumai.marcuscom.com> References: <1255542419.22880.131.camel@shumai.marcuscom.com> Message-ID: On Wed, 14 Oct 2009, Joe Marcus Clarke wrote: > On Wed, 2009-10-14 at 11:04 -0600, Warren Block wrote: >> Fixed as opposed to removable. hal used to see these USB >> devices--USB memory sticks, memory cards in a reader--as removable >> devices. Which they are. >> >> Same computer, same config that used to automount these devices as >> removable, but now FreeBSD 8.0-RC1 and hal says they are fixed devices: >> >> org.freedesktop.hal.storage.mount-fixed no <-- (action, result). >> >> Is this due to the USB system? > > I have stopped development of hal-0.5.11. I have put a lot of work into > the upcoming 0.5.13 release to fix numerous issues with USB detection. > I have been getting good results on -CURRENT with various USB sticks. > You may want to give that a try. You can get the port from the ports > module at http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi . That's a definite improvement. USB sticks work fine, or at least the three I have here work fine. The memory card reader still comes up as fixed. This is a Sandisk SDDRX3-3in1 with multiple slots. da0 and da1 always come up, along with the s1 slice of whichever memory card is loaded. -Warren Block * Rapid City, South Dakota USA From marcus at marcuscom.com Wed Oct 14 18:53:30 2009 From: marcus at marcuscom.com (Joe Marcus Clarke) Date: Wed Oct 14 18:53:36 2009 Subject: Why does hal think my USB devices are fixed? In-Reply-To: References: <1255542419.22880.131.camel@shumai.marcuscom.com> Message-ID: <1255546422.22880.136.camel@shumai.marcuscom.com> On Wed, 2009-10-14 at 12:46 -0600, Warren Block wrote: > On Wed, 14 Oct 2009, Joe Marcus Clarke wrote: > > > On Wed, 2009-10-14 at 11:04 -0600, Warren Block wrote: > >> Fixed as opposed to removable. hal used to see these USB > >> devices--USB memory sticks, memory cards in a reader--as removable > >> devices. Which they are. > >> > >> Same computer, same config that used to automount these devices as > >> removable, but now FreeBSD 8.0-RC1 and hal says they are fixed devices: > >> > >> org.freedesktop.hal.storage.mount-fixed no <-- (action, result). > >> > >> Is this due to the USB system? > > > > I have stopped development of hal-0.5.11. I have put a lot of work into > > the upcoming 0.5.13 release to fix numerous issues with USB detection. > > I have been getting good results on -CURRENT with various USB sticks. > > You may want to give that a try. You can get the port from the ports > > module at http://www.marcuscom.com:8080/cgi-bin/cvsweb.cgi . > > That's a definite improvement. USB sticks work fine, or at least the > three I have here work fine. The memory card reader still comes up as > fixed. This is a Sandisk SDDRX3-3in1 with multiple slots. da0 and da1 > always come up, along with the s1 slice of whichever memory card is > loaded. I don't have any card readers, but as Hans pointed out, this part will come from the SCSI subsystem. If CAM says the device is not removable, then hal will go with that. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091014/1f4b31ee/attachment.pgp From svein-listmail at stillbilde.net Wed Oct 14 18:55:55 2009 From: svein-listmail at stillbilde.net (Svein Skogen (listmail account)) Date: Wed Oct 14 18:56:02 2009 Subject: buffers not syncing correctly during shutdown In-Reply-To: References: <20091014151026.699a5765@ernst.jennejohn.org> <18175.200.249.56.17.1255528438.squirrel@squirrel.sv4.hmnoc.net> <86vdiix775.fsf@ds4.des.no> <26594.200.249.56.17.1255540574.squirrel@squirrel.sv4.hmnoc.net> Message-ID: <4AD61EB8.4020506@stillbilde.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Freddie Cash wrote: > I believe the default was switched at some point, though, so that the Safely > Remove isn't always needed. I believe this was changed around SP2 for XP, and Vista has always had quick-removal for the devices it undestands to be external (eSATA still gets detected as non-hotswappable unless you registry-magic-it). However, this doesn't protect against pebcak-yanking the device you have documents open from. It really doesn't. Just trust me, I've tried. ;) Maybe this is something FreeBSD should consider? Maybe a hack in "mount" to allow the mount-option "is-removable", that tells the OS "don't bother write-cache this" and "cleanse the cache when user yanks hardware"? //Svein - -- - --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg ?stli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE - --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrWHrgACgkQODUnwSLUlKTUUACgiUcE2LpKOq/xqvRpd+/IbC8+ wOYAn1F3oH8akMqBj2cXu1c6xetEXyQ9 =ZF4S -----END PGP SIGNATURE----- From weongyo.jeong at gmail.com Wed Oct 14 19:56:02 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Wed Oct 14 19:56:08 2009 Subject: if_rum dies on transmit... In-Reply-To: <200910140935.46509.hselasky@c2i.net> References: <86051.1254232666@critter.freebsd.dk> <20091013174201.GC67082@weongyo> <86iqei7tgq.fsf@jodie.vectavision.com> <200910140935.46509.hselasky@c2i.net> Message-ID: <20091014195631.GD67082@weongyo> On Wed, Oct 14, 2009 at 09:35:46AM +0200, Hans Petter Selasky wrote: > On Wednesday 14 October 2009 01:41:09 bsduser wrote: > > Weongyo Jeong writes: > > > On Tue, Sep 29, 2009 at 01:57:46PM +0000, Poul-Henning Kamp wrote: > > >> Has anybody else seen if_rum die when you try to transmit a file over > > >> a TCP connection ? > > >> > > >> If I try to print across the network, upload a file with ftp or anything > > >> else of that general tenor, if_rum seems to hang the output queue and > > >> stops transmitting packets. > > >> > > >> Restarting wpa_supplicant mostly resolves the issue, but it does not > > >> on its own discover the problem. > > >> > > >> According to tcpdump(8), packets are still received. > > >> > > >> Any ideas ? > > > > > > Could you please test with attached patch? > > > > > > regards, > > > Weongyo Jeong > > > > I had the same issues with if_rum at least while using WPA and your patch > > made them go away.... ( although removing and plugging back in does not > > quite work ) > > > > # scp INDEX-8* cookie:/usr/ports > > INDEX-8 100% 19MB 2.1MB/s 00:09 > > INDEX-8.db 100% 34MB 2.4MB/s 00:14 > > > > before the patch this would just hang. > > > > Another quick test using rsync on a bunch of files worked flawless too. > > > > usbconfig list: > > > > ugen7.2: at usbus7, cfg=0 > > md=HOST spd=HIGH (480Mbps) pwr=ON > > > > The adapter is a WUSB54GC and yes, you made my day :-) > > Weongyo: > > Is the problem that some ifqueues go full and then the USB transfers are not > restarted properly? Probably the other wlan network adapters have the same > problem too and should be patched similarly. Yes and I think other USB wireless devices should be fixed also. I'll do it as soon as possible. regards, Weongyo Jeong From weongyo.jeong at gmail.com Wed Oct 14 20:10:26 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Wed Oct 14 20:10:33 2009 Subject: if_rum dies on transmit... In-Reply-To: <86iqei7tgq.fsf@jodie.vectavision.com> References: <86051.1254232666@critter.freebsd.dk> <20091013174201.GC67082@weongyo> <86iqei7tgq.fsf@jodie.vectavision.com> Message-ID: <20091014201059.GE67082@weongyo> On Tue, Oct 13, 2009 at 05:41:09PM -0600, bsduser wrote: > Weongyo Jeong writes: > > > On Tue, Sep 29, 2009 at 01:57:46PM +0000, Poul-Henning Kamp wrote: > >> > >> Has anybody else seen if_rum die when you try to transmit a file over > >> a TCP connection ? > >> > >> If I try to print across the network, upload a file with ftp or anything > >> else of that general tenor, if_rum seems to hang the output queue and > >> stops transmitting packets. > >> > >> Restarting wpa_supplicant mostly resolves the issue, but it does not > >> on its own discover the problem. > >> > >> According to tcpdump(8), packets are still received. > >> > >> Any ideas ? > > > > Could you please test with attached patch? > > > > regards, > > Weongyo Jeong > > > > > > I had the same issues with if_rum at least while using WPA and your patch made > them go away.... ( although removing and plugging back in does not quite > work ) > > # scp INDEX-8* cookie:/usr/ports > INDEX-8 100% 19MB 2.1MB/s 00:09 > INDEX-8.db 100% 34MB 2.4MB/s 00:14 > > before the patch this would just hang. > > Another quick test using rsync on a bunch of files worked flawless too. > > usbconfig list: > > ugen7.2: at usbus7, cfg=0 > md=HOST spd=HIGH (480Mbps) pwr=ON > > The adapter is a WUSB54GC and yes, you made my day :-) Patched at r198098. Thank you for testing! regards, Weongyo Jeong From rmacklem at uoguelph.ca Wed Oct 14 20:24:18 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Wed Oct 14 20:24:24 2009 Subject: 8.0RC1 and BOOTP_NFSV3 regression? In-Reply-To: References: Message-ID: On Sun, 4 Oct 2009, Daniel Braniss wrote: > I'm not sure when this happened, but a kernel compiled with > BOOTP_NFSV3 fails when the server is not FreeBSD (ie NetAPP). > > before, with the option set, only when kernel_options="nfsv3" was set > it would fail/panic, this way, I could control which diskless, shearing the > same kernel, would boot with nfsv3 and which not, dependig on the server. > > there is hope! before it would panic when receiving a v3 file handle, now > it fails, but panics later when no init is found :-) > > is anyone with enough nfs v2/v3 knowledge willing to fix this? > Just fyi, the change of using NFSv3 by default resulted in this. The poster has confirmed that using "nfsv2" as an explicit option, allows the boot to work against a non-FreeBSD server. The problem is that nfs_setup_diskless() in sys/nfsclient/nfs_diskless.c assumed an NFSv2 type file handle, and then sys/nfsclient/nfs_vfsops.c sets the file handle size to NFSX_V3FH (which is the size of a FreeBSD server's NFSv3 file handle). At a glance, changing nfs_setup_diskless() to set the file handle size based on the length of boot.nfsroot.nfshandle is easy, but then it gets interesting... - In lib/libstand/nfs.c, there is NFSv2 code that fills in boot.nfsroot.nfshandle and adding/converting this to use NFSv3 wouldn't be too hard (more work than the above, but..). --> But I can't see how it can be told to use NFSv2 vs NFSv3? (Does anyone know of a way or would trying NFSv3 and then falling back to NFSv2 make sense?) I don't have a diskless NFS setup, so I'm going to have to depend upon others to do testing. (The poster is willing to do some testing in about 2 weeks.) I don't think this can be done for 8.0. If the change is considered a regression that needs to be fixed for 8.0, taking NFSMNT_NFSV3 out of the default flags in nfs_setup_diskless() would but it back the way FreeBSD7 behaves. I'll let others decide if this should be done. rick From des at des.no Wed Oct 14 20:34:54 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Oct 14 20:35:00 2009 Subject: buffers not syncing correctly during shutdown In-Reply-To: <26594.200.249.56.17.1255540574.squirrel@squirrel.sv4.hmnoc.net> (Mario Lobo's message of "Wed, 14 Oct 2009 14:16:14 -0300 (BRT)") References: <20091014151026.699a5765@ernst.jennejohn.org> <18175.200.249.56.17.1255528438.squirrel@squirrel.sv4.hmnoc.net> <86vdiix775.fsf@ds4.des.no> <26594.200.249.56.17.1255540574.squirrel@squirrel.sv4.hmnoc.net> Message-ID: <86my3tyas3.fsf@ds4.des.no> "Mario Lobo" writes: > That IS true ! but like you said, "most cases" <> "all cases". Once, on a > company I was doing work at, I clicked on "Safely Remove Hardware" and it > said "can?t do it. device busy", although there was (apparently) nothing > using any files from the stick. I yanked it out anyway. result: the 3 > files I edited from the stick were gone :(. Since I don?t know when I am > gonna hit a case that doesn?t belong to "most", I always try to remember > to unmount (i.e. Safely Remove Hardware) the stick before unplugging it. Always a good idea - but my point was that Windows's "safely remove hardware" feature should not be construed as an excuse for FreeBSD to hang or crash when you remove a disk or memory stick. DES -- Dag-Erling Sm?rgrav - des@des.no From wblock at wonkity.com Wed Oct 14 20:38:48 2009 From: wblock at wonkity.com (Warren Block) Date: Wed Oct 14 20:38:55 2009 Subject: Why does hal think my USB devices are fixed? In-Reply-To: <1255546422.22880.136.camel@shumai.marcuscom.com> References: <1255542419.22880.131.camel@shumai.marcuscom.com> <1255546422.22880.136.camel@shumai.marcuscom.com> Message-ID: On Wed, 14 Oct 2009, Joe Marcus Clarke wrote: > > I don't have any card readers, but as Hans pointed out, this part will > come from the SCSI subsystem. If CAM says the device is not removable, > then hal will go with that. Light sledgehammering in /usr/local/share/hal/fdi/preprobe/20thirdparty and the card reader can be made to work: First, stop hal trying to automount a card twice, once for the redundant "computer_storage" version of a disk: 10-ignore-computer_storage.fdi : true Then set some options for the card reader: 20-check-media.fdi : storage.media_check_enabled true true hal still sometimes doesn't notice new cards being connected, and the card reader's USB cable has to be reconnected. But at this point, it's at least as good as it was under 7-STABLE. -Warren Block * Rapid City, South Dakota USA From bsd at acd.homelinux.org Wed Oct 14 20:46:25 2009 From: bsd at acd.homelinux.org (Axel) Date: Wed Oct 14 20:46:32 2009 Subject: if_rum dies on transmit... In-Reply-To: <20091014201059.GE67082@weongyo> (Weongyo Jeong's message of "Wed, 14 Oct 2009 13:10:59 -0700") References: <86051.1254232666@critter.freebsd.dk> <20091013174201.GC67082@weongyo> <86iqei7tgq.fsf@jodie.vectavision.com> <20091014201059.GE67082@weongyo> Message-ID: <86pr8pg0v4.fsf@jodie.vectavision.com> Weongyo Jeong writes: > On Tue, Oct 13, 2009 at 05:41:09PM -0600, bsduser wrote: >> Weongyo Jeong writes: >> >> > On Tue, Sep 29, 2009 at 01:57:46PM +0000, Poul-Henning Kamp wrote: >> >> >> >> Has anybody else seen if_rum die when you try to transmit a file over >> >> a TCP connection ? >> >> >> >> If I try to print across the network, upload a file with ftp or anything >> >> else of that general tenor, if_rum seems to hang the output queue and >> >> stops transmitting packets. >> >> >> >> Restarting wpa_supplicant mostly resolves the issue, but it does not >> >> on its own discover the problem. >> >> >> >> According to tcpdump(8), packets are still received. >> >> >> >> Any ideas ? >> > >> > Could you please test with attached patch? >> > >> > regards, >> > Weongyo Jeong >> > >> > >> >> I had the same issues with if_rum at least while using WPA and your patch made >> them go away.... ( although removing and plugging back in does not quite >> work ) >> >> # scp INDEX-8* cookie:/usr/ports >> INDEX-8 100% 19MB 2.1MB/s 00:09 >> INDEX-8.db 100% 34MB 2.4MB/s 00:14 >> >> before the patch this would just hang. >> >> Another quick test using rsync on a bunch of files worked flawless too. >> >> usbconfig list: >> >> ugen7.2: at usbus7, cfg=0 >> md=HOST spd=HIGH (480Mbps) pwr=ON >> >> The adapter is a WUSB54GC and yes, you made my day :-) > > Patched at r198098. Thank you for testing! > > regards, > Weongyo Jeong For the records, I patched svn r197304 on an amd64 but am fairly sure it'll work the same on later revisions. Thanks very much for you work, -- Axel (bsd@acd.homelinux.org). From pjd at FreeBSD.org Wed Oct 14 20:47:08 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Wed Oct 14 20:47:16 2009 Subject: panic when mounting device >= 2 times In-Reply-To: <4AD5BD00.4050700@icyb.net.ua> References: <4AD5BD00.4050700@icyb.net.ua> Message-ID: <20091014204657.GB1727@garage.freebsd.pl> On Wed, Oct 14, 2009 at 02:58:56PM +0300, Andriy Gapon wrote: > on 14/10/2009 14:21 Alexander Best said the following: > > could somebody have a look at this PR please: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108968 > > > > this still exists in -CURRENT. > > This is because of serious and long-standing brokenness (probably from time of > introduction of GEOM) in g_vfs_open/g_vfs_close. > The essence: > 1. we allow multiple concurrent read-only mounts of a device > 2. but even a read-only mount mangles bufobj of device vnode > 3. Bug! > Trivial fix with POLA violation - prohibit concurrent RO mounts. > Non-trivial fix - _somehow_ avoid changing or depending on device vnode bufobj. I've this patch that is suppose to fix it: http://people.freebsd.org/~pjd/patches/geom_vfs.c.patch But AFAIR its not complete. I think it is still possible to remount one of the read-only mounts to read-write. Another possibility that comes to my mind is to keep list/array of consumers in bo_private instead of using one consumer only. This would be better in terms of access management. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- 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-current/attachments/20091014/f1f78f5d/attachment.pgp From gavin at FreeBSD.org Wed Oct 14 22:09:11 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Wed Oct 14 22:09:17 2009 Subject: if_rum dies on transmit... In-Reply-To: <20091014201059.GE67082@weongyo> References: <86051.1254232666@critter.freebsd.dk> <20091013174201.GC67082@weongyo> <86iqei7tgq.fsf@jodie.vectavision.com> <20091014201059.GE67082@weongyo> Message-ID: <20091014230715.E96894@ury.york.ac.uk> On Wed, 14 Oct 2009, Weongyo Jeong wrote: > On Tue, Oct 13, 2009 at 05:41:09PM -0600, bsduser wrote: >> Weongyo Jeong writes: >> >>> On Tue, Sep 29, 2009 at 01:57:46PM +0000, Poul-Henning Kamp wrote: >>>> >>>> Has anybody else seen if_rum die when you try to transmit a file over >>>> a TCP connection ? >>>> >>>> If I try to print across the network, upload a file with ftp or anything >>>> else of that general tenor, if_rum seems to hang the output queue and >>>> stops transmitting packets. >>> >>> Could you please test with attached patch? >>> >> >> I had the same issues with if_rum at least while using WPA and your patch made >> them go away.... ( although removing and plugging back in does not quite >> work ) >> >> # scp INDEX-8* cookie:/usr/ports >> INDEX-8 100% 19MB 2.1MB/s 00:09 >> INDEX-8.db 100% 34MB 2.4MB/s 00:14 >> >> before the patch this would just hang. >> >> Another quick test using rsync on a bunch of files worked flawless too. >> >> usbconfig list: >> >> ugen7.2: at usbus7, cfg=0 >> md=HOST spd=HIGH (480Mbps) pwr=ON >> >> The adapter is a WUSB54GC and yes, you made my day :-) > > Patched at r198098. Thank you for testing! Many thanks for this! Do you know if this patch is likely to fix the panics seen with rum(4) or is this likely to only fix the TX hangs? Thanks, Gavin From qing.li at bluecoat.com Thu Oct 15 01:13:45 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Thu Oct 15 01:13:52 2009 Subject: ARP Changes Message-ID: > > I know that arp has changed a lot in FreeBSD 8. I am wondering if one > change was by design? In older versions of FreeBSD, if you ping a host > that is on a local network but is down, after a few seconds ping displays: > ping: sendto: Host is down > ping: sendto: Host is down > This turned out to be a regression bug. A wrong variable is used and the incomplete entry was timing out too fast. So the ARP probe continues indefinitely ... > > Using arp to display the arp table shows: > > host.domain (x.x.x.x) at (incomplete) on em0 [ethernet] I wasn't returning incomplete entries, but now I am ... I have a patch for both issues, but I need to clean up the code because that wrong variable is used elsewhere in the same module. I should be able to commit a permanent fix by tomorrow. -- Qing From oberman at es.net Thu Oct 15 04:34:25 2009 From: oberman at es.net (Kevin Oberman) Date: Thu Oct 15 04:34:31 2009 Subject: Why does hal think my USB devices are fixed? In-Reply-To: Your message of "Wed, 14 Oct 2009 14:38:47 MDT." Message-ID: <20091015043422.6B42D1CC37@ptavv.es.net> > Date: Wed, 14 Oct 2009 14:38:47 -0600 (MDT) > From: Warren Block > Sender: owner-freebsd-current@freebsd.org > > On Wed, 14 Oct 2009, Joe Marcus Clarke wrote: > > > > I don't have any card readers, but as Hans pointed out, this part will > > come from the SCSI subsystem. If CAM says the device is not removable, > > then hal will go with that. > > Light sledgehammering in /usr/local/share/hal/fdi/preprobe/20thirdparty > and the card reader can be made to work: > > First, stop hal trying to automount a card twice, once for the redundant > "computer_storage" version of a disk: > > 10-ignore-computer_storage.fdi : > > > > > > > true > > > > > Then set some options for the card reader: > > 20-check-media.fdi : > > > > > > storage.media_check_enabled > > true > true > > > > > hal still sometimes doesn't notice new cards being connected, and the > card reader's USB cable has to be reconnected. But at this point, it's > at least as good as it was under 7-STABLE. Doing something to access the device seems to cause it to be "noticed". I use 'fsck -p' on the device, but I suspect dd(1) or most anything else that touches the device will do it. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From i.a.zhuravlev at cbtnet.ru Thu Oct 15 05:25:07 2009 From: i.a.zhuravlev at cbtnet.ru (Ilya Zhuravlev) Date: Thu Oct 15 05:25:14 2009 Subject: if_rum dies on transmit... In-Reply-To: <20091013174201.GC67082@weongyo> References: <86051.1254232666@critter.freebsd.dk> <20091013174201.GC67082@weongyo> Message-ID: <4AD6AC54.1010202@cbtnet.ru> Weongyo Jeong wrote: > On Tue, Sep 29, 2009 at 01:57:46PM +0000, Poul-Henning Kamp wrote: > >> Has anybody else seen if_rum die when you try to transmit a file over >> a TCP connection ? >> >> If I try to print across the network, upload a file with ftp or anything >> else of that general tenor, if_rum seems to hang the output queue and >> stops transmitting packets. >> >> Restarting wpa_supplicant mostly resolves the issue, but it does not >> on its own discover the problem. >> >> According to tcpdump(8), packets are still received. >> >> Any ideas ? >> > > Could you please test with attached patch? > > regards, > Weongyo Jeong > > Thanks, it stopped issues with my Dlink DWA-110 wbr, Ilya From qing.li at bluecoat.com Thu Oct 15 06:25:58 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Thu Oct 15 06:26:10 2009 Subject: ARP Changes References: Message-ID: I have committed the fix into the -current branch, svn r198111. Please give it a try and I plan to MFC the patch into 8.0 release branch in 3 days. Thank you for the report. -- Qing -----Original Message----- From: owner-freebsd-current@freebsd.org on behalf of Li, Qing Sent: Wed 10/14/2009 6:12 PM To: lab@gta.com; qingli@freebsd.org Cc: freebsd-net@freebsd.org; freebsd-current@freebsd.org Subject: Re: ARP Changes > > I know that arp has changed a lot in FreeBSD 8. I am wondering if one > change was by design? In older versions of FreeBSD, if you ping a host > that is on a local network but is down, after a few seconds ping displays: > ping: sendto: Host is down > ping: sendto: Host is down > This turned out to be a regression bug. A wrong variable is used and the incomplete entry was timing out too fast. So the ARP probe continues indefinitely ... > > Using arp to display the arp table shows: > > host.domain (x.x.x.x) at (incomplete) on em0 [ethernet] I wasn't returning incomplete entries, but now I am ... I have a patch for both issues, but I need to clean up the code because that wrong variable is used elsewhere in the same module. I should be able to commit a permanent fix by tomorrow. -- Qing _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From guru at unixarea.de Thu Oct 15 08:00:33 2009 From: guru at unixarea.de (Matthias Apitz) Date: Thu Oct 15 08:00:50 2009 Subject: [kde-freebsd] 9-CURRENT (r197801) && artsd of kde-3.5.10_2 gives SIGSEGV In-Reply-To: <20091014063221.GA2301@current.Sisis.de> References: <20091011062419.GA2168@current.Sisis.de> <3a142e750910111214rb75f185k12b2cc7e1aba59d9@mail.gmail.com> <20091012130914.GA4180@current.Sisis.de> <20091013153815.GA88394@bsdcrew.de> <20091014063221.GA2301@current.Sisis.de> Message-ID: <20091015080034.GA2045@current.Sisis.de> El d?a Wednesday, October 14, 2009 a las 08:32:21AM +0200, Matthias Apitz escribi?: > ... > > as well I have fetched the 8.0-RC1 precompiled package arts-1.5.10_2,1.tbz > and will give it a try in 9-CURRENT. > > Will let you know what I can find out. Hello, This morning I tried the 8.0-RC1 version of the pre-compiled package arts-1.5.10_2,1.tbz from the FreeBSD server: it crashes as well. So the problem is perhaps outside this package. While I was thinking what could be wrong I stumbled over the following small clash: as I said, I installed 8.0-RC1 base system and updated /usr/src from SVN and later after 9-CURRENT was build and installed I updated /usr/ports from CVS. The problem is that for the SVN checkout one must build the port /usr/ports/devel/subversion-freebsd; I compared the time when I did the SVN checkout (Oct 6, 11:xx) against the times in /var/db/pkg and it turned out that the following ports and have been installed *before* 9-CURRENT kernel/user-land: # ls -l */+CONTENTS | fgrep 'Oct 6 11' -rw-r--r-- 1 root wheel 7938 Oct 6 11:48 apr-ipv6-gdbm-db42-1.3.8.1.3.9/+CONTENTS -rw-r--r-- 1 root wheel 7368 Oct 6 11:44 autoconf-2.62/+CONTENTS -rw-r--r-- 1 root wheel 606 Oct 6 11:44 autoconf-wrapper-20071109/+CONTENTS -rw-r--r-- 1 root wheel 9579 Oct 6 11:44 automake-1.9.6_3/+CONTENTS -rw-r--r-- 1 root wheel 304 Oct 6 11:44 automake-wrapper-20071109/+CONTENTS -rw-r--r-- 1 root wheel 107102 Oct 6 11:46 db42-4.2.52_5/+CONTENTS -rw-r--r-- 1 root wheel 801 Oct 6 11:28 expat-2.0.1/+CONTENTS -rw-r--r-- 1 root wheel 1238 Oct 6 11:44 gdbm-1.8.3_3/+CONTENTS -rw-r--r-- 1 root wheel 33428 Oct 6 11:26 gettext-0.17_1/+CONTENTS -rw-r--r-- 1 root wheel 2795 Oct 6 11:26 gmake-3.81_3/+CONTENTS -rw-r--r-- 1 root wheel 2670 Oct 6 11:44 help2man-1.36.4_3/+CONTENTS -rw-r--r-- 1 root wheel 2856 Oct 6 11:23 libiconv-1.13.1/+CONTENTS -rw-r--r-- 1 root wheel 4625 Oct 6 11:19 libtool-2.2.6a/+CONTENTS -rw-r--r-- 1 root wheel 4011 Oct 6 11:44 m4-1.4.13,1/+CONTENTS -rw-r--r-- 1 root wheel 31411 Oct 6 11:28 neon28-0.28.4/+CONTENTS -rw-r--r-- 1 root wheel 1271 Oct 6 11:44 p5-gettext-1.05_2/+CONTENTS -rw-r--r-- 1 root wheel 314648 Oct 6 11:40 perl-5.8.9_3/+CONTENTS -rw-r--r-- 1 root wheel 573 Oct 6 11:27 pkg-config-0.23_1/+CONTENTS -rw-r--r-- 1 root wheel 376893 Oct 6 11:43 python26-2.6.2_3/+CONTENTS -rw-r--r-- 1 root wheel 1063 Oct 6 11:28 sqlite3-3.6.14.2/+CONTENTS -rw-r--r-- 1 root wheel 27342 Oct 6 11:50 subversion-freebsd-1.6.5/+CONTENTS esp. libtool-2.2.6a let me think that this procedure (i.e. building subversion-freebsd before updating to 9-CURRENT) could cause the clash. I will recompile the above ports and if this does not help re-install all and remove /usr/local/* and /var/db/pkg/* before starting with compiling the ports after the SVN and CVS parts are done. matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ Vote NO to EU The Lisbon Treaty: http://www.no-means-no.eu From matthias.andree at gmx.de Thu Oct 15 08:11:35 2009 From: matthias.andree at gmx.de (Matthias Andree) Date: Thu Oct 15 08:11:50 2009 Subject: buffers not syncing correctly during shutdown In-Reply-To: <20091014151026.699a5765@ernst.jennejohn.org> References: <20091014151026.699a5765@ernst.jennejohn.org> Message-ID: <4AD6D933.1070804@gmx.de> Gary Jennejohn schrieb: > On Wed, 14 Oct 2009 12:49:54 +0200 (CEST) > Alexander Best wrote: > >> hi there, >> >> to keep it short: >> >> 1. mount a removable device (e.g. an usb stick) (better use -r to prevent data >> loss) >> 2. unplug the device (without unmounting it) >> 3. `shutdown -r now` >> >> what happens is that the usual shutdown routine gets processed until all >> buffers are synced, but then the system stalls. >> >> after resetting the system all devices (which were supposed to be synced) are >> marked dirty and are being fsck'ed. >> >> cheers. >> alex >> >> oh...and i'm running FreeBSD otaku 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r197914: >> Sat Oct 10 02:58:19 CEST 2009 root@otaku:/usr/obj/usr/src/sys/ARUNDEL >> i386 >> > > I'm inclined to say that umount'ing the file systems is failing because > you pulled the USB stick out without doing umount. Of course, that > results in all file systems still being marked dirty. Obviously, this > pathological case isn't being handled. > > I personally don't see why it ever should be handled. This is UNIX not > Windows and users should be smart enough to know that they umount such > devices before removing them otherwise nasty things can happen. 1. If the device for one file system is gone, why would I mark *other* file systems dirty? There is no reason to do so. 2. If a file system was mounted read-only, and its device is removed, there are by definition ZERO dirty buffers that we need to synch on shutdown, so why does the premature unplug-readonly-before-unmount spoil the shutdown? From schmidt_chr at gmx.net Thu Oct 15 09:35:33 2009 From: schmidt_chr at gmx.net (Christian Schmidt) Date: Thu Oct 15 09:35:41 2009 Subject: Boot issues with a Dell Inspiron 530 and 8.0 RC1 In-Reply-To: <309b65830910130912u7fd303e9kffa1b248188b9194@mail.gmail.com> References: <309b65830910060054g16a099abxb8e203a46aa9e89c@mail.gmail.com> <4AD2BCD9.2090904@sandstorm.net> <309b65830910130912u7fd303e9kffa1b248188b9194@mail.gmail.com> Message-ID: <309b65830910150235w59857e83r23887193c36561f0@mail.gmail.com> On Tue, Oct 13, 2009 at 18:12, Christian Schmidt wrote: > On Mon, Oct 12, 2009 at 07:21, john hood wrote: >> Christian Schmidt wrote: > [...] >>> I am seeing a strange issue with my Dell Inspiron 530 with 8.0 RC1-p1 >>> at around 50-75% percent of all boots. It all boils down to GENERIC >>> throwing the following: >>> >>> AP #1 (PHY #1) failed! >>> panic y/n? [y] panic: bye-bye >>> cpuid = 0 > [...] >> We have 3 of these machines. >> >> In my experience, keyboard activity triggers the problem. ?If I boot the >> machine without any keyboard presses/releases between the time the loader >> starts the kernel and some time later, definitely by the time the USB >> keyboard driver attaches, then I don't get this problem. ?This includes any >> key-up (and maybe key repeat) events you may generate after typing a key at >> the boot menu, or after typing enter at the OK prompt, or pressing a key to >> bypass the autoboot timeout that counts down by seconds. >> >> If you let the machine start from cold without touching the keyboard, what >> happens? > > That is a very interesting point you are making. Indeed, it never > occured to me that I am usually hammering down on F1 and 1 to boot > faster (yeah yeah, I know ;-)). I let the machine boot through without > that a couple of times and it seemed to have worked for about a 100% > of those cases. I will keep testing but I think we have a hot > contender. :-) > Okay, after testing that for a couple of days I can confirm that it never-ever happens when I leave the keyboard alone during the boot-phase. As a workaround, I can live with not touching the keyboard. Nethertheless, this seems to be a bug that deserves fixing, isn't it? Thank you for your help. :-) Christian From ivoras at freebsd.org Thu Oct 15 09:47:33 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Oct 15 09:47:39 2009 Subject: buffers not syncing correctly during shutdown In-Reply-To: <20091014175600.GA55864@wep4035.physik.uni-wuerzburg.de> References: <20091014151026.699a5765@ernst.jennejohn.org> <20091014175600.GA55864@wep4035.physik.uni-wuerzburg.de> Message-ID: Alexey Shuvaev wrote: > On Wed, Oct 14, 2009 at 03:13:00PM +0200, Ivan Voras wrote: >> Gary Jennejohn wrote: >> >>> I personally don't see why it ever should be handled. This is UNIX not >>> Windows and users should be smart enough to know that they umount such >>> devices before removing them otherwise nasty things can happen. >> Yes, but this is 2009 not 1978. >> > Well, the other side of being in 2009 is that filesystems have evolved too. > For example, I have UFS2 + SU on most of my removable media (sticks and > external hard drives). I was always interested how > this new "feature" of FreeBSD, to allow removable media disappear almost > silently, plays in this case? I see what you mean - UFS+SU is definitely not suitable for this environment. UFS without SU (mounted "normal" or "sync") OTOH is better. Windows mounts removable devices sync (unless told otherwise) since sometime around Win98SE. > I've had one case when I lost my external hard drive during > tar -xvf ports.tar.bz2 into it. I haven't touched it at the moment > (voltage spikes?). It was quite funny trying to browse through > the half-cached content then... have spent ~5 minutes before noticing > kernel message. > Re-plugging the drive has brought it back, with dirty filesystem, of course. > Maybe it would be better if the system paniced then :/) This would not help since the newly inserted device would get its own descriptor structure, whose pointer is obviously different from the old one... > Anyway, my point is that removing the media with most of > modern filesystems on it without unmounting is an operator error. > IMHO, the system should warn such an operators in one or the other way... Warn about what? That the media has been removed? AFAIK USB does this right now. Or you are suggesting another message from the file system layer saying: "see, about that in-transit data you are thinking about... well, it's gone now." :) From grarpamp at gmail.com Thu Oct 15 06:24:02 2009 From: grarpamp at gmail.com (grarpamp) Date: Thu Oct 15 11:31:26 2009 Subject: vmstat -m/-z field parsing Message-ID: Some of the 'first' columns in the output contain spaces which makes it hard to parse the data out. Unless I'm missing the reason, I propose they be changed to underscores '_' as per the rest of the ouput. Thanks. The ones I see with my GENERIC kernel plus: 2 1 0xc0f77000 13c50c zfs.ko 3 2 0xc10b4000 3cec opensolaris.ko 4 1 0xc10b8000 11ea4 geom_eli.ko 5 2 0xc10ca000 25af0 crypto.ko 6 2 0xc10f0000 ac20 zlib.ko 7 1 0xc10fb000 7224 snd_ich.ko 8 2 0xc1103000 56740 sound.ko are: # vmstat -m... CAM SIM CAM XPT CAM dev queue CAM periph CAM queue NFS FHA eli data # vmstat -z 128 Bucket 16 Bucket 32 Bucket 64 Bucket DP fakepg FFS inode FFS1 dinode FFS2 dinode KMAP ENTRY L VFS Cache MAC labels MAP ENTRY S VFS Cache SG fakepg UMA Hash UMA Kegs UMA RCntSlabs UMA Slabs UMA Zones VM OBJECT umtx pi From valin at buchlovice.org Thu Oct 15 12:28:20 2009 From: valin at buchlovice.org (=?UTF-8?B?UmFkZWsgVmFsw6HFoWVr?=) Date: Thu Oct 15 12:28:32 2009 Subject: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" Message-ID: <4AD710D6.70404@buchlovice.org> Hi, I want to ask if there is something new in adding support to gptzfsboot/zfsboot for reading gang-blocks? From Sun's docs: Gang blocks When there is not enough contiguous space to write a complete block, the ZIO pipeline will break the I/O up into smaller 'gang blocks' which can later be assembled transparently to appear as complete blocks. Everything works fine for me, until I rewrite kernel/world after system upgrade to latest one (releng_8). After this am I no longer able to boot from zfs raidz1 pool with following messages: >/ ZFS: i/o error - all block copies unavailable />/ ZFS: can't read MOS />/ ZFS: unexpected object set type lld />/ ZFS: unexpected object set type lld />/ />/ FreeBSD/i386 boot />/ Default: z:/boot/kernel/kernel />/ boot: />/ ZFS: unexpected object set type lld />/ />/ FreeBSD/i386 boot />/ Default: tank:/boot/kernel/kernel />/ boot: // /I presume it's the same issue as talked in june-2009 current mailing list http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008589.html Any success in that matter? Thnx for answer. vaLin From jhb at freebsd.org Thu Oct 15 12:44:56 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Oct 15 12:45:08 2009 Subject: Scheduler weirdness In-Reply-To: <20091012134159.8f6e4d66.taku@tackymt.homeip.net> References: <6729ad0409e449f8dbda69ecd8feb618.squirrel@webmail.lerctr.org> <20091012134159.8f6e4d66.taku@tackymt.homeip.net> Message-ID: <200910150741.41569.jhb@freebsd.org> On Monday 12 October 2009 12:41:59 am Taku YAMAMOTO wrote: > On Sun, 11 Oct 2009 17:59:52 -0500 > "Larry Rosenman" wrote: > > > > > Ok, running RELENG_8 from Friday (10/9/2009). > > > > If I have 4 Folding-at-home processes running (they nice themselves) the > > system is slow as a dog. > > Ah, I reminded a local patch regarding SCHED_ULE against niced threads. > Something like this: > > --- sys/kern/sched_ule.c.orig 2009-04-29 12:26:30.000000000 +0900 > +++ sys/kern/sched_ule.c 2009-04-30 08:13:30.951440396 +0900 > @@ -1406,7 +1406,7 @@ sched_priority(struct thread *td) > * score. Negative nice values make it easier for a thread to be > * considered interactive. > */ > - score = imax(0, sched_interact_score(td) - td->td_proc->p_nice); > + score = imax(0, sched_interact_score(td) + td->td_proc->p_nice); > if (score < sched_interact) { > pri = PRI_MIN_REALTIME; > pri += ((PRI_MAX_REALTIME - PRI_MIN_REALTIME) / sched_interact) Thanks, I've committed this after Jeff reviewed it and will MFC it soon. -- John Baldwin From jhb at freebsd.org Thu Oct 15 12:44:58 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Oct 15 12:45:09 2009 Subject: vmstat -m/-z field parsing In-Reply-To: References: Message-ID: <200910150747.55101.jhb@freebsd.org> On Thursday 15 October 2009 2:24:00 am grarpamp wrote: > Some of the 'first' columns in the > output contain spaces which makes > it hard to parse the data out. Unless I'm > missing the reason, I propose they be > changed to underscores '_' as > per the rest of the ouput. Thanks. You can also just not use whitespace for your field separator. For example with awk and sort: vmstat -z | awk -F '[:,]' '/ITEM/ { next } /^$/ { next } // { printf "%s:\t%d\n", $1, $2 * ($4 + $5) }' | sort -t: -k 2 -n (This computes the total size of allocated memory (both used and free items) for a zone and sorts the list so the biggest zones are last.) -- John Baldwin From rnoland at FreeBSD.org Thu Oct 15 13:14:38 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Oct 15 13:14:45 2009 Subject: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" In-Reply-To: <4AD710D6.70404@buchlovice.org> References: <4AD710D6.70404@buchlovice.org> Message-ID: <1255612465.2356.808.camel@balrog.2hip.net> On Thu, 2009-10-15 at 14:08 +0200, Radek Val??ek wrote: > Hi, > > I want to ask if there is something new in adding support to > gptzfsboot/zfsboot for reading gang-blocks? I've been thinking of trying to fix this, but haven't really come up with a repeatable way to test it. I might be able to come up with at least a hack to allow booting in the short term, but if you can try this patch so that we can verify that the issue is indeed gang blocks. This doesn't fix anything yet, but it should report when it finds a gang block. I know that it is tricky to test when you can't boot, but if you can apply this patch and reinstall gptzfsboot, it should tell us for sure that gang blocks are the issue. I assume that you have a partition layout something like mine: balrog% gpart show => 34 1953525101 ada0 GPT (932G) 34 128 1 freebsd-boot (64K) 162 8388608 2 freebsd-swap (4.0G) 8388770 1945136365 3 freebsd-zfs (928G) If so, all you should need to do is get this built and then: #gpart bootcode -p /boot/gptzfsboot -i 1 ada0 substituting appropriate partition index and device info obviously. robert. > From Sun's docs: > > Gang blocks > > When there is not enough contiguous space to write a complete block, the ZIO > pipeline will break the I/O up into smaller 'gang blocks' which can later be > assembled transparently to appear as complete blocks. > > Everything works fine for me, until I rewrite kernel/world after system > upgrade to latest one (releng_8). After this am I no longer able to boot > from zfs raidz1 pool with following messages: > > >/ ZFS: i/o error - all block copies unavailable > />/ ZFS: can't read MOS > />/ ZFS: unexpected object set type lld > />/ ZFS: unexpected object set type lld > />/ > />/ FreeBSD/i386 boot > />/ Default: z:/boot/kernel/kernel > />/ boot: > />/ ZFS: unexpected object set type lld > />/ > />/ FreeBSD/i386 boot > />/ Default: tank:/boot/kernel/kernel > />/ boot: > // > /I presume it's the same issue as talked in june-2009 current mailing > list > http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008589.html > > Any success in that matter? > > Thnx for answer. > > vaLin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: zfs-report-gb.patch Type: text/x-patch Size: 512 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091015/e9517e7c/zfs-report-gb.bin From jiashiun at gmail.com Thu Oct 15 13:41:18 2009 From: jiashiun at gmail.com (Jia-Shiun Li) Date: Thu Oct 15 13:41:45 2009 Subject: firefox-2 causes panic on ia64 8.0-beta2 In-Reply-To: <20090731081723.GB54196@mech-cluster241.men.bris.ac.uk> References: <20090730171820.GA1043@mech-cluster241.men.bris.ac.uk> <20090730172701.GA1043@mech-cluster241.men.bris.ac.uk> <20090731081723.GB54196@mech-cluster241.men.bris.ac.uk> Message-ID: <1d6d20bc0910150616k271e0a7ex4ce2bfd42c3e2ff3@mail.gmail.com> On Fri, Jul 31, 2009 at 4:17 PM, Anton Shterenlikht wrote: > > good?? or dear me.. all I ever wanted is to use FBSD, I'm a mechanical > engineer, nuts and bolts, etc. Look what I've dragged myself into.. > > Seriously though, are there any SSL/https web browsers known to > work on ia64? Does firefox3 or firefox35 work for you? Jia-Shiun. From ticso at cicely7.cicely.de Thu Oct 15 14:06:43 2009 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Thu Oct 15 14:06:50 2009 Subject: Why does hal think my USB devices are fixed? In-Reply-To: <200910141945.09311.hselasky@c2i.net> References: <200910141945.09311.hselasky@c2i.net> Message-ID: <20091015140633.GD62588@cicely7.cicely.de> On Wed, Oct 14, 2009 at 07:45:08PM +0200, Hans Petter Selasky wrote: > On Wednesday 14 October 2009 19:04:07 Warren Block wrote: > > Fixed as opposed to removable. hal used to see these USB > > devices--USB memory sticks, memory cards in a reader--as removable > > devices. Which they are. > > > > Same computer, same config that used to automount these devices as > > removable, but now FreeBSD 8.0-RC1 and hal says they are fixed devices: > > > > org.freedesktop.hal.storage.mount-fixed no <-- (action, result). > > > > Is this be due to the USB system? > > Hi Warren, > > The fixed/removable information is transferred to the PC using a SCSI INQUIRY > command. What the device reports or what the CAM layer reports to HAL is not > up to the USB stack. This is a different thing. SCSI inquiry tells about removeable media. Just some examples: USB flash sticks are removeable drives with unremoveable media. USB harddisks are removeable drives with unremoveable media. USB card readers are removeable drives with removeable media. (Plain old) Floppy drives are unremoveable drives with removeable media. SCSI harddisks are unremoveable drives with unremoveable media. But even this is not correct anymore. SATA and SCSI devices can be external and powered off at any time. In the result this means that every drive might be removeable today. > The most significant bit of second byte of the INQUIRY response decides if the > medium is removable or not. > > See: ustorage_fs_inquiry() in src/sys/dev/usb/storage/ustorage_fs.c > > --HPS > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From mexas at bristol.ac.uk Thu Oct 15 15:57:39 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Oct 15 15:57:52 2009 Subject: firefox-2 causes panic on ia64 8.0-beta2 In-Reply-To: <1d6d20bc0910150616k271e0a7ex4ce2bfd42c3e2ff3@mail.gmail.com> References: <20090730171820.GA1043@mech-cluster241.men.bris.ac.uk> <20090730172701.GA1043@mech-cluster241.men.bris.ac.uk> <20090731081723.GB54196@mech-cluster241.men.bris.ac.uk> <1d6d20bc0910150616k271e0a7ex4ce2bfd42c3e2ff3@mail.gmail.com> Message-ID: <20091015155731.GA91743@mech-cluster241.men.bris.ac.uk> On Thu, Oct 15, 2009 at 09:16:45PM +0800, Jia-Shiun Li wrote: > On Fri, Jul 31, 2009 at 4:17 PM, Anton Shterenlikht wrote: > > > > good?? or dear me.. all I ever wanted is to use FBSD, I'm a mechanical > > engineer, nuts and bolts, etc. Look what I've dragged myself into.. > > > > Seriously though, are there any SSL/https web browsers known to > > work on ia64? > > Does firefox3 or firefox35 work for you? no, problems with xpcom. It's been submitted as a bug ages ago. At present security/nss doesn't build either, so I cannot get kazehakase either. thank you anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From weongyo.jeong at gmail.com Thu Oct 15 17:28:46 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Thu Oct 15 17:28:52 2009 Subject: if_rum dies on transmit... In-Reply-To: <20091014230715.E96894@ury.york.ac.uk> References: <86051.1254232666@critter.freebsd.dk> <20091013174201.GC67082@weongyo> <86iqei7tgq.fsf@jodie.vectavision.com> <20091014201059.GE67082@weongyo> <20091014230715.E96894@ury.york.ac.uk> Message-ID: <20091015172914.GF67082@weongyo> On Wed, Oct 14, 2009 at 11:08:39PM +0100, Gavin Atkinson wrote: > On Wed, 14 Oct 2009, Weongyo Jeong wrote: > >On Tue, Oct 13, 2009 at 05:41:09PM -0600, bsduser wrote: > >>Weongyo Jeong writes: > >> > >>>On Tue, Sep 29, 2009 at 01:57:46PM +0000, Poul-Henning Kamp wrote: > >>>> > >>>>Has anybody else seen if_rum die when you try to transmit a file over > >>>>a TCP connection ? > >>>> > >>>>If I try to print across the network, upload a file with ftp or anything > >>>>else of that general tenor, if_rum seems to hang the output queue and > >>>>stops transmitting packets. > >>> > >>>Could you please test with attached patch? > >>> > >> > >>I had the same issues with if_rum at least while using WPA and your patch > >>made > >>them go away.... ( although removing and plugging back in does not quite > >>work ) > >> > >># scp INDEX-8* cookie:/usr/ports > >>INDEX-8 100% 19MB 2.1MB/s > >>00:09 > >>INDEX-8.db 100% 34MB 2.4MB/s > >>00:14 > >> > >>before the patch this would just hang. > >> > >>Another quick test using rsync on a bunch of files worked flawless too. > >> > >>usbconfig list: > >> > >>ugen7.2: at usbus7, cfg=0 > >>md=HOST spd=HIGH (480Mbps) pwr=ON > >> > >>The adapter is a WUSB54GC and yes, you made my day :-) > > > >Patched at r198098. Thank you for testing! > > Many thanks for this! > > Do you know if this patch is likely to fix the panics seen with rum(4) or > is this likely to only fix the TX hangs? AFAIK this patch only fixes TX hangs. I didn't see PRs yet related with the panics but I think it could affect user's panic a little bit. regards. Weongyo Jeong From oberman at es.net Thu Oct 15 18:33:40 2009 From: oberman at es.net (Kevin Oberman) Date: Thu Oct 15 18:33:48 2009 Subject: Boot issues with a Dell Inspiron 530 and 8.0 RC1 In-Reply-To: Your message of "Thu, 15 Oct 2009 11:35:11 +0200." <309b65830910150235w59857e83r23887193c36561f0@mail.gmail.com> Message-ID: <20091015183338.37FBB1CC44@ptavv.es.net> > From: Christian Schmidt > Date: Thu, 15 Oct 2009 11:35:11 +0200 > Sender: owner-freebsd-current@freebsd.org > > On Tue, Oct 13, 2009 at 18:12, Christian Schmidt wrote: > > On Mon, Oct 12, 2009 at 07:21, john hood wrote: > >> Christian Schmidt wrote: > > [...] > >>> I am seeing a strange issue with my Dell Inspiron 530 with 8.0 RC1-p1 > >>> at around 50-75% percent of all boots. It all boils down to GENERIC > >>> throwing the following: > >>> > >>> AP #1 (PHY #1) failed! > >>> panic y/n? [y] panic: bye-bye > >>> cpuid = 0 > > [...] > >> We have 3 of these machines. > >> > >> In my experience, keyboard activity triggers the problem.  If I boot the > >> machine without any keyboard presses/releases between the time the loader > >> starts the kernel and some time later, definitely by the time the USB > >> keyboard driver attaches, then I don't get this problem.  This includes any > >> key-up (and maybe key repeat) events you may generate after typing a key at > >> the boot menu, or after typing enter at the OK prompt, or pressing a key to > >> bypass the autoboot timeout that counts down by seconds. > >> > >> If you let the machine start from cold without touching the keyboard, what > >> happens? > > > > That is a very interesting point you are making. Indeed, it never > > occured to me that I am usually hammering down on F1 and 1 to boot > > faster (yeah yeah, I know ;-)). I let the machine boot through without > > that a couple of times and it seemed to have worked for about a 100% > > of those cases. I will keep testing but I think we have a hot > > contender. :-) > > > > Okay, after testing that for a couple of days I can confirm that it > never-ever happens when I leave the keyboard alone during the > boot-phase. As a workaround, I can live with not touching the > keyboard. Nethertheless, this seems to be a bug that deserves fixing, > isn't it? FWIW, I've seen this at least as far back as V5 and I think I have seen it on V4. I have no idea if it happened in V3. That was too long ago. IT would be nice to see this fixed, but I think we have all lived with it for a long time and most have either learned not to type stuff before the device probes have ended or they have never happened to trigger it. In my case, it seems like it is OK to type after the keyboard probe is completed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From rnoland at FreeBSD.org Thu Oct 15 19:04:00 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Oct 15 19:04:12 2009 Subject: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" In-Reply-To: <4AD710D6.70404@buchlovice.org> References: <4AD710D6.70404@buchlovice.org> Message-ID: <1255633430.2175.12.camel@balrog.2hip.net> On Thu, 2009-10-15 at 14:08 +0200, Radek Val??ek wrote: > Hi, > > I want to ask if there is something new in adding support to > gptzfsboot/zfsboot for reading gang-blocks? Ok, I can't figure out any way to test this... beyond the fact that it builds and doesn't break my currently working setup. Can you give this a try? It should still report if it finds gang blocks, but hopefully now will read them as well. robert. > From Sun's docs: > > Gang blocks > > When there is not enough contiguous space to write a complete block, the ZIO > pipeline will break the I/O up into smaller 'gang blocks' which can later be > assembled transparently to appear as complete blocks. > > Everything works fine for me, until I rewrite kernel/world after system > upgrade to latest one (releng_8). After this am I no longer able to boot > from zfs raidz1 pool with following messages: > > >/ ZFS: i/o error - all block copies unavailable > />/ ZFS: can't read MOS > />/ ZFS: unexpected object set type lld > />/ ZFS: unexpected object set type lld > />/ > />/ FreeBSD/i386 boot > />/ Default: z:/boot/kernel/kernel > />/ boot: > />/ ZFS: unexpected object set type lld > />/ > />/ FreeBSD/i386 boot > />/ Default: tank:/boot/kernel/kernel > />/ boot: > // > /I presume it's the same issue as talked in june-2009 current mailing > list > http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008589.html > > Any success in that matter? > > Thnx for answer. > > vaLin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: zfs-gang-block.patch Type: text/x-patch Size: 3137 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091015/178ac281/zfs-gang-block.bin From valin at buchlovice.org Thu Oct 15 19:37:35 2009 From: valin at buchlovice.org (=?ISO-8859-2?Q?Radek_Val=E1=B9ek?=) Date: Thu Oct 15 19:37:44 2009 Subject: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" In-Reply-To: <1255633430.2175.12.camel@balrog.2hip.net> References: <4AD710D6.70404@buchlovice.org> <1255633430.2175.12.camel@balrog.2hip.net> Message-ID: <4AD779FC.1070204@buchlovice.org> Robert Noland napsal(a): > On Thu, 2009-10-15 at 14:08 +0200, Radek Val??ek wrote: > >> Hi, >> >> I want to ask if there is something new in adding support to >> gptzfsboot/zfsboot for reading gang-blocks? >> > > Ok, I can't figure out any way to test this... beyond the fact that it > builds and doesn't break my currently working setup. Can you give this > a try? It should still report if it finds gang blocks, but hopefully > now will read them as well. > > robert. > > Big thanks for the patches Robert, I will definitely test them as soon as possible (tomorrow) and report the results immediately to list. I can repeat this issue probably at any time (up to cca 30 times tested with the same result), so don't bother about the broken booting, I'm prepared for it... vaLin >> From Sun's docs: >> >> Gang blocks >> >> When there is not enough contiguous space to write a complete block, the ZIO >> pipeline will break the I/O up into smaller 'gang blocks' which can later be >> assembled transparently to appear as complete blocks. >> >> Everything works fine for me, until I rewrite kernel/world after system >> upgrade to latest one (releng_8). After this am I no longer able to boot >> from zfs raidz1 pool with following messages: >> >> >/ ZFS: i/o error - all block copies unavailable >> />/ ZFS: can't read MOS >> />/ ZFS: unexpected object set type lld >> />/ ZFS: unexpected object set type lld >> />/ >> />/ FreeBSD/i386 boot >> />/ Default: z:/boot/kernel/kernel >> />/ boot: >> />/ ZFS: unexpected object set type lld >> />/ >> />/ FreeBSD/i386 boot >> />/ Default: tank:/boot/kernel/kernel >> />/ boot: >> // >> /I presume it's the same issue as talked in june-2009 current mailing >> list >> http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008589.html >> >> Any success in that matter? >> >> Thnx for answer. >> >> vaLin >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> From wblock at wonkity.com Thu Oct 15 19:57:49 2009 From: wblock at wonkity.com (Warren Block) Date: Thu Oct 15 19:57:55 2009 Subject: Why does hal think my USB devices are fixed? In-Reply-To: <20091015043422.6B42D1CC37@ptavv.es.net> References: <20091015043422.6B42D1CC37@ptavv.es.net> Message-ID: On Wed, 14 Oct 2009, Kevin Oberman wrote: >> Date: Wed, 14 Oct 2009 14:38:47 -0600 (MDT) >> From: Warren Block >> Then set some options for the card reader: >> >> 20-check-media.fdi : >> >> >> >> >> >> >> true >> true >> >> >> My extraneous line removed from the XML above... >> hal still sometimes doesn't notice new cards being connected, and the >> card reader's USB cable has to be reconnected. But at this point, it's >> at least as good as it was under 7-STABLE. > > Doing something to access the device seems to cause it to be "noticed". > I use 'fsck -p' on the device, but I suspect dd(1) or most anything else > that touches the device will do it. This Sandisk reader appears as two devices. The CompactFlash slot is one device (da0) and the SD/MMC/MS/clock radio slot is another (da1). Using the alternate slot seems to be when it loses track. For example, use an MMC card (da1s1), works fine. Load a CF, and /dev still only has da0, da1, and da1s1. No da1s1 appears. fsck -p /dev/da0 gives 'fsck: Could not determine filesystem type', and various other attempts like 'true > /dev/da0' don't wake it up. But 'usbconfig -u 3 -a 3 reset' works every time, and is less messy than pulling the cable. -Warren Block * Rapid City, South Dakota USA From grarpamp at gmail.com Thu Oct 15 19:48:01 2009 From: grarpamp at gmail.com (grarpamp) Date: Thu Oct 15 20:21:35 2009 Subject: vmstat -m/-z field parsing In-Reply-To: <200910150747.55101.jhb@freebsd.org> References: <200910150747.55101.jhb@freebsd.org> Message-ID: Sure, it's a workaround for vmstat -z, but not easy for vmstat -m which has no handy colons/commas to key from. Shouldn't stats be easy to parse in order to be useful to many rather than a test of a few users script fu ? :) So why not hunt up, check for potential new collisions to fix and change the strings in a lint run? See below... Thank you for pointing out that I had to do 'size * (used + free)', not just 'used'. And for the fu tips too :) I guess 'free' are not returned to the system for other uses then. Are there detailed docs on what all the fields mean in the various tools... vmstat -z/-m, systat -vm, netstat -m, top, ps. Most docs seem to just list the field names a command line switch will display, instead what sense to make of them. /me, grokking with wild abandon... # sys/vm/uma_core.c: args.name = "UMA Kegs"; args.name = "UMA Zones"; struct uma_bucket_zone bucket_zones[] = { { NULL, "16 Bucket", 16 }, { NULL, "32 Bucket", 32 }, { NULL, "64 Bucket", 64 }, { NULL, "128 Bucket", 128 }, { NULL, NULL, 0} }; # find -s sys -type f | xargs egrep MALLOC_DEFINE | sed -E 's/,[^,]{1,}$//' | egrep '".* .*"' sys/arm/xscale/pxa/pxa_smi.c:MALLOC_DEFINE(M_PXASMI, "PXA SMI" sys/arm/xscale/pxa/pxa_space.c:MALLOC_DEFINE(M_PXATAG, "PXA bus_space tags" sys/cam/cam_periph.c:MALLOC_DEFINE(M_CAMPERIPH, "CAM periph" sys/cam/cam_queue.c:MALLOC_DEFINE(M_CAMQ, "CAM queue" sys/cam/cam_queue.c:MALLOC_DEFINE(M_CAMDEVQ, "CAM dev queue" sys/cam/cam_queue.c:MALLOC_DEFINE(M_CAMCCBQ, "CAM ccb queue" sys/cam/cam_sim.c:MALLOC_DEFINE(M_CAMSIM, "CAM SIM" sys/cam/cam_xpt.c:MALLOC_DEFINE(M_CAMXPT, "CAM XPT" sys/cam/scsi/scsi_low.c:MALLOC_DEFINE(M_SCSILOW, "SCSI low" sys/cam/scsi/scsi_sa.c:MALLOC_DEFINE(M_SCSISA, "SCSI sa" sys/cam/scsi/scsi_ses.c:MALLOC_DEFINE(M_SCSISES, "SCSI SES" sys/cam/scsi/scsi_targ_bh.c:MALLOC_DEFINE(M_SCSIBH, "SCSI bh" sys/compat/linux/linux_futex.c:MALLOC_DEFINE(M_FUTEX_WP, "futex wp" sys/dev/ahci/ahci.c:MALLOC_DEFINE(M_AHCI, "AHCI driver" sys/dev/siis/siis.c:MALLOC_DEFINE(M_SIIS, "SIIS driver" sys/dev/sound/midi/midi.c:MALLOC_DEFINE(M_MIDI, "midi buffers" sys/fs/nfs/nfs_commonport.c:MALLOC_DEFINE(M_NEWNFSRVCACHE, "NFSD srvcache" sys/fs/nfs/nfs_commonport.c:MALLOC_DEFINE(M_NEWNFSDCLIENT, "NFSD V4client" sys/fs/nfs/nfs_commonport.c:MALLOC_DEFINE(M_NEWNFSDSTATE, "NFSD V4state", "NFSD V4 State (Openowner, Open, Lockowner sys/fs/nfs/nfs_commonport.c:MALLOC_DEFINE(M_NEWNFSDLOCK, "NFSD V4lock" sys/fs/nfs/nfs_commonport.c:MALLOC_DEFINE(M_NEWNFSDLOCKFILE, "NFSD lckfile" sys/fs/nfs/nfs_commonport.c:MALLOC_DEFINE(M_NEWNFSSTRING, "NFSD string" sys/fs/nfs/nfs_commonport.c:MALLOC_DEFINE(M_NEWNFSUSERGROUP, "NFSD usrgroup" sys/fs/nfs/nfs_commonport.c:MALLOC_DEFINE(M_NEWNFSDREQ, "NFS req" sys/fs/nfs/nfs_commonport.c:MALLOC_DEFINE(M_NEWNFSFH, "NFS fh" sys/fs/nfs/nfs_commonport.c:MALLOC_DEFINE(M_NEWNFSCLOWNER, "NFSCL owner" sys/fs/nfs/nfs_commonport.c:MALLOC_DEFINE(M_NEWNFSCLOPEN, "NFSCL open" sys/fs/nfs/nfs_commonport.c:MALLOC_DEFINE(M_NEWNFSCLDELEG, "NFSCL deleg" sys/fs/nfs/nfs_commonport.c:MALLOC_DEFINE(M_NEWNFSCLCLIENT, "NFSCL client" sys/fs/nfs/nfs_commonport.c:MALLOC_DEFINE(M_NEWNFSCLLOCKOWNER, "NFSCL lckown" sys/fs/nfs/nfs_commonport.c:MALLOC_DEFINE(M_NEWNFSCLLOCK, "NFSCL lck" sys/fs/tmpfs/tmpfs_vfsops.c:MALLOC_DEFINE(M_TMPFSMNT, "tmpfs mount" sys/fs/tmpfs/tmpfs_vfsops.c:MALLOC_DEFINE(M_TMPFSNAME, "tmpfs name" sys/fs/unionfs/union_subr.c:static MALLOC_DEFINE(M_UNIONFSHASH, "UNIONFS hash" sys/fs/unionfs/union_subr.c:MALLOC_DEFINE(M_UNIONFSNODE, "UNIONFS node" sys/fs/unionfs/union_subr.c:MALLOC_DEFINE(M_UNIONFSPATH, "UNIONFS path" sys/fs/unionfs/union_vfsops.c:static MALLOC_DEFINE(M_UNIONFSMNT, "UNIONFS mount" sys/geom/eli/g_eli.c:MALLOC_DEFINE(M_ELI, "eli data" sys/gnu/fs/xfs/FreeBSD/xfs_mountops.c:MALLOC_DEFINE(M_XFSNODE, "XFS node" sys/kern/kern_cons.c:static MALLOC_DEFINE(M_TTYCONS, "tty console" sys/kern/kern_fail.c:MALLOC_DEFINE(M_FAIL_POINT, "Fail Points" sys/kern/subr_bus.c:static MALLOC_DEFINE(M_BUS_SC, "bus-sc", "Bus data structures sys/nfsserver/nfs_fha.c:static MALLOC_DEFINE(M_NFS_FHA, "NFS FHA" # find -s sys -type f | xargs egrep uma_zcreate | sed 's/,.*$//' | egrep '".* .*"' sys/arm/arm/pmap.c: pvzone = uma_zcreate("PV ENTRY" sys/arm/arm/pmap.c: l2zone = uma_zcreate("L2 Table" sys/arm/arm/pmap.c: l2table_zone = uma_zcreate("L2 Table" sys/compat/ndis/subr_ntoskrnl.c: mdl_zone = uma_zcreate("Windows MDL" sys/compat/ndis/subr_ntoskrnl.c: iw_zone = uma_zcreate("Windows WorkItem" sys/dev/en/midway.c: sc->map_zone = uma_zcreate("en dma maps" sys/dev/en/midway.c: en_vcc_zone = uma_zcreate("EN vccs" sys/dev/fatm/if_fatm.c: sc->vcc_zone = uma_zcreate("FATM vccs" sys/dev/hatm/if_hatm.c: if ((sc->vcc_zone = uma_zcreate("HE vccs" sys/dev/iscsi/initiator/iscsi.c: printf("iscsi_initiator: uma_zcreate failed"); sys/dev/patm/if_patm_attach.c: if ((sc->vcc_zone = uma_zcreate("PATM vccs" sys/dev/patm/if_patm_attach.c: if ((sc->tx_mapzone = uma_zcreate("PATM tx maps" sys/fs/tmpfs/tmpfs_vfsops.c: tmp->tm_dirent_pool = uma_zcreate("TMPFS dirent" sys/fs/tmpfs/tmpfs_vfsops.c: tmp->tm_node_pool = uma_zcreate("TMPFS node" sys/fs/udf/udf_vfsops.c: udf_zone_node = uma_zcreate("UDF Node zone" sys/fs/udf/udf_vfsops.c: udf_zone_ds = uma_zcreate("UDF Dirstream zone" sys/ia64/ia64/pmap.c: pvzone = uma_zcreate("PV ENTRY" sys/ia64/ia64/pmap.c: ptezone = uma_zcreate("PT ENTRY" sys/kern/kern_umtx.c: umtx_pi_zone = uma_zcreate("umtx pi" sys/kern/vfs_cache.c: cache_zone_small = uma_zcreate("S VFS Cache" sys/kern/vfs_cache.c: cache_zone_large = uma_zcreate("L VFS Cache" sys/mips/mips/pmap.c: pvzone = uma_zcreate("PV ENTRY" sys/netgraph/netflow/netflow.c: priv->zone = uma_zcreate("NetFlow cache" sys/netgraph/ng_base.c: ng_qzone = uma_zcreate("NetGraph items" sys/netgraph/ng_base.c: ng_qdzone = uma_zcreate("NetGraph data items" sys/netinet/ipfw/ip_fw2.c: ipfw_dyn_rule_zone = uma_zcreate("IPFW dynamic rule" sys/powerpc/aim/mmu_oea.c: moea_upvo_zone = uma_zcreate("UPVO entry" sys/powerpc/aim/mmu_oea.c: moea_mpvo_zone = uma_zcreate("MPVO entry" sys/powerpc/aim/mmu_oea64.c: moea64_upvo_zone = uma_zcreate("UPVO entry" sys/powerpc/aim/mmu_oea64.c: moea64_mpvo_zone = uma_zcreate("MPVO entry" sys/powerpc/booke/pmap.c: pvzone = uma_zcreate("PV ENTRY" sys/security/mac/mac_label.c: zone_label = uma_zcreate("MAC labels" sys/sun4v/sun4v/pmap.c: pvzone = uma_zcreate("PV ENTRY" sys/ufs/ffs/ffs_vfsops.c: uma_inode = uma_zcreate("FFS inode" sys/ufs/ffs/ffs_vfsops.c: uma_ufs1 = uma_zcreate("FFS1 dinode" sys/ufs/ffs/ffs_vfsops.c: uma_ufs2 = uma_zcreate("FFS2 dinode" sys/vm/device_pager.c: fakepg_zone = uma_zcreate("DP fakepg" sys/vm/sg_pager.c: fakepg_zone = uma_zcreate("SG fakepg" sys/vm/uma_core.c: slabzone = uma_zcreate("UMA Slabs" sys/vm/uma_core.c: slabrefzone = uma_zcreate("UMA RCntSlabs" sys/vm/uma_core.c: hashzone = uma_zcreate("UMA Hash" sys/vm/vm_map.c: kmapentzone = uma_zcreate("KMAP ENTRY" sys/vm/vm_map.c: mapentzone = uma_zcreate("MAP ENTRY" sys/vm/vm_object.c: obj_zone = uma_zcreate("VM OBJECT" From tinderbox at freebsd.org Thu Oct 15 20:24:44 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Oct 15 20:24:51 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <200910152024.n9FKOgF8002766@freebsd-current.sentex.ca> TB --- 2009-10-15 19:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-15 19:00:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-10-15 19:00:00 - cleaning the object tree TB --- 2009-10-15 19:00:20 - cvsupping the source tree TB --- 2009-10-15 19:00:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-10-15 19:00:52 - building world TB --- 2009-10-15 19:00:52 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-15 19:00:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-15 19:00:52 - TARGET=pc98 TB --- 2009-10-15 19:00:52 - TARGET_ARCH=i386 TB --- 2009-10-15 19:00:52 - TZ=UTC TB --- 2009-10-15 19:00:52 - __MAKE_CONF=/dev/null TB --- 2009-10-15 19:00:52 - cd /src TB --- 2009-10-15 19:00:52 - /usr/bin/make -B buildworld >>> World build started on Thu Oct 15 19:00:52 UTC 2009 >>> 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 Thu Oct 15 19:58:52 UTC 2009 TB --- 2009-10-15 19:58:52 - generating LINT kernel config TB --- 2009-10-15 19:58:52 - cd /src/sys/pc98/conf TB --- 2009-10-15 19:58:52 - /usr/bin/make -B LINT TB --- 2009-10-15 19:58:52 - building LINT kernel TB --- 2009-10-15 19:58:52 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-15 19:58:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-15 19:58:52 - TARGET=pc98 TB --- 2009-10-15 19:58:52 - TARGET_ARCH=i386 TB --- 2009-10-15 19:58:52 - TZ=UTC TB --- 2009-10-15 19:58:52 - __MAKE_CONF=/dev/null TB --- 2009-10-15 19:58:52 - cd /src TB --- 2009-10-15 19:58:52 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Oct 15 19:58:52 UTC 2009 >>> 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 >>> Kernel build for LINT completed on Thu Oct 15 20:19:49 UTC 2009 TB --- 2009-10-15 20:19:49 - building GENERIC kernel TB --- 2009-10-15 20:19:49 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-15 20:19:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-15 20:19:49 - TARGET=pc98 TB --- 2009-10-15 20:19:49 - TARGET_ARCH=i386 TB --- 2009-10-15 20:19:49 - TZ=UTC TB --- 2009-10-15 20:19:49 - __MAKE_CONF=/dev/null TB --- 2009-10-15 20:19:49 - cd /src TB --- 2009-10-15 20:19:49 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Thu Oct 15 20:19:49 UTC 2009 >>> 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 GENERIC cc -c -O -pipe -std=c99 -g -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug nexus.o(.text+0x2d3): In function `nexus_describe_intr': /src/sys/i386/i386/nexus.c:538: undefined reference to `intr_describe' *** Error code 1 Stop in /obj/pc98/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-15 20:24:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-15 20:24:42 - ERROR: failed to build GENERIC kernel TB --- 2009-10-15 20:24:42 - 3851.48 user 751.77 system 5082.26 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From glen.j.barber at gmail.com Fri Oct 16 01:24:54 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Fri Oct 16 01:25:01 2009 Subject: if_rum dies on transmit... In-Reply-To: <20091015172914.GF67082@weongyo> References: <86051.1254232666@critter.freebsd.dk> <20091013174201.GC67082@weongyo> <86iqei7tgq.fsf@jodie.vectavision.com> <20091014201059.GE67082@weongyo> <20091014230715.E96894@ury.york.ac.uk> <20091015172914.GF67082@weongyo> Message-ID: <4ad871310910151824q13842e1en53a3a682f85c1dd8@mail.gmail.com> Hello, On Thu, Oct 15, 2009 at 1:29 PM, Weongyo Jeong wrote: [snip] >> Do you know if this patch is likely to fix the panics seen with rum(4) or >> is this likely to only fix the TX hangs? > > AFAIK this patch only fixes TX hangs. ?I didn't see PRs yet related with > the panics but I think it could affect user's panic a little bit. > I applied this patch to -STABLE and it seems to have fixed my panic problems with rum(4). So far, 1+ hour uptime on AC power and 20+ minutes on battery, which is unusual. rum(4) was one of the potential culprits I was trying to isolate. Thank you! FreeBSD pegasus 8.0-RC1 FreeBSD 8.0-RC1 #8 r198161M: Thu Oct 15 20:09:20 EDT 2009 root@pegasus:/usr/obj/usr/src/sys/PEGASUS i386 -- Glen Barber From tinderbox at freebsd.org Fri Oct 16 03:44:25 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Oct 16 03:44:42 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <200910160344.n9G3iOTZ059369@freebsd-current.sentex.ca> TB --- 2009-10-16 02:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-16 02:20:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-10-16 02:20:00 - cleaning the object tree TB --- 2009-10-16 02:20:24 - cvsupping the source tree TB --- 2009-10-16 02:20:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-10-16 02:20:50 - building world TB --- 2009-10-16 02:20:50 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-16 02:20:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-16 02:20:50 - TARGET=pc98 TB --- 2009-10-16 02:20:50 - TARGET_ARCH=i386 TB --- 2009-10-16 02:20:50 - TZ=UTC TB --- 2009-10-16 02:20:50 - __MAKE_CONF=/dev/null TB --- 2009-10-16 02:20:50 - cd /src TB --- 2009-10-16 02:20:50 - /usr/bin/make -B buildworld >>> World build started on Fri Oct 16 02:20:50 UTC 2009 >>> 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 Fri Oct 16 03:18:45 UTC 2009 TB --- 2009-10-16 03:18:45 - generating LINT kernel config TB --- 2009-10-16 03:18:45 - cd /src/sys/pc98/conf TB --- 2009-10-16 03:18:45 - /usr/bin/make -B LINT TB --- 2009-10-16 03:18:45 - building LINT kernel TB --- 2009-10-16 03:18:45 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-16 03:18:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-16 03:18:45 - TARGET=pc98 TB --- 2009-10-16 03:18:45 - TARGET_ARCH=i386 TB --- 2009-10-16 03:18:45 - TZ=UTC TB --- 2009-10-16 03:18:45 - __MAKE_CONF=/dev/null TB --- 2009-10-16 03:18:45 - cd /src TB --- 2009-10-16 03:18:45 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Oct 16 03:18:45 UTC 2009 >>> 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 >>> Kernel build for LINT completed on Fri Oct 16 03:39:28 UTC 2009 TB --- 2009-10-16 03:39:28 - building GENERIC kernel TB --- 2009-10-16 03:39:28 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-16 03:39:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-16 03:39:28 - TARGET=pc98 TB --- 2009-10-16 03:39:28 - TARGET_ARCH=i386 TB --- 2009-10-16 03:39:28 - TZ=UTC TB --- 2009-10-16 03:39:28 - __MAKE_CONF=/dev/null TB --- 2009-10-16 03:39:28 - cd /src TB --- 2009-10-16 03:39:28 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Oct 16 03:39:28 UTC 2009 >>> 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 GENERIC cc -c -O -pipe -std=c99 -g -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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug nexus.o(.text+0x2d3): In function `nexus_describe_intr': /src/sys/i386/i386/nexus.c:538: undefined reference to `intr_describe' *** Error code 1 Stop in /obj/pc98/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-16 03:44:24 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-16 03:44:24 - ERROR: failed to build GENERIC kernel TB --- 2009-10-16 03:44:24 - 3846.02 user 756.86 system 5063.27 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From avg at icyb.net.ua Fri Oct 16 08:28:21 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Oct 16 08:28:28 2009 Subject: zfs boot vs loader In-Reply-To: <20091014062827.GC1696@garage.freebsd.pl> References: <4AD3220B.5030502@icyb.net.ua> <86ws30ikfw.fsf@gmail.com> <4AD45A8D.4070605@icyb.net.ua> <20091014062827.GC1696@garage.freebsd.pl> Message-ID: <4AD82E91.3030703@icyb.net.ua> on 14/10/2009 09:28 Pawel Jakub Dawidek said the following: > On Tue, Oct 13, 2009 at 01:46:37PM +0300, Andriy Gapon wrote: >> Thanks to all who replied! >> I think that I figured it out with your help. >> >> 'unload' does indeed unload zpool.cache and the latter is needed for proper zfs >> root mounting. >> 'boot /other/kernel' executes some loader scripts and zpool.cache gets loaded in >> this case (because of the settings in defaults/loader.conf). >> When doing manual 'load xxx' and then just 'boot' no loader scripts are executed >> and zpool.cache does not get loaded. In this case one has to load it manually >> using the suggested 'load -t xxx' approach. > > Could you repeat what you were doing but with vfs.zfs.debug set to 1 > from the loader? You should see some messages about missing file, maybe > we should do them visible always and not after increasing debug level? Yes, I tried this and got the following message: spa_config_load:92[1]: Cannot open /boot/zfs/zpool.cache Perhaps it's a good idea indeed to be more verbose about this. -- Andriy Gapon From avg at icyb.net.ua Fri Oct 16 08:32:18 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Oct 16 08:32:24 2009 Subject: panic when mounting device >= 2 times In-Reply-To: <20091014204657.GB1727@garage.freebsd.pl> References: <4AD5BD00.4050700@icyb.net.ua> <20091014204657.GB1727@garage.freebsd.pl> Message-ID: <4AD82F80.2050302@icyb.net.ua> on 14/10/2009 23:46 Pawel Jakub Dawidek said the following: > I've this patch that is suppose to fix it: > > http://people.freebsd.org/~pjd/patches/geom_vfs.c.patch > > But AFAIR its not complete. I think it is still possible to remount one > of the read-only mounts to read-write. > > Another possibility that comes to my mind is to keep list/array of > consumers in bo_private instead of using one consumer only. This would > be better in terms of access management. This looks very good for at least preventing the most common accidents. I've been thinking about something like creating a cloned vnode for the device vnode and giving a private copy to each filesystem. But I currently lack a lot knowledge in this area, so I can't even say if it could be feasible, let alone implement it. -- Andriy Gapon From kostikbel at gmail.com Fri Oct 16 08:38:42 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Oct 16 08:38:50 2009 Subject: panic when mounting device >= 2 times In-Reply-To: <4AD82F80.2050302@icyb.net.ua> References: <4AD5BD00.4050700@icyb.net.ua> <20091014204657.GB1727@garage.freebsd.pl> <4AD82F80.2050302@icyb.net.ua> Message-ID: <20091016083808.GO27077@deviant.kiev.zoral.com.ua> On Fri, Oct 16, 2009 at 11:32:00AM +0300, Andriy Gapon wrote: > on 14/10/2009 23:46 Pawel Jakub Dawidek said the following: > > I've this patch that is suppose to fix it: > > > > http://people.freebsd.org/~pjd/patches/geom_vfs.c.patch > > > > But AFAIR its not complete. I think it is still possible to remount one > > of the read-only mounts to read-write. > > > > Another possibility that comes to my mind is to keep list/array of > > consumers in bo_private instead of using one consumer only. This would > > be better in terms of access management. > > This looks very good for at least preventing the most common accidents. > I've been thinking about something like creating a cloned vnode for the device > vnode and giving a private copy to each filesystem. But I currently lack a lot > knowledge in this area, so I can't even say if it could be feasible, let alone > implement it. I suspect this is pretty much bad idea. The reason is that buffer list is managed by buffer object that has 1:1 correspondence with the vnode. You will end up with aliased buffers. Actually, this could happen without the proposed change as well, I believe. It is enough to mount devfs several times and then use different devfs vnodes for the same device. But since people usually mount filesystems using /dev, this does not happen in practice. For multiple ro mounts to work, we need to find a way to push the buffer object to cdev. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091016/161aab15/attachment.pgp From schmidt_chr at gmx.net Fri Oct 16 16:10:47 2009 From: schmidt_chr at gmx.net (Christian Schmidt) Date: Fri Oct 16 16:10:54 2009 Subject: Boot issues with a Dell Inspiron 530 and 8.0 RC1 In-Reply-To: <20091015183338.37FBB1CC44@ptavv.es.net> References: <309b65830910150235w59857e83r23887193c36561f0@mail.gmail.com> <20091015183338.37FBB1CC44@ptavv.es.net> Message-ID: <309b65830910160910v5081b098tfec440db48bb08a8@mail.gmail.com> On Thu, Oct 15, 2009 at 20:33, Kevin Oberman wrote: >> From: Christian Schmidt >> Date: Thu, 15 Oct 2009 11:35:11 +0200 >> Sender: owner-freebsd-current@freebsd.org >> >> On Tue, Oct 13, 2009 at 18:12, Christian Schmidt wrote: >> > On Mon, Oct 12, 2009 at 07:21, john hood wrote: >> >> Christian Schmidt wrote: >> > [...] >> >>> I am seeing a strange issue with my Dell Inspiron 530 with 8.0 RC1-p1 >> >>> at around 50-75% percent of all boots. It all boils down to GENERIC >> >>> throwing the following: >> >>> >> >>> AP #1 (PHY #1) failed! >> >>> panic y/n? [y] panic: bye-bye >> >>> cpuid = 0 >> > [...] >> >> We have 3 of these machines. >> >> >> >> In my experience, keyboard activity triggers the problem. ?If I boot the >> >> machine without any keyboard presses/releases between the time the loader >> >> starts the kernel and some time later, definitely by the time the USB >> >> keyboard driver attaches, then I don't get this problem. ?This includes any >> >> key-up (and maybe key repeat) events you may generate after typing a key at >> >> the boot menu, or after typing enter at the OK prompt, or pressing a key to >> >> bypass the autoboot timeout that counts down by seconds. >> >> >> >> If you let the machine start from cold without touching the keyboard, what >> >> happens? >> > >> > That is a very interesting point you are making. Indeed, it never >> > occured to me that I am usually hammering down on F1 and 1 to boot >> > faster (yeah yeah, I know ;-)). I let the machine boot through without >> > that a couple of times and it seemed to have worked for about a 100% >> > of those cases. I will keep testing but I think we have a hot >> > contender. :-) >> > >> >> Okay, after testing that for a couple of days I can confirm that it >> never-ever happens when I leave the keyboard alone during the >> boot-phase. As a workaround, I can live with not touching the >> keyboard. Nethertheless, this seems to be a bug that deserves fixing, >> isn't it? > > FWIW, I've seen this at least as far back as V5 and I think I have seen > it on V4. I have no idea if it happened in V3. That was too long ago. > > IT would be nice to see this fixed, but I think we have all lived with > it for a long time and most have either learned not to type stuff before > the device probes have ended or they have never happened to trigger it. > > In my case, it seems like it is OK to type after the keyboard probe is > completed. Okay, I'll take that as the closing statement. :-) Now that I know what the problem is I can just work around it. Thanks for the useful hints! Cheers, Christian From tinderbox at freebsd.org Fri Oct 16 16:55:46 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Oct 16 16:55:59 2009 Subject: [head tinderbox] failure on i386/i386 Message-ID: <200910161655.n9GGtjuI094898@freebsd-current.sentex.ca> TB --- 2009-10-16 16:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-16 16:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2009-10-16 16:20:00 - cleaning the object tree TB --- 2009-10-16 16:20:26 - cvsupping the source tree TB --- 2009-10-16 16:20:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2009-10-16 16:55:45 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2009-10-16 16:55:45 - ERROR: unable to cvsup the source tree TB --- 2009-10-16 16:55:45 - 0.80 user 11.19 system 2145.43 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From tinderbox at freebsd.org Fri Oct 16 16:57:52 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Oct 16 16:59:05 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <200910161657.n9GGvpqG094906@freebsd-current.sentex.ca> TB --- 2009-10-16 16:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-16 16:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-10-16 16:20:00 - cleaning the object tree TB --- 2009-10-16 16:20:28 - cvsupping the source tree TB --- 2009-10-16 16:20:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-10-16 16:57:51 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2009-10-16 16:57:51 - ERROR: unable to cvsup the source tree TB --- 2009-10-16 16:57:51 - 0.84 user 12.70 system 2271.34 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From rwatson at FreeBSD.org Fri Oct 16 17:09:31 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Oct 16 17:09:38 2009 Subject: dtrace profile timers still unstable? Message-ID: In the past, I've had little luck using the DTrace profile timers on FreeBSD for much without crashes, and this morning was no different. I attempted to use the following(ish) script: profile-1ms { @data[stack()] = count(); } The result was: spin lock 0x849747d8 (cyclic cpu) held by 0x85442b40 (tid 100539) too long panic: spin lock held too long 0 doadump () at pcpu.h:246 #1 0x8089b5bf in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0x8089b8a2 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0x8088afaf in _mtx_lock_spin_failed (m=0x0) at /usr/src/sys/kern/kern_mutex.c:490 #4 0x8088b035 in _mtx_lock_spin (m=0x849747d8, tid=2220091648, opts=0, file=0x8a717a45 "/usr/src/sys/modules/cyclic/../../cddl/dev/cyclic/cyclic.c", line=574) at /usr/src/sys/kern/kern_mutex.c:526 #5 0x8088b7d1 in _mtx_lock_spin_flags (m=0x849747d8, opts=0, file=0x8a717a45 "/usr/src/sys/modules/cyclic/../../cddl/dev/cyclic/cyclic.c", line=574) at /usr/src/sys/kern/kern_mutex.c:246 #6 0x8a716f97 in cyclic_clock () from /boot/kernel/cyclic.ko #7 0x80bce876 in lapic_handle_timer (frame=0x842c6c34) at /usr/src/sys/i386/i386/local_apic.c:777 #8 0x80bc61cf in Xtimerint () at apic_vector.s:108 #9 0x80bba455 in acpi_cpu_c1 () at /usr/src/sys/i386/acpica/acpi_machdep.c:554 #10 0x804ff24c in acpi_cpu_idle () at /usr/src/sys/dev/acpica/acpi_cpu.c:921 #11 0x80bcff2b in cpu_idle_acpi (busy=1) at /usr/src/sys/i386/i386/machdep.c:1236 #12 0x80bd18db in cpu_idle (busy=1) at /usr/src/sys/i386/i386/machdep.c:1324 #13 0x808bf81e in sched_idletd (dummy=0x0) at /usr/src/sys/kern/sched_ule.c:2562 In the past, I've had similar experiences, although possibly different panics. I wonder if we should just disable the profile provider in 8.0 to prevent similar footshooting by others? Or perhaps someone with some dtrace internals interest could investigate? (I've seen panics with it pretty deterministically on i386 and amd64) Robert N M Watson Computer Laboratory University of Cambridge From oliver at akephalos.de Fri Oct 16 23:40:34 2009 From: oliver at akephalos.de (O.Herold) Date: Fri Oct 16 23:45:47 2009 Subject: if_rum dies on transmit... Message-ID: <79B5A43C-06EB-4F91-ADF9-D4D0AAFBF992@akephalos.de> Thanks, works like a charm. I could test it for several hours while downloading lots of packages on two different machines (i386 & AMD64). Cheers, Oliver Herold pro bono publico From lists at mawer.org Sat Oct 17 08:26:21 2009 From: lists at mawer.org (Antony Mawer) Date: Sat Oct 17 08:26:27 2009 Subject: 8.0rc1 not recognizing partitions on EPIA SN In-Reply-To: <200910131644.04358.john@baldwin.cx> References: <4ACE6D84.3000209@gmail.com> <4ACE833A.3030506@uffner.com> <4ACE9DFD.3010207@gmail.com> <200910131644.04358.john@baldwin.cx> Message-ID: On Wed, Oct 14, 2009 at 7:44 AM, John Baldwin wrote: > On Thursday 08 October 2009 10:20:45 pm David Ehrmann wrote: >> Tom Uffner wrote: >> > David Ehrmann wrote: >> >> First, I tried to upgrade the normal way. ?I built my own kernel and >> >> installed it, but when I tried to boot it, I got a mountroot> >> >> prompt. ?When I printed the devices, instead of seeing ad0s1a and >> >> friends, I saw ad0a and ad0d (just those two for ad0). ?I was still >> >> able to use the old (7.1) kernel fine. ?Thinking it was something to >> >> do with the upgrade, I tried to do a reinstall. ?I chose the default >> >> options, but once it got to the "last chance..." screen, this happened: >> >> >> >> Unable to find device node for /dev/ad0s1b in /dev! >> >> The creation of filesystems will be aborted. >> > >> > this is becoming an FAQ for 8.0 >> > >> > the short answer is "dangerously dedicated" partitions are not supported >> > by the 8.0 installer. back up your data. zero the MBR & partition table >> > with dd, and re-slice & partition your disk. after the install, restore >> > from your backups. >> > >> > search the freebsd-current archives for full details. >> dd did the trick. >> >> I understand why this was done, but at the same time, upgrading is now >> impractical for some users, and what looks like a fresh installation >> (repartitioned, resliced) can even fail. ?Is there a change that could >> be made to the partitioning process that would fix this? > > E-mail marcel@. Am I correct in reading this as saying that -any- system which was setup as dangerously dedicated will be unbootable under 8.0, and the only way to fix is to basically repartition and reinstall...? If so ... !!! --Antony From des at des.no Sat Oct 17 15:36:40 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sat Oct 17 15:36:46 2009 Subject: 8.0rc1 not recognizing partitions on EPIA SN In-Reply-To: (Antony Mawer's message of "Sat, 17 Oct 2009 19:26:19 +1100") References: <4ACE6D84.3000209@gmail.com> <4ACE833A.3030506@uffner.com> <4ACE9DFD.3010207@gmail.com> <200910131644.04358.john@baldwin.cx> Message-ID: <86ljja3ud5.fsf@ds4.des.no> Antony Mawer writes: > Am I correct in reading this as saying that -any- system which was > setup as dangerously dedicated will be unbootable under 8.0, and the > only way to fix is to basically repartition and reinstall...? If so > ... !!! You brought it upon yourself by setting it up that way in the first place. It's called *dangerously* dedicated for a reason. DES -- Dag-Erling Sm?rgrav - des@des.no From freebsd at levsha.org.ua Sat Oct 17 17:21:32 2009 From: freebsd at levsha.org.ua (Mykola Dzham) Date: Sat Oct 17 17:21:39 2009 Subject: page fault in igb driver on 8.0-RC1 Message-ID: <20091017170351.GZ29771@expo.ukrweb.net> Hi! On hight network load system panics: GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8025e4a5 stack pointer = 0x28:0xffffff87312f3a60 frame pointer = 0x28:0xffffff87312f3a80 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 (igb0 taskq) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff80185baa = db_trace_self_wrapper+0x2a panic() at 0xffffffff8020e992 = panic+0x182 trap_fatal() at 0xffffffff8040eefd = trap_fatal+0x2ad trap_pfault() at 0xffffffff8040f27d = trap_pfault+0x22d trap() at 0xffffffff8040fbff = trap+0x3cf calltrap() at 0xffffffff803f6e13 = calltrap+0x8 --- trap 0xc, rip = 0xffffffff8025e4a5, rsp = 0xffffff87312f3a60, rbp = 0xffffff87312f3a80 --- mb_free_ext() at 0xffffffff8025e4a5 = mb_free_ext+0x15 igb_get_buf() at 0xffffffff80a3a6e5 = igb_get_buf+0x2e5 igb_rxeof() at 0xffffffff80a3abd5 = igb_rxeof+0x425 igb_handle_rx() at 0xffffffff80a3b14b = igb_handle_rx+0x3b taskqueue_run() at 0xffffffff80243ec1 = taskqueue_run+0x91 taskqueue_thread_loop() at 0xffffffff8024404f = taskqueue_thread_loop+0x3f fork_exit() at 0xffffffff801ea9b2 = fork_exit+0x112 fork_trampoline() at 0xffffffff803f72ee = fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff87312f3d30, rbp = 0 --- Uptime: 1h46m18s Cannot dump. Device not defined or unavailable. System is amd64 8.0-RC1 r197974 Tue Oct 13 23:00:17 EEST 2009 dmesg part about network cards: found-> vendor=0x8086, dev=0x10a7, revid=0x02 domain=0, bus=8, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=56 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 10 messages in map 0x1c pci0:8:0:0: reprobing on driver added igb0: port 0x2000-0x201f mem 0xd8020000-0xd803ffff,0xd8000000-0xd801ffff,0xd8080000-0xd8083fff irq 56 at device 0.0 on pci8 igb0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8020000 igb0: Reserved 0x4000 bytes for rid 0x1c type 3 at 0xd8080000 igb0: attempting to allocate 3 MSI-X vectors (10 supported) msi: routing MSI-X IRQ 256 to local APIC 7 vector 48 msi: routing MSI-X IRQ 257 to local APIC 0 vector 48 msi: routing MSI-X IRQ 258 to local APIC 1 vector 49 igb0: using IRQs 256-258 for MSI-X igb0: Using MSIX interrupts with 3 vectors igb0: [MPSAFE] igb0: [ITHREAD] igb0: [MPSAFE] igb0: [ITHREAD] igb0: [MPSAFE] igb0: [ITHREAD] igb0: bpf attached igb0: Ethernet address: 00:30:48:c6:c4:54 found-> vendor=0x8086, dev=0x10a7, revid=0x02 domain=0, bus=8, slot=0, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=70 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 10 messages in map 0x1c pci0:8:0:1: reprobing on driver added igb1: port 0x2020-0x203f mem 0xd8060000-0xd807ffff,0xd8040000-0xd805ffff,0xd8084000-0xd8087fff irq 70 at device 0.1 on pci8 igb1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8060000 igb1: Reserved 0x4000 bytes for rid 0x1c type 3 at 0xd8084000 igb1: attempting to allocate 3 MSI-X vectors (10 supported) msi: routing MSI-X IRQ 259 to local APIC 2 vector 49 msi: routing MSI-X IRQ 260 to local APIC 3 vector 49 msi: routing MSI-X IRQ 261 to local APIC 4 vector 49 igb1: using IRQs 259-261 for MSI-X igb1: Using MSIX interrupts with 3 vectors igb1: [MPSAFE] igb1: [ITHREAD] igb1: [MPSAFE] igb1: [ITHREAD] igb1: [MPSAFE] igb1: [ITHREAD] igb1: bpf attached igb1: Ethernet address: 00:30:48:c6:c4:55 I have no kernel dump (dump device disabled by default now), but i can reproduce problem with enabled kernel dump and with debug kernel if required. -- LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 From oliver at namp.de Sat Oct 17 21:00:44 2009 From: oliver at namp.de (Oliver Fakler) Date: Sat Oct 17 21:00:59 2009 Subject: 8.0 RC1 freeze while WPA ath0 Message-ID: <61410.1255813638@namp.de> Hi there, i have a problem on 8.0 RC1 while connecting to wlan with wpa Problem occurs while testing the wpa connection manual: bodo# wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS Trying to associate with 00:23:69:a2:c0:fb (SSID='Linksys' freq=2412 MHz) my wpa_supplicat.conf: network={ ssid="Linksys" psk="xxxxx" } some ath0 informations: Oct 17 22:30:37 bodo kernel: ath0: mem 0xfaef0000-0xfaefffff irq 16 at device 5.0 on pci1 Oct 17 22:30:37 bodo kernel: ath0: [ITHREAD] Oct 17 22:30:37 bodo kernel: ath0: AR5416 mac 13.10 RF2133 phy 8.1 maybe somebody have an idea? cheers Oliver From pyunyh at gmail.com Sat Oct 17 22:23:21 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sat Oct 17 22:23:27 2009 Subject: page fault in igb driver on 8.0-RC1 In-Reply-To: <20091017170351.GZ29771@expo.ukrweb.net> References: <20091017170351.GZ29771@expo.ukrweb.net> Message-ID: <20091017222314.GB19204@michelle.cdnetworks.com> On Sat, Oct 17, 2009 at 08:03:51PM +0300, Mykola Dzham wrote: > Hi! > On hight network load system panics: > > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > I believe this type of message should not be in fast path and it should be rate-limited. > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 02 > fault virtual address = 0x0 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff8025e4a5 > stack pointer = 0x28:0xffffff87312f3a60 > frame pointer = 0x28:0xffffff87312f3a80 > 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 (igb0 taskq) > trap number = 12 > panic: page fault > cpuid = 2 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff80185baa = > db_trace_self_wrapper+0x2a > panic() at 0xffffffff8020e992 = panic+0x182 > trap_fatal() at 0xffffffff8040eefd = trap_fatal+0x2ad > trap_pfault() at 0xffffffff8040f27d = trap_pfault+0x22d > trap() at 0xffffffff8040fbff = trap+0x3cf > calltrap() at 0xffffffff803f6e13 = calltrap+0x8 > --- trap 0xc, rip = 0xffffffff8025e4a5, rsp = 0xffffff87312f3a60, rbp = > 0xffffff87312f3a80 --- > mb_free_ext() at 0xffffffff8025e4a5 = mb_free_ext+0x15 > igb_get_buf() at 0xffffffff80a3a6e5 = igb_get_buf+0x2e5 > igb_rxeof() at 0xffffffff80a3abd5 = igb_rxeof+0x425 > igb_handle_rx() at 0xffffffff80a3b14b = igb_handle_rx+0x3b > taskqueue_run() at 0xffffffff80243ec1 = taskqueue_run+0x91 > taskqueue_thread_loop() at 0xffffffff8024404f = > taskqueue_thread_loop+0x3f > fork_exit() at 0xffffffff801ea9b2 = fork_exit+0x112 > fork_trampoline() at 0xffffffff803f72ee = fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff87312f3d30, rbp = 0 --- > Uptime: 1h46m18s > Cannot dump. Device not defined or unavailable. > > System is amd64 8.0-RC1 r197974 Tue Oct 13 23:00:17 EEST 2009 > Hmm, I remember some user already reported similar issues for igb(4). At that time I briefly looked over possible code paths for the issue and saw some questionable handling of mbufs under resource shortage cases and I sent my concerns to Jack but it seems he lost the mail. Unfortunately I don't have igb(4) hardwares so I guess it's somewhat hard for me to fix the issue but I'll try to read the code again if time permit. From wblock at wonkity.com Sat Oct 17 23:05:08 2009 From: wblock at wonkity.com (Warren Block) Date: Sat Oct 17 23:05:15 2009 Subject: Restarting devd Message-ID: Immediately after boot, devd restart fails: # /etc/rc.d/devd restart Stopping devd. Starting devd. devd: devd already running, pid: 398 /etc/rc.d/devd: WARNING: failed to start devd And it's right, devd is not running. Remove the stale pidfile /var/run/devd.pid, and '/etc/rc.d/devd start' goes fine. In fact, after that initial pidfile is removed, restarts are no longer a problem: # /etc/rc.d/devd restart Stopping devd. Starting devd. So why is it a problem with the first run of devd, but not afterwards? Something with /etc/rc.d/devd, or maybe something more general with /etc/rc.subr? FreeBSD lightning 8.0-RC1 FreeBSD 8.0-RC1 #6: Wed Oct 14 18:44:38 MDT 2009 root@lightning:/usr/obj/usr/src/sys/LIGHTNING i386 -Warren Block * Rapid City, South Dakota USA From dnebdal at gmail.com Sun Oct 18 00:05:43 2009 From: dnebdal at gmail.com (Daniel Nebdal) Date: Sun Oct 18 00:05:50 2009 Subject: 8.0rc1 not recognizing partitions on EPIA SN In-Reply-To: <86ljja3ud5.fsf@ds4.des.no> References: <4ACE6D84.3000209@gmail.com> <4ACE833A.3030506@uffner.com> <4ACE9DFD.3010207@gmail.com> <200910131644.04358.john@baldwin.cx> <86ljja3ud5.fsf@ds4.des.no> Message-ID: 2009/10/17 Dag-Erling Sm?rgrav : > Antony Mawer writes: >> Am I correct in reading this as saying that -any- system which was >> setup as dangerously dedicated will be unbootable under 8.0, and the >> only way to fix is to basically repartition and reinstall...? If so >> ... !!! > > You brought it upon yourself by setting it up that way in the first > place. ?It's called *dangerously* dedicated for a reason. > Indeed, though I was under the impression that the reason was "nothing else will understand this", not "we might not support this in the future". The definition from the relevant handbook section seems relevant: > *(dangerously) dedicated mode: Formatting a disk with no slice table. > This makes the process of adding disks easier, however non-FreeBSD > operating systems may not accept the disk. > Oppose compatibility mode. Then again, the same handbook page (http://www.freebsd.org/doc/en/articles/formatting-media/index.html) does warn against "interoperability with future installations", which could be read as a warning against these problems. -- Daniel Nebdal From weongyo.jeong at gmail.com Sun Oct 18 00:37:43 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Sun Oct 18 00:37:50 2009 Subject: urtw(4) feedback. In-Reply-To: References: Message-ID: <20091018003823.GH67082@weongyo> On Wed, Oct 07, 2009 at 02:23:10PM +0200, Ian Freislich wrote: > Hi > > FWIW, the manual can be updated to include support for the Linksys > WG111v3 adapter. Mine detects as follows: > > ugen4.3: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON > > urtw0: on usbus4 > urtw0: rtl8187b rf rtl8225z2 hwrev e > > Opening it up confirms the presence of a RTL8187B. > > However throughput is very poor, I haven't been able to get more > than about 130kB/s and pings seem to be timed every 1.5 seconds. I'd committed a major change of urtw(4) for RTL8187B devices; r198194. Could you please test with it? I hope TX works than before. regards, Weongyo Jeong From julian at elischer.org Sun Oct 18 01:25:11 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Oct 18 01:25:18 2009 Subject: 8.0rc1 not recognizing partitions on EPIA SN In-Reply-To: <86ljja3ud5.fsf@ds4.des.no> References: <4ACE6D84.3000209@gmail.com> <4ACE833A.3030506@uffner.com> <4ACE9DFD.3010207@gmail.com> <200910131644.04358.john@baldwin.cx> <86ljja3ud5.fsf@ds4.des.no> Message-ID: <4ADA6E79.2080401@elischer.org> Dag-Erling Sm?rgrav wrote: > Antony Mawer writes: >> Am I correct in reading this as saying that -any- system which was >> setup as dangerously dedicated will be unbootable under 8.0, and the >> only way to fix is to basically repartition and reinstall...? If so >> ... !!! > > You brought it upon yourself by setting it up that way in the first > place. It's called *dangerously* dedicated for a reason. I coined that expression back in 92 because it only worked because the bsdlabel also included a dummy fdisk block, which pointed to itself. > > DES From inpcb.harsha at gmail.com Sun Oct 18 06:28:38 2009 From: inpcb.harsha at gmail.com (Harsha) Date: Sun Oct 18 06:28:45 2009 Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] In-Reply-To: References: Message-ID: Hi Robert, Apologies for not getting earlier. On Mon, Oct 12, 2009 at 6:46 AM, Robert N. M. Watson wrote: > > Looks like a NULL pointer dereference, so perhaps a more traditional bug -- > could you convert ifindex_alloc_locked+0x71 to a line of code? You can do > this using kgdb on the kernel symbols file, perhaps "l > *ifindex_alloc_locked+0x71". It is the for loop in ifindex_alloc_locked() function- for (idx = 1; idx <= V_if_index; idx++) idx is a local variable, so I figured it is V_if_index is what is causing the page fault. It does look like a NULL pointer reference - I see that V_if_index comes from that vnet instance's value and uses the macro VNET_VNET_PTR() down the chain. Since the call chain is coming from a new thread cbb_event_thread, I believe that this thread's vnet context needs to be set using CURVNET_SET(). I'll try this tomorrow, but if think I'm not on the right track or want me to try something else please let me know. Many thanks, Harsha From julian at elischer.org Sun Oct 18 06:42:42 2009 From: julian at elischer.org (Julian Elischer) Date: Sun Oct 18 06:42:54 2009 Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] In-Reply-To: References: Message-ID: <4ADAB8E0.3090502@elischer.org> Harsha wrote: > Hi Robert, > > Apologies for not getting earlier. > > On Mon, Oct 12, 2009 at 6:46 AM, Robert N. M. Watson > wrote: >> Looks like a NULL pointer dereference, so perhaps a more traditional bug -- >> could you convert ifindex_alloc_locked+0x71 to a line of code? You can do >> this using kgdb on the kernel symbols file, perhaps "l >> *ifindex_alloc_locked+0x71". > It is the for loop in ifindex_alloc_locked() function- > for (idx = 1; idx <= V_if_index; idx++) > > idx is a local variable, so I figured it is V_if_index is what is > causing the page fault. It does look like a NULL pointer reference - I > see that V_if_index comes from that vnet instance's value and uses > the macro VNET_VNET_PTR() down the chain. Since the call chain is > coming from a new thread cbb_event_thread, I believe that this > thread's vnet context needs to be set using CURVNET_SET(). but only if you have options VIMAGE defined. if not then CURVNET_SET() is a NOP > > I'll try this tomorrow, but if think I'm not on the right track or > want me to try something else please let me know. > > Many thanks, > Harsha > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From guru at unixarea.de Sun Oct 18 07:02:54 2009 From: guru at unixarea.de (Matthias Apitz) Date: Sun Oct 18 07:03:00 2009 Subject: [kde-freebsd] 9-CURRENT (r197801) && artsd of kde-3.5.10_2 gives SIGSEGV In-Reply-To: <20091015080034.GA2045@current.Sisis.de> References: <20091011062419.GA2168@current.Sisis.de> <3a142e750910111214rb75f185k12b2cc7e1aba59d9@mail.gmail.com> <20091012130914.GA4180@current.Sisis.de> <20091013153815.GA88394@bsdcrew.de> <20091014063221.GA2301@current.Sisis.de> <20091015080034.GA2045@current.Sisis.de> Message-ID: <20091018070254.GA2256@current.Sisis.de> El d?a Thursday, October 15, 2009 a las 10:00:35AM +0200, Matthias Apitz escribi?: > esp. libtool-2.2.6a let me think that this procedure (i.e. building > subversion-freebsd before updating to 9-CURRENT) could cause the clash. > I will recompile the above ports and if this does not help re-install > all and remove /usr/local/* and /var/db/pkg/* before starting with > compiling the ports after the SVN and CVS parts are done. As I said, I removed all /usr/local/* and /var/db/pkg/* and compiled ports/x11/kde3 again ... the problem remains: aRts crashes with SIGSEGV; now I'm really clueless what can cause that :-( matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ Vote NO to EU The Lisbon Treaty: http://www.no-means-no.eu From ianf at clue.co.za Sun Oct 18 07:38:29 2009 From: ianf at clue.co.za (Ian FREISLICH) Date: Sun Oct 18 07:38:36 2009 Subject: urtw(4) feedback. In-Reply-To: <20091018003823.GH67082@weongyo> References: <20091018003823.GH67082@weongyo> Message-ID: Weongyo Jeong wrote: > On Wed, Oct 07, 2009 at 02:23:10PM +0200, Ian Freislich wrote: > > Hi > > > > FWIW, the manual can be updated to include support for the Linksys > > WG111v3 adapter. Mine detects as follows: > > > > ugen4.3: at usbus4, cfg=0 md=HOST spd=HIGH ( 480Mbps) pwr=ON > > > > urtw0: on usbus4 > > urtw0: rtl8187b rf rtl8225z2 hwrev e > > > > Opening it up confirms the presence of a RTL8187B. > > > > However throughput is very poor, I haven't been able to get more > > than about 130kB/s and pings seem to be timed every 1.5 seconds. > > I'd committed a major change of urtw(4) for RTL8187B devices; r198194. > Could you please test with it? I hope TX works than before. Thanks, I saw the commit. Should I back out Paulo's changes to test? It did merge cleanly with his code from P4. Ian -- Ian Freislich From taku at tackymt.homeip.net Sun Oct 18 11:24:18 2009 From: taku at tackymt.homeip.net (Taku YAMAMOTO) Date: Sun Oct 18 11:24:26 2009 Subject: softclock swis not bound to specific cpu Message-ID: <20091018202407.656c3863.taku@tackymt.homeip.net> I noticed that the softclock threads didn't seem to be bound to any cpu. I'm not sure whether it's the Right Thing (TM) to bind them to the corresponding cpus though: it might be good to give the scheduler a chance to rebalance callouts. I'm about to test the modification like the attached diff. Comments are welcome. -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - -------------- next part -------------- A non-text attachment was scrubbed... Name: softclock_bind.diff Type: text/x-diff Size: 1141 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091018/176b70a8/softclock_bind.bin From dmk at ncf.ca Sun Oct 18 07:29:35 2009 From: dmk at ncf.ca (Dwayne MacKinnon) Date: Sun Oct 18 11:40:37 2009 Subject: SATA DVD not found - FreeBSD 8.0-RC1 Message-ID: <200910180304.12900.dmk@ncf.ca> Hi guys, Gotta say, for the most part I'm thrilled with 8.0-RC1. Been very solid for me, no stability problems. The Linux "Emulation" works great... I have everything from Skype and Acrobat8 to UT2004 & Neverwinter Nights working. I just wanted to mention that my SATA DVD writer isn't seen when in AHCI mode. The SATA harddrive works great at UDMA150, but the CD drive isn't seen. It is seen by BIOS... I can boot off the DVD. But if I boot off the HD the DVD isn't seen. I have an ASUS M4N72-E motherboard and a LG GH22NS50 SATA DVD writer. I realize that this may be just something that will be worked out when 8.0- RELEASE hits the street. But I figured I ought to mention it regardless. Keep up the great work! Cheers, Dwayne From shoesoft at gmx.net Sun Oct 18 12:50:15 2009 From: shoesoft at gmx.net (Stefan Ehmann) Date: Sun Oct 18 12:50:23 2009 Subject: ukbd: short freeze when activating LEDs In-Reply-To: <20090905182929.GB2829@hoeg.nl> References: <200909051806.07692.hselasky@c2i.net> <20090905182929.GB2829@hoeg.nl> Message-ID: <200910181450.11838.shoesoft@gmx.net> On Saturday 05 September 2009 20:29:29 Ed Schouten wrote: > * Hans Petter Selasky wrote: > > On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote: > > > Whenever I press capslock/numlock, the system shortly (< 0.5 ms) > > > freezes. > > > > It might also be because the USB keyboard driver is using Giant, which > > can be congested. > > For half a second? I experience the same issue. I also have the same > issue with the Syscons VGA driver when switching windows. Some time ago > I talked about this with some other people and it may be possible it has > something to do with SMIs. Not sure... > Recently, I got an off-list response pointing me the "Other" section of http://wiki.freebsd.org/BugBusting/Commonly_reported_issues: "When switching consoles (e.g. Alt-F2 to switch to ttyv1), a 2-3 second delay is experienced" The suggested workaround (hint.kbdmux.0.disabled="1") also helps in my case. So it's not necessarily USB-related. From rpaulo at freebsd.org Sun Oct 18 12:51:11 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Sun Oct 18 12:51:44 2009 Subject: urtw(4) feedback. In-Reply-To: References: <20091018003823.GH67082@weongyo> Message-ID: <933A2245-8097-472E-8C06-BE57A4AA05F5@freebsd.org> On 18 Oct 2009, at 08:38, Ian FREISLICH wrote: > Weongyo Jeong wrote: >> On Wed, Oct 07, 2009 at 02:23:10PM +0200, Ian Freislich wrote: >>> Hi >>> >>> FWIW, the manual can be updated to include support for the Linksys >>> WG111v3 adapter. Mine detects as follows: >>> >>> ugen4.3: at usbus4, cfg=0 md=HOST >>> spd=HIGH ( > 480Mbps) pwr=ON >>> >>> urtw0: >> addr 3> on > usbus4 >>> urtw0: rtl8187b rf rtl8225z2 hwrev e >>> >>> Opening it up confirms the presence of a RTL8187B. >>> >>> However throughput is very poor, I haven't been able to get more >>> than about 130kB/s and pings seem to be timed every 1.5 seconds. >> >> I'd committed a major change of urtw(4) for RTL8187B devices; >> r198194. >> Could you please test with it? I hope TX works than before. > > Thanks, I saw the commit. Should I back out Paulo's changes to test? > It did merge cleanly with his code from P4. They weren't my changes, they were Weongyo's. -- Rui Paulo From ianf at clue.co.za Sun Oct 18 15:30:06 2009 From: ianf at clue.co.za (Ian FREISLICH) Date: Sun Oct 18 15:34:20 2009 Subject: urtw(4) feedback. In-Reply-To: <933A2245-8097-472E-8C06-BE57A4AA05F5@freebsd.org> References: <933A2245-8097-472E-8C06-BE57A4AA05F5@freebsd.org> <20091018003823.GH67082@weongyo> Message-ID: Rui Paulo wrote: > On 18 Oct 2009, at 08:38, Ian FREISLICH wrote: > > > Weongyo Jeong wrote: > >> On Wed, Oct 07, 2009 at 02:23:10PM +0200, Ian Freislich wrote: > >>> Hi > >>> > >>> FWIW, the manual can be updated to include support for the Linksys > >>> WG111v3 adapter. Mine detects as follows: > >>> > >>> ugen4.3: at usbus4, cfg=0 md=HOST > >>> spd=HIGH ( > > 480Mbps) pwr=ON > >>> > >>> urtw0: >>> addr 3> on > > usbus4 > >>> urtw0: rtl8187b rf rtl8225z2 hwrev e > >>> > >>> Opening it up confirms the presence of a RTL8187B. > >>> > >>> However throughput is very poor, I haven't been able to get more > >>> than about 130kB/s and pings seem to be timed every 1.5 seconds. > >> > >> I'd committed a major change of urtw(4) for RTL8187B devices; > >> r198194. > >> Could you please test with it? I hope TX works than before. > > > > Thanks, I saw the commit. Should I back out Paulo's changes to test? > > It did merge cleanly with his code from P4. > > They weren't my changes, they were Weongyo's. Right. Well, the committed changes with the files from P4 were a serious regression. I haven't been able to try stock -CURRENT yet. Ian -- Ian Freislich From gavin.atkinson at ury.york.ac.uk Sun Oct 18 15:32:54 2009 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Sun Oct 18 15:36:32 2009 Subject: 8.0rc1 not recognizing partitions on EPIA SN In-Reply-To: References: <4ACE6D84.3000209@gmail.com> <4ACE833A.3030506@uffner.com> <4ACE9DFD.3010207@gmail.com> <200910131644.04358.john@baldwin.cx> <86ljja3ud5.fsf@ds4.des.no> Message-ID: <20091018162750.E82400@ury.york.ac.uk> On Sun, 18 Oct 2009, Daniel Nebdal wrote: > 2009/10/17 Dag-Erling Sm?rgrav : >> Antony Mawer writes: >>> Am I correct in reading this as saying that -any- system which was >>> setup as dangerously dedicated will be unbootable under 8.0, and the >>> only way to fix is to basically repartition and reinstall...? If so >>> ... !!! >> >> You brought it upon yourself by setting it up that way in the first >> place. ?It's called *dangerously* dedicated for a reason. >> > > Indeed, though I was under the impression that the reason was "nothing > else will understand this", not "we might not support this in the > future". As I understand things, the problems are partially due to a bug in older versions of sysinstall that created incorrect disklables in DD mode, and partially due to the new GEOM partitioning modules, which now parse these ambiguous disk labels differently. You can get around this by compiling a custom kernel and using the old partitioning modules (use GEOM_MBR and GEOM_BSD rather than GEOM_PART), but you may well just be postponing the problem as I believe the old modules were planned to be removed at some point. Gavin From dnebdal at gmail.com Sun Oct 18 15:53:07 2009 From: dnebdal at gmail.com (Daniel Nebdal) Date: Sun Oct 18 16:00:01 2009 Subject: 8.0rc1 not recognizing partitions on EPIA SN In-Reply-To: <20091018162750.E82400@ury.york.ac.uk> References: <4ACE6D84.3000209@gmail.com> <4ACE833A.3030506@uffner.com> <4ACE9DFD.3010207@gmail.com> <200910131644.04358.john@baldwin.cx> <86ljja3ud5.fsf@ds4.des.no> <20091018162750.E82400@ury.york.ac.uk> Message-ID: On Sun, Oct 18, 2009 at 5:32 PM, Gavin Atkinson wrote: > As I understand things, the problems are partially due to a bug in older > versions of sysinstall that created incorrect disklables in DD mode, and > partially due to the new GEOM partitioning modules, which now parse these > ambiguous disk labels differently. > > You can get around this by compiling a custom kernel and using the old > partitioning modules (use GEOM_MBR and GEOM_BSD rather than GEOM_PART), but > you may well just be postponing the problem as I believe the old modules > were planned to be removed at some point. > > Gavin Does that mean that it's possible to write a DD-style disklabel that GEOM_PART would be happy with? That would open up the possibility of correcting the old label in-place (somehow)... -- Daniel Nebdal From gavin.atkinson at ury.york.ac.uk Sun Oct 18 16:19:49 2009 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Sun Oct 18 16:19:56 2009 Subject: SATA DVD not found - FreeBSD 8.0-RC1 In-Reply-To: <200910180304.12900.dmk@ncf.ca> References: <200910180304.12900.dmk@ncf.ca> Message-ID: <20091018171903.G82400@ury.york.ac.uk> On Sun, 18 Oct 2009, Dwayne MacKinnon wrote: > Gotta say, for the most part I'm thrilled with 8.0-RC1. Been very solid for > me, no stability problems. The Linux "Emulation" works great... I have > everything from Skype and Acrobat8 to UT2004 & Neverwinter Nights working. > > I just wanted to mention that my SATA DVD writer isn't seen when in AHCI mode. > The SATA harddrive works great at UDMA150, but the CD drive isn't seen. It is > seen by BIOS... I can boot off the DVD. But if I boot off the HD the DVD isn't > seen. > > I have an ASUS M4N72-E motherboard and a LG GH22NS50 SATA DVD writer. > > I realize that this may be just something that will be worked out when 8.0- > RELEASE hits the street. But I figured I ought to mention it regardless. Can you upload a verbose dmesg somewhere and post a link to it to the mailing list? Gavin From yr.retarded at gmail.com Sun Oct 18 17:14:49 2009 From: yr.retarded at gmail.com (Chris Ruiz) Date: Sun Oct 18 17:14:56 2009 Subject: ukbd: short freeze when activating LEDs In-Reply-To: <200910181450.11838.shoesoft@gmx.net> References: <200909051806.07692.hselasky@c2i.net> <20090905182929.GB2829@hoeg.nl> <200910181450.11838.shoesoft@gmx.net> Message-ID: <58c737d70910181014u7c32ffd2s8c0732a707d40a2f@mail.gmail.com> On Sun, Oct 18, 2009 at 7:50 AM, Stefan Ehmann wrote: > On Saturday 05 September 2009 20:29:29 Ed Schouten wrote: >> * Hans Petter Selasky wrote: >> > On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote: >> > > Whenever I press capslock/numlock, the system shortly (< 0.5 ms) >> > > freezes. >> > >> > It might also be because the USB keyboard driver is using Giant, which >> > can be congested. >> >> For half a second? I experience the same issue. I also have the same >> issue with the Syscons VGA driver when switching windows. Some time ago >> I talked about this with some other people and it may be possible it has >> something to do with SMIs. Not sure... >> > > Recently, I got an off-list response pointing me the "Other" section of > http://wiki.freebsd.org/BugBusting/Commonly_reported_issues: > "When switching consoles (e.g. Alt-F2 to switch to ttyv1), a 2-3 second delay > is experienced" > > The suggested workaround (hint.kbdmux.0.disabled="1") also helps in my case. > So it's not necessarily USB-related. I'm my experience the "switching consoles" delay goes away when you remove atkbd and related options from your kernel if you only have a usb keyboard. I don't have that delay with kbdmux left compiled in. The delay most likely has something to do with locking, re: GIANT. -- Chris ----------------------------------------- http://twitter.com/chrisattack http://chrisattack.com From ed at 80386.nl Sun Oct 18 17:18:09 2009 From: ed at 80386.nl (Ed Schouten) Date: Sun Oct 18 17:18:17 2009 Subject: ukbd: short freeze when activating LEDs In-Reply-To: <58c737d70910181014u7c32ffd2s8c0732a707d40a2f@mail.gmail.com> References: <200909051806.07692.hselasky@c2i.net> <20090905182929.GB2829@hoeg.nl> <200910181450.11838.shoesoft@gmx.net> <58c737d70910181014u7c32ffd2s8c0732a707d40a2f@mail.gmail.com> Message-ID: <20091018171808.GN89475@hoeg.nl> * Chris Ruiz wrote: > The delay most likely has something to do with locking, re: GIANT. What makes you think that? I could give you dozens of other reasons. The most serious one being: http://en.wikipedia.org/wiki/System_Management_Mode -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091018/a114549a/attachment.pgp From yr.retarded at gmail.com Sun Oct 18 17:26:55 2009 From: yr.retarded at gmail.com (Chris Ruiz) Date: Sun Oct 18 17:27:01 2009 Subject: ukbd: short freeze when activating LEDs In-Reply-To: <20091018171808.GN89475@hoeg.nl> References: <200909051806.07692.hselasky@c2i.net> <20090905182929.GB2829@hoeg.nl> <200910181450.11838.shoesoft@gmx.net> <58c737d70910181014u7c32ffd2s8c0732a707d40a2f@mail.gmail.com> <20091018171808.GN89475@hoeg.nl> Message-ID: <58c737d70910181026g2f9e1050ge5d8fb8dfc1a9a33@mail.gmail.com> On Sun, Oct 18, 2009 at 12:18 PM, Ed Schouten wrote: > * Chris Ruiz wrote: >> The delay most likely has something to do with locking, re: GIANT. > > What makes you think that? I could give you dozens of other reasons. The > most serious one being: > > ? ? ? ?http://en.wikipedia.org/wiki/System_Management_Mode /me puts on a pointy hat and stands in corner. I made an assumption about the cause. -- Chris ----------------------------------------- http://twitter.com/chrisattack http://chrisattack.com From dmk at ncf.ca Sun Oct 18 17:04:36 2009 From: dmk at ncf.ca (Dwayne MacKinnon) Date: Sun Oct 18 18:08:03 2009 Subject: SATA DVD not found - FreeBSD 8.0-RC1 In-Reply-To: <20091018171903.G82400@ury.york.ac.uk> References: <200910180304.12900.dmk@ncf.ca> <20091018171903.G82400@ury.york.ac.uk> Message-ID: <200910181304.20042.dmk@ncf.ca> On October 18, 2009 12:19:46 pm Gavin Atkinson wrote: > On Sun, 18 Oct 2009, Dwayne MacKinnon wrote: > > Gotta say, for the most part I'm thrilled with 8.0-RC1. Been very solid > > for me, no stability problems. The Linux "Emulation" works great... I > > have everything from Skype and Acrobat8 to UT2004 & Neverwinter Nights > > working. > > > > I just wanted to mention that my SATA DVD writer isn't seen when in AHCI > > mode. The SATA harddrive works great at UDMA150, but the CD drive isn't > > seen. It is seen by BIOS... I can boot off the DVD. But if I boot off the > > HD the DVD isn't seen. > > > > I have an ASUS M4N72-E motherboard and a LG GH22NS50 SATA DVD writer. > > > > I realize that this may be just something that will be worked out when > > 8.0- RELEASE hits the street. But I figured I ought to mention it > > regardless. > > Can you upload a verbose dmesg somewhere and post a link to it to the > mailing list? > > Gavin > Hello, Done. Sorry, I should've thought of that myself. I've also posted the output from "atacontrol list" just for completeness. http://pastebin.com/m50035eb1 (Verbose dmesg) http://pastebin.com/m4a35199c (atacontrol list) Cheers, DMK From dougb at FreeBSD.org Sun Oct 18 19:30:00 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Oct 18 19:30:07 2009 Subject: SATA DVD not found - FreeBSD 8.0-RC1 In-Reply-To: <200910180304.12900.dmk@ncf.ca> References: <200910180304.12900.dmk@ncf.ca> Message-ID: <4ADB6CB5.1020507@FreeBSD.org> Don't have an answer for your problem (sorry) but I did want to take a second and say thank you for doing this testing. It is critical to the success of a .0 release that we get as much testing from our user community as possible. I realize that running into a hardware bug is frustrating, but when this is resolved you will have the satisfaction of knowing that you helped every FreeBSD user with similar hardware. :) Regards, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From gavin at FreeBSD.org Sun Oct 18 21:01:54 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Sun Oct 18 21:02:01 2009 Subject: dtrace profile timers still unstable? In-Reply-To: References: Message-ID: <20091018210042.I82400@ury.york.ac.uk> On Fri, 16 Oct 2009, Robert Watson wrote: > In the past, I've had little luck using the DTrace profile timers on FreeBSD > for much without crashes, and this morning was no different. I attempted to > use the following(ish) script: > > profile-1ms > { > > @data[stack()] = count(); > } > > The result was: > > spin lock 0x849747d8 (cyclic cpu) held by 0x85442b40 (tid 100539) too long > panic: spin lock held too long [...] > (I've seen panics with it pretty deterministically on i386 and amd64) Is there any particular technique to get this to panic? I've been trying to get a panic from the above script (using "dtrace -s prof.d") for a few hours now without success... Gavin From wblock at wonkity.com Sun Oct 18 21:54:53 2009 From: wblock at wonkity.com (Warren Block) Date: Sun Oct 18 21:55:01 2009 Subject: /etc/rc.d locking devd.pid (was Re: Restarting devd) In-Reply-To: References: Message-ID: On Sat, 17 Oct 2009, Warren Block wrote: > Immediately after boot, devd restart fails: > > # /etc/rc.d/devd restart > Stopping devd. > Starting devd. > devd: devd already running, pid: 398 > /etc/rc.d/devd: WARNING: failed to start devd > > And it's right, devd is not running. Remove the stale pidfile > /var/run/devd.pid, and '/etc/rc.d/devd start' goes fine. ...and this is due to dhclient, run from /etc/rc.d at startup, locking /var/run/devd.pid: lightning% lsof /var/run/devd.pid COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME devd 400 root 6w VREG 0,101 3 47124 /var/run/devd.pid dhclient 865 root 6w VREG 0,101 3 47124 /var/run/devd.pid dhclient 1024 _dhcp 6w VREG 0,101 3 47124 /var/run/devd.pid This is a regression from 7-STABLE, where devd.pid is only locked by devd after startup. -Warren Block * Rapid City, South Dakota USA From rwatson at FreeBSD.org Sun Oct 18 22:02:12 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Oct 18 22:02:19 2009 Subject: dtrace profile timers still unstable? In-Reply-To: <20091018210042.I82400@ury.york.ac.uk> References: <20091018210042.I82400@ury.york.ac.uk> Message-ID: On Sun, 18 Oct 2009, Gavin Atkinson wrote: >> spin lock 0x849747d8 (cyclic cpu) held by 0x85442b40 (tid 100539) too long >> panic: spin lock held too long > > [...] > >> (I've seen panics with it pretty deterministically on i386 and amd64) > > Is there any particular technique to get this to panic? I've been trying to > get a panic from the above script (using "dtrace -s prof.d") for a few hours > now without success... The panic I saw was definitely SMP-related, and occured when I hit ctrl-c to terminate the script and see the results. They were partially reported, followed by boom. Robert N M Watson Computer Laboratory University of Cambridge From kostikbel at gmail.com Sun Oct 18 22:09:40 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Oct 18 22:09:47 2009 Subject: /etc/rc.d locking devd.pid (was Re: Restarting devd) In-Reply-To: References: Message-ID: <20091018220935.GR2160@deviant.kiev.zoral.com.ua> On Sun, Oct 18, 2009 at 03:54:52PM -0600, Warren Block wrote: > On Sat, 17 Oct 2009, Warren Block wrote: > > >Immediately after boot, devd restart fails: > > > ># /etc/rc.d/devd restart > >Stopping devd. > >Starting devd. > >devd: devd already running, pid: 398 > >/etc/rc.d/devd: WARNING: failed to start devd > > > >And it's right, devd is not running. Remove the stale pidfile > >/var/run/devd.pid, and '/etc/rc.d/devd start' goes fine. > > ...and this is due to dhclient, run from /etc/rc.d at startup, locking > /var/run/devd.pid: > > lightning% lsof /var/run/devd.pid > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > devd 400 root 6w VREG 0,101 3 47124 /var/run/devd.pid > dhclient 865 root 6w VREG 0,101 3 47124 /var/run/devd.pid > dhclient 1024 _dhcp 6w VREG 0,101 3 47124 /var/run/devd.pid > > This is a regression from 7-STABLE, where devd.pid is only locked by > devd after startup. Devd forks to spawn dhclient, it seems, and opened file descriptor for the lock file is leaking to the child. Since pidfile(3) uses flock(2), the lock survives devd death. I think that this is a generic issue with pidfile/fork interaction. It is not obvious whether setting FD_CLOEXEC flag is right thing to do there. Anyway, please test. diff --git a/lib/libutil/flopen.c b/lib/libutil/flopen.c index 754c9c0..a5e436e 100644 --- a/lib/libutil/flopen.c +++ b/lib/libutil/flopen.c @@ -100,6 +100,12 @@ flopen(const char *path, int flags, ...) errno = serrno; return (-1); } + if (fcntl(fd, F_SETFD, FD_CLOEXEC) != 0) { + serrno = errno; + (void)close(fd); + errno = serrno; + return (-1); + } return (fd); } } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091018/1288a5b7/attachment.pgp From wblock at wonkity.com Sun Oct 18 23:12:13 2009 From: wblock at wonkity.com (Warren Block) Date: Sun Oct 18 23:12:19 2009 Subject: /etc/rc.d locking devd.pid (was Re: Restarting devd) In-Reply-To: <20091018220935.GR2160@deviant.kiev.zoral.com.ua> References: <20091018220935.GR2160@deviant.kiev.zoral.com.ua> Message-ID: On Mon, 19 Oct 2009, Kostik Belousov wrote: >> >> ...and this is due to dhclient, run from /etc/rc.d at startup, locking >> /var/run/devd.pid: >> >> lightning% lsof /var/run/devd.pid >> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >> devd 400 root 6w VREG 0,101 3 47124 /var/run/devd.pid >> dhclient 865 root 6w VREG 0,101 3 47124 /var/run/devd.pid >> dhclient 1024 _dhcp 6w VREG 0,101 3 47124 /var/run/devd.pid >> >> This is a regression from 7-STABLE, where devd.pid is only locked by >> devd after startup. > > Devd forks to spawn dhclient, it seems, and opened file descriptor for > the lock file is leaking to the child. Since pidfile(3) uses flock(2), > the lock survives devd death. > > I think that this is a generic issue with pidfile/fork interaction. > It is not obvious whether setting FD_CLOEXEC flag is right thing to > do there. > > Anyway, please test. > > diff --git a/lib/libutil/flopen.c b/lib/libutil/flopen.c > index 754c9c0..a5e436e 100644 > --- a/lib/libutil/flopen.c > +++ b/lib/libutil/flopen.c > @@ -100,6 +100,12 @@ flopen(const char *path, int flags, ...) > errno = serrno; > return (-1); > } > + if (fcntl(fd, F_SETFD, FD_CLOEXEC) != 0) { > + serrno = errno; > + (void)close(fd); > + errno = serrno; > + return (-1); > + } > return (fd); > } > } The dhclient locks are still present with this code. I just did make; make install in /usr/src/lib/libutil and rebooted to test. -Warren Block * Rapid City, South Dakota USA From inpcb.harsha at gmail.com Sun Oct 18 23:26:52 2009 From: inpcb.harsha at gmail.com (Harsha) Date: Sun Oct 18 23:26:59 2009 Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] In-Reply-To: <4ADAB8E0.3090502@elischer.org> References: <4ADAB8E0.3090502@elischer.org> Message-ID: On Sat, Oct 17, 2009 at 11:42 PM, Julian Elischer wrote: > Harsha wrote: >> wrote: >>> >>> Looks like a NULL pointer dereference, so perhaps a more traditional bug >>> -- >>> could you convert ifindex_alloc_locked+0x71 to a line of code? You can do >>> this using kgdb on the kernel symbols file, perhaps "l >>> *ifindex_alloc_locked+0x71". >> >> It is the for loop in ifindex_alloc_locked() function- >> ?for (idx = 1; idx <= V_if_index; idx++) >> >> idx is a local variable, so I figured it is V_if_index is what is >> causing the page fault. It does look like a NULL pointer reference - I >> see that V_if_index comes from that ?vnet instance's value and uses >> the macro VNET_VNET_PTR() down the chain. Since the call chain is >> coming from a new thread cbb_event_thread, I believe that this >> thread's vnet context needs to be set using CURVNET_SET(). > > but only if you have options VIMAGE defined. if not then CURVNET_SET() > is a NOP I do have the VIMAGE options turned on. Can someone tell me what is the right way to add the vnet context to cbb_event_thread? I tried adding context in two locations- 1. In cbb_insert() as- CURVNET_SET(TD_TO_VNET(curthread)); 2. In if_alloc() as- CURVNET_SET(TD_TO_VNET(curthread)); or as ifp = malloc(sizeof(struct ifnet), M_IFNET, M_WAITOK|M_ZERO); #ifdef VIMAGE ifp->if_vnet = curvnet; if (ifp->if_home_vnet == NULL) ifp->if_home_vnet = curvnet; CURVNET_SET(ifp->if_vnet); #endif But in all the cases I get a warning/error about unused variable 'saved_vnet' like this- cc1: warnings being treated as errors /usr/src/sys/net/if.c: In function 'if_alloc': /usr/src/sys/net/if.c:418: warning: unused variable 'saved_vnet' The backtrace is in the link I posted earlier. Thanks, Harsha From vlad.k.sm at gmail.com Mon Oct 19 01:27:30 2009 From: vlad.k.sm at gmail.com (Vlad K Sm) Date: Mon Oct 19 01:27:37 2009 Subject: sio.c depends on "struct tty" which was changed Message-ID: <4ADBBBAC.60004@gmail.com> Hi, Tried to buildkernel with "device sio", it reported errors like "struct tty doesn't have memeber t_init_in" and etc. on code block in sio.c: tp->t_init_in.c_ispeed = tp->t_init_in.c_ospeed = tp->t_lock_in.c_ispeed = tp->t_lock_in.c_ospeed = tp->t_init_out.c_ispeed = tp->t_init_out.c_ospeed = tp->t_lock_out.c_ispeed = tp->t_lock_out.c_ospeed = comdefaultrate; Tty actually doesn't have it and seems "sio" in't suported anymore. If so, does it make sense to remove support of "device sio" from current at all? Thanks, Vlad Kuzmin From julian at elischer.org Mon Oct 19 04:00:06 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 19 04:00:14 2009 Subject: 8.0rc1 not recognizing partitions on EPIA SN In-Reply-To: References: <4ACE6D84.3000209@gmail.com> <4ACE833A.3030506@uffner.com> <4ACE9DFD.3010207@gmail.com> <200910131644.04358.john@baldwin.cx> <86ljja3ud5.fsf@ds4.des.no> <20091018162750.E82400@ury.york.ac.uk> Message-ID: <4ADBE444.1010706@elischer.org> Daniel Nebdal wrote: > On Sun, Oct 18, 2009 at 5:32 PM, Gavin Atkinson > wrote: >> As I understand things, the problems are partially due to a bug in older >> versions of sysinstall that created incorrect disklables in DD mode, and >> partially due to the new GEOM partitioning modules, which now parse these >> ambiguous disk labels differently. >> >> You can get around this by compiling a custom kernel and using the old >> partitioning modules (use GEOM_MBR and GEOM_BSD rather than GEOM_PART), but >> you may well just be postponing the problem as I believe the old modules >> were planned to be removed at some point. >> >> Gavin > > Does that mean that it's possible to write a DD-style disklabel that > GEOM_PART would be happy with? > That would open up the possibility of correcting the old label > in-place (somehow)... it may be as little as overwriting bytes 510 and 511 of block0. (the last 2 bytes of the block are a magic number) this would stop the fdisk taster from recognising it as an fdisk block and teh disklabel taster would recognise the disklabel. if you try this, keep a backup of block0 :-) From julian at elischer.org Mon Oct 19 04:22:37 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 19 04:22:50 2009 Subject: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c] In-Reply-To: References: <4ADAB8E0.3090502@elischer.org> Message-ID: <4ADBE98C.3030404@elischer.org> Harsha wrote: > On Sat, Oct 17, 2009 at 11:42 PM, Julian Elischer wrote: >> Harsha wrote: >>> wrote: >>>> Looks like a NULL pointer dereference, so perhaps a more traditional bug >>>> -- >>>> could you convert ifindex_alloc_locked+0x71 to a line of code? You can do >>>> this using kgdb on the kernel symbols file, perhaps "l >>>> *ifindex_alloc_locked+0x71". >>> It is the for loop in ifindex_alloc_locked() function- >>> for (idx = 1; idx <= V_if_index; idx++) >>> >>> idx is a local variable, so I figured it is V_if_index is what is >>> causing the page fault. It does look like a NULL pointer reference - I >>> see that V_if_index comes from that vnet instance's value and uses >>> the macro VNET_VNET_PTR() down the chain. Since the call chain is >>> coming from a new thread cbb_event_thread, I believe that this >>> thread's vnet context needs to be set using CURVNET_SET(). >> but only if you have options VIMAGE defined. if not then CURVNET_SET() >> is a NOP > I do have the VIMAGE options turned on. > > Can someone tell me what is the right way to add the vnet context to > cbb_event_thread? have you read the vimage porting document at: http://p4db.freebsd.org/fileLogView.cgi?FSPC=//depot/projects/vimage/porting_to_vimage.txt > > I tried adding context in two locations- > > 1. In cbb_insert() as- > CURVNET_SET(TD_TO_VNET(curthread)); > > 2. In if_alloc() as- > CURVNET_SET(TD_TO_VNET(curthread)); > > or as > > ifp = malloc(sizeof(struct ifnet), M_IFNET, M_WAITOK|M_ZERO); > #ifdef VIMAGE > ifp->if_vnet = curvnet; > if (ifp->if_home_vnet == NULL) > ifp->if_home_vnet = curvnet; > CURVNET_SET(ifp->if_vnet); > #endif CURVNET_SET sets curvnet but you are using it already, 3 lines above. > > But in all the cases I get a warning/error about unused variable > 'saved_vnet' like this- > > cc1: warnings being treated as errors > /usr/src/sys/net/if.c: In function 'if_alloc': > /usr/src/sys/net/if.c:418: warning: unused variable 'saved_vnet' > > The backtrace is in the link I posted earlier. > > Thanks, > Harsha From mav at FreeBSD.org Mon Oct 19 05:01:16 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon Oct 19 05:01:24 2009 Subject: SATA DVD not found - FreeBSD 8.0-RC1 In-Reply-To: <1255900985.00174556.1255889404@10.7.7.3> References: <1255879383.00174464.1255866601@10.7.7.3> <1255893786.00174536.1255883401@10.7.7.3> <1255900985.00174556.1255889404@10.7.7.3> Message-ID: <4ADBF298.5030706@FreeBSD.org> Hi. Dwayne MacKinnon wrote: > On October 18, 2009 12:19:46 pm Gavin Atkinson wrote: >> On Sun, 18 Oct 2009, Dwayne MacKinnon wrote: >>> Gotta say, for the most part I'm thrilled with 8.0-RC1. Been very solid >>> for me, no stability problems. The Linux "Emulation" works great... I >>> have everything from Skype and Acrobat8 to UT2004 & Neverwinter Nights >>> working. >>> >>> I just wanted to mention that my SATA DVD writer isn't seen when in AHCI >>> mode. The SATA harddrive works great at UDMA150, but the CD drive isn't >>> seen. It is seen by BIOS... I can boot off the DVD. But if I boot off the >>> HD the DVD isn't seen. >>> >>> I have an ASUS M4N72-E motherboard and a LG GH22NS50 SATA DVD writer. >>> >>> I realize that this may be just something that will be worked out when >>> 8.0- RELEASE hits the street. But I figured I ought to mention it >>> regardless. >> Can you upload a verbose dmesg somewhere and post a link to it to the >> mailing list? > > Done. Sorry, I should've thought of that myself. I've also posted the output > from "atacontrol list" just for completeness. > > http://pastebin.com/m50035eb1 (Verbose dmesg) > http://pastebin.com/m4a35199c (atacontrol list) For some reason your DVD detected as ATA disk device, not ATAPI during bus reset: ata4: Identifying devices: 00000001 ata4: New devices: 00000001 It caused further problems: unknown: FAILURE - ATA_IDENTIFY status=51 error=4 LBA=0 I have alike ASUS M4N78 PRO board and it looked like working fine when I last tested. Can you try some other DVD drive on that board? Can you try to load ahci module to try new CAM-based AHCI driver (be ready to drive names change to adaX)? -- Alexander Motin From dougb at FreeBSD.org Mon Oct 19 05:16:46 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Oct 19 05:16:53 2009 Subject: Apparent console regressions in -current Message-ID: <4ADBF637.8090206@FreeBSD.org> Ed, I was trying to debug an unrelated problem today and noticed what appear to be some console regressions. I'm running r198216 i386 SMP with no local patches. The two things I tried doing were using less(1) on a group of files and running 'make config' on a port. In the first case it would display a few files (small ones, less than one screenful) but after 4 or 5 files the display would stop about 1/2 way down the screen. I use less with the following environment string if it helps: LESS='-eiFP?f%f .?n?m(file %i of %m) ..?e(END) ?x- Next\: %x.:?pB%pB\%..%t' Doing 'make config' in ports uses dialog, which exhibited the same basic problem, the 1/3 to 1/2 of the display would have the output from dialog and the rest would be blank. The specific port was emulators/virtualbox but I tried a few others and got the same result. Doing both of these things works in an xterm (roxterm to be specific) so it seems to be a console issue. My kernel config is pretty close to GENERIC with a bunch of stuff removed. The only thing even vaguely console-related is 'options VESA' but I don't have anything custom configured for my console except keybell="visual" in /etc/rc.conf. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From des at des.no Mon Oct 19 06:02:47 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Oct 19 06:02:54 2009 Subject: 8.0rc1 not recognizing partitions on EPIA SN In-Reply-To: <4ADBE444.1010706@elischer.org> (Julian Elischer's message of "Sun, 18 Oct 2009 21:00:04 -0700") References: <4ACE6D84.3000209@gmail.com> <4ACE833A.3030506@uffner.com> <4ACE9DFD.3010207@gmail.com> <200910131644.04358.john@baldwin.cx> <86ljja3ud5.fsf@ds4.des.no> <20091018162750.E82400@ury.york.ac.uk> <4ADBE444.1010706@elischer.org> Message-ID: <86vdibzzsq.fsf@ds4.des.no> Julian Elischer writes: > Daniel Nebdal writes: > > Does that mean that it's possible to write a DD-style disklabel that > > GEOM_PART would be happy with? > it may be as little as overwriting bytes 510 and 511 of block0. > (the last 2 bytes of the block are a magic number) > > this would stop the fdisk taster from recognising it as an fdisk > block and teh disklabel taster would recognise the disklabel. If by "block0" you mean the very first sector of the disk, it will also stop the BIOS from booting from that disk... DES -- Dag-Erling Sm?rgrav - des@des.no From ed at 80386.nl Mon Oct 19 07:18:50 2009 From: ed at 80386.nl (Ed Schouten) Date: Mon Oct 19 07:18:58 2009 Subject: Apparent console regressions in -current In-Reply-To: <4ADBF637.8090206@FreeBSD.org> References: <4ADBF637.8090206@FreeBSD.org> Message-ID: <20091019072053.GA1293@hoeg.nl> Hello Doug, * Doug Barton wrote: > I was trying to debug an unrelated problem today and noticed what > appear to be some console regressions. Got it. It turns out the bug is as follows: When changing the baud rate, it has to grow or shrink the TTY buffers. When it has to shrink the buffer, it doesn't actually free memory directly, but uses a lazy approach to deallocate buffers as data flows through the TTY. It also calculates a water mark, to determine when to unblock input/ output on a TTY after it had to block processes. This level is calculated by obtaining the TTY buffer sizes and using 10%. Because it uses the lazy approach, it uses the wrong buffer size to calculate the watermark, which means the watermark could be placed outside the TTY buffer size, causing processes to be never waked up. This could easily be demonstrated by running `pstat -t'. It should be fixed as of revision 198223. Thanks for reporting! -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091019/a591a546/attachment.pgp From des at des.no Mon Oct 19 07:42:53 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Oct 19 07:43:00 2009 Subject: /etc/rc.d locking devd.pid In-Reply-To: <20091018220935.GR2160@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Mon, 19 Oct 2009 01:09:35 +0300") References: <20091018220935.GR2160@deviant.kiev.zoral.com.ua> Message-ID: <86my3n6d8k.fsf@ds4.des.no> Kostik Belousov writes: > I think that this is a generic issue with pidfile/fork interaction. > It is not obvious whether setting FD_CLOEXEC flag is right thing to > do there. Most certainly not. > Anyway, please test. Please read flopen.c's revision history. DES -- Dag-Erling Sm?rgrav - des@des.no From guru at unixarea.de Mon Oct 19 09:46:44 2009 From: guru at unixarea.de (Matthias Apitz) Date: Mon Oct 19 09:46:51 2009 Subject: [kde-freebsd] 9-CURRENT (r197801) && artsd of kde-3.5.10_2 gives SIGSEGV In-Reply-To: <20091018070254.GA2256@current.Sisis.de> References: <20091011062419.GA2168@current.Sisis.de> <3a142e750910111214rb75f185k12b2cc7e1aba59d9@mail.gmail.com> <20091012130914.GA4180@current.Sisis.de> <20091013153815.GA88394@bsdcrew.de> <20091014063221.GA2301@current.Sisis.de> <20091015080034.GA2045@current.Sisis.de> <20091018070254.GA2256@current.Sisis.de> Message-ID: <20091019094646.GA3003@current.Sisis.de> El d?a Sunday, October 18, 2009 a las 09:02:55AM +0200, Matthias Apitz escribi?: > As I said, I removed all /usr/local/* and /var/db/pkg/* and compiled > ports/x11/kde3 again ... the problem remains: aRts crashes with SIGSEGV; > now I'm really clueless what can cause that :-( Last weekend I installed 8.0-RC1 on the test box and installed KDE3 and Xorg from the FreeBSD ftp server: # kldload snd_ich # setenv PKG_PATH ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/8.0-RC1/packages/All # pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/8.0-RC1/packages/All/kde-3.5.10_2.tbz # pkg_add ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/8.0-RC1/packages/All/xorg-7.4_2.tbz aRts worked just as it should; then I updated kernel and userland to 9.0-CURRENT r197801 and the installed aRts of 8.0-RC1 continues working on top of this kernel; today morning I moved away /usr/local and /var/db/pkg to install KDE3 and Xorg from the packages compiled by me after CVS updating /usr/ports: # cd /usr # mv local local.80RC1 # mkdir local # cd /var/db # mv pkg pkg.80RC1 # mkdir pkg # mount -o ro -t cd9660 /dev/acd0 /mnt # cd /mnt/PKGDIR # pkg_add kde-3.5.10_2.tbz # pkg_add xorg-7.4_2.tbz aRts crashes with SIGSEGV. What could I do next? Any hint is higly welcome. matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ Vote NO to EU The Lisbon Treaty: http://www.no-means-no.eu From Johan at double-l.nl Mon Oct 19 11:06:32 2009 From: Johan at double-l.nl (Johan Hendriks) Date: Mon Oct 19 11:06:50 2009 Subject: 8.0rc1 not recognizing partitions on EPIA SN Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA57081@w2003s01.double-l.local> >> As I understand things, the problems are partially due to a bug in older >> versions of sysinstall that created incorrect disklables in DD mode, and >> partially due to the new GEOM partitioning modules, which now parse these >> ambiguous disk labels differently. >> >> You can get around this by compiling a custom kernel and using the old >> partitioning modules (use GEOM_MBR and GEOM_BSD rather than GEOM_PART), but >> you may well just be postponing the problem as I believe the old modules >> were planned to be removed at some point. >> >> Gavin >Does that mean that it's possible to write a DD-style disklabel that >GEOM_PART would be happy with? >That would open up the possibility of correcting the old label >in-place (somehow)... >-- >Daniel Nebdal I did the following on my disk and it worked. MAKE A BACKUP AND DON'T BLAME ME IF THINGS GO WRONG!!!!!!!!!!!!! dd if=/dev/zero of=/dev/ad6 oseek=1 bs=512 count=1 /dev/ad6 was my disk Regards, Johan Hendriks No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 8.5.422 / Virus Database: 270.14.20/2444 - Release Date: 10/18/09 09:04:00 From kostikbel at gmail.com Mon Oct 19 11:30:14 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon Oct 19 11:30:21 2009 Subject: /etc/rc.d locking devd.pid In-Reply-To: <86my3n6d8k.fsf@ds4.des.no> References: <20091018220935.GR2160@deviant.kiev.zoral.com.ua> <86my3n6d8k.fsf@ds4.des.no> Message-ID: <20091019112938.GT2160@deviant.kiev.zoral.com.ua> On Mon, Oct 19, 2009 at 09:42:51AM +0200, Dag-Erling Sm??rgrav wrote: > Kostik Belousov writes: > > I think that this is a generic issue with pidfile/fork interaction. > > It is not obvious whether setting FD_CLOEXEC flag is right thing to > > do there. > > Most certainly not. Why ? We definitely leak file descriptor on exec(2) unless daemon explicitely closes it after fork. I said that it is unobvious is it right to enforce FD_CLOEXEC unconditionally, because some daemons exec() itself to reinitialize. > > > Anyway, please test. > > Please read flopen.c's revision history. I am aware of flock->fcntl->flock story, but it is relevant to fork(2), not to the exec(2) issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091019/3995da1d/attachment.pgp From des at des.no Mon Oct 19 11:48:57 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Oct 19 11:49:05 2009 Subject: /etc/rc.d locking devd.pid In-Reply-To: <20091019112938.GT2160@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Mon, 19 Oct 2009 14:29:38 +0300") References: <20091018220935.GR2160@deviant.kiev.zoral.com.ua> <86my3n6d8k.fsf@ds4.des.no> <20091019112938.GT2160@deviant.kiev.zoral.com.ua> Message-ID: <86iqeb61uh.fsf@ds4.des.no> Kostik Belousov writes: > Why ? We definitely leak file descriptor on exec(2) unless daemon > explicitely closes it after fork. I said that it is unobvious is it > right to enforce FD_CLOEXEC unconditionally, because some daemons > exec() itself to reinitialize. Sorry, you're right, FD_CLOEXEC does not affect fork(2). Anyway - I'm writing regression tests for pidfile(3). Please don't commit anything until they're done. DES -- Dag-Erling Sm?rgrav - des@des.no From maksim.yevmenkin at gmail.com Mon Oct 19 14:54:17 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Mon Oct 19 14:54:24 2009 Subject: ukbd: short freeze when activating LEDs In-Reply-To: <58c737d70910181014u7c32ffd2s8c0732a707d40a2f@mail.gmail.com> References: <200909051806.07692.hselasky@c2i.net> <20090905182929.GB2829@hoeg.nl> <200910181450.11838.shoesoft@gmx.net> <58c737d70910181014u7c32ffd2s8c0732a707d40a2f@mail.gmail.com> Message-ID: On Sun, Oct 18, 2009 at 10:14 AM, Chris Ruiz wrote: > On Sun, Oct 18, 2009 at 7:50 AM, Stefan Ehmann wrote: >> On Saturday 05 September 2009 20:29:29 Ed Schouten wrote: >>> * Hans Petter Selasky wrote: >>> > On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote: >>> > > Whenever I press capslock/numlock, the system shortly (< 0.5 ms) >>> > > freezes. >>> > >>> > It might also be because the USB keyboard driver is using Giant, which >>> > can be congested. >>> >>> For half a second? I experience the same issue. I also have the same >>> issue with the Syscons VGA driver when switching windows. Some time ago >>> I talked about this with some other people and it may be possible it has >>> something to do with SMIs. Not sure... >>> >> >> Recently, I got an off-list response pointing me the "Other" section of >> http://wiki.freebsd.org/BugBusting/Commonly_reported_issues: >> "When switching consoles (e.g. Alt-F2 to switch to ttyv1), a 2-3 second delay >> is experienced" >> >> The suggested workaround (hint.kbdmux.0.disabled="1") also helps in my case. >> So it's not necessarily USB-related. > > I'm my experience the "switching consoles" delay goes away when you > remove atkbd and related options from your kernel if you only have a > usb keyboard. ?I don't have that delay with kbdmux left compiled in. > The delay most likely has something to do with locking, re: GIANT. that's somewhat right, actually. last time i looked into this, nor usb nor kbdmux(4) had really nothing to do with the delay. all kbdmux(4) does is executes the same command on all the keyboards attached to the mux. in this particular case, console switching, led toggling, etc. triggers series of ioctl() calls. now, atkdb(4) is "special" is a way that it can be instructed to attach even if no actual keyboard is present. obviously this is done so it is possible to "hot-plug" keyboard and have it work. so, when kbdmux(4) tries to execute ioctl() on non-existent keyboard, atkbd(4) is basically trying to send data to a non-existent hardware and times out. the later is basically the delay people experiencing. it is really NOT required to disable kbdmux(4) completely. just remove atkbd(4) from the mux using kbdcontrol(1). it should have exactly the same effect. once again, all of the above applied only to the case when kbdmux(4) is used with non-existing atkbd(4) keyboard. thanks, max > > -- Chris > > ----------------------------------------- > http://twitter.com/chrisattack > http://chrisattack.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From rwatson at FreeBSD.org Mon Oct 19 15:05:42 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Oct 19 15:05:49 2009 Subject: softclock swis not bound to specific cpu In-Reply-To: <20091018202407.656c3863.taku@tackymt.homeip.net> References: <20091018202407.656c3863.taku@tackymt.homeip.net> Message-ID: On Sun, 18 Oct 2009, Taku YAMAMOTO wrote: > I noticed that the softclock threads didn't seem to be bound to any cpu. > > I'm not sure whether it's the Right Thing (TM) to bind them to the > corresponding cpus though: it might be good to give the scheduler a chance > to rebalance callouts. > > I'm about to test the modification like the attached diff. Comments are > welcome. Yes, I think the intent is that they have a "soft" affinity to the CPU where the lapic timer is firing, but not a hard binding, allowing them to migrate if required. It would be interesting to measure how effective that soft affinity is in practice under various loads -- presumably the goal would be for the softclock thread to migrate if a higher (lower) priority thread is hogging the CPU. Robert N M Watson Computer Laboratory University of Cambridge From ivoras at freebsd.org Mon Oct 19 15:15:16 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Oct 19 15:15:22 2009 Subject: softclock swis not bound to specific cpu In-Reply-To: References: <20091018202407.656c3863.taku@tackymt.homeip.net> Message-ID: Robert Watson wrote: > > On Sun, 18 Oct 2009, Taku YAMAMOTO wrote: > >> I noticed that the softclock threads didn't seem to be bound to any cpu. >> >> I'm not sure whether it's the Right Thing (TM) to bind them to the >> corresponding cpus though: it might be good to give the scheduler a >> chance to rebalance callouts. >> >> I'm about to test the modification like the attached diff. Comments >> are welcome. > > Yes, I think the intent is that they have a "soft" affinity to the CPU > where the lapic timer is firing, but not a hard binding, allowing them > to migrate if required. It would be interesting to measure how > effective that soft affinity is in practice under various loads -- > presumably the goal would be for the softclock thread to migrate if a > higher (lower) priority thread is hogging the CPU. So why are there NCPU softclock threads if the binding isn't important? From ivoras at freebsd.org Mon Oct 19 15:20:06 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Oct 19 15:20:15 2009 Subject: softclock swis not bound to specific cpu In-Reply-To: References: <20091018202407.656c3863.taku@tackymt.homeip.net> Message-ID: Ivan Voras wrote: > Robert Watson wrote: >> >> On Sun, 18 Oct 2009, Taku YAMAMOTO wrote: >> >>> I noticed that the softclock threads didn't seem to be bound to any cpu. >>> >>> I'm not sure whether it's the Right Thing (TM) to bind them to the >>> corresponding cpus though: it might be good to give the scheduler a >>> chance to rebalance callouts. >>> >>> I'm about to test the modification like the attached diff. Comments >>> are welcome. >> >> Yes, I think the intent is that they have a "soft" affinity to the CPU >> where the lapic timer is firing, but not a hard binding, allowing them >> to migrate if required. It would be interesting to measure how >> effective that soft affinity is in practice under various loads -- >> presumably the goal would be for the softclock thread to migrate if a >> higher (lower) priority thread is hogging the CPU. > > So why are there NCPU softclock threads if the binding isn't important? Nevermind, I got it - they are not used only for "clock". From dmk at ncf.ca Mon Oct 19 15:56:57 2009 From: dmk at ncf.ca (Dwayne MacKinnon) Date: Mon Oct 19 16:02:21 2009 Subject: SATA DVD not found - FreeBSD 8.0-RC1 In-Reply-To: <4ADBF298.5030706@FreeBSD.org> References: <1255879383.00174464.1255866601@10.7.7.3> <1255900985.00174556.1255889404@10.7.7.3> <4ADBF298.5030706@FreeBSD.org> Message-ID: <200910191156.55547.dmk@ncf.ca> On Mon October 19 2009 01:01:12 am Alexander Motin wrote: > Hi. > > Dwayne MacKinnon wrote: > > On October 18, 2009 12:19:46 pm Gavin Atkinson wrote: > >> On Sun, 18 Oct 2009, Dwayne MacKinnon wrote: > >>> Gotta say, for the most part I'm thrilled with 8.0-RC1. Been very solid > >>> for me, no stability problems. The Linux "Emulation" works great... I > >>> have everything from Skype and Acrobat8 to UT2004 & Neverwinter Nights > >>> working. > >>> > >>> I just wanted to mention that my SATA DVD writer isn't seen when in > >>> AHCI mode. The SATA harddrive works great at UDMA150, but the CD drive > >>> isn't seen. It is seen by BIOS... I can boot off the DVD. But if I boot > >>> off the HD the DVD isn't seen. > >>> > >>> I have an ASUS M4N72-E motherboard and a LG GH22NS50 SATA DVD writer. > >>> > >>> I realize that this may be just something that will be worked out when > >>> 8.0- RELEASE hits the street. But I figured I ought to mention it > >>> regardless. > >> > >> Can you upload a verbose dmesg somewhere and post a link to it to the > >> mailing list? > > > > Done. Sorry, I should've thought of that myself. I've also posted the > > output from "atacontrol list" just for completeness. > > > > http://pastebin.com/m50035eb1 (Verbose dmesg) > > http://pastebin.com/m4a35199c (atacontrol list) > > For some reason your DVD detected as ATA disk device, not ATAPI during > bus reset: > > ata4: Identifying devices: 00000001 > > ata4: New devices: 00000001 > > It caused further problems: > > unknown: FAILURE - ATA_IDENTIFY status=51 > error=4 LBA=0 > > I have alike ASUS M4N78 PRO board and it looked like working fine when I > last tested. Can you try some other DVD drive on that board? Can you try > to load ahci module to try new CAM-based AHCI driver (be ready to drive > names change to adaX)? I don't have another SATA DVD drive, so I went with your second idea. I added ahci_load=YES to loader.conf and reconfigured /etc/fstab so that it booted properly. The end result is that I now have a working DVD drive in AHCI mode. Thank you very much... I didn't know that ahci driver existed. I've included an updated verbose dmesg for anyone who's curious. http://pastebin.com/m41fcc501 Cheers, DMK From julian at elischer.org Mon Oct 19 17:07:11 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Oct 19 17:07:18 2009 Subject: 8.0rc1 not recognizing partitions on EPIA SN In-Reply-To: <86vdibzzsq.fsf@ds4.des.no> References: <4ACE6D84.3000209@gmail.com> <4ACE833A.3030506@uffner.com> <4ACE9DFD.3010207@gmail.com> <200910131644.04358.john@baldwin.cx> <86ljja3ud5.fsf@ds4.des.no> <20091018162750.E82400@ury.york.ac.uk> <4ADBE444.1010706@elischer.org> <86vdibzzsq.fsf@ds4.des.no> Message-ID: <4ADC9CBD.1050607@elischer.org> Dag-Erling Sm?rgrav wrote: > Julian Elischer writes: >> Daniel Nebdal writes: >>> Does that mean that it's possible to write a DD-style disklabel that >>> GEOM_PART would be happy with? >> it may be as little as overwriting bytes 510 and 511 of block0. >> (the last 2 bytes of the block are a magic number) >> >> this would stop the fdisk taster from recognising it as an fdisk >> block and teh disklabel taster would recognise the disklabel. > > If by "block0" you mean the very first sector of the disk, it will also > stop the BIOS from booting from that disk... > > DES Sorry, I thought it wasnt the boot disk (my misreading) From rwatson at FreeBSD.org Mon Oct 19 17:50:12 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Oct 19 17:50:18 2009 Subject: softclock swis not bound to specific cpu In-Reply-To: References: <20091018202407.656c3863.taku@tackymt.homeip.net> Message-ID: On Mon, 19 Oct 2009, Ivan Voras wrote: >>>> I noticed that the softclock threads didn't seem to be bound to any cpu. >>>> >>>> I'm not sure whether it's the Right Thing (TM) to bind them to the >>>> corresponding cpus though: it might be good to give the scheduler a >>>> chance to rebalance callouts. >>>> >>>> I'm about to test the modification like the attached diff. Comments are >>>> welcome. >>> >>> Yes, I think the intent is that they have a "soft" affinity to the CPU >>> where the lapic timer is firing, but not a hard binding, allowing them to >>> migrate if required. It would be interesting to measure how effective >>> that soft affinity is in practice under various loads -- presumably the >>> goal would be for the softclock thread to migrate if a higher (lower) >>> priority thread is hogging the CPU. >> >> So why are there NCPU softclock threads if the binding isn't important? > > Nevermind, I got it - they are not used only for "clock". Using a soft affinity system encourages cache locality and load balancing, but allows the scheduler to compensate for occasional (or endemic) imbalance by placing work on other CPUs. A hard affinity system (in which the scheduler isn't allowed to do that) is potentially less adaptive in that regard. Obviously, there are lots of tradeoffs, but allowing ithreads and swis to wander if it turns out interrupt load (or callout scheduling, for that matter) isn't nicely balanced seems a reasonable design choice to me. What might be nice is a version of wakeup() hinting at a strong data flow between two threads, as a hint to the scheduler that maintaining CPU affinity has extra value, vs a version of wakeup() that hints at minimal data flow in which case there's reduced benefit to establishing share affinity. Robert N M Watson Computer Laboratory University of Cambridge From dougb at FreeBSD.org Mon Oct 19 18:47:29 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Oct 19 18:47:36 2009 Subject: Apparent console regressions in -current In-Reply-To: <20091019072053.GA1293@hoeg.nl> References: <4ADBF637.8090206@FreeBSD.org> <20091019072053.GA1293@hoeg.nl> Message-ID: <4ADCB440.6090903@FreeBSD.org> Ed Schouten wrote: > It should be fixed as of revision 198223. Thanks for reporting! Seems so! Thanks for the quick fix. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From jhb at freebsd.org Mon Oct 19 20:34:36 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Oct 19 20:34:49