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 w
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
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 resp
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 co
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
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 th
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"
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
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 INET_PROTOSW_ICSK value when it is actually
only a single bit. This patch corrects the
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
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 Pau
> Jeff/Roland/all,
> What is the preferred submission driver model for an iWARP-capable
> Ethernet NIC - two separate drivers (Ethernet and OpenFabrics) that
> interact with each other, or a single driver that supports both
> OpenFabrics and Ethernet interfaces?
Let's not use the term "OpenFa
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 a
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), g
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.
> >
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
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 initi
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 materi
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 Steve
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 f
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 h
* 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 accessi
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
present
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 <[EMA
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 considering
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]
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
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 prob
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 B
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
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 fla
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 th
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 nf_
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 s
| > 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
|
| an
On Fri, Jan 05, 2007 at 05:45:46AM +0900, Komuro wrote:
> 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?
>
>
>
> ---
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
> >
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
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,
Kr
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,
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
+090
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 whe
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
> + 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 unsub
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 "unsubsc
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
| > 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;
| >
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 res
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 v
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 qu
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 skb->dev not IFF_UP.
I think you misunderstood. The device c
On Thu, Jan 04, 2007 at 05:26:27PM +1100, Herbert Xu wrote:
> 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, and that
52 matches
Mail list logo
