Re: FreeBSD Project management (was: Patch sets to date and timi

2002-02-20 Thread George V. Neville-Neil

> There is http://www.freebsd.org/smp/
> 
> If someone wanted to convert this over to Twiki, go for it.  New ideas to add
> to the list are welcome as well.
> 

I'll install TWiki on my home server tomorrow and publish when I'm ready,
probably a day or so if all goes well.

Then people can try it out and if people like it that will be fine.

I'll write up a short email with pointers etc. so people will have an idea what
to expect.

If people hate it, well there is always rm :-)

Later,
George
-- 
George V. Neville-Neil  [EMAIL PROTECTED]
NIC:GN82 

"Those who would trade liberty for temporary security deserve neither" 
- Benjamin Franklin



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Patch to improve mutex collision performance

2002-02-20 Thread Greg Lehey

On Wednesday, 20 February 2002 at 23:48:12 -0500, John Baldwin wrote:
>
> On 21-Feb-02 Greg Lehey wrote:
>> On Monday, 18 February 2002 at 15:38:07 -0500, Jake Burkholder wrote:
>>> Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800,
>>>  Matthew Dillon said words to the effect of;
 I'm fairly sure JHB does not have a patch to address this but, please,
 be my guest and check P4.
>>>
>>> Actually he does.  Maybe you should have checked p4 first yourself.
>>
>> Well, maybe, like me, he doesn't know how.  I only recently learnt of
>> the existence of this repo, and I still don't know where it is.  It
>> certainly wasn't announced on the SMP mailing list.  I've seen a few
>> references to p4 there, but no indication of how to access the repo.
>>
>>> What John's patch does is spin while the lock owner is running on
>>> another cpu.  Spinning while there are no other processes on the run
>>> queues as well makes sense but you'll also be doing a lot of
>>> acquires and releases of sched_lock.
>>
>> I must be misinterpreting this statement.  Under what circumstances do
>> you spin?  Yes, I read the "while the owner is running in another
>> CPU", but the way I read that, it turns the blocking lock into a spin
>> lock.
>
> Only in some cases.  This is the classic way of implementing an adaptive mutex.

Well, no, the classic way of implementing an adaptive lock is to spin
a little bit and then block.  Alternatives would be to learn what's
going on and then decide whether to spin or block, or how long to spin
before blocking.  I've never heard it applied to a choice of CPU.
Obviously any "spin lock" shouldn't spin if the lock holder is in the
same CPU.

> You spin if the other thread is actually executing on another CPU (the idea
> being it will release the lock soon so you are better off avoiding the context
> switch) and block if it is not executing on another CPU (releasing the lock is
> already at least one context switch away, so we might as well
> switch).

If you're talking about Giant here, one of us is seriously
misunderstanding something.  The whole idea of Giant is that it should
be a blocking lock, not a spin lock.  Tell me I'm misunderstanding
you.  The very first project milestone at http://www.freebsd.org/smp/
read "Convert the giant lock from spinning to blocking".

You might say "ah, but the average system call takes less time than a
schedule".  We can test that.  I've run lmbench on zaphod and found:

Scheduling overhead:18 µs
Null syscall (1 CPU):9 µs
Null syscall (2 CPUs):  57 µs

So this doesn't stand up.  Note also that if there are more than two
CPUs, the loss of time is much more significant.

Greg
--
See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: FreeBSD Project management (was: Patch sets to date and timi

2002-02-20 Thread John Baldwin


On 21-Feb-02 George V. Neville-Neil wrote:
> I'm not in the core of the SMP stuff  (the closest I'll get is the
> networking stuff) but I wonder if there is:
> 
> 1) A work list of things that need to be done.
> 
> 2) If that list is easy to read/update.
> 
> Has anyone considered a Wiki to do this kind of coordination?  We used
> TWiki at my last employer to decent effect.  Check out www.twiki.org.

There is http://www.freebsd.org/smp/

If someone wanted to convert this over to Twiki, go for it.  New ideas to add
to the list are welcome as well.

> Later,
> George
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: RE: Patch to improve mutex collision performance

2002-02-20 Thread John Baldwin


On 21-Feb-02 Matthew Dillon wrote:
> This sounds better but why do we need a 'pause' at all?  I don't
> think spinning in this case will have any effect on power
> consumption.

The pause is extra stuff mostly needed for the HyperThreading stuff on the
Pentium4 and also it helps improve cache performance on the P4.  Talk to Peter
about it.  It's really a separate deal but this was a quick cut 'n paste.  The
actual kernel preemption code will reduce the number of context switches back
and forth on mutex release since it only preempts the kernel for real-time (i.e.
interrupt) kernel threads.  Currently we will preempt one non-RT kthread for
another.  When I talked to the guy who worked on Irix's ithread stuff at
Usenix, he said that adaptive locks actually ended up hurting performance, so I
would prefer to not put this in until after preemption is in and then do some
testing to see if adaptive mutexes help or hurt more.

