Re: FYI: v4l-linuxulator support in FreeBSD-current now [panic]
On Tuesday 12 January 2010 18:49:48 Hans Petter Selasky wrote:
Re: FYI: v4l-linuxulator support in FreeBSD-current now
Hi,
Some panics have cropped up when using linux-V4L with webcamd.
1st) panic: freeing memory in linux_v4l_cliplist_free() which is not
allocated, but there seems to be more which needs to be done.
I tried to fix something, but it was apparently not enough.
Help appreciated.
One question: Do we need to handle the IOCTL's in question at all in the
linuxulator?
--HPS
--- linux_ioctl.c.orig 2010-02-17 20:42:53.0 +0100
+++ linux_ioctl.c 2010-02-17 21:03:10.0 +0100
@@ -2711,7 +2711,7 @@
/* XXX: If there can be no concurrency: s/M_NOWAIT/M_WAITOK/ */
if ((*ppvc = malloc(sizeof(**ppvc), M_LINUX, M_NOWAIT)) == NULL)
return (ENOMEM);/* XXX: linux has no ENOMEM here */
- memcpy(vclip, *ppvc, sizeof(vclip));
+ memcpy(*ppvc, vclip, sizeof(vclip));
(*ppvc)-next = NULL;
return (0);
}
@@ -2719,13 +2719,15 @@
static int
linux_v4l_cliplist_free(struct video_window *vw)
{
- struct video_clip **ppvc;
- struct video_clip **ppvc_next;
+ struct video_clip *ppvc;
+ struct video_clip *ppvc_next;
- for (ppvc = (vw-clips); *ppvc != NULL; ppvc = ppvc_next) {
- ppvc_next = ((*ppvc)-next);
- free(*ppvc, M_LINUX);
+ for (ppvc = vw-clips; ppvc != NULL; ppvc = ppvc_next) {
+ ppvc_next = ppvc-next;
+ free(ppvc, M_LINUX);
}
+ vw-clips = NULL;
+
return (0);
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: lang/perl5.10 broken
On Wed, Feb 17, 2010 at 06:49:17PM +0100, Bernd Walter wrote: On Wed, Feb 17, 2010 at 10:01:13AM -0700, M. Warner Losh wrote: In message: 20100217152557.gw43...@cicely7.cicely.de Bernd Walter ti...@cicely7.cicely.de writes: : Not sure if this is ARM related or not. ... : *** Signal 11 Silly question: do you have enough swap space enabled? First try was with 128M on internal SD of which usually just about 10M is used during compiler runs and the second was with 1G on external USB SD reader, but just because of speed with internal. I also saw no kernel message that the system was out of space. I'm currently trying to compile perl5.8, but it takes some time. perl5.8 seems to work fine. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ZFS: statfs and recordsize problem
I have noticed, that statfs called for ZFS file systems, returns the value of FS's recordsize property in both f_bsize and f_iosize. It's a problem for some software. For example, squid uses block size of cache's file system to calculate the space occupied by file. So by default it considers that any small file uses 128KB of a cache (when default value of recordsize is used), though really this file may use 512B only. This miscalculation leads to unreasonable cleaning of a cache. IMHO the behavior of statfs have to be changed, as ZFS uses variable (up to recordsize) block sizes. It must return 512 as f_bsize and recordsize as f_iosize. One of possible solutions is the attached patch. Could somebody look it? -- Alexander Zagrebin patch-zfs_vfsops.c Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bind fails with sig11 on start / pthread failure on ARM?
On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote: On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote: [55]Please.tell.me.who.am.I# gdb /usr/sbin/named named.core 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 arm-marcel-freebsd...(no debugging symbols found)... Core was generated by `named'. Program terminated with signal 5, Trace/breakpoint trap. Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 [New Thread 20804280 (LWP 100062)] [New Thread 20804140 (LWP 100052)] (gdb) bt #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 #1 0x203572b8 in _thread_bp_death () from /lib/libthr.so.3 #2 0x20349da4 in pthread_create () from /lib/libthr.so.3 #3 0x00164cb8 in ?? () (gdb) Do we have a general threading problem on ARM? I see two different type a crashes. Both have in common that one or more threads are in _umtx_op. Unfortunately I don't know enough details about those things to isolate any more. the one from above: #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 [New Thread 20804280 (LWP 100062)] [New Thread 20804140 (LWP 100052)] (gdb) bt #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 #1 0x203572b8 in _thread_bp_death () from /lib/libthr.so.3 #2 0x20349da4 in pthread_create () from /lib/libthr.so.3 #3 0x00164cb8 in ?? () (gdb) thread 1 [Switching to thread 1 (Thread 20804280 (LWP 100062))]#0 0x203ab6f0 in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x203ab6f0 in _umtx_op () from /lib/libc.so.7 #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 #2 0x20357cc0 in pthread_cleanup_push () from /lib/libthr.so.3 #3 0x20349540 in pthread_getprio () from /lib/libthr.so.3 #4 0x203499a0 in pthread_create () from /lib/libthr.so.3 #5 0x00164cb8 in ?? () And another, which is what I get most of the time: (gdb) thread 1 [Switching to thread 1 (Thread 20804500 (LWP 100100))]#0 0x20435f28 in kevent () from /lib/libc.so.7 (gdb) bt #0 0x20435f28 in kevent () from /lib/libc.so.7 #1 0x0014f2dc in ?? () (gdb) thread 2 [Switching to thread 2 (Thread 208043c0 (LWP 100099))]#0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 #2 0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3 #3 0x20355580 in pthread_cond_signal () from /lib/libthr.so.3 #4 0x in ?? () (gdb) thread 3 [Switching to thread 3 (Thread 20804280 (LWP 100098))]#0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 #2 0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3 #3 0x20355580 in pthread_cond_signal () from /lib/libthr.so.3 #4 0x2092d008 in ?? () (gdb) thread 4 [Switching to thread 4 (Thread 20804140 (LWP 100043))]#0 0x0015755c in ?? () (gdb) bt #0 0x0015755c in ?? () -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bind fails with sig11 on start / pthread failure on ARM?
On Thu, Feb 18, 2010 at 01:49:07PM +0100, Bernd Walter wrote: On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote: On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote: [55]Please.tell.me.who.am.I# gdb /usr/sbin/named named.core 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 arm-marcel-freebsd...(no debugging symbols found)... Core was generated by `named'. Program terminated with signal 5, Trace/breakpoint trap. Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 [New Thread 20804280 (LWP 100062)] [New Thread 20804140 (LWP 100052)] (gdb) bt #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 #1 0x203572b8 in _thread_bp_death () from /lib/libthr.so.3 #2 0x20349da4 in pthread_create () from /lib/libthr.so.3 #3 0x00164cb8 in ?? () (gdb) Do we have a general threading problem on ARM? I see two different type a crashes. Both have in common that one or more threads are in _umtx_op. Unfortunately I don't know enough details about those things to isolate any more. the one from above: #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 [New Thread 20804280 (LWP 100062)] [New Thread 20804140 (LWP 100052)] (gdb) bt #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 #1 0x203572b8 in _thread_bp_death () from /lib/libthr.so.3 #2 0x20349da4 in pthread_create () from /lib/libthr.so.3 #3 0x00164cb8 in ?? () (gdb) thread 1 [Switching to thread 1 (Thread 20804280 (LWP 100062))]#0 0x203ab6f0 in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x203ab6f0 in _umtx_op () from /lib/libc.so.7 #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 #2 0x20357cc0 in pthread_cleanup_push () from /lib/libthr.so.3 #3 0x20349540 in pthread_getprio () from /lib/libthr.so.3 #4 0x203499a0 in pthread_create () from /lib/libthr.so.3 #5 0x00164cb8 in ?? () And another, which is what I get most of the time: (gdb) thread 1 [Switching to thread 1 (Thread 20804500 (LWP 100100))]#0 0x20435f28 in kevent () from /lib/libc.so.7 (gdb) bt #0 0x20435f28 in kevent () from /lib/libc.so.7 #1 0x0014f2dc in ?? () (gdb) thread 2 [Switching to thread 2 (Thread 208043c0 (LWP 100099))]#0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 #2 0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3 #3 0x20355580 in pthread_cond_signal () from /lib/libthr.so.3 #4 0x in ?? () (gdb) thread 3 [Switching to thread 3 (Thread 20804280 (LWP 100098))]#0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 #2 0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3 #3 0x20355580 in pthread_cond_signal () from /lib/libthr.so.3 #4 0x2092d008 in ?? () (gdb) thread 4 [Switching to thread 4 (Thread 20804140 (LWP 100043))]#0 0x0015755c in ?? () (gdb) bt #0 0x0015755c in ?? () Compile and install ld-elf.so, libc and libthr with debugging symbols: (cd libexec/rtld-elf make all install DEBUG_FLAGS=-g) (cd lib/libc make all install DEBUG_FLAGS=-g) (cd lib/libthr make all install DEBUG_FLAGS=-g) Then repeat the crash and try to see where in code does it happen. pgpTpSnhpmCLF.pgp Description: PGP signature
shutdown -p now reboots server instead off power down
Hello all. I have a proliant ML110 server, with the latest FreeBSD 9.0 current. (cvsuped today) When i do a shutdown - p now on the system, it reboots instead of the power down it used to do. regards Johan Hendriks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
Can you paste the exact error? Are you getting something like: error 1: lba 32 error 1: lba 1 When I've seen the above sequence, it was due to a stack overflow (IIRC), with the result that the loader would start a second time and barf out these errors. The large number in the error might give us a clue as to what's going on. If the number is really large, it might be an indication that your BIOS doesn't reliably read past a certain threshold. ZFS writes a sort of label at the beginning and end of its drives; perhaps the loader is trying to read the label at the end of the disk and is failing (I don't recall whether it tries to read both labels). Matt Matt, Here's exactly what I'm seeing after POST: error 1 lba 179552888 error 1 lba 59243926 ZFS: i/o error - all block copies unavailable FreeBSD/i386 boot Default: zroot:/boot/kernel/kernel boot: error 1 lba 179552888 error 1 lba 59243926 ZFS: i/o error - all block copies unavailable FreeBSD/i386 boot Default: zroot:/boot/kernel/kernel boot: It may or may not be related, but I notice that while in this state my hard drive activity light stays on. Thanks, Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS: statfs and recordsize problem
On Thursday 18 February 2010 7:39:28 am Alexander Zagrebin wrote: I have noticed, that statfs called for ZFS file systems, returns the value of FS's recordsize property in both f_bsize and f_iosize. It's a problem for some software. For example, squid uses block size of cache's file system to calculate the space occupied by file. So by default it considers that any small file uses 128KB of a cache (when default value of recordsize is used), though really this file may use 512B only. This miscalculation leads to unreasonable cleaning of a cache. IMHO the behavior of statfs have to be changed, as ZFS uses variable (up to recordsize) block sizes. It must return 512 as f_bsize and recordsize as f_iosize. One of possible solutions is the attached patch. Could somebody look it? If you don't get a reply, submit it as a PR so it doesn't get lost. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Promise SuperTrak EX8350 RAID driver for FreeBSD-Current
Hi! Could anyone help me? How bring this card to work in FreeBSD-Current? Sergei. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: shutdown -p now reboots server instead off power down
On Thu, 2010-02-18 at 14:15 +0100, Johan Hendriks wrote: Hello all. I have a proliant ML110 server, with the latest FreeBSD 9.0 current. (cvsuped today) When i do a shutdown - p now on the system, it reboots instead of the power down it used to do. Which version was the last that successfully powered down? Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
On Thu, Feb 18, 2010 at 5:31 AM, Chris behrnetwo...@gmail.com wrote: Can you paste the exact error? Are you getting something like: error 1: lba 32 error 1: lba 1 When I've seen the above sequence, it was due to a stack overflow (IIRC), with the result that the loader would start a second time and barf out these errors. The large number in the error might give us a clue as to what's going on. If the number is really large, it might be an indication that your BIOS doesn't reliably read past a certain threshold. ZFS writes a sort of label at the beginning and end of its drives; perhaps the loader is trying to read the label at the end of the disk and is failing (I don't recall whether it tries to read both labels). Matt Matt, Here's exactly what I'm seeing after POST: error 1 lba 179552888 error 1 lba 59243926 ZFS: i/o error - all block copies unavailable Hmm, both those LBAs fit in 28 bits. With a modern BIOS I wouldn't expect problems with those LBAs. It may or may not be related, but I notice that while in this state my hard drive activity light stays on. I think you're probably right about this being a BIOS problem. Does the gptzfsboot 'status' command show the same output when you run it with and without the F12 workaround? Here's what I see from FreeBSD and from gptzfsboot: [root ~]# zpool status pool: glamdring state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM glamdring ONLINE 0 0 0 raidz2 ONLINE 0 0 0 label/glamdring-0 ONLINE 0 0 0 label/glamdring-1 ONLINE 0 0 0 label/glamdring-2 ONLINE 0 0 0 label/glamdring-3 ONLINE 0 0 0 label/glamdring-4 ONLINE 0 0 0 label/glamdring-5 ONLINE 0 0 0 errors: No known data errors ... /boot.config: -Dh Default: glamdring:/boot/zfsloader boot: status pool: glamdring config: NAME STATE glamdring ONLINE raidz2 ONLINE label/glamdring-0 ONLINE label/glamdring-1 ONLINE label/glamdring-2 ONLINE label/glamdring-3 ONLINE label/glamdring-4 ONLINE label/glamdring-5 ONLINE Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bind fails with sig11 on start / pthread failure on ARM?
On Thu, Feb 18, 2010 at 03:10:10PM +0200, Kostik Belousov wrote: On Thu, Feb 18, 2010 at 01:49:07PM +0100, Bernd Walter wrote: On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote: On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote: [55]Please.tell.me.who.am.I# gdb /usr/sbin/named named.core 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 arm-marcel-freebsd...(no debugging symbols found)... Core was generated by `named'. Program terminated with signal 5, Trace/breakpoint trap. Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 [New Thread 20804280 (LWP 100062)] [New Thread 20804140 (LWP 100052)] (gdb) bt #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 #1 0x203572b8 in _thread_bp_death () from /lib/libthr.so.3 #2 0x20349da4 in pthread_create () from /lib/libthr.so.3 #3 0x00164cb8 in ?? () (gdb) Do we have a general threading problem on ARM? I see two different type a crashes. Both have in common that one or more threads are in _umtx_op. Unfortunately I don't know enough details about those things to isolate any more. the one from above: #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 [New Thread 20804280 (LWP 100062)] [New Thread 20804140 (LWP 100052)] (gdb) bt #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 #1 0x203572b8 in _thread_bp_death () from /lib/libthr.so.3 #2 0x20349da4 in pthread_create () from /lib/libthr.so.3 #3 0x00164cb8 in ?? () (gdb) thread 1 [Switching to thread 1 (Thread 20804280 (LWP 100062))]#0 0x203ab6f0 in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x203ab6f0 in _umtx_op () from /lib/libc.so.7 #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 #2 0x20357cc0 in pthread_cleanup_push () from /lib/libthr.so.3 #3 0x20349540 in pthread_getprio () from /lib/libthr.so.3 #4 0x203499a0 in pthread_create () from /lib/libthr.so.3 #5 0x00164cb8 in ?? () And another, which is what I get most of the time: (gdb) thread 1 [Switching to thread 1 (Thread 20804500 (LWP 100100))]#0 0x20435f28 in kevent () from /lib/libc.so.7 (gdb) bt #0 0x20435f28 in kevent () from /lib/libc.so.7 #1 0x0014f2dc in ?? () (gdb) thread 2 [Switching to thread 2 (Thread 208043c0 (LWP 100099))]#0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 #2 0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3 #3 0x20355580 in pthread_cond_signal () from /lib/libthr.so.3 #4 0x in ?? () (gdb) thread 3 [Switching to thread 3 (Thread 20804280 (LWP 100098))]#0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 #2 0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3 #3 0x20355580 in pthread_cond_signal () from /lib/libthr.so.3 #4 0x2092d008 in ?? () (gdb) thread 4 [Switching to thread 4 (Thread 20804140 (LWP 100043))]#0 0x0015755c in ?? () (gdb) bt #0 0x0015755c in ?? () Compile and install ld-elf.so, libc and libthr with debugging symbols: (cd libexec/rtld-elf make all install DEBUG_FLAGS=-g) (cd lib/libc make all install DEBUG_FLAGS=-g) (cd lib/libthr make all install DEBUG_FLAGS=-g) Then repeat the crash and try to see where in code does it happen. It is still compiling, but since kdump was fixed recently (thanks guys!) I already have some other data. But to be honest I don't see anything usefull in it. The last entry before the segfault was a successfull syslog submission. Hope the compiler finishes soon to get more detailed backtraces. [...] 59537 namedCALL kevent(0x8,0xbfffe91c,0x1,0,0,0) 59537 namedGIO fd 8 wrote 20 bytes 0x 0500 0100 || 59537 namedGIO fd 8 read 0 bytes 59537 namedRET kevent 0 59537
Re: bind fails with sig11 on start / pthread failure on ARM?
On Thu, Feb 18, 2010 at 03:10:10PM +0200, Kostik Belousov wrote: On Thu, Feb 18, 2010 at 01:49:07PM +0100, Bernd Walter wrote: On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote: On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote: [55]Please.tell.me.who.am.I# gdb /usr/sbin/named named.core 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 arm-marcel-freebsd...(no debugging symbols found)... Core was generated by `named'. Program terminated with signal 5, Trace/breakpoint trap. Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 [New Thread 20804280 (LWP 100062)] [New Thread 20804140 (LWP 100052)] (gdb) bt #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 #1 0x203572b8 in _thread_bp_death () from /lib/libthr.so.3 #2 0x20349da4 in pthread_create () from /lib/libthr.so.3 #3 0x00164cb8 in ?? () (gdb) Do we have a general threading problem on ARM? I see two different type a crashes. Both have in common that one or more threads are in _umtx_op. Unfortunately I don't know enough details about those things to isolate any more. the one from above: #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 [New Thread 20804280 (LWP 100062)] [New Thread 20804140 (LWP 100052)] (gdb) bt #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 #1 0x203572b8 in _thread_bp_death () from /lib/libthr.so.3 #2 0x20349da4 in pthread_create () from /lib/libthr.so.3 #3 0x00164cb8 in ?? () (gdb) thread 1 [Switching to thread 1 (Thread 20804280 (LWP 100062))]#0 0x203ab6f0 in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x203ab6f0 in _umtx_op () from /lib/libc.so.7 #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 #2 0x20357cc0 in pthread_cleanup_push () from /lib/libthr.so.3 #3 0x20349540 in pthread_getprio () from /lib/libthr.so.3 #4 0x203499a0 in pthread_create () from /lib/libthr.so.3 #5 0x00164cb8 in ?? () And another, which is what I get most of the time: (gdb) thread 1 [Switching to thread 1 (Thread 20804500 (LWP 100100))]#0 0x20435f28 in kevent () from /lib/libc.so.7 (gdb) bt #0 0x20435f28 in kevent () from /lib/libc.so.7 #1 0x0014f2dc in ?? () (gdb) thread 2 [Switching to thread 2 (Thread 208043c0 (LWP 100099))]#0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 #2 0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3 #3 0x20355580 in pthread_cond_signal () from /lib/libthr.so.3 #4 0x in ?? () (gdb) thread 3 [Switching to thread 3 (Thread 20804280 (LWP 100098))]#0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 #2 0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3 #3 0x20355580 in pthread_cond_signal () from /lib/libthr.so.3 #4 0x2092d008 in ?? () (gdb) thread 4 [Switching to thread 4 (Thread 20804140 (LWP 100043))]#0 0x0015755c in ?? () (gdb) bt #0 0x0015755c in ?? () Compile and install ld-elf.so, libc and libthr with debugging symbols: (cd libexec/rtld-elf make all install DEBUG_FLAGS=-g) (cd lib/libc make all install DEBUG_FLAGS=-g) (cd lib/libthr make all install DEBUG_FLAGS=-g) Then repeat the crash and try to see where in code does it happen. Currently I can only get this type. I've started the unstripped named to get all the function names. (gdb) thread 1 [Switching to thread 1 (Thread 20804500 (LWP 100100))]#0 0x20435308 in kevent () at kevent.S:3 3 RSYSCALL(kevent) Current language: auto; currently asm (gdb) bt #0 0x20435308 in kevent () at kevent.S:3 #1 0x0014f2dc in watcher () #2 0x203495b0 in thread_start (curthread=0x20804500) at /data/builder/arm-current/head/lib/libthr/thread/thr_create.c:288 #3 0x20349a20 in _pthread_create (thread=0x2046caa8, attr=0xbfffe7f8, start_routine=0x14f2ac watcher, arg=Variable arg is not available. )
Re: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
I think you're probably right about this being a BIOS problem. Does the gptzfsboot 'status' command show the same output when you run it with and without the F12 workaround? Here's what I see from FreeBSD and from gptzfsboot: [root ~]# zpool status pool: glamdring state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM glamdring ONLINE 0 0 0 raidz2 ONLINE 0 0 0 label/glamdring-0 ONLINE 0 0 0 label/glamdring-1 ONLINE 0 0 0 label/glamdring-2 ONLINE 0 0 0 label/glamdring-3 ONLINE 0 0 0 label/glamdring-4 ONLINE 0 0 0 label/glamdring-5 ONLINE 0 0 0 errors: No known data errors ... /boot.config: -Dh Default: glamdring:/boot/zfsloader boot: status pool: glamdring config: NAME STATE glamdring ONLINE raidz2 ONLINE label/glamdring-0 ONLINE label/glamdring-1 ONLINE label/glamdring-2 ONLINE label/glamdring-3 ONLINE label/glamdring-4 ONLINE label/glamdring-5 ONLINE Matt I'm seeing some difference in the bootloader output between using the F12 workaround or not: F12 workaround mode: FreeBSD/i386 boot Default: zroot:/boot/zfsloader boot: status config: NAME STATE zrootONLINE gpt/disk0 ONLINE No F12 key pressed: FreeBSD/i386 boot Default: zroot:/boot/kernel/kernel config: NAME STATE zrootONLINE gpt/disk0 ONLINE What's up with the differences between the Default boot setting? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bind fails with sig11 on start / pthread failure on ARM?
In message: 20100219031200.gy43...@cicely7.cicely.de Bernd Walter ti...@cicely7.cicely.de writes: : On Thu, Feb 18, 2010 at 03:10:10PM +0200, Kostik Belousov wrote: : On Thu, Feb 18, 2010 at 01:49:07PM +0100, Bernd Walter wrote: : On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote: :On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote: :[55]Please.tell.me.who.am.I# gdb /usr/sbin/named named.core :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 arm-marcel-freebsd...(no debugging symbols found)... :Core was generated by `named'. :Program terminated with signal 5, Trace/breakpoint trap. :Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done. :Loaded symbols for /lib/libcrypto.so.6 :Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. :Loaded symbols for /lib/libthr.so.3 :Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. :Loaded symbols for /lib/libc.so.7 :Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. :Loaded symbols for /libexec/ld-elf.so.1 :#0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 :[New Thread 20804280 (LWP 100062)] :[New Thread 20804140 (LWP 100052)] :(gdb) bt :#0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 :#1 0x203572b8 in _thread_bp_death () from /lib/libthr.so.3 :#2 0x20349da4 in pthread_create () from /lib/libthr.so.3 :#3 0x00164cb8 in ?? () :(gdb) : :Do we have a general threading problem on ARM? : : I see two different type a crashes. : Both have in common that one or more threads are in _umtx_op. : Unfortunately I don't know enough details about those things to isolate : any more. : : the one from above: : #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 : [New Thread 20804280 (LWP 100062)] : [New Thread 20804140 (LWP 100052)] : (gdb) bt : #0 0x203571b0 in _thread_bp_create () from /lib/libthr.so.3 : #1 0x203572b8 in _thread_bp_death () from /lib/libthr.so.3 : #2 0x20349da4 in pthread_create () from /lib/libthr.so.3 : #3 0x00164cb8 in ?? () : (gdb) thread 1 : [Switching to thread 1 (Thread 20804280 (LWP 100062))]#0 0x203ab6f0 in _umtx_op () from /lib/libc.so.7 : (gdb) bt : #0 0x203ab6f0 in _umtx_op () from /lib/libc.so.7 : #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 : #2 0x20357cc0 in pthread_cleanup_push () from /lib/libthr.so.3 : #3 0x20349540 in pthread_getprio () from /lib/libthr.so.3 : #4 0x203499a0 in pthread_create () from /lib/libthr.so.3 : #5 0x00164cb8 in ?? () : : And another, which is what I get most of the time: : (gdb) thread 1 : [Switching to thread 1 (Thread 20804500 (LWP 100100))]#0 0x20435f28 in kevent () from /lib/libc.so.7 : (gdb) bt : #0 0x20435f28 in kevent () from /lib/libc.so.7 : #1 0x0014f2dc in ?? () : (gdb) thread 2 : [Switching to thread 2 (Thread 208043c0 (LWP 100099))]#0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 : (gdb) bt : #0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 : #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 : #2 0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3 : #3 0x20355580 in pthread_cond_signal () from /lib/libthr.so.3 : #4 0x in ?? () : (gdb) thread 3 : [Switching to thread 3 (Thread 20804280 (LWP 100098))]#0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 : (gdb) bt : #0 0x203ab6f4 in _umtx_op () from /lib/libc.so.7 : #1 0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3 : #2 0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3 : #3 0x20355580 in pthread_cond_signal () from /lib/libthr.so.3 : #4 0x2092d008 in ?? () : (gdb) thread 4 : [Switching to thread 4 (Thread 20804140 (LWP 100043))]#0 0x0015755c in ?? () : (gdb) bt : #0 0x0015755c in ?? () : : Compile and install ld-elf.so, libc and libthr with debugging symbols: : (cd libexec/rtld-elf make all install DEBUG_FLAGS=-g) : (cd lib/libc make all install DEBUG_FLAGS=-g) : (cd lib/libthr make all install DEBUG_FLAGS=-g) : : Then repeat the crash and try to see where in code does it happen. : : Currently I can only get this type. : I've started the unstripped named to get all the function names. : : (gdb) thread 1 : [Switching to thread 1 (Thread 20804500 (LWP 100100))]#0 0x20435308 in kevent () at kevent.S:3 : 3 RSYSCALL(kevent) : Current language: auto; currently asm : (gdb) bt : #0 0x20435308 in kevent () at kevent.S:3 : #1 0x0014f2dc
Re: bind fails with sig11 on start / pthread failure on ARM?
On Fri, Feb 19, 2010 at 04:12:00AM +0100, Bernd Walter wrote: On Thu, Feb 18, 2010 at 03:10:10PM +0200, Kostik Belousov wrote: On Thu, Feb 18, 2010 at 01:49:07PM +0100, Bernd Walter wrote: On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote: On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote: [Switching to thread 4 (Thread 20804140 (LWP 100053))]#0 0x0015755c in isc_atomic_cmpxchg () (gdb) bt #0 0x0015755c in isc_atomic_cmpxchg () #1 0x00157dac in isc_rwlock_lock () #2 0x000f9790 in dns_db_register () #3 0x0004d590 in dns_sdb_register () #4 0xc974 in ns_builtin_init () #5 0x0001aa90 in $a () #6 0x0001aa90 in $a () isc_atomic_cmpxchg really sounds quite interesting though. It is not only the crashing function it is also a type of function which sounds error prune. For me it looks like a bug in bind itself. It is in contrib/bind9/lib/isc/arm/include/isc/atomic.h. My assumption is that either the assembly is broken or it gets an invalid pointer. I'm not very expirienced with ARM assembly. Warner - it names you in the copyright, so very likely you know this code. I will build a debug version of bind, but as usual it will take some time... -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Seeing the dreaded ZFS: i/o error - all block copies unavailable on 9.0-CURRENT
I'm seeing some difference in the bootloader output between using the F12 workaround or not: F12 workaround mode: FreeBSD/i386 boot Default: zroot:/boot/zfsloader boot: status config: NAME STATE zroot ONLINE gpt/disk0 ONLINE No F12 key pressed: FreeBSD/i386 boot Default: zroot:/boot/kernel/kernel config: NAME STATE zroot ONLINE gpt/disk0 ONLINE What's up with the differences between the Default boot setting? Sorry for the spam but I'm seeing something else very interesting If I boot to Good Mode (F12) and break to the boot: prompt, the system boots if I type /boot/zfsloader. However, if I type /boot/kernel/kernel (as was seen in the Default setting when I didn't hit F12), I get a crash that looks like the following: - FreeBSD/i386 boot Default: zroot:/boot/zfsloader boot: /boot/kernel/kernel int=0006err= efl=00010882 eip=0020 eax=0018b070 ebx=ed7706bd ecx=c72e2ca8 edx= esi=0040 edi=000929d0 ebp=0009279c esp=9401 cs=0008 ds=0010 es=0010 fs=0010 gs=0010 ss=0010 cs:eip=ff ff ff ff ff ff ff ff 7f-00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ss:esp=36 80 0d 07 90 00 00 01-e9 c4 fc ff ff aa ac 84 c0 0f 84 86 00 00 00 a8-80 74 f2 88 c5 b0 3d aa BTX halted - McCoy: He's dead, Jim. Kirk: Bones, do something! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bind fails with sig11 on start / pthread failure on ARM?
On Fri, Feb 19, 2010 at 04:30:00AM +0100, Bernd Walter wrote: On Fri, Feb 19, 2010 at 04:12:00AM +0100, Bernd Walter wrote: On Thu, Feb 18, 2010 at 03:10:10PM +0200, Kostik Belousov wrote: On Thu, Feb 18, 2010 at 01:49:07PM +0100, Bernd Walter wrote: On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote: On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote: [Switching to thread 4 (Thread 20804140 (LWP 100053))]#0 0x0015755c in isc_atomic_cmpxchg () (gdb) bt #0 0x0015755c in isc_atomic_cmpxchg () #1 0x00157dac in isc_rwlock_lock () #2 0x000f9790 in dns_db_register () #3 0x0004d590 in dns_sdb_register () #4 0xc974 in ns_builtin_init () #5 0x0001aa90 in $a () #6 0x0001aa90 in $a () isc_atomic_cmpxchg really sounds quite interesting though. It is not only the crashing function it is also a type of function which sounds error prune. For me it looks like a bug in bind itself. It is in contrib/bind9/lib/isc/arm/include/isc/atomic.h. My assumption is that either the assembly is broken or it gets an invalid pointer. I'm not very expirienced with ARM assembly. Warner - it names you in the copyright, so very likely you know this code. I will build a debug version of bind, but as usual it will take some time... Maybe it helps in the meanwhile: (gdb) disassemble 0x0015755c Dump of assembler code for function isc_atomic_cmpxchg: 0x00157550 isc_atomic_cmpxchg+0: mov r3, r0 0x00157554 isc_atomic_cmpxchg+4: sub r0, pc, #8 ; 0x8 0x00157558 isc_atomic_cmpxchg+8: mov r12, #-536870908; 0xe004 0x0015755c isc_atomic_cmpxchg+12: str r0, [r12] 0x00157560 isc_atomic_cmpxchg+16: mov r12, #-536870904; 0xe008 0x00157564 isc_atomic_cmpxchg+20: add r0, pc, #12 ; 0xc 0x00157568 isc_atomic_cmpxchg+24: str r0, [r12] 0x0015756c isc_atomic_cmpxchg+28: ldr r0, [r3] 0x00157570 isc_atomic_cmpxchg+32: cmp r0, r1 0x00157574 isc_atomic_cmpxchg+36: streq r2, [r3] 0x00157578 isc_atomic_cmpxchg+40: mov r1, #0 ; 0x0 0x0015757c isc_atomic_cmpxchg+44: mov r12, #-536870908; 0xe004 0x00157580 isc_atomic_cmpxchg+48: str r1, [r12] 0x00157584 isc_atomic_cmpxchg+52: mvn r1, #0 ; 0x0 0x00157588 isc_atomic_cmpxchg+56: mov r12, #-536870904; 0xe008 0x0015758c isc_atomic_cmpxchg+60: str r1, [r12] 0x00157590 isc_atomic_cmpxchg+64: mov pc, lr End of assembler dump. Seems to be the str in line 57, which is crashing. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bind fails with sig11 on start / pthread failure on ARM?
On Thu, Feb 18, 2010 at 08:40:12PM -0700, M. Warner Losh wrote: In message: 20100219033000.gz43...@cicely7.cicely.de Bernd Walter ti...@cicely7.cicely.de writes: : On Fri, Feb 19, 2010 at 04:12:00AM +0100, Bernd Walter wrote: : On Thu, Feb 18, 2010 at 03:10:10PM +0200, Kostik Belousov wrote: : On Thu, Feb 18, 2010 at 01:49:07PM +0100, Bernd Walter wrote: :On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote: : On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote: : [Switching to thread 4 (Thread 20804140 (LWP 100053))]#0 0x0015755c in isc_atomic_cmpxchg () : (gdb) bt : #0 0x0015755c in isc_atomic_cmpxchg () : #1 0x00157dac in isc_rwlock_lock () : #2 0x000f9790 in dns_db_register () : #3 0x0004d590 in dns_sdb_register () : #4 0xc974 in ns_builtin_init () : #5 0x0001aa90 in $a () : #6 0x0001aa90 in $a () : : isc_atomic_cmpxchg really sounds quite interesting though. : It is not only the crashing function it is also a type of function which : sounds error prune. : : For me it looks like a bug in bind itself. : It is in contrib/bind9/lib/isc/arm/include/isc/atomic.h. : My assumption is that either the assembly is broken or it gets an : invalid pointer. : I'm not very expirienced with ARM assembly. : Warner - it names you in the copyright, so very likely you know this code. : I will build a debug version of bind, but as usual it will take some : time... Damn. It wasn't me. Oh, wait, maybe it was... :-) I'll try to look at it tomorrow... Thank you. Recompiling libbind and named with debug support also takes some time. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bind fails with sig11 on start / pthread failure on ARM?
In message: 20100219033000.gz43...@cicely7.cicely.de Bernd Walter ti...@cicely7.cicely.de writes: : Warner - it names you in the copyright, so very likely you know this code. : I will build a debug version of bind, but as usual it will take some : time... Make sure that the code matches our current atomics code... Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bind fails with sig11 on start / pthread failure on ARM?
On Thu, Feb 18, 2010 at 08:47:39PM -0700, M. Warner Losh wrote: In message: 20100219033000.gz43...@cicely7.cicely.de Bernd Walter ti...@cicely7.cicely.de writes: : Warner - it names you in the copyright, so very likely you know this code. : I will build a debug version of bind, but as usual it will take some : time... Make sure that the code matches our current atomics code... There are just 3 functions. isc_atomic_xadd and isc_atomic_store just wrap to atomic_fetchadd_int and atomic_store_rel_int isc_atomic_cmpxchg is inline assembly, but I don't think we have such a function in our ARM atomic.h - at least I can't find it. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: shutdown -p now reboots server instead off power down
Hello all. I have a proliant ML110 server, with the latest FreeBSD 9.0 current. (cvsuped today) When i do a shutdown - p now on the system, it reboots instead of the power down it used to do. Which version was the last that successfully powered down? Gavin I really can not tell. I installed it from cd and then do a buildworld around every 2 days. I always reboot (shutdown -r) but last time we had some maintenance to do at the power net. So i needed to shutdown the server. Then i discovered that a -p did not powerdown the server anymore. regrads, JOhan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
