> David,
> thank you for the tutorial, it is quite enlightening.
> But first of all, did you take a look at my small test program?
Yes. It demonstrates the classic example of mutex abuse. A mutex is not an
appropriate synchronization mechanism when it's going to be held most of the
time and r
> Brent, David,
>
> thank you for the responses.
> I think I incorrectly formulated my original concern.
> It is not about behavior at mutex unlock but about behavior at mutex
> re-lock. You are right that waking waiters at unlock would hurt
> performance. But I think that it is not "fair" that at
> what if you have an infinite number of items on one side and finite
> number on the other, and you want to process them all (in infinite time,
> of course). Would you still try to finish everything on one side (the
> infinite one) or would you try to look at what you have on the other side?
>
> I am trying the small attached program on FreeBSD 6.3 (amd64,
> SCHED_4BSD) and 7-STABLE (i386, SCHED_ULE), both with libthr as threads
> library and on both it produces "BROKEN" message.
>
> I compile this program as follows:
> cc sched_test.c -o sched_test -pthread
>
> I believe that the beh
> On Wed, Apr 02, 2008 at 03:09:59PM -0400, Forrest Aldrich wrote:
> > Does FreeBSD have support for digitally signed binary checking,
> > similar to
> > what Linux has with bsign and DigSig, where system binaries are
> > signed and
> > this signature is verified before being run in the kernel?
I'm just an observer, and I may be confused, but it seems to me that this is
motion in the wrong direction (at least, it's not going to fix the actual
problem). As I understand the problem, once you reach a certain point, the
system slows down *every* 30.999 seconds. Now, it's possible for the co
> This isn't really accurate. First of all, if the RAID
> controller isn't confirming checksums before giving the data to
> the OS, what is the checksum for exactly?
The checksum is used to recover the data in the event one piece of the data is
lost. With all of the data but one piece, and
> While we are on the subject:
>
> What is the practical difference between VERIFY and REBUILD with regards
> to a RAID-5 array?
Verify should at a minimum read all the data. Ideally, it would read the
checksum blocks too to make sure they are still valid, but it might not.
Rebuild should read a
> A day ago at 11 am i have turn off the server,
> pull out the old driver, installed a new one, turned of the server
> and started rebuild in an hour from remote location via web interface.
> After about 5 minuted the machine became unresponsive. Tried rebooting
> - nothing. I went to the machine
> If I have an executable which is staticly linked with many copies
> of it running (a CGI script in fact), will all those copies share
> the text segment of the executable on the disc, or will it actually
> use up real memory resource with many copies of the executable ? I
> have been assuming th
> It won't fix it. The problem is dangling pointers to devices that no
> longer exist. And like all dangling references after 'free' you get
> bad thing happening.
> Believe me, if it were easy, it would have been fixed. If it was
> moderate to fix, it would have been fixed. It is a hard prob
> Since a few days, I receive this in /var/mail/root
> Any idea?
>
> Olivier
>
> From [EMAIL PROTECTED] Thu Jun 15 11:11:00 2006
> Return-Path: <[EMAIL PROTECTED]>
> Received: from xxx.be (localhost [127.0.0.1])
>by finalcut.be (8.13.3/8.13.3) with ESMTP id k5F9B0Pu051577
>for <[EMAIL P
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] ("David Schwartz") writes:
>
> >> options HZ=1000 #for polling
> > That's too low. 2000 is the minimum you should consider.
>
> Having fixed my traffic generator
> I'm starting to hit errors at 150Kpps.
I'm not sure why you're hitting errors at that speed. But here are a few
suggestions:
> options DEVICE_POLLING #network device mixed
> interrupt-polling handling
> options HZ=1000 #for polling
That's too low. 2000
> According to my formula:
>
>time(minutes) = 1e5 / ( speed(MHz) * nproc )
>
> and taking nproc = 1, this results in
>
>time = 1e5 / 2798.66 = 36 minutes
>
> Quite accurate for your system as well. At least this formula gives a
> resonable estimate about the compile time.
>
> Apparently HT
> (this is of course not my program, just some code that does the same)
>
> --- snipp ---
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> int main()
> {
> int sock, len;
Okay, you haven't set the value of 'len'.
> struct sockaddr_in addr,
I have a Compaq 2500 with an internal SCSI controller. FreeBSD 3 works
perfectly on it. Unfortunately, when I try to do a clean install of FreeBSD
4.0 or 4.1, the SYM driver grabs it and can't find any disks. I believe the
NCR driver would work perfectly, since that's what works on FreeBS
> void* ThreadMain(void* arg)
> {
>
> error = pthread_cond_wait(&gCond, &gMutex);
> ^
> error always = EINVAL (22). This is my very first call that
> uses gCond.
> }
>
> I printed out gCond, it looks good. Can someone tell me what I've
> done
> Is anyone running the SOFTUPDATES option with Stable? I just enabled it
> and was wondering if there are any issues I should be aware of
> performance wise. Any problems? I enabled it for the /usr
> filesystem. Any reason why / is not specifically recommended?
I've been quite happy wit
The distribution requirements for openldap are much more restrictive than
those for the old ldap. I'd hate to see the more retricted one replace the
freer one.
DS
> Thanks
>
> ALAN, THOMAS, ODDBJORN, HANS
>
> for your responses, end result:
>
> /usr/ports/net/ldap.DO
> Thanks. Although having maxfiles == maxfilesperproc might make sense for
> special cases e.g. a machine completely dedicated to one process -- It is
> dangerous at best for the general case. Any malicious program can make a
> machine running FreeBSD non-functional. The default should be set with
I just browsed for any information I could find on this problem. It seems
that my crash differs from the others reported in a few ways:
1) I was running 3.2-STABLE from about 26 days ago.
2) I had maxusers set to 64, not something absurd like 4.
3) My machine wa
I just had one of my servers crash with this panic from kern_timeout.c. The
relevant code seems to be:
/* Fill in the next free callout structure. */
new = SLIST_FIRST(&callfree);
if (new == NULL)
/* XXX Attempt to malloc first */
p
> > > > 1) It can be very easy to get working.
> > >
> > > Funny, you just said it was tricky to get working :)
> >
> > Tricky to get working _well_. Easy to get working. :)
> >
> > Adding an extra 'ip route' command takes 5 seconds. But then
> watching your
> > traffic balance terribly and perf
> > 1) It can be very easy to get working.
>
> Funny, you just said it was tricky to get working :)
Tricky to get working _well_. Easy to get working. :)
Adding an extra 'ip route' command takes 5 seconds. But then watching your
traffic balance terribly and performance go
25 matches
Mail list logo
