Re: HEADS UP: /bin and /sbin are now dynamically linked
> need it or not. :-) So, FTP server is not concern. /rescue/fetch MAY help > to recover RUINED FreeBSD from ashes... As /rescue/mount_cd9660, or > mount_msdosfs... In other words we can drom mount_msdosfs from /rescue > just because almost everybody can burn CD... We will save a few KBytes of FWIW, *large* installations, don't bother with buying floppies and cdroms. (By large I mean > 1000 machines.) Then again, places with large installations, probably don't use the freebsd installer, *or* have the clue to not be (too) hurt by these changes. ___ [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
On Mon, Nov 24, 2003 at 08:55:31PM -0500, Andrew Gallatin wrote: > > Daniel O'Connor writes: > > > Why didn't you pipe up when this was discussed _long_ ago? > > In the orginal thread, there was an agreement that the performance > would be measured BEFORE the default was changed, and the default > would only be changed if there was no measurable performance impact. > I believe sam@ asked for this. As far as I know, performance > measurments were never done. Instead, the switch was thrown just > before the code freeze. That's not true. I was asked to present numbers so we could make a determination as to what the impact was. It was never said that it would only be the default iff there was no performance impact. FWIW, I did find that the boot process took a performance hit, I also found that the average worldstone did not increase appreciably (ie, less than 1%). I took these numbers to re@ when I was asked to flip the dynamic switch and the feeling was that the overhead was worth the tradeoff for functionality. Finally, I must ask if anyone has evidence that this has slowed down anything other than microbenchmarks? My point of view was it did slow down the boot, but so did rcNG and no one seemed to mind about that. Also, you don't write time-sensitive applications in shell so the dynamic link overhead is not noticed there. People asked me about the affect on periodic. My response is why do you care if your periodic took 1 extra second to run (on the outside) due to dynamic linking overhead. It's just crazy. In summary, I have yet to see a compelling arguement to consider backing out the dynamic linking changes I've put in. I've read all of the messages in all of the 3+ huge threads and I'm still as resolved today as I was when I made the commit. Frankly, I'm surprised people didn't yell at me when I massively restructured the tree to put libraries in /lib. Turning on dynamic linking was the most minor part from the architectural point of view but is getting the most vitriol. How typical. -gordon pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
> 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 all the worstness is in system time, or nealy all. However, you rant this test only once. : > : > So.. : > : > 1) Microbenchmark: 40% worse : > 2) Bootstone(*):25% worse : > 3) Ports: 16% worse 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; Here's the numbers I got: x sh-s static sh + sh-d dynamic sh +--+ |x x + | |x x + + | |x x x x + + + | |x x x x + + + + + +| |x x x x x + + + + + + + +| ||___A__M_||A__M| | +--+ N Min MaxMedian AvgStddev x 20 1.27 1.31 1.31.2925 0.012085224 + 20 1.4 1.47 1.44 1.431 0.023597502 Difference at 95.0% confidence 0.1385 +/- 0.0119989 10.7157% +/- 0.928346% (Student's t, pooled s = 0.0187469) As you can see, I ran each of the tests 10 times. I timed it using a the tcsh time built-in. I ran each command once before I started timing the commands to reduce cache effects. 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. So things are a little bad, but it isn't the end of the world, especially for a 5.2-beta that's going out. Warner ___ [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
>[ From: set to /dev/null as too many can't follow the Reply-To: ]
>
>On Mon, Nov 24, 2003 at 11:00:24AM -0500, Rahul Siddharthan wrote:
>> > NO. /rescue was allowed in the system to handle the case of a trashed
>> > file in /lib[exec]. To allow a sysadmin to recover a system from the
>> > same type of mishaps they could before we went to a dynamic /.
>>
>> Ie, let's do things the same way we did in 1994? Other things have
>> changed since then, hard drives and typical root partitions are much
>> bigger, and Tim estimated the total bloat from this as 64k. Maybe
>> earlier, pre-/rescue, you couldn't recover from damaged files in the
>> root partition without a CD/floppy/NFS, it doesn't mean you should not
>> have that capability in /rescue.
>
>Lets have /rescue/{[s]bin,usr/[s]bin}. Install static copies of every
>thing in /[s]bin and /usr/[s]bin today. That will let you recover in
>even more ways.
>
>Where does it end if we don't go full-out and install a 2nd copy of every
>binary?
>
>
>> For a *lot* of people today (like home users), an up-to-date FreeBSD
>> CD or floppy or a second machine to create the disk on may not be
>> handy (and forget about NFS), but a network connection may still be
>> available.
>
>That network connection would most likely be a M$-Win box in that case,
>which doesn't have an FTP server. Samba, not an FTP client should be in
>/rescue then.
There are a lot of FTP servers for M$ Windows... At least
IIS/PWS... :-) IMHO, Microsoft gives it to all, neglecting whether they
need it or not. :-) So, FTP server is not concern. /rescue/fetch MAY help
to recover RUINED FreeBSD from ashes... As /rescue/mount_cd9660, or
mount_msdosfs... In other words we can drom mount_msdosfs from /rescue
just because almost everybody can burn CD... We will save a few KBytes of
space (that isn't really needed on modern disks), but we will loose
functionality... For me, having /rescue/fetch is a good thing, just
because it can REALLY help me to recover fallen system.
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
On Monday 24 November 2003 07:06 pm, Andrew Gallatin wrote: > M. Warner Losh writes: > > In message: <[EMAIL PROTECTED]> > > I'm just saying that most of the developers I'm talking to on IRC say > > this tread is insane, has no content and they are blowing it off > > because of that. A concrete, real benchmark will go a long way > > towards changing that. Until then, you are as good as kill filed. > > 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 I don't believe it was ever demonstrated there was no significant performance loss. I think the switch should not be made until this is resolved. netbsd went through this recently and made an effort to bring performance of a dynamic root in line with a static root before making the change. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Make it so that nobody wins
Richard Coleman wrote: > Neither side of the static/dynamic root debate wants to give in. And > neither side wants to be one the that has to recompile the world to get > what they want. So make it so that no one wins. Actually, I don't have a personal axe to grind so much as I just feel that this is a mistake. But whatever. > 1. Have sysinstall ask whether you want a dynamic or static root installed. > 2. When recompiling the world, make it mandatory that DYNAMICROOT=YES/NO > exits in make.conf. > > Neither side wins, neither side loses. Now both side will hate it equally. > > Of course, I'm only being half serious. But in a bizarre way, it kinda > makes sense. Hey, that works for me! If nothing else it will keep some attention on the issue. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Make it so that nobody wins
Agreed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Coleman Sent: Monday, November 24, 2003 10:55 PM To: [EMAIL PROTECTED] Subject: Make it so that nobody wins Neither side of the static/dynamic root debate wants to give in. And neither side wants to be one the that has to recompile the world to get what they want. So make it so that no one wins. 1. Have sysinstall ask whether you want a dynamic or static root installed. 2. When recompiling the world, make it mandatory that DYNAMICROOT=YES/NO exits in make.conf. Neither side wins, neither side loses. Now both side will hate it equally. Of course, I'm only being half serious. But in a bizarre way, it kinda makes sense. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Make it so that nobody wins
Neither side of the static/dynamic root debate wants to give in. And neither side wants to be one the that has to recompile the world to get what they want. So make it so that no one wins. 1. Have sysinstall ask whether you want a dynamic or static root installed. 2. When recompiling the world, make it mandatory that DYNAMICROOT=YES/NO exits in make.conf. Neither side wins, neither side loses. Now both side will hate it equally. Of course, I'm only being half serious. But in a bizarre way, it kinda makes sense. Richard Coleman [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
PW> Date: Mon, 24 Nov 2003 18:56:21 -0800 PW> From: Peter Wemm PW> We need nsswitch type functionality in /bin/sh. To the PW> people who want to make it static, lets see some static PW> binary dlopen() support or a nsswitch proxy system. I started a new thread inquiring about the challenges involved... which received no responses. I assume that not much has changed since the mid- to late-90s list archives I found via Google... What specific aspects of rtld are required to support NSS in static binaries? dlopen(), fixups, and dlsym()? Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. ___ [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
On Mon, Nov 24, 2003 at 11:00:24AM -0500, Rahul Siddharthan wrote: >David O'Brien wrote: >> On Sun, Nov 23, 2003 at 06:00:36PM -0800, Tim Kientzle wrote: >> > Scenarios that require /rescue are ones in which /bin and /sbin >> > are unusable, which is almost always going to imply a trashed file >> > in /bin, /sbin, or /lib. Thus, most /rescue scenarios are going to >> > involve locating a good copy of a trashed file to replace a damaged >> > local copy. >> >> NO. /rescue was allowed in the system to handle the case of a trashed >> file in /lib[exec]. To allow a sysadmin to recover a system from the >> same type of mishaps they could before we went to a dynamic /. > >Ie, let's do things the same way we did in 1994? To put it another way. FreeBSD has never had the ability to recover from a hosed root or /usr using FTP, though you can use rrestore or rcp to recover /usr. There has never been a great groundswell of complaints about this (offhand, I can't recall any). Why does this suddenly become a major issue once / is dynamically linked? > Other things have >changed since then, hard drives and typical root partitions are much >bigger, Pre-existing harddrives and root partitions do not magically expand over time. A new installation and/or a new harddrive might have a much bigger root partition but an existing one won't. > and Tim estimated the total bloat from this as 64k. And then someone else wants their favourite tool which is only another 64K and so on. Pretty soon you have a 200MB /rescue. > Maybe >earlier, pre-/rescue, you couldn't recover from damaged files in the >root partition without a CD/floppy/NFS, it doesn't mean you should not >have that capability in /rescue. If no-one's missed it in the past, why would they suddenly need it now? Peter ___ [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
On Tuesday 25 November 2003 12:20, Andrew Gallatin wrote: > > OK my bad, it will probably slow down the ports building. > > I'll bet a larger percentage of our users build ports than need nss or > ldap. Err, yes.. Of course you are claiming it should be either/or, which is not very reasonable. What about the newer version of gcc? That is considerably slower than previous versions, but I don't see people screaming to have it removed. Most things are tradeoffs, this is one of them. -- 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: 40% slowdown with dynamic /bin/sh
On Mon, 24 Nov 2003, Matthew Dillon wrote: > :I think that you forgot to attach the patches that demonstrate all of > :this. > : > :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. > : > :Scott > > That's too bad, Scott. You are just going to have to live with it. > > From my point of view anything related to BSD is fair and reasonable > game, and regardless of anything else this mailing list is discussing > topics and things that are near and dear to my heart and I have a perfect > right to comment on them. I've contributed a considerable amount of > time and effort to FreeBSD and I have a right to be on this list. > > From my point of view, it's all under the same open-source umbrella > anyway. The moment you start thinking of a project in isolation is > the moment you start to disconnect from your responsibility to the > project and to all the users and developers who depend on the project. > > I still run a lot of FreeBSD boxes and know people who run a lot of > FreeBSD boxes and, frankly, that gives me just as much right to comment > on the future directions of FreeBSD as you or anyone else. > > So you are just going to have to live with it. Maybe instead of fuming > over DFly you should consider the work from a more technical standpoint. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > > I am eager to see what you can do with DFBSD. I really, truly, am. Until then, trolling the FreeBSD mailing lists with uninformed statements about 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 ___ [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
In message: <[EMAIL PROTECTED]> Andrew Gallatin <[EMAIL PROTECTED]> writes: : 1) Microbenchmark:40% worse : 2) Bootstone(*): 25% worse : 3) Ports: 16% worse Thanks for the real numbers. 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
:I think that you forgot to attach the patches that demonstrate all of :this. : :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. : :Scott That's too bad, Scott. You are just going to have to live with it. From my point of view anything related to BSD is fair and reasonable game, and regardless of anything else this mailing list is discussing topics and things that are near and dear to my heart and I have a perfect right to comment on them. I've contributed a considerable amount of time and effort to FreeBSD and I have a right to be on this list. From my point of view, it's all under the same open-source umbrella anyway. The moment you start thinking of a project in isolation is the moment you start to disconnect from your responsibility to the project and to all the users and developers who depend on the project. I still run a lot of FreeBSD boxes and know people who run a lot of FreeBSD boxes and, frankly, that gives me just as much right to comment on the future directions of FreeBSD as you or anyone else. So you are just going to have to live with it. Maybe instead of fuming over DFly you should consider the work from a more technical standpoint. -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
:> :> :I supported the decision because: :> : :> :1. It has been requested for years :> :2. It benefits PAM and NSS. :> :3. It is easy to revert. :> :> Easy to revert? You are talking about depending on mechanisms for :> authentication and other things that WILL NOT WORK with static binaries :> as they currently stand and, apparently, will not work in the :> future either. Easy to revert? I don't think so. :> :> More like "Lets do away with support for static binaries entirely". :> Because that is precisely what is happening here. : :What the hell are you talking about What I am talking about is that if the intent in -CURRENT is to start to depend on things like NSS... and it really does make sense to be able to depend on something like NSS, then it will become less and less feasible to compile programs in a way that cannot use NSS. /bin/sh is an excellent example of this. Why is /bin/sh now dynamic again? Why can't it be static? I'm being retorical, but I think it demonstrates the problem and my point quite succinctly. Regardless of whether you have a dynamic root or a static root, FreeBSD is digging itself into a hole if it cannot use these spiffy new mechanisms with static binaries. -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
On Mon, 24 Nov 2003, Matthew Dillon wrote: > > :I supported the decision because: > : > :1. It has been requested for years > :2. It benefits PAM and NSS. > :3. It is easy to revert. > > Easy to revert? You are talking about depending on mechanisms for > authentication and other things that WILL NOT WORK with static binaries > as they currently stand and, apparently, will not work in the > future either. Easy to revert? I don't think so. > > More like "Lets do away with support for static binaries entirely". > Because that is precisely what is happening here. What the hell are you talking about ___ [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
In the last episode (Nov 24), Scott Long said: > I think that you forgot to attach the patches that demonstrate all of > this. > > 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. I think he's pointing out that within a short time there will be a BSD-licensed nscd we can use. -- Dan Nelson [EMAIL PROTECTED] ___ [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
At 8:59 PM -0500 2003/11/24, Andrew Gallatin wrote: Of course not. Nobody in their right mind uses csh for scripting. To my great horror, csh is used in most of the DNS debugging and many of the log-processing scripts that I have inherited. One of these days, I will finally live up to my threat of importing all this functionality into other programs that use other languages (toss "doc" and incorporate that functionality into "dnswalk", etc...), but that has not happened yet. Meanwhile, I don't know that a dynamic vs. static csh does me any measurable harm -- the delays waiting for responses from nameservers will overwhelm any local delays caused by dynamic vs. static linking. -- 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: 40% slowdown with dynamic /bin/sh
On Mon, 24 Nov 2003, Matthew Dillon wrote: > :Ding! "Oh god, not another one!" *plonk* > : > :We need nsswitch type functionality in /bin/sh. To the people who want to > :make it static, lets see some static binary dlopen() support or a nsswitch > :proxy system. > : > :If half as much effort had been spent on implementing such a thing as there > :has been hand wringing, then we'd have the best of both worlds by now. > : > :I'm sorry to sound harsh, but its the reality of the situation. Code > :speaks louder than words. > : > :Cheers, > :-Peter > :-- > :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > :"All of this is for nothing if we don't go to the stars" - JMS/B5 > > 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. 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. > > 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. > 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. > > And, of course, moving all of this junk out means that the libc > implementation becomes a lot smaller... it just becomes an IPC interface > and may be a small local cache rather then the full blown algorithm. > The result? Static binaries become a lot smaller too (not that that > is really a problem anyway). > > This 'it has to be static so dlopen works' argument is just not a good > argument. It's really more of an excuse then an argument. If you > really want to use dlopen then make it work with static binaries. > If you want to do it right, develop an IPC model or use an existing > IPC model. > > That said, an IPC model is precisely what I am developing for DragonFly > (a 'money where your mouth is' response). :-) Right now I'm building > it as a userspace library but I intend to move the rendezvous code > directly into the kernel. Unix domain sockets are so icky(!). They work, > but they are icky. I intend to use it for all resource and > authentication lookups... password, group, services, pam equivalent, > kerberos, resolver, and so on and so forth. Hell, I think I might use > it for C locale too just to be able to rip locale out of libc. > I think that you forgot to attach the patches that demonstrate all of this. 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. Scott ___ [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
:I supported the decision because: : :1. It has been requested for years :2. It benefits PAM and NSS. :3. It is easy to revert. Easy to revert? You are talking about depending on mechanisms for authentication and other things that WILL NOT WORK with static binaries as they currently stand and, apparently, will not work in the future either. Easy to revert? I don't think so. More like "Lets do away with support for static binaries entirely". Because that is precisely what is happening here. :Now please move along and revert it on your local system. There are far :too many REAL problems out there that need to be addressed so that 5.2 can :go out the door. This is just wasting time and energy. : :Scott This is a real problem. I have no problem with people who want dynamic roots to get dynamic roots. My problem is with this intention to not fix PAM or NSS in a way that works with static binaries, and my problem is with changing the default from static to dynamic. The result is, down the line, that either (A) it will become impossible to compile anything static, or (B) there will be things you WON'T be able to use NSS for because it will break static binaries. It is a serious logistical and planning mistake, IMHO. -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
Peter Wemm writes: > We need nsswitch type functionality in /bin/sh. To the people who want to > make it static, lets see some static binary dlopen() support or a nsswitch > proxy system. Maybe this is just nieve, but I always thought that it was the responsibility of the party introducing the creeping feature to underdatand and then minimize a potential performance impact. But now we're treading over ground brought up by John Dyson last week. I've at least partially quantified the performance impact, which is all I have time for. Drew ___ [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
:Ding! "Oh god, not another one!" *plonk* : :We need nsswitch type functionality in /bin/sh. To the people who want to :make it static, lets see some static binary dlopen() support or a nsswitch :proxy system. : :If half as much effort had been spent on implementing such a thing as there :has been hand wringing, then we'd have the best of both worlds by now. : :I'm sorry to sound harsh, but its the reality of the situation. Code :speaks louder than words. : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] :"All of this is for nothing if we don't go to the stars" - JMS/B5 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. 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. 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. 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. And, of course, moving all of this junk out means that the libc implementation becomes a lot smaller... it just becomes an IPC interface and may be a small local cache rather then the full blown algorithm. The result? Static binaries become a lot smaller too (not that that is really a problem anyway). This 'it has to be static so dlopen works' argument is just not a good argument. It's really more of an excuse then an argument. If you really want to use dlopen then make it work with static binaries. If you want to do it right, develop an IPC model or use an existing IPC model. That said, an IPC model is precisely what I am developing for DragonFly (a 'money where your mouth is' response). :-) Right now I'm building it as a userspace library but I intend to move the rendezvous code directly into the kernel. Unix domain sockets are so icky(!). They work, but they are icky. I intend to use it for all resource and authentication lookups... password, group, services, pam equivalent, kerberos, resolver, and so on and so forth. Hell, I think I might use it for C locale too just to be able to rip locale out of libc. -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
Would it be possible to ship a static /bin/sh and a dynamic /bin/dynamic-sh, with /bin/sh execing /bin/dynamic-sh if it is invoked interactively? If I'm understanding the issues correctly, a dynamic /bin/sh is desired for the benefit of interactive users, while the performance of a static /bin/sh is only an issue in non-interactive cases. Colin Percival ___ [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
M. Warner Losh writes: > In message: <[EMAIL PROTECTED]> > I'm just saying that most of the developers I'm talking to on IRC say > this tread is insane, has no content and they are blowing it off > because of that. A concrete, real benchmark will go a long way > towards changing that. Until then, you are as good as kill filed. 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 Drew ___ [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
On Mon, Nov 24, 2003 at 03:15:57PM -0500, Andrew Gallatin wrote: > > % /usr/bin/time ./harness.sh ./sh.dynamic 100 > 1.60 real 0.21 user 1.18 sys > > % ./harness.sh ./sh.static 100 > 1.12 real 0.08 user 0.87 sys > > So.. forking a dynamic sh is roughly 40% more expensive than > forking a static copy of sh. This is embarrassing. All this noise because, for every 1,000 invocations of dynamic /bin/sh, you have to wait nearly an extra 5 seconds. Truly embarrassing, indeed. Totally unacceptable for a BETA release. We all could have collectively spawned millions of dynamic shells in the time that it has taken to compile this thread. But we didn't. Can't be all that important, can it? :) Geoff ___ [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
"M. Warner Losh" wrote: > In message: <[EMAIL PROTECTED]> > Andrew Gallatin <[EMAIL PROTECTED]> writes: > : > : M. Warner Losh writes: > : > In message: <[EMAIL PROTECTED]> > : > Andrew Gallatin <[EMAIL PROTECTED]> writes: > : > : I'll bet a larger percentage of our users build ports than need nss or > : > : ldap. > : > > : > I'll bet a larger percentage of the people are ignoring this thread > : > than reading it since it has been so devoid of concrete numbers. > : > : Aside from $SUBJECT.. > > I'm just saying that most of the developers I'm talking to on IRC say > this tread is insane, has no content and they are blowing it off > because of that. A concrete, real benchmark will go a long way > towards changing that. Until then, you are as good as kill filed. Ding! "Oh god, not another one!" *plonk* We need nsswitch type functionality in /bin/sh. To the people who want to make it static, lets see some static binary dlopen() support or a nsswitch proxy system. If half as much effort had been spent on implementing such a thing as there has been hand wringing, then we'd have the best of both worlds by now. I'm sorry to sound harsh, but its the reality of the situation. Code speaks louder than words. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-BETA USB woes
On Nov 24, 2003, at 10:56, Ade Lovett wrote:
The executive summary is that after some unfortunate hardware
failures, I picked up an ASUS A7V8X-X motherboard with a 6 USB 2.0
ports.
Just as an addendum, on the advice of someone on irc, I tried booting
both NetBSD (1.6.1) and OpenBSD (3.4) on this machine. Relevant
dmesg(8) as follows:
NetBSD 1.6.1 (INSTALL) #0: Tue Apr 8 12:46:48 UTC 2003
[EMAIL PROTECTED]:/autobuild/netbsd-1-6/i386/OBJ/autobuild/
netbsd-1-6/src/sys/arch/i386/compile/INSTALL
cpu0: AMD K7 (Athlon) (686-class), 2166.54 MHz
[...]
uhci0 at pci0 dev 16 function 0: vendor 0x1106 product 0x3038 (rev.
0x80)
uhci0: interrupting at irq 3
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: vendor 0x1106 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 16 function 1: vendor 0x1106 product 0x3038 (rev.
0x80)
uhci1: interrupting at irq 3
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: vendor 0x1106 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2 at pci0 dev 16 function 2: vendor 0x1106 product 0x3038 (rev.
0x80)
uhci2: interrupting at irq 3
usb2 at uhci2: USB revision 1.0
uhub2 at usb2
uhub2: vendor 0x1106 UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
vendor 0x1106 product 0x3104 (USB serial bus, interface 0x20, revision
0x82) at pci0 dev 16 function 3 not configured
[...]
uhub0: port error, restarting port 1
uhub0: port error, giving up port 1
uhub1: port error, restarting port 1
uhub1: port error, giving up port 1
uhub1: port error, restarting port 2
uhub1: port error, giving up port 2
uhub2: port error, restarting port 1
uhub2: port error, giving up port 1
uhub2: port error, restarting port 2
uhub2: port error, giving up port 2
uhidev0 at uhub0 port 1 configuration 1 interface 0
uhidev0: Microsoft Microsoft Wireless Optical MouseÆ 1.0A, rev
2.00/0.17, addr 2, iclass 3/1
uhidev0: 2 report ids
uhid at uhidev0 reportid 1 not configured
uhid at uhidev0 reportid 2 not configured
uhub0: port error, restarting port 2
uhub0: port error, giving up port 2
So, NetBSD does something fairly similar to FreeBSD, but at least
manages to find a mouse, before completely flaking out.
On to OpenBSD:
OpenBSD 3.4 (RAMDISK_CD) #0: Tue Oct 21 19:29:29 BST 2003
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: AMD Athlon XP Model 8 (Thoroughbred) ("AuthenticAMD" 686-class)
2.17 GHz
[...]
uhci0 at pci0 dev 16 function 0 "VIA VT83C572 USB" rev 0x80: irq 3
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 16 function 1 "VIA VT83C572 USB" rev 0x80: irq 3
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2 at pci0 dev 16 function 2 "VIA VT83C572 USB" rev 0x80: irq 3
usb2 at uhci2: USB revision 1.0
uhub2 at usb2
uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
[...]
uhidev0 at uhub0 port 1 configuration 1 interface 0
uhidev0: Microsoft Microsoft Wireless Optical Mouse\M-. 1.0A, rev
2.00/0.17, addr 2, iclass 3/1
uhidev0: 2 report ids
uhid at uhidev0 reportid 1 not configured
uhid at uhidev0 reportid 2 not configured
After installing, the mouse is unresponsive.
Hoping this helps turn on a light bulb :)
-aDe
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ThinkPad 560Z & ACPI
Good people, I have managed to crowbar ACPI support into working on ThinkPad 560Z with the attached patch. The problem seems to be that TP returns everything and a kitchen sink in the list of available IRQs, but expects OS to use one you have set up using TP Configuration Program (intuitively named PS2 ;). Thus with the current approach of taking first IRQ from the list, IRQ 3 gets everything routed to it, and since it is used by serial port, cardbus bridge, USB controller and fxp in the docking station fail rather miserably. fxp reports timeouts on the regular basis and the rest silently does nothing. I have added kernel environment variable "hw.acpi.pci.preferred_irq" which would allow user to specify IRQ to be used (only in the case when it is in the list of available IRQs). If variable is not specified or if IRQ is not on the list of available ones, behaviour will revert to the original, which is to use first IRQ from the list. I do not know if this is the right way to address this problem and would appreciate any comments from people who actually know something about ACPI (as opposed to me). If there is the better way, I would really appreciate a pointer, since ACPI on this machine is fairly enjoyable. I have throtted CPU down to 25% and it is cool (in the literal meaning of the word) and battery lasted for 2 hours+ while using wireless card. Conversely if there is a value in this approach, maybe some kind soul could stick it into the codebase. This way I would not have to aplly patch every time I cvsup ;) -- Alexandre "Sunny" Kovalenko. acpi_pcib.c.patch Description: Binary data ___ [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
On Mon, Nov 24, 2003 at 06:27:13PM -0800, Tim Kientzle wrote: > The debate right now is over what programs from /usr/bin and > /usr/sbin should be included. Right now, that includes > tar, gzip, bzip2, and vi/ex. All but vi(ex) were built statically, but installed into /usr/bin. -- -- David ([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
On Tuesday 25 November 2003 12:44, Frank Mayhar wrote: > _This_ is the issue. You assert that this change "benefits a fair number > of users." I and others assert that it hurts performance and makes > disaster recovery more complex (while the existence of /rescue is a great > idea, it still adds complexity). There's proof for our assertions, but all > I'm hearing from you guys is handwaving. I don't think any one has said dynamic / is faster. > And I'm _not_ trying to be insulting or condescending. I've done > handwaving myself in the past, but I try to be aware of it and only do it > when I can justify it. In this case, the handwaving is in place of real > evidence. So, how much does it help? How _many_ users will it benefit, in > general? Sure, it doesn't matter for a webserver that runs httpd or for a > database server that does nothing but run Postgresql, but those cases are > irrelevant to the issue of a dynamically-linked root. They are affected > neither way. It is people who run a variety of applications that will be > affected, either good or bad. > So, we've seen data about the performance hit. What about data about > improved performance or improved function in some other way? What is > the compelling reason to move to a dynamic root? > > So far I've seen no argument that was even convincing, let alone > compelling. Re-read -current, and the commit messages around this whole thing. -- 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: 40% slowdown with dynamic /bin/sh
In message: <[EMAIL PROTECTED]> "David O'Brien" <[EMAIL PROTECTED]> writes: : What qualifies as a "concrete, real benchmark"? I take it you don't : think Drew's qualifies. No. forkbomds are realworld. 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
On Mon, Nov 24, 2003 at 07:19:31PM -0700, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Andrew Gallatin <[EMAIL PROTECTED]> writes: > : > : M. Warner Losh writes: > : > In message: <[EMAIL PROTECTED]> > : > Andrew Gallatin <[EMAIL PROTECTED]> writes: > : > : I'll bet a larger percentage of our users build ports than need nss or > : > : ldap. > : > > : > I'll bet a larger percentage of the people are ignoring this thread > : > than reading it since it has been so devoid of concrete numbers. > : > : Aside from $SUBJECT.. > > I'm just saying that most of the developers I'm talking to on IRC say > this tread is insane, has no content and they are blowing it off > because of that. A concrete, real benchmark will go a long way > towards changing that. Until then, you are as good as kill filed. What qualifies as a "concrete, real benchmark"? I take it you don't think Drew's qualifies. -- -- David ([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
On 25-Nov-2003 Nate Lawson wrote: > > Someone more familiar with ithread_loop should probably answer this. One > workaround might be to enable ACPI_NO_SEMAPHORES on your box. I built and booted a kernel with ACPI_NO_SEMAPHORES, but it still hangs at the same point in the boot. The stack trace is attached. It looks pretty similar to the others. John sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% ~Stopped at siointr1+0xec: jmp siointr1+0x220 db> trace siointr1(c298e000,0,c06c9567,6a0,cdb61b58) at siointr1+0xec siointr(c298e000,cdb61bf4,c045a145,c12a0de4,4) at siointr+0x35 intr_execute_handlers(c129f88c,cdb61b70,cdb61bd8,c065c5a3,34) at intr_execute_ha ndlers+0xc8 lapic_handle_intr(34) at lapic_handle_intr+0x3a Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc0457d70, esp = 0xcdb61bb4, ebp = 0xcdb61bd8 --- AcpiNsGetNextNode(bbc5,cdb61bf4,c044a8b7,c12a0c00,0) at AcpiNsGetNextNode AcpiDsTerminateControlMethod(c12a0c00,c2959700,cdb61c14,c12a0c00,c12a0de4) at Ac piDsTerminateControlMethod+0xed AcpiPsParseAml(c12a0c00,c294fcc0,c2951aa0,ce5b5ac0,d) at AcpiPsParseAml+0x15b AcpiPsxExecute(c2951aa0,0,cdb61c9c,c2951aa0,0) at AcpiPsxExecute+0x202 AcpiNsExecuteControlMethod(c2951aa0,0,cdb61c9c,c0702694,c294dedc) at AcpiNsExecu teControlMethod+0x5f AcpiNsEvaluateByHandle(c2951aa0,0,0,76,c2951aa0) at AcpiNsEvaluateByHandle+0x96 AcpiEvAsynchExecuteGpeMethod(c294dedc,0,c06a6f81,7b,0) at AcpiEvAsynchExecuteGpe Method+0x8c acpi_task_thread(0,cdb61d48,c06b6d35,311,2e636466) at acpi_task_thread+0x105 fork_exit(c0474e20,0,cdb61d48) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcdb61d7c, ebp = 0 --- ___ [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
On Mon, 24 Nov 2003, Frank Mayhar wrote: > Daniel O'Connor wrote: > > You DO know FreeBSD is a cooperative project right? > > Of course I do. I was using it when it was just 386BSD 0.1 and a patchkit. > I've watched it through a lot of changes and while I've never been a part > of the team, mostly due to lack of time, I try to throw whatever I can at > it when I'm able. > > On the _other_ hand: > > > I hardly think you're in a position to complain about a (probably very minor) > > performance loss which has a trivial work around, which also benefits a fair > > number of users. > > _This_ is the issue. You assert that this change "benefits a fair number > of users." I and others assert that it hurts performance and makes disaster > recovery more complex (while the existence of /rescue is a great idea, it > still adds complexity). There's proof for our assertions, but all I'm > hearing from you guys is handwaving. > > And I'm _not_ trying to be insulting or condescending. I've done handwaving > myself in the past, but I try to be aware of it and only do it when I can > justify it. In this case, the handwaving is in place of real evidence. > So, how much does it help? How _many_ users will it benefit, in general? > Sure, it doesn't matter for a webserver that runs httpd or for a database > server that does nothing but run Postgresql, but those cases are irrelevant > to the issue of a dynamically-linked root. They are affected neither way. > It is people who run a variety of applications that will be affected, > either good or bad. > > So, we've seen data about the performance hit. What about data about > improved performance or improved function in some other way? What is > the compelling reason to move to a dynamic root? Ok, I've about had it with this thread. Please look at the beginning of the argument last week where I CLEARLY layed out the benefits of dynamic root. If you want me to go around the globe and take a count of every person that might be benfited by it, please offer me a salary to do so. Otherwise, I really don't want to hear any more statements like above. > > So far I've seen no argument that was even convincing, let alone compelling. I supported the decision because: 1. It has been requested for years 2. It benefits PAM and NSS. 3. It is easy to revert. If you want more details on those three points, please go back and re-read your email. Now please move along and revert it on your local system. There are far too many REAL problems out there that need to be addressed so that 5.2 can go out the door. This is just wasting time and energy. Scott ___ [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
On Tue, 25 Nov 2003 03:26:14 +0100 Clement Laforet <[EMAIL PROTECTED]> wrote: :27 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LUCIFER i386 Forget about it :-) Next time i should think befor posting ;-) sorry for the noise clem ___ [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
M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Andrew Gallatin <[EMAIL PROTECTED]> writes: : I'll bet a larger percentage of our users build ports than need nss or : ldap. I'll bet a larger percentage of the people are ignoring this thread than reading it since it has been so devoid of concrete numbers. Amen! More benchmarks, less speculation, please. Since both variants are already implemented, any argument lacking measurements is weak. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Unfortunate dynamic linking for everything
Richard Coleman <[EMAIL PROTECTED]> writes: > Are you suggesting that (t)csh also move to /usr/bin to match > /usr/bin/sh? The screams caused by such a change would be deafening. Would there be any screams at all? chsh -s /bin/sh root# prevent lock-out rm -f /bin/csh /bin/tcsh echo NO_TCSH=true >>/etc/make.conf # avoid resurrection of evil # next "make world" Looks that a system without [t]csh is supported. And it works for me. -- 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: HEADS UP: /bin and /sbin are now dynamically linked
Richard Coleman wrote: I think a better compromise is to add the make.conf option so that extra utilities may be added to /rescue. As David already pointed out, this is not entirely trivial. Adding the programs isn't difficult, but it requires adjusting library includes, which would be tricky to do automatically. In addition, a surprising number of programs require minor source edits to function correctly in /rescue. In particular, many programs have hard-coded references to specific programs in /bin and /sbin. I spent a long time tracking down such references and replacing them with references to /rescue where appropriate. Without those changes, /rescue will work correctly only if /bin and /sbin are functional. There is a real potential for landmines here. With the size of disk drives these days, (for my own setup) I'm tempted to just add a complete copy of /bin and /sbin into /rescue. There's surprisingly little of /bin and /sbin that isn't already in /rescue. Most of what's omitted was left out for very straightforward reasons (e.g., tcsh is clearly redundant, devd is incompatible with crunchgen, etc.) The debate right now is over what programs from /usr/bin and /usr/sbin should be included. Right now, that includes tar, gzip, bzip2, and vi/ex. Tim Kientzle ___ [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
On Tue, 25 Nov 2003 12:14:23 +1030 "Daniel O'Connor" <[EMAIL PROTECTED]> wrote: > > 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. you can use put SH=/rescue/sh in your make.conf if you think it can have an impact... [EMAIL PROTECTED]|(501)| kde3]# ldd /bin/sh /bin/sh: libedit.so.4 => /lib/libedit.so.4 (0x28094000) libncurses.so.5 => /lib/libncurses.so.5 (0x280a9000) libc.so.5 => /lib/libc.so.5 (0x280e8000) [EMAIL PROTECTED]|(502)| kde3]# ldd /rescue/sh ldd: /rescue/sh: not a dynamic executable [EMAIL PROTECTED]|(503)| kde3]# time make clean SH=/bin/sh real0m45.019s user0m20.657s sys 0m18.339s [EMAIL PROTECTED]|(504)| kde3]# time make clean SH=/rescue/sh real0m45.476s user0m20.892s sys 0m18.131s [EMAIL PROTECTED]|(505)| kde3]# uname -ar FreeBSD lucifer.cultdeadsheep.org 5.2-BETA FreeBSD 5.2-BETA #0: Sat Nov 22 21:09:27 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LUCIFER i386 clem ___ [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
On Nov 24, 2003, at 8:09 PM, M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Andrew Gallatin <[EMAIL PROTECTED]> writes: : I'll bet a larger percentage of our users build ports than need nss or : ldap. I'll bet a larger percentage of the people are ignoring this thread than reading it since it has been so devoid of concrete numbers. 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. Dave Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[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
In message: <[EMAIL PROTECTED]> Andrew Gallatin <[EMAIL PROTECTED]> writes: : : M. Warner Losh writes: : > In message: <[EMAIL PROTECTED]> : > Andrew Gallatin <[EMAIL PROTECTED]> writes: : > : I'll bet a larger percentage of our users build ports than need nss or : > : ldap. : > : > I'll bet a larger percentage of the people are ignoring this thread : > than reading it since it has been so devoid of concrete numbers. : : Aside from $SUBJECT.. I'm just saying that most of the developers I'm talking to on IRC say this tread is insane, has no content and they are blowing it off because of that. A concrete, real benchmark will go a long way towards changing that. Until then, you are as good as kill filed. I don't say this to be mean or nasty. I'm just saying that people are sick to death of the arguing without any real facts. 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
Daniel O'Connor wrote: > You DO know FreeBSD is a cooperative project right? Of course I do. I was using it when it was just 386BSD 0.1 and a patchkit. I've watched it through a lot of changes and while I've never been a part of the team, mostly due to lack of time, I try to throw whatever I can at it when I'm able. On the _other_ hand: > I hardly think you're in a position to complain about a (probably very minor) > performance loss which has a trivial work around, which also benefits a fair > number of users. _This_ is the issue. You assert that this change "benefits a fair number of users." I and others assert that it hurts performance and makes disaster recovery more complex (while the existence of /rescue is a great idea, it still adds complexity). There's proof for our assertions, but all I'm hearing from you guys is handwaving. And I'm _not_ trying to be insulting or condescending. I've done handwaving myself in the past, but I try to be aware of it and only do it when I can justify it. In this case, the handwaving is in place of real evidence. So, how much does it help? How _many_ users will it benefit, in general? Sure, it doesn't matter for a webserver that runs httpd or for a database server that does nothing but run Postgresql, but those cases are irrelevant to the issue of a dynamically-linked root. They are affected neither way. It is people who run a variety of applications that will be affected, either good or bad. So, we've seen data about the performance hit. What about data about improved performance or improved function in some other way? What is the compelling reason to move to a dynamic root? So far I've seen no argument that was even convincing, let alone compelling. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [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
M. Warner Losh writes: > In message: <[EMAIL PROTECTED]> > Andrew Gallatin <[EMAIL PROTECTED]> writes: > : I'll bet a larger percentage of our users build ports than need nss or > : ldap. > > I'll bet a larger percentage of the people are ignoring this thread > than reading it since it has been so devoid of concrete numbers. Aside from $SUBJECT.. Drew ___ [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
In message: <[EMAIL PROTECTED]> Andrew Gallatin <[EMAIL PROTECTED]> writes: : I'll bet a larger percentage of our users build ports than need nss or : ldap. I'll bet a larger percentage of the people are ignoring this thread than reading it since it has been so devoid of concrete numbers. 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
In a message written on Tue, Nov 25, 2003 at 12:12:59PM +1030, Daniel O'Connor wrote: > If you have a file, web, mail, database, etc server it's predominant > application is already dynamically linked. It just occured to me what bothers me about this line of thinking, since several people have brought it up. When I run kwrite, or Mozilla, or any number of other dynamic apps they are relatively long lived. My database loads (eg, pays the dynamic link penalty) once at startup. By contrast /bin/sh is run often. 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. I don't suggest I am representative, but for all those with process accounting turned on you have the commands above, check it out. > If you are deploying FreeBSD on servers you should build your own release > anyway (which is hardly an onerous task). What? Did you read what you wrote? It was a stand alone paragraph, I didn't take it out of context. People who use FreeBSD on servers should build their own release? That's so nutz I don't know where to start to attack it. I think I'll leave it to the third point from www.freebsd.org: ] FreeBSD makes an ideal Internet or Intranet server. It provides robust ] network services under the heaviest loads and uses memory efficiently to ] maintain good response times for thousands of simultaneous user ] processes. Visit our gallery for examples of FreeBSD powered ] applications and services. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
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. ___ [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
On Tuesday 25 November 2003 12:23, Frank Mayhar wrote: > > Let's see. You dislike the dynamic root decision enough that > > you are considering the abandonment of FreeBSD. Then when > > you're told that you can still build a static root if you > > need/want it, you make a sarcastic remark. > > It wasn't sarcastic, it was serious. Needing to have special configuration > defeats the purpose of running FreeBSD for me. I'm busy enough that I > don't have time to deal with everything _now_; adding something else I have > to keep track of for a half-dozen systems is something else I just don't > need. You DO know FreeBSD is a cooperative project right? I hardly think you're in a position to complain about a (probably very minor) performance loss which has a trivial work around, which also benefits a fair number of users. -- 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: 40% slowdown with dynamic /bin/sh
I'm not going to add to the heat in the rest of the email, but this is a very good question: Daniel O'Connor wrote: > Why didn't you pipe up when this was discussed _long_ ago? Honestly, I don't remember the discussion. It's certainly possible that I may have missed it. I just dug around in the -current archives and couldn't find the it, but my life has been kind of chaotic over the last year or so. In fact, if it happened about a year ago, it could well have taken place while I was in China for three weeks. Believe me, if I had encountered the discussion when it took place, I would have made my feelings known. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [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
Richard Coleman writes: > Are you suggesting that (t)csh also move to /usr/bin to match > /usr/bin/sh? The screams caused by such a change would be deafening. Of course not. Nobody in their right mind uses csh for scripting. Drew ___ [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
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. > Why didn't you pipe up when this was discussed _long_ ago? In the orginal thread, there was an agreement that the performance would be measured BEFORE the default was changed, and the default would only be changed if there was no measurable performance impact. I believe sam@ asked for this. As far as I know, performance measurments were never done. Instead, the switch was thrown just before the code freeze. > > If you are deploying FreeBSD on servers you should build your own release > anyway (which is hardly an onerous task). > Its pretty hard to use the binary update tools that way. Drew ___ [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
Steve Kargl wrote: > On Mon, Nov 24, 2003 at 05:06:52PM -0800, Frank Mayhar wrote: > > Kind of defeats the purpose, don't you think? > Let's see. You dislike the dynamic root decision enough that > you are considering the abandonment of FreeBSD. Then when > you're told that you can still build a static root if you > need/want it, you make a sarcastic remark. It wasn't sarcastic, it was serious. Needing to have special configuration defeats the purpose of running FreeBSD for me. I'm busy enough that I don't have time to deal with everything _now_; adding something else I have to keep track of for a half-dozen systems is something else I just don't need. "Cake" remark elided. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [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
Daniel O'Connor writes: > 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. > I'll bet a larger percentage of our users build ports than need nss or ldap. Drew ___ [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
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. -- 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: HEADS UP: /bin and /sbin are now dynamically linked
Tim Kientzle wrote: David O'Brien wrote: On Mon, Nov 24, 2003 at 12:08:58PM -0800, Tim Kientzle wrote: ... I think [/rescue] only needs to support those recovery actions necessary to repair /bin and /sbin if they break. My stance is that no failure mode needs to be repairable that wasn't repairable with a static /. I'm willing to compromise, David. Here's what I suggest: * I could support removing vi/ex from /rescue. * In exchange for this concession, would you be willing to support adding fetch? I expect this exchange would result in a net 150-200 kB savings in /rescue. How about it? Tim I think a better compromise is to add the make.conf option so that extra utilities may be added to /rescue. Then leave both vi and fetch out of the default. With the size of disk drives these days, (for my own setup) I'm tempted to just add a complete copy of /bin and /sbin into /rescue. The extra 100 meg doesn't take much out of a 80 gig hard drive. Richard Coleman [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
On Tuesday 25 November 2003 11:36, Frank Mayhar wrote: > Daniel O'Connor wrote: > > What _REAL WORLD_ task does this slow down? > > I think the point was that, in this particular "worst" case, it's a forty > percent performance hit. What's the average case? What's the case for a > "real world" pipeline with a lot of tiny little static binaries? > > I dislike this decision enough that I'm actually considering going away > from FreeBSD, something I really had never for a moment thought possible. > It's even worse that you deride someone who tried to shed a little light > on the discussion. It is _trivial_ to buildworld with a static root. > The performance hit is real. Even if it's not forty percent it's worth > consideration, no matter how much you may want to shout down those who > disagree. Of course it's real! I am not disputing that. It's just that I believe most people don't run /bin/sh so much it matters. If they do, then building it static is simple. > > My production systems don't spin in infinite loops spawning shell > > processes which die straight away. > > Uh, _huh_. Well, can you _imagine_ a scenario in which a "production > system" might actually do something along those lines? _I_ can. Think a > system of shell scripts. Sigh. Surely you don't run /bin/sh so frequently it has an appreciable impact.. Again, if you do, buildworld with static binaries. System shell scripts run mostly at boot, this is not what the PC spends most of it's time doing. If you have a file, web, mail, database, etc server it's predominant application is already dynamically linked. > I can guarantee you that you have no idea _at all_ what is "of relevance to > most users of FreeBSD." It is nearly axiomatic that developers cannot > imagine the uses to which their users put their systems. I'm not a committer, I use FreeBSD and I submit PRs. Perhaps we should run a survey to determine what > > If it is for you then just build your world with static root. > > Kind of defeats the purpose, don't you think? ?! Not really, if you want the performance back, then build statically. > Feh. This is utterly ridiculous. Yeah, I understand why you guys made > the decision. It's the same set of reasons a lot of other people in the > past have made the same or similar decisions. We'll see if you get burned > by it, as many of those other people were. Why didn't you pipe up when this was discussed _long_ ago? I don't understand why you can't buildworld with static slash if you feel so strongly about it. If you are deploying FreeBSD on servers you should build your own release anyway (which is hardly an onerous task). -- 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: 40% slowdown with dynamic /bin/sh
On Monday 24 November 2003 05:25 pm, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > > Dan Nelson <[EMAIL PROTECTED]> writes: > : In the last episode (Nov 25), Daniel O'Connor said: > : > On Tuesday 25 November 2003 06:45, Andrew Gallatin wrote: > : > > So.. forking a dynamic sh is roughly 40% more expensive than > : > > forking a static copy of sh. This is embarrassing. > : > > > : > > I propose that we at least make /bin/sh static. (and not add a > : > > /sbin/sh; if we must have a dynamic sh, import pdksh, or put a > : > > dynamically linked sh in /usr/bin/sh). > : > > > : > > 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. > > Maybe you could try it with both and tell us the actual difference in > wall time? I don't see why this surprises anyone. A dynamic shell has to be the equivalent of swapping. In situations I have been in, you can only improve on static if you have a way to leave the pieces memory resident. Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
serial console trouble
I'm putting together a ipf/ipnat gateway for a friend using his abit BX (rev2) motherboard. I'd very much to get serial console working before tendering it over; but am having zero luck. The world/kernel deployed to this box is from my NFS host box (which runs the same kernel/world, and whose serial console works fine). The only thing that seems odd to me is that dmesg doesn't report the appropriate flags (0x10) despite them being in device.hints. Nevertheless, I should still be able to use the serial port as a login terminal give my ttys; but even that doesn't work. Anyone see anything awry here ? Anything I should try ? I've tried disabling acpi in the bios to no avail; switching on/off PNP in the bios to no avail; switching from auto to hard-set port settings in the bios to no avail. Lengthy verbose boot follows as well as kernel config. # uname -a FreeBSD test.robinpb.home 5.2-BETA FreeBSD 5.2-BETA #0: Mon Nov 24 14:41:28 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/vpn.ule i386 # fgrep COMCONSOLE /etc/make.conf BOOT_COMCONSOLE_SPEED=19200 # fgrep ttyd0 /etc/ttys ttyd0 "/usr/libexec/getty std.19200" unknown on secure # fgrep sio.0 /boot/device.hints hint.sio.0.at="isa" hint.sio.0.port="0x3F8" hint.sio.0.flags="0x10" hint.sio.0.irq="4" # cat /var/run/dmesg.boot 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: Mon Nov 24 14:41:28 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/vpn.ule Preloaded elf kernel "/boot/kernel/kernel" at 0xc07a8000. Preloaded elf module "/boot/modules/linux.ko" at 0xc07a81f4. Preloaded elf module "/boot/modules/if_de.ko" at 0xc07a82a0. Preloaded elf module "/boot/modules/accf_data.ko" at 0xc07a834c. Preloaded elf module "/boot/modules/accf_http.ko" at 0xc07a83fc. Calibrating clock(s) ... i8254 clock: 1193269 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 412365212 Hz CPU: Pentium II/Pentium II Xeon/Celeron (412.37-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x653 Stepping = 3 Features=0x183f9ff real memory = 134152192 (127 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00829000 - 0x07d89fff, 123080704 bytes (30049 pages) avail memory = 124874752 (119 MB) bios32: Found BIOS32 Service Directory header at 0xc00faf00 bios32: Entry = 0xfb380 (c00fb380) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb3b0 pnpbios: Found PnP BIOS data at 0xc00fbfd0 pnpbios: Entry = f:bff8 Rev = 1.0 Other BIOS signatures found: null: mem: Pentium Pro MTRR support enabled random: acpi0: on motherboard 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 Using $PIR table, 7 entries at 0xc00fdf00 PCI-Only Interrupts: 10 11 Location Bus Device Pin Link IRQs slot 1 0 15A 0x60 3 4 5 7 9 10 11 12 14 15 slot 1 0 15B 0x61 3 4 5 7 9 10 11 12 14 15 slot 1 0 15C 0x62 3 4 5 7 9 10 11 12 14 15 slot 1 0 15D 0x63 3 4 5 7 9 10 11 12 14 15 slot 2 0 13A 0x61 3 4 5 7 9 10 11 12 14 15 slot 2 0 13B 0x62 3 4 5 7 9 10 11 12 14 15 slot 2 0 13C 0x63 3 4 5 7 9 10 11 12 14 15 slot 2 0 13D 0x60 3 4 5 7 9 10 11 12 14 15 slot 3 0 11A 0x62 3 4 5 7 9 10 11 12 14 15 slot 3 0 11B 0x63 3 4 5 7 9 10 11 12 14 15 slot 3 0 11C 0x60 3 4 5 7 9 10 11 12 14 15 slot 3 0 11D 0x61 3 4 5 7 9 10 11 12 14 15 slot 4 09A 0x63 3 4 5 7 9 10 11 12 14 15 slot 4 09B 0x60 3 4 5 7 9 10 11 12 14 15 slot 4 09C 0x61 3 4 5 7 9 10 11 12 14 15 slot 4 09D 0x62 3 4 5 7 9 10 11 12 14 15 slot 5 0 17A 0x63 3 4 5 7 9 10 11 12 14 15 slot 5 0 17B 0x60 3 4 5 7 9 10 11 12 14 15 slot 5 0 17C 0x61 3 4 5 7 9 10 11 12 14 15 slot 5 0 17D 0x62 3 4 5 7 9 10 11 12 14 15 embedded07A 0x60 3 4 5 7 9 10 11 12 14 15 embedded07B 0x61 3 4 5 7 9 10 11 12 14 15 embedded07C 0x62 3 4 5 7 9 10 11 12 14 15 embedded07D 0x63 3 4 5 7 9 10 11 12 14 15 embedded01A 0x60 3 4 5 7 9 10 11 12 14 15 embedded01B 0x61 3 4 5 7 9 10 11 12 14 15 embedded01C 0x62 3 4 5 7 9 10 11 12 14 15 embedded01D 0x63 3 4 5 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: Power Button (fixed) ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks
Re: Unfortunate dynamic linking for everything
Andrew Gallatin wrote: So I think the best solution (*) would be to keep /bin/sh statically linked, and build a dynamic version in /usr/bin that people can use as an interactive shell. Root's shell remains /bin/sh 1) All three (;-) interactive bourne shell users that use nss/ldap get tilde expansion. 2) 3rd party scripts, which are written to be portable and don't use tilde, don't have to pay for dynamic linking. 3) System startup scripts are faster because they use the static /bin/sh Are you suggesting that (t)csh also move to /usr/bin to match /usr/bin/sh? The screams caused by such a change would be deafening. Richard Coleman [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
In message: <[EMAIL PROTECTED]> Dan Nelson <[EMAIL PROTECTED]> writes: : In the last episode (Nov 25), Daniel O'Connor said: : > On Tuesday 25 November 2003 06:45, Andrew Gallatin wrote: : > > So.. forking a dynamic sh is roughly 40% more expensive than : > > forking a static copy of sh. This is embarrassing. : > > : > > I propose that we at least make /bin/sh static. (and not add a : > > /sbin/sh; if we must have a dynamic sh, import pdksh, or put a : > > dynamically linked sh in /usr/bin/sh). : > > : > > 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. Maybe you could try it with both and tell us the actual difference in wall time? 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
In the last episode (Nov 25), Daniel O'Connor said: > On Tuesday 25 November 2003 06:45, Andrew Gallatin wrote: > > So.. forking a dynamic sh is roughly 40% more expensive than > > forking a static copy of sh. This is embarrassing. > > > > I propose that we at least make /bin/sh static. (and not add a > > /sbin/sh; if we must have a dynamic sh, import pdksh, or put a > > dynamically linked sh in /usr/bin/sh). > > > > 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. -- Dan Nelson [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
Daniel O'Connor wrote: > What _REAL WORLD_ task does this slow down? I think the point was that, in this particular "worst" case, it's a forty percent performance hit. What's the average case? What's the case for a "real world" pipeline with a lot of tiny little static binaries? I dislike this decision enough that I'm actually considering going away from FreeBSD, something I really had never for a moment thought possible. It's even worse that you deride someone who tried to shed a little light on the discussion. The performance hit is real. Even if it's not forty percent it's worth consideration, no matter how much you may want to shout down those who disagree. > My production systems don't spin in infinite loops spawning shell processes > which die straight away. Uh, _huh_. Well, can you _imagine_ a scenario in which a "production system" might actually do something along those lines? _I_ can. Think a system of shell scripts. > If yours do, well.. curious, but I hardly think it is of relevance to most > users of FreeBSD. I can guarantee you that you have no idea _at all_ what is "of relevance to most users of FreeBSD." It is nearly axiomatic that developers cannot imagine the uses to which their users put their systems. > If it is for you then just build your world with static root. Kind of defeats the purpose, don't you think? Feh. This is utterly ridiculous. Yeah, I understand why you guys made the decision. It's the same set of reasons a lot of other people in the past have made the same or similar decisions. We'll see if you get burned by it, as many of those other people were. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ [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
At 3:15 PM -0500 11/24/03, Andrew Gallatin wrote:
Here is a simple test which times the execution of a null
shell script. It basically times fork/exec of the chosen
shell.
So.. forking a dynamic sh is roughly 40% more expensive
than forking a static copy of sh. This is embarrassing.
To be more precise: shell scripts which do-nothing will
be 40% more expensive than they used to be. It is not
like the entire operating system will get 40% slower.
I propose that we at least make /bin/sh static.
I suggest that we leave all of /bin and /sbin as it is for
5.2-release. We are still telling users that 5.2 is a
snapshot of "-current", and it is more valuable to have a
wider range of experience with this worst-case scenario.
("worst-case" == all files dynamically linked).
We certainly may want to make changes to address the
performance issues that you note, but there is no reason
we must decide *which* change should be made right now.
--
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: 40% slowdown with dynamic /bin/sh
On Tuesday 25 November 2003 06:45, Andrew Gallatin wrote: > So.. forking a dynamic sh is roughly 40% more expensive than > forking a static copy of sh. This is embarrassing. > > I propose that we at least make /bin/sh static. (and not add a > /sbin/sh; if we must have a dynamic sh, import pdksh, or put a > dynamically linked sh in /usr/bin/sh). > > 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? My production systems don't spin in infinite loops spawning shell processes which die straight away. If yours do, well.. curious, but I hardly think it is of relevance to most users of FreeBSD. If it is for you then just build your world with static root. -- 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: PII SMP system hangs during boot with ACPI enabled
On Mon, 24 Nov 2003, John Polstra wrote: > On 24-Nov-2003 Nate Lawson wrote: > > > > Trace 1: > > wakeup(c2944100,0,c06a7546,140,6c) at wakeup+0x4 > > AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xa8 > > AcpiUtReleaseMutex(9,30,c295e8c0,c295e760,cdb64acc) at AcpiUtReleaseMutex+0x8c > > AcpiUtReleaseToCache(3,c295e760,cdb64ad8,c045ac17,c295e760) at > > AcpiUtReleaseToCache+0x8c > > > > Trace 2: > > _mtx_unlock_flags(c2944100,0,c06a7546,150,6c) at _mtx_unlock_flags+0x96 > > AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xc8 > > AcpiUtReleaseMutex(9,8,c045f9cc,c2965940,c12a0c00) at AcpiUtReleaseMutex+0x8c > > AcpiUtAcquireFromCache(2,cdb64bf4,c0462229,c12a0c00,cdb64c34) at > > AcpiUtAcquireFromCache+0x53 > > > > Both of these show that acpi_task_thread is calling a task and then > > AcpiOsSignalSemaphore is hanging. I'm wondering if your system can't > > handle the acpi interrupt being moved to irq 20. Please try this > > (untested) patch that should disable moving the SCI to irq 20. > > As I mentioned a minute ago, the patch didn't help. But I grabbed > another stack trace while I was at it. This one is quite different > from the others. I don't think it's different because of your > patch, though. I saw one like this earlier, but thought it might > have been an anomaly caused by my own mucking around in DDB. > > siointr1(c298d000,0,c06c9b97,6a0,cdb5ec70) at siointr1+0xec > siointr(c298d000,c053a016,c06d88a0,c06e7ae0,4) at siointr+0x35 > intr_execute_handlers(c129f88c,cdb5ec88,cdb5eccc,c065ca43,34) at > intr_execute_handlers+0xc8 > lapic_handle_intr(34) at lapic_handle_intr+0x3a > Xapic_isr1() at Xapic_isr1+0x33 > --- interrupt, eip = 0xc053a4ea, esp = 0xcdb5eccc, ebp = 0xcdb5eccc --- > critical_exit(c070af20,1,c06b8c37,14b,0) at critical_exit+0x2a > _mtx_unlock_spin_flags(c070af20,0,c06b74f7,23a,c294954c) at > _mtx_unlock_spin_flags+0x9d > ithread_loop(c12a6800,cdb5ed48,c06b7365,311,0) at ithread_loop+0x26e > fork_exit(c0520150,c12a6800,cdb5ed48) at fork_exit+0xb4 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xcdb5ed7c, ebp = 0 --- Someone more familiar with ithread_loop should probably answer this. One workaround might be to enable ACPI_NO_SEMAPHORES on your box. -Nate ___ [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
David O'Brien wrote: On Mon, Nov 24, 2003 at 12:08:58PM -0800, Tim Kientzle wrote: ... I think [/rescue] only needs to support those recovery actions necessary to repair /bin and /sbin if they break. My stance is that no failure mode needs to be repairable that wasn't repairable with a static /. I'm willing to compromise, David. Here's what I suggest: * I could support removing vi/ex from /rescue. * In exchange for this concession, would you be willing to support adding fetch? I expect this exchange would result in a net 150-200 kB savings in /rescue. How about it? Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS lockup issues and xl0 watchdog timeout
I've had a possible idea regarding the NFS issues. I'm wondering if perhaps my NFS issues are related to the other email thread I have going which is the xl0: watchdog timeouts etc. I had not noticed this until last week because it's not often I copy large files from one machine to another but doing an ftp/scp etc from one machine to the other I'm only getting 100KB/sec with a PUT from my nfsclient->nfsserver, and 6MB/sec with a GET. This used to go at 9-10MB/sec both ways. Thinking about it I think this started happening around the same time I started having NFS issues. My NFS issues are also only when writing to the server from the client, never the other way around. So this ties up with the throughput figure difference I get on FTP. Jimmy mentioned a watchdog timeout caused by what looked like a 10-15 second delay in a buffer going from userland to kernel? I guess if this is the case it could kill NFS as well. Tomorrow night I will change my xl0 card in this desktop for a spare realtek card I happen to have and test throughput and NFS. I'll let you know my results. It would be interesting to see if the other person who reported these NFS issues (soren) has a similar experience. Matt. ___ [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??
> 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. -- 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: xl0: watchdog timeout
Matt Smith wrote: Matt Smith wrote: Jimmy Selgen wrote: On Fri, 2003-11-21 at 21:29, Kris Kennaway wrote: On Fri, Nov 21, 2003 at 09:22:49PM +0100, Jimmy Selgen wrote: I saw this with some of sam's locking changes that (temporarily) broke DUMMYNET. I see you're using ipfilter - it's possible that this configuration has not been well-tested. Are you passing much traffic through ipfilter on this box? The box in question is my workstation, so I guess i'm not passing that much traffic through ipfilter. Also, when I said that the NIC still worked, I might have mislead you a bit. I had about 5-10 timeouts while scp'ing the dmesg output to my other workstation. Data seems to move from userland to the kernel, then get stuck in buffers there for 10-15 seconds, "generating" timeouts, before they're shipped off. I assume this is expected behaviour when a NIC isnt behaving correctly. It would be helpful if you can do a binary search to narrow down when the problem started. What would you have me search ? I'm a faily seasoned C programmer (12 years experience, some of them doing RTOS kernel work), but dont know much about FreeBSD kernel development, or the process of checking out different kernel revisions. I've tried a build without IPFILTER, and the problem still exists. I've also tried booting with ACPI disabled, and the problem is still there. I have attached a copy of my kernel config file, in case i'm doing something wrong. I have just noticed that my xl0 card is misbehaving as well. I have a 3c905c in my desktop and noticed that an ftp of a file from another machine on the lan (100 meg switched) was only going at around 70KB/sec. Normally I get around 9MB/sec. A netstat -bi xl0 shows lots of errors: NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll xl01500 00:04:76:8d:c5:fd 3081878 217616 3778632119 2451968 6 368229701 0 I also have this in my messages file: xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 180 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 240 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 300 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 360 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 420 bytes I do not currently have any debugging options compiled into this kernel. FreeBSD fraggle.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Nov 18 20:05:52 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FRAGGLE i386 I am actually in the process of building a new world/kernel to update it again as I thought it might be something that's fixed. I unfortunatly can not boot the old kernel to see if it works fine in that because of the statfs changes so it *could* possibly be the NIC has gone funny. I also have a 3c905a and a 3c905b in my router machine and this is showing no issues at all with the same dated kernel. http://xtaz.net/ Matt. I am now running a 5.2-BETA kernel from today and still have the problem with my xl0 card here. I can only get a max throughput of around 110KB/sec through it. And I am getting huge amounts of errors in the interface stats (5 minutes after booting): NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll xl01500 00:04:76:8d:c5:fd 217042 1290 57669634 309460 0 208178476 0 So the question is, is this my network card has died and I need to throw it out or is it related to Jimmy Selgen's email about the watchdog timeouts? It's a shame I can't boot an old kernel to test really. Matt. I have done some testing on this. I've changed the network cable, switch port etc. No affect. I've found though that if I ftp this box and GET a file it goes at around 6MB/sec. But if I PUT a file it goes at 100KB/sec. Previously this has worked at around 9-10MB/sec both ways. I can't place a date on it though because I've not tried to do large file transfers for a long time and only just noticed it this week. So it looks like it is driver related I guess. The "buffer" scenario Jimmy reported looks likely. Matt. ___ [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
> So.. forking a dynamic sh is roughly 40% more expensive than > forking a static copy of sh. This is embarrassing. read the original paper carefully: http://citeseer.nj.nec.com/cache/papers/cs/3066/http:zSzzSzswt-www.informatik.uni-hamburg.dezSz~1friedrizSzsvzSzreferenceszSzShared_Libraries_In_Sun_OS.pdf/gingell87shared.pdf it's conclusions state that they are slower. this was the _original paper_ that announced the damn things. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB 1.0 IDE to ATAPI drive enclosure failure
On Mon, Nov 24, 2003 at 03:35:42PM -0700, M. Warner Losh wrote: > : Why hasn't anything been committed? > > Code freeze? I understand the concept, but I haven't seen any reports of people claiming that OHCI works for other than mice/keyboards without the following patch (from "Brian F. Feldman" <[EMAIL PROTECTED]>): --- ohci.c 12 Nov 2003 01:40:11 - 1.138 +++ ohci.c 22 Nov 2003 03:28:42 - @@ -569,7 +569,7 @@ cur->td.td_cbp = htole32(dataphys); cur->nexttd = next; cur->td.td_nexttd = htole32(next->physaddr); - cur->td.td_be = htole32(DMAADDR(dma, curlen - 1)); + cur->td.td_be = htole32(DMAADDR(dma, offset + curlen - 1)); cur->len = curlen; cur->flags = OHCI_ADD_LEN; cur->xfer = xfer; It cured my problems with a Sony DSC F707. Maybe most people with OHCI controllers haven't had problems, but if so they've been quietly satisfied. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [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
On Mon, Nov 24, 2003 at 03:33:49PM -0700, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Stefan Farfeleder <[EMAIL PROTECTED]> writes: > : On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote: > : > From: "Jacques A. Vidrine" <[EMAIL PROTECTED]> > : > > The application is broken. You must only check errno if you get an > : > > error indication from the library call. > : > > : > errno is only meaningful after a syscall error. > : > : Wrong, counter-example: strtol(). > > 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). If that's a misinterpretation, I'm sorry. Stefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB 1.0 IDE to ATAPI drive enclosure failure
This is interesting: [17:[EMAIL PROTECTED]:[~]# camcontrol devlist at scbus1 target 0 lun 0 (da0,pass0) [17:[EMAIL PROTECTED]:[~]# camcontrol inquiry 1:0:0 pass0: Fixed Direct Access SCSI-0 device pass0: Serial Number pass0: 1.000MB/s transfers So it looks like it's just not recognizing the file system on da0. Perhaps I should try `camcontrol format`? It would probably take for ever to format a 32Gb disk over a 1M link, but I could leave it on over night... I originally formatted this disk by putting it in my primary drive sled in my laptop and running a partitioning program... -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [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
On Mon, Nov 24, 2003 at 04:07:49PM -0500, Michael Edenfield wrote: > > I doubt there is any perfect answer which will satisfy > > everyone, but perhaps we can recognize that and figure out > > some flexible middle ground. > > 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. -- -- David ([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
On Mon, Nov 24, 2003 at 12:08:58PM -0800, Tim Kientzle wrote: > Contrary to what David claims, I don't think /rescue does need > to support all of the recovery actions that a static /s?bin > would support. Rather, I think it only needs to support those > recovery actions necessary to repair /bin and /sbin if they break. No, you're missing my stance. My stance is that no failure mode needs to be repairable that wasn't repairable with a static /. With a static / last month, if I needed to get a file onto the machine, I had to use a floppy, CDROM, or mount another file system (NFS counts in this). The argument flowing in this thread is about adding additional ways to repair a trashed machine. Those of us that agreed to the /rescue bloat didn't agree to that. We agreed to the claim that /rescue would hold those bits needed to repair a trashed system in the SAME ways one did with a static /. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB 1.0 IDE to ATAPI drive enclosure failure
In message: <[EMAIL PROTECTED]> Barney Wolff <[EMAIL PROTECTED]> writes: : Why hasn't anything been committed? Code freeze? Warner ___ [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
In message: <[EMAIL PROTECTED]> Stefan Farfeleder <[EMAIL PROTECTED]> writes: : On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote: : > From: "Jacques A. Vidrine" <[EMAIL PROTECTED]> : > > The application is broken. You must only check errno if you get an : > > error indication from the library call. : > : > errno is only meaningful after a syscall error. : : Wrong, counter-example: strtol(). 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. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR filedesc structure / Giant
Am 24.11.2003 um 22:56 schrieb Kris Kennaway: On Mon, Nov 24, 2003 at 10:52:54PM +0100, Stefan Bethke wrote: Am 24.11.2003 um 22:19 schrieb Kris Kennaway: On Mon, Nov 24, 2003 at 09:45:51PM +0100, Stefan Bethke wrote: This is with a current from around two days ago, with a kernel not much different from GENERIC. Known problem. I do follow -current quite closely, but none of the cvs lists. It appears that I missed some important info. What should I monitor more closely? What can I do to analyze this more closely? First checking the mailing list archives and PR database for similar problem reports is often prudent. This one has been reported for several months, and I also submitted a PR about it. Sorry for banging on about this, but the PR kern/55175 does not appear to contain much more information than I submitted. If the problem is indeed well known, and deemed a freak accident that won't do any damage, then I apologise for wasting your time. This caused a panic on one of my systems, and the panic hosed the root filesystem. As I'm planning to put two identical systems into production at 5.2 release, or hopefully at 5-stable (depending on timeframe), I would much prefer to have confidence in the stability of the system, and this isn't it. The machine has been running current for the past 4 months, with the occasional make world and portupgrade -f, to make sure that it is stable enough for low-level production work ( <10k hits on apache, <10k emails, some ssh sessions per day). (Running setiathome to test the cpu.) The LOR appears to occur consistently on this machine; I am not sure I can force it to occur at the same sequence of events, but in five of five tries, trying to re-compile ports, it occurs during the compile. If this situation is interesting to anyone, I can easily arrange shell and console access; usually I or a colleague will be available to push buttons if neccessary. If anyone feels I can perform any tests to shed further light on this, please let me know. Thanks, Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ [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
On 24-Nov-2003 Nate Lawson wrote: > > Trace 1: > wakeup(c2944100,0,c06a7546,140,6c) at wakeup+0x4 > AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xa8 > AcpiUtReleaseMutex(9,30,c295e8c0,c295e760,cdb64acc) at AcpiUtReleaseMutex+0x8c > AcpiUtReleaseToCache(3,c295e760,cdb64ad8,c045ac17,c295e760) at > AcpiUtReleaseToCache+0x8c > > Trace 2: > _mtx_unlock_flags(c2944100,0,c06a7546,150,6c) at _mtx_unlock_flags+0x96 > AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xc8 > AcpiUtReleaseMutex(9,8,c045f9cc,c2965940,c12a0c00) at AcpiUtReleaseMutex+0x8c > AcpiUtAcquireFromCache(2,cdb64bf4,c0462229,c12a0c00,cdb64c34) at > AcpiUtAcquireFromCache+0x53 > > Both of these show that acpi_task_thread is calling a task and then > AcpiOsSignalSemaphore is hanging. I'm wondering if your system can't > handle the acpi interrupt being moved to irq 20. Please try this > (untested) patch that should disable moving the SCI to irq 20. As I mentioned a minute ago, the patch didn't help. But I grabbed another stack trace while I was at it. This one is quite different from the others. I don't think it's different because of your patch, though. I saw one like this earlier, but thought it might have been an anomaly caused by my own mucking around in DDB. siointr1(c298d000,0,c06c9b97,6a0,cdb5ec70) at siointr1+0xec siointr(c298d000,c053a016,c06d88a0,c06e7ae0,4) at siointr+0x35 intr_execute_handlers(c129f88c,cdb5ec88,cdb5eccc,c065ca43,34) at intr_execute_handlers+0xc8 lapic_handle_intr(34) at lapic_handle_intr+0x3a Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc053a4ea, esp = 0xcdb5eccc, ebp = 0xcdb5eccc --- critical_exit(c070af20,1,c06b8c37,14b,0) at critical_exit+0x2a _mtx_unlock_spin_flags(c070af20,0,c06b74f7,23a,c294954c) at _mtx_unlock_spin_flags+0x9d ithread_loop(c12a6800,cdb5ed48,c06b7365,311,0) at ithread_loop+0x26e fork_exit(c0520150,c12a6800,cdb5ed48) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcdb5ed7c, ebp = 0 --- John ___ [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
On 24-Nov-2003 Nate Lawson wrote: > On Mon, 24 Nov 2003, John Polstra wrote: >> On 24-Nov-2003 Nate Lawson wrote: >> > >> > Please also send the output of acpidump -t -d > jdp-P2.asl >> >> When I try to run that command, I get: >> >> acpidump: sysctl machdep.acpi_root does not point to RSDP >> >> The sysctl command shows that machdep.acpi_root is 0. >> Remember, though, in order to boot it I had to disable ACPI in >> /boot/loader.conf. > > Yes, I see. You could use an older kernel like the 5.1R cd. I'll try that, and send you the dump if I can get one. > Both of these show that acpi_task_thread is calling a task and then > AcpiOsSignalSemaphore is hanging. I'm wondering if your system can't > handle the acpi interrupt being moved to irq 20. Please try this > (untested) patch that should disable moving the SCI to irq 20. jhb can > probably address this better than I. I tried your patch, but it didn't change the behavior any. John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB 1.0 IDE to ATAPI drive enclosure failure
Barney Wolff wrote: > On Mon, Nov 24, 2003 at 04:44:02PM -0500, Jesse Guardiani wrote: >> >> I'm running FreeBSD 5.1-RELEASE. I just bought a generic >> USB 1.1/2.0/firewire external drive enclosure for my 32gb >> Travelstar 2.0" 12.5mm hard drive. >> >> The device shows up like this: >> >> Nov 18 14:06:16 trevarthan kernel: umass0: Acer Labs USB 2.0 Storage >> Device, rev 2.00/1.03, addr 3 Nov 18 14:06:16 trevarthan kernel: da0 at >> umass-sim0 bus 0 target 0 lun 0 Nov 18 14:06:17 trevarthan kernel: da0: >> Fixed Direct Access SCSI-0 device Nov 18 >> 14:06:17 trevarthan kernel: da0: 1.000MB/s transfers Nov 18 14:06:17 >> trevarthan kernel: da0: 30520MB (62506080 512 byte sectors: 255H 63S/T >> 3890C) >> >> But `ls -al /dev/da*` reveals no slices: > > If you're using an ohci usb controller, perhaps you need a patch. > Browse the -current archives for the last week or so. Sorry, I didn't realize that might be important. Pretty sure it's UHCI: [17:[EMAIL PROTECTED]:[~]% usbdevs addr 1: UHCI root hub, Intel addr 1: UHCI root hub, Intel addr 2: USB Receiver, Logitech addr 1: UHCI root hub, Intel And from dmesg.boot: uhci0: port 0x1800-0x181f irq 9 at device 29.0 on pci0 usb0: 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: port 0x1820-0x183f irq 11 at device 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 9 at device 29.2 on pci0 usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [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
On Mon, 24 Nov 2003, John Polstra wrote:
> On 24-Nov-2003 Nate Lawson wrote:
> >
> > Please also send the output of acpidump -t -d > jdp-P2.asl
>
> When I try to run that command, I get:
>
> acpidump: sysctl machdep.acpi_root does not point to RSDP
>
> The sysctl command shows that machdep.acpi_root is 0.
> Remember, though, in order to boot it I had to disable ACPI in
> /boot/loader.conf.
Yes, I see. You could use an older kernel like the 5.1R cd.
> > If you can break to the debugger after it has hung, a tr would be nice.
>
> The fact that it didn't occur to me to try that says a lot about how
> long I've been away from -current. :-( I've attached traces from
> two different boots. They seem to vary somewhat. I can supply line
> numbers on request.
Trace 1:
wakeup(c2944100,0,c06a7546,140,6c) at wakeup+0x4
AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xa8
AcpiUtReleaseMutex(9,30,c295e8c0,c295e760,cdb64acc) at AcpiUtReleaseMutex+0x8c
AcpiUtReleaseToCache(3,c295e760,cdb64ad8,c045ac17,c295e760) at
AcpiUtReleaseToCache+0x8c
Trace 2:
_mtx_unlock_flags(c2944100,0,c06a7546,150,6c) at _mtx_unlock_flags+0x96
AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xc8
AcpiUtReleaseMutex(9,8,c045f9cc,c2965940,c12a0c00) at AcpiUtReleaseMutex+0x8c
AcpiUtAcquireFromCache(2,cdb64bf4,c0462229,c12a0c00,cdb64c34) at
AcpiUtAcquireFromCache+0x53
Both of these show that acpi_task_thread is calling a task and then
AcpiOsSignalSemaphore is hanging. I'm wondering if your system can't
handle the acpi interrupt being moved to irq 20. Please try this
(untested) patch that should disable moving the SCI to irq 20. jhb can
probably address this better than I.
-Nate
Index: /sys/i386/acpica/madt.c
===
RCS file: /home/ncvs/src/sys/i386/acpica/madt.c,v
retrieving revision 1.7
diff -u -r1.7 madt.c
--- /sys/i386/acpica/madt.c 14 Nov 2003 22:26:29 - 1.7
+++ /sys/i386/acpica/madt.c 24 Nov 2003 21:51:02 -
@@ -538,11 +538,13 @@
}
if (intr->Source != intr->GlobalSystemInterrupt) {
+#if 0
/* XXX: This assumes that the SCI uses IRQ 9. */
if (intr->GlobalSystemInterrupt > 15 && intr->Source == 9)
acpi_OverrideInterruptLevel(
intr->GlobalSystemInterrupt);
else
+#endif
ioapic_remap_vector(new_ioapic, new_pin, intr->Source);
if (madt_find_interrupt(intr->Source, &old_ioapic,
&old_pin) != 0)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB 1.0 IDE to ATAPI drive enclosure failure
On Mon, Nov 24, 2003 at 04:44:02PM -0500, Jesse Guardiani wrote: > > I'm running FreeBSD 5.1-RELEASE. I just bought a generic > USB 1.1/2.0/firewire external drive enclosure for my 32gb > Travelstar 2.0" 12.5mm hard drive. > > The device shows up like this: > > Nov 18 14:06:16 trevarthan kernel: umass0: Acer Labs USB 2.0 Storage Device, rev > 2.00/1.03, addr 3 > Nov 18 14:06:16 trevarthan kernel: da0 at umass-sim0 bus 0 target 0 lun 0 > Nov 18 14:06:17 trevarthan kernel: da0: Fixed Direct > Access SCSI-0 device > Nov 18 14:06:17 trevarthan kernel: da0: 1.000MB/s transfers > Nov 18 14:06:17 trevarthan kernel: da0: 30520MB (62506080 512 byte sectors: 255H > 63S/T 3890C) > > But `ls -al /dev/da*` reveals no slices: If you're using an ohci usb controller, perhaps you need a patch. Browse the -current archives for the last week or so. Why hasn't anything been committed? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR filedesc structure / Giant
On Mon, Nov 24, 2003 at 10:52:54PM +0100, Stefan Bethke wrote: > > Am 24.11.2003 um 22:19 schrieb Kris Kennaway: > > >On Mon, Nov 24, 2003 at 09:45:51PM +0100, Stefan Bethke wrote: > >>This is with a current from around two days ago, with a kernel not > >>much > >>different from GENERIC. > > > >Known problem. > > I do follow -current quite closely, but none of the cvs lists. It > appears that I missed some important info. What should I monitor more > closely? What can I do to analyze this more closely? First checking the mailing list archives and PR database for similar problem reports is often prudent. This one has been reported for several months, and I also submitted a PR about it. Kris pgp0.pgp Description: PGP signature
Re: LOR filedesc structure / Giant
Am 24.11.2003 um 22:19 schrieb Kris Kennaway: On Mon, Nov 24, 2003 at 09:45:51PM +0100, Stefan Bethke wrote: This is with a current from around two days ago, with a kernel not much different from GENERIC. Known problem. I do follow -current quite closely, but none of the cvs lists. It appears that I missed some important info. What should I monitor more closely? What can I do to analyze this more closely? Thanks, Stefan -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ [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
On 24-Nov-2003 Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, John Polstra writes: >>I put kern.timecounter.hardware="i8254" into /boot/loader.conf, but >>it didn't make any difference. Are you sure it even works from >>loader.conf? From the sources it looks like this is a sysctl rather >>than a tunable. I could change it to a tunable, though, if you >>think it's worthwhile. > > It would be rather complicated to make it a tunable. Far easier to > go into the ACPI timecounter and just give it a negative quality, > that will disable it. Thanks for the tip! I did as you suggested, but it didn't cure the hanging problem. John ___ [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
On Mon, 24 Nov 2003, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, John Polstra writes: > >On 24-Nov-2003 Nate Lawson wrote: > >> It's a long shot, but what about setting kern.timecounter.hardware to > >> i8254. It appears your ACPI timer is bad. The reason why I suggest this > >> is that it seems like interrupts are being lost. > > > >I put kern.timecounter.hardware="i8254" into /boot/loader.conf, but > >it didn't make any difference. Are you sure it even works from > >loader.conf? From the sources it looks like this is a sysctl rather > >than a tunable. I could change it to a tunable, though, if you > >think it's worthwhile. > > It would be rather complicated to make it a tunable. Far easier to > go into the ACPI timecounter and just give it a negative quality, > that will disable it. > > I'm not sure why Nate think this will change anything with respect > to interrupts, but I pressume he knows what he's talking about. Some ACPI timecounters on old systems would hang on a read from the register and so moving to i8254 would help if it was being used. But farther down, I see that he was already using TSC so it won't make a difference. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
USB 1.0 IDE to ATAPI drive enclosure failure
Howdy list, I'm running FreeBSD 5.1-RELEASE. I just bought a generic USB 1.1/2.0/firewire external drive enclosure for my 32gb Travelstar 2.0" 12.5mm hard drive. The device shows up like this: Nov 18 14:06:16 trevarthan kernel: umass0: Acer Labs USB 2.0 Storage Device, rev 2.00/1.03, addr 3 Nov 18 14:06:16 trevarthan kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Nov 18 14:06:17 trevarthan kernel: da0: Fixed Direct Access SCSI-0 device Nov 18 14:06:17 trevarthan kernel: da0: 1.000MB/s transfers Nov 18 14:06:17 trevarthan kernel: da0: 30520MB (62506080 512 byte sectors: 255H 63S/T 3890C) But `ls -al /dev/da*` reveals no slices: crw-r- 1 root operator4, 22 Nov 18 13:35 /dev/da0 The hard disk inside this enclosure was formatted with a 10gig FAT32 partition. It works fine in a Coolmax Gemini 2.5" USB 2.0/1.1 drive enclosure (which shows up as IDE->ATA under Windows XP), and it works fine in this enclosure as long as I'm running Windows XP (but it shows up differently than the Gemini under XP: IDE-ATAPI). It just doesn't work under FreeBSD 5.1-RELEASE or FreeBSD 4.8-RELEASE for some reason... I've found the following links relating to similar problems: http://lists.freebsd.org/pipermail/freebsd-current/2003-August/008504.html http://lists.freebsd.org/pipermail/freebsd-hardware/2003-July/000393.html But no solutions. Has the USB code been updated since FreeBSD 5.1-RELEASE? Is there a chance it will work if I cvsup to -CURRENT? I contacted the gentleman from the first link above, and he said that the only thing different about his configuration (other than hardware) is that: 1.) He connects through a USB hub 2.) He runs -CURRENT from Nov 7th I can't seem get my hands on a USB hub, so it looks like my only option is -CURRENT. Does anyone have any clues to help get this drive working? I'm all for debugging of any kind, including coding. I'm just not sure where to start. Thanks! -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [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
In message <[EMAIL PROTECTED]>, John Polstra writes: >On 24-Nov-2003 Nate Lawson wrote: >> It's a long shot, but what about setting kern.timecounter.hardware to >> i8254. It appears your ACPI timer is bad. The reason why I suggest this >> is that it seems like interrupts are being lost. > >I put kern.timecounter.hardware="i8254" into /boot/loader.conf, but >it didn't make any difference. Are you sure it even works from >loader.conf? From the sources it looks like this is a sysctl rather >than a tunable. I could change it to a tunable, though, if you >think it's worthwhile. It would be rather complicated to make it a tunable. Far easier to go into the ACPI timecounter and just give it a negative quality, that will disable it. I'm not sure why Nate think this will change anything with respect to interrupts, but I pressume he knows what he's talking about. -- 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: LOR filedesc structure / Giant
On Mon, Nov 24, 2003 at 09:45:51PM +0100, Stefan Bethke wrote: > This is with a current from around two days ago, with a kernel not much > different from GENERIC. Known problem. Kris pgp0.pgp Description: PGP signature
Re: PII SMP system hangs during boot with ACPI enabled
On 24-Nov-2003 Nate Lawson wrote: > It's a long shot, but what about setting kern.timecounter.hardware to > i8254. It appears your ACPI timer is bad. The reason why I suggest this > is that it seems like interrupts are being lost. I put kern.timecounter.hardware="i8254" into /boot/loader.conf, but it didn't make any difference. Are you sure it even works from loader.conf? From the sources it looks like this is a sysctl rather than a tunable. I could change it to a tunable, though, if you think it's worthwhile. John ___ [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
* Garance A Drosihn <[EMAIL PROTECTED]> [031124 14:11]: > I doubt there is any perfect answer which will satisfy > everyone, but perhaps we can recognize that and figure out > some flexible middle ground. 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 ?? --Mike pgp0.pgp Description: PGP signature
Re: PII SMP system hangs during boot with ACPI enabled
On 24-Nov-2003 Nate Lawson wrote: > > Please also send the output of acpidump -t -d > jdp-P2.asl When I try to run that command, I get: acpidump: sysctl machdep.acpi_root does not point to RSDP The sysctl command shows that machdep.acpi_root is 0. Remember, though, in order to boot it I had to disable ACPI in /boot/loader.conf. > If you can break to the debugger after it has hung, a tr would be nice. The fact that it didn't occur to me to try that says a lot about how long I've been away from -current. :-( I've attached traces from two different boots. They seem to vary somewhat. I can supply line numbers on request. John db> trace siointr1(c298d000,0,c06c9bb7,6a0,cdb64a04) at siointr1+0xec siointr(c298d000,c06a7546,c070bf40,c2944100,4) at siointr+0x35 intr_execute_handlers(c129f88c,cdb64a1c,cdb64a64,c065ca63,34) at intr_execute_ha ndlers+0xc8 lapic_handle_intr(34) at lapic_handle_intr+0x3a Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc053b9a4, esp = 0xcdb64a60, ebp = 0xcdb64a64 --- wakeup(c2944100,0,c06a7546,140,6c) at wakeup+0x4 AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xa8 AcpiUtReleaseMutex(9,30,c295e8c0,c295e760,cdb64acc) at AcpiUtReleaseMutex+0x8c AcpiUtReleaseToCache(3,c295e760,cdb64ad8,c045ac17,c295e760) at AcpiUtReleaseToCa che+0x8c AcpiPsFreeOp(c295e760,cdb64afc,c045ab37,c12a0800,0) at AcpiPsFreeOp+0x30 AcpiPsDeleteCompletedOp(c12a0800,0,c12a0800,c295e7c0,c12a0800) at AcpiPsDeleteCo mpletedOp+0x17 AcpiPsGetNextWalkOp(c12a0800,c295e760,c045ac00,c2967080,c295e8c0) at AcpiPsGetNe xtWalkOp+0x77 AcpiPsDeleteParseTree(c295e8c0,c12a0c00,c12a0de4,0,cdb64bf4) at AcpiPsDeletePars eTree+0x9a AcpiPsCompleteThisOp(c12a0c00,c295e8c0,0,c12a0c10,150) at AcpiPsCompleteThisOp+0 x1b8 AcpiPsParseLoop(c12a0c00,c2967340,cdb64c14,c12a0c00,c12a0de4) at AcpiPsParseLoop +0x6c8 AcpiPsParseAml(c12a0c00,c2967380,c295ca80,ce5b5ac0,d) at AcpiPsParseAml+0x7c AcpiPsxExecute(c295ca80,0,cdb64c9c,c295ca80,0) at AcpiPsxExecute+0x202 AcpiNsExecuteControlMethod(c295ca80,0,cdb64c9c,c2944180,c294dedc) at AcpiNsExecu teControlMethod+0x5f AcpiNsEvaluateByHandle(c295ca80,0,0,76,c295ca80) at AcpiNsEvaluateByHandle+0x96 AcpiEvAsynchExecuteGpeMethod(c294dedc,0,c06a7461,7b,0) at AcpiEvAsynchExecuteGpe Method+0x8c acpi_task_thread(0,cdb64d48,c06b7385,311,5f616964) at acpi_task_thread+0x105 fork_exit(c0474e20,0,cdb64d48) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcdb64d7c, ebp = 0 --- db> c ~Stopped at siointr1+0xec: jmp siointr1+0x220 db> show all procs pid proc uarea uid ppid pgrp flag stat wmesgwchan cmd 48 c299a8d4 d26330000 0 0 204 [IWAIT] swi0: tty:sio 47 c28f0a98 ce57a0000 0 0 204 new [RUNQ] usbtask 46 c28f0c5c ce57b0000 0 0 204 new [RUNQ] usb0 8 c28f0e20 ce57c0000 0 0 204 new [RUNQ] acpi_task2 7 c2935000 ce57d0000 0 0 204 new [RUNQ] acpi_task1 6 c29351c4 ce57e0000 0 0 204 [CPU 0] acpi_task0 45 c2935388 ce57f0000 0 0 204 [IWAIT] swi7: acpitaskq 44 c293554c ce580 0 0 204 new [IWAIT] swi3: cambio 43 c2935710 ce5810000 0 0 204 new [IWAIT] swi2: camnet 42 c29358d4 ce5820000 0 0 204 new [IWAIT] swi5:+ 5 c2935a98 ce5830000 0 0 204 [SLP]tqthr 0xc070f268] taskqueu e 41 c2935c5c ce5a80000 0 0 204 new [IWAIT] swi6:+ 40 c2935e20 ce5a90000 0 0 204 [IWAIT] swi7: task queue 39 c2937000 ce5aa0000 0 0 204 [RUNQ] random 4 c28e154c ce54a0000 0 0 204 [RUNQ] g_down 3 c28e1710 ce54b0000 0 0 204 [RUNQ] g_up 2 c28e18d4 ce54c0000 0 0 204 [RUNQ] g_event 38 c28e1a98 ce54d0000 0 0 204 new [IWAIT] swi4: vm 37 c28e1c5c ce54e0000 0 0 20c [IWAIT] swi8: tty:sio clock 36 c28e1e20 ce54f0000 0 0 204 new [IWAIT] swi1: net 35 c28f ce550 0 0 204 new [IWAIT] irq9: 34 c28f01c4 ce5750000 0 0 204 new [IWAIT] irq0: clk 33 c28f0388 ce5760000 0 0 204 new [IWAIT] irq23: 32 c28f054c ce5770000 0 0 204 new [IWAIT] irq22: 31 c28f0710 ce5780000 0 0 204 new [IWAIT] irq21: 30 c28f08d4 ce5790000 0 0 204 [RUNQ] irq20: acpi0 29 c12ae1c4 cdb490000 0 0 204 new [IWAIT] irq19: fxp0 uhci0 28 c12ae388 cdb4a0000 0 0 204 new [IWAIT] irq18: 27 c12ae54c cdb4b0000 0 0 204 new [IWAIT] irq17: fxp1 26 c12ae710 cdb4c0000 0 0 204 new [IWAIT] irq16: ahc0 ahc1 25 c12ae8d4 cdb710000 0 0 204 new [IWAIT] irq15: ata1 24 c12aea98 cdb720000 0 0 204 [IWAIT] irq14: ata0 23 c12aec5c cdb730000 0 0 204 new [IWAIT] irq13: 22 c12aee20 cdb740000 0 0 204 new
Re: HEADS UP: /bin and /sbin are now dynamically linked
> > For a *lot* of people today (like home users), an up-to-date FreeBSD > > CD or floppy or a second machine to create the disk on may not be > > handy (and forget about NFS), but a network connection may still be > > available. > > That network connection would most likely be a M$-Win box in that case, > which doesn't have an FTP server. Samba, not an FTP client should be in > /rescue then. # ftp ftp.freebsd.org > get blah/blah/blah/release/bin.tgz # tar xzvf seems like a damn easy fix for killing /bin and /sbin i like the idea of having a tiny (re: non-ssl) fetch availble for when i shoot myself in the foot. would be incredibly helpful. And while in my current configurations, live cd or NFS are also options, sometimes fetch is going to be faster, and if it's a production machine, time is money. In a perfect world, I'd never hose a production machine, but... ~j > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" = "Yesterday upon the stair I saw a man who wasn't there, he wasn't there again today, oh how i wish he'd go away" Rev. Jonathan T. Sage - Lighting / Set Designer [HTTP://www.wisefreebsd.org] [HTTP://jonsage.wisefreebsd.org] [EMAIL PROTECTED] __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
recursed on non-recursive lock (sleep mutex) vnode interlock @ /var/portbuild/sparc64/src-client/sys/ufs/ufs/ufs_ihash.c:128
One of my sparc64 package machines (running -current from Nov 21) died
overnight with the following:
recursed on non-recursive lock (sleep mutex) vnode interlock @
/var/portbuild/sparc64/src-client/sys/ufs/ufs/ufs_ihash.c:128
first acquired @ /var/portbuild/sparc64/src-client/sys/ufs/ufs/ufs_ihash.c:128
panic: recurse
cpuid = 0;
Debugger("panic")
Stopped at Debugger+0x1c: ta %xcc, 1
db> trace
panic() at panic+0x174
witness_lock() at witness_lock+0x3b4
_mtx_lock_flags() at _mtx_lock_flags+0x9c
ufs_ihashget() at ufs_ihashget+0x94
ffs_vget() at ffs_vget+0x20
ufs_lookup() at ufs_lookup+0xb2c
ufs_vnoperate() at ufs_vnoperate+0x1c
vfs_cache_lookup() at vfs_cache_lookup+0x330
ufs_vnoperate() at ufs_vnoperate+0x1c
lookup() at lookup+0x408
namei() at namei+0x254
vn_open_cred() at vn_open_cred+0x208
vn_open() at vn_open+0x18
kern_open() at kern_open+0x84
open() at open+0x14
syscall() at syscall+0x308
-- syscall (5, FreeBSD ELF64, open) %o7=0x4038c2b0 --
userland() at 0x40395948
user trace: trap %o7=0x4038c2b0
pc 0x40395948, sp 0x7fddaf1
pc 0x4038b47c, sp 0x7fddc31
pc 0x101778, sp 0x7fddcf1
pc 0x101378, sp 0x7fdddb1
pc 0x100f80, sp 0x7fdde71
pc 0x4020a234, sp 0x7fddf31
done
pgp0.pgp
Description: PGP signature
LOR filedesc structure / Giant
This is with a current from around two days ago, with a kernel not much different from GENERIC. lock order reversal 1st 0xc48ab234 filedesc structure (filedesc structure) @ /usr/src/sys/kern/sys_generic.c:896 2nd 0xc0729a60 Giant (Giant) @ /usr/src/sys/fs/specfs/spec_vnops.c:377 Stack backtrace: backtrace(c06cdeaa,c0729a60,c06ca2ff,c06ca2ff,c06c5b0c) at backtrace+0x17 witness_lock(c0729a60,8,c06c5b0c,179,0) at witness_lock+0x686 _mtx_lock_flags(c0729a60,0,c06c5b0c,179,c06ce4b1) at _mtx_lock_flags+0xb4 spec_poll(d79e7afc,d79e7b1c,c05897b4,d79e7afc,c071e1a0) at spec_poll+0x113 spec_vnoperate(d79e7afc,c071e1a0,c4692208,40,c4888f00) at spec_vnoperate+0x18 vn_poll(c466f7f8,40,c4888f00,c4425c80,c4888f00) at vn_poll+0x3c selscan(c4425c80,d79e7b9c,d79e7b8c,5,4) at selscan+0x11a kern_select(c4425c80,5,bfbfe3f8,0,0) at kern_select+0x368 select(c4425c80,d79e7d14,c06e5eae,3ee,5) at select+0x67 syscall(2f,2f,2f,1,bfbfed24) at syscall+0x292 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (93), eip = 0x280c7073, esp = 0xbfbfe39c, ebp = 0xbfbfecf0 --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3c fault code = supervisor read, page not present instruction pointer = 0x8:0xc04e1305 stack pointer = 0x10:0xd8c0a8a8 frame pointer = 0x10:0xd8c0a978 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 19005 (patch) kernel: type 12 trap, code=0 Stopped at devfs_lookupx+0x448:movl0x3c(%eax),%eax db> trace devfs_lookupx(d8c0a9d0,1,0,c6592500,c4658c30) at devfs_lookupx+0x448 devfs_lookup(d8c0a9d0,c6592500,0,c6592500,c6592500) at devfs_lookup+0x4b lookup(d8c0abdc,0,c06d1d39,a6,c6592500) at lookup+0x2e0 namei(d8c0abdc,c072f3a8,0,c6592500,c07358e0) at namei+0x235 vn_open_cred(d8c0abdc,d8c0acdc,d,c4888f00,4) at vn_open_cred+0x257 vn_open(d8c0abdc,d8c0acdc,d,4,d8c0ab80) at vn_open+0x33 kern_open(c6592500,80527e6,0,3,f) at kern_open+0xd0 open(c6592500,d8c0ad14,c06e5eae,3ee,3) at open+0x30 syscall(2f,2f,2f,80543d0,0) at syscall+0x292 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5, FreeBSD ELF32, open), eip = 0x280c47b3, esp = 0xbfbfeb2c, ebp = 0xbfbfeb58 --- -- Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
40% slowdown with dynamic /bin/sh
Here is a simple test which times the execution of a null shell script. It basically times fork/exec of the chosen shell. % cat harness.sh #!/bin/sh sh=$1 cnt=$2 i=0 while [ $i -le $cnt ]; do $sh ./foo i=`expr $i + 1` done #eof %cat foo exit #eof % ldd sh.dynamic sh.dynamic: libedit.so.4 => /lib/libedit.so.4 (0x2808c000) libncurses.so.5 => /lib/libncurses.so.5 (0x280a1000) libc.so.5 => /lib/libc.so.5 (0x280e1000) % ldd sh.static ldd: sh.static: not a dynamic executable Here are some timings taken from ref5.freebsd.org: % /usr/bin/time ./harness.sh ./sh.dynamic 100 1.55 real 0.27 user 1.11 sys % /usr/bin/time ./harness.sh ./sh.dynamic 100 1.55 real 0.28 user 1.10 sys % /usr/bin/time ./harness.sh ./sh.dynamic 100 1.60 real 0.21 user 1.18 sys % ./harness.sh ./sh.static 100 1.12 real 0.08 user 0.87 sys % ./harness.sh ./sh.static 100 1.12 real 0.08 user 0.87 sys % ./harness.sh ./sh.static 100 1.12 real 0.11 user 0.84 sys So.. forking a dynamic sh is roughly 40% more expensive than forking a static copy of sh. This is embarrassing. I propose that we at least make /bin/sh static. (and not add a /sbin/sh; if we must have a dynamic sh, import pdksh, or put a dynamically linked sh in /usr/bin/sh). I'd greatly prefer that the the dynamic root default be backed out until a substantial amount of this performance can be recovered. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IRQ problem with VAIO laptop again
> uhci2: port 0x1840-0x185f > at device 29.2 on pci0 > pcib0: _PRS resource entry has unsupported type 0 > uhci2: Could not allocate irq > device_probe_and_attach: uhci2 attach returned 6 >This one loses the memory-stick slot > pcib1: at device 30.0 on pci0 > pci2: on pcib1 > pcib1: _PRS resource entry has unsupported type 0 > pcib1: slot 8 INTA is routed to irq 9 > fwohci0: mem > 0xe020-0xe0203fff,0xe0205000-0xe02057ff at device 2.0 on pci2 > pcib1: _PRS resource entry has unsupported type 0 > fwohci0: Could not allocate irq > device_probe_and_attach: fwohci0 attach returned 6 >> This one loses firewire The problem is that your _PRS values are incorrect. Actually, I think jhb committed some code to deal with extended irq resources. Send me the output of acpidump -t -d > pete-SonyVaio.asl Also, does booting without ACPI fix things? -Nate ___ [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
Garance A Drosihn wrote: Another issue with adding more-and-more to /rescue ... I am certainly not suggesting adding "more-and-more to /rescue." The dynamic root is a new feature with as-yet-unknown failure modes. As we understand those failure modes, we can fine-tune the contents of /rescue. I'm trying to understand what those failure modes are and what that implies about the contents of /rescue. I do want /rescue to be small and I want it to compile quickly. But I mostly want it to be useful to the people who need it. I kind of like the idea of having 'vi' available, ... I'm personally tempted to remove vi/ex from /rescue. I originally put it in based on my experience recovering systems where I needed to edit configure files. But, I've not managed to come up with a scenario where a broken config file would break /bin. If that's the case, then vi isn't needed in /rescue, since the purpose of /rescue is to repair a broken /bin, /sbin, /lib. Once those are working, you can mount /usr and have access to /usr/bin/vi. Contrary to what David claims, I don't think /rescue does need to support all of the recovery actions that a static /s?bin would support. Rather, I think it only needs to support those recovery actions necessary to repair /bin and /sbin if they break. That could be a very small set of tools. It is not necessarily a subset of /bin and /sbin, however. Unfortunately (or fortunately, I suppose), few people seem to have actually needed /rescue, so we as a community don't yet have enough experience to really tailor that toolkit. disaster scenarios where you won't have something you need. For some reason, I manage to hit those every few months. The only way to find out what's truly necessary in /rescue is to pay attention to people who actually use it. If someone knows they'll never use it, NO_RESCUE has been shown to measurably reduce buildworld times. I doubt there is any perfect answer which will satisfy everyone, but perhaps we can recognize that and figure out some flexible middle ground. That's exactly what I'm trying to do. Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: atheros (ath) - duplicate packets with long distance link
On Monday 24 November 2003 21:22, Sam Leffler wrote: > tcpdump -e -i ath0 -y IEEE802_11 > > and verify the 802.11 frames are actual duplicates. They should not be > unless there's a bug in the duplicate suppression logic in the 802.11 code. The packets are definately from the same host. Will it help if I recompile with AR_DEBUG turned on ? PING 192.168.10.10 (192.168.10.10): 56 data bytes 64 bytes from 192.168.10.10: icmp_seq=0 ttl=64 time=4.373 ms 64 bytes from 192.168.10.10: icmp_seq=0 ttl=64 time=74.278 ms (DUP!) 64 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=2.646 ms 64 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=83.930 ms (DUP!) 64 bytes from 192.168.10.10: icmp_seq=2 ttl=64 time=2.631 ms 64 bytes from 192.168.10.10: icmp_seq=3 ttl=64 time=4.127 ms atheros# tcpdump -e -i ath0 -y IEEE802_11 proto ICMP tcpdump: data link type DLT_IEEE802_11 tcpdump: listening on ath0 00:04:57.452451 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:f0:4 DA:0:5:5d:95:ef:2c 192.1 68.10.20 > 192.168.10.10: icmp: echo request 00:04:57.455152 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:57.457598 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:57.461559 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:57.467485 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:57.478495 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:57.483984 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:57.490683 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:57.509604 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:57.531031 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:57.546951 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:57.557694 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:58.469354 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:f0:4 DA:0:5:5d:95:ef:2c 192.1 68.10.20 > 192.168.10.10: icmp: echo request 00:04:58.473004 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:58.476335 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:58.488546 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:58.508876 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:58.521360 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:58.528470 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:58.537460 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:58.547434 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:58.551423 DA:0:5:5d:95:f0:4 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:ef:2c 192.1 68.10.10 > 192.168.10.20: icmp: echo reply 00:04:59.479303 BSSID:0:5:5d:95:ef:2c SA:0:5:5d:95:f0:4 DA:0:5:5d:95:ef:2c 192.1 68.10.20 > 192.168.10.10: icmp: echo request Johann ___ [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
On Mon, 24 Nov 2003, John Polstra wrote: > On 24-Nov-2003 Nate Lawson wrote: > > Please add debug.acpi.disable="cpu" to loader.conf or type that in at the > > loader prompt. If it boots ok, we'll have to debug the acpi_cpu_startup > > path. > > Thanks. It still hangs even with debug.acpi.disable="cpu". I have > attached the verbose boot messages. They are essentially the same as > the previous messages, except that the acpi_cpu messages are gone now > as expected. > > If there's anything else I should try, just let me know. It's a long shot, but what about setting kern.timecounter.hardware to i8254. It appears your ACPI timer is bad. The reason why I suggest this is that it seems like interrupts are being lost. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
