Re: 40% slowdown with dynamic /bin/sh
On Mon, 24 Nov 2003, Andrew Gallatin wrote: > >Daniel O'Connor writes: > > > > It is _trivial_ to buildworld with a static root. > >Then its equally trivial to build with a dynamic root. Please do so, >and don't wreck the performance of the OS I've used since 1994. Then just use OS from 1994 and don't bother about NEW features that may appear in dumb, slow, dynamically linked OS. Just put your head in the sand and say "I'm pretty happy with old statically linked OS and I never need new features in it"... World is going forward, and the payment of new features is awesome performance of OLD, not so good profiled (due statical linking) dynamic linking functions. "if it isn't broken - don't fix it". But if you don't use dynamic linking - it's DEFINITELY NOT broken. And will never be fixed. Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
./Scott Long wrote: Please, read : http://www.netmeister.org/news/learn2quote.html > Also, I'm really starting to resent you using the FreeBSD mailing > lists as an advocacy channel for DragonFly. I fail to see how FreeBSD > 4.x and DFBSD relate to FreeBSD 5-current, which is the overall topic > of this mailing list at the moment. This comment is so ridiculous I can't resist. He has explained a very clever and nice solution for the problem, rather than bitching about it which is what the 95% of the thread is about. By bashing him, not only you're doing a great job for inter-camp relations, you're making the absurd assumption that such a solution (once/if it appears in DragonFly) cannot/will not be easily ported to FreeBSD. Cheers, -- Miguel Mendez <[EMAIL PROTECTED]> http://www.energyhq.es.eu.org PGP Key: 0xDC8514F1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Tools v. Policy: Dynamic linking
First, this can be moved right to -chat or /dev/null. Whatever trips your trigger. The first post is just to -current, because that's where all the commotion is. I think everyone can concede that the discussion has basically begun to bore most. I think, however, that a fundamental point has been lost in the noise here: The current decision to make dynamic linking the default is a policy issue, and not one of providing additional functionality. I don't think anyone is disatisfied that someone finally did the work to make support for NSS and PAM et al. work for those who need it. It was a difficult and long-awaited set of functions. A good deal of thanks should go to Gordon and Jacques and all the others who hacked and tested to make it work. Even if there might have been a technical middle road that would have more easily pleased everyone, those who do the work have the final say as to the implementation. The real problem, that seems to have gotten lost here, is why does this set of new functions need to be the system default? I can only imagine that the true reason is one of maintenance. Hooking dynamic linking into the system forces the project to make sure it always builds and works. This, imho, should be more the responsibility of the small set of individuals (and I do think the number of users who need this type of functionality is relatively small when viewing the big picture) who need dynamic linking in their systems. One could even dedicate a build cycle within the build cluster to make sure that the dynamically built worlds continue to build with on-going changes. The pros and cons have been discussed ad nauseum. I don't think one side will be able to convince the other that their approach is better or worse in the long run and that eventually, people are just going to get even more irrational in their arguements. I mean, comparing compiler upgrades (which are externally developed and support new architectures) to dynamic linking seems to be tangental at best. Running "fork bombs" vs. port builds to make a point is just selective analysis. Labelling one side as "dynamic, progressive, innovative" and the other "crusty conservative old-timers" is just adding noise. Those advocating "progress" need to realize that moving forward doesn't always mean you're moving in the right direction. Making FreeBSD more "like" Solaris or Linux is only valid up to a certain point. We all like this new functionality. We just don't want it in our backyard... (further bantering suppressed) Fast or slow, NSS support or not, does it really need to be default? Can't the project make a commitment to this set of functions without making it the system default? No one objects to making this set of functions possible. It seems a good deal object to making it the default. -- Yours truly, shaun at shamz.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
memory allocation issue loading a kernel module
Hi everyone, I was wondering if there is a way to flush out pages in memory that might not be required. I have a device driver that allocates 16 distict buffers each 32K in size. This is done with a bus_dma call as they will be accessed by a PCI device. The problem is that if I do a compile on my system prior to trying to kldload the module, there isn't enough physical memory for the driver. I am assuming it is the disk cache that is eating up that memory and I want to flush out enough pages for my bus_dma allocation to work. Is this possible? Any and all comments are appreciated. Thanks in advance, Sean ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to fix this in 5.1-REL??
On (2003/11/24 15:39), Kevin Oberman wrote: > > > I end up with the following when I run `make world` on 5.1-RELEASE-p10. > > > > Did you read UPDATING? > > I fear a bikeshed, but I really think it may be past time to remove > the 'world' target from /usr/src/Makefile.inc1. It is rarely useful > and only should be used by those who understand the process and know > that it is safe. Removing it would remove a clear way to shoot one's > foot and would really have trivial impact on those who use it > properly. I agree. The job requires quite a lot of documentation work, though. If you can get buy-in from the doc project folks, I doubt you'd meet with serious objections from src people. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
On Mon, Nov 24, 2003 at 11:16:07PM -0700, M. Warner Losh wrote: >H, It looks like the hit is less than 10% in the fork intensive >test I just wrote: > >#!/bin/sh >for i in 0 1 2 3 4 5 6 7 8 9; do >for j in 0 1 2 3 4 5 6 7 8 9; do >for k in 0 1 2 3 4 5 6 7 8 9; do > for l in 0 1 2 3 4 5 6 7 8 9; do > for m in 0 1 2 3 4 5 6 7 8 9; do > for n in 0 1 2 3 4 5 6 7 8 9; do >true; >done; done; done; done; done; done; Unless you've done something wierd to your /bin/sh, "true" is a builtin. This test just to measures the ongoing runtime overhead of a dynamic executable (ie PIC code). Drew's test was measuring the startup overhead. >Clearly dynamic is slower, but it is more like 11% slower (10.67%) on >the average than 40% slower. I think this would be a more typical >usage pattern. You have measured different things. Drew's test shows that a dynamic /bin/sh tahes about 40% longer to start. Your test shows that once started, it runs about 11% slower. And the 11% slower is _very_ worrying since it is probably more widely applicable than just /bin/sh. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: memory allocation issue loading a kernel module
Sean McNeil wrote: > Hi everyone, > > I was wondering if there is a way to flush out pages in memory that > might not be required. I have a device driver that allocates 16 distict > buffers each 32K in size. This is done with a bus_dma call as they will > be accessed by a PCI device. The problem is that if I do a compile on > my system prior to trying to kldload the module, there isn't enough > physical memory for the driver. I am assuming it is the disk cache that > is eating up that memory and I want to flush out enough pages for my > bus_dma allocation to work. > > Is this possible? Any and all comments are appreciated. The problem has probably nothing to do with the disk cache eating up memory but I believe what you're seeing is physical address space fragmentation. On x86, when devices want to perform DMA operations, they are given physical addresses, not virtual ones as with other architectures like sparc64 which have an IOMMU. This means that for each of your 32k buffers, you need 8 _physically contiguous_ pages of memory. Unfortunately, the more a system is running, the more the physical address space tends to be fragmented, and it becomes impossible to reserve large chunks of physically contiguous memory, hence why the kldload is failing. If I remember correctly, Alan Cox intended to write a binary buddy allocator to handle the physical address space (or do coalescing another way, I'm not sure...) so that this particular problem is solved. Cheers, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
In message: <[EMAIL PROTECTED]> Peter Jeremy <[EMAIL PROTECTED]> writes: : On Mon, Nov 24, 2003 at 11:16:07PM -0700, M. Warner Losh wrote: : >H, It looks like the hit is less than 10% in the fork intensive : >test I just wrote: : > : >#!/bin/sh : >for i in 0 1 2 3 4 5 6 7 8 9; do : >for j in 0 1 2 3 4 5 6 7 8 9; do : >for k in 0 1 2 3 4 5 6 7 8 9; do : > for l in 0 1 2 3 4 5 6 7 8 9; do : > for m in 0 1 2 3 4 5 6 7 8 9; do : > for n in 0 1 2 3 4 5 6 7 8 9; do : >true; : >done; done; done; done; done; done; : : Unless you've done something wierd to your /bin/sh, "true" is a : builtin. This test just to measures the ongoing runtime overhead : of a dynamic executable (ie PIC code). Drew's test was measuring : the startup overhead. True. However, I get very similar numbers of I change it to /usr/bin/true (12% slower). /bin/sh usually fork+exec things other /bin/sh. : >Clearly dynamic is slower, but it is more like 11% slower (10.67%) on : >the average than 40% slower. I think this would be a more typical : >usage pattern. : : You have measured different things. Drew's test shows that a dynamic : /bin/sh tahes about 40% longer to start. Your test shows that once : started, it runs about 11% slower. And the 11% slower is _very_ : worrying since it is probably more widely applicable than just /bin/sh. Dynamically linked prorgrams tend to be a few percent slower than their static counterparts due to PIC code typically being slower than non-PIC code. There's nothing new here. Clearly there are problems to look into, but it isn't the end of the world. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
On Tue, Nov 25, 2003 at 04:54:41AM +, E.B. Dreger wrote: >What specific aspects of rtld are required to support NSS in >static binaries? dlopen(), fixups, and dlsym()? All of the above. The underlying problem is how to handle a library call from within the NSS/PAM/whatever shared library. This has been discussed in one of the recent threads but it boils down to: 1) Static executables don't normally have any symbols available at runtime so it's difficult for a shared library to resolve symbols using definitions in the executable. 2) It is possible (likely?) that a shared library may reference a symbol that does not exist within the executable. 3) Loading libc.so etc to resolve a symbol means that there may be two distinct (and possibly different) instances of the same object associated with a process. This may create problems where those objects have side-effects. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: memory allocation issue loading a kernel module
Yes, thanks for the clarification. I still am inclined to believe, though, that the disk driver is what is fragmenting the physical memory with disk cacheing. It is only a theory, but it sounded plausible. Thanks again, Sean On Tue, 2003-11-25 at 00:13, Maxime Henrion wrote: > Sean McNeil wrote: > > Hi everyone, > > > > I was wondering if there is a way to flush out pages in memory that > > might not be required. I have a device driver that allocates 16 distict > > buffers each 32K in size. This is done with a bus_dma call as they will > > be accessed by a PCI device. The problem is that if I do a compile on > > my system prior to trying to kldload the module, there isn't enough > > physical memory for the driver. I am assuming it is the disk cache that > > is eating up that memory and I want to flush out enough pages for my > > bus_dma allocation to work. > > > > Is this possible? Any and all comments are appreciated. > > The problem has probably nothing to do with the disk cache eating up > memory but I believe what you're seeing is physical address space > fragmentation. On x86, when devices want to perform DMA operations, > they are given physical addresses, not virtual ones as with other > architectures like sparc64 which have an IOMMU. This means that for > each of your 32k buffers, you need 8 _physically contiguous_ pages of > memory. > > Unfortunately, the more a system is running, the more the physical > address space tends to be fragmented, and it becomes impossible to > reserve large chunks of physically contiguous memory, hence why the > kldload is failing. > > If I remember correctly, Alan Cox intended to write a binary buddy > allocator to handle the physical address space (or do coalescing another > way, I'm not sure...) so that this particular problem is solved. > > Cheers, > Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: memory allocation issue loading a kernel module
Sean McNeil wrote: > Yes, thanks for the clarification. I still am inclined to believe, > though, that the disk driver is what is fragmenting the physical memory > with disk cacheing. It is only a theory, but it sounded plausible. Maybe, but the root cause is not the disk caching. It may be that this subsystem is doing a lot of allocations/deallocations and thus leads to physical address space fragmentation, but the root cause is how we deal with physical address space, and the correct fix is not to add hacks into the disk caching code. I'm insisting on this because I don't want to see people adding hacks here and there to workaround the problem. Even if you get the disk caching code to cause less fragmentation, fragmentation _will_ happen. At best it'll take a bit longer. Cheers, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
How many bikesheds can _you_ build on a pin head ?
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes : > >First, this can be moved right to -chat or /dev/null. Without it being an attack on shauns probably well thought out email, his offer in the first line of it is too good to pass. This is an email to everybody who participated in the most recent couple of bikesheds: FreeBSD exists because the stuff in the CVS repos has value to people. If FreeBSD starts to fall behind or even God forbid, downright suck, people will abandon FreeBSD. The people who improve the value of the CVS repos are called committers. Committers are volounteers who do the best they can for free, more often than not in their own spare time. Committers have never been known to have large amounts of spare time nor (with a few notable exceptions) a desire to receive as much email as possible. So all the time committers spend wading through bikesheds of email is time they don't work on the code, docs or ports, and therefore ipso facto time during which FreeBSD looses momentum. And each of you, every time you feel like sending an email, therefore get to decide, indirectly, if FreeBSD should have a future or not. Think about it this way, next time you press "reply": Would I rather have all the developers read my email or would I rather have them working on improving FreeBSD ? Also, think about this: You run, unquestioned code which does great and magic things deep in the VM system, interrupt code, buffer cache, filesystems etc etc, you don't even stop to think about how it actually works, you trust the people who did it to know better than you. But once it comes to a totally insignificant issue as to which binaries are linked static and dynamic, you suddenly do not trust the judgement of the same people, but feel that your views are so important that it is paramount that they listen to you and do exactly as you say because YOU KNOW BETTER!!! That my friends, is how you could help kill BSD... I have for myself recently taken a break from all active FreeBSD development because I find the environment about as pleasant as a kindergarten right before lunch. If the project continues to degenerate into one bikeshed discussion bigger than the next about issues of increasing irrelevance, then I won't be able to persuade myself to go back in and suffer the noise while I work on the really important things. Poul-Henning PS: As for DFBSD staff posting to FreeBSD lists: the other 2-3 BSDs have for ten years managed to coexist mostly peacefully because we have respected each others mailing lists as not being suitable for promoting our cause. DFBSD would do well in adopting the same. PPS: Poul-Henning has not been a core member for a number of years now, so he obviously does not speak for [EMAIL PROTECTED] He also does not speak for the project as such. He doesn't speak with any special authority either. He simply speaks for himself, as a committer who has been one of the most active in the FreeBSD project for the last ten years. There, that should save a core member or two the trouble of posting a disclaimer. Hope you appreciate it :-) PPPS: If you post this to SlashDot, DaemonNews or other such fora, you're lame beyond imagination. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
On Tue, Nov 25, 2003 at 01:17:34AM -0700, M. Warner Losh wrote: >True. However, I get very similar numbers of I change it to >/usr/bin/true (12% slower). /bin/sh usually fork+exec things other >/bin/sh. That's a more interesting result and more comparable to Drew's test. It doesn't necessarily invalidate Drew's results - /bin/sh has 3 shared libraries and is locale-aware whereas /usr/bin/test has 1 shared library and doesn't rely on the locale. /usr/bin/true is also significantly smaller (implying less relocation requirements). /bin/sh could reasonably be expected to take longer to startup then /usr/bin/test. >Dynamically linked prorgrams tend to be a few percent slower than >their static counterparts due to PIC code typically being slower than >non-PIC code. There's nothing new here. Except that, on face value, your figures suggested an 11% slowdown attribute to PIC code - which is way above "a few percent". >Clearly there are problems to look into, but it isn't the end of the >world. Agreed. I think most people agree that more work needs to be done. The arguing seems to be whether the work should be done before or after the big switch is thrown and how to go about recovering the lost performance. (And of course one contingent is insisting it be green whilst a different contingent is insisting that it can't be green and has to be triangular instead). Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: memory allocation issue loading a kernel module
Oh, I absolutely agree. I do not want any hacks. I was hoping that there might be an existing mechanism that was in place that would allow for the purging of unused physical pages by resource hogs. I am reminded of an old OS I was fond of: AmigaOS. It had a real nice feature where applications, drivers, etc. would register a "low memory" callback. Whenever the OS reached certain water-marks, these callbacks would get invoked. It was a nice clean way for shared libraries and drivers to cache things in memory, but then throw them away when things got tight. It is not a big deal for me. This is for a customer of mine and they are OK with loading the module early during boot when memory isn't fragmented yet. Just thinking "out text", Sean On Tue, 2003-11-25 at 00:31, Maxime Henrion wrote: > Sean McNeil wrote: > > Yes, thanks for the clarification. I still am inclined to believe, > > though, that the disk driver is what is fragmenting the physical memory > > with disk cacheing. It is only a theory, but it sounded plausible. > > Maybe, but the root cause is not the disk caching. It may be that this > subsystem is doing a lot of allocations/deallocations and thus leads to > physical address space fragmentation, but the root cause is how we deal > with physical address space, and the correct fix is not to add hacks into > the disk caching code. I'm insisting on this because I don't want to see > people adding hacks here and there to workaround the problem. Even if > you get the disk caching code to cause less fragmentation, fragmentation > _will_ happen. At best it'll take a bit longer. > > Cheers, > Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
On Mon, 24 Nov 2003, Leo Bicknell wrote: > Process accounting can tell the story: > > % lastcomm | wc -l >47806 > % lastcomm | sed -e 's/ .*.//' | sort | uniq -c | sort -nr | head > 25281 sendmail > 4094 sh > 2987 perl > 2846 inetd > 1704 procmail > 1640 httpd > 1221 cron > 814 date > 732 postgres > 648 rateup > > Looks like sh is the 2nd most frequently executed command on my > system. It is 8.5% of all executed programs on this particular > system. I think slowing down 8.5% of all the programs the system > runs is important. For what it's worth, here's the data that I've taken from the daily process accounting files of one of our somewhat busy shellboxes: # lastcomm -f acct.0 | sed -e 's/ .*.//' | sort | uniq -c | sort -nr | head 4829 qpopper 3426 bash 3191 sendmail 1915 sh 1687 httpd 1281 sed 1030 sshd2 952 rm 792 procmail 739 cron # lastcomm -f acct.1 | sed -e 's/ .*.//' | sort | uniq -c | sort -nr | head 5383 qpopper 3282 bash 2743 sendmail 1617 httpd 1187 sh 1071 sed 772 rm 739 cron 694 procmail 478 cat # lastcomm -f acct.2 | sed -e 's/ .*.//' | sort | uniq -c | sort -nr | head 5376 qpopper 2823 bash 2118 sendmail 1674 httpd 1510 sh 745 procmail 740 cron 292 python 288 atrun 211 inetd Though /bin/sh isn't 2nd on the list, it does feature prominently in the top 10. I would assume that anyone with a fairly busy machine acting as a shellbox and webserver would see something along these lines... Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
:... :5.x and propaganda about DFBSD doesn't really mean a whole lot, unless you :are looking for new recruits to your camp. In any case, you've made your :point on a nearly daily basis that 5.x is inferior to what DFBSD will be, :and that you don't have much knowledge or care about 5.x anyways. So :please, go do what you do best and make DFBSD the envy of the BSD world. :I'll be first in line to pat you on the back when you succeed. : :Scott Hmm. Well, I think there's some confusion here. While I certainly like my vision for DFly better then I like the vision for FreeBSD-5, that is simply in the eye of the beholder... of course I am going to like my own vision better. It's my vision, after all! Your vision is obviously different. In fact, I expect that each person has his own vision for the project, so don't knock me for mine. But that has nothing to do with perceived inferiority or superiority. The issue isn't so much whether one project is better then the other as it is whether one is able and willing to borrow a proven concept from another project to replace the one that maybe isn't so hot in one's own. As it happens, I have borrowed quite a bit of code from 5.x. As it also happens, I believe that 5.x would benefit by adopting some of the things that have already been proven to work quite well in DragonFly. For example, using a statistical time accumulation model instead of calling microtime() in the middle of the critical thread switch path, or not preemptively switching threads operating in kernelland to another cpu, or the implementation of a mutexless scheduler. Just a few examples. I can only point out the concepts and ideas and point to the code in DFly, it is up to FreeBSD-5 developers to take the ball up and either throw it away or run with it. I have not been posting daily, but you seem to be frustrated about something. I can only suggest that blaming me for your frustrations is not going to solve any tangible, technical issue in FreeBSD-5. My posts are technical and to the point. Just because it's coming out of my mouth rather then someone you might respect a bit more doesn't make it any more or less valid. If you cannot address them based on their technical merit then you've missed the point of the post entirely. And, just for the record, I feel quite obligated to try to move the FreeBSD project forward along a path that I believe will be more beneficial to its users. Just to be clear: My obligation is to all the people who use FreeBSD, not to the feelings of particular developers whos vision(s) I might disagree with. I have no intent or intention of screwing over FreeBSD (how absurd!) but you should not mistakenly equate that to me being accomodating to FreeBSD's current vision which, yes! it is true! I have serious disagreements with. Over the years I have recommended FreeBSD to hundreds of people and I take that responsibility very seriously. If it is within the scope of the FreeBSD charter for a person to post based on a perceived obligation to the end users of FreeBSD, then I certainly still have a right to post to this group. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
On Tuesday 25 November 2003 03:07, Don Lewis wrote: > On 25 Nov, Daniel O'Connor wrote: > > On Tuesday 25 November 2003 11:52, Dan Nelson wrote: > > > > I'd greatly prefer that the the dynamic root default be backed out > > > > > >> > > until a substantial amount of this performance can be recovered. > >> > > >> > What _REAL WORLD_ task does this slow down? > >> > >> Try timing "cd /usr/ports/www/mozilla-devel ; make clean" with static > >> and dynamic /bin. bsd.port.mk spawns many many many /bin/sh processes. > > > > OK my bad, it will probably slow down the ports building. > > The ports infrastructure is horribly slow even with a static sh, though > not as glacially slow as installing and patching Solaris 9. > But if the change to dynamic root "provokes" this slowdown that people have been seeing, it would be much better to address the cause and not the symptom. The change to dynamic root here is not the cause, the extra overhead of using dynamically linked tools is, and that should be the main focus point. If the overhead of dynamic linking is reduced, that will benefit all of us, even if we use a dynamic root or not. -- Erik H. Bakke ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
From: "Stefan Farfeleder" <[EMAIL PROTECTED]> > > errno is meaningful for syscalls after an error (the original > > message). The fact that other functions also dink with errno is not > > relevant to that statement. > > I read boyd's statement as a contradiction to Jacques' one (only after > syscall error vs. after library call error). some libc functions do mangle errno, but only after an error. in my terse statement the intention was to affirm that errno is meaningless unless an error has ocurred (a syscall being the simplest case, while random other libc calls may behave in the same way). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
In message <[EMAIL PROTECTED]>, "boyd, rounin" write s: >From: "Stefan Farfeleder" <[EMAIL PROTECTED]> >> > errno is meaningful for syscalls after an error (the original >> > message). The fact that other functions also dink with errno is not >> > relevant to that statement. >> >> I read boyd's statement as a contradiction to Jacques' one (only after >> syscall error vs. after library call error). > >some libc functions do mangle errno, but only after an error. > >in my terse statement the intention was to affirm that errno is >meaningless unless an error has ocurred (a syscall being the >simplest case, while random other libc calls may behave in >the same way). Errno is undefined unless the relevant manual page states otherwise. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
i see that there some doubt about whether running lots of shell scripts ever happens. what happens when you use make? lots of shells get run and they run small (one line?) scripts. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: sleeping without a mutex (acd related)
I have been experiencing some random lockups after upgrading from
5.1-RELEASE to 5.2-BETA.
I then wen on and enabled all the debug options in my kernel config
hoping to be able to find the cause.
But now I cannot boot at all. In the end of the boot process when
detecting ATA drives, I get this:
ad0: 76319MB [155061/16/63] at ata0-master UDMA100
acd0-5: CDROM with 6 CD changer at ata1-master PIO4
acd6: DVDROM at ata1-slave PIO4
panic: sleeping without a mutex
Debugger("panic")
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db>
db> trace
Debugger(c06e3744,c07549a0,c06e3ec9,d861ab60,100) at Debugger+0x54
panic(c06e3ec9,0,c06e3eb8,c06d6584,10) at panic+0xd5
msleep(c45173d8,0,4c,c06d6584,0) at msleep+0x505
acd_geom_access(c452de00,1,0,0,0) at acd_geom_access+0x115
g_access_rel(c4509280,1,0,0,d861aca0) at g_access_rel+0x20d
g_slice_new(c0742a60,4,c452de00,d861ac9c,d861aca0) at g_slice_new+0xea
g_mbr_taste(c0742a60,c452de00,0,15b,c452dd80) at g_mbr_taste+0x90
g_new_provider_event(c452de00,0,c06de186,b5,6667) at g_new_provider_event+0d
one_event(d861ad10,c04f2b95,c074f994,0,4c) at one_event+0x218
g_run_events(c074f994,0,4c,c06dd10e,a) at g_run_events+0x15
g_event_procbody(0,d861ad48,c06e1304,311,2cb966) at g_event_procbody+0x45
fork_exit(c04f2b50,0,d861ad48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xd861ad7c, ebp = 0 ---
I am not a kernel expert but the problem seems to be related to acd.
--
Best regards
Christian Laursen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
> That's a more interesting result and more comparable to Drew's test. > It doesn't necessarily invalidate Drew's results - /bin/sh has 3 > shared libraries and is locale-aware whereas /usr/bin/test has 1 > shared library and doesn't rely on the locale. /usr/bin/true is also > significantly smaller (implying less relocation requirements). > /bin/sh could reasonably be expected to take longer to startup then > /usr/bin/test. another can of worms. various shells have test, true and false built in. so, you have to be very careful in writing a shell comparision benchmark. to complicate matters, ksh (statically linked) has _always_ been faster than sh. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Operating system advocacy (Was: Re: 40% slowdown with dynamic /bin/sh)
Matthew Dillon writes: > Hmm. Well, I think there's some confusion here. While I > certainly like my vision for DFly better then I like the vision > for FreeBSD-5, that is simply in the eye of the beholder... of > course I am going to like my own vision better. It's my vision, > after all! Your vision is obviously different. In fact, I expect > that each person has his own vision for the project, so don't > knock me for mine. There is a lot of opinion-knocking happening here on both sides, and tempers are flaring. Can I please ask that all parties take a step back and do what it takes to increase light and reduce heat? > But that has nothing to do with perceived inferiority or > superiority. True, inferiority/superiority issues are notoriously fulminative, and we need to get this track back to the technical level, and away from more personal achievment issues. > The issue isn't so much whether one project is better then the > other as it is whether one is able and willing to borrow a proven > concept from another project to replace the one that maybe isn't > so hot in one's own. No. This thread is about a much more basic issue; the resolution of the static/dynamic issue in the / volume. Which operating system has the better solution, while a valid discussion point, is a side track here, and is serving to add heat, not light. > As it happens, I have borrowed quite a bit of code > from 5.x. As it also happens, I believe that 5.x would benefit > by adopting some of the things that have already been proven to > work quite well in DragonFly. For example, using a statistical > time accumulation model instead of calling microtime() in the > middle of the critical thread switch path, or not preemptively > switching threads operating in kernelland to another cpu, or the > implementation of a mutexless scheduler. Just a few examples. I > can only point out the concepts and ideas and point to the code > in DFly, it is up to FreeBSD-5 developers to take the ball up and > either throw it away or run with it. Good points all. Perhaps they need to be discussed in their own right, and not as a digression to the original thread? > And, just for the record, I feel quite obligated to try to move > the FreeBSD project forward along a path that I believe will be > more beneficial to its users. Careful. You are working hard on a very admirable project; please can you continue to do do, and as-and-when issues from DFBSD prove their worth, they will be adopted by other projects. This is a case where the separation of strong personalities actually works out rather nicely, and you can help this by proving how well DFBSD technology is :-). There have been personality clashes in the past; some of these have been shown to be unresolvable, but we now have the improved situation where the talented folks are still developing BSD code without hindering each other. This way BSD and its users win. The way you can best help BSD is to continue to develop DragonFlyBSD. > Just to be clear: My obligation is to > all the people who use FreeBSD, not to the feelings of particular > developers whos vision(s) I might disagree with. I have no > intent or intention of screwing over FreeBSD (how absurd!) but > you should not mistakenly equate that to me being accomodating to > FreeBSD's current vision which, yes! it is true! I have serious > disagreements with. Sure. There are going to be disagreements, This is why there are 4 BSD's available for free. > Over the years I have recommended FreeBSD to hundreds of people > and I take that responsibility very seriously. Thank you! I hope that you will also be able to do that with DragonFlyBSD. > If it is within the scope of the FreeBSD charter for a person to > post based on a perceived obligation to the end users of FreeBSD, > then I certainly still have a right to post to this group. Sort of. General opinion-mongering, flamage, sidetracking and so on are off-charter. This is "FreeBSD CURRENT", and it is most likely the best to keep it somewhat restricted to that as some folks are starting to get annoyed at the "Dragonfly Advertising". I think that keeping DFBSD-Advocacy/Discussion on FreeBSD lists to a pretty low level would help keep blood pressure down all round (No offense intended, DFBSD is a worthwhile project, its just that inter-project politics are somewhat rough, and I'm trying to cool things down!) M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
WITHOUT_DYNAMICROOT vs. NO_DYNAMICROOT
Hi, There's a bug in the release notes of CURRENT: In Chapter 2.3 "Userland Changes" of the ReleaseNotes of CURRENT I read about the Makefile variable WITHOUT_DYNAMICROOT whereas /usr/src/Makefile.inc1 wants -DNO_DYNAMICROOT. It should be corrected in the ReleaseNotes (IMHO) mit freundlichen Grüßen / best regards Matthias Schündehütte SIEMENS AG, PTD M OI IT Tel. +49-30-386 29957 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: WITHOUT_DYNAMICROOT vs. NO_DYNAMICROOT
On 2003.11.25 12:52:03 +0100, Schuendehuette Matthias wrote: > Hi, > > There's a bug in the release notes of CURRENT: > > In Chapter 2.3 "Userland Changes" of the ReleaseNotes of CURRENT I read > about the Makefile variable WITHOUT_DYNAMICROOT whereas > /usr/src/Makefile.inc1 wants -DNO_DYNAMICROOT. > > It should be corrected in the ReleaseNotes (IMHO) Yes, that should be changed. I just asked the RE team permission to fix this (since we are in a code freeze at the moment). Thanks for reporting it. -- Simon L. Nielsen FreeBSD Documentation Team pgp0.pgp Description: PGP signature
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
On Mon, Nov 24, 2003 a.d., Jacques A. Vidrine wrote: > The application is broken. You must only check errno if you get an > error indication from the library call. Sorry, but I don't see your point. I know when to check for errno. If you took the little illustrating program for a real life example of the use of errno, that's unfortunate :-) The problem is that the emulated/wrapped close from libc_r does not behave like the real one. libc_r is leaking some of its guts (the tricks it's doing with O_NONBLOCK, etc) in the interface. This is technically a bug. The fix was trivial. Regards, Adi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: sleeping without a mutex (acd related)
On Tue, Nov 25, 2003 at 11:21:03AM +0100, Christian Laursen wrote:
+> I have been experiencing some random lockups after upgrading from
+> 5.1-RELEASE to 5.2-BETA.
+>
+> I then wen on and enabled all the debug options in my kernel config
+> hoping to be able to find the cause.
+>
+> But now I cannot boot at all. In the end of the boot process when
+> detecting ATA drives, I get this:
+>
+> ad0: 76319MB [155061/16/63] at ata0-master UDMA100
+> acd0-5: CDROM with 6 CD changer at ata1-master PIO4
+> acd6: DVDROM at ata1-slave PIO4
+> panic: sleeping without a mutex
+> Debugger("panic")
+> Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
+> db>
+> db> trace
+> Debugger(c06e3744,c07549a0,c06e3ec9,d861ab60,100) at Debugger+0x54
+> panic(c06e3ec9,0,c06e3eb8,c06d6584,10) at panic+0xd5
+> msleep(c45173d8,0,4c,c06d6584,0) at msleep+0x505
+> acd_geom_access(c452de00,1,0,0,0) at acd_geom_access+0x115
Yeah. There are two calls of tsleep(9) without timeout set
(in line 499, 509), so this KASSERT is reached:
KASSERT(timo != 0 || mtx_owned(&Giant) || mtx != NULL,
("sleeping without a mutex"));
--
Pawel Jakub Dawidek [EMAIL PROTECTED]
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
pgp0.pgp
Description: PGP signature
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
On Tue, 25 Nov 2003, Enache Adrian wrote: > On Mon, Nov 24, 2003 a.d., Jacques A. Vidrine wrote: > > The application is broken. You must only check errno if you get an > > error indication from the library call. > > Sorry, but I don't see your point. I know when to check for errno. > If you took the little illustrating program for a real life example of > the use of errno, that's unfortunate :-) > > The problem is that the emulated/wrapped close from libc_r does not > behave like the real one. libc_r is leaking some of its guts > (the tricks it's doing with O_NONBLOCK, etc) in the interface. > This is technically a bug. The fix was trivial. I don't see a bug. You don't check errno unless the return is -1. If the return is -1, then it must be because "ret = __sys_close(fd)" failed in which case errno will be set appropriately. Even so, there are other things to worry about aside from the fcntl to set the flags. The wrapped close also uses fstat(2) which can fail in ways not listed by close(2). -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to fix this in 5.1-REL??
* Kevin Oberman <[EMAIL PROTECTED]> [20031125 02:39]: wrote: > > Date: Sat, 22 Nov 2003 06:07:03 -0800 > > From: Kris Kennaway <[EMAIL PROTECTED]> > > Sender: [EMAIL PROTECTED] > > > > > > --nVMJ2NtxeReIH9PS > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > > > On Sat, Nov 22, 2003 at 03:16:06PM +0300, Odhiambo Washington wrote: > > > I end up with the following when I run `make world` on 5.1-RELEASE-p10. > > > > Did you read UPDATING? > > I fear a bikeshed, but I really think it may be past time to remove > the 'world' target from /usr/src/Makefile.inc1. It is rarely useful > and only should be used by those who understand the process and know > that it is safe. Removing it would remove a clear way to shoot one's > foot and would really have trivial impact on those who use it > properly. Hmm, This was meant to help me but instead I was left speechless, not knowing how to say that I did not understand the context of this ;) How am I supposed to go over the initial problem? When Kris Kennaway asked me that question, I emphatically told him, YES, I did. Then what he thought I should do was to rm /usr/include/g++/* I did exactly that, but it did not help solve the problem and even so, I wasn't quite sure why I was to do this, after re-reading from UPDATING. So my problem is very much alive and kicking ;) -Wash -- +==+ |\ _,,,---,,_ | Odhiambo Washington<[EMAIL PROTECTED]> Zzz /,`.-'`'-. ;-;;,_ | Wananchi Online Ltd. www.wananchi.com |,4- ) )-,_. ,\ ( `'-'| Tel: +254 20 313985-9 +254 20 313922 '---''(_/--' `-'\_) | GSM: +254 722 743223 +254 733 744121 +==+ Every improvement in communication makes the bore more terrible. -- Frank Moore Colby smime.p7s Description: S/MIME cryptographic signature
Cardbus cards break bge0
I recently cvsup'ed (last week anyway), and build/installed world/kernel etc. Now, when I connect a cardbus card (firewire cards, ethernet, wireless, etc), my broadcom bge0 interface goes crazy, stops functioning, and I get this: Nov 19 10:18:32 neutrino kernel: cardbus0: Resource not specified in CIS: id=10, size=1 Nov 19 10:18:32 neutrino kernel: bge1: mem 0xf601-0xf601 irq 11 at device 0.0 on cardbus0 Nov 19 10:18:32 neutrino kernel: bge1: RX CPU self-diagnostics failed! Nov 19 10:18:32 neutrino kernel: bge1: chip initialization failed Nov 19 10:18:32 neutrino kernel: device_probe_and_attach: bge1 attach returned 6 Nov 19 10:18:32 neutrino kernel: cbb0: CardBus card activation failed Nov 19 10:18:32 neutrino kernel: bge0: PHY read timed out Nov 19 10:18:48 neutrino last message repeated 85 times My gigabit ethernet (the broadcom) card device (which is onboard - this is a laptop) is bge0. Notice above it complains about bge1, then the "PHY read timed out" errors start. If I boot with the card installed, here's what I get: Nov 19 10:23:35 neutrino kernel: bge0: PHY read timed out Nov 19 10:23:35 neutrino last message repeated 9 times Nov 19 10:23:35 neutrino kernel: bge0: RX CPU self-diagnostics failed! Nov 19 10:23:35 neutrino kernel: bge0: flow-through queue init failed Nov 19 10:23:35 neutrino kernel: bge0: initialization failure Anyone have any ideas on what caused this breakage? Eric -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
On Mon, Nov 24, 2003 at 07:11:29PM -0800, Matthew Dillon wrote: > You don't need dynamic loading to get nsswitch type functionality. You > only need dynamic loading if nobody is willing to write an IPC > model to get the functionality. It's really silly to create such a > fundamental restriction on the binary because people are too lazy > to build an IPC based mechanism. Matt, I'm not lazy. (Well, maybe I am, but that's not why I implemented NSS in the canoncial way instead of using IPC.) I've experimented with proxy-based solutions. Such solutions add a lot of complexity with little benefit. The primary NSS backends today are: NIS --- lightweight, proxy would just slow things down Hesiod --- lightweight winbindd --- lightweight (it implements its own proxy) nss_ldap --- could benefit IMHO, it makes more sense to write NSS modules that do their own proxying than to make things even more complicated in libc. Those that are lightweight don't carry extra baggage; those that do can implement proxying in the most efficient manner for that particular backend, e.g. some calls can be proxyed while others done in-process. You don't have to rewrite existing NSS modules so that they take into account that they are really serving multiple processes--- which usually means adding credentials management, locking, per-process state, and so forth to each NSS module. Or you could just create a whole new NSS API and call it something else and forget about support for existing NSS modules. Caching results (which is different than out-of-process implementations, the Linux nscd authors are just confused) does require a daemon, but this doesn't really complicate things. (I should get around to that someday :-) That said, I would not stand in the way of a well-thought out, well-written NSS implementation that attempts to proxy every get*() call over e.g. RPC. (Hmm, sounds like NIS to me. I guess that's partially explains why PADL.com's NIS<->LDAP gateway is popular :-) > Not only silly, but it seems to me > that it also creates security issues. At least with a client/server > model it is possible to isolate the authentication code to, for example, > disallow exec(), filesystem operations, or the opening of any new files. Um, if you can't trust the authentication code, what can you trust? Furthermore, for many many many applications that use getpwnam(3) and so on, increased privileges are not needed or wanted. And if you *are* really talking about authentication code (and not directory services), then you need to get PAM to work in a statically linked world, also. (You can compile PAM statically today, but that means no 3rd-party modules. The same holds for NSS, of course.) > The other huge advantage that IPC has over DLL is that you can switchout > the backend mechanisms on a running system without killing and restarting > anything other then he one service you want to switch out, and if it > doesn't work right you can restart the old one or keep live as a fallback. When using the current NSS implementation, there is no need to kill/restart anything when you update /etc/nsswitch.conf. New modules are dynamically loaded, and any no-longer-referenced ones are unloaded. > the IPC model is so much better then the DLL model for this sort of thing > I don't understand why people are even arguing about it. Because the rest of us are stupid and lazy, remember? :-) Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pcm(4) related panic
Hello, On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic like this: (watch out for folded lines; the stack backtrace below is rewritten by hand from ddb) lock order reversal 1st 0xc22a45ac vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 2nd 0xc06c0420 swap_pager swhash (swap_pager swhash) @ \ /usr/src/sys/vm/swap_pager.c:1838 3rd 0xc0c358c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 Stack backtrace: backtrace witness_lock _mtx_lock_flags obj_allock slab_zalloc uma_zone_slab uma_zalloc_internal uma_zalloc_arg swp_pager_meta_build swap_pager_putpages default_pager_putpages vm_pageout_flush vm_pageout_clean vm_pageout_scan vm_pageout fork_exit fork_trampoline Sleeping on "swread" with the following non-sleepable locks held: exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \ /usr/src/sys/dev/sound/pcm/dsp.c:146 panic: sleeping thread (pid 583) owns a non-sleepable lock syncing disks, buffers remaining... 1410 1410 panic: mi_switch: \ switch in a critical section Uptime: 1m45s panic: msleep Uptime: 1m45s panic: msleep Uptime: 1m45s panic: msleep Uptime: 1m45s panic: msleep [... repeated few more times] Fatal double fault: eip = 0xc05e3916 esp = 0xc8db8ff4 ebp = 0xc8db9004 panic: double fault Uptime: 1m45s panic: msleep Uptime: 1m45s panic: msleep Uptime: 1m45s panic: msleep Uptime: 1m45s [...] And the machine suddenly reboots, so there is no coredump. eip address points close to: c05e3910 T sc_vtb_putc To reproduce this panic just start some audio player app (like xmms), and launch countless memory-eating applications (like mozilla ;>). The machine starts swapping, and it panics. % uname -a FreeBSD kaszanka.domek 5.2-BETA FreeBSD 5.2-BETA #0: Sun Nov 23 01:23:10\ CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KASZANKA i386 dmesg fragments: CPU: AMD Athlon(tm) XP 2000+ (1666.73-MHz 686-class CPU) pcm0: port 0xec00-0xec3f irq 10 at device 8.0 on pci0 pcm0: rl0: port 0xe800-0xe8ff mem \ 0xdf00-0xdfff ir q 10 at device 10.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: port 0xe400-0xe4ff mem \ 0xde00-0xdeff ir q 10 at device 11.0 on pci0 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Regards, Artur ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
On Mon, Nov 24, 2003 at 10:06:12PM -0500, Andrew Gallatin wrote: > How about Gordon's initial bootstone, which increased by 25%? > http://docs.freebsd.org/cgi/mid.cgi?16091.44150.539095.704531 > > And I just did a "make clean" run in /usr/ports/archivers (by manually > mv'ing a static and dynamic sh to /bin in turn): > > static: 96.63 real53.45 user39.27 sys > dynamic: 112.42 real55.51 user51.62 sys > > The wall clock is bad (16% worse) and the system time is worse (31%). > > > So.. > > 1) Microbenchmark:40% worse > 2) Bootstone(*): 25% worse > 3) Ports: 16% worse So can we just have a statically linked /bin/sh and get on with life? That seems to have the most impact. We can also expend our efforts to improve dynamic linking performance, since that will improve the performance of the other 99.9% of the universe. Users who REALLY REALLY need /bin/sh to support 3rd-party NSS modules in the mean time can build /bin/sh dynamically. Or we can have /usr/bin/sh as someone else suggested (most of the FreeBSD world's shell scripts--- which are what we *really* seem to be talking about--- already have #! /bin/sh). I prefer to keep as much of the world dynamic, both for dlopen support and for easier system patching. But I can also understand the desire to avoid a penalty for all those short but oft-run scripts. In any case, I'd really like to see a goal for 5.3-RELEASE that includes bringing dynamically-linked /bin/sh performance (*much*) closer to statically-linked /bin/sh performance. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
On Mon, Nov 24, 2003 at 08:22:52PM -0600, David Leimbach wrote: > Yep :). > > I feel like saying "set the default to static and make the dynamic bins > the option" so > the people who can't be bothered to compile their own system even > though everyone > I know does this for tuning purposes anyway can stop whining. > > But I won't say that. I feel we need to pressure to improve the performance of dynamic linking. This is not really different from anything else we do in -CURRENT: some things we have to throw out there before it is perfect, in order to reach critical mass. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: 40% slowdown with dynamic /bin/sh
Jacques A. Vidrine wrote: > On Mon, Nov 24, 2003 at 10:06:12PM -0500, Andrew Gallatin wrote: > > How about Gordon's initial bootstone, which increased by 25%? > > http://docs.freebsd.org/cgi/mid.cgi?16091.44150.539095.704531 > > > > And I just did a "make clean" run in /usr/ports/archivers (by manually > > mv'ing a static and dynamic sh to /bin in turn): > > > > static: 96.63 real53.45 user39.27 sys > > dynamic: 112.42 real55.51 user51.62 sys > > > > The wall clock is bad (16% worse) and the system time is worse (31%). > So can we just have a statically linked /bin/sh and get on with life? > That seems to have the most impact. We can also expend our efforts > to improve dynamic linking performance, since that will improve the > performance of the other 99.9% of the universe. Yes, let's do it and get on with it. /bin/sh is critically important to the performance of many things in the system, but shared / is very useful as well - it's allowed me to move my 4.x systems with small / up to 5-current, and / programs can take advantage of NSS and PAM modules that exist *today*. > ... > In any case, I'd really like to see a goal for 5.3-RELEASE that > includes bringing dynamically-linked /bin/sh performance (*much*) > closer to statically-linked /bin/sh performance. Yes -- this is -current: let's get 5.2 out the door and improve on it for 5.3. Guy Helmer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
Jacques A. Vidrine writes: > > So can we just have a statically linked /bin/sh and get on with life? That certainly seems like the best compromise. Then we can end this thread ;) > That seems to have the most impact. We can also expend our efforts > to improve dynamic linking performance, since that will improve the > performance of the other 99.9% of the universe. > What happened to mdodd's prebinding efforts? Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Mon, Nov 24, 2003 at 02:41:44PM -0800 I heard the voice of David O'Brien, and lo! it spake thus: > On Mon, Nov 24, 2003 at 04:07:49PM -0500, Michael Edenfield wrote: > > > > Would it be possible, through some make.conf magic, for the end-user to > > set extra programs to be put into /rescue that are not typically there? > > > > RESCUE_EXTRAPRGS= usr.bin/vi usr.bin/fetch > > This list could easily need things added to librescue. If you can delay building the rescue stuff until after everything else, you can use ldd(1) on the built binaries for everything else and hash up the list from that. I do something similar in a set of scripts I have to generate filesystems for small systems (i.e., I create a variable in a Makefile listing all the programs, and it automatically includes all the libraries the programs need) with a little sed/awk. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
4 -> 5 Problem
I build 5-CURRENT every night, and NFS export src and obj to my other CURRENT machines to update. I've been doing this quite happily this way for a while. When I try to do an installkernel on a stable machine, I get: [EMAIL PROTECTED]:/usr/src# make installkernel Bad system call (core dumped) *** Error code 140 Stop in /usr/src. I can no longer do this on any of the current boxes either: mkdir -p /boot/kernel install -p -m 555 -o root -g wheel kernel /boot/kernel *** Signal 12 Stop in /usr/obj/usr/src/sys/P6MPFW. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I tried with -DALWAYS_CHECK_MAKE as well. Have I missed something in UPDATING? Anyone else doing this without issue? the Current target machine is from Thu Sep 25 14:32:19 GMT 2003, the stable one from Mon Mar 24 16:30:45 GMT 2003, and the src and obj are fresh from last night. Lawrence Farr EPC Direct Limited ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
In message <[EMAIL PROTECTED]>, "Jacques A. Vidrine" wri tes: > So can we just have a statically linked /bin/sh and get on with life? I was thinking the same thing myself a few days ago. Cheers, -- Cy Schubert <[EMAIL PROTECTED]>http://www.komquats.com/ BC Government . FreeBSD UNIX [EMAIL PROTECTED] . [EMAIL PROTECTED] http://www.gov.bc.ca/ .http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4 -> 5 Problem
On Tue, 25 Nov 2003 16:18:26 - "Lawrence Farr" <[EMAIL PROTECTED]> wrote: > > the Current target machine is from Thu Sep 25 14:32:19 GMT 2003, > the stable one from Mon Mar 24 16:30:45 GMT 2003, and the > src and obj are fresh from last night. did you read /usr/src/UPDATING ? 20031112: The statfs structure has been updated with 64-bit fields to allow accurate reporting of multi-terabyte filesystem sizes. You should build world, then build and boot the new kernel BEFORE doing a `installworld' as the new kernel will know about binaries using the old statfs structure, but an old kernel will not know about the new system calls that support the new statfs structure. clem ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: 4 -> 5 Problem
Err yes I did. Im trying to install a kernel. Lawrence Farr EPC Direct Limited > -Original Message- > From: Clement Laforet [mailto:[EMAIL PROTECTED] > Sent: 25 November 2003 16:26 > To: Lawrence Farr > Cc: [EMAIL PROTECTED] > Subject: Re: 4 -> 5 Problem > > On Tue, 25 Nov 2003 16:18:26 - > "Lawrence Farr" <[EMAIL PROTECTED]> wrote: > > > > the Current target machine is from Thu Sep 25 14:32:19 GMT 2003, > > the stable one from Mon Mar 24 16:30:45 GMT 2003, and the > > src and obj are fresh from last night. > > did you read /usr/src/UPDATING ? > > 20031112: > The statfs structure has been updated with 64-bit fields to > allow accurate reporting of multi-terabyte filesystem > sizes. You should build world, then build and boot > the new kernel > BEFORE doing a `installworld' as the new kernel will > know about > binaries using the old statfs structure, but an old > kernel will > not know about the new system calls that support the > new statfs > structure. > > clem > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
requesting vinum help
Could a vinum guru please contact me via email? I've lost 2 vinum volumes as a result of the latest fiasco and naturally am eager to figure out what's going on and recover the data. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: requesting vinum help
Could a vinum guru please contact me via email? I've lost 2 vinum volumes as a result of the latest fiasco and naturally am eager to figure out what's going on and recover the data. This isn't necessarily directed at you - I'm just using this email as a footstep to send this general comment - I am kind of under the assumption that -current is more of a test bed, and anything can happen at any time, which is why it's bad to run -current on a machine you care deeply about (at least its data). I think I've seen at least 5 mails in the past few weeks about people getting jammed into a corner with (what sounds like) production type boxes, or at least important boxes (or they wouldn't need a vinum?).. It seems odd to me that they wouldn't give it a whirl first before attempting to use it on a box they seem so protective of. Anyway, I'm just stating that running -current is for testing and developing, not really for production - at least I'm fairly certain. Feel free to delete this mail and ignore me.. Eric -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
At 9:19 AM -0600 11/25/03, Jacques A. Vidrine wrote: On Mon, Nov 24, 2003, Andrew Gallatin wrote: So can we just have a statically linked /bin/sh and get on with life? I still think we would be better off using 5.2-release for collecting more experience with the *operational* issues of having a dynamic /bin/sh. We all know and knew that there would be a performance hit. We also all know that a static /bin/sh will work fine in disaster situations. That seems to have the most impact. We can also expend our efforts to improve dynamic linking performance, since that will improve the performance of the other 99.9% of the universe. This is certainly my hope. There are more ways to solve the performance problem than just statically-linking /bin/sh. If we do not alleviate the performance issues via other means, then we can certainly statically-link /bin/sh for 5.3-release. We have run with a statically-linked /bin/sh for years, so there is nothing much to *learn* by running with it for the next two months. Yes, there is a performance benefit, but nothing to *learn*. But my fear is that if we *do* address the performance issues, then we'll still shy off a dynamically-linked /bin/sh simply because some folks will say "we don't know that we can trust it", etc. I have no objection if we want to statically-link some things like /bin/sh for 5.3-release, but I don't think we need to do it for 5.2-release -- aka "a snapshot of freebsd-current". -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to fix this in 5.1-REL??
> Date: Tue, 25 Nov 2003 17:47:29 +0300 > From: Odhiambo Washington <[EMAIL PROTECTED]> > > > --+g7M9IMkV8truYOl > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > * Kevin Oberman <[EMAIL PROTECTED]> [20031125 02:39]: wrote: > > > Date: Sat, 22 Nov 2003 06:07:03 -0800 > > > From: Kris Kennaway <[EMAIL PROTECTED]> > > > Sender: [EMAIL PROTECTED] > > >=20 > > >=20 > > > --nVMJ2NtxeReIH9PS > > > Content-Type: text/plain; charset=3Dus-ascii > > > Content-Disposition: inline > > >=20 > > > On Sat, Nov 22, 2003 at 03:16:06PM +0300, Odhiambo Washington wrote: > > > > I end up with the following when I run `make world` on 5.1-RELEASE-= > p10. > > >=20 > > > Did you read UPDATING? > >=20 > > I fear a bikeshed, but I really think it may be past time to remove > > the 'world' target from /usr/src/Makefile.inc1. It is rarely useful > > and only should be used by those who understand the process and know > > that it is safe. Removing it would remove a clear way to shoot one's > > foot and would really have trivial impact on those who use it > > properly. > > > Hmm, > > This was meant to help me but instead I was left speechless, not knowing > how to say that I did not understand the context of this ;) > How am I supposed to go over the initial problem? > When Kris Kennaway asked me that question, I emphatically told him, YES, > I did. Then what he thought I should do was to rm /usr/include/g++/* > I did exactly that, but it did not help solve the problem and even so, > I wasn't quite sure why I was to do this, after re-reading from UPDATING. > So my problem is very much alive and kicking ;) This was not addressed so much to you as to the list. The following is a history lesson. Sorry to waste the time of those who have been with FreeBSD for a long time and know all about it. While UPDATING contain details on updating a system, the Makefile in /usr/src (actually Makefile.inc1) contains a target of 'world' and, through V3 of FreeBSD, this was considered the appropriate target for re-compiling sources. In the days of V4, a new methodology for updating that was far less prone to failure that would leave a system unusable was developed with two new targets, 'buildworld' and 'installworld'. The old 'world' target was left in the file as it could still be used and people were used to using it (POLA). But, as V4 developed, UPDATING specified only the "new" method of updating and the developers could integrate changes in ways that would not work with the 'world' target. Now we are moving on to V5 and 'world' is growing increasingly dangerous to use. Because changes are applied that will allow smooth upgrades when the kernel is built after the new system is built, but before it is installed, "make world" is increasingly unlikely to work. I was suggesting that it's time to eliminate this excellent path to foot-shooting once and for all. In addition, people often do miss the section of UPDATING on the V4 to V5 upgrade and end up with the wrong version of loader (which is pretty sure to get fixed promptly) and with the /usr/include/g++ headers intact. This can produce all kinds of build problems down the road. I have no idea how to get the message about this across any better, but I know that when V5 is declared "stable", we are going to see a flood of failed builds as a result of this oversight. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
"Matthew D. Fuller" <[EMAIL PROTECTED]> wrote: > >Not just the startup scripts, but ANY script. I dare say there's a long, >long list of scripts that use ~-expansion, to say nothing of the >homegrown ones we all have working quietly and forgotten for years. It's required for POSIX compliance. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ IRISH SEA: SOUTHWESTERLY 5 OR 6. SHOWERS. GOOD. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
Robert Watson <[EMAIL PROTECTED]> wrote: > >Someone must be using /bin/sh as a shell, because apparently someone >spent a lot of time adding things like character input editing, filename >completion, etc. We even use "sh" as the default in adduser(8). Command-line editing is required for POSIX compliance. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ FAIR ISLE: SOUTHWESTERLY BACKING EASTERLY 5 TO 7, PERHAPS GALE 8 LATER. SHOWERS THEN RAIN. MODERATE OR GOOD. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
In message: <[EMAIL PROTECTED]> "boyd, rounin" <[EMAIL PROTECTED]> writes: : i see that there some doubt about whether running lots of : shell scripts ever happens. what happens when you : use make? lots of shells get run and they run small : (one line?) scripts. make buildworld slows down < 1% when you switch from static /bin/sh to dynamic. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
rc scripts run double on boot?
With a recent -current, I've noticed double prints for the last few rc scripts, like this: Starting cron. Local package initialization:. Local package initialization:. Additional TCP options:. Additional TCP options:. Anyone else seeing this? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Intel SE7500WV2 not working with ACPI
Since the interrupt changes, my dual Xeons based on the SE7500WV2 board don't work with ACPI. Specificly, the onboard nics (em0 and em1) appear to not be recieving interupts. Instead, they continiously get watchdog timeouts. In a stock current, this is an instant panic. With a minor fix to the watchdog function, the system sees to be more or less funcitonal other then not having a network. Disabling ACPI makes the nics work. I have updated the BIOS to the latest version[0]. I've included ACPI and non-ACPI dmesg output below. What else is needed to diagnose this problem? Any patches I should try? -- Brooks [0] In a way, I'm glad the BIOS update didn't fix the problem because that would probably mean I'd have to flash another 70 machines. Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #1: Tue Nov 11 14:45:00 PST 2003 [EMAIL PROTECTED]:/usr/home/brooks/working/freebsd/p4/xname/sys/i386/compile/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a75000. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) XEON(TM) CPU 2.20GHz (2193.54-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff Hyperthreading: 2 logical CPUs real memory = 1073676288 (1023 MB) avail memory = 1033482240 (985 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard lapic0: Forcing LINT1 to edge trigger Pentium Pro MTRR support enabled ACPI-0660: *** Warning: Type override - [DEB_] had invalid type (Integer) for Scope operator, changed to (Scope) ACPI-0660: *** Warning: Type override - [MLIB] had invalid type (Integer) for Scope operator, changed to (Scope) ACPI-0660: *** Warning: Type override - [DATA] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0660: *** Warning: Type override - [SIO_] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0660: *** Warning: Type override - [LEDP] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0660: *** Warning: Type override - [GPEN] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0660: *** Warning: Type override - [GPST] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0660: *** Warning: Type override - [WUES] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0660: *** Warning: Type override - [WUSE] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0660: *** Warning: Type override - [SBID] had invalid type (String) for Scope operator, changed to (Scope) ACPI-0660: *** Warning: Type override - [SWCE] had invalid type (String) for Scope operator, changed to (Scope) acpi0: on motherboard ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_._REG] (Node 0xc29b4660), AE_NOT_EXIST acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST device_probe_and_attach: acpi0 attach returned 6 npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 19 entries at 0xc00f3060 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pci_cfgintr: 0:29 INTA BIOS irq 5 pci_cfgintr: 0:29 INTB BIOS irq 10 pci0: at device 0.1 (no driver attached) pcib1: at device 3.0 on pci0 pci2: on pcib1 pci2: at device 28.0 (no driver attached) pcib2: at device 29.0 on pci2 pci4: on pcib2 pci2: at device 30.0 (no driver attached) pcib3: at device 31.0 on pci2 pci3: on pcib3 pci_cfgintr: 3:7 INTA BIOS irq 5 pci_cfgintr: 3:7 INTB BIOS irq 5 em0: port 0x2040-0x207f mem 0xfeac-0xfead irq 5 at device 7.0 on pci3 em0: Speed:N/A Duplex:N/A em1: port 0x2000-0x203f mem 0xfeae-0xfeaf irq 5 at device 7.1 on pci3 em1: Speed:N/A Duplex:N/A pci0: at device 3.1 (no driver attached) uhci0: port 0x3020-0x303f irq 5 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 0x3000-0x301f irq 10 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 pcib4: at device 30.0 on pci0 pci1: on pcib4 pci_cfgintr: 1:2 INTA BIOS irq 9 pci_cfgintr: 1:12 INTA BIOS irq 11 atapci0: port 0x1420-0x142f,0x140c-0x140f,0x1410-0x1417,0x1408-0x140b,0x1400-0x1407 mem 0xfe9e-0xfe9e3fff irq 9 at device 2.0 on pci1 atapci0: [MPSAFE] ata2: at 0x1400 on atapci0 ata2: [MPSAFE] ata3: at 0x1410 on atapci0 ata3: [MPSAFE] pci1: at device 12.0 (no driver attached) isab0: at device 31.0 on pci0 i
Re: 40% slowdown with dynamic /bin/sh
"Daniel O'Connor" <[EMAIL PROTECTED]> writes: > What _REAL WORLD_ task does this slow down? I suspect 'make world' takes a serious hit. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: /bin and /sbin are now dynamically linked
At 10:09 AM -0600 11/25/03, Matthew D. Fuller wrote: On Mon, Nov 24, 2003, I heard the voice of David O'Brien, and lo! it spake thus: > On Mon, Nov 24, 2003, Michael Edenfield wrote: > > > > Would it be possible, through some make.conf magic, for > > the end-user to set extra programs to be put into /rescue > > that are not typically there? > > > RESCUE_EXTRAPRGS= usr.bin/vi usr.bin/fetch This list could easily need things added to librescue. If you can delay building the rescue stuff until after everything else, you can use ldd(1) on the built binaries for everything else and hash up the list from that. It is a bit more complicated than that, because programs may include embedded references to other files. So, I think some developer would *have* to do a little up-front work for any program that would be optionally-added to /rescue. Also, if you completely automate it, then a year from now someone will make a change to 'vi' which drags in a few extra libraries, and people will be blind-sided with a much larger /rescue. If someone is watching what happens, they could #ifdef-out that extra code for the /rescue version. I do like the idea, but to do it right *will* involve extra work for each optional program. I would gladly do that extra work for any programs that I cared to have in /rescue -- but personally I set up dual-boot systems, so I don't really care about any of them... :-) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NFS lockup issues & xl0 timeouts
Update on xl0 issues and NFS issues: I unfortunatly left my realtek network card in work so I'll do this tomorrow night instead of tonight. But I've now installed the absolute latest world/kernel on both server and client again to see if the hang has gone. I have noticed the NFS transfer hangs at the same point always. If I cp mysql-4.0.16.tar.gz to /usr/src it hangs instantly and always with this filesize: -rw-r--r--1 root wheel 122880 Nov 25 18:30 mysql-4.0.16.tar.gz Is that significant in any way? Another test I just did is swap the roles of the client and server around. So I've ran a server on the client and mounted the directory on the server. Doing this and NFS works perfectly writing to the server but not reading. It hangs whilst reading. Left for 5 minutes so far: -rw-r--r-- 1 root wheel 65536 Nov 25 18:39 mysql-4.0.16.tar.gz This filesize looks significant to me. Like a buffer is full or something. So this suggests I have a problem only in the one direction. And this is also the direction I have the xl0 transfer problems with. I would suggest my problems are totally down to the xl0 card/driver and not NFS related at all. I will find this out once and for all when I test with the realtek card tomorrow night (when I remember to bring it home from work). The affected card is: [EMAIL PROTECTED]:7:0: class=0x02 card=0x100010b7 chip=0x920010b7 rev=0x74 hdr=0x00 vendor = '3COM Corp, Networking Division' device = '3C905C-TX Fast EtherLink for PC Management NIC' class= network subclass = ethernet xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x1000-0x107f mem 0xfc304800-0xfc30487f irq 10 at device 7.0 on pci5 xl0: Ethernet address: 00:04:76:8d:c5:fd miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Regards, Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [Me too]: rc scripts run double on boot?
On Tue, 25 Nov 2003, it was written: > On Tuesday 25 November 2003 18:35, Nate Lawson wrote: > > With a recent -current, I've noticed double prints for the last few > > rc scripts, like this: > > > > Starting cron. > > Local package initialization:. > > Local package initialization:. > > Additional TCP options:. > > Additional TCP options:. > > > > Anyone else seeing this? > > Yes, since the last buldworld, which was quite a while ago: > # uname -a > FreeBSD kiste.local 5.1-CURRENT FreeBSD 5.1-CURRENT #8: Wed Oct 29 > 20:49:45 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 The suggested fix works for me: rm -rf /etc/rc.d/* mergemaster Of course, make sure you don't have local changes in /etc/rc.d first. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to fix this in 5.1-REL??
On Tue, 25 Nov 2003 08:57:10 -0800 "Kevin Oberman" <[EMAIL PROTECTED]> wrote: > Now we are moving on to V5 and 'world' is growing increasingly dangerous > to use. Because changes are applied that will allow smooth upgrades > when the kernel is built after the new system is built, but before it is > installed, "make world" is increasingly unlikely to work. > > I was suggesting that it's time to eliminate this excellent path to > foot-shooting once and for all. By disabling it temporarily until 5-current becomes 5-stable and such changes are very unlikely to get applied? Bye, Alexander. -- Reboot America. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: /bin and /sbin are now dynamically linked
Would it be possible to get a copy of this script? Please! :) Matthew D. Fuller wrote: On Mon, Nov 24, 2003 at 02:41:44PM -0800 I heard the voice of David O'Brien, and lo! it spake thus: On Mon, Nov 24, 2003 at 04:07:49PM -0500, Michael Edenfield wrote: Would it be possible, through some make.conf magic, for the end-user to set extra programs to be put into /rescue that are not typically there? RESCUE_EXTRAPRGS= usr.bin/vi usr.bin/fetch This list could easily need things added to librescue. If you can delay building the rescue stuff until after everything else, you can use ldd(1) on the built binaries for everything else and hash up the list from that. I do something similar in a set of scripts I have to generate filesystems for small systems (i.e., I create a variable in a Makefile listing all the programs, and it automatically includes all the libraries the programs need) with a little sed/awk. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
:IMHO, it makes more sense to write NSS modules that do their own :proxying than to make things even more complicated in libc. Those :that are lightweight don't carry extra baggage; those that do can :implement proxying in the most efficient manner for that particular :backend, e.g. some calls can be proxyed while others done in-process. :You don't have to rewrite existing NSS modules so that they take into :account that they are really serving multiple processes--- which :usually means adding credentials management, locking, per-process :state, and so forth to each NSS module. Or you could just create a :whole new NSS API and call it something else and forget about support :for existing NSS modules. : :Caching results (which is different than out-of-process :implementations, the Linux nscd authors are just confused) does :require a daemon, but this doesn't really complicate things. (I :should get around to that someday :-) : :That said, I would not stand in the way of a well-thought out, :well-written NSS implementation that attempts to proxy every get*() :call over e.g. RPC. (Hmm, sounds like NIS to me. I guess that's :partially explains why PADL.com's NIS<->LDAP gateway is popular :-) Well, here's the issue... where do you think the future is? I believe the future is in large, extended clusters of machines which either need to agree on their management resources or which need to be capable of hierarchically accessing a global resource namespace. Sure you can do this within the nsswitch framework, by writing particular NSS modules that then going out and implementing some other proxy protocol. But most NSS modules are not going to be written with IPC in mind so it would be a fairly difficult and involved job to create an integrated framework capable of the above within NSS. Without doing that you would be restricted to only those modules which are directly capable of proxying *AND* you would have to contend with various proxy-capable modules using different protocols. In otherwords, it's a mess. It seems silly to waste your time on a framework that you are just going to have to rip out again a year or two from now. By using an IPC mechanism from the start the framework and centralization issues go away. Poof, gone. No issue. A module written as an IPC service doesn't know or care (other then for authentication purpopses) who is making requests of it. In DFly it is particularly important because we are going for an SSI-capable result and you just can't do that with NSS (at least not without devaluing the NSS mechanism so much you might as well not have used it in the first place!). The absolute worst case in an IPC framework is that the program trying to access service X and not being able to find it would have to fork/exec the service binary itself to create the IPC connection. This, of course, would only occur under extrodinary circumstances (such as when you are in single-user mode). But despite the overhead we are only talking about two lines of code, really. fork() and exec(). Well, three... pipe(), fork(), and exec(). In regards to caching... with an IPC mechanism the client can choose to cache the results however it pleases. The IPC mechanism can simply notify the client asynchronously if a cache invalidation is required. That's what a real messaging/port protocol gives you the ability to do. So generaly performance using the IPC mechanism is going to be as good or better then what we currently have with uncached flat files or uncached databases. Which brings up yet another cool result ... when you use an IPC mechanism you don't need to generate DBM's. The service process itself will simply scan /etc/master.passwd, /etc/group, and so forth, and build its own in-memory database. Being able to get rid of the DBMs is only part of the equation because it also means that files which are not otherwise DBM's, such as /etc/services and /etc/group, enjoy the same feature. :Um, if you can't trust the authentication code, what can you trust? :Furthermore, for many many many applications that use getpwnam(3) and :so on, increased privileges are not needed or wanted. Think out of the box.Consider a multi-layered approach. Take access to master.passwd for example. Would you have (A) the authentication code integrated into the potentially buggy program be able to access the file directly or would you rather have (B) the authentication code access an IPC service which *ONLY* allows challenge/response, does *NOT* give you direct access to the encrypted contents of the password file, and which limits the challenge rate to prevent dictionary attacks? That's about the best example that I can come up with. Think about it... the *ONLY* code that has access to the actual
Re: Intel SE7500WV2 not working with ACPI
> acpi0: on motherboard > ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_._REG] (Node > 0xc29b4660), AE_NOT_EXIST > acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST > device_probe_and_attach: acpi0 attach returned 6 This is the source of the problems. When acpi0 fails to attach, everything else is done through the legacy PCI code. The question is, why is it failing? The above-mentioned EC method could indicate the problem is in walking the namespace but we'll have to look at the ASL to be sure. Please send a url to the output of: acpidump -t -d > brooks-Intel.asl Also, build with options ACPI_DEBUG and set these in your loader.conf: debug.acpi.layer="ACPI_ALL_COMPONENTS" debug.acpi.level="ACPI_LV_OPREGION" -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
On Tue, Nov 25, 2003 at 11:50:25AM -0800, Matthew Dillon wrote: > Just not thinking out of the box, maybe. Matt, I'm talking about the de facto standard NSS, as found in Solaris and Linux; and now FreeBSD 5 [*] and soon NetBSD [**]. You are talking about some better mousetrap. The latter does not have any relevance to this thread, which is about dynamic linking in next release of FreeBSD. If you want to talk about FreeBSD 6.x and a better mousetrap, please go right ahead with a new thread here on freebsd-current or over on freebsd-arch. If you want to talk about the future of DragonFlyBSD, I'm sure there is an appropriate list for that--- this one ain't it. Parts of your message certainly seemed to describe what might be best for some other operating system. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Side notes: [*] The actual APIs used by Solaris and Linux are *very* different; and the APIs used by FreeBSD are *somewhat* different from Linux. However, because the *core concepts* are the same--- dynamic loading, in-process modules--- portability issues are not much of a problem. [**] NetBSD doesn't support dynamic loading yet, but has had considerable influence on the FreeBSD implementation. NetBSD developers have indicated to me that they expect to bring in the FreeBSD changes so that there will be basically the same implementation on FreeBSD and NetBSD. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
On Tue, Nov 25, 2003 at 07:36:45PM +0100, Dag-Erling Sm?rgrav wrote: > "Daniel O'Connor" <[EMAIL PROTECTED]> writes: > > What _REAL WORLD_ task does this slow down? > > I suspect 'make world' takes a serious hit. It does not (Warner has quoted numbers a few times now). Kris pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
:Matt, I'm talking about the de facto standard NSS, as found in Solaris :and Linux; and now FreeBSD 5 [*] and soon NetBSD [**]. You are talking :about some better mousetrap. The latter does not have any relevance :to this thread, which is about dynamic linking in next release of :FreeBSD. : :If you want to talk about FreeBSD 6.x and a better mousetrap, please :go right ahead with a new thread here on freebsd-current or over on :freebsd-arch. : :If you want to talk about the future of DragonFlyBSD, I'm sure there :is an appropriate list for that--- this one ain't it. Parts of your :message certainly seemed to describe what might be best for some other :operating system. : :Cheers, :-- :Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal :[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] : : :Side notes: : :[*] The actual APIs used by Solaris and Linux are *very* different; :and the APIs used by FreeBSD are *somewhat* different from Linux. :However, because the *core concepts* are the same--- dynamic loading, :in-process modules--- portability issues are not much of a problem. : :[**] NetBSD doesn't support dynamic loading yet, but has had :considerable influence on the FreeBSD implementation. NetBSD :developers have indicated to me that they expect to bring in :the FreeBSD changes so that there will be basically the same :implementation on FreeBSD and NetBSD. I'm not sure of the relevance of this comment. My original opinion still stands... you guys are using this issue as an excuse to basically do away with static binaries, rather then fixing the real problem which is an inability to dynamically load modules in a static binary. How much do you intend to use NSS for? I mean, what's the point of adopting this cool infrastructure if all you are going to do with it is make a better PAM out of it? You can use it for basic authentication, sure, but the more things you try to use it for without static binary support the fewer things you can compile statically. You are basically doing away with the static linking capability of the system for no good reason that I can see, and coming up with all sorts of extra junk, like /rescue, to work around that fact. You are creating a huge mess *JUST* to be able to port a dynamic load NSS framework and you are throwing away functionality left and right to get it. That's no good in my book. If you *REALLY* want dynamic load NSS then you ought to spend the time to make it work with static binaries rather then just being lazy and getting rid of static binaries. So, yes, I do think you guys are being lazy in that regard. If this is the path you've chosen to go then you have an obligation not to tear out major existing system capabilities, such as the ability to generate static binaries, in the process. If the APIs are totally different then I don't see any difference between your direct NSS implementation and my ability, within an IPC framework, to implement NSS as a backend service. I suppose you can call me work "building a better mousetrap", implying that I am doing work that has already been done, but it is really no different then what you are doing in FreeBSD-5 by changing existing API standards to suit your particular implementation. There is a lot of circular reasoning going on here... it's the same sort of circular reasoning that John uses to justify some of the more esoteric scheduling mechanisms in -current. A because of B because of A, and to hell with anyone who wanted to use C. What I am doing is not reinventing the wheel, I am simply reinventing the API that the backend of libc uses to access resources. There is nothing preventing me from then implementing something like NSS and PAM on the backend of the new API, as a service rather then as a DLL. I fully expect that someone will do that, in fact, possibly even me. But I also expect that straight IPC will solve at least as many problems and in fact solve significantly more problems then the DLL NSS solution solves. So, yes, IPC will be the basis used in DFly. That does not invalidate my comments vis-a-vie the dynamic/static problem with NSS and PAM that FreeBSD-5 has. If you want to do it right then make DLL's work with static binaries. If you want to do it wrong then ignore static binaries. It is that simple. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
On Tue, Nov 25, 2003 at 12:39:11PM -0800, Matthew Dillon wrote: > So, yes, I do think you guys are being lazy in that regard. If this > is the path you've chosen to go then you have an obligation not to > tear out major existing system capabilities, such as the ability to > generate static binaries, in the process. If this is what you think has happened, you're living in some parallel fantasy universe. > There is a lot of circular reasoning going on here... it's the same sort > of circular reasoning that John uses to justify some of the more esoteric > scheduling mechanisms in -current. A because of B because of A, and > to hell with anyone who wanted to use C. Keep the ad homenim attacks to yourself, buster! This was uncalled-for. Kris pgp0.pgp Description: PGP signature
Re: [Me too]: rc scripts run double on boot?
| Of course, make sure you don't have local changes in /etc/rc.d first. Shouldn't these be placed in /usr/local/etc/rc.d -- Mit freundlichen Gruessen, Marco Wertejuk - mwcis.com Consulting & Internet Solutions ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
netgraph/ng_eiface double panic & turnstile/sio lock order reversal in 5.2-BETA
I've been experiencing a repeatable panic using ng_eiface(4) on -CURRENT
of the last few days.
Environment:
FreeBSD twiddle.local 5.2-BETA FreeBSD 5.2-BETA #0: Tue Nov 25 19:28:22
UTC 2003 [EMAIL PROTECTED]:/home/data/work/usr/src/sys/TWIDDLE i386
Description:
Shutting down an ng_eiface node which has a non-zero lladdr causes a panic.
How-To-Repeat:
Configure an ng_eiface(4) node, set its lladdr with ifconfig(8), shut it
down:
# cat >/tmp/ngctl
mkpeer . eiface hook ether
name .:hook vif0
rmhook . hook
# ngctl -f /tmp/ngctl
# ifconfig ngeth0 link '00:bd:03:11:25:01'
# ngctl shutdown vif0:
lock order reversal
1st 0xc0765d8c turnstile chain (turnstile chain) @
/usr/src/sys/kern/subr_turnstile.c:370
2nd 0xc079a500 sio (sio) @ /usr/src/sys/dev/sio/sio.c:3203
Stack backtrace:
backtrace(c070794e,c079a500,c07502c0,c07502c0,c0719757) at backtrace+0x17
witness_lock(c079a500,8,c0719757,c83,3f8) at witness_lock+0x672
_mtx_lock_spin_flags(c079a500,0,c0719757,c83,1) at _mtx_lock_spin_flags+0xda
siocnputc(c0750440,6b,5,ddcb08b4,6b) at siocnputc+0x81
cnputc(6b,c076e780,1,c4a40500,c071d675) at cnputc+0x7a
putchar(6b,ddcb08b4,c053a72d,c076e800,1) at putchar+0x6c
kvprintf(c071d674,c0564b80,ddcb08b4,a,ddcb08d4) at kvprintf+0x8d
printf(c071d674,c,c056ced2,c078ac40,38) at printf+0x57
trap(c0760018,c0760010,c0760010,0,c4a40500) at trap+0xd7
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc056a146, esp = 0xddcb0958, ebp = 0xddcb0978 ---
turnstile_wait(0,c479b9c8,1103bd00,1cc,c479b9c8) at turnstile_wait+0x86
_mtx_lock_sleep(c479b9c8,0,c070c7ca,250,c49efe7c) at _mtx_lock_sleep+0x115
_mtx_lock_flags(c479b9c8,0,c070c7ca,250,c0538e1c) at _mtx_lock_flags+0x97
if_detach(c479b808,c4d64300,ddcb0a58,c4dbfa51,c479b808) at if_detach+0x394
ether_ifdetach(c479b808,c070d32d,820,c4d64300,c4d64300) at
ether_ifdetach+0x30
ng_eiface_rmnode(c4d64300,0,0,c4d64300,c4d64300) at ng_eiface_rmnode+0x61
ng_rmnode(c4d64300,0,0,0,0) at ng_rmnode+0xc7
ng_generic_msg(c4d64300,c48b7780,0,c0768598,c07acfd4) at
ng_generic_msg+0x11f
ng_apply_item(c4d64300,c48b7780,c070d32d,7d6,c48b7780) at
ng_apply_item+0x365
ng_snd_item(c48b7780,0,c47a4360,0,0) at ng_snd_item+0x7b6
ngc_send(c4ab4780,0,c1d12800,c47a4820,0) at ngc_send+0x146
sosend(c4ab4780,c47a4820,ddcb0c4c,c1d12800,0) at sosend+0x4cd
kern_sendit(c4a40500,3,ddcb0cc4,0,0) at kern_sendit+0x17c
sendit(c4a40500,3,ddcb0cc4,0,804f034) at sendit+0x16e
sendto(c4a40500,ddcb0d14,c071d6f6,3ee,6) at sendto+0x5b
syscall(2f,2f,2f,bfbfe9c0,bfbfe9c2) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (133), eip = 0x280c58cf, esp = 0xbfbfe96c, ebp = 0xbfbfebe8 ---
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x1103bd00
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc056a146
stack pointer = 0x10:0xddcb0958
frame pointer = 0x10:0xddcb0978
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 582 (ngctl)
kernel: type 12 trap, code=0
Stopped at turnstile_wait+0x86:movl0(%edx),%eax
db> panic
panic: from debugger
Debugger("panic")
Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc06a9254
stack pointer = 0x10:0xddcb0720
frame pointer = 0x10:0xddcb072c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 582 (ngctl)
Stopped at turnstile_wait+0x86:movl0(%edx),%eax
db> where
turnstile_wait(0,c479b9c8,1103bd00,1cc,c479b9c8) at turnstile_wait+0x86
_mtx_lock_sleep(c479b9c8,0,c070c7ca,250,c49efe7c) at _mtx_lock_sleep+0x115
_mtx_lock_flags(c479b9c8,0,c070c7ca,250,c0538e1c) at _mtx_lock_flags+0x97
if_detach(c479b808,c4d64300,ddcb0a58,c4dbfa51,c479b808) at if_detach+0x394
ether_ifdetach(c479b808,c070d32d,820,c4d64300,c4d64300) at
ether_ifdetach+0x30
ng_eiface_rmnode(c4d64300,0,0,c4d64300,c4d64300) at ng_eiface_rmnode+0x61
ng_rmnode(c4d64300,0,0,0,0) at ng_rmnode+0xc7
ng_generic_msg(c4d64300,c48b7780,0,c0768598,c07acfd4) at
ng_generic_msg+0x11f
ng_apply_item(c4d64300,c48b7780,c070d32d,7d6,c48b7780) at
ng_apply_item+0x365
ng_snd_item(c48b7780,0,c47a4360,0,0) at ng_snd_item+0x7b6
ngc_send(c4ab4780,0,c1d12800,c47a4820,0) at ngc_send+0x146
sosend(c4ab4780,c47a4820,ddcb0c4c,c1d12800,0) at sosend+0x4cd
kern_sendit(c4a40500,3,ddcb0cc4,0,0) at kern_sendit+0x17c
sendit(c4a40500,3,ddcb0cc4,0,804f034) at sendit+0x16e
sendto(c4a40500,ddcb0d14,c071d6f6,3ee,6) at sendto+0x5b
syscall(2f,2f,2f,bfbfe9c0,bfbfe9c2) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (133, FreeBSD ELF32, sendto), eip = 0x280c58cf, esp =
0xbfbfe96c, ebp = 0xbfbfebe8 ---
db> panic
panic: from debugger
Uptime: 2m3s
panic: mi_s
Re: [Me too]: rc scripts run double on boot?
On Tue, 25 Nov 2003, Marco Wertejuk wrote: > | Of course, make sure you don't have local changes in /etc/rc.d first. > > Shouldn't these be placed in /usr/local/etc/rc.d Sure. I was just being overly careful since I just suggested someone rm -rf a directory. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
:> is the path you've chosen to go then you have an obligation not to :> tear out major existing system capabilities, such as the ability to :> generate static binaries, in the process. : :If this is what you think has happened, you're living in some parallel :fantasy universe. I am simply repeating the reasoning being used for going to a dynamic root. Forgive me if I misread it, but I believe the argument was that FreeBSD-5 was migrating to NSS and NSS's DLL mechanism does not work in a static world, therefore dynamic becomes the default. If I am wrong and NSS's DLL mechanism can be used in a static world, please correct me! So exactly how far do you intend to go with NSS? Because it seems to me that FreeBSD-5's goal is to start to depend on the DLL capabilities. If the goal is an intention to depend on DLL then you damn well need to make it work with static ELF binaries. It's that simple. :> There is a lot of circular reasoning going on here... it's the same sort :> of circular reasoning that John uses to justify some of the more esoteric :> scheduling mechanisms in -current. A because of B because of A, and :> to hell with anyone who wanted to use C. : :Keep the ad homenim attacks to yourself, buster! This was uncalled-for. : :Kris Well, the scheduler arguments are more involved but I am not incorrect here. E.G. the priority borrowing exists to work around problems with the mutex implementation. Preemption by non-interrupts threads also exists to work around problems with the mutex implementation. Preemptive cpu migration could be turned off fairly easily and doesn't really count. The priority borrowing is a mess, though. You may think its the best thing since sliced bread but I think it unnecessarily complicates both the scheduler core and the programming model. -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pcm(4) related panic
Artur Poplawski <[EMAIL PROTECTED]> wrote: > Hello, > > On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic > like this: > > (watch out for folded lines; the stack backtrace below is rewritten by > hand from ddb) > > lock order reversal > 1st 0xc22a45ac vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 > 2nd 0xc06c0420 swap_pager swhash (swap_pager swhash) @ \ > /usr/src/sys/vm/swap_pager.c:1838 > 3rd 0xc0c358c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 > Stack backtrace: > backtrace > witness_lock > _mtx_lock_flags > obj_allock > slab_zalloc > uma_zone_slab > uma_zalloc_internal > uma_zalloc_arg > swp_pager_meta_build > swap_pager_putpages > default_pager_putpages > vm_pageout_flush > vm_pageout_clean > vm_pageout_scan > vm_pageout > fork_exit > fork_trampoline > > Sleeping on "swread" with the following non-sleepable locks held: > exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \ > /usr/src/sys/dev/sound/pcm/dsp.c:146 > panic: sleeping thread (pid 583) owns a non-sleepable lock > syncing disks, buffers remaining... 1410 1410 panic: mi_switch: \ > switch in a critical section > Uptime: 1m45s > panic: msleep > Uptime: 1m45s > panic: msleep > Uptime: 1m45s > panic: msleep > Uptime: 1m45s > panic: msleep > [... repeated few more times] > Fatal double fault: > eip = 0xc05e3916 > esp = 0xc8db8ff4 > ebp = 0xc8db9004 > panic: double fault > Uptime: 1m45s > panic: msleep > Uptime: 1m45s > panic: msleep > Uptime: 1m45s > panic: msleep > Uptime: 1m45s > [...] > And the machine suddenly reboots, so there is no coredump. > > eip address points close to: > c05e3910 T sc_vtb_putc > > To reproduce this panic just start some audio player app (like xmms), > and launch countless memory-eating applications (like mozilla ;>). > The machine starts swapping, and it panics. > > % uname -a > FreeBSD kaszanka.domek 5.2-BETA FreeBSD 5.2-BETA #0: Sun Nov 23 01:23:10\ > CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KASZANKA i386 > > dmesg fragments: > CPU: AMD Athlon(tm) XP 2000+ (1666.73-MHz 686-class CPU) > pcm0: port 0xec00-0xec3f irq 10 at device 8.0 on pci0 > pcm0: > rl0: port 0xe800-0xe8ff mem \ > 0xdf00-0xdfff ir > q 10 at device 10.0 on pci0 > miibus0: on rl0 > rlphy0: on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > rl1: port 0xe400-0xe4ff mem \ > 0xde00-0xdeff ir > q 10 at device 11.0 on pci0 > rlphy1: on miibus1 > rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto In the meantime I've managed to get a coredump, by directly calling doadump() from ddb. Results: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KASZANKA# gdb -k kernel.debug /var/crash/vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-undermydesk-freebsd"... panic: sleeping thread (pid 568) owns a non-sleepable lock panic messages: --- panic: sleeping thread (pid 568) owns a non-sleepable lock syncing disks, buffers remaining... panic: msleep Dumping 128 MB 16 32 48 64 80 96 112 --- Reading symbols from /usr/obj/usr/src/sys/KASZANKA/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/KASZANKA/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug Reading symbols from /usr/obj/usr/src/sys/KASZANKA/modules/usr/src/sys/modules/linux/linux.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/KASZANKA/modules/usr/src/sys/modules/linux/linux.ko.debug Reading symbols from /boot/kernel/netgraph.ko...done. Loaded symbols for /boot/kernel/netgraph.ko Reading symbols from /boot/kernel/ng_ether.ko...done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/kernel/ng_pppoe.ko...done. Loaded symbols for /boot/kernel/ng_pppoe.ko Reading symbols from /boot/kernel/ng_socket.ko...done. Loaded symbols for /boot/kernel/ng_socket.ko Reading symbols from /boot/kernel/mga.ko...done. Loaded symbols for /boot/kernel/mga.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc04292cd in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0xc8dba7bc "à×hÀ") at /usr/src/sys/ddb/db_command.c:548 #2 0xc042906a in db_command (last_cmdp=0xc068ce80, cmd_table=0x0, aux_cmd_tablep=0xc06480c0, aux_cmd_tablep_end=0xc
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
On Tue, Nov 25, 2003 at 04:46:24PM +0200, Enache Adrian wrote: > On Mon, Nov 24, 2003 a.d., Jacques A. Vidrine wrote: > > The application is broken. You must only check errno if you get an > > error indication from the library call. > > Sorry, but I don't see your point. I know when to check for errno. > If you took the little illustrating program for a real life example of > the use of errno, that's unfortunate :-) > > The problem is that the emulated/wrapped close from libc_r does not > behave like the real one. libc_r is leaking some of its guts > (the tricks it's doing with O_NONBLOCK, etc) in the interface. > This is technically a bug. The fix was trivial. Hello Enache, My point was that this is not technically a bug. According to IEEE Std 1003.1-2001 aka the Single Unix Specification Version 3 (``SUSv3'') aka POSIX, an application must not examine and interpret `errno' unless the library gives an error indication. There are some functions--- strtol and family, sysconf, others--- that have unusual, errno-preserving behavior. These are described individually in the appropriate section of the standard. For these and only these, you can set errno to 0 and check it immediately after the function call to see whether an error has occurred. I believe that includes all functions described in ISO/IEC 9899:1999 (``C99''), as well as some described only in SUSv3. `close' is not a part of C99, nor is it attributed the `unusual', errno-preserving behavior in SUSv3. (By the way, this exact topic was discuss at some length by the the Austin Common Standards Revision Group this past summer.) Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PII SMP system hangs during boot with ACPI enabled
On 24-Nov-2003 Nate Lawson wrote: > > Please also send the output of acpidump -t -d > jdp-P2.asl I booted the 5.1R live CD in an attempt to get this output. I discovered that the machine hangs the same way with 5.1R as it does with -current. (When I originally installed 5.1R, the machine had an older, non-ACPI BIOS.) I've attached the verbose boot messages from 5.1R, in case that's worth anything. Such a shame -- it gets within a hair's breadth of running init, but it just can't quite make it all the way there. John SMAP type=01 base= len=0009fc00 SMAP type=02 base=0009fc00 len=0400 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=0fee SMAP type=03 base=0ffe len=00018000 SMAP type=04 base=0fff8000 len=8000 SMAP type=02 base=fec0 len=1000 SMAP type=02 base=fee0 len=1000 SMAP type=02 base=fffc len=0004 Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-RELEASE #0: Mon Jun 9 19:20:51 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc0b0c000. Preloaded mfs_root "/boot/mfsroot" at 0xc0b0c250. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0b0c294. Calibrating clock(s) ... i8254 clock: 1193040 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz Calibrating TSC clock ... TSC clock: 400910451 Hz Timecounter "TSC" frequency 400910451 Hz CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183fbff real memory = 268304384 (255 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00b33000 - 0x0fb39fff, 251686912 bytes (61447 pages) avail memory = 248926208 (237 MB) bios32: Found BIOS32 Service Directory header at 0xc00fdb40 bios32: Entry = 0xfdb50 (c00fdb50) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdb71 pnpbios: Found PnP BIOS data at 0xc00f72c0 pnpbios: Entry = f:6964 Rev = 1.0 Other BIOS signatures found: wlan: <802.11 Link Layer> null: random: mem: Pentium Pro MTRR support enabled md0: Preloaded image 4423680 bytes at 0xc06877a4 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.SBRG.PS2M._STA] (N ode 0xc12a11a0), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\_SB_.PCI0.SBRG.PS2M._STA] (N ode 0xc12a11a0), AE_AML_REGION_LIMIT pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: power button is handled as a fixed feature programming model. ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 3 Timecounter "ACPI-safe" frequency 3579545 Hz AcpiOsDerivePciId: bus 0 dev 0 func 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 ACPI-1287: *** Error: Method execution failed [\_SB_.PCI0.SBRG.PS2M._STA] (N ode 0xc12a11a0), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\_SB_.PCI0.SBRG.PS2M._STA] (N ode 0xc12a11a0), AE_AML_REGION_LIMIT acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 initial configuration \_SB_.LNKA irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] 0.1.0 \_SB_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 12 14 15] 0.1.1 \_SB_.LNKD irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] 0.7.3 \_SB_.LNKA irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] 0.19.0 \_SB_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 12 14 15] 0.19.1 \_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 0.19.2 \_SB_.LNKD irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] 0.19.3 \_SB_.LNKB irq 9: [ 3 4 5 6 7 9 10 11 12 14 15] 0.20.0 \_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 0.20.1 \_SB_.LNKD irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] 0.20.2 \_SB_.LNKA irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] 0.20.3 \_SB_.LNKA irq 10: [ 3 4 5 6 7 9 10 11 12 14 15] 0.18.0 \_SB_.LNKA ir
Re: 40% slowdown with dynamic /bin/sh
On Tue, Nov 25, 2003 at 12:39:11PM -0800, Matthew Dillon wrote: > My original opinion > still stands... you guys are using this issue as an excuse to basically > do away with static binaries, rather then fixing the real problem which > is an inability to dynamically load modules in a static binary. No, it is one of the issues that have been pushing FreeBSD (and most other modern UNIX systems, it seems) towards more dynamically linked components. The other issues have also been discussed on this list recently and in the pass. I'm not sure why this one draws such interest. (I participate in this thread only because I feel like I know a thing or two about the NSS details.) Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
On Tue, Nov 25, 2003 at 01:15:58PM -0800, Matthew Dillon wrote: > > :> is the path you've chosen to go then you have an obligation not to > :> tear out major existing system capabilities, such as the ability to > :> generate static binaries, in the process. > : > :If this is what you think has happened, you're living in some parallel > :fantasy universe. > > I am simply repeating the reasoning being used for going to a dynamic > root. Forgive me if I misread it, but I believe the argument was that > FreeBSD-5 was migrating to NSS and NSS's DLL mechanism does not work > in a static world, therefore dynamic becomes the default. If I am > wrong and NSS's DLL mechanism can be used in a static world, please > correct me! No, what you said was "not to tear out..the ability to generate static binaries". That's completely different, and is absolutely not what has happened, or what is planned. Static binaries continue to be supported, available, and work with the system NSS and PAM modules as before. > :> There is a lot of circular reasoning going on here... it's the same sort > :> of circular reasoning that John uses to justify some of the more esoteric > :> scheduling mechanisms in -current. A because of B because of A, and > :> to hell with anyone who wanted to use C. > : > :Keep the ad homenim attacks to yourself, buster! This was uncalled-for. > : > :Kris > > Well, the scheduler arguments are more involved but I am not incorrect > here. We're not talking about schedulers. What is at issue is that you decided, for no reason appropriate to the topic of discussion, to mention that you think an unrelated FreeBSD developer has difficulties with logical reasoning. What the hell, Matt? By what standards of behaviour is this acceptable? We have rules of conduct on the FreeBSD mailing lists, and people have been removed in the past because they were unable to hold themselves to them. Don't think that you're exempt just because you're Matt Dillon. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL Personal attacks and profanity (in the context of an argument) are not allowed, and that includes users and developers alike. Gross breaches of netiquette, like excerpting or reposting private mail when permission to do so was not and would not be forthcoming, are frowned upon but not specifically enforced. However, there are also very few cases where such content would fit within the charter of a list and it would therefore probably rate a warning (or ban) on that basis alone. Kris pgp0.pgp Description: PGP signature
Re: pcm(4) related panic
On 25 Nov, Artur Poplawski wrote: > Artur Poplawski <[EMAIL PROTECTED]> wrote: > >> Hello, >> >> On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic >> like this: >> Sleeping on "swread" with the following non-sleepable locks held: >> exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \ >> /usr/src/sys/dev/sound/pcm/dsp.c:146 This enables the panic. >> panic: sleeping thread (pid 583) owns a non-sleepable lock Then the panic happens when another thread tries to grab the mutex. The problem is that the pcm code attempts to hold a mutex across a call to uiomove(), which can sleep if the userland buffer that it is trying to access is paged out. Either the buffer has to be pre-wired before calling getchns(), or the mutex has to be dropped around the call to uiomove(). The amount of memory to be wired should be limited to 'sz' as calculated by chn_read() and chn_write(), which complicates the logic. Dropping the mutex probably has other issues. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pcm(4) related panic
On 25 Nov, Don Lewis wrote: > On 25 Nov, Artur Poplawski wrote: >> Artur Poplawski <[EMAIL PROTECTED]> wrote: >> >>> Hello, >>> >>> On a 5.1-RELEASE and 5.2-BETA machines I have been able to cause a panic >>> like this: > >>> Sleeping on "swread" with the following non-sleepable locks held: >>> exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc1c3d740) locked @ \ >>> /usr/src/sys/dev/sound/pcm/dsp.c:146 > > This enables the panic. > >>> panic: sleeping thread (pid 583) owns a non-sleepable lock > > Then the panic happens when another thread tries to grab the mutex. > > > The problem is that the pcm code attempts to hold a mutex across a call > to uiomove(), which can sleep if the userland buffer that it is trying > to access is paged out. Either the buffer has to be pre-wired before > calling getchns(), or the mutex has to be dropped around the call to > uiomove(). The amount of memory to be wired should be limited to > 'sz' as calculated by chn_read() and chn_write(), which complicates the > logic. Dropping the mutex probably has other issues. Following up to myself ... It might be safe to drop the mutex for the uiomove() call if the code set flags to enforce a limit of one reader and one writer at a time to keep the code from being re-entered. The buffer pointer manipulations in sndbuf_dispose() and sndbuf_acquire() would probably still have to be protected by the mutex. If this can be made to work, it would probably be preferable to wiring the buffer. It would have a lot less CPU overhead, and would work better with large buffers, which could still be allowed to page normally. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 40% slowdown with dynamic /bin/sh
:No, what you said was "not to tear out..the ability to generate static :binaries". That's completely different, and is absolutely not what :has happened, or what is planned. Static binaries continue to be :supported, available, and work with the system NSS and PAM modules as :before. I think you are missing the point I made in that response, because it isn't that cut and dry. Obviously isn't that cut and dry. Why is a dynamic root the default again? Because statically linking NSS and PAM is not the direction FreeBSD-5 is going. So if you are going to start depending on dynamic loading, and I seem to recall a number of conversations where that is, in fact, the intention, then you are marginalizing your static binary support. The more you use NSS and operate on the assumption that DLL will be leveraged, the more you marginalize your static binary support. FreeBSD-5 has *ALREADY* made major concessions, such as going to the dynamic root, precisely because it has *ALREADY* marginalized static binary support. That is what I'm hearing. What I am saying is that for something this fundamental to the infrastructure, it is not appropriate to marginalize static binary support. That is all I am saying here. Sure, I think an IPC mechanism is a better API, but that has nothing at all to do with this DLL / static/dyanmic binary issue in FreeBSD-5. They are two separate issues. Right now, in FreeBSD-5, the issue is the marginalized static binary support. :We're not talking about schedulers. What is at issue is that you :decided, for no reason appropriate to the topic of discussion, to :mention that you think an unrelated FreeBSD developer has difficulties :with logical reasoning. : :What the hell, Matt? By what standards of behaviour is this :acceptable? : :We have rules of conduct on the FreeBSD mailing lists, and people have :been removed in the past because they were unable to hold themselves :to them. Don't think that you're exempt just because you're Matt :Dillon. Yes, and apparently you are breaking them as much as you believe I am, Kris. You are also seriously misinterpreted my postings. I am obviously not advocating that FreeBSD-5 rip everything out and move to an IPC model. It takes time and consideration to be able to do something like that. What I am advocating is that FreeBSD-5 not marginalize and restrict (make less flexible) basic infrastructure in order to get other infrastructure working. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Intel SE7500WV2 not working with ACPI
On Tue, Nov 25, 2003 at 12:12:16PM -0800, Nate Lawson wrote: > > acpi0: on motherboard > > ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_._REG] > > (Node 0xc29b4660), AE_NOT_EXIST > > acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST > > device_probe_and_attach: acpi0 attach returned 6 > > This is the source of the problems. When acpi0 fails to attach, > everything else is done through the legacy PCI code. The question is, why > is it failing? The above-mentioned EC method could indicate the problem > is in walking the namespace but we'll have to look at the ASL to be sure. > > Please send a url to the output of: > acpidump -t -d > brooks-Intel.asl http://people.freebsd.org/~brooks/debug/brooks-Intel.asl > Also, build with options ACPI_DEBUG and set these in your loader.conf: > > debug.acpi.layer="ACPI_ALL_COMPONENTS" > debug.acpi.level="ACPI_LV_OPREGION" There's a new dmesg with this done at: http://people.freebsd.org/~brooks/debug/dmesg-brooks-Intel Thanks, Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
At 11:50 AM -0800 2003/11/25, Matthew Dillon wrote: ... Or you can build an IPC mechanism that implements the PAM functionality and then have programs which would otherwise use PAM instead use the IPC mechanism. Which is the whole point of having the IPC mechanism in the first place. That all sounds wonderful! So, when are you going to deliver this fully functioning and debugged code for inclusion in FreeBSD-5.2? -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How many bikesheds can _you_ build on a pin head ?
On Tue, 25 Nov 2003, Poul-Henning Kamp wrote: > I have for myself recently taken a break from all active FreeBSD > development because I find the environment about as pleasant as a > kindergarten right before lunch. Does this mean GEOM has been orphaned? Who now has the mantle for it then? -a ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to fix this in 5.1-REL??
Kevin Oberman wrote: ...Because changes are applied that will allow smooth upgrades when the kernel is built after the new system is built, but before it is installed, "make world" is increasingly unlikely to work... The recent statfs changes demonstrated why the 'makeworld' > 'makekernel' sequence sometimes fails :-( But I'm still very fuzzy on why the 'makekernel' > 'makeworld' sequence is not recommended in FreeBSD the way it is, for example, in OpenBSD. What does 'buildworld' give us that the new kernel might need? Just a simple example would help me more than anything. Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to fix this in 5.1-REL??
On Tue, Nov 25, 2003 at 03:35:54PM -0800, walt wrote: > Kevin Oberman wrote: > > >...Because changes are applied that will allow smooth upgrades > >when the kernel is built after the new system is built, but before it is > >installed, "make world" is increasingly unlikely to work... > > The recent statfs changes demonstrated why the 'makeworld' > 'makekernel' > sequence sometimes fails :-( > > But I'm still very fuzzy on why the 'makekernel' > 'makeworld' sequence > is not recommended in FreeBSD the way it is, for example, in OpenBSD. > > What does 'buildworld' give us that the new kernel might need? Just a > simple example would help me more than anything. The correct toolchain including the compiler and config(8). -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
At 11:27 PM +0100 11/25/03, Brad Knowles wrote: At 11:50 AM -0800 2003/11/25, Matthew Dillon wrote: ... Or you can build an IPC mechanism that implements the PAM functionality and then have programs which would otherwise use PAM instead use the IPC mechanism. Which is the whole point of having the IPC mechanism in the first place. That all sounds wonderful! So, when are you going to deliver this fully functioning and debugged code for inclusion in FreeBSD-5.2? My guess is that he will deliver it to DragonFly BSD, and it will then be up to someone with FreeBSD commit privs to look at steal^h^h^h^h^h^h adapting it for our purposes... Note that we are already in the code-freeze for 5.2-release, so I will estimate the probability that all this happens in time for this release is zero. Absolute zero. What might happen for 5.3-release is a different story, of course. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: requesting vinum help
On Tuesday, 25 November 2003 at 10:48:44 -0600, Eric Anderson wrote: > >> Could a vinum guru please contact me via email? >> >> I've lost 2 vinum volumes as a result of the latest fiasco and naturally >> am eager to figure out what's going on and recover the data. > > This isn't necessarily directed at you - I'm just using this email as a > footstep to send this general comment - > > I am kind of under the assumption that -current is more of a test bed, > and anything can happen at any time, which is why it's bad to run > -current on a machine you care deeply about (at least its data). Correct. More to the point, though, it requires you to rely more on yourself. At the very least, this means RTFM, which in this case includes a number of things to submit if you have problems. It's at the end of vinum(4) or at http://www.vinumvm.org/vinum/how-to-debug.html. Greg -- See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: 40% slowdown with dynamic /bin/sh
At 2:48 PM -0800 2003/11/25, Matthew Dillon wrote: What I am advocating is that FreeBSD-5 not marginalize and restrict (make less flexible) basic infrastructure in order to get other infrastructure working. If you've got working, debugged code that works in the manner you are espousing, and still achieves the same goal of making NSS and PAM work everywhere, I'm sure we'd all love to see it. In the absence of any code contribution to the contrary, I see no alternative than the method that has been selected. Sure, it's not great. Sure, it's slower (more or less, depending on which benchmarks you believe). But it is the best implementation that was available, and this is -CURRENT, where things are expected to periodically be in a state of flux while major changes are underway. -- Brad Knowles, <[EMAIL PROTECTED]> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: requesting vinum help
>> Could a vinum guru please contact me via email? >> >> I've lost 2 vinum volumes as a result of the latest fiasco and naturally >> am eager to figure out what's going on and recover the data. EA> This isn't necessarily directed at you - I'm just using this email as a EA> footstep to send this general comment - EA> I am kind of under the assumption that -current is more of a test bed, EA> and anything can happen at any time, which is why it's bad to run EA> -current on a machine you care deeply about (at least its data). I EA> think I've seen at least 5 mails in the past few weeks about people EA> getting jammed into a corner with (what sounds like) production type EA> boxes, or at least important boxes (or they wouldn't need a vinum?) There is the point! If no-one would ever take the risk of running -current on a bigger, more important box no-one would have the capabilities to test vinum and other large scale stuff in realistic environments. No my suggestion is to help those (brave) guys rather than screaming: "Fool, don't you know it's -current!?" The not so good point about the original request is that he is looking for private assistance, while the problem and - even more - the solution of it might be very interesting to all of us (more than much of the other ongoing threads, for sure). EA> .. It seems odd to me that they wouldn't give it a whirl first EA> before attempting to use it on a box they seem so protective of. EA> Anyway, I'm just stating that running -current is for testing and EA> developing, not really for production - at least I'm fairly certain. There's the magic keyword again: testing! Who should do it if not guys like him? If vinum had crossed my way before, I'd try to help - sorry. -- Best regards, Maxmailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: memory allocation issue loading a kernel module
On Tuesday 25 November 2003 18:43, Maxime Henrion wrote: > If I remember correctly, Alan Cox intended to write a binary buddy > allocator to handle the physical address space (or do coalescing another > way, I'm not sure...) so that this particular problem is solved. Another way to solve it is the bktr approach which has a KLD that just reserves some memory early on (ie you load it in the loader). This means that when you test your module the memory chunk stays around no matter how often you reload. You could get more RAM too 8-) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: memory allocation issue loading a kernel module
Perfect!! This is exactly the thing I need. I will investigate. Memory is an option, but this project is pretty much done. Knowing how to do the bktr approach is something worth the excercise. More RAM won't teach me anything new ;-) Sean On Tue, 2003-11-25 at 16:09, Daniel O'Connor wrote: > On Tuesday 25 November 2003 18:43, Maxime Henrion wrote: > > If I remember correctly, Alan Cox intended to write a binary buddy > > allocator to handle the physical address space (or do coalescing another > > way, I'm not sure...) so that this particular problem is solved. > > Another way to solve it is the bktr approach which has a KLD that just > reserves some memory early on (ie you load it in the loader). This means that > when you test your module the memory chunk stays around no matter how often > you reload. > > You could get more RAM too 8-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Sound stop'd working after upgrade ...
I upgraded my machine shortly after those changes with statfs ... upgrade went well, but sound stop'd working ... the device is being detected: pcm0: port 0xe400-0xe43f,0xe000-0xe0ff mem 0xe0102000-0xe01020ff,0xe0101000-0xe01011ff irq 17 at device 31.5 on pci0 pcm0: and, from what I can tell, the proper devices are being built in /dev, but try and play music using xmms, and I get nothing ... Not sure what to debug, or where ... help? :( Thanks ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
Tony Finch wrote: "Matthew D. Fuller" <[EMAIL PROTECTED]> wrote: Not just the startup scripts, but ANY script. I dare say there's a long, long list of scripts that use ~-expansion, to say nothing of the homegrown ones we all have working quietly and forgotten for years. It's required for POSIX compliance. Tony. Ouch! Very good point, Tony. Does POSIX require that such expansion work for usernames that may not be in the current passwd file? That could dictate a lot. Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.2-BETA root mount failure
Gents, (Firsthand I sorry if this E-Mail is sent twice to the list, got client rejected from mx1.) I'm having difficulties trying out the 5.2-BETA, preparing for the release. I would greatly appreciate it if anyone has some time at hand to help (re)solve a problem that occures with my 5.2-BETA kernel (26 nov 2003). The situation is the following: I have tried to upgrade a system (http://www.msi.com.tw/program/products/server/svr/pro_svr_detail.php?UID=376) from 5.1-RELEASE to 5.2-BETA, according to the src/UPDATING text (I did add the COMPAT_FREEBSD4 option to my kernel config). buildworld went fine and so did buildkernel. After doing a installkernel and booting with the newly installed 5.2-BETA kernel (single-user), I get the following message before I get thrown in the "mount root> " prompt: mounting root from ufs:/dev/ar0s1a setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 mount root> Did I miss a step or have I hit something in -current? Below is my dmesg output (working 5.1) : Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-RELEASE #0: Tue Nov 25 09:49:42 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/CURRENT Preloaded elf kernel "/boot/kernel/kernel" at 0xc0381000. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2391148112 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2391.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff real memory = 1073676288 (1023 MB) avail memory = 1039364096 (991 MB) pnpbios: Bad PnP BIOS data checksum Pentium Pro MTRR support enabled acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00fdec0 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 30.0 on pci0 pci2: on pcib2 em0: port 0xb000-0xb03f mem 0xe200-0xe201 irq 12 at device 5.0 on pci2 em0: Speed:10 Mbps Duplex:Half fxp0: port 0xb400-0xb43f mem 0xe202-0xe203,0xe2044000-0xe2044fff irq 10 at device 6.0 on pci2 fxp0: Ethernet address 00:0c:76:15:19:c5 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci2: at device 7.0 (no driver attached) atapci0: port 0xcc00-0xcc0f,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xbc00-0xbc07 mem 0xe204-0xe2043fff irq 11 at device 10.0 on pci2 ata2: at 0xbc00 on atapci0 ata3: at 0xc400 on atapci0 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci1 ata1: at 0x170 irq 15 on atapci1 pci0: at device 31.3 (no driver attached) sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 npx0: on motherboard npx0: INT 16 interface orm0: at iomem 0xc8000-0xd07ff,0xc-0xc7fff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3b0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec IP Filter: v3.4.31 initialized. Default = pass all, Logging = enabled acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% ad4: 117800MB [239340/16/63] at ata2-master UDMA100 ad6: 117800MB [239340/16/63] at ata3-master UDMA100 ar0: 117301MB [14953/255/63] status: READY subdisks: disk0 READY on ad4 at ata2-master disk1 READY on ad6 at ata3-master Opened disk ad4 -> 1 Opened disk ad6 -> 1 Opened disk ad6 -> 1 Mounting root from ufs:/dev/ar0s1a %atacontrol list ATA channel 0: Master: no device present Slave: no device present ATA channel 1: Master: ATA/ATAPI rev 0 Slave: no device present ATA channel 2: Master: ad4 ATA/ATAPI rev 6 Slave: no device present ATA channel 3: Master: ad6 ATA/ATAPI rev 6 Slave: no device present %atacontrol status 0 ar0: ATA RAID1 subdisks: ad4 ad6 status: READY %atacontrol mode 2 Master = UDMA100 Slave = ??? %atacontrol mode 3 Master = UDMA100 Slave = ??? -- Jeroen Hogeveen, <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
lock order reversal
i was just looking through my daily reports from my new 5.2 beta box and found this in dmesg. lock order reversal 1st 0xc08f7ce0 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201 2nd 0xc1031100 system map (system map) @ /usr/src/sys/vm/vm_map.c:2210 Stack backtrace: lock order reversal 1st 0xc214c948 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 2nd 0xc08f7160 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pager.c:1838 3rd 0xc10358c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 Stack backtrace: I went back through /var/log/messages and found more, looks like it started around nov12 This box isn't really being used for much. It was a test box for mysql 4.0.15 and is a nfs server (no rpc.lockd running) Nov 12 01:36:40 nfs kernel: lock order reversal Nov 12 01:36:40 nfs kernel: 1st 0xc211f818 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 Nov 12 01:36:40 nfs kernel: 2nd 0xc08ed180 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pager.c:1838 Nov 12 01:36:40 nfs kernel: 3rd 0xc103440c vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 Nov 12 01:36:40 nfs kernel: Stack backtrace: Nov 23 21:48:19 nfs kernel: lock order reversal Nov 23 21:48:19 nfs kernel: 1st 0xc08f7ce0 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201 Nov 23 21:48:19 nfs kernel: 2nd 0xc1031100 system map (system map) @ /usr/src/sys/vm/vm_map.c:2210 Nov 23 21:48:19 nfs kernel: Stack backtrace: Nov 23 21:51:19 nfs kernel: lock order reversal Nov 23 21:51:19 nfs kernel: 1st 0xc2154294 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 Nov 23 21:51:19 nfs kernel: 2nd 0xc08f7160 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pager.c:1838 Nov 23 21:51:19 nfs kernel: 3rd 0xc10358c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 Nov 23 21:51:19 nfs kernel: Stack backtrace: Nov 24 03:03:52 nfs kernel: lock order reversal Nov 24 03:03:52 nfs kernel: 1st 0xc08f7ce0 UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201 Nov 24 03:03:52 nfs kernel: 2nd 0xc1031100 system map (system map) @ /usr/src/sys/vm/vm_map.c:2210 Nov 24 03:03:52 nfs kernel: Stack backtrace: here is my whole dmesg. Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.2-BETA #0: Sun Nov 23 19:35:06 CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel "/boot/kernel/kernel" at 0xc09e. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium/P55C (232.67-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bf real memory = 134217728 (128 MB) avail memory = 120754176 (115 MB) Intel Pentium detected, installing workaround for F00F bug ACPI-0159: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TABLES ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI_TABLES ACPI: table load failed: AE_NO_ACPI_TABLES npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 pcib0: at pcibus 0 on motherboard pci0: on pcib0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pci0: at device 8.0 (no driver attached) bt0: port 0xfff4-0xfff7 mem 0xfff7f000-0xfff7 irq 10 at device 17.0 on pci0 bt0: BT-958 FW Rev. 5.07B Ultra Wide SCSI Host Adapter, SCSI ID 7, 192 CCBs de0: port 0xf880-0xf8ff mem 0xfff7ec00-0xfff7ec7f irq 9 at device 19.0 on pci0 de0: SMC 9332BDT 21140A [10-100Mb/s] pass 2.2 de0: address 00:e0:29:00:b1:c2 orm0: at iomem 0xea000-0xebfff,0xe9000-0xe9fff,0xc8000-0xcbfff,0xc-0xc7fff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) psmcpnp0: irq resource info is missing; assuming irq 12 unknown: can't assign resources (port) ppc1: parallel port not found. unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 232671577 Hz quality 800 Timecounters tick every 10.000 msec Waiting 15 seconds for SCSI devices to settle de0: enabling Full Duplex 100baseTX port GEOM: create disk da0 dp=0xc2096c50 da0 at bt0 bus 0 target 4 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 8683MB (17783240 512 byte sectors: 255H 63
IPFW2 verrevpath issue (IPv4 TCP, fresh kernel)
Hi, I seem to have difficulties with verrevpath in IPFW2 (current kernel, cvsupped a few hours ago) which APPEARS to not match - or am I too whatever to configure ipfw2 properly? Excerpt from "ipfw show": | 0010038 3216 allow ip from any to any via lo0 | 00200 0 0 deny ip from any to 127.0.0.0/8 | 00300 0 0 deny ip from 127.0.0.0/8 to any > 0040039 12941 deny log ip from any to any not verrevpath in | 00500 0 0 deny ip from 192.168.0.0/24 to any in via tun0 | ... Now, when I try to connect from my machine to a remote one with "ssh [EMAIL PROTECTED]" I'm getting loads of | kernel: ipfw: 400 Deny TCP 1.2.3.4:22 217.225.230.222:49228 in via tun0 | kernel: ipfw: 400 Deny TCP 1.2.3.4:22 217.225.230.222:49228 in via tun0 in syslog and the counter of the 00400 rule increases, and I don't get a connection. Leaving out the 00400 rule makes my outbound TCP connections work. (Apparently the 00400 rule swallows the SYN|ACK packets.) 217.225.230.222 is my IP and 1.2.3.4 is the remote IP. tun0 is a PPPoE interface, with ppp(8). I have a default route via 217.5.*.* gateway on tun0 (both the default route and the host route for this 217.5.*.* gateway use device tun0). "route get 1.2.3.4" prints that 1.2.3.4 is routed via some 217.5.*.* host which is on tun0, so this looks fine. I'd expect that the "in via tun0" matched the outbound route as returned by route get. To add to the confusion, NTP (that uses UDP) is fine, the machine will synchronize to an outside server (my ISP's DCF receiver) via the same gateway just fine. Is my expectation wrong or is there a pertinent IPFW2 bug in a current 5.2-BETA kernel? -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Modem(PCMCIA) works on 4.8, hangs machine on 5.2-BETA
I tried(!) to use the following modem on my 5.2-BETA (actually -CURRENT from a week or so ago), and the machine HUNG on the OPEN. usb0: USB revision 1.0 usb1: USB revision 1.0 fwohci0: OHCI version 1.0 (ROM=1) sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: at port 0x2e8-0x2ef irq 3 on isa0 sio1: type 16550A sio2 at port 0x2f8-0x2ff irq 11 flags 0x4 slot 0 on pccard0 sio2: type 16550A sio2: unable to activate interrupt in fast mode - using normal mode The SIO2 is my Toshiba 3CXM056-BNW modem, and is what I'm sending this from on 4.8. What debug/help do y'all need to fix it? LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)
Matthew Dillon <[EMAIL PROTECTED]> writes: > How much do you intend to use NSS for? I mean, what's the point of > adopting this cool infrastructure if all you are going to do with it > is make a better PAM out of it? The important thing is that NSS allows to plug modules such as LDAP or PostgreSQL for user base management. PAM is only halfway there and doesn't give libc et al. a notion of a user or group context (in spite of its "account" context), NSS does. One might discuss if PAM is really needed with NSS in place, but it's hard to think of a system without NSS and removing PAM now doesn't look right. Of course, you can stuff the whole NSS client side (thinking "IPC") into a statically linked executable. To stall this discussion: I don't mind if NSS is dynamically or statically linked. I won't let this drift into any other dynamic <-> static discussion. > reason that I can see, and coming up with all sorts of extra junk, > like /rescue, to work around that fact. As a user, I like /rescue better than the step-child that /stand/* used to be. It's part of the world, which /stand wasn't. One word of warning: there used to be SuSE Linux versions that wouldn't let you log in single-user mode when the system was using NIS in multi-user because there was nothing to communicate with through AF_UNIX sockets yet this was expected to be able to log in. There are potholes and pitfalls that I consider major considered with a dynamic /bin /sbin setup. Watch out. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW2 verrevpath issue (IPv4 TCP, fresh kernel)
> Is my expectation wrong or is there a pertinent IPFW2 bug in a current > 5.2-BETA kernel? You're alone in this, though cjc hasn't been able to reproduce this. Are you on a multi-homed system? -sc -- Sean Chittenden ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.2-BETA root mount failure
Gents, I'm having difficulties trying out the 5.2-BETA, preparing for the release. I would greatly appreciate it if anyone has some time at hand to help (re)solve a problem that occures with my 5.2-BETA kernel (26 nov 2003). The situation is the following: I have tried to upgrade a system (http://www.msi.com.tw/program/products/server/svr/pro_svr_detail.php?UID=376) from 5.1-RELEASE to 5.2-BETA, according to the src/UPDATING text (I did add the COMPAT_FREEBSD4 option to my kernel config). buildworld went fine and so did buildkernel. After doing a installkernel and booting with the newly installed 5.2-BETA kernel (single-user), I get the following message before I get thrown in the "mount root> " prompt: mounting root from ufs:/dev/ar0s1a setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 mount root> Did I miss a step or have I hit something in -current? Below is my dmesg output (working 5.1) : Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-RELEASE #0: Tue Nov 25 09:49:42 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/CURRENT Preloaded elf kernel "/boot/kernel/kernel" at 0xc0381000. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2391148112 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2391.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff real memory = 1073676288 (1023 MB) avail memory = 1039364096 (991 MB) pnpbios: Bad PnP BIOS data checksum Pentium Pro MTRR support enabled acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00fdec0 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 30.0 on pci0 pci2: on pcib2 em0: port 0xb000-0xb03f mem 0xe200-0xe201 irq 12 at device 5.0 on pci2 em0: Speed:10 Mbps Duplex:Half fxp0: port 0xb400-0xb43f mem 0xe202-0xe203,0xe2044000-0xe2044fff irq 10 at device 6.0 on pci2 fxp0: Ethernet address 00:0c:76:15:19:c5 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci2: at device 7.0 (no driver attached) atapci0: port 0xcc00-0xcc0f,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xbc00-0xbc07 mem 0xe204-0xe2043fff irq 11 at device 10.0 on pci2 ata2: at 0xbc00 on atapci0 ata3: at 0xc400 on atapci0 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci1 ata1: at 0x170 irq 15 on atapci1 pci0: at device 31.3 (no driver attached) sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 npx0: on motherboard npx0: INT 16 interface orm0: at iomem 0xc8000-0xd07ff,0xc-0xc7fff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3b0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec IP Filter: v3.4.31 initialized. Default = pass all, Logging = enabled acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% ad4: 117800MB [239340/16/63] at ata2-master UDMA100 ad6: 117800MB [239340/16/63] at ata3-master UDMA100 ar0: 117301MB [14953/255/63] status: READY subdisks: disk0 READY on ad4 at ata2-master disk1 READY on ad6 at ata3-master Opened disk ad4 -> 1 Opened disk ad6 -> 1 Opened disk ad6 -> 1 Mounting root from ufs:/dev/ar0s1a %atacontrol list ATA channel 0: Master: no device present Slave: no device present ATA channel 1: Master: ATA/ATAPI rev 0 Slave: no device present ATA channel 2: Master: ad4 ATA/ATAPI rev 6 Slave: no device present ATA channel 3: Master: ad6 ATA/ATAPI rev 6 Slave: no device present %atacontrol status 0 ar0: ATA RAID1 subdisks: ad4 ad6 status: READY %atacontrol mode 2 Master = UDMA100 Slave = ??? %atacontrol mode 3 Master = UDMA100 Slave = ??? -- Jeroen Hogeveen, <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW2 verrevpath issue (IPv4 TCP, fresh kernel)
On Tue, 25 Nov 2003, Sean Chittenden wrote: > > Is my expectation wrong or is there a pertinent IPFW2 bug in a current > > 5.2-BETA kernel? > > You're alone in this, though cjc hasn't been able to reproduce this. > Are you on a multi-homed system? -sc Sort of. I do have three xl(4) NICs in my system. xl0 and xl1 are bridged via ng_bridge(*), IP 192.168.0.1 on one card, no IP on the other; xl2 is the transport for tun0 (which is PPPoE in my case) and doesn't have an IP either, so "multi-homed" might read "tun0 has an address, xl0 has another and lo0 has a third one". These xl* cards shouldn't matter for my problem, at the time I tested my firewall setups, the networks were idle with no other hosts attached. I noticed that very recently there was a bug fix that made the machine pick the right outbound address again (which it didn't for some days or weeks, haven't compiled kernels daily) - I wonder if it's related. Unfortunately, I don't have a 5.1-RELEASE box here to test. Would 4.9 with IPFW2 option be sufficiently similar in IPFW2 matters that it's worthwhile testing? (*) I have a configuration where the bridge is to have the same IP from both xl0 and xl1. Traditional bridge code gets confused over ARP and coughs up the MACs it would need and "locks itself out", netgraph-bridge is fine however. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rtld + static linking
"E.B. Dreger" wrote: > After watching the recent shared/dynamic threads, and reading the > archives from five or six years ago, I have a question... > > Dynamic linking works by the kernel running the dynamic linker, > which loads shared objects and fixes the symbol tables, yes? No. Dynamic linking works because the crt0 mmap's the /usr/libexec/ld.so file as executable, and then points known stub offsets into it. It then passes this as part of the environment, at a negative offset, into the _main, which fills out a little glue table. After all this is set up, then _main calls the location .entry in the executable, which is usally main, but can be set to something else at link time. This all works because the crt0.o has some self-knowledge for a number of symbol offsets, and because _main is called with the environment descriptor. Basically, the environment descriptor is lost in the static linking case. > Is there some reason that a statically-linked program couldn't > include some "ld-elf.a" type of intelligence? Would that be > necessary and sufficient to allow statically-linked programs to > load shared objects? Yes, and yes. The main reason that there is no dlopen is that the environment descriptor is lost. This is pretty trivial to remedy, but it means passing the environment descriptor to something that can use it to set up the startup. This is complicated by the fact that only a single .init entry point is usable, so if you were to override it, you would lose library initialization for C libraries, and you would fail to call constructor code for statically declare class instances in C++ code, and lose out on other linker set stuff, such as per thread exception stacks, etc.. The trivial fix for this is to add a void * parameter to the constructor iterator in the crt0, and then pass the environment there, so that you could implement a libdlopen that took that and used it to obtain the self-knowledge of the crt0 that was needed to (1) adjust the stub pointers to an mmap'ed ld.so, and (2) provide the access to the symbol table needed so that when you loaded modules, they would link properly vs. the symbols in the executable itself. You would either need to change the list to specifically reference the libc symbols, OR you would need to reload libc.so (the problem with doing the latter is that you might get a different libc out of it, and the executable symbols that may replace the libc symbols wouldn't do so for modules, so that's a non-starter). It's actually a pretty trivial crt0 and ld change to deal with this, the sticking point is that you have to also change the libgcc and other GNU code to pass a NULL value to the void * constructor parameter in the default case. This would make the code minorly incompatible with Linux, etc., unless you could get the GCC people to pick up your change. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Modem(PCMCIA) works on 4.8, hangs machine on 5.2-BETA
On Tue, 25 Nov 2003, Larry Rosenman wrote: > I tried(!) to use the following modem on my 5.2-BETA (actually -CURRENT from > a week or so ago), and the machine HUNG on the OPEN. > > > usb0: USB revision 1.0 > usb1: USB revision 1.0 > fwohci0: OHCI version 1.0 (ROM=1) > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1: at port 0x2e8-0x2ef irq 3 on isa0 > sio1: type 16550A > sio2 at port 0x2f8-0x2ff irq 11 flags 0x4 slot 0 on pccard0 > sio2: type 16550A > sio2: unable to activate interrupt in fast mode - using normal mode > The SIO2 is my Toshiba 3CXM056-BNW modem, and is what I'm sending this > from on 4.8. > > What debug/help do y'all need to fix it? Interestingly, I tried it again under the -CURRENT, and got 512 silo overflows, and 9400 interupt overflows, then the lock. I can't even get into DDB. So, where to PCMCIA/CBB/ETC guru's? LER > > LER > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)
On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote: > As a user, I like /rescue better than the step-child that /stand/* used > to be. It's part of the world, which /stand wasn't. Except that we still have /stand. It should be shot, but some won't let it go... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: rtld + static linking
On Tue, Nov 25, 2003 at 05:44:18PM -0800, Terry Lambert wrote: > "E.B. Dreger" wrote: > > After watching the recent shared/dynamic threads, and reading the > > archives from five or six years ago, I have a question... > > > > Dynamic linking works by the kernel running the dynamic linker, > > which loads shared objects and fixes the symbol tables, yes? > > No. > > Dynamic linking works because the crt0 mmap's the /usr/libexec/ld.so > file as executable, and then points known stub offsets into it. No. Dynamic linking works because the kernel loads and runs the dynamic linker when it sees that the executable defines an interpeter. > > Is there some reason that a statically-linked program couldn't > > include some "ld-elf.a" type of intelligence? Would that be > > necessary and sufficient to allow statically-linked programs to > > load shared objects? > > Yes, and yes. No, and no. A complete executable (i.e. staticly linked) does not export any symbols, or at least not in the same way a shared executable and shared libraries do. If I try to dynamicly link libbar into a complete executable foo and libbar depends on libc, then there's no guarantee that all the required bits from libc are in foo, nor is there any guarantee that the bits are actually visible or even accessable (no linkage table). Dynamicly loading libc for use by libbar can work, but it's not guaranteed. One failure mode is suddenly having two instances of a common variable instead of one. Another is the clobbering of data caused reinitializations. So, the problem of dynamic linking a shared library into a static process is non-trivial and probably cannot be solved genericly. Under restricted and controlled conditions you can make it work. I would call it the ability to have plugins, not the ability to load dynamic libraries. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to fix this in 5.1-REL??
Brooks Davis answered: walt asked: What does 'buildworld' give us that the new kernel might need? The correct toolchain including the compiler and config(8). Okay, thanks, that helps. Just thinking out loud about worst-case examples for people who do routinely use 'make world' (like I have for several years). I found out first-hand why installworld quits halfway through when the new executables won't run on the old kernel. I need no further education on that point ;-) I'm thinking, though, that doing 'make kernel' first has a much lower potential for disaster than 'make world': if I reboot after a 'make kernel' and the new kernel won't run on the old world, then all I need to do to recover is to boot the old kernel again and 'make buildworld'. Seems difficult to do any real harm this way. Is this completely wrong-headed? Am I missing something important? (Yes, I know I should just do it the right way every time -- but I'm trying to reason through just why some ways are right and some are wrong.) Thanks for any insights. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
