>> 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, et
> 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
On Wed, Mar 9, 2011 at 12:15 PM, Thomas David Rivers 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:
>
> uname -s
> 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 ver
> 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.
On Fri, Nov 5, 2010 at 1:12 PM, Dominic Fandrey 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 fetch han
>> 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 h
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 gr
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:
http://www.freebsd.org/cgi/query-pr.cgi?pr=124621&c
On Fri, Apr 24, 2009 at 11:21 AM, Horst Günther Burkhardt III
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 also results in
> 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 repr
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 2009
> 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
> 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
> 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
> 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
> 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 tabl
> 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 o
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 wo
> 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
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:
>
&g
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 ss
> 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 w
> 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 o
> 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,
> plea
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
> 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 d
> 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 beli
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: port
0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa41
> 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
> 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 y
> 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
> 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 woul
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 pla
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 6
> 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
> 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, out-o
> > 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
> > 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 no
> -
> 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
_
> > 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
w
> 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 mai
> 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
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
> 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 a
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
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
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 make.con
> 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 th
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
> 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. Belo
> 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.
53 matches
Mail list logo