>   -Matt
>   Matthew Dillon 
>   <[EMAIL PROTECTED]>
> 
>:I would rather make the locks adaptive like so:  (untested)
>:
>:--- //depot/projects/smpng/sys/conf/options 2002/02/08 13:19:07
>:+++ //depot/user/jhb/lock/conf/options  2002/02/08 13:50:54
>:@@ -56,6 +56,7 @@
>:# mapped I/O
>: 
>: # Miscellaneous options.
>:+ADAPTIVE_MUTEXES
>: BLEED
>: COMPAT_43  opt_compat.h
>: COMPAT_SUNOS   opt_compat.h
>:--- //depot/projects/smpng/sys/i386/include/cpufunc.h   2001/12/18 13:07:32
>:+++ //depot/user/jhb/lock/i386/include/cpufunc.h2001/12/20 15:54:32
>:@@ -550,6 +550,12 @@
>:__asm __volatile("movl %0,%%dr7" : : "r" (sel));
>: }
>: 
>:+static __inline void
>:+cpu_pause(void)
>:+{
>:+   __asm __volatile("pause");
>:+}
>:+
>: static __inline critical_t
>: cpu_critical_enter(void)
>: {
>:--- //depot/projects/smpng/sys/kern/kern_mutex.c2002/02/08 14:19:21
>:+++ //depot/user/jhb/lock/kern/kern_mutex.c 2002/02/08 13:50:54
>:@@ -34,6 +34,7 @@
>:  * Machine independent bits of mutex implementation.
>:  */
>: 
>:+#include "opt_adaptive_mutexes.h"
>: #include "opt_ddb.h"
>: 
>: #include 
>:@@ -345,7 +354,22 @@
>:continue;
>:}
>: 
>:+#if defined(SMP) && defined(ADAPTIVE_MUTEXES)
>:/*
>:+* If the current owner of the lock is executing on another
>:+* CPU, spin instead of blocking.
>:+*/
>:+   if (((struct thread *)(v & MTX_FLAGMASK)->td_kse->kse_oncpu
>:!=
>:+   NOCPU) {
>:+   mtx_unlock_spin(&sched_lock);
>:+#ifdef __i386__
>:+   cpu_pause();
>:+#endif
>:+   continue;
>:+   }
>:+#endif /* SMP && ADAPTIVE_MUTEXES */
>:+
>:+   /*
>: * We deffinately must sleep for this lock.
>: */
>:mtx_assert(m, MA_NOTOWNED);
>:@@ -433,6 +457,9 @@
>:/* Give interrupts a chance while we spin. */
>:critical_exit();
>:while (m->mtx_lock != MTX_UNOWNED) {
>:+#ifdef __i386__
>:+   cpu_pause();
>:+#endif
>:if (i++ < 1000)
>:continue;
>:if (i++ < 6000)
>:
>:This is more a specific problem with Giant and I don't think it will be a
>:problem with other mutexes, so I'd prefer a solution not quite so tailored to
>:this particular behavior of Giant.
>:
>:-- 
>:
>:John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
>:"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Patch to improve mutex collision performance

2002-02-20 Thread John Baldwin


On 21-Feb-02 Greg Lehey wrote:
> On Monday, 18 February 2002 at 15:38:07 -0500, Jake Burkholder wrote:
>> Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800,
>>  Matthew Dillon said words to the effect of;
>>> I'm fairly sure JHB does not have a patch to address this but, please,
>>> be my guest and check P4.
>>
>> Actually he does.  Maybe you should have checked p4 first yourself.
> 
> Well, maybe, like me, he doesn't know how.  I only recently learnt of
> the existence of this repo, and I still don't know where it is.  It
> certainly wasn't announced on the SMP mailing list.  I've seen a few
> references to p4 there, but no indication of how to access the repo.
> 
>> What John's patch does is spin while the lock owner is running on
>> another cpu.  Spinning while there are no other processes on the run
>> queues as well makes sense but you'll also be doing a lot of
>> acquires and releases of sched_lock.
> 
> I must be misinterpreting this statement.  Under what circumstances do
> you spin?  Yes, I read the "while the owner is running in another
> CPU", but the way I read that, it turns the blocking lock into a spin
> lock.

Only in some cases.  This is the classic way of implementing an adaptive mutex.
You spin if the other thread is actually executing on another CPU (the idea
being it will release the lock soon so you are better off avoiding the context
switch) and block if it is not executing on another CPU (releasing the lock is
already at least one context switch away, so we might as well switch).

> Greg
> --
> See complete headers for address and phone numbers
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Patch to improve mutex collision performance

2002-02-20 Thread Matthew Dillon


:Matthew Dillon wrote:
:> I'm not interested in using P4.  I think it's a mistake.  That is, I
:> think it is being severely overused.  At the very least it is preventing
:> me from comitting simple things to -current because as far as I can tell
:> when you add up the junk sitting in P4 it touches almost every file
:> in the kernel tree.  Everything I've tried to work on has some hack
:> sitting in P4 somewhere that somebody hasn't committed.
:
:By the same token, you have also stated:
:
:] Well... try again.  If something ought to be compatible in a piecemeal
:]commit and isn't, then something unexpected happened and you need to
:]find out what it was.  Doing a full-on commit for something like the
:]proc lock patch is far too dangerous.  It's just too large a patch set
:]and we know from experience (cam, softupdates, etc...) that having a
:]small handful of people testing a large private patch is not going to
:]find all the bugs.
:
:How do you reconcile these divergent points of view?

These are not divergent points of view.  I am saying quite clearly that
the ucred code and proc-locking code can be committed in a piecemeal
fashion.  In fact, good chunk of the proc locking code already has been
with no ill effect on the tree - it might not be completely operational
due to Giant, but just comitting it tests a great deal of infrastructure
including potential lock order reversals and mismatched locks.  That's
the whole point of doing things this way.

:What large scale changes are "OK", and what large scale changes
:are "too dangerous"?

The best example I can think of is Julian's initial KSE commit, where
he rearranged the proc structure.  The rearrangement touched a huge
number of files and the commit had to be made all at once, not file by
file, due to the structural changes. 

:Do you have a set of rules, that would let us look at a patch
:set and instantly decide which of these two categories the
:code fell into?
:
:I'm not trying to be a jerk, but not everything can be broken
:down into 1 line commits, and not everything can be broken down
:into 8 line commits, or 64 line commits, or 512 line commits,
:etc. (if you'll forgive my proof by induction).
:
:-- Terry

This is getting a bit absurd.  I am arguing a general principle here,
you are not contributing anything by stretching it into an irrational
statement.  One line commits?  Oh come on!

I will say that the work *I* am doing on -current is mostly piecemeal
in nature.  I even expect the VM locking to wind up being piecemeal.
Everything I have posted to date has been piecemeal.  For example,
the ucred patchset I posted does not patch all the ucred functions,
it just patched the read-only functions.  But as a side effect that
gave me a basis to track down the other uses of Giant in the general
syscall path.  That was a good demarkation point for me.  It is by
no means the end... it is, as I have said, piecemeal.

The result?  I was able to immediately note the use of Giant in
trap.c (the ucred clearing code) as well as its use in userret(),
plus I could test a few of the ucred functions like getuid() and test
the Giant instrumentation.

So you see, a piecemeal commit can have a great ability to move the
development process forward.  When you spend weeks or months putting
together an UBER-patch you do not get any of that... it's all delayed
and when the patch finally goes in people wind up spending a lot of
time testing the patch itself rather then working on the ramification
of what the patch allows you to move on to.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



make release failure in kerberos

2002-02-20 Thread John Hay

Hi Jacques,

Make release fails here. Can it be your changes to kerberos?

John
-- 
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]


===> libexec/kdc
...
cc -O -pipe  -I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/include  
-I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc  
-I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/lib/krb5  
-I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/lib/asn1  
-I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/lib/hdb  
-I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/lib/roken  
-I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kuser  
-I/usr/obj/usr/src/kerberos5/libexec/kdc/../../lib/libasn1  
-I/usr/obj/usr/src/kerberos5/libexec/kdc/../../lib/libhdb  
-I/usr/obj/usr/src/kerberos5/libexec/kdc -Wall 
-I/usr/src/kerberos5/libexec/kdc/../../include 
-I/usr/src/kerberos5/libexec/kdc/../../include -DHAVE_CONFIG_H -DINET6-c 
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c: In function 
`create_reply_ticket':
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:254: syntax 
error before `ticket'
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:268: warning: 
implicit declaration of function `krb_create_ticket'
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:268: `ticket' 
undeclared (first use in this function)
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:268: (Each 
undeclared identifier is reported only once
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:268: for each 
function it appears in.)
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:282: warning: 
implicit declaration of function `krb_life_to_time'
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c: In function 
`do_authenticate':
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:405: `v4_realm' 
undeclared (first use in this function)
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:407: warning: 
implicit declaration of function `db_fetch4'
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:435: warning: 
implicit declaration of function `get_des_key'
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:483: warning: 
implicit declaration of function `krb_time_to_life'
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c: In function 
`do_getticket':
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:587: `ANAME_SZ' 
undeclared (first use in this function)
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:588: `INST_SZ' 
undeclared (first use in this function)
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:589: `REALM_SZ' 
undeclared (first use in this function)
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:599: `v4_realm' 
undeclared (first use in this function)
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:646: syntax 
error before `ticket'
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:651: `SNAME_SZ' 
undeclared (first use in this function)
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:654: `ticket' 
undeclared (first use in this function)
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:666: warning: 
implicit declaration of function `decomp_ticket'
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:651: warning: 
unused variable `sinstance'
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:650: warning: 
unused variable `sname'
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:589: warning: 
unused variable `prealm'
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:588: warning: 
unused variable `pinst'
/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:587: warning: 
unused variable `pname'
*** Error code 1

Stop in /usr/src/kerberos5/libexec/kdc.
*** Error code 1

