Re: [PATCH 4/8][BNX2X] resubmit as attachments: bnx2x_hsi.h
On Mon, Oct 08, 2007 at 06:16:17PM +0200, Eliezer Tamir wrote: bnx2x_hsi.h - machine generated hardware and microcode definitions over 7000 lines... how much of this is really needed? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
forcedeth oops
Using 2.6.21-rc1 (x86-64) I can get an oops in the forcedeth driver in
usually under about 5s with heavy network load (near line-rate GE, a
simpy using netcat and /dev/zero from one host to another suffices).
In nv_rx_done we have:
if (flags NV_TX_LASTPACKET) {
if (flags NV_TX_ERROR) {
if (flags NV_TX_UNDERFLOW)
np-stats.tx_fifo_errors++;
if (flags NV_TX_CARRIERLOST)
np-stats.tx_carrier_errors++;
np-stats.tx_errors++;
} else {
np-stats.tx_packets++;
np-stats.tx_bytes += np-get_tx_ctx-skb-len;
}
dev_kfree_skb_any(np-get_tx_ctx-skb);
np-get_tx_ctx-skb = NULL;
}
Now, it seems that sometimes, for reasons I've not really looked into
as yet that np-get_tx_ctx-skb is NULL, so things go kaput (cr2 ends
up being 0x88, which I assume is the offset of len in skb).
No, if I do something along the lines of:
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index a363148..59027aa 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -1918,7 +1918,12 @@ static void nv_tx_done(struct net_device *dev)
np-stats.tx_errors++;
} else {
np-stats.tx_packets++;
- np-stats.tx_bytes +=
np-get_tx_ctx-skb-len;
+ /* XXX for some reason under heavy load,
+ np-get_tx_ctx-skb can be null */
+ if (likely(np-get_tx_ctx-skb))
+ np-stats.tx_bytes +=
np-get_tx_ctx-skb-len;
+ else
+ printk(KERN_ERR XXX saw null
skb\n);
}
dev_kfree_skb_any(np-get_tx_ctx-skb);
np-get_tx_ctx-skb = NULL;
the problem goes away completely, I can do hours of traffic, 100s of
GBs where it would break in a few seconds before. However, I never
see the printk actually print anything... so I'm a bit mystified. I
disassembled the code in the original case and it seems perfectly
sane.
Can anyone explain why I see -skb == NULL and why the above change
seems to make that go away? (Or perhaps why the printk isn't
working).
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skge dysfunction on Amd X2 machine with 4GB memory
On Sun, Feb 11, 2007 at 04:57:55PM +0200, Matti Aarnio wrote: With the skge driver there seems to be some sort of problem to work in a system with memory above the 4 GB of PCI address space. The chipset (apparently) doesn't deal with bus addresses over 4GB even though the MAC does. I guess the right way to fix this long term is to detect systems with these chips and mask the dma_mask globally (or if you're clever per bus)? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pci=routeirq solves EHCI-problem
On Tue, Aug 08, 2006 at 04:27:41PM +0200, Lutz Urban wrote: I'm sorry to tell you that my previous message was bogus. The problem still persists. Daniel Drake has posted a fix that's in -mm you can try. It's probably the least painful solution to date, can you please try that: http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/broken-out/pci-quirk_via_irq-behaviour-change.patch and let us know how it works for you. I'd like to see this or something similar merged into mainline and -stable pretty soon (pending problem reports from people). - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
On Wed, Jun 14, 2006 at 11:40:04AM +0200, Jesper Dangaard Brouer wrote: The Linux traffic's control engine inaccurately calculates transmission times for packets sent over ADSL links. For some packet sizes the error rises to over 50%. This occurs because ADSL uses ATM as its link layer transport, and ATM transmits packets in fixed sized 53 byte cells. What if AAL5 is used? The cell-alignment math is going to be wrong there surely? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Disable multipath cache routing
(cc' list exploded to include various people who might not be reading netdev, sorry about that) On Sat, May 20, 2006 at 03:11:20PM +0530, pravin b shelar wrote: I am working on Linux multipath networking and I will like to fix bugs related to equal cost multipath caching support. My experience here is limited to having been using as and finding it was creating erroneous routes which DaveM correctly guessed was the result of CONFIG_IP_MULTIPATH_CACHED being enabled. Looking over ipv4/route.c there is a fair bit of complex code to audit (fib_semantics.c also needs to be checked, but it's not very involved) so perhaps if you or someone else who understand this code well is interested that would be a good place to start a code audit? I see also a patch from Herbert Xu about disabling this on the input path (the patch isn't present in the tree right now, I'm not sure if it was revert/fixed or just never merged). Perhaps he can also point out what wrong here? http://oss.sgi.com/archives/netdev/2005-04/msg00232.html Anyhow, the code as-is hasn't been maintained for a long time except for a few minor blips (I'm using hg's annotate to find those and have included those people on the cc' list as presumably there are using these features and might have useful input). - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Disable multipath cache routing
Apparently IP_ROUTE_MULTIPATH_CACHED isn't entirely safe to use and will oops the kernel sooner or later. The Kconfig comment says EXPERIMENTAL but it's not. Let's go further and mark it BROKEN for now (leaving the comment as-is though). If nobody steps up to resurrect this code we can discuss removing it entirely. Signed-off-by: Chris Wedgwood [EMAIL PROTECTED] diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig index 011cca7..3a08b9e 100644 --- a/net/ipv4/Kconfig +++ b/net/ipv4/Kconfig @@ -124,7 +124,7 @@ config IP_ROUTE_MULTIPATH config IP_ROUTE_MULTIPATH_CACHED bool IP: equal cost multipath with caching support (EXPERIMENTAL) - depends on IP_ROUTE_MULTIPATH + depends on IP_ROUTE_MULTIPATH BROKEN help Normally, equal cost multipath routing is not supported by the routing cache. If you say Y here, alternative routes are cached - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] MPPE probably doesn't need to be EXPERIMENTAL
A lot of people use MPPE and I'm not aware of too many complaints with this. Remove it's EXPERIMENTAL status. Signed-off-by: Chris Wedgwood [EMAIL PROTECTED] diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index aa633fa..2c56a95 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2579,8 +2579,8 @@ config PPP_BSDCOMP modules once you have said make modules. If unsure, say N. config PPP_MPPE - tristate PPP MPPE compression (encryption) (EXPERIMENTAL) - depends on PPP EXPERIMENTAL + tristate PPP MPPE compression (encryption) + depends on PPP select CRYPTO select CRYPTO_SHA1 select CRYPTO_ARC4 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Router stops routing after changing MAC Address
On Mon, Mar 13, 2006 at 10:00:41AM -0800, Stephen Hemminger wrote: There still is a bug in the 3c59x driver. It doesn't include any code to handle changing the mac address. It will work if you take the device down, change address, then bring it up. But you shouldn't have to do that. I sent a patch do to this probably a year or two back and it was rejected (by akpm if I recall) because of the argument that you could and should take it down, change the MAC and bring it back up. Is this no longer a requirement? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fw: [Bugme-new] [Bug 5627] New: Network boot - IP-Config reports wrong DHCP server address
On Thu, Jan 19, 2006 at 02:14:31AM -0800, Andrew Morton wrote: Summary: Network boot - IP-Config reports wrong DHCP server address Kernel Version: 2.6.14.2 if/we klibc is merged we could pull this code out surely? i had problems myself getting it working reliably and ended up using a small initramfs cpio with a modified ipconfig from klibc there - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.15-rc1] VFS: file-max limit 400490 reached
On Sat, Nov 12, 2005 at 12:26:48AM -0500, Jeff Garzik wrote: VFS: file-max limit 400490 reached does lsof show anything useful? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipv6 SIOCGIFCONF not implemented ?
On Wed, Aug 24, 2005 at 01:44:09PM -0700, David S. Miller wrote: It is intentional, BSD ioctls for configuration are deprecated, use netlink instead. will they go away completely at some point? lots of things that (for example) set interface addresses i bet use the ioctls and are not netlink aware (i'm guessing we have a libnetlink or something people can transition too) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: overflows in /proc/net/dev
On Thu, Aug 18, 2005 at 09:28:10AM +0200, Sebastian Cla?en wrote:
in struct net_device_stats all members are defined as unsgined
long. In time of gigabit ethernet this takes not long to overflow.
It should still take an appreciable amount of time surely? We can
detect those wraps in userspace and deal with it as needed.
Are there any plans to change these coutners to unsigned long long?
It comes up from time to time (see below).
I saw in ifconfig source code the byte and packet counters are
already defined as unsigned long long.
ifconfig is userspace.
[...]
struct net_device_stats
{
- unsigned long rx_packets; /* total packets received
*/
- unsigned long tx_packets; /* total packets transmitted
*/
- unsigned long rx_bytes; /* total bytes received */
- unsigned long tx_bytes; /* total bytes transmitted */
+ unsigned long long rx_packets; /* total packets received
*/
+ unsigned long long tx_packets; /* total packets transmitted
*/
+ unsigned long long rx_bytes;/* total bytes received
*/
+ unsigned long long tx_bytes;/* total bytes transmitted
*/
I thought the concensurs here was that because doing reliable atomic
updates of 64-bit values isn't possible on some (most?) 32-bit
architectures so we need additional locking to make this work which is
undesirable? (It might even be a FAQ by now as this comes up fairly
often).
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: atheros driver - desc
On Sun, Aug 07, 2005 at 05:01:34PM +0200, Harald Welte wrote: I will consult my legal counsel about this. My current naive position on this is that only the actuall process of the re-engineering matters, not the result. Which countries is this advice valid for? Does someone need to chase this inside the US in parallel? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: argh... ;/
On Fri, Aug 12, 2005 at 07:44:28AM -0400, John W. Linville wrote: Don't use crappy MUAs? Well, plenty of people do. It's almost the norm so crappy probably isn't very fair. It does seem that most if the GUI-base MUAs though by default have problematic settings (Mozilla, Thunderbird, Evolution, Outlook all have problems at tims). People also like to cut paste patches from xterms or simlar into MUAs which usually doesn't work very well either. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: argh... ;/
On Fri, Aug 05, 2005 at 01:20:59PM -0400, John W. Linville wrote: Yes. Opening attachments makes them harder to review. Lots of people can't inline patches because they are inflicted with crappy MUAs --- I would much prefer patches as attachments in those cases versus mangled patches. Also, I would arguue any sane MUA would make dealing with reading/openning patches for sensible mime types trivial. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
