Re: diskless/rc
In message [EMAIL PROTECTED]you write: }make sure the kernel you are booting is the same as the NFS file systems }you are using. they are. danny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: diskless/rc
In message [EMAIL PROTECTED]you write:
}On Thu, Nov 30, 2000 at 05:56:57PM +0200, Danny Braniss wrote:
}
} 1) the cmp -s - BUS ERROR
} 2) cp ${T} /etc/motd- cp: /etc/motd: Bad address
}
} now only 2 is happening - go figure :-)
} it also used to, after it went multiuser, to panic when i did the
} cmp -s ${T} /etc/motd
}
} any insights?
}
}Bad hardware?
ahh, wish it was that easy. i just finished doing a make world on the diskless
and all went ok - i didn't check if the compiled is ok, but many processes/io
later and the diskless is still running ok.
danny
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: make buildworld fails
Dave Hayes wrote: Kent Stewart [EMAIL PROTECTED] writes: Dave Hayes wrote: Cvsup'd sources (tag=RELEASE_4_2_0) from scratch fail: I don't see a tag=RELEASE_4_2_0. There is a tag=RELENG_4_2_0_RELEASE. Could this be your problem. No, I misreported the tag. If I had tried that, there'd probably be no sources. ;) Just making sure :) I did a cvsup build of 3 systems using 4-stable when it showed up as 4.2-release. How did you install 4.2 and did you cvsup src-all. You are dying building the gnu /binutils. Function mkstemps is a function in the Standard C Library libc and is located at /usr/src/contrib/binutils/libiberty/. It is almost like you are missing a ldconfig -R /usr/obj/usr/src/lib/libc or libc doesn't exist because of the install. Kent -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] The opinions expressed above are entirely my own "We should never live in a world where dreams are rarer than money." -Mathhew Brodrick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PXE boot problem.
From: Doug White [EMAIL PROTECTED] Subject: Re: PXE boot problem. Date: Thu, 30 Nov 2000 20:18:26 -0800 (PST) On Thu, 30 Nov 2000, Matt Simerson wrote: Hi Folks, I've been trying hard to get a FreeBSD system booted via PXE with only limited success. Maybe someone can have a look at my configs and shed a little light on this for me. Here's what happens at boot time: Intel UNDI, PXE-2.0 (build 067) Problem #1: broken build. Flash your motherboard/card to the latest, build 082. I have two Intel PRO/100+ Management Adapters with differnet versions of ROM. One is build 67, the other is build 78. Both work fine for me. NFS is configured as follows: matt# more /etc/exports /-alldirs -ro /usr -alldirs -ro /cdrom -alldirs -maproot=root -ro Perhaps, you can add /tftpboot in /etc/exports. Manabu Yokawa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
why doesn't aio use at_exit(9)?
why doesn't aio use at_exit(9) instead of requiring an explicit call in kern_exit.c for aio_rundown? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make buildworld fails
Kent Stewart [EMAIL PROTECTED] writes: I did a cvsup build of 3 systems using 4-stable when it showed up as 4.2-release. How did you install 4.2 and did you cvsup src-all. This is a 3.3-RELEASE system upgrading to 4.2, I did cvsup src-all, You are dying building the gnu /binutils. Function mkstemps is a function in the Standard C Library libc and is located at /usr/src/contrib/binutils/libiberty/. It is almost like you are missing a ldconfig -R /usr/obj/usr/src/lib/libc or libc doesn't exist because of the install. This could very well be. I am following the instructions in UPGRADING under "To update from 3.x to 4.x stable". -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] The opinions expressed above are entirely my own There is no greater calamity for a nation or individual than not finding contentment in one's sufficiency. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_pageout_scan badness
Long ago, it was written here on 25 Oct 2000 by Matt Dillon: :Consider that a file with a huge number of pages outstanding :should probably be stealing pages from its own LRU list, and :not the system, to satisfy new requests. This is particularly :true of files that are demanding resources on a resource-bound :system. :... : Terry Lambert : [EMAIL PROTECTED] This isn't exactly what I was talking about. The issue in regards to the filesystem syncer is that it fsync()'s an entire file. If you have a big file (e.g. a USENET news history file) the filesystem syncer can come along and exclusively lock it for *seconds* while it is fsync()ing it, stalling all activity on the file every 30 seconds. [...] One of the reasons why Yahoo uses MAP_NOSYNC so much (causing the problem that Alfred has been talking about) is because the filesystem syncer is 'broken' in regards to generating unnecessarily long stalls. Personally speaking, I would much rather use MAP_NOSYNC anyway, even with a fixed filesystem syncer. MAP_NOSYNC pages are not restricted by the size of the filesystem buffer cache, so you can have a whole lot more dirty pages in the system then you would normally be able to have. This 'feature' has had the unfortunate side effect of screwing up *THWACK* Yeah, no kidding -- here's what I see it screwing up. First, some background: I've built three news machines, two transit boxen and one reader box, with recent INN k0dez, and 4.2-STABLE of a few days ago (having tested NetBSD, more on that later), and a brief detour into 5-current. The two transit boxes have somewhere on the order of ~400MB memory or less; the amount I've put in the reader box has increased up to a Gig as I try to figure out what's happening. I'm using the MAP_NOSYNC on the history database files on all to try to get the NetBSD performance of not hitting history, and I've made a couple other minor tweaks to use mmap where the INN history code probably should, but doesn't. Everything starts out well, where the history disk is beaten at startup but as time passes, the time taken to do lookups and writes drops down to near-zero levels, and the disk gets quiet. And actually, the transit machines stay that way, while the reader machine gives me problems after some time. What I notice is that the amount of memory used keeps increasing, until it's all used, and the Free amount shown by `top' drops to a meg or so. Cache and Buf get a bit, but most of it is Active. Far more than is accounted for by the processes. Now, what happens on the reader machine is that after some time of the Active memory increasing, it runs out and starts to swap out processes, and the timestamps on the history database files (.index and .hash, this is the md5-based history) get updated, rather than remaining at the time INN is started. Then the rapid history times skyrocket until it takes more than 1/4 of the time. I don't see this on the transit boxen even after days of operation. Now, what happens when I stop INN and everything news-related is that some memory is freed up, but still, there can be, say, 400MB still reported as Active. More when I had a full gig in this machine to try to keep it from swapping, all of which got used... Then, when I reboot the machine, it gives the kernel messages about syncing disks; done, and then suddenly the history drive light goes on and it starts grinding for five minutes or so, before the actual reboot happens. No history activity happens when I shut down INN normally, which should free the MAP_NOSYNC'ed pages and make them available to be written to disk before rebooting, maybe. I'm also running BerkeleyDB for the reader overview on this machine, and I just discovered that I had applied MAP_NOSYNC to an earlier release, but the library linked in had not had this -- I just fixed that and am running that way now (and see a noticeable improvement) so now when I reboot, I may see both the overview database disk and the history disk get some pre-reboot activity, if what I think is happening really is happening. What I think is happening, based on these observations, is that the data from the history hash files (less than 100MB) gets read into memory, but the updates to it are not written over the data to be replaced -- it's simply appended to, up to the limit of the available memory. When this limit is reached on the transit machines, then things stabilize and old pages get recycled (but still, more memory overall is used than the size of the actual file). I'm guessing that additional activity of the reader machine causes jumps in memory usage not seen on the transit machines, that is enough to force some of the unwritten dirty pages to be written to the history file, as a few megs of swap get used, which is why it does not stabilize as `nicely' as
Re: make buildworld fails
Dave Hayes wrote: Kent Stewart [EMAIL PROTECTED] writes: I did a cvsup build of 3 systems using 4-stable when it showed up as 4.2-release. How did you install 4.2 and did you cvsup src-all. This is a 3.3-RELEASE system upgrading to 4.2, I did cvsup src-all, You are dying building the gnu /binutils. Function mkstemps is a function in the Standard C Library libc and is located at /usr/src/contrib/binutils/libiberty/. It is almost like you are missing a ldconfig -R /usr/obj/usr/src/lib/libc or libc doesn't exist because of the install. This could very well be. I am following the instructions in UPGRADING under "To update from 3.x to 4.x stable". The general comment is that you have to be at 3.5 to do that. However, Engelshall had a process that worked for almost every concievable difficulty at 3.5 4.x. There were somethings fixed in the week or so after 4.2 was released and you might consider 4-stable. Some things in Engleshall's procedure are out of date such as mv'ing /MYKERNEL to /kernel but it touches on some of your problems. See http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=51796+57580+/usr/local/www/db/text/2000/freebsd-stable/20001015.freebsd-stable If you have to fight upgrading and making two worlds (3.5 and 4.2-R), a binary upgrade followed by making your world and kernel will be much faster. The 4.x buildworld just about requires 2x as long as a buildworld in 3.x. I use the buildworld sequence from /usr/src/UPDATING almost religiously because I cvsup everytime I do a build. I also like the idea of building everything before I start the installs. In my situation, I found that putting the process into a script would have everything built when I would go back to check on the status. Doing the individual steps typically left me at just the end of the buildworld. Kent -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] The opinions expressed above are entirely my own There is no greater calamity for a nation or individual than not finding contentment in one's sufficiency. -- Kent Stewart Richland, WA mailto:[EMAIL PROTECTED] http://kstewart.urx.com/kstewart/index.html FreeBSD News http://daily.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Strange thing with serial console speed
Hi, I have two machines running -current. One of them is configured for serial console and connected to the second one. On the 2nd one I usually build world and the kernels for the two machines. The I install world and the kernels from /usr/obj of the 2nd machine (exported via nfs). In principal this works just fine Except that I decided yesterday to raise the serial console speed to 115200 by putting the appropriate line into /etc/make.conf. I though, that this definition wouldn't matter for the machine without serial console. So I was really surprised to see, that that machine didn't boot anymore today. What happens is, that it prints the BTX loader version line, the cursor jumps to the upper left corner of the screen and there it stays until i press ctrl-alt-del or hit reset. Rebuilding /usr/src/sys/boot without the speed definition in /etc/make.conf fixes the problem. So, how is the serial console speed tangled to the non-serial console boot??? Is this a bug or a feature? Regards, harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PXE boot problem.
On Nov 30, Matt Simerson wrote: [...] Intel UNDI, PXE-2.0 (build 067) Copyright (c) 1997, 1998 Intel Corporation [...] Get the flash upgrade from intel. Mine reads: Intel(R) Boot Agent Version 4.0.14 and it works well. --Mat -- Mathew Kanner [EMAIL PROTECTED] SOCS McGill University Obtuse quote: He [not me] understands: "This field of perception is void of perception of man." -- The Quintessence of Buddhism To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Per-process kernel stack size
On Thu, 30 Nov 2000, Mike Smith wrote: The routines have a nesting of 10-12 functions having 10-100 lines each. Could you tell us what is the minimum available run time memory in the per-process kernel stack for running these routines? You can generally assume that you have about 4k of kernel stack (you will normally have more, but don't count on it 8). I'm sure this is pretty obvious, and has already occured to most everyone else, but... Wouldn't it be a simple matter to set a global pointer to the stack base (lowest address) when switching context, so that the running code could know exactly how close it is to the limits? Maybe this would not be used in release code, but could be another tool for auditing suspicious code. Even better, maybe the stack could be set on a non-contiguous virtual address so that any overflow would trigger a fault? I would *much* rather have the machine grind to a halt with a relevant message than see mysterious data corruption. Of course, neither of these would be worthwhile once I stop writing code with bugs ;-) All the best, -Richard --- Richard Hodges | Matriplex, inc. title | 769 Basque Way [EMAIL PROTECTED] | Carson City, NV 89706 775-886-6477| www.matriplex.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
bpf and libpcap (freebsd packet capture)
[EMAIL PROTECTED]: I have two questions that concern enhancing the freebsd packet capture. I am looking into doing some source code changes for bpf, libpcap, and the kernel, if necessary, to increase the performance of packet capture for a custom sniffer on a loaded network. Now what I read was increasing the bpf buffer size to 256K rather than the default 32K. Can we increase this more? Can you please help me or rather point me in the right direction. Question 1: It I want to increase the buffer size of the bpf which #define would I have to change? I found a few BUF variables. The reason is that I want to sniff on a loaded 100Mbs network without dropping any packets. I found these variables: bpf.c:#define BPF_BUFSIZE (MCLBYTES-8) bpf.c:#define BPF_BUFSIZE 4096 bpf.h:#define BPF_MAXBUFSIZE 0x8000 bpf.h:#define BPF_MINBUFSIZE 32 My guess is that it is the #define BPF_MINBUFSIZE 32 because I read that the default buffer is 32K and I want to change it to 256K. Is this the right variable to change? or do I have to change code of libpcap files: pcap-enet.c:#define BUFSPACE (4*1024) pcap-nit.c:#define BUFSPACE (4*CHUNKSIZE) pcap-pf.c:#define BUFSPACE (200 * 256) pcap-snit.c:#define BUFSPACE (4*CHUNKSIZE) pcap.h:#define PCAP_ERRBUF_SIZE 256 Question 2: It seems after my testing if you insert a very large bpf filter rule to the bpf device, it breaks. My testing involved filtering in a few services/ports and external traffic to and from about 20 different ips and to exclude any internal traffic of the 20, which I can't subnet because they are not grouped together. The filter rule grows extreming large, which I thinks overruns the stack or address space for bpf. Is there any default variable that can increase the actucal filter rule or filter rule buffer? My collegue, hack the number of instructions that is passed to pcap, but it still breaks it. Can you point me where to look in order to increase the filter rule. Thanks, Carlos R. Garcia To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_pageout_scan badness
: Personally speaking, I would much rather use MAP_NOSYNC anyway, even with : a fixed filesystem syncer. MAP_NOSYNC pages are not restricted by :... : :Yeah, no kidding -- here's what I see it screwing up. First, some :background: : :I've built three news machines, two transit boxen and one reader box, :with recent INN k0dez, and 4.2-STABLE of a few days ago (having tested :NetBSD, more on that later), and a brief detour into 5-current. :.. : :Everything starts out well, where the history disk is beaten at startup :but as time passes, the time taken to do lookups and writes drops down :to near-zero levels, and the disk gets quiet. And actually, the transit :... : :What I notice is that the amount of memory used keeps increasing, until :it's all used, and the Free amount shown by `top' drops to a meg or so. :Cache and Buf get a bit, but most of it is Active. Far more than is :accounted for by the processes. This is to be expected, because the dirty MAP_NOSYNC pages will not be written out until they are forced out, or by msync(). :Now, what happens on the reader machine is that after some time of the :Active memory increasing, it runs out and starts to swap out processes, :and the timestamps on the history database files (.index and .hash, this :is the md5-based history) get updated, rather than remaining at the :time INN is started. Then the rapid history times skyrocket until it :takes more than 1/4 of the time. I don't see this on the transit boxen :even after days of operation. Hmm. That doesn't sound right. Free memory should drop to near zero, but then what should happen is the pageout daemon should come along and deactivate a big chunk of the 'active' pages... so you should see a situation where you have, say, 200MB worth of active pages and 200MB worth of inactive pages. After that the pageout daemon should start paging out the inactive pages and increasing the 'cache'. The number of 'free' pages will always be near zero, which is to be expected. But it should not be swapping out any process. The actual amount of 'free' memory in the system is actually 'free+cache' pages. :Now, what happens when I stop INN and everything news-related is that :some memory is freed up, but still, there can be, say, 400MB still :reported as Active. More when I had a full gig in this machine to :... : :Then, when I reboot the machine, it gives the kernel messages about :syncing disks; done, and then suddenly the history drive light goes :on and it starts grinding for five minutes or so, before the actual :reboot happens. Right. This is to be expected. You have a lot of dirty pages in the system due to the use of MAP_NOSYNC that have to be flushed out. :No history activity happens when I shut down INN normally, which should :free the MAP_NOSYNC'ed pages and make them available to be written to :disk before rebooting, maybe. MAP_NOSYNC pages are not flushed when the referencing program exits. They stick around until they are forced out. You can flush them manually by using a mmap()/msync() combination. i.e. an msync() prior to munmap()ing (from INND only) ought to do it. :What I think is happening, based on these observations, is that the :data from the history hash files (less than 100MB) gets read into :memory, but the updates to it are not written over the data to be :replaced -- it's simply appended to, up to the limit of the available :memory. When this limit is reached on the transit machines, then :things stabilize and old pages get recycled (but still, more memory :overall is used than the size of the actual file). It doesn't append... the pages are reused. The set of 'active' pages in the VM system is effectively the set of all files accessed for the entire system, not just MAP_NOSYNC pages. If you are only MAP_NOSYNC'ing 100MB worth of pages, then only 100MB worth of pages will be left unflushed. Is it possible that history file rewriting is creating an issue? Doesn't INN rewrite the history file every once in a while to clear out old garbage? I'm not up on the latest INN. :I'm guessing that additional activity of the reader machine causes :jumps in memory usage not seen on the transit machines, that is enough :to force some of the unwritten dirty pages to be written to the :history file, as a few megs of swap get used, which is why it does :not stabilize as `nicely' as the transit machines. This makes sense... the amount of swap that gets used is critical. If we are talking about only a few megabytes, then your system is *not* swapping significantly, it is simply swapping out completely idle pages from things like idle getty's and such. This is a good thing. The disk activity would thus be mostly due to MAP_NOSYNC pages being written out. :Now, something I contemplated -- it seems that Bad Undesirable Things :happen as soon as I start
natd bug
Hi there! I was just looking why my natd doesnt work, when I discovered the following bug (?): I compiled my kernel with IPDIVERT IPFIREWALL and IPFIREWALL_DEFAULT_TO_ACCEPT and I set up only one rule: ipfw add divert natd all from any to any via isp0 Then I started natd (at boot time): natd -unregistered_only -dynamic -n isp0 But when a package arrives (doesn't matter from localhost or another host), natd gives out a kernel message: Nov 30 15:03:06 server natd[195]: failed to write packet back (Permission denied) What does that mean? I started natd from my rc.local, so it runs as root and it should have all permissions. Thanks in advance! Best Regards, Freddy -- Geek Code 3.1: GCS s+: a--- C+++ UBOU+++ P-- E--- W++ N w--- V++ PGP- t? 5? tv = Frederik Meerwaldt ICQ: 83045387 Homepage: http://www.freddym.org Bavaria/Germany OpenVMS and Unix Howtos and much more FreeBSD, NetBSD, OpenBSD, Tru64, OpenVMS, Ultrix, BeOS, Linux To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: natd bug
Hi, What are your firewall settings? Most likely, it's denying natd packets to pass, you need a special rule for that, like: # ipfw add divert natd all from any to any via isp0 That'll do the trick. --Rink - Original Message - From: "Frederik Meerwaldt" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 30, 2000 8:25 PM Subject: natd bug Hi there! I was just looking why my natd doesnt work, when I discovered the following bug (?): I compiled my kernel with IPDIVERT IPFIREWALL and IPFIREWALL_DEFAULT_TO_ACCEPT and I set up only one rule: ipfw add divert natd all from any to any via isp0 Then I started natd (at boot time): natd -unregistered_only -dynamic -n isp0 But when a package arrives (doesn't matter from localhost or another host), natd gives out a kernel message: Nov 30 15:03:06 server natd[195]: failed to write packet back (Permission denied) What does that mean? I started natd from my rc.local, so it runs as root and it should have all permissions. Thanks in advance! Best Regards, Freddy -- Geek Code 3.1: GCS s+: a--- C+++ UBOU+++ P-- E--- W++ N w--- V++ PGP- t? 5? tv = Frederik Meerwaldt ICQ: 83045387 Homepage: http://www.freddym.org Bavaria/Germany OpenVMS and Unix Howtos and much more FreeBSD, NetBSD, OpenBSD, Tru64, OpenVMS, Ultrix, BeOS, Linux To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: natd bug
Hi! # ipfw add divert natd all from any to any via isp0 I have exactly this line in my config (see my original posting) Best Regards, Freddy -- Geek Code 3.1: GCS s+: a--- C+++ UBOU+++ P-- E--- W++ N w--- V++ PGP- t? 5? tv = Frederik Meerwaldt ICQ: 83045387 Homepage: http://www.freddym.org Bavaria/Germany OpenVMS and Unix Howtos and much more FreeBSD, NetBSD, OpenBSD, Tru64, OpenVMS, Ultrix, BeOS, Linux To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: natd bug
On Thu, Nov 30, 2000 at 08:25:15PM +0100, Frederik Meerwaldt wrote: I compiled my kernel with IPDIVERT IPFIREWALL and IPFIREWALL_DEFAULT_TO_ACCEPT and I set up only one rule: ipfw add divert natd all from any to any via isp0 Then I started natd (at boot time): natd -unregistered_only -dynamic -n isp0 But when a package arrives (doesn't matter from localhost or another host), natd gives out a kernel message: Nov 30 15:03:06 server natd[195]: failed to write packet back (Permission denied) Is your link up at that time? The usual setup for a sppp device using dynamic ip's is an invalid ip (0.0.0.0) that is changed once an ip was assigned. So, if you are not dialled in, the invalid ip will be put in by natd, and that usually causes this error message. - Thomas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: PXE boot problem. - SOLVED
That was it. Updating the flash on the Intel NIC and she booted right up. Thanks, Matt -Original Message- From: Mathew KANNER [mailto:[EMAIL PROTECTED]] Sent: Friday, December 01, 2000 8:54 AM To: Matt Simerson Cc: '[EMAIL PROTECTED]' Subject: Re: PXE boot problem. On Nov 30, Matt Simerson wrote: [...] Intel UNDI, PXE-2.0 (build 067) Copyright (c) 1997, 1998 Intel Corporation [...] Get the flash upgrade from intel. Mine reads: Intel(R) Boot Agent Version 4.0.14 and it works well. --Mat -- Mathew Kanner [EMAIL PROTECTED] SOCS McGill University Obtuse quote: He [not me] understands: "This field of perception is void of perception of man." -- The Quintessence of Buddhism To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why doesn't aio use at_exit(9)?
On Fri, Dec 01, 2000 at 02:02:58AM -0800, Alfred Perlstein wrote: why doesn't aio use at_exit(9) instead of requiring an explicit call in kern_exit.c for aio_rundown? There's no reason that I'm aware of. Unless you're in a hurry, I'll add that change to a cleanup patch that I have in the pipe. Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why doesn't aio use at_exit(9)?
* Alan Cox [EMAIL PROTECTED] [001201 11:56] wrote: On Fri, Dec 01, 2000 at 02:02:58AM -0800, Alfred Perlstein wrote: why doesn't aio use at_exit(9) instead of requiring an explicit call in kern_exit.c for aio_rundown? There's no reason that I'm aware of. Unless you're in a hurry, I'll add that change to a cleanup patch that I have in the pipe. Er, how much of a cleanup do you have? The only work I've done so far is to remove all the #ifdef VFS_AIO's in the file, if you could commit your cleanup soon it would help. :) thanks, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why doesn't aio use at_exit(9)?
On Fri, Dec 01, 2000 at 12:08:48PM -0800, Alfred Perlstein wrote: * Alan Cox [EMAIL PROTECTED] [001201 11:56] wrote: On Fri, Dec 01, 2000 at 02:02:58AM -0800, Alfred Perlstein wrote: why doesn't aio use at_exit(9) instead of requiring an explicit call in kern_exit.c for aio_rundown? There's no reason that I'm aware of. Unless you're in a hurry, I'll add that change to a cleanup patch that I have in the pipe. Er, how much of a cleanup do you have? The only work I've done so far is to remove all the #ifdef VFS_AIO's in the file, if you could commit your cleanup soon it would help. :) If you're already working on converting aio to use at_exit, go ahead. It won't interfere with my work. Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: why doesn't aio use at_exit(9)?
* Alan Cox [EMAIL PROTECTED] [001201 12:21] wrote: On Fri, Dec 01, 2000 at 12:08:48PM -0800, Alfred Perlstein wrote: * Alan Cox [EMAIL PROTECTED] [001201 11:56] wrote: On Fri, Dec 01, 2000 at 02:02:58AM -0800, Alfred Perlstein wrote: why doesn't aio use at_exit(9) instead of requiring an explicit call in kern_exit.c for aio_rundown? There's no reason that I'm aware of. Unless you're in a hurry, I'll add that change to a cleanup patch that I have in the pipe. Er, how much of a cleanup do you have? The only work I've done so far is to remove all the #ifdef VFS_AIO's in the file, if you could commit your cleanup soon it would help. :) If you're already working on converting aio to use at_exit, go ahead. It won't interfere with my work. I plan to make it a kld module, like i just did with sysvipc. Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PCIOCGETCONF/PCIOCREAD requires write permission?
[Observed on 4.2-STABLE, but I've redirected replies to the hackers list.] 'pciconf -l' is documented to work for non-priv users, however the first thing the underlying ioctl code (pci_ioctl) does is bail with EPERM if the caller does not have /dev/pci open for write. Is there any reason why the FWRITE test cannot/should not be moved down into the 'case PCIOCWRITE' part of the switch? This would make both PCIOCGETCONF and PCIOCREAD work for readonly access to /dev/pci (which seems to me to be saner behaviour). --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
thr_sleep() and thr_wakeup()
Can we kill these syscalls? They are not used anywhere in the kernel and although they have wrapper functions in libc, no header contains prototypes for these wrappers. According to the CVS log they were originally brought in for POSIX threads and AIO, neither of which use this facility. Comments? -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
unsubscribe
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
On Fri, Dec 01, 2000 at 13:56:13 -0700, Lyndon Nerenberg wrote: [Observed on 4.2-STABLE, but I've redirected replies to the hackers list.] 'pciconf -l' is documented to work for non-priv users, however the first thing the underlying ioctl code (pci_ioctl) does is bail with EPERM if the caller does not have /dev/pci open for write. The documentation is wrong, unfortunately. Is there any reason why the FWRITE test cannot/should not be moved down into the 'case PCIOCWRITE' part of the switch? This would make both PCIOCGETCONF and PCIOCREAD work for readonly access to /dev/pci (which seems to me to be saner behaviour). At least with the PCIOCGETCONF, you need write permission, because it copies in patterns to match against. As for PCIOCREAD, it only allows reading of PCI registers, so the question there is whether there are any potential security implications to allowing non-root users to read PCI registers. If reading configuration registers caused performance degredation, for instance. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: thr_sleep() and thr_wakeup()
Can we kill these syscalls? They are not used anywhere in the kernel and although they have wrapper functions in libc, no header contains prototypes for these wrappers. According to the CVS log they were originally brought in for POSIX threads and AIO, neither of which use this facility. Comments? Seconded. I see no reason for keeping these. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: thr_sleep() and thr_wakeup()
On Friday, December 01, 2000, John Baldwin wrote: Can we kill these syscalls? They are not used anywhere in the kernel and although they have wrapper functions in libc, no header contains prototypes for these wrappers. According to the CVS log they were originally brought in for POSIX threads and AIO, neither of which use this facility. Comments? Agreed. Also, this is UNIX International thread namespace (thr_*). -- |Chris Costello [EMAIL PROTECTED] |Your e-mail has been returned due to insufficient voltage. `-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: thr_sleep() and thr_wakeup()
On Friday, December 01, 2000, John Baldwin wrote: Can we kill these syscalls? They are not used anywhere in the kernel and although they have wrapper functions in libc, no header contains prototypes for these wrappers. According to the CVS log they were originally brought in for POSIX threads and AIO, neither of which use this facility. Comments? Agreed. Also, this is UNIX International thread namespace (thr_*). Interesting. Ok, if these system calls are going to be removed the whole file may as well be removed, since then it would just have yield in it. John and I agree that kern_synch.c is probably as good a place as any for yield, but there may be a better place. Thoughts? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm_pageout_scan badness
: Personally speaking, I would much rather use MAP_NOSYNC anyway, even with :... :Everything starts out well, where the history disk is beaten at startup :but as time passes, the time taken to do lookups and writes drops down :to near-zero levels, and the disk gets quiet. And actually, the transit :... :What I notice is that the amount of memory used keeps increasing, until :it's all used, and the Free amount shown by `top' drops to a meg or so. :Cache and Buf get a bit, but most of it is Active. Far more than is :accounted for by the processes. This is to be expected, because the dirty MAP_NOSYNC pages will not be written out until they are forced out, or by msync(). I just discovered the user command `fsync' which has revealed a few things to me, clearing up some mysteries. Also, I've watched more closely the pattern of what happens to the available memory following a fresh boot... At the moment, this (reader) machine has been up for half a day, with performance barely able to keep up with a full feed (but starting to slip as the overnight burst of binaries is starting), but at last look, history lookups and writes are accounting for more than half (!) of the INN news process time, with available idle time being essentially zero. So... :Now, what happens on the reader machine is that after some time of the :Active memory increasing, it runs out and starts to swap out processes, :and the timestamps on the history database files (.index and .hash, this :is the md5-based history) get updated, rather than remaining at the :time INN is started. Then the rapid history times skyrocket until it :takes more than 1/4 of the time. I don't see this on the transit boxen :even after days of operation. Hmm. That doesn't sound right. Free memory should drop to near zero, but then what should happen is the pageout daemon should come along and deactivate a big chunk of the 'active' pages... so you should see a situation where you have, say, 200MB worth of active pages and 200MB worth of inactive pages. After that the pageout daemon should start paging out the inactive pages and increasing the 'cache'. The number of 'free' pages will always be near zero, which is to be expected. But it should not be swapping out any process. Here is what I noticed while watching the `top' values for Active, Inactive, and Free following this last boot (I didn't pay any attention to the other fields to notice any wild fluctuations there, next time maybe), on this machine with 512MB of RAM, if it reveals anything: Following the boot, things start out with plenty of memory Free, and something like 4MB Active, which seems reasonable to me. Then I start things. As is to be expected, INN increases in size as it does history lookups and updates, and the amount of memory shown as Active tracks this, more or less. But what's happening to the Free value! It's going down at as much as 4MB per `top' interval. Or should I say, what is happening to the Inactive value -- it's constantly increasing, and I observe a rapid migration of all the Free memory to Inactive, until the value of Inactive peaks out at the time that Free drops to about 996k, beyond which it changes little. None of the swap space has been touched yet. As soon as the value for Free hits bottom and that of Inactive has reached a max, now the migration happens from Inactive to Active -- until this point, the value of Active has been roughly what I would expect to see, given the size of the history hash/index files, and the BerkeleyDB file I'm now using MAP_NOSYNC as well for a definite improvement in overview access times. Anyway, I don't remember what values exactly I was seeing for Free and Inactive or Active, since I was just watching for general trends, but I seem to recall Active being ~100MB, and Inactive somewhat more. (Are you saying above that this Inactive value should be migrating to Cache, which I'm not seeing, rather than to Active, which I do see? If so, then hmmm.) Now memory is drifting at a fairly rapid pace from Inactive (the meaning of which I'm not exactly clear about, although there's some explanation in the `top' man page that hasn't quite clicked into understanding yet), over to the Active field, at something like 2MB or so per `top' interval. Free remains close to 1MB, but Active is constantly growing, although no processes are clearly taking up any of this, apart from INN which only accounts for around 100MB at this time, and isn't increasing at the rate of increase of Active memory. Anyway, the Active field continues to increase as Inactive decreases until finally Inactive bottoms out, down from several hundred MB to a one or two digit MB value (I don't remember exactly), while Active has increased to almost 400MB. This is something like 20 minutes after the reboot, and now the first bit of swap gets hit. However, the value of Active has hit its peak and
unsubscribe
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
