Re: ftp passive mode

On Sun, 11 Jul 1999 22:27:04 PST, Adam Wight wrote: > Why was the FTP_PASS_MODE logic changed? This forces everyone who > uses active connections to alter their environment... Please let's not get into this again. This was discussed to death on the hackers mailing list last week and the week

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

On Sun, 11 Jul 1999, Mike Haertel wrote: > >On Sat, 10 Jul 1999, Matthew Dillon wrote: > >> > >> The supposedly atomic functions in i386/include/atomic.h are not > >> as atomic as was previously thought :-): > >> > >> #define atomic_add_short(P, V) (*(u_short*)(P) += (V)) > >[.

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

On Mon, 12 Jul 1999, Peter Jeremy wrote: > Mike Haertel <[EMAIL PROTECTED]> wrote: > >Um. FYI on x86, even if the compiler generates the RMW > >form "addl $1, foo", it's not atomic. If you want it to > >be atomic you have to precede the opcode with a LOCK > >prefix 0xF0. > > I'd noticed that p

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

Doug Rabson wrote in list.freebsd-current: > On Mon, 12 Jul 1999, Peter Jeremy wrote: > > That said, it should be fairly simple to change Matt's new in-line > > assembler versions to insert LOCK prefixes when building an SMP > > kernel. (Although I don't know that this is necessary yet, given

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

Doug Rabson wrote: > On Mon, 12 Jul 1999, Peter Jeremy wrote: > > > Mike Haertel <[EMAIL PROTECTED]> wrote: > > >Um. FYI on x86, even if the compiler generates the RMW > > >form "addl $1, foo", it's not atomic. If you want it to > > >be atomic you have to precede the opcode with a LOCK > > >pre

Using float emulator on a system with FPU?

Moin, 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). Is there any way to use these emulators on a system that has a hardware FPU? Guessing from LINT's comments, you had to leave out npx and include one

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

> We don't need the lock prefix for the current SMP implementation. A lock > prefix would be needed in a multithreaded implementation but should not be > added unless the kernel is an SMP kernel otherwise UP performance would > suffer. > > -- > Doug Rabson Mail: [EMAIL

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

>I was under the impression that a locked instruction was essentially free >at runtime, with the sole exception of being one byte larger. No, they are very expensive, at least when done in a minimal loop (8 cycles on my P5/133 UP and 16 cycles on my Celeron/450). ISTR Steve Passe saying that the

Re: Using float emulator on a system with FPU?

