On Fri, 11 Apr 2008 07:26:05 -0700 (PDT)
Unga [EMAIL PROTECTED] wrote:
I listen to FLAC on amarok on professional headphones
at the same time browsing web while compiling 'make
buildworld' :)
/me confused... are you saying it your music listening is not affected by
building world while on
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 start
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't seem to
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?
[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
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
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.
...
Thoughts?
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:
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.
And
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
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
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
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
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
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 aborts when an
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
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 variable
18 matches
Mail list logo
