Re: AMD AGP Bug
Glendon Gross wrote: That's right, guys! This is FreeBSD after all... so Mr. Lambert is entitled to charge 10K for that bugfix code if he wants. In fact he is Free to do so. But it's a little pricy for me, although perhaps not for AMD if it means they can fix their cache-paging problems! It cost me two weeks to figure out, and both Intel and AMD wanted to charge me $$$ to file a problem report. I once fixed a Borland library problem which was pretty serious: it would effect all programs that did string manipulation, and linked the standard library, instead of using the compiler generated inlines. They wanted to charge me to file a bug report, too, so I demanded that they agree to send me a T-shirt before I would tell them the fix. As far as I know, they still have the bug. Microsoft also charged me to report a bug in the removable media driver in Windows 95/98 (you can't safely page to it because it fails to propagate some writes it's supposed to propagate, so you can'tt safely install Windows on a JAZ or Syquest cartridge, because paging fails). I made them admit the problem, and they credited the incident report after they admitted it was their issue, but it still started my 90 day support clock, so that it wasn't there when I needed it, later. Since it's not a FreeBSD problem, you'll forgive me if I find it funny that Linux and Windows disables the PSE to work around some problems. It's not that hard to understand or work around, if you know where to look, and knowing where to look is what will cost them. The *other* AMD problem, with AGP and 4K and 4M pages that point to the same memory could arguably be a chipset or a software problem (depending on whether or not the chipset vendor has documented the behaviour before people were let loose to write the software -- errata: the difference between a software problem and a software workaround to a hardware problem). It's already documented how to work around that one; I'm sure a fix is pending for Linux, and Windows will probably leave PSE off until they can figure out a way to update everyone. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: AMD AGP Bug
Terry Lambert wrote: Glendon Gross wrote: That's right, guys! This is FreeBSD after all... so Mr. Lambert is entitled to charge 10K for that bugfix code if he wants. In fact he is Free to do so. But it's a little pricy for me, although perhaps not for AMD if it means they can fix their cache-paging problems! It cost me two weeks to figure out, and both Intel and AMD wanted to charge me $$$ to file a problem report. [..] Since it's not a FreeBSD problem, you'll forgive me if I find it funny that Linux and Windows disables the PSE to work around some problems. It's not that hard to understand or work around, if you know where to look, and knowing where to look is what will cost them. [..] The *other* AMD problem, with AGP and 4K and 4M pages that point to the same memory could arguably be a chipset or a software problem (depending on whether or not the chipset vendor has documented the behaviour before people were let loose to write the software -- errata: the difference between a software problem and a software workaround to a hardware problem). It's already documented how to work around that one; I'm sure a fix is pending for Linux, and Windows will probably leave PSE off until they can figure out a way to update everyone. I'm a little confused as to which bugs are which that we're talking about now. Which is the one that you're trying to sell the info for? The issues that I know about: - interactions between PG_G, CR4_PGE, 4M and 4K pages and TLB flushing (potentially cross platform issue due to boot time quirks).. I think we have a workaround for this in our code already, but I have a better complete fix for it in a pending change that I'm working on. - AMD invlpg vs 4MB page bug (AMD bug). If you invlpg using an address in the upper 2MB of a 4MB page, the 4MB tlb may not be flushed (we dont suffer from this (I think) because we do some very suboptimal things with 4MB pages), versus doing an invlpg at the base address of the 4MB mapping. - AMD write cache allocation due to speculative writes being cancelled and then written back later vs no cache snooping on AGP regions. I'm somewhat perplexed about this issue, there's lots of conflicting info going around, a good deal of it which does not make much sense [to me :-)]. I really dont see what PSE has to do with this for several reasons.. if the page/ region is cacheable, why does a 4MB vs 4K page make any difference? cacheable vs no-cache-snooping is a recipe for disaster.. why would 4K pages on a non-coherent region be safer? Or is the problem that write allocation happens on uncacheable/non-write-back regions in 4MB pages? Or something else? - hardware prefetch (newer AMD cpus, pentium 4, 0.13 micron pentium3's) related problems. (can be solved with PAT and/or MSRR programming). I'm just trying to figure out if there's something I'm missing. I know we do some very dubious things with PG_G at bootup. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Pam problems today
David W. Chapman Jr. [EMAIL PROTECTED] writes: are the lines I had to comment out. I checked and I don't have pam_login_access.so. I know that there have been a bunch of changes recently, so if this is a known problem I apologize. Right. I forgot to commit the Makefile. Sorry :( DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: AMD AGP Bug
Peter Wemm wrote: I'm a little confused as to which bugs are which that we're talking about now. Which is the one that you're trying to sell the info for? I'm not really trying to sell the fix; it's that I'm not willing to give it away when it's no benefit to do so; I'd need a bribe. Kind of like Kirk and Soft Updates. 8-). I was aware of all but the recent AMD problem, but it's pretty obvious in retrospect (Alfred had the idea of putting a fast network interface in an AGP slot some time back, and I looked at AGP a little back then). I can tell you how to cause the problem I'm talking about, off list, if you're willing to laugh along and keep quiet (I have dibs on the bribe 8-)). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
How is maintaining ipsec SADB code?
I'm trying to implement the use of SA sensitivity labels. While looking through the code, i've founded some unclear operations, so I want to ask some questions about them. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Pam problems today
David, Thanks for posting this. I have built a new world and kernel but haven't run mergemaster, yet. I did see the problem just waiting in /usr/src/etc/rc.d so I think I'll just leave it there for the time being. Thanks again for the advance notice. ed Quoting David W. Chapman Jr. [EMAIL PROTECTED]: Same thing happened to me yesterday after a make install world and mergemaster. Took awhile to figure out. Building and installing libpam does not install pam_login_access.so Manfred I'm glad I'm not alone. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Pam problems today
On Fri, Feb 01, 2002 at 06:25:21AM -0800, Edwin Culp wrote: David, Thanks for posting this. I have built a new world and kernel but haven't run mergemaster, yet. I did see the problem just waiting in /usr/src/etc/rc.d so I think I'll just leave it there for the time being. Thanks again for the advance notice. If you cvsup now, it should be fixed, it was a missing Makefile. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Recent -Current KDE problems
I'm seeing this on a -current as of yesterday and as of today. I just finished a make world and kernel a few mins ago as well as rebuilding all my ports, but kde still dies when I try to load it, last night before I tried to rebuild all the ports I was getting signal 11's. Any ideas anyone? list! Bus error - core dumped Feb 1 09:03:19 dwcjr kernel: pid 88809 (ksplash), uid 1000: exited on signal 10 (core dumped) Bus error - core dumped Bus error - core dumped Feb 1 09:03:20 dwcjr kernel: pid 88810 (kdeinit), uid 1000: exited on signal 10 (core dumped) Feb 1 09:03:20 dwcjr kernel: pid 88811 (ksmserver), uid 1000: exited on signal 10 (core dumped) connect() failed: : No such file or directory -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Recent -Current KDE problems
++ 01/02/02 09:04 -0600 - David W. Chapman Jr.: | I'm seeing this on a -current as of yesterday and as of today. I | just finished a make world and kernel a few mins ago as well as | rebuilding all my ports, but kde still dies when I try to load it, | last night before I tried to rebuild all the ports I was getting | signal 11's. Any ideas anyone? This is because KDE is compiled with objprelink (ports/devel/objprelink) which depends on a certain version of binutils, I guess. Once I get my laptop updated I'll see what I can figure out.. I'm guessing it's a small patch to objprelink. In the mean time, I'll see if I can add a WITHOUT_OBJPRELINK hook to the KDE ports. (More discussion on the KDE/FreeBSD list at http://lists.csociety.org/listinfo/kde-freebsd) --pete -- Pete Fritchman [petef@(databits.net|freebsd.org|csh.rit.edu)] finger [EMAIL PROTECTED] for PGP key To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Recent -Current KDE problems
On Fri, Feb 01, 2002 at 10:18:20AM -0500, Pete Fritchman wrote: ++ 01/02/02 09:04 -0600 - David W. Chapman Jr.: | I'm seeing this on a -current as of yesterday and as of today. I | just finished a make world and kernel a few mins ago as well as | rebuilding all my ports, but kde still dies when I try to load it, | last night before I tried to rebuild all the ports I was getting | signal 11's. Any ideas anyone? This is because KDE is compiled with objprelink (ports/devel/objprelink) which depends on a certain version of binutils, I guess. Once I get my laptop updated I'll see what I can figure out.. I'm guessing it's a small patch to objprelink. In the mean time, I'll see if I can add a WITHOUT_OBJPRELINK hook to the KDE ports. How are you going to tell, in the objprelink port, what version of binutils you're working with? If you patch it to fix the -current problem, you'll likely break -stable. -- Alan E Please rush me my portable walrus cleaning kit! Yes I am over 18, but my IQ isn't. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Recent -Current KDE problems
On Fri, Feb 01, 2002 at 10:18:20AM -0500, Pete Fritchman wrote: ++ 01/02/02 09:04 -0600 - David W. Chapman Jr.: | I'm seeing this on a -current as of yesterday and as of today. I | just finished a make world and kernel a few mins ago as well as | rebuilding all my ports, but kde still dies when I try to load it, | last night before I tried to rebuild all the ports I was getting | signal 11's. Any ideas anyone? This is because KDE is compiled with objprelink (ports/devel/objprelink) which depends on a certain version of binutils, I guess. Once I get my laptop updated I'll see what I can figure out.. I'm guessing it's a small patch to objprelink. In the mean time, I'll see if I can add a WITHOUT_OBJPRELINK hook to the KDE ports. How are you going to tell, in the objprelink port, what version of binutils you're working with? If you patch it to fix the -current problem, you'll likely break -stable. Or maybe he will fix binutils. :-) On current anything that use a libpng that was compiled with the new binutils just coredump with a bus error. Well anything is maybe exagerated a little, gs from ghostscript-gnu, pnmtopng from netpnm and also a manually compiled and dinamically linked pngtest from png/work/libpng. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Recent -Current KDE problems
++ 01/02/02 11:07 -0500 - Alan Eldridge: | On Fri, Feb 01, 2002 at 10:18:20AM -0500, Pete Fritchman wrote: | ++ 01/02/02 09:04 -0600 - David W. Chapman Jr.: | | I'm seeing this on a -current as of yesterday and as of today. I | | just finished a make world and kernel a few mins ago as well as | | rebuilding all my ports, but kde still dies when I try to load it, | | last night before I tried to rebuild all the ports I was getting | | signal 11's. Any ideas anyone? | | This is because KDE is compiled with objprelink (ports/devel/objprelink) | which depends on a certain version of binutils, I guess. Once I get my | laptop updated I'll see what I can figure out.. I'm guessing it's a | small patch to objprelink. In the mean time, I'll see if I can add a | WITHOUT_OBJPRELINK hook to the KDE ports. | | How are you going to tell, in the objprelink port, what version of | binutils you're working with? If you patch it to fix the -current problem, | you'll likely break -stable. Probably some magic with OSVERSION (if it was bumped) or something. --pete -- Pete Fritchman [petef@(databits.net|freebsd.org|csh.rit.edu)] finger [EMAIL PROTECTED] for PGP key To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: *_enable=YES behavior is bogus
Paul Fardy [EMAIL PROTECTED] types: When the rc.conf file includes foo_enable=NO it's right to expect that the system will operate like a system that does not have foo installed. On Thursday, January 31, 2002, at 04:43 AM, Mike Meyer wrote: So you think that if I install a syslog from ports that's started via /usr/local/etc/rc.d/syslogd.sh, syslog_enable=NO in /etc/rc.conf should disable it? For that matter, if I set ipfilter_enable=YES and firewall_enable=NO, should the system enable ipfilter or not, as there are two contradictory things. These aren't similar situations. Your syslog example is essentially an issue of scope or name space and not the meaning enable or of no. It's my understanding that the values in /etc/rc.conf apply to the FreeBSD core and not to any version that someone might install to override the core version. The configuration for an package that sits in /usr/local should be found in /usr/local/etc. I'd be disappointed to see packages that don't follow such a policy. There are many examples in rc.conf similar to your suggested contradiction: natd_enable=NO natd_interface=fxp0 inetd_enable=NO inetd_program=/usr/sbin/inetd These examples, _and_yours_, are examples that suggest that /etc/rc.conf has a fundamental principle that foo_enable=YES/NO is supreme. One can set up all the requisite parameters (e.g. you can create sendmail.cf, named.conf, tune inetd.conf, compile psm into the kernel or install any of various screen savers), yet one can still set an appropriate variable foo_enable=NO which will not enable the feature. Not enabling something is *not* the same thing as disabling it. But I think that the intent in /etc/rc.conf is that enable=NO _is_ the same thing as disabling it. You might say If that were the intent, they'd have used ___. What word should we use to indicate the absolute YES or NO that some of us believe should be the simple correct interpretation? Paul Fardy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: *_enable=YES behavior is bogus
On Fri, Feb 01, 2002 at 02:47:30AM -0330, Paul Fardy wrote: These examples, _and_yours_, are examples that suggest that /etc/rc.conf has a fundamental principle that foo_enable=YES/NO is supreme. One can set up all the requisite parameters (e.g. you can create sendmail.cf, named.conf, tune inetd.conf, compile psm into the kernel or install any of various screen savers), yet one can still set an appropriate variable foo_enable=NO which will not enable the feature. It will not enable it, no. Nor will the feature be disabled if it for some reason already was enabled. Not enabling something is *not* the same thing as disabling it. But I think that the intent in /etc/rc.conf is that enable=NO _is_ the same thing as disabling it. You might say If that were Consider that the actual code in the various rc* start scripts is in most cases of the form: if foo_enable==yes do stuff else do nothing Some cases are instead if foo_enable==no do nothing else do stuff A cursory search found a total of one instance where foobar=NO actually makes something happen, and it was not of the form foo_enable=NO (The single exception I found is tcp_extensions=NO) For all other variables one can set in rc.conf foobar=NO means do nothing. Looking at the code the intent certainly seems to be foo_enable=NO shouldn't do anything. the intent, they'd have used ___. What word should we use to indicate the absolute YES or NO that some of us believe should be the simple correct interpretation? foo_enabled=YES/NO perhaps?? I.e. describing the desired state of the feature instead of the desired action to be taken. There are of course several people who feel that the current behaviour is the intuitive and obviously correct interpretation and would prefer not to have it changed. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in vfs_syscalls
* Michael Nottebrock [EMAIL PROTECTED] [020131 12:19] wrote: I'm getting these kind of panics with yesterday's kernel every time I try to use rpm. [[EMAIL PROTECTED]]:~ rpm -Uhv --root=/compat/linux /home/lofi/libpng-1.0.9-1.i386.rpm recursed on non-recursive lock (sleep mutex) filedesc structure @ ../../../kern/vfs_syscalls.c:3573 first acquired @ ../../../kern/vfs_syscalls.c:998 panic: recurse I've just committed a fix, please let me know if it works for you. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: *_enable=YES behavior is bogus
Hi all, But I think that the intent in /etc/rc.conf is that enable=NO _is_ the same thing as disabling it. You might say If that were the intent, they'd have used ___. What word should we use to indicate the absolute YES or NO that some of us believe should be the simple correct interpretation? I would suggest foo_functionality. That is very clear, (albeit a bit long *g*). Ciao Siegbert To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: AMD AGP Bug
On Thu, 31 Jan 2002, Jason Evans wrote: On Wed, Jan 30, 2002 at 11:14:48PM +0100, Gérard Roudier wrote: Linux can be fixed, but the useless writes of the existing Athlons from the very fast cache to the relatively very slow memory cannot. And all Athlon users may well pay this penalty under any OS... unless we want to disable caching. :) Have you done benchmarks to show that the speculative writes are useless often enough to cause enough memory bus contention that overall performance is degraded, despite the speedups when the speculative writes are valid? I haven't done any benchmark of this sort, neither intend to do any since I haven't time for that. But I wrote in my email that my 2 Athlon systems worked fine and fast, just to indicate that for normal use I didn't see any performance problem at all. I suspect that AMD in fact performed such tests; otherwise they wouldn't have gone to the trouble of implementing speculative writes. The Athlon rewriting same value to cacheable memory under the knees of programmers looks a severe issue to me if it is true. Not only AGP memory can be affected. What about SMP, MMIO (if some cacheable mapping exists), etc...? In my opinion, OSes having some cacheable mapping to AGP memory is not the real problem. Just it has revealed the AMD issue. Gérard. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
auth 7d989b2b unsubscribe freebsd-current [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Recent -Current KDE problems
On Fri, Feb 01, 2002 at 11:07:19AM -0500, Alan Eldridge wrote: How are you going to tell, in the objprelink port, what version of binutils you're working with? If you patch it to fix the -current problem, you'll likely break -stable. I plan on MFC'ing Binutils 2.12.0 when it is released in 2 mo. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Recent -Current KDE problems
On Fri, Feb 01, 2002 at 10:36:01AM -0800, David O'Brien wrote: On Fri, Feb 01, 2002 at 11:07:19AM -0500, Alan Eldridge wrote: How are you going to tell, in the objprelink port, what version of binutils you're working with? If you patch it to fix the -current problem, you'll likely break -stable. I plan on MFC'ing Binutils 2.12.0 when it is released in 2 mo. Please let the KDE team know when this is going to happen. Also, if my above suspicion is correct, then we need a way of determining which version of binutils is on a -stable system. Is ld --version a reliable indicator? -- Alan E Please rush me my portable walrus cleaning kit! Yes I am over 18, but my IQ isn't. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock reversal in fdalloc()
* Alfred Perlstein [EMAIL PROTECTED] [020131 10:48] wrote:
* Bruce Evans [EMAIL PROTECTED] [020131 09:42] wrote:
I'm not sure that releasing the lock here is safe, but other parts of
fdalloc() do this.
I don't think this is safe at a glance, I think it's only safe right
before return'ing from the function. I'll look at it later tonight.
It's actually safe... however dup2 thinks that we won't race
for the file slot:
if (new = fdp-fd_nfiles) {
if ((error = fdalloc(td, new, i))) {
FILEDESC_UNLOCK(fdp);
return (error);
}
if (new != i)
panic(dup2: fdalloc);
/*
* fdalloc() may block, retest everything.
*/
goto retry;
}
basically it seems to get pissy if it doesn't get the file slot it asks
for, so if another thread wins the race here, we'll panic. this problem
seems to also exist for 4.x and previous versions of freebsd.
I'd like to get this fixed. Any suggestions? I think simply
removing the assertion should remove this hazzard, correct?
--
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using 1970s technology,
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Recent -Current KDE problems
On Fri, Feb 01, 2002 at 01:51:54PM -0500, Alan Eldridge wrote: Is ld --version a reliable indicator? Should be. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: AMD AGP Bug
On Thu, 31 Jan 2002, Terry Lambert wrote: Cameron, Frank wrote: From what was posted on the linux-kernel list the problem is the OS doing the wrong thing not the hardware. I originally asked the question (albeit not worded as clearly as I should have) because if Microsoft and Linux programmers made the same mistake, might FreeBSD have also. No. FreeBSD does not make active use of 4M pages for anything other than the initial kernel text and data, which is obvious, if you look at /sys/i386/machdep.c. For Linux and Windows, the obvious thing is to not map the memory into an aperture marked cacheable and in a 4M page; it's a coding problem with the use of 4M pages, when memory in them is allocated to AGP. This still doesn't get around the other bug, which happens if you use 4M pages certain obviously useful ways, without waving a dead chicken over certain things. 8-). This one is not $10,000 but $0, since it has already been suggested.:-) Gérard. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: AMD AGP Bug
On Thu, Jan 31, 2002 at 09:32:48PM +0100, Gérard Roudier wrote: On Thu, 31 Jan 2002, Jason Evans wrote: On Wed, Jan 30, 2002 at 11:14:48PM +0100, Gérard Roudier wrote: Linux can be fixed, but the useless writes of the existing Athlons from the very fast cache to the relatively very slow memory cannot. And all Athlon users may well pay this penalty under any OS... unless we want to disable caching. :) Have you done benchmarks to show that the speculative writes are useless often enough to cause enough memory bus contention that overall performance is degraded, despite the speedups when the speculative writes are valid? I haven't done any benchmark of this sort, neither intend to do any since I haven't time for that. But I wrote in my email that my 2 Athlon systems worked fine and fast, just to indicate that for normal use I didn't see any performance problem at all. I suspect that AMD in fact performed such tests; otherwise they wouldn't have gone to the trouble of implementing speculative writes. The Athlon rewriting same value to cacheable memory under the knees of programmers looks a severe issue to me if it is true. Not only AGP memory can be affected. What about SMP, MMIO (if some cacheable mapping exists), etc...? I am not familiar with the acronym MMIO is so I can't comment on that. In general though, having memoryspace used for memory-mapped I/O devices (including AGP) marked as cacheable is a bad idea unless you are very careful and know exactly what you are doing. For SMP it shouldn't be any problem. Multi-CPU systems normally run some cache-coherence protocol between themselves to make sure that things like this is not a problem. In my opinion, OSes having some cacheable mapping to AGP memory is not the real problem. Just it has revealed the AMD issue. It might be argued that there should be some cache-coherence protocol between the CPU and the AGP device. Not knowing how AGP is specified I don't know if this interaction between the CPU and AGP is a bug or just working as specified. I suspect it is the latter though. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: *_enable=YES behavior is bogus
At 6:36 PM +0100 2/1/02, Erik Trulsson wrote: Consider that the actual code in the various rc* start scripts is in most cases of the form: if foo_enable==yes do stuff else do nothing The RC scripts are starting up in a known environment (loosely speaking). Enough is known about that environment that the code in question knows there there is no need to do anything to turn off the service if the rc.conf file has blah_enable=NO. When 'lpd_enable=no', for instance, then it is very reasonable for the startup scripts to assume that absolutely nothing needs to be done to turn off lpd. We pretty much know it ain't running, so why write code to turn it off? I imagine it's futile to argue this, if you're going to argue it based on the implementation-details in rc.conf, instead of asking what should we do? from the point of view of what would make the most sense to the most users. As a support person, I also like to think of another question. Given that some users will get it wrong no matter which way we do this, then which wrong is the one that we can handle the most gracefully? In this discussion, there have been two suggestions as to how 'firewall_enable=no' should behave. 1) if the firewall is compiled in the kernel, then =no means that the firewall is blocking all packets, no matter what other rules might be lying around. The machine is completely locked down from network access (ie, the present behavior). or 2) no matter how the kernel is compiled, =no means the machine acts as if there is no firewall installed. Ie, it accepts all packets. No packets are blocked. The machine is wide open. If the user *expects* 1, but we actually implement 2, then the machine is wide-open when they did not expect that. My position is that we can *easily* do something to help that person immediately realize that they did not get what they expected. If the user *expects* 2, but we implemented 1, then the machine is locked down. If the user is not sitting at the console of the machine, then there is absolutely nothing which can be done (from a coding perspective) to help that person out. They must have a keyboard and monitor on that machine, and they must go to the machine and login via that console. I understand the first error (where the machine ends up completely open) is not desirable. It is very very bad. However, I think we can write some code to help out that user. That user is extremely likely to be sitting at the console, and they are extremely likely to want to log into that console, and there is nothing which prevents them from logging in. We can provide warning messages for that user, and they can immediately fix the error. But I think the second error is also very bad, and there is no way for us to address it via coding. It might be a pretty major hassle for that person to fix the problem (particularly if they did this over a remote connection, and the machine is far away). And yes, the user should be brilliant and a complete expert before they change any setting in any file on a unix box, but hearing that they were stupid is not much of a soothing consolation to the user when they are hit with a situation like this. As a support person, it is pretty rare that the user is happy when they find out they were stupid for making a perfectly reasonable assumption, based on how everything else in rc.conf seems (to them) to work. No, they did not read the code to see what the 'else' case of every enable option does, but they did notice that every time they set blah_enable=no, they found that when the system came up blah was not running. It *is* reasonable for them to assume the same behavior would be true for network_enable=no. I understand the reasoning of people who think the present behavior is logical. However, we can write code which helps those people if we pick what seems (to them) to be the illogical behavior. We do not have that option for the group of people who happen to use a different set of logical reasoning to come to the opposite conclusion. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: *_enable=YES behavior is bogus
At 6:36 PM +0100 2/1/02, Erik Trulsson wrote: Consider that the actual code in the various rc* start scripts is in most cases of the form: if foo_enable==yes do stuff else do nothing Let me approach this from a different angle. Several people have tried to argue this by proposing various What if? scenarios. Let me also do that. Let us say that we did happen to decide that for all 'foo_enable' options in rc.conf, a setting of 'foo_enable=no' does in fact mean that the service 'foo' will NOT be running at the end of the boot-up process. Maybe some company offers us a million dollars if we will just guarantee that, and we think of all the good programmers we could pay for that million dollars, so we all agree to standardize on this definition of 'enable=no' If we decided to do that, then as a *practical* matter, how many of the current options in rc.conf would need to be changed? I don't mean if we need to cover the case where someone renames /usr/sbin/lpd to /bin/echo, what would we need to do?. I mean, given any default installation of the base operating system (no ports), and any valid kernel configuration, in what cases of 'enable' would we really *have* to add some lines to those 'else' clauses that you quoted? In the case of lpd_enable, as a *practical* matter, there would be no need to write additional code. There is no kernel setting which automatically turns on lpd support, and if 'lpd_enable=yes' does not *start* /usr/sbin/lpd, then we do know that the lpd program is not running. I don't have time to look into it now, but I expect that is true for all of the other 'enable' options. As a *practical* reality, I expect that the firewall_enable option is the only one where we do need to write code to implement the 'enable=no' case as I described it. People will argue that this is special, because it's a kernel option! Lpd would behave exactly the same way, *if* it were a kernel option!. All fine and good, *if* it were true, but irrelevant to my What if? question. Of the current foo_enable options, which options would we need to change *right now* to support the definition of 'enable=no' that some people think is logical? [mind you, I don't actually know the answer to that question, but I just got a phone call and need to leave right now... So, I am breaking the first rule of a good lawyer, in that I am asking a question that I don't already know the answer to. :-) ] -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: AMD AGP Bug
On Fri, 1 Feb 2002, Erik Trulsson wrote: On Thu, Jan 31, 2002 at 09:32:48PM +0100, Gérard Roudier wrote: On Thu, 31 Jan 2002, Jason Evans wrote: On Wed, Jan 30, 2002 at 11:14:48PM +0100, Gérard Roudier wrote: Linux can be fixed, but the useless writes of the existing Athlons from the very fast cache to the relatively very slow memory cannot. And all Athlon users may well pay this penalty under any OS... unless we want to disable caching. :) Have you done benchmarks to show that the speculative writes are useless often enough to cause enough memory bus contention that overall performance is degraded, despite the speedups when the speculative writes are valid? I haven't done any benchmark of this sort, neither intend to do any since I haven't time for that. But I wrote in my email that my 2 Athlon systems worked fine and fast, just to indicate that for normal use I didn't see any performance problem at all. I suspect that AMD in fact performed such tests; otherwise they wouldn't have gone to the trouble of implementing speculative writes. The Athlon rewriting same value to cacheable memory under the knees of programmers looks a severe issue to me if it is true. Not only AGP memory can be affected. What about SMP, MMIO (if some cacheable mapping exists), etc...? I am not familiar with the acronym MMIO is so I can't comment on that. In general though, having memoryspace used for memory-mapped I/O devices (including AGP) marked as cacheable is a bad idea unless you are very careful and know exactly what you are doing. Normally you just need a non-cachable mapping. Nothing should preclude to also have cachable mappings as long as programs donnot misuse _explicitely_ any of the existing mappings. For SMP it shouldn't be any problem. Multi-CPU systems normally run some cache-coherence protocol between themselves to make sure that things like this is not a problem. Theory looks perfect, reality is different. Just I am under the impression that Intel speak about their hardware errata a lot more clearly than AMD seem to do. In my opinion, OSes having some cacheable mapping to AGP memory is not the real problem. Just it has revealed the AMD issue. It might be argued that there should be some cache-coherence protocol between the CPU and the AGP device. Not knowing how AGP is specified I don't know if this interaction between the CPU and AGP is a bug or just working as specified. I suspect it is the latter though. AGP does not require cache to snoop AGP accesses to memory, but it perfectly allows implementations to ensure such coherency. As a result, AGP softwares must not rely on that. I guess that neither Windows 2000 nor Linux were/are relying on such coherency that is explicetely not required by AGP specifications. I never read that AGP specifications allow CPU to screw up AGP memory in the back of actually executed program instructions. Gérard. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: *_enable=YES behavior is bogus
Hello, I'm usually but a lurker, though I'd like to toss in my $.02 on this... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Garance A Drosihn Sent: Friday, February 01, 2002 4:52 PM To: Erik Trulsson; Paul Fardy Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: *_enable=YES behavior is bogus In this discussion, there have been two suggestions as to how 'firewall_enable=no' should behave. 1) if the firewall is compiled in the kernel, then =no means that the firewall is blocking all packets, no matter what other rules might be lying around. The machine is completely locked down from network access (ie, the present behavior). or 2) no matter how the kernel is compiled, =no means the machine acts as if there is no firewall installed. Ie, it accepts all packets. No packets are blocked. The machine is wide open. It strikes me that #2 is the clear winner in terms of implementation consistency. I understand the first error (where the machine ends up completely open) is not desirable. It is very very bad. However, I think we can write some code to help out that user. That user is extremely likely to be sitting at the console, and they are extremely likely to want to log into that console, and there is nothing which prevents them from logging in. We can provide warning messages for that user, and they can immediately fix the error. I'm not sure why this would be considered not desirable or bad in any other way. When the kernel is first compiled with the firewalling code, it seem silly that anyone would, at that early point, consider themselves firewalled. Even your average knucklehead user that wants to use the firewalling code, and compiles a new kernel with it present (implying at least some level of technical proficiency in the first place) would not expect to render the network useless--or be protected--until some chain of events occurred. The proper thing (IMHO) is to leave the behavior of the box unchanged (unfirewalled) until a change is willfully implemented--as opposed to some functionality being added to the kernel, which should not really effect normal operations (obviously with some rather large exceptions). If the exceptions are a concern, it seems to me focus should be on the consistency of kernel configuration and how it relates to normal operations--not the rc files. Cheers, Ben To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: *_enable=YES behavior is bogus
At 5:16 PM -0500 2/1/02, Benjamin P. Grubin wrote: I understand the first error (where the machine ends up completely open) is not desirable. It is very very bad. However, I think we can write some code to help out that user. That user is extremely likely to be sitting at the console, and they are extremely likely to want to log into that console, and there is nothing which prevents them from logging in. We can provide warning messages for that user, and they can immediately fix the error. I'm not sure why this would be considered not desirable or bad in any other way. When the kernel is first compiled with the firewalling code, it seem silly that anyone would, at that early point, consider themselves firewalled. Well, actually, I can easily think of reasons a person might end up with the firewall compiled into the kernel, and why they might really want to come up in a completely-locked down environment. That may seem odd, but sometimes there are good reasons to be very paranoid. I can also see that there should be some knob in rc.conf so a person can easily trigger this behavior. Note that they might want to do this *after* the initial install, where they have some reason where they want to reboot and immediately come up with the firewall blocking all network access. I really do not want to attack the intelligence of either group of users, since both groups have understandable reasons (IMO) for wanting the behavior that they want. Sometimes that happens. I just do not believe that the knob for this lockdown mode should be called 'firewall_enable=no', given the practical reality of what a user sees when they set 'foo_enable=no' for all other values of 'foo'. [and it turned out that the panic call I got in the middle of my previous message was due to a loose ethernet cable, and not a bunch of servers crashing, so that turned out to be easy... :-)] -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: *_enable=YES behavior is bogus
At 4:52 PM -0500 2/1/02, Garance A Drosihn wrote: It *is* reasonable for them to assume the same behavior would be true for network_enable=no. I meant firewall_enable=no here! If the option *was* called network_enable=no, then it would be VERY reasonable to expect the machine to be locked-down! :-) [it wouldn't surprise me if I have done that in some other messages, too. Sorry about that. Maybe I should check to see if my own brain's ethernet cable is plugged in] -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Login failures ...
Hello, I faced Login Fail problem when I upgrade to FreeBSD 5.0 Current. Error messages are login: PAM unable to dlopen(/usr/lib/pam_login_access.so) login: PAM[dlerror: Cannot open /usr/lib/pam_login+access.so] login: PAM adding faulty moule: /usr/log/pam_login_access.so Does anybody know how to solve it? Thanks in advance. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How is maintaining ipsec SADB code?
On Fri, Feb 01, 2002 at 08:49:15AM -0500, Ilmar S. Habibulin wrote: I'm trying to implement the use of SA sensitivity labels. While looking through the code, i've founded some unclear operations, so I want to ask some questions about them. This code comes from KAME: you can reach the developers at [EMAIL PROTECTED] Kris msg34008/pgp0.pgp Description: PGP signature
Re: lock reversal in fdalloc()
On Fri, 1 Feb 2002, Alfred Perlstein wrote:
It's actually safe... however dup2 thinks that we won't race
for the file slot:
if (new = fdp-fd_nfiles) {
if ((error = fdalloc(td, new, i))) {
FILEDESC_UNLOCK(fdp);
return (error);
}
if (new != i)
panic(dup2: fdalloc);
/*
* fdalloc() may block, retest everything.
*/
goto retry;
}
basically it seems to get pissy if it doesn't get the file slot it asks
for, so if another thread wins the race here, we'll panic. this problem
seems to also exist for 4.x and previous versions of freebsd.
I'd like to get this fixed. Any suggestions? I think simply
removing the assertion should remove this hazzard, correct?
Something like that. This was apparently missed when the retry loop was
added. Lite2 has the panic but not the retry loop.
BTW, the retry loop also picks up changes to the limit on descriptors.
In fdalloc(), the corresponding limit is treated as a loop invariant,
but it is not invariant. I think the process's rlimit can't change,
but maxfilesperproc can change even if the process doesn't block, since
it is not protected by FILEDESC_LOCK() :-(. Fortunately, the
maxfilesperproc limit isn't very important.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Junior Annoying Hacker Task
foo_enable=NO ipfilter_enable=YES firewall_enable=NO natd_enable=NO natd_interface=fxp0 inetd_enable=NO inetd_program=/usr/sbin/inetd foo_enable=YES/NO foo_enable=NO Who is a GTK hacker? Does someone want to write a registry editor program? The point of the program would be to edit the FreeBSD Registry, rc.conf, and make it look just like the Windows Registry in the editor, using _ as the implied path component/terminal component (key) seperator. Then we can all be honest with ourselves that the only difference between it an the Windows Registry is that the Windows registry is accessible/modifiable from kernel mode, and the path component and key names. You can start with: My Computer\HKEY_LOCAL_MACHINE\natd NameData --- - enable NO interface fxp0 My Computer\HKEY_LOCAL_MACHINE\inetd NameData --- - enable NO program /usr/sbin/inetd etc. If you want to get ambitious: o Make HKEY_LOCAL_MACHINE an alias for your node name, and include your node name in the list. o Call it localhost, if you are feeling too guilty about calling it HKEY_LOCAL_MACHINE. o Make the tool operate on node names other than localhost, so you can do remote administration of configuration files on a cluster of FreeBSD boxes o Add more subkeys; perhaps it should not be just My Computer\localhost\inetd but My Computer\localhost\rc.conf\inetd letting you fold in the other files, like the inetd.conf, into registry handlers, e.g.: My Computer\localhost\inetd.conf\telnet enable NO sockettype stream protocoltcp waitNO userroot program /usr/libexec/telnetd etc.. o Support sysctls in the HKEY_DYN_DATA and HKEY_CURRENT_CONFIG sections (for those that can go into loader.rc). Sure, people would be annoyed to find out that they had been moving towards an idea that Microsoft had developed, but wouldn't this be a fun tweak to people's tails? 8-) 8-) 8-) -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Latest binutils import breaks Alpha cross compiles
On 2002-01-30 23:22, Terry Lambert wrote: Peter Wemm wrote: I dont suppose you actually thought to go and have a look and see what the problem is yourself, rather than assigning the work to somebody else? Nope, sorry. I hear the latest binutils break Alpha cross compilation. My fix is to back out the changes locally, and not use them. Basically, instead of fixing the brokeness, I chose to not break the fixedness. This still *is* -CURRENT, right? If it doesn't break, once in a while, how will new things be tested by the -CURRENT userbase? Instead of whining about you broke it, and haven't fixed it it would be a far better thing to contribute patches that fix the brokenness. - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Fri, Feb 01, 2002 at 04:26:13PM -0800, Terry Lambert wrote: Who is a GTK hacker? Does someone want to write a registry editor program? The point of the program would be to edit the FreeBSD Registry, rc.conf, and make it look just like the Windows Registry in the editor, using _ as the implied path component/terminal component (key) seperator. Then we can all be honest with ourselves that the only difference between it an the Windows Registry is that the Windows registry is accessible/modifiable from kernel mode, and the path component and key names. You can start with: My Computer\HKEY_LOCAL_MACHINE\natd NameData --- - enable NO interface fxp0 My Computer\HKEY_LOCAL_MACHINE\inetd NameData --- - enable NO program /usr/sbin/inetd etc. If you want to get ambitious: o Make HKEY_LOCAL_MACHINE an alias for your node name, and include your node name in the list. o Call it localhost, if you are feeling too guilty about calling it HKEY_LOCAL_MACHINE. o Make the tool operate on node names other than localhost, so you can do remote administration of configuration files on a cluster of FreeBSD boxes o Add more subkeys; perhaps it should not be just My Computer\localhost\inetd but My Computer\localhost\rc.conf\inetd letting you fold in the other files, like the inetd.conf, into registry handlers, e.g.: My Computer\localhost\inetd.conf\telnet enable NO sockettype stream protocoltcp waitNO userroot program /usr/libexec/telnetd etc.. o Support sysctls in the HKEY_DYN_DATA and HKEY_CURRENT_CONFIG sections (for those that can go into loader.rc). This last point is neat, especially if whoever is doing it could setup something with the doc team and actually get to actively documenting, as things progress, what each sysctl does and affects. Sure, people would be annoyed to find out that they had been moving towards an idea that Microsoft had developed, but wouldn't this be a fun tweak to people's tails? 8-) 8-) 8-) -- Terry -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Friday 01 February 2002 07:26 pm, Terry Lambert wrote: foo_enable=NO ipfilter_enable=YES firewall_enable=NO natd_enable=NO natd_interface=fxp0 inetd_enable=NO inetd_program=/usr/sbin/inetd foo_enable=YES/NO foo_enable=NO Who is a GTK hacker? Does someone want to write a registry editor program? Yuch. Why? The point of the program would be to edit the FreeBSD Registry, rc.conf, and make it look just like the Windows Registry in the editor, using _ as the implied path component/terminal component (key) seperator. You are surely insane. Or trying to make a point which isn't true, which is pretty similar. Then we can all be honest with ourselves that the only difference between it an the Windows Registry is that the Windows registry is accessible/modifiable from kernel mode, and the path component and key names. No, there's are enormous differences: - There's a well-known plain-text file so it can be readily backed up and restored. - There is not a single point of failure for all progams; it only controls basic system functions and services, it does not control applications, so if it fails, your applications aren't all screwed up, and if your applications screw up terribly they can't corrupt your basic system. Indeed, the lack of an API to *write* to /etc/rc.conf is one of it's greatest strengths: It is far less vulnerable to major corruption if things go nutty. You can start with: My Computer\HKEY_LOCAL_MACHINE\natd NameData --- - enable NO interface fxp0 My Computer\HKEY_LOCAL_MACHINE\inetd NameData --- - enable NO program /usr/sbin/inetd etc. If you want to get ambitious: o Make HKEY_LOCAL_MACHINE an alias for your node name, and include your node name in the list. o Call it localhost, if you are feeling too guilty about calling it HKEY_LOCAL_MACHINE. o Make the tool operate on node names other than localhost, so you can do remote administration of configuration files on a cluster of FreeBSD boxes o Add more subkeys; perhaps it should not be just My Computer\localhost\inetd but My Computer\localhost\rc.conf\inetd letting you fold in the other files, like the inetd.conf, into registry handlers, e.g.: My Computer\localhost\inetd.conf\telnet enable NO sockettype stream protocoltcp waitNO userroot program /usr/libexec/telnetd etc.. o Support sysctls in the HKEY_DYN_DATA and HKEY_CURRENT_CONFIG sections (for those that can go into loader.rc). Sure, people would be annoyed to find out that they had been moving towards an idea that Microsoft had developed, but wouldn't this be a fun tweak to people's tails? 8-) 8-) 8-) -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME -- http://www.babbleon.org http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: AMD AGP Bug
Erik Trulsson wrote: The Athlon rewriting same value to cacheable memory under the knees of programmers looks a severe issue to me if it is true. Not only AGP memory can be affected. What about SMP, MMIO (if some cacheable mapping exists), etc...? I am not familiar with the acronym MMIO is so I can't comment on that. Memory Mapped I/O. 8-). In general though, having memoryspace used for memory-mapped I/O devices (including AGP) marked as cacheable is a bad idea unless you are very careful and know exactly what you are doing. What he said. 8-) 8-). For SMP it shouldn't be any problem. Multi-CPU systems normally run some cache-coherence protocol between themselves to make sure that things like this is not a problem. I think the problem is pages in which there are inter-CPU locks being set and cleared. Say you had a speculative write that would clear a lock, only you decide not to clear it because it doesn't happen. In my opinion, OSes having some cacheable mapping to AGP memory is not the real problem. Just it has revealed the AMD issue. It might be argued that there should be some cache-coherence protocol between the CPU and the AGP device. This is what Bruce and Peter suggested; Peter said that he was working on a rewrite of the pmap code and would look in that area. Not knowing how AGP is specified I don't know if this interaction between the CPU and AGP is a bug or just working as specified. I suspect it is the latter though. If it doesn't have to be correct, I can make it as fast as you want! The CPU is so fast, it can execute an infinite loop is 6 seconds! -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Latest binutils import breaks Alpha cross compiles
Giorgos Keramidas wrote: This still *is* -CURRENT, right? If it doesn't break, once in a while, how will new things be tested by the -CURRENT userbase? A make world before commit? Is this a trick question? Instead of whining about you broke it, and haven't fixed it it would be a far better thing to contribute patches that fix the brokenness. If you insist, I can contribute patches that will back out the binutils changes. I think this is already in the process of being handled, though; you seem to be catching up on some very old email. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Brian T.Schellenberger wrote: Does someone want to write a registry editor program? Yuch. Why? Clearly, you are not a Junior Annoying Hacker. The point of the program would be to edit the FreeBSD Registry, rc.conf, and make it look just like the Windows Registry in the editor, using _ as the implied path component/terminal component (key) seperator. You are surely insane. Or trying to make a point which isn't true, which is pretty similar. OK, say we view it as read only, except for the editor (note the editor might be vi, so you can't complain 8-)). How is path-to-file + path-to-key-in-file any different than absolute-path-to-key? The only thing that seems different is the implied component seperator at the file/file-content boundary, and the translation of the _ into the file space component seperator, and back. It's all just a matter of represntational geometry for the same information, isn't it? No, there's are enormous differences: - There's a well-known plain-text file so it can be readily backed up and restored. regedit Registry Export Registry File... backupCR regedit Registry Import Registry File... backupCR - There is not a single point of failure for all progams; it only controls basic system functions and services, it does not control applications, so if it fails, your applications aren't all screwed up, and if your applications screw up terribly they can't corrupt your basic system. firewall_enable=NO 8-) 8-). Indeed, the lack of an API to *write* to /etc/rc.conf is one of it's greatest strengths: It is far less vulnerable to major corruption if things go nutty. vi? sed? any text editor? The lack of constraints on how one may interact with the rc.conf is one of its main weaknesses. A single missing quotation mark will result in an inaccessible system, if you don't have console access, and one that must be repaired, if you do. There's not even a virc equivalent to vipw, that can do a consistency check on the file to make sure it's sourceable by a shell script, before permitting the edits to replace the valid contents, and keep a backup of the previous file for you. Alternately, we can just call a spade a spade, and admit that what we have is a flat file registry, which pretends to be hierarchical by using _ as a hierachy delimiter for component seperation. Actually, this is a lot like the Manx subdirectory support in the shell program that came with the developement environment, and used topdir/subdir/finaldir as the name of the directory, and simply hid the names of all but the last component. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Fri, 1 Feb 2002, Terry Lambert wrote: ... : There's not even a virc equivalent to vipw, that can do a : consistency check on the file to make sure it's sourceable by a shell : script, before permitting the edits to replace the valid contents, and : keep a backup of the previous file for you. Out of this entire thread, something I like! This would be a great idea. * Matt Heckaman - mailto:[EMAIL PROTECTED] http://www.lucida.ca/gpg * * GPG fingerprint - 53CA 8320 C8F6 32ED 9DDF 036E 3171 C093 4AD3 1364 * The Universe is run by the complex interweaving of three elements: energy, matter, and enlightened self-interest. -- G'Kar, Survivors To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
Matt Heckaman wrote: On Fri, 1 Feb 2002, Terry Lambert wrote: : There's not even a virc equivalent to vipw, that can do a : consistency check on the file to make sure it's sourceable by a shell : script, before permitting the edits to replace the valid contents, and : keep a backup of the previous file for you. Out of this entire thread, something I like! This would be a great idea. Determining source-ability by sourcing is dangerous. You would need to do a chroot, or run it as a non-priviledged user, for the purposes of testing, and you would not be able to see some side effects, if the file contained code, even then. Also, people use vipw because if you don't, the database doesn't get rebuilt. There's no corresponding force to make them use it for virc. All that aside, I'll admit that it would be better than what's there. But of course, that's more of a Junior Hacker than a Junior Annoying Hacker task, and, really, what we are trying to do here is raise up someone to compete with Albert for number of complaints. 8-) 8-o 8-O }B^). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Login failures ...
On Fri, Feb 01, 2002 at 03:06:17PM -0800, Bokyung Wang wrote: Hello, I faced Login Fail problem when I upgrade to FreeBSD 5.0 Current. Error messages are login: PAM unable to dlopen(/usr/lib/pam_login_access.so) login: PAM[dlerror: Cannot open /usr/lib/pam_login+access.so] login: PAM adding faulty moule: /usr/log/pam_login_access.so Does anybody know how to solve it? I posted a quick solution earlier today/last night on -current, should be easy to find since there hasn't been much traffic since I posted it. if you cvsup and make world it should fix it now. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock reversal in fdalloc()
Bruce Evans wrote: basically it seems to get pissy if it doesn't get the file slot it asks for, so if another thread wins the race here, we'll panic. this problem seems to also exist for 4.x and previous versions of freebsd. I'd like to get this fixed. Any suggestions? I think simply removing the assertion should remove this hazzard, correct? I think if you delayed the allocation, it'd be OK, but I don't see a clean way to do it without a bit of work. Something like that. This was apparently missed when the retry loop was added. Lite2 has the panic but not the retry loop. BTW, the retry loop also picks up changes to the limit on descriptors. In fdalloc(), the corresponding limit is treated as a loop invariant, but it is not invariant. I think the process's rlimit can't change, but maxfilesperproc can change even if the process doesn't block, since it is not protected by FILEDESC_LOCK() :-(. Fortunately, the maxfilesperproc limit isn't very important. I think this is a requirement. The problem is the case where the maxfilesperproc has *not* changed, and some other thread wins the race to the last one, you have to honor that, and fail the current attempt. Retries are fugly. 8-(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock reversal in fdalloc()
* Terry Lambert [EMAIL PROTECTED] [020201 17:02] wrote: Bruce Evans wrote: basically it seems to get pissy if it doesn't get the file slot it asks for, so if another thread wins the race here, we'll panic. this problem seems to also exist for 4.x and previous versions of freebsd. I'd like to get this fixed. Any suggestions? I think simply removing the assertion should remove this hazzard, correct? I think if you delayed the allocation, it'd be OK, but I don't see a clean way to do it without a bit of work. Something like that. This was apparently missed when the retry loop was added. Lite2 has the panic but not the retry loop. BTW, the retry loop also picks up changes to the limit on descriptors. In fdalloc(), the corresponding limit is treated as a loop invariant, but it is not invariant. I think the process's rlimit can't change, but maxfilesperproc can change even if the process doesn't block, since it is not protected by FILEDESC_LOCK() :-(. Fortunately, the maxfilesperproc limit isn't very important. I think this is a requirement. The problem is the case where the maxfilesperproc has *not* changed, and some other thread wins the race to the last one, you have to honor that, and fail the current attempt. Retries are fugly. 8-(. There's a bunch of bogosity in the ordering of allocation of slots in the filedesc versus filling out the struct file and insertion into the list that I need to work out. I should be able to take a swipe at it in a couple of weeks hopefully. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock reversal in fdalloc()
Alfred Perlstein wrote: There's a bunch of bogosity in the ordering of allocation of slots in the filedesc versus filling out the struct file and insertion into the list that I need to work out. I should be able to take a swipe at it in a couple of weeks hopefully. It's very tempting to put an API to it, and make everyone use it the same way, to guarantee consistency. It's also very tempting to hack the crap out of it to seperate file access itself from the system call layer itself, so that file slot allocation is something that is system call layer specific, which would greatly enhance the ability to do kernel level file I/O and other things. AIX has a nice model, here. Doing that would put the API barrier at the system call layer along, which would clean up almost everything that needed to use it. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
On Friday 01 February 2002 08:38 pm, Terry Lambert wrote: Brian T.Schellenberger wrote: - There is not a single point of failure for all progams; it only controls basic system functions and services, it does not control applications, so if it fails, your applications aren't all screwed up, and if your applications screw up terribly they can't corrupt your basic system. firewall_enable=NO I wouldn't think of a firewall as an application program. I can be certain that installing or corrupting or otherwise screwing up my text editor, my image-editing program, by CD-management program, my financial program, my DVD-viewing program, my newsreader, or my browser won't break my firewall. That's the big drawback of the stupid registry idea. Indeed, the lack of an API to *write* to /etc/rc.conf is one of it's greatest strengths: It is far less vulnerable to major corruption if things go nutty. vi? sed? any text editor? Yes, but application programs aren't writing to it. You only write to it when you set down to do it. So vi acts like regedit, except that it's much easier to find things manipulate since you have the same interface to that file that you have to everything else. (For example, Linux maintains kernel options in much this same way, but it's *much* easier to just with an editable (commented) kernel config file; that's a big part of the reason I went back to FreeBSD. The lack of constraints on how one may interact with the rc.conf is one of its main weaknesses. A single missing quotation mark will result in an inaccessible system, if you don't have console access, and one that must be repaired, if you do. There's not even a virc equivalent to vipw, that can do a consistency check on the file to make sure it's sourceable by a shell script, before permitting the edits to replace the valid contents, and keep a backup of the previous file for you. I've never so messed myself up, but I can see where that would be a problem. *This* is a good idea, actually. Alternately, we can just call a spade a spade, and admit that what we have is a flat file registry, which pretends to be hierarchical by using _ as a hierachy delimiter for component seperation. I don't see that at all--the most distinctive characteristic to me of the Microsoft Windows Registry is that it tries to be a *single* place where *all* configuration information--both system and application--is written. If you ask Microsoft I'm pretty sure they'd tell you that's it's prime advantage and I claim that it's prime drawback. Either way, that's what most distinguishes it. Actually, this is a lot like the Manx subdirectory support in the shell program that came with the developement environment, and used topdir/subdir/finaldir as the name of the directory, and simply hid the names of all but the last component. 8-). Building this information into a directory hierarchy sounds clever but gives me nightmares in recalling the startup / daemon control in Linux (using the ATT scheme, I believe)--which sounds like a good idea in theory but I always found was an absolute nightmare in practice. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message -- Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work) Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal) ME -- http://www.babbleon.org http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: *_enable=YES behavior is bogus
In message: p05101415b880b7928804@[128.113.24.47] Garance A Drosihn [EMAIL PROTECTED] writes: : In this discussion, there have been two suggestions as to how : 'firewall_enable=no' should behave. : 1) if the firewall is compiled in the kernel, then =no :means that the firewall is blocking all packets, no :matter what other rules might be lying around. The :machine is completely locked down from network access :(ie, the present behavior). : or 2) no matter how the kernel is compiled, =no means the :machine acts as if there is no firewall installed. Ie, :it accepts all packets. No packets are blocked. The :machine is wide open. : : If the user *expects* 1, but we actually implement 2, then the : machine is wide-open when they did not expect that. My position : is that we can *easily* do something to help that person : immediately realize that they did not get what they expected. : : If the user *expects* 2, but we implemented 1, then the machine : is locked down. If the user is not sitting at the console of : the machine, then there is absolutely nothing which can be done : (from a coding perspective) to help that person out. They must : have a keyboard and monitor on that machine, and they must go : to the machine and login via that console. The rational for #1 being implemented now is that all security features, when specially enabled (which you had to do to compile the kernel with ipfw in it) must fail safely. Safely is defined as being more restrictive than less. #2 is less. That's the whole reason we do this. But I think this is going to be one of those threads that lasts forever and then nothing happens because they end in deadlock. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
firewall_enable
Actually, there's a simple way around this that is failsafe. firewall_enable=YESWhat it deos now =NOWide open =FAILSAFE Defaults to wired down. /etc/defaults/rc.conf firewall_enable=FAILSAFE That way, people that say firewall_enable=NO get what they want, those that say firewall_enable=YES aren't impacted, and those that do nothing get the default firewall behavior that is compiled into the kernel. The default behavior is controlled by kernel options, but genearlly is closed rather than open. A few extra comments in LINT, where people likely cut and paste their ipfw and/or ipfilter lines from anyway, should allow those paying attention to realize the consequences of their actions: # IPFIREWALL enables support for IP firewall construction, in # conjunction with the `ipfw' program. IPFIREWALL_VERBOSE sends # logged packets to the system logger. IPFIREWALL_VERBOSE_LIMIT # limits the number of times a matching entry can be logged. # # WARNING: IPFIREWALL defaults to a policy of deny ip from any to # any and if you do not add other rules during startup to allow # access, YOU WILL LOCK YOURSELF OUT. If you do not setup firewall # rules in /etc/rc.conf (with firewall_enable=YES and # firewall_type=xxx), you must go to the machine and fix it from the # console. # # When setting up a machine for the first time, especially a remote # machine, with a firewall, you are strongly urged to add # IPFIREWALL_DEFAULT_TO_ACCEPT to your kernel and are sure that you're # firewall is properly setup in /etc/rc.conf before removing that # option. Remote machines can be hard to fix remotely if you do not # do this and fail to configure the firewall. # # IPFIREWALL_DEFAULT_TO_ACCEPT causes the default rule (at boot) to # allow everything. Use with care, if a cracker can crash your # firewall machine, they can get to your protected machines. However, # if you are using it as an as-needed filter for specific problems as # they arise, then this may be for you. Changing the default to 'allow' # means that you won't get stuck if the kernel and /sbin/ipfw binary get # out of sync. # options IPFIREWALL #firewall SEE WARNINGS ABOVE options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_FORWARD #enable transparent proxy support options IPFIREWALL_VERBOSE_LIMIT=100#limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT#allow everything by default Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in vfs_syscalls
Alfred Perlstein wrote: I've just committed a fix, please let me know if it works for you. Yes, everything's fine now. Thanks again! :) -- Michael Nottebrock To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: firewall_enable
On Friday 01 February 2002 11:56 pm, M. Warner Losh wrote: Actually, there's a simple way around this that is failsafe. firewall_enable=YES What it deos now =NOWide open =FAILSAFE Defaults to wired down. Before the discussion on -stable degenerated, there were several calls for making this variable tri-state. It definitely seems like the best solution. Now that this is on -current and we have something concrete, maybe it can get committed :) -David To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Annoying Hacker Task
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 1 Feb 2002, Terry Lambert wrote: ... : Determining source-ability by sourcing is dangerous. Well, you said make sure it's sourcable -- not source it :) : You would need to do a chroot, or run it as a non-priviledged user, : for the purposes of testing, and you would not be able to see some side : effects, if the file contained code, even then. Yeah, but we've also got a file edited by root and root alone, why would root be trying to add all kinds of code in it? I think rc.conf will be failing as it is if people add certain code in it, what do we lose? : Also, people use vipw because if you don't, the database doesn't get : rebuilt. There's no corresponding force to make them use it for virc. You can rebuild the database manually *ducks* -- I know what you're saying though, and I've used things similar to vipw for other daemon config files that had no databases simply for the safety of checking syntax. : All that aside, I'll admit that it would be better than what's there. Yep :) : But of course, that's more of a Junior Hacker than a Junior Annoying : Hacker task, and, really, what we are trying to do here is raise up : someone to compete with Albert for number of complaints. 8-) 8-o 8-O : }B^). :) * Matt Heckaman - mailto:[EMAIL PROTECTED] http://www.lucida.ca/gpg * * GPG fingerprint - 46D8 5C3B 5499 1D14 F01C 2ADD D1B9 6165 9E16 F8E4 * The Universe is run by the complex interweaving of three elements: energy, matter, and enlightened self-interest. -- G'Kar, Survivors -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) Comment: http://www.lucida.ca/gpg/ iD8DBQE8W55K0blhZZ4W+OQRAjqLAKCeMIHPY5g6jhxDKCp42PcDJThmzwCgrpUf NXYHCrKEUqX70qyYFdLESq0= =2VH0 -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
