Re: gtags? htags?

[Makoto Matsushita]

gnn They're needed for the tags: target in the kernel makefiles and
gnn since I'd like to be able to browse code...

Feel free to check URL:http://snapshots.jp.FreeBSD.org/tour/.  Both
5-current and 4-stable code are HTMLed with GLOBAL daily.

-- -
Makoto `MAR' Matsushita

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

Re: 5-CURRENT, make buildworld break?

[John Hay]

I see that here too. Maybe des missed something during his openpam upgrade?

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

 I upgraded frem 4.5-STABLE to 5.0-CURRENT three days ago, and it worked
 fine. But since I cvsupped yesterday, a 'make buildworld' results in:
 
 ** snip snip **
 
 cc -pg -O -pipe -I/usr/src/lib/libpam/libpam
 -I/usr/src/lib/libpam/libpam/../.. /../contrib/openpam/include -DLIB_MAJ=2
 -Werror -Wall -W -Wstrict-prototypes -Wm issing-prototypes -Wpointer-arith
 -Wreturn-type -Wcast-qual -Wwrite-strings -Wsw itch -Wshadow -Wcast-align
 -Wno-uninitialized -c /usr/src/lib/libpam/libpam/pam _std_option.c -o
 pam_std_option.po
 make: don't know how to make openpam_static_modules.po.
 Stop *** Error code 2
 
 Stop in /usr/src/lib/libpam.
 *** Error code 1
 
 Stop in /usr/src/lib.
 *** Error code 1
 
 Stop in /usr/src.
 *** Error code 1
 
 ** snip snip **
 
 I've tried several times, each time with a clean /usr/obj.
 
 
 Best regards,
 Rasmus Skaarup

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

Re: 5-CURRENT, make buildworld break?

[Maxim M. Kazachek]

It dies on the depend stage, if -DNOPROFILE is used... It needs
pam_misc.h on usr.bin/su then.

   Sincerely, Maxim M. Kazachek
   mailto:[EMAIL PROTECTED]
   mailto:[EMAIL PROTECTED]




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

Re: 5-CURRENT, make buildworld break?

[Dag-Erling Smorgrav]

John Hay [EMAIL PROTECTED] writes:
 I see that here too. Maybe des missed something during his openpam upgrade?

Ah, yes - src/lib/libpam/libpam/Makefile should have NOPROFILE=YES.  I
didn't notice because I have it in my make.conf.

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

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

Re: 5-CURRENT, make buildworld break?

[Dag-Erling Smorgrav]

Ruslan Ermilov [EMAIL PROTECTED] writes:
 That's why it's always a good idea to test changes with make release,
 in a pristine environment.

Last I checked, 'make release' checks the sources out from CVS, and is
therefore useless to test changes that haven't yet been committed.

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

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

Re: 5-CURRENT, make buildworld break?

[Ruslan Ermilov]

On Wed, Mar 06, 2002 at 01:17:28PM +0100, Dag-Erling Smorgrav wrote:
 Ruslan Ermilov [EMAIL PROTECTED] writes:
  That's why it's always a good idea to test changes with make release,
  in a pristine environment.
 
 Last I checked, 'make release' checks the sources out from CVS, and is
 therefore useless to test changes that haven't yet been committed.
 
There's such a thing as LOCAL_PATCHES since at least 1996.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

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

Re: 5-CURRENT, make buildworld break?

[Ruslan Ermilov]

On Wed, Mar 06, 2002 at 01:01:19PM +0100, Dag-Erling Smorgrav wrote:
 John Hay [EMAIL PROTECTED] writes:
  I see that here too. Maybe des missed something during his openpam upgrade?
 
 Ah, yes - src/lib/libpam/libpam/Makefile should have NOPROFILE=YES.  I
 didn't notice because I have it in my make.conf.
 
That's why it's always a good idea to test changes with make release,
in a pristine environment.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

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

Re: 5-CURRENT, make buildworld break?

[Dag-Erling Smorgrav]

Ruslan Ermilov [EMAIL PROTECTED] writes:
 On Wed, Mar 06, 2002 at 01:17:28PM +0100, Dag-Erling Smorgrav wrote:
  Last I checked, 'make release' checks the sources out from CVS, and is
  therefore useless to test changes that haven't yet been committed.
 There's such a thing as LOCAL_PATCHES since at least 1996.

Great!  Now if only that was *documented* somewhere...

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

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

Re: 5-CURRENT, make buildworld break?

[Ruslan Ermilov]

On Wed, Mar 06, 2002 at 01:25:01PM +0100, Dag-Erling Smorgrav wrote:
 Ruslan Ermilov [EMAIL PROTECTED] writes:
  On Wed, Mar 06, 2002 at 01:17:28PM +0100, Dag-Erling Smorgrav wrote:
   Last I checked, 'make release' checks the sources out from CVS, and is
   therefore useless to test changes that haven't yet been committed.
  There's such a thing as LOCAL_PATCHES since at least 1996.
 
 Great!  Now if only that was *documented* somewhere...
 
We have a make release guy now, please blame him!  :-)

On Fri, Oct 26, 2001 at 08:28:25PM +0900, Makoto MATSUSHITA wrote:

 Dear Committers,

 Today I've joined the FreeBSD developers' team with lots of helps of
 Kuriyama-san (he is my mentor).  I'll work in the area of
 src/release (boot floppies, release procedures), and I'll be a member
 of make-buildworld/installworld/release-breaker busters.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

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

Re: Won't boot after the commits to timecounter code

[qhwt]

On Wed, Mar 06, 2002 at 08:49:18AM +0100, Poul-Henning Kamp wrote:
  In message 20020306054514.GA395@gzl, [EMAIL PROTECTED] writes:
  Hello.
  After upgrading to the kernel as of 2002-03-03 00:00:00(UTC), it stopped
  booting just after the message:
  
  Timecounter i8254  frequency 1193182 Hz
  
  With some debugging printf()'s inserted, I found it was tc-tc_get_timecount()
  called from tco_delta() called just after the bcopy() in tc_windup().
  So maybe the next place I have to look at is i8254_get_timecount(), which is in
  /sys/i386/isa/clock.c, but the last (effective) commit to this file is
  revision 1.180(at the end of January).
  
  I couldn't even drop into DDB; no response other than to power button.
  The last bootable(and stable so far) kernel is from 2002-02-24.
  I don't think this is caused by some leftover in the work directory
  since I always build kernels in a new empty directory under /usr/obj.
  
  Any (clue|fix)\?

 The only thing I know off right now is this thing from BDE which
 I havn't been able to verify yet:



 
 From:Bruce Evans [EMAIL PROTECTED]
 Subject: dummy_timecounter broken; breaks booting with -d
 To:  [EMAIL PROTECTED]
 Message-Id: [EMAIL PROTECTED]
 Date:Tue, 05 Mar 2002 08:09:26 +1100
 
 %%%
 Index: kern_tc.c
 ===
 RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v
 retrieving revision 1.116
 diff -u -2 -r1.116 kern_tc.c
 --- kern_tc.c 26 Feb 2002 09:16:27 -  1.116
 +++ kern_tc.c 4 Mar 2002 21:08:03 -
 @@ -192,4 +252,14 @@
   gen = tc-tc_generation;
   bintime2timeval(tc-tc_offset, tvp);
 + /*
 +  * XXX dummy_timecounter is now broken.  Its tc_get_timecount
 +  * needs to be called before it works, and that doesn't
 +  * always happen naturally.  In particular, we spin forever
 +  * here after booting with -d unless we do an unnatural call
 +  * here, since the screen timeout code is always run on entry
 +  * to ddb, and it calls here.
 +  */
 + if (gen == 0  timecounter == dummy_timecounter)
 + (void)tc-tc_get_timecount(tc);
   } while (gen == 0 || gen != tc-tc_generation);
  }
 %%%
 
 Bruce

Hmm, this doesn't seem to change the situation.

I tried reverting the following files:
  /sys/sys/timetc.h:1.46 - 1.45
  /sys/kern/kern_tc.c:  1.116 - 1.114
and managed to get into the single-user mode, but this of course doesn't solve
the problem.

I inserted a pair of printf() inside mtx_lock_spin/mtx_unlock_spin in
i8254_get_timecount() and it kept printing the message while tc_init()
was blocked, so I think it's blocked at mtx_lock_spin in i8254_get_timecount()
when called from tc_init(), but not when called from somewhere else.
(maybe an interrupt handler?)

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

Re: Won't boot after the commits to timecounter code

[Bruce Evans]

On Wed, 6 Mar 2002, Poul-Henning Kamp wrote:

 The only thing I know off right now is this thing from BDE which
 I havn't been able to verify yet:

I got the hang for all boots, but it was a local problem.  I had added
a nanouptime() call the tc_windup(), and this spins forever when
tc_windup() is called from tc_init() or switch_timecounter() (because
timecounter-generation is 0).  At least one of these calls is made
unconditionally at boot time, but there is normally no problem, at
least if WITNESS and KTR are not enabled (my default) because the
functions that spin on the generation update are not called.  But
interrupt activity might result in them being called, and WITNESS
and/or KTR call them if a lock is witnessed.

The following patch is the result of attempting to debug this.  I first
had to debug the debugger, since it has the same problem.

 
 From:Bruce Evans [EMAIL PROTECTED]
 Subject: dummy_timecounter broken; breaks booting with -d
 To:  [EMAIL PROTECTED]
 Message-Id: [EMAIL PROTECTED]
 Date:Tue, 05 Mar 2002 08:09:26 +1100

 %%%
 Index: kern_tc.c
 ===
 RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v
 retrieving revision 1.116
 diff -u -2 -r1.116 kern_tc.c
 --- kern_tc.c 26 Feb 2002 09:16:27 -  1.116
 +++ kern_tc.c 4 Mar 2002 21:08:03 -
 @@ -192,4 +252,14 @@
   gen = tc-tc_generation;
   bintime2timeval(tc-tc_offset, tvp);
 + /*
 +  * XXX dummy_timecounter is now broken.  Its tc_get_timecount
 +  * needs to be called before it works, and that doesn't
 +  * always happen naturally.  In particular, we spin forever
 +  * here after booting with -d unless we do an unnatural call
 +  * here, since the screen timeout code is always run on entry
 +  * to ddb, and it calls here.
 +  */
 + if (gen == 0  timecounter == dummy_timecounter)
 + (void)tc-tc_get_timecount(tc);
   } while (gen == 0 || gen != tc-tc_generation);
  }
 %%%

 Bruce


 In message 20020306054514.GA395@gzl, [EMAIL PROTECTED] writes:
 Hello.
 After upgrading to the kernel as of 2002-03-03 00:00:00(UTC), it stopped
 booting just after the message:
 
 Timecounter i8254  frequency 1193182 Hz
 
 With some debugging printf()'s inserted, I found it was tc-tc_get_timecount()
 called from tco_delta() called just after the bcopy() in tc_windup().
 So maybe the next place I have to look at is i8254_get_timecount(), which is in
 /sys/i386/isa/clock.c, but the last (effective) commit to this file is
 revision 1.180(at the end of January).
 
 I couldn't even drop into DDB; no response other than to power button.
 The last bootable(and stable so far) kernel is from 2002-02-24.
 I don't think this is caused by some leftover in the work directory
 since I always build kernels in a new empty directory under /usr/obj.
 
 Any (clue|fix)\?
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 

 --
 Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
 [EMAIL PROTECTED] | TCP/IP since RFC 956
 FreeBSD committer   | BSD since 4.3-tahoe
 Never attribute to malice what can adequately be explained by incompetence.

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

Bruce


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

Re: Won't boot after the commits to timecounter code

[Bruce Evans]

On Wed, 6 Mar 2002 [EMAIL PROTECTED] wrote:

 I inserted a pair of printf() inside mtx_lock_spin/mtx_unlock_spin in
 i8254_get_timecount() and it kept printing the message while tc_init()
 was blocked, so I think it's blocked at mtx_lock_spin in i8254_get_timecount()
 when called from tc_init(), but not when called from somewhere else.
 (maybe an interrupt handler?)

Apparently you have KTR enabled (not the default in GENERIC).  I think
WITNESS+KTR already caused nasty recursion from the mtx_lock_spin, and
we now get an endless loop when nanotime() is called with an invalid
timecounter in the following call chain:

tc_init - tc_windup - tco_delta - i8254_get_timecount - mtx_foo -
witness_foo - ktr_foo - nanotime,

just after nanotime has somehow recursed back into i8254_get_timecounter
without causing endless recursion!

Try setting MTX_NOWITNESS in the initialization of clock_lock in
i386/machdep.c.

Bruce


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

smbfs in -current?

[Seth Hettich]

The NOTES has no real info, and I don't see a man page... how
is this supposed to work?

I'm getting lots of:
smbfs_smb.o: In function `smbfs_smb_lockandx':
/usr/src/sys/i386/compile/SJH/../../../fs/smbfs/smbfs_smb.c(.text+0x90):
undefin
ed reference to `mb_put_uint8'


I have both:
options SMBFS
options NETSMB


in my config.

Perhaps someone could give a little explanation, and add it to NOTES?

-Seth

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

SIGHUP during local package initialization

[Galen Sampson]

Hello all,

I have recently experienced some interesting behavior.  During the boot process
multiple programs seem to be receiving a SIGHUP.  I have the stable version of
samba installed from ports, and this causes nmbd to core dump during the
machine startup.  I have talked with the samba people about this and donated
the core file to them.  They did feel that it was strange that nmbd would be
getting a signal during startup though.

This problem was hard to track down.  It seems that it programs only receive
this SIGHUP sometimes.  My only thought to the intermitant occurance is that
something is SIGHUPing all of the processes, but sometimes local initialization
starts before this happens.  My /var/log/messages showed that samba and cyrus
(my only programs started during init that were not part of the base system)
both caught this signal.

This should be a trivial task for me to track down.  Unfortunately I'm having
problems.  My main method of searching was performing grep for kill in the
/etc directory.  This did not yield anything promising.  I was wondering if
someone could give me hints about tracking this problem down.

regards,
Galen

__
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

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

Re: gtags? htags?

[Julian Elischer]

It might be an idea if the kernel were kept separate because
I find that the cross-reference is good but having kernel and userspace
mixed up is a bit confusing..


On Wed, 6 Mar 2002, Makoto Matsushita wrote:

 
 gnn They're needed for the tags: target in the kernel makefiles and
 gnn since I'd like to be able to browse code...
 
 Feel free to check URL:http://snapshots.jp.FreeBSD.org/tour/.  Both
 5-current and 4-stable code are HTMLed with GLOBAL daily.
 
 -- -
 Makoto `MAR' Matsushita
 
 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

