Re: bind fails with sig11 on start / pthread failure on ARM?
On Fri, Feb 19, 2010 at 05:12:06AM +0100, Bernd Walter wrote: > On Thu, Feb 18, 2010 at 08:47:39PM -0700, M. Warner Losh wrote: > > In message: <20100219033000.gz43...@cicely7.cicely.de> > > Bernd Walter 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. #0 0x0015521c in isc_atomic_cmpxchg (p=0x155214, cmpval=0, val=1) at atomic.h:75 75 } [New Thread 20804500 (LWP 100100)] [New Thread 208043c0 (LWP 100099)] [New Thread 20804280 (LWP 100098)] [New Thread 20804140 (LWP 100043)] (gdb) bt #0 0x0015521c in isc_atomic_cmpxchg (p=0x155214, cmpval=0, val=1) at atomic.h:75 #1 0x00155a20 in isc_rwlock_lock (rwl=0x1c0fd4, type=isc_rwlocktype_write) at /data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/rwlock.c:325 #2 0x000f8144 in dns_db_register (name=0x173fe8 "_builtin", create=0x4d46c , driverarg=0x2092b078, mctx=0x2080e0c0, dbimp=0x2092b08c) at /data/builder/arm-current/head/lib/bind/dns/../../../contrib/bind9/lib/dns/db.c:821 #3 0x0004d0b4 in dns_sdb_register (drivername=0x173fe8 "_builtin", methods=Variable "methods" is not available. ) at /data/builder/arm-current/head/lib/bind/dns/../../../contrib/bind9/lib/dns/sdb.c:239 #4 0xc96c in ns_builtin_init () at /data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/builtin.c:296 #5 0x0001a97c in $a () at /data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/main.c:741 #6 0x0001a97c in $a () at /data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/main.c:741 (gdb) print p $1 = (isc_int32_t *) 0x155214 (gdb) print *p $2 = -498139128 (gdb) Initially it looks like a valid pointer. But it also looks like a pointer in codespace, which of course would be non-writeable and can't be updated. -- B.Walter 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?
Bernd Walter wrote:
On Fri, Feb 19, 2010 at 05:12:06AM +0100, Bernd Walter wrote:
On Thu, Feb 18, 2010 at 08:47:39PM -0700, M. Warner Losh wrote:
In message: <20100219033000.gz43...@cicely7.cicely.de>
Bernd Walter 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.
#0 0x0015521c in isc_atomic_cmpxchg (p=0x155214, cmpval=0, val=1) at
atomic.h:75
75 }
[New Thread 20804500 (LWP 100100)]
[New Thread 208043c0 (LWP 100099)]
[New Thread 20804280 (LWP 100098)]
[New Thread 20804140 (LWP 100043)]
(gdb) bt
#0 0x0015521c in isc_atomic_cmpxchg (p=0x155214, cmpval=0, val=1) at
atomic.h:75
#1 0x00155a20 in isc_rwlock_lock (rwl=0x1c0fd4, type=isc_rwlocktype_write)
at
/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/rwlock.c:325
#2 0x000f8144 in dns_db_register (name=0x173fe8 "_builtin", create=0x4d46c , driverarg=0x2092b078,
mctx=0x2080e0c0, dbimp=0x2092b08c) at /data/builder/arm-current/head/lib/bind/dns/../../../contrib/bind9/lib/dns/db.c:821
#3 0x0004d0b4 in dns_sdb_register (drivername=0x173fe8 "_builtin", methods=Variable
"methods" is not available.
)
at
/data/builder/arm-current/head/lib/bind/dns/../../../contrib/bind9/lib/dns/sdb.c:239
#4 0xc96c in ns_builtin_init () at
/data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/builtin.c:296
#5 0x0001a97c in $a () at
/data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/main.c:741
#6 0x0001a97c in $a () at
/data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/main.c:741
(gdb) print p
$1 = (isc_int32_t *) 0x155214
(gdb) print *p
$2 = -498139128
(gdb)
Initially it looks like a valid pointer.
But it also looks like a pointer in codespace, which of course would be
non-writeable and can't be updated.
Hi,
Some time ago we changed an address of RAS. Probably that's the problem. Please
try
with patch below.
grzesiek
diff --git a/contrib/bind9/lib/isc/arm/include/isc/atomic.h b/contrib/bind9/lib/
index 6a6e984..2f12921 100644
--- a/contrib/bind9/lib/isc/arm/include/isc/atomic.h
+++ b/contrib/bind9/lib/isc/arm/include/isc/atomic.h
@@ -53,9 +53,9 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int
__asm __volatile("1:\n"
"adr%1, 1b\n"
- "mov%0, #0xe004\n"
+ "mov%0, #0x1004\n"
"str%1, [%0]\n"
- "mov%0, #0xe008\n"
+ "mov%0, #0x1008\n"
"adr%1, 2f\n"
"str%1, [%0]\n"
"ldr%1, [%2]\n"
@@ -63,10 +63,10 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_i
"streq %4, [%2]\n"
"2:\n"
"mov%3, #0\n"
- "mov%0, #0xe004\n"
+ "mov%0, #0x1004\n"
"str%3, [%0]\n"
"mov%3, #0x\n"
- "mov%0, #0xe008\n"
+ "mov%0, #0x1008\n"
"str%3, [%0]\n"
: "=r" (ras_start), "=r" (done)
,"+r" (p), "+r" (cmpval), "+r" (val) : : "memory");
___
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 01:29:03PM +0100, Grzegorz Bernacki wrote:
> Bernd Walter wrote:
> >On Fri, Feb 19, 2010 at 05:12:06AM +0100, Bernd Walter wrote:
> >>On Thu, Feb 18, 2010 at 08:47:39PM -0700, M. Warner Losh wrote:
> >>>In message: <20100219033000.gz43...@cicely7.cicely.de>
> >>>Bernd Walter 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.
> >
> >#0 0x0015521c in isc_atomic_cmpxchg (p=0x155214, cmpval=0, val=1) at
> >atomic.h:75
> >75 }
> >[New Thread 20804500 (LWP 100100)]
> >[New Thread 208043c0 (LWP 100099)]
> >[New Thread 20804280 (LWP 100098)]
> >[New Thread 20804140 (LWP 100043)]
> >(gdb) bt
> >#0 0x0015521c in isc_atomic_cmpxchg (p=0x155214, cmpval=0, val=1) at
> >atomic.h:75
> >#1 0x00155a20 in isc_rwlock_lock (rwl=0x1c0fd4, type=isc_rwlocktype_write)
> >at
> >
> > /data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/rwlock.c:325
> >#2 0x000f8144 in dns_db_register (name=0x173fe8 "_builtin",
> >create=0x4d46c , driverarg=0x2092b078,
> >mctx=0x2080e0c0, dbimp=0x2092b08c) at
> >
> > /data/builder/arm-current/head/lib/bind/dns/../../../contrib/bind9/lib/dns/db.c:821
> >#3 0x0004d0b4 in dns_sdb_register (drivername=0x173fe8 "_builtin",
> >methods=Variable "methods" is not available.
> >)
> >at
> >
> > /data/builder/arm-current/head/lib/bind/dns/../../../contrib/bind9/lib/dns/sdb.c:239
> >#4 0xc96c in ns_builtin_init () at
> >/data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/builtin.c:296
> >#5 0x0001a97c in $a () at
> >/data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/main.c:741
> >#6 0x0001a97c in $a () at
> >/data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/main.c:741
> >(gdb) print p
> >$1 = (isc_int32_t *) 0x155214
> >(gdb) print *p
> >$2 = -498139128
> >(gdb)
> >
> >Initially it looks like a valid pointer.
> >But it also looks like a pointer in codespace, which of course would be
> >non-writeable and can't be updated.
> >
>
> Hi,
>
> Some time ago we changed an address of RAS. Probably that's the problem.
> Please try
> with patch below.
I will try, but if p really points to codespace it should be a problem
in a any of the calling functions.
> grzesiek
>
> diff --git a/contrib/bind9/lib/isc/arm/include/isc/atomic.h
> b/contrib/bind9/lib/
> index 6a6e984..2f12921 100644
> --- a/contrib/bind9/lib/isc/arm/include/isc/atomic.h
> +++ b/contrib/bind9/lib/isc/arm/include/isc/atomic.h
> @@ -53,9 +53,9 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval,
> isc_int
>
> __asm __volatile("1:\n"
> "adr%1, 1b\n"
> - "mov%0, #0xe004\n"
> + "mov%0, #0x1004\n"
> "str%1, [%0]\n"
> - "mov%0, #0xe008\n"
> + "mov%0, #0x1008\n"
> "adr%1, 2f\n"
> "str%1, [%0]\n"
> "ldr%1, [%2]\n"
> @@ -63,10 +63,10 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval,
> isc_i
> "streq %4, [%2]\n"
> "2:\n"
> "mov%3, #0\n"
> - "mov%0, #0xe004\n"
> + "mov%0, #0x1004\n"
> "str%3, [%0]\n"
> "mov%3, #0x\n"
> - "mov%0, #0xe008\n"
> + "mov%0, #0x1008\n"
> "str%3, [%0]\n"
> : "=r" (ras_start), "=r" (done)
> ,"+r" (p), "+r" (cmpval), "+r" (val) : : "memory");
>
>
--
B.Walter 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?
Bernd Walter wrote: On Fri, Feb 19, 2010 at 01:29:03PM +0100, Grzegorz Bernacki wrote: Bernd Walter wrote: On Fri, Feb 19, 2010 at 05:12:06AM +0100, Bernd Walter wrote: On Thu, Feb 18, 2010 at 08:47:39PM -0700, M. Warner Losh wrote: In message: <20100219033000.gz43...@cicely7.cicely.de> Bernd Walter 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. #0 0x0015521c in isc_atomic_cmpxchg (p=0x155214, cmpval=0, val=1) at atomic.h:75 75 } [New Thread 20804500 (LWP 100100)] [New Thread 208043c0 (LWP 100099)] [New Thread 20804280 (LWP 100098)] [New Thread 20804140 (LWP 100043)] (gdb) bt #0 0x0015521c in isc_atomic_cmpxchg (p=0x155214, cmpval=0, val=1) at atomic.h:75 #1 0x00155a20 in isc_rwlock_lock (rwl=0x1c0fd4, type=isc_rwlocktype_write) at /data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/rwlock.c:325 #2 0x000f8144 in dns_db_register (name=0x173fe8 "_builtin", create=0x4d46c , driverarg=0x2092b078, mctx=0x2080e0c0, dbimp=0x2092b08c) at /data/builder/arm-current/head/lib/bind/dns/../../../contrib/bind9/lib/dns/db.c:821 #3 0x0004d0b4 in dns_sdb_register (drivername=0x173fe8 "_builtin", methods=Variable "methods" is not available. ) at /data/builder/arm-current/head/lib/bind/dns/../../../contrib/bind9/lib/dns/sdb.c:239 #4 0xc96c in ns_builtin_init () at /data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/builtin.c:296 #5 0x0001a97c in $a () at /data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/main.c:741 #6 0x0001a97c in $a () at /data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/main.c:741 (gdb) print p $1 = (isc_int32_t *) 0x155214 (gdb) print *p $2 = -498139128 (gdb) Initially it looks like a valid pointer. But it also looks like a pointer in codespace, which of course would be non-writeable and can't be updated. Hi, Some time ago we changed an address of RAS. Probably that's the problem. Please try with patch below. I will try, but if p really points to codespace it should be a problem in a any of the calling functions. I think that gdb is lying. Function isc_rwlock_lock() calls isc_atomic_cmpxchg() like that: isc_atomic_cmpxchg(&rwl->cnt_and_flag, 0, WRITER_ACTIVE); rwl=0x1c0fd4 as you can see in backtrace above and cnt_and_flag is at offset 0x10 in rwl, so address of rwl->cnt_and_flag should be 0x1c0fd4+0x10 not 0x155214. Address of rwl should be in .bss section and 0x1c0fd4 looks good for me, so in this case a believe that gdb says true. At the begining of isc_atomic_cmpxchg() there is some like this: : sub r0, pc, #8 ; 0x8 it changes contents of r0 (which contained value of first parameter) to address of code, maybe gdb takes value of r0 and think that it contains value of first parameter. grzesiek ___ 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?
> > Some time ago we changed an address of RAS. Probably that's the problem. > Please try > with patch below. > > grzesiek Good job. IMO, ARM atomic.h should have cmpxchg and the other standard atomic routines so applications don't roll their own and they become stale. This will help application writers if we move the atomic commands from the ARMv4/ARMv5 ARM_RAS_START/ARM_RAS_END atomic method to ARMv6/ARMv7 ldrex/strex/clrex commands. --Mark Tinguely ___ 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 08:13:15AM -0600, Mark Tinguely wrote: > > > > Some time ago we changed an address of RAS. Probably that's the problem. > > Please try > > with patch below. > > > > grzesiek > > Good job. > > IMO, ARM atomic.h should have cmpxchg and the other standard atomic routines > so applications don't roll their own and they become stale. You can see an explanation in svn log: r174206 | dougb | 2007-12-03 09:26:34 +0100 (Mon, 03 Dec 2007) | 10 lines Update this file so that BIND on ARM can actually work. I quote: The problem was, isc_atomic_cmpxchg() is almost like our atomic_cmpset_32(), except it expects the old value to be returned, whereas our atomic_cmpset_32 returns 1 on success, or 0 on failure. So I re-implemented something suitable. Submitted by: cognet Reviewed by:bsdimp r170349 | dougb | 2007-06-06 00:15:38 +0200 (Wed, 06 Jun 2007) | 5 lines Add a custom atomic.h file which implements the C versions of the code we already have assembly versions of. Written by: imp > This will help application writers if we move the atomic commands from the > ARMv4/ARMv5 ARM_RAS_START/ARM_RAS_END atomic method to ARMv6/ARMv7 > ldrex/strex/clrex commands. -- B.Walter 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?
Mark Tinguely wrote: Some time ago we changed an address of RAS. Probably that's the problem. Please try with patch below. grzesiek Good job. IMO, ARM atomic.h should have cmpxchg and the other standard atomic routines so applications don't roll their own and they become stale. Yes, I agree. grzesiek ___ 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 01:29:03PM +0100, Grzegorz Bernacki wrote:
> Hi,
>
> Some time ago we changed an address of RAS. Probably that's the problem.
> Please try
> with patch below.
>
> grzesiek
>
> diff --git a/contrib/bind9/lib/isc/arm/include/isc/atomic.h
> b/contrib/bind9/lib/
> index 6a6e984..2f12921 100644
> --- a/contrib/bind9/lib/isc/arm/include/isc/atomic.h
> +++ b/contrib/bind9/lib/isc/arm/include/isc/atomic.h
> @@ -53,9 +53,9 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval,
> isc_int
>
> __asm __volatile("1:\n"
> "adr%1, 1b\n"
> - "mov%0, #0xe004\n"
> + "mov%0, #0x1004\n"
> "str%1, [%0]\n"
> - "mov%0, #0xe008\n"
> + "mov%0, #0x1008\n"
> "adr%1, 2f\n"
> "str%1, [%0]\n"
> "ldr%1, [%2]\n"
> @@ -63,10 +63,10 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval,
> isc_i
> "streq %4, [%2]\n"
> "2:\n"
> "mov%3, #0\n"
> - "mov%0, #0xe004\n"
> + "mov%0, #0x1004\n"
> "str%3, [%0]\n"
> "mov%3, #0x\n"
> - "mov%0, #0xe008\n"
> + "mov%0, #0x1008\n"
> "str%3, [%0]\n"
> : "=r" (ras_start), "=r" (done)
> ,"+r" (p), "+r" (cmpval), "+r" (val) : : "memory");
Strange:
cc -O -pipe -mcpu=arm9 -DVERSION='"9.6.1-P3"' -DHAVE_CONFIG_H -D_REENTRANT
-D_THREAD_SAFE -DLIBINTERFACE=51 -DLIBREVISION=1 -DLIBAGE=1 -DWANT_IPV6
-DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='"/var"' -DNS_SYSCONFDIR='"/etc/namedb"'
-DNAMED_CONFFILE='"/etc/namedb/named.conf"'
-DRNDC_CONFFILE='"/etc/namedb/rndc.conf"'
-DRNDC_KEYFILE='"/etc/namedb/rndc.key"'
-I/data/builder/arm-current/head/lib/bind/isc/..
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/bind9/include
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/dns/include/dst
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/dns/include
-I/data/builder/arm-current/head/lib/bind/isc/../dns
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isccc/include
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isccfg/include
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/include
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/pthreads/include
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/include
-I/data/builder/arm-current/head/lib/bind/isc/../isc
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/lwres/unix/include
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/lwres/include
-I/data/builder/arm-current/head/lib/bind/isc/../lwres
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/include
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/pthreads/include
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/include
-I/data/builder/arm-current/head/lib/bind/isc
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/arm/include
-g -std=gnu99 -c
/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/rwlock.c
{standard input}: Assembler messages:
{standard input}:69: Error: invalid constant -- `mov ip,#0x1004'
{standard input}:71: Error: invalid constant -- `mov ip,#0x1008'
{standard input}:79: Error: invalid constant -- `mov ip,#0x1004'
{standard input}:82: Error: invalid constant -- `mov ip,#0x1008'
*** Error code 1
Stop in /data/builder/arm-current/head/lib/bind/isc.
*** Error code 1
Stop in /data/builder/arm-current/head/lib/bind.
8297.000u 387.000s 2:52:06.37 84.1% -1482+1914k 134+1455io 306pf+0w
Exit 1
I fail to seee why the assembler sees it to be wrong.
It is a valid hex value - what else should the assembler take care
about?
--
B.Walter 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?
>
> Strange:
Not so much, the first values for ras_start/end were chosen to be immediate
values, so you could just mov them, but the new one aren't.
Try something like the patch attached instead (untested, I have no arm setup
here, but you'll get the idea).
Regards,
Olivier
Index: contrib/bind9/lib/isc/arm/include/isc/atomic.h
===
--- contrib/bind9/lib/isc/arm/include/isc/atomic.h (revision 203777)
+++ contrib/bind9/lib/isc/arm/include/isc/atomic.h (working copy)
@@ -49,26 +49,22 @@
static inline isc_int32_t
isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val)
{
- register int done, ras_start;
+ register int done, ras_start = #0x1004;
__asm __volatile("1:\n"
"adr%1, 1b\n"
- "mov%0, #0xe004\n"
"str%1, [%0]\n"
- "mov%0, #0xe008\n"
"adr%1, 2f\n"
- "str%1, [%0]\n"
+ "str%1, [%0, #4]\n"
"ldr%1, [%2]\n"
"cmp%1, %3\n"
"streq %4, [%2]\n"
"2:\n"
"mov%3, #0\n"
- "mov%0, #0xe004\n"
"str%3, [%0]\n"
"mov%3, #0x\n"
- "mov%0, #0xe008\n"
- "str%3, [%0]\n"
- : "=r" (ras_start), "=r" (done)
+ "str%3, [%0, #4]\n"
+ : "+r" (ras_start), "=r" (done)
,"+r" (p), "+r" (cmpval), "+r" (val) : : "memory");
return (done);
___
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: new em problems on HEAD
On Wed, 27 Jan 2010, Jack Vogel wrote: I have no idea, i see no evidence that its the em driver at fault, do you? Just for the sake of random randomness, I've noticed that my 16th January vintage kernel seems to have lost its 1 Gbit capability on the em0 connection and also seems to have intermittent interrupt storms. Of course I should really update to a more current version, and it may be more of a hardware issue anyway (especially as it may have followed a bunch of power cuts in short succession). But I thought it might be worth a mention in case it's something prior to the 16th Jan build that did it. Or not, as the case may be. :) ___ 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"
HAST (Highly Available Storage) now in HEAD.
Hi. Yesterday I committed HAST to the HEAD branch. HAST allows to transparently store data on two physically separated machines connected over the TCP/IP network. HAST works in Primary-Secondary (Master-Backup, Master-Slave) configuration, which means that only one of the cluster nodes can be active at any given time. Only Primary node is able to handle I/O requests to HAST-managed devices. Currently HAST is limited to two cluster nodes in total. HAST operates on block level - it provides disk-like devices in /dev/hast/ directory for use by file systems and/or applications. Working on block level makes it transparent for file systems and applications. There in no difference between using HAST-provided device and raw disk, partition, etc. All of them are just regular GEOM providers in FreeBSD. For more information please consult hastd(8), hastctl(8) and hast.conf(5) manual pages, as well as: http://wiki.FreeBSD.org/HAST On the wiki page above you should find instructions how to initialize hast and integrate it with ucarp. Let me know (using freebsd...@freebsd.org mailing list) if you have and questions or comments. And last, but not least, I'd like to thank sponsorswho made this projects possible: The FreeBSD Foundation, http://www.freebsdfoundation.org OMCnet Internet Service GmbH, http://www.omc.net TransIP BV, http://www.transip.nl -- Pawel Jakub Dawidek http://www.wheel.pl p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpXW0Rd7BO2p.pgp Description: PGP signature
Re: ZFS: statfs and recordsize problem
On Thu, Feb 18, 2010 at 03:39:28PM +0300, 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? I committed (slightly modified version of) your patch to HEAD. Thanks! -- Pawel Jakub Dawidek http://www.wheel.pl p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgp67WCYnRd70.pgp Description: PGP signature
Re: ATA_CAM-ed mvsata(4) on OpenRD-client
Hi. Norikatsu Shigemura wrote: > I got a OpenRD-client (Marvell 88F6281 SoC), and I'm tring to > make mvsata(4) ATA_CAM, like following: > > But I got following panic, my I help you? > In this time, I attached no devices to SATA/eSATA port. > - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - > sata0: at mem 0xf108-0xf1085fff irq > 21 on mbus0 > sata0: [MPSAFE] > sata0: [ITHREAD] > ata0: on sata0 > ata0: [MPSAFE] > ata0: [ITHREAD] > ata1: on sata0 > ata1: [MPSAFE] > ata1: [ITHREAD] > spin lock 0xc3766680 (fvH) held by 0xc3613b48 (tid -1061308344) too long > panic: spin lock held too long > KDB: enter: panic > [ thread pid 0 tid 10 ] > Stopped at 0xc09dcb50 = kdb_enter+0x48:ldrbr15, [r15, r15, ror > r15]! > db> A bit unexpected. > - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - > > So I tried to get following information: > - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - > _mtx_lock_sleep() at 0xc09a6a24 = _mtx_lock_sleep+0x10 > scp=0xc09a6a24 rlv=0xc09a6c0c (0xc09a6c0c = _mtx_lock_flags+0x7c) > rsp=0xc0d62d14 rfp=0xc0d62d3c > r10=0xc0d62d70 r9=0xc09039a8 > r8=0x r7=0x0851 r6=0xc0b47100 r5=0x > r4=0xc35dd974 > _mtx_lock_flags() at 0xc09a6ba0 = _mtx_lock_flags+0x10 > scp=0xc09a6ba0 rlv=0xc0903fac (0xc0903fac = xpt_sim_opened+0x17c) > rsp=0xc0d62d40 rfp=0xc0d62d68 > r8=0xc0bde8f0 r7=0xc090d4a4 > r6=0xc3765e00 r5=0xc0b47100 r4=0xc3766240 > xpt_sim_opened() at 0xc0903f3c = xpt_sim_opened+0x10c > scp=0xc0903f3c rlv=0xc0904068 (0xc0904068 = xpt_sim_opened+0x238) > rsp=0xc0d62d6c rfp=0xc0d62d88 > r10=0xc0bde904 r9=0xc0b47100 > r8=0x r7=0xc090d4a4 r6=0x0080 r5=0x > r4=0x0001 > xpt_sim_opened() at 0xc0904048 = xpt_sim_opened+0x218 > scp=0xc0904048 rlv=0xc0905940 (0xc0905940 = xpt_register_async+0xd0) > rsp=0xc0d62d8c rfp=0xc0d62e34 > xpt_register_async() at 0xc0905880 = xpt_register_async+0x10 > scp=0xc0905880 rlv=0xc090d484 (0xc090d484 = ata_get_xport+0x2198) > rsp=0xc0d62e38 rfp=0xc0d62e44 > r10=0x r9=0x > r8=0x005fffcc r7=0xc35593c0 r6=0xc0b62170 r5=0xc0be74d0 > r4=0x001c Even more unexpected. I've searched all sources for xpt_sim_opened() call and found only one place - in atapi-cam.c, which shouldn't be used in your case. You are using different sources, or there is a garbage in stack? -- Alexander Motin ___ 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 05:49:59PM +0100, Olivier Houchard wrote:
> >
> > Strange:
>
>
> Not so much, the first values for ras_start/end were chosen to be immediate
> values, so you could just mov them, but the new one aren't.
> Try something like the patch attached instead (untested, I have no arm setup
> here, but you'll get the idea).
I just got an idea in wqhich direction to look, just to see a lot of fog
there, but that's my problem.
I'm not very good with ARM assembly and inline assembly, although I did
know a goo amount of alpha, 6502, 68k, ... assembly.
Anyway - your patch works (with minor fix):
[213]Please.tell.me.who.am.I# host -a www.freebsd.org 127.0.0.1
Trying "www.freebsd.org"
Using domain server:
Name: 10.1.1.9
Address: 10.1.1.9#53
Aliases:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26655
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 5
;; QUESTION SECTION:
;www.freebsd.org. IN ANY
;; ANSWER SECTION:
www.freebsd.org.3600IN MX 0 .
www.freebsd.org.3600IN 2001:4f8:fff6::21
www.freebsd.org.3600IN A 69.147.83.33
;; AUTHORITY SECTION:
freebsd.org.2019IN NS ns3.isc-sns.info.
freebsd.org.2019IN NS ns2.isc-sns.com.
freebsd.org.2019IN NS ns1.isc-sns.net.
;; ADDITIONAL SECTION:
ns3.isc-sns.info. 2019IN A 63.243.194.1
ns3.isc-sns.info. 2019IN 2001:5a0:10::1
ns2.isc-sns.com.19745 IN A 38.103.2.1
ns1.isc-sns.net.19745 IN A 72.52.71.1
ns1.isc-sns.net.19745 IN 2001:470:1a::1
Received 284 bytes from 10.1.1.9#53 in 355 ms
[214]Please.tell.me.who.am.I#
>
> Regards,
>
> Olivier
> Index: contrib/bind9/lib/isc/arm/include/isc/atomic.h
> ===
> --- contrib/bind9/lib/isc/arm/include/isc/atomic.h(revision 203777)
> +++ contrib/bind9/lib/isc/arm/include/isc/atomic.h(working copy)
> @@ -49,26 +49,22 @@
> static inline isc_int32_t
> isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val)
> {
> - register int done, ras_start;
> + register int done, ras_start = #0x1004;
I had to remove the '#' in this line:
register int done, ras_start = 0x1004;
>
> __asm __volatile("1:\n"
> "adr%1, 1b\n"
> - "mov%0, #0xe004\n"
> "str%1, [%0]\n"
> - "mov%0, #0xe008\n"
> "adr%1, 2f\n"
> - "str%1, [%0]\n"
> + "str%1, [%0, #4]\n"
> "ldr%1, [%2]\n"
> "cmp%1, %3\n"
> "streq %4, [%2]\n"
> "2:\n"
> "mov%3, #0\n"
> - "mov%0, #0xe004\n"
> "str%3, [%0]\n"
> "mov%3, #0x\n"
> - "mov%0, #0xe008\n"
> - "str%3, [%0]\n"
> - : "=r" (ras_start), "=r" (done)
> + "str%3, [%0, #4]\n"
> + : "+r" (ras_start), "=r" (done)
> ,"+r" (p), "+r" (cmpval), "+r" (val) : : "memory");
> return (done);
>
--
B.Walter 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: ATA_CAM-ed mvsata(4) on OpenRD-client
In message: <4b7ef63c.7030...@freebsd.org> Alexander Motin writes: : Hi. : : Norikatsu Shigemura wrote: : > I got a OpenRD-client (Marvell 88F6281 SoC), and I'm tring to : > make mvsata(4) ATA_CAM, like following: : > : > But I got following panic, my I help you? : > In this time, I attached no devices to SATA/eSATA port. : > - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - : > sata0: at mem 0xf108-0xf1085fff irq 21 on mbus0 : > sata0: [MPSAFE] : > sata0: [ITHREAD] : > ata0: on sata0 : > ata0: [MPSAFE] : > ata0: [ITHREAD] : > ata1: on sata0 : > ata1: [MPSAFE] : > ata1: [ITHREAD] : > spin lock 0xc3766680 (fvH) held by 0xc3613b48 (tid -1061308344) too long : > panic: spin lock held too long : > KDB: enter: panic : > [ thread pid 0 tid 10 ] : > Stopped at 0xc09dcb50 = kdb_enter+0x48:ldrbr15, [r15, r15, ror r15]! : > db> : : A bit unexpected. : : > - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - : > : > So I tried to get following information: : > - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - : > _mtx_lock_sleep() at 0xc09a6a24 = _mtx_lock_sleep+0x10 : > scp=0xc09a6a24 rlv=0xc09a6c0c (0xc09a6c0c = _mtx_lock_flags+0x7c) : > rsp=0xc0d62d14 rfp=0xc0d62d3c : > r10=0xc0d62d70 r9=0xc09039a8 : > r8=0x r7=0x0851 r6=0xc0b47100 r5=0x : > r4=0xc35dd974 : > _mtx_lock_flags() at 0xc09a6ba0 = _mtx_lock_flags+0x10 : > scp=0xc09a6ba0 rlv=0xc0903fac (0xc0903fac = xpt_sim_opened+0x17c) : > rsp=0xc0d62d40 rfp=0xc0d62d68 : > r8=0xc0bde8f0 r7=0xc090d4a4 : > r6=0xc3765e00 r5=0xc0b47100 r4=0xc3766240 : > xpt_sim_opened() at 0xc0903f3c = xpt_sim_opened+0x10c : > scp=0xc0903f3c rlv=0xc0904068 (0xc0904068 = xpt_sim_opened+0x238) : > rsp=0xc0d62d6c rfp=0xc0d62d88 : > r10=0xc0bde904 r9=0xc0b47100 : > r8=0x r7=0xc090d4a4 r6=0x0080 r5=0x : > r4=0x0001 : > xpt_sim_opened() at 0xc0904048 = xpt_sim_opened+0x218 : > scp=0xc0904048 rlv=0xc0905940 (0xc0905940 = xpt_register_async+0xd0) : > rsp=0xc0d62d8c rfp=0xc0d62e34 : > xpt_register_async() at 0xc0905880 = xpt_register_async+0x10 : > scp=0xc0905880 rlv=0xc090d484 (0xc090d484 = ata_get_xport+0x2198) : > rsp=0xc0d62e38 rfp=0xc0d62e44 : > r10=0x r9=0x : > r8=0x005fffcc r7=0xc35593c0 r6=0xc0b62170 r5=0xc0be74d0 : > r4=0x001c : : Even more unexpected. I've searched all sources for xpt_sim_opened() : call and found only one place - in atapi-cam.c, which shouldn't be used : in your case. You are using different sources, or there is a garbage in : stack? IIRC, I got better stack traces when I used the kernel.tramp kernel... 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"
ZFS allows deletion of files in a sticky directory
I have found that directory entry may be deleted from a ZFS directory with the sticky bit, if "the entry is a plain file and you have write access" (this is citation from a comments in zfs_dir.c) But this behavior isn't described in the sticky(8) and isn't allowed on a UFS. The attached patch provides the UFS-like behavior of a sticky directories on a ZFS. Is this bug or feature? -- Alexander Zagrebin patch-zfs_dir.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"
Known LoR when taking bringing up bge(4) after system in multiuser?
Hi, I came across the following LoR: lock order reversal: 1st 0xc56aae04 if_afdata (if_afdata) @ /usr/home/garrcoop/ipcvs/freebsd/src/sys/net/if_llatbl.c:130 2nd 0xc58a1d80 radix node head (radix node head) @ /usr/home/garrcoop/ipcvs/freebsd/src/sys/net/route.c:360 KDB: stack backtrace: db_trace_self_wrapper(c0c6993e,c5264828,c08b173f,c08a2f35,c0c6c9d1,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08a2f35,c0c6c9d1,c5530758,c552b680,c5264884,...) at kdb_backtrace+0x29 _witness_debugger(c0c6c9d1,c58a1d80,c0c6cacb,c552b680,c0c77940,...) at _witness_debugger+0x1e witness_checkorder(c58a1d80,1,c0c77940,168,0,...) at witness_checkorder+0x818 _rw_rlock(c58a1d80,c0c77940,168,c568d2e4,1,...) at _rw_rlock+0x9c rtalloc1_fib(c5264a60,0,0,0,c526493c,...) at rtalloc1_fib+0x82 rtalloc1(c5264a60,0,0,1,0,...) at rtalloc1+0x27 in_lltable_rtcheck(c56aac00,a000,c5264a60,576,c0c7691c,...) at in_lltable_rtcheck+0x3e in_lltable_lookup(c58a1b00,a000,c5264a60,c0913e33,52098000,...) at in_lltable_lookup+0xc3 llentry_update(c52649f0,c58a1b00,c5264a60,c56aac00,c552c4b8,...) at llentry_update+0xa3 flowtable_lookup(c5739400,c5b27700,c5264a58,0,3,...) at flowtable_lookup+0x437 ip_output(c5b27700,0,0,0,0,...) at ip_output+0xf8 icmp_reflect(1,10,0,c552c6c0,c552bf70,...) at icmp_reflect+0x5cc icmp_input(c5b27700,14,c568d240,c0dafc80,c568d240,...) at icmp_input+0x3f0 ip_input(c5b27700,c5264bcc,c07235f4,c0dafc80,0,...) at ip_input+0x619 netisr_dispatch_src(1,0,c5b27700,c5264c04,c091c349,...) at netisr_dispatch_src+0xcb netisr_dispatch(1,c5b27700,c56aac00,c56aac00,c5b74002,...) at netisr_dispatch+0x20 ether_demux(c56aac00,c5b27700,3,0,3) at ether_demux+0x193 ether_input(c56aac00,c5b27700,c0c250e6,d41,c56b7008,...) at ether_input+0x355 bge_rxeof(c56b7008,0,c0c250e6,e13,c56b7008,...) at bge_rxeof+0x2b9 bge_intr(c56b7000,c5264cc8,c085f65d,c0dc8880,c5576a38,...) at bge_intr+0x107 intr_event_execute_handlers(c55717f8,c5576a00,c0c61560,533,c5576a70,...) at intr_event_execute_handlers+0x10f ithread_loop(c56b26c0,c5264d38,c0c612a1,343,c55717f8,...) at ithread_loop+0x98 fork_exit(c084923c,c56b26c0,c5264d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc5264d70, ebp = 0 --- when I did the following steps [once]: echo "ifconfig_bge0=\"DHCP\"" >> /etc/rc.conf /etc/rc.d/netif start using srcs from cvs pulled in the last 2 days or so... I'll gladly provide more details when requested. Thanks, -Garrett ___ 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"
