Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Maxim M. Kazachek
On Mon, 24 Nov 2003, Andrew Gallatin wrote:


Daniel O'Connor writes:
 
  It is _trivial_ to buildworld with a static root.

Then its equally trivial to build with a dynamic root.  Please do so,
and don't wreck the performance of the OS I've used since 1994.
Then just use OS from 1994 and don't bother about NEW features
that may appear in dumb, slow, dynamically linked OS. Just put your head
in the sand and say I'm pretty happy with old statically linked OS and I
never need new features in it... World is going forward, and the payment
of new features is awesome performance of OLD, not so good profiled (due
statical linking) dynamic linking functions. if it isn't broken - don't
fix it. But if you don't use dynamic linking - it's DEFINITELY NOT
broken. And will never be fixed.


   Sincerely, Maxim M. Kazachek
   mailto:[EMAIL PROTECTED]
   mailto:[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Miguel Mendez
./Scott Long wrote:

Please, read : http://www.netmeister.org/news/learn2quote.html

 Also, I'm really starting to resent you using the FreeBSD mailing
 lists as an advocacy channel for DragonFly.  I fail to see how FreeBSD
 4.x and DFBSD relate to FreeBSD 5-current, which is the overall topic
 of this mailing list at the moment.

This comment is so ridiculous I can't resist. He has explained a very
clever and nice solution for the problem, rather than bitching about it
which is what the 95% of the thread is about. By bashing him, not only
you're doing a great job for inter-camp relations, you're making the
absurd assumption that such a solution (once/if it appears in DragonFly)
cannot/will not be easily ported to FreeBSD.

Cheers,
-- 
Miguel Mendez [EMAIL PROTECTED]
http://www.energyhq.es.eu.org
PGP Key: 0xDC8514F1

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Tools v. Policy: Dynamic linking

2003-11-25 Thread shaun

First, this can be moved right to -chat or /dev/null. Whatever trips your
trigger. The first post is just to -current, because that's where all the
commotion is.  I think everyone can concede that the discussion has
basically begun to bore most.  I think, however, that a fundamental point
has been lost in the noise here: The current decision to make dynamic 
linking the default is a policy issue, and not one of providing additional
functionality.

I don't think anyone is disatisfied that someone finally did the work to 
make support for NSS and PAM et al. work for those who need it. It was a
difficult and long-awaited set of functions.  A good deal of thanks should
go to Gordon and Jacques and all the others who hacked and tested to make
it work. Even if there might have been a technical middle road that would 
have more easily pleased everyone, those who do the work have the 
final say as to the implementation.

The real problem, that seems to have gotten lost here, is why does this 
set of new functions need to be the system default?  I can only imagine
that the true reason is one of maintenance.  Hooking dynamic linking into 
the system forces the project to make sure it always builds and works.
This, imho, should be more the responsibility of the small set of
individuals (and I do think the number of users who need this type of
functionality is relatively small when viewing the big picture) who need 
dynamic linking in their systems.  One could even dedicate a build cycle
within the build cluster to make sure that the dynamically built worlds 
continue to build with on-going changes.

The pros and cons have been discussed ad nauseum. I don't think one side 
will be able to convince the other that their approach is better or worse
in the long run and that eventually, people are just going to get even more
irrational in their arguements. I mean, comparing compiler upgrades (which
are externally developed and support new architectures) to dynamic linking
seems to be tangental at best. Running fork bombs vs. port builds to make
a point is just selective analysis. Labelling one side as dynamic,
progressive, innovative and the other crusty conservative old-timers is
just adding noise. Those advocating progress need to realize that moving
forward doesn't always mean you're moving in the right direction. Making
FreeBSD more like Solaris or Linux is only valid up to a certain point.
We all like this new functionality. We just don't want it in our
backyard... (further bantering suppressed)

Fast or slow, NSS support or not, does it really need to be default? Can't
the project make a commitment to this set of functions without making it
the system default? No one objects to making this set of functions
possible. It seems a good deal object to making it the default.

-- 
Yours truly,

shaun at shamz.net


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


memory allocation issue loading a kernel module

2003-11-25 Thread Sean McNeil
Hi everyone,

I was wondering if there is a way to flush out pages in memory that
might not be required.  I have a device driver that allocates 16 distict
buffers each 32K in size.  This is done with a bus_dma call as they will
be accessed by a PCI device.  The problem is that if I do a compile on
my system prior to trying to kldload the module, there isn't enough
physical memory for the driver.  I am assuming it is the disk cache that
is eating up that memory and I want to flush out enough pages for my
bus_dma allocation to work.

Is this possible?  Any and all comments are appreciated.

Thanks in advance,
Sean


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: How to fix this in 5.1-REL??

2003-11-25 Thread Sheldon Hearn
On (2003/11/24 15:39), Kevin Oberman wrote:

I end up with the following when I run `make world` on  5.1-RELEASE-p10.
  
  Did you read UPDATING?
 
 I fear a bikeshed, but I really think it may be past time to remove
 the 'world' target from /usr/src/Makefile.inc1. It is rarely useful
 and only should be used by those who understand the process and know
 that it is safe. Removing it would remove a clear way to shoot one's
 foot and would really have trivial impact on those who use it
 properly.

I agree.  The job requires quite a lot of documentation work, though.

If you can get buy-in from the doc project folks, I doubt you'd meet
with serious objections from src people.

Ciao,
Sheldon.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Peter Jeremy
On Mon, Nov 24, 2003 at 11:16:07PM -0700, M. Warner Losh wrote:
H, It looks like the hit is less than 10% in the fork intensive
test I just wrote:

#!/bin/sh
for i in 0 1 2 3 4 5 6 7 8 9; do
for j in 0 1 2 3 4 5 6 7 8 9; do
for k in 0 1 2 3 4 5 6 7 8 9; do
 for l in 0 1 2 3 4 5 6 7 8 9; do
 for m in 0 1 2 3 4 5 6 7 8 9; do
  for n in 0 1 2 3 4 5 6 7 8 9; do
true;
done; done; done; done; done; done;

Unless you've done something wierd to your /bin/sh, true is a
builtin.  This test just to measures the ongoing runtime overhead
of a dynamic executable (ie PIC code).  Drew's test was measuring
the startup overhead.

Clearly dynamic is slower, but it is more like 11% slower (10.67%) on
the average than 40% slower.  I think this would be a more typical
usage pattern.

You have measured different things.  Drew's test shows that a dynamic
/bin/sh tahes about 40% longer to start.  Your test shows that once
started, it runs about 11% slower.  And the 11% slower is _very_
worrying since it is probably more widely applicable than just /bin/sh.

Peter
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: memory allocation issue loading a kernel module

2003-11-25 Thread Maxime Henrion
Sean McNeil wrote:
 Hi everyone,
 
 I was wondering if there is a way to flush out pages in memory that
 might not be required.  I have a device driver that allocates 16 distict
 buffers each 32K in size.  This is done with a bus_dma call as they will
 be accessed by a PCI device.  The problem is that if I do a compile on
 my system prior to trying to kldload the module, there isn't enough
 physical memory for the driver.  I am assuming it is the disk cache that
 is eating up that memory and I want to flush out enough pages for my
 bus_dma allocation to work.
 
 Is this possible?  Any and all comments are appreciated.

The problem has probably nothing to do with the disk cache eating up
memory but I believe what you're seeing is physical address space
fragmentation.  On x86, when devices want to perform DMA operations,
they are given physical addresses, not virtual ones as with other
architectures like sparc64 which have an IOMMU.  This means that for
each of your 32k buffers, you need 8 _physically contiguous_ pages of
memory.

Unfortunately, the more a system is running, the more the physical
address space tends to be fragmented, and it becomes impossible to
reserve large chunks of physically contiguous memory, hence why the
kldload is failing.

If I remember correctly, Alan Cox intended to write a binary buddy
allocator to handle the physical address space (or do coalescing another
way, I'm not sure...) so that this particular problem is solved.

Cheers,
Maxime
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
Peter Jeremy [EMAIL PROTECTED] writes:
: On Mon, Nov 24, 2003 at 11:16:07PM -0700, M. Warner Losh wrote:
: H, It looks like the hit is less than 10% in the fork intensive
: test I just wrote:
: 
: #!/bin/sh
: for i in 0 1 2 3 4 5 6 7 8 9; do
: for j in 0 1 2 3 4 5 6 7 8 9; do
: for k in 0 1 2 3 4 5 6 7 8 9; do
:  for l in 0 1 2 3 4 5 6 7 8 9; do
:  for m in 0 1 2 3 4 5 6 7 8 9; do
:   for n in 0 1 2 3 4 5 6 7 8 9; do
: true;
: done; done; done; done; done; done;
: 
: Unless you've done something wierd to your /bin/sh, true is a
: builtin.  This test just to measures the ongoing runtime overhead
: of a dynamic executable (ie PIC code).  Drew's test was measuring
: the startup overhead.

True.  However, I get very similar numbers of I change it to
/usr/bin/true (12% slower).  /bin/sh usually fork+exec things other
/bin/sh.

: Clearly dynamic is slower, but it is more like 11% slower (10.67%) on
: the average than 40% slower.  I think this would be a more typical
: usage pattern.
: 
: You have measured different things.  Drew's test shows that a dynamic
: /bin/sh tahes about 40% longer to start.  Your test shows that once
: started, it runs about 11% slower.  And the 11% slower is _very_
: worrying since it is probably more widely applicable than just /bin/sh.

Dynamically linked prorgrams tend to be a few percent slower than
their static counterparts due to PIC code typically being slower than
non-PIC code.  There's nothing new here.

Clearly there are problems to look into, but it isn't the end of the
world.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Peter Jeremy
On Tue, Nov 25, 2003 at 04:54:41AM +, E.B. Dreger wrote:
What specific aspects of rtld are required to support NSS in
static binaries?  dlopen(), fixups, and dlsym()?

All of the above.  The underlying problem is how to handle a
library call from within the NSS/PAM/whatever shared library.
This has been discussed in one of the recent threads but it
boils down to:
1) Static executables don't normally have any symbols available at
   runtime so it's difficult for a shared library to resolve symbols
   using definitions in the executable.
2) It is possible (likely?) that a shared library may reference a
   symbol that does not exist within the executable.
3) Loading libc.so etc to resolve a symbol means that there may be
   two distinct (and possibly different) instances of the same object
   associated with a process.  This may create problems where those
   objects have side-effects.

Peter
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: memory allocation issue loading a kernel module

2003-11-25 Thread Sean McNeil
Yes, thanks for the clarification.  I still am inclined to believe,
though, that the disk driver is what is fragmenting the physical memory
with disk cacheing.  It is only a theory, but it sounded plausible.

Thanks again,
Sean

On Tue, 2003-11-25 at 00:13, Maxime Henrion wrote:
 Sean McNeil wrote:
  Hi everyone,
  
  I was wondering if there is a way to flush out pages in memory that
  might not be required.  I have a device driver that allocates 16 distict
  buffers each 32K in size.  This is done with a bus_dma call as they will
  be accessed by a PCI device.  The problem is that if I do a compile on
  my system prior to trying to kldload the module, there isn't enough
  physical memory for the driver.  I am assuming it is the disk cache that
  is eating up that memory and I want to flush out enough pages for my
  bus_dma allocation to work.
  
  Is this possible?  Any and all comments are appreciated.
 
 The problem has probably nothing to do with the disk cache eating up
 memory but I believe what you're seeing is physical address space
 fragmentation.  On x86, when devices want to perform DMA operations,
 they are given physical addresses, not virtual ones as with other
 architectures like sparc64 which have an IOMMU.  This means that for
 each of your 32k buffers, you need 8 _physically contiguous_ pages of
 memory.
 
 Unfortunately, the more a system is running, the more the physical
 address space tends to be fragmented, and it becomes impossible to
 reserve large chunks of physically contiguous memory, hence why the
 kldload is failing.
 
 If I remember correctly, Alan Cox intended to write a binary buddy
 allocator to handle the physical address space (or do coalescing another
 way, I'm not sure...) so that this particular problem is solved.
 
 Cheers,
 Maxime

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: memory allocation issue loading a kernel module

2003-11-25 Thread Maxime Henrion
Sean McNeil wrote:
 Yes, thanks for the clarification.  I still am inclined to believe,
 though, that the disk driver is what is fragmenting the physical memory
 with disk cacheing.  It is only a theory, but it sounded plausible.

Maybe, but the root cause is not the disk caching.  It may be that this
subsystem is doing a lot of allocations/deallocations and thus leads to
physical address space fragmentation, but the root cause is how we deal
with physical address space, and the correct fix is not to add hacks into
the disk caching code.  I'm insisting on this because I don't want to see
people adding hacks here and there to workaround the problem.  Even if
you get the disk caching code to cause less fragmentation, fragmentation
_will_ happen.  At best it'll take a bit longer.

Cheers,
Maxime
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


How many bikesheds can _you_ build on a pin head ?

2003-11-25 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes
:

First, this can be moved right to -chat or /dev/null.


Without it being an attack on shauns probably well thought out email,
his offer in the first line of it is too good to pass.

This is an email to everybody who participated in the most recent
couple of bikesheds:


FreeBSD exists because the stuff in the CVS repos has value to people.

If FreeBSD starts to fall behind or even God forbid, downright suck,
people will abandon FreeBSD.

The people who improve the value of the CVS repos are called committers.

Committers are volounteers who do the best they can for free, more
often than not in their own spare time.

Committers have never been known to have large amounts of spare time
nor (with a few notable exceptions) a desire to receive as much email
as possible.

So all the time committers spend wading through bikesheds of email
is time they don't work on the code, docs or ports, and therefore
ipso facto time during which FreeBSD looses momentum.

And each of you, every time you feel like sending an email, therefore
get to decide, indirectly, if FreeBSD should have a future
or not.

Think about it this way, next time you press reply:

Would I rather have all the developers read my email or would
I rather have them working on improving FreeBSD ?

Also, think about this:

You run, unquestioned code which does great and magic things deep
in the VM system, interrupt code, buffer cache, filesystems etc
etc, you don't even stop to think about how it actually works, you
trust the people who did it to know better than you.

But once it comes to a totally insignificant issue as to which
binaries are linked static and dynamic, you suddenly do not trust
the judgement of the same people, but feel that your views are
so important that it is paramount that they listen to you and
do exactly as you say because YOU KNOW BETTER!!!

That my friends, is how you could help kill BSD...


I have for myself recently taken a break from all active FreeBSD
development because I find the environment about as pleasant as a
kindergarten right before lunch.

If the project continues to degenerate into one bikeshed discussion
bigger than the next about issues of increasing irrelevance, then
I won't be able to persuade myself to go back in and suffer the
noise while I work on the really important things.


Poul-Henning


PS:
As for DFBSD staff posting to FreeBSD lists: the other 2-3 BSDs
have for ten years managed to coexist mostly peacefully because we
have respected each others mailing lists as not being suitable for
promoting our cause.  DFBSD would do well in adopting the same.

PPS: 
Poul-Henning has not been a core member for a number of years now,
so he obviously does not speak for [EMAIL PROTECTED]  He also does not speak
for the project as such.  He doesn't speak with any special authority
either.  He simply speaks for himself, as a committer who has been
one of the most active in the FreeBSD project for the last ten
years.  There, that should save a core member or two the trouble
of posting a disclaimer.  Hope you appreciate it :-)

PPPS: If you post this to SlashDot, DaemonNews or other such fora,
you're lame beyond imagination.

-- 
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.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Peter Jeremy
On Tue, Nov 25, 2003 at 01:17:34AM -0700, M. Warner Losh wrote:
True.  However, I get very similar numbers of I change it to
/usr/bin/true (12% slower).  /bin/sh usually fork+exec things other
/bin/sh.

That's a more interesting result and more comparable to Drew's test.
It doesn't necessarily invalidate Drew's results - /bin/sh has 3
shared libraries and is locale-aware whereas /usr/bin/test has 1
shared library and doesn't rely on the locale.  /usr/bin/true is also
significantly smaller (implying less relocation requirements).
/bin/sh could reasonably be expected to take longer to startup then
/usr/bin/test.

Dynamically linked prorgrams tend to be a few percent slower than
their static counterparts due to PIC code typically being slower than
non-PIC code.  There's nothing new here.

Except that, on face value, your figures suggested an 11% slowdown
attribute to PIC code - which is way above a few percent.

Clearly there are problems to look into, but it isn't the end of the
world.

Agreed.  I think most people agree that more work needs to be done.  The
arguing seems to be whether the work should be done before or after the
big switch is thrown and how to go about recovering the lost performance.
(And of course one contingent is insisting it be green whilst a different
contingent is insisting that it can't be green and has to be triangular
instead).

Peter
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: memory allocation issue loading a kernel module

2003-11-25 Thread Sean McNeil
Oh, I absolutely agree.  I do not want any hacks.  I was hoping that
there might be an existing mechanism that was in place that would allow
for the purging of unused physical pages by resource hogs.

I am reminded of an old OS I was fond of: AmigaOS.  It had a real nice
feature where applications, drivers, etc. would register a low memory
callback.  Whenever the OS reached certain water-marks, these callbacks
would get invoked.  It was a nice clean way for shared libraries and
drivers to cache things in memory, but then throw them away when things
got tight.

It is not a big deal for me.  This is for a customer of mine and they
are OK with loading the module early during boot when memory isn't
fragmented yet.

Just thinking out text,
Sean

On Tue, 2003-11-25 at 00:31, Maxime Henrion wrote:
 Sean McNeil wrote:
  Yes, thanks for the clarification.  I still am inclined to believe,
  though, that the disk driver is what is fragmenting the physical memory
  with disk cacheing.  It is only a theory, but it sounded plausible.
 
 Maybe, but the root cause is not the disk caching.  It may be that this
 subsystem is doing a lot of allocations/deallocations and thus leads to
 physical address space fragmentation, but the root cause is how we deal
 with physical address space, and the correct fix is not to add hacks into
 the disk caching code.  I'm insisting on this because I don't want to see
 people adding hacks here and there to workaround the problem.  Even if
 you get the disk caching code to cause less fragmentation, fragmentation
 _will_ happen.  At best it'll take a bit longer.
 
 Cheers,
 Maxime

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Andre Guibert de Bruet

On Mon, 24 Nov 2003, Leo Bicknell wrote:

 Process accounting can tell the story:

 % lastcomm | wc -l