buildworld problems, undefined reference to '__ntohl' and '__htonl'

[Matthew Dillon]

This has been broken for several days now, maybe longer.  It would be
nice if whoever broke it would fix it.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]

cc -nostdlib -static -Ttext 0x0 -o loader.sym 
/usr/obj/FreeBSD/FreeBSD-current/src/sys/boot/i386/loader/../btx/lib/crt0.o main.o 
conf.o bcache.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o 
interp_parse.o load_aout.o load_elf.o ls.o misc.o module.o panic.o isapnp.o pnp.o 
interp_forth.o vers.o  
/usr/obj/FreeBSD/FreeBSD-current/src/sys/boot/i386/loader/../../ficl/libficl.a 
/usr/obj/FreeBSD/FreeBSD-current/src/sys/boot/i386/loader/../libi386/libi386.a 
/usr/obj/FreeBSD/FreeBSD-current/src/sys/boot/i386/loader/../../../../lib/libstand/libstand.a
load_aout.o: In function `aout_loadfile':
load_aout.o(.text+0x7c): undefined reference to `__ntohl'
load_aout.o(.text+0x8d): undefined reference to `__ntohl'
load_aout.o(.text+0x9e): undefined reference to `__ntohl'
load_aout.o(.text+0xaf): undefined reference to `__ntohl'
load_aout.o(.text+0xcf): undefined reference to `__ntohl'
load_aout.o(.text+0xe0): more undefined references to `__ntohl' follow
/usr/obj/FreeBSD/FreeBSD-current/src/sys/boot/i386/loader/../libi386/libi386.a(pxe.o): 
In function `pxe_enable':
pxe.o(.text+0x4e1): undefined reference to `__htonl'
pxe.o(.text+0x4f5): undefined reference to `__htonl'
pxe.o(.text+0x50c): undefined reference to `__htonl'
pxe.o(.text+0x523): undefined reference to `__htonl'
/usr/obj/FreeBSD/FreeBSD-current/src/sys/boot/i386/loader/../../../../lib/libstand/libstand.a(nfs.o):
 In function `nfs_getrootfh':
nfs.o(.text+0x4f): undefined reference to `__htonl'
nfs.o(.text+0xd5): undefined reference to `__ntohl'


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

Re: buildworld problems, undefined reference to '__ntohl' and'__htonl'

[Garance A Drosihn]

At 1:15 PM -0800 3/6/02, Matthew Dillon wrote:
 This has been broken for several days now, maybe longer.  It
 would be nice if whoever broke it would fix it.

Is this in a 'make buildworld' step?  I just did one buildworld
on i386, and it completed fine (src is cvsup'ed as of about noon).
I'm doing a second buildworld right now (after having applied a
patch I am trying to test), but I haven't gotten to the buildkernel
or installkernel steps.

So, if it's the buildworld step, then I can say that it's working
fine for me at the moment.  (with my kernel options, make options,
etc..)

-- 
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]

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

Re: Patch for critical_enter()/critical_exit() interrupt assem

[John Baldwin]

On 05-Mar-02 Matthew Dillon wrote:
 
: It makes no sense whatsoever to me to be told not to commit something
: due to stale code that may not be quite compatible sitting in P4 that
: you can't make work in any reasonable time frame.  You should stop
: trying to screw over my work and instead look to your own.   You have
: so many balls in the air constructed in a fine mesh that you can't seem
: to accept a single change to your perfectly meshing subsystems, half
: of which are going stale in P4.  This is greatly restricting your
: ability to consider deviation.
:
:*sigh*  The only reason I'm not spending my cycles tracking down the
:preemption
:bugs so that preemption can go in is that I have decided that at the moment
:there is more gain to be found by doing actual locking work.  This means that
:preemption will eventually go in, just Not Right Now.  To that extent, I
:don't
:think premature optimizations based on observations of a kernel locked
:entirely
:by Giant that alter the API's preemption will change (and that were
:originally
:introduced when I committed all the bits of the preemption code that I could
:w/o breaking the kernel) should go in.
 
 Those are your cycles, not mine.  Why should I be forced to sit on my
 heals
 for an unknown period of time (but so far 3 weeks waiting for the ucred 
 changes and 2 weeks waiting for critical_*()), twiddling my thumbs
 wasting
 MY cycles just because of your own scheduling issues?
 
 That's really the crux of this whole situation.  I don't think it is 
 appropriate for you to impose your development methodology on me or
 anyone else, and I most especially do not think it is appropriate for
 you to arbitrarily hold off the hard work that I have done in order
 to fit it into your schedule.  
 
 I have said very clearly what I intend these critical_*() patches to
 do.  I have said, repeatedly, that I do not believe they would 
 intefere with your work in any significant manner.  You have yet to
 explain in any detail why you think they would.  I have said,
 repeatedly, that I am perfectly willing to work with you later on
 when you ARE ready to move forward on your own work.
 
 That's the crux of the situation, John.   I do not believe you have
 the right to hold this work off, at least not based on any of the
 explanations you have given so far.

Have you read the paper I posted to arch?  It quite clearly (I thought)
explained the role of the critical_* and the cpu_critical_* in the preemption
code.  It should be rather obvious from that why I don't want the critical_*
stuff to change from their current model.  I also think that just as it is too
early to optimize to light weight ithread switches (sparc64 is going to
optimize all kthread switches, not just ithreads by using a more general
approach, and we may do that on other arch's as well) it is too early to
optimize and add complexity for certain API's when we aren't sure what effect
they will really have on the final product.  For example, right now Giant
blocks almost all of the kernel so we are going to contest it on almost every
case.  Contesting involves grabbing the sched_lock which can result in
executing the critical section implementation more than we will end up doing
later.  I would rather wait on optimizations until the system is farther along
and we can judge what things really need optimization and which ones don't. 
Optimizations are usually a tradeoff as far as increased complexity vs.
performance and I personally at least would like to keep things simple for the
time being.  However, I would not be opposed to the code if it fit into the
design in the document I posted to arch.

A couple of notes though based on a quick preliminary glance at the code:

- The swi code has been changed to not be limited to a bitfield so that it can
  support an arbtirary number of swi's.  Right now we still support a small
  number but we may end up with several netisr's for example.  We also may move
  away from scheduling netisr's via swi_sched anyways and using a semaphore or
  some such instead.  Presently your patch goes back to assuming a fixed number
  of SWI's.
- More of a minor niglet that is easy to be fixed: you added MD fields to the MI
  pcpu bits of struct pcpu.  MD fields belong in the PCPU_MD_FIELDS macro in
  sys/i386/include/pcpu.h.  If you intend for the fields to be MI, then that is
  more of a problem as it assumes too much about interrupts for different
  platforms.  Alpha interrupts will not easily fit into a simple bitmask for
  example.

-- 

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 for critical_enter()/critical_exit() interrupt assem

[Matthew Dillon]

:Have you read the paper I posted to arch?  It quite clearly (I thought)
:explained the role of the critical_* and the cpu_critical_* in the preemption
:code.  It should be rather obvious from that why I don't want the critical_*

I'm sorry John, I have no idea what you are refering to here.  You have
given no reference that I can lookup... you have hundreds of postings 
on arch.  

Why don't you just post the reasoning?  Nothing I have seen anywhere
so far would create an issue.  I've heard you repeatedly reference
documents but I have no idea which documents you are talking about
or which portion of said documents you are refering to.  So instead
of continuing to post ghost references why don't you just lay the
problem out as you see it in this thread and explain why you do not
believe the critical section work I am doing would work with it.

:stuff to change from their current model.  I also think that just as it is too
:early to optimize to light weight ithread switches (sparc64 is going to
:optimize all kthread switches, not just ithreads by using a more general

We have very different development models, and different priorities.
I'm not sure why you are attempting to impose your development model
and priorities on me.  This is the work I want to do.  It's my time
here, not yours, and if you believe that the work will make your job
harder in some future unspecified commit then you have only to bring
up the issue down the road when you are actually ready to work on
that future unspecified commit and we can work it out.  But I don't
think it's appropriate for you to impose such a strict set of requirements
based on work that does not exist in -current anywhere as far as I can
tell.

:approach, and we may do that on other arch's as well) it is too early to
:optimize and add complexity for certain API's when we aren't sure what effect
:they will really have on the final product.  For example, right now Giant
:blocks almost all of the kernel so we are going to contest it on almost every
:case.  Contesting involves grabbing the sched_lock which can result in
:executing the critical section implementation more than we will end up doing
:later.  I would rather wait on optimizations until the system is farther along
:and we can judge what things really need optimization and which ones don't. 

Again, different development models.  I see a set of APIs being severely
misused by commits, the most recent being Peter's-that-he-backed-out,
and I see a considerable need down the road for an efficient critical
section API.  You may not be interested in doing the work on these now
but you != me.  This work is my interest.  Again, I don't understand why
you are trying to impose your personal tastes on me.

:A couple of notes though based on a quick preliminary glance at the code:
:
:- The swi code has been changed to not be limited to a bitfield so that it can
:  support an arbtirary number of swi's.  Right now we still support a small
:  number but we may end up with several netisr's for example.  We also may move
:  away from scheduling netisr's via swi_sched anyways and using a semaphore or
:  some such instead.  Presently your patch goes back to assuming a fixed number
:  of SWI's.

I see an swi scheduler, which has nothing to do with the critical section
work I have done.  If there is other SWI stuff I don't see it in the
-current tree.  Nor does the work I have done in any way prevent the
use of or in any way make it more difficult to use a list-based SWI
queueing system instead of a bitmap. 

The bitmap stuff in my critical section patch only applies to i386... it's
a specific implementation for soft and statclock IPI forwarding for
the deferred case, nothing more.  I didn't even bother to integrate AST
(saving that for later work).  It does not in any way prevent one
from redoing that bit of code or even simply keeping the code and adding
an SWI queue feature - something that could in fact be done either MD or
MI depending on the needs of the architectures.

If you believe there to be a problem here, perhaps explaining the SWI
mechanism you are refering to would help.  I am confident that it would
not impose anything incompatible with the work I've done.

:- More of a minor niglet that is easy to be fixed: you added MD fields to the MI
:  pcpu bits of struct pcpu.  MD fields belong in the PCPU_MD_FIELDS macro in
:  sys/i386/include/pcpu.h.  If you intend for the fields to be MI, then that is
:  more of a problem as it assumes too much about interrupts for different
:  platforms.  Alpha interrupts will not easily fit into a simple bitmask for
:  example.
:
:-- 
:
:John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/

These fields do in fact belong in MD PCPU_MD_FIELDS.  I didn't notice
it, perhaps because there is not a single 

Re: buildworld problems, undefined reference to '__ntohl' and'__htonl'

[Matthew Dillon]

I think it may just be my-bad.  The kernel source got out of sync
with the main tree.  I just cvs updated the whole smelly pot and
buildworld works just fine.

Sorry for the false alarm!

-Matt

:
:At 1:15 PM -0800 3/6/02, Matthew Dillon wrote:
: This has been broken for several days now, maybe longer.  It
: would be nice if whoever broke it would fix it.
:
:Is this in a 'make buildworld' step?  I just did one buildworld
:on i386, and it completed fine (src is cvsup'ed as of about noon).
:I'm doing a second buildworld right now (after having applied a
:patch I am trying to test), but I haven't gotten to the buildkernel
:or installkernel steps.
:
:So, if it's the buildworld step, then I can say that it's working
:fine for me at the moment.  (with my kernel options, make options,
:etc..)
:
:-- 
:Garance Alistair Drosehn=   [EMAIL PROTECTED]

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

Re: Should 4.5-STABLE - 5.0-CURRENT work?

[Alex Popa]

On Wed, Mar 06, 2002 at 12:36:28AM -0800, David O'Brien wrote:
 On Wed, Mar 06, 2002 at 10:00:19AM +0200, Alex Popa wrote:
  cc -O -pipe -march=pentiumpro -funsigned-char -I. 
-I/usr/src/usr.bin/awk/../../contrib/one-true-awk
/usr/src/usr.bin/awk/../../contrib/one-true-awk/maketab.c -o maketab
  ./maketab  proctab.c
  /usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found
  *** Error code 1
  
  Stop in /usr/src/usr.bin/awk.
  *** Error code 1
 
 (*sigh*)  Fixed.

Thank you, that worked for me!

There were some problems during installworld, with sh getting killed
during installworld, in chpass on:
[ ! -e /usr/bin/chpass ] ||  chflags noschg /usr/bin/chpass || true

sh was getting killed w/ signal 10 or 11, I cannot remember.  However, I
just removed the setuid binaries in /usr/bin and /usr/sbin, then
everything worked.  Also got some problems with sh at kernel make,
just before the linking part.  Solved by replacing /bin/sh with
/usr/local/bin/bash during kernel build and install.  This was with the
old kernel I mentioned in my first message, so world and kernel were out
of sync.

All seems to work OK w/ the -release kernel and world (until now, at
least, built two other kernels, and used X w/ no apparent problems).

Thank you, everybody!  You are doing a great job!

Alex
(now a happy 5.0-CURRENT user)

+--
Alex Popa,  |  Artificial Intelligence is
[EMAIL PROTECTED]| no match for Natural Stupidity
+--
It took the computing power of three C-64s to fly to the Moon.
It takes a 486 to run Windows 95. Something is wrong here.

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

binutils

[Michael McGoldrick]

Hi, I recently rebuilt Mozilla and kdebase on my (very up to date) current box. Since 
then, both moz and most KDE apps have been very crashy. I think this is probably 
something to do with binutils, but is there any way I can check? and are there any 
workarounds?

Additional info: x86 machine, world/kernel last built from sources cvsupped on 6 March 
16:34:35 GMT

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

Contemplating THIS change to signals.

[Julian Elischer]

Maybe this should be in -arch.. I couldn;t make my mind up,
but..


There is some behaviour in signals which seems
1/ un-neccesary
2/ potentially dangerous.
in addition it is 
3/ Definitly incompatible with KSEs.

I am hoping that someone can give me a good reason why it is done, and
failing that, I'm hoping people can give comments on my thoughts.

The behavious in question was inherrited from   BSD4.4-LITE2

When the sleep code (tsleep,msleep, cv{stuff})
checks to see if there is a pending signal that might cause the sleep
to abort, it calls CURSIG() which calls issignal,
which in turn might decide to actually suspend the process.
(if the user hit ^Z for example)

This is fine when CURSIG is called from userret(), because we are on the
user boundary, however calling it from the sleep()
call seems a rather UN-NICE thing to do.

One could argue that it is safe because you are not allowed to sleep
while holding resources (um is it not possible to sleep
while holding a vnode?) but it seems that it is possible to hit ^Z
at teh right moment while something is holding some resource
(during what it expects to be a very short term sleep,) and end up
blocking the whole system.

I would argue that a process can be considered to be suspended even while
it is running in kernel space. My definition of a suspended process 
would be one that id not running any user code. it is not making any
headway on the userland program. This I put it to the group that 
it is sufficient to only suspend a process when it is crossing the user
boundary. (returning to user space)

My suggestion is to remove teh code in issignal() that perfoms the
blocking actions and create a separate function that does that action.
I would then call that function from userret() immediatly after the call
to issignal(). The result would be that
suspended processes would still not reach userland, but processes would
not have to option of suspending indefinitly at sleep().

The signal would still cut short the sleep, but the process would be 
allowed to proceed to the user boundary, at which point it would
be suspended as before.

If anyone has any reasons they think this is a bad idea, then please speak
up. Neithe Matt (Dillon) nor I can see that stopping in msleep
is required, and both of us are in fact un-easy with it.

In a THREADED world it gets even more complicated, because
the SUSPENDED state is a PER_PROCESS state, which means that
you are not suspented until ALL THERADS have left userland
and been counted as 'suspended'.
Having some threads stopped 'near' msleep and others stopped at the
userland boundary  is asking for trouble in my opinion.

I can not think of any downside to making the suspension 
(whether from ptrace, or a signal) only occur at the user boundary.

If I hear NO arguments I'll take it that no-one can think of any reasons
to not change the code. If yuo have a reason PLEASE speak up so that we
can discuss it and try figure out whether it is real or can be
gotten around in some manner.


Julian

 





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

Re: Patch for critical_enter()/critical_exit() interrupt assem

[Julian Elischer]

On Wed, 6 Mar 2002, Jeroen C.van Gelderen wrote:
 
 Search for paper John Baldwin and find link 6:


A good start though incomplete. Unfortunate that it took such a fight to
get it to be written. Hopefully it's existance can prevent soem further
bloodshed. Is it possible for other people to add to this or is it a 
closed document?




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

Re: Won't boot after the commits to timecounter code

[qhwt]

On Thu, Mar 07, 2002 at 04:34:00AM +1100, Bruce Evans wrote:
 On Wed, 6 Mar 2002 [EMAIL PROTECTED] wrote:

  I inserted a pair of printf() inside mtx_lock_spin/mtx_unlock_spin in
  i8254_get_timecount() and it kept printing the message while tc_init()
  was blocked, so I think it's blocked at mtx_lock_spin in i8254_get_timecount()
  when called from tc_init(), but not when called from somewhere else.
  (maybe an interrupt handler?)

 Apparently you have KTR enabled (not the default in GENERIC).  I think
 WITNESS+KTR already caused nasty recursion from the mtx_lock_spin, and
 we now get an endless loop when nanotime() is called with an invalid
 timecounter in the following call chain:

 tc_init - tc_windup - tco_delta - i8254_get_timecount - mtx_foo -
 witness_foo - ktr_foo - nanotime,

 just after nanotime has somehow recursed back into i8254_get_timecounter
 without causing endless recursion!

Yes, I have the following KTR options enabled (I think I brought this from
NOTES about a year before):
  options   KTR
  options   KTR_EXTEND
  options   KTR_ENTRIES=1024
  options   KTR_COMPILE=0x3f
  options   KTR_MASK=0x201208
  options   KTR_CPUMASK=0x3

but WITNESS is commented out.

 Try setting MTX_NOWITNESS in the initialization of clock_lock in
 i386/machdep.c.

O.k., I'll try this(but does it affect a kernel without WITNESS?), then
try a kernel without KTR options.

Thanks.

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

Re: gtags? htags?

[Makoto Matsushita]

julian It might be an idea if the kernel were kept separate because
julian I find that the cross-reference is good but having kernel and userspace
julian mixed up is a bit confusing..

Hmm, maybe it's a good idea about userland/kernel separation.  I'll
try it later (maybe this evening or this weekend).

-- -
Makoto `MAR' Matsushita

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