>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). > >Is there any way to use these emulators on a system that has a >hardware FPU? Toggling `npx_exists' using ddb used to work. Now, toggling it off on i58

patch: PAM hooks for rshd & rlogind

Attached are patches for rshd and rlogind to add a hook to use PAM modules to handle user authentication. Currently we have restricted compute servers that we want to keep most users from directly logging into, but that must retain the .rhosts functionality for the few users that are allowed to l

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

:> We don't need the lock prefix for the current SMP implementation. A lock :> prefix would be needed in a multithreaded implementation but should not be :> added unless the kernel is an SMP kernel otherwise UP performance would :> suffer. :> :> -- :> Doug Rabson Mail: [

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

>p.s. I'm pretty sure that the lock prefix costs nothing on a UP system, >and probably wouldn't be noticed on an SMP system either because the >write-allocation overhead is already pretty bad. But I haven't tested >it. it's actually quite expensive in terms of bus bandwidth bec

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

:>p.s. I'm pretty sure that the lock prefix costs nothing on a UP system, :>and probably wouldn't be noticed on an SMP system either because the :>write-allocation overhead is already pretty bad. But I haven't tested :>it. : :it's actually quite expensive in terms of bus bandwidt

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

Matthew Dillon scribbled this message on Jul 12: > p.s. I'm pretty sure that the lock prefix costs nothing on a UP system, > and probably wouldn't be noticed on an SMP system either because the > write-allocation overhead is already pretty bad. But I haven't tested > it. actuall

lock prefix overhead in SMP system - results

Ok, here we are. The lock instruction overhead is significant relative the execution time of the instruction, though on a 450 MHz P-III it is still not a huge problem. Basically 12 vs 89 ns for the non competitive case, and 26 vs 161 ns for the competitive case. empty loop

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

:actually, I'm not so sure, it guarantees that NO other bus operation :will succeed while this is happening... what happens if a pci bus :mastering card makes a modification to this value? sure, it normally :won't happen, but it can... and w/o the lock prefix, this CAN happen :from what I unders

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

You might think that, due to MESI state bits in the cache and bus coherency protocols, that locks are "free". Unfortunately, the lock prefix has a measurable cost on a UP system, at least on P6 and later processors. The reason is that the locked memory operation is an "at-retirement" operation,

Just the kind of news we needed...

If you haven't /.'d today, there's a news article purporting that FreeBSD can be exploited via kernel modules: http://thc.pimmel.com/ -scooter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

Re: When will -CURRENT support PCMCIA modems again?

> 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 continue with this: is anybody else > working on it

Re: patch: PAM hooks for rshd & rlogind

> Attached are patches for rshd and rlogind to add a hook to use > PAM modules to handle user authentication. Thank you! Saves me (and JDP?) some work! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-cu

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

Yup, and if you read [EMAIL PROTECTED], its old news *shrug* 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: > > > http://thc.pimmel.com/ > > > > -scooter > > > To Unsubscribe: se

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

Here we are: Empty loop mode 09.21 ns/loop nproc=1 lcks=EMPTY Tight loop, 1 and 2 processes, with and without lock prefix mode 1 16.48 ns/loop nproc=1 lcks=no mode 2 23.65 ns/loop nproc=2 lcks=no mode 3 93.02 ns/loop nproc=1 lcks=yes mod

Ack! Wrong results.

How did that happen?!!! Argg..I didn't save the email. Here are better results: Empty loop: mode 09.21 ns/loop nproc=1 lcks=EMPTY With and without lock prefix, one and two processes mode 1 16.48 ns/loop nproc=1 lcks=no mode 2 23.65 ns/loop

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

Mike Haertel once wrote: > Anyway, taking all that into account, I still agree with Dillon that > it is a better software solution to allow the same loadable drivers to > work for both UP and MP systems whenever possible. What's wrong, again with /modules and /modules.smp? If some third party

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

> do away with the lock prefix on non-SMP machines. I don't know if the > SMP variable is accessible from within the i386/include/atomic.h header > file, though. > SMP is globally defined (in opt_global.h). -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe free

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

I don't understand. If you have to be root to load a kernel module then don't you have complete control over the box anyway? If so, you can replace the kernel and all the MD5 checksums and check code isn't going to do you a bit of good. To Unsubscribe: send mail to [EMAIL PROTECTED] wit

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

In message <[EMAIL PROTECTED]>, John-Mark Gurney writes: >Matthew Dillon scribbled this message on Jul 12: >> p.s. I'm pretty sure that the lock prefix costs nothing on a UP system, >> and probably wouldn't be noticed on an SMP system either because the >> write-allocation overhead is

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

> If you haven't /.'d today, there's a news article purporting that > FreeBSD can be exploited via kernel modules: > > > http://thc.pimmel.com/ I did a quick read of that, I don't see how the system is being exploited at all. All of their tricks need to be able to load a kernel module in order

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

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: > > > http://thc.pimmel.com/ > I actually found the article a very good source of documentation on programming loadable modules for F

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

> > http://thc.pimmel.com/ > > > I actually found the article a very good source of documentation on > programming loadable modules for FreeBSD. Granted, I'm not sure of it's > accuracy, but it was a worthwhile read for someone like myself who has > only coded LKMs for Linux. Very interesting.

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 Mon, 12 Jul 1999, Dmitrij Tejblum wrote: > > Alan Cox wrote: > > > When you create a stack or grow an existing stack, the minimum chunk size > > > is 128K. > > > > This make use of "growable" stacks in libc_r particulary useful, given that > > libc_r make "growable" only 64K stacks. > > Th

Re: Using float emulator on a system with FPU?

On Mon, 12 Jul 1999, Martin Cracauer wrote: > Moin, > > 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). > > Is there any way to use these emulators on a system that has a > hardware FPU? > > Guessing

Using float emulator on a system with FPU?

< 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 configurations in 4.0. Unfortunately, my resolution was soundly d

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

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: > > > > > > http://thc.pimmel.com/ > > > I actually found the article a ver

Re: Using float emulator on a system with FPU?

On Mon, 12 Jul 1999, 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 configu

Re: Using float emulator on a system with FPU?

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 FPUs anymore. What non-ancient >CPU doesn't have

Re: Using float emulator on a system with FPU?

On Mon, 12 Jul 1999, Brian F. Feldman wrote: > On Mon, 12 Jul 1999, 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

Re: Using float emulator on a system with FPU?

On Mon, 12 Jul 1999, 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 confi

RE: Using float emulator on a system with FPU?

> > 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... > > > > Embedded systems, anyone? True, but how late a version do you really want to run on them? I've left even my P60's at Fre

Re: Using float emulator on a system with FPU?

> 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... IIRC, there were a few folks running FreeBSD in an embedded environment. Perhaps with 80386 FPU coprocessor-less systems? Dan Eischen [EMAIL

Re: Using float emulator on a system with FPU?

On Mon, Jul 12, 1999 at 01:38:57PM -0700, David Schwartz 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... > > > > > > > Embedded systems, anyone? > > True, but how

Re: Using float emulator on a system with FPU?

Brian F. Feldman once wrote: > > 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 FPUs anymore. What > non-anc

Re: Using float emulator on a system with FPU?

On Mon, 12 Jul 1999, 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... I've noticed recently, more and more, Linux is moving into the embedded market quite nicely, an

Re: Using float emulator on a system with FPU?

On Mon, 12 Jul 1999, Alex Zepeda wrote: > On Mon, 12 Jul 1999, 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... > > I've noticed recently, more and more, Li

Re: Using float emulator on a system with FPU?

Alex Zepeda wrote: > On Mon, 12 Jul 1999, 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... Nonsense. Read this:

Re: Ack! Wrong results.

On Mon, 12 Jul 1999, Matthew Dillon wrote: > How did that happen?!!! Argg..I didn't save the email. > > Here are better results: > > Empty loop: > > mode 09.21 ns/loop nproc=1 lcks=EMPTY > > With and without lock prefix, one and two processes > > mode 1

Re: Ack! Wrong results.

:Just as another data point, it would be interesting to see the overhead :for non-inline versions (i.e. functions in the kernel which are using lock :or not called by code in loaded modules). : :The alpha versions of these operations are already non-inline since it :takes quite a few instructions

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

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'm not sure of it's > > accuracy, but it was a worthwhile read for so

Re: HELP!!! -CURRENT libtool problem.

Satoshi. On Mon, Jul 12, 1999 at 12:31:52AM -0700, Satoshi - Ports Wraith - Asami wrote: > * From: Nik Clayton <[EMAIL PROTECTED]> > > I really wish you would stop spreading FUD. Don't open your mouth if > you don't know what you are talking about. I do know what I'm talking about -- specific

Re: utmp & last

In article <[EMAIL PROTECTED]>, Ayan George <[EMAIL PROTECTED]> wrote: > > What seems strange is that they use the different data types to > store the same information (the time): > > struct lastlog { > time_t ll_time; > charll_line[UT_LINESIZE];

Re: "objtrm" problem probably found

Doug Rabson <[EMAIL PROTECTED]> wrote: >We don't need the lock prefix for the current SMP implementation. A lock >prefix would be needed in a multithreaded implementation but should not be >added unless the kernel is an SMP kernel otherwise UP performance would >suffer. Modulo the issue of UP vs

Re: MTRR stuff

> > > What exactly are the ranges? You haven't given me enough info yet. I wrote the > > K6-* MTRR driver, so I'd like to help. > > > OK, the Linux 3dfx driver attempts to set up a write combining range starting > at the card's base address and 0x40 bytes long. After doing this it then >

Re: "objtrm" problem probably found

:Or (maybe more clearly): : :#ifdef SMP :#defineSMP_LOCK"lock; " :#else :#defineSMP_LOCK :#endif : :#define ATOMIC_ASM(type,op)\ :__asm __volatile (SMP_LOCK op : "=m" (*(type *)p) : "ir" (v), "0" (*(type *)p)) Yes, precisely. :I believe the API to the PCI-loc

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

> Although function calls are more expensive than inline code, > they aren't necessarily a lot more so, and function calls to > non-locked RMW operations are certainly much cheaper than > inline locked RMW operations. This is a fairly key statement in context, and an opinion here would count for

Re: Using float emulator on a system with FPU?

> > 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 FPUs anymore. What non-ancient > CPU doesn't have an FPU? And we're talking about

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

: :> Although function calls are more expensive than inline code, :> they aren't necessarily a lot more so, and function calls to :> non-locked RMW operations are certainly much cheaper than :> inline locked RMW operations. : :This is a fairly key statement in context, and an opinion here would

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

> > : > :> Although function calls are more expensive than inline code, > :> they aren't necessarily a lot more so, and function calls to > :> non-locked RMW operations are certainly much cheaper than > :> inline locked RMW operations. > : > :This is a fairly key statement in context, and an opin

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

:I assumed too much in asking the question; I was specifically :interested in indirect function calls, since this has a direct impact :on method-style implementations. Branch prediction caches are typically PC-sensitive. An indirect method call will never be as fast as a direct call,

Re: MTRR stuff

On Mon, 12 Jul 1999, Mike Smith wrote: > > > > > What exactly are the ranges? You haven't given me enough info yet. I wrote the > > > K6-* MTRR driver, so I'd like to help. > > > > > OK, the Linux 3dfx driver attempts to set up a write combining range starting > > at the card's base address a

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

Mike Smith <[EMAIL PROTECTED]> wrote: >> Although function calls are more expensive than inline code, >> they aren't necessarily a lot more so, and function calls to >> non-locked RMW operations are certainly much cheaper than >> inline locked RMW operations. > >This is a fairly key statement in c

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

Matthew Dillon <[EMAIL PROTECTED]> wrote: >The change in code flow used to be the expensive piece, but not any >more. You typically either see a branch prediction cache (Intel) >offering a best-case of 0-cycle latency, or a single-cycle latency >that is slot-fillable (MIPS). In

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

: :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). I don't know whether this :semantic chang

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

: :Based on general computer architecture principles, I'd say that a lock :prefix is likely to become more expensive[1], whilst a function call :will become cheaper[2] over time. :... : :[1] A locked instruction implies a synchronous RMW cycle. In order :to meet write-ordering guarantees (wit

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

On Mon, Jul 12, 1999 at 07:09:58PM -0700, Mike Smith wrote: > > Although function calls are more expensive than inline code, > > they aren't necessarily a lot more so, and function calls to > > non-locked RMW operations are certainly much cheaper than > > inline locked RMW operations. > > This is

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

> On Mon, Jul 12, 1999 at 07:09:58PM -0700, Mike Smith wrote: > > > Although function calls are more expensive than inline code, > > > they aren't necessarily a lot more so, and function calls to > > > non-locked RMW operations are certainly much cheaper than > > > inline locked RMW operations. >

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 macros are then {

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

:... I would also like to add a few more notes in regards to write pipelines. Write pipelines are not used any more, at least not long ones. The reason is simply the cache coherency issue again. Until the data is actually written into the L1 cache, it is acoherent. Acoher

Re: Using float emulator on a system with FPU?

On Mon, 12 Jul 1999, 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... I've got a few. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | |

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

>Second answer: in the real world, we're nearly always hitting the >cache on stack operations associated with calls and argument passing, >but not less often on operations in the procedure body. So, in ^^^ typo Urk. I meant to say "less often", delete the "not". To Unsubscribe: send mail

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

>This is a fairly key statement in context, and an opinion here would >count for a lot; are function calls likely to become more or less >expensive in time? Ambiguous question. First answer: Assume we're hitting the cache, taking no branch mispredicts, and everything is generally going at "the

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

Matthew Dillon <[EMAIL PROTECTED]> wrote: >:[1] A locked instruction implies a synchronous RMW cycle. In order >:to meet write-ordering guarantees (without which, a locked RMW >:cycle would be useless as a semaphore primitive), it implies a >:complete write serialization, and probably

Re: HELP!!! -CURRENT libtool problem.

> You're correct in that better awareness is almost definitely the key. > Would you consider posting the -stable and -current port build results You can find the realtime results from http://bento.freebsd.org/ -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send ma

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 Mon, Jul 12, 1999 at 10:53:49PM +0400, Dmitrij Tejblum wrote: > > I don't see how MAP_ANON is better than MAP_STACK. > It consumes fewer resources. Each time you grow the stack, it adds another vm_map_entry to the vm_map and (eventually) allocates another vm_object. Using MAP_ANON, there i