Re: eXperimental bandwidth delay product code (was Re: Network performancetuning.)
Cool! We were just commenting that it's too bad dummynet/ALTQ really couldn't help the interactive response for us dial-up users. Anyway, I i haven't seen the beginning of the thread but surely both altq and dummynet can help, with the CBQ/WFQ support. In the case of dummynet, you can pace incoming traffic as well, at your endpoint. This means you act after the bottleneck, but the effect is that this way you will delay acks, and so slow down the connection eating a lot of bandwidth, and in the steady state this keeps the queue very short even before the bottleneck. Much like what products like packeteer do. cheers luigi just tried this on my dial-up connection on a fresh -STABLE but don't really notice any appreciable difference. net.inet.tcp.tcp_send_dynamic_enable: 1 net.inet.tcp.tcp_send_dynamic_min: 1024 (tried it with default 4096 too) My ssh response is still about 3 or 4 seconds behind my typing. What should a dial-up user expect? Thanks! Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Whitespace at end of line
On Sun, Jul 15, 2001 at 11:32:59PM -0500, David Scheidt wrote: ..., and wasted bandwidth from those cvsuping the changes. My cvsup of the repository took ~4 times as long when the changes were made to the man pages. *sigh* Are we now a hostage to CVSup times? Put it in cron and do it at 3am when you don't really care how long it takes. You would not have survived the `sup' days if you think CVSup takes a long time. I can only laugh at the wasted bandwidth comment. Any idea how much BW was being taken up by Napster related traffic until a month ago?? CVSup, with its low BW design of only sending diffs, pales in comparison. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: eXperimental bandwidth delay product code (was Re: Networkperformance tuning.)
I have been testing this over a very slow (barely ever over 24000 bps due to a crappy phone line) dial-up link, and as expected, over an idle line there is no difference (typing in an interactive ssh session seems a little quicker, but that could just be me). The gain comes when someone is downloading over the link and I try to type in an interactive ssh session. (I'm sharing the link with 1 other computer). Without the sysctl turned on typing in the interactive session results in a 10-15 second wait before anything appears on the screen; but with the sysctl turned on the wait is 2-3 seconds. I'd say that's pretty good work :-) Ken On Mon, 16 Jul 2001, Luigi Rizzo wrote: Cool! We were just commenting that it's too bad dummynet/ALTQ really couldn't help the interactive response for us dial-up users. Anyway, I i haven't seen the beginning of the thread but surely both altq and dummynet can help, with the CBQ/WFQ support. In the case of dummynet, you can pace incoming traffic as well, at your endpoint. This means you act after the bottleneck, but the effect is that this way you will delay acks, and so slow down the connection eating a lot of bandwidth, and in the steady state this keeps the queue very short even before the bottleneck. Much like what products like packeteer do. cheers luigi just tried this on my dial-up connection on a fresh -STABLE but don't really notice any appreciable difference. net.inet.tcp.tcp_send_dynamic_enable: 1 net.inet.tcp.tcp_send_dynamic_min: 1024 (tried it with default 4096 too) My ssh response is still about 3 or 4 seconds behind my typing. What should a dial-up user expect? Thanks! Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
wu-ftpd
Does anyone know how to set simultaneous downloads for users to 2 in /etc/ftpaccess for wu-ftpd? -- Ted Sikora [EMAIL PROTECTED] http://www.unixos2.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cron program core dumped (signal 11)
At 5:35 PM +0200 7/16/01, Chojin wrote: I update recompiled my system and my kernel. After reboot, I see cron program doesn't work it exits on a signal 11 (core dumped). MD5 (/usr/sbin/cron) = e56aa049cf7216f3c3f8e2ada7e9b4f3 Someone could help me ? You have a malformed cron entry which is missing the username field. If you correct it, cron will not core dump. We are testing a patch to prevent the core dump which should be committed soon. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: math library difference between linux emulation and native freebsd (and native linux)
[EMAIL PROTECTED] wrote: So I have stumbled across a linux emulation bug in freebsd. Below is the program that returns different results based on FreeBSD, Linux or Linux emulation under FreeBSD. [ ... ] There are only two shared libaries in common (libc and libm) and both are the same on FreeBSD (in /compat/linux) and Linux. So any ideas on where the program is going wrong? man fpsetround The defaults for the Linux emulator are different than the defaults for Linux. Linux sets some stuff up wrong, and then assumes that it's set up wrong. If you want to get exactly the same answers as for Linux, you will need to set the hardware up the same. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cron program core dumped (signal 11)
cd /usr/src/usr.sbin/cron make cleandir depend make CFLAGS=-ggdb -g3 STRIP= all install ..then run '/usr/sbin/cron' from the command line, and see if it leaves a coredump in the current directory. If it does, then do the following: gdb /usr/sbin/cron /path/to/cron.core (at the gdb prompt) bt info local up info local up info local [repeat until highest level] Hm. Now that I kinda tested this, cron doesn't seem to leave a corefile. Well, still.. this message was redirected to -stable in the hope that somebody there would know better how to help :\ G'luck, Peter -- This sentence claims to be an Epimenides paradox, but it is lying. Okay, I followed your instructions: GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd... Core was generated by `cron'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libutil.so.3...done. Reading symbols from /usr/lib/libc.so.4...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x804e59b in env_free (envp=0x0) at env.c:44 44 for (p = envp; *p; p++) (gdb) bt #0 0x804e59b in env_free (envp=0x0) at env.c:44 #1 0x804c166 in free_entry (e=0x805a8c0) at entry.c:77 #2 0x804de44 in load_entry (file=0x2810ab98, error_func=0x804b8dc log_error, pw=0x280fd780, envp=0x80576d0) at entry.c:423 #3 0x804badf in load_user (crontab_fd=6, pw=0x280fd780, name=0xbfbff9d4 rico) at user.c:105 #4 0x804ab37 in process_crontab (uname=0xbfbff9d4 rico, fname=0xbfbff9d4 rico, tabname=0xbfbff8d4 tabs/rico, statbuf=0xbfbffb4c, new_db=0xbfbffadc, old_db=0xbfbffbd4) at database.c:252 #5 0x804a76c in load_database (old_db=0xbfbffbd4) at database.c:120 #6 0x8049b92 in main (argc=1, argv=0xbfbffc34) at cron.c:116 #7 0x8049941 in _start () (gdb) info local p = (char **) 0x0 (gdb) up #1 0x804c166 in free_entry (e=0x805a8c0) at entry.c:77 77 env_free(e-envp); (gdb) info local No locals. (gdb) up #2 0x804de44 in load_entry (file=0x2810ab98, error_func=0x804b8dc log_error, pw=0x280fd780, envp=0x80576d0) at entry.c:423 423 free_entry(e); (gdb) info local ecode = e_username e = (entry *) 0x805a8c0 ch = 47 cmd = /hom0,20,40\3/articuno/Articuno.botchk /dev/null 21\000file, '\000' repeats 20 times, TÜ\a(\000r\006(, '\000' repeats 104 times, 4Ý\a(\000r\006(, '\000' repeats 56 times, ´Ý\a(\000r\006(, '\000' repeats 200 times, Tß\a(\000r\006(\000\000\000\000\000\000\000\000tß\a(\000r\006(, '\000' repeats 60 times, éY\005(\237\214\004\b¬ÿ\a(\000\000\000\000\216Y\005(h6\006(@\200\006(, '\000' repeats 12 times, @\200\006\001... envstr = \001\000\000\000\000daryn003\3\000n\000\000/usr/bin:/usr/sbin, '\000' repeats 202 times, ÄÕ\a(\000r\006(, '\000' repeats 112 times, ´Ö\a(\000r\006(, '\000' repeats 16 times, äÖ\a(\000r\006(, '\000' repeats 96 times, ´×\a(\000r\006(Ä×\a(\000r\006(\000\000\000\000\000\000\000\000ä×\a(\000r\00 6(, '\000' repeats 208 times, \224Ù\a(\000r\006(, '\000' repeats 136 times, ´Ú\a(\000r\006(\000\000\000\000\000\000\000\000ÔÚ\a(\000r\006(, '\000' repeats 12 times, 78... prev_env = (char **) 0x8053860 (gdb) up #3 0x804badf in load_user (crontab_fd=6, pw=0x280fd780, name=0xbfbff9d4 rico) at user.c:105 105 e = load_entry(file, log_error, pw, envp); (gdb) info local envstr = 0,20,40 * * * * /home/rico/poulet/scripts/botchk\000Articuno.botchk /dev/null 21\000\200\006(, '\000' repeats 12 times, @\200\006\001,õ¿¿;Y\005(\227\026\b(ü\234°\006\000r\006(îX\005(h6\006(Ä\215\ a(\000\000\000\000éY\005(\227\026\b(\217*\005(\000\000\000\000\216Y\005(h6\0 06(\000\000\000\000\2009\006(éY\005(n\t\b(n\t\b(\004\000\000\000\004\000\000 \000 \207\016(Ùø¿¿Ôù¿¿\004\000... file = (FILE *) 0x2810ab98 u = (user *) 0x80538a0 e = (entry *) 0x805a840 status = 0 envp = (char **) 0x80576d0 tenvp = (char **) 0x8057060 (gdb) up #4 0x804ab37 in process_crontab (uname=0xbfbff9d4 rico, fname=0xbfbff9d4 rico, tabname=0xbfbff8d4 tabs/rico, statbuf=0xbfbffb4c, new_db=0xbfbffadc, old_db=0xbfbffbd4) at database.c:252 252 u = load_user(crontab_fd, pw, fname); (gdb) info local pw = (struct passwd *) 0x280fd780 crontab_fd = 6 u = (user *) 0x0 (gdb) up #5 0x804a76c in load_database (old_db=0xbfbffbd4) at database.c:120 120 process_crontab(fname, fname, tabname, (gdb) info local fname = rico, '\000' repeats 251 times tabname = tabs/rico\03\000\000(àþ\a(\000\000\000\001\216Y\005(h6\006(@\200\006(\0 00\000\000\000\210%\006(Lù¿¿@\200\006\001Hù¿¿;Y\005(éY\005(\b\214\004\bT1\b( \001\000\000\000\216Y\005(h6\006(@\200\006(\000\000\000\000h6\006(@\200\006\
NEWCARD updates
For a while now I've been playing with NEWCARD, and I ended up making a lot of changes. I would appreciate any comments on them. Since there are a number of large changes, I'm not going to commit right away. You can find the diffs at http://people.freebsd.org/~jon/newcard.diff (.gz version also available if you don't feel like downloading 140k) This should apply cleanly on any -CURRENT this month. (if yours is older, the fix is trivial) You may also need to apply http://people.freebsd.org/~jon/pci_enable_io.diff if your -CURRENT is before June 10. Briefly, the significant changes include: * Way better resource management in pccbb, pccard and cardbus. * pccard hot-removal now appears to work. * support pre-fetchable memory in cardbus. * update cardbus to support new pci bus interface functions. * FINALLY fix cardbus CIS reading, it should no longer freeze your machine. (I seem to recall fixing this before, but oh well...) * variable renames in pccbb cause I was getting confused which was which. What's not there: * style(9) complience in portions of code (will fix those separately) * a simpler version of the cis reading interface * a complete implementation of CIS tuple parsing Again, I would appreciate any testing and/or comments on this. BTW, does anyone have a copy of the pccard specs, or know of some other resource for a complete description of cis tuples? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cron program core dumped (signal 11)
On Mon, Jul 16, 2001 at 06:00:01PM +0200, Chojin wrote: cd /usr/src/usr.sbin/cron make cleandir depend make CFLAGS=-ggdb -g3 STRIP= all install ..then run '/usr/sbin/cron' from the command line, and see if it leaves a coredump in the current directory. If it does, then do the following: gdb /usr/sbin/cron /path/to/cron.core (at the gdb prompt) bt info local up info local up info local [repeat until highest level] Hm. Now that I kinda tested this, cron doesn't seem to leave a corefile. Well, still.. this message was redirected to -stable in the hope that somebody there would know better how to help :\ G'luck, Peter -- This sentence claims to be an Epimenides paradox, but it is lying. Okay, I followed your instructions: (I purposefully redirected this to -stable.. since you don't want to acknowledge it is a -stable issue, staying on -hackers this time..) The stack trace you posted seems to imply that cron is dying while processing rico's crontab, and is dying at such a point in the code that would indicate that rico's account has expired. Is that the case? If so, then the easiest thing for you to do would be to remove rico's crontab (crontab -u rico -l rico.cron.save crontab -u rico -r) until rico's account is reactivated or totally removed. G'luck, Peter -- .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Network performance tuning.
Matt Dillon wrote: Also, the algorithm is less helpful when it has to figure out the optimal transmit buffer size for every new connection (consider a web server). I am considering ripping out the ssthresh junk from the stack, which does not work virtually at all, and using the route table's ssthresh field to set the initial buffer size for the algorithm. The state of the art for initial window size is flow monitoring at the next hop router, with feedback to the host system. A gross approximation is called fast start. ClickArray has a patch for this, which could potentially be released back to FreeBSD; I will check with TPTB... it's a pretty trivial version of the RFC'ed initial window scaling. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Whitespace at end of line
Wilko Bulte wrote: Maybe I'm just plain dim today (I will add a beer to rectify this situation at first convenience..) but what is so bad about some trailing whitespace that a massive commit-a-thlon is called for? just wondering, Wilko You use emacs, don't you? 8-) 8-) -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3
On Fri, 13 Jul 2001, Bill Paul wrote: For those who have gigabit ethernet NICs based on the National Semiconductor DP83820 and DP83821 controller chips and want to use them with FreeBSD 4.2 and 4.3, there is a driver kit now available at the following URL: ... These cards are all extremely cheap (some can be had for under $100) and fairly easy to find. (I now have one in my workstation.) They could potentially become extremely popular, which is why I'm making a driver retrofit kit available. Anyone running a recent 4-STABLE or 5.0-CURRENT system should already have the necessary driver support. How do these perform compared to the more expensive gigabit cards? Mike Silby Silbersack They're okay. The NatSemi chip has one flaw, which is that RX buffers must be aligned on a 64-bit boundary. None of the more expensive NICs have this restriction. The correct way to deal with this is to copy frames on receive to fixup the alignment, but I decided to make this conditional for this driver: on the i386 platform, the driver omits the copy since unaligned accesses are allowed, and the performance hit for copying is severe when you're using jumbo frames. On the alpha, you have to do the copy. The chip has some nifty features though: hardware VLAN tag insertion and removal, TCP/IP checksum offload on receive and transmit, 2048-bit multicast hash filter, and 4 pattern match buffers for use with WOL. The transmit checksum offload has to be turned off if you use jumbo frames larger than about 8K, because the chip only has an 8K transmit FIFO. There is also support for interrupt moderation. For $90 to $120, they're a good bargain. You should be able get at least 300 to 400Mbps on good x86 hardware (with TCP). -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: init
[EMAIL PROTECTED] wrote: i need to TAILQ_INIT a queue at kernel startup .. how can i do it in my code? reg Grep for SYSINIT in the kernel sources. Do your initialization as late as possible, but before the queue is used. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: pagedaemon + vmdaemon
Dan wrote: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root2 14.2 0.0 00 ?? DL Tue11AM 4:35.33 (pagedaemon) root3 12.7 0.0 00 ?? DL Tue11AM 1:56.25 (vmdaemon) Cpu kept hitting high load averages on machines for about 1 min periods on some machines on some apache servers. I wrote a script to catch the offending processes and it seems to be these ones. Ideas on why they would be taking that much cpu? Generally speaking, it probably means that you are swapping a lot because you are running more programs than you have RAM available to run. If you add RAM, or run fewer programs, this will go away. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3
Mike Silbersack wrote: For those who have gigabit ethernet NICs based on the National Semiconductor DP83820 and DP83821 controller chips and want to use them with FreeBSD 4.2 and 4.3, there is a driver kit now available at the following URL: ... These cards are all extremely cheap (some can be had for under $100) and fairly easy to find. (I now have one in my workstation.) They could potentially become extremely popular, which is why I'm making a driver retrofit kit available. Anyone running a recent 4-STABLE or 5.0-CURRENT system should already have the necessary driver support. How do these perform compared to the more expensive gigabit cards? Read the driver. In general, they require an extra copy because of the inability of the card to DMA on a reasonable boundry. Bill's commentary in his drivers is frequently enlightening, and often amusing... 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: HP9000/L1000
To All, Recently, a few people mentioned that there is interest in porting FreeBSD to HP's PA-RISC platforms. The following URL has documentation and an early release of the Linux PA-RISC port. I am not affiliated with the project, but I would like to see FreeBSD on more platforms. I hope the URL helps. http://parisc-linux.org -- Terry Lee Hewlett-Packard Company [EMAIL PROTECTED] Internet and Applications Systems Lab Tel: (916) 748-23528000 Foothills Blvd., MS 5596 Fax: (916) 748-2337Roseville, CA 95747-5596 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cron program core dumped (signal 11)
In fact, rico account has expired. I removed expiration ,then now cron works. But I thought cron had no problem if an account expires. Strange... :p Thanks for all. Regards. Chojin - Original Message - From: Peter Pentchev [EMAIL PROTECTED] To: Chojin [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, July 16, 2001 6:39 PM Subject: Re: Cron program core dumped (signal 11) On Mon, Jul 16, 2001 at 06:00:01PM +0200, Chojin wrote: cd /usr/src/usr.sbin/cron make cleandir depend make CFLAGS=-ggdb -g3 STRIP= all install ..then run '/usr/sbin/cron' from the command line, and see if it leaves a coredump in the current directory. If it does, then do the following: gdb /usr/sbin/cron /path/to/cron.core (at the gdb prompt) bt info local up info local up info local [repeat until highest level] Hm. Now that I kinda tested this, cron doesn't seem to leave a corefile. Well, still.. this message was redirected to -stable in the hope that somebody there would know better how to help :\ G'luck, Peter -- This sentence claims to be an Epimenides paradox, but it is lying. Okay, I followed your instructions: (I purposefully redirected this to -stable.. since you don't want to acknowledge it is a -stable issue, staying on -hackers this time..) The stack trace you posted seems to imply that cron is dying while processing rico's crontab, and is dying at such a point in the code that would indicate that rico's account has expired. Is that the case? If so, then the easiest thing for you to do would be to remove rico's crontab (crontab -u rico -l rico.cron.save crontab -u rico -r) until rico's account is reactivated or totally removed. G'luck, Peter -- .siht ekil ti gnidaer eb d'uoy ,werbeH ni erew ecnetnes siht fI To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3
In a message dated 07/16/2001 1:11:09 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: How do these perform compared to the more expensive gigabit cards? Read the driver. In general, they require an extra copy because of the inability of the card to DMA on a reasonable boundry. Bill's commentary in his drivers is frequently enlightening, and often amusing... 8-). Maybe at some point he'll get that the boundry issue is a pci bus-mastering spec issue and not a controller design flaw, as he seems to harp on this in just about every driver? A more important question is are these 32-bit cards, and if so, do they have enough internal buffer to do sustained 1GB transfers. Generally 32-bit PCI is too slow for GB, as it cant do sustained 1GB transfers. Some 32-bit GB cards are just a total waste. Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3
Hi, [EMAIL PROTECTED] wrote: In a message dated 07/16/2001 1:11:09 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: How do these perform compared to the more expensive gigabit cards? Read the driver. In general, they require an extra copy because of the inability of the card to DMA on a reasonable boundry. Bill's commentary in his drivers is frequently enlightening, and often amusing... 8-). Maybe at some point he'll get that the boundry issue is a pci bus-mastering spec issue and not a controller design flaw, as he seems to harp on this in just about every driver? That's incorrect, there no nothing limiting a PCI device for doing busmastering on a byte boundary The reason why not that many devices support it, especially on the receive side, is that the circuit gets more complicated. Another thing, since there is all this hardware that requires alignment, maybe we should consider modifying FreeBSD so receive buffers are aligned, afaik, Linux use aligned receive buffers But I don't know how complicated that would be, so please don't flame me :-) A more important question is are these 32-bit cards, and if so, do they have enough internal buffer to do sustained 1GB transfers. Generally 32-bit PCI is too slow for GB, as it cant do sustained 1GB transfers. Some 32-bit GB cards are just a total waste. Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3
In a message dated 07/16/2001 1:54:25 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: Maybe at some point he'll get that the boundry issue is a pci bus- mastering spec issue and not a controller design flaw, as he seems to harp on this in just about every driver? That's incorrect, there no nothing limiting a PCI device for doing busmastering on a byte boundary The reason why not that many devices support it, especially on the receive side, is that the circuit gets more complicated. the fact that you can fudge it in circuitry doesnt change the way that transfers work. B To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Whitespace at end of line
On Mon, Jul 16, 2001 at 09:42:22AM -0700, Terry Lambert wrote: Wilko Bulte wrote: Maybe I'm just plain dim today (I will add a beer to rectify this situation at first convenience..) but what is so bad about some trailing whitespace that a massive commit-a-thlon is called for? just wondering, Wilko You use emacs, don't you? No, vi. My first experiences with Unix (SysV.2) were in the days that Emacs was considered anti-social (on 8MB memory machines with 68020 CPUs). W/ -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Youth is not a time in life, it is a state of mind To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Whitespace at end of line
You use emacs, don't you? No, vi. My first experiences with Unix (SysV.2) were in the days that Emacs was considered anti-social (on 8MB memory machines with 68020 CPUs). What, you mean you *haven't* run emacs on a Sun-3/50 with 4 Mbytes? :-) Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Whitespace at end of line
On Mon, Jul 16, 2001 at 08:39:04PM +0200, [EMAIL PROTECTED] wrote: You use emacs, don't you? No, vi. My first experiences with Unix (SysV.2) were in the days that Emacs was considered anti-social (on 8MB memory machines with 68020 CPUs). What, you mean you *haven't* run emacs on a Sun-3/50 with 4 Mbytes? :-) No. I did run SunOS 3.5 on them but that was without Emacs. The 3/50 was an upgrade of our 2/120 ;-) Ever tried compiling X on a 2/120? :) W/ -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Youth is not a time in life, it is a state of mind To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cron program core dumped (signal 11)
On Mon, Jul 16, 2001 at 07:42:14PM +0200, Chojin wrote: In fact, rico account has expired. I removed expiration ,then now cron works. But I thought cron had no problem if an account expires. Strange... :p Yeah, it shouldn't do that. Kris PGP signature
Re: Whitespace at end of line
On Mon, Jul 16, 2001 at 09:42:22AM -0700, Terry Lambert wrote: Wilko Bulte wrote: Maybe I'm just plain dim today (I will add a beer to rectify this situation at first convenience..) but what is so bad about some trailing whitespace that a massive commit-a-thlon is called for? just wondering, Wilko You use emacs, don't you? What does vi vs. emacs have to do with it? -- -- David, a Vi user. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3
On Monday, July 16, 2001, at 12:57 PM, Bill Paul wrote: [...] The chip has some nifty features though: hardware VLAN tag insertion and removal, TCP/IP checksum offload on receive and transmit, 2048-bit multicast hash filter, and 4 pattern match buffers for use with WOL. What is WOL? Wake on LAN. The transmit checksum offload has to be turned off if you use jumbo frames larger than about 8K, because the chip only has an 8K transmit FIFO. There is also support for interrupt moderation. Does it automatically not checksum packets 8K, or does A Bad Thing happen if you fail to turn it off first? It does a Bad Thing (tm). In my testing, trying to send a frame larger than 8170 bytes puts the transmitter to sleep. Normally, the chip acknowledges transmit commands with three interrupt indications: TX DMA done (packet was transfered to the chip), TX done (packet made it to the wire), TX idle (TX queue empty, waiting for more packets). If you have transmit checksums enabled and send a frame larger than 8170 bytes, you get the TX DMA done interrupt, but nothing else. The transmitter stops responding after that, and eventually a watchdog timeout is triggered which resets the NIC. The driver disables TX checksum offloading if you set the MTU above a certain threshold. I think at that point, the performance gain from using jumbo frames is greater than that of using TX checksum offload anyway (for sustained transfers anyway). For the record, the chip allows TX checksum offload on a global or per-packet basis. I use the per-packet method, and simply don't set the I want TX checksums computed bits in the TX DMA descriptors once the MTU is set above the threshold (I also clear the if_hwassist flags so the OS will go back to computing the checksums itself). -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Whitespace at end of line
On Mon, Jul 16, 2001 at 08:40:09PM +0200, Wilko Bulte wrote: On Mon, Jul 16, 2001 at 08:39:04PM +0200, [EMAIL PROTECTED] wrote: You use emacs, don't you? No, vi. My first experiences with Unix (SysV.2) were in the days that Emacs was considered anti-social (on 8MB memory machines with 68020 CPUs). What, you mean you *haven't* run emacs on a Sun-3/50 with 4 Mbytes? :-) No. I did run SunOS 3.5 on them but that was without Emacs. The 3/50 was an upgrade of our 2/120 ;-) Ever tried compiling X on a 2/120? :) It's even not fun with these: ticso@cicely41:~ dmesg | head NetBSD 1.5V (CICELY41) #1: Sat May 19 21:52:45 CEST 2001 [EMAIL PROTECTED]:/net/10.1.1.22/var/d21/NetBSD/src/sys/arch/sun3/compile/CICELY41 Model: sun3 60 fpu: mc68881 total memory = 24576 KB avail memory = 21888 KB using 166 buffers containing 1328 KB of memory mainbus0 (root) obio0 at mainbus0 zsc0 at obio0 addr 0x0 ipl 6: (softpri 3) ticso@cicely41:~ uptime 9:48PM up 43 days, 6:42, 3 users, load averages: 0.18, 0.12, 0.09 I also own two 3/50 but 4M is not realy much today. But now that NetBSD has official support for sun2 Machines ;) -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Save Up To 70% On Music For Your Business!
Title: Welcome If you cannot read this eMail, please go tohttp://www.nwd42.com/s.asp?N=Zwm8Yq3701v~HNHIEGDCEOYJCHGDFHJhO Welcome ! FINALLY, AFFORDABLE MUSIC FOR YOUR BUSINESS! Some things just make sense. Like playing music in your business that your customers and staff enjoy. Choosing the right music builds atmosphere and creates a positive experience for your customers. Research has consistently revealed that a direct result of foreground music is that customers stay longer, spend more money and return more often. Youve probably experienced this for yourself. Right?Now you can put professionally programmed music to work for your business. PlayNetwork Online is the first music service in the world to make it simple, convenient and affordable for businesses like yours to subscribe to a monthly music service online. PlayNetwork Online is a music subscription service that lets you pick from fresh mixes of original artist music or create your own custom programs online. A few mouse clicks and youre all set, leaving you to more important things like spending time with your customers. Once you've subscribed, we'll automatically deliver a brand new CD ROM containing over 8 hours of music directly to your business every month.Visit our web site and subscribe today.Add life to your business with music!Or Call Us At 1-866-752-9321 For More Information.Call MeeMail UsSUBSCRIBE TODAY AND SAVE! Click here to configure your eMail preference:http://www.nwd42.com/s.asp?N=Zwm8Yq3701v~HNHIEGDCEOYJCHGDFHJXb Click here to unsubscribe:http://www.nwd42.com/s.asp?N=Zwm8Yq3701v~HNHIEGDCEOYJCHGDFHJfN
Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3
On Mon, 16 Jul 2001, Bill Paul wrote: They're okay. The NatSemi chip has one flaw, which is that RX buffers must be aligned on a 64-bit boundary. None of the more expensive NICs have this restriction. Go ahead and beat me up if you have to :-) But why is there _any_ issue with RX buffer alignment? I get some mbufs and set the data pointer to any point I want, or I get a cluster, which is always on a 2k boundary. The OS wants the _payload_ to be aligned on a 32-bit boundary. It tries to do 32-bit accesses to the IP header, and the NFS code also does 32-bit accesses when trying to un-XDR NFS requests. In both cases, the code assumes that the data will be aligned on a 32-bit boundary. On the x86, the alignment doesn't matter: you can do 32-bit loads and stores from arbitrary boundaries and the CPU will fake things up for you so that you won't generate an unaligned access trap, though there will be a slight performance penalty. But on other CPUs such as the alpha, SPARC, PPC and (I suspect) the IA-64, unaligned accesses in the kernel generate a fatal trap and a panic. In user space, an unaligned access may result in a bus error, unless the OS is kind enough to handle the trap, which I believe FreeBSD/alpha does. The problem is that the ethernet frame header is only 14 bytes, which means when the chip DMAs to a 32-bit or 64-bit aligned buffer, the payload, which immediately follows the ethernet frame header, ends up on a 16-bit boundary, which is not what we want. You can fix this in one of two ways: if the chip allows it, you can offset the RX buffer address by two bytes and thereby force the payload to be 32-bit aligned, or you can copy the data to a new buffer with the right alignment. Having the chip do it for you is obviously the prefered approach. The chips supported by the fxp, xl, pcn, tl, ste, ti, sk, wx and lge drivers support this. The latter four are all gigE chipsets. Now, before any of you armchair geniuses out there start chiming in with your incredibly brilliant solutions for this problem which you just made up on the spot, forget it. This issue has been discussed to death and there's just no easy way around it. Terry Lambert and Alfred Perlstein, this means you. I mean it. Put down the keyboard and back away from the computer or *blam!* I'll shoot. Now TX buffers are a problem - I have to take what I get and just deal with it. If both start address and length need to be aligned, then I'm pretty much screwed - I have to copy... Most chips place no restrictions on the alignment of TX buffers. The only exceptions I know of where the chip API simply doesn't permit it are the RealTek 8139/if_rl (surprise) and the VIA Rhine I and Rhine II/if_vr. -Bill = -Bill Paul(925) 691-2800 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = I like zees guys. Zey are fonny guys. Just keel one of zem. -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3
The proble is that teh ethernet header is 14 bytes so you must choose to allighn either the whole packet, or the IP header, but you cannot do both. On Mon, 16 Jul 2001, Soren Kristensen wrote: Hi, [EMAIL PROTECTED] wrote: In a message dated 07/16/2001 1:11:09 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: How do these perform compared to the more expensive gigabit cards? Read the driver. In general, they require an extra copy because of the inability of the card to DMA on a reasonable boundry. Bill's commentary in his drivers is frequently enlightening, and often amusing... 8-). Maybe at some point he'll get that the boundry issue is a pci bus-mastering spec issue and not a controller design flaw, as he seems to harp on this in just about every driver? That's incorrect, there no nothing limiting a PCI device for doing busmastering on a byte boundary The reason why not that many devices support it, especially on the receive side, is that the circuit gets more complicated. Another thing, since there is all this hardware that requires alignment, maybe we should consider modifying FreeBSD so receive buffers are aligned, afaik, Linux use aligned receive buffers But I don't know how complicated that would be, so please don't flame me :-) A more important question is are these 32-bit cards, and if so, do they have enough internal buffer to do sustained 1GB transfers. Generally 32-bit PCI is too slow for GB, as it cant do sustained 1GB transfers. Some 32-bit GB cards are just a total waste. Soren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3
On Mon, 16 Jul 2001, Bill Paul wrote: On Mon, 16 Jul 2001, Bill Paul wrote: They're okay. The NatSemi chip has one flaw, which is that RX buffers must be aligned on a 64-bit boundary. None of the more expensive NICs have this restriction. Go ahead and beat me up if you have to :-) But why is there _any_ issue with RX buffer alignment? I get some mbufs and set the data pointer to any point I want, or I get a cluster, which is always on a 2k boundary. The OS wants the _payload_ to be aligned on a 32-bit boundary. It tries to do 32-bit accesses to the IP header, and the NFS code also does 32-bit accesses when trying to un-XDR NFS requests. Oh... I see... I guess you could grab an mbuf and copy just the IP header for that, no? (Just curious at this point :-) But on other CPUs such as the alpha, SPARC, PPC and (I suspect) the IA-64, unaligned accesses in the kernel generate a fatal trap and a panic. In user space, an unaligned access may result in a bus error, unless the OS is kind enough to handle the trap, which I believe FreeBSD/alpha does. I don't think that is the case. I seem to remember FreeBSD Alpha 4.3 sysinstall croaking on me once with an alignment error. Most chips place no restrictions on the alignment of TX buffers. The only exceptions I know of where the chip API simply doesn't permit it are the RealTek 8139/if_rl (surprise) and the VIA Rhine I and Rhine II/if_vr. And the IDT 77211 ATM SAR chip. Fortunately, most of the PDUs I see are perfectly aligned, and no copy is needed. Thanks for the explanation! -Richard --- Richard Hodges | Matriplex, inc. Product Manager | 769 Basque Way [EMAIL PROTECTED] | Carson City, NV 89706 775-886-6477| www.matriplex.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: pagedaemon + vmdaemon
ya it seems it is running into swap abit. hmmm watching apache with truss i see alot of error #35's in the sys callswhat is that related to again? On Mon, 16 Jul 2001, John Baldwin wrote: Date: Mon, 16 Jul 2001 13:03:33 -0700 (PDT) From: John Baldwin [EMAIL PROTECTED] To: Dan [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: pagedaemon + vmdaemon On 16-Jul-01 Dan wrote: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root2 14.2 0.0 00 ?? DL Tue11AM 4:35.33 (pagedaemon) root3 12.7 0.0 00 ?? DL Tue11AM 1:56.25 (vmdaemon) Cpu kept hitting high load averages on machines for about 1 min periods on some machines on some apache servers. I wrote a script to catch the offending processes and it seems to be these ones. Ideas on why they would be taking that much cpu? These processes manage the VM paging, so perhaps you are running low on memory and trashing? -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Debugging natd?
The machine I redirected telnet too has changed IP addresses... And; I discovered after simply changing my natd_flags in /etc/rc.conf that natd isn't properly redirecting the port. I checked the messages log (/var/log/alias.log) and nothing appears to be amiss. (And, I've got -l on the natd_flags; but nothing is showing up in syslog) Here's the flags (this is 4.3-RELEASE): natd_flags=-l -m -u -redirect_port tcp 10.1.0.11:telnet -redirect_port udp 10.1.0.11:telnet -redirect_port tcp 10.1.0.26:telnet -redirect_port u dp 10.1.0.26:telnet (The previous/working IP addreses were 10.0.0.11 10.0.0.26.) So - per the subject - just how does one start debugging a problem like this - what tools are around to try and figure things out? - Thanks! - - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3
The OS wants the _payload_ to be aligned on a 32-bit boundary. It tries to do 32-bit accesses to the IP header, and the NFS code also does 32-bit accesses when trying to un-XDR NFS requests. Oh... I see... I guess you could grab an mbuf and copy just the IP header for that, no? (Just curious at this point :-) That doesn't work for the NFS case: an XDR-encoded packet may contain lots of different fields separated by 32-bit length markers. Also, there's a religious issue, namely a violation of protocol boundaries. This is an ethernet driver: it's not supposed to have any really intimate knowledge of IP or TCP or UDP, so you really don't want to go mucking about with the frame payload if you can avoid it. (Lastly, my goal here is to make the card work, not re-write the innards of the networking stack or NFS. I really don't want intimate knowledge of IP, TCP or UDP either. :) But on other CPUs such as the alpha, SPARC, PPC and (I suspect) the IA-64, unaligned accesses in the kernel generate a fatal trap and a panic. In user space, an unaligned access may result in a bus error, unless the OS is kind enough to handle the trap, which I believe FreeBSD/alpha does. I don't think that is the case. I seem to remember FreeBSD Alpha 4.3 sysinstall croaking on me once with an alignment error. No no: an unaligned access trap in the kernel is fatal, but an unaligned access trap in a *user-space* process is not. Once in a while you will see messages on the console about unaligned access traps generated by user programs, but these don't panic the system. In the case of FreeBSD/alpha, we fake it up so know about the problem but the process keeps running. Some OSes (e.g. Solaris) clobber the process with a SIGBUS. Some would argue the latter behavior is better since it makes it easier to find and fix what is probably a bug in the first place. -Bill -- = -Bill Paul(925) 691-2800 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = I like zees guys. Zey are fonny guys. Just keel one of zem. -- The 3 Amigos = To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Whitespace at end of line
From: David O'Brien [EMAIL PROTECTED] Subject: Re: Whitespace at end of line Date: Mon, Jul 16, 2001 at 12:31:02PM -0700 On Mon, Jul 16, 2001 at 09:42:22AM -0700, Terry Lambert wrote: Wilko Bulte wrote: Maybe I'm just plain dim today (I will add a beer to rectify this situation at first convenience..) but what is so bad about some trailing whitespace that a massive commit-a-thlon is called for? just wondering, Wilko You use emacs, don't you? What does vi vs. emacs have to do with it? It's probably one of those rumours that Emacs likes playing smart and $ adding whitespace to the end of wrapped lines. Lies, damn lies. $ $ -giorgos $ $ (a happy emacs user who also feels comfortable with vi, joe, pico, whatever) $ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
trying to do two pcmcia network cards (ep0 ep1)
/etc/rc.conf looks like this: pccard_enable=YES pccard_mem=DEFAULT pccardd_flags= -i 10 -i 15 removable_interfaces=ep0 ep1 /etc/defaults/pccard.conf has this: io 0x240-0x360 irq 10 15 memory 0xd4000 96k and I added a second config line to the ep0 line like this: config auto ep 10 config auto ep 15 (the rest of the 3c589 A/B/C/D entry is unchanged) So when I boot with the two 3com cards in the system, only one of them works - it comes up at port 0x240-0x24f irq 10 slot 0. When the second one tries to come up, it says: No free configuration for card 3com Any help is appreciated. I would also like to know what no free configuration for... means - does that mean there is no free irq for it ? or something else ? thanks! _ Get your FREE download of MSN Explorer at http://explorer.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Weird named problem - IN A for nameservers being lost!
I've been trying to track down a weird problem with our mail system suddenly believing that a host does not exist, or timing out in DNS. I tracked it down to the DNS server, but I am not entirely sure what is going on. What appears to be happening is that the glue IN A record for the NS server for a domain is getting lost, and the NS record is remaining. When named gets into this state, it doesn't seem to be able to recover... it sees the NS record but it can't resolve it because the glue record is gone, and it doesn't try to get it after that. If you look at the cache dumps and dig output below, you can clearly see the timeout for fuji.jamcracker.com is less then the timeout for jamcracker.com AFTER we've looked up other elements for fuji, which means that when it timed out, that IN A record will be gone. But that IN A record is the IP address for the NS. So when it times out, the jamcracker entry is left there with no NS records whatsoever. I believe what is happening is that something is looking up other records for fuji, and this is replacing the original glue record with the real IN A record, but also changing the timeouts somehow and causing fuji's record to timeout early. As far as I can tell, this is an extremely serious bug in named. I am running 8.2.3. This has occured with several mail destinations, not just jamcracker. I went through jamcrackers whole DNS hierarchy and everything is setup properly, including all the timeouts (they are all set to 3600 seconds). Has anyone else seen this? Anyone know what is going on here? -Matt --- Here is a cache dump of a case where 'nslookup -query=mx jamcracker.com' no longer works. Everything with jamcracker in it is being dumped: jamcracker 2436IN SOA fuji.jamcracker.com. hostmaster.jamcracker.com. ( 2001062900 10800 3600 1728000 3600 );Cr=auth [216.32.126.150] ; 2436IN fuji.jamcracker.com. hostmaster.jamcracker.com. ( ; 2001062900 10800 3600 1728000 3600 );jamcracker.com.;NODATA ;-$ ;Cr=auth [216.32.126.150] 2436IN NS fuji.jamcracker.com.;Cr=auth [216.32.126.150] 2436IN A 66.35.217.100 ;Cr=auth [216.32.126.150] And here is a cache dump after I restart named and do the same nslookup: jamcracker 3591IN NS fuji.jamcracker.com.;Cr=auth [216.32.126.150] 3591IN MX 5 va2mc.ummailbox.net. ;Cr=auth [216.32.126.150] $ORIGIN jamcracker.com. fuji3591IN A 66.35.220.151 ;Cr=addtnl [216.32.126.150] And here is a dump after named has been running a while: jamcracker 2016IN NS fuji.jamcracker.com.;Cr=auth [216.32.126.150] 2016IN MX 5 va2mc.ummailbox.net. ;Cr=auth [216.32.126.150] 2206IN SOA fuji.jamcracker.com. hostmaster.jamcracker.com. ( 2001062900 10800 3600 1728000 3600 );Cr=auth [66.35.220.151] ; 2206IN fuji.jamcracker.com. hostmaster.jamcracker.com. ( ; 2001062900 10800 3600 1728000 3600 );jamcracker.com.;NODATA ;-$ ;Cr=auth [66.35.220.151] 3140IN A 66.35.217.100 ;Cr=auth [66.35.220.151] $ORIGIN jamcracker.com. fuji1846IN A 66.35.220.151 ;NT=13 Cr=addtnl [216.32.126.150] ; 2213IN fuji.jamcracker.com. hostmaster.jamcracker.com. ( ; 2001062900 10800 3600 1728000 3600 );jamcracker.com.;NODATA ;-$ ; And here is the dig output. earth:/etc/namedb# dig jamcracker.com ; DiG 8.3 jamcracker.com ;; res options: init recurs defnam dnsrch ;; got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUERY SECTION: ;; jamcracker.com, type = A, class = IN ;; ANSWER SECTION: jamcracker.com. 50m27s IN A 66.35.217.100 ;; AUTHORITY SECTION: jamcracker.com. 31m43s IN NSfuji.jamcracker.com. ;; ADDITIONAL SECTION: fuji.jamcracker.com.28m53s IN A 66.35.220.151 ;; Total query time: 1 msec ;; FROM: earth.backplane.com to SERVER: default -- 127.0.0.1 ;; WHEN: Mon Jul 16 17:36:13 2001 ;; MSG SIZE sent: 32 rcvd: 83 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Whitespace at end of line
On Mon, Jul 16, 2001 at 12:31:02PM -0700, David O'Brien wrote: On Mon, Jul 16, 2001 at 09:42:22AM -0700, Terry Lambert wrote: Wilko Bulte wrote: Maybe I'm just plain dim today (I will add a beer to rectify this situation at first convenience..) but what is so bad about some trailing whitespace that a massive commit-a-thlon is called for? just wondering, Wilko You use emacs, don't you? What does vi vs. emacs have to do with it? The beer. -- Castles are sacked in war, Chieftains are scattered far, Truth is a fixed star, Eileen aroon! -- Gerald Griffin __ Charles Shannon Hendrix s h a n n o n @ w i d o m a k e r . c o m To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Weird named problem - IN A for nameservers being lost!
On Mon, 16 Jul 2001, Matt Dillon wrote: I've been trying to track down a weird problem with our mail system suddenly believing that a host does not exist, or timing out in DNS. I tracked it down to the DNS server, but I am not entirely sure what is going on. What appears to be happening is that the glue IN A record for the NS server for a domain is getting lost, and the NS record is remaining. When named gets into this state, it doesn't seem to be able to recover... it sees the NS record but it can't resolve it because the glue record is gone, and it doesn't try to get it after that. This looks like a problem brought up on the djbdns mailing list a long while ago. When the NS records listed with the roots and the NS records returned by the NSes don't match (or share any NSes whatsoever, for that matter), BIND breaks as you've described. The resolution, as I recall, was don't do that! Bind 9 might handle the case correctly, as might djbdns. In any case, the admins of jamcracker.com should be synchronizing their NS listings. Here's how it is now: dig jamcracker.com NS ; DiG 8.3 jamcracker.com NS ;; res options: init recurs defnam dnsrch ;; got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUERY SECTION: ;; jamcracker.com, type = NS, class = IN ;; ANSWER SECTION: jamcracker.com. 2D IN NSSCA03.SEC.DNS.EXODUS.NET. jamcracker.com. 2D IN NSSCA02.SEC.DNS.EXODUS.NET. dig jamcracker.com NS @sca03.sec.dns.exodus.net ; DiG 8.3 jamcracker.com NS @sca03.sec.dns.exodus.net ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; QUERY SECTION: ;; jamcracker.com, type = NS, class = IN ;; ANSWER SECTION: jamcracker.com. 1H IN NSfuji.jamcracker.com. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3
[EMAIL PROTECTED] writes: A more important question is are these 32-bit cards, and if so, do they have enough internal buffer to do sustained 1GB transfers. Generally 32-bit PCI is too slow for GB, as it cant do sustained 1GB transfers. Some 32-bit GB cards are just a total waste. The two cards that I have experience with are the Netgear GA622T and SMC9462TX. Both are 64-bit/66MHz cards. The first nge cards we tried were a pair of Netgear GA622T boards. They leave a lot to be desired. We put them in our Dell PowerEdge 4400 boxes (Serverworks chipset with interleaved ram and 64-bit/66MHz PCI, 733MHz Xeon) hooked them up through our Extreme Summit 7i Gigabit switch (Copper). They have a decent packets/second rate for minimally sized packets (155,000 packets/sec or so), but they have serious trouble filling the link with UDP packets -- even with jumbo frames, I can't seem to push more than 450Mb/sec out of them. At this point, we figured the NatSemi DP8382x was just a lousy chipset, so we ordered a pair of SMC9462TX boards. Based on comments which used to be in the lge driver, we assumed that they used the Level 1 LXT1001 chips. However, we found out that the SMC9462TX boards that we have use the NatSemi DP8382x. (Perhaps the SMC9462SX uses the LXT1001?) We were pleasantly surprised to learn that the nge based SMC boards do perform well. Using the same hosts switch as above, we can nearly fill the link with 1500 byte packets (950Mb/sec, I think). And they can also sustain more than 155,000 minimally sized packets/sec. They can easily fill the link with jumbo frames, but then there's that 8k tx fifo checksum limitation. Hope this helps, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Weird named problem - IN A for nameservers being lost!
: : :On Mon, 16 Jul 2001, Matt Dillon wrote: : : I've been trying to track down a weird problem with our mail system : suddenly believing that a host does not exist, or timing out in DNS. : : I tracked it down to the DNS server, but I am not entirely sure what is : going on. What appears to be happening is that the glue IN A record : for the NS server for a domain is getting lost, and the NS record is : remaining. When named gets into this state, it doesn't seem to be able : to recover... it sees the NS record but it can't resolve it because : the glue record is gone, and it doesn't try to get it after that. : :This looks like a problem brought up on the djbdns mailing list a long :while ago. When the NS records listed with the roots and the NS records :returned by the NSes don't match (or share any NSes whatsoever, for that :matter), BIND breaks as you've described. : :The resolution, as I recall, was don't do that! Bind 9 might handle the :case correctly, as might djbdns. In any case, the admins of :jamcracker.com should be synchronizing their NS listings. : :Here's how it is now: I don't think that's it... if you look at the dumps, there were no timeouts in the 2-day range. The original glue NS records (from exodus) had already been completely replaced by the NS record from their zone. Everything in their zones is already synchronized. -Matt : dig jamcracker.com NS : :; DiG 8.3 jamcracker.com NS :;; res options: init recurs defnam dnsrch :;; got answer: :;; -HEADER- opcode: QUERY, status: NOERROR, id: 4 :;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 :;; QUERY SECTION: :;; jamcracker.com, type = NS, class = IN : :;; ANSWER SECTION: :jamcracker.com. 2D IN NSSCA03.SEC.DNS.EXODUS.NET. :jamcracker.com. 2D IN NSSCA02.SEC.DNS.EXODUS.NET. : : dig jamcracker.com NS @sca03.sec.dns.exodus.net : :; DiG 8.3 jamcracker.com NS @sca03.sec.dns.exodus.net :; (1 server found) :;; res options: init recurs defnam dnsrch :;; got answer: :;; -HEADER- opcode: QUERY, status: NOERROR, id: 6 :;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 :;; QUERY SECTION: :;; jamcracker.com, type = NS, class = IN : :;; ANSWER SECTION: :jamcracker.com. 1H IN NSfuji.jamcracker.com. : :Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3
Bill Paul writes: by user programs, but these don't panic the system. In the case of FreeBSD/alpha, we fake it up so know about the problem but the process keeps running. Some OSes (e.g. Solaris) clobber the process with a SIGBUS. Some would argue the latter behavior is better since it makes it easier to find and fix what is probably a bug in the first place. Actually, you can control this behaviour with the uac (1) command on FreeBSD/alpha. 'uac -s' causes unaligned access errors to result in a SIGBUS being delivered to the parent and its future descendants. You can also enable/disable printing of errors, etc. Really handy when you're using a ghostscript not built w/Compaq C. Also, Tru64 has a similar command with the same name and different syntax. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Weird named problem - IN A for nameservers being lost!
On Mon, 16 Jul 2001, Matt Dillon wrote: I don't think that's it... if you look at the dumps, there were no timeouts in the 2-day range. The original glue NS records (from exodus) had already been completely replaced by the NS record from their zone. Everything in their zones is already synchronized. -Matt If I recall correctly, what you're describing above *causes* the problem. Their NSes have to be synced with the roots. I tried searching the archives, and I can't find the messages talking about the topic. I did find djb's page with his rants about dns breakages, and at the end of one he mentions: Beware that, because of the ``credibility'' rules described above, the NS records from the child servers must include the NS records from the parent. Otherwise an attacker can break BIND's access to the child servers. This is from: http://cr.yp.to/djbdns/notes.html So, there's something to it, though I no longer remember exactly why. Read through that page, he seems to be trying to explain the problem. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Weird named problem - IN A for nameservers being lost!
: : :On Mon, 16 Jul 2001, Matt Dillon wrote: : : I don't think that's it... if you look at the dumps, there were no timeouts : in the 2-day range. The original glue NS records (from exodus) had already : been completely replaced by the NS record from their zone. Everything in : their zones is already synchronized. : : -Matt : :If I recall correctly, what you're describing above *causes* the problem. :Their NSes have to be synced with the roots. : :I tried searching the archives, and I can't find the messages talking :about the topic. I did find djb's page with his rants about dns :breakages, and at the end of one he mentions: : :Beware that, because of the ``credibility'' rules described above, the NS :records from the child servers must include the NS records from the :parent. Otherwise an attacker can break BIND's access to the child :servers. : :This is from: http://cr.yp.to/djbdns/notes.html : :So, there's something to it, though I no longer remember exactly why. :Read through that page, he seems to be trying to explain the problem. : :Mike Silby Silbersack Interesting. He describes in the section about 'expiring glue' creating loops in the DNS server, but doesn't mention a particular bug. However, there's another section where he mentions something about bind reducing the TTL by 5% for certain credibility cases. Going back to my original posting... the NS is 2016 and fuji is 1846 = 170 = 5%. I think This credibility stuff reducing the TTL in named is responsible for these blowups. I am going to email the bind group with this whole mess to see what they have to say. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Weird named problem - IN A for nameservers being lost!
On Mon, 16 Jul 2001, Matt Dillon wrote: Interesting. He describes in the section about 'expiring glue' creating loops in the DNS server, but doesn't mention a particular bug. However, there's another section where he mentions something about bind reducing the TTL by 5% for certain credibility cases. Going back to my original posting... the NS is 2016 and fuji is 1846 = 170 = 5%. I think This credibility stuff reducing the TTL in named is responsible for these blowups. I am going to email the bind group with this whole mess to see what they have to say. -Matt I wish you luck in getting it fixed. That 5% may have been intended for removal; 8.1.2 used to reduce the TTL by 5% for _each_ query. That was clearly removed for 8.2, but perhaps the initial decrement was forgotten. However, the problem probably indicates a more serious problem in 8.x's resolver, which may be fixed in 9 and is not intended to be backported. I guess Mark'll have to answer that. (He seems to read and reply to -security, so he appears reachable.) Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
mail failed, returning to sender
|- Message log follows: ---| | no valid recipients were found for this message | |--| | [EMAIL PROTECTED] - unknown user |--| German translation: Sie haben Ihre eMail an die Adresse [EMAIL PROTECTED] gerichtet. Der hintere Teil der Adresse (Domain), @mail.hh.provi.de, ist gueltig, der Benutzernamen jedoch nicht. Ueberpruefen Sie bitte insbesondere diesen Teil der eMail-Adresse! Sie erhalten im Anhang die ersten zehn Zeilen Ihrer Original-eMail zurueck. Mit freundlichen Gruessen, Point of Presence GmbH, Hamburg From [EMAIL PROTECTED] Tue Jul 17 05:01:51 2001 Return-path: [EMAIL PROTECTED] Envelope-to: [EMAIL PROTECTED] Delivery-date: Tue, 17 Jul 2001 05:01:51 +0200 Received: from mx2.freebsd.org ([216.136.204.119]) by mail.provi.de with smtp (Exim 3.20 #2) id 15ML7O-00070G-00 for [EMAIL PROTECTED]; Tue, 17 Jul 2001 05:01:50 +0200 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 84C0055DB9; Mon, 16 Jul 2001 20:01:31 -0700 (PDT) (envelope-from [EMAIL PROTECTED]) Received: by hub.freebsd.org (Postfix, from userid 538) id AA8F437B411; Mon, 16 Jul 2001 20:01:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 8EF8E2E8039; Mon, 16 Jul 2001 20:01:30 -0700 (PDT) (envelope-from owner-freebsd-hackers-digest) Received: by hub.freebsd.org (bulk_mailer v1.12); Mon, 16 Jul 2001 20:01:30 -0700 From: [EMAIL PROTECTED] (freebsd-hackers-digest) To: [EMAIL PROTECTED] Subject: freebsd-hackers-digest V5 #182 Reply-To: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Precedence: bulk Message-ID: [EMAIL PROTECTED] Date: Mon, 16 Jul 2001 20:01:30 -0700 (PDT) freebsd-hackers-digest Monday, July 16 2001 Volume 05 : Number 182 In this issue: mail failed, returning to sender Re: Whitespace at end of line Re: DDB mp3's Re: eXperimental bandwidth delay product code (was Re: Network performance tuning.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
No Subject
auth a170165f subscribe freebsd-hackers [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Weird named problem - IN A for nameservers being lost!
:... : Interesting. He describes in the section about 'expiring glue' : creating loops in the DNS server, but doesn't mention a particular : bug. : : However, there's another section where he mentions something about : bind reducing the TTL by 5% for certain credibility cases. : : Going back to my original posting... the NS is 2016 and fuji : is 1846 = 170 = 5%. : : I think This credibility stuff reducing the TTL in named is : responsible for these blowups. I am going to email the bind group : with this whole mess to see what they have to say. : : -Matt : :I wish you luck in getting it fixed. That 5% may have been intended for :removal; 8.1.2 used to reduce the TTL by 5% for _each_ query. That was :clearly removed for 8.2, but perhaps the initial decrement was forgotten. : :However, the problem probably indicates a more serious problem in 8.x's :resolver, which may be fixed in 9 and is not intended to be backported. I :guess Mark'll have to answer that. (He seems to read and reply to :-security, so he appears reachable.) : :Mike Silby Silbersack I submitted a bug report. Mark and I are talking about it. Basically what it comes down to is that the 5% code is still there, but conditionalized with NOADDITIONAL. That is, if you set NOADDITIONAL then the 5% code is ripped out. I also took a look on Google. The problem appears to be well known for a long time, I just don't know why the bind guys haven't ripped out this 5% code stuff. I am going to commit a change to /usr/src/usr.sbin/named/Makefile.inc (in -current and MFC to -stable 3 days later) that turns on NOADDITIONAL and effectively fixes this problem for 8.2.x. Hopefully the bind guys will rip out the code entirely, it just doesn't belong there. I mean, it's ok for bind to fail instantly, or to allow the case, but it isn't ok for bind to allow the case 40 minutes and then fail from that point on until it's restarted. Judging from the Google, this has been the source of many, many problems, and I don't quite understand why it wasn't ripped out last year. I am also CCing Doug Barton, who appears to be responsible for bind8 in ports. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: math library difference between linux emulation and native freebsd (and native linux)
Terry Lambert writes: [EMAIL PROTECTED] wrote: There are only two shared libaries in common (libc and libm) and both are the same on FreeBSD (in /compat/linux) and Linux. So any ideas on where the program is going wrong? man fpsetround That won't change a thing. Both systems round to nearest. The defaults for the Linux emulator are different than the defaults for Linux. Linux sets some stuff up wrong, FreeBSD sets stuff up wrong. This is a choice between bad and worse, since the CPU does not support what you want. An x86 CPU has a rounding precision that may be set for float, double, or long double. FreeBSD sets the CPU to make double work, giving extra fraction bits for float and truncating long double. Linux sets the CPU to make long double work, giving extra fraction bits for both float and long double. Now what is worse, getting some extra bits in an intermediate calculation or truncation? Note that the FreeBSD setting causes _both_ problems. See float_t, double_t, FLT_EVAL_METHOD and FLT_ROUNDS in the 1999 C standard for ways to deal with x86 hardware. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
