Re: [CFT] Improved ZFS metaslab code (faster write speed)
On Fri, Aug 27, 2010 at 6:24 PM, jhell wrote: > On 08/27/2010 19:50, Artem Belevich wrote: >> Another "me too" here. >> >> 8-stable/amd64 + v15 (zpool still uses v14) + metaslab + >> abe_stat_rrwlock + A.Gapon's vm_paging_needed() + uma defrag patches. >> >> The box survived few days of pounding on it without any signs of trouble. >> > > I must have missed the uma defrag patches but according to the code Here is the UMA patch I was talking about: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2010-08/msg00188.html > those patches should not have any effect on your implimentation of ZFS > on your system because vfs.zfs.zio.use_uma defaults to off unless you > have manually turned this on or the patch reverts that facility back to > its original form. Hmm. Indeed. Kmem_malloc carves memory allocations directly from kmem. Yet the difference in max ARC size with the patch applied is there. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2010-08/msg00257.html Perhaps reduced UMA fragmentation helps those subsystem that do use UMA (including ZFS which always uses uma for various housekeeping data). --Artem ___ 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: [CFT] Improved ZFS metaslab code (faster write speed)
On 08/27/2010 19:50, Artem Belevich wrote:
> Another "me too" here.
>
> 8-stable/amd64 + v15 (zpool still uses v14) + metaslab +
> abe_stat_rrwlock + A.Gapon's vm_paging_needed() + uma defrag patches.
>
> The box survived few days of pounding on it without any signs of trouble.
>
I must have missed the uma defrag patches but according to the code
those patches should not have any effect on your implimentation of ZFS
on your system because vfs.zfs.zio.use_uma defaults to off unless you
have manually turned this on or the patch reverts that facility back to
its original form.
Running on a full ZFSv15 system with the metaslab & rrwlock patches and
a slightly modified patch from avg@ for vm_paging_needed() I was able to
achieve the results in read and write ops that I was looking for.
The modified patch from avg@ (portion patch) is:
#ifdef _KERNEL
if (arc_reclaim_needed()) {
needfree = 0;
wakeup(&needfree);
}
#endif
I still moved that down to below _KERNEL for the obvious reasons. But
when I was using the original patch with if (needfree) I noticed a
performance degradation after ~12 hours of use with and without UMA
turned on. So far with ~48 hours of testing with the top half of that
being with the above change, I have not seen more degradation of
performance after that ~12 hour mark.
In another 12 hours of testing with UMA turned off Ill be turning UMA
back on and testing for another 24 hours. Before that third patch from
avg@ had come along I had turned UMA on and had no performance loss for
~7 hours. Obviously I had to reboot after applying avg@'s patch and
decided to test strictly without UMA at that point.
There seems to be a problem in the logic behind the needfree use and or
arc_reclaim_needed() area that should be worked out, but at least for
this system i386 8.1-STABLE where my code is at right now "Is STABLE!".
===
For reference I have also adjusted these: (arc.c)
- /* Start out with 1/8 of all memory */
- arc_c = kmem_size() / 8;
+ /* Start out with 1/4 of all memory */
+ arc_c = kmem_size() / 4;
And these: (arc.c)
- arc_c = MIN(arc_c, vmem_size(heap_arena, VMEM_ALLOC | VMEM_FREE) / 8);
+ arc_c = MIN(arc_c, vmem_size(heap_arena, VMEM_ALLOC | VMEM_FREE) / 4);
There seems to be no relative way currently to handle adjusting these
properly based on the amount of memory in the system and sets a blind
default currently to 1/8 and in a system with 2GB that is ~256MB but if
you are adjusting to kmem_size as stated above and you set KVA_PAGES to
512 like suggested, then you end up with an arc_c equaling 64MB. So
unless you adjust your kmem_size accordingly on some systems to make up
for the 1/8th problem your ZFS install is going to suffer. This is more
of a problem for systems below the 2GB memory range. Now for systems
that have quite high ranges of memory 8G for example your really only
using 1GB and it will be fairly hard besides adjusting the source to use
more RAM without effecting something else in the system inherently by
bumping vm.kmem_size*
===
1GB RAM on ZFSv15 with the patches mentioned: (loader.conf) adjust
accordingly to your own systems environment.
kern.maxdsiz="640M"
kern.maxusers="512" # Overcome the max calculated 384 for >1G of MEM.
# See: /sys/kern/subr_param.c for details. ???
vfs.zfs.arc_min="62M"
vfs.zfs.arc_max="496M"
vfs.zfs.prefetch_disable=0
vm.kmem_size="512M"
vm.kmem_size_max="768M"
vm.kmem_size_min="128M"
Regards,
--
jhell,v
___
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: [CFT] Improved ZFS metaslab code (faster write speed)
Another "me too" here. 8-stable/amd64 + v15 (zpool still uses v14) + metaslab + abe_stat_rrwlock + A.Gapon's vm_paging_needed() + uma defrag patches. The box survived few days of pounding on it without any signs of trouble. --Artem On Fri, Aug 27, 2010 at 4:19 PM, Norikatsu Shigemura wrote: > Hi mm. > > On Fri, 27 Aug 2010 16:05:00 -0400 > Scott Ullrich wrote: >> On Sun, Aug 22, 2010 at 12:26 PM, Martin Matuska wrote: >> > Thank you, I have updated the v15 patch for 8-STABLE. >> I have been running your patch for a couple days now and no issues. >> Nice work! > > Yes, me too. I'll try to zpool/zfs upgrade! > I'm waiting for your update v15, metaslab and abe_stat_rrwlock:-). > > -- > Norikatsu Shigemura > ___ > 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" > ___ 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: [CFT] Improved ZFS metaslab code (faster write speed)
Hi mm. On Fri, 27 Aug 2010 16:05:00 -0400 Scott Ullrich wrote: > On Sun, Aug 22, 2010 at 12:26 PM, Martin Matuska wrote: > > Thank you, I have updated the v15 patch for 8-STABLE. > I have been running your patch for a couple days now and no issues. > Nice work! Yes, me too. I'll try to zpool/zfs upgrade! I'm waiting for your update v15, metaslab and abe_stat_rrwlock:-). -- Norikatsu Shigemura ___ 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"
[head tinderbox] failure on powerpc64/powerpc
TB --- 2010-08-27 20:41:32 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-27 20:41:32 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-27 20:41:32 - cleaning the object tree TB --- 2010-08-27 20:41:48 - cvsupping the source tree TB --- 2010-08-27 20:41:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-27 21:01:08 - building world TB --- 2010-08-27 21:01:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-27 21:01:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-27 21:01:08 - TARGET=powerpc TB --- 2010-08-27 21:01:08 - TARGET_ARCH=powerpc64 TB --- 2010-08-27 21:01:08 - TZ=UTC TB --- 2010-08-27 21:01:08 - __MAKE_CONF=/dev/null TB --- 2010-08-27 21:01:08 - cd /src TB --- 2010-08-27 21:01:08 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 27 21:01:09 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ===> gnu/lib/libgomp (all) cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/alloc.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/barrier.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/critical.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c In file included from /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c:32: ./libgomp_f.h: In function 'omp_check_defines': ./libgomp_f.h:65: error: size of array 'test' is negative *** Error code 1 Stop in /src/gnu/lib/libgomp. *** Error code 1 Stop in /src/gnu/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-27 21:29:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-27 21:29:04 - ERROR: failed to build world TB --- 2010-08-27 21:29:04 - 1144.83 user 376.58 system 2851.64 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ 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: [CFT] Improved ZFS metaslab code (faster write speed)
On Sun, Aug 22, 2010 at 12:26 PM, Martin Matuska wrote: > Thank you, I have updated the v15 patch for 8-STABLE. I have been running your patch for a couple days now and no issues. Nice work! Scott ___ 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: [CFT] ZFS ACL and rrwlock speedup
2010/8/24 Martin Matuska : > Dear FreeBSD community, > > in my last CFT I presented a patch that improves ZFS write speed. There > have been easily portable improvements on the read side in OpenSolaris, > too. Of course, the improvement here is by far not that dramatic as in > the zfs_metaslab.patch, but OpenSolaris developers claim this also > improves the speed of stat() calls. > > I would like to Call For Testing for the following patch (9-CURRENT): > http://people.freebsd.org/~mm/patches/zfs/zfs_abe_stat_rrwlock.patch > > This patch adds the following: > - better ACL caching and speedup of the ACL permission checks > - lowered mutex contention in the read/writer lock (rrwlock) > - several bugfixes > > This patch does not interfere with the zfs_metaslab.patch > > To apply the patch against 8-STABLE, you need to apply the v15 update first: > http://people.freebsd.org/~mm/patches/zfs/v15/stable-8-v15.patch > > The patch imports the following OpenSolaris onnv revisions: > 9749 (without zlook), 9866, 9981, 10143, 10232, 10295, 10250, 10269 > > And covers the following OpenSolaris Bug IDs: > 6802734 Support for Access Based Enumeration (not used on FreeBSD) > 6844861 inconsistent xattr readdir behavior with too-small buffer > 6848431 zfs with rstchown=0 or file_chown_self privilege allows user to > "take" ownership > 6775100 stat() performance on files on zfs should be improved > 6827779 rrwlock is overly protective of its counters > 6857433 memory leaks found at: zfs_acl_alloc/zfs_acl_node_alloc > 6860318 truncate() on zfsroot succeeds when file has a component of its > path set without access permission > 6865875 zfs sometimes incorrectly giving search access to a dir > 6870564 panic in zfs_getsecattr > 6867395 zpool_upgrade_007_pos testcase panic'd with BAD TRAP: type=e > (#pf Page fault) > 6868276 zfs_rezget() can be hazardous when znode has a cached ACL So far so good on this patch as well. Running it for a good 3 days with 4TB and it is nice and fast (220MB/sec for 1.5 TB drives). Scott ___ 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: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes
On Fri, Aug 27, 2010 at 09:46:35PM +0200, Fabian Keil wrote: > > diff --git a/lib/libc/stdlib/atexit.c b/lib/libc/stdlib/atexit.c > > index 97cf234..511172a 100644 > > --- a/lib/libc/stdlib/atexit.c > > +++ b/lib/libc/stdlib/atexit.c > > @@ -200,6 +200,6 @@ __cxa_finalize(void *dso) > > if (dso == NULL) > > _MUTEX_DESTROY(&atexit_mutex); > > > > - if (&__pthread_cxa_finalize != NULL) > > + if (has_phdr && &__pthread_cxa_finalize != NULL) > > __pthread_cxa_finalize(&phdr_info); > > } > > That fixed it. Thanks a lot. Thank for your help, fixed in r211894. pgpr3GJ9fm8d0.pgp Description: PGP signature
Re: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes
Kostik Belousov wrote:
> On Fri, Aug 27, 2010 at 09:25:34PM +0200, Fabian Keil wrote:
> > Kostik Belousov wrote:
> >
> > > On Fri, Aug 27, 2010 at 06:21:08PM +0200, Fabian Keil wrote:
> > > > The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for
> > > > me. It aborts on exit (C-x C-c) after receiving SIGBUS:
> > > > Reverting to lib/libc/stdlib/atexit.c 1.9 gets it working again,
> > > > using 1.11 brings back the crashes. I didn't csup between those
> > > > versions and thus don't have 1.10 in git, but given that it's a
> > > > style change it shouldn't matter.
> > > >
> > > > I'm using amd64 and so far I only noticed the problem with emacs.
> > > >
> > > > Is anyone else seeing this?
> > > Reverting the atexit change might cover the issue in some other place.
> > > Please build and install rtld, libc and libthr with symbolic
> > > debug information. On of the way to do this is to:
> > > cd /usr/src/libexec/rtld-elf
> > > make obj && make depend && make all install DEBUG_FLAGS=-g
> > > cd ../../lib/libc
> > > make obj && make depend && make all install DEBUG_FLAGS=-g
> > > cd ../../lib/libthr
> > > make obj && make depend && make all install DEBUG_FLAGS=-g
> > >
> > > Then, reproduce the crash and get "bt full" output from the
> > > core. I may need some further information after that.
> >
> > #0 0x0008045dd44c in kill () at kill.S:3
> > 3 RSYSCALL(kill)
> > [New Thread 1260600 (LWP 100244)]
> > (gdb) bt full
> > #0 0x0008045dd44c in kill () at kill.S:3
> > No locals.
> > #1 0x005545c0 in fatal_error_signal (sig=10) at emacs.c:402
> > No locals.
> > #2
> > No symbol table info available.
> > #3 __elf_phdr_match_addr (phdr_info=0x7fffcf90, addr=0x69ba20) at
> > /usr/src/lib/libc/gen/elf_utils.c:39
> > i = 109
> > #4 0x000803038fdb in __pthread_cxa_finalize (phdr_info=0x7fffcf90)
> > at /usr/src/lib/libthr/thread/thr_fork.c:109
> > af = (struct pthread_atfork *) 0xe1e7c0
> > af1 = (struct pthread_atfork *) 0x0
> > #5 0x0008045be0a7 in __cxa_finalize (dso=0x0) at
> > /usr/src/lib/libc/stdlib/atexit.c:204
> > phdr_info = {dlpi_addr = 0, dlpi_name = 0x7fffd080 "`\177",
> > dlpi_phdr = 0x7fffe848, dlpi_phnum = 59448, dlpi_adds = 0, dlpi_subs =
> > 34367899629,
> > dlpi_tls_modid = 15046784, dlpi_tls_data = 0x12c2538}
> > p = (struct atexit *) 0x0
> > fn = {fn_type = 1, fn_ptr = {std_func = 0x8007ccff0 ,
> > cxa_func = 0x8007ccff0 }, fn_arg = 0x0, fn_dso = 0x0}
> > n = -1
> > has_phdr = 0
> > #6 0x0008045683c7 in exit (status=0) at
> > /usr/src/lib/libc/stdlib/exit.c:67
> > No locals.
> > #7 0x00556817 in Fkill_emacs (arg=Could not find the frame base
> > for "Fkill_emacs".
> > ) at emacs.c:2146
> > gcpro1 = Could not find the frame base for "Fkill_emacs".
> > Current language: auto; currently asm
> Ewww. Please try this.
>
> diff --git a/lib/libc/stdlib/atexit.c b/lib/libc/stdlib/atexit.c
> index 97cf234..511172a 100644
> --- a/lib/libc/stdlib/atexit.c
> +++ b/lib/libc/stdlib/atexit.c
> @@ -200,6 +200,6 @@ __cxa_finalize(void *dso)
> if (dso == NULL)
> _MUTEX_DESTROY(&atexit_mutex);
>
> - if (&__pthread_cxa_finalize != NULL)
> + if (has_phdr && &__pthread_cxa_finalize != NULL)
> __pthread_cxa_finalize(&phdr_info);
> }
That fixed it. Thanks a lot.
Fabian
signature.asc
Description: PGP signature
Re: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes
On Fri, Aug 27, 2010 at 09:25:34PM +0200, Fabian Keil wrote: > Kostik Belousov wrote: > > > On Fri, Aug 27, 2010 at 06:21:08PM +0200, Fabian Keil wrote: > > > The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for > > > me. It aborts on exit (C-x C-c) after receiving SIGBUS: > > > > > > f...@r500 ~ $gdb emacs > > > 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 "amd64-marcel-freebsd"... > > > (gdb) run > > > Starting program: /usr/local/bin/emacs > > > [New LWP 100281] > > > [New Thread 1260600 (LWP 100281)] > > > > > > Program received signal SIGBUS, Bus error. > > > [Switching to Thread 1260600 (LWP 100281)] > > > 0x0008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 > > > (gdb) where > > > #0 0x0008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 > > > #1 0x000803038abb in __pthread_cxa_finalize () > > > from /lib/libthr.so.3 #2 0x0008045bdfa7 in __cxa_finalize () > > > from /lib/libc.so.7 #3 0x0008045682c7 in exit () > > > from /lib/libc.so.7 #4 0x00556817 in Fkill_emacs (arg=Could > > > not find the frame base for "Fkill_emacs". ) at emacs.c:2146 > > > #5 0x00600ec0 in Ffuncall (nargs=1, args=0x7fffc880) at > > > eval.c:3024 #6 0x00658d47 in Fbyte_code (bytestr=8602321, > > > vector=8602357, maxdepth=20) at bytecode.c:680 #7 0x006017e6 > > > in funcall_lambda (fun=8602229, nargs=0, arg_vector=0x7fffcdc8) at > > > eval.c:3211 #8 0x006011e0 in Ffuncall (nargs=1, > > > args=0x7fffcdc0) at eval.c:3070 #9 0x00658d47 in > > > Fbyte_code (bytestr=9558105, vector=9558141, maxdepth=20) at > > > bytecode.c:680 #10 0x006017e6 in funcall_lambda (fun=9558029, > > > nargs=1, arg_vector=0x7fffd358) at eval.c:3211 #11 > > > 0x006011e0 in Ffuncall (nargs=2, args=0x7fffd350) at > > > eval.c:3070 #12 0x005fb954 in Fcall_interactively > > > (function=11961778, record_flag=11544578, keys=20138021) at > > > callint.c:869 #13 0x00600f36 in Ffuncall (nargs=4, > > > args=0x7fffd760) at eval.c:3030 #14 0x006008fd in call3 > > > (fn=11756290, arg1=11961778, arg2=11544578, arg3=20138021) at > > > eval.c:2850 #15 0x0056b7ac in Fcommand_execute (cmd=11961778, > > > record_flag=11544578, keys=20138021, special=11544674) at > > > keyboard.c:10507 #16 0x0055cc69 in read_char (commandflag=1, > > > nmaps=2, maps=0x7fffdb70, prev_event=11544578, > > > used_mouse_menu=0x7fffded4, end_time=0x0) at keyboard.c:3166 #17 > > > 0x0056880e in read_key_sequence (keybuf=0x7fffe280, > > > bufsize=30, prompt=11544578, dont_downcase_last=0, > > > can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9512 > > > #18 0x00558a33 in command_loop_1 () at keyboard.c:1643 #19 > > > 0x005fe0aa in internal_condition_case (bfun=0x5586a0 > > > , handlers=11629954, hfun=0x557f90 ) at > > > eval.c:1490 #20 0x0055836a in command_loop_2 () at > > > keyboard.c:1360 #21 0x005fda2c in internal_catch > > > (tag=11621170, func=0x558350 , arg=11544578) at > > > eval.c:1226 #22 0x00558320 in command_loop () at > > > keyboard.c:1339 #23 0x00557a85 in recursive_edit_1 () at > > > keyboard.c:954 #24 0x00557c45 in Frecursive_edit () at > > > keyboard.c:1016 #25 0x005560b8 in main (argc=1, > > > argv=0x7fffe840) at emacs.c:1833 > > > > > > Reverting to lib/libc/stdlib/atexit.c 1.9 gets it working again, > > > using 1.11 brings back the crashes. I didn't csup between those > > > versions and thus don't have 1.10 in git, but given that it's a > > > style change it shouldn't matter. > > > > > > I'm using amd64 and so far I only noticed the problem with emacs. > > > > > > Is anyone else seeing this? > > Reverting the atexit change might cover the issue in some other place. > > Please build and install rtld, libc and libthr with symbolic > > debug information. On of the way to do this is to: > > cd /usr/src/libexec/rtld-elf > > make obj && make depend && make all install DEBUG_FLAGS=-g > > cd ../../lib/libc > > make obj && make depend && make all install DEBUG_FLAGS=-g > > cd ../../lib/libthr > > make obj && make depend && make all install DEBUG_FLAGS=-g > > > > Then, reproduce the crash and get "bt full" output from the > > core. I may need some further information after that. > > #0 0x0008045dd44c in kill () at kill.S:3 > 3 RSYSCALL(kill) > [New Thread 1260600 (LWP 100244)] > (gdb) bt full > #0 0x0008045dd44c in kill () at kill.S:3 > No locals. > #1 0x005545c0 in fatal_error_signal (sig=10) at emacs.c:402 > No
kernel panic and corrupt vmcore
Installed a kernel based on yesterday's src/ tree. The kernel panicked and the generated core seems to be corrupt. Is there a known issue with getting core dumps on x86_64 freebsd? The top of the core.txt.0 file shows troutmask.apl.washington.edu dumped core - see /usr/tmp/vmcore.0 Fri Aug 27 11:26:26 PDT 2010 FreeBSD troutmask.apl.washington.edu 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r211766M: Tue Aug 24 14:52:25 PDT 2010 ka...@troutmask.apl.washington.edu:/usr/obj/usr/src/sys/SPEW amd64 panic: page fault 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 "amd64-marcel-freebsd"... Cannot access memory at address 0xff01ffe0 (kgdb) #0 0x in ?? () Cannot access memory at address 0x0 (kgdb) If anyone wants the entire content of core.txt.0, simply request it. My was doing the following when the panic occurred: 1) Running rsync via cron to back up /usr/home accounts from /dev/ad6s1f to /dev/ad4s1f. Both file systems use softupdates+journaling. 2) Building ports/www/firefox (which is version 3.6.8) 3) Running the GCC dejagnu testsuite for the gfortran compiler 4) Using firefox-3.5.11 to view a site that drives the Xorg srever to 90% CPU usage. -- Steve ___ 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: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes
Kostik Belousov wrote: > On Fri, Aug 27, 2010 at 06:21:08PM +0200, Fabian Keil wrote: > > The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for > > me. It aborts on exit (C-x C-c) after receiving SIGBUS: > > > > f...@r500 ~ $gdb emacs > > 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 "amd64-marcel-freebsd"... > > (gdb) run > > Starting program: /usr/local/bin/emacs > > [New LWP 100281] > > [New Thread 1260600 (LWP 100281)] > > > > Program received signal SIGBUS, Bus error. > > [Switching to Thread 1260600 (LWP 100281)] > > 0x0008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 > > (gdb) where > > #0 0x0008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 > > #1 0x000803038abb in __pthread_cxa_finalize () > > from /lib/libthr.so.3 #2 0x0008045bdfa7 in __cxa_finalize () > > from /lib/libc.so.7 #3 0x0008045682c7 in exit () > > from /lib/libc.so.7 #4 0x00556817 in Fkill_emacs (arg=Could > > not find the frame base for "Fkill_emacs". ) at emacs.c:2146 > > #5 0x00600ec0 in Ffuncall (nargs=1, args=0x7fffc880) at > > eval.c:3024 #6 0x00658d47 in Fbyte_code (bytestr=8602321, > > vector=8602357, maxdepth=20) at bytecode.c:680 #7 0x006017e6 > > in funcall_lambda (fun=8602229, nargs=0, arg_vector=0x7fffcdc8) at > > eval.c:3211 #8 0x006011e0 in Ffuncall (nargs=1, > > args=0x7fffcdc0) at eval.c:3070 #9 0x00658d47 in > > Fbyte_code (bytestr=9558105, vector=9558141, maxdepth=20) at > > bytecode.c:680 #10 0x006017e6 in funcall_lambda (fun=9558029, > > nargs=1, arg_vector=0x7fffd358) at eval.c:3211 #11 > > 0x006011e0 in Ffuncall (nargs=2, args=0x7fffd350) at > > eval.c:3070 #12 0x005fb954 in Fcall_interactively > > (function=11961778, record_flag=11544578, keys=20138021) at > > callint.c:869 #13 0x00600f36 in Ffuncall (nargs=4, > > args=0x7fffd760) at eval.c:3030 #14 0x006008fd in call3 > > (fn=11756290, arg1=11961778, arg2=11544578, arg3=20138021) at > > eval.c:2850 #15 0x0056b7ac in Fcommand_execute (cmd=11961778, > > record_flag=11544578, keys=20138021, special=11544674) at > > keyboard.c:10507 #16 0x0055cc69 in read_char (commandflag=1, > > nmaps=2, maps=0x7fffdb70, prev_event=11544578, > > used_mouse_menu=0x7fffded4, end_time=0x0) at keyboard.c:3166 #17 > > 0x0056880e in read_key_sequence (keybuf=0x7fffe280, > > bufsize=30, prompt=11544578, dont_downcase_last=0, > > can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9512 > > #18 0x00558a33 in command_loop_1 () at keyboard.c:1643 #19 > > 0x005fe0aa in internal_condition_case (bfun=0x5586a0 > > , handlers=11629954, hfun=0x557f90 ) at > > eval.c:1490 #20 0x0055836a in command_loop_2 () at > > keyboard.c:1360 #21 0x005fda2c in internal_catch > > (tag=11621170, func=0x558350 , arg=11544578) at > > eval.c:1226 #22 0x00558320 in command_loop () at > > keyboard.c:1339 #23 0x00557a85 in recursive_edit_1 () at > > keyboard.c:954 #24 0x00557c45 in Frecursive_edit () at > > keyboard.c:1016 #25 0x005560b8 in main (argc=1, > > argv=0x7fffe840) at emacs.c:1833 > > > > Reverting to lib/libc/stdlib/atexit.c 1.9 gets it working again, > > using 1.11 brings back the crashes. I didn't csup between those > > versions and thus don't have 1.10 in git, but given that it's a > > style change it shouldn't matter. > > > > I'm using amd64 and so far I only noticed the problem with emacs. > > > > Is anyone else seeing this? > Reverting the atexit change might cover the issue in some other place. > Please build and install rtld, libc and libthr with symbolic > debug information. On of the way to do this is to: > cd /usr/src/libexec/rtld-elf > make obj && make depend && make all install DEBUG_FLAGS=-g > cd ../../lib/libc > make obj && make depend && make all install DEBUG_FLAGS=-g > cd ../../lib/libthr > make obj && make depend && make all install DEBUG_FLAGS=-g > > Then, reproduce the crash and get "bt full" output from the > core. I may need some further information after that. #0 0x0008045dd44c in kill () at kill.S:3 3 RSYSCALL(kill) [New Thread 1260600 (LWP 100244)] (gdb) bt full #0 0x0008045dd44c in kill () at kill.S:3 No locals. #1 0x005545c0 in fatal_error_signal (sig=10) at emacs.c:402 No locals. #2 No symbol table info available. #3 __elf_phdr_match_addr (phdr_info=0x7fffcf90, addr=0x69ba20) at /usr/src/lib/libc/gen/elf_utils.c:39 i = 109 #4 0x000803038fdb in __pthread_cxa_finalize (phdr_info=0x7fffcf90)
Re: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes
On Fri, Aug 27, 2010 at 06:21:08PM +0200, Fabian Keil wrote: > The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for me. > It aborts on exit (C-x C-c) after receiving SIGBUS: > > f...@r500 ~ $gdb emacs > 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 "amd64-marcel-freebsd"... > (gdb) run > Starting program: /usr/local/bin/emacs > [New LWP 100281] > [New Thread 1260600 (LWP 100281)] > > Program received signal SIGBUS, Bus error. > [Switching to Thread 1260600 (LWP 100281)] > 0x0008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 > (gdb) where > #0 0x0008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 > #1 0x000803038abb in __pthread_cxa_finalize () from /lib/libthr.so.3 > #2 0x0008045bdfa7 in __cxa_finalize () from /lib/libc.so.7 > #3 0x0008045682c7 in exit () from /lib/libc.so.7 > #4 0x00556817 in Fkill_emacs (arg=Could not find the frame base for > "Fkill_emacs". > ) at emacs.c:2146 > #5 0x00600ec0 in Ffuncall (nargs=1, args=0x7fffc880) at > eval.c:3024 > #6 0x00658d47 in Fbyte_code (bytestr=8602321, vector=8602357, > maxdepth=20) at bytecode.c:680 > #7 0x006017e6 in funcall_lambda (fun=8602229, nargs=0, > arg_vector=0x7fffcdc8) at eval.c:3211 > #8 0x006011e0 in Ffuncall (nargs=1, args=0x7fffcdc0) at > eval.c:3070 > #9 0x00658d47 in Fbyte_code (bytestr=9558105, vector=9558141, > maxdepth=20) at bytecode.c:680 > #10 0x006017e6 in funcall_lambda (fun=9558029, nargs=1, > arg_vector=0x7fffd358) at eval.c:3211 > #11 0x006011e0 in Ffuncall (nargs=2, args=0x7fffd350) at > eval.c:3070 > #12 0x005fb954 in Fcall_interactively (function=11961778, > record_flag=11544578, keys=20138021) at callint.c:869 > #13 0x00600f36 in Ffuncall (nargs=4, args=0x7fffd760) at > eval.c:3030 > #14 0x006008fd in call3 (fn=11756290, arg1=11961778, arg2=11544578, > arg3=20138021) at eval.c:2850 > #15 0x0056b7ac in Fcommand_execute (cmd=11961778, > record_flag=11544578, keys=20138021, special=11544674) at keyboard.c:10507 > #16 0x0055cc69 in read_char (commandflag=1, nmaps=2, > maps=0x7fffdb70, prev_event=11544578, used_mouse_menu=0x7fffded4, > end_time=0x0) > at keyboard.c:3166 > #17 0x0056880e in read_key_sequence (keybuf=0x7fffe280, > bufsize=30, prompt=11544578, dont_downcase_last=0, can_return_switch_frame=1, > fix_current_buffer=1) at keyboard.c:9512 > #18 0x00558a33 in command_loop_1 () at keyboard.c:1643 > #19 0x005fe0aa in internal_condition_case (bfun=0x5586a0 > , handlers=11629954, hfun=0x557f90 ) at eval.c:1490 > #20 0x0055836a in command_loop_2 () at keyboard.c:1360 > #21 0x005fda2c in internal_catch (tag=11621170, func=0x558350 > , arg=11544578) at eval.c:1226 > #22 0x00558320 in command_loop () at keyboard.c:1339 > #23 0x00557a85 in recursive_edit_1 () at keyboard.c:954 > #24 0x00557c45 in Frecursive_edit () at keyboard.c:1016 > #25 0x005560b8 in main (argc=1, argv=0x7fffe840) at emacs.c:1833 > > Reverting to lib/libc/stdlib/atexit.c 1.9 gets it working again, > using 1.11 brings back the crashes. I didn't csup between those > versions and thus don't have 1.10 in git, but given that it's a > style change it shouldn't matter. > > I'm using amd64 and so far I only noticed the problem with emacs. > > Is anyone else seeing this? Reverting the atexit change might cover the issue in some other place. Please build and install rtld, libc and libthr with symbolic debug information. On of the way to do this is to: cd /usr/src/libexec/rtld-elf make obj && make depend && make all install DEBUG_FLAGS=-g cd ../../lib/libc make obj && make depend && make all install DEBUG_FLAGS=-g cd ../../lib/libthr make obj && make depend && make all install DEBUG_FLAGS=-g Then, reproduce the crash and get "bt full" output from the core. I may need some further information after that. Thank you for the report. pgpeYbDV5z7nJ.pgp Description: PGP signature
Re: a question about FreeBSD
On Fri, Aug 27, 2010 at 11:05 AM, V. T. Mueller, Continum wrote: > Freddie Cash wrote: Also, try man top. >> >> -C will show stats for individual CPUs at the top of the screen >> (similar to pressing 0 in top on Linux). This was added to top in 7.2 >> or 7.3 or thereabouts. > > You mean top -P Whoops, you're right. That's what I get for looking at "echo $TOP" and guessing at which of CHP did it, instead of reading the man page. :) -- Freddie Cash fjwc...@gmail.com ___ 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: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes
On 08/27/2010 12:21, Fabian Keil wrote: > The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for me. > It aborts on exit (C-x C-c) after receiving SIGBUS: > r211704 was just a style(9) fix and should coincide with cvs/1.10 that your talking about. r211706 or cvs/1.11 is the culprit that has caused your problem but I have no way to verify that here without merging it locally. If this is the case please mark the MFC of r211706 cvs/1.11 as a do-not-do. Regards, -- jhell,v ___ 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: a question about FreeBSD
Freddie Cash wrote: Also, try man top. -C will show stats for individual CPUs at the top of the screen (similar to pressing 0 in top on Linux). This was added to top in 7.2 or 7.3 or thereabouts. You mean top -P -- Volker T. Mueller Continum AG Bismarckallee 7d 79098 Freiburg i. Br. Tel. +49 761 21711171 Fax. +49 761 21711198 http://www.continum.net Sitz der Gesellschaft: Freiburg im Breisgau Registergericht: Amtsgericht Freiburg, HRB 6866 Vorstand: Rolf Mathis, Volker T. Mueller Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach ___ 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: a question about FreeBSD
Hi, Try using htop from the ports. -- Love & Light Ventsislav Nikolov On Fri, Aug 27, 2010 at 7:07 AM, 崔岩ccuiy...@gmail.com wrote: > Dear all: > > A quick question about the FreeBSD. In my lab, there is a multicore > machine and i install a FreeBSD > system on it. I wonder to know how to see the utilization for each > core? are there such tools? Thanks! > > -- > Think big; Dream impossible; Make it happen. > ___ > 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" > ___ 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: a question about FreeBSD
On Fri, Aug 27, 2010 at 9:45 AM, Julian Elischer wrote: > On 8/26/10 10:10 PM, Steve Kargl wrote: >> On Fri, Aug 27, 2010 at 12:07:11PM +0800, ccuiy...@gmail.com wrote: >>> >>> Dear all: >>> >>> A quick question about the FreeBSD. In my lab, there is a multicore >>> machine and i install a FreeBSD >>> system on it. I wonder to know how to see the utilization for each >>> core? are there such tools? Thanks! >> >> Wrong mailing list. Try freebsd-quest...@freebsd.org. >> >> Also, try man top. > > specifically, there will be an idle thread for each CPU > > so top -SH will allow you to see how much idle time there is on each cpu. -C will show stats for individual CPUs at the top of the screen (similar to pressing 0 in top on Linux). This was added to top in 7.2 or 7.3 or thereabouts. -- Freddie Cash fjwc...@gmail.com ___ 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: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related
On 08/27/2010 10:12 AM, Andriy Gapon wrote: Cool! Meanwhile can you double-check what timers does Linux use there? (No idea how to do that, especially if it's NO_HZ kernel). Sure, if someone can tell me what to do. I know even less about linux than I do about freebsd. :) First thing that came to mind: sysctl -a | grep -i time kernel.sched_time_avg = 1000 kernel.timer_migration = 1 kernel.sched_rt_runtime_us = 95 kernel.hung_task_timeout_secs = 120 fs.lease-break-time = 45 dev.parport.default.timeslice = 200 dev.parport.default.spintime = 500 net.core.xfrm_aevent_etime = 10 Also this looks promising from /proc: http://people.freebsd.org/~dougb/timer_list.txt Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related
on 27/08/2010 19:19 Doug Barton said the following: > Yes, it improved things greatly. I first ran with just powerd for several > hours > and that worked fine. The next day I was able to use powerd and cx_lowest=C2 > for > the better part of a day (including watching a few flash videos). By the end > of > the day intr started to run away again, so not out of the woods yet, but at > least > this shows we're going in the right direction. Also, while poking around in > the > BIOS settings I noticed in one of the "information only" screens that I don't > usually visit one line about the "minimum cpu speed" is 1.00 GHz, which the > sysctl > output above seems to verify. So where the throttling code was getting all > those > other numbers I don't know. > > Meanwhile I've actually not been running FreeBSD for most of this week I've > been > working on re-partitioning my new disk and running ubuntu. So 2 interesting > pieces > of information there, first the "CPU Frequency Scaling Monitor" for the gnome > that > comes with ubuntu never goes below 1 GHz, so that bit seems extra verified. > Second, I can watch all the flash videos I want while doing other stuff in the > background (like restoring the backups of my data) without any problems, so > add > that to windows in terms of OS' that work on this same hardware. Now that I > have > finally figured out how to boot windows, linux, and 2 FreeBSDs on the same > disk > I'll be able to set up 7-stable i386 and 9-current amd64 to see how they > compare > to the 9-current i386 I was using previously; so I should have more > information in > a few days. Cool! Meanwhile can you double-check what timers does Linux use there? (No idea how to do that, especially if it's NO_HZ kernel). -- Andriy Gapon ___ 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: a question about FreeBSD
On 8/26/10 10:10 PM, Steve Kargl wrote: On Fri, Aug 27, 2010 at 12:07:11PM +0800, ccuiy...@gmail.com wrote: Dear all: A quick question about the FreeBSD. In my lab, there is a multicore machine and i install a FreeBSD system on it. I wonder to know how to see the utilization for each core? are there such tools? Thanks! Wrong mailing list. Try freebsd-quest...@freebsd.org. Also, try man top. specifically, there will be an idle thread for each CPU so top -SH will allow you to see how much idle time there is on each cpu. ___ 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: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related
On 08/27/2010 03:25 AM, Andriy Gapon wrote: on 23/08/2010 11:43 Doug Barton said the following: Ok, so it seems that you're suggesting to disable throttling, so I added the following to /boot/loader.conf: hint.p4tcc.0.disabled="1" hint.p4tcc.1.disabled="1" hint.acpi_throttle.0.disabled="1" hint.acpi_throttle.1.disabled="1" Not sure the .1.'s are necessary, but I wanted to be thorough. With that I get: dev.cpu.0.freq_levels: 2333/31000 2000/26000 1667/22000 1333/17000 1000/13000 dev.est.0.freq_settings: 2333/31000 2000/26000 1667/22000 1333/17000 1000/13000 dev.est.1.freq_settings: 2333/31000 2000/26000 1667/22000 1333/17000 1000/13000 hopefully that's more in line with what it should be? I'd really like to be able to at least use powerd since it does seem to help with heat when the system is idle (and by extension, power consumption as well). Unless you say differently when I get up tomorrow I'll try this configuration for a little while and see how it goes. So, how did this go? Did the change make any difference? Yes, it improved things greatly. I first ran with just powerd for several hours and that worked fine. The next day I was able to use powerd and cx_lowest=C2 for the better part of a day (including watching a few flash videos). By the end of the day intr started to run away again, so not out of the woods yet, but at least this shows we're going in the right direction. Also, while poking around in the BIOS settings I noticed in one of the "information only" screens that I don't usually visit one line about the "minimum cpu speed" is 1.00 GHz, which the sysctl output above seems to verify. So where the throttling code was getting all those other numbers I don't know. Meanwhile I've actually not been running FreeBSD for most of this week I've been working on re-partitioning my new disk and running ubuntu. So 2 interesting pieces of information there, first the "CPU Frequency Scaling Monitor" for the gnome that comes with ubuntu never goes below 1 GHz, so that bit seems extra verified. Second, I can watch all the flash videos I want while doing other stuff in the background (like restoring the backups of my data) without any problems, so add that to windows in terms of OS' that work on this same hardware. Now that I have finally figured out how to boot windows, linux, and 2 FreeBSDs on the same disk I'll be able to set up 7-stable i386 and 9-current amd64 to see how they compare to the 9-current i386 I was using previously; so I should have more information in a few days. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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"
emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes
The recent lib/libc/stdlib/atexit.c changes broke emacs (23.2_2,2) for me. It aborts on exit (C-x C-c) after receiving SIGBUS: f...@r500 ~ $gdb emacs 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 "amd64-marcel-freebsd"... (gdb) run Starting program: /usr/local/bin/emacs [New LWP 100281] [New Thread 1260600 (LWP 100281)] Program received signal SIGBUS, Bus error. [Switching to Thread 1260600 (LWP 100281)] 0x0008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 (gdb) where #0 0x0008045c432d in __elf_phdr_match_addr () from /lib/libc.so.7 #1 0x000803038abb in __pthread_cxa_finalize () from /lib/libthr.so.3 #2 0x0008045bdfa7 in __cxa_finalize () from /lib/libc.so.7 #3 0x0008045682c7 in exit () from /lib/libc.so.7 #4 0x00556817 in Fkill_emacs (arg=Could not find the frame base for "Fkill_emacs". ) at emacs.c:2146 #5 0x00600ec0 in Ffuncall (nargs=1, args=0x7fffc880) at eval.c:3024 #6 0x00658d47 in Fbyte_code (bytestr=8602321, vector=8602357, maxdepth=20) at bytecode.c:680 #7 0x006017e6 in funcall_lambda (fun=8602229, nargs=0, arg_vector=0x7fffcdc8) at eval.c:3211 #8 0x006011e0 in Ffuncall (nargs=1, args=0x7fffcdc0) at eval.c:3070 #9 0x00658d47 in Fbyte_code (bytestr=9558105, vector=9558141, maxdepth=20) at bytecode.c:680 #10 0x006017e6 in funcall_lambda (fun=9558029, nargs=1, arg_vector=0x7fffd358) at eval.c:3211 #11 0x006011e0 in Ffuncall (nargs=2, args=0x7fffd350) at eval.c:3070 #12 0x005fb954 in Fcall_interactively (function=11961778, record_flag=11544578, keys=20138021) at callint.c:869 #13 0x00600f36 in Ffuncall (nargs=4, args=0x7fffd760) at eval.c:3030 #14 0x006008fd in call3 (fn=11756290, arg1=11961778, arg2=11544578, arg3=20138021) at eval.c:2850 #15 0x0056b7ac in Fcommand_execute (cmd=11961778, record_flag=11544578, keys=20138021, special=11544674) at keyboard.c:10507 #16 0x0055cc69 in read_char (commandflag=1, nmaps=2, maps=0x7fffdb70, prev_event=11544578, used_mouse_menu=0x7fffded4, end_time=0x0) at keyboard.c:3166 #17 0x0056880e in read_key_sequence (keybuf=0x7fffe280, bufsize=30, prompt=11544578, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9512 #18 0x00558a33 in command_loop_1 () at keyboard.c:1643 #19 0x005fe0aa in internal_condition_case (bfun=0x5586a0 , handlers=11629954, hfun=0x557f90 ) at eval.c:1490 #20 0x0055836a in command_loop_2 () at keyboard.c:1360 #21 0x005fda2c in internal_catch (tag=11621170, func=0x558350 , arg=11544578) at eval.c:1226 #22 0x00558320 in command_loop () at keyboard.c:1339 #23 0x00557a85 in recursive_edit_1 () at keyboard.c:954 #24 0x00557c45 in Frecursive_edit () at keyboard.c:1016 #25 0x005560b8 in main (argc=1, argv=0x7fffe840) at emacs.c:1833 Reverting to lib/libc/stdlib/atexit.c 1.9 gets it working again, using 1.11 brings back the crashes. I didn't csup between those versions and thus don't have 1.10 in git, but given that it's a style change it shouldn't matter. I'm using amd64 and so far I only noticed the problem with emacs. Is anyone else seeing this? Fabian signature.asc Description: PGP signature
Re: [PATCH] Use MACHINE_ARCH for boot loader
On Thursday, August 26, 2010 8:50:01 pm Xin LI wrote: > Hi, > > The attached patch changes FreeBSD/x86 back to FreeBSD/i386 on i386 and > FreeBSD/amd64 on amd64. > > Comments welcome! I'll commit it in by the weekend if there is no > objection on this. As others have noted, the 'x86' is on purpose, and I would rather it continue to do that rather than this change. -- 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"
Re: [PATCH] Use MACHINE_ARCH for boot loader
On Fri Aug 27 10, Alexander Best wrote: > On Fri Aug 27 10, Kostik Belousov wrote: > > On Thu, Aug 26, 2010 at 05:50:01PM -0700, Xin LI wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA256 > > > > > > Hi, > > > > > > The attached patch changes FreeBSD/x86 back to FreeBSD/i386 on i386 and > > > FreeBSD/amd64 on amd64. > > > > > > Comments welcome! I'll commit it in by the weekend if there is no > > > objection on this. > > Change to FreeBSD/x86 was on purpose. And, since the same loader > > can boot both i386 and amd64 kernels, I consider the current state > > more logical. > > yeah. i think jhb wanted this to happen. the old thread for this can be found > here [1]. oops. forgot the reference. :( it's [1] http://www.mail-archive.com/freebsd-hack...@freebsd.org/msg70613.html ...also r205662 seems to have introduced x86. the commit message might be interesting. cheers. alex > > there's also a PR with a patch submitted by myself which will make use of the > keyword 'x86' throughout the whole loader(8) code. > > the PR number for that is 147120. would be nice if someone would commit the > patch. that is of course if in fact it has really been decided that for code > that's being shared between amd64 and i386 the keyword 'x86' shall be used > consistently. > > however recently i've seen quite some commits to HEAD which make me believe > that the developers (most of all jhb) want to make heavy use of the 'x86' > keyword. > > cheers. > alex > > > > > Later, kernel reports its architecture explicitely. > > > > -- > a13x -- a13x ___ 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: [PATCH] Use MACHINE_ARCH for boot loader
On Fri Aug 27 10, Kostik Belousov wrote: > On Thu, Aug 26, 2010 at 05:50:01PM -0700, Xin LI wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Hi, > > > > The attached patch changes FreeBSD/x86 back to FreeBSD/i386 on i386 and > > FreeBSD/amd64 on amd64. > > > > Comments welcome! I'll commit it in by the weekend if there is no > > objection on this. > Change to FreeBSD/x86 was on purpose. And, since the same loader > can boot both i386 and amd64 kernels, I consider the current state > more logical. yeah. i think jhb wanted this to happen. the old thread for this can be found here [1]. there's also a PR with a patch submitted by myself which will make use of the keyword 'x86' throughout the whole loader(8) code. the PR number for that is 147120. would be nice if someone would commit the patch. that is of course if in fact it has really been decided that for code that's being shared between amd64 and i386 the keyword 'x86' shall be used consistently. however recently i've seen quite some commits to HEAD which make me believe that the developers (most of all jhb) want to make heavy use of the 'x86' keyword. cheers. alex > > Later, kernel reports its architecture explicitely. -- a13x ___ 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: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related
on 23/08/2010 11:43 Doug Barton said the following: > Ok, so it seems that you're suggesting to disable throttling, so I added the > following to /boot/loader.conf: > > hint.p4tcc.0.disabled="1" > hint.p4tcc.1.disabled="1" > hint.acpi_throttle.0.disabled="1" > hint.acpi_throttle.1.disabled="1" > > Not sure the .1.'s are necessary, but I wanted to be thorough. With that I > get: > dev.cpu.0.freq_levels: 2333/31000 2000/26000 1667/22000 1333/17000 1000/13000 > dev.est.0.freq_settings: 2333/31000 2000/26000 1667/22000 1333/17000 > 1000/13000 > dev.est.1.freq_settings: 2333/31000 2000/26000 1667/22000 1333/17000 > 1000/13000 > > hopefully that's more in line with what it should be? I'd really like to be > able > to at least use powerd since it does seem to help with heat when the system is > idle (and by extension, power consumption as well). > > Unless you say differently when I get up tomorrow I'll try this configuration > for a little while and see how it goes. So, how did this go? Did the change make any difference? -- Andriy Gapon ___ 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: [RFC] ifconfig description support in rc.d
On 27 August 2010 00:09, Doug Barton wrote:
> On 08/26/2010 12:53 PM, pluknet wrote:
>>
>> [cc'ing current@ as rc@ looks too quite]
>>
>> Hi.
>>
>> Since ifconfig has grown to label interfaces with
>> ifconfig $ifname description "foobar", what about
>> to give it more life and store i/face descriptions
>> semi-permanently, so they will survive between reboots?
>>
>> This patch adds a functionality to rc.d to label
>> interfaces at boot time.
>>
>> Comments are welcome.
>
> This seems like a good addition, thanks. Please also write a patch for
> rc.conf.5 to describe this new functionality and I'll be happy to commit it.
Xin Li helped me with updating rc.conf.5 (thanks!).
It's included in attached patch.
> One note below.
>
>
>> --- etc/network.subr (revision 211280)
>> +++ etc/network.subr (working copy)
>> @@ -1187,6 +1187,24 @@
>> return 0
>> }
>>
>> +# ifnet_descr
>> +# Add description to all requested interfaces.
>> +#
>> +ifnet_descr()
>> +{
>> + local _if _ifdescr
>> +
>> + # ifconfig_IF_descr
>> + for _if in `ifconfig -l`; do
>> + _ifdescr="`get_if_var $_if ifconfig_IF_descr`"
>> + if [ ! -z "$_ifdescr" ]; then
>
> This is probably better as [ -n "$_ifdescr" ]
>
This was blindly copy&pasted after ifnet_rename().
So, it makes sense probably to change test expression there as well.
[see ifnet_rename() proposed change below inline]
This change to ifnet_rename() is not included in attached patch
to not complicate things unnecessarily for now.
Index: etc/network.subr
===
--- etc/network.subr(revision 211280)
+++ etc/network.subr(working copy)
@@ -1179,7 +1179,7 @@
# ifconfig_IF_name
for _if in `ifconfig -l`; do
_ifname=`get_if_var $_if ifconfig_IF_name`
- if [ ! -z "$_ifname" ]; then
+ if [ -n "$_ifname" ]; then
ifconfig $_if name $_ifname
fi
done
--
wbr,
pluknet
descr.rc.d.2.diff
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: [RFC] ifconfig description support in rc.d
On 27 August 2010 01:09, Xin LI wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 2010/08/26 13:09, Doug Barton wrote: >> On 08/26/2010 12:53 PM, pluknet wrote: >>> [cc'ing current@ as rc@ looks too quite] >>> >>> Hi. >>> >>> Since ifconfig has grown to label interfaces with >>> ifconfig $ifname description "foobar", what about >>> to give it more life and store i/face descriptions >>> semi-permanently, so they will survive between reboots? >>> >>> This patch adds a functionality to rc.d to label >>> interfaces at boot time. >>> >>> Comments are welcome. >> >> This seems like a good addition, thanks. Please also write a patch for >> rc.conf.5 to describe this new functionality and I'll be happy to commit >> it. One note below. > > I have drafted one. Nice, thank you! With my poor English, this is a valuable help from you. > > (Note that fxp is a 100Mbps card so it might be sensible to replace it > with just Switch 2?) > Thanks for catching this. Will fix it. -- wbr, pluknet ___ 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: a question about FreeBSD
On Fri, Aug 27, 2010 at 12:07:11PM +0800, 崔岩ccuiy...@gmail.com wrote: > A quick question about the FreeBSD. In my lab, there is a multicore > machine and i install a FreeBSD > system on it. I wonder to know how to see the utilization for each > core? are there such tools? Thanks! Try $ top -P. -- Denny Lin ___ 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: [PATCH] Use MACHINE_ARCH for boot loader
On Thu, Aug 26, 2010 at 05:50:01PM -0700, Xin LI wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, > > The attached patch changes FreeBSD/x86 back to FreeBSD/i386 on i386 and > FreeBSD/amd64 on amd64. > > Comments welcome! I'll commit it in by the weekend if there is no > objection on this. Change to FreeBSD/x86 was on purpose. And, since the same loader can boot both i386 and amd64 kernels, I consider the current state more logical. Later, kernel reports its architecture explicitely. pgps1JWmEnpVV.pgp Description: PGP signature
