Re: Recommendation for minor KVM adjustments for the release
- I would like to cap the size of the buffer cache at 200MB, giving us another 70MB or so of KVM which is equivalent to another 30,000 or so nmbclusters. That also seems like overkill for the vast majority of systems. But probably not for the large-memory systems (and on the machines with small memory the limit will be smaller anyway). Having a machine with a few gigs of memory and being able to use only 200MB for the buffer cache seems to be quite bad for a general-purpose machine. Uh, I don't think you understand what this limit is about. It's essentially the limit on the amount of filesystem directory data that can be cached. It does not limit the amount of file data that can be cached - that is only limited by the amount of RAM in the machine. Ahh, thanks for the clarification. I retract my previous email about limiting this as well. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kern/24854: NEWCARD support for aironet driver an(4)
On Sun, Aug 19, 2001 at 09:14:52AM -0400, Jonathan Chen wrote: [summary of past events for the benefit of gnats] - original PR filed for Cisco aironet not working under newcard - My LMC342 works just fine, and I though this might be a bug in newcard (as opposed to the an driver as suggested in the pr), suggested Sam to try the updated newcard (http://people.freebsd.org/~jon/newcard.diff.3) - this patch makes an work under newcard without the proposed changes in the pr. I believe I already tried just uncommenting 'optional ata pccard' with the -current source, without any luck. Sam, I'm not sure what you mean here. What I mean here is that an unpatched -current (as of mid-August) was not resulting in detection of my LMC352. In the current sources, the following in src/sys/conf/files has been commented out: #dev/an/if_an_pccard.c optional an pccard Commenting this out and recompiling did NOT result in a successful attach, at least when I tested this in early August. I'm testing again by backing out of your patch and recompiling, and it turns out that it -does- work now, most likely this was operator error in not uncommenting the the conf/files entry, since I don't see any likely commits that would have changed anything...sigh, sorry for the waste of time. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/conf/files.diff?r1=1.483r2=1.484f=h documents when the line was commented out...it's been that way for a while... The first time I tried it (not in X) removal and reinsertion of the Aironet card was fine. The second time (while in X), removal was ok, but card reinsertion caused a reboot (no panic)... Let me know what you want me to do exactly, in terms of what kind of debugging you need...once I hear back I'll build a debug kernel. Are you sure there is no panic while in X? Your X server might have futzed with the video card so you might not actually see the panic. If you can try to reproduce this in text mode, then the panic message as well as a traceback would be a very good start. -nod- But before you do that, I believe I may have found a fix for a possible panic situation. This panic occurs in witness_destroy as a supervisor read page not present error (I presume while trying to dereference lock). This panic can be easily reproduced by running dhclient an0, removing and reinserting the card, then killing dhclient. The fix appears to be shockingly simple: I'll see if I can reproduce the problem in CLI mode with your patch to if_an_pccard.c diff -u -r1.8 if_an_pccard.c --- sys/dev/an/if_an_pccard.c 2001/05/26 09:26:58 1.8 +++ sys/dev/an/if_an_pccard.c 2001/08/19 12:57:14 @@ -118,6 +118,7 @@ sc-an_gone = 1; bus_teardown_intr(dev, sc-irq_res, sc-irq_handle); an_release_resources(dev); + mtx_destroy(sc-an_mtx); return (0); } Take care, --Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recommendation for minor KVM adjustments for the release
: :David Greenman wrote: : :- I would like to cap the size of the buffer cache at 200MB, : giving us another 70MB or so of KVM which is equivalent to : another 30,000 or so nmbclusters. : :That also seems like overkill for the vast majority of systems. : :But probably not for the large-memory systems (and on the machines :with small memory the limit will be smaller anyway). Having a :machine with a few gigs of memory and being able to use only 200MB :for the buffer cache seems to be quite bad for a general-purpose :machine. : : Uh, I don't think you understand what this limit is about. It's :essentially the limit on the amount of filesystem directory data that :can be cached. It does not limit the amount of file data that can :be cached - that is only limited by the amount of RAM in the machine. : :-DG : :David Greenman :Co-founder, The FreeBSD Project - http://www.freebsd.org :President, TeraSolutions, Inc. - http://www.terasolutions.com Yes, and the buffer cache determines how much dirty file-backed data (via write() or mmap()) the system is allowed to accumulate before it forces it out, which should probably be the greater concern here. The issue we face in regards to these limitations is simply that the kernel only has 1 GB of KVA space available no matter how much physical ram is in the box. We currently scale a number of things based on physical ram - sendfile() buffer space, buffer cache, swap meta space, kernel malloc area, PV Entry space, and so forth. Machine with large amounts of ram wind up eating up so much KVA that simple tuning elements such as increasing the number of NMBCLUSTERS or increasing 'maxusers' can cause the machine to run out of KVA space during the boot process, resulting in a panic. All I am suggesting here is that we throw in some reasonable limits temporarily (until we can come up with a permanent solution), limits which really only effect machines with greater then 1GB of real memory and which can be overriden by kernel options, in order to avoid common tuning configurations (e.g. large number of NMBCLUSTERS, high 'maxusers' specification) from causing unexpected crashes at boot time. This will give us time to come up with a more permanent solution. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recommendation for minor KVM adjustments for the release
: :David Greenman wrote: : :- I would like to cap the size of the buffer cache at 200MB, : giving us another 70MB or so of KVM which is equivalent to : another 30,000 or so nmbclusters. : :That also seems like overkill for the vast majority of systems. : :But probably not for the large-memory systems (and on the machines :with small memory the limit will be smaller anyway). : :-SB I should also say that even in the Linux and Solaris worlds, systems with 4GB of ram wind up being very specific-use systems. Typically such systems are used almost solely to run large databases. For example, so something like Oracle can manage a multi-gigabyte cache. These applications do not actually require the memory to be swap-backed, or file-backed, or really managed at all. In FreeBSD land the use-case would simply be our physical-backed-shared- memory feature. We could implement the 8-byte MMU extensions in the PMAP code as a kernrel option to be able to access ram 4GB without having to change anything else in the kernel (not even vm_page_t or the pmap supporting structures) *IF* we only use the ram 4GB in physical-backed SysV shared memory mappings. This would actually cover 99% of the needs of people who need to run systems with this much ram. There are lots of issues on IA32 in regards to memory 4GB... for example, many PCI cards cannot DMA beyond 4GB. We would avoid these issues as well by only using the memory as physical backing store for SysV shared memory segments. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recommendation for minor KVM adjustments for the release
: :There are two things I would like to commit for the release: : : - I would like to cap the SWAPMETA zone reservation to 70MB, :which allows us to manage a maximum of 29GB worth of swapped :out data. : :This is plenty and saves us 94MB of KVM which is roughly :equivalent to 30,000 nmbclusters/mbufs. : : It's seems really hard to justify even that much SWAPMETA. A more :reasonable amount would be more like 20MB. : : - I would like to cap the size of the buffer cache at 200MB, :giving us another 70MB or so of KVM which is equivalent to :another 30,000 or so nmbclusters. : : That also seems like overkill for the vast majority of systems. : : :-DG : :David Greenman It's not a 1:1 mapping. There is some sparseness to the way SWAPMETA structures are used so 29GB worth of swap-meta supported VM may wind up only being 15GB of actually-swapped-out-dat in reallity. It depends very heavily on the applications being run. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recommendation for minor KVM adjustments for the release
On Sun, 19 Aug 2001, Matt Dillon wrote: : Uh, I don't think you understand what this limit is about. It's :essentially the limit on the amount of filesystem directory data that :can be cached. It does not limit the amount of file data that can :be cached - that is only limited by the amount of RAM in the machine. Yes, and the buffer cache determines how much dirty file-backed data (via write() or mmap()) the system is allowed to accumulate before it forces it out, which should probably be the greater concern here. How hard would it be to allow dirty data in the file cache, without buffer mappings ? regards, Rik -- IA64: a worthy successor to i860. http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Proposed patch (-stable) for minor KVM adjustments for the release
To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [Fwd: Re: slashdotted: /kernel: xl0: no memory for rx list -- packet dropped!]
On Sun, Aug 19, 2001 at 04:51:24PM -0400, Jan Knepper wrote: Hi! Does anyone here know what to do about this? Read the manpage for the xl driver: xl%d: no memory for rx list The driver failed to allocate an mbuf for the receiver ring. Increase the nmbclusters or decrease the mbuf load. You can check the current values with netstat -m. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 4.4-20010815-RC1 GENERIC kernel build fails
On Sun, Aug 19, 2001 at 02:54:59PM -0700, Ed Hudson wrote: cc: Internal compiler error: program ld got fatal signal 11 *** Error code 1 Stop in /usr/src/sys/compile/GENERIC. *** Error code 1 Stop in /usr/src/sys/compile/GENERIC. See the FAQ entry about sig11's. Kris PGP signature
Re: [Fwd: Re: slashdotted: /kernel: xl0: no memory for rx list -- packet dropped!]
I figured that much. What I am looking for is a way to clear the connections still showing LAST_ASK Jan Bernd Walter wrote: [EMAIL PROTECTED]"> On Sun, Aug 19, 2001 at 04:51:24PM -0400, Jan Knepper wrote: Hi!Does anyone here know what to do about this? Read the manpage for the xl driver: xl%d: no memory for rx list The driver failed to allocate an mbuf for the receiver ring.Increase the nmbclusters or decrease the mbuf load.You can check the current values with netstat -m.
Re: kern/24854: NEWCARD support for aironet driver an(4)
On Sun, Aug 19, 2001 at 09:14:52AM -0400, Jonathan Chen wrote: Are you sure there is no panic while in X? Your X server might have futzed with the video card so you might not actually see the panic. If you can try to reproduce this in text mode, then the panic message as well as a traceback would be a very good start. Hmmm...what I saw appeared to be a spontaneous reboot. Forgot to mention that earlier. But before you do that, I believe I may have found a fix for a possible panic situation. This panic occurs in witness_destroy as a supervisor read page not present error (I presume while trying to dereference lock). This panic can be easily reproduced by running dhclient an0, removing and reinserting the card, then killing dhclient. The fix appears to be shockingly simple: diff -u -r1.8 if_an_pccard.c --- sys/dev/an/if_an_pccard.c 2001/05/26 09:26:58 1.8 +++ sys/dev/an/if_an_pccard.c 2001/08/19 12:57:14 @@ -118,6 +118,7 @@ sc-an_gone = 1; bus_teardown_intr(dev, sc-irq_res, sc-irq_handle); an_release_resources(dev); + mtx_destroy(sc-an_mtx); return (0); } Here's the panic and traceback (typed by hand, haven't set up serial console for this). This is BEFORE applying the patch to if_an_pccard.c, as with the patch, no panic occurs. Cool. Fatal trap 12: page fault while in kernel mode fault virtual addresss = 0xc fault code = supervisor read, page not present instruction pointer = 0x8:0xc027a577 stack pointer = 0x10:0xcd861d3c frame pointer = 0x10:0xcd861d48 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IPL = 0 current process = 542 (dhclient) kernel : type 12 trap, code=0 Stopped at witness_destroy+0x237: cmpl %esi,0xc(%edx) db trace witness_destroy(c2577a58,c2577a00,cd861d68,c02acaf4,c2577a58) at witness_destroy +0x237 mtx_destroy(c2577a58,c2577a00,cd861d7c,c02aae8a,c2577a00) at mtx_destory+0x73 bpf_freed(c2577a00,cd8a20a0,cd83db80,cd861da4,c0234e6c) at bpf_freed+0x68 bpfclose)(c2574400,3,2000,cd83db80,c2574400) at bpfclose+0x136 spec_close(cd861dc4,cd861dd8,c02a85d4,cd861dc4,c2511080) at spec_close+0x90 spec_vnoperate(cd861dc4,c2511080,c2511080,c04354a0,cd8a20a0) at spec_vnoperate+0x15 vn_close(cd8a20a0,3,c2572f00,cd83db80,cd861e38) at vn_close+0x40 vn_closefile(c2511080,cd83db80,cd83db80,c2511080,c027ba56) at vn_closefile+0x1f fdrop(c2511080,cd83db80,,c2577b50,c027acac) at fdrop+0xaf closef(c2511080,cd83db80) at closef+0x9b fdfree(cd83db80,cd83dce8) at fdfree+0x38 exit1(cd83db80,f,0,cd83db80,bfff) at exit1+0x61d sigexit(cd83db80,f,,4,cd83db80) at sigexit+0x2f7 postsig(f) at postsig+0xec userret(cd83db80,cd861a8,51f,1b,80a9aa0) at userret+0x5b6 syscall(bfbf002f,80a002f,bfbf002f,bfbfe174,80a9aa0) at syscall+0x67b syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (81, FreeBSD ELF, getpgrp), eip = 0x8055864, esp = 0xbfbfdcd8, ebp = 0xbfbfdd04 --- --Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: IPv6 DAD avoidance
brian Can anybody tell me if it's possbile to tell a given interface brian not to do DAD ? There is a kernel MIB, 'net.inet6.ip6.dad_count'. See inet6(4) manpage for more detail. However, there is no way to stop DAD for any given interfaces; only we have two choices, 'do DAD to any interfaces' or 'do not DAD to all interfaces'. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
