Re: [PATCH] caching daemon release and nsswitch patches
Hi, Doug! I'm not sure what guidelines were given to you when you started the project, but in reviewing your work the first thing I noticed was that you are not following the guidelines in the style(9) man page. You should read that page, and spend an afternoon reformatting your code to fit what is described there. The most common error you've made is not following the 80 column rule, which hopefully should be easily fixed. While one could argue with the specific items in that page, and quite possibly be right, the idea of having a style guideline is more to have a common format that we can all work towards than to have a perfect format that we can all agree on. By reformatting your code to fit this guideline you will greatly increase the chances that it will be welcomed into the tree with open arms. The other style area that you should look at is your man pages. If you look in /usr/share/examples/mdoc you will find the FreeBSD style guidelines for man pages. The line wrapping issue comes into play here as well. We generally don't go past column 60 in man pages, since that reduces CVS repo churn for corrections down the road. Also, any time you have a full stop (period) at the end of a sentence, you should start a new line. I think that you are also using some macros that I'm not familiar with, although I'm not an mdoc expert. Thank you very much for your suggestions - I'll reformat the code and man files. I've seemed to forget about style(9) in some places :( The other area that I'm interested in is how you plan to have cached interact with DNS lookups, /etc/hosts, named, etc. If there was a project plan posted somewhere on this already and I missed it, please accept my apologies, and send along a reference. If not, I'm very interested to hear what your plans are. There is some information in my project's description here: http://wikitest.freebsd.org/moin.cgi/NsswitchAndCachingTechnicalDetails The Integrating nsswitch and caching describes the way that I use to make cached work. It can actually interact with any nsswitch database. All we need is to supply the special structure (in patches it is usually called cache_info) with 3 functions pointers (*_id_func, *_marshal_func, *_unmarshal_func). These functions are used by nsdispatch during the caching of sccessful results. id_func identifies the key - the unique identifier, which will identify the data in the cache. And marshal_func/unmarshal_func pack/unpack data into/from the (char *)buffer. So almost all data, that go through nsdispatch calls, can be cached. And struct hostent and struct addrinfo are no exceptions to this rule. I already have the patch with *_id_func, *_marshal and *_unmarshal_func implemented for the hosts nsswitch database. I'll send it to the list along with the corrected version of the cached a bit later (in about 12 hours). P.S. the patched version of nsdispatch uses the functions that are implemented in nscache.c and nscachedcli.c files (they are present in the patch). With best regards, Michael ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
PUC driver addition Sealevel cPCI 7203 possible
Hi, Intro My company is currently using Linux as a platform for our own control software platform (all in c). We often have clashes between kernel and the rest in the sense of timings, priority handling etc. I feel Linux is not an OS but a kernel plus the rest which hampers us (too) often. My personal experience with FreeBSD is better, a nicely integrated platform being more complete and better documented. I am not a deep inside programmer, only an engineer that uses the packages provided, fixes minor application issues an goes in the field. I would like to convince my colleagues to consider FreeBSD. Good part is the software is rather easily ported, bad part is I am missing crucial support for a type of serial port card. Question Who can help me to add the correct entries - if possible- to src/sys/dev/puc/pucdata.c (as I understand from the sources) for this card: http://www.sealevel.com/product_detail.asp?product_id=497PCI%5FRS%2D232%5FRS%2D422%5FRS%2D485%5FIsolated%5FSerial%5FInterface%5F The sealevel model no. 7203 that utilizes 16C850 UART. Our systems use 4 of these boards on a cPCI bus. Thank you, Maarten ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PUC driver addition Sealevel cPCI 7203 possible
On Mon, Aug 29, 2005 at 12:13:53PM +0200, Maarten wrote: Hi, Intro My company is currently using Linux as a platform for our own control software platform (all in c). We often have clashes between kernel and the rest in the sense of timings, priority handling etc. I feel Linux is not an OS but a kernel plus the rest which hampers us (too) often. My personal experience with FreeBSD is better, a nicely integrated platform being more complete and better documented. I am not a deep inside programmer, only an engineer that uses the packages provided, fixes minor application issues an goes in the field. I would like to convince my colleagues to consider FreeBSD. Good part is the software is rather easily ported, bad part is I am missing crucial support for a type of serial port card. Question Who can help me to add the correct entries - if possible- to src/sys/dev/puc/pucdata.c (as I understand from the sources) for this card: http://www.sealevel.com/product_detail.asp?product_id=497PCI%5FRS%2D232%5FRS%2D422%5FRS%2D485%5FIsolated%5FSerial%5FInterface%5F The sealevel model no. 7203 that utilizes 16C850 UART. Our systems use 4 of these boards on a cPCI bus. At best you have vendor documentation on chip mappings, but usually one can guess the UART layout within the PCI mappings within a few trys once you know the mappings that a given card requests on PCI. Do a boot -v on a FreeBSD system with such a card plugged in to get the required PCI values. Try it with and without puc compiled in - maybe there is already support for that card. Once all chips are probed correctly you should tryout the xtals. Many cards use raised frequencies over PC traditional once, some cards even have different frequencies on their ports. Considered the documented 460.8k rates I would asume COM_FREQ * 4. Proper identification of such cards is sometimes troublesome. In many cases different cards identify themself identic and the kernel won't know the correct configuration to use. It is advised not to mix different puc cards to avoid such situations. Fortunately the 16C850 have large FiFos - with traditional 16C550 FiFo sizes you easily get into troubles even with moderate speeds, especially if your interrupts are shared with non-sio devices and you can't use PUC_FASTINTR. Nevertheless a configuration with PUC_FASTINTR is still prefered. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
ntpd and cmos clock update
I think I saw more than once speculations that FreeBSD updates CMOS clock when time is set, so CMOS clock value should always be very close to internal OS timer. But I always took it with a grain of salt because every time I reboot after long uptime period I see messages from ntpd about adjusting clock by many seconds and such discrepancy should not occur, of course, during couple of minutes that reboot takes. Recently this question (re-)surfaced in Russian language BSD newsgroup and I thought that a wider community might be interested. It seems that CMOS clock is updated using resettodr(9) function. There seem to be only a few occasions when this function is called: 1. clock_settime(ClOCK_REALTIME) // through kern_time.c:settime() 2. settimeofday() // through kern_time.c:settime() 3. machdep.adjkerntz sysctl is set I believe that ntpd calls settime-family functions only if time offset is larger than 128ms (or maybe I am thinking about ntpdate), but normally it uses ntp_adjtime() to adjust time keeping. Obviosuly, a system running ntpd with good enough hardware clock and good enough connection to good enough ntp server(s) would use the latter method all of the time after some initial stabilization period. But it seems that time changes are never propagated to CMOS in this case, thus leading to behavior mentioned in the beginning. This is not a big problem, of course, but quite an annoyance (sometimes). I wonder what could be the best solution to this issue. One idea is to always update CMOS from adjkerntz(8) upon shutdown/reboot, but this would not help if system crashes, but adjkerntz could also do it periodically. Any ideas ? Is it worth concern at all ? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
interrupt handlers - FreeBSD 4.9
1) What is the purpose of the two interrupt handler arrays ihandler[]
and intr_handlers[]?
What I saw on my system:
(kgdb) print intr_handler
$8 = {0x302b2d04 clkintr, 0x302b9bd4 atkbd_isa_intr,
0x302b6708 isa_strayintr, 0x302be648 siointr, 0x302be648 siointr,
0x302b6708 isa_strayintr, 0x302b53e0 fdc_intr, 0x30268128 dc_intr,
0x302b2fa0 rtcintr, 0x302b6708 isa_strayintr,
0x302b6708 isa_strayintr, 0x30268128 dc_intr,
0x302b6708 isa_strayintr, 0x302b6708 isa_strayintr,
0x3017606c ata_intr, 0x3017606c ata_intr}
(kgdb) p/a ihandlers
$11 = 0x302a522e Xresume0
(kgdb) p/a *ihandlers
$12 = 0x1ec05ff
2) Does cpl contain the mask to block hardware and software interrupts
or just for the software interrupts?
--
Thanks
Bharath
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd and cmos clock update
On 8/28/05, Andriy Gapon [EMAIL PROTECTED] wrote: I think I saw more than once speculations that FreeBSD updates CMOS clock when time is set, so CMOS clock value should always be very close to internal OS timer. But I always took it with a grain of salt because every time I reboot after long uptime period I see messages from ntpd about adjusting clock by many seconds and such discrepancy should not occur, of course, during couple of minutes that reboot takes. ... That's why I always thought that ntpd did not work in FreeBSD 5.x! -- Dmitry Mityugov, St. Petersburg, Russia I ignore all messages with confidentiality statements We live less by imagination than despite it - Rockwell Kent, N by E ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bge driver internal routing issues?
On Sun, Aug 28, 2005 at 09:06:47PM +0100, Steven Hartland wrote: Having a really odd problem here where udp queries to servers running on machines with bge cards dont respond via ip address that are being bound on: Can you run tcpdump -s 0 -vvv port 1234 on the client (replace port 1234 with the port number for the service). See if tcpdump shows a reply packet, and if it does see if the checksum is reported OK. It could be that the checksum offloading on the bge card is busted. (You could also check netstat -s on the client to see if it shows many bad checksums in the UDP section.) David. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Feature requests / inquiries.
Dear Sirs / Fellow Freebsd Freaks, I've been using FreeBSD for a while now as a routing/firewalling platform, but recent developments in our network infrastructure confront me with some lack of features in the IPstack. In a nutshell, i'm looking for support for (in order of importance to me) : (r)STP, ECMP, and LACP. For STP, i have found a patch that contained a port from netbsd code of if_bridge ; but i'm way too insecure about running this on a production system. For ECMP, the only thing i found out was that there used to be a patchset that did something like it, but went defunct after 4.8. LACP: no idea at all, sorry :) As these are features we'll be using some time soon now, i can say we _need_ them. I have even seriously considered moving to NetBSD; the lack of NIC polling support for the intel chipsets i'm using is holding me back at the moment. I do not want to move over to linux, for various reasons. So I figured perhaps some of the freebsd community is also interested in these features, and I might as well sponsor (part of?) its development. Are there any persons interested in developing these features, or do they already exist and am I just plain ignorant (forgive me if that is the case). Please note that i'm not interested in the netgraph approach, as that's (imho) just a hack around it, and it's not functioning with for example gnu/zebra et all. I am looking for short- and long-term solutions, anything that's developed trough sponsoring i'd be happy to contribute to the main tree. As this would be the first time we actually ask for a specific feature in any OSS software, I could be way off the scale with the figures i had in mind. This would be about 200 to 400 euro per feature, the more important ones like STP and ECMP are totally open to discussion. Any takers? Any enlightenment? Thanks for helping out in advance ;) Met vriendelijke groet / With kind regards, Bart Van Kerckhove [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: interrupt handlers - FreeBSD 4.9
On Monday 29 August 2005 08:11 am, Bharath Bhushan wrote:
1) What is the purpose of the two interrupt handler arrays ihandler[]
and intr_handlers[]?
Not sure. It may be that ihandler is used for INTR_FAST interrupts.
What I saw on my system:
(kgdb) print intr_handler
$8 = {0x302b2d04 clkintr, 0x302b9bd4 atkbd_isa_intr,
0x302b6708 isa_strayintr, 0x302be648 siointr, 0x302be648 siointr,
0x302b6708 isa_strayintr, 0x302b53e0 fdc_intr, 0x30268128 dc_intr,
0x302b2fa0 rtcintr, 0x302b6708 isa_strayintr,
0x302b6708 isa_strayintr, 0x30268128 dc_intr,
0x302b6708 isa_strayintr, 0x302b6708 isa_strayintr,
0x3017606c ata_intr, 0x3017606c ata_intr}
(kgdb) p/a ihandlers
$11 = 0x302a522e Xresume0
(kgdb) p/a *ihandlers
$12 = 0x1ec05ff
2) Does cpl contain the mask to block hardware and software interrupts
or just for the software interrupts?
Both. SWI is the upper 8 bits, lower 24 are for hardware. (24 are used with
APIC_IO, 16 with the 8259A pics).
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve = http://www.FreeBSD.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Syscall/Sysret state on i386 arch
On Sunday 28 August 2005 10:32 am, alexander wrote: The AMD64 arch is using the syscall/sysret opcodes instead of int80h to perform a syscall (/usr/src/lib/libc/amd64/SYS.h). I just checked the output my of dmesg and it says: CPU: AMD Duron(tm) Processor (1311.69-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x671 Stepping = 1 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV ,\ PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc0400800SYSCALL,MMX+,3DNow+,3DNow I got a hold of the AMD document number 21086.pdf. It describes both opcodes pretty well, but doesn't tell which CPUs support the new opcodes. But since the first revision of that document is dated Sept 1997 quite a lot of i386 CPU's should support the opcodes. The NASM manual only states [P6,AMD] as the required CPU to perform those opcodes. I found some patches for Linux that replace the int80h syscall calling convention with syscall/sysret on i386 and the results look pretty convincing: (INT $0x80 based getpid(), got pid 497) latency:282 cycles (SYSENTER based getpid(), got pid 497) latency:138 cycles on a 266 MHz PII this is 0.51 usecs for a getpid(). (was 1.06 usecs) Quoted from: http://www.ussg.iu.edu/hypermail/linux/kernel/9806.1/0878.html Does anybody know more about this? Is it even possible to replace the current syscall implementation that easily or would that require elaborate changes to all the syscalls (libc), etc. And which CPU's support these new opcodes? Doesn anybody know if the Linux patches actually got comitted to the official kernel? Support for syscall/sysret is determined by a cpuid flag. I do believe someone has worked on either syscall/sysret or sysenter/sysexit support in a p4 branch. You can try asking jeff@ about it. I think it was sysenter/sysexit and it didn't really improve things much. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Syscall/Sysret state on i386 arch
John Baldwin wrote: On Sunday 28 August 2005 10:32 am, alexander wrote: The AMD64 arch is using the syscall/sysret opcodes instead of int80h to perform a syscall (/usr/src/lib/libc/amd64/SYS.h). I just checked the output my of dmesg and it says: CPU: AMD Duron(tm) Processor (1311.69-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x671 Stepping = 1 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV ,\ PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc0400800SYSCALL,MMX+,3DNow+,3DNow I got a hold of the AMD document number 21086.pdf. It describes both opcodes pretty well, but doesn't tell which CPUs support the new opcodes. But since the first revision of that document is dated Sept 1997 quite a lot of i386 CPU's should support the opcodes. The NASM manual only states [P6,AMD] as the required CPU to perform those opcodes. I found some patches for Linux that replace the int80h syscall calling convention with syscall/sysret on i386 and the results look pretty convincing: (INT $0x80 based getpid(), got pid 497) latency:282 cycles (SYSENTER based getpid(), got pid 497) latency:138 cycles on a 266 MHz PII this is 0.51 usecs for a getpid(). (was 1.06 usecs) Quoted from: http://www.ussg.iu.edu/hypermail/linux/kernel/9806.1/0878.html Does anybody know more about this? Is it even possible to replace the current syscall implementation that easily or would that require elaborate changes to all the syscalls (libc), etc. And which CPU's support these new opcodes? Doesn anybody know if the Linux patches actually got comitted to the official kernel? Support for syscall/sysret is determined by a cpuid flag. I do believe someone has worked on either syscall/sysret or sysenter/sysexit support in a p4 branch. You can try asking jeff@ about it. I think it was sysenter/sysexit and it didn't really improve things much. Actually, the results were fairly inconclusive because it was also somewhat unstable under real loads. The work is in Perforce under //depot/user/jeff/sysenter/... I've worked on this branch also, but not in a few months. I can make patches if anyone is interested. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] caching daemon release and nsswitch patches
In the last episode (Aug 29), Michael Bushkov said: There is some information in my project's description here: http://wikitest.freebsd.org/moin.cgi/NsswitchAndCachingTechnicalDetails One question that comes to mind: It looks like the end-user application is still responsible for performing nss lookups. How do you ensure that one user can't poison the cache and cause problems for other users? Could cached do all nss operations itself (making it more like nscd in other OSes)? -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Feature requests / inquiries.
On Mon, Aug 29, 2005 at 05:56:25PM +0200, Bart Van Kerckhove wrote: Dear Sirs / Fellow Freebsd Freaks, I've been using FreeBSD for a while now as a routing/firewalling platform, but recent developments in our network infrastructure confront me with some lack of features in the IPstack. In a nutshell, i'm looking for support for (in order of importance to me) : (r)STP, ECMP, and LACP. For STP, i have found a patch that contained a port from netbsd code of if_bridge ; but i'm way too insecure about running this on a production system. For ECMP, the only thing i found out was that there used to be a patchset that did something like it, but went defunct after 4.8. LACP: no idea at all, sorry :) As these are features we'll be using some time soon now, i can say we _need_ them. I have even seriously considered moving to NetBSD; the lack of NIC polling support for the intel chipsets i'm using is holding me back at the moment. I do not want to move over to linux, for various reasons. So I figured perhaps some of the freebsd community is also interested in these features, and I might as well sponsor (part of?) its development. Are there any persons interested in developing these features, or do they already exist and am I just plain ignorant (forgive me if that is the case). Please note that i'm not interested in the netgraph approach, as that's (imho) just a hack around it, and it's not functioning with for example gnu/zebra et all. I am looking for short- and long-term solutions, anything that's developed trough sponsoring i'd be happy to contribute to the main tree. As this would be the first time we actually ask for a specific feature in any OSS software, I could be way off the scale with the figures i had in mind. This would be about 200 to 400 euro per feature, the more important ones like STP and ECMP are totally open to discussion. Any takers? Any enlightenment? Thanks for helping out in advance ;) if_bridge has been imported into FreeBSD 6.0 and I believe will be merged to 5.x before 5.5. I can't speak for ECMP. LACP is supported by ng_fec. The fact that you don't like it is a seperate issue. FWIW, ng_fec only uses netgraph for configuration. It's not really a netgraph node. I'd personally like to see OpenBSD's if_trunk imported and LACP added, but I certainly don't have time. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpJYGgQDqtHb.pgp Description: PGP signature
Re: Feature requests / inquiries.
On Monday 29 August 2005 19:50, Brooks Davis wrote: On Mon, Aug 29, 2005 at 05:56:25PM +0200, Bart Van Kerckhove wrote: Dear Sirs / Fellow Freebsd Freaks, I've been using FreeBSD for a while now as a routing/firewalling platform, but recent developments in our network infrastructure confront me with some lack of features in the IPstack. In a nutshell, i'm looking for support for (in order of importance to me) : (r)STP, ECMP, and LACP. For STP, i have found a patch that contained a port from netbsd code of if_bridge ; but i'm way too insecure about running this on a production system. For ECMP, the only thing i found out was that there used to be a patchset that did something like it, but went defunct after 4.8. LACP: no idea at all, sorry :) As these are features we'll be using some time soon now, i can say we _need_ them. I have even seriously considered moving to NetBSD; the lack of NIC polling support for the intel chipsets i'm using is holding me back at the moment. I do not want to move over to linux, for various reasons. So I figured perhaps some of the freebsd community is also interested in these features, and I might as well sponsor (part of?) its development. Are there any persons interested in developing these features, or do they already exist and am I just plain ignorant (forgive me if that is the case). Please note that i'm not interested in the netgraph approach, as that's (imho) just a hack around it, and it's not functioning with for example gnu/zebra et all. I am looking for short- and long-term solutions, anything that's developed trough sponsoring i'd be happy to contribute to the main tree. As this would be the first time we actually ask for a specific feature in any OSS software, I could be way off the scale with the figures i had in mind. This would be about 200 to 400 euro per feature, the more important ones like STP and ECMP are totally open to discussion. Any takers? Any enlightenment? Thanks for helping out in advance ;) if_bridge has been imported into FreeBSD 6.0 and I believe will be merged to 5.x before 5.5. A candidate MFC patchset is at: http://people.freebsd.org/~thompsa/if_bridge-5stable.diff and is believed to be production quality (judging from the reports for RELENG_6 so far). There might be minor problems and/or yet undiscovered problems, but only testing gets it there. Andrew is certainly thankful for any feedback! I can't speak for ECMP. LACP is supported by ng_fec. The fact that you don't like it is a seperate issue. FWIW, ng_fec only uses netgraph for configuration. It's not really a netgraph node. I'd personally like to see OpenBSD's if_trunk imported and LACP added, but I certainly don't have time. It's certainly a good idea to look at if_trunk. I don't have hardware to build a testbed, but I belive there are people out there who do and also have the skills to make it happen. The main problem is: Whoever does this must have (physical) access to a reasonable testbed and free time while there (i.e. agreement with employer etc) -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpHxrJu18K69.pgp Description: PGP signature
Re: Syscall/Sysret state on i386 arch
On Mon Aug 29 05, Scott Long wrote: Actually, the results were fairly inconclusive because it was also somewhat unstable under real loads. The work is in Perforce under //depot/user/jeff/sysenter/... I've worked on this branch also, but not in a few months. I can make patches if anyone is interested. Scott That would be awsome. I'd defenately check it out, because I'm really interested to see how syscall/sysret compares to the current way of doing syscalls. Maybe somebody can comment on the speed increase that was gained by replacing int80h in the AMD64 branch. I just had a look at lib/libc/amd64/SYS.h and it seems they decided to use syscall/sysret instead of int80h about 2 years ago: Revision 1.25 (Wed Apr 30 18:06:14 2003 UTC (2 years, 4 months ago) by peter) Cheers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Feature requests / inquiries.
On Mon, Aug 29, 2005 at 08:09:43PM +0200, Max Laier wrote: On Monday 29 August 2005 19:50, Brooks Davis wrote: On Mon, Aug 29, 2005 at 05:56:25PM +0200, Bart Van Kerckhove wrote: Dear Sirs / Fellow Freebsd Freaks, I've been using FreeBSD for a while now as a routing/firewalling platform, but recent developments in our network infrastructure confront me with some lack of features in the IPstack. In a nutshell, i'm looking for support for (in order of importance to me) : (r)STP, ECMP, and LACP. For STP, i have found a patch that contained a port from netbsd code of if_bridge ; but i'm way too insecure about running this on a production system. For ECMP, the only thing i found out was that there used to be a patchset that did something like it, but went defunct after 4.8. LACP: no idea at all, sorry :) As these are features we'll be using some time soon now, i can say we _need_ them. I have even seriously considered moving to NetBSD; the lack of NIC polling support for the intel chipsets i'm using is holding me back at the moment. I do not want to move over to linux, for various reasons. So I figured perhaps some of the freebsd community is also interested in these features, and I might as well sponsor (part of?) its development. Are there any persons interested in developing these features, or do they already exist and am I just plain ignorant (forgive me if that is the case). Please note that i'm not interested in the netgraph approach, as that's (imho) just a hack around it, and it's not functioning with for example gnu/zebra et all. I am looking for short- and long-term solutions, anything that's developed trough sponsoring i'd be happy to contribute to the main tree. As this would be the first time we actually ask for a specific feature in any OSS software, I could be way off the scale with the figures i had in mind. This would be about 200 to 400 euro per feature, the more important ones like STP and ECMP are totally open to discussion. Any takers? Any enlightenment? Thanks for helping out in advance ;) if_bridge has been imported into FreeBSD 6.0 and I believe will be merged to 5.x before 5.5. A candidate MFC patchset is at: http://people.freebsd.org/~thompsa/if_bridge-5stable.diff and is believed to be production quality (judging from the reports for RELENG_6 so far). There might be minor problems and/or yet undiscovered problems, but only testing gets it there. Andrew is certainly thankful for any feedback! I can't speak for ECMP. LACP is supported by ng_fec. The fact that you don't like it is a seperate issue. FWIW, ng_fec only uses netgraph for configuration. It's not really a netgraph node. I'd personally like to see OpenBSD's if_trunk imported and LACP added, but I certainly don't have time. It's certainly a good idea to look at if_trunk. I don't have hardware to build a testbed, but I belive there are people out there who do and also have the skills to make it happen. The main problem is: Whoever does this must have (physical) access to a reasonable testbed and free time while there (i.e. agreement with employer etc) I've got the equipment access, but lack the time. Untangling the mess in the VLAN and EtherChannel support has been on my like for a couple years now, but I have know idea when or if I'll get to it. FWIW, a Catalyst 2950 series switch will do EtherChannel and they appear to be available on e-bay for under $500 if someone wants to work on this. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgpHHTTvyzylb.pgp Description: PGP signature
Atheros driver and radiotap reliability
Hi guys, I'm trying to get an accurate measurement of signal strength (preferably in dBm) on a per-packet basis between two atheros cards that I have. I had some correspondence with the ethereal developers and David Young and apparently there is a bug in how ethereal handles the radiotap header. David told me that tcpdump will correctly report whatever the device driver tells it is the correct signal signal strength, but not to trust it until the devices have been calibrated. How does the ath driver report the signal strength in the radiotap header? From tcpdump, it's giving me this value: /* taken from /sys/net80211/ieee80211_radiotap.h */ * IEEE80211_RADIOTAP_DB_ANTSIGNAL u_int8_tdecibel (dB) * * RF signal power at the antenna, decibel difference from an * arbitrary, fixed reference. ... In this same file, there is a u_int8_t ANTSIGNAL reported in dBm. It appears as though everything is driver (and device, probably) dependent, so I'd like to know how the driver computes this value. As a side question, does anyone have an easier way to reliably measure per-packet signal strength? The area has a decent amount of traffic and I have to be able to analyze the packets themselves, so a plain hardware solution will not do. Thanks, Sam ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bge driver internal routing issues?
Thanks for the that, we've just packed down the machines to move them I will endeavour to test this as soon as I have access to them again. However I think I did try disabling checksum off loading but not a 100% sure so will need to check. Steve - Original Message - From: David Malone [EMAIL PROTECTED] On Sun, Aug 28, 2005 at 09:06:47PM +0100, Steven Hartland wrote: Having a really odd problem here where udp queries to servers running on machines with bge cards dont respond via ip address that are being bound on: Can you run tcpdump -s 0 -vvv port 1234 on the client (replace port 1234 with the port number for the service). See if tcpdump shows a reply packet, and if it does see if the checksum is reported OK. It could be that the checksum offloading on the bge card is busted. (You could also check netstat -s on the client to see if it shows many bad checksums in the UDP section.) This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ntpd and cmos clock update
In message: [EMAIL PROTECTED] Dmitry Mityugov [EMAIL PROTECTED] writes: : That's why I always thought that ntpd did not work in FreeBSD 5.x! ntpd works perfectly on FreebSD 5.x Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atheros driver and radiotap reliability
Sam Pierson wrote: Hi guys, I'm trying to get an accurate measurement of signal strength (preferably in dBm) on a per-packet basis between two atheros cards that I have. I had some correspondence with the ethereal developers and David Young and apparently there is a bug in how ethereal handles the radiotap header. News to me; the last time I checked it looked correct. David told me that tcpdump will correctly report whatever the device driver tells it is the correct signal signal strength, but not to trust it until the devices have been calibrated. How does the ath driver report the signal strength in the radiotap header? From tcpdump, it's giving me this value: /* taken from /sys/net80211/ieee80211_radiotap.h */ * IEEE80211_RADIOTAP_DB_ANTSIGNAL u_int8_tdecibel (dB) * * RF signal power at the antenna, decibel difference from an * arbitrary, fixed reference. ... In this same file, there is a u_int8_t ANTSIGNAL reported in dBm. It appears as though everything is driver (and device, probably) dependent, so I'd like to know how the driver computes this value. The radiotap header includes the rssi returned by the hardware for rx'd frames. sc-sc_rx_th.wr_antsignal = ds-ds_rxstat.rs_rssi; Nothing is recorded for tx frames. You can typically treat it as being in .5dBm units relative to the current noise floor. Note however that there is currently no way to calibrate these values to physical units; doing that is not a simple matter. As a side question, does anyone have an easier way to reliably measure per-packet signal strength? The area has a decent amount of traffic and I have to be able to analyze the packets themselves, so a plain hardware solution will not do. Thanks, rssi is provided and is accurate. If you want the rssi of the ack on xmit you need to collect that yourself from the tx descriptor when it's reaped. The sample tx rate control algorithm uses it (for example). Sam ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Problems with mpeg video
I asked this question on -questions, and got no answers (or at least none that I saw). I recently upgrade from a 1gig tunderbird to a 3gig P4 system, both running 5-STABLE from post 5.4-RELASE. The system and all ports were rebuilt with make.conf having: CPUTYPE=p3 CFLAGS= -O -pipe COPTFLAGS= -O -pipe On the new system, videos don't display the video stream - just a black box with red dots on it. This happens with both plaympeg and xine. I'm looking for suggestions on where to start debugging this issue. Thanks, mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
