* Re: Route cache performance
From: Alexey Kuznetsov @ 2005-09-07 19:59 UTC (permalink / raw)
To: Simon Kirby; +Cc: Robert Olsson, Alexey Kuznetsov, Eric Dumazet, netdev
In-Reply-To: <20050907162854.GB24735@netnation.com>
Hello!
> Yes, setting maxbatch to 10000 also results in working gc,
Could you try lower values? F.e. I guess 300 or a little more
(it is netdev_max_backlog) should be enough.
> for the normal case also hurts the DoS case...and it really hurts when
> the when the DoS case is the normal case.
5.7% is not "really hurts" yet. :-)
Alexey
^ permalink raw reply
* Re: Route cache performance
From: Robert Olsson @ 2005-09-07 17:21 UTC (permalink / raw)
To: Simon Kirby; +Cc: Robert Olsson, Alexey Kuznetsov, Eric Dumazet, netdev
In-Reply-To: <20050907165528.GC24735@netnation.com>
Simon Kirby writes:
> I've only been able to send 179 Mbps from one box, so that's what has
> been killing it. On the receiving end, 2.6.13-rc6 with the direct
> dst_free now drops a bunch but stays responsive with working GC,
> routing through about 69.6 Mbps, while 2.4.27 routes 103 Mbps worth.
If route hash setup is identical, buckets etc and HZ is same etc. I have no
idea about the performance difference. Somebody else? In other case you need
to compare (o)profiles and see if this can give us any hints. To test drivers
etc you might also want to test with a single flow.
Cheers.
--ro
^ permalink raw reply
* Re: Route cache performance
From: Simon Kirby @ 2005-09-07 16:57 UTC (permalink / raw)
To: Robert Olsson; +Cc: Alexey Kuznetsov, Eric Dumazet, netdev
In-Reply-To: <17183.6655.977975.249491@robur.slu.se>
On Wed, Sep 07, 2005 at 06:49:03PM +0200, Robert Olsson wrote:
> It's called trade-off's :) rDoS is hardly nomal case? But maybe it's time
> to compare routing via route hash vs FIB lookup directly again now when
> we have RCU with some FIB lookup's too.
I haven't even filled the route tables yet. I've just been testing with
a bog standard table (three /24s and one /0).
Simon-
^ permalink raw reply
* Re: Route cache performance
From: Simon Kirby @ 2005-09-07 16:55 UTC (permalink / raw)
To: Robert Olsson; +Cc: Alexey Kuznetsov, Eric Dumazet, netdev
In-Reply-To: <17183.309.317160.103056@robur.slu.se>
On Wed, Sep 07, 2005 at 05:03:17PM +0200, Robert Olsson wrote:
> It was quite some time since I saw dst cache overflow and we use 2.6
> in infrastructure. Anyway I was able to "tune" route cache so I see
> in our lab system on a SMP box. I think UP and SMP behaves the same
> but with UP we could disable the deferred delete as Simon tested.
>
> I don't know if anything happen in 2.6.9 I don't think so. But any
> improvement in drivers or FIB lookup may increase the burden so we get
> overflows.
I believe what I've been seeing is a _reduction_ in performance in both
the e1000 driver and other parts of the kernel that result in it handling
these packets much more slowly than in 2.4. The dst cache only overflows
when the thing is completely pegged, so earlier 2.6 versions that were a
little faster (eg: 2.6.11) were only overflowing occasionally depending
on the speed of the input traffic.
I've only been able to send 179 Mbps from one box, so that's what has
been killing it. On the receiving end, 2.6.13-rc6 with the direct
dst_free now drops a bunch but stays responsive with working GC,
routing through about 69.6 Mbps, while 2.4.27 routes 103 Mbps worth.
If it would be helpful, I can build some scripts to do benchmarks with
different kernel combinations, and run it on a bunch of different kernel
versions.
Simon-
^ permalink raw reply
* Re: Route cache performance
From: Robert Olsson @ 2005-09-07 16:49 UTC (permalink / raw)
To: Simon Kirby; +Cc: Robert Olsson, Alexey Kuznetsov, Eric Dumazet, netdev
In-Reply-To: <20050907162854.GB24735@netnation.com>
Simon Kirby writes:
> Yes, setting maxbatch to 10000 also results in working gc, though routing
> throughput is about 5.7% higher when just calling dst_free directly.
Oh that's good news... You loose 5.7% for rDoS but should benefit
in normal conditions.
> There was discussion about this before (recycling of existing entries is
> also now impossible, as compared with 2.4). It's a shame that this win
> for the normal case also hurts the DoS case...and it really hurts when
> the when the DoS case is the normal case.
It's called trade-off's :) rDoS is hardly nomal case? But maybe it's time
to compare routing via route hash vs FIB lookup directly again now when
we have RCU with some FIB lookup's too.
Cheers.
--ro
^ permalink raw reply
* Re: Route cache performance
From: Simon Kirby @ 2005-09-07 16:28 UTC (permalink / raw)
To: Robert Olsson; +Cc: Alexey Kuznetsov, Eric Dumazet, netdev
In-Reply-To: <17182.64751.340488.996748@robur.slu.se>
On Wed, Sep 07, 2005 at 04:45:03PM +0200, Robert Olsson wrote:
> Packet processing happens in RX_SOFIRQ. NAPI or non-NAPI is no difference
> with RCU deferred delete this should happen by the RCU-tasklet when
> tasklets are run after the real SOFTIRQ's.
>
> There is a limit for RCU work... maxbatch it's set to 10 you could back
> out the patch and try increase it 1000/10000 so we know this not prevent
> the freeing of entries.
Yes, setting maxbatch to 10000 also results in working gc, though routing
throughput is about 5.7% higher when just calling dst_free directly.
> Also RCU clearly states that is should be used in read-mostly situations
> rDoS is outside this scope. Anyway it would be interesting to understand
> what's going on.
There was discussion about this before (recycling of existing entries is
also now impossible, as compared with 2.4). It's a shame that this win
for the normal case also hurts the DoS case...and it really hurts when
the when the DoS case is the normal case.
Simon-
^ permalink raw reply
* Re: Route cache performance
From: Robert Olsson @ 2005-09-07 15:03 UTC (permalink / raw)
To: Alexey Kuznetsov; +Cc: Simon Kirby, Robert Olsson, Eric Dumazet, netdev
In-Reply-To: <20050907011959.GA25725@yakov.inr.ac.ru>
Alexey Kuznetsov writes:
> Robert, have you seen this pehonomenon already? Did you mean that SMP works
> or that it never works (but this patch is valid only for UP)? Did it
> become worse after 2.6.9?
It was quite some time since I saw dst cache overflow and we use 2.6
in infrastructure. Anyway I was able to "tune" route cache so I see
in our lab system on a SMP box. I think UP and SMP behaves the same
but with UP we could disable the deferred delete as Simon tested.
I don't know if anything happen in 2.6.9 I don't think so. But any
improvement in drivers or FIB lookup may increase the burden so we get
overflows.
We had some code that checked the RCU latency.
Cheers.
--ro
^ permalink raw reply
* Re: Route cache performance
From: Robert Olsson @ 2005-09-07 14:45 UTC (permalink / raw)
To: Simon Kirby; +Cc: Robert Olsson, Alexey Kuznetsov, Eric Dumazet, netdev
In-Reply-To: <20050906235700.GA31820@netnation.com>
Simon Kirby writes:
> Woot!
>
> Yes, this is the difference. With the patch applied (ajust directly
> freeing the dst_entry), everything balances easily, there are no
> overflows, and the result of rt_may_expire() looks very reasonable.
> (Yay!)
>
> So, this seems to be the culprit. Is NAPI supposed to allow the
> queued bh to run or should we just not be queuing this?
Packet processing happens in RX_SOFIRQ. NAPI or non-NAPI is no difference
with RCU deferred delete this should happen by the RCU-tasklet when
tasklets are run after the real SOFTIRQ's.
There is a limit for RCU work... maxbatch it's set to 10 you could back
out the patch and try increase it 1000/10000 so we know this not prevent
the freeing of entries.
module_param(maxbatch, int, 0); /* rcupdate.c */
Also RCU clearly states that is should be used in read-mostly situations
rDoS is outside this scope. Anyway it would be interesting to understand
what's going on.
Cheers.
--ro
^ permalink raw reply
* [AX.25] Make asc2ax thread-proof
From: Ralf Baechle DL5RB @ 2005-09-07 14:34 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-hams
Asc2ax was still using a static buffer for all invocations which isn't
exactly SMP-safe. Change asc2ax to take an additional result buffer as
the argument. Change all callers to provide such a buffer.
This one only really is a fix for ROSE and as per recent discussions
there's still much more to fix in ROSE ...
Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
include/net/ax25.h | 2 +-
net/ax25/ax25_addr.c | 27 ++++++++++++---------------
net/rose/rose_subr.c | 4 ++--
3 files changed, 15 insertions(+), 18 deletions(-)
Index: linux-cvs/include/net/ax25.h
===================================================================
--- linux-cvs.orig/include/net/ax25.h
+++ linux-cvs/include/net/ax25.h
@@ -279,7 +279,7 @@ extern struct sock *ax25_make_new(struct
/* ax25_addr.c */
extern ax25_address null_ax25_address;
extern char *ax2asc(char *buf, ax25_address *);
-extern ax25_address *asc2ax(char *);
+extern void asc2ax(ax25_address *addr, char *callsign);
extern int ax25cmp(ax25_address *, ax25_address *);
extern int ax25digicmp(ax25_digi *, ax25_digi *);
extern unsigned char *ax25_addr_parse(unsigned char *, int, ax25_address *, ax25_address *, ax25_digi *, int *, int *);
Index: linux-cvs/net/ax25/ax25_addr.c
===================================================================
--- linux-cvs.orig/net/ax25/ax25_addr.c
+++ linux-cvs/net/ax25/ax25_addr.c
@@ -67,37 +67,34 @@ char *ax2asc(char *buf, ax25_address *a)
/*
* ascii -> ax25 conversion
*/
-ax25_address *asc2ax(char *callsign)
+void asc2ax(ax25_address *addr, char *callsign)
{
- static ax25_address addr;
char *s;
int n;
for (s = callsign, n = 0; n < 6; n++) {
if (*s != '\0' && *s != '-')
- addr.ax25_call[n] = *s++;
+ addr->ax25_call[n] = *s++;
else
- addr.ax25_call[n] = ' ';
- addr.ax25_call[n] <<= 1;
- addr.ax25_call[n] &= 0xFE;
+ addr->ax25_call[n] = ' ';
+ addr->ax25_call[n] <<= 1;
+ addr->ax25_call[n] &= 0xFE;
}
if (*s++ == '\0') {
- addr.ax25_call[6] = 0x00;
- return &addr;
+ addr->ax25_call[6] = 0x00;
+ return;
}
- addr.ax25_call[6] = *s++ - '0';
+ addr->ax25_call[6] = *s++ - '0';
if (*s != '\0') {
- addr.ax25_call[6] *= 10;
- addr.ax25_call[6] += *s++ - '0';
+ addr->ax25_call[6] *= 10;
+ addr->ax25_call[6] += *s++ - '0';
}
- addr.ax25_call[6] <<= 1;
- addr.ax25_call[6] &= 0x1E;
-
- return &addr;
+ addr->ax25_call[6] <<= 1;
+ addr->ax25_call[6] &= 0x1E;
}
/*
Index: linux-cvs/net/rose/rose_subr.c
===================================================================
--- linux-cvs.orig/net/rose/rose_subr.c
+++ linux-cvs/net/rose/rose_subr.c
@@ -337,13 +337,13 @@ static int rose_parse_ccitt(unsigned cha
memcpy(&facilities->source_addr, p + 7, ROSE_ADDR_LEN);
memcpy(callsign, p + 12, l - 10);
callsign[l - 10] = '\0';
- facilities->source_call = *asc2ax(callsign);
+ asc2ax(&facilities->source_call, callsign);
}
if (*p == FAC_CCITT_SRC_NSAP) {
memcpy(&facilities->dest_addr, p + 7, ROSE_ADDR_LEN);
memcpy(callsign, p + 12, l - 10);
callsign[l - 10] = '\0';
- facilities->dest_call = *asc2ax(callsign);
+ asc2ax(&facilities->dest_call, callsign);
}
p += l + 2;
n += l + 2;
^ permalink raw reply
* Re: [patch 1/1] ipw2100: remove by-hand function entry/exit debugging
From: Ingo Oeser @ 2005-09-07 13:39 UTC (permalink / raw)
To: Jeff Garzik
Cc: David S. Miller, akpm, pavel, ipw2100-admin, pavel, linux-kernel,
netdev
In-Reply-To: <431E5514.2070003@pobox.com>
Hi Jeff,
Jeff Garzik wrote:
> David S. Miller wrote:
> > From: Jeff Garzik <jgarzik@pobox.com>
> > Date: Tue, 06 Sep 2005 21:51:21 -0400
> >
> >>NAK. Rationale: maintainer's choice. Pavel doesn't get to choose
> >>the debugger of choice for the driver maintainer.
> >
> > If it makes the driver unreadable and thus harder to maintain,
> > I think such changes should seriously be considered.
> >
> > Most of the DEBUG_INFO macro usage is fine, but those "enter"
> > and "exit" ones are just pure noise and should be removed.
>
> I find them useful in my own drivers; they are definitely not pure noise.
gcc -finstrument-functions
can do that completely without adding noise to the sources.
been there, done that. With a gcc-patch you don't even need to
resolve symbols.
Regards
Ingo Oeser
^ permalink raw reply
* Re: [PATCH] wrong firmware location in IPW2100 Kconfig entry (Was: IPW2100 Kconfig)
From: Jiri Slaby @ 2005-09-07 12:44 UTC (permalink / raw)
To: abonilla
Cc: 'Jesper Juhl', netdev, linux-kernel, ipw2100-admin,
'Roman Zippel', 'Sam Ravnborg'
In-Reply-To: <005901c5b313$fc974610$a20cc60a@amer.sykes.com>
Alejandro Bonilla napsal(a):
> Thanks. I also had a question. To whom is this patch sent to? Netdev or LK?
>How does one determine?
>
>
Read, read, read. Documentation/SubmittingPatches, point 4.
--
Jiri Slaby www.fi.muni.cz/~xslaby
~\-/~ jirislaby@gmail.com ~\-/~
241B347EC88228DE51EE A49C4A73A25004CB2A10
^ permalink raw reply
* Re: Fw: masquerading failure for at least icmp and tcp+sack on amd64
From: Patrick McHardy @ 2005-09-07 12:39 UTC (permalink / raw)
To: Marc Lehmann; +Cc: Andrew Morton, netdev, Netfilter Development Mailinglist
In-Reply-To: <20050907052057.09714a4c.akpm@osdl.org>
Andrew Morton wrote:
> I recently upgraded a 32 bit machine to a new amd64 board+cpu. I took the
> same kernel (2.6.13-rc7) and just recompiled it for 64 bit, plus upgraded
> userspace to 64 bit.
>
> Firewall config stayed the same.
>
> Problem: neither ping nor tcp was being masqueraded properly. I created
> the following test-set-up:
>
> iptables -t mangle -F
> iptables -t filter -F
> iptables -t nat -F
> iptables -t nat -A POSTROUTING -p all -s 10.0.0.0/8 -d \! 10.0.0.0/8 -j MASQUERADE
>
> i..e the above masquerade rule should be the only firewall rule, and all
> fules shoul[d have policy ACCEPT.
>
> The effect was that tcp packets and icmp packets coming from 10.0.0.1 on
> interface eth0 were properly masqueraded on the outgoing "inet" interface
> (ppp0 renamed):
>
> eth0:
> 19:17:24.364351 IP 10.0.0.1.44320 > 129.13.162.95.80: S 3745828676:3745828676(0) win 5840 <mss 1460,nop,nop,sackOK>
>
> inet:
> 19:17:24.364505 IP 84.56.237.68.44320 > 129.13.162.95.80: S 3745828676:3745828676(0) win 5840 <mss 1452,nop,nop,sackOK>
> 19:17:24.378029 IP 129.13.162.95.80 > 84.56.237.68.44320: S 3777391404:3777391404(0) ack 3745828677 win 5840 <mss 1460,nop,nop,sackOK>
> 19:17:24.378103 IP 84.56.237.68.44320 > 129.13.162.95.80: R 3745828677:3745828677(0) win 0
>
> However, the reverse packets were rejected. ip_conntrack showed this:
>
> tcp 6 52 SYN_SENT src=10.0.0.1 dst=129.13.162.95 sport=44320 dport=80 [UNREPLIED] src=129.13.162.95 dst=84.56.237.68 sport=80 dport=44320 mark=0 use=1
It seems ip_conntrack did not like the SYN/ACK and marked it as invalid,
NAT leaves the packet alone and the firewall resets the connection.
Please try if loading the ipt_LOG module and executing
"echo 255 > /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid"
gives more information
> Weird obervation 2:
>
> Some sites could be connected to with TCP. It turned out that those
> sites did not support TCP SACK. Indeed, turning off SACK either on the
> remote side of a connection or on the origonator side resulted in workign
> masquerading:
>
> eth0:
> 19:23:29.928470 IP 10.0.0.1.45611 > 129.13.162.95.80: S 4113365634:4113365634(0) win 5840 <mss 1460>
> 19:23:29.942246 IP 129.13.162.95.80 > 10.0.0.1.45611: S 4161877683:4161877683(0) ack 4113365635 win 5840 <mss 1460>
> 19:23:29.942313 IP 10.0.0.1.45611 > 129.13.162.95.80: . ack 1 win 5840
>
> inet:
> 19:23:29.928249 IP 84.56.237.68.45611 > 129.13.162.95.80: S 4113365634:4113365634(0) win 5840 <mss 1452>
> 19:23:29.942199 IP 129.13.162.95.80 > 84.56.237.68.45611: S 4161877683:4161877683(0) ack 4113365635 win 5840 <mss 1460>
> 19:23:29.942332 IP 84.56.237.68.45611 > 129.13.162.95.80: . ack 1 win 5840
>
> However, ICMP still is not masqueraded.
Please also try this again with logging enabled.
> Kernels that worked:
>
> 2.6.13-rc7, 2.6.12.5, 2.6.11 and lower, compiled for x86 with gcc-3.4
>
> Kernels that don't work:
>
> 2.6.13-rc7 (compiled with gcc-3.4 and 4.0.2 debian), 2.6.13 (gcc-4.02)
Can you retest with 2.6.12.5 on 64bit so we can see if it is a new
problem?
> Kernel configuration was exactly the same for the 2.6.13-rc7 kernels,
> modulo the cpu and architectrue selections.
>
> I have a somewhat nontrivial source routing set-up on that machine that I
> could document more if that could be a possible reason for that problem. I
> am confident that this is not a configuration error, as the configuraiton
> worked basically unchanged since the 2.4 days, and I am confident it's not
> a iptables setup problem either, as I can reproduce it with empty rules
> except for the masquerading rule.
So far I don't think its related to routed.
^ permalink raw reply
* [git patches] net driver update
From: Jeff Garzik @ 2005-09-07 4:55 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
[just sent this to Andrew/Linus]
Please pull from 'upstream' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to obtain the various updates described below:
drivers/net/Kconfig | 7
drivers/net/Makefile | 2
drivers/net/ac3200.c | 2
drivers/net/atarilance.c | 2
drivers/net/dm9000.c | 2
drivers/net/forcedeth.c | 4
drivers/net/iseries_veth.c | 1
drivers/net/s2io-regs.h | 13
drivers/net/s2io.c | 98 -
drivers/net/s2io.h | 5
drivers/net/spider_net.c | 2334 ++++++++++++++++++++++++++++++
drivers/net/spider_net.h | 469 ++++++
drivers/net/spider_net_ethtool.c | 126 +
drivers/net/sun3lance.c | 2
drivers/net/wireless/airo.c | 43
drivers/net/wireless/atmel.c | 17
drivers/net/wireless/ipw2200.c | 2264 ++++++++++++++---------------
drivers/net/wireless/ipw2200.h | 408 ++---
drivers/net/wireless/netwave_cs.c | 7
drivers/net/wireless/prism54/isl_ioctl.c | 3
drivers/net/wireless/prism54/islpci_dev.c | 3
drivers/net/wireless/ray_cs.c | 858 +++++------
drivers/net/wireless/ray_cs.h | 7
drivers/net/wireless/wl3501.h | 1
drivers/net/wireless/wl3501_cs.c | 7
drivers/s390/net/claw.c | 20
include/linux/pci_ids.h | 1
include/linux/wireless.h | 38
include/net/iw_handler.h | 123 +
net/core/wireless.c | 58
net/ieee80211/ieee80211_crypt.c | 27
net/ieee80211/ieee80211_crypt_ccmp.c | 47
net/ieee80211/ieee80211_crypt_tkip.c | 131 -
net/ieee80211/ieee80211_crypt_wep.c | 30
net/ieee80211/ieee80211_module.c | 40
net/ieee80211/ieee80211_rx.c | 310 ++-
net/ieee80211/ieee80211_tx.c | 66
net/ieee80211/ieee80211_wx.c | 73
38 files changed, 5350 insertions(+), 2299 deletions(-)
Al Viro:
lvalues abuse in lance
Frank Pavlic:
s390: claw driver fixes
Jean Tourrilhes:
WE-19 for kernel 2.6.13
ray_cs : WE-17 support
iw263_netwave_we17.diff
atmel_cs : WE-17 support
wl3501_cs : WE-17 support
prism54 : WE-17 support
airo : WE-19 support
Jeff Garzik:
[wireless] build fixes after merging WE-19
[wireless ieee80211,ipw2200] Lindent source code
>>
>> NOTE: As explained in the full cset description, this Lindent
>> will help us sync up Intel, and as a side effect make the code
>> look better.
>>
Jens Osterkamp:
net: add driver for the NIC on Cell Blades
net: update the spider_net driver
net: fix bonding with spider_net
Michael Ellerman:
iseries_veth: Update copyright notice
ravinandan.arakali@neterion.com:
S2io: Hardware and miscellaneous fixes
viro@ftp.linux.org.uk:
iomem annotations (ac3200.c)
missed s/u32/pm_message_t/ (dm9000)
__user annotations (forcedeth.c)
[patch snipped]
^ permalink raw reply
* [PATCH 2.6.13] S2io: Hardware and miscellaneous fixes
From: ravinandan.arakali @ 2005-09-07 4:36 UTC (permalink / raw)
To: jgarzik, netdev
Cc: raghavendra.koushik, ravinandan.arakali, leonid.grossman,
rapuru.sriram, ananda.raju
Hi,
This patch contains the following hardware related fixes and other
miscellaneous bug fixes.
1. Updated the definition of single and double-bit ECC errors
2. Earlier we were allocating Transmit descriptors equal to
MAX_SKB_FRAGS. This was causing a boundary condition failure.
Need to allocate MAX_SKB_FRAGS+1 descriptors.
3. On some platforms(like PPC), pci_alloc_consistent() can return
a zero DMA address. Since the NIC cannot handle zero-addresses,
a workaround has been provided. Basically, we don't use such
that page. We reallocate.
4. If list_info allocation failed during driver load, check for
it during driver exit and return instead of trying to dereference
NULL pointer.
5. Increase the debug level of few non-critical debug messages.
6. Reset the card on critical ECC double errors only in case of
XframeI since XframeII can recover from such errors.
7. Print copyright message on driver load.
8. Bumped up the driver version no. to 2.0.8.1
Signed-off-by: Ravinandan Arakali <ravinandan.arakali@neterion.com>
---
diff -urpN old/drivers/net/s2io-regs.h new/drivers/net/s2io-regs.h
--- old/drivers/net/s2io-regs.h 2005-09-06 04:51:44.000000000 -0700
+++ new/drivers/net/s2io-regs.h 2005-09-06 04:52:08.000000000 -0700
@@ -1,5 +1,5 @@
/************************************************************************
- * regs.h: A Linux PCI-X Ethernet driver for S2IO 10GbE Server NIC
+ * regs.h: A Linux PCI-X Ethernet driver for Neterion 10GbE Server NIC
* Copyright(c) 2002-2005 Neterion Inc.
* This software may be used and distributed according to the terms of
@@ -713,13 +713,16 @@ typedef struct _XENA_dev_config {
u64 mc_err_reg;
#define MC_ERR_REG_ECC_DB_ERR_L BIT(14)
#define MC_ERR_REG_ECC_DB_ERR_U BIT(15)
+#define MC_ERR_REG_MIRI_ECC_DB_ERR_0 BIT(18)
+#define MC_ERR_REG_MIRI_ECC_DB_ERR_1 BIT(20)
#define MC_ERR_REG_MIRI_CRI_ERR_0 BIT(22)
#define MC_ERR_REG_MIRI_CRI_ERR_1 BIT(23)
#define MC_ERR_REG_SM_ERR BIT(31)
-#define MC_ERR_REG_ECC_ALL_SNG (BIT(6) | \
- BIT(7) | BIT(17) | BIT(19))
-#define MC_ERR_REG_ECC_ALL_DBL (BIT(14) | \
- BIT(15) | BIT(18) | BIT(20))
+#define MC_ERR_REG_ECC_ALL_SNG (BIT(2) | BIT(3) | BIT(4) | BIT(5) |\
+ BIT(6) | BIT(7) | BIT(17) | BIT(19))
+#define MC_ERR_REG_ECC_ALL_DBL (BIT(10) | BIT(11) | BIT(12) |\
+ BIT(13) | BIT(14) | BIT(15) |\
+ BIT(18) | BIT(20))
u64 mc_err_mask;
u64 mc_err_alarm;
diff -urpN old/drivers/net/s2io.c new/drivers/net/s2io.c
--- old/drivers/net/s2io.c 2005-09-06 04:51:44.000000000 -0700
+++ new/drivers/net/s2io.c 2005-09-06 04:52:08.000000000 -0700
@@ -1,5 +1,5 @@
/************************************************************************
- * s2io.c: A Linux PCI-X Ethernet driver for S2IO 10GbE Server NIC
+ * s2io.c: A Linux PCI-X Ethernet driver for Neterion 10GbE Server NIC
* Copyright(c) 2002-2005 Neterion Inc.
* This software may be used and distributed according to the terms of
@@ -28,7 +28,7 @@
* explaination of all the variables.
* rx_ring_num : This can be used to program the number of receive rings used
* in the driver.
- * rx_ring_len: This defines the number of descriptors each ring can have. This
+ * rx_ring_sz: This defines the number of descriptors each ring can have. This
* is also an array of size 8.
* tx_fifo_num: This defines the number of Tx FIFOs thats used int the driver.
* tx_fifo_len: This too is an array of 8. Each element defines the number of
@@ -67,7 +67,7 @@
/* S2io Driver name & version. */
static char s2io_driver_name[] = "Neterion";
-static char s2io_driver_version[] = "Version 2.0.3.1";
+static char s2io_driver_version[] = "Version 2.0.8.1";
static inline int RXD_IS_UP2DT(RxD_t *rxdp)
{
@@ -404,7 +404,7 @@ static int init_shared_mem(struct s2io_n
config->tx_cfg[i].fifo_len - 1;
mac_control->fifos[i].fifo_no = i;
mac_control->fifos[i].nic = nic;
- mac_control->fifos[i].max_txds = MAX_SKB_FRAGS;
+ mac_control->fifos[i].max_txds = MAX_SKB_FRAGS + 1;
for (j = 0; j < page_num; j++) {
int k = 0;
@@ -418,6 +418,26 @@ static int init_shared_mem(struct s2io_n
DBG_PRINT(ERR_DBG, "failed for TxDL\n");
return -ENOMEM;
}
+ /* If we got a zero DMA address(can happen on
+ * certain platforms like PPC), reallocate.
+ * Store virtual address of page we don't want,
+ * to be freed later.
+ */
+ if (!tmp_p) {
+ mac_control->zerodma_virt_addr = tmp_v;
+ DBG_PRINT(INIT_DBG,
+ "%s: Zero DMA address for TxDL. ", dev->name);
+ DBG_PRINT(INIT_DBG,
+ "Virtual address %llx\n", (u64)tmp_v);
+ tmp_v = pci_alloc_consistent(nic->pdev,
+ PAGE_SIZE, &tmp_p);
+ if (!tmp_v) {
+ DBG_PRINT(ERR_DBG,
+ "pci_alloc_consistent ");
+ DBG_PRINT(ERR_DBG, "failed for TxDL\n");
+ return -ENOMEM;
+ }
+ }
while (k < lst_per_page) {
int l = (j * lst_per_page) + k;
if (l == config->tx_cfg[i].fifo_len)
@@ -600,7 +620,7 @@ static void free_shared_mem(struct s2io_
mac_info_t *mac_control;
struct config_param *config;
int lst_size, lst_per_page;
-
+ struct net_device *dev = nic->dev;
if (!nic)
return;
@@ -616,9 +636,10 @@ static void free_shared_mem(struct s2io_
lst_per_page);
for (j = 0; j < page_num; j++) {
int mem_blks = (j * lst_per_page);
- if ((!mac_control->fifos[i].list_info) ||
- (!mac_control->fifos[i].list_info[mem_blks].
- list_virt_addr))
+ if (!mac_control->fifos[i].list_info)
+ return;
+ if (!mac_control->fifos[i].list_info[mem_blks].
+ list_virt_addr)
break;
pci_free_consistent(nic->pdev, PAGE_SIZE,
mac_control->fifos[i].
@@ -628,6 +649,18 @@ static void free_shared_mem(struct s2io_
list_info[mem_blks].
list_phy_addr);
}
+ /* If we got a zero DMA address during allocation,
+ * free the page now
+ */
+ if (mac_control->zerodma_virt_addr) {
+ pci_free_consistent(nic->pdev, PAGE_SIZE,
+ mac_control->zerodma_virt_addr,
+ (dma_addr_t)0);
+ DBG_PRINT(INIT_DBG,
+ "%s: Freeing TxDL with zero DMA addr. ", dev->name);
+ DBG_PRINT(INIT_DBG, "Virtual address %llx\n",
+ (u64)(mac_control->zerodma_virt_addr));
+ }
kfree(mac_control->fifos[i].list_info);
}
@@ -2479,9 +2512,10 @@ static void rx_intr_handler(ring_info_t
#endif
spin_lock(&nic->rx_lock);
if (atomic_read(&nic->card_state) == CARD_DOWN) {
- DBG_PRINT(ERR_DBG, "%s: %s going down for reset\n",
+ DBG_PRINT(INTR_DBG, "%s: %s going down for reset\n",
__FUNCTION__, dev->name);
spin_unlock(&nic->rx_lock);
+ return;
}
get_info = ring_data->rx_curr_get_info;
@@ -2596,8 +2630,14 @@ static void tx_intr_handler(fifo_info_t
if (txdlp->Control_1 & TXD_T_CODE) {
unsigned long long err;
err = txdlp->Control_1 & TXD_T_CODE;
- DBG_PRINT(ERR_DBG, "***TxD error %llx\n",
- err);
+ if ((err >> 48) == 0xA) {
+ DBG_PRINT(TX_DBG, "TxD returned due \
+ to loss of link\n");
+ }
+ else {
+ DBG_PRINT(ERR_DBG, "***TxD error \
+ %llx\n", err);
+ }
}
skb = (struct sk_buff *) ((unsigned long)
@@ -2689,12 +2729,16 @@ static void alarm_intr_handler(struct s2
if (val64 & MC_ERR_REG_ECC_ALL_DBL) {
nic->mac_control.stats_info->sw_stat.
double_ecc_errs++;
- DBG_PRINT(ERR_DBG, "%s: Device indicates ",
+ DBG_PRINT(INIT_DBG, "%s: Device indicates ",
dev->name);
- DBG_PRINT(ERR_DBG, "double ECC error!!\n");
+ DBG_PRINT(INIT_DBG, "double ECC error!!\n");
if (nic->device_type != XFRAME_II_DEVICE) {
- netif_stop_queue(dev);
- schedule_work(&nic->rst_timer_task);
+ /* Reset XframeI only if critical error */
+ if (val64 & (MC_ERR_REG_MIRI_ECC_DB_ERR_0 |
+ MC_ERR_REG_MIRI_ECC_DB_ERR_1)) {
+ netif_stop_queue(dev);
+ schedule_work(&nic->rst_timer_task);
+ }
}
} else {
nic->mac_control.stats_info->sw_stat.
@@ -2706,7 +2750,8 @@ static void alarm_intr_handler(struct s2
val64 = readq(&bar0->serr_source);
if (val64 & SERR_SOURCE_ANY) {
DBG_PRINT(ERR_DBG, "%s: Device indicates ", dev->name);
- DBG_PRINT(ERR_DBG, "serious error!!\n");
+ DBG_PRINT(ERR_DBG, "serious error %llx!!\n",
+ (unsigned long long)val64);
netif_stop_queue(dev);
schedule_work(&nic->rst_timer_task);
}
@@ -3130,7 +3175,7 @@ int s2io_xmit(struct sk_buff *skb, struc
queue_len = mac_control->fifos[queue].tx_curr_put_info.fifo_len + 1;
/* Avoid "put" pointer going beyond "get" pointer */
if (txdp->Host_Control || (((put_off + 1) % queue_len) == get_off)) {
- DBG_PRINT(ERR_DBG, "Error in xmit, No free TXDs.\n");
+ DBG_PRINT(TX_DBG, "Error in xmit, No free TXDs.\n");
netif_stop_queue(dev);
dev_kfree_skb(skb);
spin_unlock_irqrestore(&sp->tx_lock, flags);
@@ -3528,7 +3573,7 @@ static void s2io_set_multicast(struct ne
val64 = readq(&bar0->mac_cfg);
sp->promisc_flg = 1;
- DBG_PRINT(ERR_DBG, "%s: entered promiscuous mode\n",
+ DBG_PRINT(INFO_DBG, "%s: entered promiscuous mode\n",
dev->name);
} else if (!(dev->flags & IFF_PROMISC) && (sp->promisc_flg)) {
/* Remove the NIC from promiscuous mode */
@@ -3543,7 +3588,7 @@ static void s2io_set_multicast(struct ne
val64 = readq(&bar0->mac_cfg);
sp->promisc_flg = 0;
- DBG_PRINT(ERR_DBG, "%s: left promiscuous mode\n",
+ DBG_PRINT(INFO_DBG, "%s: left promiscuous mode\n",
dev->name);
}
@@ -5325,7 +5370,7 @@ s2io_init_nic(struct pci_dev *pdev, cons
break;
}
}
- config->max_txds = MAX_SKB_FRAGS;
+ config->max_txds = MAX_SKB_FRAGS + 1;
/* Rx side parameters. */
if (rx_ring_sz[0] == 0)
@@ -5525,9 +5570,14 @@ s2io_init_nic(struct pci_dev *pdev, cons
if (sp->device_type & XFRAME_II_DEVICE) {
DBG_PRINT(ERR_DBG, "%s: Neterion Xframe II 10GbE adapter ",
dev->name);
- DBG_PRINT(ERR_DBG, "(rev %d), Driver %s\n",
+ DBG_PRINT(ERR_DBG, "(rev %d), %s",
get_xena_rev_id(sp->pdev),
s2io_driver_version);
+#ifdef CONFIG_2BUFF_MODE
+ DBG_PRINT(ERR_DBG, ", Buffer mode %d",2);
+#endif
+
+ DBG_PRINT(ERR_DBG, "\nCopyright(c) 2002-2005 Neterion Inc.\n");
DBG_PRINT(ERR_DBG, "MAC ADDR: %02x:%02x:%02x:%02x:%02x:%02x\n",
sp->def_mac_addr[0].mac_addr[0],
sp->def_mac_addr[0].mac_addr[1],
@@ -5544,9 +5594,13 @@ s2io_init_nic(struct pci_dev *pdev, cons
} else {
DBG_PRINT(ERR_DBG, "%s: Neterion Xframe I 10GbE adapter ",
dev->name);
- DBG_PRINT(ERR_DBG, "(rev %d), Driver %s\n",
+ DBG_PRINT(ERR_DBG, "(rev %d), %s",
get_xena_rev_id(sp->pdev),
s2io_driver_version);
+#ifdef CONFIG_2BUFF_MODE
+ DBG_PRINT(ERR_DBG, ", Buffer mode %d",2);
+#endif
+ DBG_PRINT(ERR_DBG, "\nCopyright(c) 2002-2005 Neterion Inc.\n");
DBG_PRINT(ERR_DBG, "MAC ADDR: %02x:%02x:%02x:%02x:%02x:%02x\n",
sp->def_mac_addr[0].mac_addr[0],
sp->def_mac_addr[0].mac_addr[1],
diff -urpN old/drivers/net/s2io.h new/drivers/net/s2io.h
--- old/drivers/net/s2io.h 2005-09-06 04:51:44.000000000 -0700
+++ new/drivers/net/s2io.h 2005-09-06 04:52:08.000000000 -0700
@@ -1,5 +1,5 @@
/************************************************************************
- * s2io.h: A Linux PCI-X Ethernet driver for S2IO 10GbE Server NIC
+ * s2io.h: A Linux PCI-X Ethernet driver for Neterion 10GbE Server NIC
* Copyright(c) 2002-2005 Neterion Inc.
* This software may be used and distributed according to the terms of
@@ -622,6 +622,9 @@ typedef struct mac_info {
/* Fifo specific structure */
fifo_info_t fifos[MAX_TX_FIFOS];
+ /* Save virtual address of TxD page with zero DMA addr(if any) */
+ void *zerodma_virt_addr;
+
/* rx side stuff */
/* Ring specific structure */
ring_info_t rings[MAX_RX_RINGS];
^ permalink raw reply
* Re: [patch 1/1] ipw2100: remove by-hand function entry/exit debugging
From: Jeff Garzik @ 2005-09-07 2:48 UTC (permalink / raw)
To: David S. Miller; +Cc: akpm, pavel, ipw2100-admin, pavel, linux-kernel, netdev
In-Reply-To: <20050906.194111.130652562.davem@davemloft.net>
David S. Miller wrote:
> From: Jeff Garzik <jgarzik@pobox.com>
> Date: Tue, 06 Sep 2005 21:51:21 -0400
>
>
>>NAK. Rationale: maintainer's choice. Pavel doesn't get to choose
>>the debugger of choice for the driver maintainer.
>
>
> If it makes the driver unreadable and thus harder to maintain,
> I think such changes should seriously be considered.
>
> Most of the DEBUG_INFO macro usage is fine, but those "enter"
> and "exit" ones are just pure noise and should be removed.
I find them useful in my own drivers; they are definitely not pure noise.
Jeff
^ permalink raw reply
* Re: proto_unregister sleeps while atomic
From: David S. Miller @ 2005-09-07 2:48 UTC (permalink / raw)
To: kaber; +Cc: daniele, linux-kernel, netdev
In-Reply-To: <431E2978.2030701@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Wed, 07 Sep 2005 01:42:48 +0200
> The only other user of proto_list besides proto_register, which
> doesn't care, are the seqfs functions. They use the slab pointer,
> but in a harmless way:
>
> proto->slab == NULL ? "no" : "yes",
>
> Anyway, I've moved it up to the top.
Ok thanks, patch applied.
^ permalink raw reply
* Re: [patch 1/1] ipw2100: remove by-hand function entry/exit debugging
From: David S. Miller @ 2005-09-07 2:41 UTC (permalink / raw)
To: jgarzik; +Cc: akpm, pavel, ipw2100-admin, pavel, linux-kernel, netdev
In-Reply-To: <431E4799.7000502@pobox.com>
From: Jeff Garzik <jgarzik@pobox.com>
Date: Tue, 06 Sep 2005 21:51:21 -0400
> NAK. Rationale: maintainer's choice. Pavel doesn't get to choose
> the debugger of choice for the driver maintainer.
If it makes the driver unreadable and thus harder to maintain,
I think such changes should seriously be considered.
Most of the DEBUG_INFO macro usage is fine, but those "enter"
and "exit" ones are just pure noise and should be removed.
^ permalink raw reply
* Re: Patch for link detection for R8169
From: Jeff Garzik @ 2005-09-07 1:56 UTC (permalink / raw)
To: Francois Romieu; +Cc: Miroslaw Mieszczak, linux-kernel, Netdev List
In-Reply-To: <20050906194602.GA20862@electric-eye.fr.zoreil.com>
Francois Romieu wrote:
> Miroslaw Mieszczak <mieszcz@zabrze.zigzag.pl> :
>
>>There is a patch to driver of RLT8169 network card. This match make
>>possible detection of the link status even if network interface is down.
>>This is usefull for laptop users.
>
>
> (side note: there is maintainer entry for the r8169 and network related
> patches are welcome on netdev@vger.kernel.org)
>
> Can you elaborate why it is usefull for laptop users ?
>
> I am sceptical: tg3/bn2x/skge do not seem to allow it either.
>
> Jeff, is it a requirement ?
Generally most drivers power down hardware, MAC at least, when the
interface is down. As such, many drivers do not (cannot), as written,
report any useful link information.
IF the phy is not powered down, when the interface goes down, and IF
hardware permits, it would certainly be nice to report link state when
interface is down. This is a hardware-dependent, driver-dependent choice.
Jeff
^ permalink raw reply
* Re: [patch 1/1] ipw2100: remove by-hand function entry/exit debugging
From: Jeff Garzik @ 2005-09-07 1:51 UTC (permalink / raw)
To: akpm; +Cc: pavel, ipw2100-admin, pavel, Linux Kernel, Netdev List
In-Reply-To: <200509062056.j86KuHcL031448@shell0.pdx.osdl.net>
akpm@osdl.org wrote:
> From: Pavel Machek <pavel@ucw.cz>
>
> This removes debug prints from entry/exit of functions. Such level of
> debugging should probably be done by gdb or similar.
>
> Signed-off-by: Pavel Machek <pavel@suse.cz>
> Cc: Jeff Garzik <jgarzik@pobox.com>
> Cc: "James P. Ketrenos" <ipw2100-admin@linux.intel.com>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
NAK. Rationale: maintainer's choice. Pavel doesn't get to choose the
debugger of choice for the driver maintainer.
I do this entry/exit stuff in my net and SATA drivers; printk is my
primary method of debugging.
Jeff
^ permalink raw reply
* [PATCH Linus Git] README.ipw2200 does not contain firmware information.
From: Alejandro Bonilla Beeche @ 2005-09-07 1:48 UTC (permalink / raw)
To: ipw2200-devel, netdev, linux-kernel; +Cc: jketreno, Linus Torvalds
[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]
Hi,
The kconfig from net/wireless says to look at the README.ipw2200 for
further installation of the firmware file. We have that information unde
INSTALL not under README.ipw2200, still I just added a part that talks
about installing the firmware file. This because README.ipw2200 is
already in the Documentation/networking/.
I'm still spamming everyone cause I have not been told where to send
this directly. :-)
Signed-off-by: Alejandro Bonilla <abonilla@linuxwireless.org>
Pasted and attached.
debian:~/linux-2.6# diff -usr Documentation/networking/README.ipw2200~
Documentation/networking/README.ipw2200
--- Documentation/networking/README.ipw2200~ 2005-09-06
19:33:24.000000000 -0600
+++ Documentation/networking/README.ipw2200 2005-09-06
19:33:24.000000000 -0600
@@ -27,7 +27,8 @@
1.4. Sysfs Helper Files
2. About the Version Numbers
3. Support
-4. License
+4. Firmware installation
+5. License
1. Introduction
@@ -272,7 +273,18 @@
http://ipw2200.sf.net/
-4. License
+4. Firmware installation
+----------------------------------------------
+
+The driver requires a firmware image, download it and extract the files
+under /lib/firmware
+
+The firmware can be downloaded from the following URL:
+
+ http://ipw2200.sf.net/
+
+
+5. License
-----------------------------------------------
Copyright(c) 2003 - 2005 Intel Corporation. All rights reserved.
[-- Attachment #2: IPW2200-README-git.patch --]
[-- Type: text/x-patch, Size: 790 bytes --]
--- Documentation/networking/README.ipw2200~ 2005-09-06 19:33:24.000000000 -0600
+++ Documentation/networking/README.ipw2200 2005-09-06 19:33:24.000000000 -0600
@@ -27,7 +27,8 @@
1.4. Sysfs Helper Files
2. About the Version Numbers
3. Support
-4. License
+4. Firmware installation
+5. License
1. Introduction
@@ -272,7 +273,18 @@
http://ipw2200.sf.net/
-4. License
+4. Firmware installation
+----------------------------------------------
+
+The driver requires a firmware image, download it and extract the files
+under /lib/firmware
+
+The firmware can be downloaded from the following URL:
+
+ http://ipw2200.sf.net/
+
+
+5. License
-----------------------------------------------
Copyright(c) 2003 - 2005 Intel Corporation. All rights reserved.
^ permalink raw reply
* Re: Route cache performance
From: Alexey Kuznetsov @ 2005-09-07 1:19 UTC (permalink / raw)
To: Simon Kirby; +Cc: Robert Olsson, Alexey Kuznetsov, Eric Dumazet, netdev
In-Reply-To: <20050906235700.GA31820@netnation.com>
Hello!
On Tue, Sep 06, 2005 at 04:57:00PM -0700, Simon Kirby wrote:
> On Fri, Aug 26, 2005 at 09:49:11PM +0200, Robert Olsson wrote:
...
> > I think Simon uses UP and it could be idea to check if the RCU deferred
> > deletion causes the problem.
..
> Yes, this is the difference. With the patch applied (ajust directly
> freeing the dst_entry), everything balances easily, there are no
> overflows, and the result of rt_may_expire() looks very reasonable.
> (Yay!)
>
> So, this seems to be the culprit. Is NAPI supposed to allow the
> queued bh to run or should we just not be queuing this?
It is supposed to work. :-) The problem is like an unkillable zombie.
Robert, have you seen this pehonomenon already? Did you mean that SMP works
or that it never works (but this patch is valid only for UP)? Did it
become worse after 2.6.9?
Alexey
^ permalink raw reply
* RE: Fw: [Bugme-new] [Bug 5194] New: IPSec related OOps in 2.6.13
From: Matt LaPlante @ 2005-09-07 0:06 UTC (permalink / raw)
To: 'Herbert Xu', 'Andrew Morton'
Cc: netdev, olel, bugme-daemon, 'Linux Kernel Mailing List',
'David S. Miller'
In-Reply-To: <20050906122029.GB4594@gondor.apana.org.au>
Patch worked like a charm here, no more kernel panics! Excellent work, many
thanks for the quick fix...more people should have such a work ethic.
Cheers,
Matt
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> owner@vger.kernel.org] On Behalf Of Herbert Xu
> Sent: Tuesday, September 06, 2005 8:20 AM
> To: Andrew Morton
> Cc: netdev@vger.kernel.org; olel@ans.pl; bugme-daemon@kernel-
> bugs.osdl.org; Matt LaPlante; Linux Kernel Mailing List; David S. Miller
> Subject: Re: Fw: [Bugme-new] [Bug 5194] New: IPSec related OOps in 2.6.13
>
> On Tue, Sep 06, 2005 at 04:08:56AM -0700, Andrew Morton wrote:
> >
> > Problem Description:
> >
> > Oops: 0000 [#1]
> > PREEMPT
> > Modules linked in:
> > CPU: 0
> > EIP: 0060:[<c01f562c>] Not tainted VLI
> > EFLAGS: 00010216 (2.6.13)
> > EIP is at sha1_update+0x7c/0x160
>
> Thanks for the report. Matt LaPlante had exactly the same problem
> a couple of days ago. I've tracked down now to my broken crypto
> cipher wrapper functions which will step over a page boundary if
> it's not aligned correctly.
>
>
> [CRYPTO] Fix boundary check in standard multi-block cipher processors
>
> The boundary check in the standard multi-block cipher processors are
> broken when nbytes is not a multiple of bsize. In those cases it will
> always process an extra block.
>
> This patch corrects the check so that it processes at most nbytes of data.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Route cache performance
From: Simon Kirby @ 2005-09-06 23:57 UTC (permalink / raw)
To: Robert Olsson; +Cc: Alexey Kuznetsov, Eric Dumazet, netdev
In-Reply-To: <17167.29239.469711.847951@robur.slu.se>
On Fri, Aug 26, 2005 at 09:49:11PM +0200, Robert Olsson wrote:
> Hello!
>
> This thread seems familar :)
>
> I think Simon uses UP and it could be idea to check if the RCU deferred
> deletion causes the problem.
>...
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -485,7 +485,11 @@ static struct file_operations rt_cpu_seq
> static __inline__ void rt_free(struct rtable *rt)
> {
> multipath_remove(rt);
> +#ifdef CONFIG_SMP
> call_rcu_bh(&rt->u.dst.rcu_head, dst_rcu_free);
> +#else
> + dst_free((struct dst_entry *)rt);
> +#endif
> }
>
> static __inline__ void rt_drop(struct rtable *rt)
Woot!
Yes, this is the difference. With the patch applied (ajust directly
freeing the dst_entry), everything balances easily, there are no
overflows, and the result of rt_may_expire() looks very reasonable.
(Yay!)
So, this seems to be the culprit. Is NAPI supposed to allow the
queued bh to run or should we just not be queuing this?
Simon-
^ permalink raw reply
* Re: proto_unregister sleeps while atomic
From: Patrick McHardy @ 2005-09-06 23:42 UTC (permalink / raw)
To: David S. Miller; +Cc: daniele, linux-kernel, netdev
In-Reply-To: <20050906.160728.25203864.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 740 bytes --]
David S. Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Wed, 07 Sep 2005 01:02:01 +0200
>
>
>>You're right, good catch. This patch fixes it by moving the lock
>>down to the list-operation which it is supposed to protect.
>
>
> I think we need to unlink from the list first if you're
> going to do it this way. Otherwise someone can find the
> protocol via lookup, and then bogusly try to use the SLAB
> cache we're freeing up.
>
> Or does something else prevent this?
The only other user of proto_list besides proto_register, which
doesn't care, are the seqfs functions. They use the slab pointer,
but in a harmless way:
proto->slab == NULL ? "no" : "yes",
Anyway, I've moved it up to the top.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1168 bytes --]
[NET]: proto_unregister: fix sleeping while atomic
proto_unregister holds a lock while calling kmem_cache_destroy, which can
sleep.
Noticed by Daniele Orlandi <daniele@orlandi.com>.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit d68b08edb26dfb58d18ab6c555d011572f9115a6
tree 1d14cf91ca5db6878b6af3953f85a34a6fe12a91
parent 591bd554f58b7d363167760a606d2a84696772da
author Patrick McHardy <kaber@trash.net> Wed, 07 Sep 2005 01:35:19 +0200
committer Patrick McHardy <kaber@trash.net> Wed, 07 Sep 2005 01:35:19 +0200
net/core/sock.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1529,6 +1529,8 @@ EXPORT_SYMBOL(proto_register);
void proto_unregister(struct proto *prot)
{
write_lock(&proto_list_lock);
+ list_del(&prot->node);
+ write_unlock(&proto_list_lock);
if (prot->slab != NULL) {
kmem_cache_destroy(prot->slab);
@@ -1550,9 +1552,6 @@ void proto_unregister(struct proto *prot
kfree(name);
prot->twsk_slab = NULL;
}
-
- list_del(&prot->node);
- write_unlock(&proto_list_lock);
}
EXPORT_SYMBOL(proto_unregister);
^ permalink raw reply
* Re: [patch 2.6.13 2/2] 3c59x: add option for using memory-mapped PCI I/O resources
From: Andrew Morton @ 2005-09-06 23:13 UTC (permalink / raw)
To: John W. Linville; +Cc: hch, linux-kernel, netdev, jgarzik
In-Reply-To: <20050906225744.GB26003@tuxdriver.com>
"John W. Linville" <linville@tuxdriver.com> wrote:
>
> On Tue, Sep 06, 2005 at 03:15:46PM -0700, Andrew Morton wrote:
> > "John W. Linville" <linville@tuxdriver.com> wrote:
> > >
> > > I fully intend to have have a flag in the private data set based on
> > > the PCI ID when I accumulate some data on which devices support this
> > > and which don't. So far I've only got a short list... Do you think
> > > such a flag should be based on which ones work, or which ones break?
> >
> > The ones which are known to work.
> >
> > Bear in mind that this is an old, messy and relatively stable driver which
> > handles a huge number of different NICs. Caution is the rule here.
>
> I definitely agree. That is another part of why I defaulted to "use_mmio=0".
>
> I'll post PCI ID based patches as I determine supported cards.
>
What I'd suggest you do is to look at enabling the feature for, say,
IS_CYCLONE and IS_TORNADO NICs. Do that as a separate -mm patch, make sure
that an explicit `use_mmio=0' will still turn it off.
So in the style of that driver, something like:
static int use_mmio[MAX_UNITS] = { [ 0 .. MAX_UNITS-1 ] = -1, };
Then:
if (module parm given)
use_mmio[unit] = 1 or 0
...
/* Determine the default if the user didn't override us */
if (use_mmio[unit] == -1 && (IS_CYCLONE || IS_TORNADO))
use_mmio[unit] = 1;
priv->use_mmio = use_mmio[unit]; (maybe)
....
if (priv->use_mmio == 1)
do mmio stuff
There's a bit to be done here, so I'll drop your initial set of patches.
btw, Donald Becker's 3c59x.c has done mmio for ages. Suggest you take a
look in there. http://www.scyld.com/vortex.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox