Not to say that any problems that might have developed with SCHED_4BSD
should not be fixed, but you should give SCHED_ULE a try since it brings
benefits even for single CPU systems (e.g. better interactive response).
For my particular work load, 4BSD is actually faster than ULE in
RELENG_7.
Hi Josh, thanks for the report. How many CPUs are in your system? Can
you give me the output of 'vmstat 5' over the course of one run on 4BSD
and ULE? Or just one of them if you can't spare the time.
Hi Jeff,
The system has a single quad-core chip, namely an Intel Core 2 Quad
Q6600. Below
All,
I mentioned this on another thread, but I think it deserves a separate
thread. Not only so it will get its own attention, but also so I don't
hijack the other thread.
I have noticed some performance discrepancies with ULE and 4BSD in
RELENG_7, specifically with ffmpeg. I have all the kernel
I have noticed some performance discrepancies with ULE and 4BSD in
RELENG_7, specifically with ffmpeg. I have all the kernel debugging
options disabled, and as I understand it, the userland debugging is
all off by default in RELENG_7.
Here are a couple of additional benchmarks comparing the
Hello,
I have managed to lock my (amd64, RELENG_7) machine up twice today. In
both cases, I was transferring a file to my laptop (in one case over
SMB, the other over FTP). Both resulted in a hard lock (no panic). One
of the lockups had an em1: watchdog timeout message on the console,
the other
Sorry, I should have also included dmesg output. The not properly
dismounted errors are obviously from the last crash :)
Here is /var/run/dmesg.boot:
Copyright (c) 1992-2007 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the
There's another thread on this issue, although that thread seems to
apply to a specific version (of em(4) code, or of NIC PROM revision -- I
don't know, the dmesg output is somewhat ambiguous).
Ah sorry, I did see that thread, but did notice the em version was
different, and that it didn't
Let me preface this by saying that I know -j is unsupported with
ports, and that there are efforts to potentially add hooks for -j. I
just happened to have found a bunch of ports that compiled properly
when setting MAKE_ARGS to -j X in RELENG_6_2.
I had quite a few entries like this in my
Hello,
During buildworld on RELENG_7 csup'd as of 10/22, it dies in
sys/boot/i386/boot2 with:
=== sys/boot/i386/boot2 (all)
-533 bytes available
*** Error code 1
Stop in /usr/src/sys/boot/i386/boot2.
*** Error code 1
I took a look at the cc command line:
cc -Os -fno-guess-branch-probability
I'm trying ot downgrade from RELENG_6 to RELENG_6_2 but encounter a
error when trying to build the kernel.
I'm not quite sure what to do at this point so I'd appreciate some input.
Your log appears to only contain the stdout (based on your make
command, and the lack of an actual error during
Output of
make buildkernel KERNCONF=ALTQSMP /root/buildlog
Have you tried removing /usr/obj, then retrying buildworld? Your
/usr/obj may have some RELENG_6 stuff lingering and causing problems
in the build.
Josh
___
freebsd-stable@freebsd.org
options PAE
One very probable culprit for slowness
I'd say it IS the culprit. PAE is known to decrease performance, and
this is probably 95% of the cause.
Using _ULE might yield a bit more performance as well
Yes, in 7.0-BETA3 I'm seeing a 7% increase in performance (sysbench
with
-
Building 32 bit binaries on amd64 apparently isn't working:
# cc -m64 -march=k8 -o test64 test.c ./test64
testing!!
# cc -m32 -march=k8 -o test32 test.c ./test32
You need to include -B/usr/lib32, and as far as I know that is not new
to -BETA4:
Josh
Hello.
I have been able to reproduce this panic for a while now, and finally
decided to build in debugging support for my kernel and obtain a
proper panic, backtrace, etc as it's still happening with 7.2-BETA1
(FreeBSD pflog.net 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Tue Apr
7 16:03:17 EDT
Unfortunately, as mentioned in the subject, I am unable to get a
savecore. After show alllocks and bt, I ran call doadump, which
appeared to work fine. However, after rebooting, there was no savecore
in /var/crash and running savecore against /dev/mirror/gm1s1b states:
I was able to reproduce
On Fri, Apr 24, 2009 at 11:21 AM, Horst Günther Burkhardt III
ho...@sxemacs.org wrote:
I'm trying to debug a piece of software. It dumps a core file which
mysteriously vanishes. it's not in the program directory, nor my $HOME,
nor /var/crash nor /var/core ...
Deliberately crashing /bin/sh
I just noticed that the changes to the ext2 code to support inode
sizes other than 128 was never MFC'd:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/gnu/fs/ext2fs/ext2_linux_ialloc.c?r1=1.25.8.1;sortby=date#diff
I submitted a patch to this PR:
Can you confirm that this fix helped for you? i.e. do you still
see the problem?
FreeBSD 7.0-RC1 #14: Sun Dec 30 21:50:59 EST 2007
I'm still seeing this problem, but it isn't nearly as bad. I still
get some jerky mouse movement, but music doesn't skip now when I'm
compiling.
I noticed
OK, can you obtain a schedgraph trace when the problem is manifesting?
See /usr/src/tools/sched/ and previous discussion in this or related
threads.
Anyone? Time is rapidly running out to get this fixed in time for
7.0-RELEASE, so we need this trace ASAP.
Kris,
I would be happy to try
The problems I am currently interested in are people who have not found
an acceptable workaround for their performance problems :)
Ok, good point. :) And I guess we should assume that anyone who is
still having the problem has not had success with any of the
workarounds. I guess ideally,
Can anyone else using 7.0 who hasn't already (especially those using ZFS)
check his/her /var/log/messages for disk TIMEOUTs or other disk error
messages? If this is widespread, I think the chances re slim that it is a
hardware problem in every case.
I noticed this week that I was getting DMA
I have been debugging a problem with ushare in FreeBSD 7.0,
specifically I have tracked it down to the pthread_cond_wait call
inside the libupnp library that ushare uses. UpnpInit ultimately calls
the below ithread_cond_wait, which is where I am seeing the hang.
The code in question is on line
On Fri, Apr 18, 2008 at 11:35 PM, Brian [EMAIL PROTECTED] wrote:
I see this is the standard recommendation for those of us using SMP. I am
wondering how far away we are from that becoming standard, since on even
amd64, I see the older scheduler is still in place?
I believe the current plan is
The c compiler is the one shipped with 7.0 RELEASE. Except for the 3
new header files that I placed from cvsupped sources into /usr/include/sys
the entire system is 7.0 RELEASE.
Prior to beginning the build I deliberately set
# export CFLAGS=
Nothing else in my environment would have
On Tue, May 20, 2008 at 11:58:03AM +1000, Mark Andrews wrote:
# export CFLAGS=
This does NOT remove CFLAGS from the environment.
It does when you shell is bash.
I think what Mark was getting at is that simply setting CFLAGS to
prior to make does not trump the setting of CFLAGS in
No, even though it is a dual-core system. I did not want to chance a
race condition. I simply executed 'make buildworld' initially, then
'make -DNO_CLEAN buildworld' when I encountered problems in the build.
Ok, it was worth asking, just to rule out the obvious.
I'm still not sure where
I think the developers and users have made their points clear, and
they're no going to agree any more (but they may agree less) over
time.
You make it sound as if all users are of the same opinion as Jo. The
majority of the responses from users running 6.3 in the thread(s) have
been positive
It's not really a problem, as the device and the SATA hard drives and
DVD+RW attached to the bus operate properly, but I'm wondering why the
ICH9 controller (in AHCI mode) on the Asus P5K-E motherboard shows up
as:
atapci1: Intel AHCI controller port
Because your motherboard allows for the enabling of AHCI on the ICH9.
This is often a BIOS feature you can turn on/off.
I double checked and it is indeed set properly to AHCI mode (instead
of enhanced or legacy). I also upgrade the BIOS and it still shows
up the same way.
I don't believe it's
As Jeremy said it is ok. In pciconf output you can see
class=0x010601. Your ICH9 controller has PCI subclass 0x06 (SATA)
and PCI programming interface 0x01 (AHCI).
Thank you both! I figured it was operating normally (I've noticed no
performance problems or oddities from the controller or
Hello,
I just csup'd this morning and now I cannot build a kernel that does
not include INET6. I can send my KERNCONF, but it is sufficient to
create a kernel config with:
include GENERIC
nooption INET6
Here's the error during kernel compilation of a kernel config without
options INET6 in the
This was an oversight on my part -- none of our LINT build targets
(apparently) excludes INET6. It's fixed easily with an ifdef, and I've
received re@ approval to merge the fix, so it's in the tree as of about an
hour or two ago. If you experience continuing problems after a cvsup,
please
However, what I'm seeing on my system today is evidence of the scheduler
having a bug, rather than merely being suboptimal. If the old scheduler is
still maintained and supposed to work (however sub-optimally) in 4-CPU
configurations, I'd expect either inquiries for more debug-information or
Thanks, but after reading the thread is there a single place in the kernel
that reports the how many fds are currently in use? Does the no more fds
message get logged in /var/log/messages or only in the kernel log buffer,
since I haven't seen that message in the messages file, and since we
I just built world from RELENG_7 sources csup'd this morning, and it
appears the change to src/lib/libc/stdlib/grantpt.c has broken sshd.
I see the following when I attempt to login:
Oct 28 12:32:34 pflog sshd[78236]: fatal: openpty returns device for
which ttyname fails.
Oct 28 12:32:34 pflog
On Tue, Oct 28, 2008 at 12:56 PM, Josh Carroll [EMAIL PROTECTED] wrote:
I just built world from RELENG_7 sources csup'd this morning, and it
appears the change to src/lib/libc/stdlib/grantpt.c has broken sshd.
I see the following when I attempt to login:
Oct 28 12:32:34 pflog sshd[78236
I suspect you are running a new libc, but forgot to update libutil to
the latest version as well. Keep in mind that such a setup is not really
supported.
Yes, exactly my problem. The mystery on my end is now how I managed to
build libc but not libutil. :)
Ah, right after I finished typing
A while back, I submitted a patch for PR kern/124621, which allows the
mounting of an ext2(3) filesystem created with an inode size other
than 128. The e2fsprogs' default is now 256, so file systems created
on newer Linux distributions or with the port will not be mountable.
I was hopeful this
I already expressed my opinion on
http://lists.freebsd.org/pipermail/freebsd-hackers/2008-September/025933.html
Sorry, I do not subscribe to hackers@ so I did not see that message. So what do
you recommend is done to further test it? I tested simple things like copies,
writes, deletes, etc on
I do not suggest testing. I suggest understand what inode metadata is stored
in the added 128 bytes and evaluate whether this information can be ignored
without dangerous consequences for filesystem consistency or user data.
Well, to be clear I didn't just double the size of the inode table.
Ok, I describe my concern once more. I do not object against the checking
of the inode size. But, if inode size is changed, then some data is added
to the inode, that could (and usually does, otherwise why extend it ?)
change intrerpetation of the inode. Thus, we need a verification of the
Ok, I describe my concern once more. I do not object against the checking
of the inode size. But, if inode size is changed, then some data is added
to the inode, that could (and usually does, otherwise why extend it ?)
change intrerpetation of the inode. Thus, we need a verification of the
Could you please point me to your patch and an explanation on how to apply it
and test it?
You can grab the patch here:
http://pflog.net/~floyd/ext2fs.diff
To apply it:
cd /usr/src/sys/gnu/fs
patch /path/to/ext2fs.diff
cd /usr/src/sys/modules/ext2fs
make clean make
kldload ./ext2fs.ko
It seems that the term swap-backed is misleading for some people. It does
NOT mean your md(4) device will be constantly swapping to disk (and the man
page does an alright job of relaying this). It simply means that generally
available memory will be used, and so will swap iff available
I also noticed that behavior, shouldn't compiler/linker look
into /usr/lib32 without additional -B switch?
--
regards, Maciej Suszko.
I don't know if it should or should not, but I can confirm that this
behavior was around in 7.0-RELEASE, so it's been that way for quite a
while, at least in
Greetings!
I'm having a problem with nfsd hanging and not serving mount points,
during which time it can not not be killed. This problem started
happening sometime after November 2nd, since kernel from 11/2 sources
does not exhibit this problem.
The current kernel I'm running is via SVN I just
I'm having a problem with nfsd hanging and not serving mount points,
during which time it can not not be killed. This problem started
happening sometime after November 2nd, since kernel from 11/2 sources
does not exhibit this problem.
Please try the attached patch, rick
Thanks! I had to
On Fri, Nov 5, 2010 at 1:12 PM, Dominic Fandrey kamik...@bsdforen.de wrote:
On 05/11/2010 20:59, Jeremy Chadwick wrote:
On Fri, Nov 05, 2010 at 08:50:48PM +0100, Dominic Fandrey wrote:
On 05/11/2010 19:17, Dominic Fandrey wrote:
This is an example, I can download the file with firefox,
but
Here's the last 30 lines of the output from kdump after it has hung
(the trace file no longer gets written to once the fetch process
hangs):
*snip*
38016 fetch RET read 53/0x35
38016 fetch CALL read(0x3,0x81006835,0x3cb)
I believe this read corresponds to this part of fetch.c
Hi All,
Just upgraded my home machine to 8.2-RELEASE via
freebsd-update remotely (spare time at work.) and on reboot my pf
ruleset isnt being loaded. running '/etc/rc.d/pf start' once its booted
does start it fine though. Any suggestions on debugging or shall i just
try a verbose
On Wed, Mar 9, 2011 at 12:15 PM, Thomas David Rivers riv...@dignus.com wrote:
Just installed a fresh 8.2-stable on a brand-spanking-new 64-bit
machine...
But, when I try to build 32-bit programs I get problems linking,
and I stumbled onto PR bin/139146.
The PR mentions this quick test:
Whatever you do, please leave at least some way (at least a tunable) to
enable/disable HTT - some workloads are better with, and some without it,
and some BIOSes are unreliable in enabling/disabling it :)
I noticed that disabling HTT via the machdep.hyperthreading_allowed
tunable resulted in
That would mean the only time a
person can use tunefs on a root filesystem is when they either do it
manually during the FreeBSD installation (adding -t to the list of
newfs flags in the filesystem creation UI), or if they boot off of some
other medium (USB flash drive, CD, PXE, etc.).
Or
53 matches
Mail list logo