47806
 % lastcomm | sed -e 's/ .*.//' | sort | uniq -c | sort -nr | head
 25281 sendmail
 4094 sh
 2987 perl
 2846 inetd
 1704 procmail
 1640 httpd
 1221 cron
  814 date
  732 postgres
  648 rateup

 Looks like sh is the 2nd most frequently executed command on my
 system.  It is 8.5% of all executed programs on this particular
 system.  I think slowing down 8.5% of all the programs the system
 runs is important.

For what it's worth, here's the data that I've taken from the daily
process accounting files of one of our somewhat busy shellboxes:

# lastcomm -f acct.0 | sed -e 's/ .*.//' | sort | uniq -c | sort -nr | head
4829 qpopper
3426 bash
3191 sendmail
1915 sh
1687 httpd
1281 sed
1030 sshd2
 952 rm
 792 procmail
 739 cron
# lastcomm -f acct.1 | sed -e 's/ .*.//' | sort | uniq -c | sort -nr | head
5383 qpopper
3282 bash
2743 sendmail
1617 httpd
1187 sh
1071 sed
 772 rm
 739 cron
 694 procmail
 478 cat
# lastcomm -f acct.2 | sed -e 's/ .*.//' | sort | uniq -c | sort -nr | head
5376 qpopper
2823 bash
2118 sendmail
1674 httpd
1510 sh
 745 procmail
 740 cron
 292 python
 288 atrun
 211 inetd

Though /bin/sh isn't 2nd on the list, it does feature prominently in the
top 10. I would assume that anyone with a fairly busy machine acting as a
shellbox and webserver would see something along these lines...

Regards,

 Andre Guibert de Bruet | Enterprise Software Consultant 
 Silicon Landmark, LLC. | http://siliconlandmark.com/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Matthew Dillon
:...
:5.x and propaganda about DFBSD doesn't really mean a whole lot, unless you
:are looking for new recruits to your camp.  In any case, you've made your
:point on a nearly daily basis that 5.x is inferior to what DFBSD will be,
:and that you don't have much knowledge or care about 5.x anyways.  So
:please, go do what you do best and make DFBSD the envy of the BSD world.
:I'll be first in line to pat you on the back when you succeed.
:
:Scott

Hmm.  Well, I think there's some confusion here.  While I certainly
like my vision for DFly better then I like the vision for FreeBSD-5,
that is simply in the eye of the beholder... of course I am going
to like my own vision better.  It's my vision, after all!  Your
vision is obviously different.  In fact, I expect that each person
has his own vision for the project, so don't knock me for mine.

But that has nothing to do with perceived inferiority or superiority.
The issue isn't so much whether one project is better then the other
as it is whether one is able and willing to borrow a proven concept
from another project to replace the one that maybe isn't so hot in
one's own.   As it happens, I have borrowed quite a bit of code
from 5.x.  As it also happens, I believe that 5.x would benefit by
adopting some of the things that have already been proven to work
quite well in DragonFly.  For example, using a statistical time 
accumulation model instead of calling microtime() in the middle
of the critical thread switch path, or not preemptively switching
threads operating in kernelland to another cpu, or the implementation
of a mutexless scheduler.  Just a few examples.  I can only point out
the concepts and ideas and point to the code in DFly, it is up to
FreeBSD-5 developers to take the ball up and either throw it away or
run with it. 

I have not been posting daily, but you seem to be frustrated about
something.  I can only suggest that blaming me for your frustrations
is not going to solve any tangible, technical issue in FreeBSD-5.  My
posts are technical and to the point.  Just because it's coming out of
my mouth rather then someone you might respect a bit more doesn't 
make it any more or less valid.  If you cannot address them based
on their technical merit then you've missed the point of the post
entirely.

And, just for the record, I feel quite obligated to try to move
the FreeBSD project forward along a path that I believe will be more
beneficial to its users.  Just to be clear:  My obligation is to all
the people who use FreeBSD, not to the feelings of particular
developers whos vision(s) I might disagree with.  I have no intent or
intention of screwing over FreeBSD (how absurd!) but you should not
mistakenly equate that to me being accomodating to FreeBSD's current
vision which, yes! it is true! I have serious disagreements with.
Over the years I have recommended FreeBSD to hundreds of people and
I take that responsibility very seriously.

If it is within the scope of the FreeBSD charter for a person to
post based on a perceived obligation to the end users of FreeBSD,
then I certainly still have a right to post to this group.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Erik H. Bakke
On Tuesday 25 November 2003 03:07, Don Lewis wrote:
 On 25 Nov, Daniel O'Connor wrote:
  On Tuesday 25 November 2003 11:52, Dan Nelson wrote:
 I'd greatly prefer that the the dynamic root default be backed out

until a substantial amount of this performance can be recovered.
  
   What _REAL WORLD_ task does this slow down?
 
  Try timing cd /usr/ports/www/mozilla-devel ; make clean with static
  and dynamic /bin.  bsd.port.mk spawns many many many /bin/sh processes.
 
  OK my bad, it will probably slow down the ports building.

 The ports infrastructure is horribly slow even with a static sh, though
 not as glacially slow as installing and patching Solaris 9.

But if the change to dynamic root provokes this slowdown that people have 
been seeing, it would be much better to address the cause and not the 
symptom.

The change to dynamic root here is not the cause, the extra overhead of using 
dynamically linked tools is, and that should be the main focus point.

If the overhead of dynamic linking is reduced, that will benefit all of us, 
even if we use a dynamic root or not.

-- 
Erik H. Bakke

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY

2003-11-25 Thread boyd, rounin
From: Stefan Farfeleder [EMAIL PROTECTED]
  errno is meaningful for syscalls after an error (the original
  message).  The fact that other functions also dink with errno is not
  relevant to that statement.
 
 I read boyd's statement as a contradiction to Jacques' one (only after
 syscall error vs. after library call error).

some libc functions do mangle errno, but only after an error.

in my terse statement the intention was to affirm that errno is
meaningless unless an error has ocurred (a syscall being the
simplest case, while random other libc calls may behave in
the same way).


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY

2003-11-25 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], boyd, rounin write
s:
From: Stefan Farfeleder [EMAIL PROTECTED]
  errno is meaningful for syscalls after an error (the original
  message).  The fact that other functions also dink with errno is not
  relevant to that statement.
 
 I read boyd's statement as a contradiction to Jacques' one (only after
 syscall error vs. after library call error).

some libc functions do mangle errno, but only after an error.

in my terse statement the intention was to affirm that errno is
meaningless unless an error has ocurred (a syscall being the
simplest case, while random other libc calls may behave in
the same way).

Errno is undefined unless the relevant manual page states otherwise.

-- 
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.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread boyd, rounin
i see that there some doubt about whether running lots of
shell scripts ever happens.  what happens when you
use make?  lots of shells get run and they run small
(one line?) scripts.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


panic: sleeping without a mutex (acd related)

2003-11-25 Thread Christian Laursen
I have been experiencing some random lockups after upgrading from
5.1-RELEASE to 5.2-BETA.

I then wen on and enabled all the debug options in my kernel config
hoping to be able to find the cause.

But now I cannot boot at all. In the end of the boot process when
detecting ATA drives, I get this:

ad0: 76319MB ST380011A [155061/16/63] at ata0-master UDMA100  
acd0-5: CDROM with 6 CD changer CD-C68E at ata1-master PIO4   
acd6: DVDROM CREATIVEDVD5240E-1 at ata1-slave PIO4
panic: sleeping without a mutex 
Debugger(panic)   
Stopped at  Debugger+0x54:  xchgl   %ebx,in_Debugger.0  
db 
db trace   
Debugger(c06e3744,c07549a0,c06e3ec9,d861ab60,100) at Debugger+0x54  
panic(c06e3ec9,0,c06e3eb8,c06d6584,10) at panic+0xd5
msleep(c45173d8,0,4c,c06d6584,0) at msleep+0x505
acd_geom_access(c452de00,1,0,0,0) at acd_geom_access+0x115  
g_access_rel(c4509280,1,0,0,d861aca0) at g_access_rel+0x20d 
g_slice_new(c0742a60,4,c452de00,d861ac9c,d861aca0) at g_slice_new+0xea  
g_mbr_taste(c0742a60,c452de00,0,15b,c452dd80) at g_mbr_taste+0x90   
g_new_provider_event(c452de00,0,c06de186,b5,6667) at g_new_provider_event+0d
one_event(d861ad10,c04f2b95,c074f994,0,4c) at one_event+0x218   
g_run_events(c074f994,0,4c,c06dd10e,a) at g_run_events+0x15 
g_event_procbody(0,d861ad48,c06e1304,311,2cb966) at g_event_procbody+0x45   
fork_exit(c04f2b50,0,d861ad48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xd861ad7c, ebp = 0 ---

I am not a kernel expert but the problem seems to be related to acd.

-- 
Best regards
Christian Laursen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread boyd, rounin
 That's a more interesting result and more comparable to Drew's test.
 It doesn't necessarily invalidate Drew's results - /bin/sh has 3
 shared libraries and is locale-aware whereas /usr/bin/test has 1
 shared library and doesn't rely on the locale.  /usr/bin/true is also
 significantly smaller (implying less relocation requirements).
 /bin/sh could reasonably be expected to take longer to startup then
 /usr/bin/test.

another can of worms.  various shells have test, true and false built in.
so, you have to be very careful in writing a shell comparision benchmark.

to complicate matters, ksh (statically linked) has _always_ been faster than sh.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Operating system advocacy (Was: Re: 40% slowdown with dynamic /bin/sh)

2003-11-25 Thread Mark Murray
Matthew Dillon writes:
 Hmm.  Well, I think there's some confusion here.  While I
 certainly like my vision for DFly better then I like the vision
 for FreeBSD-5, that is simply in the eye of the beholder... of
 course I am going to like my own vision better.  It's my vision,
 after all!  Your vision is obviously different.  In fact, I expect
 that each person has his own vision for the project, so don't
 knock me for mine.

There is a lot of opinion-knocking happening here on both sides, and
tempers are flaring.

Can I please ask that all parties take a step back and do what it takes
to increase light and reduce heat?

 But that has nothing to do with perceived inferiority or
 superiority.

True, inferiority/superiority issues are notoriously fulminative, and we
need to get this track back to the technical level, and away from more
personal achievment issues.

 The issue isn't so much whether one project is better then the
 other as it is whether one is able and willing to borrow a proven
 concept from another project to replace the one that maybe isn't
 so hot in one's own.

No. This thread is about a much more basic issue; the resolution of the
static/dynamic issue in the / volume.

Which operating system has the better solution, while a valid discussion
point, is a side track here, and is serving to add heat, not light.

  As it happens, I have borrowed quite a bit of code
 from 5.x.  As it also happens, I believe that 5.x would benefit
 by adopting some of the things that have already been proven to
 work quite well in DragonFly.  For example, using a statistical
 time accumulation model instead of calling microtime() in the
 middle of the critical thread switch path, or not preemptively
 switching threads operating in kernelland to another cpu, or the
 implementation of a mutexless scheduler.  Just a few examples.  I
 can only point out the concepts and ideas and point to the code
 in DFly, it is up to FreeBSD-5 developers to take the ball up and
 either throw it away or run with it.

Good points all. Perhaps they need to be discussed in their own right,
and not as a digression to the original thread?

 And, just for the record, I feel quite obligated to try to move
 the FreeBSD project forward along a path that I believe will be
 more beneficial to its users.

Careful. You are working hard on a very admirable project; please can
you continue to do do, and as-and-when issues from DFBSD prove their
worth, they will be adopted by other projects. This is a case where the
separation of strong personalities actually works out rather nicely, and
you can help this by proving how well DFBSD technology is :-).

There have been personality clashes in the past; some of these have been
shown to be unresolvable, but we now have the improved situation where
the talented folks are still developing BSD code without hindering each
other. This way BSD and its users win.

The way you can best help BSD is to continue to develop DragonFlyBSD.

   Just to be clear:  My obligation is to
 all the people who use FreeBSD, not to the feelings of particular
 developers whos vision(s) I might disagree with.  I have no
 intent or intention of screwing over FreeBSD (how absurd!) but
 you should not mistakenly equate that to me being accomodating to
 FreeBSD's current vision which, yes! it is true! I have serious
 disagreements with.

Sure. There are going to be disagreements, This is why there are 4 BSD's
available for free.

 Over the years I have recommended FreeBSD to hundreds of people
 and I take that responsibility very seriously.

Thank you! I hope that you will also be able to do that with
DragonFlyBSD.

 If it is within the scope of the FreeBSD charter for a person to
 post based on a perceived obligation to the end users of FreeBSD,
 then I certainly still have a right to post to this group.

