* Re: Sis900 and VLAN 8021q.o incompatible/MTU troubles
From: Francois Romieu @ 2005-05-12 20:37 UTC (permalink / raw)
To: Axel Reinhold; +Cc: netdev
In-Reply-To: <200505120743.j4C7hWKI011583@l0p.le-gobw.de>
Axel Reinhold <Axel.Reinhold@le-gobw.de> :
[...]
> my sis900 is running fine in standard mode. Together with 8021q.o
> i get all kinds of troubles - for example samba is no more working at
> all - without vlan everything is fine - with vlans everything basically
> works - but only to a certain point, then it screws up.
It can help if you provide:
- the kernel revision;
- some vlan context (commands issued ? vlan only or mixed config ?);
- the range of working size for simple ping.
--
Ueimor
^ permalink raw reply
* Re: issue with new TCP TSO stuff
From: Andi Kleen @ 2005-05-12 20:26 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20050512.130341.82102354.davem@davemloft.net>
On Thu, May 12, 2005 at 01:03:41PM -0700, David S. Miller wrote:
> From: Andi Kleen <ak@muc.de>
> Subject: Re: issue with new TCP TSO stuff
> Date: 12 May 2005 22:02:51 +0200,Thu, 12 May 2005 22:02:51 +0200
>
> > Sure, but did you verify it was the actual problem? (e.g. with a profiler)
> > If the cache line the atomic operation is done on is EXCLUSIVE to the
> > CPU then it should not take *that* long to do the atomic operations.
>
> Such issues cannot be measured like that, they tend to make
> other operations slower by inducing cache misses elsewhere.
Atomic operations, especially with cache misses, normally show in a fine
grained profile. They also don't cause additional cache misses over
non atomic writes.
> I used my brain to analyze this slowdown, instead of the
> computer, I'm sorry if that disturbs you :-)
What disturbs me is your conclusion :)
-Andi
^ permalink raw reply
* Re: issue with new TCP TSO stuff
From: David S. Miller @ 2005-05-12 20:13 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <E1DWAZg-0006aD-00@gondolin.me.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: issue with new TCP TSO stuff
Date: Thu, 12 May 2005 20:05:48 +1000
> What we could do is get the TSO drivers to all implement NETIF_F_FRAGLIST.
> Once they do that, you can simply chain up the skb's and send it off to
> them. The coalescing will need to be done in the drivers. However, that's
> not too bad because coalescing only has to be done at the skb boundaries.
>
> In fact, this is how we can simplify the unwinding stuff in your
> skb_append_pages function. Because the coalescing only needs to occur
> between skb's, you only need to check the first frag to know whether it
> can be coalesced or not. This means that the unwinding stuff can mostly
> go away.
>
> We'll have to watch out for retransmissions of the frame with a non-null
> frag_list pointer. They will need to be copied if their clone is still
> hanging around.
Yes, we can just add a frag_list pointer check to the skb_cloned()
tests we do when cons'ing up retransmit SKBs for tcp_transmit_skb().
But this still has the early free problem, I think. If an ACK
comes in which releases an SKB on the chain, while the driver
is still working with that chain, we cannot free the SKB. We
have to do it some time later.
One way to prevent that would be to do an skb_get() on every
SKB in the chain, but then we're back to the original problem
of all the extra atomic operations.
A secondary point is that I'd like to use a name other than
NETIF_F_FRAGLIST because people are super confused as to what this
device flag even means. Some people confuse it with NETIF_F_SG,
others thing it takes a huge UDP frame and fragments it into MTU sized
IP frames and checksums the whole thing. None of which are true.
Loopback is the only driver which supports this properly, by
simply doing nothing with the packet :-)
So back to the main point, we are in quite a conundrum. The whole
point of TSO is to offload the segmentation overhead, but we're in
fact making the TCP output engine more expensive for the TSO path.
I've also considered a longer term idea where we store the write queue
in some minimal abstract format, instead of a list of SKBs. Just a
data collection and some sequence numbers. But that would be a huge
change with questionable gains.
^ permalink raw reply
* Re: issue with new TCP TSO stuff
From: David S. Miller @ 2005-05-12 20:03 UTC (permalink / raw)
To: ak; +Cc: netdev
In-Reply-To: <20050512200251.GA72662@muc.de>
From: Andi Kleen <ak@muc.de>
Subject: Re: issue with new TCP TSO stuff
Date: 12 May 2005 22:02:51 +0200,Thu, 12 May 2005 22:02:51 +0200
> Sure, but did you verify it was the actual problem? (e.g. with a profiler)
> If the cache line the atomic operation is done on is EXCLUSIVE to the
> CPU then it should not take *that* long to do the atomic operations.
Such issues cannot be measured like that, they tend to make
other operations slower by inducing cache misses elsewhere.
I used my brain to analyze this slowdown, instead of the
computer, I'm sorry if that disturbs you :-)
^ permalink raw reply
* Re: issue with new TCP TSO stuff
From: David S. Miller @ 2005-05-12 19:26 UTC (permalink / raw)
To: ak; +Cc: netdev
In-Reply-To: <m1sm0sttvy.fsf@muc.de>
From: Andi Kleen <ak@muc.de>
Subject: Re: issue with new TCP TSO stuff
Date: Thu, 12 May 2005 16:13:05 +0200
> Are you sure a few atomic_inc/dec are really causing noticeable
> slowdown? That would surprise me unless you have lots of cache line
> bouncing on a MP system.
It's about 7 or 8 times as many atomic gets and puts on pages compared
to the older code (with an 8K page size).
Some of it we can't get rid of, because we keep a normal write queue
segmented set of SKBs around.
But the TSO part we can eliminate.
^ permalink raw reply
* Re: Questions wrt QoS code on Linux
From: Jonathan Day @ 2005-05-12 19:07 UTC (permalink / raw)
To: Thomas Graf; +Cc: netdev
I'll deal with the first part first, as it's the
easiest. :)
Very crudely, you can look at networking as being
carried out in two stages - collecing the packets to
be sent, and then sending them.
Something like CBQ tells the machine how to go about
collecting the packets, by creating a number of queues
into which the packets can be placed.
A distinct section of code for classifying packets is
used to help the collector to identify the different
types of packet so that the collector can handle them
correctly.
You've actually got another bit in there which
determines the ordering of the packets. a FIFO queue
won't be ordered the same as a PRIO queue, for
example.
A completely seperate stage is then needed to actually
gather the packets from the queue(s). You might drain
one queue completely before moving onto the next, you
might work in a round-robin manner, you might even
give a queue a fixed timeslice and grab as many
packets as possible within that slice before moving
on.
An additional section handles the case where the
network is overloaded. You can drop packets early, by
using systems like RED, BLUE, GREEN or BLACK. (Of
these, only RED and the variant GRED are in Linux at
the moment.)
At present, the Linux QoS menu is confusing. CBQ is
listed as a packet scheduler, when it in fact queues
the packets, rather than schedules them. RED is marked
as a queue, whereas it really filters, it doesn't
queue.
My proposal is to do the following:
1. Rename the sched directory to qos
2. Add a sched subdirectory and move the schedulers
into it
3. Add a queue subdirectory and move the queue
handlers into it
4. Add a classifier subdirectory and move the packet
classifiers into it
5. Add a processor subdirectory and move all code for
processing packets (such as RED) into it
Everything else would be left where it was. Help files
and menu syntax would be changed to reflect what the
option actually did. I would probably want to change
the symbols as well, to make it easier to follow in
the code as to what is happening.
--- Thomas Graf <tgraf@suug.ch> wrote:
> * Jonathan Day
>
<20050512044040.61360.qmail@web31504.mail.mud.yahoo.com>
> 2005-05-11 21:40
> > First off, I notice that all the code is lumped
> > together and much of it is generically labelled
> > "scheduling". I'm wondering if it might not be
> more
> > readable if the list were divided into four
> sections -
> > "queueing disciplines", "scheduling", "packet
> > classification" and "everything else". Would that
> seem
> > sensible? Or would it risk making things
> > over-structured?
>
> Sounds reasonable although I'm not sure if I
> understand
> the difference between "scheduling" and "qdisc".
__________________________________
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
http://mobile.yahoo.com/learn/mail
^ permalink raw reply
* Re: tg3 support broken on PPC, a workaround
From: Manuel Perez Ayala @ 2005-05-12 18:06 UTC (permalink / raw)
To: Rick Jones; +Cc: mchan, netdev
In-Reply-To: <4283853C.9070608@hp.com>
Rick Jones <rick.jones2@hp.com> wrote:
> Since both read and write boundaries are being changed, doesn't
> netperf need to be run in each direction?
I have two twin systems: PowerMac G4 both with 3com 3c996T connected to a 3com
gigabit switch, same memomry, same disk, same os. I have compiled and
installed
the driver with the harcoded best dma configuration on both.
These are the netperf results from one side:
afs02-i:/usr/share/doc/netperf# netperf -H afs01-i
TCP STREAM TEST to afs01-i
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 671.71
And these are the netperf results from the other side:
afs01-i:~# netperf -H afs02-i
TCP STREAM TEST to afs02-i
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 667.96
And on the local device:
afs01-i:~# netperf -H afs01-i
TCP STREAM TEST to afs01-i
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 1834.33
----------
Manuel Perez Ayala
mperaya@alcazaba.unex.es
Facultad de Biblioteconomía y Documentación
Universidad de Extremadura
^ permalink raw reply
* Re: tg3 support broken on PPC, a workaround
From: Rick Jones @ 2005-05-12 16:33 UTC (permalink / raw)
To: Manuel Perez Ayala; +Cc: Michael Chan, netdev
In-Reply-To: <20050512112827.7danjtr4kckg8swc@158.49.151.11>
Since both read and write boundaries are being changed, doesn't netperf need to
be run in each direction?
rick jones
^ permalink raw reply
* More 'Badness in dst_release' messages
From: Jim Minter @ 2005-05-12 16:11 UTC (permalink / raw)
To: netdev
Hello,
I'm getting 'Badness in dst_release' messages and associated occasional
panics (dereferencing invalidated dst pointers), and am having some
problems tracking down the cause. Could anyone spare a moment to advise
me what I can do next to debug and resolve the issue?
I'm running vanilla kernel-2.6.11, x86_64 SMP, on a single-CPU (but
hyperthreaded) EM64T Xeon. I'm using IPv4, and that's where all the
problems seem to be. IPv6 isn't compiled in; XFRM and bridging are, but
I'm not using either. I've had similar problems with an equivalent 2.6.10
setup.
These are all the types of backtraces that I'm getting (bear in mind that
because it's x86_64, there's no CONFIG_FRAME_POINTER, so the backtraces
are noisy). I have verified by hand that the top address in each
corresponds to a dst_release call in the code, though.
Call Trace:<ffffffff803370fc>{tcp_v4_connect+1932}
<ffffffff802fe408>{lock_sock+200}
<ffffffff803464b2>{inet_stream_connect+226}
<ffffffff802395e8>{sprintf+136}
<ffffffff802fe408>{lock_sock+200}
<ffffffff80179a1b>{fget+91}
<ffffffff802fc92a>{sys_connect+122}
<ffffffff802fb380>{sockfd_lookup+32}
<ffffffff802fcef4>{sys_getsockopt+132}
<ffffffff8010e4ca>{system_call+126}
[corresponds to the __sk_dst_set(sk, &rt->u.dst); in tcp_v4_connect():
this seems to be curious to me]
Call Trace:<ffffffff80345cbb>{inet_sock_destruct+555}
<ffffffff802fd93e>{sk_free+30}
<ffffffff803460d8>{inet_release+88}
<ffffffff802fb4a1>{sock_release+33}
<ffffffff802fc175>{sock_close+53}
<ffffffff801798c2>{__fput+98}
<ffffffff801781ee>{filp_close+126}
<ffffffff801782a3>{sys_close+147}
<ffffffff8010e4ca>{system_call+126}
Call Trace:<IRQ> <ffffffff802ffc76>{__kfree_skb+102}
<ffffffff88028675>{:e1000:e1000_clean+389}
<ffffffff80331e13>{tcp_transmit_skb+1651}
<ffffffff802fea2f>{sk_reset_timer+15}
<ffffffff80305e94>{net_rx_action+132}
<ffffffff8013af51>{__do_softirq+113}
<ffffffff8013b005>{do_softirq+53}
<ffffffff801113c7>{do_IRQ+71}
<ffffffff8010ea71>{ret_from_intr+0} <EOI>
<ffffffff8010c8c6>{mwait_idle+86}
<ffffffff8010c84f>{cpu_idle+63}
Any suggestions would be much appreciated as I haven't been able yet to
replicate the bug elsewhere. Although I don't have physical access to the
machine in question, I am able to arrange for debugging kernels to be put
on it, if I know what to look for!
Many thanks,
Jim Minter <jim@ferrypath.org.uk>
^ permalink raw reply
* Re: issue with new TCP TSO stuff
From: Andi Kleen @ 2005-05-12 14:13 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20050511.223036.39664020.davem@davemloft.net>
"David S. Miller" <davem@davemloft.net> writes:
>
> This shows up in testing where the connection is application limited.
> For example, an "scp" goes more slowly over TSO now, there are less
> cpu cycles available for the encryption.
>
> It's tricky to come up with a scheme to fix this. I would love to be
> able to not do the page grabs/releases in the actual TSO frame. I
> really haven't come up with a clean way to do that however.
Are you sure a few atomic_inc/dec are really causing noticeable
slowdown? That would surprise me unless you have lots of cache line
bouncing on a MP system.
What CPU did you test it on? Does it happen with only a single CPU?
And did you actually see them in some profile?
Assuming the struct page is in cache the P4 core is the slowest at
that that I know, but even on that one it should be in the noise on
the other overhead of talking to a NIC on a PCI bus.
Perhaps it is something else..
-Andi
^ permalink raw reply
* Re: Questions wrt QoS code on Linux
From: Thomas Graf @ 2005-05-12 12:20 UTC (permalink / raw)
To: Jonathan Day; +Cc: netdev
In-Reply-To: <20050512044040.61360.qmail@web31504.mail.mud.yahoo.com>
* Jonathan Day <20050512044040.61360.qmail@web31504.mail.mud.yahoo.com> 2005-05-11 21:40
> First off, I notice that all the code is lumped
> together and much of it is generically labelled
> "scheduling". I'm wondering if it might not be more
> readable if the list were divided into four sections -
> "queueing disciplines", "scheduling", "packet
> classification" and "everything else". Would that seem
> sensible? Or would it risk making things
> over-structured?
Sounds reasonable although I'm not sure if I understand
the difference between "scheduling" and "qdisc".
> Secondly, there seem to be an awful lot of QoS methods
> not represented in Linux. Implementing them all might
> easily double the kernel size for not very much
> benefit, even if anyone could find the time to do so.
> On the other hand, there are probably some that are
> under development and others high on the wishlist.
> Does anyone know what projects are currently underway
> or being planned?
We're lacking feedback on this subject from the users, we hear
a lot from the typical home user wanting to get some control
over his ADSL/cable link but not much from other areas.
There have been some recent additions, mainly Jamal's actions
and my small ematch API. They perfectly serve as a base to
solve more complex problems but are still in a early stage
of completness and documentation.
The current development direction is to get away from big and
complex problem solvers and focus on tiny and simple components
that can be put together to solve problems more individually.
^ permalink raw reply
* Re: [PATCH 4/4] iseries_veth: Cleanup skbs to prevent unregister_netdevice() hanging
From: David Gibson @ 2005-05-12 11:28 UTC (permalink / raw)
To: Michael Ellerman
Cc: Andrew Morton, netdev, Jeff Garzik, linux-kernel, PPC64-dev
In-Reply-To: <200505121809.45419.michael@ellerman.id.au>
On Thu, May 12, 2005 at 06:09:45PM +1000, Michael Ellerman wrote:
> Hi Andrew, Jeff,
>
> The iseries_veth driver is badly behaved in that it will keep TX packets
> hanging around forever if they're not ACK'ed and the queue never fills up.
>
> This causes the unregister_netdevice code to wait forever when we try to take
> the device down, because there's still skbs around with references to our
> struct net_device.
>
> There's already code to cleanup any un-ACK'ed packets in veth_stop_connection()
> but it's being called after we unregister the net_device, which is too late.
>
> The fix is to rearrange the module exit function so that we cleanup any
> outstanding skbs and then unregister the driver.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Nice catch.
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/people/dgibson
^ permalink raw reply
* Re: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122)
From: Herbert Xu @ 2005-05-12 11:07 UTC (permalink / raw)
To: Tommy Christensen; +Cc: Ken-ichirou MATSUZAWA, netdev, David S. Miller
In-Reply-To: <1115895482.30106.95.camel@tsc-6.cph.tpack.net>
On Thu, May 12, 2005 at 12:58:03PM +0200, Tommy Christensen wrote:
>
> Signed-off-by: Tommy S. Christensen <tommy.christensen@tpack.net>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks,
--
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: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122)
From: Tommy Christensen @ 2005-05-12 10:58 UTC (permalink / raw)
To: Herbert Xu; +Cc: Ken-ichirou MATSUZAWA, netdev, David S. Miller
In-Reply-To: <20050512104229.GB25631@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 235 bytes --]
On Thu, 2005-05-12 at 12:42, Herbert Xu wrote:
> For new comments please use the following style which is more standard
> in the kernel these days:
Sure, no problem.
Signed-off-by: Tommy S. Christensen <tommy.christensen@tpack.net>
[-- Attachment #2: Type: text/x-patch, Size: 699 bytes --]
diff -ru linux-2.6.12-rc4/net/netlink/af_netlink.c linux-2.6.12-work/net/netlink/af_netlink.c
--- linux-2.6.12-rc4/net/netlink/af_netlink.c 2005-05-11 11:10:20.000000000 +0200
+++ linux-2.6.12-work/net/netlink/af_netlink.c 2005-05-12 12:55:32.374430076 +0200
@@ -735,11 +735,15 @@
sock_hold(sk);
if (p->skb2 == NULL) {
- if (atomic_read(&p->skb->users) != 1) {
+ if (skb_shared(p->skb)) {
p->skb2 = skb_clone(p->skb, p->allocation);
} else {
- p->skb2 = p->skb;
- atomic_inc(&p->skb->users);
+ p->skb2 = skb_get(p->skb);
+ /*
+ * skb ownership may have been set when
+ * delivered to a previous socket.
+ */
+ skb_orphan(p->skb2);
}
}
if (p->skb2 == NULL) {
^ permalink raw reply
* Re: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122)
From: Herbert Xu @ 2005-05-12 10:42 UTC (permalink / raw)
To: Tommy Christensen; +Cc: Ken-ichirou MATSUZAWA, netdev, David S. Miller
In-Reply-To: <1115891887.30106.89.camel@tsc-6.cph.tpack.net>
On Thu, May 12, 2005 at 11:58:07AM +0200, Tommy Christensen wrote:
>
> Yes, I like this better. Good idea.
I see that you've given up on the minimalism :)
> Signed-off-by: Tommy S. Christensen <tommy.christensen@tpack.net>
It looks good to me too except for that comment of yours :)
> diff -ru linux-2.6.12-rc4/net/netlink/af_netlink.c linux-2.6.12-work/net/netlink/af_netlink.c
> --- linux-2.6.12-rc4/net/netlink/af_netlink.c 2005-05-11 11:10:20.000000000 +0200
> +++ linux-2.6.12-work/net/netlink/af_netlink.c 2005-05-12 11:51:57.427312857 +0200
> @@ -735,11 +735,13 @@
>
> sock_hold(sk);
> if (p->skb2 == NULL) {
> - if (atomic_read(&p->skb->users) != 1) {
> + if (skb_shared(p->skb)) {
> p->skb2 = skb_clone(p->skb, p->allocation);
> } else {
> - p->skb2 = p->skb;
> - atomic_inc(&p->skb->users);
> + p->skb2 = skb_get(p->skb);
> + /* skb ownership may have been set when
> + delivered to a previous socket. */
For new comments please use the following style which is more standard
in the kernel these days:
/*
* blah blah blah ....
* for comments that don't fit on a single line.
*/
Thanks,
--
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] netlink: defer socket destruction a bit
From: Herbert Xu @ 2005-05-12 10:36 UTC (permalink / raw)
To: Tommy Christensen; +Cc: David S. Miller, netdev, Ken-ichirou MATSUZAWA
In-Reply-To: <1115891821.30106.86.camel@tsc-6.cph.tpack.net>
On Thu, May 12, 2005 at 11:57:01AM +0200, Tommy Christensen wrote:
>
> I moved the call to skb_orphan in the other patch, as you
> suggested. I think that also makes this patch safe as it is.
>
> Right?
Indeed it is. This also means that we don't hold onto the skb's
share of rmalloc quota for an excessive amount of time if the
number of broadcast sockets is large.
Thanks,
--
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
* [PATCH] use lookup_create in af_unix
From: Christoph Hellwig @ 2005-05-12 10:23 UTC (permalink / raw)
To: davem; +Cc: netdev
currently it opencodes it, but that's in the way of chaning the
lookup_hash interface.
I'd prefer to disallow modular af_unix over exporting lookup_create,
but I'll leave that to you.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: fs/namei.c
===================================================================
--- eed337ef5e9ae7d62caa84b7974a11fddc7f06e0/fs/namei.c (mode:100644 sha1:defe6781e003c208fc0a4b6e92bcf1dc2a0465de)
+++ uncommitted/fs/namei.c (mode:100644)
@@ -1580,6 +1580,7 @@
fail:
return dentry;
}
+EXPORT_SYMBOL_GPL(lookup_create);
int vfs_mknod(struct inode *dir, struct dentry *dentry, int mode, dev_t dev)
{
Index: net/unix/af_unix.c
===================================================================
--- eed337ef5e9ae7d62caa84b7974a11fddc7f06e0/net/unix/af_unix.c (mode:100644 sha1:c478fc8db7768428580d23381856fa53fa31add2)
+++ uncommitted/net/unix/af_unix.c (mode:100644)
@@ -770,33 +770,12 @@
err = path_lookup(sunaddr->sun_path, LOOKUP_PARENT, &nd);
if (err)
goto out_mknod_parent;
- /*
- * Yucky last component or no last component at all?
- * (foo/., foo/.., /////)
- */
- err = -EEXIST;
- if (nd.last_type != LAST_NORM)
- goto out_mknod;
- /*
- * Lock the directory.
- */
- down(&nd.dentry->d_inode->i_sem);
- /*
- * Do the final lookup.
- */
- dentry = lookup_hash(&nd.last, nd.dentry);
+
+ dentry = lookup_create(&nd, 0);
err = PTR_ERR(dentry);
if (IS_ERR(dentry))
goto out_mknod_unlock;
- err = -ENOENT;
- /*
- * Special case - lookup gave negative, but... we had foo/bar/
- * From the vfs_mknod() POV we just have a negative dentry -
- * all is fine. Let's be bastards - you had / on the end, you've
- * been asking for (non-existent) directory. -ENOENT for you.
- */
- if (nd.last.name[nd.last.len] && !dentry->d_inode)
- goto out_mknod_dput;
+
/*
* All right, let's create it.
*/
@@ -845,7 +824,6 @@
dput(dentry);
out_mknod_unlock:
up(&nd.dentry->d_inode->i_sem);
-out_mknod:
path_release(&nd);
out_mknod_parent:
if (err==-EEXIST)
^ permalink raw reply
* Re: issue with new TCP TSO stuff
From: Herbert Xu @ 2005-05-12 10:05 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20050511.223036.39664020.davem@davemloft.net>
Hi Dave:
I've got a number of comments for your patch which I will send once
I've finished reading it all.
David S. Miller <davem@davemloft.net> wrote:
>
> I don't know, maybe we can do something clever with the
> skb_shinfo(skb)->frag_list pointer.
This was in fact going to be one of my comments :)
What we could do is get the TSO drivers to all implement NETIF_F_FRAGLIST.
Once they do that, you can simply chain up the skb's and send it off to
them. The coalescing will need to be done in the drivers. However, that's
not too bad because coalescing only has to be done at the skb boundaries.
In fact, this is how we can simplify the unwinding stuff in your
skb_append_pages function. Because the coalescing only needs to occur
between skb's, you only need to check the first frag to know whether it
can be coalesced or not. This means that the unwinding stuff can mostly
go away.
We'll have to watch out for retransmissions of the frame with a non-null
frag_list pointer. They will need to be copied if their clone is still
hanging around.
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: assertion (!atomic_read(&sk->sk_rmem_alloc)) failed at net/netlink/af_netlink.c (122)
From: Tommy Christensen @ 2005-05-12 9:58 UTC (permalink / raw)
To: Herbert Xu; +Cc: Ken-ichirou MATSUZAWA, netdev, David S. Miller
In-Reply-To: <20050511231751.GA21781@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 269 bytes --]
On Thu, 2005-05-12 at 01:17, Herbert Xu wrote:
> BTW, we could also move the skb_orphan to the skb_get path since the
> cloned packets don't need the orphan call.
Yes, I like this better. Good idea.
Signed-off-by: Tommy S. Christensen <tommy.christensen@tpack.net>
[-- Attachment #2: Type: text/x-patch, Size: 687 bytes --]
diff -ru linux-2.6.12-rc4/net/netlink/af_netlink.c linux-2.6.12-work/net/netlink/af_netlink.c
--- linux-2.6.12-rc4/net/netlink/af_netlink.c 2005-05-11 11:10:20.000000000 +0200
+++ linux-2.6.12-work/net/netlink/af_netlink.c 2005-05-12 11:51:57.427312857 +0200
@@ -735,11 +735,13 @@
sock_hold(sk);
if (p->skb2 == NULL) {
- if (atomic_read(&p->skb->users) != 1) {
+ if (skb_shared(p->skb)) {
p->skb2 = skb_clone(p->skb, p->allocation);
} else {
- p->skb2 = p->skb;
- atomic_inc(&p->skb->users);
+ p->skb2 = skb_get(p->skb);
+ /* skb ownership may have been set when
+ delivered to a previous socket. */
+ skb_orphan(p->skb2);
}
}
if (p->skb2 == NULL) {
^ permalink raw reply
* Re: [PATCH] netlink: defer socket destruction a bit
From: Tommy Christensen @ 2005-05-12 9:57 UTC (permalink / raw)
To: Herbert Xu; +Cc: David S. Miller, netdev, Ken-ichirou MATSUZAWA
In-Reply-To: <20050511230309.GA21547@gondor.apana.org.au>
On Thu, 2005-05-12 at 01:03, Herbert Xu wrote:
> On Thu, May 12, 2005 at 12:35:06AM +0200, Tommy Christensen wrote:
> >
> > No, skb2 cannot be shared with a listening socket. As I read the code,
> > it can only be non-null when delivery has failed.
>
> What about this code path:
>
> 1) skb2 = skb, refcnt++.
> 2) Devliered to socket 1.
> 3) Socket 1 frees skb through recvmsg.
> 4) skb2 = skb, refcnt++.
> 5) Delivery fails.
>
> Now skb2 is identical to skb and they both refer to socket 1.
You're right, Herbert. The interception by recvmsg has to be
considered in this case also. Tricky.
I moved the call to skb_orphan in the other patch, as you
suggested. I think that also makes this patch safe as it is.
Right?
-Tommy
^ permalink raw reply
* Re: tg3 support broken on PPC, a workaround
From: Manuel Perez Ayala @ 2005-05-12 9:28 UTC (permalink / raw)
To: Michael Chan
In-Reply-To: <1115825081.8570.93.camel@rh4>
Michael Chan <mchan@broadcom.com> wrote:
>
> This tells me that your cache line size is 32 bytes.
>
> Let's try some experiments and see what works and what doesn't. Please
> hardcode the following values in tp->dma_rwctrl before it is written to
> the register:
>
Net performance of the working driver:
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 415.08
Tryouts:
> 1. DMA read/write boundaries set to 256:
>
> tp->dma_rwctrl = 0x76ff2d0f;
>
tg3.c:v3.10 (September 14, 2004)
PCI: Enabling device 0001:10:13.0 (0014 -> 0016)
tg3: tg3_test_dma DMA read/write boundaries set to 256: 76FF2D0F
eth1: Tigon3 [partno(BCM95700A6) rev 7102 PHY(5401)] (PCI:33MHz:64-bit)
10/100/1000BaseT Ethernet 00:04:76:3b:51:ae
eth1: RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] WireSpeed[0] TSOcap[0]
--> DATA CORRUPTION
> 2. DMA read boundary 256, write boundary 32:
>
> tp->dma_rwctrl = 0x76ff150f;
>
tg3.c:v3.10 (September 14, 2004)
PCI: Enabling device 0001:10:13.0 (0014 -> 0016)
tg3: tg3_test_dma DMA read boundary 256, write boundary 32: 76FF150F
eth1: Tigon3 [partno(BCM95700A6) rev 7102 PHY(5401)] (PCI:33MHz:64-bit)
10/100/1000BaseT Ethernet 00:04:76:3b:51:ae
eth1: RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] WireSpeed[0] TSOcap[0]
--> DATA OK
Net Performance:
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 647.19
The net performance is grown over a 50% from the working driver default
setting.
> 3. DMA read boundary 32, write boundary 256
>
> tp->dma_rwctrl = 0x76ff2a0f;
>
tg3.c:v3.10 (September 14, 2004)
PCI: Enabling device 0001:10:13.0 (0014 -> 0016)
tg3: tg3_test_dma DMA read boundary 32, write boundary 256: 76FF2A0F
eth1: Tigon3 [partno(BCM95700A6) rev 7102 PHY(5401)] (PCI:33MHz:64-bit)
10/100/1000BaseT Ethernet 00:04:76:3b:51:ae
eth1: RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] WireSpeed[0] TSOcap[0]
--> DATA CORRUPTION
No net performance impact.
> 4. Let's also try without asserting all byte enables:
>
> tp->dma_rwctrl = 0x763f2d0f;
>
tg3.c:v3.10 (September 14, 2004)
PCI: Enabling device 0001:10:13.0 (0014 -> 0016)
tg3: tg3_test_dma without asserting all byte enables: 763F2D0F
eth1: Tigon3 [partno(BCM95700A6) rev 7102 PHY(5401)] (PCI:33MHz:64-bit)
10/100/1000BaseT Ethernet 00:04:76:3b:51:ae
eth1: RXcsums[1] LinkChgREG[1] MIirq[1] ASF[0] Split[0] WireSpeed[0] TSOcap[0]
--> DATA CORRUPTION
Net performance like DMA read boundary 256, write boundary 32:, over 50%, but
with data corruption.
I've only tried whith the working driver (2.6.8 with dma code from 2.6.7). Do
you need I also try the original 2.6.8?
Before my initial report, I've tried the broadcom driver 8.1.55 with no
success
and the same kind of data corruption. Then I focused on the tg3 driver.
----------
Manuel Perez Ayala
mperaya@alcazaba.unex.es
Facultad de Biblioteconomía y Documentación
Universidad de Extremadura
^ permalink raw reply
* Re: 2.4.30-hf1 do_IRQ stack overflows
From: Manfred Schwarb @ 2005-05-12 8:44 UTC (permalink / raw)
To: Herbert Xu; +Cc: marcelo.tosatti, linux-kernel, davem, netdev
In-Reply-To: <E1DVyuq-0005Sf-00@gondolin.me.apana.org.au>
> Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
> >
> > May 11 04:22:09 server kernel: [__switch_to+82/256]
> [schedule+738/1344] [schedule_timeout+84/160] [process_timeout+0/96]
>
[st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294702743/96]
>
[st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294703097/96]
>
> The stack trace becomes unreadable at this point. Please run klogd
> with -X and then decode the messages with ksymoops. Alternatively
> run ksymoops on the output of dmesg directly.
>
Here are the 3 ksymoopsified traces (ksymoops -i):
May 11 04:22:09 tp-meteodat7 kernel: f3668824 00000274 e9a40380 00000000
00000003 f7e5d280 f3668000 0000000e
May 11 04:22:09 tp-meteodat7 kernel: c010d948 00000003 f7e5d318
f7e5d308 f7e5d280 f3668000 0000000e 00000006
May 11 04:22:09 tp-meteodat7 kernel: f1960018 f1a00018 ffffff14
c024893e 00000010 00000202 f7e5d280 f196cc00
May 11 04:22:09 tp-meteodat7 kernel: Call Trace: [call_do_IRQ+5/13]
[pfifo_fast_dequeue+62/80] [qdisc_restart+31/432] [dev_queue_xmit+383/880]
[neigh_resolve_output+321/624]
May 11 04:22:09 tp-meteodat7 kernel: Call Trace: [<c010d948>]
[<c024893e>] [<c02483df>] [<c023ccaf>] [<c0243af1>]
May 11 04:22:09 tp-meteodat7 kernel: [<c025a2d8>] [<c025a220>]
[<c025a220>] [<c024763e>] [<c025a220>] [<c0258a4e>]
May 11 04:22:09 tp-meteodat7 kernel: [<c025a220>] [<c025a445>]
[<c025a370>] [<c025a370>] [<c024763e>] [<c025a370>]
May 11 04:22:09 tp-meteodat7 kernel: [<c0258e2d>] [<c025a370>]
[<c023ccaf>] [<c0271c20>] [<c026bdc9>] [<c026e824>]
May 11 04:22:09 tp-meteodat7 kernel: [<c025d4a0>] [<c025d4a0>]
[<c026a2fa>] [<c0272eda>] [<c02735be>] [<c025581f>]
May 11 04:22:09 tp-meteodat7 kernel: [<c02556c0>] [<c024763e>]
[<c02556c0>] [<c025514f>] [<c02556c0>] [<c0255a89>]
May 11 04:22:09 tp-meteodat7 kernel: [<c0255860>] [<c0255860>]
[<c024763e>] [<c0255860>] [<c0255589>] [<c0255860>]
May 11 04:22:09 tp-meteodat7 kernel: [<c023d505>] [<c023d5d3>]
[<c023d76a>] [<c01254c6>] [<c010b094>] [<c010d948>]
May 11 04:22:09 tp-meteodat7 kernel: [<c0107722>] [<c011cee2>]
[<c011cb14>] [<c011ca60>] [<f90f0697>] [<f90f07f9>]
May 11 04:22:09 tp-meteodat7 kernel: [<f90f08ab>] [<f90f20c6>]
[<f914d588>] [<f914f255>] [<f8b557d4>] [<f8b629ca>]
May 11 04:22:09 tp-meteodat7 kernel: [<f8b3a3c4>] [<f8b4cc74>]
[<f8b3a3c4>] [<f8b39e28>] [<f8b448c3>] [<f8b4d47e>]
May 11 04:22:09 tp-meteodat7 kernel: [<f8b4f8c3>] [<f8b4667b>]
[<f8b3a308>] [<f8b465ad>] [<f8b531fc>] [<c02387be>]
May 11 04:22:09 tp-meteodat7 kernel: [<c02387be>] [<f90dd5f4>]
[<c02483df>] [<c023ccaf>] [<c0243af1>] [<c02387be>]
May 11 04:22:09 tp-meteodat7 kernel: [<f90dd5f4>] [<c02483df>]
[<c023ccaf>] [<c0243af1>] [<c025a2d8>] [<c025a220>]
May 11 04:22:09 tp-meteodat7 kernel: [<c025a220>] [<c024763e>]
[<c025a220>] [<c0258a4e>] [<c025a220>] [<c025a445>]
May 11 04:22:09 tp-meteodat7 kernel: [<c025a370>] [<c025a370>]
[<c024763e>] [<c025a370>] [<c0258e2d>] [<c025a370>]
May 11 04:22:09 tp-meteodat7 kernel: [<c02399dc>] [<c0237f63>]
[<c025d4a0>] [<c025d4a0>] [<c026a2bd>] [<c0272eda>]
May 11 04:22:09 tp-meteodat7 kernel: [<c02735be>] [<c01e4308>]
[<f8b20233>] [<f8b20233>] [<f8b20547>] [<f8b31d39>]
May 11 04:22:09 tp-meteodat7 kernel: [<f8b18565>] [<f8b696b7>]
[<f8b7068b>] [<c01258ca>] [<c0125753>] [<c0158905>]
May 11 04:22:09 tp-meteodat7 kernel: [<c0108fa7>]
Warning (Oops_read): Code line not seen, dumping what data is available
Trace; c010d948 <call_do_IRQ+5/d>
Trace; c024893e <pfifo_fast_dequeue+3e/50>
Trace; c02483df <qdisc_restart+1f/1b0>
Trace; c023ccaf <dev_queue_xmit+17f/370>
Trace; c0243af1 <neigh_resolve_output+141/270>
Trace; c025a2d8 <ip_finish_output2+b8/150>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c0258a4e <ip_output+14e/1e0>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c025a445 <ip_queue_xmit2+d5/29f>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c0258e2d <ip_queue_xmit+34d/600>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c023ccaf <dev_queue_xmit+17f/370>
Trace; c0271c20 <tcp_v4_send_check+a0/f0>
Trace; c026bdc9 <tcp_transmit_skb+3e9/700>
Trace; c026e824 <tcp_send_ack+84/d0>
Trace; c025d4a0 <tcp_rfree+0/20>
Trace; c025d4a0 <tcp_rfree+0/20>
Trace; c026a2fa <tcp_rcv_established+7fa/a50>
Trace; c0272eda <tcp_v4_do_rcv+13a/160>
Trace; c02735be <tcp_v4_rcv+6be/7a0>
Trace; c025581f <ip_local_deliver_finish+15f/1a0>
Trace; c02556c0 <ip_local_deliver_finish+0/1a0>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c02556c0 <ip_local_deliver_finish+0/1a0>
Trace; c025514f <ip_local_deliver+18f/240>
Trace; c02556c0 <ip_local_deliver_finish+0/1a0>
Trace; c0255a89 <ip_rcv_finish+229/2bc>
Trace; c0255860 <ip_rcv_finish+0/2bc>
Trace; c0255860 <ip_rcv_finish+0/2bc>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c0255860 <ip_rcv_finish+0/2bc>
Trace; c0255589 <ip_rcv+389/4c0>
Trace; c0255860 <ip_rcv_finish+0/2bc>
Trace; c023d505 <netif_receive_skb+1e5/220>
Trace; c023d5d3 <process_backlog+93/130>
Trace; c023d76a <net_rx_action+fa/170>
Trace; c01254c6 <do_softirq+76/e0>
Trace; c010b094 <do_IRQ+f4/130>
Trace; c010d948 <call_do_IRQ+5/d>
Trace; c0107722 <__switch_to+52/100>
Trace; c011cee2 <schedule+2e2/540>
Trace; c011cb14 <schedule_timeout+54/a0>
Trace; c011ca60 <process_timeout+0/60>
Trace; f90f0697 <[usbcore]usb_start_wait_urb+a7/1a0>
Trace; f90f07f9 <[usbcore]usb_internal_control_msg+69/80>
Trace; f90f08ab <[usbcore]usb_control_msg+9b/b0>
Trace; f90f20c6 <[usbcore]usb_get_report+76/80>
Trace; f914d588 <[hid]hid_read_report+98/c0>
Trace; f914f255 <[hid]hiddev_ioctl+565/cd0>
Trace; f8b557d4 <[reiserfs]get_cnode+14/80>
Trace; f8b629ca <[reiserfs].LC32+57e7/5a7d>
Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0>
Trace; f8b4cc74 <[reiserfs]leaf_insert_into_buf+1c4/2c0>
Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0>
Trace; f8b39e28 <[reiserfs]balance_leaf+30a8/3120>
Trace; f8b448c3 <[reiserfs]ip_check_balance+2e3/bf0>
Trace; f8b4d47e <[reiserfs]leaf_cut_from_buffer+28e/4b0>
Trace; f8b4f8c3 <[reiserfs]pathrelse_and_restore+43/60>
Trace; f8b4667b <[reiserfs]unfix_nodes+9b/180>
Trace; f8b3a308 <[reiserfs]do_balance+d8/130>
Trace; f8b465ad <[reiserfs]fix_nodes+3fd/430>
Trace; f8b531fc <[reiserfs]reiserfs_insert_item+14c/150>
Trace; c02387be <__kfree_skb+fe/160>
Trace; c02387be <__kfree_skb+fe/160>
Trace; f90dd5f4 <[8139too]rtl8139_start_xmit+84/180>
Trace; c02483df <qdisc_restart+1f/1b0>
Trace; c023ccaf <dev_queue_xmit+17f/370>
Trace; c0243af1 <neigh_resolve_output+141/270>
Trace; c02387be <__kfree_skb+fe/160>
Trace; f90dd5f4 <[8139too]rtl8139_start_xmit+84/180>
Trace; c02483df <qdisc_restart+1f/1b0>
Trace; c023ccaf <dev_queue_xmit+17f/370>
Trace; c0243af1 <neigh_resolve_output+141/270>
Trace; c025a2d8 <ip_finish_output2+b8/150>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c0258a4e <ip_output+14e/1e0>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c025a445 <ip_queue_xmit2+d5/29f>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c0258e2d <ip_queue_xmit+34d/600>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c02399dc <skb_checksum+5c/320>
Trace; c0237f63 <sock_def_readable+63/80>
Trace; c025d4a0 <tcp_rfree+0/20>
Trace; c025d4a0 <tcp_rfree+0/20>
Trace; c026a2bd <tcp_rcv_established+7bd/a50>
Trace; c0272eda <tcp_v4_do_rcv+13a/160>
Trace; c02735be <tcp_v4_rcv+6be/7a0>
Trace; c01e4308 <locate_hd_struct+38/a0>
Trace; f8b20233 <[scsi_mod]__scsi_end_request+233/240>
Trace; f8b20233 <[scsi_mod]__scsi_end_request+233/240>
Trace; f8b20547 <[scsi_mod]scsi_io_completion+1d7/4c0>
Trace; f8b31d39 <[sd_mod]rw_intr+89/2c0>
Trace; f8b18565 <[scsi_mod]scsi_finish_command+c5/110>
Trace; f8b696b7 <[libata]ata_qc_complete+37/b0>
Trace; f8b7068b <[sata_promise]pdc_interrupt+16b/1b0>
Trace; c01258ca <bh_action+6a/70>
Trace; c0125753 <tasklet_hi_action+53/a0>
Trace; c0158905 <sys_ioctl+2a5/311>
Trace; c0108fa7 <system_call+33/38>
###############################################################
May 11 04:26:28 tp-meteodat7 kernel: f3668998 000003e8 00000000 00000000
f3668000 f3668ac0 f3668a34 00000000
May 11 04:26:28 tp-meteodat7 kernel: c010d948 f3668000 0001961a
00000944 f3668ac0 f3668a34 00000000 00000944
May 11 04:26:28 tp-meteodat7 kernel: 00000018 f1960018 ffffff14
f90820a7 00000010 00000246 f3668a34 f40a9ec0
May 11 04:26:28 tp-meteodat7 kernel: Call Trace: [call_do_IRQ+5/13]
[st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294250663/96]
[st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294268736/96]
[st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294250842/96]
[st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294254302/96]
May 11 04:26:28 tp-meteodat7 kernel: Call Trace: [<c010d948>]
[<f90820a7>] [<f9086740>] [<f908215a>] [<f9082ede>]
May 11 04:26:28 tp-meteodat7 kernel: [<c025a370>] [<c0247185>]
[<c025a370>] [<c025a370>] [<c0247557>] [<c025a370>]
May 11 04:26:28 tp-meteodat7 kernel: [<f9085fb8>] [<c0258e2d>]
[<c025a370>] [<c02735be>] [<c0271c20>] [<c026bdc9>]
May 11 04:26:28 tp-meteodat7 kernel: [<c026e824>] [<c025d4a0>]
[<c025d4a0>] [<c026a2fa>] [<c0272eda>] [<c02735be>]
May 11 04:26:28 tp-meteodat7 kernel: [<c025581f>] [<c02556c0>]
[<c024763e>] [<c02556c0>] [<c025514f>] [<c02556c0>]
May 11 04:26:28 tp-meteodat7 kernel: [<c0255a89>] [<c0255860>]
[<c0255860>] [<c024763e>] [<c0255860>] [<c0255589>]
May 11 04:26:28 tp-meteodat7 kernel: [<c0255860>] [<c023d505>]
[<c023d5d3>] [<c023d76a>] [<c01254c6>] [<c010b094>]
May 11 04:26:28 tp-meteodat7 kernel: [<c010d948>] [<f90f0018>]
[<f914e620>] [<f914e7b6>] [<f914d473>] [<f914d5a6>]
May 11 04:26:28 tp-meteodat7 kernel: [<c018480b>] [<f914f255>]
[<f8b557d4>] [<f8b629ca>] [<f8b3a3c4>] [<f8b4cc74>]
May 11 04:26:28 tp-meteodat7 kernel: [<f8b3a3c4>] [<f8b39e28>]
[<f8b448c3>] [<f8b4d47e>] [<f8b4f8c3>] [<f8b4667b>]
May 11 04:26:28 tp-meteodat7 kernel: [<f8b3a308>] [<f8b465ad>]
[<f8b531fc>] [<c02387be>] [<c02387be>] [<c02387be>]
May 11 04:26:28 tp-meteodat7 kernel: [<f90dd5f4>] [<c02483df>]
[<c023ccaf>] [<c0243af1>] [<c025a2d8>] [<c025a220>]
May 11 04:26:28 tp-meteodat7 kernel: [<c025a220>] [<c024763e>]
[<c025a220>] [<c0258a4e>] [<c025a220>] [<c025a445>]
May 11 04:26:28 tp-meteodat7 kernel: [<c025a370>] [<c025a370>]
[<c024763e>] [<c025a370>] [<c0258e2d>] [<c025a370>]
May 11 04:26:28 tp-meteodat7 kernel: [<c024763e>] [<c0271c20>]
[<c026bdc9>] [<c0237f63>] [<c025d4a0>] [<c025d4a0>]
May 11 04:26:28 tp-meteodat7 kernel: [<c026a2bd>] [<c0272eda>]
[<c02735be>] [<c025581f>] [<c02556c0>] [<c024763e>]
May 11 04:26:28 tp-meteodat7 kernel: [<c02556c0>] [<c025514f>]
[<c02556c0>] [<c0255a89>] [<c0255860>] [<c0255860>]
May 11 04:26:28 tp-meteodat7 kernel: [<c024763e>] [<c011cee2>]
[<c011cb1e>] [<c01594d4>] [<c01598d9>] [<c0159bb4>]
May 11 04:26:28 tp-meteodat7 kernel: [<c0158905>] [<c0124bb5>]
[<c0108fa7>]
Warning (Oops_read): Code line not seen, dumping what data is available
Trace; c010d948 <call_do_IRQ+5/d>
Trace; f90820a7 <[ip_conntrack]__ip_conntrack_find+17/90>
Trace; f9086740 <[ip_conntrack]ip_conntrack_protocol_tcp+0/40>
Trace; f908215a <[ip_conntrack]ip_conntrack_find_get+3a/80>
Trace; f9082ede <[ip_conntrack]ip_conntrack_in+1ae/2e0>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c0247185 <nf_iterate+55/a0>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c0247557 <nf_hook_slow+f7/210>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; f9085fb8 <[ip_conntrack]ip_conntrack_local_out_ops+0/18>
Trace; c0258e2d <ip_queue_xmit+34d/600>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c02735be <tcp_v4_rcv+6be/7a0>
Trace; c0271c20 <tcp_v4_send_check+a0/f0>
Trace; c026bdc9 <tcp_transmit_skb+3e9/700>
Trace; c026e824 <tcp_send_ack+84/d0>
Trace; c025d4a0 <tcp_rfree+0/20>
Trace; c025d4a0 <tcp_rfree+0/20>
Trace; c026a2fa <tcp_rcv_established+7fa/a50>
Trace; c0272eda <tcp_v4_do_rcv+13a/160>
Trace; c02735be <tcp_v4_rcv+6be/7a0>
Trace; c025581f <ip_local_deliver_finish+15f/1a0>
Trace; c02556c0 <ip_local_deliver_finish+0/1a0>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c02556c0 <ip_local_deliver_finish+0/1a0>
Trace; c025514f <ip_local_deliver+18f/240>
Trace; c02556c0 <ip_local_deliver_finish+0/1a0>
Trace; c0255a89 <ip_rcv_finish+229/2bc>
Trace; c0255860 <ip_rcv_finish+0/2bc>
Trace; c0255860 <ip_rcv_finish+0/2bc>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c0255860 <ip_rcv_finish+0/2bc>
Trace; c0255589 <ip_rcv+389/4c0>
Trace; c0255860 <ip_rcv_finish+0/2bc>
Trace; c023d505 <netif_receive_skb+1e5/220>
Trace; c023d5d3 <process_backlog+93/130>
Trace; c023d76a <net_rx_action+fa/170>
Trace; c01254c6 <do_softirq+76/e0>
Trace; c010b094 <do_IRQ+f4/130>
Trace; c010d948 <call_do_IRQ+5/d>
Trace; f90f0018 <[usbcore]call_policy_interface+8/260>
Trace; f914e620 <[hid]hiddev_send_event+0/b0>
Trace; f914e7b6 <[hid]hiddev_report_event+66/80>
Trace; f914d473 <[hid]hid_input_report+133/170>
Trace; f914d5a6 <[hid]hid_read_report+b6/c0>
Trace; c018480b <isofs_read_super+46b/800>
Trace; f914f255 <[hid]hiddev_ioctl+565/cd0>
Trace; f8b557d4 <[reiserfs]get_cnode+14/80>
Trace; f8b629ca <[reiserfs].LC32+57e7/5a7d>
Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0>
Trace; f8b4cc74 <[reiserfs]leaf_insert_into_buf+1c4/2c0>
Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0>
Trace; f8b39e28 <[reiserfs]balance_leaf+30a8/3120>
Trace; f8b448c3 <[reiserfs]ip_check_balance+2e3/bf0>
Trace; f8b4d47e <[reiserfs]leaf_cut_from_buffer+28e/4b0>
Trace; f8b4f8c3 <[reiserfs]pathrelse_and_restore+43/60>
Trace; f8b4667b <[reiserfs]unfix_nodes+9b/180>
Trace; f8b3a308 <[reiserfs]do_balance+d8/130>
Trace; f8b465ad <[reiserfs]fix_nodes+3fd/430>
Trace; f8b531fc <[reiserfs]reiserfs_insert_item+14c/150>
Trace; c02387be <__kfree_skb+fe/160>
Trace; c02387be <__kfree_skb+fe/160>
Trace; c02387be <__kfree_skb+fe/160>
Trace; f90dd5f4 <[8139too]rtl8139_start_xmit+84/180>
Trace; c02483df <qdisc_restart+1f/1b0>
Trace; c023ccaf <dev_queue_xmit+17f/370>
Trace; c0243af1 <neigh_resolve_output+141/270>
Trace; c025a2d8 <ip_finish_output2+b8/150>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c0258a4e <ip_output+14e/1e0>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c025a445 <ip_queue_xmit2+d5/29f>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c0258e2d <ip_queue_xmit+34d/600>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c0271c20 <tcp_v4_send_check+a0/f0>
Trace; c026bdc9 <tcp_transmit_skb+3e9/700>
Trace; c0237f63 <sock_def_readable+63/80>
Trace; c025d4a0 <tcp_rfree+0/20>
Trace; c025d4a0 <tcp_rfree+0/20>
Trace; c026a2bd <tcp_rcv_established+7bd/a50>
Trace; c0272eda <tcp_v4_do_rcv+13a/160>
Trace; c02735be <tcp_v4_rcv+6be/7a0>
Trace; c025581f <ip_local_deliver_finish+15f/1a0>
Trace; c02556c0 <ip_local_deliver_finish+0/1a0>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c02556c0 <ip_local_deliver_finish+0/1a0>
Trace; c025514f <ip_local_deliver+18f/240>
Trace; c02556c0 <ip_local_deliver_finish+0/1a0>
Trace; c0255a89 <ip_rcv_finish+229/2bc>
Trace; c0255860 <ip_rcv_finish+0/2bc>
Trace; c0255860 <ip_rcv_finish+0/2bc>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c011cee2 <schedule+2e2/540>
Trace; c011cb1e <schedule_timeout+5e/a0>
Trace; c01594d4 <poll_freewait+44/50>
Trace; c01598d9 <do_select+239/250>
Trace; c0159bb4 <sys_select+294/4e0>
Trace; c0158905 <sys_ioctl+2a5/311>
Trace; c0124bb5 <sys_time+15/50>
Trace; c0108fa7 <system_call+33/38>
################################################################
May 11 04:30:06 tp-meteodat7 kernel: f3668830 00000280 f2c73080 00000000
f196cd80 d2029180 d2029180 00000042
May 11 04:30:06 tp-meteodat7 kernel: c010d948 f196cd80 f008a0ec
d2029180 d2029180 d2029180 00000042 f008a080
May 11 04:30:06 tp-meteodat7 kernel: f1960018 f5fd0018 ffffff14
c0238723 00000010 00000202 d2029180 d2029180
May 11 04:30:06 tp-meteodat7 kernel: Call Trace: [call_do_IRQ+5/13]
[__kfree_skb+99/352]
[st:__insmod_st_O/lib/modules/2.4.30-hf1/kernel/drivers/scsi/st+4294624756/96]
[qdisc_restart+114/432] [dev_queue_xmit+383/880]
May 11 04:30:06 tp-meteodat7 kernel: Call Trace: [<c010d948>]
[<c0238723>] [<f90dd5f4>] [<c0248432>] [<c023ccaf>]
May 11 04:30:06 tp-meteodat7 kernel: [<c025a2d8>] [<c025a220>]
[<c025a220>] [<c024763e>] [<c025a220>] [<c0258a4e>]
May 11 04:30:06 tp-meteodat7 kernel: [<c025a220>] [<c025a445>]
[<c025a370>] [<c025a370>] [<c024763e>] [<c025a370>]
May 11 04:30:06 tp-meteodat7 kernel: [<c0258e2d>] [<c025a370>]
[<c0271c20>] [<c026bdc9>] [<c026e824>] [<c025d4a0>]
May 11 04:30:06 tp-meteodat7 kernel: [<c025d4a0>] [<c026a2fa>]
[<c0272eda>] [<c02735be>] [<c025581f>] [<c02556c0>]
May 11 04:30:06 tp-meteodat7 kernel: [<c024763e>] [<c02556c0>]
[<c025514f>] [<c02556c0>] [<c0255a89>] [<c0255860>]
May 11 04:30:06 tp-meteodat7 kernel: [<c0255860>] [<c024763e>]
[<c0255860>] [<c0255589>] [<c0255860>] [<c023d505>]
May 11 04:30:06 tp-meteodat7 kernel: [<c023d5d3>] [<c023d76a>]
[<c01254c6>] [<c010b094>] [<c010d948>] [<f9109ae3>]
May 11 04:30:06 tp-meteodat7 kernel: [<f910a404>] [<f910be18>]
[<f90f058d>] [<f90f066d>] [<f90f07f9>] [<f90f08ab>]
May 11 04:30:06 tp-meteodat7 kernel: [<f90f20c6>] [<f914d588>]
[<c018480b>] [<f914f255>] [<f8b557d4>] [<f8b629ca>]
May 11 04:30:06 tp-meteodat7 kernel: [<f8b3a3c4>] [<f8b4cc74>]
[<f8b3a3c4>] [<f8b39e28>] [<f8b448c3>] [<f8b4d47e>]
May 11 04:30:06 tp-meteodat7 kernel: [<f8b4f8c3>] [<f8b4667b>]
[<f8b3a308>] [<f8b465ad>] [<f8b531fc>] [<c02387be>]
May 11 04:30:06 tp-meteodat7 kernel: [<c023cfb3>] [<f90ddb21>]
[<f90dd5f4>] [<c02387be>] [<f90dd5f4>] [<c02387be>]
May 11 04:30:06 tp-meteodat7 kernel: [<c02387be>] [<f90dd5f4>]
[<c02483df>] [<c023ccaf>] [<c025a2d8>] [<c025a220>]
May 11 04:30:06 tp-meteodat7 kernel: [<c025a220>] [<c024763e>]
[<c025a220>] [<c0258a4e>] [<c025a220>] [<c025a445>]
May 11 04:30:06 tp-meteodat7 kernel: [<c025a370>] [<c025a370>]
[<c024763e>] [<c025a370>] [<c0258e2d>] [<c025a370>]
May 11 04:30:06 tp-meteodat7 kernel: [<c0237f63>] [<c025d4a0>]
[<c025d4a0>] [<c026a2bd>] [<c0272eda>] [<c02735be>]
May 11 04:30:06 tp-meteodat7 kernel: [<c025581f>] [<c02556c0>]
[<c024763e>] [<c02556c0>] [<c025514f>] [<c02556c0>]
May 11 04:30:06 tp-meteodat7 kernel: [<c0255a89>] [<c013e624>]
[<c01594d4>] [<c01598d9>] [<c0159bb4>] [<c0158905>]
May 11 04:30:06 tp-meteodat7 kernel: [<c0124bb5>] [<c0108fa7>]
Warning (Oops_read): Code line not seen, dumping what data is available
Trace; c010d948 <call_do_IRQ+5/d>
Trace; c0238723 <__kfree_skb+63/160>
Trace; f90dd5f4 <[8139too]rtl8139_start_xmit+84/180>
Trace; c0248432 <qdisc_restart+72/1b0>
Trace; c023ccaf <dev_queue_xmit+17f/370>
Trace; c025a2d8 <ip_finish_output2+b8/150>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c0258a4e <ip_output+14e/1e0>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c025a445 <ip_queue_xmit2+d5/29f>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c0258e2d <ip_queue_xmit+34d/600>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c0271c20 <tcp_v4_send_check+a0/f0>
Trace; c026bdc9 <tcp_transmit_skb+3e9/700>
Trace; c026e824 <tcp_send_ack+84/d0>
Trace; c025d4a0 <tcp_rfree+0/20>
Trace; c025d4a0 <tcp_rfree+0/20>
Trace; c026a2fa <tcp_rcv_established+7fa/a50>
Trace; c0272eda <tcp_v4_do_rcv+13a/160>
Trace; c02735be <tcp_v4_rcv+6be/7a0>
Trace; c025581f <ip_local_deliver_finish+15f/1a0>
Trace; c02556c0 <ip_local_deliver_finish+0/1a0>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c02556c0 <ip_local_deliver_finish+0/1a0>
Trace; c025514f <ip_local_deliver+18f/240>
Trace; c02556c0 <ip_local_deliver_finish+0/1a0>
Trace; c0255a89 <ip_rcv_finish+229/2bc>
Trace; c0255860 <ip_rcv_finish+0/2bc>
Trace; c0255860 <ip_rcv_finish+0/2bc>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c0255860 <ip_rcv_finish+0/2bc>
Trace; c0255589 <ip_rcv+389/4c0>
Trace; c0255860 <ip_rcv_finish+0/2bc>
Trace; c023d505 <netif_receive_skb+1e5/220>
Trace; c023d5d3 <process_backlog+93/130>
Trace; c023d76a <net_rx_action+fa/170>
Trace; c01254c6 <do_softirq+76/e0>
Trace; c010b094 <do_IRQ+f4/130>
Trace; c010d948 <call_do_IRQ+5/d>
Trace; f9109ae3 <[usb-uhci]insert_qh+83/c0>
Trace; f910a404 <[usb-uhci]uhci_submit_control_urb+244/370>
Trace; f910be18 <[usb-uhci]uhci_submit_urb+3c8/400>
Trace; f90f058d <[usbcore]usb_submit_urb+3d/40>
Trace; f90f066d <[usbcore]usb_start_wait_urb+7d/1a0>
Trace; f90f07f9 <[usbcore]usb_internal_control_msg+69/80>
Trace; f90f08ab <[usbcore]usb_control_msg+9b/b0>
Trace; f90f20c6 <[usbcore]usb_get_report+76/80>
Trace; f914d588 <[hid]hid_read_report+98/c0>
Trace; c018480b <isofs_read_super+46b/800>
Trace; f914f255 <[hid]hiddev_ioctl+565/cd0>
Trace; f8b557d4 <[reiserfs]get_cnode+14/80>
Trace; f8b629ca <[reiserfs].LC32+57e7/5a7d>
Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0>
Trace; f8b4cc74 <[reiserfs]leaf_insert_into_buf+1c4/2c0>
Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0>
Trace; f8b39e28 <[reiserfs]balance_leaf+30a8/3120>
Trace; f8b448c3 <[reiserfs]ip_check_balance+2e3/bf0>
Trace; f8b4d47e <[reiserfs]leaf_cut_from_buffer+28e/4b0>
Trace; f8b4f8c3 <[reiserfs]pathrelse_and_restore+43/60>
Trace; f8b4667b <[reiserfs]unfix_nodes+9b/180>
Trace; f8b3a308 <[reiserfs]do_balance+d8/130>
Trace; f8b465ad <[reiserfs]fix_nodes+3fd/430>
Trace; f8b531fc <[reiserfs]reiserfs_insert_item+14c/150>
Trace; c02387be <__kfree_skb+fe/160>
Trace; c023cfb3 <netif_rx+93/1f0>
Trace; f90ddb21 <[8139too]rtl8139_rx_interrupt+131/320>
Trace; f90dd5f4 <[8139too]rtl8139_start_xmit+84/180>
Trace; c02387be <__kfree_skb+fe/160>
Trace; f90dd5f4 <[8139too]rtl8139_start_xmit+84/180>
Trace; c02387be <__kfree_skb+fe/160>
Trace; c02387be <__kfree_skb+fe/160>
Trace; f90dd5f4 <[8139too]rtl8139_start_xmit+84/180>
Trace; c02483df <qdisc_restart+1f/1b0>
Trace; c023ccaf <dev_queue_xmit+17f/370>
Trace; c025a2d8 <ip_finish_output2+b8/150>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c0258a4e <ip_output+14e/1e0>
Trace; c025a220 <ip_finish_output2+0/150>
Trace; c025a445 <ip_queue_xmit2+d5/29f>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c0258e2d <ip_queue_xmit+34d/600>
Trace; c025a370 <ip_queue_xmit2+0/29f>
Trace; c0237f63 <sock_def_readable+63/80>
Trace; c025d4a0 <tcp_rfree+0/20>
Trace; c025d4a0 <tcp_rfree+0/20>
Trace; c026a2bd <tcp_rcv_established+7bd/a50>
Trace; c0272eda <tcp_v4_do_rcv+13a/160>
Trace; c02735be <tcp_v4_rcv+6be/7a0>
Trace; c025581f <ip_local_deliver_finish+15f/1a0>
Trace; c02556c0 <ip_local_deliver_finish+0/1a0>
Trace; c024763e <nf_hook_slow+1de/210>
Trace; c02556c0 <ip_local_deliver_finish+0/1a0>
Trace; c025514f <ip_local_deliver+18f/240>
Trace; c02556c0 <ip_local_deliver_finish+0/1a0>
Trace; c0255a89 <ip_rcv_finish+229/2bc>
Trace; c013e624 <__alloc_pages+64/280>
Trace; c01594d4 <poll_freewait+44/50>
Trace; c01598d9 <do_select+239/250>
Trace; c0159bb4 <sys_select+294/4e0>
Trace; c0158905 <sys_ioctl+2a5/311>
Trace; c0124bb5 <sys_time+15/50>
Trace; c0108fa7 <system_call+33/38>
--
+++ Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS +++
GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail
^ permalink raw reply
* [PATCH 4/4] iseries_veth: Cleanup skbs to prevent unregister_netdevice() hanging
From: Michael Ellerman @ 2005-05-12 8:09 UTC (permalink / raw)
To: Andrew Morton, Jeff Garzik; +Cc: netdev, linux-kernel, PPC64-dev
Hi Andrew, Jeff,
The iseries_veth driver is badly behaved in that it will keep TX packets
hanging around forever if they're not ACK'ed and the queue never fills up.
This causes the unregister_netdevice code to wait forever when we try to take
the device down, because there's still skbs around with references to our
struct net_device.
There's already code to cleanup any un-ACK'ed packets in veth_stop_connection()
but it's being called after we unregister the net_device, which is too late.
The fix is to rearrange the module exit function so that we cleanup any
outstanding skbs and then unregister the driver.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
--
drivers/net/iseries_veth.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
Index: veth-fixes/drivers/net/iseries_veth.c
===================================================================
--- veth-fixes.orig/drivers/net/iseries_veth.c 2005-05-12 16:27:32.000000000 +1000
+++ veth-fixes/drivers/net/iseries_veth.c 2005-05-12 16:27:42.000000000 +1000
@@ -1388,18 +1388,25 @@
{
int i;
- vio_unregister_driver(&veth_driver);
+ /* Stop the queues first to stop any new packets being sent. */
+ for (i = 0; i < HVMAXARCHITECTEDVIRTUALLANS; i++)
+ if (veth_dev[i])
+ netif_stop_queue(veth_dev[i]);
+ /* Stop the connections before we unregister the driver. This
+ * ensures there's no skbs lying around holding the device open. */
for (i = 0; i < HVMAXARCHITECTEDLPS; ++i)
veth_stop_connection(i);
HvLpEvent_unregisterHandler(HvLpEvent_Type_VirtualLan);
/* Hypervisor callbacks may have scheduled more work while we
- * were destroying connections. Now that we've disconnected from
+ * were stoping connections. Now that we've disconnected from
* the hypervisor make sure everything's finished. */
flush_scheduled_work();
+ vio_unregister_driver(&veth_driver);
+
for (i = 0; i < HVMAXARCHITECTEDLPS; ++i)
veth_destroy_connection(i);
^ permalink raw reply
* Re: 2.4.30-hf1 do_IRQ stack overflows
From: Manfred Schwarb @ 2005-05-12 7:59 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel, davem, netdev
In-Reply-To: <20050511124640.GE8541@logos.cnet>
>
> The traces show huge networking execution paths.
>
> It seems you are using some packet scheduler (CONFIG_NET_SCHED)? Pretty
> much all
> traces show functions from sch_generic.c. Can you disable that for a test?
>
Yes, indeed, I made some experiments with it, but do not need it urgently.
I will disable it, thanks for the hint.
And I will report back.
> >
> > Below my three overflow messages. Would the stack reduction patches of
> Badari Pulavarty
> > help in my case? If so, I would strongly vote for inclusion into 2.4
> series!!
>
> It has been decided that the stack reduction patches were too intrusive to
> be merged
> at this stage of v2.4 life.
>
OK, I got the message, I will consider upgrading to 2.6 sometime this
year...
--
+++ Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS +++
GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail
^ permalink raw reply
* [PATCH 3/4] iseries_veth: Don't leak skbs in RX path
From: Michael Ellerman @ 2005-05-12 7:55 UTC (permalink / raw)
To: Andrew Morton, Jeff Garzik; +Cc: netdev, linux-kernel
Hi Andrew, Jeff,
Under some strange circumstances the iseries_veth driver can leak skbs.
Fix is simply to call dev_kfree_skb() in the right place.
Fix up the comment as well.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
--
iseries_veth.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
Index: veth-fixes/drivers/net/iseries_veth.c
===================================================================
--- veth-fixes.orig/drivers/net/iseries_veth.c
+++ veth-fixes/drivers/net/iseries_veth.c
@@ -1264,13 +1264,18 @@ static void veth_receive(struct veth_lpa
vlan = skb->data[9];
dev = veth_dev[vlan];
- if (! dev)
- /* Some earlier versions of the driver sent
- broadcasts down all connections, even to
- lpars that weren't on the relevant vlan.
- So ignore packets belonging to a vlan we're
- not on. */
+ if (! dev) {
+ /*
+ * Some earlier versions of the driver sent
+ * broadcasts down all connections, even to lpars
+ * that weren't on the relevant vlan. So ignore
+ * packets belonging to a vlan we're not on.
+ * We can also be here if we receive packets while
+ * the driver is going down, because then dev is NULL.
+ */
+ dev_kfree_skb_irq(skb);
continue;
+ }
port = (struct veth_port *)dev->priv;
dest = *((u64 *) skb->data) & 0xFFFFFFFFFFFF0000;
^ 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