Re: Apache + threads under FreeBSD ...
>CC'd to David. > >David Greenman was going to backport a fix, but I stalled him because >of backwards compatbility. Since I haven't had the time to implement >the "osendfile" compat syscall, I'd like to know if he'll be MFC'ing the >fix or if I should do it? I'm too busy to deal with it right now. Please proceed. -DG David Greenman-Lawrence Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
>And everybody with VM clue I've asked says it would be trivial to >flip two page-table entries, so for all I care it can be It's going to take a fair bit more than just swapping some page table entries, but it's certainly doable. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
>On Thu, Mar 14, 2002 at 12:47:29PM +0700, John Indra wrote: > >> And to clarify things... I don't know what's wrong with malloc() in -CURRENT >> and -STABLE (and I don't even know whether it's even "wrong"). All I want is >> to let the Perl maintainer in -CURRENT and -STABLE to compile the stock Perl >> with its own malloc library, thus Perl in FreeBSD doesn't suffer from this >> kind of slowness. > >phkmalloc is generally pretty efficient..how do you know that >switching to the perl internal malloc to optimize this particular >usage pattern won't severely pessimize others? If you read the bug report, you'll see that using perl's malloc results in the program running more than 10 times faster. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
>The above perl program results in a loop more or less like: > > n = 2 > for (i = 0; i < 100; i++) > realloc(n++); > >Now, if you read _any_ malloc(3) man page, they will tell you that there >is no way it can be guaranteed that this does not result in a lot of >copying. Um, except that copying isn't what is causing the problem. The performance problem is apparantly caused by tens of thousands of page faults per second as the memory is freed and immediately reallocated again from the kernel. Doesn't phkmalloc keep a small pool of allocations around to avoid problems like this? -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ping with usec resolution
>I'm looking for a ping with usec (microsecond) resolution >(as Redhat 7.2 is using). Could FreeBSD have it too? Anyone >got the source for it? FreeBSD's ping has had microsecond resolution since version 1. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMPng manager's responsibilities (was: Patch for critical_enter()/critical_exit() & interrupt assem)
>On Thursday, 7 March 2002 at 13:19:05 -0800, Julian Elischer wrote: >> >> >> On Thu, 7 Mar 2002, David Greenman wrote: >> >>>> No, Core has just said that he doesn't because he can over-rule any change >>>> in the kernel. And there is no requirement for him to justify it. >>> >>>That is definately *NOT* what core has said. Please go re-read our >>> announcement of the SMPng tech lead appointment. We specifically indicate >>> that the tech lead is obligated to provide justification for any decisions >>> that he may make. >> >> So, where is it? > >*sigh* It's not explicitly in the statement. I mentioned this point >in core, and got the reply: I think Julian is asking for John's justification, not our appointment message. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for critical_enter()/critical_exit() & interrupt assem
>No, Core has just said that he doesn't because he can over-rule any change >in the kernel. And there is no requirement for him to justify it. That is definately *NOT* what core has said. Please go re-read our announcement of the SMPng tech lead appointment. We specifically indicate that the tech lead is obligated to provide justification for any decisions that he may make. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for critical_enter()/critical_exit() & interrupt assem
>>:John has been consistently chugging along on the job all the way. >>:At this point in time, until he is officially unseated John is our >>:designated SMPng architect and his word is pretty final. >>: >>:-- >>:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> >>Oooh... so you mean that since I was working full time and unable >>to contribute, somehow this disqualifies me now? > >No, but it does make you, like the rest of us, underlings to John >architectural direction. Just a quick note that the core team is still having a lively discussion about this issue. All options are still on the table, including appointing an offical SMPng architect/manager. Please be patient. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Discussion of guidelines for additional version control mechanisms (fwd)
>>Some things are too impractically large to do incrementally and are an >>all-or-nothing thing. I recall seeing your early VM commits which were huge, >>you had been working on for months, and were not incremental things. > > Actually, most VM system work that was done was developed over a period of >a few weeks at most, and in most cases were developed and tested in less than >a week. John Dyson had some stuff that brewed for a month or so and in fact >that caused some problems when I wanted to work in a similar area. In those >cases, John D and I collaborated very closely on the VM work, and often >emailed each other patches to integrate into each other's trees. ...but the >important point is that I don't believe that we ever told people not to work >on the VM system because it might conflict with our work. We told people not >to work on it because it was too delicate and too easily broken. :-) Oh, and one more thing... It was ALWAYS forefront in our minds to get any work that we had done committed as soon as possible, specifically to avoid having to deal with conflicts that other people may make, to avoid bit-rot in our working kernel trees, and to get the changes out to the masses for maximal testing. I continue to feel strongly that this is the only way to be successful in developing for FreeBSD. Now, I'm talking about changes to existing files in FreeBSD of course. People that bring whole new arch ports to the kernel have a different problem, but in those cases the overlap with existing files in FreeBSD is very minimal, so longer delays to commit would not normally affect anyone else. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Discussion of guidelines for additional version control mechanisms (fwd)
>>Anyway, my point is that the Perforce repo itself isn't the problem. The >> problem is that people are maintaining private patch sets for long periods >> and making claims to the areas that their patches cover. Step-wise evolution >> is the only way to go in this distributed development model and in order to >> acheive this, private development trees need to be minimized as much as >> possible. > >Some things are too impractically large to do incrementally and are an >all-or-nothing thing. I recall seeing your early VM commits which were huge, >you had been working on for months, and were not incremental things. Actually, most VM system work that was done was developed over a period of a few weeks at most, and in most cases were developed and tested in less than a week. John Dyson had some stuff that brewed for a month or so and in fact that caused some problems when I wanted to work in a similar area. In those cases, John D and I collaborated very closely on the VM work, and often emailed each other patches to integrate into each other's trees. ...but the important point is that I don't believe that we ever told people not to work on the VM system because it might conflict with our work. We told people not to work on it because it was too delicate and too easily broken. :-) -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Discussion of guidelines for additional version control mechanisms (fwd)
>In the past week, a number of comments have been made both for and against >additional version control mechanisms being used to supplement the FreeBSD >Project official CVS server. Proponents of additional mechanisms, such as It's my view that work that happens outside of our official CVS repo is private work no matter what source control system is used (or if one is used at all). It is always a problem for one developer to say "I've got changes to , so don't touch that part of the system." This might be justified for a very short period (measured in a few days at most), but anything longer term will almost certainly put off other developers that may wish to work in the same or related area. This isn't a new problem, either. We've had similar turf conflicts before that very much resembled the one at hand. So...What's that phrase? - "Either take a dump or get off the pot". Something like that. Developers need to develop in ways that their work gets out as soon as possible so that 1) Other developers can review the work as it happens, make comments - perhaps influencing the design at an early stage when it really needs to be, and 2) So that you don't end up with some buggy mega-commit that has so much stuff wound up in it that it's nearly impossible to isolate the bugs. Anyway, my point is that the Perforce repo itself isn't the problem. The problem is that people are maintaining private patch sets for long periods and making claims to the areas that their patches cover. Step-wise evolution is the only way to go in this distributed development model and in order to acheive this, private development trees need to be minimized as much as possible. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com President, Download Technologies, Inc. - http://www.downloadtech.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's touching my executables?
>On Thu, Aug 02, 2001 at 06:28:59PM +, Christian Weisgerber ([EMAIL PROTECTED]) >wrote: >> An increasing number of executables on that box are sporting ever >> newer mtimes. This appears to have been going on ever since the >> Jul 25 update. There is no clear pattern which executables are >> touched. md5 comparisons with previous backup levels (using a Jul 13 >> copy of md5) suggest that the executables have not been changed. >> >> For various reasons I consider it unlikely that I'm dealing with a >> security issue here, although I'm looking into that as well. >> >> Can anybody think of a technical explanation? > >Probably the recent change (IIRC) that someone turned running an >executable into a mtime change. There was no such change. I proposed a change that would update the atime, but that was not committed because it has some bad side effects. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fxp driver not reset after Windows reboot?
>On my VAIO laptop, I have trouble rebooting directly from Windows to >FreeBSD (luckily enough I don't run Windows that often :-) >I tried to look at the driver code, but it looks to me like it is doing >resets when attaching the fxp driver, but somehow, Windows has left it >in the state where it isn't recognized properly. > >Below I have dmesg output, stripped to the fxp0 part. Does anyone have >an idea what the problem might be, or where to try to debug this? >I have added some comments to the dmesg output, /* here */, to add the >programs running there > >Mark > >FreeBSD 5.0-CURRENT #0: Wed Dec 6 09:34:39 CET 2000 >[EMAIL PROTECTED]:/usr/src2/sys/compile/vaio >Preloaded elf kernel "kernel" at 0xc042b000. >Preloaded userconfig_script "/boot/kernel.conf" at 0xc042b09c. >Preloaded elf module "if_fxp.ko" at 0xc042b0ec. >fxp0: port 0xfcc0-0xfcff mem >0xfed0-0xfedf,0xfecff000-0xfecf irq 9 at device 11.0 on pci0 >fxp0: Ethernet address ff:ff:ff:ff:ff:ff, 10Mbps >BRIDGE 990810, have 7 interfaces >-- index 1 type 6 phy 0 addrl 6 addr ff.ff.ff.ff.ff.ff >/* dhclient leads to the below */ >fxp0: SCB timeout Based on the above, I would say that Windows has powered-down the NIC. This is outside of the scope of the driver, so I don't think a solution should be implemented there. Probably something for our APM folks. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current paging strategy
>On Thu, Nov 02, 2000 at 12:45:30AM -0800, David Greenman wrote: >> >Interesting. THis needs about two bytes per page for the counter? >> >>Actually, we found that a single byte per page was sufficient. Pages tended >> to be either heavily accessed or rarely accessed. Even in the unusual case >> where all pages are frequently accessed, the page reclaim rate (and thus >> adjustment rate of the page references count) increases high enough to still >> provide for a decent distribution of the counters and for the page LOU to be >> effective. > >One byte sounds good for i386. >Maybe it makes sense to have it 4 or 8 byte on risc platforms. >I wonder if it's a critical path and if there are more of this in >the kernel source. No, space consumption of the vm_page data structure is by far the greatest concern. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: slight improvement in locore.s?
>locore.s includes: >#define ALLOCPAGES(foo) \ >movlR(physfree), %esi ; \ >movl$((foo)*PAGE_SIZE), %eax ; \ >addl%esi, %eax ; \ >movl%eax, R(physfree) ; \ >movl%esi, %edi ; \ >movl$((foo)*PAGE_SIZE),%ecx ; \ >xorl%eax,%eax ; \ >cld ; \ >rep ; \ >stosb > > >might it be a very slight optimisation to change this to: >#define ALLOCPAGES(foo) \ >movlR(physfree), %esi ; \ >movl$((foo)*PAGE_SIZE), %eax ; \ >movl%eax, %ecx ; \ >addl%esi, %eax ; \ >movl%eax, R(physfree) ; \ >movl%esi, %edi ; \ >xorl%eax,%eax ; \ >cld ; \ >rep ; \ >stosb > >?? Improvement in what way? Readability? I don't think so. Performance? This macro is only used in the initial bootstrap of the kernel. ...changing it might save a few bytes, however. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current paging strategy
>Interesting. THis needs about two bytes per page for the counter? Actually, we found that a single byte per page was sufficient. Pages tended to be either heavily accessed or rarely accessed. Even in the unusual case where all pages are frequently accessed, the page reclaim rate (and thus adjustment rate of the page references count) increases high enough to still provide for a decent distribution of the counters and for the page LOU to be effective. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current paging strategy
>What paging strategy does FreeBSD currently use? Is it LRU or some >approximation to it? How much memory does this strategy take up in its >current implementation? It's probably nothing like anything you've heard of before. It's closest to LOU (least often used). We look at the page's reference flag and increment/decrement a counter depending on it. The rate that we look at the reference flag is also roughly proportional to the rate at which new pages are needed. This algorithm has proven to be extremely effective and does much better than simple LRU. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch review: DELAY.patch
> >http://phk.freebsd.dk/patch/DELAY.patch > >Move DELAY() and sysbeep() from to >and remove unneeded #includes of What's the motivation of this change? To bring it into the MI area? -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel breakage in aac.c (Was: Can't build a kernel)
> This is still broken: > >===> aac >cc -O -pipe -DAAC_COMPAT_LINUX -D_KERNEL -Wall -Wredundant-decls >-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith >-Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- >-I. -I@ -I@/../include -mpreferred-stack-boundary=2 -c >/usr/amd/realmounts/slave/usr/current/src/sys/modules/aac/../../dev/aac/aac.c >/usr/amd/realmounts/slave/usr/current/src/sys/modules/aac/../../dev/aac/aac.c: In >function `aac_linux_ioctl': >/usr/amd/realmounts/slave/usr/current/src/sys/modules/aac/../../dev/aac/aac.c:1815: >dereferencing >pointer to incomplete type Here is a fix. Hopefully Mike will commit it soon. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. Index: aac.c === RCS file: /home/ncvs/src/sys/dev/aac/aac.c,v retrieving revision 1.1 diff -c -r1.1 aac.c *** aac.c 2000/09/13 03:20:34 1.1 --- aac.c 2000/09/18 08:45:08 *** *** 35,40 --- 35,41 #include #include #include + #include #include To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fxp suspend/resume hangs
I've made a few changes to the patches which should address my primary
concerns. Instead of using IFF_RUNNING, I added a new softc variable to
track the suspended condition. Only the APM stuff should call suspend/resume,
so the interrupt logic should be uneffected in non-APM machines. Please try
these patches out and let me know if they work as expected. They should apply
and work with both -stable and -current.
-DG
David Greenman
Co-founder, The FreeBSD Project - http://www.freebsd.org
President, TeraSolutions, Inc. - http://www.terasolutions.com
Pave the road of life with opportunities.
Index: if_fxp.c
===
RCS file: /home/ncvs/src/sys/pci/if_fxp.c,v
retrieving revision 1.77.2.3
diff -c -r1.77.2.3 if_fxp.c
*** if_fxp.c2000/06/19 00:54:30 1.77.2.3
--- if_fxp.c2000/09/17 13:15:33
***
*** 125,135
--- 125,139
fxp_lwcopy(src, dst)
volatile u_int32_t *src, *dst;
{
+ #ifdef __i386__
+ *dst = *src;
+ #else
volatile u_int16_t *a = (volatile u_int16_t *)src;
volatile u_int16_t *b = (volatile u_int16_t *)dst;
b[0] = a[0];
b[1] = a[1];
+ #endif
}
/*
***
*** 215,220
--- 219,225
static void fxp_mediastatus __P((struct ifnet *, struct ifmediareq *));
static void fxp_set_media __P((struct fxp_softc *, int));
static __inline void fxp_scb_wait __P((struct fxp_softc *));
+ static __inline void fxp_dma_wait __P((volatile u_int16_t *, struct fxp_softc *sc));
static FXP_INTR_TYPE fxp_intr __P((void *));
static void fxp_start __P((struct ifnet *));
static int fxp_ioctl __P((struct ifnet *,
***
*** 283,290
struct fxp_softc *sc;
{
int i = 1;
! while (CSR_READ_1(sc, FXP_CSR_SCB_COMMAND) && --i);
}
/*
--- 288,311
struct fxp_softc *sc;
{
int i = 1;
+
+ while (CSR_READ_1(sc, FXP_CSR_SCB_COMMAND) && --i)
+ DELAY(2);
+ if (i == 0)
+ printf(FXP_FORMAT ": SCB timeout\n", FXP_ARGS(sc));
+ }
+
+ static __inline void
+ fxp_dma_wait(status, sc)
+ volatile u_int16_t *status;
+ struct fxp_softc *sc;
+ {
+ int i = 1;
! while (!(*status & FXP_CB_STATUS_C) && --i)
! DELAY(2);
! if (i == 0)
! printf(FXP_FORMAT ": DMA timeout\n", FXP_ARGS(sc));
}
/*
***
*** 679,690
--- 700,784
return 0;
}
+ /*
+ * Device suspend routine. Stop the interface and save some PCI
+ * settings in case the BIOS doesn't restore them properly on
+ * resume.
+ */
+ static int
+ fxp_suspend(device_t dev)
+ {
+ struct fxp_softc *sc = device_get_softc(dev);
+ int i, s;
+
+ s = splimp();
+
+ fxp_stop(sc);
+
+ for (i=0; i<5; i++)
+ sc->saved_maps[i] = pci_read_config(dev, PCIR_MAPS + i*4, 4);
+ sc->saved_biosaddr = pci_read_config(dev, PCIR_BIOS, 4);
+ sc->saved_intline = pci_read_config(dev, PCIR_INTLINE, 1);
+ sc->saved_cachelnsz = pci_read_config(dev, PCIR_CACHELNSZ, 1);
+ sc->saved_lattimer = pci_read_config(dev, PCIR_LATTIMER, 1);
+
+ sc->suspended = 1;
+
+ splx(s);
+
+ return 0;
+ }
+
+ /*
+ * Device resume routine. Restore some PCI settings in case the BIOS
+ * doesn't, re-enable busmastering, and restart the interface if
+ * appropriate.
+ */
+ static int
+ fxp_resume(device_t dev)
+ {
+ struct fxp_softc *sc = device_get_softc(dev);
+ struct ifnet *ifp = &sc->sc_if;
+ u_int16_t pci_command;
+ int i, s;
+
+ s = splimp();
+
+ /* better way to do this? */
+ for (i=0; i<5; i++)
+ pci_write_config(dev, PCIR_MAPS + i*4, sc->saved_maps[i], 4);
+ pci_write_config(dev, PCIR_BIOS, sc->saved_biosaddr, 4);
+ pci_write_config(dev, PCIR_INTLINE, sc->saved_intline, 1);
+ pci_write_config(dev, PCIR_CACHELNSZ, sc->saved_cachelnsz, 1);
+ pci_write_config(dev, PCIR_LATTIMER, sc->saved_lattimer, 1);
+
+ /* reenable busmastering */
+ pci_command = pci_read_config(dev, PCIR_COMMAND, 2);
+ pci_command |= (PCIM_CMD_MEMEN|PCIM_CMD_BUSMASTEREN);
+ pci_write_config(dev, PCIR_COMMAND, pci_command, 2);
+
+ CSR_WRITE_4(sc, FXP_CSR_PORT, FXP_PORT_SELECTIVE_RESET);
+ DELAY(10);
+
+ /* reinitialize interface if necessary */
+ if (ifp->if_flags & IFF_UP)
+ fxp_init(sc);
+
+ sc->suspended = 0;
+
+ splx(s);
+
+ return 0;
+ }
+
static device_method_t fxp_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, fxp_probe),
Re: fxp suspend/resume hangs
>appended below is an excerpt from a message sent to -stable earlier >tonight, containing content of a type which kris kenneway correctly >suggested would find a more suitable audience on -current. > >in summary: PR kern/18756 contains a patch (against -stable, alas, >sorry) which fixes kernel hangs in the fxp driver on some laptops >after a resume from suspend. while quite a few people appear to be >using this patch successfully, it hasn't been committed -- david >greenman had an entirely reasonable objection to one aspect of the >patch's behavior. > >unfortunately, my knowledge of the kernel isn't sufficient to >adequately address david's concerns, and though i've mailed him to >ask for guidance twice over the past 4 months, i haven't received a >response. that's probably my fault, i probably should have been >mailing -current to being with. I can only find the 5/22 email regarding this, so I seem to have missed your second message. With over a thousand emails a day coming into my inbox, this shouldn't be too surprising. My response to the 5/22 message was this: ... This could be a problem. If an interrupt occurs, it must be acknowledged otherwise you'll be stuck in an infinit loop - PCI interrupts are level sensitive and must be cleared in the ISR. ... In short, while it may fix a hang in your laptop case, it opens the driver up to a hang if an unexpected interrupt occurs while IFF_RUNNING is clear. I think this is dangerous enough that I don't think the code should not be compiled as part of the standard driver. One just cannot ignore level- sensitive PCI interrupts. >if anybody can offer any suggestions as to how to move forward with >getting this patch to the point where it can be committed, i'd >certainly appreciate it. alternately, any feedback on whether the >patch is necessary and/or functional on your machine, laptop or no, >would be interesting. >> i wouldn't be at all surprised if there were a better approach than >> simply ignoring interrupts when the device isn't running, but it's >> not clear to me what that would be. if anybody has any suggestions >> as to how to clean this up, i'm all ears. alternately, if any >> committers want to take this on, that'd be swell too. Someone needs to find out what the laptop is doing to the STATACK register that causes a hang when it is accessed. Failing any better resolution, I guess that the objected-to change could be committed with an ifdef. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
>In article <[EMAIL PROTECTED]>, David Greenman ><[EMAIL PROTECTED]> wrote: >> >I will add that this is the pattern that Kirk teaches in his kernel >> >internals class. >> >>If that's true, > >Do you want me to fax you a copy of page 15 of his class notes from >the course he gave at last year's FreeBSDCon, or will you just take my >word for it? I'm not calling you a liar. I think it is possible that you may have misunderstood what Kirk was saying, however. Having not been in the class myself, it is perhaps a bit presumptuous for me to think that. There are cases where one must check for the condition after the wakeup - the cases where multiple sleepers/consumers are waiting on the same condition/resource, for example. ...and there are cases that simply don't work that way and aren't suseptible to that inherent race condition. Is it possible that Kirk was speaking about the race condition cases? >> then he should practice what he preaches. Some of the code that I'm >> refering to (e.g. lockf) was apparantly written by him. > >Whether Kirk practices what he preaches is irrelevant to this >discussion. Instead of focusing on a 1-sentence "I will add ..." from >my posting, why not respond to the main thrust of it -- the paragraph >I quoted from the Birrell paper? Because I haven't decided whether I agree with it or not. I think an argument could be made that adding the checks in a case where a bogus wakeup can never happen might actually obscure the code by leading the programmer into thinking that there could be multiple sleepers/consumers. Perhaps I read more into code than I should, but I naturally assume that if a check is made for something then the condition being checked for can happen. If it cannot, then that just leads me astray. Certainly comments are a good thing to keep people on the right path, but then this applies whether you check the post-tsleep state or not. >>I'll say again, however, that some of the cases that rely on the >> historical symantics would become very expensive if they had to go >> through a series of complex checks (perhaps list traversals, etc), >> in order to verify that the wakeup wasn't bogus. I personally don't >> think this is an improvement. > >Some of them might be expensive, but most of them would not. That could be - I honestly don't know and it seems to me that a thorough code review would be needed before a conclusion can be drawn. >Obviously the waker-upper knows that the condition is true. Otherwise >the existing code which doesn't check wouldn't work. In the expensive >cases the waker-upper could simply set a flag for the sleeper to >check. For me, that doesn't make the code easier to read or understand - it has the opposite effect. ...but then I'm used to the historical symantics and naturally consider the possible cases when looking at the code. >Note, I am not expressing an opinion about whether the sleeps should >be terminated prematurely during shutdown. But I am expressing a >strong opinion about whether sleepers should do a reality check before >proceeding. I could be persuaded to think that way, but I still remain unconvinced. Again, I'm used to the historical symantics, so changing them requires a pretty good justification and a bit of brain rewiring, which I naturally resist. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
>I will add that this is the pattern that Kirk teaches in his kernel >internals class. If that's true, then he should practice what he preaches. Some of the code that I'm refering to (e.g. lockf) was apparantly written by him. I'll say again, however, that some of the cases that rely on the historical symantics would become very expensive if they had to go through a series of complex checks (perhaps list traversals, etc), in order to verify that the wakeup wasn't bogus. I personally don't think this is an improvement. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
>I did say "as a general rule". If you know that "by design" nothing else >is going to mess with what you're sleeping on before you wake up then >you can make tighter optimisations but that's not the general case. >There is such a thing as over optimisation though and for the sake of a >simple if statement it is probably better to write code that is robust >to changes made elsewhere in the system rather than squeeze every inch >of performance out of the code, unless there's a real need to optimize >in that particular area. In some cases it isn't practical or very expensive to verify that the condition that caused the sleep in the first place has been satisfied - that's often why certain parts of the kernel rely on the established tsleep symantics. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
>In the particular case of sleeping though, a woken process does need to >check the condition that it slept on because one of the other processes >sleeping on that resource may have had a chance to run first and changed >some state. So as a general rule, you shouldn't assume that everything >is fine when you return from being asleep because it might not be. No, that's not true, and there are many examples in the kernel where a bogus wakeup would lead to bad things happening. I recall some code in the advisory locking code, and VM system, that assume that there is only one wakeup event and that the thing causing it assures that certain other things have occured before issuing it. That's just the way it has worked since the dawn of time. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ugly, slow shutdown
>>Can you give a reason why we'll have to now start coding defensively >>because our arguments to tsleep() are just "advisory" now? > >It is not something we "suddenly have to do" it's been The Right Way >even since I first sharpened my teeth on unix kernels many years ago. Uh, Poul, I think you're full of it. The previous behavior of tsleep where you can make assumptions about who wakes you and under what conditions is a long and well established idiom. We (the kernel developers of BSD) have always coded to the established kernel programming interface and most of us consider it bad form to check for conditions which can't happen because the kernel API doesn't allow it. For example, we don't check for a NULL return from malloc in the case of !NO_WAIT, because we knew that the code would never do that. There are many other examples of similar assumptions in the kernel. We write the code to be efficient and only check for bogus conditions that might happen. The only exception to this is programatic ASSERTs that do internal consistency checks, but the purpose of those is quite different. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc driver and underruns (was: Strangeness with 4.0-S)
>> <<[EMAIL PROTECTED]> said: >> >> > Ohh... and a finally note, DEC blew the chip design by only including >> > a 160byte threshold point given that PCI 2.0 spec says it should have >> > been 500bytes!! >> >> It wouldn't be the first thing DEC had screwed up in the design of >> these NICs. On the other hand, Intel has owned the silicon for a >> couple of years now, which is more than enough time to unscrew it if >> they really wanted to. Clearly, they'd rather be selling 82559s > >As far as I can tell the fxp driver doesn't even use the tx_fifo in the >825xxx chips :-) The 82557-9 have a 2KB internal buffer for transmits. They don't start transmitting until a programmed threshold is reached - this is to insure that PCI bus latency doesn't result in the transmitter getting stalled. The fxp driver starts out with this threshold set at 512 bytes, but will increase it (512 bytes at a time) when a DMA underrun occurs. Of course once the threshold reached 1536, then an entire 1500 byte packet is DMA'd into the buffer before the transmit begins. There is buffering on the receive side as well, but I don't recall off hand how large that is (although I think it's 2KB as well). -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's up with ftp.freebsd.org
>On Wed, Jul 05, 2000 at 10:16:52 -0700, David Greenman wrote: >> >It doesn't seem to be allowing anon logings - nobody released some fancy new >> >game, have they? >> >>I've had to reduce the user limit until a bandwidth issue is addressed. It >> should be back to normal by the weekend. > >You might want to adjust the error message people get when the user limit >has been exceeded: > >ncftp>open ftp.freebsd.org >User anonymous access denied. >Login failed. >ncftp>quit > >Most ftp servers say something about too many users...this leaves people >with the impression that the machine doesn't support anonymous ftp. Oops! I forgot about that when I built the server earlier in the year. This is the first time that the limit has been reached, so noone noticed. :-) -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's up with ftp.freebsd.org
>It doesn't seem to be allowing anon logings - nobody released some fancy new >game, have they? I've had to reduce the user limit until a bandwidth issue is addressed. It should be back to normal by the weekend. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Scheduler changes?
>Using idprio as Volodymyr suggested seems to be a viable workaround. You >mentioned in another message that idprio could potentially deadlock my >machine, though. Under what conditions could this happen (and how likely >is it to occur)? idprio can lead to a system hang due to priority inversion. For example, suppose that an idprio process does disk I/O and locks a critical resource (such as the vnode for the '/' directory) prior to doing that. Then also suppose that a normal process is in a permanent run state (loop: goto loop). When the I/O completes on the idprio process, it will never be given an opportunity to release the vnode lock. Eventually just about everything in the system will deadlock waiting on that resource and the system will essentially hang. The work-around for this is to temporarily increase the priority of idprio processes while they execute in the kernel, but this hasn't yet been implemented. The above scenario can happen pretty easily if you have an idprio process doing a normal mix of file operations - all you need then is normal priority process(es) to eat all the CPU for long periods - even a few seconds can be very annoying to interactive users. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org Manufacturer of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP changes and breaking kld object module compatibility
>:> There's another good reason to MFC the linux patch on wednesday... >:> that is, to do it at the same time the SMP cleanup is MFC'd, and that >:> is because both patch sets require the linux kernel module to be >:> recompiled and I'd rather not force people to do that twice. >:> >:> The SMP patchset, in fact, requires that all kernel modules be >:> recompiled due to the locks that were removed from the spl*() macros. I wonder if they really must be recompiled. It sounds like that would improve performance, but is seems like gratuitous locking in this area wouldn't necessarily cause things to break. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
>I do not consider the linux scripting patch to be a major infrastructure >change, I consider it to be a simple bug fix. If you have a functional >issue with the patch I'm all ears. If you disagree with my assessment of >the triviality of the linux scripting patch, then I will ask for a >second opinion from someone who is not quite so jaded in regards to my >commits... say Jordan or DG. I'm sure you're right that the impact is minor. I'm a little uncomfortable with immediate MFC's, even though I've been guilty of doing that myself at times in the past. Can we perhaps compromise and allow for a one day delay? At least that would catch glaring mistakes like mis-applied patches that happen sometimes even with highly skilled developers who have only the best intentions. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Load average calculation?
>:I'm not sure if this is -current fodder or not, but since it's still >:happening in -current, I'll ask. >: >:We recently upgraded a server from 2.2.8 to 4.0(the same behavior is shown >:on 5.0-current, too). Before, with the exact same load, we'd see load >:averages from between 0.20 and 0.30. Now, we're getting: >: >:load averages: 4.16, 4.23, 4.66 >: >:Top shows the same CPU percentages, just a much higher load average for the >:same work being done. Did the load average calculation change, or something >:with the scheduler differ? Customers are complaining that the load average >:is too high, which is kinda silly, since 4.0 seems noticably faster in some >:cases. >: >:Any ideas? >: >:Kevin > >I believe the load average was changed quite a while ago to reflect not >only runnable processes but also processes stuck in disk-wait. It's >a more accurate measure of load. It's always been that way in BSD. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I/O clustering, Re: patches for test / review
>>Committing a 64k block would require 8 times the overhead of bundling >>up the RPC as well as transmission and reply, it may be possible >>to pipeline these commits because you don't really need to wait >>for one to complete before issueing another request, but it's still >>8x the amount of traffic. > >I agree that it is obvious for NFS, but I don't see it as being >obvious at all for (modern) disks, so for that case I would like >to see numbers. > >If running without clustering is just as fast for modern disks, >I think the clustering needs rethought. Depends on the type of disk drive and how it is configured. Some drives perform badly (skip a revolution) with back-to-back writes. In all cases, without aggregation of blocks, you pay the extra cost of additional interrupts and I/O rundowns, which can be a significant factor. Also, unless the blocks were originally written by the application in a chunk, they will likely be mixed with blocks to varying locations, in which case for drives without write caching enabled, you'll have additional seeks to write the blocks out. Things like this don't show up when doing simplistic sequential write tests. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current, XEON and MP performance
>I don't know where to ask first (or what to look at) so I'd like some >creative guessing by some people closer to the sources... > >Running the same programs on nearly identically configured -CURRENT kernels >on a HP NetServer LH4 (four 550 MHz PIII Xeon with 512MB Cache, supposed to >be an INTEL 450NX-based chipset) with one GB RAM and a home-grown ASUS >P2-BDS based system (two 450 MHz PIII) with 512 MB RAM I find that the >programs (running on the same input data) on the "smaller" machine tend to >take only a third of the CPU time they need on the LH4. [Worse: The LH4 >behaves like a spoilt brat when it comes to hardware, disliking the Intel >EtherExpress that came with it (generating bus mastering problems after >bringing it up), having interrupt routing problems with two DEC TULIP based >ethernet cards sharing the same IRQ and being picky just which 3C906B-TX it >gets plugged in. It's a bitch and I'd like shooting it. Oh yes - HP has been >very helpful, telling me that I was at least 10 years behind wanting to run >a BSD and that only WinNT, HP-Sux and Linux were supported on this hardware.] > >Back to the topic: Are there any reasons for these observations? If someone >liked taking a closer look at it I could provide them with access to the >machine (and its console). I ran out of clues... What about wall-clock time? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crash from ^T during heavy paging
>On Mon, 10 Jan 2000, Stephen McKay wrote: > >> The problem is that calcru() thinks that P_INMEM means that the proc >> structure is fully and accurately populated. But P_INMEM is one of the >> first flags set. >> >> So, calcru() and possibly some other places, are looking at a struct proc >> before it's all there. What's the "proper" way to do it? > >It should really be one of the _last_ flags set, if it's to mean anything. >I don't know how to explain the prevalance of race conditions in the old >code, except to say it probably has to do with not planning ahead. >Certainly it's not acceptable to create new race conditions now (even if >it can happen by accident). > >So, here's something to defer P_INMEM til the end, when the process is >really "ready": > >--- sys/kern/kern_fork.c Tue Dec 7 22:11:35 1999 >+++ /tmp/kern_fork.c Tue Jan 11 03:32:44 2000 >@@ -351,7 +351,7 @@ >* Increase reference counts on shared objects. >* The p_stats and p_sigacts substructs are set in vm_fork. >*/ >- p2->p_flag = P_INMEM; >+ p2->p_flag = 0; > if (p1->p_flag & P_PROFIL) > startprofclock(p2); > MALLOC(p2->p_cred, struct pcred *, sizeof(struct pcred), >@@ -499,6 +499,7 @@ > microtime(&(p2->p_stats->p_start)); > p2->p_acflag = AFORK; > (void) splhigh(); >+ p2->p_flag |= P_INMEM; > p2->p_stat = SRUN; > setrunqueue(p2); > (void) spl0(); It shouldn't be necessary to set the flag inside of splhigh. If you move it up a line I think you'll have a winner. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6 (Re: 4.0 code freeze scheduled for Jan 15th)
>> Get IPv6 into the tree. Now. Thank you. > >I don't know quite what makes you think that we came down in the last >shower of rain, but has it ever occurred to you that we're not >_completely_ stupid? > >Do you _always_ assume that anyone other than yourself is a complete >moron? What makes you think that we don't want this code integrated, or >that we don't care about it? Have you bothered to actually read those >sides of this discussion that have come from the release engineering team? > >Wouldn't it be much more sensible of you to assume that there are good >and valid reasons for things being the way they are? Wouldn't it be much >more sensible of you to enquire as to what these reasons are, or perhaps >to even have paid attention to all the discussions and progress that have >gone on over the last few months (or even just stayed up to date in the >last week, where the whole matter has been discussed)? > >Or are you just too lazy? Too lazy to pay attention? Too lazy to >actually participate in this process? Too lazy to do anything other than >to wait until it's too late to do anything, and then randomly sling blame >around? What _do_ you think you achieve with this? How do you think >that insulting the people that are actually trying to do the work while >you sit on the sidelines is going to help the process? > >It's been said before, and I'm sure it'll be said again; if you can't >or won't offer support or assistance, the very least you can do is avoid >being actively destructive. Take a few moments to think about what it is >that you and we want to achieve, and how best to get there. And take a >hint; insulting us is not how to go about it. Mike, I think this is just a bit over the top and doesn't belong in our mailing lists. Please stop doing that. It really isn't fair to blame the FreeBSD developer base at large, and users as well for the slowness of the integration. The KAME team has never asked for integration help as far as I can recall and the primary reason for the delay was actually due to their attentions being focused on NetBSD (with the justification that they were about to freeze for a release). This all said, I don't think we are that far away from having a functional IPv6 implementation in FreeBSD. Most (all?) of the stack is there and what is needed now is the completion of support in the various system utilities. I think this part of the merger could be completed in an amount of time that is measured in weeks if the KAME developers can find the time to put into it right now. If not, then this whole discussion is a waste of bandwidth and everyone should just stop gritching over it. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 code freeze scheduled for Jan 15th
> * From: "Jordan K. Hubbard" <[EMAIL PROTECTED]> > > * How do you think things "get included" in the OS? Do you think one > * just moves the KAME bits into a directory next to /usr/src, goes away > * for 24 hours to let them bits do their thing, and then comes back to > * find that nature has done the rest of the work? Sorry, it might work > * that way for hamsters but it doesn't work that way for code! Somebody > >dear mr. hubbard, > >please do not insult hamsters. it doesn't work that way for hamsters >either. we are fully aware of our surroundings and plan our lives >accordingly. in fact, satoshi is out picking oranges now so i have >full access to his computer. (ooohh nude hamster pics) > >that said, i don't think you need to push back the release date. > >sincerely, >fifi > >p.s. pardon the lack of capital letters but my paws can't quite reach > the shift key and the alphabet keys at the same time If that is true, then how were you able to push the paren keys? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Your misleading, no LYING message to me
>He is just expressing his point. From what I can tell someone removed him >from the list with no reason and now he is angry. I probably would be too. That is not at all what happend. Karl went off the deep end about phk recommending a Motorola GPS to do timekeeping. Then, after a pile of insulting messages from Karl, Karl made an accusation that someone removed him from three of the mailing lists. For at least two of those lists, he was simply wrong. For the third (freebsd-current), there is no evidence to support his claim. >Also, I can tell that someone is doing some good covering up. Its ashame to >see leaders do this. How can you tell that? There is no evidence to support that. *I'm* certainly not covering anything up and I've seen no reason to believe that anyone else is, either. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Your misleading, no, LYING message to me
>I have to say that PHK has become the MASTER at pissing >people off, ensuring that his opponent goes the deep end >and staying calm so the blame obviously does not fall on >him. Got to admit his formula is very very nice 8) > > >By a long shot the problem is NOT Karl. It takes at least >TWO to engage in a combatitive conflict -- that is if >you are not schizophreniac. > >The proper tactic to resolve the conflict should have >been to wait a cool off period and then slug it off >technically. Nevertheless, instead of waiting for >Karl to cool off and attempt to ration with him , >it was much easier to drive him further down: hence >thru censorship the "technical" argument was won >with virtually no technical effort at all -- Like I said >earlier very very nice tactic ! May I respectfully request that people not jump to conclusions without a lot more to go on than some angry accusations. I would also like to say that Poul-Henning's behavior in this thread was exceptional and that Karl had no reason to react the way he did. I think Karl owes a lot of people some apologies. His behavior was clearly inappropriate and continues to be so. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Your misleading, no, LYING message to me
>Someone logged into HUB the EDITED me out of the CURRENT mailing list. As near as I can tell, noone with the ability to su was logged into hub earlier today when you claim that you were removed. As far as I know, noone had removed you. I have not seen any messages (other than your claim) or any other evidence that would indicate such an action occured. >Again, who was su'd or logged into the majordomo account (or any account >with write access to the list directories) a few hours ago? Noone as far as I can tell. Jonathan is a man of exceptional integrity and you have no basis for making the accusations that you have against him. I think you owe him an apology. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposed patch to fix VN device (again)
I've heard from both of you that you think the other is wrong. This isn't very helpful, however, in finding the correct solution. What I'd like to hear from both of you is the reasons why swap is better as a device, or not. There seems to be some unstated architectural philosophy that needs to be stated before any informed decision can be made about what is the right direction to go in. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Which is the truth? (sycalls and traps)
>Am I also right in assuming that all the registers that the user was >running when they did the KERNCALL have been saved on the KERNEL stack by >the time that the above routines are called? No, that's what the pushal (push all) does. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH for testing
>:I don't think this should go in at all. >: >:It increases the size of the proc structure (thereby affecting _all_ >:processes) gratuitously. While I'm generally in favour of having the process >:arguments kept around, the "BSD way" has been to only examine them in user >:memory, despite that being unreliable and just annoying. >: >:The benefits are fairly minimal, and I don't believe justify the cost >:incurred. > >If it weren't for 'setproctitle()' I would agree with you. But since >setproctitle() exists we have a serious mess on our hands. Personally I >would prefer to see it cleaned up as follows: > > * place a copy of the initial arguments in the struct proc as well > as the uarea. > * have the sysctl that limits the buffer size within the struct proc > to something reasonable (e.g. 1K) but don't bother making 'ps' > fall back to the uarea. Allow a value of '0' indicating 'unlimited' > (i.e. really means ARGS_MAX). > * setproctitle() messes with the struct proc only > * ps, top, et all use the struct proc only > >And, also, we need to get rid of the 'e' option to ps entirely. It's a >major security hole. I agree that we need to get rid of 'e' and any other options that allow reading another process's environment. I don't agree with putting the command args in the proc struct, however, for the reason that Sean mentioned above. In my opinion, doing so majorly bloats the proc struct for no good reason and also introduces gratuitous incompatibilities for utilities that want to modify their argv[*] and expect the modifications to show up in ps(1). -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [Patches avail?] Re: MMAP() in STABLE/CURRENT ...
>On Thu, Oct 07, 1999 at 10:09:23AM -0700, Matthew Dillon wrote: > >> Intel's ECC implementation is not perfect (1), but it's good enough to >> catch these sorts of problems. > >Just as an interesting side note, we had a motherboard which >supported ECC ram and had ECC ram in it and which was crashing. >Eventually we discovered that every 8th byte in page aligned 4KB >chunks was becomming corrupted. > >We replaced the ram and saw no improvement, and then got a replacement >motherboard. As far as I could see the only significant difference >between the new and old motherboard was the addition of a heat sink >to the memory controler chip. The machine is now perfectly happy. > >So it seems that ECC isn't enough if your memory controler is too >hot! ECC doesn't protect against certain types of motherboard address line errors (since although the ECC is correct, the selected address is wrong, so thus the data is wrong). There's parity protection on parts of the CPU address bus, but I don't believe there is any protection between the memory controller and the DIMMs for this type of problem. A handful of metal filings is also known to cause problems when it is dispersed properly. :-) -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: request for review: move of /var/cron/log to /var/log/cron.log
>On Sun, Sep 05, 1999 at 11:32:35AM +0200, Nick Hibma wrote: >> -/var/cron/log 600 3 100 * Z >> +/var/log/cron.log 600 3 100 * Z >> /var/log/amd.log664 7 100 * Z >> /var/log/kerberos.log 664 7 100 * Z >> /var/log/lpd-errs 664 7 100 * Z > >Would it make sense (while you're there), to get rid of the ".log" >suffix of certain log files like cron.log, amd.log, etc ... > >I think the fact that files live under /var/"log" should be enough >to tell people, "here live logfiles". > >Since those files are rotated automatically by newsyslog there >shouldn't be any reason to say "no, this breaks scripts", since >the OS provides the newsyslog facility, so we can change it there >as well... > >What do you think ? I think they should all have .log since there can be subdirectories and it makes the files more easily identifiable. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: readdirplus client side fix (was Re: IRIX 6.5.4 NFS v3 TCP client + FreeBSD server = bewm)
>Look up a bit in the code. If bigenough is not true, cnp does not >get initialized. This could lead to the bogus length -- or rather, >it would be the cnp that is bogus, not the 'len'. > >The question is how to fix it. I think we can safely avoid doing the >cache_enter so try changing the 'if (doit)' to 'if (doit && bigenough)'. >I've included the patch below. ... >In order to accomplish this, the underlying vnode representing each >directory entry is retrieved and locked. However, there is a special >case: We *already* have a reference on the directory vnode itself, >and one of the directory entries, ".", will be the same vnode. Our >reference vnode, vp is *NOT* locked. In fact, we *can't* lock it >without creating a potential deadlock situation (at least that is my >take). I good bit of detective work...excellent job. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PMAP_SHPGPERPROC: related to pagedaemon?
PMAP_SHPGPERPROC controls the default number of struct pv_entry that the system allocates kernel virtual memory for. A pv_entry is a data structure that tracks physical to virtual page translations. For example, suppose the system wants to page out a specific page of memory. It needs to know all the processes that have that mapped so that it can efficiently remove it from all of the processes page tables. For pages that are usually not shared between processes (like stack pages, for example), then there is only one pv_entry. For pages that are shared, then there is one pv_entry for each mapping of it, and thus the number of pv_entries can become quite large - perhaps hundreds or thousands of times the total number of pages in the system, depending on how much sharing is going on. Due to various complications in the VM system, the kernel wants the virtual memory for the pv_entry structs preallocated...so setting this too high will waste kernel virtual memory to the point where no more can be allocated (causing the system to crash, usually at bootup time), and too few can lead to running out of them if there is a large amount of page sharing. I don't know what's going on with your system, but it's definately unusual to hit this limit under normal circumstances. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com >On Fri, 23 Jul 1999, Doug wrote: > >> Using two -current machines, both dated 7/16 I got the following >> message in my log file, which I think explains the weird spontaneous >> reboots I've been getting. >> >> /kernel: pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC > > In my efforts to track this down today I have been monitoring the >logs like a hawk. When this message started appearing again (now with the >PMAP_SHPGPERPROC set to 300 in the kernel config file) I took a look at >the system and what it was doing. I was very disturbed to find that >according to 'ps' pagedaemon was eating up 67% of the cpu. This is a >dual-PIII 500 machine, and I'm not sure if 'ps' is reporting 67% of one >CPU (my first guess) or 67% of both. > > I captured the output of 'ps -aulx' to a file, here is the bit >about pagedaemon, line wrapped for readability. > >USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIMECOMMAND >root2 66.7 0.0 00 ?? RL 10:12AM 5:15.52 (pagedaemon) > >UID PPID CPU PRI NI WCHAN >0 0 265 -18 0- > > There were no other unusual symptoms, except that the miva (CGI) >processes that the box is supposed to be processing were backed way up. >Normally they complete very quickly (roughly 3 per second) with little or >no backlog. > > I've increased the PMAP_SHPGPERPROC setting in the kernel config >file to 400 and recompiled just in case the system panics again, however >with it set to 300 as it is now it recovers ok. Once again, any thoughts >or suggestions welcome. > >Thanks, > >Doug > > > >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: Heh heh, humorous lockup
>: Yes, I do - at least with the 512MB figure. That would be half of the 1GB >:KVA space and large systems really need that space for things like network >:buffers and other map regions. >: >:-DG >: >:David Greenman >:Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org >:Creator of high-performance Internet servers - http://www.terasolutions.com > >What would be an acceptable upper limit? 256MB? 128MB? The test >I ran (Kirk's news test) ate around 60MB for the "FFS Node" memory area >before the number of vnodes stabilized, on a 1GB machine. I would say >that a 128MB upper limit would be too small for a 4G machine. A 256MB >limit ought to work for a 4G machine > >Since most of those news files were small, I think Kirk's news test code >is pretty much the worse case scenario as far as vnode allocation goes. Well, I could possibly live with 256MB, but the vnode/fsnode consumption seems to be getting a bit silly in the memory overhead department, even for machines with 4GB of RAM. It seems like there needs to be fewer of them and/or they need to go on a diet. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Heh heh, humorous lockup
>Since we have increased the hard page table allocation for the kernel to >1G (?) we should be able to safely increase VM_KMEM_SIZE_MAX. I was >thinking of increasing it to 512MB. This increase only effects >large-memory systems. It keeps them from locking up :-) > >Anyone have any objections? Yes, I do - at least with the 512MB figure. That would be half of the 1GB KVA space and large systems really need that space for things like network buffers and other map regions. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Stuck in "objtrm"
You'll want to look primarily in the swap_pager code since it messes with
that (at least it used to - I don't recall what Matt's new code does with it).
There should be various calls to vm_object_pip_* that manipulate the
paging_in_progress number.
-DG
David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com
>On Tuesday, 6th July 1999, Stephen McKay wrote:
>
>>the make world hangs with cc1 in "objtrm"...
>
>I'm having a fun old conversation with myself here! ;-)
>
>Here's some concrete info:
>
>(kgdb) p/x *(struct vm_object*) 0xc32ea21c
>$13 = {object_list = {tqe_next = 0xc3389e58, tqe_prev = 0xc323fdec},
> shadow_head = {tqh_first = 0x0, tqh_last = 0xc32ea224}, shadow_list = {
>tqe_next = 0xc327b8dc, tqe_prev = 0xc32cb734}, memq = {
>tqh_first = 0xc0308e80, tqh_last = 0xc03046ec}, generation = 0x3004,
> type = 0x1, size = 0x2a7, ref_count = 0x0, shadow_count = 0x0,
> pg_color = 0x5, hash_rand = 0xfd9a69d7, flags = 0x21c8,
> paging_in_progress = 0x1, behavior = 0x0, resident_page_count = 0x9,
> backing_object = 0x0, backing_object_offset = 0x0, last_read = 0x14,
> pager_object_list = {tqe_next = 0xc323c438, tqe_prev = 0xc323a424},
> handle = 0x0, un_pager = {vnp = {vnp_size = 0x16}, devp = {devp_pglist = {
>tqh_first = 0x16, tqh_last = 0x0}}, swp = {swp_bcount = 0x16}}}
>
>The high points:
>ref_count=0
>shadow_count=0
>type=1 (OBJT_SWAP)
>paging_in_progress=1
>resident_page_count=9
>flags=0x21c8 (onemapping, mightbedirty, writeable, pipwnt, dead)
>
>A typical memory page from this object:
>
>(kgdb) p/x *(struct vm_page*) 0xc02ffd90
>$14 = {pageq = {tqe_next = 0xc0317dc0, tqe_prev = 0xc02f1960}, hnext = 0x0,
> listq = {tqe_next = 0xc0317dc0, tqe_prev = 0xc02f196c}, object = 0xc32ea21c,
> pindex = 0x2f, phys_addr = 0x4f4000, queue = 0x41, flags = 0x0, pc = 0x34,
> wire_count = 0x0, hold_count = 0x0, act_count = 0x8, busy = 0x0,
> valid = 0xff, dirty = 0xff}
>
>The high points:
>queue=inactive
>flags=0
>wire_count=0
>hold_count=0
>busy=0
>valid=ff
>dirty=ff
>
>All 9 of them are like that. So, no busy or PG_BUSY or anything. No paging
>really in progress after all. So the object's paging_in_progress count is
>out.
>
>Who was watching what code changed recently? Remember I had this problem
>on a kernel from 1999/06/16 too. So it's an "old" problem.
>
>Off to research the next installment...
>
>Stephen.
>
>PS I haven't worked out yet how to find the stack of the errant process.
>Any hints? The stack trace should be helpful.
>
>
>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: net.inet.tcp.always_keepalive on as default ?
>> I don't support increasing the default timeout. That would cause problems >>for a lot of server systems that rely on the relatively short two hour >>default. >>The best I think you could do would be to increase it to something like >>12-24 hours as a default, but even that might be problematical. >> Actually, I think we should leave it alone. I don't mind if people add an >>rc.conf variable, however. > >First of all, our current default is not two hours, but to kill >after 4 hours idle followed by no response for 20min: > > net.inet.tcp.keepidle: 14400 > net.inet.tcp.keepintvl: 150 > >So anyone depending on two hours are screwed already. I believe the above numbers are in slowtimo ticks (500ms), so if you do the math, you come up with 2 hours. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
>In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes: > >>But, consider going back to the discusssions leading up to the Host >>Requirements >>RFC (1122). The particular problem was that the original timeout value for >>keepalives was tiny (a few minutes). 1122 dictated the corrections for this. >>Here are the important points from section 4.2.3.6: > >But RFC 1122 pretty much entirely predates the "modern internet user". While >I fully supported the policy back then, I no longer do. > >I still think the right thing is: > > default to keepalives. > set the timeout to a week. I don't support increasing the default timeout. That would cause problems for a lot of server systems that rely on the relatively short two hour default. The best I think you could do would be to increase it to something like 12-24 hours as a default, but even that might be problematical. Actually, I think we should leave it alone. I don't mind if people add an rc.conf variable, however. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: -stable vs -current (was Re: solid NFS patch #6... )
>> point, we shouldn't be merging stuff back into the -stable branch, only fix >> specific straightforward problems that don't require complete >> re-engineering. > >No new features means stagnation in development. It means that someone >coming to FreeBSD and looking for a feature will only find it in -current, >which, by virtue of being -current, will have other miscellaneous problems. >This person gets annoyed and leaves. Sorry, but this just isn't how our development model has worked over the past 6 years. -stable means it and we are not going to change that. -current is for new features. The only new features that are added to -stable are those which don't affect existing functionality and architectural changes are to be avoid as much as possible. This has been a winning model for us and we're not going to change it. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Porting Greg Lehey's rawio.c from FreeBSD to Linux...
>Matthew Jacob wrote: >> For raw pattern testing Linux has a special challenge since you right >> directly into the buffer cache. There *is* a BLKFLSBUF ioctl that can try >> and force a flush but this probably ought to be written to use O_FSYNC- I >> think that the ll_rw code might use it or an fsync could be done... > >Linux' fsync() works only on directories, not on files. Huh? That doesn't make any sense. The "f" in fsync() stands for "file". -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: support for larger memory
> Time and time again we have all seen people get bit in the rear because >BSDI compatibility was broken. Broken for a good cause, mind you, because >FreeBSD seemed to lose a little of that "power to serve" when it died >horribly on newer servers :) > So, the good news is, we can now support large memory configurations >(and I recall that 4G might not be that far off). The bad news is, the >fairly decent number of programs which are available for BSDI but not >FreeBSD won't run on FreeBSD now. > > Anyway, we all know that. But what I would like to know is: how does >BSDI support large memory configurations? I'm confused on how it is that >the $1000+ commercial BSD derivative can't handle running on newer >servers (although it is pleasing to think a $0 BSD derivative can :) ) >Surely, this cannot be the case, though. > > So, I'm curious, why is it that we needed to break BSDI compatibility in >order to support large memory configurations. It would seem that the two >shouldn't be mutually exclusive. BSD/OS compatibility for v2.0 static binaries can be had again with a few modifications. Someone with access to BSD/OS v2.0 binaries, time, and appropriate knowledge, just needs to make them. The brokeness actually comes from a design screwup that BSDI made in the v2.0 crt0 which they apparantly later fixed in v3.0. We should be able to run v3 and later static binaries. We've never had support for any version of their shared binaries. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: latest -current doesn't execute BSDI-binary bladeenc
>"Daniel O'Connor" writes: >> On 17-Mar-99 Dag-Erling Smorgrav wrote: >> > The bug is on the web site, not in the kernel. David Greenman >> > committed a patch to better support large memory configurations. >> > Unfortunately, it seems this was not possible to achieve without >> > breaking BSDI compatibility. >> Would it be feasable to have an option to switch between the two? > >Probably. I was just about to investigate this possibility. If the remaining userland issues are dealt with, then perhaps. It is currently necessary to rebuild certain utilities after changing this, however, so making it a simple kernel compile time option isn't sufficient. A much better solution would be for someone to spend the time to implement the needed VM frobbing of modifying, at BSDI binary exec-time, the ps_strings address constant in the binary's crt0 that is causing the problem. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: The future of a.out support?
>It was my understanding that the kernel would continue to support >a.out, and I think that's important. If FreeBSD can support SCO, >Linux, Solaris, BSDI, NetBSD and OpenBSD, it seems important that it >should also contain support for FreeBSD, even old, obsolete versions. > >May I assume that this is the case, and that the comment applies only >to what ``make world'' builds? Even so, though, I think that it >is important to provide a way to build the libraries and ld.so if >necessary, though probably not in the world target. Yes, a.out execution support will be standard in FreeBSD for at least several more years. At some point it may become an option, but that's a long way off. The only thing people are talking about is support for building the system binaries in a.out. We're moving to ELF because at some point our "make world" source build system, not to mention the compiler toolchain, will no longer support building a.out binaries. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: KVA/KVM shortages
>> On tuesday I crashed a machine after it ran out of kvm. (dual PII 400 with >> 768MB RAM) poking about in the code adding: >> >> options "VM_KMEM_SIZE=(24*1024*1024)" >> options "VM_KMEM_SIZE_MAX=(128*1024*1024)" >> >> seems like a good way foward. Is it? > >>From what I can see, you shouldn't need to set VM_KMEM_SIZE_MAX unless >you're also setting VM_KMEM_SIZE_SCALE. > >I just committed a tweak that allows you to say: > > set kern.vm.kmem.size= > >at the loader prompt or in /boot/loader.rc to override the default >VM_KMEM_SIZE value. > >If anyone has any more of these tunables that can easily be enhanced >like this, please let me know. Is there a way from the boot loader that one can find out what options are available to be tuned? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
