Re: valgrind on FreeBSD 7
On Mon, 17 Mar 2008, Heiko Wundram wrote: Hey all! It's been some time now, and I just wanted to ping quietly whether there's any chance to get (a preview of) the valgrind adapted for FreeBSD 7. out is a futile task, I guess, as I didn't manage to find it in the FreeBSD perforce repository the last time I looked (and was pointed there), but that's probably due to my personal stupidity in using the web-frontend for Perforce (which I find absolutely horrible). Thanks for any pointer/hint/message! -- Heiko Wundram Here's a tarball of what's in perforce right now. I tried it a little bit, and it seemed to work for me. Make sure to install the kernel module! http://www.silby.com/valgrind_freebsd_3.tar.gz But don't send me questions about it - I'm not an expert on it, I'm just the guy who grabbed it from perforce and found that it seems to work. :) -Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patches
On Wed, 22 Aug 2007, shyam burkule wrote: hellow can someone send me patch implementating page replacement algorithm in freeBSD Thanks Shyam No. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Examples on using RTC
On Fri, 16 Feb 2007 [EMAIL PROTECTED] wrote: /usr/ports/emulators/rtc regards, usleep Already using / looked at that. I'm looking for something more in-depth. -Garrett The rtc port's sole purpose is to make the vmware port happier. As you probably saw, it just fakes the functions of the linux rtc device. What other rtc functions do you need? Almost everything the linux rtc device does can be accomplished by raising your system hz and using usleep/select. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where to start?
On Mon, 22 Jan 2007, [EMAIL PROTECTED] wrote: I would guess that if a way could be found to preallocate the journal space (as with mkfile(8) in sufficiently-old systems), and then record its location in a reasonably-secure location (the superblock?), it could be accessed during recovery without reference to possibly-corrupt filesystem metadata. That's the kind of approach I was thinking of. I'm sure it would be a bit of work, but it would be cool. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where to start?
On Fri, 19 Jan 2007, Soeren Straarup wrote: Hi I'm looking for a project. Something that would actually be used. Preferely something with kernel and geom. I have looked over the project page, but not sure where to start. /Soeren I'd like to see the ability to run gjournal without reformatting. If you could create a dummy file inside the filesystem, then use that area for the journal, it might be possible. I'm sure that would let a lot more people see if journalling is right for them. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardening FreeBSD, does anyone have any documentation that may help?
On Tue, 21 Nov 2006, Joerg Sonnenberger wrote: The code is integrated in GCC 4.1, patching if needed at all is quite contained. But we're still running gcc 3.4.6, and won't be moving to gcc 4.1 on 6.x. The gcc 3.4.6 patch is the one we're reluctant to have to support. The ABI impact is limited to the stack guard cookie, the initialisation function and the failure handler. Three different solutions can be used: (1) The code can be part of a separate library (libssp). (2) The code can be part of libc (DragonFly, OpenBSD and glibc do this). (3) Like (2), but the cookie is part of the Thread Control Block, e.g. accessible via %gs. This is done on newer glibc systems and has the advantage of avoiding PIC references. Can you point me to more information on which systems implement #3? The original benchmarks done with Propolice by IBM suggest typical degrations in the area of 2%-5%, depending on how many functions are called and not inlined and how many of them need to get the protection. The site of Etoh has more details. One specific question about performance that came up was how much compiling libc with SSP enabled would impact the performance of applications. I also brought up the topic of whether we might consider using the flag to enable SSP for all functions, rather than just the ones which use strings. We need to gather more empirical data on how many recent buffer overflows have been on non-string arrays. Or is the default SSP option to protect all functions using arrays of any type rather than just arrays of strings? Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] adding two new options to 'cp'
On Wed, 26 Jul 2006, Eric Anderson wrote: I'm tired of trying to use rsync or gcp (which doesn't like symlinks often) to copy trees of files/directories using hard links, so I added the gcp-ish options -a and -l. ... Comments? Flames? Committers willing to commit? Eric Having just read this thread start to finish, I strongly feel that Eric should be given an award for putting up with all the crap he was given and not losing his temper. In sincerely hope that this thread does not scare off others who have local patches that they are considering contributing to FreeBSD. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heavy system load by pagedaemon
On Fri, 12 May 2006, Iasen Kostov wrote: Exactly what i did :). I set vm.pmap.shpgperproc=600 in loader.conf and about 5 min after boot the system paniced and I was not able even to see the message (either because I was pressing enter for the command or it just doesn't wait for a key). Then i set it to 500 in loader at boot time and currently it works but when it crashed used PV entries were ~4 300 000 now they go to ~5 000 000 and it doesn't panic. Which make me think that the panic is not related to setting vm.pmap.shpgperproc to 600 (which could probably lead to KVA exhastion) but to something else. I'll try to increase KVA_PAGES (why isn't there tunable ?) and then set vm.pmap.shpgperproc to some higher value, but this will be after a fresh make world (I cvsuped already :( ) some time soon. Can you provide instructions on how to create a testbench that exhibits these same problems? Can eAccelerator + PHP + Apache + some simple script + apachebench do the trick? If so, that would allow other people to work on the problem. Kris Kennaway seems to like benchmarking; maybe you could pry him temporarily away from MySQL benchmarking to take a look at this. Also note that Peter Wemm has been reducing the size of PV Entries in -current, as he was running out of KVA due to them too - maybe he could provide you with a patch for 6.x with the same feature. Here's part of his description of the change: --- This is important because of the following scenario. If you have a 1GB file (262144 pages) mmap()ed into 50 processes, that requires 13 million pv entries. At 24 bytes per pv entry, that is 314MB of ram and kvm, while at 12 bytes it is 157MB. A 157MB saving is significant. --- HTH, Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heavy system load by pagedaemon
On Fri, 12 May 2006, Iasen Kostov wrote: On Fri, 2006-05-12 at 10:27 -0500, Mike Silbersack wrote: Can you provide instructions on how to create a testbench that exhibits these same problems? Can eAccelerator + PHP + Apache + some simple script + apachebench do the trick? Nope, apache probaly needs to use many pages of shared memory to exhaust the PV Entries (as I understand it). eAccelerator uses shm when it has something to put there and most porbably apache does the same. So I think You'll need a lot of different scripts (and many apache processes) to make eAccelerator cache them and probaly some other media to make apache use shm on it own (I'm realy not sure how apache uses shared memory but it probably does because this problem apears when people are using forking apache). Well, let me restate what I said above. If nobody else is running into this, nobody else will be motivated to fix it. On the other hand, if you put in the time to figure out how others can reproduce it, others then will be able to try to help fixing it. If you don't show a to reproduce it, there's no way it can be fixed. That's realy nice to hear. Interesting thing is that: sysctl vm.zone | grep PV PV ENTRY: 48, 5114880, 4039498, 564470, 236393602 PV Entry's size is 48 here which is even worst than 28 case ... :) Regards. Ah, I was quoting the i386 change. On amd64, he reduced it from 48 bytes to 24 bytes. :) Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: RFC: Adding a ``user'' mount option
On Thu, 6 Apr 2006, Peter Jeremy wrote: On Wed, 2006-Apr-05 12:14:29 -0500, Rick C. Petty wrote: If not operator, then maybe one configurable group, defaulting to operator. Sounds like a good idea. -- Peter Jeremy What group do NFS and SMBFS shares belong to? Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: Adding a ``user'' mount option
On Mon, 3 Apr 2006, Joe Marcus Clarke wrote: I know we have vfs.usermount, but this is not always sufficient since the user has to own the mount point in question. What I propose is to add a ``user'' mount option ? la Linux. This would make mount and umount setuid root, but would allow much more flexibility when it comes to removable media and desktop systems. I'm not a src committer, so this isn't a threat to commit. I'm more interested in getting feedback, and hopefully some src committer interest. I think this would really benefit desktop FreeBSD. http://www.marcuscom.com/downloads/usermount.diff Joe That is a very useful feature, I think it would be a welcome addition to FreeBSD. Making it work for floppies / CDs should be pretty easy, but since you're adding it as a new feature for us, can you consider making it even more flexible? What I mean is this: We have smbfs support. It would be nice if usermount supported wildcards, so that you could say that user home directories on the samba server 10.2.2.3 could be usermounted by users to the fileserver directory in their home directory. If that worked out of the box, it would really rock. Basic usermount support only would require you to add an entry for each user, which is not convenient. Mike Silby Silbersack___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VMWARE GSX Port?
On Sat, 25 Feb 2006, Scott Long wrote: Ashok Shrestha wrote: VMWARE GSX was released recently for free. [http://www.vmware.com/news/releases/server_beta.html] Is anyone working on a port for this? I've started on it, but I haven't made much progress yet. Scott Anyone who's interested in working on it should make sure to start with the VMWare 3 port (which works at present), and Orlando's beta 4.5 port: http://www.break.net/orlando/freebsd.html Also of major use would be the merged linux vmware modules available at: http://knihovny.cvut.cz/ftp/pub/vmware/ (or more specifically) http://knihovny.cvut.cz/ftp/pub/vmware/vmware-any-any-update98.tar.gz This has support for VMWare 1 through 5.5, so if you take our version 3/4 support and this code, you should be able to see what's left to implement. So, support SHOULD be possible, it's just a matter of someone putting in the time to get it all working. (I do not have any such time, unfortunately.) Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Named requests filling up T1
Thanks Matt, The answer to both is no. The domain doesn't resolve either (v.tn.co.za). It looks like the source IP changes too...sigh I tried a whois on the source IP and it was not found, so it may be spoofed? Or someone has a very messed up server... There was a thread on bugtraq about this, you're either being attacked or are being used to attack someone else. Reconfigure BIND so that it ignores recursive queries originating from outside your network - at least that will save your outbound bandwidth. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6-STABLE: HZ1000, RFC1323 non-compliance, and PF
On Fri, 16 Dec 2005, Alan Amesbury wrote: Because we have several systems equipped with em(4)-compatible cards that are intended to accept traffic at gigabit speeds, I've configured them with HZ=2000, per the notes above. However, 6-STABLE has also included some newer pf(4) code, which is fundamentally incompatible with a HZ setting this high. I did some digging and eventually came up with this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/61404 I'll throw it on my to-do list, hopefully I'll get to it over the next few weeks. I'm going to fix it a bit differently than that patch does, though. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mmap() sendfile()
On Mon, 12 Dec 2005, Cedric Tabary wrote: If it is true, doing a sendfile() on some very big files (even if not keeping the descriptor open after) will kill the cache ? Please help me to understand why this patch ? and the difference between sendfile() and mmap() at the memory or cache level.. Cédric My memory escapes me on all the details, but there were two potential reasons not to use sendfile with 4.x that no longer apply in 5.x and above: 1. Sendfile used to send small files inefficiently, sending the http headers in one packet and the data in another. I fixed this in 5.x. 2. Alan Cox improved the memory efficiency of sendfile greatly, it now uses a single kernel buffer for all copies of the same block of the same file, whereas the old implementation made an in-kernel copy of each block, making it no more memory efficient than using mbufs. So, if there was a reason to not use sendfile under 4.x, it's probably not true anymore. Someone sent me a patch to thttpd which made it more efficient on FreeBSD a looong time ago, I don't recall what changes he had made. Mike Silby Silbersack___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: select(2) timeout precision
On Tue, 1 Nov 2005, Viktor Vasilev wrote: With FreeBSD 5.4-RELEASE I almost constantly get ~2 microseconds delta. That is with 100HZ kernel on PIII 500MHz or Sempron 64 2800+ Put kern.hz=1000 in /boot/loader.conf to kick it up to 1000Hz, that should improve the accuracy a lot. The optimizations in the url someone else posted should probably be integrated into FreeBSD, but moving to a higher Hz setting is a necessity in either case. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limiting closed port RST response from XXX to 200...
On Tue, 18 Oct 2005, Joerg Sonnenberger wrote: On Mon, Oct 17, 2005 at 05:51:15PM -0700, [EMAIL PROTECTED] wrote: Hi, On a server I'm benchmark testing, via local host, I'm getting Limiting closed port RST response from to 200 packets/sec on the console when I'm running a lot of local connections very quickly all at once (about 7500 per second). I've added the following: Check that you don't run out of TCP ports. Adjusting MSS might help, netstat -an would show a long list of ports. Joerg The 5.x and 6.x series don't let you run out of ports due to TIME_WAIT sockets accumulating, so please stop spreading the advice that people should twiddle with the MSL. It's no longer useful advice. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Limiting closed port RST response from XXX to 200...
Hi, On a server I'm benchmark testing, via local host, I'm getting Limiting closed port RST response from to 200 packets/sec on the console when I'm running a lot of local connections very quickly all at once (about 7500 per second). I've added the following: net.inet.tcp.log_in_vain: 0 net.inet.udp.log_in_vain: 0 but still does it. Is there any way to disable it short of installing ipf? I'd like to see what the theoretical limit of the machine is without it perhaps limiting connections in some manner. Thanks! Ray Er, if you're seeing those messages, your benchmark is going very awry! The kernel is telling you that 7500 junk packets per second are coming in, but that it has chosen to send RST packets in response to only 200 of them. What you should be asking is - why are 7500 junk packets per second coming into the system? This could be due to a flaw in how your benchmark is setup (if you're trying to connect to a port that has no listening service or DNS lookups to a nonexistent DNS server?), or it could be some kernel bug you've uncovered. If it's the latter, then I would be very interested in helping you get it fixed. There is a sysctl for disabling the reset rate limiting, but I would suggest that you track down the source of the problem before resorting to disabling the feature. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: JFS2 on freebsd
On Fri, 9 Sep 2005, Kamal R. Prasad wrote: would a port of JFS2 be of interest to freebsd core? thanks -kamal There are many things that would be of interest to FreeBSD users, but that's not a good reason to start a project. If you're motivated only because you think others desire your work, you'll probably give up when you have to start dealing with all the realities of the project. However, if you're motivated because *you* want to port JFS2, then you'll probably do a good job of it. So, of course support for new filesystem support is good, but my personal opinion is that JFS2 isn't worth your time, for two reasons: a) Even if it's BSD licensed, it's unlikely to displace UFS as our default filesystem. b) It's not a widely used filesystem, so it doesn't really increase our interoperability with other OSes. OTOH, updating our ext2 code, or ntfs code (if that's even possible) would be something of use to many people, I suspect. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: JFS2 on freebsd
On Fri, 9 Sep 2005, Sergey Babkin wrote: OTOH, updating our ext2 code, or ntfs code (if that's even possible) would be something of use to many people, I suspect. Why not go for ext3 instead of JFS then? It has journaling in it. -SB I was thinking that as I wrote it as well, I'm not sure why I didn't state it. But before ext3's journalling extensions could be implemented, ext2 would have to be brought up to date. Also, it would be nice if ext2 could be reimplemented in BSD licensed code before undergoing that ext3 conversion. :) Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Parking disk drive heads
On Fri, 19 Aug 2005, Doug Ambrisko wrote: Flash is nice but it has some issues. Atleast dropping it isn't one! Doug A. I'd be really happy if I could get a USB flash drive to last more than 8 months. Luckily, I started weekly backups after the first failure. That helped a lot when the second failure happened. The weird ways flash goes bad really makes me want to run something with full checksums (like ZFS) on it. Alas, even if I hacked up UFS to support such features, I suspect the W2K machines at work would be unhappy with it. :) I wonder if I should hack together a script that does MD5s during the backup process and notifies me if untouched files start changing... Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel code of reseting/ignoring tcp SYN packets
On Sat, 6 Aug 2005, Minh Tran wrote: Would anyone have some hints on the clean way of injecting some code to deal with SYN packets or could you give me some ideas on which files i should look at? I really appreciate that. I saw some promising files in src/sys/netinet but they are not all clear in my mind. Thanks heaps! I don't have any idea what you are asking, so I can't answer your question. Before proceeding, it would probably be worth your while to find a copy of Stevens's TCP/IP Illustrated Volume 2 and at least skim it so that you have a better idea of how the connection establishment process works. The book describes an earlier version of the BSD TCP/IP stack, but much still applies. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ProPolice: best way to fill canary
On Sat, 9 Jul 2005, Jeremie Le Hen wrote: Thanks for you answer. In that case, which sysctl should we use ? * OpenBSD's kern.arnd (KERN_ARND) which is a front-end to the arc4random() function ? * NetBSD's kern.urandom (KERN_URND) which is using the rnd(4) pseudo-device. They also have KERN_ARND in sysctl.h, which is no more than a #define of KERN_URND, for compatibility with OpenBSD. Usually, I noticed that FreeBSD used to be as close as possible with NetBSD. But I would like to hear the voice of a more experienced hacker about this. Thanks. Best regards, -- Jeremie Le Hen I wouldn't say that we favor code from any one project over another, every situation is different. In this case, I'm personally rather indifferent - both RNGs should supply good entropy. Arc4 may be a bit faster (I don't know if anyone has benchmarked by how much), so for this purpose it would seem to be the one to use. I can commit any patches you have after the 6.0 code freeze ends, which should be in the next few weeks. (It can be MFC'd to 6.0 and 5.4 after that as well.) Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ProPolice: best way to fill canary
On Fri, 8 Jul 2005, Jeremie Le Hen wrote: The second method requires to introduce the kern.arnd sysctl (KERN_ARND). FYI, note that NetBSD has kern.urandom (KERN_URND) and they define KERN_ARND to be an alias to this. Your comments will be welcome. Best regards, -- Jeremie Le Hen I don't see any problem with introducing such a sysctl, if it would make the propolice patch simpler. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improving bind 9 for money
On Thu, 26 May 2005, Attila Nagy wrote: Hello, I'm just doing a quick poll. If I would have a given amount of money and I would like to make bind 9 go faster (both in the terms of caching and authoritative performance) on FreeBSD, could I find the appropriate people for the job? The modifications would remain under the same license as bind itself. If somebody feels that she/he has the competence and the time to work on this, please mail me privately. Thanks, and sorry for the quite off topic message. -- Attila Nagy e-mail: [EMAIL PROTECTED] If you have some sort of dns benchmarking program, it would be interesting if you could add it to ports; rwatson has done a lot of benchmarking with mysql on freebsd 5 vs 6, it would be interesting to see if BIND performance has changed in a similar fashion. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Broadcom 5789
On Tue, 17 May 2005 [EMAIL PROTECTED] wrote: Could someone with knowledge of the Broadcom ethernet chips and the bge driver check if adding support for the 5789 is really that easy and if yes, initiate the needed steps to get the device id's in the kernel? Adding support for new chips often is that easy, if you look in the 3com xl and Intel fxp driver histories you'll find tons of changes which are just like the one you made below. I'll commit the change if you can remind me to do so later in the week (Thursday or Friday.) Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ip_reass() - possibly incorrect goto
On Wed, 23 Mar 2005, Maxim Konovalov wrote: On Tue, 22 Mar 2005, 12:08-0800, [EMAIL PROTECTED] wrote: Hi hackers, I am looking at the ip_reass() routine. In case of the 1st fragment we create the reassembly queue. After the queue has been inserted in the hash bucket, the if () code does a goto inserted. Should this be changed to goto done instead? Any code that is executed for the 1st fragment, like frag per packet limiting and complete reassembly are not valid. Am I mistaken? Yep, it seems you are right. The second micro optimization - drop the fragment early if maxfragsperpacket == 0. Andre, Mike, what do you think? Looks good to me. Please tell us if you come up with any more optimizations for the reassembly code, Vijay. On a related note... While looking through the code, I think I figured out a way to avoid IDSes if you're trying to mess with a FreeBSD machine: /* * Handle ECN by comparing this segment with the first one; * if CE is set, do not lose CE. * drop if CE and not-ECT are mixed for the same packet. */ Couldn't you send a fragment with half the exploit payload (too short for the IDS to match), then send a packet with a different ECN status to overwrite that fragment (at least in the IDS's buffer, but not in FreeBSD's, since it would be dropped), and then send the second part of the payload? Hmmm... Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Priority Increasing
On Sun, 27 Feb 2005, Ashwin Chandra wrote: Hi all, Ive been trying to counter the malicious effects of a forkbomb by setting the forkbomb parent and children to a PRI_MAX priority, although this is not having any effect on the system load. Basically in my code when I know which process is acting maliciously (forkbomb), I run the following simple code: If you're sure that the program is a forkbomb, why not modify the forkbomb protection that is already present in kern_fork.c: tsleep(forksleep, PUSER, fork, hz / 2); What it does at present is whenever you try to fork and you've hit your process limit (see limits(1)), it puts your process to sleep for .5 seconds. If you have a better way to tell if something is a forkbomb, why not just do the same thing, perhaps with a shorter sleep. Don't try too hard to defeat forkbombs, though. Whenever it's been discussed, someone has invariably pointed out that you could just fork 750 processes, and then have those 750 do something else which is kernel intensive, like reading/writing 1 byte at a time. In other words, limiting the maximum number of processes a user can have must be part of the equation - and we probably set that limit too high by default. :) Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: remote connection to mysql
On Mon, 21 Feb 2005, Matt wrote: Hi, I'm trying to connect remotely to my database server. It is MySQL 4.1.7 which I install from ports. I created a user with permissions to connect from any remote location. I'm using Perl DBI, like this: Are you sure that you set up MySQL to accept TCP connections? I think it defaults to local sockets only; you can verify by running netstat -na and seeing if there's anything listening on port 3306. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bus_dmamem_alloc strangeness
On Thu, 17 Feb 2005, Gerald Heinig wrote: Hi hackers, I've come across weird behaviour in bus_dmamem_alloc() whilst trying to allocate small memory blocks (less than PAGE_SIZE) which have to be aligned to PAGE_SIZE. My segment size is 2048, my maximum number of segments is 1 (it MUST be contiguous), my max. total segment size is also 2048 and my alignment constraint is 4k (PAGE_SIZE). However, the DMA memory I'm getting from bus_dmamem_alloc() is NOT aligned to 4k. You should e-mail Scott Long ([EMAIL PROTECTED]) about this directly. I believe that he has been working on related changes to busdma recently, but I'm not sure which branches have received his improvements. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: malloc vs ptmalloc2
On Mon, 14 Feb 2005, Uwe Doering wrote: Just from memory, doesn't Linux' malloc require kernel support for re-mapping memory regions, which is not available in FreeBSD? This issue came up in the discussion about FreeBSD's anemic realloc performance. Or has this kernel functionality been added to recent versions of FreeBSD? You may want to investigate this before you invest too much time into your porting effort. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers I thought that thread was speculative, with someone saying it would be nice if realloc had kernel help, or something like that. However, if that feature is used by some malloc library which might be portable to FreeBSD (so that the feature's use can be shown), I'd suggest that someone contact Alan Cox ([EMAIL PROTECTED]) - he seems to be working on optimizing the VM system right now, so he'd be the person who could code up support for this feature quickest. Mike Silby Silbersack ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple hard disk failures - coincidence ?
On Sat, 18 Dec 2004, Gary Corcoran wrote: I've just had *THREE* Maxtor 250GB hard disk failures on my FreeBSD 4.10 server within a matter of days. One I could attribute to actual failure. Two made me suspicious. Three has me wondering if this is some software problem... (or a conspiracy (just kidding) ;-) ) Are the errors occuring at around the same block numbers? I recall a thread on -current talking about how some drives reported failures around the 133GB mark. Soren recently committed a patch to -current changing the point at which 48bit addressing is used to work around this. It may be worth investigating. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Rebooting the kernel without resetting uptime?
On Fri, 3 Dec 2004, Stefan Midjich wrote: Hi I know a guy i respect on IRC told me this is not possible but since this is the hackers list i thought the topic at least deserves a discussion. I guess i wont be able to sit still until someone either does it or shows me why it can't be done. Faking the uptime which is retrieved by netcraft and other services which check TCP timestamps would be easy. Faking your local uptime might be a bit more work, there could be sideeffects of accelerating the timecounters. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HD Mirroring
On Mon, 29 Nov 2004, Andre Oppermann wrote: If you have many TCP connections to one target it may happen that you get the same source port on the originator again within the TIME_WAIT timeout. And if the ISN wrapped in the meantime the new connection will 'hang'. Just to clear this up, the problem with randomized source ports and TIME_WAIT is not that the ISN is wrapping. The problem is that if a port is reused too quickly, the ISN has not incremented enough and is less than the final sequence number of the previous connection. There's code in 5.3 which eliminates this problem by incrementing a global offset for each connection established, I will probably MFC it before 4.11 so that this problem is over with once and for all. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MYSQL connection problem (correction re-post)
On Tue, 30 Nov 2004 [EMAIL PROTECTED] wrote: Hi Arun; hrmm. Can you try switching the port to another port number? Perhaps a lower port number? See if you can get it to connect in that way? Makes no difference Try doing a tcpdump -n -i lo0 and see what traffic occurs when you make the connection attempt. It should only be a few lines, so posting to this thread will be fine. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS
On Wed, 15 Sep 2004, Sam wrote: Call me crazy, but does anyone else see this as hooey? 2^64 512B sectors is 8192 zettabytes (zetta, exa, peta, tera, ...). I'm also wondering what perversion of moore's law is applicable to storage consumption. Crappy marketing articles. Sam Maybe they're actually doing some sort of sub-sector addressing, so the 2^64 refers to the number of bytes on the disk, rather than the number of sectors. That would bring it down by 2^9, and might make the argument more potent. It'll be interesting to see what Hans Reiser says about it... Obviously he's biased towards ReiserFS, but he's certainly much more familiar with FS design than most of us, and will certainly have opinions. :) Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS
On Thu, 16 Sep 2004, Gary Corcoran wrote: Yeah, okay, there's multiple definitions of what 64-bit filesystem is referring to. So what are FreeBSD's current filesystem limitations? 2^64 bytes files, and 2^64 blocks per filesystem? But I seem to recall some problems as people were approaching a terabyte or two ??? Gary Scott Long is addressing this: http://www.freebsd.org/projects/bigdisk/ (To sum up, the filesystem is fine with 1TB, the utilities aren't.) Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAPI DVDwriters (not) to buy?
On Mon, 9 Aug 2004, Wilko Bulte wrote: On Mon, Aug 09, 2004 at 10:29:35PM +0200, Søren Schmidt wrote.. duallayer media yet as I havn't been able to locate any that didn't cost an arm and a leg :) Oh, its slow for ripping as they have put in a lock for that, you can get around it by loading new firmware that removes that lock (and region locking as well if needed) from here http://tdb.rpc1.org/index.htm Ah, have you tried that f/w? thanks a bunch! W/ -- Wilko Bulte [EMAIL PROTECTED] I have a ND-1100A, and it has been working great with the modified firmware. The 1100A only burns +R discs, but it has worked great for me so far; I don't think that it has burned a single coaster yet. However, I have only used it under Windows, I can't speak for its FreeBSD compatibility. If I was to upgrade, I would definitely choose another NEC burner. (Which is funny, because I bought the original because it was the cheapest one for sale at a local store at the time. Only after I got it home and out of the box did I find out that it was a rebranded NEC. I'm lucky that I didn't get a piece of junk!) Mike Silby Silbersack___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network buffer allocations: mbuma, PLEASE TEST
On Wed, 26 May 2004, Bosko Milekic wrote: Hi, If you're running -CURRENT, please test this: http://people.freebsd.org/~bmilekic/code/mbuma2.diff It is several extensions to UMA and mbuf cluster allocation built on top of it. Sounds good in theory, but I'm too lazy to test it. The m_getcl changes looked ok to my quick read of the patch, but I didn't look through the mbuma implementation at all. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device pooling and high interrupts
On Sat, 24 Apr 2004, GiZmen wrote: Hello, I am runnign freebsd 5.2.1 on 386 arch with two rl lan cards. My mainboard is on VIA KT 266A with AMD athlon 1.1. I read man polling and i have HZ=1000. My problem is that when i set up sysctl variable kern.polling.enable=1 my interrupts greatly increase. When my system is idle and indicate 0-1% interrupts with out polling. and when i turn on polling interrupts goes up to about 20% on idle system. Is it normal ? I never before use polling and i dont know that i have something bad in my system ? Can somebody explain me this ? thx -- Best Regards: GiZmen Ruslan can probably jump in and give you a better explanation than I can, but I'll try to provide a quick answer. In short, the rl cards + driver are not well suited to polling and will not work well with it enabled. Support for polling on rl may in fact be removed as a result of this. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC include files conundrum.
On Sun, 14 Mar 2004, David Gilbert wrote: The C++ FAQ referred to by iostream (not iostream.h) seems to imply that you should use iostream and sstream (no .h)... but including those files imposes a very different standard that this port is not ready to accept. It appears that (among other things that I havn't found yet) all 'istream' must be written 'std::istream' ... etc. So what's the solution? Dave. #include blahblahblah using namespace STD; or something similar should restore the behavior the application is expecting. (Apparently including namespace std is evil, and this is why the FAQs aren't helpful in telling you this.) Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SPAM/virii apparently from freeBSD addresses.
On Sun, 29 Feb 2004, Julian Elischer wrote: Somewhere out there there is a ?Virus?/?Hacker?/?Spammer? getting really annoying.. Yeah, I'm getting it too. Worst part is, clamav 0.65 doesn't pick it up. I'm waiting for the 0.67 port to be committed... Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: em0, polling performance, P4 2.8ghz FSB 800mhz
On Sat, 28 Feb 2004, Don Bowman wrote: You could use ipfw to limit the damage of a syn flood, e.g. a keep-state rule with a limit of ~2-5 per source IP, lower the timeouts, increase the hash buckets in ipfw, etc. This would use a mask on src-ip of all bits. something like: allow tcp from any to any setup limit src-addr 2 this would only allow 2 concurrent TCP sessions per unique source address. Depends on the syn flood you are expecting to experience. You could also use dummynet to shape syn traffic to a fixed level i suppose. Does that really help? If so, we need to optimize the syncache. :( Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current
On Mon, 16 Feb 2004, Ganbold wrote: Hi, I installed FreeBSD 5.2 and updated using cvsup on Dell Poweredge 1600SC. However still FreeBSD doesn't recognize network card. It has onboard Intel Pro/1000 MT card. What should I do in order to use this onboard Intel PRO/1000 card? I checked Intel web site and found only em driver for FreeBSD 4.7. Where can I find latest driver for Intel PRO/1000 MT network card? tia, Ganbold The driver in 5.2 should support that card. Can you post the results of a pciconf -lv so we can see the PCI ID of your specific card? Thanks, Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel PRO/1000 MT onboard network card problem in FreeBSD 5.2-current
On Mon, 16 Feb 2004, Ganbold wrote: Hi, Following is the output of pciconf -lv command: As others have pointed out, the problem isn't in the em driver, since the card isn't even showing up in pciconf. Either it's somehow not enabled, or FreeBSD isn't detecting the PCI bridge that the card is connected to. If you're running in ACPI mode, I suggest that you try running without ACPI and see if that changes anything. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Obtaining 75k (active) concurrent tcp sessions..
On Thu, 12 Feb 2004, Bill wrote: I read a post that was sent to freebsd-hackers, which mentioned an individual was able to obtain 1.6 million concurrent tcp sessions, so I assume it's possible. That was with a heavily modified version of FreeBSD, you wouldn't be able to hit 1.6 million out of the box. My goal is to setup a server, which is capable of accepting at least 75k tcp connections to perform some firewall stress tests at work. Given that information on this subject is quite scarce, I thought I'd post this question and see what type of response I get back. Any assistance or suggestions would be greatly appreciated, Thanks in advance, -=-Bill-=- I've run tests up to a few thousand connections, I believe that 75000 should be doable, but it will take tuning. Start with 5000 and keep increasing in increments of 5000 from there, upping values for various resource limits as you hit them. I think that maxsockets, mbuf clusters, and maxfiles will be your main limitations... they should all scale to 75000, but I'm not sure how many people have done so. Now, if you want good performance... that could be another story. However, if all you're doing is having a sample app which accepts connections and holds them open until the client hangs up, then you should be able to do it. (If you were sending real data, then the amount of memory being used for socket buffers might become a problem.) Note that for the client side of those connections, you may need more than one machine; with only ~65535 possible ephemeral ports available per IP (and it being tough to use the same ephemeral port on different IPs with the BSD network stack), it'd be best to just do two client machines with 75000/2 connections each. (There is no such limit for the server side, of course.) Post to this list if you run into any problems, or find any specific issues that prevent you from reaching the goal. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: select, sendto and ENOBUFS
On Tue, 10 Feb 2004, Andrew wrote: The conclusion being that send, sendto and select will never block on a UDP socket and the man page just doesn't make it too clear. I'm assuming it is the same for raw sockets. UNPv1 section 6.3 seems to say that select should work for UDP...Part 2 under Under What Conditions Is a Descriptor Ready certainly indicates that select should work. Anyway a bug or not, is there a better work around than sleeping? I'm guessing not... Thanks, Andrew Well, one workaround would be to figure out a way to have the kernel implement the behavior you desire. :) I doubt that anyone will put effort into this problem soon; it looks like it would be quite a large change to the network stack, and we all have plenty of projects to work on. Maybe you could figure out where in the kernel the ENOBUFS is occuring, and then add a tsleep which would be woken when the transmit queue cleared a bit. That would introduce unexpected blocking, but I can't imagine that waiting for a few packets to exit the queue would take much time. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [call for helpers!] Tuning for the Beaver Challenge
Bascially everything in section 2.2.3 (/etc/sysctl.conf) is wrong; some values may need tweaking, but changing them blindly will not be helpful. The one setting that I do suggest you keep is: kern.ipc.somaxconn=512 (128 may be too low for http testing) The settings from section 2.2.4 will _probably_ be ok, but you'll have to run netstat -m after a benchmarking run to really know. One setting which you'll need to change for the apache2 run is kern.ipc.nsfbufs. Unfortunately, -stable doesn't have any way to tell if you're running out, so you'll have to just guess there. Under -current, netstat -m will tell you what you need to know. Also, you'll probably want to increase KVA_PAGES from 256 to 512 so that the kernel does not run out of memory. Under section 2.2.7, take out the section talking about CPU_FASTER_5X86_FPU through CPU_UPGRADE_HW_CACHE - none of these options is going to help, and it will just increase the likelyhood that something goes wrong. In general, it appears that you can run most of the benchmarks locally, so I suggest that you do that when trying to decide how to tweak settings. For the threads-related benchmarks (volcanomark and apache2 with worker) start asking for help on the -threads mailing list. This is the one thing that is likely to benefit from tweaking. Mike Silby Silbersack On Tue, 10 Feb 2004, Dung Patrick wrote: Hi Beaver Challenge 2004 is coming!. Details in http://osuosl.org/benchmarks/bc/ We are preparing the tuning guide. Definitely we need suggestions and comments. Please see this forum to view the latest tuning guide: http://osuosl.org/forums/viewforum.php?f=8 Attached is a ver0.4 of the tuning guide. Regards Patrick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems resolving bsdcan.org?
On Sun, 25 Jan 2004, Dan Langille wrote: I've had reports of people not being able to resolve hostnames for bsdcan.org. I do know that one of the domain's DNS servers is offline (m20.unixathome.org). But the other (nezlok.unixathome.org) is up and accepting queries (at least for all my attempts). I can't see the problem. Can you? Thanks. -- Dan Langille : http://www.langille.org/ AFAIK, older versions of bind used to not handle the dead server case well at all. Perhaps people are still running older (unpatched), older (patched), or other vendor with the same bug DNS servers. I know this only because it happened to me back in 1999 or so, and was really frustrating (even though I still had 2/3 servers working!) IIRC, these older servers *did* handle the case where they received an icmp unreachable message fine, and just went on to the next machine; could you have another computer take over the dead DNS server's IP and run no services on it? Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: XL driver checksum producing corrupted but checksum-correct packets
On Sat, 24 Jan 2004, Sam Smith wrote: The thread on the OpenBSD list now contains a patch which seems to fix the problem (for me, on OpenBSD, shifting data by both NFS and ftp doing md5 checksums on the files at both ends). Although it doesn't seem to turn off hardware checksums (which is what I think it should do). Regards Sam Turning off hardware checksumming is exactly what that patch does. This doesn't add any new information to the discussion, unfortunately. You don't happen to have the same type of motherboard chipset Matt does, do you? We could be barking up the wrong branch of a tree... Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: XL driver checksum producing corrupted but checksum-correct packets
On Sat, 24 Jan 2004, Robert Watson wrote: To pick up the corrupted packet on the machine where the corruption is occurring, you might want to try hooking up the UDP checksum drop case to BPF_MTAP() for a special BPF device or rule, or have it spit them into a raw socket (probably easier). He said that the packet's checksum passes, but it is corrupt, so this won't work. I suppose that one thing we could do in the long run to help detect this sort of corruption would be to import OpenBSD's TCP MD5 support and ensure that packets which fail the md5 or fail the checksum are logged so that they can be investigated. Of course, that's adding data to the packet, and heisenberg wouldn't be too happy about that. :) Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [CHECKER] bugs in FreeBSD
On Sun, 18 Jan 2004, Matthew Dillon wrote: Well, this is fun. There are over 460 files in the 5.x source tree (360 in DFly) that make calls to malloc(... M_NOWAIT), and so far about 80% of the calls that I've reviewed generate inappropriate side effects when/if a failure occurs. CAM is the biggest violator... it even has a few panic() conditionals if a malloc(... M_NOWAIT) fails. Not Fun! I keep getting the urge to write a simple failure generator for malloc / m_get / etc that would compare the caller's address to a linked list of previous callers so that you could ensure that you would get exactly one failure returned to malloc() call in the system. This would guarantee better coverage than random failures, which aren't likely to find the bulk of the failure cases. Another interesting debug idea would be to extend the above idea, and have seperate malloc buckets for each caller, along with cookies / canary values before and after each piece of data; this could be used to figure out *exactly* which function is causing memory corruption. Of course, I found so many problems when I wrote the MBUF_STRESS_TEST code that I really don't want to think about how long fixing all the bugs exposed by the above two tests would take. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.x source update and compilation problem in HP Vectra VE18
On Tue, 30 Dec 2003, Ganbold wrote: Hi, I installed FreeBSD 5.1 in HP Vectra VE18 PIII 450MHz with 128MB RAM and 4GB HDD. However I'm having problem compiling sources. Whenever I try to make buildworld make stops sometime later saying some variable not found etc. When I check As has already been pointed out, this sounds like bad ram or some other flaky hardware. Does this computer work well under load with whatever OS was on it previously? You might want to try memtest, available from http://www.memtest86.com/ ; it might be able to help diagnose the problem. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: support for __thread
On Sun, 21 Dec 2003, Alfred Perlstein wrote: Any idea of how much effort it would take? I have no clue as to how to fix our toolchain, gooing the work in ld.so doesn't see that awful, but it's not trivial either: http://people.freebsd.org/~alfred/tls.pdf I want a threaded webstone so that I can generate a lot more load with wimpier client boxes on FreeBSD. While you're working on gcc / our linker, you may want to investigate this article that I just saw on news.google.com as well: --- GCC summit in Kuwait concludes meetings, approves ''anti-terrorism'' agreement --- I'm not sure exactly what OS support that requires, but having it would certainly put us ahead of OpenBSD's ProPolice + nonexec stack! Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adding more ram
On Wed, 10 Dec 2003 [EMAIL PROTECTED] wrote: Hi all. I have a server with 1GB of RAM and a swap partition of 2GB i will upgrade the memory server to 2GB so my questions are: should i fix the swap partition to have now 4GB of space ? what other changes do i have to make to my system after adding more ram ? regards. Dan's advice seems good; swapping more than a gig of data would be awful. I'm replying because I want to answer your real question. g The notion of swap = 2 x ram is an old one, and is no longer applicable. (Some) older VM systems used very simplistic swapping mechanisms, which required entire processes to be swapped, thereby requiring large amounts of swap space. FreeBSD (and other modern OSes) page out to the swap file in increments of 4K pages, and do so in a flexible manner. As a result, you should always have *some* swap space to handle overload cases, but it's not necessary to keep any specific ram to swap ratio. (Actually, the term swapping is still used inside the FreeBSD kernel, but it only applies to paging out the last 20K or so of a process's memory.) Now, to contradict myself, there *is* a reason that you might wish to have a larger swapfile. Taking a crashdump requires that the swap file must be of the size RAM + 64K or so. Hence, your present swap file might be slightly too small to take a crashdump once you upgrade to 2G ram. Whether this is an issue for you or not depends on how often your machine crashes and whether you wish to debug it. :) Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Update: Debox sendfile modifications
On Wed, 5 Nov 2003, Vivek Pai wrote: If you were to have sendfile issue the disk reads, how would you signal completion? I guess one approach is to make the socket buffer appear to have no space while the sendfile-initiated read is in progress, but it seems to me that such an approach would be considered too ugly. It would cause the least modification to applications, because otherwise apps need to disable interest on the socket having space, and re-enable it after getting notified that the sendfile-initiated read (and transfer) completed. Am I missing something? -Vivek I'm not quite certain how I would do it yet. At this point in time I'm just brainstorming. I have some other things I'd like to work on in the next few weeks, I'll sit down and think about this more in late November / early December if I'm still in the right mindset. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.1-p10 reproducible crash with Apache2
On Wed, 5 Nov 2003, [ISO-8859-1] Branko F. Grac(nar wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Silbersack wrote: | Can you try updating to 5.1-current and see if the situation changes at | all? A lot has changed since 5.1-release. If it's still broken in | 5.1-current, we can take a look into it. | | Thanks, I tried today with yesterday's -CURRENT. Same symptoms. No kernel panic, just lockup. Brane Ok, submit a PR with clear details on how to recreate the problem, and we'll see if someone can take a look into it. I'm too busy to look at it, but at least putting it in a PR will ensure that it doesn't get too lost. Once the PR is filed, you might want to try asking on the freebsd-threads list; it sounds like the issue might be thread-related. (Note that your original e-mail might contain enough detail, I'm not certain; I just skimmed it. Filing a good PR is important either way, mailing list messages get easily lost.) Thanks, Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Update: Debox sendfile modifications
Ok, I've reread the debox paper, looked over the patch, and talked to Alan Cox about his present and upcoming work on the vm system. The debox patch does three basic things (if I'm understanding everything correctly.): 1. It ensures that the header is sent in the same packet as the first part of the data, fixing performance with small files. - This part of the patch needs a little cleanup, but that's easy enough. I will try to integrate it next week. 2. The patch merges sendfile buffers so that when the same page is sent to multiple connections, kernel address space is not wasted. - While this is the part of the patch with the widest benefit, it will be the most difficult to integrate. In order to support 64-bit architectures better, Alan has refactored the sendfile code, meaning that the patch would have to be rewritten to fit this new layout. 3. The patch returns a new error when sendfile realizes that it will have to block on disk I/O, thereby allowing Flash to have a helper do the blocking call. - While this change could be made easily enough, I'm not sure that it would benefit anything other than Flash, so I'm not certain if we should do it. However, based on what you learned with Flash, I have an alternate idea: --- Suppose that sendfile is called to send to a non-blocking socket, and that it detects that the page(s) required are not in memory, and that disk I/O will be necessary. Instead of blocking, sendfile would call a sendfile helper kernel thread (either by calling kthread_create, or by having a preexisting pool.) After dispatching this thread, sendfile would return EWOULDBLOCK to the caller. Note that only a limited number of threads would exist (perhaps 8?), so, if all threads were busy, sendfile would have to block like it does at present. Once the I/O was complete, the thread would call sowakeup (or whatever is called typically when a thread is now ready for writing) for the socket in question. The application would call sendfile, like normal, but this time everything would succeed because the page would be in memory. --- If such a feature were implemented, it might have the same increased performance effect that your new return value does, except that it would require no modification for a non-blocking sendfile based application to take advantage of it. Alan, would this be possible from the VM system's perspective? Is it safe to assume that once the page in question was in the page cache that it would hang around long enough for the second sendfile call to access it before it is paged back out again? Thanks, Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Update: Debox sendfile modifications
On Tue, 4 Nov 2003, Vivek Pai wrote: The one other aspect of this is that sf_bufs mappings are maintained for a configurable amount of time, reducing the number of TLB ops. You can specify the parameter for how long, ranging from -1 (no coalescing at all), 0 (coalesce, but free immediately after last holder release), to any other time. Obviously, any value above 0 will increase the amount of wired memory at any given point in time, but it's configurable. Ah, I missed that point. Did your testing show the caching part of the functionality to be significant? There are two problems to this approach that I see a) you'd have to return a value back to sendfile while this async operation is in progress, because you don't have any other non-intrusive way of giving back the return value at any other time b) once that small number of kernel threads gets exhausted, you lose the opportunity to serve requests out of main memory part (a) means that this change can't be made completely without application re-coding, and part (b) means that more sophisticated applications could lose performance. How about something that lets you choose what happens - we've got a flag field anyway, so why not have options to control the behavior on missing pages? Applications like Flash might just want the error message so that they can handle it themselves, while other applications may be happy with the default that you're suggesting. -Vivek Yeah, I guess you're right; as John-Mark Gurney also pointed out, it would be extremely difficult to hide the asychronous implementation. Assuming that we came up with an extra flag which told sendfile to use asynchronous mode (and raised the maximum number of such threads), wouldn't it be even more efficient than Flash's helper threads? Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.1-p10 reproducible crash with Apache2
On Mon, 3 Nov 2003, [ISO-8859-1] Branko F. Grac(nar wrote: Machine locked up in about 5 seconds (this is 1u p4 xeon 2.4 GHz, 2GB of ~ ram). This only accours if Apache2 SSLMutex is set to 'sem' and SSLSessionCache is set to 'shm:/path(size)'. So... there are possible problems with shared memory implementation in 5.1-RELEASE Brane Can you try updating to 5.1-current and see if the situation changes at all? A lot has changed since 5.1-release. If it's still broken in 5.1-current, we can take a look into it. Thanks, Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some mmap observations compared to Linux 2.6/OpenBSD
On Fri, 31 Oct 2003, Vivek Pai wrote: Before we proceed on this, I'd like to ask is there actuall a committer ready to follow up on this? We currently make our patches available on Ping's homepage, and they're relatively clean. He spent a fair bit of time getting it from a relatively ugly set of changes to something more elegant and better integrated with the rest of the kernel. However, even with the benchmark success that we've gotten (which Aniruddha Bohra mentioned in a different e-mail), we haven't had a single nibble from a committer. FreeBSD lags Linux badly on the SpecWeb99 benchmarks, and those are probably more representative than some arbitrary microbenchmark. It would be nice to get some respectable numbers on it, especially if we could do it with a stable user-space server. -Vivek My main concern is that your patches may no longer cleanly apply to -current, which could make integration more difficult. If integration is easy, and if we can show some improvement with webservers other than Flash, I'll help with integration. However, with the 5.2 code freeze starting in mid-November, I can't guarantee that we could have it integrated by then. However, that doesn't preclude us from doing work on it during that time. Does the version of flash available for download (.1 alpha) have the changes which take advantage of your enhanced sendfile integrated? Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some mmap observations compared to Linux 2.6/OpenBSD
On Sat, 25 Oct 2003, David Schultz wrote: But regardless of the approach, someone has yet to demonstrate that this is actually a performance problem in the real world. ;-) I could be way wrong, but I would think that a database might mmap discontiguous segments of memory. Perhaps someone familiar with mysql/postgres/others might know if they would be a good benchmark. Actually, relating to this, didn't phk request a VM function which would remap a page (or contiguous segment of pages) to a new address which had free space after it? I believe that he needed such a feature to turbocharge realloc(). It sounds like the freelist mode of operation would make that more feasible. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Some mmap observations compared to Linux 2.6/OpenBSD
On Sun, 26 Oct 2003 [EMAIL PROTECTED] wrote: Details about what we have so far are at http://www.cs.princeton.edu/~yruan/debox/ Yaoping Ruan had mentioned this on the list before (and sent a pointer to the sendfile patches), but didn't seem to get much response. -Vivek As always, you're seeing the lack of available committer time, not a real lack of interest. One way to accelerate the process might be for someone (not necessarily you, any reader of this mailing list could do it) to show that this change visibly benefits some easy to run benchmark. Some simple setup of apachebench vs thttpd (which uses sendfile, afaik) would be useful for this purpose. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD mail list etiquette
On Sat, 25 Oct 2003, John-Mark Gurney wrote: And patches (against FreeBSD) are highly encouraged. It rarely helps to simply point out flaws (or showing how X OS runs soo much better than FreeBSD, why are you guys even running FreeBSD?) w/o showing code to fix it. -- John-Mark GurneyVoice: +1 415 225 5579 Heck, I'd be happy if working benchmark programs were provided. A big chunk of figuring out bugs / performance problems always seems to be setting up the right conditions for the problem to be recreated. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: High mem (4GB) support on FreeBSD 4.8
On Sat, 18 Oct 2003, Yaoping Ruan wrote: Hi: I installed the 4.8 release on a new box with 4GB memory, and found kernel panic when I tried to write date. But the system run great with only 2GB memory. Is there any kernel compiling option in the LINT, like the high mem option in Linux? BTW, we also tried 4.6 release, didn't have this problem but had some different issues. Some of the kernel autoscaling values may be off with 4GB machines; I believe that this has been fixed with 4.9, so running 4.9-RC3 might be the easiest answer. Alternately, try the following: 1. Check the mailing list archives, there might be a better explanation than I'm about to give. 2. Play with the amount of memory available using the hw.physmem tunable in loader.conf; you can set to to intermediate values, such as 3G, etc. 3. Tweak the tunable kern.vm.kmem.size upwards, it defaults to 200M, which is probably too small for a 4G machine; try 300 or 400M. Don't worry about PAE, that's only needed if you have _more_ than 4G of ram. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Determining CPU features / cache organization from userland
On Fri, 10 Oct 2003, Joseph Koshy wrote: Hi -hackers, I'm looking for ways that a userland program can determine the CPU features available on an SMP machine -- processor model, stepping numbers, supported features, cache organization etc. For example, on some x86 processors the CPUID instruction could be used to determine some of these parameters, but using this instruction in an SMP context is a little tricky since we do not know which CPU gets to execute the instruction. At least in the Intel world, multiprocessor systems are _always_ supposed to have matching processor steppings, so the reliability of the information should be very good indeed. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 802.11 AP Status?
On Thu, 9 Oct 2003, Leo Bicknell wrote: I need to make a FreeBSD box be a proper 802.11 AP (BSS Mode). I've got a pile of Orinoco cards here, but they seem to still not be supported. What ever happened to that effort? Assuming they still aren't supported any recomendations on a cheap PCMCIA and/or PCI 802.11 card that is well supported in BSS Mode on FreeBSD? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 I have a Netgear MA311 (Prism 2.5 chipset) doing its job as a BSS under -stable, and it works pretty well. Now, take that with a grain of salt, because I only run one node off of it, and that's a machine also running FreeBSD. That machine is running a Netgear MA401, which is the PCMCIA version of the 311. Note that if you're willing to run -current, your options are even better: According to the ath manpage, the Atheros based cards support BSS mode, they're a/b/g capable, and they're true PCI/cardbus cards, so they should perform better. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.8-stable kernel panic
On Mon, 15 Sep 2003, Robert Watson wrote: If one of you has had a chance to test this properly, please go ahead and commit. I don't have remote -STABLE development boxes, so haven't been able to do any -STABLE merging since I went to BSDCon. I did get RE permission to MFC this change. FYI, I have a bunch more related changes in a patch that I can dig up once I'm caught up on work re-mail. There are a number of M_TRYWAIT scenarios where we don't test the return value -- some easier to fix than others. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories Ok, I'll do it. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.8-stable kernel panic
On Sun, 14 Sep 2003 [EMAIL PROTECTED] wrote: Hello, It's been almost a month now since I posted the original message on the list and I'm wondering about the progress on resolving this problem. I still can reproduce the panics after cvs-supping to RELENG_4 ~ 23:00 EDT today. Thanks much. Ooops, I forgot to follow up on this. Ok, a few questions: 1. Can you compile INVARIANTS and INVARIANT_SUPPORT into your kernel? That might help us track down the problem. 2. What does your network setup look like? Are you using divert sockets, is there ppp in action, etc. I believe that I tried out your script at the time, and I couldn't find it to cause any problems on my system. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: non reliable nmi
On Thu, 28 Aug 2003, Don Bowman wrote: I have machdep.ddb_on_nmi=1. I can drop into the debugger with the magic key sequence. However, when i hit the NMI jumper, i don't always go there. Sometimes I do. The system is 4-way SMP [2xHTT xeon processors] with 4.7. Any suggestion on where my NMI might be going? Is your NMI about 106K in size, and does it have the subjects Thank you, Wicked screensaver and others? If so, I think I know where it's going... Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell fast ethernet 3ccfe575bt-d
On Tue, 26 Aug 2003, Maxime Henrion wrote: M. Warner Losh wrote: In message: [EMAIL PROTECTED] Sandeep Kumar Davu [EMAIL PROTECTED] writes: : I was intalling freebsd on laptop and could not find the drivers for : 3ccfe575bt-d fast ethernet 10/100base-tx ethernet card. Could anyone please : enligten me where can I find the driver for this card. /usr/src/sys/dev/xl in current. nowhere on 4.x stable. The sources for the xl(4) driver live in /usr/src/sys/pci, not in /usr/src/sys/dev/xl which doesn't exist. The driver is contained in the if_xl.c and if_xlreg.h files. Cheers, Maxime * 3Com 3c575TX 10/100Mbps/RJ-45 (Cardbus, Hurricane ASIC) No cardbus support in -stable. :) Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: possible deadlocks?
On Thu, 7 Aug 2003, Robert Watson wrote: On Wed, 6 Aug 2003, Ted Unangst wrote: My advisor Dawson Engler has written a deadlock detector, and we'd like some verification. They look like bugs, unless there is some other reason why two call chains cannot happen at the same time. Neat -- sounds like two good catches given the responses so far. Can we expect more such reports forthcoming? This kind of help will be invaluable in finishing up the fine-grained locking work. Alternatively, do you plan to post the software? Is this static or dynamic analysis? etc, etc? :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories Just for everyone's info, any locking problems that I introduce over the next few months will not be mistakes, they will be test cases for the deadlock detector. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbuf cluster shortage caused kernel panic
On Wed, 23 Jul 2003, Kevin A. Pieckiel wrote: #uname -a FreeBSD fileserver1.smartrafficenter.net 4.7-STABLE FreeBSD 4.7-STABLE #0: Mon Dec 16 19:41:03 EST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FILESERVER1 i386 Running 4.7 stable with sources CVSed on 16 Dec 2002. My fileserver has been running since 17 Dec 2002 and suddenly lost its ability to talk on the network today. Went to the console to discover a flood of messages that it was out of mbuf clusters, read tuning(7) for more info. What can I do to help solve any problems that might exist in the kernel code, and what suggestions do you have to keep this from happening on my fileserver again? Kernel, debug kernel, CVS date, kernel config, and core file can be made available upon request. Thanks much, Kevin A. Pieckiel Your panic seems to indicate that the mbuf cluster chain became corrupted, which could have happened in one of a few ways. I'll address your question in two parts: 1. How do I prevent the system from using all mbuf clusters. This depends on the application you're running; next time you're in a similar situation, you may wish to run netstat -n | more and look at the sendq values to see if there are a large number of connections with large sendqs that are sucking up all the mbuf clusters. If a large number of mbuf clusters are in use without much of anything showing up in netstat -n, then we have some sort of mbuf cluster leak, which is much more serious. 2. How do I prevent the system from panicing when all mbuf clusters are used up? This question has a more useful answer. :) You could cvsup to 4.8-STABLE; at least two bugs which would result in panics during mbuf exhaustion have been fixed, and an additional potential panic causing situation has been patched. One of those bugs may be the same as the one that affected you, but it would be very time consuming to figure it out. Even if you stay with the kernel version you are at, you may want to enable the INVARIANTS (and INVARIANT_SUPPORT) options. This will cause additional checks to be enabled in the kernel which will make tracking down future panics easier. If this problem is infrequent, I think your best course of action is to build a 4.7 kernel with INVARIANTS for now, and plan on a 4.8-stable upgrade at some point in the future. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbuf cluster shortage caused kernel panic
On Wed, 23 Jul 2003, Leo Bicknell wrote: I had a crash a few days ago on a 4.8-RELEASE box that I hadn't looked into yet, but when I saw your message I went back to take a look. I also ran out of mbuf clusters. First time on this machine, and since I've used it to test a number of high bandwidth*delay paths I've at times had the socket buffers cranked and really exercised MBUF's but good. At the time of the panic the limits were sane (32k send/receive tcp). #2 0xc0163e24 in poweroff_wait () #3 0xc0184ad5 in sbappendaddr () #4 0xc01c85a1 in udp_input () #5 0xc01bbb18 in ip_input () #6 0xc01bbb77 in ipintr () #7 0xc0292631 in swi_net_next () #8 0xc0185d83 in sendit () #9 0xc0185e86 in sendto () #10 0xc02a0e51 in syscall2 () Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 I think that this may have been caused by the bug I fixed in if_loop.c revision 1.47.2.8 (post 4.8-release.) Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nvidia Licensing Question
This is becoming a really annoying FAQ. The reason nobody has ported the NIC driver is because the source code is not provided; it's just a binary driver with a wrapper. You'd be just as well off trying to port the Windows driver... I didn't look into the sound driver at all, it may be the same way. Mike Silby Silbersack On Sun, 20 Jul 2003, Joe Warner wrote: Hi, I was talking to someone recently about why there isn't support for Nvidia's Nforce drivers under FreeBSD yet. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AMD Opteron
On Wed, 25 Jun 2003, Matt Bednarik wrote: Does FreeBSD support the new 64 bit AMD Opteron? I am thinking about having a dual processor opteron system built, can i stay with freebsd? As of now, 5.1 does support the opteron in 64-bit mode, but the support is still preliminary... if it's not complete enough for you, you could always just run the machine in 32-bit mode. We have an amd64 mailing list now, you may wish to ask around there for more information. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vr(4) duplex problems
On Fri, 20 Jun 2003, Daniel O'Connor wrote: Hmm, well all I could manage was a 5 port micro switch. It is made by Alloy but can autodetect crossover (MDX?). It works fine with the vr port doing autodetect, so I guess it's an interaction with the older switch. No idea how ammenable to software fixing that would be though :( -- Daniel O'Connor software and network engineer Actually, it may be possible to fix through software. The fact that your card is using ukphy means that we're using the generic PHY support, which may be doing something slightly wrong for whatever PHY is actually present on your NIC. If you look through the various *_phy drivers, you'll see that some have tiny little variations necessary for proper operation... However, since we've established that vr autodetects fine on some hubs, and that you can force the duplex and have it work ok, I don't think it's worth the time to track down the problem. (After all, it may not be solvable through software.) However, if you have an interest in learning about the internal workings of PHYs, I'll be glad to commit patches for you. :) Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vr(4) duplex problems
On Tue, 17 Jun 2003, Daniel O'Connor wrote: If possible, I'd like you to try some other brands of 100/FDX hubs and see if autonegotiation works properly; this would help tell us if the problem is general, or specific to that card. I don't have any other brands of 100/FDX switches :( I will try and dig one up, but I think the best I can do is a different generation switch from the same manufacturer. Well, then we're somewhat stuck. Couldn't you sneak in a little 5 port hub from home and splice it into the network? :) ukphy0: Generic IEEE 802.3u media interface on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Nothing out of the ordinary there, but perhaps we're messing up by _not_ recognizing a specific PHY and doing something special. H... I have an idea, but since forced duplex works for you, I'm not inclined to spend time on it now. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vr(4) duplex problems
On Mon, 16 Jun 2003, Daniel O'Connor wrote: I have 4.8 vintage PC with an Epox 8K9A9I motherboard (http://www.epox.com/html/motherboard.asp?product=EP-8K9AIlang=1) which has an onboard vr(4) interface. I find that if the interface auto negotiates, it picks 100Mbit/FDX which matches the switch, but transfers are very bursty. If I force half duplex 100 or 10 mbit it works as I would expect (unbursty..). 10mbit/FDX is bursty as well. Does anyone have any patches, or ideas/suggestions? Thanks. -- Daniel O'Connor software and network engineer Well, there have been a few reports of similar problems. However, back when those reports came in, there were a bunch of other problems with our if_vr driver, so everyone gave up and switched network cards before we could get to the duplex autoneg problem. :) If possible, I'd like you to try some other brands of 100/FDX hubs and see if autonegotiation works properly; this would help tell us if the problem is general, or specific to that card. Also, can you post the dmesg output relating to your card? I'm curious which PHY device you have. Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Expensive timeout(9) function...
On Tue, 1 Apr 2003, Yar Tikhiy wrote: Thanks for your explanation! I hope this little thread will draw the attention of the responsible or interested parties to the warnings ;-) -- Yar The _tick routines are not easy to fix, FWIW. MII access functions are quite time consuming almost any way you look at it. Well, actually, I figured out a way to make them much faster, but it's been a few months since I looked at that patch, I guess I should pull it back up and post it somewhere... Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Expensive timeout(9) function...
On Tue, 1 Apr 2003, Poul-Henning Kamp wrote: The _tick routines are not easy to fix, FWIW. MII access functions are quite time consuming almost any way you look at it. I'm not sure the _tick functions should even be called from a timeout(). In many ways it seems preferable to me to have then run sequentially from a single thread, possibly via a task-queue. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 Yeah, I suppose limiting it to one mii_tick routine per second would help somewhat... but it's still a bad situation. Actually, we could improve it quite a bit if someone adds NANODELAY() (hint, hint...) Couldn't we have a first-run nanodelay that just used nanotime to do the counting for it? Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Expensive timeout(9) function...
On Tue, 1 Apr 2003, Poul-Henning Kamp wrote: Yeah, I suppose limiting it to one mii_tick routine per second would help somewhat... but it's still a bad situation. I wasn't advocating slowing it down that much, merely trying to run it sequentially out of timeout()'s hair. shrug Either way would be fine, I don't think there's any major need for a poll once per second. There used to be a crumbled note with this somewhere in my stack of TODO items, but by now I suspect that it is ironed perfectly flat from the weight of all the stuff on top of it. But to add to my knowledge-base: What length of delays are you looking for ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 I'd be happy with 100ns granularity (rounded up), with no major concern for jitter. For the purposes of the MII delays, all we really care is that we wait long enough; if we wait too long sometimes, that's no big deal. For reference, 3Com's documentation states that 40ns should be enough, but our current DELAY on i386 seems to take a few uS last time I checked. So, even if you can only get 300ns granularity, that'd still save a lot of time. This is why I suggested using something which just reads nanotime in a loop; nanotime should be accurate enough, right? BTW, does it appear to everyone else that half of these messages are getting dropped on their way to the lists, or is it just me? Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: future of all the jail patches [was: Re: jail statfs patch]
On Mon, 3 Mar 2003, Bjoern A. Zeeb wrote: Christian asks me to file a PR to better get this tracked and perhaps included in mainstream. I had seen lots of jail discussion here the last months but I think there had been few PR submission. What is the overall opinion on this - file PRs ? What about including (at least some) of the (other) jail patches in HEAD ? What about jail-ng ? [ Perhaps take this discussion to -current ? ] -- Bjoern A. Zeebbzeeb at Zabbadoz dot NeT Well, the first step to getting anything committed is to find an interested committer. In order for that committer to look at the patch, it's naturally best to have a PR filed so that committer can look at it easily. So what you should do is: 1. File the PR. 2. Find an interested commmitter. If 2 fails, ask core for commit privaledges so you can commit it yourself. Just be quite sure your patch is good before you do that. :) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Disk scheduling in FreeBSD
On Fri, 28 Feb 2003, Paul Robinson wrote: Well, I'm just a hanger-on without a commit bit, so I'll work on making it production ready in the next few weeks, post up a patch and if somebody wants to commit it, great. At the moment it's all based on 4.3-RELEASE and isn't really production ready. It does look worth doing though. Make an easy to run testbench which should show the performance improvements / disadvantages of a new IO scheduler first; that's really the first step. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ACPI: working ACPI vs broken ACPI
On Sat, 15 Feb 2003, Martin Blapp wrote: Feb 13 17:41:05 ibm-01 kernel: ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE31 Feb 13 17:41:05 ibm-01 kernel: ACPI-0625: *** Info: GPE Block1 defined as GPE32 to GPE63 I see similar errors on my Presario 2100US... Wild guess: Seem to result from this. If I'm looking at NetBSD's http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/acpi/acpi_ec.c they have a lot done since they took acpi from us. I'm sure it works for netbsd. Is anybody working on this ? Martin I've been trying to load that URL since yesterday, but it's not working from here. Can you elaborate on what it does? Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Trailing whitespace in FreeBSD
On Mon, 10 Feb 2003, Jordan K Hubbard wrote: * Obligatory trivia: I wonder how many remember that freefall was named after Rod's passion for the sport I've always wondered about that... unfortunately, the answer is much less exciting than I had expected it to be. THANKS FOR RUINING MY BELIEFS ABOUT FREEBSD, JORDAN. /me goes off in search of a new hobby with new mysteries. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VIA Rhine III (MII without any phy!)
On Thu, 30 Jan 2003, Greg Lewis wrote: Hi all, I've recently acquired a motherboard with a VIA Rhine III onboard NIC. I couldn't see support for this in the current vr(4) driver in either -current or -stable and am trying to add support for it. Having not done any kernel hacking before I'd appreciate some pointers if someone would be so kind. Thomas Nystrom has found the necessary fixes to our driver, I should be committing them this weekend (and MFCing them to 4.x soon after that.) Soo... wait a few days, and all will be good. :) I've also found what looks to be good documentation for the chip on the VIA web site, so I should be able to track down appropriate information as necessary. Sorry to be pedantic, but there's a problem with that statement. Via's documentation isn't good, there are many tiny glitches they don't list. Nonetheless, they are far better than Nvidia, who isn't releasing any specs for their NIC chipset... Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: max simultaneous TCP connections (32,763)?
On Sun, 26 Jan 2003, Sam Tannous wrote: I have two freebsd boxes (back to back) and I've been playing with a simple server on one machine and client on the other machine (this was simply an exercise with playing with kqueue). Both the server and the client are single processes and the client seems to stop at 32,763 connections. I've modified the port range, tcp keepalive, kern.ipc.somaxconn, maxfiles, maxsockets, nmbclusters. I even tried net.inet.tcp.tcbhashsize (up to 1024). Is there some other parameter I'm missing? Or is this a known limitation/bug? --Sam Look more closely at the net.inet.ip.portrange.* sysctl values, you should be able to make the range as large as 1024 to 65535. At present, FreeBSD uses an overly simple hash table which only allows each outgoing port to be used once. As a result, the number of outgoing connections is definitely limited. However, there should be no similar limitation on incoming connections, other than memory size. You might consider setting up more clients and seeing how far you can push the server. :) Also, disabling keepalives shouldn't matter, they don't take up any additional space except for during the period when they are actually sent. (Which would require 2 hours of idle time.) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NIC driver
On Wed, 22 Jan 2003, Eirik Nygaard wrote: I just got a new computer with a network card I don't seem to find any FreeBSD drivers for. It got a realtek 8201 chipset so I thought I could make my own driver, but I am not sure where to start. Are there any guides on how to make a simpel driver out there? Any hint tips would be great, where to start, what I need to know. -- Eirik Nygaard [EMAIL PROTECTED] That should be a supported card. What version of FreeBSD are you running? Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NIC driver
On Wed, 22 Jan 2003, Eirik Nygaard wrote: I am running 5.0-RELEASE, nothing shows up in neither dmesg nor ifconfig. It is a built-in network card on an Asus A7N266-VM motherboard. -- Eirik Nygaard [EMAIL PROTECTED] Ok, please post the output of a pciconf -l, run as root. Perhaps it's just a slightly different pci ID. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NIC driver
On Wed, 22 Jan 2003, Eirik Nygaard wrote: none4@pci0:4:0: class=0x02 card=0x0c111043 chip=0x01c310de rev=0xc2 hdr=0x00 rl0@pci1:8:0 is another realtek card I put into the computer to be abel to copy the pciconf -l info without manually writing it over. The network card is none4@pci0:4:0 it seems if I use the -v switch also. none4@pci0:4:0: class=0x02 card=0x0c111043 chip=0x01c310de rev=0xc2 hdr=0x00 vendor = 'Nvidia Corporation' device = 'nForce MCP Networking Adapter' class= network subclass = ethernet -- Eirik Nygaard [EMAIL PROTECTED] Hm, I guess we don't support that chipset. Apologies for the confusion, I was confused by an earlier commit regarding NForce2 boards; apparently some vendors are shipping boards with Nvidia's onboard ethernet _and_ a secondary 3com interface. (The reason for the secondary interace will become clear in a second.) The Realtek 8201L is merely the PHY part of the chip, which we already support. As for the main ethernet chip, we don't currently have a driver. While a Linux driver does exist, it's totally useless in our situation. Nvidia has the driver split into a closed binary and a wrapper; there's no way to figure out how to program the chip from the wrapper alone. Your only option is to bug Nvidia into releasing either the chip's documentation or the source code to the Linux network driver. You might want to look around various Linux mailing lists and see if someone has already figured out who to contact; I doubt that anyone is happy with the binary only driver. (Especially given that virtually every other NIC has at least a GPL'd driver, even if it's poorly documented.) I'd recommend getting used to the realtek card you threw into the box; it seems unlikely that you're going to be able to get Nvidia to cave into giving out documentation without a prolonged fight. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can dhclient rely on /dev/random?
On Sat, 28 Dec 2002, Tim Kientzle wrote: I've clocked /dev/random on -current at just about 10MB/s (on a 1GHz AMD Duron). That's plenty fast enough for generating session keys. ;-) Sounds like it, I didn't realize it was that fast. :) If this code is just used for generating occasional keys, 4.x's /dev/random may well suffice. As I dig deeper, though, I'm starting to suspect that this code isn't actually used by dhclient at all. That would suggest a much simpler fix... ;-) Tim Warning! Warning! Under 4.x, you probably want to use /dev/urandom. The reason for this is that /dev/random is only guaranteed to give you values when it can guarantee that you're getting good randomness. And as 4.x doesn't harvest many entropy sources by default, there's little good randomness, and you'll get nothing! /dev/urandom's bad randomness is certainly better than no randomness at all. :) Of course, if dhclient doesn't need any randomness, then I guess you don't have to worry. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Can dhclient rely on /dev/random?
On Sat, 28 Dec 2002, Tim Kientzle wrote: Policy Question: is a fast, high-quality /dev/random a gauranteed feature starting with 5.0? Yes. Technical Question: is /dev/random sufficient for the cryptographic requirements of programs like dhclient, bind, etc? Yes. I believe both of these are answered 'yes'. If so, I'll work up a patch to alter these programs to rely solely on /dev/random. I suppose that patch should be sent to the ISC folks, since those programs are vendor imports. (?) (I'm envisioning a FAST_GOOD_DEV_RANDOM compile-time switch; if set, /dev/random would be the only source of entropy used.) Any pointers/suggestions appreciated, Tim Kientzle The only problem is that /dev/urandom and /dev/random might be too slow for direct use whereever random data is needed. However, they are certainly a lot better for seeding an RC4 generator (or something similar) than netstat / ps / etc would be. As such, you may even want to use /dev/urandom under 4.x, although it's nowhere near as good as the /dev/(u)random on 5.x. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tcp_usrreq bug ??
On Tue, 3 Dec 2002, Aniruddha Bohra wrote: Hello The following code snippet is from netinet/tcp_usrreq.c As in the comment (and presumably correct behaviour) a RST should be sent on close if the connection is embryonic. However, if (tp-t_state TCPS_ESTABLISHED) tp = tcp_close(tp); does not do it. One can imagine a scenario when a client would just do a connect() and close() and an overloaded server would have its listen queue crowded by connections that were not synchronized but closed. I have seen this happen in my lab test, where I use httperf to measure Apache webserver throughput. There are several listen queue overflows and resets. The interesting part is that the client _NEVER_ has more than 3200 open descriptors yet a queue of 4096 on the server gets filled up. Is there a reason for not sending a RST or is it a bug? Please help. Thanks Aniruddha I took a quick look, and I agree that the comment doesn't seem to match reality. Looking back, it appears that the code/comment have been exactly the same since FreeBSD 2, back in 1994. Note that I haven't actually doublechecked this with tcpdump, so my comments are based off of what you stated... There are two sides to examine this problem from: The server side, and the client side. Server side: Getting flooded with SYN packets is an unfortunate reality that all OSes must deal with these days. Even if you're using a pre-syncache version of FreeBSD, you shouldn't be seeing too many problems due to listen queue overflows. If performance is terrible, you may consider moving to FreeBSD 4.7, or doing further examination to determine if listen queue overflows are really hurting you. Client side: #1 - Why is your benchmark program terminating connections before they finish connecting? #2 - I've been thinking about how FreBSD should handle the situation where a connection is closed before it has become established, and I think that silently dropping the connection is best. Here's why: Normal usage, single connection closed like this: Client receives syn-ack packet, responds with reset. Had a reset been preemptively sent, it would have crossed with the syn-ack on the wire, and two syn-acks would be sent. Either way, the connection gets reset. Flooded server, single connection closed: Same as above; preemptive reset wastes bandwidth. Client used to perform a synflood: Again, same as above. If a reset was sent, you'd double the PPS the server was flooded with. That being said, I don't think that a connect/close pair would be used for a synflood. Such a flood would be easily blockable and tracable with extreme ease. Note that FreeBSD's rst rate limiting would limit the number of connections / second that would be reset, but the server's built-in anti-syn flood countermeasures should do fine. Hence, I'm not sure that we can do anything better than what we are doing now. Once the 5.0 codefreeze is over, I'll go in and take out the misleading comment. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
On Wed, 4 Dec 2002, Stijn Hoop wrote: With the mentioned change of /etc/sysctl.conf to /boot/loader.conf, I am indeed seeing much better times on this 'benchmark'. See attached log. Not only the _select_sleep method benefits from this. What are the reasons *not* to do this? As to why Linux may appear better... I believe that Linux defaults to hz=100, but that the default switched to hz=1000 sometime in the recent past. And why don't we do the same? (I suspect this is related to the question above :) Well, it's generally believed that in the common case (around 100 processes, and/or with well behaved processes that voluntarily give up their timeslice) that 100 context switches per second is enough for smooth performance. Whether this is true or not as you hit 500+ processes on a busy server is unknown, I don't believe that anyone has done benchmarking. One argument against more frequent context switches when you have 100 processes is that you will be invalidating the contents of the various caches more often, leading to less efficient overall performance. The same argument could also be made for the VM system if the system is under memory pressure. On the other hand, a higher HZ should create a system which runs a bit smoother for interactive programs. And, as you point out, it is necessary for good timing in emulators / simulators / dummynet. In short, I don't think the issue has been discussed much, partially because it's so easy for those who want hz=1000 to just edit loader.conf. If you want to propose that we switch to hz=1000 by default: 1. Make a list of applications / setups that benefit from hz=1000. 2. Wait until after 5.0-release is out the door. 3. Pose your question on -arch. Good luck. :) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
On Wed, 4 Dec 2002, Stijn Hoop wrote: In short, I don't think the issue has been discussed much, partially because it's so easy for those who want hz=1000 to just edit loader.conf. If you want to propose that we switch to hz=1000 by default: Nah, I'll leave that to someone who has some more expertise in writing benchmarks etc. --Stijn Well, what you _should_ do is make sure that the Xmame documentation gets updated to mention that FreeBSD users should tweak kern.hz for best performance. :) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: [nephtes@openface.ca: [Xmame] Use of usleep() with -sleepidle]
On Mon, 2 Dec 2002, Stijn Hoop wrote: Hi, Summary: this is going to be a rather long email about the timing of various _sleep functions, compared to the same on Linux. I ran across this at the xmame mailing list, and I have seen some interesting results. One had an Athlon 1400XP, and got the following for the select speeds: %%% Testing _select_sleep (x 1000), delay 8 Total time: .906000 ms; unit time: 9.06 ms; estimated overhead: 1.06 ms %%% What's going on here? Is our select really that much slower, or is the program measuring the wrong values, or doesn't this speed make a difference in 'real-world' applications, or what? --Stijn The time select() takes should be directly related to your system's hz setting. The default for FreeBSD is 100, which means that the interrupt timer will fire every 10ms. If you want to play with that, edit /etc/sysctl.conf and set kern.hz=1000, which should give you 1 ms accuracy. As to why Linux may appear better... I believe that Linux defaults to hz=100, but that the default switched to hz=1000 sometime in the recent past. To answer your final question: Sleep accuracy doesn't matter to most applications, but I'm sure counterexamples could be found. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Changing socket buffer timeout to a u_long?
On Thu, 21 Nov 2002, Julian Elischer wrote: On Thu, 21 Nov 2002, David G. Andersen wrote: Are there compelling reasons not to change the socket buffer timeout to a u_long from a u_short? This variable stores the number of ticks before the socket operation times out. -Dave (not on -hackers anymore, please CC) I can see this in -current. In -stable I'm not sure of the ramifications. It might screw up any proprietary loadable protocols. I Think there are a couple of them. The change sounds like a good idea, if we intend to keep socket timeouts useful. So that we don't get into binary compatibility issues with 5.0, the change should probably be made soon... Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/bin/sleep sleep.c
On Wed, 20 Nov 2002, Tony Finch wrote: David Schultz [EMAIL PROTECTED] wrote: BSS and modified data are not shared, and Matt is only counting zero fill and COW faults. Most of the BSS is mmapped zero pages that are copy-on-write, so in simple programs they should be mostly shared. See rtld-elf/map_object.c Tony. I'm curious how well COW sharing really works under FreeBSD. Earlier this year, I fixed a piece of code which was O((processes sharing a page)^2) in the VM system. When certain simple forkbombs were run, they would cause the machine to freeze for 30 seconds at a time or more once the VM cleanup routines kicked in and ran the O(N^2) piece of code. What bugged me at the time was that I couldn't seem to reproduce the problem with other programs... this led me to believe that we aren't really sharing too many pages in common use, but I didn't have time to investigate if that was true or not. Someone with an interest in VM implementations might want to take a wander through and see how well page sharing really works on a typical FreeBSD system. :) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sfbuf problems
On Thu, 24 Oct 2002, Ian Campbell wrote: I tried a hack sendfile replacement with write() and lseek(), just to see if that made a difference... but all it did was chew mbufs instead of sf_bufs ... How can I tell if I'm just using all available buffer space, or if it's just a leak I'm not seeing? How can I increase available kvm if it becomes necessary? Once you shutdown the server, does netstat -na show all the connections dying off, and does netstat -m show mbuf usage dropping back to normal? If connections die off properly and the number of mbufs drops back to normal, then there is probably no leak. During normal usage, it is entirely possible to max out mbuf usage without there being a memory leak. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
