Re: "objtrm" problem probably found (was Re: Stuck in "objtrm")

Before this thread on "cache coherence" and "memory consistency" goes any further, I'd like to suggest a time-out to read something like http://www-ece.rice.edu/~sarita/Publications/models_tutorial.ps. A lot of what I'm reading has a grain of truth but isn't quite right. This paper appeared as a

Re: Thread stack allocation (was Re: cvs commit: src/lib/libc_r Makefile src/lib/libc_r/uthread pthread_private.h uthread_create.c uthread_gc.c uthread_init.c)

Alan Cox <[EMAIL PROTECTED]> writes: > P.S. As an aside, just once, everyone should look at the /proc/"pid"/map > of a running cvsup. Each line you see is a vm_map_entry. (What you > see is a result of Modula-3's garbage collector.) Roughly speaking, Modula-3 really appears to be doing some

Re: Thread stack allocation (was Re: cvs commit: src/lib/libc_r Makefile src/lib/libc_r/uthread pthread_private.h uthread_create.c uthread_gc.c uthread_init.c)

On Tue, Jul 13, 1999 at 11:29:03AM +0300, Ville-Pertti Keinonen wrote: > > Alan Cox <[EMAIL PROTECTED]> writes: > > > P.S. As an aside, just once, everyone should look at the /proc/"pid"/map > > of a running cvsup. Each line you see is a vm_map_entry. (What you > > see is a result of Modula-3

Re: Using float emulator on a system with FPU?

Doug Rabson <[EMAIL PROTECTED]> wrote: >You might consider looking at the fp emulator which I wrote for the alpha. >It should be accurate (I tested against the fpu on an x86) and contains >test harness code which can be used to play with it on both x86 and alpha. Anyone interested in working on F

Re: Using float emulator on a system with FPU?

"Brian F. Feldman" wrote: > > Why shouldn't we? Noone uses machines without FPUs anymore. What non-ancient > CPU doesn't have an FPU? And we're talking about the i386 family here... And 486SX. Anyway, I still hear of people with such machines. As a matter of fact, I caught some flak when I made

Re: Using float emulator on a system with FPU?

In <[EMAIL PROTECTED]>, Garrett Wollman wrote: > < said: > > > I'm going to work on FreeBSD's floating point support, but I need to > > test my changes on systems using the FPU emulators (non-GPL and GPL). > > I suggested about half a year ago that we should officially desupport > non-FPU conf

Re: "objtrm" problem probably found (was Re: Stuck in "objtrm")

Matthew Dillon <[EMAIL PROTECTED]> wrote: >:I'm not sure there's any reason why you shouldn't. If you changed the >:semantics of a stack segment so that memory addresses below the stack >:pointer were irrelevant, you could implement a small, 0-cycle, on-chip >:stack (that overflowed into memory).

Re: Thread stack allocation (was Re: cvs commit: src/lib/libc_r Makefile src/lib/libc_r/uthread pthread_private.h uthread_create.c uthread_gc.c uthread_init.c)

Alan Cox <[EMAIL PROTECTED]> writes: > Almost all of these vm_map_entry's started out as a single entry that got > fragmented as mprotects were performed by the garbage collector. > Instead of maintaining the page protections as part of the vm_map_entry, > you could separate them into a smaller,

LOCK overheads (was Re: "objtrm" problem probably found)

To expand on this morning's table: i386SX-25 486DX2-50 P-133 PII-266 PIII-450 nproc locks mode 0 1950.23 161.1739.6526.31 9.21 EMPTY mode 1 3340.59 221.7471.7424.4516.48 1 no tight mode 2 3237.57 222.9671.1825.2723.65

Re: Using float emulator on a system with FPU?

Alex Zepeda wrote: > I've noticed recently, more and more, Linux is moving into the embedded > market quite nicely, and being used on smaller and smaller systems. > FreeBSD OTOH has been focusing (albeit not too successfully) on the higher > end market. OTOOH: http://www.freebsd.org/~picobsd/ _

Re: Thread stack allocation (was Re: cvs commit: src/lib/libc_r Makefile src/lib/libc_r/uthread pthread_private.h uthread_create.c uthread_gc.c uthread_init.c)

Ville-Pertti Keinonen wrote: > > Modula-3 really appears to be doing something weird, making half of > the entries read-only. A garbage collected language should actually > be capable of doing a better job than a non-gc one. Seems like pretty standard GC technique to me. Mark pages read-only to

PR with patch, any takers?

[PATCH] mountd(8) can apply flags to wrong filesystem [Includes a patch, patch looks like it applies to mountd.c from current] Description When mountd(8) receives a HUP signal, it stops all NFS exporting of filesystems, and then passes the export rules from /etc/exports via a number

Re: Just the kind of news we needed...

Doug Rabson <[EMAIL PROTECTED]> writes: > On Mon, 12 Jul 1999 [EMAIL PROTECTED] wrote: > > > Hi, > > > > On Mon, 12 Jul 1999, Scott Michel wrote: > > > > > If you haven't /.'d today, there's a news article purporting that > > > FreeBSD can be exploited via kernel modules: > > > > > > > > > h

Re: Just the kind of news we needed...

Mon, Jul 12, 1999 at 11:23:42PM +0100, Nik Clayton wrote: > On Mon, Jul 12, 1999 at 02:41:32PM -0400, David E. Cross wrote: > > > > http://thc.pimmel.com/ > > > > > > > I actually found the article a very good source of documentation on > > > programming loadable modules for FreeBSD. Granted, I

PR with patch, any takers?

[PATCH] tempnam.c security problems [Includes a patch, patch applies to tempnam.c from current] Description The tempnam function has the security problem of trusting an environment variable, even when running setuid. While it might seem that using this function in a setuid/setgid

Re: Using float emulator on a system with FPU?

On Tue, 13 Jul 1999, Peter Jeremy wrote: > Doug Rabson <[EMAIL PROTECTED]> wrote: > >You might consider looking at the fp emulator which I wrote for the alpha. > >It should be accurate (I tested against the fpu on an x86) and contains > >test harness code which can be used to play with it on both

Re: LOCK overheads (was Re: "objtrm" problem probably found)

Here's another data point: {"/home/green"}$ cc -O2 locktests.c -o locktests {"/home/green"}$ ./locktests mode 0 10.92 ns/loop nproc=1 lcks=EMPTY mode 1 17.99 ns/loop nproc=1 lcks=no mode 2 17.97 ns/loop nproc=2 lcks=no mode 3 166.33 ns/loop nproc=1 lcks=yes mode 4 167.91 ns/loop nproc=2 lc

Permissions on current.freebsd.org

x 19 root 0 1024 Jul 9 12:37 4.0-19990709-CURRENT drwx-- 19 root 0 1024 Jul 11 12:33 4.0-19990711-CURRENT drwx-- 19 root 0 1024 Jul 12 12:42 4.0-19990712-CURRENT drwx-- 19 root 0 1024 Jul 13 12:38 4.0-19990713-CURRENT Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61,

Re: LOCK overheads (was Re: "objtrm" problem probably found)

:Here's another data point: :{"/home/green"}$ cc -O2 locktests.c -o locktests :{"/home/green"}$ ./locktests :mode 0 10.92 ns/loop nproc=1 lcks=EMPTY :mode 1 17.99 ns/loop nproc=1 lcks=no :mode 2 17.97 ns/loop nproc=2 lcks=no :mode 3 166.33 ns/loop nproc=1 lcks=yes :mode 4 167.91 ns/loop n

Re: Using float emulator on a system with FPU?

As Poul-Henning Kamp wrote ... > In message <[EMAIL PROTECTED]>, "Bria > > >> I suggested about half a year ago that we should officially desupport > >> non-FPU configurations in 4.0. Unfortunately, my resolution was > >> soundly defeated. > > > >Why shouldn't we? Noone uses machines without FPU

Re: Using float emulator on a system with FPU?

Wilko Bulte wrote in list.freebsd-current: > As Poul-Henning Kamp wrote ... > > In message <[EMAIL PROTECTED]>, "Bria > > > > >> I suggested about half a year ago that we should officially desupport > > >> non-FPU configurations in 4.0. Unfortunately, my resolution was > > >> soundly defea

Re: LOCK overheads (was Re: "objtrm" problem probably found)

On Tue, 13 Jul 1999, Matthew Dillon wrote: > > :Here's another data point: > :{"/home/green"}$ cc -O2 locktests.c -o locktests > :{"/home/green"}$ ./locktests > :mode 0 10.92 ns/loop nproc=1 lcks=EMPTY > :mode 1 17.99 ns/loop nproc=1 lcks=no > :mode 2 17.97 ns/loop nproc=2 lcks=no > :mode

Re: Permissions on current.freebsd.org

2:33 4.0-19990711-CURRENT > drwx-- 19 root 0 1024 Jul 12 12:42 4.0-19990712-CURRENT > drwx-- 19 root 0 1024 Jul 13 12:38 4.0-19990713-CURRENT > > Regards >Oliver > > -- > Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany > (Info: finger userinfo:[EMAI

Re: "objtrm" problem probably found (was Re: Stuck in "objtrm")

> On Mon, Jul 12, 1999 at 10:38:03PM -0700, Mike Smith wrote: > > I said: > > > than indirect function calls on some architectures: inline > > > branched code. So you still have a global variable selecting > > > locked/non-locked, but it's a boolean, rather than a pointer. > > > Your atomic macro

Re: LOCK overheads (was Re: "objtrm" problem probably found)

According to Matthew Dillon: > Wow, now that *is* expensive! The K6 must be implementing it in > microcode for it to be that bad. K6-200: 244 [21:57] roberto@keltia:src/C> ./locktest 0 ... empty 26.84 ns/loop 1proc 22.62 ns/loop 2proc 22.64 ns/loop empty w/locks 17.58 ns/loop 1proc w/l

Re: Using float emulator on a system with FPU?

"Brian F. Feldman" <[EMAIL PROTECTED]> wrote: >On Tue, 13 Jul 1999, Peter Jeremy wrote: >> Anyone interested in working on FP emulation (or checking the >> shortcuts DEC made when then designed the Alpha) might like to >> check out : > >fetch: ucbtest.tar.g

Re: LOCK overheads (was Re: "objtrm" problem probably found)

Matthew Dillon <[EMAIL PROTECTED]> wrote: >:mode 1 17.99 ns/loop nproc=1 lcks=no >:mode 3 166.33 ns/loop nproc=1 lcks=yes ... >:This is a K6-2 350. Locks are pretty expensive on them. >Wow, now that *is* expensive! The K6 must be implementing it in >microcode for it to be that bad. I

Re: When will -CURRENT support PCMCIA modems again?

In message <[EMAIL PROTECTED]> Greg Lehey writes: : I've just updated my laptop from 3.2-RELEASE to 4.0-CURRENT, and I : find that PCMCIA modems (sio) are no longer supported. I'm playing : around with it to get it to work, but so far I've just managed to get : panics out of sioprobe. Before I c

panic in -current (trap 12)

This is with a current kernel - a kernel built 2 days ago runs ok. The system crashes at boot, just after the disk checks. I don't have a core dump, only the message printed on screen: fault code: supervisor read , page not present instruction pointer: 0xc0175396 from my kernel: c0175234 t vfs