* 3C905C-TX
From: Daniel Höhnle @ 2005-11-30 12:59 UTC (permalink / raw)
To: linux-kernel, andrewm, netdev
Hello i have Suse Linux 9.3 and a 3Com 3C905C-TX Networkcard. But she
don't works. Where can I get a Driver??? Or give it a Dokumentation
how I can make the Driver??
Thanks
Daniel Höhnle
^ permalink raw reply
* [PATCH] i82596/CONFIG_APRICOT release_region() fix
From: Magnus Damm @ 2005-11-30 7:23 UTC (permalink / raw)
To: netdev; +Cc: Magnus Damm
Fix release_region() in i82596 driver using CONFIG_APRICOT.
linux-2.6.15-rc3 configured with CONFIG_APRICOT=y calls release_region()
incorrectly if no hardware is found:
Trying to free nonexistent resource <00000000-00000010>
This patch sets up dev->base_addr before the label "out1" might be used.
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
---
82596.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
--- linux-2.6.15-rc3/drivers/net/82596.c 2005-11-30 16:10:34.000000000 +0900
+++ linux-2.6.15-rc3-i82596_apricot_release_region/drivers/net/82596.c 2005-11-30 16:11:13.000000000 +0900
@@ -1203,6 +1203,9 @@
checksum += eth_addr[i];
}
+ dev->base_addr = ioaddr;
+ dev->irq = 10;
+
/* checksum is a multiple of 0x100, got this wrong first time
some machines have 0x100, some 0x200. The DOS driver doesn't
even bother with the checksum.
@@ -1215,8 +1218,6 @@
goto out1;
}
- dev->base_addr = ioaddr;
- dev->irq = 10;
}
#endif
dev->mem_start = (int)__get_free_pages(GFP_ATOMIC, 0);
^ permalink raw reply
* Re: [2.6 patch] net/ipv6/: make two functions static
From: David S. Miller @ 2005-11-30 0:29 UTC (permalink / raw)
To: bunk; +Cc: netdev, linux-kernel
In-Reply-To: <20051123012359.GH3963@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Wed, 23 Nov 2005 02:23:59 +0100
> This patch makes two needlessly global functions static.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Also applied, thanks.
^ permalink raw reply
* Re: [2.6 patch] net/ipv4/netfilter/: small cleanups
From: David S. Miller @ 2005-11-30 0:28 UTC (permalink / raw)
To: bunk; +Cc: coreteam, netfilter-devel, netdev, linux-kernel
In-Reply-To: <20051123004108.GE3963@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Wed, 23 Nov 2005 01:41:08 +0100
> This patch contains the following cleanups:
> - make needlessly global code static
> - ip_conntrack_core.c: ip_conntrack_flush() -> ip_conntrack_flush(void)
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied, thanks Adrian.
^ permalink raw reply
* Re: [2.6 patch] net/ipv4/: make two functions static
From: David S. Miller @ 2005-11-30 0:27 UTC (permalink / raw)
To: bunk; +Cc: netdev, linux-kernel
In-Reply-To: <20051123003806.GD3963@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Wed, 23 Nov 2005 01:38:06 +0100
> This patch makes two needlessly global functions static.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied, thanks Adrian.
^ permalink raw reply
* Your Password
From: hostmaster @ 2005-11-30 0:02 UTC (permalink / raw)
To: ralf
[-- Attachment #1: Type: text/plain, Size: 123 bytes --]
Account and Password Information are attached!
***** Go to: http://www.muppetlabs.com
***** Email: postman@muppetlabs.com
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: Fw: [Fwd: [Bug 5644] New: NFS v3 TCP 3-way handshake incorrect, iptables blocks access]
From: Patrick McHardy @ 2005-11-29 22:32 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Olaf Kirch, Harald Welte, netfilter-devel, David S. Miller,
netdev
In-Reply-To: <Pine.LNX.4.58.0511291135430.31216@blackhole.kfki.hu>
Jozsef Kadlecsik wrote:
> Mounting NFS file systems after a (warm) reboot could take a long time if
> firewalling and connection tracking was enabled.
>
> The reason is that the NFS clients tends to use the same ports (800 and
> counting down). Now on reboot, the server would still have a TCB for an
> existing TCP connection client:800 -> server:2049. The client sends a
> SYN from port 800 to server:2049, which elicits an ACK from the server.
> The firewall on the client drops the ACK because (from its point of
> view) the connection is still in half-open state, and it expects to see
> a SYNACK.
>
> The client will eventually time out after several minutes.
>
> The following patch corrects this, by accepting ACKs on half open connections
> as well.
Thanks Jozsef, I'll pass it on to Dave tommorrow.
^ permalink raw reply
* Re: NIC irq nobody cared ? virtual to physical and DMA questions
From: Ivo van Doorn @ 2005-11-29 21:05 UTC (permalink / raw)
To: Mateusz Berezecki; +Cc: linux-kernel, netdev, kernel-mentors
In-Reply-To: <745843498.20051129212851@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
Hi,
> This time the questions are different.
>
> Given the following output could anyone please tell me what is wrong ?
> In explicit what does that mysterious "nobody cared" message mean?
> And another stupid question: should DMA for a network card be enabled before or maybe
> _after_ interrupts get enabled? And... how to convert virtual address
> to physical one?
The nobody cared error message is reported when a device is raising interrupts while
the actual driver has not yet registered the interrupt handler.
The best way to handle this for network drivers (done in rt2x00, which works fine) would be:
1 - Allocate DMA
2 - Registers interrupt handler
3 - Enable device interrupts.
IvD
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Patch] 2.4.32 - Neighbour Cache (ARP) State machine bug Fixed
From: Pradeep Vincent @ 2005-11-29 20:42 UTC (permalink / raw)
To: Roberto Nibali, netdev; +Cc: linux-kernel, torvalds
>From the source,
/*
Transitions NUD_STALE <-> NUD_REACHABLE do not occur
when fast path is built: we have no timers associated with
these states, we do not have time to check state when sending.
neigh_periodic_timer check periodically neigh->confirmed
time and moves NUD_REACHABLE -> NUD_STALE.
If a routine wants to know TRUE entry state, it calls
neigh_sync before checking state.
Called with write_locked neigh.
*/
I got the impression that neigh_periodic_timer is supposed to check
for stale entries although it doesn't. Which tasklet are you referring
to ? Or are you saying I should be calling neigh_sync instead of
checking for stale entries myself.
VMACS are used outside the linux system - for e.g. certain routers
present different VMACS for a default gateway ip for active-active
load-balancing and when one dies off, the failed VMAC is removed
eventually causing linux system using the failed VMAC to balk as it
doesn't stale out the arp cache entries even when traffic isn't able
to flow (confirmed doesn't move ahead).
netdev folks, can you CC me on your reply.
Thanks,
Pradeep Vincent
On 11/28/05, Roberto Nibali <ratz@drugphish.ch> wrote:
> > In 2.4.21, arp code uses gc_timer to check for stale arp cache
> > entries. In 2.6, each entry has its own timer to check for stale arp
> > cache. 2.4.29 to 2.4.32 kernels (atleast) use neither of these timers.
>
> Regarding NUD_REACHABLE <-> NUD_STALE transition it has a timer check.
> Due to the fast path it's not enabled per default. Use neigh_sync() to
> check, although I believe the installed tasklet does this for you already.
>
> The knowledgeable netdev people will know better.
>
> > This causes problems in environments where IPs or MACs are reassigned
> > - saw this problem on load balancing router based networks that use
> > VMACs. Tested this code on load balancing router based networks as
> > well as peer-linux systems.
>
> How do you use VMACs in 2.4.x?
>
> > diff -Naur old/net/core/neighbour.c new/net/core/neighbour.c
> > --- old/net/core/neighbour.c Wed Nov 23 17:15:30 2005
> > +++ new/net/core/neighbour.c Wed Nov 23 17:26:01 2005
> > @@ -14,6 +14,7 @@
> > * Vitaly E. Lavrov releasing NULL neighbor in neigh_add.
> > * Harald Welte Add neighbour cache statistics like rtstat
> > * Harald Welte port neighbour cache rework from 2.6.9-rcX
> > + * Pradeep Vincent Move neighbour cache entry to stale state
> > */
> >
> > #include <linux/config.h>
> > @@ -705,6 +706,14 @@
> > neigh_release(n);
> > continue;
> > }
> > +
> > + /* Mark it stale - To be reconfirmed later when used */
> > + if (n->nud_state&NUD_REACHABLE &&
> > + now - n->confirmed > n->parms->reachable_time) {
> > + n->nud_state = NUD_STALE;
> > + neigh_suspect(n);
> > + }
> > +
>
> If this is really a problem, why not simply call neigh_sync()? Your
> patch also seems to be whitespace damaged.
>
> > write_unlock(&n->lock);
> >
> > next_elt:
>
> I've cc'd netdev since this is where such patches should go for
> discussion; left Linus in the loop (netiquette) although he's nothing to
> do with this ;).
>
> Cheers,
> Roberto Nibali, ratz
> --
> echo
> '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
>
^ permalink raw reply
* NIC irq nobody cared ? virtual to physical and DMA questions
From: Mateusz Berezecki @ 2005-11-29 20:28 UTC (permalink / raw)
To: linux-kernel, netdev, kernel-mentors
Hello List,
This time the questions are different.
Given the following output could anyone please tell me what is wrong ?
In explicit what does that mysterious "nobody cared" message mean?
And another stupid question: should DMA for a network card be enabled before or maybe
_after_ interrupts get enabled? And... how to convert virtual address
to physical one?
Nov 29 21:25:47 debian kernel: atheros: receive init routine called
Nov 29 21:25:47 debian kernel: atheros: physical address of RX head is 00000000
Nov 29 21:25:47 debian kernel: atheros: enabling DMA receive. this can crash things supposedly.
Nov 29 21:25:47 debian kernel: irq 11: nobody cared (try booting with the "irqpoll" option)
Nov 29 21:25:47 debian kernel: [dump_stack+23/32] dump_stack+0x17/0x20
Nov 29 21:25:47 debian kernel: [__report_bad_irq+39/144] __report_bad_irq+0x27/0x90
Nov 29 21:25:47 debian kernel: [note_interrupt+114/192] note_interrupt+0x72/0xc0
Nov 29 21:25:47 debian kernel: [__do_IRQ+200/224] __do_IRQ+0xc8/0xe0
Nov 29 21:25:47 debian kernel: [do_IRQ+80/128] do_IRQ+0x50/0x80
Nov 29 21:25:47 debian kernel: =======================
Nov 29 21:25:47 debian kernel: [common_interrupt+26/32] common_interrupt+0x1a/0x20
Nov 29 21:25:47 debian kernel: [do_softirq+115/128] do_softirq+0x73/0x80
Nov 29 21:25:47 debian kernel: =======================
Nov 29 21:25:47 debian kernel: [irq_exit+67/80] irq_exit+0x43/0x50
Nov 29 21:25:47 debian kernel: [do_IRQ+87/128] do_IRQ+0x57/0x80
Nov 29 21:25:47 debian kernel: [common_interrupt+26/32] common_interrupt+0x1a/0x20
Nov 29 21:25:47 debian kernel: [pg0+260065664/1065075712] ath_init+0x30/0x80 [atheros]
Nov 29 21:25:47 debian kernel: [dev_open+70/144] dev_open+0x46/0x90
Nov 29 21:25:47 debian kernel: [dev_change_flags+83/288] dev_change_flags+0x53/0x120
Nov 29 21:25:47 debian kernel: [devinet_ioctl+1437/1472] devinet_ioctl+0x59d/0x5c0
Nov 29 21:25:47 debian kernel: [inet_ioctl+166/208] inet_ioctl+0xa6/0xd0
Nov 29 21:25:47 debian kernel: [sock_ioctl+248/592] sock_ioctl+0xf8/0x250
Nov 29 21:25:47 debian kernel: [do_ioctl+40/144] do_ioctl+0x28/0x90
Nov 29 21:25:47 debian kernel: [vfs_ioctl+87/496] vfs_ioctl+0x57/0x1f0
Nov 29 21:25:47 debian kernel: [sys_ioctl+57/96] sys_ioctl+0x39/0x60
Nov 29 21:25:47 debian kernel: [syscall_call+7/11] syscall_call+0x7/0xb
Nov 29 21:25:47 debian kernel: handlers:
Nov 29 21:25:47 debian kernel: [usb_hcd_irq+0/80] (usb_hcd_irq+0x0/0x50)
Nov 29 21:25:47 debian last message repeated 3 times
Nov 29 21:25:47 debian kernel: [yenta_interrupt+0/192] (yenta_interrupt+0x0/0xc0)
Nov 29 21:25:47 debian kernel: [pg0+260075488/1065075712] (ath_intr+0x0/0x150 [atheros])
Nov 29 21:25:47 debian kernel: Disabling IRQ #11
Nov 29 21:25:47 debian kernel: atheros: interrupts enabled
Nov 29 21:25:47 debian kernel: atheros: device up and running
--
kind regards,
Mateusz Berezecki
^ permalink raw reply
* Re: [PATCH 07/13]: [NETFILTER]: Fix xfrm lookup in ip_route_me_harder/ip6_route_me_harder
From: Herbert Xu @ 2005-11-29 11:31 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, netfilter-devel, kaber
In-Reply-To: <20051128.234947.117781000.davem@davemloft.net>
On Mon, Nov 28, 2005 at 11:49:47PM -0800, David S. Miller wrote:
>
> I think #1 and #2 can be handled by an on-stack copy of "struct
> ip_options" high enough in the call chain, but #3 is a bit less
> trivial to cope with like that.
>
> It would be nice to kill the IPCB() copy, and give us 12 bytes back in
> skb->cb[] :-)
That would be great. I'm glad that Patrick's patch set is bringing
out potential ways of shrinking sk_buff.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Fw: [Fwd: [Bug 5644] New: NFS v3 TCP 3-way handshake incorrect, iptables blocks access]
From: Jozsef Kadlecsik @ 2005-11-29 10:43 UTC (permalink / raw)
To: Olaf Kirch
Cc: Harald Welte, netdev, netfilter-devel, David S. Miller,
Patrick McHardy
In-Reply-To: <Pine.LNX.4.58.0511250937560.22835@blackhole.kfki.hu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1330 bytes --]
Hi,
On Fri, 25 Nov 2005, Jozsef Kadlecsik wrote:
> On Thu, 24 Nov 2005, Olaf Kirch wrote:
>
> > On Thu, Nov 24, 2005 at 03:08:27PM +0100, Harald Welte wrote:
> > > Jozsef Kadlecsik doesn't recall those patches/changes (even though he's
> > > our "Mr. TCP state tracking" and is indicated as the author of one of
> > > the two patches.
> > >
> > > I also don't recall having seen any of those patches before. But that
> > > doesn't mean all too much, my brain is like a sieve some times.
> >
> > Those patches came out of a discussion on netfilter-devel. Sorry,
> > I don't know exactly when but looking at our CVS log it was Dec 2004.
>
> Yes, it was about a year ago - finally I could dig out the patches from my
> mail archives. I'll prepare an updated version on the weekend and send it
> out to netfilter-devel for reviewing.
Attached is the updated patch. Unfortunately nfsim currently is broken so
I could not test it against the testsuite, but actually it's identical
with the original, not applied patches. The patch takes care both
ip_conntrack and nf_conntrack.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
[-- Attachment #2: tcp-win-half-close.patch --]
[-- Type: TEXT/PLAIN, Size: 5431 bytes --]
Mounting NFS file systems after a (warm) reboot could take a long time if
firewalling and connection tracking was enabled.
The reason is that the NFS clients tends to use the same ports (800 and
counting down). Now on reboot, the server would still have a TCB for an
existing TCP connection client:800 -> server:2049. The client sends a
SYN from port 800 to server:2049, which elicits an ACK from the server.
The firewall on the client drops the ACK because (from its point of
view) the connection is still in half-open state, and it expects to see
a SYNACK.
The client will eventually time out after several minutes.
The following patch corrects this, by accepting ACKs on half open connections
as well.
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
diff -urN --exclude-from=/usr/src/diff.exclude linux-2.6.15-rc2-orig/net/ipv4/netfilter/ip_conntrack_proto_tcp.c linux-2.6.15-rc2-tcp-win/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
--- linux-2.6.15-rc2-orig/net/ipv4/netfilter/ip_conntrack_proto_tcp.c 2005-11-20 04:25:03.000000000 +0100
+++ linux-2.6.15-rc2-tcp-win/net/ipv4/netfilter/ip_conntrack_proto_tcp.c 2005-11-29 11:01:25.000000000 +0100
@@ -272,9 +272,9 @@
* sCL -> sCL
*/
/* sNO, sSS, sSR, sES, sFW, sCW, sLA, sTW, sCL, sLI */
-/*ack*/ { sIV, sIV, sSR, sES, sCW, sCW, sTW, sTW, sCL, sIV },
+/*ack*/ { sIV, sIG, sSR, sES, sCW, sCW, sTW, sTW, sCL, sIV },
/*
- * sSS -> sIV Might be a half-open connection.
+ * sSS -> sIG Might be a half-open connection.
* sSR -> sSR Might answer late resent SYN.
* sES -> sES :-)
* sFW -> sCW Normal close request answered by ACK.
@@ -917,8 +917,12 @@
switch (new_state) {
case TCP_CONNTRACK_IGNORE:
- /* Either SYN in ORIGINAL
- * or SYN/ACK in REPLY. */
+ /* Ignored packets:
+ *
+ * a) SYN in ORIGINAL
+ * b) SYN/ACK in REPLY
+ * c) ACK in reply direction after initial SYN in original.
+ */
if (index == TCP_SYNACK_SET
&& conntrack->proto.tcp.last_index == TCP_SYN_SET
&& conntrack->proto.tcp.last_dir != dir
@@ -985,13 +989,20 @@
}
case TCP_CONNTRACK_CLOSE:
if (index == TCP_RST_SET
- && test_bit(IPS_SEEN_REPLY_BIT, &conntrack->status)
- && conntrack->proto.tcp.last_index == TCP_SYN_SET
+ && ((test_bit(IPS_SEEN_REPLY_BIT, &conntrack->status)
+ && conntrack->proto.tcp.last_index == TCP_SYN_SET)
+ || (!test_bit(IPS_ASSURED_BIT, &conntrack->status)
+ && conntrack->proto.tcp.last_index == TCP_ACK_SET))
&& ntohl(th->ack_seq) == conntrack->proto.tcp.last_end) {
- /* RST sent to invalid SYN we had let trough
- * SYN was in window then, tear down connection.
+ /* RST sent to invalid SYN or ACK we had let trough
+ * at a) and c) above:
+ *
+ * a) SYN was in window then
+ * c) we hold a half-open connection.
+ *
+ * Delete our connection entry.
* We skip window checking, because packet might ACK
- * segments we ignored in the SYN. */
+ * segments we ignored. */
goto in_window;
}
/* Just fall trough */
diff -urN --exclude-from=/usr/src/diff.exclude linux-2.6.15-rc2-orig/net/netfilter/nf_conntrack_proto_tcp.c linux-2.6.15-rc2-tcp-win/net/netfilter/nf_conntrack_proto_tcp.c
--- linux-2.6.15-rc2-orig/net/netfilter/nf_conntrack_proto_tcp.c 2005-11-20 04:25:03.000000000 +0100
+++ linux-2.6.15-rc2-tcp-win/net/netfilter/nf_conntrack_proto_tcp.c 2005-11-29 11:19:00.000000000 +0100
@@ -280,9 +280,9 @@
* sCL -> sCL
*/
/* sNO, sSS, sSR, sES, sFW, sCW, sLA, sTW, sCL, sLI */
-/*ack*/ { sIV, sIV, sSR, sES, sCW, sCW, sTW, sTW, sCL, sIV },
+/*ack*/ { sIV, sIG, sSR, sES, sCW, sCW, sTW, sTW, sCL, sIV },
/*
- * sSS -> sIV Might be a half-open connection.
+ * sSS -> sIG Might be a half-open connection.
* sSR -> sSR Might answer late resent SYN.
* sES -> sES :-)
* sFW -> sCW Normal close request answered by ACK.
@@ -912,8 +912,12 @@
switch (new_state) {
case TCP_CONNTRACK_IGNORE:
- /* Either SYN in ORIGINAL
- * or SYN/ACK in REPLY. */
+ /* Ignored packets:
+ *
+ * a) SYN in ORIGINAL
+ * b) SYN/ACK in REPLY
+ * c) ACK in reply direction after initial SYN in original.
+ */
if (index == TCP_SYNACK_SET
&& conntrack->proto.tcp.last_index == TCP_SYN_SET
&& conntrack->proto.tcp.last_dir != dir
@@ -979,13 +983,20 @@
}
case TCP_CONNTRACK_CLOSE:
if (index == TCP_RST_SET
- && test_bit(IPS_SEEN_REPLY_BIT, &conntrack->status)
- && conntrack->proto.tcp.last_index == TCP_SYN_SET
+ && ((test_bit(IPS_SEEN_REPLY_BIT, &conntrack->status)
+ && conntrack->proto.tcp.last_index == TCP_SYN_SET)
+ || (!test_bit(IPS_ASSURED_BIT, &conntrack->status)
+ && conntrack->proto.tcp.last_index == TCP_ACK_SET))
&& ntohl(th->ack_seq) == conntrack->proto.tcp.last_end) {
- /* RST sent to invalid SYN we had let trough
- * SYN was in window then, tear down connection.
+ /* RST sent to invalid SYN or ACK we had let trough
+ * at a) and c) above:
+ *
+ * a) SYN was in window then
+ * c) we hold a half-open connection.
+ *
+ * Delete our connection entry.
* We skip window checking, because packet might ACK
- * segments we ignored in the SYN. */
+ * segments we ignored. */
goto in_window;
}
/* Just fall trough */
^ permalink raw reply
* [PATCH] orinoco: fix setting power management parameters
From: Pavel Roskin @ 2005-11-29 7:59 UTC (permalink / raw)
To: orinoco-devel, NetDev
Power management parameters could not be set by iwconfig due to
incorrect error handling.
Signed-off-by: Pavel Roskin <proski-mXXj517/zsQ@public.gmane.org>
---
This is a very simple bugfix, and the bug is serious enough, so I'll
appreciate if the patch gets priority handling and goes to 2.6.15. I
have lots of other stuff that can wait until 2.6.16.
diff --git a/drivers/net/wireless/orinoco.c
b/drivers/net/wireless/orinoco.c
index 2032c56..708b146 100644
--- a/drivers/net/wireless/orinoco.c
+++ b/drivers/net/wireless/orinoco.c
@@ -3492,9 +3492,8 @@ static int orinoco_ioctl_setpower(struct
break;
default:
err = -EINVAL;
- }
- if (err)
goto out;
+ }
if (prq->flags & IW_POWER_TIMEOUT) {
priv->pm_on = 1;
--
Regards,
Pavel Roskin
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply related
* Re: [PATCH 07/13]: [NETFILTER]: Fix xfrm lookup in ip_route_me_harder/ip6_route_me_harder
From: David S. Miller @ 2005-11-29 7:49 UTC (permalink / raw)
To: herbert; +Cc: netdev, netfilter-devel, kaber
In-Reply-To: <20051129073441.GA18387@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 29 Nov 2005 18:34:41 +1100
> On Tue, Nov 29, 2005 at 08:02:34AM +0100, Patrick McHardy wrote:
> > It seems in most places where only IPCB(skb)->opt is cleared
> > the entire CB should be cleared. A couple of spots also look
> > completely unnecessary, for example all places clearing the CB
> > before passing the packet to netif_rx. I would expect the next
> > user beeing responsible for clearing the space he needs if
> > neccessary.
>
> Agreed. However, it seems that ip_rcv() only clears the CB options
> if ihl is greater than 5. So until that's changed the people feeding
> netif_rx will have to clear the CB.
I wonder if that stuff can be simplified somehow.
We only use those options in two ways:
1) To process early in input via ip_options_compile()
and the source route check in ip_rcv_finish()
2) To do forwarding processing on options in ip_forward_finish()
and the multicast equivalent in ipmr.c
3) For locally destined packets, when the options are to be
passed to the user via a recvmsg() CMSG.
Well, there is a 4th, which is what we're talking about here,
which is all of the zero'ing out of the thing during encapsulation
which is mostly a waste.
I think #1 and #2 can be handled by an on-stack copy of "struct
ip_options" high enough in the call chain, but #3 is a bit less
trivial to cope with like that.
It would be nice to kill the IPCB() copy, and give us 12 bytes back in
skb->cb[] :-)
^ permalink raw reply
* Re: [PATCH 07/13]: [NETFILTER]: Fix xfrm lookup in ip_route_me_harder/ip6_route_me_harder
From: Herbert Xu @ 2005-11-29 7:34 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <438BFD0A.5040105@trash.net>
On Tue, Nov 29, 2005 at 08:02:34AM +0100, Patrick McHardy wrote:
>
> - IPSKB_MASQUERADED is unused
> - IPSKB_TRANSLATED is unused
> - IPSKB_FORWARDED is used by ipmr in a way that looks broken,
> it expects the flags on the input path to be the same it set
> on the output path.
> - IPSKB_XFRM_TUNNEL_SIZE should be cleared when a packet enters
> the IP stack
Yes that looks correct.
> It seems in most places where only IPCB(skb)->opt is cleared
> the entire CB should be cleared. A couple of spots also look
> completely unnecessary, for example all places clearing the CB
> before passing the packet to netif_rx. I would expect the next
> user beeing responsible for clearing the space he needs if
> neccessary.
Agreed. However, it seems that ip_rcv() only clears the CB options
if ihl is greater than 5. So until that's changed the people feeding
netif_rx will have to clear the CB.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 07/13]: [NETFILTER]: Fix xfrm lookup in ip_route_me_harder/ip6_route_me_harder
From: Patrick McHardy @ 2005-11-29 7:02 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <20051128210628.GA15057@gondor.apana.org.au>
Herbert Xu wrote:
> On Sun, Nov 20, 2005 at 04:31:37PM +0000, Patrick McHardy wrote:
>
>>diff --git a/include/net/ip.h b/include/net/ip.h
>>index 9f09882..377036b 100644
>>--- a/include/net/ip.h
>>+++ b/include/net/ip.h
>>@@ -45,6 +45,7 @@ struct inet_skb_parm
>> #define IPSKB_TRANSLATED 2
>> #define IPSKB_FORWARDED 4
>> #define IPSKB_XFRM_TUNNEL_SIZE 8
>>+#define IPSKB_XFRM_TRANSFORMED 16
>> };
>
>
> My only question about this patch is where should we clear these flags?
> For instance, when ipip/gre transmits a packet, should this flag (and
> perhaps other flags here) be cleared?
Good point. This specific flags should be cleared when a packet
(re-)enters the IP stack, I guess by definition of the cb, this
holds for the other flags as well. Looking at the other flags:
- IPSKB_MASQUERADED is unused
- IPSKB_TRANSLATED is unused
- IPSKB_FORWARDED is used by ipmr in a way that looks broken,
it expects the flags on the input path to be the same it set
on the output path.
- IPSKB_XFRM_TUNNEL_SIZE should be cleared when a packet enters
the IP stack
It seems in most places where only IPCB(skb)->opt is cleared
the entire CB should be cleared. A couple of spots also look
completely unnecessary, for example all places clearing the CB
before passing the packet to netif_rx. I would expect the next
user beeing responsible for clearing the space he needs if
neccessary.
^ permalink raw reply
* Re: [RFC] [PATCH 1/3] ioat: DMA subsystem
From: Andrew Grover @ 2005-11-28 22:57 UTC (permalink / raw)
To: linux-kernel, netdev
In-Reply-To: <20051124150433.GA3590@havoc.gtf.org>
(resending in plain text, trimming CCs)
Thanks to everyone for taking the time to provide feedback. We're
going to go make the changes you suggested and will hopefully have the
code fixed up (and add more docs) in a few weeks.
Regards -- Andy
^ permalink raw reply
* Re: VIA "Velocity" test report - VLAN reception not working
From: Francois Romieu @ 2005-11-28 22:48 UTC (permalink / raw)
To: linux; +Cc: alan, netdev
In-Reply-To: <20051126004057.11284.qmail@science.horizon.com>
linux@horizon.com <linux@horizon.com> :
[...]
> Link detected: no
>
> Kernel 2.6.15-rc2, monolithic. Only local patch is PPSkit-lite, which
> really shouldn't have any effect. No idea about that "Link detected: no"
> line; I'm ssh- ed in over it right now.
The driver does not correctly handle netif_carrier_{on/off}.
[...]
> I saw a bunch of VLAN filtering stuff in the driver that I didn't
> really follow, so perhaps the problem's there.
>
> (I confess I didn't choose super-carefully. It was advertised as having
> Linux support and VLAN support and was reasonably cheap. I didn't
> actually know the chipset until it arrived. And yes, I *am* asking the
> vendor for support, but I expect that'll take a while.)
If you can put the card in a crashme/testme computer, feel free to try
the patches at:
http://www.zoreil.com/~romieu/linux/kernel/2.6.x/2.6.15-rc2/via-velocity/20051128
The patches apply on top of each other. I'd suggest doing a first round
of testing without VLAN to check that the usual flow did not experience
collateral damages.
If it works fine, enable VLAN when the last patch is applied and add
a single vlan with vconfig. If it does not crash, tcpdump + ping in
both direction w/wo VLAN may help fix the issues.
The patches are quite straightforward even if they are poorly described.
--
Ueimor
^ permalink raw reply
* Re: [Patch] 2.4.32 - Neighbour Cache (ARP) State machine bug Fixed
From: Roberto Nibali @ 2005-11-28 21:40 UTC (permalink / raw)
To: Pradeep Vincent; +Cc: linux-kernel, torvalds, netdev
In-Reply-To: <9fda5f510511281257o364acb3gd634f8e412cd7301@mail.gmail.com>
> In 2.4.21, arp code uses gc_timer to check for stale arp cache
> entries. In 2.6, each entry has its own timer to check for stale arp
> cache. 2.4.29 to 2.4.32 kernels (atleast) use neither of these timers.
Regarding NUD_REACHABLE <-> NUD_STALE transition it has a timer check.
Due to the fast path it's not enabled per default. Use neigh_sync() to
check, although I believe the installed tasklet does this for you already.
The knowledgeable netdev people will know better.
> This causes problems in environments where IPs or MACs are reassigned
> - saw this problem on load balancing router based networks that use
> VMACs. Tested this code on load balancing router based networks as
> well as peer-linux systems.
How do you use VMACs in 2.4.x?
> diff -Naur old/net/core/neighbour.c new/net/core/neighbour.c
> --- old/net/core/neighbour.c Wed Nov 23 17:15:30 2005
> +++ new/net/core/neighbour.c Wed Nov 23 17:26:01 2005
> @@ -14,6 +14,7 @@
> * Vitaly E. Lavrov releasing NULL neighbor in neigh_add.
> * Harald Welte Add neighbour cache statistics like rtstat
> * Harald Welte port neighbour cache rework from 2.6.9-rcX
> + * Pradeep Vincent Move neighbour cache entry to stale state
> */
>
> #include <linux/config.h>
> @@ -705,6 +706,14 @@
> neigh_release(n);
> continue;
> }
> +
> + /* Mark it stale - To be reconfirmed later when used */
> + if (n->nud_state&NUD_REACHABLE &&
> + now - n->confirmed > n->parms->reachable_time) {
> + n->nud_state = NUD_STALE;
> + neigh_suspect(n);
> + }
> +
If this is really a problem, why not simply call neigh_sync()? Your
patch also seems to be whitespace damaged.
> write_unlock(&n->lock);
>
> next_elt:
I've cc'd netdev since this is where such patches should go for
discussion; left Linus in the loop (netiquette) although he's nothing to
do with this ;).
Cheers,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
^ permalink raw reply
* Re[4]: net_device + pci_dev question
From: Mateusz Berezecki @ 2005-11-28 21:08 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel, netdev
In-Reply-To: <1133211819.2824.82.camel@laptopd505.fenrus.org>
Hello Arjan,
On 28th november 2005 (22:03:38) you wrote:
> oh it's *your own* netdev...
Yes:-) Sorry for not being precise
> that makes things a lot easier ;)
> it's custom to have driver private data per net dev
> (see netdev_priv() to get it, alloc_etherdev() takes the size of it as
> argument). It's custom to make that private data a struct in which you
> can store the pci device pointer yourself, as well as any other per card
> data that you need to store
Ok, I will do it like that then. Thank you for the explanation on this
issue.
kind regards,
Mateusz Berezecki
^ permalink raw reply
* Re: [PATCH 07/13]: [NETFILTER]: Fix xfrm lookup in ip_route_me_harder/ip6_route_me_harder
From: Herbert Xu @ 2005-11-28 21:06 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <20051120163137.16666.924.sendpatchset@localhost.localdomain>
On Sun, Nov 20, 2005 at 04:31:37PM +0000, Patrick McHardy wrote:
>
> diff --git a/include/net/ip.h b/include/net/ip.h
> index 9f09882..377036b 100644
> --- a/include/net/ip.h
> +++ b/include/net/ip.h
> @@ -45,6 +45,7 @@ struct inet_skb_parm
> #define IPSKB_TRANSLATED 2
> #define IPSKB_FORWARDED 4
> #define IPSKB_XFRM_TUNNEL_SIZE 8
> +#define IPSKB_XFRM_TRANSFORMED 16
> };
My only question about this patch is where should we clear these flags?
For instance, when ipip/gre transmits a packet, should this flag (and
perhaps other flags here) be cleared?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Re[2]: net_device + pci_dev question
From: Arjan van de Ven @ 2005-11-28 21:03 UTC (permalink / raw)
To: Mateusz Berezecki; +Cc: linux-kernel, netdev
In-Reply-To: <1653628458.20051128215644@gmail.com>
On Mon, 2005-11-28 at 21:56 +0100, Mateusz Berezecki wrote:
> Hello Arjan,
>
> On 27th november 2005 (22:25:13) you wrote:
>
> > On Sun, 2005-11-27 at 20:58 +0100, Mateusz Berezecki wrote:
> >> Hello List!
> >>
> >> Having only net_device pointer is it possible to retrieve associated pci_dev
> >> pointer basing on this information only?
>
> > what do you need it for?
>
> for pci_alloc_consistent() which takes pci_dev as a first argument to
> allocate contiguous memory block for DMA transfers. I just realized
oh it's *your own* netdev...
that makes things a lot easier ;)
it's custom to have driver private data per net dev
(see netdev_priv() to get it, alloc_etherdev() takes the size of it as
argument). It's custom to make that private data a struct in which you
can store the pci device pointer yourself, as well as any other per card
data that you need to store
^ permalink raw reply
* Re[2]: net_device + pci_dev question
From: Mateusz Berezecki @ 2005-11-28 20:56 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: linux-kernel, netdev
In-Reply-To: <1133126713.2853.45.camel@laptopd505.fenrus.org>
Hello Arjan,
On 27th november 2005 (22:25:13) you wrote:
> On Sun, 2005-11-27 at 20:58 +0100, Mateusz Berezecki wrote:
>> Hello List!
>>
>> Having only net_device pointer is it possible to retrieve associated pci_dev
>> pointer basing on this information only?
> what do you need it for?
for pci_alloc_consistent() which takes pci_dev as a first argument to
allocate contiguous memory block for DMA transfers. I just realized
when I saw your answer that I might have moved the memory allocation to
some routine which is called earlier in time which has access to
pci_dev pointer directly, like net_device->init IIRC. But I'm not
really sure if that would be correct solution.
> (and.. what if the nic isn't a pci one?)
Uh... it's cardbus interface and still uses pci_* stuff without problems. (?)
Do I miss something?
kind regards
Mateusz Berezecki
^ permalink raw reply
* (no subject)
From: declarator @ 2005-11-28 20:08 UTC (permalink / raw)
^ permalink raw reply
* Re: KERNEL: assertion (!sk->sk_forward_alloc) failed
From: Jesse Brandeburg @ 2005-11-28 16:44 UTC (permalink / raw)
To: Miquel van Smoorenburg, nipsy; +Cc: linux-kernel, Kernel Netdev Mailing List
In-Reply-To: <dmf1kn$t2s$1@news.cistron.nl>
This should really be on netdev, so I copied it.
On 11/28/05, Miquel van Smoorenburg <miquels@cistron.nl> wrote:
> In article <20051128123601.GA32346@king.bitgnome.net>,
> Mark Nipper <nipsy@bitgnome.net> wrote:
> > I received the following in my system logs recently:
> >---
> >Nov 27 22:56:20 king kernel: KERNEL: assertion (!sk->sk_forward_alloc)
> >failed at net/core/stream.c (279)
> >Nov 27 22:56:20 king kernel: KERNEL: assertion (!sk->sk_forward_alloc)
> >failed at net/ipv4/af_inet.c (151)
> >
> > All I could find related to this was some potential bugs
> >mentioned in 2.6.9 and in particular with relation to TSO.
> >However, I'm running a vanilla 2.6.13.4 at the moment. But, I do
> >have an e1000 and checking ethtool does show TSO on.
>
> I'm seeing the same on 2.6.14.2, also with e1000. It wasn't there on
> 2.6.11.12 which I was running previously.
I don't believe this is related to e1000 because we don't mess with
the sock (sk) struct. Did you try disabling TSO? I bet the netdev
guys can help.
^ 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