Re: Patch for critical_enter()/critical_exit() interrupt assem

[Matthew Dillon]

:Search for paper John Baldwin and find link 6:
:  
:http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=199282+204026+/usr/local/www/db/
:text/2002/freebsd-arch/20020303.freebsd-arch
:
:The actual paper is at:
:  http://www.FreeBSD.org/~jhb/smpng/design/article.{ps,pdf}
:
:-J
:--
:Jeroen C. van Gelderen - [EMAIL PROTECTED]

Ok... I've read it.  The sections on interrupts and critical sections
are fully compatible with my patch.  The one section... basically
the last sentence of the last paragraph, is exactly the piece that
my patch cleans up and makes more flexible.  Instead of requiring that
cpu_critical_*() always be used for the initial critical_enter() my
patch makes it optional, and for I386 I use that flexibility to allow
critical_*() to NOT have to call cpu_critical_*().

-Matt
Matthew Dillon 
[EMAIL PROTECTED]

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

Re: Patch for critical_enter()/critical_exit() interrupt assem

[Justin T. Gibbs]

:stuff to change from their current model.  I also think that just as it
:is too early to optimize to light weight ithread switches (sparc64 is
:going to optimize all kthread switches, not just ithreads by using a more
:general

We have very different development models, and different priorities.

[...]

This same issue came up at the BSDCon developers conference in
regard to ithreads.  Is it better to optimize some bit of code
because it is the fun and interesting thing to do, or to build a simple,
yet stable and easily verified foundation, that we can later optimize
in a controlled manner?  This is not about whether these particular
changes are correct.  The concern is that they may contain a subtle
bug that makes it difficult to verify other portions of the system.
I don't think anyone believes that we are at a point in current
where we can convince ourselves that the system does work, no matter how
slowly, in all cases.  If we start to optimize before we reach such
a point, how will we ever determine the robustness of the system?
An optimization put in place today may have a bug or may expose a
bug somewhere else in the system.  In the current situation it is
difficult to know which scenario is true (bug or side-effect) because
we don't have a solid, verified, foundation.

My 2 cents?  Work with John to get the APIs that affect this particular
code stable.  That means discussion and perhaps that discussion will
take some time (if this blow-up hadn't occurred the discussion
would already be over now ;-).  Once the APIs are in place, commit your
code in a format that makes it completely optional, just like your Giant
lock optimizations.  This means that those interested in validating
and determining the impact of your code can easily do so by flipping
a switch.  Those who would rather debug their own subsystem problems
in a slower, but simpler, environment can do so too.

--
Justin

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

$B9-9p!*!*A49q?69~M;;q<B;\Cf!*(B$B!*(B

[sales]

$B9-9p!*(B

$BFMA3$9$_$^$;$s!#(B
$B5^$J=PHq$G$*:$$j$NJ}$*NO$K$J$j$^$9!#(B

$B%i%$%/%U%!%$%J%s%9!!ET!J(B1$B!K(B22433
$B#2#4;~4V$5$l$J$$J}$O(B
$B$3$A$i$^$G$*4j$$CW$7$^$9!#(B

$BO"Mm@h(B
[EMAIL PROTECTED]

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

Re: Patch for critical_enter()/critical_exit() interrupt assem

[Matthew Dillon]

:This same issue came up at the BSDCon developers conference in
:regard to ithreads.  Is it better to optimize some bit of code
:because it is the fun and interesting thing to do, or to build a simple,
:yet stable and easily verified foundation, that we can later optimize
:in a controlled manner?  This is not about whether these particular
:changes are correct.  The concern is that they may contain a subtle
:bug that makes it difficult to verify other portions of the system.
:...
:--
:Justin

   Well now hold on a second here Justin.  Did you even look at the
   patch?  Or are you just making a generalization that is totally
   unrelated to the patch?  Perhaps you are unaware of the sysctl 
   instrumentation that allows the interrupts-enabled-during-critical-section
   mechanism to be turned on and off on a whim?  Perhaps you are unaware 
   that this patch is not JUST an optmization.  Far from it, it solves a
   number of what I consider to be critical issues.  For example, it 
   solves the IPI deadlock problem, and it allows us to cleanup some
   fairly aweful hacks in the code, e.g. in fork_exit().

   I'm all for a discussion, but I would prefer it if the discussion were
   based on the actual work that I am trying to get committed and not
   some incorrect generalization that is being used to justify some other
   approach.

   None of this is secret.  I've stated these facts very clearly a half 
   dozen times now AND in the commit message.  Don't ignore it or assume
   that I am some beginner who's just throwing random commits in and
   destabilizing the tree.  I have gone to great lengths to do the precise
   opposite of that.

-Matt


Matthew Dillon 
[EMAIL PROTECTED]

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

Re: Patch for critical_enter()/critical_exit() interrupt assem

[Matthew Dillon]

:My 2 cents?  Work with John to get the APIs that affect this particular
:code stable.  That means discussion and perhaps that discussion will
:take some time (if this blow-up hadn't occurred the discussion
:would already be over now ;-).  Once the APIs are in place, commit your
:code in a format that makes it completely optional, just like your Giant
:lock optimizations.  This means that those interested in validating
:and determining the impact of your code can easily do so by flipping
:a switch.  Those who would rather debug their own subsystem problems
:in a slower, but simpler, environment can do so too.
:
:--
:Justin

The API is intended for the stage-2 commit.  The stage-1 commit
is intended to do all the 'hard stuff' in as straightforward
a manner as possible.  The sysctl / option you talk about here
existed in my patch set 2 and a half weeks ago.

I really wish you people would at least read the patch and commit
message before you comment on it.

-Matt


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