On Thu, Jan 04, 2007 at 07:29:30PM +1100, Herbert Xu wrote:
On Thu, Jan 04, 2007 at 09:03:51AM +0100, Jarek Poplawski wrote:
I doubt this is the right solution. It certainly
could fix this particular situation but my main
point was packets shouldn't get into kernel
receive queues with
When inserting new nodes into a fib6 tree, the leaf pointer
is first to NULL and later corrected when the key gets
assigned. However, the tree is not locked for this period
of time, therefore nodes with an invalid leaf pointer
are accessible. Lookups that occur during this period of time
expect a
Hi all,
(sorry for newbie question)
I'm trying to learn the networking code of an ancient 2.4.18 vanilla kernel.
I understand that the egress path of network packet (socket buffer) as
general behaviour, goes through the method hard_start_xmit() within of
the driver layer. This method is the
| previous code had the form (this is copied from 2.6.17-mm1 original):
|
| size = 0;
| sk_for_each(sk2, node, list)
| if (++size = best_size_so_far)
| goto next;
|
On Thu, Jan 04, 2007 at 09:50:14AM +0100, Jarek Poplawski wrote:
Could you explain? I can see some inet_rtm_newaddr
interrupted. For me it could be e.g.:
after
vconfig add eth0 9
ip addr add dev eth0.9 ...
Whether eth0.9 is up or not does not affect this at all. The spin
locks are
On Thu, Jan 04, 2007 at 09:27:07PM +1100, Herbert Xu wrote:
On Thu, Jan 04, 2007 at 09:50:14AM +0100, Jarek Poplawski wrote:
Could you explain? I can see some inet_rtm_newaddr
interrupted. For me it could be e.g.:
after
vconfig add eth0 9
ip addr add dev eth0.9 ...
Whether
On Wed, 3 Jan 2007 15:46:31 -0500, Paul Moore wrote:
This makes me believe that Ingo's patch (which I see is now in Linus' and
Andrew's trees) is the way to go and not the lock re-order approach in Adam's
patch. I'm going to continue to look into this, almost more for my own
education than
Hi,
On Wednesday 03 January 2007 20:33, Lennert Buytenhek wrote:
I'd also love to see the old tproxy API go away entirely. It was
always a bit of a pain to use.
It's gone with these patches: all you need is to bind() to foreign
addresses, like in the Linux 2.2 days.
--
Regards,
On Thu, Jan 04, 2007 at 01:13:27PM +0100, KOVACS Krisztian wrote:
I'd also love to see the old tproxy API go away entirely. It was
always a bit of a pain to use.
It's gone with these patches: all you need is to bind() to foreign
addresses, like in the Linux 2.2 days.
That's how I
| With the implementation now, the output of before(x,y) is reliable: it
returns true
| if (and only if) x is indeed `before' y.
|
| Sorry but I don't think you've answered my question.
|
| Let y = (x + 2^31) % 2^32, how is making
|
| before(x, y) == before(y, x) == 0
|
| any
Hi Dave,
as per earlier email, can you please revert the definition of the
TCP `before' relation: there is code which implicitly depends on it.
Furthermore, this definition appears in textbooks such as Stevens
and therefore, even if the newer definition may have nicer properties,
it is safer to
Hello,
Below I attach a patch proposal.
Regards,
Jarek P.
---
On 02-01-2007 06:40, Andrew Morton wrote:
Begin forwarded message:
Date: Mon, 1 Jan 2007 17:53:04 +0100
From: Malte Schröder [EMAIL PROTECTED]
To: linux-kernel@vger.kernel.org
Subject: [BUG] panic 2.6.20-rc3 in
Steve Glendinning wrote:
Attached is a driver for SMSC's LAN911x and LAN921x families of embedded
ethernet controllers. There is an existing smc911x driver in the tree;
this is intended to replace it.
This driver contains workarounds for all known hardware issues, and has
been tested on all
Here's a proposed patch that addresses a problem with natsemi
NICs and long cables we've been chasing (*sigh*).
I'm interested in feedback on how to fix this sanely.
Olaf
--
From: Olaf Kirch [EMAIL PROTECTED]
Subject: natsemi: make
Hello,
I believe I have found a bug in PF_PACKET socket filtering (introduced in
linux-2.6.19). If BPF returns values larger than 0x8000u, run_filter in
af_packet.c considers that as error instead of simply accepting packet in its
full length. sk_filter does not have this problem.
Raivis
Jarek Poplawski wrote:
On Thu, Jan 04, 2007 at 09:27:07PM +1100, Herbert Xu wrote:
On Thu, Jan 04, 2007 at 09:50:14AM +0100, Jarek Poplawski wrote:
Could you explain? I can see some inet_rtm_newaddr
interrupted. For me it could be e.g.:
after
vconfig add eth0 9
ip addr add dev eth0.9
On Thu, 4 Jan 2007 08:49:49 -0800
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=7770
Summary: Network connection randomly drops
Kernel Version: 2.6.19 onward
Status: NEW
Severity: normal
Owner: [EMAIL PROTECTED]
These attached patches are a simplified version of Michael Buesch's original
hwmode API patches to adm8211, p54, and zd1211rw-d80211. These will be
necessary once you pull up2 from Jiri Benc's tree.
Thanks,
-Michael Wu
adm8211: Fix compilation for d80211 hwmode API change
From: Michael Wu
* Thomas Graf [EMAIL PROTECTED] 2007-01-04 10:39
When inserting new nodes into a fib6 tree, the leaf pointer
is first to NULL and later corrected when the key gets
assigned. However, the tree is not locked for this period
of time, therefore nodes with an invalid leaf pointer
are accessible.
On 1/4/07, David Miller [EMAIL PROTECTED] wrote:
I've applied that patch, thanks.
David, I suppose you've applied the locking patch as well...
--
Eric
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: Thomas Graf [EMAIL PROTECTED]
Date: Thu, 4 Jan 2007 20:21:47 +0100
* Thomas Graf [EMAIL PROTECTED] 2007-01-04 10:39
When inserting new nodes into a fib6 tree, the leaf pointer
is first to NULL and later corrected when the key gets
assigned. However, the tree is not locked for this
From: Gerrit Renker [EMAIL PROTECTED]
Date: Thu, 4 Jan 2007 12:54:54 +
Hi Dave,
as per earlier email, can you please revert the definition of the
TCP `before' relation: there is code which implicitly depends on it.
Furthermore, this definition appears in textbooks such as Stevens
and
From: Eric Lemoine [EMAIL PROTECTED]
Date: Thu, 4 Jan 2007 21:06:48 +0100
On 1/4/07, David Miller [EMAIL PROTECTED] wrote:
I've applied that patch, thanks.
David, I suppose you've applied the locking patch as well...
No, not yet.
Your locking patches are definitely 2.6.21 material, but
From: Herbert Xu [EMAIL PROTECTED]
Date: Thu, 04 Jan 2007 17:26:27 +1100
David Stevens [EMAIL PROTECTED] wrote:
You're right, I don't know whether it'll fix the problem Ben saw
or not, but it looks like the original code can do a receive before the
in_device is fully initialized,
On 1/4/07, David Miller [EMAIL PROTECTED] wrote:
From: Eric Lemoine [EMAIL PROTECTED]
Date: Thu, 4 Jan 2007 21:06:48 +0100
On 1/4/07, David Miller [EMAIL PROTECTED] wrote:
I've applied that patch, thanks.
David, I suppose you've applied the locking patch as well...
No, not yet.
Your
On Thu, 2007-01-04 at 21:57 +0100, Eric Lemoine wrote:
On 1/4/07, David Miller [EMAIL PROTECTED] wrote:
From: Eric Lemoine [EMAIL PROTECTED]
Date: Thu, 4 Jan 2007 21:06:48 +0100
On 1/4/07, David Miller [EMAIL PROTECTED] wrote:
I've applied that patch, thanks.
David, I suppose
On Wed, 3 Jan 2007 22:33:08 -0200
Dâniel Fraga [EMAIL PROTECTED] wrote:
Jan 3 22:10:13 belforts vmunix: eth0: Tx timeout - resetting
Solved by forcing 10Mbps full duplex, using options dmfe
mode=4 in /etc/modprobe.conf.
--
http://u-br.net
Linux 2.6.19: Avast! A bilge rat!
Sao Paulo -
From: Paul Moore [EMAIL PROTECTED]
Date: Thu, 04 Jan 2007 15:04:31 -0500
From: Paul Moore [EMAIL PROTECTED]
The inet_create() and inet6_create() functions incorrectly set the
inet_sock-is_icsk field. Both functions assume that the is_icsk field is
large enough to hold at least a
On 1/4/07, David Miller [EMAIL PROTECTED] wrote:
From: Paul Moore [EMAIL PROTECTED]
Date: Thu, 04 Jan 2007 15:04:31 -0500
From: Paul Moore [EMAIL PROTECTED]
The inet_create() and inet6_create() functions incorrectly set the
inet_sock-is_icsk field. Both functions assume that the is_icsk
On Thu, Jan 04, 2007 at 12:49:02PM +, Gerrit Renker wrote:
The key point where the new definition differs from the old is that _the
relation_
before(x,y) is unambiguous: the case before(x,y) before(y,x) will no
longer occur.
This is highly dependent on how the before macro is used in
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Fri, 5 Jan 2007 00:32:31 -0200
I expected a warning since the and operation clearly could yield a
value that would overflow, just like in the constant case...
It sounds stupid, but once you introduce variables and not
everything is
Hi all,
(sorry for newbie question)
I'm trying to learn the networking code of an ancient 2.4.18 vanilla kernel.
I understand that the egress path of network packet (socket buffer) as
general behaviour, goes through the method hard_start_xmit() within of
the driver layer. This method is the
On Thu, Jan 04, 2007 at 12:33:33PM -0800, David Miller wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Thu, 04 Jan 2007 17:26:27 +1100
David Stevens [EMAIL PROTECTED] wrote:
You're right, I don't know whether it'll fix the problem Ben saw
or not, but it looks like the original
On Thu, 04 Jan 2007 15:39:24 +1100
ahendry [EMAIL PROTECTED] wrote:
Trivial. Newlines missing on the SOCK_DEBUG's for X.25 facility negotiation.
Signed-off-by: Andrew Hendry [EMAIL PROTECTED]
Acked-by: Alan Cox [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe
+ struct sk_buff *skbn;
+ skbn = skb_clone(skb, GFP_ATOMIC);
+
If this fails then you starting passing NULL around. I'm also a bit
confused as to where you free the copy in all the error cases ?
Is there any reason for creating skbn here rather than in
skb_forward_call ?
-
To
On Wed, Jan 03, 2007 at 04:53:58PM +, Sid Boyce wrote:
...
It seems =2.6.19 and the SuSEfirewall are incompatible.
Actually, many programs could be incomapatible with
newer kernel versions, so sometimes upgrades or at
least recompilations are needed.
...
There is still the problem where
Hi,
I made a patch below.
With this patch, the ftp-transfer-stop problem does not happen.
Therefore, I think this is not a problem of vsftpd.
Mr.YOSHIFUJI san, why did you set TCPOLEN_TSTAMP_ALIGNED
to iov_len?
--- linux-2.6.20-rc3/net/ipv4/tcp_ipv4.c.orig 2007-01-03 11:50:04.0
On Wed, Jan 03, 2007 at 11:16:59PM +, Jon Maloy wrote:
See my comments below.
Regards
///jon
Jarek Poplawski wrote:
..
Maybe I misinterpret this but, IMHO lockdep
complains about locks acquired in different
order: tipc_ref_acquire() gets ref_table_lock
and then
On Thu, 2007-01-04 at 07:07 +0200, Michael S. Tsirkin wrote:
If you think I should not add the udata parameter to the req_notify_cq()
provider verb, then I can rework the chelsio driver:
1) at cq creation time, pass the virtual address of the u32 used by the
library to track the current
Regards
///jon
Jarek Poplawski wrote:
I know lockdep is sometimes
too careful but nevertheless some change is needed
to fix a real bug or give additional information
to lockdep.
I don't know lockdep well enough yet, but I will try to find out if that
is possible.
Btw. there is a
The OAKNET driver:
- has been marked as BROKEN for more than two years and
- is still marked as BROKEN.
Drivers that had been marked as BROKEN for such a long time seem to be
unlikely to be revived in the forseeable future.
But if anyone wants to ever revive this driver, the code is still
OK, I'm back from vacation today.
Anyway I don't have a definitive statement on this right now. I guess
I agree that I don't like having an extra parameter to a function that
should be pretty fast (although req notify isn't quite as hot as
something like posting a send request or polling a cq),
On Thu, 2007-01-04 at 13:34 -0800, Roland Dreier wrote:
OK, I'm back from vacation today.
Anyway I don't have a definitive statement on this right now. I guess
I agree that I don't like having an extra parameter to a function that
should be pretty fast (although req notify isn't quite as
On Thu, 04 Jan 2007 17:58:23 +0100
Bernhard Schmidt [EMAIL PROTECTED] wrote:
Hi,
I've hit another kernel oops with 2.6.20-rc3 on i386 platform. It is
reproducible, as soon as I load nf_conntrack_ipv6 and try to send
something large (scp or so) inside an OpenVPN tunnel on my client
From: ahendry [EMAIL PROTECTED]
Date: Thu, 04 Jan 2007 15:39:24 +1100
Trivial. Newlines missing on the SOCK_DEBUG's for X.25 facility negotiation.
Signed-off-by: Andrew Hendry [EMAIL PROTECTED]
Applied, thanks Andrew.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the
On Thu, Jan 04, 2007 at 04:16:20PM +, Jon Maloy wrote:
Regards
///jon
Jarek Poplawski wrote:
I know lockdep is sometimes
too careful but nevertheless some change is needed
to fix a real bug or give additional information
to lockdep.
I don't know lockdep well enough yet, but
This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm
47 matches
Mail list logo
