Re: fusefs-kmod broken?

[Anish Mistry]

On Monday 23 August 2010 10:57:40 Ian FREISLICH wrote:
 Ian FREISLICH wrote:
  So, in this case is the fusefs module broken?  I'm guessing it is.
  I don't like the way fuse_fileops is initialised in fuse4bsd.  I
  would prefer for the struct to be zeroed and then the fo_xxx
  implimented bits set as appropriate.  That way when the struct is
  changed, you don't get stung again.
 
 I am an idiot - that will have no effect.  This patch needs to be
 included in sysutils/fusefs-kmod/files

Would you file a PR with the patch accounting for the correct 
__FreeBSD_version__?

Thanks,

-- 
Anish Mistry


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] Use MACHINE_ARCH for boot loader

[Kostik Belousov]

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

Re: a question about FreeBSD

[Denny Lin]

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: [RFC] ifconfig description support in rc.d

[pluknet]

On 27 August 2010 01:09, Xin LI delp...@delphij.net 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: [RFC] ifconfig description support in rc.d

[pluknet]

On 27 August 2010 00:09, Doug Barton do...@freebsd.org 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 copypasted 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: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related

[Andriy Gapon]

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: [PATCH] Use MACHINE_ARCH for boot loader

[Alexander Best]

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: [PATCH] Use MACHINE_ARCH for boot loader

[Alexander Best]

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

[John Baldwin]

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

emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes

[Fabian Keil]

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 
command_loop_1, handlers=11629954, hfun=0x557f90 cmd_error) at eval.c:1490
#20 0x0055836a in command_loop_2 () at keyboard.c:1360
#21 0x005fda2c in internal_catch (tag=11621170, func=0x558350 
command_loop_2, 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: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related

[Doug Barton]

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

Re: a question about FreeBSD

[Julian Elischer]

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

[Andriy Gapon]

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: runaway intr problems: powerd and/or hw.acpi.cpu.cx_lowest related

[Doug Barton]

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: a question about FreeBSD

[Freddie Cash]

On Fri, Aug 27, 2010 at 9:45 AM, Julian Elischer jul...@elischer.org 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: a question about FreeBSD

[Ventsislav Nikolov]

Hi,

Try using htop from the ports.


--
Love  Light
Ventsislav Nikolov



On Fri, Aug 27, 2010 at 7:07 AM, 崔岩ccuiy...@gmail.com ccuiy...@gmail.comwrote:

 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

[V. T. Mueller, Continum]

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: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes

[jhell]

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]

On Fri, Aug 27, 2010 at 11:05 AM, V. T. Mueller, Continum
v.t.muel...@continum.net 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

[Kostik Belousov]

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 
 command_loop_1, handlers=11629954, hfun=0x557f90 cmd_error) at eval.c:1490
 #20 0x0055836a in command_loop_2 () at keyboard.c:1360
 #21 0x005fda2c in internal_catch (tag=11621170, func=0x558350 
 command_loop_2, 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: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes

[Fabian Keil]

Kostik Belousov kostik...@gmail.com 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
  command_loop_1, handlers=11629954, hfun=0x557f90 cmd_error) at
  eval.c:1490 #20 0x0055836a in command_loop_2 () at
  keyboard.c:1360 #21 0x005fda2c in internal_catch
  (tag=11621170, func=0x558350 command_loop_2, 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  signal handler called
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
  

kernel panic and corrupt vmcore

[Steve Kargl]

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]

On Fri, Aug 27, 2010 at 09:25:34PM +0200, Fabian Keil wrote:
 Kostik Belousov kostik...@gmail.com 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
   command_loop_1, handlers=11629954, hfun=0x557f90 cmd_error) at
   eval.c:1490 #20 0x0055836a in command_loop_2 () at
   keyboard.c:1360 #21 0x005fda2c in internal_catch
   (tag=11621170, func=0x558350 command_loop_2, 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  signal handler called
 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  

Re: emacs aborting on exit with recent lib/libc/stdlib/atexit.c changes

[Fabian Keil]

Kostik Belousov kostik...@gmail.com wrote:

 On Fri, Aug 27, 2010 at 09:25:34PM +0200, Fabian Keil wrote:
  Kostik Belousov kostik...@gmail.com 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  signal handler called
  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 rtld_exit, 
  cxa_func = 0x8007ccff0 rtld_exit}, 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

[Kostik Belousov]

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: [CFT] ZFS ACL and rrwlock speedup

[Scott Ullrich]

2010/8/24 Martin Matuska m...@freebsd.org:
 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: [CFT] Improved ZFS metaslab code (faster write speed)

[Scott Ullrich]

On Sun, Aug 22, 2010 at 12:26 PM, Martin Matuska m...@freebsd.org 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

[head tinderbox] failure on powerpc64/powerpc

[FreeBSD Tinderbox]

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)

[Norikatsu Shigemura]

Hi mm.

On Fri, 27 Aug 2010 16:05:00 -0400
Scott Ullrich sullr...@gmail.com wrote:
 On Sun, Aug 22, 2010 at 12:26 PM, Martin Matuska m...@freebsd.org 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 n...@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)

[Artem Belevich]

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 n...@freebsd.org wrote:
 Hi mm.

 On Fri, 27 Aug 2010 16:05:00 -0400
 Scott Ullrich sullr...@gmail.com wrote:
 On Sun, Aug 22, 2010 at 12:26 PM, Martin Matuska m...@freebsd.org 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 n...@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

___
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)

[jhell]

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)

[Artem Belevich]

On Fri, Aug 27, 2010 at 6:24 PM, jhell jh...@dataix.net 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