Stop in /usr/src/kerberos5/libexec.
*** Error code 1

Stop in /usr/src/kerberos5.
*** Error code 1

Stop in /usr/src/release.
*** Error code 1

Stop in /home/src/release.
End Thu Feb 21 01:27:59 SAST 2002

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Version control software (was: Patch sets to date and timing tests with Giant out of userret.)

2002-02-20 Thread Terry Lambert

Greg Lehey wrote:
> On Tuesday, 19 February 2002 at 16:44:06 -0800, David O'Brien wrote:
> > On Tue, Feb 19, 2002 at 01:51:31PM -0700, M. Warner Losh wrote:
> >> Bitkeeper enforces the linux devleopment model
> >> to a large extent,
> >
> > In what way(s)?
> 
> I'd be interested in this too.  I've been using Bitkeeper for, well,
> Linux development, but I don't see anything which locks it in to that
> direction.  Of course, Bitkeeper isn't free either, so there's no
> particular reason to prefer it to p4.

Bitkeeper is free if you publish your repository; P4 is free
if you are a free software project.  Otherwise, they cost.

Both are barriers to commercial utilization of free code, in
the same way.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Patch to improve mutex collision performance

2002-02-20 Thread Terry Lambert

Matthew Dillon wrote:
> I'm not interested in using P4.  I think it's a mistake.  That is, I
> think it is being severely overused.  At the very least it is preventing
> me from comitting simple things to -current because as far as I can tell
> when you add up the junk sitting in P4 it touches almost every file
> in the kernel tree.  Everything I've tried to work on has some hack
> sitting in P4 somewhere that somebody hasn't committed.

By the same token, you have also stated:

] Well... try again.  If something ought to be compatible in a piecemeal
]commit and isn't, then something unexpected happened and you need to
]find out what it was.  Doing a full-on commit for something like the
]proc lock patch is far too dangerous.  It's just too large a patch set
]and we know from experience (cam, softupdates, etc...) that having a
]small handful of people testing a large private patch is not going to
]find all the bugs.

How do you reconcile these divergent points of view?


> I would like to see John commit his ucred stuff with Giant
> instrumentation.  If he doesn't want to do it then I would like him
> to give me permission to do it from my tree now.  I see no reason why
> we should have to wait another X days or weeks to see this stuff in
> the main tree.  It just makes no sense to me.

What large scale changes are "OK", and what large scale changes
are "too dangerous"?

Do you have a set of rules, that would let us look at a patch
set and instantly decide which of these two categories the
code fell into?

I'm not trying to be a jerk, but not everything can be broken
down into 1 line commits, and not everything can be broken down
into 8 line commits, or 64 line commits, or 512 line commits,
etc. (if you'll forgive my proof by induction).

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Perforce repo (was: Patch sets to date and timing tests with Giant out of userret.)

2002-02-20 Thread Bernd Walter

On Wed, Feb 20, 2002 at 06:31:14PM -0800, Julian Elischer wrote:
> 
> 
> 
> On Thu, 21 Feb 2002, Greg Lehey wrote:
> 
> > On Tuesday, 19 February 2002 at  0:00:19 -0800, Peter Wemm wrote:
> 
> > Am I the only person who, despite careful scrutiny, missed this
> > announcement?  I would have thought that this would at least have been
> > worth a HEADS UP and prior discussion in -core.  I've just checked my
> > -core archive, and though we discuss this repo from time to time,
> > there was nothing there to suggest that it was publicly available.
> 
> Even better is that the stuff is exported to a CVS tree and CVSupped out 
> so you can actually work on it.
> (of course the version numbers are wierd but that doesn't matter)

There is still missing an overview over the p4 collections.
No - I'm not going to cvsup p4-all - I already had an increasing of
1G overnight without a single warning.
A p4-self collection is also missing.

-- 
B.Walter  COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)

2002-02-20 Thread Greg Lehey

On Wednesday, 20 February 2002 at 21:42:48 -0500, Andrew R. Reiter wrote:
> On Wed, 20 Feb 2002, George V. Neville-Neil wrote:
>
>> I'm not in the core of the SMP stuff  (the closest I'll get is the
>> networking stuff) but I wonder if there is:
>
> Doesn't this belong on [EMAIL PROTECTED] so that SMP people could
> answer?

Only up to  a point.  My issues (and George's, for that matter) are
the project management side of things.  I'm copying -developers, but
maybe we need a different list: I'm open to suggestions.  Maybe it's a
symptom of the problem that there's no project management list.

Greg
--
See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)

2002-02-20 Thread Greg Lehey

On Wednesday, 20 February 2002 at 18:35:37 -0800, Alfred Perlstein wrote:
> * Greg Lehey <[EMAIL PROTECTED]> [020220 18:26] wrote:
>>
>> I'm not picking on jhb here.  This is the project's fault, not any
>> individual's.  We need some kind of project management to coordinate
>> this effort, or the results will be seriously suboptimal.  I would
>> certainly not like to see dillon go away because it's too difficult to
>> work with the project.
>
> First with the code complete has it go in.  Seems pretty simple
> enough doesn't it?

Too simple.  It's not the "code complete", it's the correct code to
implement a part of the overall goal.  And we should be working
together, not duplicating each other's efforts.

> I've had quite enough of people telling others to hold off because
> "i'll have the feature any day now", or "that fix is in my local
> tree".

That's a detail, though admittedly one that needs to be addressed.  We
have more serious issues.  Last Friday I asked for an overall project
plan, and I still haven't seen one.  Yes, we had some useful
discussions, but it's still not enough.  If it took Sun 8 years of
(relatively) careful project planning to get their SMP up to a
reasonable standard, how can we hope to succeed if we don't even
decide what we're trying to do?

Two years ago I spoke with you on the phone about SMP, and said that I
didn't think that the project could cope with such a pervasive change.
That's why I was happy when BSD[Ii] dropped both the design and the
code into our lap, and we had an SMP project manager (for all of 6
months).  Looking back now, we're making the same old mistakes.

Greg
--
See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)

2002-02-20 Thread Andrew R. Reiter

On Wed, 20 Feb 2002, George V. Neville-Neil wrote:

:I'm not in the core of the SMP stuff  (the closest I'll get is the
:networking stuff) but I wonder if there is:

Doesn't this belong on [EMAIL PROTECTED] so that SMP people could answer?

:
:1) A work list of things that need to be done.
:
:2) If that list is easy to read/update.
:
:Has anyone considered a Wiki to do this kind of coordination?  We used
:TWiki at my last employer to decent effect.  Check out www.twiki.org.
:
:Later,
:George
:
:To Unsubscribe: send mail to [EMAIL PROTECTED]
:with "unsubscribe freebsd-current" in the body of the message
:

--
Andrew R. Reiter
[EMAIL PROTECTED]
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Perforce repo (was: Patch sets to date and timing tests withGiant out of userret.)

2002-02-20 Thread Julian Elischer




On Thu, 21 Feb 2002, Greg Lehey wrote:

> On Tuesday, 19 February 2002 at  0:00:19 -0800, Peter Wemm wrote:

> Am I the only person who, despite careful scrutiny, missed this
> announcement?  I would have thought that this would at least have been
> worth a HEADS UP and prior discussion in -core.  I've just checked my
> -core archive, and though we discuss this repo from time to time,
> there was nothing there to suggest that it was publicly available.

