Re: polling for sio?
On Thu, Apr 08, 2004 at 12:34:43PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Marcel Moolenaar [EMAIL PROTECTED] writes: : On Wed, Apr 07, 2004 at 03:36:02PM -0700, othermark wrote: : I have a multi-port PCI card under puc and sio that has 4 19200 : connections to it now, and when data is streaming across all of : them at once, I get several silo overflows. Would it be better : to run this under puc + uart? : : Not really. The problem is that puc(4) iterates over all ports in : the same way whether you use uart(4) or sio(4). So, puc(4) is : the problem more that sio(4) or uart(4). However, uart(4) has the : beginnings of an interface that puc(4) could use to figure out : which UART needs attention without actually calling the interrupt : routine for each of them. Yes, but at 19200 baud, his problems likely aren't related to the iteration. They are likely related to the fact that he said his interrupt is shared and therefore not fast. We have horrible interrupt latency in current when you want to get to the FIFOs of UARTs quickly :-(. Those cards are just what they are - cheap. They have very small FIFOs and they don't use DMA. IRQ sharing makes them even worse than traditional ISA stuff. My advise for cost efficient and fast serials is getting USB ones. Even noname USB serials do much better then puc(4) based. E.g. the FT232BM (uftdi(4)) has 128 bytes send and 384 bytes receive buffer plus your USB controller does DMA. At best you would add a cheap OHCI card if your onboard USB is UHCI based as OHCI is less CPU intensive. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fundraising for FreeBSD development.
Hi, Have a few questions for you. Would the fund raising be handled through FreeBSD or direct to you? Are you taking pledges now? I would assume you would gather pledges over the next month to see if can get the USD16500, if you do, then the pledges become real donations, if you dont, then the pledges become null. If the fund raising is connected with FreeBSD, could people who donate larger amounts get some form of acknowledgement on the FreeBSD site? This would give an incentive for vendors who sell products that rely or use FreeBSD to donate larger amounts. -John On Thu, 8 Apr 2004, Poul-Henning Kamp wrote: http://people.freebsd.org/~phk/funding.html Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
passing messages to routing sockets
I understand that in order to add a new route to the routing
table, one must fill a buffer with an ifa_msghdr header, followed by three
socked adddress structures, representing the destination net/ip, the
netmask and the gateway.
While reading route(4) I encountered this:
struct ifa_msghdr {
..
u_int ifmam_addrs;/* like rtm_addrs */
..
}
Now, the description for the rtm_addrs member of the rt_msghdr
says that this should be a bitmask that identifies sockaddrs in the
message sent to the routing socket.
Could anyone provide a quick/small example on how to fill this
member ? I don't really understand what I should write into it.
Thanks in advance for any interest shown to my problem and any
time spent on enlightening a poor soul :)
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: polling for sio?
On Thu, Apr 08, 2004 at 12:34:43PM -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Marcel Moolenaar [EMAIL PROTECTED] writes: : On Wed, Apr 07, 2004 at 03:36:02PM -0700, othermark wrote: : I have a multi-port PCI card under puc and sio that has 4 19200 : connections to it now, and when data is streaming across all of : them at once, I get several silo overflows. Would it be better : to run this under puc + uart? : : Not really. The problem is that puc(4) iterates over all ports in : the same way whether you use uart(4) or sio(4). So, puc(4) is : the problem more that sio(4) or uart(4). However, uart(4) has the : beginnings of an interface that puc(4) could use to figure out : which UART needs attention without actually calling the interrupt : routine for each of them. Yes, but at 19200 baud, his problems likely aren't related to the iteration. They are likely related to the fact that he said his interrupt is shared and therefore not fast. We have horrible interrupt latency in current when you want to get to the FIFOs of UARTs quickly :-(. Those cards are just what they are - cheap. They have very small FIFOs and they don't use DMA. IRQ sharing makes them even worse than traditional ISA stuff. My advise for cost efficient and fast serials is getting USB ones. Even noname USB serials do much better then puc(4) based. E.g. the FT232BM (uftdi(4)) has 128 bytes send and 384 bytes receive buffer plus your USB controller does DMA. At best you would add a cheap OHCI card if your onboard USB is UHCI based as OHCI is less CPU intensive. I used to use 9600 bps serial links on LSI-11/23 systems 20 years ago to run SLIP over. This was with dumb DL-11 serial adapters on way slower CPUs and busses than we have today. The difference was a much lower interrupt latency. You'd think that running serial links 10 times faster on CPUs that are a few hundred times faster wouldn't be too hard. louie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fundraising for FreeBSD development.
At 5:18 PM -0400 4/8/04, John Von Essen wrote: Hi, Have a few questions for you. Would the fund raising be handled through FreeBSD or direct to you? He has answered that. Funding direct to PHK. Please READ the web page that you quoted from his original message: http://people.freebsd.org/~phk/funding.html Are you taking pledges now? I would assume you would gather pledges over the next month to see if can get the USD16500, if you do, then the pledges become real donations, if you don't, then the pledges become null. He has answered that. Pledges are not money. Pledges are wishes. It is a bad idea to bet your family's financial health and your mortgage on the other people's wish to contribute, even if those wishes are well-intended. This is particularly true if that group of well-wishers include a number of people that you have never dealt with before. I can tell you from my own personal experience that many people will promise you money to do something, and then after you do it they'll have a million excuses. Oh, my car broke down, poor little old me. I guess *you* will have to do without that money that I had promised *you*, because *my* car broke down. Believe me, they'll make it sound like you're supposed to apologize to them for the bad luck that they have had. If the fund raising is connected with FreeBSD, could people who donate larger amounts get some form of acknowledgement on the FreeBSD site? This would give an incentive for vendors who sell products that rely or use FreeBSD to donate larger amounts. This has already been discussed in the thread. I'm sure that various things could be arranged for any vendor who really puts up some money to help fund Poul-Henning's work on the specific project he is proposing to do. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: polling for sio?
On Fri, Apr 09, 2004 at 02:01:56PM -0400, Louis A. Mamakos wrote: Those cards are just what they are - cheap. They have very small FIFOs and they don't use DMA. IRQ sharing makes them even worse than traditional ISA stuff. My advise for cost efficient and fast serials is getting USB ones. Even noname USB serials do much better then puc(4) based. E.g. the FT232BM (uftdi(4)) has 128 bytes send and 384 bytes receive buffer plus your USB controller does DMA. At best you would add a cheap OHCI card if your onboard USB is UHCI based as OHCI is less CPU intensive. I used to use 9600 bps serial links on LSI-11/23 systems 20 years ago to run SLIP over. This was with dumb DL-11 serial adapters on way slower CPUs and busses than we have today. The difference was a much lower interrupt latency. You'd think that running serial links 10 times faster on CPUs that are a few hundred times faster wouldn't be too hard. I'm not saying that interrupt latency is OK and that it's impossible to get things running with this kind of hardware, but it's very questionable that you have a fast CPU with fast IO bandwidth just to waste cycles for cheap hardware while you can easily get much more efficient hardware for your money. 16550 design is ancient - having them addressed via PCI doesn't change very much. You are also not running your Fastethernet with the same mechanisms as you did with your 10 times slower ISA NIC. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fundraising for FreeBSD development.
Simon L. Nielsen wrote: I cannot promise exposure on the main FreeBSD Project pages, that would be up to the webmasters (and to some extent the core team) to arrange and allow for such precense. We currently have list of donors both on http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/index.html#DONORS and on http://www.freebsd.org/donations/donors.html so I don't see a reason why donations to phk's project could not be somewhere on the main FreeBSD website. Surely PHK's appeal could be linked to in the news section reguardless of whether the final contributors are listed on FreeBSD.org or not? That's sure to increase the awareness of what PHK's trying to do. Andrew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
MFCs needed in src/sys/sys/cdefs.h
This is an extended version of my previous email to hackers@ which hasn't attracted any attention. This time I'm mailing the authors too. Two revisions need MFC in src/sys/sys/cdefs.h: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/cdefs.h.diff?r1=1.78r2=1.79 Silences gobs of warnings in just about any libtool-using software. Fix for CURRENT commited: (5 months, 1 week ago) by peter. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/cdefs.h.diff?r1=1.74r2=1.75 This one fixes __RCSID(), __RCSID_SOURCE(), etc in the same manner as __FBSDID(). The commit message even says it should be MFCed after one week, but that never happened. Commited (8 months, 2 weeks ago) by gad. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
/bin/sh bug? munges here-doc eof markers
Why does /bin/sh insert 0x81, or 129, or SYNBASE, before every non-word character in here-doc delimiters? It grows 'END-of-vietnamese/x-unikey/files/patch-src::unikey-gtk::Makefile.am' which is 69 characters, well below EOFMARKLEN (79) to 80 characters. Should I file a PR? [EMAIL PROTECTED] ~/tmp 1048:0 sh shar 21 - |head -1|hd -c 37 39 3a 20 88 45 4e 44 81 2d 6f 66 81 2d 76 69 |79: .END.-of.-vi| 000 7 9 : 210 E N D 201 - o f 201 - v i 0010 65 74 6e 61 6d 65 73 65 81 2f 78 81 2d 75 6e 69 |etnamese./x.-uni| 010 e t n a m e s e 201 / x 201 - u n i 0020 6b 65 79 81 2f 66 69 6c 65 73 81 2f 70 61 74 63 |key./files./patc| 020 k e y 201 / f i l e s 201 / p a t c 0030 68 81 2d 73 72 63 81 3a 81 3a 75 6e 69 6b 65 79 |h.-src.:.:unikey| 030 h 201 - s r c 201 : 201 : u n i k e y 0040 81 2d 67 74 6b 81 3a 81 3a 4d 61 6b 65 66 69 6c |.-gtk.:.:Makefil| 040 201 - g t k 201 : 201 : M a k e f i l 0050 65 2e 61 6d 0a|e.am.| 050 e . a m \n 055 -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MFCs needed in src/sys/sys/cdefs.h
At 10:50 PM +0200 4/9/04, Roman Neuhauser wrote: This is an extended version of my previous email to hackers@ which hasn't attracted any attention. This time I'm mailing the authors too. I must have missed the earlier message... Two revisions need MFC in src/sys/sys/cdefs.h: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/cdefs.h.diff?r1=1.78r2=1.79 Silences gobs of warnings in just about any libtool-using software. Fix for CURRENT commited: (5 months, 1 week ago) by peter. I have no opinion on this. It looks fine to me. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/cdefs.h.diff?r1=1.74r2=1.75 This one fixes __RCSID(), __RCSID_SOURCE(), etc in the same manner as __FBSDID(). The commit message even says it should be MFCed after one week, but that never happened. Commited (8 months, 2 weeks ago) by gad. When I went to MFC this, I found out that cdefs in -stable was different enough to cdefs in -current that this was not a simple MFC. That update modified lines added by earlier changes which had not been MFC'ed. After talking about it with BDE, we felt that it was more trouble than it was worth to sort out what should and should not be MFC'ed. Note, for instance, that the lines which are replaced by r1.75 do not even exist in cdefs.h for release 4.x. The update fixes the handling of the NO__RCSID, NO__RCSID_SOURCE, NO__SCCSID, and NO_COPYRIGHT options -- and 4.x does not have any of those NO__* options. In fact, it doesn't have the __SCCSID macro, never mind the NO__SCCSID option to nullify that macro... It would be easy enough to write a minimal update for 4.x that would add and then fix those options. But right now I am really over-committed and over-tired. I also do not see much urgency in MFC'ing a fix for bugs that do not exist in -stable... It would have been much nicer if you had gotten my attention about this a few weeks ago. We are now *in* the code-freeze for 4.x, so I'll have to see what re@ thinks about it. I could also pick up Peter's update, if he wanted me to. -- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute; Troy, NY; USA ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD and Debugging?
Hi, I've been writing an application for some time now, and I seem to have introduced some kind of bug that is smashing the stack or the heap *somewhere*. One of my variables (or more) are being changed, and the program relies on this being set to the last time data was read from a socket. It's getting reset to 0 for some odd, odd reason. But enough of my whining. My code, my problems. What isn't my problem, though, and is probably a lot of people's problem, is the lack of a *good* debugger for BSD. I know gdb is pretty good, and it does help me often, but I can't seem to find a debugger that will detect under/over reads/writes in the heap and/or stack (bounds checking). I had downloaded the bounds checking gcc, it compiled fine, but I get an error that doesn't allow it to run on FreeBSD 4.9 (w/ gcc-2.95.2) -- something about ulimit not being found. I checked Google, and of course, found nothing. I didn't bother enough to look any deeper than that. For Linux, I've seen valgrind (probably one of the best) as well as several others. In the commercial arena, Rational's PURIFY and Parasoft's INSURE++ work on every OS *but* BSD. Any particular reason for this? Are there any debuggers out there for BSD that will detect the heap/stack corruption!? Thanks in advance for you support, Brandon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
At 06:11 10/04/2004, Brandon Erhart wrote: Are there any debuggers out there for BSD that will detect the heap/stack corruption!? Real Men use printf(3). :-) Colin Percival ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
Brandon Erhart wrote: For Linux, I've seen valgrind (probably one of the best) as well as several others. In the commercial arena, Rational's PURIFY and Parasoft's INSURE++ work on every OS *but* BSD. Any particular reason for this? Are there any debuggers out there for BSD that will detect the heap/stack corruption!? Valgrind is available for FreeBSD. http://eirikn.kerneled.com/valgrind/ -- Lev Walkin [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
Thank you. You are my new god. I had checked out a version of valgrind for BSD (one of the patches) and it failed to compile. Everything seems to be working, except I get this warning at the beginning of the program: Warning: ignoring --pointercheck=yes, because i386_set_ldt failed (errno=45) Any ideas? Brandon At 11:17 PM 4/9/2004, you wrote: Brandon Erhart wrote: For Linux, I've seen valgrind (probably one of the best) as well as several others. In the commercial arena, Rational's PURIFY and Parasoft's INSURE++ work on every OS *but* BSD. Any particular reason for this? Are there any debuggers out there for BSD that will detect the heap/stack corruption!? Valgrind is available for FreeBSD. http://eirikn.kerneled.com/valgrind/ -- Lev Walkin [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
On Fri, Apr 09, 2004 at 11:11:49PM -0600, Brandon Erhart wrote: [...] Are there any debuggers out there for BSD that will detect the heap/stack corruption!? ElectricFence (devel/ElectricFence in the ports collection) detects most kinds of heap corruption, but not stack corruption. It will reliably abort the program on the exact instruction that first corrupts the heap (e.g. overruns a buffer), then you can use gdb on the core dump to analyze it further. After installing the port, run your program with ef.sh. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