Sort of. General opinion-mongering, flamage, sidetracking and so on
are off-charter. This is FreeBSD CURRENT, and it is most likely the
best to keep it somewhat restricted to that as some folks are starting
to get annoyed at the Dragonfly Advertising. I think that keeping
DFBSD-Advocacy/Discussion on FreeBSD lists to a pretty low level would
help keep blood pressure down all round (No offense intended, DFBSD is
a worthwhile project, its just that inter-project politics are somewhat
rough, and I'm trying to cool things down!)

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


WITHOUT_DYNAMICROOT vs. NO_DYNAMICROOT

2003-11-25 Thread Schuendehuette Matthias
Hi,

There's a bug in the release notes of CURRENT:

In Chapter 2.3 Userland Changes of the ReleaseNotes of CURRENT I read
about the Makefile variable WITHOUT_DYNAMICROOT whereas
/usr/src/Makefile.inc1 wants -DNO_DYNAMICROOT.

It should be corrected in the ReleaseNotes (IMHO)

mit freundlichen Grüßen / best regards

Matthias Schündehütte
SIEMENS AG, PTD M OI IT
Tel. +49-30-386 29957
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: WITHOUT_DYNAMICROOT vs. NO_DYNAMICROOT

2003-11-25 Thread Simon L. Nielsen
On 2003.11.25 12:52:03 +0100, Schuendehuette Matthias wrote:
 Hi,
 
 There's a bug in the release notes of CURRENT:
 
 In Chapter 2.3 Userland Changes of the ReleaseNotes of CURRENT I read
 about the Makefile variable WITHOUT_DYNAMICROOT whereas
 /usr/src/Makefile.inc1 wants -DNO_DYNAMICROOT.
 
 It should be corrected in the ReleaseNotes (IMHO)

Yes, that should be changed.  I just asked the RE team permission to fix
this (since we are in a code freeze at the moment).

Thanks for reporting it.

-- 
Simon L. Nielsen
FreeBSD Documentation Team


pgp0.pgp
Description: PGP signature


Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY

2003-11-25 Thread Enache Adrian
On Mon, Nov 24, 2003 a.d., Jacques A. Vidrine wrote:
 The application is broken.  You must only check errno if you get an
 error indication from the library call.

Sorry, but I don't see your point. I know when to check for errno.
If you took the little illustrating program for a real life example of
the use of errno, that's unfortunate :-)

The problem is that the emulated/wrapped close from libc_r does not
behave like the real one. libc_r is leaking some of its guts
(the tricks it's doing with O_NONBLOCK, etc) in the interface.
This is technically a bug. The fix was trivial.

Regards,
Adi
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: panic: sleeping without a mutex (acd related)

2003-11-25 Thread Pawel Jakub Dawidek
On Tue, Nov 25, 2003 at 11:21:03AM +0100, Christian Laursen wrote:
+ I have been experiencing some random lockups after upgrading from
+ 5.1-RELEASE to 5.2-BETA.
+ 
+ I then wen on and enabled all the debug options in my kernel config
+ hoping to be able to find the cause.
+ 
+ But now I cannot boot at all. In the end of the boot process when
+ detecting ATA drives, I get this:
+ 
+ ad0: 76319MB ST380011A [155061/16/63] at ata0-master UDMA100  
+ acd0-5: CDROM with 6 CD changer CD-C68E at ata1-master PIO4   
+ acd6: DVDROM CREATIVEDVD5240E-1 at ata1-slave PIO4
+ panic: sleeping without a mutex 
+ Debugger(panic)   
+ Stopped at  Debugger+0x54:  xchgl   %ebx,in_Debugger.0  
+ db 
+ db trace   
+ Debugger(c06e3744,c07549a0,c06e3ec9,d861ab60,100) at Debugger+0x54  
+ panic(c06e3ec9,0,c06e3eb8,c06d6584,10) at panic+0xd5
+ msleep(c45173d8,0,4c,c06d6584,0) at msleep+0x505
+ acd_geom_access(c452de00,1,0,0,0) at acd_geom_access+0x115  

Yeah. There are two calls of tsleep(9) without timeout set
(in line 499, 509), so this KASSERT is reached:

KASSERT(timo != 0 || mtx_owned(Giant) || mtx != NULL,
(sleeping without a mutex));

-- 
Pawel Jakub Dawidek   [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net


pgp0.pgp
Description: PGP signature


Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY

2003-11-25 Thread Daniel Eischen
On Tue, 25 Nov 2003, Enache Adrian wrote:

 On Mon, Nov 24, 2003 a.d., Jacques A. Vidrine wrote:
  The application is broken.  You must only check errno if you get an
  error indication from the library call.
 
 Sorry, but I don't see your point. I know when to check for errno.
 If you took the little illustrating program for a real life example of
 the use of errno, that's unfortunate :-)
 
 The problem is that the emulated/wrapped close from libc_r does not
 behave like the real one. libc_r is leaking some of its guts
 (the tricks it's doing with O_NONBLOCK, etc) in the interface.
 This is technically a bug. The fix was trivial.

I don't see a bug.  You don't check errno unless the return is -1.
If the return is -1, then it must be because ret = __sys_close(fd)
failed in which case errno will be set appropriately.

Even so, there are other things to worry about aside from the fcntl
to set the flags.  The wrapped close also uses fstat(2) which can fail
in ways not listed by close(2).

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: How to fix this in 5.1-REL??

2003-11-25 Thread Odhiambo Washington
* Kevin Oberman [EMAIL PROTECTED] [20031125 02:39]: wrote:
  Date: Sat, 22 Nov 2003 06:07:03 -0800
  From: Kris Kennaway [EMAIL PROTECTED]
  Sender: [EMAIL PROTECTED]
  
  
  --nVMJ2NtxeReIH9PS
  Content-Type: text/plain; charset=us-ascii
  Content-Disposition: inline
  
  On Sat, Nov 22, 2003 at 03:16:06PM +0300, Odhiambo Washington wrote:
I end up with the following when I run `make world` on  5.1-RELEASE-p10.
  
  Did you read UPDATING?
 
 I fear a bikeshed, but I really think it may be past time to remove
 the 'world' target from /usr/src/Makefile.inc1. It is rarely useful
 and only should be used by those who understand the process and know
 that it is safe. Removing it would remove a clear way to shoot one's
 foot and would really have trivial impact on those who use it
 properly.


Hmm,

This was meant to help me but instead I was left speechless, not knowing
how to say that I did not understand the context of this ;)
How am I supposed to go over the initial problem?
When Kris Kennaway asked me that question, I emphatically told him, YES,
I did. Then what he thought I should do was to rm /usr/include/g++/*
I did exactly that, but it did not help solve the problem and even so,
I wasn't quite sure why I was to do this, after re-reading from UPDATING.
So my problem is very much alive and kicking ;)



-Wash


--
+==+
|\  _,,,---,,_ | Odhiambo Washington[EMAIL PROTECTED]
Zzz /,`.-'`'-.  ;-;;,_ | Wananchi Online Ltd.   www.wananchi.com
   |,4-  ) )-,_. ,\ (  `'-'| Tel: +254 20 313985-9  +254 20 313922
  '---''(_/--'  `-'\_) | GSM: +254 722 743223   +254 733 744121
+==+
Every improvement in communication makes the bore more terrible.
-- Frank Moore Colby


smime.p7s
Description: S/MIME cryptographic signature


Cardbus cards break bge0

2003-11-25 Thread Eric Anderson
I recently cvsup'ed (last week anyway), and build/installed world/kernel 
etc.  Now,  when I connect a cardbus card
(firewire cards, ethernet, wireless, etc), my broadcom bge0 interface 
goes crazy, stops functioning, and I get this:

Nov 19 10:18:32 neutrino kernel: cardbus0: Resource not specified in 
CIS: id=10, size=1
Nov 19 10:18:32 neutrino kernel: bge1: Broadcom BCM5702 Gigabit 
Ethernet, ASIC rev. 0x1002 mem 0xf601-0xf601 irq 11 at device 
0.0 on cardbus0
Nov 19 10:18:32 neutrino kernel: bge1: RX CPU self-diagnostics failed!
Nov 19 10:18:32 neutrino kernel: bge1: chip initialization failed
Nov 19 10:18:32 neutrino kernel: device_probe_and_attach: bge1 attach 
returned 6
Nov 19 10:18:32 neutrino kernel: cbb0: CardBus card activation failed
Nov 19 10:18:32 neutrino kernel: bge0: PHY read timed out
Nov 19 10:18:48 neutrino last message repeated 85 times

My gigabit ethernet (the broadcom) card device (which is onboard - this 
is a laptop) is bge0.  Notice above it complains about bge1, then the
PHY read timed out errors start.  If I boot with the card installed, 
here's what I get:

Nov 19 10:23:35 neutrino kernel: bge0: PHY read timed out
Nov 19 10:23:35 neutrino last message repeated 9 times
Nov 19 10:23:35 neutrino kernel: bge0: RX CPU self-diagnostics failed!
Nov 19 10:23:35 neutrino kernel: bge0: flow-through queue init failed
Nov 19 10:23:35 neutrino kernel: bge0: initialization failure
Anyone have any ideas on what caused this breakage?

Eric

--
--
Eric Anderson   Systems Administrator  Centaur Technology
All generalizations are false, including this one.
--
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Jacques A. Vidrine
On Mon, Nov 24, 2003 at 07:11:29PM -0800, Matthew Dillon wrote:
 You don't need dynamic loading to get nsswitch type functionality.  You
 only need dynamic loading if nobody is willing to write an IPC
 model to get the functionality.  It's really silly to create such a
 fundamental restriction on the binary because people are too lazy
 to build an IPC based mechanism.  

Matt, I'm not lazy. (Well, maybe I am, but that's not why I
implemented NSS in the canoncial way instead of using IPC.)  I've
experimented with proxy-based solutions.  Such solutions add a lot of
complexity with little benefit.  The primary NSS backends today are:

 NIS --- lightweight, proxy would just slow things down
 Hesiod --- lightweight
 winbindd --- lightweight (it implements its own proxy)
 nss_ldap --- could benefit

IMHO, it makes more sense to write NSS modules that do their own
proxying than to make things even more complicated in libc.  Those
that are lightweight don't carry extra baggage; those that do can
implement proxying in the most efficient manner for that particular
backend, e.g. some calls can be proxyed while others done in-process.
You don't have to rewrite existing NSS modules so that they take into
account that they are really serving multiple processes--- which
usually means adding credentials management, locking, per-process
state, and so forth to each NSS module.  Or you could just create a
whole new NSS API and call it something else and forget about support
for existing NSS modules.

Caching results (which is different than out-of-process
implementations, the Linux nscd authors are just confused) does
require a daemon, but this doesn't really complicate things.  (I
should get around to that someday :-)

That said, I would not stand in the way of a well-thought out,
well-written NSS implementation that attempts to proxy every get*()
call over e.g. RPC.  (Hmm, sounds like NIS to me.  I guess that's
partially explains why PADL.com's NIS-LDAP gateway is popular :-)

 Not only silly, but it seems to me
 that it also creates security issues.  At least with a client/server
 model it is possible to isolate the authentication code to, for example,
 disallow exec(), filesystem operations, or the opening of any new files.

Um, if you can't trust the authentication code, what can you trust?
Furthermore, for many many many applications that use getpwnam(3) and
so on, increased privileges are not needed or wanted.

And if you *are* really talking about authentication code (and not
directory services), then you need to get PAM to work in a statically
linked world, also.  (You can compile PAM statically today, but that
means no 3rd-party modules.  The same holds for NSS, of course.)

 The other huge advantage that IPC has over DLL is that you can switchout
 the backend mechanisms on a running system without killing and restarting
 anything other then he one service you want to switch out, and if it
 doesn't work right you can restart the old one or keep live as a fallback.

When using the current NSS implementation, there is no need to
kill/restart anything when you update /etc/nsswitch.conf.  New
modules are dynamically loaded, and any no-longer-referenced ones are
unloaded.

 the IPC model is so much better then the DLL model for this sort of thing
 I don't understand why people are even arguing about it.

Because the rest of us are stupid and lazy, remember?  :-)

Cheers,
-- 
Jacques Vidrine   NTT/Verio SME  FreeBSD UNIX   Heimdal
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


pcm(4) related panic

2003-11-25 Thread Artur Poplawski
Hello,  

On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic 
like this:
 
(watch out for folded lines; the stack backtrace below is rewritten by
hand from ddb)

lock order reversal
 1st 0xc22a45ac vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323
 2nd 0xc06c0420 swap_pager swhash (swap_pager swhash) @ \
/usr/src/sys/vm/swap_pager.c:1838
 3rd 0xc0c358c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876
Stack backtrace:
  backtrace
  witness_lock
  _mtx_lock_flags
  obj_allock
  slab_zalloc
  uma_zone_slab
  uma_zalloc_internal
  uma_zalloc_arg
  swp_pager_meta_build
  swap_pager_putpages
  default_pager_putpages
  vm_pageout_flush
  vm_pageout_clean
  vm_pageout_scan
  vm_pageout
  fork_exit
  fork_trampoline

Sleeping on swread with the following non-sleepable locks held:
exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \   
/usr/src/sys/dev/sound/pcm/dsp.c:146
panic: sleeping thread (pid 583) owns a non-sleepable lock
syncing disks, buffers remaining... 1410 1410 panic: mi_switch: \ 
switch in a critical section
Uptime: 1m45s
panic: msleep
Uptime: 1m45s
panic: msleep
Uptime: 1m45s
panic: msleep
Uptime: 1m45s
panic: msleep
[... repeated few more times]
Fatal double fault:
eip = 0xc05e3916
esp = 0xc8db8ff4
ebp = 0xc8db9004
panic: double fault
Uptime: 1m45s
panic: msleep
Uptime: 1m45s 
panic: msleep
Uptime: 1m45s
panic: msleep
Uptime: 1m45s
[...]
And the machine suddenly reboots, so there is no coredump.
 
eip address points close to:
c05e3910 T sc_vtb_putc
 
To reproduce this panic just start some audio player app (like xmms), 
and launch countless memory-eating applications (like mozilla ;).
The machine starts swapping, and it panics. 

% uname -a 
FreeBSD kaszanka.domek 5.2-BETA FreeBSD 5.2-BETA #0: Sun Nov 23 01:23:10\ 
 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KASZANKA i386 

dmesg fragments:
CPU: AMD Athlon(tm) XP 2000+ (1666.73-MHz 686-class CPU)
pcm0: AudioPCI ES1373-B port 0xec00-0xec3f irq 10 at device 8.0 on pci0 
pcm0: Cirrus Logic CS4297A AC97 Codec
rl0: RealTek 8139 10/100BaseTX port 0xe800-0xe8ff mem \
 0xdf00-0xdfff ir
q 10 at device 10.0 on pci0
miibus0: MII bus on rl0
rlphy0: RealTek internal media interface on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
rl1: RealTek 8139 10/100BaseTX port 0xe400-0xe4ff mem \
 0xde00-0xdeff ir
q 10 at device 11.0 on pci0
rlphy1: RealTek internal media interface on miibus1
rlphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

Regards, Artur
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Jacques A. Vidrine
On Mon, Nov 24, 2003 at 10:06:12PM -0500, Andrew Gallatin wrote:
 How about Gordon's initial bootstone, which increased by 25%?
 http://docs.freebsd.org/cgi/mid.cgi?16091.44150.539095.704531
 
 And I just did a make clean run in /usr/ports/archivers (by manually
 mv'ing a static and dynamic sh to /bin in turn):
 
 static:   96.63 real53.45 user39.27 sys
 dynamic: 112.42 real55.51 user51.62 sys
 
 The wall clock is bad (16% worse) and the system time is worse (31%).
 
 
 So.. 
 
 1) Microbenchmark:40% worse
 2) Bootstone(*):  25% worse
 3) Ports: 16% worse

So can we just have a statically linked /bin/sh and get on with life?
That seems to have the most impact.  We can also expend our efforts
to improve dynamic linking performance, since that will improve the
performance of the other 99.9% of the universe.

Users who REALLY REALLY need /bin/sh to support 3rd-party NSS modules
in the mean time can build /bin/sh dynamically.  Or we can have
/usr/bin/sh as someone else suggested (most of the FreeBSD world's
shell scripts--- which are what we *really* seem to be talking
about--- already have #! /bin/sh).

I prefer to keep as much of the world dynamic, both for dlopen support
and for easier system patching.  But I can also understand the desire
to avoid a penalty for all those short but oft-run scripts.

In any case, I'd really like to see a goal for 5.3-RELEASE that
includes bringing dynamically-linked /bin/sh performance (*much*)
closer to statically-linked /bin/sh performance.

Cheers,
-- 
Jacques Vidrine   NTT/Verio SME  FreeBSD UNIX   Heimdal
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Jacques A. Vidrine
On Mon, Nov 24, 2003 at 08:22:52PM -0600, David Leimbach wrote:
 Yep :).
 
 I feel like saying set the default to static and make the dynamic bins 
 the option so
 the people who can't be bothered to compile their own system even 
 though everyone
 I know does this for tuning purposes anyway can stop whining.
 
 But I won't say that.

I feel we need to pressure to improve the performance of dynamic
linking.  This is not really different from anything else we do in
-CURRENT: some things we have to throw out there before it is perfect,
in order to reach critical mass.

Cheers,
-- 
Jacques Vidrine   NTT/Verio SME  FreeBSD UNIX   Heimdal
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


RE: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Guy Helmer
Jacques A. Vidrine wrote:
 On Mon, Nov 24, 2003 at 10:06:12PM -0500, Andrew Gallatin wrote:
  How about Gordon's initial bootstone, which increased by 25%?
  http://docs.freebsd.org/cgi/mid.cgi?16091.44150.539095.704531
  
  And I just did a make clean run in /usr/ports/archivers (by manually
  mv'ing a static and dynamic sh to /bin in turn):
  
  static:   96.63 real53.45 user39.27 sys
  dynamic: 112.42 real55.51 user51.62 sys
  
  The wall clock is bad (16% worse) and the system time is worse (31%).
 So can we just have a statically linked /bin/sh and get on with life?
 That seems to have the most impact.  We can also expend our efforts
 to improve dynamic linking performance, since that will improve the
 performance of the other 99.9% of the universe.

Yes, let's do it and get on with it.  /bin/sh is critically important
to the performance of many things in the system, but shared / is very
useful as well - it's allowed me to move my 4.x systems with small /
up to 5-current, and / programs can take advantage of NSS and PAM
modules that exist *today*.
 
 ...
 In any case, I'd really like to see a goal for 5.3-RELEASE that
 includes bringing dynamically-linked /bin/sh performance (*much*)
 closer to statically-linked /bin/sh performance.

Yes -- this is -current: let's get 5.2 out the door and improve on it
for 5.3.

Guy Helmer

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Andrew Gallatin

Jacques A. Vidrine writes:
  
  So can we just have a statically linked /bin/sh and get on with life?

That certainly seems like the best compromise.   Then we can end this
thread ;)

  That seems to have the most impact.  We can also expend our efforts
  to improve dynamic linking performance, since that will improve the
  performance of the other 99.9% of the universe.
  

What happened to mdodd's prebinding efforts?

Drew
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-25 Thread Matthew D. Fuller
On Mon, Nov 24, 2003 at 02:41:44PM -0800 I heard the voice of
David O'Brien, and lo! it spake thus:
 On Mon, Nov 24, 2003 at 04:07:49PM -0500, Michael Edenfield wrote:
  
  Would it be possible, through some make.conf magic, for the end-user to
  set extra programs to be put into /rescue that are not typically there?
  
  RESCUE_EXTRAPRGS= usr.bin/vi usr.bin/fetch
 
 This list could easily need things added to librescue.

If you can delay building the rescue stuff until after everything else,
you can use ldd(1) on the built binaries for everything else and hash up
the list from that.  I do something similar in a set of scripts I have to
generate filesystems for small systems (i.e., I create a variable in a
Makefile listing all the programs, and it automatically includes all the
libraries the programs need) with a little sed/awk.


-- 
Matthew Fuller (MF4839)   |  [EMAIL PROTECTED]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/

The only reason I'm burning my candle at both ends, is because I
  haven't figured out how to light the middle yet
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


4 - 5 Problem

2003-11-25 Thread Lawrence Farr
I build 5-CURRENT every night, and NFS export src and obj
to my other CURRENT machines to update. I've been doing 
this quite happily this way for a while. When I try to
do an installkernel on a stable machine, I get:

[EMAIL PROTECTED]:/usr/src# make installkernel
Bad system call (core dumped)
*** Error code 140

Stop in /usr/src. 

I can no longer do this on any of the current boxes either:

mkdir -p /boot/kernel
install -p -m 555 -o root -g wheel kernel /boot/kernel
*** Signal 12

Stop in /usr/obj/usr/src/sys/P6MPFW.
*** Error code 1

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

Stop in /usr/src.

I tried with -DALWAYS_CHECK_MAKE as well. Have I missed 
something in UPDATING? Anyone else doing this without 
issue?

the Current target machine is from Thu Sep 25 14:32:19 GMT 2003,
the stable one from Mon Mar 24 16:30:45 GMT 2003, and the 
src and obj are fresh from last night.

Lawrence Farr
EPC Direct Limited  

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Cy Schubert
In message [EMAIL PROTECTED], Jacques A. Vidrine 
wri
tes:
 So can we just have a statically linked /bin/sh and get on with life?

I was thinking the same thing myself a few days ago.


Cheers,
--
Cy Schubert [EMAIL PROTECTED]http://www.komquats.com/
BC Government .   FreeBSD UNIX
[EMAIL PROTECTED] . [EMAIL PROTECTED]
http://www.gov.bc.ca/ .http://www.FreeBSD.org/



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 4 - 5 Problem

2003-11-25 Thread Clement Laforet
On Tue, 25 Nov 2003 16:18:26 -
Lawrence Farr [EMAIL PROTECTED] wrote:
 
 the Current target machine is from Thu Sep 25 14:32:19 GMT 2003,
 the stable one from Mon Mar 24 16:30:45 GMT 2003, and the 
 src and obj are fresh from last night.

did you read /usr/src/UPDATING ?

20031112:
The statfs structure has been updated with 64-bit fields to
allow accurate reporting of multi-terabyte filesystem
sizes. You should build world, then build and boot the new kernel
BEFORE doing a `installworld' as the new kernel will know about
binaries using the old statfs structure, but an old kernel will
not know about the new system calls that support the new statfs
structure.

clem
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


RE: 4 - 5 Problem

2003-11-25 Thread Lawrence Farr
Err yes I did. Im trying to install a kernel.

Lawrence Farr
EPC Direct Limited  

 -Original Message-
 From: Clement Laforet [mailto:[EMAIL PROTECTED] 
 Sent: 25 November 2003 16:26
 To: Lawrence Farr
 Cc: [EMAIL PROTECTED]
 Subject: Re: 4 - 5 Problem
 
 On Tue, 25 Nov 2003 16:18:26 -
 Lawrence Farr [EMAIL PROTECTED] wrote:
  
  the Current target machine is from Thu Sep 25 14:32:19 GMT 2003,
  the stable one from Mon Mar 24 16:30:45 GMT 2003, and the 
  src and obj are fresh from last night.
 
 did you read /usr/src/UPDATING ?
 
 20031112:
 The statfs structure has been updated with 64-bit fields to
 allow accurate reporting of multi-terabyte filesystem
 sizes. You should build world, then build and boot 
 the new kernel
 BEFORE doing a `installworld' as the new kernel will 
 know about
 binaries using the old statfs structure, but an old 
 kernel will
 not know about the new system calls that support the 
 new statfs
 structure.
 
 clem
 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


requesting vinum help

2003-11-25 Thread Joel M. Baldwin
Could a vinum guru please contact me via email?

I've lost 2 vinum volumes as a result of the latest fiasco and naturally
am eager to figure out what's going on and recover the data.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: requesting vinum help

2003-11-25 Thread Eric Anderson

Could a vinum guru please contact me via email?

I've lost 2 vinum volumes as a result of the latest fiasco and naturally
am eager to figure out what's going on and recover the data.
This isn't necessarily directed at you - I'm just using this email as a 
footstep to send this general comment -

I am kind of under the assumption that -current is more of a test bed, 
and anything can happen at any time, which is why it's bad to run 
-current on a machine you care deeply about (at least its data).  I 
think I've seen at least 5 mails in the past few weeks about people 
getting jammed into a corner with (what sounds like) production type 
boxes, or at least important boxes (or they wouldn't need a vinum?).. It 
seems odd to me that they wouldn't give it a whirl first before 
attempting to use it on a box they seem so protective of.

Anyway, I'm just stating that running -current is for testing and 
developing, not really for production - at least I'm fairly certain.

Feel free to delete this mail and ignore me..

Eric



--
--
Eric Anderson  Systems Administrator  Centaur Technology
All generalizations are false, including this one.
--
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Garance A Drosihn
At 9:19 AM -0600 11/25/03, Jacques A. Vidrine wrote:
On Mon, Nov 24, 2003, Andrew Gallatin wrote:

So can we just have a statically linked /bin/sh and get on
with life?
I still think we would be better off using 5.2-release for
collecting more experience with the *operational* issues of
having a dynamic /bin/sh.  We all know and knew that there
would be a performance hit.  We also all know that a static
/bin/sh will work fine in disaster situations.
That seems to have the most impact.  We can also expend
our efforts to improve dynamic linking performance, since
that will improve the performance of the other 99.9% of
the universe.
This is certainly my hope.  There are more ways to solve the
performance problem than just statically-linking /bin/sh.
If we do not alleviate the performance issues via other means,
then we can certainly statically-link /bin/sh for 5.3-release.
We have run with a statically-linked /bin/sh for years, so
there is nothing much to *learn* by running with it for the
next two months.  Yes, there is a performance benefit, but
nothing to *learn*.
But my fear is that if we *do* address the performance issues,
then we'll still shy off a dynamically-linked /bin/sh simply
because some folks will say we don't know that we can trust
it, etc.
I have no objection if we want to statically-link some things
like /bin/sh for 5.3-release, but I don't think we need to do
it for 5.2-release -- aka a snapshot of freebsd-current.
--
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: How to fix this in 5.1-REL??

2003-11-25 Thread Kevin Oberman
 Date: Tue, 25 Nov 2003 17:47:29 +0300
 From: Odhiambo Washington [EMAIL PROTECTED]
 
 
 --+g7M9IMkV8truYOl
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 * Kevin Oberman [EMAIL PROTECTED] [20031125 02:39]: wrote:
   Date: Sat, 22 Nov 2003 06:07:03 -0800
   From: Kris Kennaway [EMAIL PROTECTED]
   Sender: [EMAIL PROTECTED]
  =20
  =20
   --nVMJ2NtxeReIH9PS
   Content-Type: text/plain; charset=3Dus-ascii
   Content-Disposition: inline
  =20
   On Sat, Nov 22, 2003 at 03:16:06PM +0300, Odhiambo Washington wrote:
 I end up with the following when I run `make world` on  5.1-RELEASE-=
 p10.
  =20
   Did you read UPDATING?
 =20
  I fear a bikeshed, but I really think it may be past time to remove
  the 'world' target from /usr/src/Makefile.inc1. It is rarely useful
  and only should be used by those who understand the process and know
  that it is safe. Removing it would remove a clear way to shoot one's
  foot and would really have trivial impact on those who use it
  properly.
 
 
 Hmm,
 
 This was meant to help me but instead I was left speechless, not knowing
 how to say that I did not understand the context of this ;)
 How am I supposed to go over the initial problem?
 When Kris Kennaway asked me that question, I emphatically told him, YES,
 I did. Then what he thought I should do was to rm /usr/include/g++/*
 I did exactly that, but it did not help solve the problem and even so,
 I wasn't quite sure why I was to do this, after re-reading from UPDATING.
 So my problem is very much alive and kicking ;)

This was not addressed so much to you as to the list.

The following is a history lesson. Sorry to waste the time of those who
have been with FreeBSD for a long time and know all about it.

While UPDATING contain details on updating a system, the Makefile in
/usr/src (actually Makefile.inc1) contains a target of 'world' and,
through V3 of FreeBSD, this was considered the appropriate target for
re-compiling sources.

In the days of V4, a new methodology for updating that was far less
prone to failure that would leave a system unusable was developed with
two new targets, 'buildworld' and 'installworld'. The old 'world' target
was left in the file as it could still be used and people were used to
using it (POLA). But, as V4 developed, UPDATING specified only the new
method of updating and the developers could integrate changes in ways
that would not work with the 'world' target.

Now we are moving on to V5 and 'world' is growing increasingly dangerous
to use. Because changes are applied that will allow smooth upgrades
when the kernel is built after the new system is built, but before it is
installed, make world is increasingly unlikely to work.

I was suggesting that it's time to eliminate this excellent path to
foot-shooting once and for all. 

In addition, people often do miss the section of UPDATING on the V4 to
V5 upgrade and end up with the wrong version of loader (which is pretty
sure to get fixed promptly) and with the /usr/include/g++ headers
intact. This can produce all kinds of build problems down the road. I
have no idea how to get the message about this across any better, but I
know that when V5 is declared stable, we are going to see a flood of
failed builds as a result of this oversight.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Unfortunate dynamic linking for everything

2003-11-25 Thread Tony Finch
Matthew D. Fuller [EMAIL PROTECTED] wrote:

Not just the startup scripts, but ANY script.  I dare say there's a long,
long list of scripts that use ~-expansion, to say nothing of the
homegrown ones we all have working quietly and forgotten for years.

It's required for POSIX compliance.

Tony.
-- 
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
IRISH SEA: SOUTHWESTERLY 5 OR 6. SHOWERS. GOOD.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Unfortunate dynamic linking for everything

2003-11-25 Thread Tony Finch
Robert Watson [EMAIL PROTECTED] wrote:

Someone must be using /bin/sh as a shell, because apparently someone
spent a lot of time adding things like character input editing, filename
completion, etc.  We even use sh as the default in adduser(8).

Command-line editing is required for POSIX compliance.

Tony.
-- 
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
FAIR ISLE: SOUTHWESTERLY BACKING EASTERLY 5 TO 7, PERHAPS GALE 8 LATER.
SHOWERS THEN RAIN. MODERATE OR GOOD.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread M. Warner Losh
In message: [EMAIL PROTECTED]
boyd, rounin [EMAIL PROTECTED] writes:
: i see that there some doubt about whether running lots of
: shell scripts ever happens.  what happens when you
: use make?  lots of shells get run and they run small
: (one line?) scripts.

make buildworld slows down  1% when you switch from static /bin/sh to
dynamic.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


rc scripts run double on boot?

2003-11-25 Thread Nate Lawson
With a recent -current, I've noticed double prints for the last few rc
scripts, like this:

Starting cron.
Local package initialization:.
Local package initialization:.
Additional TCP options:.
Additional TCP options:.

Anyone else seeing this?

-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Intel SE7500WV2 not working with ACPI

2003-11-25 Thread Brooks Davis
Since the interrupt changes, my dual Xeons based on the SE7500WV2 board
don't work with ACPI.  Specificly, the onboard nics (em0 and em1)
appear to not be recieving interupts.  Instead, they continiously get
watchdog timeouts.  In a stock current, this is an instant panic.  With
a minor fix to the watchdog function, the system sees to be more or less
funcitonal other then not having a network.  Disabling ACPI makes the
nics work.  I have updated the BIOS to the latest version[0].

I've included ACPI and non-ACPI dmesg output below.  What else is needed
to diagnose this problem?  Any patches I should try?

-- Brooks

[0] In a way, I'm glad the BIOS update didn't fix the problem because
that would probably mean I'd have to flash another 70 machines.

Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-CURRENT #1: Tue Nov 11 14:45:00 PST 2003
[EMAIL 
PROTECTED]:/usr/home/brooks/working/freebsd/p4/xname/sys/i386/compile/GENERIC
Preloaded elf kernel /boot/kernel/kernel at 0xc0a75000.
ACPI APIC Table: INTEL  SWV20   
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) XEON(TM) CPU 2.20GHz (2193.54-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf24  Stepping = 4
  
Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM
  Hyperthreading: 2 logical CPUs
real memory  = 1073676288 (1023 MB)
avail memory = 1033482240 (985 MB)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  6
 cpu3 (AP): APIC ID:  7
ioapic0 Version 2.0 irqs 0-23 on motherboard
ioapic1 Version 2.0 irqs 24-47 on motherboard
ioapic2 Version 2.0 irqs 48-71 on motherboard
lapic0: Forcing LINT1 to edge trigger
Pentium Pro MTRR support enabled
ACPI-0660: *** Warning: Type override - [DEB_] had invalid type (Integer) for 
Scope operator, changed to (Scope)
ACPI-0660: *** Warning: Type override - [MLIB] had invalid type (Integer) for 
Scope operator, changed to (Scope)
ACPI-0660: *** Warning: Type override - [DATA] had invalid type (String) for Scope 
operator, changed to (Scope)
ACPI-0660: *** Warning: Type override - [SIO_] had invalid type (String) for Scope 
operator, changed to (Scope)
ACPI-0660: *** Warning: Type override - [LEDP] had invalid type (String) for Scope 
operator, changed to (Scope)
ACPI-0660: *** Warning: Type override - [GPEN] had invalid type (String) for Scope 
operator, changed to (Scope)
ACPI-0660: *** Warning: Type override - [GPST] had invalid type (String) for Scope 
operator, changed to (Scope)
ACPI-0660: *** Warning: Type override - [WUES] had invalid type (String) for Scope 
operator, changed to (Scope)
ACPI-0660: *** Warning: Type override - [WUSE] had invalid type (String) for Scope 
operator, changed to (Scope)
ACPI-0660: *** Warning: Type override - [SBID] had invalid type (String) for Scope 
operator, changed to (Scope)
ACPI-0660: *** Warning: Type override - [SWCE] had invalid type (String) for Scope 
operator, changed to (Scope)
acpi0: INTEL  SWV20on motherboard
ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_._REG] (Node 
0xc29b4660), AE_NOT_EXIST
acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST
device_probe_and_attach: acpi0 attach returned 6
npx0: [FAST]
npx0: math processor on motherboard
npx0: INT 16 interface
pcibios: BIOS version 2.10
Using $PIR table, 19 entries at 0xc00f3060
pcib0: Host to PCI bridge at pcibus 0 on motherboard
pci0: PCI bus on pcib0
pci_cfgintr: 0:29 INTA BIOS irq 5
pci_cfgintr: 0:29 INTB BIOS irq 10
pci0: unknown at device 0.1 (no driver attached)
pcib1: PCIBIOS PCI-PCI bridge at device 3.0 on pci0
pci2: PCI bus on pcib1
pci2: base peripheral, interrupt controller at device 28.0 (no driver attached)
pcib2: PCIBIOS PCI-PCI bridge at device 29.0 on pci2
pci4: PCI bus on pcib2
pci2: base peripheral, interrupt controller at device 30.0 (no driver attached)
pcib3: PCIBIOS PCI-PCI bridge at device 31.0 on pci2
pci3: PCI bus on pcib3
pci_cfgintr: 3:7 INTA BIOS irq 5
pci_cfgintr: 3:7 INTB BIOS irq 5
em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.16 port 0x2040-0x207f mem 
0xfeac-0xfead irq 5 at device 7.0 on pci3
em0:  Speed:N/A  Duplex:N/A
em1: Intel(R) PRO/1000 Network Connection, Version - 1.7.16 port 0x2000-0x203f mem 
0xfeae-0xfeaf irq 5 at device 7.1 on pci3
em1:  Speed:N/A  Duplex:N/A
pci0: unknown at device 3.1 (no driver attached)
uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port 0x3020-0x303f irq 5 at 
device 29.0 on pci0
usb0: Intel 82801CA/CAM (ICH3) USB controller USB-A on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1: Intel 82801CA/CAM (ICH3) USB controller 

Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Dag-Erling Smørgrav
Daniel O'Connor [EMAIL PROTECTED] writes:
 What _REAL WORLD_ task does this slow down?

I suspect 'make world' takes a serious hit.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-25 Thread Garance A Drosihn
At 10:09 AM -0600 11/25/03, Matthew D. Fuller wrote:
On Mon, Nov 24, 2003, I heard the voice of
   David O'Brien, and lo! it spake thus:
  On Mon, Nov 24, 2003, Michael Edenfield wrote:
  
   Would it be possible, through some make.conf magic, for
   the end-user to set extra programs to be put into /rescue
   that are not typically there?
  
  RESCUE_EXTRAPRGS= usr.bin/vi usr.bin/fetch

 This list could easily need things added to librescue.
If you can delay building the rescue stuff until after
everything else, you can use ldd(1) on the built binaries
for everything else and hash up the list from that.
It is a bit more complicated than that, because programs may
include embedded references to other files.  So, I think
some developer would *have* to do a little up-front work for
any program that would be optionally-added to /rescue.
Also, if you completely automate it, then a year from now
someone will make a change to 'vi' which drags in a few
extra libraries, and people will be blind-sided with a much
larger /rescue.  If someone is watching what happens, they
could #ifdef-out that extra code for the /rescue version.
I do like the idea, but to do it right *will* involve extra
work for each optional program.  I would gladly do that extra
work for any programs that I cared to have in /rescue -- but
personally I set up dual-boot systems, so I don't really care
about any of them...  :-)
--
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: NFS lockup issues xl0 timeouts

2003-11-25 Thread Matt Smith
Update on xl0 issues and NFS issues:

I unfortunatly left my realtek network card in work so I'll do this 
tomorrow night instead of tonight.

But I've now installed the absolute latest world/kernel on both server 
and client again to see if the hang has gone.

I have noticed the NFS transfer hangs at the same point always. If I cp 
mysql-4.0.16.tar.gz to /usr/src it hangs instantly and always with this 
filesize:

-rw-r--r--1 root  wheel  122880 Nov 25 18:30 mysql-4.0.16.tar.gz

Is that significant in any way?

Another test I just did is swap the roles of the client and server 
around. So I've ran a server on the client and mounted the directory on 
the server.

Doing this and NFS works perfectly writing to the server but not 
reading. It hangs whilst reading.

Left for 5 minutes so far:

-rw-r--r--   1 root  wheel  65536 Nov 25 18:39 mysql-4.0.16.tar.gz

This filesize looks significant to me. Like a buffer is full or something.

So this suggests I have a problem only in the one direction. And this is 
also the direction I have the xl0 transfer problems with. I would 
suggest my problems are totally down to the xl0 card/driver and not NFS 
related at all.

I will find this out once and for all when I test with the realtek card 
tomorrow night (when I remember to bring it home from work).

The affected card is:
[EMAIL PROTECTED]:7:0:   class=0x02 card=0x100010b7 chip=0x920010b7 rev=0x74 
hdr=0x00
vendor   = '3COM Corp, Networking Division'
device   = '3C905C-TX Fast EtherLink for PC Management NIC'
class= network
subclass = ethernet

xl0: 3Com 3c905C-TX Fast Etherlink XL port 0x1000-0x107f mem 
0xfc304800-0xfc30487f irq 10 at device 7.0 on pci5
xl0: Ethernet address: 00:04:76:8d:c5:fd
miibus0: MII bus on xl0
xlphy0: 3c905C 10/100 internal PHY on miibus0
xlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

Regards, Matt.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: [Me too]: rc scripts run double on boot?

2003-11-25 Thread Nate Lawson
On Tue, 25 Nov 2003, it was written:
 On Tuesday 25 November 2003 18:35, Nate Lawson wrote:
  With a recent -current, I've noticed double prints for the last few
  rc scripts, like this:
 
  Starting cron.
  Local package initialization:.
  Local package initialization:.
  Additional TCP options:.
  Additional TCP options:.
 
  Anyone else seeing this?

 Yes, since the last buldworld, which was quite a while ago:
 # uname -a
 FreeBSD kiste.local 5.1-CURRENT FreeBSD 5.1-CURRENT #8: Wed Oct 29
 20:49:45 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  i386

The suggested fix works for me:
  rm -rf /etc/rc.d/*
  mergemaster

Of course, make sure you don't have local changes in /etc/rc.d first.

-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: How to fix this in 5.1-REL??

2003-11-25 Thread Alexander Leidinger
On Tue, 25 Nov 2003 08:57:10 -0800
Kevin Oberman [EMAIL PROTECTED] wrote:

 Now we are moving on to V5 and 'world' is growing increasingly dangerous
 to use. Because changes are applied that will allow smooth upgrades
 when the kernel is built after the new system is built, but before it is
 installed, make world is increasingly unlikely to work.
 
 I was suggesting that it's time to eliminate this excellent path to
 foot-shooting once and for all. 

By disabling it temporarily until 5-current becomes 5-stable and such
changes are very unlikely to get applied?

Bye,
Alexander.

-- 
   Reboot America.

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: HEADS UP: /bin and /sbin are now dynamically linked

2003-11-25 Thread slave-mike
Would it be possible to get a copy of this script?

Please! :)

Matthew D. Fuller wrote:
On Mon, Nov 24, 2003 at 02:41:44PM -0800 I heard the voice of
David O'Brien, and lo! it spake thus:
On Mon, Nov 24, 2003 at 04:07:49PM -0500, Michael Edenfield wrote:

Would it be possible, through some make.conf magic, for the end-user to
set extra programs to be put into /rescue that are not typically there?
RESCUE_EXTRAPRGS= usr.bin/vi usr.bin/fetch
This list could easily need things added to librescue.


If you can delay building the rescue stuff until after everything else,
you can use ldd(1) on the built binaries for everything else and hash up
the list from that.  I do something similar in a set of scripts I have to
generate filesystems for small systems (i.e., I create a variable in a
Makefile listing all the programs, and it automatically includes all the
libraries the programs need) with a little sed/awk.



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Matthew Dillon

:IMHO, it makes more sense to write NSS modules that do their own
:proxying than to make things even more complicated in libc.  Those
:that are lightweight don't carry extra baggage; those that do can
:implement proxying in the most efficient manner for that particular
:backend, e.g. some calls can be proxyed while others done in-process.
:You don't have to rewrite existing NSS modules so that they take into
:account that they are really serving multiple processes--- which
:usually means adding credentials management, locking, per-process
:state, and so forth to each NSS module.  Or you could just create a
:whole new NSS API and call it something else and forget about support
:for existing NSS modules.
:
:Caching results (which is different than out-of-process
:implementations, the Linux nscd authors are just confused) does
:require a daemon, but this doesn't really complicate things.  (I
:should get around to that someday :-)
:
:That said, I would not stand in the way of a well-thought out,
:well-written NSS implementation that attempts to proxy every get*()
:call over e.g. RPC.  (Hmm, sounds like NIS to me.  I guess that's
:partially explains why PADL.com's NIS-LDAP gateway is popular :-)

Well, here's the issue... where do you think the future is?  I
believe the future is in large, extended clusters of machines which
either need to agree on their management resources or which need to
be capable of hierarchically accessing a global resource namespace.

Sure you can do this within the nsswitch framework, by writing 
particular NSS modules that then going out and implementing some other
proxy protocol.  But most NSS modules are not going to be written with IPC
in mind so it would be a fairly difficult and involved job to create 
an integrated framework capable of the above within NSS.  Without doing
that you would be restricted to only those modules which are directly
capable of proxying *AND* you would have to contend with various
proxy-capable modules using different protocols.  In otherwords, it's
a mess.  It seems silly to waste your time on a framework that you are
just going to have to rip out again a year or two from now.

By using an IPC mechanism from the start the framework and centralization
issues go away.  Poof, gone.  No issue.  A module written as an IPC
service doesn't know or care (other then for authentication purpopses)
who is making requests of it.   In DFly it is particularly important
because we are going for an SSI-capable result and you just can't do
that with NSS (at least not without devaluing the NSS mechanism so much
you might as well not have used it in the first place!).

The absolute worst case in an IPC framework is that the program trying 
to access service X and not being able to find it would have to fork/exec
the service binary itself to create the IPC connection.  This, of course,
would only occur under extrodinary circumstances (such as when you are
in single-user mode).  But despite the overhead we are only talking about
two lines of code, really.  fork() and exec().  Well, three... pipe(),
fork(), and exec().

In regards to caching... with an IPC mechanism the client can choose
to cache the results however it pleases.  The IPC mechanism can simply
notify the client asynchronously if a cache invalidation is required.
That's what a real messaging/port protocol gives you the ability to do.
So generaly performance using the IPC mechanism is going to be as good
or better then what we currently have with uncached flat files or uncached
databases.

Which brings up yet another cool result ... when you use an IPC mechanism
you don't need to generate DBM's.  The service process itself will simply
scan /etc/master.passwd, /etc/group, and so forth, and build its own
in-memory database.  Being able to get rid of the DBMs is only part of
the equation because it also means that files which are not otherwise
DBM's, such as /etc/services and /etc/group, enjoy the same feature.

:Um, if you can't trust the authentication code, what can you trust?
:Furthermore, for many many many applications that use getpwnam(3) and
:so on, increased privileges are not needed or wanted.
 
Think out of the box.Consider a multi-layered approach.  Take 
access to master.passwd for example.  Would you have
(A) the authentication code integrated into the potentially buggy program
be able to access the file directly or would you rather have 
(B) the authentication code access an IPC service which *ONLY* allows
challenge/response, does *NOT* give you direct access to the 
encrypted contents of the password file, and which limits the challenge
rate to prevent dictionary attacks?

That's about the best example that I can come up with.  Think about
it... the *ONLY* code that has access to the actual 

Re: Intel SE7500WV2 not working with ACPI

2003-11-25 Thread Nate Lawson
 acpi0: INTEL  SWV20on motherboard
 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_._REG] (Node 
 0xc29b4660), AE_NOT_EXIST
 acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST
 device_probe_and_attach: acpi0 attach returned 6

This is the source of the problems.  When acpi0 fails to attach,
everything else is done through the legacy PCI code.  The question is, why
is it failing?  The above-mentioned EC method could indicate the problem
is in walking the namespace but we'll have to look at the ASL to be sure.

Please send a url to the output of:
 acpidump -t -d  brooks-Intel.asl

Also, build with options ACPI_DEBUG and set these in your loader.conf:

debug.acpi.layer=ACPI_ALL_COMPONENTS
debug.acpi.level=ACPI_LV_OPREGION

-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Jacques A. Vidrine
On Tue, Nov 25, 2003 at 11:50:25AM -0800, Matthew Dillon wrote:
 Just not thinking out of the box, maybe.

Matt, I'm talking about the de facto standard NSS, as found in Solaris
and Linux; and now FreeBSD 5 [*] and soon NetBSD [**].  You are talking
about some better mousetrap.  The latter does not have any relevance
to this thread, which is about dynamic linking in next release of
FreeBSD.

If you want to talk about FreeBSD 6.x and a better mousetrap, please
go right ahead with a new thread here on freebsd-current or over on
freebsd-arch.

If you want to talk about the future of DragonFlyBSD, I'm sure there
is an appropriate list for that--- this one ain't it.  Parts of your
message certainly seemed to describe what might be best for some other
operating system.

Cheers,
-- 
Jacques Vidrine   NTT/Verio SME  FreeBSD UNIX   Heimdal
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]


Side notes:

[*] The actual APIs used by Solaris and Linux are *very* different;
and the APIs used by FreeBSD are *somewhat* different from Linux.
However, because the *core concepts* are the same--- dynamic loading,
in-process modules--- portability issues are not much of a problem.

[**] NetBSD doesn't support dynamic loading yet, but has had
considerable influence on the FreeBSD implementation.  NetBSD
developers have indicated to me that they expect to bring in
the FreeBSD changes so that there will be basically the same
implementation on FreeBSD and NetBSD.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Kris Kennaway
On Tue, Nov 25, 2003 at 07:36:45PM +0100, Dag-Erling Sm?rgrav wrote:
 Daniel O'Connor [EMAIL PROTECTED] writes:
  What _REAL WORLD_ task does this slow down?
 
 I suspect 'make world' takes a serious hit.

It does not (Warner has quoted numbers a few times now).

Kris


pgp0.pgp
Description: PGP signature


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Matthew Dillon

:Matt, I'm talking about the de facto standard NSS, as found in Solaris
:and Linux; and now FreeBSD 5 [*] and soon NetBSD [**].  You are talking
:about some better mousetrap.  The latter does not have any relevance
:to this thread, which is about dynamic linking in next release of
:FreeBSD.
:
:If you want to talk about FreeBSD 6.x and a better mousetrap, please
:go right ahead with a new thread here on freebsd-current or over on
:freebsd-arch.
:
:If you want to talk about the future of DragonFlyBSD, I'm sure there
:is an appropriate list for that--- this one ain't it.  Parts of your
:message certainly seemed to describe what might be best for some other
:operating system.
:
:Cheers,
:-- 
:Jacques Vidrine   NTT/Verio SME  FreeBSD UNIX   Heimdal
:[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
:
:
:Side notes:
:
:[*] The actual APIs used by Solaris and Linux are *very* different;
:and the APIs used by FreeBSD are *somewhat* different from Linux.
:However, because the *core concepts* are the same--- dynamic loading,
:in-process modules--- portability issues are not much of a problem.
:
:[**] NetBSD doesn't support dynamic loading yet, but has had
:considerable influence on the FreeBSD implementation.  NetBSD
:developers have indicated to me that they expect to bring in
:the FreeBSD changes so that there will be basically the same
:implementation on FreeBSD and NetBSD.

I'm not sure of the relevance of this comment.  My original opinion
still stands... you guys are using this issue as an excuse to basically
do away with static binaries, rather then fixing the real problem which
is an inability to dynamically load modules in a static binary.

How much do you intend to use NSS for?  I mean, what's the point of
adopting this cool infrastructure if all you are going to do with it
is make a better PAM out of it?  You can use it for basic authentication,
sure, but the more things you try to use it for without static binary
support the fewer things you can compile statically.  You are basically
doing away with the static linking capability of the system for no good
reason that I can see, and coming up with all sorts of extra junk,
like /rescue, to work around that fact.  You are creating a huge mess
*JUST* to be able to port a dynamic load NSS framework and you are 
throwing away functionality left and right to get it.  That's no good
in my book.  If you *REALLY* want dynamic load NSS then you ought to
spend the time to make it work with static binaries rather then just
being lazy and getting rid of static binaries.

So, yes, I do think you guys are being lazy in that regard.  If this
is the path you've chosen to go then you have an obligation not to
tear out major existing system capabilities, such as the ability to
generate static binaries, in the process.

If the APIs are totally different then I don't see any difference
between your direct NSS implementation and my ability, within an 
IPC framework, to implement NSS as a backend service.  I suppose you
can call me work building a better mousetrap, implying that I am
doing work that has already been done, but it is really no different
then what you are doing in FreeBSD-5 by changing existing API standards
to suit your particular implementation.

There is a lot of circular reasoning going on here... it's the same sort
of circular reasoning that John uses to justify some of the more esoteric
scheduling mechanisms in -current.  A because of B because of A, and
to hell with anyone who wanted to use C.

What I am doing is not reinventing the wheel, I am simply reinventing the
API that the backend of libc uses to access resources.  There is nothing
preventing me from then implementing something like NSS and PAM on the
backend of the new API, as a service rather then as a DLL.  I fully
expect that someone will do that, in fact, possibly even me.  But I also
expect that straight IPC will solve at least as many problems and
in fact solve significantly more problems then the DLL NSS solution
solves.

So, yes, IPC will be the basis used in DFly.  That does not invalidate
my comments vis-a-vie the dynamic/static problem with NSS and PAM
that FreeBSD-5 has.  If you want to do it right then make DLL's work
with static binaries.  If you want to do it wrong then ignore static
binaries.  It is that simple.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Kris Kennaway
On Tue, Nov 25, 2003 at 12:39:11PM -0800, Matthew Dillon wrote:

 So, yes, I do think you guys are being lazy in that regard.  If this
 is the path you've chosen to go then you have an obligation not to
 tear out major existing system capabilities, such as the ability to
 generate static binaries, in the process.

If this is what you think has happened, you're living in some parallel
fantasy universe.

 There is a lot of circular reasoning going on here... it's the same sort
 of circular reasoning that John uses to justify some of the more esoteric
 scheduling mechanisms in -current.  A because of B because of A, and
 to hell with anyone who wanted to use C.

Keep the ad homenim attacks to yourself, buster!  This was uncalled-for.

Kris

pgp0.pgp
Description: PGP signature


Re: [Me too]: rc scripts run double on boot?

2003-11-25 Thread Marco Wertejuk
| Of course, make sure you don't have local changes in /etc/rc.d first.

Shouldn't these be placed in /usr/local/etc/rc.d

-- 
Mit freundlichen Gruessen,
Marco Wertejuk - mwcis.com
Consulting  Internet Solutions
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


netgraph/ng_eiface double panic turnstile/sio lock order reversal in 5.2-BETA

2003-11-25 Thread Robin Breathe
I've been experiencing a repeatable panic using ng_eiface(4) on -CURRENT 
of the last few days.

Environment:
FreeBSD twiddle.local 5.2-BETA FreeBSD 5.2-BETA #0: Tue Nov 25 19:28:22 
UTC 2003 [EMAIL PROTECTED]:/home/data/work/usr/src/sys/TWIDDLE  i386

Description:
Shutting down an ng_eiface node which has a non-zero lladdr causes a panic.
How-To-Repeat:
Configure an ng_eiface(4) node, set its lladdr with ifconfig(8), shut it 
down:



# cat /tmp/ngctl
 mkpeer . eiface hook ether
 name .:hook vif0
 rmhook . hook
# ngctl -f /tmp/ngctl
# ifconfig ngeth0 link '00:bd:03:11:25:01'
# ngctl shutdown vif0:
lock order reversal
 1st 0xc0765d8c turnstile chain (turnstile chain) @ 
/usr/src/sys/kern/subr_turnstile.c:370
 2nd 0xc079a500 sio (sio) @ /usr/src/sys/dev/sio/sio.c:3203
Stack backtrace:
backtrace(c070794e,c079a500,c07502c0,c07502c0,c0719757) at backtrace+0x17
witness_lock(c079a500,8,c0719757,c83,3f8) at witness_lock+0x672
_mtx_lock_spin_flags(c079a500,0,c0719757,c83,1) at _mtx_lock_spin_flags+0xda
siocnputc(c0750440,6b,5,ddcb08b4,6b) at siocnputc+0x81
cnputc(6b,c076e780,1,c4a40500,c071d675) at cnputc+0x7a
putchar(6b,ddcb08b4,c053a72d,c076e800,1) at putchar+0x6c
kvprintf(c071d674,c0564b80,ddcb08b4,a,ddcb08d4) at kvprintf+0x8d
printf(c071d674,c,c056ced2,c078ac40,38) at printf+0x57
trap(c0760018,c0760010,c0760010,0,c4a40500) at trap+0xd7
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc056a146, esp = 0xddcb0958, ebp = 0xddcb0978 ---
turnstile_wait(0,c479b9c8,1103bd00,1cc,c479b9c8) at turnstile_wait+0x86
_mtx_lock_sleep(c479b9c8,0,c070c7ca,250,c49efe7c) at _mtx_lock_sleep+0x115
_mtx_lock_flags(c479b9c8,0,c070c7ca,250,c0538e1c) at _mtx_lock_flags+0x97
if_detach(c479b808,c4d64300,ddcb0a58,c4dbfa51,c479b808) at if_detach+0x394
ether_ifdetach(c479b808,c070d32d,820,c4d64300,c4d64300) at 
ether_ifdetach+0x30
ng_eiface_rmnode(c4d64300,0,0,c4d64300,c4d64300) at ng_eiface_rmnode+0x61
ng_rmnode(c4d64300,0,0,0,0) at ng_rmnode+0xc7
ng_generic_msg(c4d64300,c48b7780,0,c0768598,c07acfd4) at 
ng_generic_msg+0x11f
ng_apply_item(c4d64300,c48b7780,c070d32d,7d6,c48b7780) at 
ng_apply_item+0x365
ng_snd_item(c48b7780,0,c47a4360,0,0) at ng_snd_item+0x7b6
ngc_send(c4ab4780,0,c1d12800,c47a4820,0) at ngc_send+0x146
sosend(c4ab4780,c47a4820,ddcb0c4c,c1d12800,0) at sosend+0x4cd
kern_sendit(c4a40500,3,ddcb0cc4,0,0) at kern_sendit+0x17c
sendit(c4a40500,3,ddcb0cc4,0,804f034) at sendit+0x16e
sendto(c4a40500,ddcb0d14,c071d6f6,3ee,6) at sendto+0x5b
syscall(2f,2f,2f,bfbfe9c0,bfbfe9c2) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (133), eip = 0x280c58cf, esp = 0xbfbfe96c, ebp = 0xbfbfebe8 ---
kernel trap 12 with interrupts disabled

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x1103bd00
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc056a146
stack pointer   = 0x10:0xddcb0958
frame pointer   = 0x10:0xddcb0978
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 582 (ngctl)
kernel: type 12 trap, code=0
Stopped at  turnstile_wait+0x86:movl0(%edx),%eax
db panic
panic: from debugger
Debugger(panic)
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc06a9254
stack pointer   = 0x10:0xddcb0720
frame pointer   = 0x10:0xddcb072c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 582 (ngctl)
Stopped at  turnstile_wait+0x86:movl0(%edx),%eax
db where
turnstile_wait(0,c479b9c8,1103bd00,1cc,c479b9c8) at turnstile_wait+0x86
_mtx_lock_sleep(c479b9c8,0,c070c7ca,250,c49efe7c) at _mtx_lock_sleep+0x115
_mtx_lock_flags(c479b9c8,0,c070c7ca,250,c0538e1c) at _mtx_lock_flags+0x97
if_detach(c479b808,c4d64300,ddcb0a58,c4dbfa51,c479b808) at if_detach+0x394
ether_ifdetach(c479b808,c070d32d,820,c4d64300,c4d64300) at 
ether_ifdetach+0x30
ng_eiface_rmnode(c4d64300,0,0,c4d64300,c4d64300) at ng_eiface_rmnode+0x61
ng_rmnode(c4d64300,0,0,0,0) at ng_rmnode+0xc7
ng_generic_msg(c4d64300,c48b7780,0,c0768598,c07acfd4) at 
ng_generic_msg+0x11f
ng_apply_item(c4d64300,c48b7780,c070d32d,7d6,c48b7780) at 
ng_apply_item+0x365
ng_snd_item(c48b7780,0,c47a4360,0,0) at ng_snd_item+0x7b6
ngc_send(c4ab4780,0,c1d12800,c47a4820,0) at ngc_send+0x146
sosend(c4ab4780,c47a4820,ddcb0c4c,c1d12800,0) at sosend+0x4cd
kern_sendit(c4a40500,3,ddcb0cc4,0,0) at kern_sendit+0x17c
sendit(c4a40500,3,ddcb0cc4,0,804f034) at sendit+0x16e
sendto(c4a40500,ddcb0d14,c071d6f6,3ee,6) at sendto+0x5b
syscall(2f,2f,2f,bfbfe9c0,bfbfe9c2) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (133, FreeBSD ELF32, sendto), eip = 0x280c58cf, esp = 
0xbfbfe96c, ebp = 0xbfbfebe8 ---
db panic
panic: from debugger
Uptime: 2m3s
panic: 

Re: [Me too]: rc scripts run double on boot?

2003-11-25 Thread Nate Lawson
On Tue, 25 Nov 2003, Marco Wertejuk wrote:
 | Of course, make sure you don't have local changes in /etc/rc.d first.

 Shouldn't these be placed in /usr/local/etc/rc.d

Sure.  I was just being overly careful since I just suggested someone
rm -rf a directory.

-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Matthew Dillon

: is the path you've chosen to go then you have an obligation not to
: tear out major existing system capabilities, such as the ability to
: generate static binaries, in the process.
:
:If this is what you think has happened, you're living in some parallel
:fantasy universe.

I am simply repeating the reasoning being used for going to a dynamic 
root.  Forgive me if I misread it, but I believe the argument was that
FreeBSD-5 was migrating to NSS and NSS's DLL mechanism does not work
in a static world, therefore dynamic becomes the default.  If I am
wrong and NSS's DLL mechanism can be used in a static world, please
correct me!

So exactly how far do you intend to go with NSS?  Because it seems to 
me that FreeBSD-5's goal is to start to depend on the DLL capabilities.
If the goal is an intention to depend on DLL then you damn well need to
make it work with static ELF binaries.  It's that simple.

: There is a lot of circular reasoning going on here... it's the same sort
: of circular reasoning that John uses to justify some of the more esoteric
: scheduling mechanisms in -current.  A because of B because of A, and
: to hell with anyone who wanted to use C.
:
:Keep the ad homenim attacks to yourself, buster!  This was uncalled-for.
:
:Kris

Well, the scheduler arguments are more involved but I am not incorrect
here.  E.G. the priority borrowing exists to work around problems with
the mutex implementation.  Preemption by non-interrupts threads also
exists to work around problems with the mutex implementation.  Preemptive
cpu migration could be turned off fairly easily and doesn't really count.
The priority borrowing is a mess, though.  You may think its the best
thing since sliced bread but I think it unnecessarily complicates both
the scheduler core and the programming model.

-Matt

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: pcm(4) related panic

2003-11-25 Thread Artur Poplawski
Artur Poplawski [EMAIL PROTECTED] wrote:

 Hello,  
 
 On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic 
 like this:
  
 (watch out for folded lines; the stack backtrace below is rewritten by
 hand from ddb)
 
 lock order reversal
  1st 0xc22a45ac vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323
  2nd 0xc06c0420 swap_pager swhash (swap_pager swhash) @ \
 /usr/src/sys/vm/swap_pager.c:1838
  3rd 0xc0c358c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876
 Stack backtrace:
   backtrace
   witness_lock
   _mtx_lock_flags
   obj_allock
   slab_zalloc
   uma_zone_slab
   uma_zalloc_internal
   uma_zalloc_arg
   swp_pager_meta_build
   swap_pager_putpages
   default_pager_putpages
   vm_pageout_flush
   vm_pageout_clean
   vm_pageout_scan
   vm_pageout
   fork_exit
   fork_trampoline
 
 Sleeping on swread with the following non-sleepable locks held:
 exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \   
 /usr/src/sys/dev/sound/pcm/dsp.c:146
 panic: sleeping thread (pid 583) owns a non-sleepable lock
 syncing disks, buffers remaining... 1410 1410 panic: mi_switch: \ 
 switch in a critical section
 Uptime: 1m45s
 panic: msleep
 Uptime: 1m45s
 panic: msleep
 Uptime: 1m45s
 panic: msleep
 Uptime: 1m45s
 panic: msleep
 [... repeated few more times]
 Fatal double fault:
 eip = 0xc05e3916
 esp = 0xc8db8ff4
 ebp = 0xc8db9004
 panic: double fault
 Uptime: 1m45s
 panic: msleep
 Uptime: 1m45s 
 panic: msleep
 Uptime: 1m45s
 panic: msleep
 Uptime: 1m45s
 [...]
 And the machine suddenly reboots, so there is no coredump.
  
 eip address points close to:
 c05e3910 T sc_vtb_putc
  
 To reproduce this panic just start some audio player app (like xmms), 
 and launch countless memory-eating applications (like mozilla ;).
 The machine starts swapping, and it panics. 
 
 % uname -a 
 FreeBSD kaszanka.domek 5.2-BETA FreeBSD 5.2-BETA #0: Sun Nov 23 01:23:10\ 
  CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KASZANKA i386 
 
 dmesg fragments:
 CPU: AMD Athlon(tm) XP 2000+ (1666.73-MHz 686-class CPU)
 pcm0: AudioPCI ES1373-B port 0xec00-0xec3f irq 10 at device 8.0 on pci0 
 pcm0: Cirrus Logic CS4297A AC97 Codec
 rl0: RealTek 8139 10/100BaseTX port 0xe800-0xe8ff mem \
  0xdf00-0xdfff ir
 q 10 at device 10.0 on pci0
 miibus0: MII bus on rl0
 rlphy0: RealTek internal media interface on miibus0
 rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 rl1: RealTek 8139 10/100BaseTX port 0xe400-0xe4ff mem \
  0xde00-0xdeff ir
 q 10 at device 11.0 on pci0
 rlphy1: RealTek internal media interface on miibus1
 rlphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto



In the meantime I've managed to get a coredump, by directly calling
doadump() from ddb. Results:


[EMAIL PROTECTED]:/usr/obj/usr/src/sys/KASZANKA# gdb -k kernel.debug 
/var/crash/vmcore.0
GNU gdb 5.2.1 (FreeBSD)  
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: sleeping thread (pid 568) owns a non-sleepable lock
panic messages:
---
panic: sleeping thread (pid 568) owns a non-sleepable lock

syncing disks, buffers remaining... panic: msleep
Dumping 128 MB
 16 32 48 64 80 96 112
---
Reading symbols from 
/usr/obj/usr/src/sys/KASZANKA/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done.
Loaded symbols for 
/usr/obj/usr/src/sys/KASZANKA/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug
Reading symbols from 
/usr/obj/usr/src/sys/KASZANKA/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for 
/usr/obj/usr/src/sys/KASZANKA/modules/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols from /boot/kernel/netgraph.ko...done.
Loaded symbols for /boot/kernel/netgraph.ko
Reading symbols from /boot/kernel/ng_ether.ko...done.
Loaded symbols for /boot/kernel/ng_ether.ko
Reading symbols from /boot/kernel/ng_pppoe.ko...done.
Loaded symbols for /boot/kernel/ng_pppoe.ko
Reading symbols from /boot/kernel/ng_socket.ko...done.
Loaded symbols for /boot/kernel/ng_socket.ko
Reading symbols from /boot/kernel/mga.ko...done.
Loaded symbols for /boot/kernel/mga.ko
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc04292cd in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0xc8dba7bc à×hÀ) 
at /usr/src/sys/ddb/db_command.c:548
#2  0xc042906a in db_command 

Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY

2003-11-25 Thread Jacques A. Vidrine
On Tue, Nov 25, 2003 at 04:46:24PM +0200, Enache Adrian wrote:
 On Mon, Nov 24, 2003 a.d., Jacques A. Vidrine wrote:
  The application is broken.  You must only check errno if you get an
  error indication from the library call.
 
 Sorry, but I don't see your point. I know when to check for errno.
 If you took the little illustrating program for a real life example of
 the use of errno, that's unfortunate :-)
 
 The problem is that the emulated/wrapped close from libc_r does not
 behave like the real one. libc_r is leaking some of its guts
 (the tricks it's doing with O_NONBLOCK, etc) in the interface.
 This is technically a bug. The fix was trivial.

Hello Enache,

My point was that this is not technically a bug.  According to
IEEE Std 1003.1-2001 aka the Single Unix Specification Version 3
(``SUSv3'') aka POSIX, an application must not examine and interpret
`errno' unless the library gives an error indication.

There are some functions--- strtol and family, sysconf, others---
that have unusual, errno-preserving behavior.  These are described
individually in the appropriate section of the standard.  For these
and only these, you can set errno to 0 and check it immediately after
the function call to see whether an error has occurred.  I believe
that includes all functions described in ISO/IEC 9899:1999 (``C99''),
as well as some described only in SUSv3. `close' is not a part of
C99, nor is it attributed the `unusual', errno-preserving behavior in
SUSv3.

(By the way, this exact topic was discuss at some length by the the
Austin Common Standards Revision Group this past summer.)

Cheers,
-- 
Jacques Vidrine   NTT/Verio SME  FreeBSD UNIX   Heimdal
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: PII SMP system hangs during boot with ACPI enabled

2003-11-25 Thread John Polstra
On 24-Nov-2003 Nate Lawson wrote:
 
 Please also send the output of acpidump -t -d  jdp-P2.asl

I booted the 5.1R live CD in an attempt to get this output.  I
discovered that the machine hangs the same way with 5.1R as it does
with -current.  (When I originally installed 5.1R, the machine had
an older, non-ACPI BIOS.)

I've attached the verbose boot messages from 5.1R, in case that's
worth anything.  Such a shame -- it gets within a hair's breadth of
running init, but it just can't quite make it all the way there.

John
SMAP type=01 base= len=0009fc00
SMAP type=02 base=0009fc00 len=0400
SMAP type=02 base=000e len=0002
SMAP type=01 base=0010 len=0fee
SMAP type=03 base=0ffe len=00018000
SMAP type=04 base=0fff8000 len=8000
SMAP type=02 base=fec0 len=1000
SMAP type=02 base=fee0 len=1000
SMAP type=02 base=fffc len=0004
Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-RELEASE #0: Mon Jun  9 19:20:51 GMT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Preloaded elf kernel /boot/kernel/kernel at 0xc0b0c000.
Preloaded mfs_root /boot/mfsroot at 0xc0b0c250.
Preloaded elf module /boot/kernel/acpi.ko at 0xc0b0c294.
Calibrating clock(s) ... i8254 clock: 1193040 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter i8254  frequency 1193182 Hz
Calibrating TSC clock ... TSC clock: 400910451 Hz
Timecounter TSC  frequency 400910451 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x652  Stepping = 2
  Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM
OV,PAT,PSE36,MMX,FXSR
real memory  = 268304384 (255 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x00b33000 - 0x0fb39fff, 251686912 bytes (61447 pages)
avail memory = 248926208 (237 MB)
bios32: Found BIOS32 Service Directory header at 0xc00fdb40
bios32: Entry = 0xfdb50 (c00fdb50)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0xdb71
pnpbios: Found PnP BIOS data at 0xc00f72c0
pnpbios: Entry = f:6964  Rev = 1.0
Other BIOS signatures found:
wlan: 802.11 Link Layer
null: null device, zero device
random: entropy source
mem: memory  I/O
Pentium Pro MTRR support enabled
md0: Preloaded image /boot/mfsroot 4423680 bytes at 0xc06877a4
npx0: math processor on motherboard
npx0: INT 16 interface
acpi0: TYANCP TYANTBLE on motherboard
ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.SBRG.PS2M._STA] (N
ode 0xc12a11a0), AE_AML_REGION_LIMIT
ACPI-0175: *** Error: Method execution failed [\_SB_.PCI0.SBRG.PS2M._STA] (N
ode 0xc12a11a0), AE_AML_REGION_LIMIT
pci_open(1):mode 1 addr port (0x0cf8) is 0x805c
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=71908086)
pcibios: BIOS version 2.10
AcpiOsDerivePciId: bus 0 dev 7 func 0
acpi0: power button is handled as a fixed feature programming model.
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 5, width = 3
ACPI timer looks BAD  min = 2, max = 5, width = 3
Timecounter ACPI-safe  frequency 3579545 Hz
AcpiOsDerivePciId: bus 0 dev 0 func 0
AcpiOsDerivePciId: bus 0 dev 0 func 0
AcpiOsDerivePciId: bus 0 dev 7 func 0
ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.SBRG.PS2M._STA] (N
ode 0xc12a11a0), AE_AML_REGION_LIMIT
ACPI-0175: *** Error: Method execution failed [\_SB_.PCI0.SBRG.PS2M._STA] (N
ode 0xc12a11a0), AE_AML_REGION_LIMIT
acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
acpi_cpu0: CPU on acpi0
acpi_cpu1: CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 initial configuration 
\_SB_.LNKA irq  10: [  3  4  5  6  7  9 10 11 12 14 15]  0.1.0
\_SB_.LNKB irq   9: [  3  4  5  6  7  9 10 11 12 14 15]  0.1.1
\_SB_.LNKD irq  11: [  3  4  5  6  7  9 10 11 12 14 15]  0.7.3
\_SB_.LNKA irq  10: [  3  4  5  6  7  9 10 11 12 14 15]  0.19.0
\_SB_.LNKB irq   9: [  3  4  5  6  7  9 10 11 12 14 15]  0.19.1
\_SB_.LNKC irq   0: [  3  4  5  6  7  9 10 11 12 14 15]  0.19.2
\_SB_.LNKD irq  11: [  3  4  5  6  7  9 10 11 12 14 15]  0.19.3
\_SB_.LNKB irq   9: [  3  4  5  6  7  9 10 11 12 14 15]  0.20.0
\_SB_.LNKC irq   0: [  3  4  5  6  7  9 10 11 12 14 15]  0.20.1
\_SB_.LNKD irq  11: [  3  4 

Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Jacques A. Vidrine
On Tue, Nov 25, 2003 at 12:39:11PM -0800, Matthew Dillon wrote:
 My original opinion
 still stands... you guys are using this issue as an excuse to basically
 do away with static binaries, rather then fixing the real problem which
 is an inability to dynamically load modules in a static binary.

No, it is one of the issues that have been pushing FreeBSD (and most
other modern UNIX systems, it seems) towards more dynamically linked
components.  The other issues have also been discussed on this list
recently and in the pass.  I'm not sure why this one draws such
interest.  (I participate in this thread only because I feel like I
know a thing or two about the NSS details.)

Cheers,
-- 
Jacques Vidrine   NTT/Verio SME  FreeBSD UNIX   Heimdal
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Kris Kennaway
On Tue, Nov 25, 2003 at 01:15:58PM -0800, Matthew Dillon wrote:
 
 : is the path you've chosen to go then you have an obligation not to
 : tear out major existing system capabilities, such as the ability to
 : generate static binaries, in the process.
 :
 :If this is what you think has happened, you're living in some parallel
 :fantasy universe.
 
 I am simply repeating the reasoning being used for going to a dynamic 
 root.  Forgive me if I misread it, but I believe the argument was that
 FreeBSD-5 was migrating to NSS and NSS's DLL mechanism does not work
 in a static world, therefore dynamic becomes the default.  If I am
 wrong and NSS's DLL mechanism can be used in a static world, please
 correct me!

No, what you said was not to tear out..the ability to generate static
binaries.  That's completely different, and is absolutely not what
has happened, or what is planned.  Static binaries continue to be
supported, available, and work with the system NSS and PAM modules as
before.

 : There is a lot of circular reasoning going on here... it's the same sort
 : of circular reasoning that John uses to justify some of the more esoteric
 : scheduling mechanisms in -current.  A because of B because of A, and
 : to hell with anyone who wanted to use C.
 :
 :Keep the ad homenim attacks to yourself, buster!  This was uncalled-for.
 :
 :Kris
 
 Well, the scheduler arguments are more involved but I am not incorrect
 here.

We're not talking about schedulers.  What is at issue is that you
decided, for no reason appropriate to the topic of discussion, to
mention that you think an unrelated FreeBSD developer has difficulties
with logical reasoning.

What the hell, Matt?  By what standards of behaviour is this
acceptable?

We have rules of conduct on the FreeBSD mailing lists, and people have
been removed in the past because they were unable to hold themselves
to them.  Don't think that you're exempt just because you're Matt
Dillon.

  
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL

  Personal attacks and profanity (in the context of an argument) are
  not allowed, and that includes users and developers alike. Gross
  breaches of netiquette, like excerpting or reposting private mail when
  permission to do so was not and would not be forthcoming, are frowned
  upon but not specifically enforced. However, there are also very few
  cases where such content would fit within the charter of a list and it
  would therefore probably rate a warning (or ban) on that basis alone.

Kris



pgp0.pgp
Description: PGP signature


Re: pcm(4) related panic

2003-11-25 Thread Don Lewis
On 25 Nov, Artur Poplawski wrote:
 Artur Poplawski [EMAIL PROTECTED] wrote:
 
 Hello,  
 
 On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic 
 like this:

 Sleeping on swread with the following non-sleepable locks held:
 exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \   
 /usr/src/sys/dev/sound/pcm/dsp.c:146

This enables the panic.

 panic: sleeping thread (pid 583) owns a non-sleepable lock

Then the panic happens when another thread tries to grab the mutex.


The problem is that the pcm code attempts to hold a mutex across a call
to uiomove(), which can sleep if the userland buffer that it is trying
to access is paged out.  Either the buffer has to be pre-wired before
calling getchns(), or the mutex has to be dropped around the call to
uiomove().  The amount of memory to be wired should be limited to
'sz' as calculated by chn_read() and chn_write(), which complicates the
logic.  Dropping the mutex probably has other issues.


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: pcm(4) related panic

2003-11-25 Thread Don Lewis
On 25 Nov, Don Lewis wrote:
 On 25 Nov, Artur Poplawski wrote:
 Artur Poplawski [EMAIL PROTECTED] wrote:
 
 Hello,  
 
 On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic 
 like this:
 
 Sleeping on swread with the following non-sleepable locks held:
 exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \   
 /usr/src/sys/dev/sound/pcm/dsp.c:146
 
 This enables the panic.
 
 panic: sleeping thread (pid 583) owns a non-sleepable lock
 
 Then the panic happens when another thread tries to grab the mutex.
 
 
 The problem is that the pcm code attempts to hold a mutex across a call
 to uiomove(), which can sleep if the userland buffer that it is trying
 to access is paged out.  Either the buffer has to be pre-wired before
 calling getchns(), or the mutex has to be dropped around the call to
 uiomove().  The amount of memory to be wired should be limited to
 'sz' as calculated by chn_read() and chn_write(), which complicates the
 logic.  Dropping the mutex probably has other issues.

Following up to myself ...

It might be safe to drop the mutex for the uiomove() call if the code
set flags to enforce a limit of one reader and one writer at a time to
keep the code from being re-entered.  The buffer pointer manipulations
in sndbuf_dispose() and sndbuf_acquire() would probably still have to be
protected by the mutex.  If this can be made to work, it would probably
be preferable to wiring the buffer.  It would have a lot less CPU
overhead, and would work better with large buffers, which could still be
allowed to page normally.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Matthew Dillon

:No, what you said was not to tear out..the ability to generate static
:binaries.  That's completely different, and is absolutely not what
:has happened, or what is planned.  Static binaries continue to be
:supported, available, and work with the system NSS and PAM modules as
:before.

I think you are missing the point I made in that response, because
it isn't that cut and dry.  Obviously isn't that cut and dry.  Why
is a dynamic root the default again?  Because statically linking NSS
and PAM is not the direction FreeBSD-5 is going.  So if you are going
to start depending on dynamic loading, and I seem to recall a number
of conversations where that is, in fact, the intention, then you
are marginalizing your static binary support.  The more you use NSS
and operate on the assumption that DLL will be leveraged,
the more you marginalize your static binary support.  FreeBSD-5
has *ALREADY* made major concessions, such as going to the dynamic
root, precisely because it has *ALREADY* marginalized static binary
support.  That is what I'm hearing.

What I am saying is that for something this fundamental to the
infrastructure, it is not appropriate to marginalize static binary support.
That is all I am saying here.  Sure, I think an IPC mechanism is a better
API, but that has nothing at all to do with this DLL / static/dyanmic
binary issue in FreeBSD-5.  They are two separate issues.  Right now,
in FreeBSD-5, the issue is the marginalized static binary support.

:We're not talking about schedulers.  What is at issue is that you
:decided, for no reason appropriate to the topic of discussion, to
:mention that you think an unrelated FreeBSD developer has difficulties
:with logical reasoning.
:
:What the hell, Matt?  By what standards of behaviour is this
:acceptable?
:
:We have rules of conduct on the FreeBSD mailing lists, and people have
:been removed in the past because they were unable to hold themselves
:to them.  Don't think that you're exempt just because you're Matt
:Dillon.

Yes, and apparently you are breaking them as much as you believe I am,
Kris.  You are also seriously misinterpreted my postings.  I am obviously
not advocating that FreeBSD-5 rip everything out and move to an IPC
model.  It takes time and consideration to be able to do something like
that.   What I am advocating is that FreeBSD-5 not marginalize and
restrict (make less flexible) basic infrastructure in order to get other
infrastructure working.

-Matt
Matthew Dillon 
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Intel SE7500WV2 not working with ACPI

2003-11-25 Thread Brooks Davis
On Tue, Nov 25, 2003 at 12:12:16PM -0800, Nate Lawson wrote:
  acpi0: INTEL  SWV20on motherboard
  ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_._REG] 
  (Node 0xc29b4660), AE_NOT_EXIST
  acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST
  device_probe_and_attach: acpi0 attach returned 6
 
 This is the source of the problems.  When acpi0 fails to attach,
 everything else is done through the legacy PCI code.  The question is, why
 is it failing?  The above-mentioned EC method could indicate the problem
 is in walking the namespace but we'll have to look at the ASL to be sure.
 
 Please send a url to the output of:
  acpidump -t -d  brooks-Intel.asl

http://people.freebsd.org/~brooks/debug/brooks-Intel.asl

 Also, build with options ACPI_DEBUG and set these in your loader.conf:
 
 debug.acpi.layer=ACPI_ALL_COMPONENTS
 debug.acpi.level=ACPI_LV_OPREGION

There's a new dmesg with this done at:

http://people.freebsd.org/~brooks/debug/dmesg-brooks-Intel

Thanks,
Brooks

-- 
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4


pgp0.pgp
Description: PGP signature


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Brad Knowles
At 11:50 AM -0800 2003/11/25, Matthew Dillon wrote:

 ... Or you can build an IPC mechanism that implements the PAM
 functionality and then have programs which would otherwise use PAM
 instead use the IPC mechanism.  Which is the whole point of having
 the IPC mechanism in the first place.
	That all sounds wonderful!

	So, when are you going to deliver this fully functioning and 
debugged code for inclusion in FreeBSD-5.2?

--
Brad Knowles, [EMAIL PROTECTED]
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: How many bikesheds can _you_ build on a pin head ?

2003-11-25 Thread Andrew P. Lentvorski, Jr.
On Tue, 25 Nov 2003, Poul-Henning Kamp wrote:

 I have for myself recently taken a break from all active FreeBSD
 development because I find the environment about as pleasant as a
 kindergarten right before lunch.

Does this mean GEOM has been orphaned?  Who now has the mantle for it
then?

-a
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: How to fix this in 5.1-REL??

2003-11-25 Thread walt
Kevin Oberman wrote:

...Because changes are applied that will allow smooth upgrades
when the kernel is built after the new system is built, but before it is
installed, make world is increasingly unlikely to work...
The recent statfs changes demonstrated why the 'makeworld'  'makekernel'
sequence sometimes fails  :-(
But I'm still very fuzzy on why the 'makekernel'  'makeworld' sequence
is not recommended in FreeBSD the way it is, for example, in OpenBSD.
What does 'buildworld' give us that the new kernel might need?  Just a
simple example would help me more than anything.
Thanks.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: How to fix this in 5.1-REL??

2003-11-25 Thread Brooks Davis
On Tue, Nov 25, 2003 at 03:35:54PM -0800, walt wrote:
 Kevin Oberman wrote:
 
 ...Because changes are applied that will allow smooth upgrades
 when the kernel is built after the new system is built, but before it is
 installed, make world is increasingly unlikely to work...
 
 The recent statfs changes demonstrated why the 'makeworld'  'makekernel'
 sequence sometimes fails  :-(
 
 But I'm still very fuzzy on why the 'makekernel'  'makeworld' sequence
 is not recommended in FreeBSD the way it is, for example, in OpenBSD.
 
 What does 'buildworld' give us that the new kernel might need?  Just a
 simple example would help me more than anything.

The correct toolchain including the compiler and config(8).

-- Brooks

-- 
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4


pgp0.pgp
Description: PGP signature


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Garance A Drosihn
At 11:27 PM +0100 11/25/03, Brad Knowles wrote:
At 11:50 AM -0800 2003/11/25, Matthew Dillon wrote:

 ... Or you can build an IPC mechanism that implements
 the PAM functionality and then have programs which
 would otherwise use PAM instead use the IPC mechanism.
 Which is the whole point of having the IPC mechanism
 in the first place.
	That all sounds wonderful!

So, when are you going to deliver this fully functioning
and debugged code for inclusion in FreeBSD-5.2?
My guess is that he will deliver it to DragonFly BSD, and it
will then be up to someone with FreeBSD commit privs to look
at steal^h^h^h^h^h^h adapting it for our purposes...
Note that we are already in the code-freeze for 5.2-release,
so I will estimate the probability that all this happens in
time for this release is zero.  Absolute zero.  What might
happen for 5.3-release is a different story, of course.
--
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: requesting vinum help

2003-11-25 Thread Greg 'groggy' Lehey
On Tuesday, 25 November 2003 at 10:48:44 -0600, Eric Anderson wrote:

 Could a vinum guru please contact me via email?

 I've lost 2 vinum volumes as a result of the latest fiasco and naturally
 am eager to figure out what's going on and recover the data.

 This isn't necessarily directed at you - I'm just using this email as a
 footstep to send this general comment -

 I am kind of under the assumption that -current is more of a test bed,
 and anything can happen at any time, which is why it's bad to run
 -current on a machine you care deeply about (at least its data).  

Correct.  More to the point, though, it requires you to rely more on
yourself.  At the very least, this means RTFM, which in this case
includes a number of things to submit if you have problems.  It's at
the end of vinum(4) or at
http://www.vinumvm.org/vinum/how-to-debug.html.

Greg
--
See complete headers for address and phone numbers.


pgp0.pgp
Description: PGP signature


Re: 40% slowdown with dynamic /bin/sh

2003-11-25 Thread Brad Knowles
At 2:48 PM -0800 2003/11/25, Matthew Dillon wrote:

 What I am advocating is that FreeBSD-5 not marginalize and
 restrict (make less flexible) basic infrastructure in order to get other
 infrastructure working.
	If you've got working, debugged code that works in the manner you 
are espousing, and still achieves the same goal of making NSS and PAM 
work everywhere, I'm sure we'd all love to see it.

	In the absence of any code contribution to the contrary, I see no 
alternative than the method that has been selected.  Sure, it's not 
great.  Sure, it's slower (more or less, depending on which 
benchmarks you believe).

	But it is the best implementation that was available, and this is 
-CURRENT, where things are expected to periodically be in a state of 
flux while major changes are underway.

--
Brad Knowles, [EMAIL PROTECTED]
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re[2]: requesting vinum help

2003-11-25 Thread Max Laier
 Could a vinum guru please contact me via email?

 I've lost 2 vinum volumes as a result of the latest fiasco and naturally
 am eager to figure out what's going on and recover the data.

EA This isn't necessarily directed at you - I'm just using this email as a
EA footstep to send this general comment -

EA I am kind of under the assumption that -current is more of a test bed,
EA and anything can happen at any time, which is why it's bad to run 
EA -current on a machine you care deeply about (at least its data).  I
EA think I've seen at least 5 mails in the past few weeks about people
EA getting jammed into a corner with (what sounds like) production type
EA boxes, or at least important boxes (or they wouldn't need a vinum?)

There is the point! If no-one would ever take the risk of running
-current on a bigger, more important box no-one would have the
capabilities to test vinum and other large scale stuff in realistic
environments. No my suggestion is to help those (brave) guys rather
than screaming: Fool, don't you know it's -current!?

The not so good point about the original request is that he is looking
for private assistance, while the problem and - even more - the
solution of it might be very interesting to all of us (more than much
of the other ongoing threads, for sure).

EA .. It seems odd to me that they wouldn't give it a whirl first
EA before  attempting to use it on a box they seem so protective of.

EA Anyway, I'm just stating that running -current is for testing and 
EA developing, not really for production - at least I'm fairly certain.

There's the magic keyword again: testing! Who should do it if not guys
like him? If vinum had crossed my way before, I'd try to help - sorry.

-- 
Best regards,
 Maxmailto:[EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: memory allocation issue loading a kernel module

2003-11-25 Thread Daniel O'Connor
On Tuesday 25 November 2003 18:43, Maxime Henrion wrote:
 If I remember correctly, Alan Cox intended to write a binary buddy
 allocator to handle the physical address space (or do coalescing another
 way, I'm not sure...) so that this particular problem is solved.

Another way to solve it is the bktr approach which has a KLD that just 
reserves some memory early on (ie you load it in the loader). This means that 
when you test your module the memory chunk stays around no matter how often 
you reload.

You could get more RAM too 8-)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
  -- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140  AE4B 319B 41F4 5D17 FDD5

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: memory allocation issue loading a kernel module

2003-11-25 Thread Sean McNeil
Perfect!! This is exactly the thing I need.  I will investigate.  Memory
is an option, but this project is pretty much done.  Knowing how to do
the bktr approach is something worth the excercise.

More RAM won't teach me anything new ;-)

Sean

On Tue, 2003-11-25 at 16:09, Daniel O'Connor wrote:
 On Tuesday 25 November 2003 18:43, Maxime Henrion wrote:
  If I remember correctly, Alan Cox intended to write a binary buddy
  allocator to handle the physical address space (or do coalescing another
  way, I'm not sure...) so that this particular problem is solved.
 
 Another way to solve it is the bktr approach which has a KLD that just 
 reserves some memory early on (ie you load it in the loader). This means that 
 when you test your module the memory chunk stays around no matter how often 
 you reload.
 
 You could get more RAM too 8-)

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Sound stop'd working after upgrade ...

2003-11-25 Thread Marc G. Fournier

I upgraded my machine shortly after those changes with statfs ... upgrade
went well, but sound stop'd working ... the device is being detected:

pcm0: Intel ICH4 (82801DB) port 0xe400-0xe43f,0xe000-0xe0ff mem 
0xe0102000-0xe01020ff,0xe0101000-0xe01011ff irq 17 at device 31.5 on pci0
pcm0: Avance Logic ALC650 AC97 Codec

and, from what I can tell, the proper devices are being built in /dev, but
try and play music using xmms, and I get nothing ...

Not sure what to debug, or where ... help? :(

Thanks ...



Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]   Yahoo!: yscrappy  ICQ: 7615664
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Unfortunate dynamic linking for everything

2003-11-25 Thread Tim Kientzle
Tony Finch wrote:
Matthew D. Fuller [EMAIL PROTECTED] wrote:

Not just the startup scripts, but ANY script.  I dare say there's a long,
long list of scripts that use ~-expansion, to say nothing of the
homegrown ones we all have working quietly and forgotten for years.


It's required for POSIX compliance.

Tony.
Ouch!  Very good point, Tony.

Does POSIX require that such expansion work for
usernames that may not be in the current passwd
file?
That could dictate a lot.

Tim Kientzle

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


5.2-BETA root mount failure

2003-11-25 Thread Jeroen Hogeveen
Gents,

(Firsthand I sorry if this E-Mail is sent twice to the list, got client
rejected from mx1.)

I'm having difficulties trying out the 5.2-BETA, preparing for the 
release. I would greatly appreciate it if anyone has some time at hand to 
help (re)solve a problem that occures with my 5.2-BETA kernel (26 nov
2003).

The situation is the following: I have tried to upgrade a system
(http://www.msi.com.tw/program/products/server/svr/pro_svr_detail.php?UID=376)
from 5.1-RELEASE to 5.2-BETA, according to the src/UPDATING text (I did
add the COMPAT_FREEBSD4 option to my kernel config).

buildworld went fine and so did buildkernel. After doing a installkernel
and booting with the newly installed 5.2-BETA kernel (single-user), I
get the following message before I get thrown in the mount root 
prompt:

mounting root from ufs:/dev/ar0s1a
setrootbyname failed
ffs_mountroot: can't find rootvp
Root mount failed: 6

mount root

Did I miss a step or have I hit something in -current?


Below is my dmesg output (working 5.1) :

Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-RELEASE #0: Tue Nov 25 09:49:42 GMT 2003
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/CURRENT
Preloaded elf kernel /boot/kernel/kernel at 0xc0381000.
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 2391148112 Hz
CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2391.15-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf27  Stepping = 7

Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
real memory  = 1073676288 (1023 MB)
avail memory = 1039364096 (991 MB)
pnpbios: Bad PnP BIOS data checksum
Pentium Pro MTRR support enabled
acpi0: IntelR AWRDACPI on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 10 entries at 0xc00fdec0
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-fast  frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
acpi_cpu0: CPU on acpi0
acpi_cpu1: CPU on acpi0
acpi_tz0: thermal zone on acpi0
acpi_button0: Power Button on acpi0
acpi_button1: Sleep Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0
pci2: ACPI PCI bus on pcib2
em0: Intel(R) PRO/1000 Network Connection, Version - 1.5.31 port 
0xb000-0xb03f mem 0xe200-0xe201 irq 12 at device 5.0 on pci2
em0:  Speed:10 Mbps  Duplex:Half
fxp0: Intel 82557/8/9 EtherExpress Pro/100(B) Ethernet port 
0xb400-0xb43f mem 0xe202-0xe203,0xe2044000-0xe2044fff irq 10 at 
device 6.0 on pci2
fxp0: Ethernet address 00:0c:76:15:19:c5
miibus0: MII bus on fxp0
inphy0: i82555 10/100 media interface on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pci2: display, VGA at device 7.0 (no driver attached)
atapci0: Promise PDC20276 UDMA133 controller port 
0xcc00-0xcc0f,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xbc00-0xbc07 mem 
0xe204-0xe2043fff irq 11 at device 10.0 on pci2
ata2: at 0xbc00 on atapci0
ata3: at 0xc400 on atapci0
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci1: Intel ICH4 UDMA100 controller port 
0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci1
ata1: at 0x170 irq 15 on atapci1
pci0: serial bus, SMBus at device 31.3 (no driver attached)
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
npx0: math processor on motherboard
npx0: INT 16 interface
orm0: Option ROMs at iomem 0xc8000-0xd07ff,0xc-0xc7fff on isa0
pmtimer0 on isa0
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0
Timecounters tick every 10.000 msec
IP Filter: v3.4.31 initialized.  Default = pass all, Logging = enabled
acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0%
ad4: 117800MB IC35L120AVV207-1 [239340/16/63] at ata2-master UDMA100
ad6: 117800MB IC35L120AVV207-1 [239340/16/63] at ata3-master UDMA100
ar0: 117301MB ATA RAID1 array [14953/255/63] status: READY subdisks:
 disk0 READY on ad4 at ata2-master
 disk1 READY on ad6 at ata3-master
Opened disk ad4 - 1
Opened disk ad6 - 1
Opened disk ad6 - 1
Mounting root from ufs:/dev/ar0s1a


%atacontrol list
ATA channel 0:
Master:  no device present
Slave:   no device present
ATA channel 1:
Master:  SR244W/T01A ATA/ATAPI rev 0
Slave:   no device present
ATA channel 2:
Master:  ad4 

lock order reversal

2003-11-25 Thread John
i was just looking through my daily reports from my new 5.2 beta box and 
found this in dmesg.
lock order reversal
 1st 0xc08f7ce0 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201
 2nd 0xc1031100 system map (system map) @ /usr/src/sys/vm/vm_map.c:2210
Stack backtrace:
lock order reversal
 1st 0xc214c948 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323
 2nd 0xc08f7160 swap_pager swhash (swap_pager swhash) @ 
/usr/src/sys/vm/swap_pager.c:1838
 3rd 0xc10358c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876
Stack backtrace:


I went back through /var/log/messages and found more, looks like it started
around nov12
This box isn't really being used for much. It was a test box for mysql 4.0.15
and is a nfs server (no rpc.lockd running)

Nov 12 01:36:40 nfs kernel: lock order reversal
Nov 12 01:36:40 nfs kernel: 1st 0xc211f818 vm object (vm object) @ 
/usr/src/sys/vm/swap_pager.c:1323
Nov 12 01:36:40 nfs kernel: 2nd 0xc08ed180 swap_pager swhash (swap_pager swhash) @ 
/usr/src/sys/vm/swap_pager.c:1838
Nov 12 01:36:40 nfs kernel: 3rd 0xc103440c vm object (vm object) @ 
/usr/src/sys/vm/uma_core.c:876
Nov 12 01:36:40 nfs kernel: Stack backtrace:

Nov 23 21:48:19 nfs kernel: lock order reversal
Nov 23 21:48:19 nfs kernel: 1st 0xc08f7ce0 UMA lock (UMA lock) @ 
/usr/src/sys/vm/uma_core.c:1201
Nov 23 21:48:19 nfs kernel: 2nd 0xc1031100 system map (system map) @ 
/usr/src/sys/vm/vm_map.c:2210
Nov 23 21:48:19 nfs kernel: Stack backtrace:
Nov 23 21:51:19 nfs kernel: lock order reversal
Nov 23 21:51:19 nfs kernel: 1st 0xc2154294 vm object (vm object) @ 
/usr/src/sys/vm/swap_pager.c:1323
Nov 23 21:51:19 nfs kernel: 2nd 0xc08f7160 swap_pager swhash (swap_pager swhash) @ 
/usr/src/sys/vm/swap_pager.c:1838
Nov 23 21:51:19 nfs kernel: 3rd 0xc10358c4 vm object (vm object) @ 
/usr/src/sys/vm/uma_core.c:876
Nov 23 21:51:19 nfs kernel: Stack backtrace:
Nov 24 03:03:52 nfs kernel: lock order reversal
Nov 24 03:03:52 nfs kernel: 1st 0xc08f7ce0 UMA lock (UMA lock) @ 
/usr/src/sys/vm/uma_core.c:1201
Nov 24 03:03:52 nfs kernel: 2nd 0xc1031100 system map (system map) @ 
/usr/src/sys/vm/vm_map.c:2210
Nov 24 03:03:52 nfs kernel: Stack backtrace:

here is my whole dmesg. 

Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.2-BETA #0: Sun Nov 23 19:35:06 CST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Preloaded elf kernel /boot/kernel/kernel at 0xc09e.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Pentium/P55C (232.67-MHz 586-class CPU)
  Origin = GenuineIntel  Id = 0x543  Stepping = 3
  Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX
real memory  = 134217728 (128 MB)
avail memory = 120754176 (115 MB)
Intel Pentium detected, installing workaround for F00F bug
ACPI-0159: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TABLES
ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI_TABLES
ACPI: table load failed: AE_NO_ACPI_TABLES
npx0: [FAST]
npx0: math processor on motherboard
npx0: INT 16 interface
pcibios: BIOS version 2.10
pcib0: Host to PCI bridge at pcibus 0 on motherboard
pci0: PCI bus on pcib0
isab0: PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX3 WDMA2 controller port 0xffa0-0xffaf at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
pci0: display, VGA at device 8.0 (no driver attached)
bt0: Buslogic Multi-Master SCSI Host Adapter port 0xfff4-0xfff7 mem 
0xfff7f000-0xfff7 irq 10 at device 17.0 on pci0
bt0: BT-958 FW Rev. 5.07B Ultra Wide SCSI Host Adapter, SCSI ID 7, 192 CCBs
de0: Digital 21140A Fast Ethernet port 0xf880-0xf8ff mem 0xfff7ec00-0xfff7ec7f irq 9 
at device 19.0 on pci0
de0: SMC 9332BDT 21140A [10-100Mb/s] pass 2.2
de0: address 00:e0:29:00:b1:c2
orm0: Option ROMs at iomem 
0xea000-0xebfff,0xe9000-0xe9fff,0xc8000-0xcbfff,0xc-0xc7fff on isa0
pmtimer0 on isa0
atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 
0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5 drive on fdc0 drive 0
ppc0: parallel port not found.
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
unknown: PNP0303 can't assign resources (port)
psmcpnp0: irq resource info is missing; assuming irq 12
unknown: PNP0700 can't assign resources (port)
ppc1: parallel port not found.
unknown: PNP0501 can't assign resources (port)
unknown: PNP0501 can't assign resources (port)
Timecounter TSC frequency 232671577 Hz quality 800

IPFW2 verrevpath issue (IPv4 TCP, fresh kernel)

2003-11-25 Thread Matthias Andree
Hi,

I seem to have difficulties with verrevpath in IPFW2 (current kernel,
cvsupped a few hours ago) which APPEARS to not match - or am I too
whatever to configure ipfw2 properly?

Excerpt from ipfw show:

| 0010038   3216 allow ip from any to any via lo0
| 00200 0  0 deny ip from any to 127.0.0.0/8
| 00300 0  0 deny ip from 127.0.0.0/8 to any
 0040039  12941 deny log ip from any to any not verrevpath in
| 00500 0  0 deny ip from 192.168.0.0/24 to any in via tun0
| ...

Now, when I try to connect from my machine to a remote one with
ssh [EMAIL PROTECTED] I'm getting loads of

| kernel: ipfw: 400 Deny TCP 1.2.3.4:22 217.225.230.222:49228 in via tun0
| kernel: ipfw: 400 Deny TCP 1.2.3.4:22 217.225.230.222:49228 in via tun0

in syslog and the counter of the 00400 rule increases, and I don't get a
connection.  Leaving out the 00400 rule makes my outbound TCP
connections work.  (Apparently the 00400 rule swallows the SYN|ACK
packets.)

217.225.230.222 is my IP and 1.2.3.4 is the remote IP. tun0 is a PPPoE
interface, with ppp(8). I have a default route via 217.5.*.* gateway on
tun0 (both the default route and the host route for this 217.5.*.*
gateway use device tun0).

route get 1.2.3.4 prints that 1.2.3.4 is routed via some 217.5.*.*
host which is on tun0, so this looks fine.

I'd expect that the in via tun0 matched the outbound route as returned
by route get.

To add to the confusion, NTP (that uses UDP) is fine, the machine will
synchronize to an outside server (my ISP's DCF receiver) via the same
gateway just fine.

Is my expectation wrong or is there a pertinent IPFW2 bug in a current
5.2-BETA kernel?

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Modem(PCMCIA) works on 4.8, hangs machine on 5.2-BETA

2003-11-25 Thread Larry Rosenman
I tried(!) to use the following modem on my 5.2-BETA (actually -CURRENT from
a week or so ago), and the machine HUNG on the OPEN.


usb0: USB revision 1.0
usb1: USB revision 1.0
fwohci0: OHCI version 1.0 (ROM=1)
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1: Generic IRDA-compatible device at port 0x2e8-0x2ef irq 3 on isa0
sio1: type 16550A
sio2 at port 0x2f8-0x2ff irq 11 flags 0x4 slot 0 on pccard0
sio2: type 16550A
sio2: unable to activate interrupt in fast mode - using normal mode
The SIO2 is my Toshiba 3CXM056-BNW modem, and is what I'm sending this
from on 4.8.

What debug/help do y'all need to fix it?

LER

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)

2003-11-25 Thread Matthias Andree
Matthew Dillon [EMAIL PROTECTED] writes:

 How much do you intend to use NSS for?  I mean, what's the point of
 adopting this cool infrastructure if all you are going to do with it
 is make a better PAM out of it?

The important thing is that NSS allows to plug modules such as LDAP or
PostgreSQL for user base management. PAM is only halfway there and
doesn't give libc et al. a notion of a user or group context (in spite
of its account context), NSS does. One might discuss if PAM is really
needed with NSS in place, but it's hard to think of a system without
NSS and removing PAM now doesn't look right.

Of course, you can stuff the whole NSS client side (thinking IPC)
into a statically linked executable. To stall this discussion: I don't
mind if NSS is dynamically or statically linked. I won't let this drift
into any other dynamic - static discussion.

 reason that I can see, and coming up with all sorts of extra junk,
 like /rescue, to work around that fact.

As a user, I like /rescue better than the step-child that /stand/* used
to be. It's part of the world, which /stand wasn't.

One word of warning: there used to be SuSE Linux versions that wouldn't
let you log in single-user mode when the system was using NIS in
multi-user because there was nothing to communicate with through AF_UNIX
sockets yet this was expected to be able to log in. There are potholes
and pitfalls that I consider major considered with a dynamic /bin /sbin
setup.

Watch out.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: IPFW2 verrevpath issue (IPv4 TCP, fresh kernel)

2003-11-25 Thread Sean Chittenden
 Is my expectation wrong or is there a pertinent IPFW2 bug in a current
 5.2-BETA kernel?

You're alone in this, though cjc hasn't been able to reproduce this.
Are you on a multi-homed system?  -sc

-- 
Sean Chittenden
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


5.2-BETA root mount failure

2003-11-25 Thread Jeroen Hogeveen
Gents,

I'm having difficulties trying out the 5.2-BETA, preparing for the 
release. I would greatly appreciate it if anyone has some time at hand 
to help (re)solve a problem that occures with my 5.2-BETA kernel (26 nov
2003).

The situation is the following: I have tried to upgrade a system
(http://www.msi.com.tw/program/products/server/svr/pro_svr_detail.php?UID=376)
from 5.1-RELEASE to 5.2-BETA, according to the src/UPDATING text (I did
add the COMPAT_FREEBSD4 option to my kernel config).
buildworld went fine and so did buildkernel. After doing a installkernel
and booting with the newly installed 5.2-BETA kernel (single-user), I
get the following message before I get thrown in the mount root 
prompt:
mounting root from ufs:/dev/ar0s1a
setrootbyname failed
ffs_mountroot: can't find rootvp
Root mount failed: 6
mount root

Did I miss a step or have I hit something in -current?

Below is my dmesg output (working 5.1) :

Copyright (c) 1992-2003 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.1-RELEASE #0: Tue Nov 25 09:49:42 GMT 2003
[EMAIL PROTECTED]:/usr/src/sys/i386/compile/CURRENT
Preloaded elf kernel /boot/kernel/kernel at 0xc0381000.
Timecounter i8254  frequency 1193182 Hz
Timecounter TSC  frequency 2391148112 Hz
CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2391.15-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf27  Stepping = 7
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
real memory  = 1073676288 (1023 MB)
avail memory = 1039364096 (991 MB)
pnpbios: Bad PnP BIOS data checksum
Pentium Pro MTRR support enabled
acpi0: IntelR AWRDACPI on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 10 entries at 0xc00fdec0
acpi0: power button is handled as a fixed feature programming model.
Timecounter ACPI-fast  frequency 3579545 Hz
acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
acpi_cpu0: CPU on acpi0
acpi_cpu1: CPU on acpi0
acpi_tz0: thermal zone on acpi0
acpi_button0: Power Button on acpi0
acpi_button1: Sleep Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0
pci2: ACPI PCI bus on pcib2
em0: Intel(R) PRO/1000 Network Connection, Version - 1.5.31 port 
0xb000-0xb03f mem 0xe200-0xe201 irq 12 at device 5.0 on pci2
em0:  Speed:10 Mbps  Duplex:Half
fxp0: Intel 82557/8/9 EtherExpress Pro/100(B) Ethernet port 
0xb400-0xb43f mem 0xe202-0xe203,0xe2044000-0xe2044fff irq 10 at 
device 6.0 on pci2
fxp0: Ethernet address 00:0c:76:15:19:c5
miibus0: MII bus on fxp0
inphy0: i82555 10/100 media interface on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pci2: display, VGA at device 7.0 (no driver attached)
atapci0: Promise PDC20276 UDMA133 controller port 
0xcc00-0xcc0f,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xbc00-0xbc07 
mem 0xe204-0xe2043fff irq 11 at device 10.0 on pci2
ata2: at 0xbc00 on atapci0
ata3: at 0xc400 on atapci0
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci1: Intel ICH4 UDMA100 controller port 
0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci1
ata1: at 0x170 irq 15 on atapci1
pci0: serial bus, SMBus at device 31.3 (no driver attached)
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
npx0: math processor on motherboard
npx0: INT 16 interface
orm0: Option ROMs at iomem 0xc8000-0xd07ff,0xc-0xc7fff on isa0
pmtimer0 on isa0
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0
Timecounters tick every 10.000 msec
IP Filter: v3.4.31 initialized.  Default = pass all, Logging = enabled
acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0%
ad4: 117800MB IC35L120AVV207-1 [239340/16/63] at ata2-master UDMA100
ad6: 117800MB IC35L120AVV207-1 [239340/16/63] at ata3-master UDMA100
ar0: 117301MB ATA RAID1 array [14953/255/63] status: READY subdisks:
 disk0 READY on ad4 at ata2-master
 disk1 READY on ad6 at ata3-master
Opened disk ad4 - 1
Opened disk ad6 - 1
Opened disk ad6 - 1
Mounting root from ufs:/dev/ar0s1a

%atacontrol list
ATA channel 0:
Master:  no device present
Slave:   no device present
ATA channel 1:
Master:  SR244W/T01A ATA/ATAPI rev 0
Slave:   no device present
ATA channel 2:
Master:  ad4 IC35L120AVV207-1/V24OA66A ATA/ATAPI rev 6
Slave:   no device present
ATA channel 3:

Re: IPFW2 verrevpath issue (IPv4 TCP, fresh kernel)

2003-11-25 Thread Matthias Andree
On Tue, 25 Nov 2003, Sean Chittenden wrote:

  Is my expectation wrong or is there a pertinent IPFW2 bug in a current
  5.2-BETA kernel?
 
 You're alone in this, though cjc hasn't been able to reproduce this.
 Are you on a multi-homed system?  -sc

Sort of. I do have three xl(4) NICs in my system. xl0 and xl1 are
bridged via ng_bridge(*), IP 192.168.0.1 on one card, no IP on the
other; xl2 is the transport for tun0 (which is PPPoE in my case) and
doesn't have an IP either, so multi-homed might read tun0 has an
address, xl0 has another and lo0 has a third one.

These xl* cards shouldn't matter for my problem, at the time I tested my
firewall setups, the networks were idle with no other hosts attached.


I noticed that very recently there was a bug fix that made the machine
pick the right outbound address again (which it didn't for some days or
weeks, haven't compiled kernels daily) - I wonder if it's related.
Unfortunately, I don't have a 5.1-RELEASE box here to test. Would 4.9
with IPFW2 option be sufficiently similar in IPFW2 matters that it's
worthwhile testing?



(*) I have a configuration where the bridge is to have the same IP from
both xl0 and xl1. Traditional bridge code gets confused over ARP and
coughs up the MACs it would need and locks itself out,
netgraph-bridge is fine however.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: rtld + static linking

2003-11-25 Thread Terry Lambert
E.B. Dreger wrote:
 After watching the recent shared/dynamic threads, and reading the
 archives from five or six years ago, I have a question...
 
 Dynamic linking works by the kernel running the dynamic linker,
 which loads shared objects and fixes the symbol tables, yes?

No.

Dynamic linking works because the crt0 mmap's the /usr/libexec/ld.so
file as executable, and then points known stub offsets into it.  It
then passes this as part of the environment, at a negative offset,
into the _main, which fills out a little glue table.  After all this
is set up, then _main calls the location .entry in the executable,
which is usally main, but can be set to something else at link time.
This all works because the crt0.o has some self-knowledge for a number
of symbol offsets, and because _main is called with the environment
descriptor.  Basically, the environment descriptor is lost in the
static linking case.


 Is there some reason that a statically-linked program couldn't
 include some ld-elf.a type of intelligence?  Would that be
 necessary and sufficient to allow statically-linked programs to
 load shared objects?

Yes, and yes.

The main reason that there is no dlopen is that the environment
descriptor is lost.  This is pretty trivial to remedy, but it
means passing the environment descriptor to something that can
use it to set up the startup.

This is complicated by the fact that only a single .init entry
point is usable, so if you were to override it, you would lose
library initialization for C libraries, and you would fail to
call constructor code for statically declare class instances in
C++ code, and lose out on other linker set stuff, such as per
thread exception stacks, etc..

The trivial fix for this is to add a void * parameter to the
constructor iterator in the crt0, and then pass the environment
there, so that you could implement a libdlopen that took that
and used it to obtain the self-knowledge of the crt0 that was
needed to (1) adjust the stub pointers to an mmap'ed ld.so, and
(2) provide the access to the symbol table needed so that when
you loaded modules, they would link properly vs. the symbols in
the executable itself.  You would either need to change the list
to specifically reference the libc symbols, OR  you would need
to reload libc.so (the problem with doing the latter is that you
might get a different libc out of it, and the executable symbols
that may replace the libc symbols wouldn't do so for modules, so
that's a non-starter).

It's actually a pretty trivial crt0 and ld change to deal with
this, the sticking point is that you have to also change the
libgcc and other GNU code to pass a NULL value to the void *
constructor parameter in the default case.  This would make
the code minorly incompatible with Linux, etc., unless you could
get the GCC people to pick up your change.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Modem(PCMCIA) works on 4.8, hangs machine on 5.2-BETA

2003-11-25 Thread Larry Rosenman
On Tue, 25 Nov 2003, Larry Rosenman wrote:

 I tried(!) to use the following modem on my 5.2-BETA (actually -CURRENT from
 a week or so ago), and the machine HUNG on the OPEN.


 usb0: USB revision 1.0
 usb1: USB revision 1.0
 fwohci0: OHCI version 1.0 (ROM=1)
 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
 sio0: type 16550A
 sio1: Generic IRDA-compatible device at port 0x2e8-0x2ef irq 3 on isa0
 sio1: type 16550A
 sio2 at port 0x2f8-0x2ff irq 11 flags 0x4 slot 0 on pccard0
 sio2: type 16550A
 sio2: unable to activate interrupt in fast mode - using normal mode
 The SIO2 is my Toshiba 3CXM056-BNW modem, and is what I'm sending this
 from on 4.8.

 What debug/help do y'all need to fix it?
Interestingly, I tried it again under the -CURRENT, and got 512 silo
overflows, and 9400 interupt overflows, then the lock.  I can't
even get into DDB.

So, where to PCMCIA/CBB/ETC guru's?

LER


 LER



-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)

2003-11-25 Thread David O'Brien
On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote:
 As a user, I like /rescue better than the step-child that /stand/* used
 to be. It's part of the world, which /stand wasn't.

Except that we still have /stand.  It should be shot, but some won't let
it go...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: rtld + static linking

2003-11-25 Thread Marcel Moolenaar
On Tue, Nov 25, 2003 at 05:44:18PM -0800, Terry Lambert wrote:
 E.B. Dreger wrote:
  After watching the recent shared/dynamic threads, and reading the
  archives from five or six years ago, I have a question...
  
  Dynamic linking works by the kernel running the dynamic linker,
  which loads shared objects and fixes the symbol tables, yes?
 
 No.
 
 Dynamic linking works because the crt0 mmap's the /usr/libexec/ld.so
 file as executable, and then points known stub offsets into it.

No.

Dynamic linking works because the kernel loads and runs the dynamic
linker when it sees that the executable defines an interpeter.

  Is there some reason that a statically-linked program couldn't
  include some ld-elf.a type of intelligence?  Would that be
  necessary and sufficient to allow statically-linked programs to
  load shared objects?
 
 Yes, and yes.

No, and no.

A complete executable (i.e. staticly linked) does not export any
symbols, or at least not in the same way a shared executable and
shared libraries do. If I try to dynamicly link libbar into a
complete executable foo and libbar depends on libc, then there's
no guarantee that all the required bits from libc are in foo, nor
is there any guarantee that the bits are actually visible or even
accessable (no linkage table).
Dynamicly loading libc for use by libbar can work, but it's not
guaranteed. One failure mode is suddenly having two instances of
a common variable instead of one. Another is the clobbering of
data caused reinitializations.

So, the problem of dynamic linking a shared library into a static
process is non-trivial and probably cannot be solved genericly.
Under restricted and controlled conditions you can make it work.
I would call it the ability to have plugins, not the ability to
load dynamic libraries.

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: How to fix this in 5.1-REL??

2003-11-25 Thread walt
Brooks Davis answered:

walt asked:
What does 'buildworld' give us that the new kernel might need?

The correct toolchain including the compiler and config(8).
Okay, thanks, that helps.

Just thinking out loud about worst-case examples for people who
do routinely use 'make world' (like I have for several years).
I found out first-hand why installworld quits halfway through
when the new executables won't run on the old kernel.  I need no
further education on that point ;-)
I'm thinking, though, that doing 'make kernel' first has a much
lower potential for disaster than 'make world':  if I reboot after
a 'make kernel' and the new kernel won't run on the old world, then
all I need to do to recover is to boot the old kernel again and
'make buildworld'. Seems difficult to do any real harm this way.
Is this completely wrong-headed?  Am I missing something important?

(Yes, I know I should just do it the right way every time -- but
I'm trying to reason through just why some ways are right and
some are wrong.)
Thanks for any insights.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]


  1   2   >