Even better is that the stuff is exported to a CVS tree and CVSupped out 
so you can actually work on it.
(of course the version numbers are wierd but that doesn't matter)

> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)

2002-02-20 Thread George V. Neville-Neil

I'm not in the core of the SMP stuff  (the closest I'll get is the
networking stuff) but I wonder if there is:

1) A work list of things that need to be done.

2) If that list is easy to read/update.

Has anyone considered a Wiki to do this kind of coordination?  We used
TWiki at my last employer to decent effect.  Check out www.twiki.org.

Later,
George

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)

2002-02-20 Thread Alfred Perlstein

* Greg Lehey <[EMAIL PROTECTED]> [020220 18:26] wrote:
> 
> I'm not picking on jhb here.  This is the project's fault, not any
> individual's.  We need some kind of project management to coordinate
> this effort, or the results will be seriously suboptimal.  I would
> certainly not like to see dillon go away because it's too difficult to
> work with the project.

First with the code complete has it go in.  Seems pretty simple
enough doesn't it?

I've had quite enough of people telling others to hold off because
"i'll have the feature any day now", or "that fix is in my local
tree".

Like I care about your local tree, it's useless from my point of
view when it's not working and in the repo.

And what the hell has happened to the usb stack?

-Alfred

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)

2002-02-20 Thread Greg Lehey

On Monday, 18 February 2002 at 23:04:03 -0800, Peter Wemm wrote:
> Matthew Dillon wrote:
>>> What a waste.. John has already done all this stuff already (using
>>> td_ucred instead of p_ucred) over the entire tree.
>>>
>>> Cheers,
>>> -Peter
>>
>> He didn't instrument Giant, and if you actually believe that one
>> massive commit is going to be more stable then the piecemeal safe-mode
>> commits I am making then you are smoking something.  Or are you
>> expecting John to commit his patchset piecemeal as well and test
>> inbetween?  If that is so, then he just wasted a whole lot time
>> managing all this junk in P4 because, frankly, it only took me a few
>> minutes to instrument the easier system calls.  I spend far more
>> time testing.
>
> So, John's last few months of work is junk then, is it?

On Monday, 18 February 2002 at 23:22:28 -0800, Peter Wemm wrote:
> Matthew Dillon wrote:
>>>
>>> So, John's last few months of work is junk then, is it?
>>>
>>> Cheers,
>>> -Peter
>>> --
>>> Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>>
>> I'll tell you what is junk... patches for things like getuid() sitting
>> in P4 (whether instrumented or not).  That's junk.
>>
>> I'll tell what is NOT junk.  What isn't junk are things like John's more
>> complex patch to kern_descrip.c.  There's real work involved there
>> that can be salvaged, and which can be committed to the -current
>> piecemeal if Giant is properly instrumented.
>>
>> The biggest problem is that all of this stuff is sitting in P4 and none
>> of it belongs there.
>
> With all due respect, bullshit!  The p4 tree exists only as an
> alternative to people having large uncommitted diffs sitting in
> checked out cvs trees.
>
> Mailing patches between people trying to work in parallel is a
> bigger waste of time.  That is inherently single threaded.

While I don't agree with dillon's tone, I can understand his
frustration.  There is a lack of communication in the SMP project.  I
might have done more myself if I had been able to follow it without
being on IRC 24 hours a day.  I suspect that this applies to other
people as well.

Note that dillon has suffered because of this.  He has gone and done
what looks like being unnecessary work.  When he tries to commit it,
he finds that somebody else has been working on it, and despite a
kernel summit only a couple of days ago, he didn't know about it.

I'm not picking on jhb here.  This is the project's fault, not any
individual's.  We need some kind of project management to coordinate
this effort, or the results will be seriously suboptimal.  I would
certainly not like to see dillon go away because it's too difficult to
work with the project.

Greg
--
See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Perforce repo (was: Patch sets to date and timing tests with Giant out of userret.)

2002-02-20 Thread Greg Lehey

On Tuesday, 19 February 2002 at  0:00:19 -0800, Peter Wemm wrote:
> Julian Elischer wrote:
>> I'd prefer to be working on a branch of CVS if it weren't for the people
>> that would scream whenever I moved my merged tag up.
>> (eek eek cvsup bloat).
>> That way i would have a dozen people helping me but with my code in P4 I
>> have me and occasionally Peter.
>
> Everybody who can commit to cvs on freefall also has p4 access. 

Well, I certainly missed this.

> The set of people who can help is exactly the same.  In fact, we
> even have a couple of non-comitters with access.  As I posted
> before,

When?

> the instructions are in
> http://people.freebsd.org/~peter/p4cookbook.txt, and the 'p4newuser'
> command on freefall is what is run to activate it.  If we want a
> majordomo [EMAIL PROTECTED] mailing list (or something like that,
> as an analog to [EMAIL PROTECTED]), I can have that set up as
> well.

Am I the only person who, despite careful scrutiny, missed this
announcement?  I would have thought that this would at least have been
worth a HEADS UP and prior discussion in -core.  I've just checked my
-core archive, and though we discuss this repo from time to time,
there was nothing there to suggest that it was publicly available.

Greg
--
See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Version control software (was: Patch sets to date and timing tests with Giant out of userret.)

2002-02-20 Thread Greg Lehey

On Tuesday, 19 February 2002 at 16:44:06 -0800, David O'Brien wrote:
> On Tue, Feb 19, 2002 at 01:51:31PM -0700, M. Warner Losh wrote:
>> Bitkeeper enforces the linux devleopment model
>> to a large extent,
>
> In what way(s)?

I'd be interested in this too.  I've been using Bitkeeper for, well,
Linux development, but I don't see anything which locks it in to that
direction.  Of course, Bitkeeper isn't free either, so there's no
particular reason to prefer it to p4.

Greg
--
See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Patch to improve mutex collision performance

2002-02-20 Thread Matthew Dillon


:On Monday, 18 February 2002 at 15:38:07 -0500, Jake Burkholder wrote:
:> Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800,
:>  Matthew Dillon said words to the effect of;
:>> I'm fairly sure JHB does not have a patch to address this but, please,
:>> be my guest and check P4.
:>
:> Actually he does.  Maybe you should have checked p4 first yourself.
:
:Well, maybe, like me, he doesn't know how.  I only recently learnt of
:the existence of this repo, and I still don't know where it is.  It
:certainly wasn't announced on the SMP mailing list.  I've seen a few
:references to p4 there, but no indication of how to access the repo.
:
:> What John's patch does is spin while the lock owner is running on
:> another cpu.  Spinning while there are no other processes on the run
:> queues as well makes sense but you'll also be doing a lot of
:> acquires and releases of sched_lock.
:
:I must be misinterpreting this statement.  Under what circumstances do
:you spin?  Yes, I read the "while the owner is running in another
:CPU", but the way I read that, it turns the blocking lock into a spin
:lock.
:
:Greg

I'm not interested in using P4.  I think it's a mistake.  That is, I
think it is being severely overused.  At the very least it is preventing
me from comitting simple things to -current because as far as I can tell
when you add up the junk sitting in P4 it touches almost every file 
in the kernel tree.  Everything I've tried to work on has some hack
sitting in P4 somewhere that somebody hasn't committed.

Well, that sucks folks.  I want to be able to work on -current.  There
are literally 20 or 30 procedures that I can document and/or instrument
Giant in and commit to the main tree trivially, with almost no chance of
breaking someone and I want to do that to get those routines out of the
way. 

