> > Do you have any errors when you reboot related to nfs?
> >
>
> LOL! I forgot to check the console at boot. Been administering all the
> machines remotely and you forget to do the most basic thing. *sigh*
>
> Anyways, yes there was an error when starting mountd. It takes a few
> seconds to
> > http://wiki.freebsd.org/ZFSKnownProblems
> >
> > This looks like #1.
> >
>
> Hmm.. I don't think there's a large amount of transfer between UFS & ZFS,
> unless the client is using /tmp a lot, it should all be on ZFS.
>
> I noted #4 as well, and therefore tried disabling prefetch. I can'
On Tue, Apr 15, 2008 at 05:20:05PM +0900, [EMAIL PROTECTED] wrote:
> We believe we've found a bug in the libgcc or libstdc++ library (not
> sure which one) packaged with the gcc43 port in fbsd7 on an Intel
> x86-64.
> ...
> Thoughts?
http://lists.freebsd.org/pipermail/freebsd-stable/2008-April/041
[EMAIL PROTECTED] wrote:
Howdy,
We believe we've found a bug in the libgcc or libstdc++ library (not
sure which one) packaged with the gcc43 port in fbsd7 on an Intel
x86-64. A program linked against those libraries aborts when an
exception is thrown. It does not abort if -lpthread is added to
Howdy,
We believe we've found a bug in the libgcc or libstdc++ library (not
sure which one) packaged with the gcc43 port in fbsd7 on an Intel
x86-64. A program linked against those libraries aborts when an
exception is thrown. It does not abort if -lpthread is added to the
link line, even though
At Tue, 15 Apr 2008 03:10:14 -0700,
Jeremy Chadwick wrote:
>
> On Tue, Apr 15, 2008 at 05:20:05PM +0900, [EMAIL PROTECTED] wrote:
> > We believe we've found a bug in the libgcc or libstdc++ library (not
> > sure which one) packaged with the gcc43 port in fbsd7 on an Intel
> > x86-64.
> > ...
> > T
I thought this was gone, but on a kernel from Saturday I'm seeing a bunch of
these:
calcru: runtime went backwards from 65109085931 usec to 61451418084 usec for
pid 1384 (FahCore_78.exe)
calcru: runtime went backwards from 65061446064 usec to 61427333429 usec for
pid 1400 (FahCore_a0.exe)
calcru: r
On Tue, Apr 15, 2008 at 07:59:40AM -0500, Larry Rosenman wrote:
> I thought this was gone, but on a kernel from Saturday I'm seeing a bunch of
> these:
This one is covered in the FAQ in the troubleshooting section, 5.19.
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54
On Tue, Apr 15, 2008 at 10:11:38AM -0400, Scott Robbins wrote:
> On Tue, Apr 15, 2008 at 07:59:40AM -0500, Larry Rosenman wrote:
> > I thought this was gone, but on a kernel from Saturday I'm seeing a bunch of
> > these:
>
> This one is covered in the FAQ in the troubleshooting section, 5.19.
A
Hello,
I experience also a strange lagg when using SCHED_ULE and FreeBSD 7.0 on
AMD64 platforms with and without UP. I tried to track on FreeBSD 7 from
the very early days, so I noticed some performance impacts last year
when something chenged in the scheduling. I'm not very familiar with the
On Tue, Apr 15, 2008 at 07:20:34AM -0700, Jeremy Chadwick wrote:
> On Tue, Apr 15, 2008 at 10:11:38AM -0400, Scott Robbins wrote:
> > On Tue, Apr 15, 2008 at 07:59:40AM -0500, Larry Rosenman wrote:
> > > I thought this was gone, but on a kernel from Saturday I'm seeing a bunch
> > > of
> > > these
Thanks for the followup. I have not yet gotten a reliable test case
to reproduce the problem. I've done a number of tests with the zil
and/or prefetch on with no hangs. I will be collecting some more data
later this week.
If anyone knows a source of consistently slow but large torrents (I
suppos
A few months back there were some problems with the above, that were
fixed by committing software changes. I wanted to check in to see how
it is working for those that have this hardware.
Brian
___
freebsd-stable@freebsd.org mailing list
http://lists
Hey guys;
I'm back to using FreeBSD, after my major hardware upgrade seriously
broke everything (teach me to optimise...)
I've stuck it on my xbox for now, and it runs like a charm, of course,
except it complains then dies on boot about the HDD having problems
with DMA. It's only using a 40-condu
Hi,
I just noticed that scripts in /etc/daily.local, /etc/weekly.local, etc,
never run.
The reason seems to be that the /etc/periodic/daily/999.local and similar
scripts use "for script in $daily_local". Because the variable $daily_local
is initialized in /etc/defaults/periodic.conf to /etc/daily
At Tue, 15 Apr 2008 18:43:21 +0800,
David Xu wrote:
>
> [EMAIL PROTECTED] wrote:
> > Howdy,
> >
> > We believe we've found a bug in the libgcc or libstdc++ library (not
> > sure which one) packaged with the gcc43 port in fbsd7 on an Intel
> > x86-64. A program linked against those libraries abor
On Tue, 15 Apr 2008, Jeremy Chadwick wrote:
On Tue, Apr 15, 2008 at 10:11:38AM -0400, Scott Robbins wrote:
On Tue, Apr 15, 2008 at 07:59:40AM -0500, Larry Rosenman wrote:
I thought this was gone, but on a kernel from Saturday I'm seeing a bunch of
these:
This one is covered in the FAQ in the
On Wed, Apr 16, 2008 at 12:41:35AM +0100, Miguel Lopes Santos Ramos wrote:
> I just noticed that scripts in /etc/daily.local, /etc/weekly.local, etc,
> never run.
> The reason seems to be that the /etc/periodic/daily/999.local and similar
> scripts use "for script in $daily_local". Because the var
18 matches
Mail list logo
