Re: Signal sensitivity problem with if_rum
Any idea if is there anything to change/tune ? There is not just bbp17 to tune there are probably others much more important registers. But as I already mentioned that code is completly missing. I was not talking about autotuning features, which are missing as you pointed. Was talking just about changing/tuning values of some registers to increase reception sensitivity. The people of linux, seem to have increased the sensitivity by modifing bbp17 and disabling autotuning. I tried with bbp17 and for the autotuning disabled, well, we already have it implemented :) (just joking) Anyway, giving that I didn't get an increase of sensitivity, I think we'll need the help of the developers. Well, this morning will try to increase sensitivity of those usb rum with a linux system, just to check what they say here : http://209.85.229.132/search?q=cache:H8W6R5Ds3mYJ:forum.aircrack-ng.org/index.php%3Ftopic%3D2235.0+bbp17+ralink+linux&cd=1&hl=ca&ct=clnk&gl=es&client=firefox-a Regards, Gus ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Interrupts + Polling mode (similar to Linux's NAPI)
--- On Sat, 5/2/09, Adrian Chadd wrote: > From: Adrian Chadd > Subject: Re: Interrupts + Polling mode (similar to Linux's NAPI) > To: barney_cord...@yahoo.com > Cc: "FreeBSD Net" > Date: Saturday, May 2, 2009, 2:32 AM > 2009/5/2 Barney Cordoba : > > > I think its unlikely that a commercial implementation > is going to > > be of much use generally, as with a mutex based OS > you're going to > > have to do heavy specialization to get the results > you want. For > > example a web server, transparent firewall and router > would required > > very different implementations to be properly > optimised. > > > > I'm going to regularly hear the open sorcerers > whining about > > contributing, but the fact is that the work I'm > doing has no place in > > a general purpose OS. Optimizing for a specific > commercial product is > > going to require all kinds of fudging and gimmickry. > > Sure, but you may find that your fudging and gimmickry > could be useful > as a reference platform for more generic improvements. > > So I do encourage you (and others!) with these sorts of > hackery to > release your stuff for others to use and abuse. Who knows, > they may > get improved and included into FreeBSD at a later stage. > > (FWIW, companies like Ironport do just this. :) > Companies might release bug fixes and such, but nobody is going to spend a lot of money to build a better mousetrap and then effectively give away the work to all of their competitors. BC Barney ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Regression: em driver in -CURRENT, "Invalid MAC address"
Hi, When I upgraded my 7-STABLE virtual machine under VirtualBox to 8-CURRENT, the em driver stopped working. VirtualBox supports three different flavours of emulated em devices, all of which result in the "Invalid MAC address" error and cannot be used any more. The error was previously reported for VMWare, but since VirtualBox is as different from VMWare as it can be, the problem is most likely in the driver. I can provide more information if needed, I'll be at DevSummit with the box. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Slow local TCP transfers on -CURRENT
Kevin Day wrote: I've been seeing this for a few months now on -CURRENT. TCP transfers to local IP addresses (but not 127.0.0.1) are incredibly slow. Transfer from localhost: # scp "r...@127.0.0.1:/boot/kernel/kernel" . kernel 100% 11MB 11.1MB/s 00:00 Appropriately fast. Transfer from an IP on a local interface: # scp "r...@216.14.96.4:/boot/kernel/kernel" . kernel 0% 16KB 13.0KB/s 14:37 ETA The routes seem normal: # route get 127.0.0.1 route to: localhost destination: localhost interface: lo0 flags: recvpipe sendpipe ssthresh rtt,msecmtuweightexpire 0 0 0 0 16384 1 0 # route -n get 216.14.96.4 route to: 216.14.96.4 destination: 216.14.96.0 mask: 255.255.255.128 interface: nfe0 flags: recvpipe sendpipe ssthresh rtt,msecmtuweightexpire 0 0 0 0 1500 1 0 nfe0: flags=8843 metric 0 mtu 1500 options=19b ether 00:30:48:c6:dd:9c inet 216.14.96.4 netmask 0xff80 broadcast 216.14.96.127 Takes 10-60 minutes to copy, stalling frequently during the transfer. It's not limited to just scp either, all TCP transfers seem to stall this way. I don't believe I'm doing anything unusual, has anyone seen anything like this? Known fallout from the ARPv2 work I believe. As a workaround until it gets fixed: route add -host (if-ip) -iface lo0 (note I haven't tested this myself) (see the Jan 2009 freebsd-net@ thread "Bacula: VERY SLOW on SAME host" for some details). Cheers, Lawrence ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Signal sensitivity problem with if_rum
On 5/2/09, Gustau Perez wrote: > >>> Any idea if is there anything to change/tune ? >>> >> >> There is not just bbp17 to tune there are probably others much more >> important >> registers. >> >> But as I already mentioned that code is completly missing. >> >> >I was not talking about autotuning features, which are missing as you > pointed. Was talking > just about changing/tuning values of some registers to increase > reception sensitivity. > > The people of linux, seem to have increased the sensitivity by > modifing bbp17 and disabling > autotuning. I tried with bbp17 and for the autotuning disabled, well, we > already have it > implemented :) (just joking) Anyway, giving that I didn't get an > increase of sensitivity, I think we'll > need the help of the developers. > > Well, this morning will try to increase sensitivity of those usb rum > with a linux system, just to check > what they say here : That information is misleading, I remmember reading somewhere that linux rt73 had similar problems like rum but it got fixed, and is not present in new kernels. I think that problem originated for linux from now obsolete drivers. On what linux version and what drivers version do you experience similar problems with signal sensitivity like with rum? -- Paul ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Regression: em driver in -CURRENT, "Invalid MAC address"
I'm willing to bet that its in fact the same problem that VMWare is having. Our method of getting the mac address changed, and the emulations seem to be unprepared for it. This was done for a real customer requirement to allow support of alternate mac addressing in firmware. What happens now is a warm reset of the hardware is done, followed by reading the RAR[0] register. In a real Intel NIC the mac address will be valid in that register, but in VMWare, and I'm willing to bet in VirtualBox as well, its 0. VMWare also has 3 choices of device (wow, amazing coincidence :), can you tell me when you pick e1000 what real adapter it claims to emulate? I am considering options for this problem. The one I lean toward right now is to make a "legacy" em driver, it will have support for ONLY pre-PCI Express hardware, it will be frozen as it were, the idea is that with no new work on it it will not suffer from any regression type failures. If I do this, there are some strategy issues, and its those I'm thinking about. In any case, I intend to have this problem resolved for 8's release. Stay tuned. Jack On Sat, May 2, 2009 at 5:25 AM, Ivan Voras wrote: > Hi, > > When I upgraded my 7-STABLE virtual machine under VirtualBox to 8-CURRENT, > the em driver stopped working. VirtualBox supports three different flavours > of emulated em devices, all of which result in the "Invalid MAC address" > error and cannot be used any more. > > The error was previously reported for VMWare, but since VirtualBox is as > different from VMWare as it can be, the problem is most likely in the > driver. > > I can provide more information if needed, I'll be at DevSummit with the > box. > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
tcp problem with freebsd 7.1?
Hi, With regarding to the following statement, is there any serious tcp problem with freebsd 7.1? "We recently found our new FreeBSD server (located in some foreign region) has poor network performance. After doing some tcpdump and iperf testing, we found that out-of-order TCP packets are not inserted into queue. This is an 100Mbps line, and TSO is disabled. " Very appreciate for any suggestion. Thanks ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
tcp problem with freebsd 7.1?
Hi, With regarding to the following statement, is there any serious tcp problem with freebsd 7.1? "We recently found our new FreeBSD server (located in some foreign region) has poor network performance. After doing some tcpdump and iperf testing, we found that out-of-order TCP packets are not inserted into queue. This is an 100Mbps line, and TSO is disabled. " Very appreciate for any suggestion. Thanks ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: tcp problem with freebsd 7.1?
We have had some issues with NIC drivers in the past.. what Nics are you running. Specifically some Nics need to have the CRC checks disabled. This also sounds like state is not being kept on the IP Filter if you are running one. Do you have more details? --Wes On May 2, 2009, at 9:28 AM, Sam Wun wrote: Hi, With regarding to the following statement, is there any serious tcp problem with freebsd 7.1? "We recently found our new FreeBSD server (located in some foreign region) has poor network performance. After doing some tcpdump and iperf testing, we found that out-of-order TCP packets are not inserted into queue. This is an 100Mbps line, and TSO is disabled. " Very appreciate for any suggestion. Thanks ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Freebsd failed to create routing prefix
Hello everyone, I need help. My box(Machine1) by default will perform IPv6 stateless autoconfiguration and I need to change this autoconfigured address to static manually without restarting. Here are the steps I follow but I sure I missed something cause I was unsuccessful of doing it. 1. I disabled sysctl knob to stop receiving rtadv # sysctl -w net.inet6.ip6.accept_rtadv=0 2. I then removed the autoconfigured ipv6 address from the interface # ifconfig em0 inet6 2001:db8:1234:abcd:20c:27ff:fe3d:63dd delete 3. I removed the default ipv6 route since I will replace with another route # route delete -inet6 default 4. I then added the autoconfigured ipv6 address back to the interface to make it static # ifconfig em0 inet6 2001:db8:1234:abcd:20c:27ff:fe3d:63dd prefixlen 64 up 5. I added the new default ipv6 route # route add -inet6 default 2001:db8:1234:abcd::1 At this point I pinged 2001:db8:1234:abcd:20c:27ff:fe3d:63dd from another IPv6 box (Machine2) with IPv6 address of the same prefix (2001:db8:1234:abcd:215:d3ff:fe4f:acaf) but with no success. But if I ping6 from Machine2 to my router 2001:db8:1234:abcd::1 I am successfull. I tried to check IPv6 route information from Machine1 thru netstat -rnf inet6 but have not found this entry: 2001:db8:1234:abcd::/64 link#1UC em0 I hope someone could shed light on how to put this route into my ipv6 routing table. Is this a bug in FreeBSD not to automatically add a routing prefix after changing from IPv6 stateless autoconfiguration to static IPv6 address ? Thanks, Romskie ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/134168: [ral] ral driver problem on RT2525 2.4GHz transceiver + RT2560 MAC/BBP wireless
Old Synopsis: ral driver problem on RT2525 2.4GHz transceiver + RT2560 MAC/BBP wireless New Synopsis: [ral] ral driver problem on RT2525 2.4GHz transceiver + RT2560 MAC/BBP wireless Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 2 21:41:43 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134168 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/134157: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression]
Old Synopsis: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable New Synopsis: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 2 21:53:37 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134157 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/133968: [dummynet] [panic] dummynet kernel panic
Old Synopsis: Dummynet kernel panic New Synopsis: [dummynet] [panic] dummynet kernel panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 2 21:56:12 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133968 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/133969: [dummynet] [panic] Fatal trap 12: page fault while in kernel mode with dummynet
Old Synopsis: Fatal trap 12: page fault while in kernel mode with dummynet New Synopsis: [dummynet] [panic] Fatal trap 12: page fault while in kernel mode with dummynet Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat May 2 21:56:48 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133969 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Freebsd failed to create routing prefix
Hello M.Laranjo The Kame stack for IPv6 should be working fine, whether you use stateless autoconfiguration or static configuration. Since you want to use static configuration, my suggestion would be to modify the /etc/rc.conf file so that your static configuration is loaded everytime at boot. That way, you don't have to suppress the autoconfigured address to reconfigure your static address afterwards. The lines you will need are : ipv6_enable="YES" ipv6_network_interface="em0" ipv6_ifconfig_em0="2001:db8:1234:abcd:20c:27ff:fe3d:63dd prefixlen 64" ipv6_defaultrouter="2001:db8:1234:abcd::1" This should work. Please try to ping6 your router to see if everything is working as it's supposed to. About your last question, I'm not 100% sure, but I don't think FreeBSD will autoconfigure a route if you just add a static ipv6 address on your interface... Unless you use a routing daemon like routed. Kind regards Aman Jassal Le Sam 2 mai 2009 21:59, Rommel Laranjo a écrit : > Hello everyone, > > > I need help. My box(Machine1) by default will perform IPv6 stateless > autoconfiguration and I need to change this autoconfigured address to > static manually without restarting. Here are the steps I follow but I sure > I missed something cause I was > unsuccessful of doing it. > > 1. I disabled sysctl knob to stop receiving rtadv > # sysctl -w net.inet6.ip6.accept_rtadv=0 > > > 2. I then removed the autoconfigured ipv6 address from the interface > # ifconfig em0 inet6 2001:db8:1234:abcd:20c:27ff:fe3d:63dd delete > > > 3. I removed the default ipv6 route since I will replace with another > route # route delete -inet6 default > > > 4. I then added the autoconfigured ipv6 address back to the interface to > make it static # ifconfig em0 inet6 2001:db8:1234:abcd:20c:27ff:fe3d:63dd > prefixlen 64 up > > 5. I added the new default ipv6 route > # route add -inet6 default 2001:db8:1234:abcd::1 > > > At this point I pinged 2001:db8:1234:abcd:20c:27ff:fe3d:63dd from another > IPv6 box (Machine2) with IPv6 address of the same prefix > (2001:db8:1234:abcd:215:d3ff:fe4f:acaf) but with no success. But if I > ping6 from Machine2 to my router 2001:db8:1234:abcd::1 I am successfull. > > I tried to check IPv6 route information from Machine1 thru netstat -rnf > inet6 but have not found this entry: > > 2001:db8:1234:abcd::/64 link#1UC > em0 > > I hope someone could shed light on how to put this route into my ipv6 > routing table. Is this a bug in FreeBSD not to automatically add a routing > prefix after changing from IPv6 stateless autoconfiguration to static IPv6 > address ? > > Thanks, > > > Romskie > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Regression: em driver in -CURRENT, "Invalid MAC address"
2009/5/2 Jack Vogel : > I'm willing to bet that its in fact the same problem that VMWare is having. > Our method of getting the mac address changed, and the emulations seem > to be unprepared for it. > > This was done for a real customer requirement to allow support of alternate > mac addressing in firmware. What happens now is a warm reset of the hardware > is done, followed by reading the RAR[0] register. In a real Intel NIC the > mac > address will be valid in that register, but in VMWare, and I'm willing to > bet in > VirtualBox as well, its 0. > > VMWare also has 3 choices of device (wow, amazing coincidence :), can > you tell me when you pick e1000 what real adapter it claims to emulate? Here's the information on all three: em0: port 0xc060-0xc067 mem 0xf082-0xf083 irq 16 at device 8.0 on pci0 em0: Invalid MAC address device_attach: em0 attach returned 5 em1: port 0xc068-0xc06f mem 0xf084-0xf085 irq 17 at device 9.0 on pci0 em1: Invalid MAC address device_attach: em1 attach returned 5 em2: port 0xc070-0xc077 mem 0xf086-0xf087 irq 18 at device 10.0 on pci0 em2: Invalid MAC address device_attach: em2 attach returned 5 e...@pci0:0:8:0: class=0x02 card=0x001e8086 chip=0x100e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82540EM Gigabit Ethernet Controller' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction e...@pci0:0:9:0: class=0x02 card=0x10048086 chip=0x10048086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82543GC Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction e...@pci0:0:10:0:class=0x02 card=0x075015ad chip=0x100f8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82545EM Gigabit Ethernet Controller (copper)' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D3 current D0 cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction > I am considering options for this problem. The one I lean toward right now > is to make a "legacy" em driver, it will have support for ONLY pre-PCI > Express > hardware, it will be frozen as it were, the idea is that with no new work on > it > it will not suffer from any regression type failures. If I do this, there > are some > strategy issues, and its those I'm thinking about. I think that would be a losing battle wrt future developments of both the driver and the VM environments (too fragile state; anyway, other OSes don't have the issue so why should we?). I don't really know how it works but couldn't you use the information talked about earlier (register is 0 after a warm reset) to detect the general class of the problem and if detected conditionally proceed with the old code / behaviour just for the initialization part? Another possible route is to make use of VM detection present in HEAD and just blindly use the old way if a VM environment is detected. I think this is only slightly less bad than forking the driver since new VM platforms are appearing all the time - is something like the middle option doable? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Freebsd failed to create routing prefix
Rommel Laranjo wrote in : rs> I hope someone could shed light on how to put this route into my ipv6 rs> routing table. rs> Is this a bug in FreeBSD not to automatically add a routing prefix rs> after changing from IPv6 stateless autoconfiguration to rs> static IPv6 address ? It looks odd because that link should be added automatically at 4 in your procedure regardless of whether you use the stateless autoconf. BTW, does your system have multiple NICs? -- | Hiroki SATO pgpDxd2C8bhPz.pgp Description: PGP signature
Re: kern/125181: [ndis] [patch] with wep enters kdb.enter.unknown, panics
On 7/13/08, ga...@freebsd.org wrote: > Old Synopsis: [ndis] with wep enters kdb.enter.unknown, panics > New Synopsis: [ndis] [patch] with wep enters kdb.enter.unknown, panics > > State-Changed-From-To: feedback->open > State-Changed-By: gavin > State-Changed-When: Sun Jul 13 17:06:03 UTC 2008 > State-Changed-Why: > Over to maintainers for evaluation > > > Responsible-Changed-From-To: gavin->freebsd-net > Responsible-Changed-By: gavin > Responsible-Changed-When: Sun Jul 13 17:06:03 UTC 2008 > Responsible-Changed-Why: > Submitter reports my patch fixes things for him > > http://www.freebsd.org/cgi/query-pr.cgi?pr=125181 > As of recent CURRENT(r191746), this issue have been fixed. -- Paul ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Check out my photos on Facebook
Hi Freebsd-net, I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. Thanks, Alex To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=841695471&k=32DYP2TXT5XM5CEIXFY6X3&r freebsd-net@freebsd.org was invited to join Facebook by Alex Santiago. If you do not wish to receive this type of email from Facebook in the future, please click on the link below to unsubscribe. http://www.facebook.com/o.php?k=cbecc8&u=1119946398&mid=66e0fbG42c1069eG0G8 Facebook's offices are located at 156 University Ave., Palo Alto, CA 94301. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
How to complie keepliaved from Port.
Hi, Is there anyone knows how to compile keepalived from the port? Its patch only available up to version 7.0. When I followed its instruction to patch 4 files, 1 or 2 of those have been *rej*, and when I ignored and continue to build it, kernel compilation caused error. Is there a new keepalived patch for freebsd 7.1 and 7.2? Thanks ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