I have no interest in taking what should be a day's worth of work and
stretching out into one or two weeks due to having to check P4 to see 
what hacks other people might have left sitting there for weeks or months
(half of it stale now).  It is a supreme waste of time.

I would like to see John commit his ucred stuff with Giant 
instrumentation.  If he doesn't want to do it then I would like him
to give me permission to do it from my tree now.  I see no reason why
we should have to wait another X days or weeks to see this stuff in
the main tree.  It just makes no sense to me.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: RE: Patch to improve mutex collision performance

2002-02-20 Thread Matthew Dillon

This sounds better but why do we need a 'pause' at all?  I don't
think spinning in this case will have any effect on power
consumption.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>

:I would rather make the locks adaptive like so:  (untested)
:
:--- //depot/projects/smpng/sys/conf/options 2002/02/08 13:19:07
:+++ //depot/user/jhb/lock/conf/options  2002/02/08 13:50:54
:@@ -56,6 +56,7 @@
:# mapped I/O
: 
: # Miscellaneous options.
:+ADAPTIVE_MUTEXES
: BLEED
: COMPAT_43  opt_compat.h
: COMPAT_SUNOS   opt_compat.h
:--- //depot/projects/smpng/sys/i386/include/cpufunc.h   2001/12/18 13:07:32
:+++ //depot/user/jhb/lock/i386/include/cpufunc.h2001/12/20 15:54:32
:@@ -550,6 +550,12 @@
:__asm __volatile("movl %0,%%dr7" : : "r" (sel));
: }
: 
:+static __inline void
:+cpu_pause(void)
:+{
:+   __asm __volatile("pause");
:+}
:+
: static __inline critical_t
: cpu_critical_enter(void)
: {
:--- //depot/projects/smpng/sys/kern/kern_mutex.c2002/02/08 14:19:21
:+++ //depot/user/jhb/lock/kern/kern_mutex.c 2002/02/08 13:50:54
:@@ -34,6 +34,7 @@
:  * Machine independent bits of mutex implementation.
:  */
: 
:+#include "opt_adaptive_mutexes.h"
: #include "opt_ddb.h"
: 
: #include 
:@@ -345,7 +354,22 @@
:continue;
:}
: 
:+#if defined(SMP) && defined(ADAPTIVE_MUTEXES)
:/*
:+* If the current owner of the lock is executing on another
:+* CPU, spin instead of blocking.
:+*/
:+   if (((struct thread *)(v & MTX_FLAGMASK)->td_kse->kse_oncpu !=
:+   NOCPU) {
:+   mtx_unlock_spin(&sched_lock);
:+#ifdef __i386__
:+   cpu_pause();
:+#endif
:+   continue;
:+   }
:+#endif /* SMP && ADAPTIVE_MUTEXES */
:+
:+   /*
: * We deffinately must sleep for this lock.
: */
:mtx_assert(m, MA_NOTOWNED);
:@@ -433,6 +457,9 @@
:/* Give interrupts a chance while we spin. */
:critical_exit();
:while (m->mtx_lock != MTX_UNOWNED) {
:+#ifdef __i386__
:+   cpu_pause();
:+#endif
:if (i++ < 1000)
:continue;
:if (i++ < 6000)
:
:This is more a specific problem with Giant and I don't think it will be a
:problem with other mutexes, so I'd prefer a solution not quite so tailored to
:this particular behavior of Giant.
:
:-- 
:
:John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
:"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Patch to improve mutex collision performance

2002-02-20 Thread Greg Lehey

On Monday, 18 February 2002 at 15:38:07 -0500, Jake Burkholder wrote:
> Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800,
>   Matthew Dillon said words to the effect of;
>> I'm fairly sure JHB does not have a patch to address this but, please,
>> be my guest and check P4.
>
> Actually he does.  Maybe you should have checked p4 first yourself.

Well, maybe, like me, he doesn't know how.  I only recently learnt of
the existence of this repo, and I still don't know where it is.  It
certainly wasn't announced on the SMP mailing list.  I've seen a few
references to p4 there, but no indication of how to access the repo.

> What John's patch does is spin while the lock owner is running on
> another cpu.  Spinning while there are no other processes on the run
> queues as well makes sense but you'll also be doing a lot of
> acquires and releases of sched_lock.

I must be misinterpreting this statement.  Under what circumstances do
you spin?  Yes, I read the "while the owner is running in another
CPU", but the way I read that, it turns the blocking lock into a spin
lock.

Greg
--
See complete headers for address and phone numbers

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: ports/34908: libpng port makes bad dynamic library on -CURRENT

2002-02-20 Thread Stijn Hoop

Hi -current,

I ventured into this brave new world a few days ago and ran into
this very problem. Alexander's patch (along with a make install in
/usr/src/gnu/usr.bin/binutils) fixed it, as advertised.

Maybe this can now be committed?

--Stijn

-- 
Help Wanted: Telepath. You know where to apply.



msg34978/pgp0.pgp
Description: PGP signature


Re: Patch sets to date and timing tests with Giant out of userre

2002-02-20 Thread John Baldwin


On 19-Feb-02 Terry Lambert wrote:
> Julian Elischer wrote:
>> The fully safe version of this code is:
>> td->td_retval[0] = td->td_ucred->cr_ruid;
>> td->td_retval[1] = td->td_ucred->cr_uid;
>> return (0);
>> 
>> because td->td_ucred is read-only for it's whole existance.
> 
> ???
> 
> Are you sure that td->td_ucred can't change in the middle,
> to point to a different ucred, as a result of kernel
> preemption?

Yes.  A thread's ucred pointer is constant teh entire time that it is in the
kernel.  If we get preempted who cares.  We will still be teh same thread when
we continue executing. :)

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



RE: Patch to improve mutex collision performance

2002-02-20 Thread John Baldwin


On 18-Feb-02 Matthew Dillon wrote:
> While testing some Giant removal stuff I noticed that my current
> system sometimes got into an extremely non-optimal flip-flop situation
> between two processes contesting Giant on an SMP system which halved the
> syscall performance in the test.
> 
> In my getuid test, for example, with Giant in place I was getting
> 683Kcalls/sec with one process and 427Kcalls/sec with two.  Giant
> was being obtained in two places: in userret and in getuid().
> 
> When I turned off Giant in getuid() the syscall performance actually
> went DOWN, to 250Kcalls/sec with two processes.  This was a totally
> unexpected result.
> 
> It turns out that the two processes got into an extremely non-optimal 
> contested/sleep/wakeup situation, even though they do not actually have
> to sleep on Giant in this situation.
> 
> The solution is to allow _mtx_lock_sleep() to spin instead of sleep in
> the situation where:  (1) there are no runnable processes other then
> the ones already running on a cpu, (2) interrupts are enabled, and 
> (3) the mutex in question is not contested (to avoid starving the thread
> contesting the mutex).  In this case we can spin.
> 
> This will go in tonight if no problems arise.

I would rather make the locks adaptive like so:  (untested)

--- //depot/projects/smpng/sys/conf/options 2002/02/08 13:19:07
+++ //depot/user/jhb/lock/conf/options  2002/02/08 13:50:54
@@ -56,6 +56,7 @@
# mapped I/O
 
 # Miscellaneous options.
+ADAPTIVE_MUTEXES
 BLEED
 COMPAT_43  opt_compat.h
 COMPAT_SUNOS   opt_compat.h
