Re: a very strange netstat output and problem when using transparent proxy
2006/11/7, Marat N.Afanasyev <[EMAIL PROTECTED]>: Oliver Fromme wrote: > Marat N.Afanasyev wrote: > > bge0: flags=8843 mtu 1500 > > Ok, I also have a machine with bge(4) NIC within reach. > I've had a look at it for similar symptoms (see below). > > > bge0 1500 00:50:45:5f:4f:78 2341018 799 3062828 > > 0 0 > > 799 is not good, but I wouldn't call it "huge amount of > ierrs". Is that a typical number, or was that output > taken before the problem (network freeze) appears? more typical is the following: % netstat -I bge0 -w 60 input (bge0) output packets errs bytespackets errs bytes colls 151993 241 111011660 172436 0 120848541 0 169867 388 118858096 192997 0 135783627 0 130524 407 91213775 145884 0 110857756 0 327168 1637 214730921 397193 0 275486626 0 385627 1027 254274520 471177 0 333456526 0 300184 720 198432049 367100 0 271325679 0 261095 5525 166910652 324112 0 251708900 0 278257 11998 176453071 349975 0 268865328 0 314383 8617 203347024 393589 0 301819857 0 195408 11647 129989509 246718 0 195720356 0 7163 237876087244 13165 07694485 0 2485 247861743165 6571 04015170 0 2202 261751117627 6225 03992217 0 and oops. none of two interfaces can any more process any incoming packet. ping drops increase to 99% > > > % uptime > > 7:34PM up 40 mins, 3 users, load averages: 0.14, 0.16, 0.08 > > Ok, 799 ierrs after 40 minuted uptime is definitely not > good. :-) > > > Real IP address. I've already switched forward off and make squid listen > > on 80 instead. Problem persists. > > OK, so it's a NIC problem, not IPFW-related. > > Here's output from my machine with bge(4) NIC: > > Name Mtu Network Address Ipkts IerrsOpkts Oerrs Coll > bge0 1500 00:16:35:... 780859535 3451475 0 0 > > Uptime is 8 days, the machine is only moderately loaded, > but gets quite some amount of NFS traffic (as a client). > OS is FreeBSD 6.2-PRELELEASE as of October 19th. as I said before, this problem persists on all my machines with 5704. > Whie 35 ierrs in 8 days isn't much, I think it still > indicates a problem somewhere. It should really be 0. > (I haven't experienced any freezes or other problems, > though.) > > Maybe you should ask on the -stable mailing list for > others with bge(4) NICs to check. It looks like a bug > in the driver. > > Oh by the way, do you have polling enabled? Try to > switch in on (if disabled) or off (if enabled) and check > whether it improves the situation for you. > > Best regards >Oliver > polling cannot be "safely" turned on smp, without eating a lot of cpu to interrupt processing. So, I run away from polling. -- SY, Marat ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" Maybe bge(4) has some problems with it. At least I have found that on my laptop and servers, the bge_tick() is time-consuming sometimes, and may result lost_polls increasing abnormally. So I won't enable device polling before the problem is addressed and fixed. To your problem, I'm not sure whether fwd rule was used properly. Perhaps divert may help? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
New wpi driver
Hi all, I'm pleased to tell you i got the latest wpi driver from Damien Bergamini to work properly on a latest -stable on an Acer laptop. Some history: I didn't do anything special, only report some problems on the [EMAIL PROTECTED] about this new driver on the recently 4.0 release and Damien was kind enough to respond me, the problem were related to the switch on my laptop used to turn on/off the receiver being an ACPI-only switch, this cause the driver to not work properly due to openbsd acpi issues on the laptop. Then Damien ask if i would like to have the FreeBSD version of the driver since i told him the switch work properly on FreeBSD, this all end up me having the driver working smoothly on FreeBSD. The driver as provided by Damien compiled without any issues on my stable, no need to put it under any special directory or what else. Obviously the driver is BSD licensed and obviously is an unsupported version of the driver so not complain to the author if this fail for you. For make this all clear i quote word from the author: --- No problem. It's BSD-licensed, you can redistribute it freely. I just don't want to hear complaints from users if it doesn't work. I don't provide any "support" for the FreeBSD version of wpi(4). --- The driver is available here: http://www.datacode.it/wpi-freebsd/wpi-freebsd.tgz If anyone from FreeBSD team or else is willing to put it on a host with more bandwidth it's more then welcome. Here is the relevant part from the dmesg and ifconfig. wpi0: mem 0xd210-0xd2100fff irq 19 at device 0.0 on pci5 channel 1 pwr1 0x007d pwr2 0x007c channel 2 pwr1 0x007b pwr2 0x007e channel 3 pwr1 0x009c pwr2 0x009d channel 4 pwr1 0x009e pwr2 0x009c channel 5 pwr1 0x pwr2 0x channel 6 pwr1 0x0075 pwr2 0x0076 channel 7 pwr1 0x0075 pwr2 0x0074 channel 8 pwr1 0x0077 pwr2 0x0076 channel 9 pwr1 0x0075 pwr2 0x0077 channel 10 pwr1 0x pwr2 0x channel 11 pwr1 0x0001 pwr2 0x0001 channel 12 pwr1 0x0001 pwr2 0x0001 channel 13 pwr1 0x0001 pwr2 0x0001 channel 14 pwr1 0x0001 pwr2 0x0001 wpi0: Ethernet address: 00:13:02:18:e5:b2 wpi0: flags=8802 mtu 1500 ether 00:13:02:18:e5:b2 media: IEEE 802.11 Wireless Ethernet autoselect status: no carrier ssid "" channel 1 authmode OPEN privacy OFF txpowmax 100 bmiss 7 protmode CTS Regards -- Massimo.run(); ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] tun(4) and tap(4) if_clone support.
Landon Fuller wrote: Nick Barkas ([EMAIL PROTECTED]) and I have added interface cloning support to the tun(4) and tap(4) drivers. We maintained backwards-compatible support for devfs cloning, which is now disabled by default -- it can be re-enabled via a sysctl. Interfaces that are created via devfs cloning may still be removed via ifconfig destroy. The latest patch is available here http://www.opendarwin.org/~landonf/code/patch-tuntap_ifclone I've submitted kern/105228 with the patch, and I'd be most appreciative of comments/suggestions. Interesting stuff. If it eliminates a race on creation, that has to be a good thing; I may have run into this race in the past month or two. It would however change tap/tun behaviour in that currently I have a few scripts which use dd(1) to force the device node to be created. This is undocumented behaviour specific to its devfs implementation which perhaps I shouldn't be relying upon, before I go on to create a bridge from several tap instances (which are then hooked up to QEMU virtual machines). Good work! BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Posting restrictions on this mailing list (for spam control)?
MQ wrote: [snip] > The mailing list denied all the mail from my previous mail box provided by > Netease(NASDAQ: NTES) from China mainland, even I subscribed to -net, and > asked me to wait the moderator's approval. But after I changed my > mailbox to > gmail, the filter never returned such message. I don't know why I can't > post > to -net even I subscribed to it. Maybe a misconfiguration? No. At least, not misconfiguration at FreeBSD.org side. I have discussed the situation with David (the postmaster@) and this seems to be caused by misconfiguration and wrong implementation of the e-mail standards by NTES, which in turn caused SpamAssassin to provide false positives (personally I do not think that they should be considered as false positives, they are REAL problems that should be addressed and corrected). Cheers, -- Xin LI <[EMAIL PROTECTED]> http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: mpd4 on sparc64 problem (maybe netgraph involved)
Volodymyr Kostyrko wrote: I have a host machine (i386) with many i386 clients and one sparc64 all configured the same way. All i386 client work just fine, while sparc64 one refuses to do so. There is a bug in LCP negotiation in mpd4_0b5 on 64bit big-endian platforms like sparc64. I have commited required patches info mpd CVS on sourceforge.net. Patched version is successfully tested on i386, amd64 and sparc64 platforms. -- Alexander Motin ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Proposed 6.2 em RELEASE patch
This patch is an evolution of the last one I sent out. It has
a couple of minor corrections, like a bad forward decl in
the header.
The last patch has had quite a bit of testing and all reports
have been positive. The only complaint was from Gleb who
says he needs to keep his beloved infinite for loop in the
interrupt handler, well I have a better one for you Gleb, keep
reading.
I have also been doing some extreme stress testing using
SmartBits, and discovered the driver as it stands is really
not able to take extreme receive side pounding, Scott
pointed out that this is why the FAST_INTR work was done :)
There were some people that had stability issues with that
work, but there were also many that did not. I actually
merged the FAST code onto my last patch, and ran the
SB stress and found it really was able to gracefully handle
that load, way to go Scott :)
I've pondered this situation, and this patch I'm including here
today is the result. Here's what it does:
If you drop it in place, compile it, and go... you will get the
code that has been tested for a week, it uses the older
style interrupts, it has the watchdog and other SMP fixes
so its been proven.
BUT, I've added the FAST_INTR changes back into the code, so
if you go into your Makefile and add -DEM_FAST_INTR you will
then get the taskqueue stuff.
So, Gleb, rather than replace the infinite for loop that no one
thinks is a good idea, you can just define FAST_INTR again,
and you should be good to go.
I see this as the best thing for the 6.2 RELEASE, it lets us
keep moving forward, people that want max performance
can define EM_FAST_INTR and help us wring out any
problems, it also will mean that I will have our Intel test
group start using this code. But for those that just want
a stable driver the standard compile will still give them that.
The patch I'm including is against BETA3. Let me know of
your concerns or issues.
Cheers,
Jack
diff -Naur stable/dev/em/if_em.c newpatch/dev/em/if_em.c
--- stable/dev/em/if_em.c Wed Nov 8 23:42:20 2006
+++ newpatch/dev/em/if_em.c Wed Nov 8 23:44:16 2006
@@ -204,7 +204,7 @@
static void em_start(struct ifnet *);
static void em_start_locked(struct ifnet *ifp);
static int em_ioctl(struct ifnet *, u_long, caddr_t);
-static void em_watchdog(struct ifnet *);
+static void em_watchdog(struct adapter *);
static void em_init(void *);
static void em_init_locked(struct adapter *);
static void em_stop(void *);
@@ -212,6 +212,8 @@
static int em_media_change(struct ifnet *);
static void em_identify_hardware(struct adapter *);
static int em_allocate_pci_resources(struct adapter *);
+static int em_allocate_intr(struct adapter *);
+static void em_free_intr(struct adapter *);
static void em_free_pci_resources(struct adapter *);
static void em_local_timer(void *);
static int em_hardware_init(struct adapter *);
@@ -253,8 +255,7 @@
static int em_82547_fifo_workaround(struct adapter *, int);
static void em_82547_update_fifo_head(struct adapter *, int);
static int em_82547_tx_fifo_reset(struct adapter *);
-static void em_82547_move_tail(void *arg);
-static void em_82547_move_tail_locked(struct adapter *);
+static void em_82547_move_tail(void *);
static int em_dma_malloc(struct adapter *, bus_size_t,
struct em_dma_alloc *, int);
static void em_dma_free(struct adapter *, struct em_dma_alloc *);
@@ -267,11 +268,18 @@
static int em_sysctl_int_delay(SYSCTL_HANDLER_ARGS);
static void em_add_int_delay_sysctl(struct adapter *, const char *,
const char *, struct em_int_delay_info *, int, int);
+static void em_add_rx_process_limit(struct adapter *, const char *,
+ const char *, int *, int);
+#ifdef EM_FAST_INTR
+static void em_intr_fast(void *);
+static void em_handle_rxtx(void *context, int pending);
+static void em_handle_link(void *context, int pending);
+#else /* Legacy Interrupt Handling */
static void em_intr(void *);
-
#ifdef DEVICE_POLLING
static poll_handler_t em_poll;
-#endif
+#endif /* DEVICE_POLLING */
+#endif /* EM_FAST_INTR */
/*
* FreeBSD Device Interface Entry Points
@@ -321,6 +329,10 @@
TUNABLE_INT("hw.em.txd", &em_txd);
TUNABLE_INT("hw.em.smart_pwr_down", &em_smart_pwr_down);
+/* How many packets rxeof tries to clean at a time */
+static int em_rx_process_limit = 100;
+TUNABLE_INT("hw.em.rx_process_limit", &em_rx_process_limit);
+
/*
* Device identification routine
*
@@ -406,8 +418,8 @@
OID_AUTO, "stats", CTLTYPE_INT|CTLFLAG_RW, adapter, 0,
em_sysctl_stats, "I", "Statistics");
- callout_init(&adapter->timer, CALLOUT_MPSAFE);
- callout_init(&adapter->tx_fifo_timer, CALLOUT_MPSAFE);
+ callout_init_mtx(&adapter->timer, &adapter->mtx, 0);
+ callout_init_mtx(&adapter->tx_fifo_timer, &adapter->mtx, 0);
/* Determine hardware revision */
em_identify_hardware(adapter);
@@ -432,6 +444,11 @@
em_tx_abs_int_delay_dflt);
}
Re: Proposed 6.2 em RELEASE patch
Without introduced this new patch, can I still use sysctl to maximise its performance like FAST_INTR? S On 11/9/06, Jack Vogel <[EMAIL PROTECTED]> wrote: This patch is an evolution of the last one I sent out. It has a couple of minor corrections, like a bad forward decl in the header. The last patch has had quite a bit of testing and all reports have been positive. The only complaint was from Gleb who says he needs to keep his beloved infinite for loop in the interrupt handler, well I have a better one for you Gleb, keep reading. I have also been doing some extreme stress testing using SmartBits, and discovered the driver as it stands is really not able to take extreme receive side pounding, Scott pointed out that this is why the FAST_INTR work was done :) There were some people that had stability issues with that work, but there were also many that did not. I actually merged the FAST code onto my last patch, and ran the SB stress and found it really was able to gracefully handle that load, way to go Scott :) I've pondered this situation, and this patch I'm including here today is the result. Here's what it does: If you drop it in place, compile it, and go... you will get the code that has been tested for a week, it uses the older style interrupts, it has the watchdog and other SMP fixes so its been proven. BUT, I've added the FAST_INTR changes back into the code, so if you go into your Makefile and add -DEM_FAST_INTR you will then get the taskqueue stuff. So, Gleb, rather than replace the infinite for loop that no one thinks is a good idea, you can just define FAST_INTR again, and you should be good to go. I see this as the best thing for the 6.2 RELEASE, it lets us keep moving forward, people that want max performance can define EM_FAST_INTR and help us wring out any problems, it also will mean that I will have our Intel test group start using this code. But for those that just want a stable driver the standard compile will still give them that. The patch I'm including is against BETA3. Let me know of your concerns or issues. Cheers, Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Proposed 6.2 em RELEASE patch
On 11/8/06, Sam Wun <[EMAIL PROTECTED]> wrote: Without introduced this new patch, can I still use sysctl to maximise its performance like FAST_INTR? S Not sure if I'm understanding you, but let me try. You cannot attain the same receive performance without the patch. When I use SmartBits and blast UDP packets at TWO fiber PCI-E NICS and set it to 70% utilization of the line it will just BURY the system, meaning that the shell on the console will appear wedged. Once you stop the test it recovers, but during it its totally consumed handling interrupts. Perhaps with careful tweaking of everything you can make things better, but if so that goes beyond my tuning knowledge. Just one NIC will be OK, and if I drop the utilization down to 45% its ok, but 50 and up and we go into the tank, as it were :) If you compile with EM_FAST_INTR then the system will continue to operate quite well with the same load. Now, this is one kind of load, and there is still other types that work just fine without FAST_INTR, and without the patch you can still use sysctl to adjust tuning parameters as your needs vary. BUT, I do not believe you can do as well as you can with FAST_INTR on, this is why I wanted to get this code back into the driver conditionally before RELEASE. Does that answer your question Sam? Regards, Jack On 11/9/06, Jack Vogel < [EMAIL PROTECTED]> wrote: > > This patch is an evolution of the last one I sent out. It has > a couple of minor corrections, like a bad forward decl in > the header. > > The last patch has had quite a bit of testing and all reports > have been positive. The only complaint was from Gleb who > says he needs to keep his beloved infinite for loop in the > interrupt handler, well I have a better one for you Gleb, keep > reading. > > I have also been doing some extreme stress testing using > SmartBits, and discovered the driver as it stands is really > not able to take extreme receive side pounding, Scott > pointed out that this is why the FAST_INTR work was done :) > > There were some people that had stability issues with that > work, but there were also many that did not. I actually > merged the FAST code onto my last patch, and ran the > SB stress and found it really was able to gracefully handle > that load, way to go Scott :) > > I've pondered this situation, and this patch I'm including here > today is the result. Here's what it does: > > If you drop it in place, compile it, and go... you will get the > code that has been tested for a week, it uses the older > style interrupts, it has the watchdog and other SMP fixes > so its been proven. > > BUT, I've added the FAST_INTR changes back into the code, so > if you go into your Makefile and add -DEM_FAST_INTR you will > then get the taskqueue stuff. > > So, Gleb, rather than replace the infinite for loop that no one > thinks is a good idea, you can just define FAST_INTR again, > and you should be good to go. > > I see this as the best thing for the 6.2 RELEASE, it lets us > keep moving forward, people that want max performance > can define EM_FAST_INTR and help us wring out any > problems, it also will mean that I will have our Intel test > group start using this code. But for those that just want > a stable driver the standard compile will still give them that. > > The patch I'm including is against BETA3. Let me know of > your concerns or issues. > > Cheers, > > Jack > > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to " [EMAIL PROTECTED]" > > > ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
