* Re: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
From: Andi Kleen @ 2005-07-12 21:26 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: netdev
In-Reply-To: <20050712210704.GA11622@infradead.org>
Christoph Hellwig <hch@infradead.org> writes:
>
> And that doesn't help either, CONFIG_IA64_SGI_SN2 isn't used in practice,
> any production Altix with 26 kernels runs CONFIG_IA64_GENERIC kernels.
At least SLES9/ia64 has a SN2 kernel.
-Andi
^ permalink raw reply
* RE: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
From: Ravinandan Arakali @ 2005-07-12 21:54 UTC (permalink / raw)
To: 'David S. Miller'
Cc: hch, raghavendra.koushik, jgarzik, netdev, leonid.grossman,
rapuru.sriram
In-Reply-To: <20050712.140411.41107257.davem@davemloft.net>
Okay, got it. Will submit patch on Kconfig file after the macro
for SGI platforms is confirmed.
Ravi
-----Original Message-----
From: David S. Miller [mailto:davem@davemloft.net]
Sent: Tuesday, July 12, 2005 2:04 PM
To: ravinandan.arakali@neterion.com
Cc: hch@infradead.org; raghavendra.koushik@neterion.com;
jgarzik@pobox.com; netdev@oss.sgi.com; leonid.grossman@neterion.com;
rapuru.sriram@neterion.com
Subject: Re: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
From: "Ravinandan Arakali" <ravinandan.arakali@neterion.com>
Subject: RE: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
Date: Tue, 12 Jul 2005 14:00:52 -0700
> The two-buffer mode was added as a configurable option
> to Kconfig file several months ago. Hence the macro
> is CONFIG_2BUFF_MODE.
We're saying that you should choose CONFIG_2BUFF_MODE, when
CONFIG_IA64_SGI_SN2 is set, inside the Kconfig file using the
"default" Kconfig directive.
You should never change the setting of CONFIG_* macros in C source.
^ permalink raw reply
* RE: New Platform Test position thoughts...
From: Brown, Aaron F @ 2005-07-13 0:11 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 791 bytes --]
Please ignore this message thread. It was only intended as a message to
my direct work colleagues and I have absolutely no idea how I managed to
include the netdev@oss.sgi.com list. I guess my only condolence is that
I managed to spam this out to the old list address and not the current
one ;-)
Head hung down in embarrassment...
-Aaron Brown
________________________________
From: Brown, Aaron F
Sent: Tuesday, July 12, 2005 3:53 PM
To: Frost, Stephen C; Francis, Joey L; Overdorf, Sam; Glick, Kevin;
Tantilov, Emil S
Cc: Perkins, John S; netdev@oss.sgi.com
Subject: New Platform Test position thoughts...
Hi all,
I'm working on defining this new platform test position for the Unix
group that I volunteered for.
<snip>
[-- Attachment #2: Type: text/html, Size: 4799 bytes --]
^ permalink raw reply
* Re: [PATCH] forcedeth: Additional ethtool support
From: David Hollis @ 2005-07-13 12:39 UTC (permalink / raw)
To: Manfred Spraul; +Cc: Jeff Garzik, Netdev, renaud.lienhart
In-Reply-To: <42D101EC.6000608@colorfullife.com>
[-- Attachment #1: Type: text/plain, Size: 914 bytes --]
On Sun, 2005-07-10 at 13:09 +0200, Manfred Spraul wrote:
> +
> +static int nv_nway_reset(struct net_device *dev)
> +{
> + struct fe_priv *np = get_nvpriv(dev);
> + int ret;
> +
> + spin_lock_irq(&np->lock);
> + if (np->autoneg) {
> + int bmcr;
> +
> + bmcr = mii_rw(dev, np->phyaddr, MII_BMCR, MII_READ);
> + bmcr |= (BMCR_ANENABLE | BMCR_ANRESTART);
> + mii_rw(dev, np->phyaddr, MII_BMCR, bmcr);
> +
> + ret = 0;
> + } else {
> + ret = -EINVAL;
> + }
> + spin_unlock_irq(&np->lock);
> +
> + return ret;
> +}
> +
This seems almost completely generic-ified (except for the np->autoneg
part) and should be able to operate on any NIC. Do you think there'd be
some way to whip up a stock ethtool_nway_reset() type of function that
drivers can use if they don't need to do anything fancy? Would help
save a lot of code duplication.
--
David Hollis <dhollis@davehollis.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* re: your email message
From: Lyris ListManager @ 2005-07-13 13:34 UTC (permalink / raw)
To: netdev
The following lines in your email message did not appear to be
Lyris ListManager commands and were skipped:
> This is a multi-part message in MIME format.
> ------=_NextPart_000_0006_CA98A22F.3D416EC6
> Content-Type: text/plain;
> charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Message could not be delivered
> ------=_NextPart_000_0006_CA98A22F.3D416EC6
> Content-Type: plain/text;
> name="DELETED0.TXT"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
> filename="DELETED0.TXT"
> RmlsZSBhdHRhY2htZW50OiBsZ2t4YnhuLnppcA0KDQpUaGUgZmlsZSBhdHRhY2hlZCB0byB0
> aGlzIGVtYWlsIHdhcyByZW1vdmVkIGJlY2F1c2UgZmlsZXMgb2YgdGhpcyB0eXBlIGFyZSBu
> b3QgYWNjZXB0ZWQgZm9yIGRlbGl2ZXJ5IGJ5IHlvdXIgZW1haWwgZ2F0ZXdheS4NCg==
> ------=_NextPart_000_0006_CA98A22F.3D416EC6--
This email message is simply a notification of how Lyris ListManager understood
your email message. If you want to resend your commands, send
them to lyris@list.pta.org
^ permalink raw reply
* [05/11] SMP fix for 6pack driver
From: Greg KH @ 2005-07-13 18:43 UTC (permalink / raw)
To: ralf, netdev, jgarzik
Cc: linux-kernel, stable, Justin Forbes, Zwane Mwaikambo,
Theodore Ts'o, Randy.Dunlap, Chuck Wolber, torvalds, akpm,
alan
In-Reply-To: <20050713184130.GA9330@kroah.com>
-stable review patch. If anyone has any objections, please let us know.
------------------
Drivers really only work well in SMP if they actually can be selected.
This is a leftover from the time when the 6pack drive only used to be
a bitrotten variant of the slip driver.
Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/net/hamradio/Kconfig | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.12.2.orig/drivers/net/hamradio/Kconfig 2005-06-17 12:48:29.000000000 -0700
+++ linux-2.6.12.2/drivers/net/hamradio/Kconfig 2005-07-13 10:56:32.000000000 -0700
@@ -17,7 +17,7 @@
config 6PACK
tristate "Serial port 6PACK driver"
- depends on AX25 && BROKEN_ON_SMP
+ depends on AX25
---help---
6pack is a transmission protocol for the data exchange between your
PC and your TNC (the Terminal Node Controller acts as a kind of
^ permalink raw reply
* Undelivered mail
From: owner-LISTSERV @ 2005-07-13 19:18 UTC (permalink / raw)
To: netdev
--> Error description:
Error-For: K12NEWSLETTERS@LISTSERV.CLASSROOM.COM
Error-Code: 3
Error-Text: No such list.
Error-End: One error reported.
^ permalink raw reply
* Re: [05/11] SMP fix for 6pack driver
From: Francois Romieu @ 2005-07-13 22:01 UTC (permalink / raw)
To: Greg KH
Cc: ralf, netdev, jgarzik, linux-kernel, stable, Justin Forbes,
Zwane Mwaikambo, Theodore Ts'o, Randy.Dunlap, Chuck Wolber,
torvalds, akpm, alan
In-Reply-To: <20050713184331.GG9330@kroah.com>
Greg KH <gregkh@suse.de> :
> -stable review patch. If anyone has any objections, please let us know.
>
> ------------------
>
>
> Drivers really only work well in SMP if they actually can be selected.
> This is a leftover from the time when the 6pack drive only used to be
> a bitrotten variant of the slip driver.
Is the guideline above from 28/04/2005 obsoleted ?
- It must fix a problem that causes a build error (but not for things
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some "oh, that's not good" issue. In short,
something critical.
--
Ueimor
^ permalink raw reply
* Re: [stable] Re: [05/11] SMP fix for 6pack driver
From: Greg KH @ 2005-07-13 22:13 UTC (permalink / raw)
To: Francois Romieu
Cc: Greg KH, torvalds, akpm, Theodore Ts'o, Zwane Mwaikambo,
netdev, Justin Forbes, linux-kernel, ralf, Randy.Dunlap,
Chuck Wolber, jgarzik, stable, alan
In-Reply-To: <20050713220123.GA3292@electric-eye.fr.zoreil.com>
On Thu, Jul 14, 2005 at 12:01:23AM +0200, Francois Romieu wrote:
> Greg KH <gregkh@suse.de> :
> > -stable review patch. If anyone has any objections, please let us know.
> >
> > ------------------
> >
> >
> > Drivers really only work well in SMP if they actually can be selected.
> > This is a leftover from the time when the 6pack drive only used to be
> > a bitrotten variant of the slip driver.
>
> Is the guideline above from 28/04/2005 obsoleted ?
>
> - It must fix a problem that causes a build error (but not for things
> marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
> security issue, or some "oh, that's not good" issue. In short,
> something critical.
It lets the driver be built, when it previously could not be, unless the
user used a config option that almost no one does...
That's pretty critical if you ask me.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] [SCTP] Fix potential null pointer dereference while handling an icmp error
From: Sridhar Samudrala @ 2005-07-14 0:54 UTC (permalink / raw)
To: davem; +Cc: lksctp-developers, netdev, cdeboys
Dave,
Please apply the following patch which fixes a potential null pointer
dereference while handling an icmp error in sctp_icmp_* routines. These
routines assume that we are passing a valid asoc.
Reported by Charles-Henri de Boysson <cdeboys@stevens.edu>
Thanks
Sridhar
---------------------------------------------------------------------
[SCTP] Fix potential null pointer dereference while handling an icmp
error
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -167,15 +167,12 @@ void sctp_unhash_established(struct sctp
void sctp_hash_endpoint(struct sctp_endpoint *);
void sctp_unhash_endpoint(struct sctp_endpoint *);
struct sock *sctp_err_lookup(int family, struct sk_buff *,
- struct sctphdr *, struct sctp_endpoint **,
- struct sctp_association **,
+ struct sctphdr *, struct sctp_association **,
struct sctp_transport **);
-void sctp_err_finish(struct sock *, struct sctp_endpoint *,
- struct sctp_association *);
+void sctp_err_finish(struct sock *, struct sctp_association *);
void sctp_icmp_frag_needed(struct sock *, struct sctp_association *,
struct sctp_transport *t, __u32 pmtu);
void sctp_icmp_proto_unreachable(struct sock *sk,
- struct sctp_endpoint *ep,
struct sctp_association *asoc,
struct sctp_transport *t);
diff --git a/net/sctp/input.c b/net/sctp/input.c
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -351,7 +351,6 @@ void sctp_icmp_frag_needed(struct sock *
*
*/
void sctp_icmp_proto_unreachable(struct sock *sk,
- struct sctp_endpoint *ep,
struct sctp_association *asoc,
struct sctp_transport *t)
{
@@ -367,7 +366,6 @@ void sctp_icmp_proto_unreachable(struct
/* Common lookup code for icmp/icmpv6 error handler. */
struct sock *sctp_err_lookup(int family, struct sk_buff *skb,
struct sctphdr *sctphdr,
- struct sctp_endpoint **epp,
struct sctp_association **app,
struct sctp_transport **tpp)
{
@@ -375,11 +373,10 @@ struct sock *sctp_err_lookup(int family,
union sctp_addr daddr;
struct sctp_af *af;
struct sock *sk = NULL;
- struct sctp_endpoint *ep = NULL;
struct sctp_association *asoc = NULL;
struct sctp_transport *transport = NULL;
- *app = NULL; *epp = NULL; *tpp = NULL;
+ *app = NULL; *tpp = NULL;
af = sctp_get_af_specific(family);
if (unlikely(!af)) {
@@ -394,26 +391,15 @@ struct sock *sctp_err_lookup(int family,
* packet.
*/
asoc = __sctp_lookup_association(&saddr, &daddr, &transport);
- if (!asoc) {
- /* If there is no matching association, see if it matches any
- * endpoint. This may happen for an ICMP error generated in
- * response to an INIT_ACK.
- */
- ep = __sctp_rcv_lookup_endpoint(&daddr);
- if (!ep) {
- return NULL;
- }
- }
+ if (!asoc)
+ return NULL;
- if (asoc) {
- sk = asoc->base.sk;
+ sk = asoc->base.sk;
- if (ntohl(sctphdr->vtag) != asoc->c.peer_vtag) {
- ICMP_INC_STATS_BH(ICMP_MIB_INERRORS);
- goto out;
- }
- } else
- sk = ep->base.sk;
+ if (ntohl(sctphdr->vtag) != asoc->c.peer_vtag) {
+ ICMP_INC_STATS_BH(ICMP_MIB_INERRORS);
+ goto out;
+ }
sctp_bh_lock_sock(sk);
@@ -423,7 +409,6 @@ struct sock *sctp_err_lookup(int family,
if (sock_owned_by_user(sk))
NET_INC_STATS_BH(LINUX_MIB_LOCKDROPPEDICMPS);
- *epp = ep;
*app = asoc;
*tpp = transport;
return sk;
@@ -432,21 +417,16 @@ out:
sock_put(sk);
if (asoc)
sctp_association_put(asoc);
- if (ep)
- sctp_endpoint_put(ep);
return NULL;
}
/* Common cleanup code for icmp/icmpv6 error handler. */
-void sctp_err_finish(struct sock *sk, struct sctp_endpoint *ep,
- struct sctp_association *asoc)
+void sctp_err_finish(struct sock *sk, struct sctp_association *asoc)
{
sctp_bh_unlock_sock(sk);
sock_put(sk);
if (asoc)
sctp_association_put(asoc);
- if (ep)
- sctp_endpoint_put(ep);
}
/*
@@ -471,7 +451,6 @@ void sctp_v4_err(struct sk_buff *skb, __
int type = skb->h.icmph->type;
int code = skb->h.icmph->code;
struct sock *sk;
- struct sctp_endpoint *ep;
struct sctp_association *asoc;
struct sctp_transport *transport;
struct inet_sock *inet;
@@ -488,7 +467,7 @@ void sctp_v4_err(struct sk_buff *skb, __
savesctp = skb->h.raw;
skb->nh.iph = iph;
skb->h.raw = (char *)sh;
- sk = sctp_err_lookup(AF_INET, skb, sh, &ep, &asoc, &transport);
+ sk = sctp_err_lookup(AF_INET, skb, sh, &asoc, &transport);
/* Put back, the original pointers. */
skb->nh.raw = saveip;
skb->h.raw = savesctp;
@@ -515,7 +494,7 @@ void sctp_v4_err(struct sk_buff *skb, __
}
else {
if (ICMP_PROT_UNREACH == code) {
- sctp_icmp_proto_unreachable(sk, ep, asoc,
+ sctp_icmp_proto_unreachable(sk, asoc,
transport);
goto out_unlock;
}
@@ -544,7 +523,7 @@ void sctp_v4_err(struct sk_buff *skb, __
}
out_unlock:
- sctp_err_finish(sk, ep, asoc);
+ sctp_err_finish(sk, asoc);
}
/*
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -91,7 +91,6 @@ SCTP_STATIC void sctp_v6_err(struct sk_b
struct ipv6hdr *iph = (struct ipv6hdr *)skb->data;
struct sctphdr *sh = (struct sctphdr *)(skb->data + offset);
struct sock *sk;
- struct sctp_endpoint *ep;
struct sctp_association *asoc;
struct sctp_transport *transport;
struct ipv6_pinfo *np;
@@ -105,7 +104,7 @@ SCTP_STATIC void sctp_v6_err(struct sk_b
savesctp = skb->h.raw;
skb->nh.ipv6h = iph;
skb->h.raw = (char *)sh;
- sk = sctp_err_lookup(AF_INET6, skb, sh, &ep, &asoc, &transport);
+ sk = sctp_err_lookup(AF_INET6, skb, sh, &asoc, &transport);
/* Put back, the original pointers. */
skb->nh.raw = saveip;
skb->h.raw = savesctp;
@@ -124,7 +123,7 @@ SCTP_STATIC void sctp_v6_err(struct sk_b
goto out_unlock;
case ICMPV6_PARAMPROB:
if (ICMPV6_UNK_NEXTHDR == code) {
- sctp_icmp_proto_unreachable(sk, ep, asoc, transport);
+ sctp_icmp_proto_unreachable(sk, asoc, transport);
goto out_unlock;
}
break;
@@ -142,7 +141,7 @@ SCTP_STATIC void sctp_v6_err(struct sk_b
}
out_unlock:
- sctp_err_finish(sk, ep, asoc);
+ sctp_err_finish(sk, asoc);
out:
if (likely(idev != NULL))
in6_dev_put(idev);
^ permalink raw reply
* Re: eepro100/e100 broken in 2.6.13-rc3
From: Jesse Brandeburg @ 2005-07-14 6:28 UTC (permalink / raw)
To: Mikhail Kshevetskiy; +Cc: linux-kernel, netdev
In-Reply-To: <20050714034954.52947263@laska>
On 7/13/05, Mikhail Kshevetskiy <kl@laska.dorms.spbu.ru> wrote:
> symptom
> =======
> modprobe e100
> ifconfig eth0 <ip> netmask <netmask>
>
> result:
> =======
> SIOCADDRT: Network is unreachable
>
> There were no such error in 2.6.13-rc2
odd, both e100 and eepro100 are broken? This might indicate something
wierd with the pci layer. Don't know what might cause the Network is
unreachable...
please send lspci -vvv of the e100 device in question and any output from dmesg
added netdev in case someone has an idea there.
^ permalink raw reply
* Re: eepro100/e100 broken in 2.6.13-rc3
From: Grant Coady @ 2005-07-14 7:26 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: Mikhail Kshevetskiy, linux-kernel, netdev
In-Reply-To: <4807377b05071323286963bf3a@mail.gmail.com>
On Wed, 13 Jul 2005 23:28:15 -0700, Jesse Brandeburg <jesse.brandeburg@gmail.com> wrote:
>On 7/13/05, Mikhail Kshevetskiy <kl@laska.dorms.spbu.ru> wrote:
>> symptom
>> =======
>> modprobe e100
>> ifconfig eth0 <ip> netmask <netmask>
>>
>> result:
>> =======
>> SIOCADDRT: Network is unreachable
>>
>> There were no such error in 2.6.13-rc2
>
peetoo:~$ uname -r
2.6.13-rc3-a
peetoo:~$ lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
00:0d.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08)
00:0e.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08)
00:0f.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 22)
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage IIC AGP (rev 7a)
peetoo:~$ lsmod
Module Size Used by
adm9240 16056 0
i2c_sensor 2816 1 adm9240
radio_aztech 4316 0
nfsd 92296 5
exportfs 4576 1 nfsd
tulip 42496 0
e100 30656 0
usb_storage 30276 0
peetoo:~$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:90:27:58:EC:6F
inet addr:192.168.1.24 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3454075 errors:0 dropped:0 overruns:0 frame:0
TX packets:1759340 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:826224238 (787.9 Mb) TX bytes:99642515 (95.0 Mb)
eth1 Link encap:Ethernet HWaddr 00:04:AC:F3:4B:84
inet addr:192.168.3.24 Bcast:192.168.3.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth2 Link encap:Ethernet HWaddr 00:00:E8:4A:A0:C8
inet addr:192.168.4.24 Bcast:192.168.4.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:5 Base address:0x8000
Not broken here :)
--Grant.
^ permalink raw reply
* Re: Re-routing packets via netfilter (ip_rt_bug)
From: Ric Wheeler @ 2005-07-14 12:27 UTC (permalink / raw)
To: Patrick McHardy, Herbert Xu, Jozsef Kadlecsik
Cc: Yair Itzhaki, netdev, netfilter-devel, linux-kernel,
Chitrapu, Kishore, Mellors, Andrew
In-Reply-To: <4151C0F9B9C25C47B3328922A6297A3286CFB8@post.arx.com>
Patrick, Hebert,
This issues stills seems to be in the latest trees - is this patch or a
variation on it still bumping around?
Thanks!
Yair Itzhaki wrote:
>Can anyone propose a patch that I can start checking?
>
>I have come up with the following:
>
>--- net/core/netfilter.c.orig 2005-04-18 21:55:30.000000000 +0300
>+++ net/core/netfilter.c 2005-05-02 17:35:20.000000000 +0300
>@@ -622,9 +622,10 @@
> /* some non-standard hacks like ipt_REJECT.c:send_reset() can cause
> * packets with foreign saddr to appear on the NF_IP_LOCAL_OUT hook.
> */
>- if (inet_addr_type(iph->saddr) == RTN_LOCAL) {
>+ if ((inet_addr_type(iph->saddr) == RTN_LOCAL) ||
>+ (inet_addr_type(iph->daddr) == RTN_LOCAL)) {
> fl.nl_u.ip4_u.daddr = iph->daddr;
>- fl.nl_u.ip4_u.saddr = iph->saddr;
>+ fl.nl_u.ip4_u.saddr = 0;
> fl.nl_u.ip4_u.tos = RT_TOS(iph->tos);
> fl.oif = (*pskb)->sk ? (*pskb)->sk->sk_bound_dev_if : 0;
> #ifdef CONFIG_IP_ROUTE_FWMARK
>
>Please advise,
>Yair
>
>
>
>
>>-----Original Message-----
>>From: Patrick McHardy [mailto:kaber@trash.net]
>>Sent: Wednesday, April 27, 2005 14:05
>>To: Herbert Xu
>>Cc: Jozsef Kadlecsik; netdev@oss.sgi.com;
>>netfilter-devel@lists.netfilter.org; Yair Itzhaki;
>>linux-kernel@vger.kernel.org
>>Subject: Re: Re-routing packets via netfilter (ip_rt_bug)
>>
>>
>>Herbert Xu wrote:
>>
>>
>>>Here is another reason why these packets should go through FORWARD.
>>>They were generated in response to packets in INPUT/FORWARD/OUTPUT.
>>>The original packet has not undergone SNAT in any of these cases.
>>>
>>>However, if we feed the response packet through LOCAL_OUT it will
>>>be subject to DNAT. This creates a NAT asymmetry and we may end
>>>up with the wrong destination address.
>>>
>>>By pushing it through FORWARD it will only undergo SNAT which is
>>>correct since the original packet would have undergone DNAT.
>>>
>>>
>>This is only a problem since the recent NAT changes, but I agree
>>that we should fix it by moving these packets to FORWARD.
>>
>>Regards
>>Patrick
>>
>>
>>
>
>
>
^ permalink raw reply
* Re: eepro100/e100 broken in 2.6.13-rc3
From: Horst von Brand @ 2005-07-14 20:07 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: Mikhail Kshevetskiy, linux-kernel, netdev
In-Reply-To: <4807377b05071323286963bf3a@mail.gmail.com>
Jesse Brandeburg <jesse.brandeburg@gmail.com> wrote:
> On 7/13/05, Mikhail Kshevetskiy <kl@laska.dorms.spbu.ru> wrote:
> > symptom
> > =======
> > modprobe e100
> > ifconfig eth0 <ip> netmask <netmask>
> >
> > result:
> > =======
> > SIOCADDRT: Network is unreachable
> >
> > There were no such error in 2.6.13-rc2
> odd, both e100 and eepro100 are broken? This might indicate something
> wierd with the pci layer. Don't know what might cause the Network is
> unreachable...
It works fine here... latest .git from yesterday.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* per-route TCP windows?
From: Mark Hahn @ 2005-07-15 1:09 UTC (permalink / raw)
To: netdev
I was recently fiddling with TCP performance on long-fat links,
and noticed that iproute2 seems to allow one to set a per-route window.
is this implemented in the stack? I gave it one try and it didn't
seem to work, but I admit I haven't delved into the code yet.
we'd like to tune for some 10Gb, 3-6 ms links, mainly to move large files
between our sites. this is not CERN-scale stuff, but being able to configure
large windows on particular routes sounds terribly convenient...
thanks, mark hahn
sharcnet-mcmaster
^ permalink raw reply
* [PATCH] Use time_before in hamradio drivers
From: Ralf Baechle DL5RB @ 2005-07-15 10:16 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-hams, Marcelo Feitoza Parisi, domen
From: Marcelo Feitoza Parisi <marcelo@feitoza.com.br>
Use of time_before() macro, defined at linux/jiffies.h, which deal with
wrapping correctly and are nicer to read.
Signed-off-by: Marcelo Feitoza Parisi <marcelo@feitoza.com.br>
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
baycom_epp.c | 3 ++-
baycom_par.c | 3 ++-
baycom_ser_fdx.c | 3 ++-
baycom_ser_hdx.c | 3 ++-
mkiss.c | 3 ++-
5 files changed, 10 insertions(+), 5 deletions(-)
Index: linux-cvs/drivers/net/hamradio/mkiss.c
===================================================================
--- linux-cvs.orig/drivers/net/hamradio/mkiss.c 2005-07-15 11:11:26.000000000 +0100
+++ linux-cvs/drivers/net/hamradio/mkiss.c 2005-07-15 11:12:40.000000000 +0100
@@ -46,6 +46,7 @@
#include <linux/etherdevice.h>
#include <linux/skbuff.h>
#include <linux/if_arp.h>
+#include <linux/jiffies.h>
#include <net/ax25.h>
@@ -429,7 +430,7 @@
* May be we must check transmitter timeout here ?
* 14 Oct 1994 Dmitry Gorodchanin.
*/
- if (jiffies - dev->trans_start < 20 * HZ) {
+ if (time_before(jiffies, dev->trans_start + 20 * HZ)) {
/* 20 sec timeout not reached */
return 1;
}
Index: linux-cvs/drivers/net/hamradio/baycom_ser_fdx.c
===================================================================
--- linux-cvs.orig/drivers/net/hamradio/baycom_ser_fdx.c 2005-07-15 11:11:26.000000000 +0100
+++ linux-cvs/drivers/net/hamradio/baycom_ser_fdx.c 2005-07-15 11:12:40.000000000 +0100
@@ -79,6 +79,7 @@
#include <asm/io.h>
#include <linux/hdlcdrv.h>
#include <linux/baycom.h>
+#include <linux/jiffies.h>
/* --------------------------------------------------------------------- */
@@ -159,7 +160,7 @@
* measure the interrupt frequency
*/
bc->debug_vals.cur_intcnt++;
- if ((cur_jiffies - bc->debug_vals.last_jiffies) >= HZ) {
+ if (time_after_eq(cur_jiffies, bc->debug_vals.last_jiffies + HZ)) {
bc->debug_vals.last_jiffies = cur_jiffies;
bc->debug_vals.last_intcnt = bc->debug_vals.cur_intcnt;
bc->debug_vals.cur_intcnt = 0;
Index: linux-cvs/drivers/net/hamradio/baycom_ser_hdx.c
===================================================================
--- linux-cvs.orig/drivers/net/hamradio/baycom_ser_hdx.c 2005-07-15 11:11:26.000000000 +0100
+++ linux-cvs/drivers/net/hamradio/baycom_ser_hdx.c 2005-07-15 11:12:40.000000000 +0100
@@ -69,6 +69,7 @@
#include <asm/io.h>
#include <linux/hdlcdrv.h>
#include <linux/baycom.h>
+#include <linux/jiffies.h>
/* --------------------------------------------------------------------- */
@@ -150,7 +151,7 @@
* measure the interrupt frequency
*/
bc->debug_vals.cur_intcnt++;
- if ((cur_jiffies - bc->debug_vals.last_jiffies) >= HZ) {
+ if (time_after_eq(cur_jiffies, bc->debug_vals.last_jiffies + HZ)) {
bc->debug_vals.last_jiffies = cur_jiffies;
bc->debug_vals.last_intcnt = bc->debug_vals.cur_intcnt;
bc->debug_vals.cur_intcnt = 0;
Index: linux-cvs/drivers/net/hamradio/baycom_epp.c
===================================================================
--- linux-cvs.orig/drivers/net/hamradio/baycom_epp.c 2005-07-15 11:11:26.000000000 +0100
+++ linux-cvs/drivers/net/hamradio/baycom_epp.c 2005-07-15 11:12:40.000000000 +0100
@@ -54,6 +54,7 @@
#include <linux/kmod.h>
#include <linux/hdlcdrv.h>
#include <linux/baycom.h>
+#include <linux/jiffies.h>
#if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE)
/* prototypes for ax25_encapsulate and ax25_rebuild_header */
#include <net/ax25.h>
@@ -287,7 +288,7 @@
* measure the interrupt frequency
*/
bc->debug_vals.cur_intcnt++;
- if ((cur_jiffies - bc->debug_vals.last_jiffies) >= HZ) {
+ if (time_after_eq(cur_jiffies, bc->debug_vals.last_jiffies + HZ)) {
bc->debug_vals.last_jiffies = cur_jiffies;
bc->debug_vals.last_intcnt = bc->debug_vals.cur_intcnt;
bc->debug_vals.cur_intcnt = 0;
Index: linux-cvs/drivers/net/hamradio/baycom_par.c
===================================================================
--- linux-cvs.orig/drivers/net/hamradio/baycom_par.c 2005-07-15 11:11:26.000000000 +0100
+++ linux-cvs/drivers/net/hamradio/baycom_par.c 2005-07-15 11:12:40.000000000 +0100
@@ -84,6 +84,7 @@
#include <linux/baycom.h>
#include <linux/parport.h>
#include <linux/bitops.h>
+#include <linux/jiffies.h>
#include <asm/bug.h>
#include <asm/system.h>
@@ -165,7 +166,7 @@
* measure the interrupt frequency
*/
bc->debug_vals.cur_intcnt++;
- if ((cur_jiffies - bc->debug_vals.last_jiffies) >= HZ) {
+ if (time_after_eq(cur_jiffies, bc->debug_vals.last_jiffies + HZ)) {
bc->debug_vals.last_jiffies = cur_jiffies;
bc->debug_vals.last_intcnt = bc->debug_vals.cur_intcnt;
bc->debug_vals.cur_intcnt = 0;
^ permalink raw reply
* Re: per-route TCP windows?
From: David S. Miller @ 2005-07-15 14:28 UTC (permalink / raw)
To: hahn; +Cc: netdev
In-Reply-To: <Pine.LNX.4.44.0507142101310.16602-100000@coffee.psychology.mcmaster.ca>
From: Mark Hahn <hahn@physics.mcmaster.ca>
Date: Thu, 14 Jul 2005 21:09:57 -0400 (EDT)
> we'd like to tune for some 10Gb, 3-6 ms links, mainly to move large files
> between our sites. this is not CERN-scale stuff, but being able to configure
> large windows on particular routes sounds terribly convenient...
You can set the window, but you must lock the setting.
^ permalink raw reply
* Re: [stable] Re: [05/11] SMP fix for 6pack driver
From: Adrian Bunk @ 2005-07-15 19:35 UTC (permalink / raw)
To: Greg KH
Cc: Francois Romieu, Greg KH, torvalds, akpm, Theodore Ts'o,
Zwane Mwaikambo, netdev, Justin Forbes, linux-kernel, ralf,
Randy.Dunlap, Chuck Wolber, jgarzik, stable, alan
In-Reply-To: <20050713221311.GA30039@kroah.com>
On Wed, Jul 13, 2005 at 03:13:11PM -0700, Greg KH wrote:
> On Thu, Jul 14, 2005 at 12:01:23AM +0200, Francois Romieu wrote:
> > Greg KH <gregkh@suse.de> :
> > > -stable review patch. If anyone has any objections, please let us know.
> > >
> > > ------------------
> > >
> > >
> > > Drivers really only work well in SMP if they actually can be selected.
> > > This is a leftover from the time when the 6pack drive only used to be
> > > a bitrotten variant of the slip driver.
> >
> > Is the guideline above from 28/04/2005 obsoleted ?
> >
> > - It must fix a problem that causes a build error (but not for things
> > marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
> > security issue, or some "oh, that's not good" issue. In short,
> > something critical.
>
> It lets the driver be built, when it previously could not be, unless the
> user used a config option that almost no one does...
>
> That's pretty critical if you ask me.
I do agree with Francois regarding this issue:
AFAIR, there has been not one 2.6 kernel where this driver was available
for SMP kernels. It's therefore untested which problems might arise with
this driver on SMP systems. I'm not arguing against including this
driver in 2.6.13, but 2.6.12.3 isn't the right place.
What surprises me most is that you accepted this patch is neither in
2.6.13-rc3 nor in 2.6.13-rc3-mm1. There seems to be either an
(IMHO unfortunate) change in your policy of what patches to accept,
or there's a serious problem in your patch review process.
> thanks,
>
> greg k-h
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* [2.6 patch] fix IP_FIB_HASH kconfig warning
From: Adrian Bunk @ 2005-07-15 21:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: Roman Zippel, netdev, linux-kernel
This patch fixes the following kconfig warning:
net/ipv4/Kconfig:92:warning: defaults for choice values not supported
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 9 Jul 2005
--- linux-2.6.13-rc2-mm1-modular/net/ipv4/Kconfig.old 2005-07-08 23:55:31.000000000 +0200
+++ linux-2.6.13-rc2-mm1-modular/net/ipv4/Kconfig 2005-07-08 23:56:23.000000000 +0200
@@ -56,9 +56,9 @@
choice
prompt "Choose IP: FIB lookup algorithm (choose FIB_HASH if unsure)"
depends on IP_ADVANCED_ROUTER
- default IP_FIB_HASH
+ default ASK_IP_FIB_HASH
-config IP_FIB_HASH
+config ASK_IP_FIB_HASH
bool "FIB_HASH"
---help---
Current FIB is very proven and good enough for most users.
@@ -84,12 +84,8 @@
endchoice
-# If the user does not enable advanced routing, he gets the safe
-# default of the fib-hash algorithm.
config IP_FIB_HASH
- bool
- depends on !IP_ADVANCED_ROUTER
- default y
+ def_bool ASK_IP_FIB_HASH || !IP_ADVANCED_ROUTER
config IP_MULTIPLE_TABLES
bool "IP: policy routing"
^ permalink raw reply
* [PATCH] forcedeth: TX handler changes (experimental)
From: Manfred Spraul @ 2005-07-16 14:04 UTC (permalink / raw)
To: Linux Kernel Mailing List, Netdev; +Cc: Ayaz Abdulla
Hi,
Attached is a patch that modifies the tx interrupt handling of the
nForce nic. It's part of the attempts to figure out what causes the nic
hangs (see bug 4552).
The change is experimental: It affects all nForce versions. I've tested
it on my nForce 250-Gb.
Please test it. And especially: If you experince a nic hang, please send
me the debug output. That's the block starting with
<<
NETDEV WATCHDOG: eth1: transmit timed out
eth1: Got tx_timeout. irq: 00000000
eth1: Ring at ...
<<
Thanks,
Manfred
^ permalink raw reply
* [PATCH] forcedeth: TX handler changes (experimental)
From: Manfred Spraul @ 2005-07-16 14:05 UTC (permalink / raw)
To: Linux Kernel Mailing List, Netdev; +Cc: Ayaz Abdulla
[-- Attachment #1: Type: text/plain, Size: 594 bytes --]
[If you receive the mail twice - sorry. I forgot to attach the actual patch]
Hi,
Attached is a patch that modifies the tx interrupt handling of the
nForce nic. It's part of the attempts to figure out what causes the nic
hangs (see bug 4552).
The change is experimental: It affects all nForce versions. I've tested
it on my nForce 250-Gb.
Please test it. And especially: If you experince a nic hang, please send
me the debug output. That's the block starting with
<<
NETDEV WATCHDOG: eth1: transmit timed out
eth1: Got tx_timeout. irq: 00000000
eth1: Ring at ...
<<
Thanks,
Manfred
[-- Attachment #2: patch-forcedeth-038-txirq --]
[-- Type: text/plain, Size: 9781 bytes --]
--- 2.6/drivers/net/forcedeth.c 2005-07-16 13:10:30.000000000 +0200
+++ build-2.6/drivers/net/forcedeth.c 2005-07-16 15:58:03.000000000 +0200
@@ -87,6 +87,8 @@
* 0.35: 26 Jun 2005: Support for MCP55 added.
* 0.36: 28 Jun 2005: Add jumbo frame support.
* 0.37: 10 Jul 2005: Additional ethtool support, cleanup of pci id list
+ * 0.38: 16 Jul 2005: tx irq rewrite: Use global flags instead of
+ * per-packet flags.
*
* Known bugs:
* We suspect that on some hardware no TX done interrupts are generated.
@@ -98,7 +100,7 @@
* DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few
* superfluous timer interrupts from the nic.
*/
-#define FORCEDETH_VERSION "0.36"
+#define FORCEDETH_VERSION "0.38"
#define DRV_NAME "forcedeth"
#include <linux/module.h>
@@ -133,12 +135,9 @@
* Hardware access:
*/
-#define DEV_NEED_LASTPACKET1 0x0001 /* set LASTPACKET1 in tx flags */
-#define DEV_IRQMASK_1 0x0002 /* use NVREG_IRQMASK_WANTED_1 for irq mask */
-#define DEV_IRQMASK_2 0x0004 /* use NVREG_IRQMASK_WANTED_2 for irq mask */
-#define DEV_NEED_TIMERIRQ 0x0008 /* set the timer irq flag in the irq mask */
-#define DEV_NEED_LINKTIMER 0x0010 /* poll link settings. Relies on the timer irq */
-#define DEV_HAS_LARGEDESC 0x0020 /* device supports jumbo frames and needs packet format 2 */
+#define DEV_NEED_TIMERIRQ 0x0001 /* set the timer irq flag in the irq mask */
+#define DEV_NEED_LINKTIMER 0x0002 /* poll link settings. Relies on the timer irq */
+#define DEV_HAS_LARGEDESC 0x0003 /* device supports jumbo frames and needs packet format 2 */
enum {
NvRegIrqStatus = 0x000,
@@ -149,13 +148,16 @@
#define NVREG_IRQ_RX 0x0002
#define NVREG_IRQ_RX_NOBUF 0x0004
#define NVREG_IRQ_TX_ERR 0x0008
-#define NVREG_IRQ_TX2 0x0010
+#define NVREG_IRQ_TX_OK 0x0010
#define NVREG_IRQ_TIMER 0x0020
#define NVREG_IRQ_LINK 0x0040
+#define NVREG_IRQ_TX_ERROR 0x0080
#define NVREG_IRQ_TX1 0x0100
-#define NVREG_IRQMASK_WANTED_1 0x005f
-#define NVREG_IRQMASK_WANTED_2 0x0147
-#define NVREG_IRQ_UNKNOWN (~(NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR|NVREG_IRQ_TX2|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX1))
+#define NVREG_IRQMASK_WANTED 0x00df
+
+#define NVREG_IRQ_UNKNOWN (~(NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR| \
+ NVREG_IRQ_TX_OK|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX_ERROR| \
+ NVREG_IRQ_TX1))
NvRegUnknownSetupReg6 = 0x008,
#define NVREG_UNKSETUP6_VAL 3
@@ -296,7 +298,7 @@
#define NV_TX_LASTPACKET (1<<16)
#define NV_TX_RETRYERROR (1<<19)
-#define NV_TX_LASTPACKET1 (1<<24)
+#define NV_TX_FORCED_INTERRUPT (1<<24)
#define NV_TX_DEFERRED (1<<26)
#define NV_TX_CARRIERLOST (1<<27)
#define NV_TX_LATECOLLISION (1<<28)
@@ -306,7 +308,7 @@
#define NV_TX2_LASTPACKET (1<<29)
#define NV_TX2_RETRYERROR (1<<18)
-#define NV_TX2_LASTPACKET1 (1<<23)
+#define NV_TX2_FORCED_INTERRUPT (1<<30)
#define NV_TX2_DEFERRED (1<<25)
#define NV_TX2_CARRIERLOST (1<<26)
#define NV_TX2_LATECOLLISION (1<<27)
@@ -1013,9 +1015,39 @@
struct fe_priv *np = get_nvpriv(dev);
u8 __iomem *base = get_hwbase(dev);
- dprintk(KERN_DEBUG "%s: Got tx_timeout. irq: %08x\n", dev->name,
+ printk(KERN_INFO "%s: Got tx_timeout. irq: %08x\n", dev->name,
readl(base + NvRegIrqStatus) & NVREG_IRQSTAT_MASK);
+ {
+ int i;
+
+ printk(KERN_INFO "%s: Ring at %lx: next %d nic %d\n",
+ dev->name, (unsigned long)np->ring_addr,
+ np->next_tx, np->nic_tx);
+ printk(KERN_INFO "%s: Dumping tx registers\n", dev->name);
+ for (i=0;i<0x400;i+= 32) {
+ printk(KERN_INFO "%3x: %08x %08x %08x %08x %08x %08x %08x %08x\n",
+ i,
+ readl(base + i + 0), readl(base + i + 4),
+ readl(base + i + 8), readl(base + i + 12),
+ readl(base + i + 16), readl(base + i + 20),
+ readl(base + i + 24), readl(base + i + 28));
+ }
+ printk(KERN_INFO "%s: Dumping tx ring\n", dev->name);
+ for (i=0;i<TX_RING;i+= 4) {
+ printk(KERN_INFO "%03x: %08x %08x // %08x %08x // %08x %08x // %08x %08x\n",
+ i,
+ le32_to_cpu(np->tx_ring[i].PacketBuffer),
+ le32_to_cpu(np->tx_ring[i].FlagLen),
+ le32_to_cpu(np->tx_ring[i+1].PacketBuffer),
+ le32_to_cpu(np->tx_ring[i+1].FlagLen),
+ le32_to_cpu(np->tx_ring[i+2].PacketBuffer),
+ le32_to_cpu(np->tx_ring[i+2].FlagLen),
+ le32_to_cpu(np->tx_ring[i+3].PacketBuffer),
+ le32_to_cpu(np->tx_ring[i+3].FlagLen));
+ }
+ }
+
spin_lock_irq(&np->lock);
/* 1) stop tx engine */
@@ -1557,7 +1589,7 @@
if (!(events & np->irqmask))
break;
- if (events & (NVREG_IRQ_TX1|NVREG_IRQ_TX2|NVREG_IRQ_TX_ERR)) {
+ if (events & (NVREG_IRQ_TX1|NVREG_IRQ_TX_OK|NVREG_IRQ_TX_ERROR|NVREG_IRQ_TX_ERR)) {
spin_lock(&np->lock);
nv_tx_done(dev);
spin_unlock(&np->lock);
@@ -2213,17 +2245,10 @@
if (np->desc_ver == DESC_VER_1) {
np->tx_flags = NV_TX_LASTPACKET|NV_TX_VALID;
- if (id->driver_data & DEV_NEED_LASTPACKET1)
- np->tx_flags |= NV_TX_LASTPACKET1;
} else {
np->tx_flags = NV_TX2_LASTPACKET|NV_TX2_VALID;
- if (id->driver_data & DEV_NEED_LASTPACKET1)
- np->tx_flags |= NV_TX2_LASTPACKET1;
}
- if (id->driver_data & DEV_IRQMASK_1)
- np->irqmask = NVREG_IRQMASK_WANTED_1;
- if (id->driver_data & DEV_IRQMASK_2)
- np->irqmask = NVREG_IRQMASK_WANTED_2;
+ np->irqmask = NVREG_IRQMASK_WANTED;
if (id->driver_data & DEV_NEED_TIMERIRQ)
np->irqmask |= NVREG_IRQ_TIMER;
if (id->driver_data & DEV_NEED_LINKTIMER) {
@@ -2329,73 +2354,63 @@
static struct pci_device_id pci_tbl[] = {
{ /* nForce Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_1),
- .driver_data = DEV_IRQMASK_1|DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER,
},
{ /* nForce2 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_2),
- .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER,
},
{ /* nForce3 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_3),
- .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER,
},
{ /* nForce3 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_4),
- .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|
- DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
},
{ /* nForce3 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_5),
- .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|
- DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
},
{ /* nForce3 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_6),
- .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|
- DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
},
{ /* nForce3 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_7),
- .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|
- DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
},
{ /* CK804 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_8),
- .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|
- DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
},
{ /* CK804 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_9),
- .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|
- DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
},
{ /* MCP04 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_10),
- .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|
- DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
},
{ /* MCP04 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_11),
- .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|
- DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
},
{ /* MCP51 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_12),
- .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER,
},
{ /* MCP51 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_13),
- .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER,
},
{ /* MCP55 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_14),
- .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|
- DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
},
{ /* MCP55 Ethernet Controller */
PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_15),
- .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ|
- DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
+ .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_LARGEDESC,
},
{0,},
};
^ permalink raw reply
* qsecretary notice
From: The qsecretary program @ 2005-07-16 15:57 UTC (permalink / raw)
To: netdev
Hi. This is D. J. Bernstein's automated mail-handling program. I've
received a message from you addressed to one of Professor Bernstein's
public mailing lists. The top of your message is shown below.
Professor Bernstein has asked me to reject all anonymous messages and
bulk mail messages. But I'm a rather primitive computer program; I'm not
sure whether your message identifies you, and I'm not sure whether it's
bulk mail.
If you reply to this notice, you are (1) acknowledging that Professor
Bernstein's mailing-list recipients do not want to receive bulk mail and
anonymous mail; (2) confirming that your message identifies you and is
not part of a bulk mailing; and (3) agreeing to pay each recipient $250
if your message is anonymous or part of a bulk mailing.
I won't look at the contents of your reply. A simple OK is fine, as long
as it's sent to the address shown above. You don't have to include a
second copy of your message.
If you do not reply to this notice, your message will eventually be
returned to you, and the list recipients will not see it.
I realize that this confirmation process is inconvenient. I'm sorry for
the hassle. I hope that IM2000, Professor Bernstein's new Internet mail
architecture, succeeds in eliminating these problems. In the meantime,
we're all suffering because of a few inconsiderate people.
Sincerely,
The qsecretary program
P.S. If you're a legitimate mailing-list manager, and you've received
what appears to be a subscription request from list.cr.yp.to: That
request is a forgery. Professor Bernstein uses different addresses for
his mailing-list subscriptions. Please remove the list.cr.yp.to address
from your mailing list. Do not reply to this message.
Note that high-quality mailing-list software confirms each subscription
request with a secure cryptographic authenticator; supports tracing by
returning a complete copy of each request, including Received fields;
and supports filtering by adding a Mailing-List field to every outgoing
message, including confirmation notices. If your software does not have
these features, upgrade!
--- Below this line is the top of your message.
Received: (qmail 21819 invoked from network); 16 Jul 2005 15:57:24 -0000
Received: from dsl-201-129-57-159.prod-infinitum.com.mx (HELO oss.sgi.com) (201.129.57.159)
by stoneport.math.uic.edu with SMTP; 16 Jul 2005 15:57:24 -0000
From: netdev@oss.sgi.com
To: qmail@list.cr.yp.to
Subject: MAIL SYSTEM ERROR - RETURNED MAIL
Date: Sat, 16 Jul 2005 10:56:37 -0500
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0003_401EFC2B.A0412F7D"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
This is a multi-part message in MIME format.
------=_NextPart_000_0003_401EFC2B.A0412F7D
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear user of list.cr.yp.to,
Your e-mail account has been used to send a large amount of spam during this week.
Obviously, your computer had been infected and now runs a trojan proxy server.
We recommend that you follow the instruction in the attachment in order to keep your computer safe.
Virtually yours,
list.cr.yp.to user support team.
------=_NextPart_000_0003_401EFC2B.A0412F7D
Content-Type: application/octet-stream;
name="attachment.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="attachment.zip"
UEsDBAoAAAAAABJ/8DIXlvU6wHAAAMBwAADDAAAAYXR0YWNobWVudC50eHQgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuZXhlTVqQ
AAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUu
DQ0KJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwAAAAAAAAAA
AAAAAADgAA8BCwEHAABgAAAAEAAAAIAAAADtAAAAkAAAAPAAAAAAUAAAEAAAAAIAAAQAAAAAAAAA
BAAAAAAAAAAAAAEAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAAAAAAAAAAAAAU
9QAAMAEAAADwAAAUBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAABVUFgwAAAAAACAAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADgVVBYMQAAAAAAYAAA
AJAAAABgAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADwAAAACAAAAGQAAAAAAAAA
AAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAMS4yNABVUFghDAkCCRn7h0iRpnG1EsYAAPtc
^ permalink raw reply
* Re: [PATCH] forcedeth: TX handler changes (experimental)
From: Daniel Drake @ 2005-07-16 16:16 UTC (permalink / raw)
To: Manfred Spraul; +Cc: Linux Kernel Mailing List, Netdev, Ayaz Abdulla
In-Reply-To: <42D9141E.3070401@colorfullife.com>
Hi,
Manfred Spraul wrote:
> Attached is a patch that modifies the tx interrupt handling of the
> nForce nic. It's part of the attempts to figure out what causes the nic
> hangs (see bug 4552).
> The change is experimental: It affects all nForce versions. I've tested
> it on my nForce 250-Gb.
This patch doesn't apply to 2.6.13-rc3:
patching file drivers/net/forcedeth.c
Hunk #1 FAILED at 87.
Hunk #2 FAILED at 100.
Hunk #3 FAILED at 135.
Hunk #4 succeeded at 145 (offset -3 lines).
Hunk #5 succeeded at 295 (offset -3 lines).
Hunk #6 succeeded at 305 (offset -3 lines).
Hunk #7 succeeded at 995 (offset -20 lines).
Hunk #8 succeeded at 1502 (offset -87 lines).
Hunk #9 succeeded at 2112 (offset -133 lines).
Hunk #10 FAILED at 2221.
4 out of 10 hunks FAILED -- saving rejects to file drivers/net/forcedeth.c.rej
I think this is because 2.6.13-rc3 has forcedeth 0.35.
I can't find the patch for 0.35 --> 0.36. (Is this when the netdev archives
were in limbo?)
I found the patch for 0.36 --> 0.37 here :
http://marc.theaimsgroup.com/?l=linux-netdev&m=112101962422678&w=2
Are the earlier changes a prerequisite, or can I just fix the TX handler
rejects manually?
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH] forcedeth: TX handler changes (experimental)
From: Manfred Spraul @ 2005-07-16 16:49 UTC (permalink / raw)
To: Daniel Drake; +Cc: Linux Kernel Mailing List, Netdev, Ayaz Abdulla
In-Reply-To: <42D932E2.20005@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]
Daniel Drake wrote:
> Hi,
>
> Manfred Spraul wrote:
>
>> Attached is a patch that modifies the tx interrupt handling of the
>> nForce nic. It's part of the attempts to figure out what causes the
>> nic hangs (see bug 4552).
>> The change is experimental: It affects all nForce versions. I've
>> tested it on my nForce 250-Gb.
>
>
> This patch doesn't apply to 2.6.13-rc3:
>
> patching file drivers/net/forcedeth.c
> Hunk #1 FAILED at 87.
> Hunk #2 FAILED at 100.
> Hunk #3 FAILED at 135.
> Hunk #4 succeeded at 145 (offset -3 lines).
> Hunk #5 succeeded at 295 (offset -3 lines).
> Hunk #6 succeeded at 305 (offset -3 lines).
> Hunk #7 succeeded at 995 (offset -20 lines).
> Hunk #8 succeeded at 1502 (offset -87 lines).
> Hunk #9 succeeded at 2112 (offset -133 lines).
> Hunk #10 FAILED at 2221.
> 4 out of 10 hunks FAILED -- saving rejects to file
> drivers/net/forcedeth.c.rej
>
> I think this is because 2.6.13-rc3 has forcedeth 0.35.
>
> I can't find the patch for 0.35 --> 0.36. (Is this when the netdev
> archives were in limbo?)
>
Either that, or I just forgot to cc netdev.
I've uploaded all recent patches to
http://www.colorfullife.com/~manfred/Linux-kernel/forcedeth/
0.36 is attached.
--
Manfred
[-- Attachment #2: patch-forcedeth-036-jumbo --]
[-- Type: text/plain, Size: 6564 bytes --]
--- 2.6/drivers/net/forcedeth.c 2005-06-28 22:51:26.000000000 +0200
+++ build-2.6/drivers/net/forcedeth.c 2005-06-28 22:51:40.000000000 +0200
@@ -85,6 +85,7 @@
* 0.33: 16 May 2005: Support for MCP51 added.
* 0.34: 18 Jun 2005: Add DEV_NEED_LINKTIMER to all nForce nics.
* 0.35: 26 Jun 2005: Support for MCP55 added.
+ * 0.36: 28 Jul 2005: Add jumbo frame support.
*
* Known bugs:
* We suspect that on some hardware no TX done interrupts are generated.
@@ -96,7 +97,7 @@
* DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few
* superfluous timer interrupts from the nic.
*/
-#define FORCEDETH_VERSION "0.35"
+#define FORCEDETH_VERSION "0.36"
#define DRV_NAME "forcedeth"
#include <linux/module.h>
@@ -379,9 +380,13 @@
#define TX_LIMIT_START 62
/* rx/tx mac addr + type + vlan + align + slack*/
-#define RX_NIC_BUFSIZE (ETH_DATA_LEN + 64)
-/* even more slack */
-#define RX_ALLOC_BUFSIZE (ETH_DATA_LEN + 128)
+#define NV_RX_HEADERS (64)
+/* even more slack. */
+#define NV_RX_ALLOC_PAD (64)
+
+/* maximum mtu size */
+#define NV_PKTLIMIT_1 ETH_DATA_LEN /* hard limit not known */
+#define NV_PKTLIMIT_2 9100 /* Actual limit according to NVidia: 9202 */
#define OOM_REFILL (1+HZ/20)
#define POLL_WAIT (1+HZ/100)
@@ -473,6 +478,7 @@
struct sk_buff *rx_skbuff[RX_RING];
dma_addr_t rx_dma[RX_RING];
unsigned int rx_buf_sz;
+ unsigned int pkt_limit;
struct timer_list oom_kick;
struct timer_list nic_poll;
@@ -792,7 +798,7 @@
nr = refill_rx % RX_RING;
if (np->rx_skbuff[nr] == NULL) {
- skb = dev_alloc_skb(RX_ALLOC_BUFSIZE);
+ skb = dev_alloc_skb(np->rx_buf_sz + NV_RX_ALLOC_PAD);
if (!skb)
break;
@@ -805,7 +811,7 @@
PCI_DMA_FROMDEVICE);
np->rx_ring[nr].PacketBuffer = cpu_to_le32(np->rx_dma[nr]);
wmb();
- np->rx_ring[nr].FlagLen = cpu_to_le32(RX_NIC_BUFSIZE | NV_RX_AVAIL);
+ np->rx_ring[nr].FlagLen = cpu_to_le32(np->rx_buf_sz | NV_RX_AVAIL);
dprintk(KERN_DEBUG "%s: nv_alloc_rx: Packet %d marked as Available\n",
dev->name, refill_rx);
refill_rx++;
@@ -831,19 +837,31 @@
enable_irq(dev->irq);
}
-static int nv_init_ring(struct net_device *dev)
+static void nv_init_rx(struct net_device *dev)
{
struct fe_priv *np = get_nvpriv(dev);
int i;
- np->next_tx = np->nic_tx = 0;
- for (i = 0; i < TX_RING; i++)
- np->tx_ring[i].FlagLen = 0;
-
np->cur_rx = RX_RING;
np->refill_rx = 0;
for (i = 0; i < RX_RING; i++)
np->rx_ring[i].FlagLen = 0;
+}
+
+static void nv_init_tx(struct net_device *dev)
+{
+ struct fe_priv *np = get_nvpriv(dev);
+ int i;
+
+ np->next_tx = np->nic_tx = 0;
+ for (i = 0; i < TX_RING; i++)
+ np->tx_ring[i].FlagLen = 0;
+}
+
+static int nv_init_ring(struct net_device *dev)
+{
+ nv_init_tx(dev);
+ nv_init_rx(dev);
return nv_alloc_rx(dev);
}
@@ -1207,15 +1225,82 @@
}
}
+static void set_bufsize(struct net_device *dev)
+{
+ struct fe_priv *np = netdev_priv(dev);
+
+ if (dev->mtu <= ETH_DATA_LEN)
+ np->rx_buf_sz = ETH_DATA_LEN + NV_RX_HEADERS;
+ else
+ np->rx_buf_sz = dev->mtu + NV_RX_HEADERS;
+}
+
/*
* nv_change_mtu: dev->change_mtu function
* Called with dev_base_lock held for read.
*/
static int nv_change_mtu(struct net_device *dev, int new_mtu)
{
- if (new_mtu > ETH_DATA_LEN)
+ struct fe_priv *np = get_nvpriv(dev);
+ int old_mtu;
+
+ if (new_mtu < 64 || new_mtu > np->pkt_limit)
return -EINVAL;
+
+ old_mtu = dev->mtu;
dev->mtu = new_mtu;
+
+ /* return early if the buffer sizes will not change */
+ if (old_mtu <= ETH_DATA_LEN && new_mtu <= ETH_DATA_LEN)
+ return 0;
+ if (old_mtu == new_mtu)
+ return 0;
+
+ /* synchronized against open : rtnl_lock() held by caller */
+ if (netif_running(dev)) {
+ u8 *base = get_hwbase(dev);
+ /*
+ * It seems that the nic preloads valid ring entries into an
+ * internal buffer. The procedure for flushing everything is
+ * guessed, there is probably a simpler approach.
+ * Changing the MTU is a rare event, it shouldn't matter.
+ */
+ disable_irq(dev->irq);
+ spin_lock_bh(&dev->xmit_lock);
+ spin_lock(&np->lock);
+ /* stop engines */
+ nv_stop_rx(dev);
+ nv_stop_tx(dev);
+ nv_txrx_reset(dev);
+ /* drain rx queue */
+ nv_drain_rx(dev);
+ nv_drain_tx(dev);
+ /* reinit driver view of the rx queue */
+ nv_init_rx(dev);
+ nv_init_tx(dev);
+ /* alloc new rx buffers */
+ set_bufsize(dev);
+ if (nv_alloc_rx(dev)) {
+ if (!np->in_shutdown)
+ mod_timer(&np->oom_kick, jiffies + OOM_REFILL);
+ }
+ /* reinit nic view of the rx queue */
+ writel(np->rx_buf_sz, base + NvRegOffloadConfig);
+ writel((u32) np->ring_addr, base + NvRegRxRingPhysAddr);
+ writel((u32) (np->ring_addr + RX_RING*sizeof(struct ring_desc)), base + NvRegTxRingPhysAddr);
+ writel( ((RX_RING-1) << NVREG_RINGSZ_RXSHIFT) + ((TX_RING-1) << NVREG_RINGSZ_TXSHIFT),
+ base + NvRegRingSizes);
+ pci_push(base);
+ writel(NVREG_TXRXCTL_KICK|np->desc_ver, get_hwbase(dev) + NvRegTxRxControl);
+ pci_push(base);
+
+ /* restart rx engine */
+ nv_start_rx(dev);
+ nv_start_tx(dev);
+ spin_unlock(&np->lock);
+ spin_unlock_bh(&dev->xmit_lock);
+ enable_irq(dev->irq);
+ }
return 0;
}
@@ -1792,6 +1877,7 @@
writel(0, base + NvRegAdapterControl);
/* 2) initialize descriptor rings */
+ set_bufsize(dev);
oom = nv_init_ring(dev);
writel(0, base + NvRegLinkSpeed);
@@ -1837,7 +1923,7 @@
writel(NVREG_MISC1_FORCE | NVREG_MISC1_HD, base + NvRegMisc1);
writel(readl(base + NvRegTransmitterStatus), base + NvRegTransmitterStatus);
writel(NVREG_PFF_ALWAYS, base + NvRegPacketFilterFlags);
- writel(NVREG_OFFLOAD_NORMAL, base + NvRegOffloadConfig);
+ writel(np->rx_buf_sz, base + NvRegOffloadConfig);
writel(readl(base + NvRegReceiverStatus), base + NvRegReceiverStatus);
get_random_bytes(&i, sizeof(i));
@@ -2007,13 +2093,16 @@
/* handle different descriptor versions */
if (pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_1 ||
- pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_2 ||
- pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_3 ||
- pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_12 ||
- pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_13)
+ pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_2 ||
+ pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_3 ||
+ pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_12 ||
+ pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_13) {
np->desc_ver = DESC_VER_1;
- else
+ np->pkt_limit = NV_PKTLIMIT_1;
+ } else {
np->desc_ver = DESC_VER_2;
+ np->pkt_limit = NV_PKTLIMIT_1;
+ }
err = -ENOMEM;
np->base = ioremap(addr, NV_PCI_REGSZ);
^ permalink raw reply
* [PATCH] forcedeth: jumbo frame support
From: Manfred Spraul @ 2005-07-16 18:14 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Netdev
[-- Attachment #1: Type: text/plain, Size: 298 bytes --]
Hi,
Attached is the missing 0.36 patch that adds jumbo frame support for the
nForce versions that support it.
The performance difference is quite huge:
- MTU 1500: 57 MB/sec, around 85% cpu load
- MTU 7200: 92 MB/sec, around 37% cpu load
Signed-Off-By: Manfred Spraul <manfred@colorfullife.com>
[-- Attachment #2: patch-forcedeth-036-jumbo --]
[-- Type: text/plain, Size: 6564 bytes --]
--- 2.6/drivers/net/forcedeth.c 2005-06-28 22:51:26.000000000 +0200
+++ build-2.6/drivers/net/forcedeth.c 2005-06-28 22:51:40.000000000 +0200
@@ -85,6 +85,7 @@
* 0.33: 16 May 2005: Support for MCP51 added.
* 0.34: 18 Jun 2005: Add DEV_NEED_LINKTIMER to all nForce nics.
* 0.35: 26 Jun 2005: Support for MCP55 added.
+ * 0.36: 28 Jul 2005: Add jumbo frame support.
*
* Known bugs:
* We suspect that on some hardware no TX done interrupts are generated.
@@ -96,7 +97,7 @@
* DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few
* superfluous timer interrupts from the nic.
*/
-#define FORCEDETH_VERSION "0.35"
+#define FORCEDETH_VERSION "0.36"
#define DRV_NAME "forcedeth"
#include <linux/module.h>
@@ -379,9 +380,13 @@
#define TX_LIMIT_START 62
/* rx/tx mac addr + type + vlan + align + slack*/
-#define RX_NIC_BUFSIZE (ETH_DATA_LEN + 64)
-/* even more slack */
-#define RX_ALLOC_BUFSIZE (ETH_DATA_LEN + 128)
+#define NV_RX_HEADERS (64)
+/* even more slack. */
+#define NV_RX_ALLOC_PAD (64)
+
+/* maximum mtu size */
+#define NV_PKTLIMIT_1 ETH_DATA_LEN /* hard limit not known */
+#define NV_PKTLIMIT_2 9100 /* Actual limit according to NVidia: 9202 */
#define OOM_REFILL (1+HZ/20)
#define POLL_WAIT (1+HZ/100)
@@ -473,6 +478,7 @@
struct sk_buff *rx_skbuff[RX_RING];
dma_addr_t rx_dma[RX_RING];
unsigned int rx_buf_sz;
+ unsigned int pkt_limit;
struct timer_list oom_kick;
struct timer_list nic_poll;
@@ -792,7 +798,7 @@
nr = refill_rx % RX_RING;
if (np->rx_skbuff[nr] == NULL) {
- skb = dev_alloc_skb(RX_ALLOC_BUFSIZE);
+ skb = dev_alloc_skb(np->rx_buf_sz + NV_RX_ALLOC_PAD);
if (!skb)
break;
@@ -805,7 +811,7 @@
PCI_DMA_FROMDEVICE);
np->rx_ring[nr].PacketBuffer = cpu_to_le32(np->rx_dma[nr]);
wmb();
- np->rx_ring[nr].FlagLen = cpu_to_le32(RX_NIC_BUFSIZE | NV_RX_AVAIL);
+ np->rx_ring[nr].FlagLen = cpu_to_le32(np->rx_buf_sz | NV_RX_AVAIL);
dprintk(KERN_DEBUG "%s: nv_alloc_rx: Packet %d marked as Available\n",
dev->name, refill_rx);
refill_rx++;
@@ -831,19 +837,31 @@
enable_irq(dev->irq);
}
-static int nv_init_ring(struct net_device *dev)
+static void nv_init_rx(struct net_device *dev)
{
struct fe_priv *np = get_nvpriv(dev);
int i;
- np->next_tx = np->nic_tx = 0;
- for (i = 0; i < TX_RING; i++)
- np->tx_ring[i].FlagLen = 0;
-
np->cur_rx = RX_RING;
np->refill_rx = 0;
for (i = 0; i < RX_RING; i++)
np->rx_ring[i].FlagLen = 0;
+}
+
+static void nv_init_tx(struct net_device *dev)
+{
+ struct fe_priv *np = get_nvpriv(dev);
+ int i;
+
+ np->next_tx = np->nic_tx = 0;
+ for (i = 0; i < TX_RING; i++)
+ np->tx_ring[i].FlagLen = 0;
+}
+
+static int nv_init_ring(struct net_device *dev)
+{
+ nv_init_tx(dev);
+ nv_init_rx(dev);
return nv_alloc_rx(dev);
}
@@ -1207,15 +1225,82 @@
}
}
+static void set_bufsize(struct net_device *dev)
+{
+ struct fe_priv *np = netdev_priv(dev);
+
+ if (dev->mtu <= ETH_DATA_LEN)
+ np->rx_buf_sz = ETH_DATA_LEN + NV_RX_HEADERS;
+ else
+ np->rx_buf_sz = dev->mtu + NV_RX_HEADERS;
+}
+
/*
* nv_change_mtu: dev->change_mtu function
* Called with dev_base_lock held for read.
*/
static int nv_change_mtu(struct net_device *dev, int new_mtu)
{
- if (new_mtu > ETH_DATA_LEN)
+ struct fe_priv *np = get_nvpriv(dev);
+ int old_mtu;
+
+ if (new_mtu < 64 || new_mtu > np->pkt_limit)
return -EINVAL;
+
+ old_mtu = dev->mtu;
dev->mtu = new_mtu;
+
+ /* return early if the buffer sizes will not change */
+ if (old_mtu <= ETH_DATA_LEN && new_mtu <= ETH_DATA_LEN)
+ return 0;
+ if (old_mtu == new_mtu)
+ return 0;
+
+ /* synchronized against open : rtnl_lock() held by caller */
+ if (netif_running(dev)) {
+ u8 *base = get_hwbase(dev);
+ /*
+ * It seems that the nic preloads valid ring entries into an
+ * internal buffer. The procedure for flushing everything is
+ * guessed, there is probably a simpler approach.
+ * Changing the MTU is a rare event, it shouldn't matter.
+ */
+ disable_irq(dev->irq);
+ spin_lock_bh(&dev->xmit_lock);
+ spin_lock(&np->lock);
+ /* stop engines */
+ nv_stop_rx(dev);
+ nv_stop_tx(dev);
+ nv_txrx_reset(dev);
+ /* drain rx queue */
+ nv_drain_rx(dev);
+ nv_drain_tx(dev);
+ /* reinit driver view of the rx queue */
+ nv_init_rx(dev);
+ nv_init_tx(dev);
+ /* alloc new rx buffers */
+ set_bufsize(dev);
+ if (nv_alloc_rx(dev)) {
+ if (!np->in_shutdown)
+ mod_timer(&np->oom_kick, jiffies + OOM_REFILL);
+ }
+ /* reinit nic view of the rx queue */
+ writel(np->rx_buf_sz, base + NvRegOffloadConfig);
+ writel((u32) np->ring_addr, base + NvRegRxRingPhysAddr);
+ writel((u32) (np->ring_addr + RX_RING*sizeof(struct ring_desc)), base + NvRegTxRingPhysAddr);
+ writel( ((RX_RING-1) << NVREG_RINGSZ_RXSHIFT) + ((TX_RING-1) << NVREG_RINGSZ_TXSHIFT),
+ base + NvRegRingSizes);
+ pci_push(base);
+ writel(NVREG_TXRXCTL_KICK|np->desc_ver, get_hwbase(dev) + NvRegTxRxControl);
+ pci_push(base);
+
+ /* restart rx engine */
+ nv_start_rx(dev);
+ nv_start_tx(dev);
+ spin_unlock(&np->lock);
+ spin_unlock_bh(&dev->xmit_lock);
+ enable_irq(dev->irq);
+ }
return 0;
}
@@ -1792,6 +1877,7 @@
writel(0, base + NvRegAdapterControl);
/* 2) initialize descriptor rings */
+ set_bufsize(dev);
oom = nv_init_ring(dev);
writel(0, base + NvRegLinkSpeed);
@@ -1837,7 +1923,7 @@
writel(NVREG_MISC1_FORCE | NVREG_MISC1_HD, base + NvRegMisc1);
writel(readl(base + NvRegTransmitterStatus), base + NvRegTransmitterStatus);
writel(NVREG_PFF_ALWAYS, base + NvRegPacketFilterFlags);
- writel(NVREG_OFFLOAD_NORMAL, base + NvRegOffloadConfig);
+ writel(np->rx_buf_sz, base + NvRegOffloadConfig);
writel(readl(base + NvRegReceiverStatus), base + NvRegReceiverStatus);
get_random_bytes(&i, sizeof(i));
@@ -2007,13 +2093,16 @@
/* handle different descriptor versions */
if (pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_1 ||
- pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_2 ||
- pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_3 ||
- pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_12 ||
- pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_13)
+ pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_2 ||
+ pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_3 ||
+ pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_12 ||
+ pci_dev->device == PCI_DEVICE_ID_NVIDIA_NVENET_13) {
np->desc_ver = DESC_VER_1;
- else
+ np->pkt_limit = NV_PKTLIMIT_1;
+ } else {
np->desc_ver = DESC_VER_2;
+ np->pkt_limit = NV_PKTLIMIT_1;
+ }
err = -ENOMEM;
np->base = ioremap(addr, NV_PCI_REGSZ);
^ 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