Re: Dirty pages & low memory hangs with mmap
Stephen Hocking-Senior Programmer PGS Tensor Perth once wrote: > I've been seeing an interesting problem when doing a make installworld > on a 486 with 16MB of memory. Immediately after installing libc.so.3, > it will hang. Happened to me here today on Pentium 90 with 64Mb of RAM. It was installing world (with -j 3) from nfs mounted /usr/obj and /usr/src (mounted ro). It did not hang but rebooted (no backtraces, the kernel is built with -fomit-frame-pointer). I restarted the installworld and it completed fine, I guess, it did not have to reinstall libc.so.3 the second time, because of ``install -C''. This was not current either -- going from a 2 weeks old -stable to the most recent -stable. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Dirty pages & low memory hangs with mmap
I've been seeing an interesting problem when doing a make installworld on a 486 with 16MB of memory. Immediately after installing libc.so.3, it will hang. DDB gives a backtrace to a mmap related call (sorry, the box is at home at the memoment and this email was prompted by something on freebsd-current). It's quite reproducible, but worked around by issuing a bunch of syncs every second. Outside of that, the box runs fine (it's my ppp NAT gateway, runs squid & nntpcached as well). Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Break of today current and patch
On Thu, 8 Jul 1999, David O'Brien wrote: > > todays current breaks in build of libgcc > > Since libgcc/Makefile hasn't been touched since April, me thinks > something else is going on in your environment. > > > ===> gnu/lib/libgcc > > c++ -O2 -mpentium -fpcc-struct-return -ffast-math -fno-strength-reduce > ... You don't have CXXFLAGS set in your environment, do you? That will break several of the things under gnu/ Kris - "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
MTRR stuff
For some video cards (to wit, the voodoo stuff), the MTRRs should be set up as follows write-combining +--+ +---+ uncacheable i.e. the two regions have the same starting area, but the small chunk for the registers should be uncacheable. When I try to do this using memconf on my K6-2, it spits the dummy. Is there a work around for this? Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Known MMAP() race conditions ... ?
I wish to make one thing perfectly clear here, or, rather, a couple of
things. None of this thread was started as a 'slam session' against
*anyone* out there...
To those that have responded privately that "they are experiencing the
problem too", without a better way of saying it...that helps absolutely
noone. If you are experiencing the same problem, voice it to the list.
Right now, there are only a few of us that I know of, and, compared to the
"grand scheme of things", that isn't even a pebble on a beach.
Personally, I'm at a disadvantage to debug this, as my baby is 2.5k
kilometers away from me :( She's on a serial console, through a
portmaster, that doesn't appear to have any way of allow me to break into
DDB...but, even so, I'm spending as much time as possible following
directions from those that appear to want to do more then just tell me to
run Linux for an INN server *sigh*
A few weeks ago, one admin posted a quick C program that, if you ran and
ctl-c'd from it several times, would cause the machine to hang...can
someone resend that out? I'll use it on my machine at home to test
4.0-CURRENT, and I have a machine at the offiec running 3.2-STABLE to test
on...
On Thu, 8 Jul 1999, Doug wrote:
> On Thu, 8 Jul 1999, The Hermit Hacker wrote:
>
> > right now, at work, I'm enjoying a 4 way battle. Me, fighting to bring in
> > FreeBSD to replace some of our Solaris boxes. A friend of mine, fighting
> > to bring in Linux to replace some of our Solaris boxes. My boss fighting
> > against both of us to keep Solaris "because its what we've always used".
>
> If it makes you feel any better, I'm in exactly the same position
> and losing my battle because of NFS and SMP issues. We just got two more
> intel boxes to work with on this project, one is already set up for linux
> (making a total of two), when I asked my boss about the other one he said
> he's not sure yet what he wants to do with it.
>
> There was a similar thread to this one instigated by me a few
> weeks ago. I got the same, "well run stuff that runs good on freebsd
> instead" response. My problem is that my project parameters are set by my
> boss (and reality) and require smp and nfs that work at least as well as
> linux'. They don't, so I'm losing my battle.
>
> Doug (who has to go ktrace amd again because it just fell over while my
> boss was testing it)
> --
> On account of being a democracy and run by the people, we are the only
> nation in the world that has to keep a government four years, no matter
> what it does.
> -- Will Rogers
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: question regarding CMD640 chipsets
On Thu, 8 Jul 1999, Bruce Evans wrote: > Rev.1.31 of ide_pci.c put the call in a dubious place (after some early > return statements) in ide_pci_attach(). Try putting it at the beginning > of the function (after `type' is initialized). hmmm if i had looked the code above that switch()... i probably wouldn't have had to ask... thanks much > Bruce Blackbox - An X11R6 Window Manager http://blackbox.wiw.org/ __ Bradley T. Hughes <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current kernel build temporarily broken
:> it will crunch) at the moment. :> :> -Matt : :Is there anything I can do? : :Cheers, :-Peter (CC'ing to current) Kirk committed the fix -- The sense of a KASSERT() had gotten reversed accidently. Everything is hunky dory - except for the fact that I'm not able to commit any of these things myself. The patches remaining in the current VFS/BIO set are relatively minor, which means I can shift my attention over to the VM/INN/MMAP problems. The INN problem is a stickier issue and the solution may wind up making -current slightly less efficient in the near term. Basically what we have to do is to map writeable pages read-only and then take a fault to detect the clean->dirty transition. We can then synchronously block in vm_fault (without holding any locks, I might add) when there are too many dirty pages in the system. The pageout daemon will be able to run earlier (before it becomes too late). Also, on the positive side, by accounting dirty pages earlier we can manage low-memory situations all that more easily, which means that we can shift the clustering code from the beginning (when queued) to the end (when I/O is physically initiated). This will have the side effect of removing a whole cartload of junk from the filesystem critical path as well as remove a bunch of fields from the vnode structure. It will also greatly reduce the amount of memory-related blocking that occurs deep within a call-stack which should help performance on loaded machines by reducing lock contention. So if people don't scream at me for the slightly less efficient page faulting I think we can make progress. Actually, I don't think the page faulting will be as bad as all that... the loss of efficiency occurs mostly in shared R+W mmaps, not so much with BSS extensions because those tend to take a fault anyway because they start out as zero-fill. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Known MMAP() race conditions ... ?
On Thu, 8 Jul 1999, The Hermit Hacker wrote: > right now, at work, I'm enjoying a 4 way battle. Me, fighting to bring in > FreeBSD to replace some of our Solaris boxes. A friend of mine, fighting > to bring in Linux to replace some of our Solaris boxes. My boss fighting > against both of us to keep Solaris "because its what we've always used". If it makes you feel any better, I'm in exactly the same position and losing my battle because of NFS and SMP issues. We just got two more intel boxes to work with on this project, one is already set up for linux (making a total of two), when I asked my boss about the other one he said he's not sure yet what he wants to do with it. There was a similar thread to this one instigated by me a few weeks ago. I got the same, "well run stuff that runs good on freebsd instead" response. My problem is that my project parameters are set by my boss (and reality) and require smp and nfs that work at least as well as linux'. They don't, so I'm losing my battle. Doug (who has to go ktrace amd again because it just fell over while my boss was testing it) -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Stuck in "objtrm" - live kernel test to run
Ok, I've traced the code down and I think that there is a good chance that the OBJ_DEAD fix that Alan described may solve the problem. What I think is happening is that a process context is holding a PIP count on the object, then deallocating the object and creating an interlock situation. There is a way we can find out for sure. For any of you with processes stuck in objtrm, see if you can gdb the kernel and get a backtrace of that process to see if it might be in a state where a previous call context is holding a PIP count on the object. gdb -k /kernel /dev/mem ^^ works better if this is a debug kernel but it doesn't have to be. It does have to be the kernel that is currently running. proc (e.g. proc 222) gdb's default radix is 10, but sometimes people change it to 16 so if it complains, you may be typing the number in in the wrong radix. back Note: the process cannot be swapped out, so if you've had a process stuck in objtrm for a long time try doing as "ps axfl" to force it's upages in and then gdb should be able to backtrace it. The 'f' in the ps does that. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
current kernel build temporarily broken
Just to head off complaints - we accidently made an incomplete commit last night updating some vfs/bio stuff. I have an email in to Kirk with the pieces that we forgot. CURRENT will not build (or if it does, it will crunch) at the moment. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
Somebody should study the abilities of the on-cpu APIC for this for pentium ff. machines. In message <[EMAIL PROTECTED]>, Bruce Evans writes: >>dfr> If I understand this correctly, you are suggesting that we program timer0 >>dfr> so that we only take interrupts when a finetimer is due to fire? If so, >>dfr> then it sounds very good. The idea of taking 6000+ interrupts/sec made me >>dfr> uneasy, even though most would return without doing any work. > >6000+ interrupts/sec is not many, unless it is done all the time. A >486/33 can handle about 5 (16000 for pcaudio + 3 * 11520 for sio's). > >>There is one problem in this method. acquire_timer0() is only implemented >>for i386. We would need to write something equivalent for alpha... > >This is a serious problem. acquire_timer0() is currently disabled even >for i386's when the i8254 is used for timecounting. This is not hard >to fix (the hooks into clkintr() work even better with timecounters >since it is not necessary to resynchronise clock interrupts after a >state change), but an i8254 interrupt frequency of 16000 Hz is too fast >to be used routinely if the i8254 is being used for timecounting (even >if the CPU can keep up with the interrupts, the overflow heuristics in >i8254_get_timecount() may break down). Other systems may have even >more limitations on the timecounters. > >Bruce > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer)
>dfr> If I understand this correctly, you are suggesting that we program timer0 >dfr> so that we only take interrupts when a finetimer is due to fire? If so, >dfr> then it sounds very good. The idea of taking 6000+ interrupts/sec made me >dfr> uneasy, even though most would return without doing any work. 6000+ interrupts/sec is not many, unless it is done all the time. A 486/33 can handle about 5 (16000 for pcaudio + 3 * 11520 for sio's). >There is one problem in this method. acquire_timer0() is only implemented >for i386. We would need to write something equivalent for alpha... This is a serious problem. acquire_timer0() is currently disabled even for i386's when the i8254 is used for timecounting. This is not hard to fix (the hooks into clkintr() work even better with timecounters since it is not necessary to resynchronise clock interrupts after a state change), but an i8254 interrupt frequency of 16000 Hz is too fast to be used routinely if the i8254 is being used for timecounting (even if the CPU can keep up with the interrupts, the overflow heuristics in i8254_get_timecount() may break down). Other systems may have even more limitations on the timecounters. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Known MMAP() race conditions ... ?
:At that time, Matt pop'd up and stated that he knew of *at least* 6 MMAP() :related race conditions that he was hoping to be able to get fixed "within :a week"...that would have been two weeks ago. I think I was talking about mmap w/ NFS. Under FreeBSD-current I know of two problems ( though I could be forgetting some ) - there is a problem when a lot of pages get dirtied that can cause a low-memory deadlock to occur, and I believe there is a problem when mlock() or madvise() is used though I haven't reproduced it yet. Under FreeBSD-stable there are a number of additional, but minor problems related to visibility of non-zero garbage after file EOF in an mmap(), but these would have no effect on INN. What we need to know is why the machines are locking up. The usual way to figure this out is to compile the kernel up with DDB and then when it locks up ctl-alt-esc on the console to get the DDB prompt, and do a 'ps' to see what the procsses are blocked in. If the problem is the dirty-page problem, there are ways around it (basically by syncing more often). -Matt Matthew Dillon <[EMAIL PROTECTED]> :Thanks... : :Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy :Systems Administrator @ hub.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Known MMAP() race conditions ... ?
On Thu, Jul 08, 1999 at 10:18:35AM -0300, The Hermit Hacker wrote: > The newest INN does not have this option, MMAP() is a requirement for > it... Sorry, I didn't know that. Too bad, then. > ah, okay, so you are saying that FreeBSD shouldn't be demonstrated using > software that taxes/tweaks bugs in it? Exactly. If you want to show the strengths of a system, it just doesn't make sense to rely on its weaker parts. > Boy, does that sound like a quick > road to problems... Management: but, when you sold us on this operating > system, it was perfectly stable. Me: ya, well, I picked and choose the > software I ran for the demo, sorry... I didn't say you have to lie about your choice. > Right now, my 'fight' is weak, since all my friend has to do is point out > that 'the MMAP() issue isn't an issue under Linux'...and, as far as I'm Linux has other -- IMHO more annoying -- issues, so I think your friend had better stop bragging. > My opinion on the Linux vs *BSD issue is, and always has been, that *BSD > makes the better *server*...we have very strong networking code, a very > stable kernel and a sane development model...but this MMAP() issue really > hurts :( I think everyone agrees. Now, the problem is that it's not an easy thing to fix, or it would already be fixed. -- Pierre Beyssac [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: userland ppp - startup
>From the keyboard of Boris Staeblow: > >> Why is rc.conf readable by world?! > > > >Why not? > > What about that: > > spppconfig_isp0="authproto=chap myauthname=foo myauthsecret='top secret' > hisauthname=some-gw hisauthsecret='another secret'" I'm not quite satisfied with the way the passwords are configured with spppcontrol. Not to talk about writing those passwords into rc.conf. At that time (and even now) Joerg and i put that into rc.conf, it was (and is) much better to have this in rc.conf than having nothing at all. A way might be to have those passwords (md5 ?) encrypted in a file, which is then handed via spppcontrol into the kernel and are decrypted and used only for the time they are actually needed ? Of course, i currently do not even have the time to think about how to implement this ... hellmuth -- Hellmuth MichaelisTel +49 40 559747-70 HCS Hanseatischer Computerservice GmbHFax +49 40 559747-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de 22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: question regarding CMD640 chipsets
>upon booting -current (from 7/6/99) i noticed that the kernel didn't report >that the work around was enabled... so i began searching through the code >looking for where the workaround actually was... i found it in >src/sys/i386/isa/wd.c (line 282), but the wdc_pci() function only sets >static int eide_quirks wd.c... looking into src/sys/pci/ide_pci.c in >wdattach() i can see a case statement (line 1457) where wdc_pci is supposed >to be called... but it never gets called (verified by putting a printf into >wdc_pci and recompiling/installing/booting kernel) Rev.1.31 of ide_pci.c put the call in a dubious place (after some early return statements) in ide_pci_attach(). Try putting it at the beginning of the function (after `type' is initialized). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Break of today current and patch
> todays current breaks in build of libgcc Since libgcc/Makefile hasn't been touched since April, me thinks something else is going on in your environment. > ===> gnu/lib/libgcc > c++ -O2 -mpentium -fpcc-struct-return -ffast-math -fno-strength-reduce ... What does adding "-v" to your CLFAGS in /etc/make.conf show? -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunderNew Midi Driver Framework with a Fine Timer)
On Thu, 8 Jul 1999 11:00:24 +0100 (BST), Doug Rabson <[EMAIL PROTECTED]> said: >> There is one problem in this method. acquire_timer0() is only implemented >> for i386. We would need to write something equivalent for alpha... dfr> The timer hardware on the alpha is essentially the same but the interrupts dfr> are wired up differently. I'm not sure how hard it would be to get timer0 dfr> working but I think it should be possible. I see. Then I can work on i386 first, and later on alpha. dfr> The alphas tend to run the main clock quite fast (typically 1024hz) so the dfr> granularity of timing is better but probably not good enough for midi or dfr> pca. I agree. Seigo Tanimura <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
