* RE: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
From: Ravinandan Arakali @ 2005-07-12 21:00 UTC (permalink / raw)
To: 'David S. Miller', hch
Cc: raghavendra.koushik, jgarzik, netdev, leonid.grossman,
rapuru.sriram
In-Reply-To: <20050712.133404.52118192.davem@davemloft.net>
The two-buffer mode was added as a configurable option
to Kconfig file several months ago. Hence the macro
is CONFIG_2BUFF_MODE.
The two-buffer receive mode involves two buffers (128 byte
aligned) for each packet. This mode drastically increases
performance on SGI platforms and hence enabled only for
these platforms. On other platforms, there's no difference
compared to one-buffer mode but the added complexity and
extra memory allocated does not make it worthwhile to
enable this mode for non-SGI platforms. Also, most of
our QA cycle on non-SGI platforms has been done with
one-buffer mode.
Thanks,
Ravi
> > +/* Enable 2 buffer mode by default for SGI system */
> > +#ifdef CONFIG_IA64_SGI_SN2
> > +#define CONFIG_2BUFF_MODE
> > +#endif
>
> this enabled it only on kernel that are built to only run on SN2
> hardware, which is completely useless in practice. Besides that defining
> a CONFIG_ symbol from source files is a big no-go.
Yes, do this in the Kconfig file instead.
^ permalink raw reply
* Re: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
From: David S. Miller @ 2005-07-12 21:04 UTC (permalink / raw)
To: ravinandan.arakali
Cc: hch, raghavendra.koushik, jgarzik, netdev, leonid.grossman,
rapuru.sriram
In-Reply-To: <000a01c58724$ca41a7c0$4f10100a@pc.s2io.com>
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: [PATCH 2.6.12.1 5/12] S2io: Performance improvements
From: Christoph Hellwig @ 2005-07-12 21:07 UTC (permalink / raw)
To: David S. Miller
Cc: ravinandan.arakali, hch, raghavendra.koushik, jgarzik, netdev,
leonid.grossman, rapuru.sriram
In-Reply-To: <20050712.140411.41107257.davem@davemloft.net>
On Tue, Jul 12, 2005 at 02:04:11PM -0700, David S. Miller wrote:
> 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.
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.
You have to make this run-time selectable.
^ permalink raw reply
* 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
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