Re: Lots of kernel core dumps
On Mon, Mar 24, 2003 at 08:18:43PM +0100, Daniela wrote: >Well, it's just a home server. I don't mind a few crashes, but security is >important for me. What do you think, should I go back to -stable? If you're willing to put up with a few crashes _and_ assist with debugging the crashes (eg trying patches) then running -CURRENT would help the Project. One option you could try is to stick with -CURRENT for a month or two and see how it pans out - if you feel it's too painful, downgrade to -STABLE. (I ran -CURRENT on my main workstation for about 3 years - I dropped back to -STABLE midway through last year because -CURRENT happened to strike an extended period of instability and it was causing me too much angst). On the topic of security, you should be aware that -CURRENT is not officially supported and therefore isn't mentioned in security advisories - in general -CURRENT will have security patches applied before -STABLE but you will need to do some detective work if you want to identify the exact time/revision affected. There have also been a couple of instances where security problems only affected -CURRENT. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Jail seperation patch (v7)
Hello, I released a new version of the jail seperation patch I've been working on for FreeBSD 5.0. Changes from v6: * Ported Jared Mauch's raw IP patch over to the 5.0 tree * Added sysctl to allow/disallow ipfw use * ipfw2: it requires jailed users to use IP addresses that are inside their jails (thereby preventing interference between jails) If anyone's interested in testing it, it can be found at http://msalem.translator.cx/dist/jail_seperation.v7.patch. Thanks, -- Mooneer Salem GPLTrans: http://www.translator.cx/ lifeafterking.org: http://www.lifeafterking.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Incorrect declarations for exec*
Tim Kientzle wrote: > I believe the exec* functions are > declared incorrectly. Unless I'm mistaken, > execve should be declared as > > int > execve(const char *path, const char *const argv[], const char *const envp[]); > > rather than > > int > execve(const char *path, char *const argv[], char *const envp[]); http://www.opengroup.org/onlinepubs/7908799/xsh/execve.html -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Incorrect declarations for exec*
I believe the exec* functions are declared incorrectly. Unless I'm mistaken, execve should be declared as int execve(const char *path, const char *const argv[], const char *const envp[]); rather than int execve(const char *path, char *const argv[], char *const envp[]); (Note the additional 'const' for argv and envp.) Without this, there's no completely correct way to build an argv or envp array with constant strings, since you end up discarding a const somewhere along the way. Similar edits should be done to the other exec* declarations. Yes, GCC complains either way, since it (erroneously) warns about adding const-ness in a pointer assignment. (But only if you routinely use '-pedantic', which I doubt many people do. ;-) Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
User-PPP MTU/MRU - LCP Problem
There is a problem in user-ppp LCP negotation that sometimes the assigned tun0 MTU is incorrectly set. I've sent this msg to brian (the freebsd user-ppp responsible), and then submited a bug report (patch example included) on Feb 17, but I haven't heard anything from him (or anyone else) since them, maybe he's away or something... http://www.freebsd.org/cgi/query-pr.cgi?pr=48378 If someone can handle this, and as 4.8-release has been postponed, can have this fixed on it, it would be great. There seems to be many users with this problem, specially regarding PPPoE and other interfaces with non-standard MTU of 1500. Read the bug report for more information about the problem and a patch example. Thanks -- Fabio Vilan <[EMAIL PROTECTED]> "Any sufficiently advanced technology is indistinguishable from magic." Arthur C. Clarke's Third Law, from Profiles of the Future To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bug in subr_bus.c?
On Sun, 23 Mar 2003, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > John-Mark Gurney <[EMAIL PROTECTED]> writes: > : The bus code could use some locking in it... like you can't delete_child > : from child_detache... and/or better docs on how to handle children... I'm > : not even sure how I was doing things wrong, but I think it might of been > : problems with my code not calling bus_generic_detach before calling > : device_child_delete... > > I'm doing the locking, but you can do a bus_delete_child in a child's > detach routine. Cardbus does this right now and it works when you > unload the cardbus bridge... (btw, I'm using 1.117.2.1 as reference 5.0-R) I'm talking about child_detached (I forgot the d), not detach... so, say you have a bus driver that has a child_detached routine. When you unload the kld for the child, the kld will do a detach of the child. If you look at the device_detach, it will call the device's detach, then the parent's child_detached routine all before marking the device as NOTPRESENT. If you try to do a device_delete_child in the child_detached routine, device_delete_child will call device_detach again, and since the state is still ATTACHED, it will go through the detach procedure again, and either end up with a memory fault or a recursive loop. I just looked briefly at the cardbus code, and you don't have a child_detached routine. John-Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: shared mem and panics when out of PV Entries
On 24 Mar 2003, at 16:02, Igor Sysoev wrote: > How many Apache processes do you have and what's their size ? It varies between 150 and 256 Apache processes. Our MaxClients is set to 256, which seems to work well. Their size varies from 240MB to 290MB depending on how long they've been running. Their resident set size (RSS) is usually between 7MB and 90MB each, though it seems to average about 60MB each (as shown in 'top' and 'ps'). The root Apache process has the same size as the others, but the RSS is only 1.2MB. > kern.ipc.shm_use_phys, kern.ipc.shmmax, etc are for System V shared > memory. They have no relation to the memory that shared between > processes via fork(). That would explain why they've not had any effect on this issue. :-) So, what's the best approach to limiting memory shared via fork() or reducing PV Entry usage by that memory? Is there something I can do with the kernel config or sysctl to accomplish this? Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KVM mice issues
On Monday 24 March 2003 06:33 am, you wrote: > hi, > Hi Alxey, > Yep. In order to avoid moused(8) getting something crazy (after > console switch) I just forced psm reset after synchronization error > detection. It can be achieved by changing changing of > PSM_SYNCERR_THRESHOLD1 define from 20 to 0 (in file sys/isa/psm.c). > > Please try to do it and let me know result, if you're also happy > with solution -- I'll cleanup and commit my patch which forces such > behaviour using sysctl(8). > I tried this. Unfortunately it didn't work for my particular problem. I went back to my original solution (which seems to be pretty MouseMan+ centric unfortunately) of reinitializing the mouse after a protocol error, and I think I have something that works at least as well as the Windows driver. The optimal solution (for me) is to reset the mouse on protocol error and also to set PSM_SYNCERR_THRESHOLD1 to 0 (I get a lot of sync errors after I do a reset.. I imagine I'm doing something incorrectly here :). So far this solution seems to work well, at least I haven't lost my mouse wheel after switching to/from another port on the KVM. When I switch back my mouse acts a bit odd for a moment (the sync errors) and then resets itself and seems to work fine. I'm much happier with a momentarily flaky mouse *with* a mousewheel than a non-flaky mouse without one. If you're interested I can send you the patch I've got. Thanks for your help! -chip -- chip norkus; renaissance hacker;[EMAIL PROTECTED] "question = (to) ? be : !be;" --Shakespeare http://telekinesis.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ISD200
Hello ! I'm hope this is the right place for asking that... I was wondering if someone could write or port (from Linux) a driver for external USB hardrive using the InSystem ISD200 cable. It doesn't work with the regular umass driver, someone told me that it seems that these are bulk/bulk/bulk transport protocol devices, but using an alternative encapsulation of the ATAPI protocol on top of that. Here is the Linux driver listing: http://linuxusb.bkbits.net:8080/usb-2.5/anno/drivers/usb/storage/[EMAIL PROTECTED]|src/|src/drivers|src/drivers/usb|src/drivers/usb/storage I'm unfortunately not a developer but I would be pleased to help, so I could access my "2 months old" new USB hardrive (I was so sure it was going to work under FreeBSD, but it never did). Thank you. Antoine To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Lots of kernel core dumps
On Sunday 23 March 2003 20:20, Wes Peters wrote: > On Saturday 22 March 2003 15:10, Daniela wrote: > > > I know, but 5.0-RELEASE was > > > > > > a) A work-in-progress, not a perfect, bug-free release > > > > > > b) A snapshot of 5.0-CURRENT > > > > > > You read the 5.0 Early Adopter's Guide, right? Bugs like this are > > > expected at this stage in the development process, and if you > > > encounter them then you need to either give up on 5.x and go back to > > > 4.x-STABLE, or upgrade to 5.0-CURRENT if they are already fixed > > > there. > > > > > > Kris > > > > Yes, I read the Early Adopter's Guide. > > Is there any way to solve this without upgrading to -current? > > I want a stable server, of course, but I still want to help the FreeBSD > > folks to make 5.0 the best release ever. This requires testing to be > > done. > > Yes it does, but not on a "production" machine. We admire your courage > and willingness to help, but it's not helping as much as you think. ;^) > > The reason for creating the 5.0 release is to make it easy for more > developers and testers to jump onto the 5.x bandwagon by giving them a > known (relatively) good starting point. Quite a number of problems have > been fixed since 5.0-RELEASE; CURRENT is now generally much more stable, > and nobody is going to spend time updating 5.0 which is essentially an > "early access" release. > > You have to decide for yourself if this machine is too critical to run > CURRENT, in which case it's probably best off running STABLE or the > latest 4.x release branch, or if you want to update it to CURRENT, follow > the CURRENT mailing list, and update again at known stable development > points. It looks like right now is pretty good if you want to jump. > > At any rate, thanks for your tenacity. We really do appreciate the > contributions of everyone. Well, it's just a home server. I don't mind a few crashes, but security is important for me. What do you think, should I go back to -stable? FreeBSD is the world's best OS, I want to see it succeeding and I want to help as much as possible. Daniela To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
MBuf use size problem on 4.8-RC
Hi, netstat -m produces following output on my machine, running 4.8-RC: 21732/22336/96000 mbufs in use (current/peak/max): 21732 mbufs allocated to data 20733/21260/24000 mbuf clusters in use (current/peak/max) 48104 Kbytes allocated to network (8% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines I tracked the percentage of mb_map in use. It reached 70% and then wrapped back to 0%. Why does it happen? A bug? There seems to be a problem with booting up 4.8-RC on a 4GB machine. The kernel reaching multiuser mode produces message about unability of allocating new u_map and panics. This is HyperThreading enabled machine (2+2logical CPUs). Any ideas? Thanks. /S To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: misc/41772: can't disable keybell [PATCH]
On 23-Mar-2003 [EMAIL PROTECTED] wrote:
>
>> Using kbdcontrol -b off on my laptop running current does
>> turn off the sound already.
>
> I tested `kbdcontrol -b off` on FreeBSD 5.0-RELEASE, and it
> still did not turn off the beeper. I have also checked
> 'syscons.c', v. 1.399 ([0]), and foud only one change
> concerning keybell:
> 'if (cold || shutdown_in_progress || !enable_bell)' -
> ('enable_bell' added, which must be "hw.syscons.bell"
> sysctl var), that enables to turn the keybell off globally,
> but not for separate vtys.
>
>> Incidentally, using quiet.off doesn't
>> shut it up either which is very confusing since quiet sets
>> SC_QUIET_BELL.
>
> I tested this again, and it works fine:
>
> `kbdcontrol -b quiet.normal`
> `(sleep 2;echo -e "\x07";sleep 2)&`
> When, after executing this command, i quickly switch to
> another vty, I hear no bell; when I stay on the same vty,
> I can hear the bell.
>
>> PCI ID's for the ICH4 controllere were committed prior to 4.7.
>
> good, found my controller's ID in the latest CVSweb ATA-PCI tree
>
>> This patch would inadvertently turn off visual bell's if you
>> set the duration or pitch to zero manually. A better patch
>> might be:
>>
>> Index: syscons.c
>> ===
>> RCS file: /usr/cvs/src/sys/dev/syscons/syscons.c,v
>> retrieving revision 1.399
>> diff -u -r1.399 syscons.c
>> --- syscons.c 3 Mar 2003 16:24:44 - 1.399
>> +++ syscons.c 22 Mar 2003 14:38:58 -
>> @@ -3547,7 +3547,7 @@
>> if (scp != scp->sc->cur_scp)
>> scp->sc->blink_in_progress += 2;
>> blink_screen(scp->sc->cur_scp);
>> -} else {
>> +} else if (duration != 0 && pitch != 0) {
>> if (scp != scp->sc->cur_scp)
>> pitch *= 2;
>> sysbeep(pitch, duration);
>>
>> Can you verify that this fix works for you?
>
> yes, it does
> but, I think, this may produce faster code:
> +} else if (duration && pitch) {
Nope, optimizing like that is the compiler's job, not the authors.
Making readable code that follows style conventions leads to code
that is easier to maintain. :)
> I also found couple more problems:
>
> 00.
> `kbdcontrol -b 128.800`
> `(sleep 2;echo -e "\x07";sleep 2)&`
> If I stay on the same vty, I hear 800Hz bell, if I switch
> to another vty, I hear ~400Hz bell.
>
> `kbdcontrol -b normal`
> `(sleep 2;echo -e "\x07";sleep 2)&`
> If I stay on the same vty, I hear normal bell, if I switch
> to another vty, I hear a bell with pitch twice as _high_.
>
> 01.
> `kbdcontrol quiet.115.400` - won't set SC_QUIET_BELL flag
I have no idea about these other bugs.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"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
Re: shared mem and panics when out of PV Entries
On Mon, 24 Mar 2003, Andrew Kinney wrote: > The source of the PV Entry usage is shared memory in Apache > (PHP and/or mod_perl). We know it's Apache memory sharing > that causes the problem because nearly all PV Entries are freed > when Apache is stopped and the problem is worst right after > Apache starts when you have a lot of "clean" memory segments > getting shared (10 to 11 million PV Entries used). After Apache > has run for awhile and the shared memory segments become > unshared due to them being "dirtied", the number of PV Entries > used declines and settles in at a much lower number (3 to 5 million > PV Entries used most days). Apache on this machine likes to > hover right around 256 children processes, so you could see how > requiring duplicate PV Entries per shared memory segment per > Apache process could add up quite quickly. > > Under ideal circumstances, we'd correct our PHP/PERL code to > avoid running into the issue at all, but this is customer code that > we don't have much control over since we allow users to select and > run their own CGI scripts without our intervention. So, for this > instance, we have to solve it at the system level by bullet-proofing > our system as much as possible. How many Apache processes do you have and what's their size ? > I've read that setting sysctl kern.ipc.shm_use_phys to "1" will > cause shared memory segments not to use PV Entries at all. > (See > http://www.geocrawler.com/archives/3/159/2002/6/50/9031353/ ) > However, in the real world with FreeBSD 4.7, setting > kern.ipc.shm_use_phys to "1" seems to have no visible effect on > the number of PV Entries consumed by Apache memory sharing. > We're currently running sysctl kern.ipc.shm_use_phys=1 and are > still seeing the heavy PV Entry usage after rebooting (sysctl set on > boot) with no apparent difference in usage. > > My thoughts at this point are leaning towards setting some limits > on shared memory (kern.ipc.shmmax, kern.ipc.shmseg, > kern.ipc.shmall, and kern.ipc.shmmax sysctl's) to limit the number > of PV Entries that Apache can consume by way of shared > memory. Is that a viable approach to this problem? What kind of > gotchas and caveats should I watch out for in taking this approach? > Any recommendations on which one to tweak first? kern.ipc.shm_use_phys, kern.ipc.shmmax, etc are for System V shared memory. They have no relation to the memory that shared between processes via fork(). Igor Sysoev http://sysoev.ru/en/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KVM mice issues
hi, Yep. In order to avoid moused(8) getting something crazy (after console switch) I just forced psm reset after synchronization error detection. It can be achieved by changing changing of PSM_SYNCERR_THRESHOLD1 define from 20 to 0 (in file sys/isa/psm.c). Please try to do it and let me know result, if you're also happy with solution -- I'll cleanup and commit my patch which forces such behaviour using sysctl(8). On Mon, Mar 24, 2003 at 12:50:24PM +0200, Ruslan Ermilov wrote: > I think Alexey was having similar issues, and may have some > non-production quality patches for you to try. > > On Sun, Mar 23, 2003 at 09:57:36AM -0600, Chip Norkus wrote: > > > > Greetings hackers, > > > > I have a KVM switch and a fairly new (Logitech MouseMan+ cordless) mouse, > > and I've found that while FreeBSD properly detects the mouse and all its > > functionality (buttons, scrollwheel, etc) upon boot if I switch to > > another port on the KVM and then switch back my mouse "loses" its > > functionality. > > > > After spending a while trying to figure out this problem (and reading PRs > > on the issue (esp. i386/25463)) I found that a solution was not > > immediately available, but might be somewhat easy to achieve. In > > particular, for my mouse, the mouse driver can and does detect invalid > > packets, and invalid packets are always received after a return to my > > FreeBSD system via the KVM. I found that doing a reinitialization of the > > device would fix the mouse, but that doing it from the interrupt handler > > (in sys/isa/psm.c around line 2170) caused some intermediate problems. > > Normally the mouse would just bounce around and generate click events for > > a while and then settle down, but occasionally the driver (or maybe > > mouse?) would lock solid and I'd have to reboot the system. > > > > Anyways, I'd like to work further on this problem and hopefully find a > > solution, but I'm having some trouble understanding where and what I > > should do. I'm not a novice C hacker, but I *am* a very novice kernel > > hacker and would appreciate help from anyone with knowledge of the psm > > (and atkbdc) code. I've considered maybe adding an ioctl to reset the > > mouse and adding a signal handler to moused to force a reset, but that > > seems kind of silly when the kernel driver can detect the problem itself > > and resolve it. On the other hand, maybe that's the right way to go? > > Advice would be greatly appreciated. > > > > -chip > > -- > > chip norkus; renaissance hacker;[EMAIL PROTECTED] > > "question = (to) ? be : !be;" --Shakespeare http://telekinesis.org/ > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > -- > Ruslan ErmilovSysadmin and DBA, > [EMAIL PROTECTED] Sunbay Software AG, > [EMAIL PROTECTED] FreeBSD committer, > +380.652.512.251 Simferopol, Ukraine > > http://www.FreeBSD.orgThe Power To Serve > http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KVM mice issues
I think Alexey was having similar issues, and may have some non-production quality patches for you to try. On Sun, Mar 23, 2003 at 09:57:36AM -0600, Chip Norkus wrote: > > Greetings hackers, > > I have a KVM switch and a fairly new (Logitech MouseMan+ cordless) mouse, > and I've found that while FreeBSD properly detects the mouse and all its > functionality (buttons, scrollwheel, etc) upon boot if I switch to > another port on the KVM and then switch back my mouse "loses" its > functionality. > > After spending a while trying to figure out this problem (and reading PRs > on the issue (esp. i386/25463)) I found that a solution was not > immediately available, but might be somewhat easy to achieve. In > particular, for my mouse, the mouse driver can and does detect invalid > packets, and invalid packets are always received after a return to my > FreeBSD system via the KVM. I found that doing a reinitialization of the > device would fix the mouse, but that doing it from the interrupt handler > (in sys/isa/psm.c around line 2170) caused some intermediate problems. > Normally the mouse would just bounce around and generate click events for > a while and then settle down, but occasionally the driver (or maybe > mouse?) would lock solid and I'd have to reboot the system. > > Anyways, I'd like to work further on this problem and hopefully find a > solution, but I'm having some trouble understanding where and what I > should do. I'm not a novice C hacker, but I *am* a very novice kernel > hacker and would appreciate help from anyone with knowledge of the psm > (and atkbdc) code. I've considered maybe adding an ioctl to reset the > mouse and adding a signal handler to moused to force a reset, but that > seems kind of silly when the kernel driver can detect the problem itself > and resolve it. On the other hand, maybe that's the right way to go? > Advice would be greatly appreciated. > > -chip > -- > chip norkus; renaissance hacker;[EMAIL PROTECTED] > "question = (to) ? be : !be;" --Shakespeare http://telekinesis.org/ > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
shared mem and panics when out of PV Entries
Hello,
(very long message with background information on the issue
follows)
The machine discussed in this email is tracking RELENG_4_7.
The machine is a well loaded web/mail/ftp server with dual Athlon
MP 2000+ CPUs, 4GB of RAM, and 8GB of available swap space.
The most it has ever swapped was 292KB (yes, KB not MB) and
the CPUs are about 60% idle most of the time. I don't believe we're
pushing the hardware all that hard given the specifications of the
system.
We're getting panics ("page fault" panic traced back to
pmap_insert_entry) because we're running out of PV Entries. I've
bumped up PMAP_SHPGPERPROC to 400, then 800, and then
1500 over the last several months in an attempt to solve this
problem by increasing the PV Entries limit (per the warning in
pmap_collect). Each time, we still bumped the limit and got
panics due to running out of PV Entries. I've verified that maxed
PV Entries are indeed the cause of the panics by logging sysctl
vm.zone. Our PV Entry limit is now 3502 (from sysctl
vm.zone) and we're still running into this limit.
With 1GB KVA space, I really shouldn't take
PMAP_SHPGPERPROC much higher since each PV Entry takes
28 bytes of KVA space and with 3502 PV Entries, that is
nearly 300MB of KVA space used just for PV Entries. Also, from
past experience, if you set PMAP_SHPGPERPROC too high, the
system will not boot. I'm not 100% sure, but I believe that would
happen right around PMAP_SHPGPERPROC=1600 from my
calculations.
Now, I could increase KVA space by way of increasing
KVA_PAGES and presumably continue increasing
PMAP_SHPGPERPROC until the problem goes away, but per a
previous discussion, there are problems (related to pthreads) with
increasing KVA_PAGES in FreeBSD 4.7. This has apparently
been fixed in FreeBSD 4.8.
Since moving to FreeBSD 4.8 isn't an option I can exercise in the
near term, I'd like to approach this problem from a different angle
and possibly solve it without needing to increase KVA_PAGES. In
my opinion, increasing KVA_PAGES would only be a short term
bandaid for the PV Entries issue. I'll eventually need to increase
KVA_PAGES for a different reason, though, because sysctl
vm.kvm_free does hit "0" sometimes after the system has been
running for awhile, but I'll tackle that issue if/when it becomes a
stability issue.
The source of the PV Entry usage is shared memory in Apache
(PHP and/or mod_perl). We know it's Apache memory sharing
that causes the problem because nearly all PV Entries are freed
when Apache is stopped and the problem is worst right after
Apache starts when you have a lot of "clean" memory segments
getting shared (10 to 11 million PV Entries used). After Apache
has run for awhile and the shared memory segments become
unshared due to them being "dirtied", the number of PV Entries
used declines and settles in at a much lower number (3 to 5 million
PV Entries used most days). Apache on this machine likes to
hover right around 256 children processes, so you could see how
requiring duplicate PV Entries per shared memory segment per
Apache process could add up quite quickly.
Under ideal circumstances, we'd correct our PHP/PERL code to
avoid running into the issue at all, but this is customer code that
we don't have much control over since we allow users to select and
run their own CGI scripts without our intervention. So, for this
instance, we have to solve it at the system level by bullet-proofing
our system as much as possible.
I've read that setting sysctl kern.ipc.shm_use_phys to "1" will
cause shared memory segments not to use PV Entries at all.
(See
http://www.geocrawler.com/archives/3/159/2002/6/50/9031353/ )
However, in the real world with FreeBSD 4.7, setting
kern.ipc.shm_use_phys to "1" seems to have no visible effect on
the number of PV Entries consumed by Apache memory sharing.
We're currently running sysctl kern.ipc.shm_use_phys=1 and are
still seeing the heavy PV Entry usage after rebooting (sysctl set on
boot) with no apparent difference in usage.
My thoughts at this point are leaning towards setting some limits
on shared memory (kern.ipc.shmmax, kern.ipc.shmseg,
kern.ipc.shmall, and kern.ipc.shmmax sysctl's) to limit the number
of PV Entries that Apache can consume by way of shared
memory. Is that a viable approach to this problem? What kind of
gotchas and caveats should I watch out for in taking this approach?
Any recommendations on which one to tweak first?
If I'm headed in completely the wrong direction to solve this PV
Entries limit issue, I'd appreciate any alternative approaches to
solving the problem that anyone is willing to offer.
If you need any further information about our settings or usage,
please let me know. I've been as thorough as possible in this
email without getting overly verbose, but in complex issues like this
I recognize that I may not have included all the information needed
for the experts to make