--- //depot/projects/smpng/sys/i386/include/cpufunc.h   2001/12/18 13:07:32
+++ //depot/user/jhb/lock/i386/include/cpufunc.h2001/12/20 15:54:32
@@ -550,6 +550,12 @@
__asm __volatile("movl %0,%%dr7" : : "r" (sel));
 }
 
+static __inline void
+cpu_pause(void)
+{
+   __asm __volatile("pause");
+}
+
 static __inline critical_t
 cpu_critical_enter(void)
 {
--- //depot/projects/smpng/sys/kern/kern_mutex.c2002/02/08 14:19:21
+++ //depot/user/jhb/lock/kern/kern_mutex.c 2002/02/08 13:50:54
@@ -34,6 +34,7 @@
  * Machine independent bits of mutex implementation.
  */
 
+#include "opt_adaptive_mutexes.h"
 #include "opt_ddb.h"
 
 #include 
@@ -345,7 +354,22 @@
continue;
}
 
+#if defined(SMP) && defined(ADAPTIVE_MUTEXES)
/*
+* If the current owner of the lock is executing on another
+* CPU, spin instead of blocking.
+*/
+   if (((struct thread *)(v & MTX_FLAGMASK)->td_kse->kse_oncpu !=
+   NOCPU) {
+   mtx_unlock_spin(&sched_lock);
+#ifdef __i386__
+   cpu_pause();
+#endif
+   continue;
+   }
+#endif /* SMP && ADAPTIVE_MUTEXES */
+
+   /*
 * We deffinately must sleep for this lock.
 */
mtx_assert(m, MA_NOTOWNED);
@@ -433,6 +457,9 @@
/* Give interrupts a chance while we spin. */
critical_exit();
while (m->mtx_lock != MTX_UNOWNED) {
+#ifdef __i386__
+   cpu_pause();
+#endif
if (i++ < 1000)
continue;
if (i++ < 6000)

This is more a specific problem with Giant and I don't think it will be a
problem with other mutexes, so I'd prefer a solution not quite so tailored to
this particular behavior of Giant.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



RE: pgrp/session patch

2002-02-20 Thread John Baldwin


On 19-Feb-02 Seigo Tanimura wrote:
> Here is the most up-to-date version of pgrp/session lock (at Change 6700):
> 
> http://people.FreeBSD.org/~tanimura/patches/pgrp10.diff.gz
> 
> I would like to commit this on the next Sunday. Otherwise, my patch
> would conflict with other patches, especially tty.

I've looked over other versions of this patch and am happy with them, so I have
no objections. :)

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Kernel compile error with today's cvsup.

2002-02-20 Thread Edwin Culp

David,

I see it's already fixed so I'll assume that you no longer need the 
compiler output.  I'm sorry that I didn't answer before but I just
checked my email and went to some meetings and am just getting back.

Thanks for your help,

ed

Quoting David O'Brien <[EMAIL PROTECTED]>:

> On Wed, Feb 20, 2002 at 05:53:59AM -0800, Edwin Culp wrote:
> > On my daily build, my kernels are broken as per log:
> > 
> > ===> wi
> > cd /usr/obj/usr/src/sys/PIII850N; 
> MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm 
> > make -
> > f /usr/src/sys/dev/aic7xxx/aicasm/Makefile
> > Warning: Object directory not changed from original
> /usr/obj/usr/src/sys/PIII850N
> > cc -O -pipe  -I/usr/include -I.-c aicasm_gram.c
> > cc: installation problem, cannot exec `cpp0': No such file or directory
> > cc: installation problem, cannot exec `cc1': No such file or directory
> > *** Error code 1
> 
> 
> I need to see the output of ``/usr/bin/cc -print-search-dirs'' from the
> problematic compiler.
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


-- 
To announce that there must be no criticism of the president,
or that we are to stand by the president, right or wrong, is not
only unpatriotic and servile, but is morally treasonable to
the American public.  - Theodore Roosevelt



---

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Ethernet tunnel device

2002-02-20 Thread Alfred Perlstein

* Terry Lambert <[EMAIL PROTECTED]> [020220 11:13] wrote:
> Mark Santcroos wrote:
> 
> > I managed to create a simple linux program that had the same problem. From
> > there on it was easy...
> > 
> > The problem was created by Alfred's locking commit of Jan 13.
> > (No hard feelings, it helped me to understand the code alot better! ;) )
> > 
> > Can someone please commit the attached (trivial) patch?
> 
> Alfred... that would be for you?  8-).

All patches are trivial, it's the bugs that are a b*tch.

Yes, the patch has been committed. 

-Alfred

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Ethernet tunnel device

2002-02-20 Thread Terry Lambert

Mark Santcroos wrote:
> On Sat, Feb 16, 2002 at 01:02:09AM -0800, Terry Lambert wrote:
> > Pretty clearly, if it happens, and the process is truly
> > gone, then there is a resource track cleanup that's
> > missing (perhaps it's a reference that results from the
> > Linux mmap resource track cleanup not releasing it?).
> 
> It was indeed a linux_compat specific resource cleanup issue.

Cool.  No zebras.  8-).


> I managed to create a simple linux program that had the same problem. From
> there on it was easy...
> 
> The problem was created by Alfred's locking commit of Jan 13.
> (No hard feelings, it helped me to understand the code alot better! ;) )
> 
> Can someone please commit the attached (trivial) patch?

Alfred... that would be for you?  8-).

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: cannot exec `cpp0': No such file or directory

2002-02-20 Thread David O'Brien

On Wed, Feb 20, 2002 at 06:02:38PM +0100, Jose M. Alcaide wrote:
> $ cc p.c -o p
> cc: installation problem, cannot exec `cpp0': No such file or directory

