PR kern/36329
Hi hackers! PR kern/36329 which i submitted for freebsd4.x is not fixed in freebsd5.0 $ uname -a FreeBSD 5.0-CURRENT-20010911-JPSNAP FreeBSD 5.0-CURRENT-20010911-JPSNAP #0: Tue Sep 11 06:48:53 GMT 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC i386 Is anyone fixxxing it, cause i can't do it by myself yet? -- e-mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Is there any co-operation between KSE and similar effort in NetBSD?
Folks, I wonder if there is any co-operation between our KSE and similar effort in NetBSD (see http://web.mit.edu/nathanw/www/usenix/freenix-sa/freenix-sa.html). To me it sounds logical to unite efforts if not for the kernel code, but at least for the kernel interfaces and userland library. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Is there any co-operation between KSE and similar effort in NetBSD?
Maxim Sobolev wrote: I wonder if there is any co-operation between our KSE and similar effort in NetBSD (see http://web.mit.edu/nathanw/www/usenix/freenix-sa/freenix-sa.html). To me it sounds logical to unite efforts if not for the kernel code, but at least for the kernel interfaces and userland library. FreeBSD developers are aware of the implementation of scheduler activations within NetBSD. For the most part, the NetBSD implementation is a fairly faithful implementation of the original Scheduler Activations paper. The FreeBSD effort attempts to achieve better performance by going a slightly different route, with the similar goal of creating a call conversion threading mechanism (a blocking call is converted into a non-blocking call plus a thread context switch that does not result in a heavy weight process context switch, as in the SVR4 and Linux threading implementations). If you read the FreeBSD papers on KSE's, the intention is to ensure SMP scalability via threading (not an issue that was addressed by the original SA paper), and to minimize context switch overhead, far more than can be achieved by naieve kernel threading (as in SVR4 and Linux), without putting the thread group affinity into the kernel scheduler, with dangerous and unpredictable stavation deadlocks having a high probability of occurring. When I originally coined the term KSE (Kernel Schedulable Entity), it was intentionally different terminology from the exiting literature, so as to not bias implementation. My original view of implementation was that an async call gate, not scheduler activations, would be used, in order to make all system calls asynchronus completion (a blocking context would be late-bound only as necessary, so all calls operating from in-core data, e.g. getpid(), getppid(), gettimeofday(), etc., would complete without the creation of a context). The eventual settlement on the modified SA approach was as a result of a design decision by Jason Evans, after significant architectural discussion held both on the mailing lists, and at the Whistle Communications all hands room during BAFUG meetings on the topic. As you can see: the use of the new terminology was successful in avoiding bias, even if it didn't arrive at the more radical answer I wanted (ironic that the 64 bit change is going to add a new call gate for a new libc, and that that call gate will also not be asynchronous, when the original argument against an async call gate was the call gate change required ;^)). In any case, the FreeBSD people have examined and learned what they felt they could from the NetBSD implementation, but the final FreeBSD implementation is unlikely to share much, if any, code. You would probably be well advised to look at the FreeBSD KSE project pages, and examine the archived architectural and design documents there, for more information, if you are truly curious about the FreeBSD implementation. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PR kern/36329
$ uname -a FreeBSD 5.0-CURRENT-20010911-JPSNAP FreeBSD 5.0-CURRENT-20010911-JPSNAP #0: Tue Sep 11 06:48:53 GMT 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GENERIC i386 Sorry, i see the date above :) Is anyone fixxxing it, cause i can't do it by myself yet? But anyway, is it fixed in freebsd5.0? -- e-mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
** Approved. **
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00E5_84A70E3A.C4515B83
linker bug?
In order to measure call overhead on an Athlon XP system I
compiled and ran the following program and saw some curious
results!
$ cat foo.c
#include stdlib.h
void func() { }
void(*funp)() = 0;
int main(int argc, char **argv) {
int i, j;
if (argv[1][0] != '?') /* defeat compile-time optimization */
funp = func;
i = atoi(argv[1]);
for (j = i; j 0; --j)
(*funp) ();
}
$ cc -O -fomit-frame-pointer foo.c
$ time a.out 10
a.out 10 4.11s user 0.01s system 97% cpu 4.215 total
Then I did a static link and saw the time increase by 10 seconds!
$ cc -O -fomit-frame-pointer -static foo.c
$ time a.out 10
a.out 10 14.28s user 0.01s system 96% cpu 14.759 total
nm reveals the problem.
$ cc -O -fomit-frame-pointer foo.c nm a.out |grep func
08048490 T func
$ cc -O -fomit-frame-pointer -static foo.c nm a.out |grep func
080481c4 T func
Here is what
void func() {}
gets compiled to:
.p2align 2,0x90
.globl func
.typefunc,@function
func:
ret
This is on a 4.6-RC system with gcc-2.95.3. The fact that
func is aligned on a 16 byte boundary in the -dynamic case is
likely conincidental. gcc-3.1 seems to put it on an 8 byte
with -dynamic and 4 byte boundary with -static.
So the question is: does the linker ignore alignment
altogether or did I miss some magic flag?
-- bakul
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: LINT CPU features table
On Fri, 7 Jun 2002, Lucky Green wrote: [This inquiry found no takers on -questions, so I am trying it on -hackers] I found the list of CPU options in LINT to be not very accessible. What would be considerably more useful, perhaps in addition to the information in LINT, would be a table of CPU's, with a checkbox for each CPU feature that should/could be enabled for this particular CPU. Is anybody here aware of such a table? If not, is anybody here able to perhaps create such a table and add it to the Handbook? I believe it would be of substantial help to the user. OK, I have an AMD K6-333. [User looks down the AMD K6 row of the table]. I can turn on feature L, M, and Y. Thanks in advance, --Lucky For most cpus, there is little to be gained by fiddling with cpu specific options. Hence, there is little reason to provide a complex table; having all cpu types enabled as in GENERIC is just fine. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
porting from linux
Hi,
I'm trying to track down a problem in the netsaint-plugins plugin
check_snmp. It partially works, but if check_snmp is given more than
one OID, it bombs out with a failure in strscat. Apparently strscat
comes from utils.c which is linked with check_snmp.c.
The error generally looks like this:
bash-2.05a# /usr/local/libexec/netsaint/check_snmp -H localhost -C -o
.1.3.6.1.4.1.2021.10.1.5.1,.1.3.6.1.4.1.2021.10.1.5.2,.1.3.6.1.4.1.2021.10.1.5.3
-w :1,:2,:3 -c :5,:10,:20 -l load
check_snmp in free(): warning: chunk is already free
check_snmp in realloc(): warning: chunk is already free
failed malloc in strscat
I'm guessing that since netsaint is developed on Linux, I'm running into
some odd linux-ism.
I did a send-pr on the port and contacted the port maintainer, but I
thought maybe I'd find someone here who would like to tinker. The port of
the netsaint-plugins is under /usr/ports/net.
FWIW, here's the strscat function in utils.c:
/**
*
* Concatenates one string to the end of another
*
* Given a pointer destination string, which may or may not already
* hold some text, and a source string with additional text (possibly
* NULL or empty), returns a pointer to a string that is the first
* string with the second concatenated to it. Uses realloc to free
* memory held by the dest argument if new storage space is required.
*
* Example:
*
* char *str=NULL;
* str = strscpy(This is a line of text with no trailing newline);
* str = strscat(str,\n);
*
*/
char *strscat(char *dest, const char *src)
{
int len,l2;
if (src)
l2 = strlen (src);
else
return dest;
if (dest)
len = strlen (dest);
else
len = 0;
dest = realloc (dest, len + l2 + 1);
if (dest == NULL)
terminate (STATE_UNKNOWN, failed malloc in strscat\n);
strncpy (dest + len, src, l2);
dest[len + l2] = 0;
return dest;
}
And the call to strscat in check_snmp:
while (fgets(input_buffer, MAX_INPUT_BUFFER - 1, child_process))
output = strscat(output, input_buffer);
---
if (ptr strstr(ptr, delimiter) == NULL) {
response = strscat(response, ptr);
ptr = NULL;
---
I'm not a C person at all. I wish this had just been written in perl :)
FWIW, I found some general porting guidelines on the net, but most of them
in talking about free(), malloc(), and realloc() just mention that you
shouldn't be including malloc.h, and this does not.
Any help is appreciated.
PR is: http://www.freebsd.org/cgi/query-pr.cgi?pr=39182
port maintainer is: [EMAIL PROTECTED]
Thanks for any help!
Charles
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: kernel booting diff between boot2 and loader
On Tue, Jun 11, 2002 at 03:26:28AM +0200, Mark Santcroos wrote: I wonder what is different in booting the kernel from loader(8) and from boot2. In vmware2 I am not able to boot the kernel from boot2, it hangs after loading the kernelfile. Using loader it goes fine. I tried current,stable and generic kernels, all without luck. This was not really a problem, until I wanted to use etherboot, where I ofcourse can't use loader. fyi: this was fixed by statically compiling the hints file into the kernel. -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
#1 DIET PILL! LOSE 10-15 LBS PER WEEK+BONUS 6983
Hey there, If you're like me, you've tried EVERYTHING to lose weight. I know how you feel - the special diets, miracle pills, and fancy exercise equipment never helped me lose a pound either. It seemed like the harder I tried, the bigger I got, until I heard about a product called Extreme Power Plus. You're probably thinking to yourself, Oh geez, not another miracle diet pill! Like you, I was skeptical at first, but my sister swore it helped her lose 23 pounds in just two weeks, so I told her I'd give it a shot. I mean, there was nothing to lose except a lot of weight! Let me tell you, it was the best decision I've ever made. Period. Six months later, as I'm writing this message to you, I've gone from 355 pounds to 210 pounds, and I haven't changed my exercise routine or diet at all. Yes, I still eat pizza, and lots of it! I was so happy with the results that I contacted the manufacturer and got permission to resell it - at a BIG discount. I want to help other people lose weight like I did, because it does so much for your self-esteem, not to mention your health. I give you my personal pledge that Extreme Power Plus absolutely WILL WORK FOR YOU. If it doesn't, you can return it any time for a full refund. Interested, visit http://2002marketing.com/affiliate3/index.htm If you are frustrated with trying other products, not having any success, and just not getting the results you were promised, then I recommend the only product that worked for me - EXTREME POWER PLUS. You're probably asking yourself, Ok, so how does this stuff actually work? Extreme Power Plus contains Lipotropic fat burners and ephedra which is scientifically proven to increase metabolism and cause rapid weight loss. No hocus pocus in these pills - just RESULTS, RESULTS, RESULTS!! Here is the bottom line ... I can help you lose 10-15 pounds per week naturally, without exercising and without having to eat rice cakes all day. Just try it for one month - there's nothing to lose, and everything to gain. You will lose weight fast - GUARANTEED. That is my pledge to you. To order Extreme Power Plus on our secure server, just click on the link below: http://2002marketing.com/affiliate3/index.htm If you have difficulty accessing the website above, please try our mirror site by clicking on the link below: http://2002marketing.com/affiliate3/index.htm To see what some of our customers have said about this product, visit http://2002marketing.com/affiliate3/index.htm To see a list of ingredients and for more information on test studies and how it will help you lose weight, visit http://2002marketing.com/affiliate3/index.htm * If you do not wish to receive any more emails from me, please send an email to [EMAIL PROTECTED] requesting to be removed. * To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
