On Tue, Jun 3, 2008 at 9:53 PM, Pawel Jakub Dawidek [EMAIL PROTECTED] wrote:
On Sat, May 31, 2008 at 01:52:56PM +0800, Tz-Huan Huang wrote:
Hi,
Our nfs server is running 7-stable/amd64 with 8G ram, the size of zfs
pool is 12T. We have set vm.kmem_size and vm.kmem_size_max to
1.5G, but the
Chuck, good day.
Tue, Jun 03, 2008 at 04:41:40PM -0400, Chuck Robey wrote:
I am having problems with the git out of ports git-fetch keeps on dumping
core when I try update of xorg (the initial checkout works ok). I'm running
FreeBSD-current ... does anyone have any idea why this might
On Tue, 3 Jun 2008, Ed Schouten wrote:
* Chuck Robey [EMAIL PROTECTED] wrote:
I am having problems with the git out of ports git-fetch keeps on
dumping core when I try update of xorg (the initial checkout works ok).
I'm running FreeBSD-current ... does anyone have any idea why this might
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Watson wrote:
On Tue, 3 Jun 2008, Ed Schouten wrote:
* Chuck Robey [EMAIL PROTECTED] wrote:
I am having problems with the git out of ports git-fetch keeps
on dumping core when I try update of xorg (the initial checkout works
ok).
Chuck,
Wed, Jun 04, 2008 at 10:12:55AM -0400, Chuck Robey wrote:
I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace
nearby, but it seems to be crash inside free().
Application memory errors in HEAD but not in a RELENG_ branch are
frequently a symptom of an application bug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Watson wrote:
On Tue, 3 Jun 2008, Ed Schouten wrote:
* Chuck Robey [EMAIL PROTECTED] wrote:
I am having problems with the git out of ports git-fetch keeps
on dumping core when I try update of xorg (the initial checkout works
ok).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eygene Ryabinkin wrote:
Chuck, good day.
Tue, Jun 03, 2008 at 04:41:40PM -0400, Chuck Robey wrote:
I am having problems with the git out of ports git-fetch keeps on
dumping
core when I try update of xorg (the initial checkout works ok).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eygene Ryabinkin wrote:
Chuck,
Wed, Jun 04, 2008 at 10:12:55AM -0400, Chuck Robey wrote:
I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace
nearby, but it seems to be crash inside free().
Application memory errors in HEAD but not
Chuck,
Wed, Jun 04, 2008 at 10:32:27AM -0400, Chuck Robey wrote:
Any possibility of using ElectricFence (devel/ElectricFence)
for chasing memory-related troubles?
Now that I have gdb working with me again, I am checking the git-fetch image
to
see where it got lost. If I must bring a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eygene Ryabinkin wrote:
Chuck,
Wed, Jun 04, 2008 at 10:32:27AM -0400, Chuck Robey wrote:
Any possibility of using ElectricFence (devel/ElectricFence)
for chasing memory-related troubles?
Now that I have gdb working with me again, I am checking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eygene Ryabinkin wrote:
Chuck,
Wed, Jun 04, 2008 at 10:32:27AM -0400, Chuck Robey wrote:
Any possibility of using ElectricFence (devel/ElectricFence)
for chasing memory-related troubles?
Now that I have gdb working with me again, I am checking
Tz-Huan Huang [EMAIL PROTECTED] writes:
The vfs.zfs.arc_max was set to 512M originally, the machine survived for
4 days and panicked this morning. Now the vfs.zfs.arc_max is set to 64M
by Oliver's suggestion, let's see how long it will survive. :-)
[EMAIL PROTECTED] ~% uname -a
FreeBSD
On Thu, Jun 5, 2008 at 12:31 AM, Dag-Erling Smørgrav [EMAIL PROTECTED] wrote:
Tz-Huan Huang [EMAIL PROTECTED] writes:
The vfs.zfs.arc_max was set to 512M originally, the machine survived for
4 days and panicked this morning. Now the vfs.zfs.arc_max is set to 64M
by Oliver's suggestion, let's
On 2008-Jun-04 11:26:02 -0400, Chuck Robey [EMAIL PROTECTED] wrote:
#3 0x08066467 in unlock_pack () at builtin-fetch.c:56
#4 0x2848b5f3 in __cxa_finalize () from /lib/libc.so.7
#5 0x2843b1aa in exit () from /lib/libc.so.7
#6 0x0804b0e3 in handle_internal_command (argc=2, argv=0x) at
Chuck,
Wed, Jun 04, 2008 at 11:26:02AM -0400, Chuck Robey wrote:
[...]
Looking at the top stack frame (main), that frame and the next are deeply
involved in inspecting argv 0 thru 2, and since it's full of garbage, that's
what breaks things. That's NOT malloc, that seems to be either a
On Wed, 4 Jun 2008, Eygene Ryabinkin wrote:
hello!
has just subscribed
this problem with git is fixed in version 1.5.5.1,
our port requires updating.
--
Have fun!
chd
___
freebsd-hackers@freebsd.org mailing list
* Peter Jeremy [EMAIL PROTECTED] wrote:
On 2008-Jun-04 11:26:02 -0400, Chuck Robey [EMAIL PROTECTED] wrote:
#3 0x08066467 in unlock_pack () at builtin-fetch.c:56
#4 0x2848b5f3 in __cxa_finalize () from /lib/libc.so.7
#5 0x2843b1aa in exit () from /lib/libc.so.7
#6 0x0804b0e3 in
Dmitry, good day.
Wed, Jun 04, 2008 at 11:21:59PM +0400, Chagin Dmitry wrote:
this problem with git is fixed in version 1.5.5.1,
Yeah, commit 7b7f39eae6ab0bbcc68d3c42a5b23595880e528f
our port requires updating.
Care to test? The diff from 1.5.5 is below. Ed, Eric, anyone, any
comments? I
Hello,
I think it would be nice to have standard byteorder conversion functions for
user applications across the BSDs and Linux.
betoh64(), htobe64(), etc. (like OpenBSD's sys/endian.h)
Just small convenience functions/macros, but useful because it's such a common
requirement; applications
On Thursday 05 June 2008 00:33:19 Nanno Langstraat wrote:
My question to FreeBSD:
I don't use FreeBSD myself, but I'll prepare a patch if you like the
idea and if you indicate what you'll accept:
* endian.h or sys/endian.h ?
I maintain that it should be endian.h for user
20 matches
Mail list logo