Fixed.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Sorry, false alarm (was: Panic with today's -CURRENT at runq_choose+0x83)

2002-02-20 Thread David Wolfskill

>Date: Wed, 20 Feb 2002 07:49:19 -0800 (PST)
>From: David Wolfskill <[EMAIL PROTECTED]>

>Just built & installed today's -CURRENT (CVSup around 0347 hrs. PST):

>...
>Stopped at  runq_choose+0x83:   movl0(%edx),%eax
>db> trace
>runq_choose(c035a660,d683cd0c,c02b1b3e,c01a8d87,12e) at runq_choose+0x83
>choosethread(c01a8d87,12e,c0196384,d682c500,1a09) at choosethread+0xd
>sw1(d682c600,d683cd34,c01961c4,0,d683cd48) at sw1+0x20
>idle_proc(0,d683cd48,0,c0196384,0) at idle_proc+0x5c
>fork_exit(c0196384,0,d683cd48) at fork_exit+0x9c
>fork_trampoline() at fork_trampoline+0x8

Ahhh... that would seem to have been merely fallout from the upgrade
process I used.  A subsequent reboot worked fine:

freebeast(5.0-C)[1] uname -a
FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #84: Wed Feb 20 
07:20:46 PST 2002 
[EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST  i386
freebeast(5.0-C)[2] 

and I didn't even have the above-referenced panic at all on my laptop:

g1-7(5.0-C)[1] uname -a
FreeBSD g1-7.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Wed Feb 20 09:13:13 
PST 2002 [EMAIL PROTECTED]:/common/S3/obj/usr/src/sys/LAPTOP_30W_NC  i386
g1-7(5.0-C)[2] 


So... move along, folks; nothing to see here  Sorry for the noise.

Cheers,
david   (links to my resume at http://www.catwhisker.org/~david)
-- 
David H. Wolfskill  [EMAIL PROTECTED]
I believe it would be irresponsible (and thus, unethical) for me to advise,
recommend, or support the use of any product that is or depends on any
Microsoft product for any purpose other than personal amusement.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: cannot exec `cpp0': No such file or directory

2002-02-20 Thread Jose M. Alcaide

On Wed, Feb 20, 2002 at 09:21:14AM -0800, David O'Brien wrote:
> I need to see the output of ``/usr/bin/cc -print-search-dirs'' from the
> problematic compiler.

$ /usr/bin/cc -print-search-dirs
install: /usr/libexec/(null)
programs: /usr/libexec/elf/
libraries: /usr/lib/

-- 
** Jose M. Alcaide  //  [EMAIL PROTECTED]  //  [EMAIL PROTECTED] **
** "Beware of Programmers who carry screwdrivers" --  Leonard Brandwein **

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Kernel compile error with today's cvsup.

2002-02-20 Thread David O'Brien

On Wed, Feb 20, 2002 at 05:53:59AM -0800, Edwin Culp wrote:
> On my daily build, my kernels are broken as per log:
> 
> ===> wi
> cd /usr/obj/usr/src/sys/PIII850N;  MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm 
> make -
> f /usr/src/sys/dev/aic7xxx/aicasm/Makefile
> Warning: Object directory not changed from original /usr/obj/usr/src/sys/PIII850N
> cc -O -pipe  -I/usr/include -I.-c aicasm_gram.c
> cc: installation problem, cannot exec `cpp0': No such file or directory
> cc: installation problem, cannot exec `cc1': No such file or directory
> *** Error code 1


I need to see the output of ``/usr/bin/cc -print-search-dirs'' from the
problematic compiler.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: cannot exec `cpp0': No such file or directory

2002-02-20 Thread David O'Brien

On Wed, Feb 20, 2002 at 06:02:38PM +0100, Jose M. Alcaide wrote:
> Using ktrace(1), I found that now cc searchs its subcomponents in
> /usr/libexec/elf. However, installworld puts them in /usr/libexec.
...
> Could this problem be related to the recent changes to
> src/gnu/usr.bin/cc/cc_tools/freebsd-native.h (1.10, 1.11)?

I need to see the output of ``/usr/bin/cc -print-search-dirs'' from the
problematic compiler.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Kernel compile error with today's cvsup.

2002-02-20 Thread John Hay

> On my daily build, my kernels are broken as per log:
> 
> ===> wi
> cd /usr/obj/usr/src/sys/PIII850N;  MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm 
> make -
> f /usr/src/sys/dev/aic7xxx/aicasm/Makefile
> Warning: Object directory not changed from original /usr/obj/usr/src/sys/PIII850N
> cc -O -pipe  -I/usr/include -I.-c aicasm_gram.c
> cc: installation problem, cannot exec `cpp0': No such file or directory
> cc: installation problem, cannot exec `cc1': No such file or directory
> *** Error code 1
> 

I don't think it is the kernel. My "make release" failed with the same
type of error and that machine's kernel is from Jan 28. Maybe it is the
search path that changed in gnu/usr.bin/cc/cc_tools/freebsd-native.h
... Just a guess.

John
-- 
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Ethernet tunnel device

2002-02-20 Thread Alfred Perlstein

* Mark Santcroos <[EMAIL PROTECTED]> [020220 03:52] wrote:
> 
> It was indeed a linux_compat specific resource cleanup issue.
> 
> I managed to create a simple linux program that had the same problem. From 
> there on it was easy...
> 
> The problem was created by Alfred's locking commit of Jan 13.
> (No hard feelings, it helped me to understand the code alot better! ;) )
> 
> Can someone please commit the attached (trivial) patch?

Done.

-Alfred

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



cannot exec `cpp0': No such file or directory

2002-02-20 Thread Jose M. Alcaide

Hello,

Just made world, and now cc(1) fails:

$ cc p.c -o p
cc: installation problem, cannot exec `cpp0': No such file or directory

Using ktrace(1), I found that now cc searchs its subcomponents in
/usr/libexec/elf. However, installworld puts them in /usr/libexec.
Nothing is said about this problem in UPDATING.

Could this problem be related to the recent changes to
src/gnu/usr.bin/cc/cc_tools/freebsd-native.h (1.10, 1.11)?

Cheers,
JMA
-- 
** Jose M. Alcaide  //  [EMAIL PROTECTED]  //  [EMAIL PROTECTED] **
** "Beware of Programmers who carry screwdrivers" --  Leonard Brandwein **

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Panic with today's -CURRENT at runq_choose+0x83

2002-02-20 Thread David Wolfskill

Just built & installed today's -CURRENT (CVSup around 0347 hrs. PST):

Wed Feb 20 05:48:23 PST 2002

FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0)

login: Fboot() called on cpu#0
Waiting (max 60 seconds) for system process `vnlru' to stop...stopped
lock order reversal
 1st 0xc0337420 sched lock @ /usr/src/sys/kern/kern_idle.c:105
 2nd 0xc0390840 sio @ /usr/src/sys/dev/sio/sio.c:3137
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 
fault virtual address   = 0xd6820001
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc01a78cf
stack pointer   = 0x10:0xd683ccd0
frame pointer   = 0x10:0xd683cce0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 11 (idle: cpu0)
kernel: type 12 trap, code=0
timeout stopping cpus
Stopped at  runq_choose+0x83:   movl0(%edx),%eax
db> trace
runq_choose(c035a660,d683cd0c,c02b1b3e,c01a8d87,12e) at runq_choose+0x83
choosethread(c01a8d87,12e,c0196384,d682c500,1a09) at choosethread+0xd
sw1(d682c600,d683cd34,c01961c4,0,d683cd48) at sw1+0x20
idle_proc(0,d683cd48,0,c0196384,0) at idle_proc+0x5c
fork_exit(c0196384,0,d683cd48) at fork_exit+0x9c
fork_trampoline() at fork_trampoline+0x8
db> show pcpu 0
cpuid= 0
curthread= 0xd682c600: pid 11 "idle: cpu0"
curpcb   = 0xd683cda0
fpcurthread  = none
idlethread   = 0xd682c600: pid 11 "idle: cpu0"
currentldt   = 0x28
spin locks held:
exclusive (spin mutex) sched lock (0xc0337420) locked @ 
/usr/src/sys/kern/kern_idle.c:105
db> show pcpu 1
cpuid= 1
curthread= 0xda408700: pid 90879 "reboot"
curpcb   = 0xda4b8da0
fpcurthread  = none
idlethread   = 0xd682c900: pid 10 "idle: cpu1"
currentldt   = 0x28
spin locks held:
exclusive (spin mutex) clk (0xc033ad00) locked @ /usr/src/sys/i386/isa/clock.c:415
db> show locks
exclusive (spin mutex) sched lock (0xc0337420) locked @ 
/usr/src/sys/kern/kern_idle.c:105
db> 


I have some errands to run; should be back within about 1.5 hrs., but
will be quite willing to poke & hack around to see what's up after that
time.

Cheers,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
I believe it would be irresponsible (and thus, unethical) for me to advise,
recommend, or support the use of any product that is or depends on any
Microsoft product for any purpose other than personal amusement.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Kernel compile error with today's cvsup.

2002-02-20 Thread Edwin Culp

On my daily build, my kernels are broken as per log:

===> wi
cd /usr/obj/usr/src/sys/PIII850N;  MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm 
make -
f /usr/src/sys/dev/aic7xxx/aicasm/Makefile
Warning: Object directory not changed from original /usr/obj/usr/src/sys/PIII850N
cc -O -pipe  -I/usr/include -I.-c aicasm_gram.c
cc: installation problem, cannot exec `cpp0': No such file or directory
cc: installation problem, cannot exec `cc1': No such file or directory
*** Error code 1

Thanks,

ed


---

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: mergemaster and /etc/pam.d

2002-02-20 Thread Dag-Erling Smorgrav

Doug Barton <[EMAIL PROTECTED]> writes:
> On Fri, 4 Jan 2002, John Baldwin wrote:
> > I don't think pam.d is installed right now by default.  Once it is
> > turned on by default I think mergemaster will DTRT.
>   John's right. By design, mm only knows about things installed by
> /usr/src/etc/Makefile. That makes it flexible over time and much easier to
> keep up to date.

pam.d *is* listed in etc/Makefile, and mergemaster *does* pick up
changes to it, as long as the RCS Id changed.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



RE: mergemaster and /etc/pam.d

2002-02-20 Thread Doug Barton

On Fri, 4 Jan 2002, John Baldwin wrote:

>
> On 04-Jan-02 Michael D. Harnois wrote:
> > mergemaster does not pick up changes to the /etc/pam.d directory. Is
> > this a feature?
>
> I don't think pam.d is installed right now by default.  Once it is turned on by
> default I think mergemaster will DTRT.

John's right. By design, mm only knows about things installed by
/usr/src/etc/Makefile. That makes it flexible over time and much easier to
keep up to date.

Doug
-- 
   "We have known freedom's price. We have shown freedom's power.
  And in this great conflict, ...  we will see freedom's victory."
- George W. Bush, President of the United States
  State of the Union, January 28, 2002

 Do YOU Yahoo!?



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Ethernet tunnel device

2002-02-20 Thread Mark Santcroos

On Sat, Feb 16, 2002 at 01:02:09AM -0800, Terry Lambert wrote:
> Pretty clearly, if it happens, and the process is truly
> gone, then there is a resource track cleanup that's
> missing (perhaps it's a reference that results from the
> Linux mmap resource track cleanup not releasing it?).

It was indeed a linux_compat specific resource cleanup issue.

I managed to create a simple linux program that had the same problem. From 
there on it was easy...

The problem was created by Alfred's locking commit of Jan 13.
(No hard feelings, it helped me to understand the code alot better! ;) )

Can someone please commit the attached (trivial) patch?

Mark

ps. there might be more pieces of code like this maybe.

-- 
Mark Santcroos  RIPE Network Coordination Centre
http://www.ripe.net/home/mark/  New Projects Group/TTM


--- linux_ioctl.c.orig  Wed Feb 20 12:34:46 2002
+++ linux_ioctl.c   Wed Feb 20 12:35:06 2002
@@ -2313,9 +2313,10 @@
TAILQ_FOREACH(he, &handlers, list) {
if (cmd >= he->low && cmd <= he->high) {
error = (*he->func)(td, args);
-   if (error != ENOIOCTL)
+   if (error != ENOIOCTL) {
fdrop(fp, td);
return (error);
+   }
}
}
fdrop(fp, td);



Re: Kernel Debugging over the Ethernet?

2002-02-20 Thread Maxim Sobolev

If my memory serves some time ago Jonathan Lemon was planning to add
ability to remotely debug kernel via TCP/IP. Try to contact him and
ask about the status of his work.

-Maxim

Julian Elischer wrote:
> 
> On Tue, 19 Feb 2002, George V. Neville-Neil wrote:
> 
> > Hi Folks,
> >
> >   Now that Luigi has put in polling support for some ethernet drivers
> > I was wondering how much work it would be to make the remote kernel debugging
> > run over the ethernet.  I have worked on systems like this before (it's the
> > reason
> > I did polling network device drivers in Wind River's VxWorks) but it depends
> > on a debugging system that has the ability to have its back end swapped out.
> >
> >   Who would I talk to about how kernel debugging works at the
> > lowest layers right now?  Which source files should I look at first.
> 
> the gdb debugging piggybacks onto the ddb debugger
> the file i386/i386/i386-gdbstub.c gives the basic
> interface for the serial connection.
> 
> the serial part is in /sys/dev/sio/sio.c
> 
> I don't know what gdb does on the ethernet but my guess is that it's
> already written there somewhere.
> 
> I guess using udp packets with an address set by a sysctl
> would be sufficient,
> especially if we had our own udp handler (which I'm told can be done in a
> very small amount of code it we know what packets we are getting).
> 
> >
> > Thanks,
> > George
> >
> > --
> > George V. Neville-Neil  [EMAIL PROTECTED]
> > NIC:GN82
> >
> > "Those who would trade liberty for temporary security deserve neither"
> >   - Benjamin Franklin
> >
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-hackers" in the body of the message
> >
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: more -current testers

2002-02-20 Thread Maxim Sobolev

Michael Lucas wrote:
> 
> I understand that we're getting to that stage where we need more
> -current testers.
> 
> We all agree that the optimal thing would be to have hordes of very
> sophisticated users who can debug problems on their own and submit
> patches to fix all their issues.  I would guess that we all also agree
> that that's not going to happen.
> 
> It seems that the best we can hope for is to educate some of the
> braver users who are ready to take the next step and are willing to
> donate some time to us.
> 
> I'm considering doing a series of articles on testing FreeBSD-current,
> including: setting up for kernel dumps, what to type at the debugger
> prompt after a crash, filing a decent bug report, what to expect from
> -current, and so on.  I would also make it clear when to not bother
> filing a bug report (i.e., "You crashed, but had no WITNESS?  Sorry,
> enable WITNESS & try again."). This would be (I suspect) three
> articles, running about a month and a half.
> 
> The last time I checked, I get 12-15 thousand readers for each
> article.  One half of one percent uptake would (hopefully) be quite a
> few bug reports.

Excellent idea IMO.

-Maxim

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: more -current testers

2002-02-20 Thread Tom Fischer

Hello,

These proposed articles can only help.  I've been following this
list for a few years, I'm ready to contribute in my own small
way :-)

tom

[EMAIL PROTECTED]

Michael Lucas wrote:
> I understand that we're getting to that stage where we need more
> -current testers.
> 
> We all agree that the optimal thing would be to have hordes of very
> sophisticated users who can debug problems on their own and submit
> patches to fix all their issues.  I would guess that we all also agree
> that that's not going to happen.
> 
> It seems that the best we can hope for is to educate some of the
> braver users who are ready to take the next step and are willing to
> donate some time to us.
> 
> I'm considering doing a series of articles on testing FreeBSD-current,
> including: setting up for kernel dumps, what to type at the debugger
> prompt after a crash, filing a decent bug report, what to expect from
> -current, and so on.  I would also make it clear when to not bother
> filing a bug report (i.e., "You crashed, but had no WITNESS?  Sorry,
> enable WITNESS & try again."). This would be (I suspect) three
> articles, running about a month and a half.
> 
> The last time I checked, I get 12-15 thousand readers for each
> article.  One half of one percent uptake would (hopefully) be quite a
> few bug reports.
> 
> My question to the community is: is it too early to do this?  If I
> start now, the articles would probably appear April-May.
> 
> Thanks,
> Michael
> 
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message