On 17 Sep 2007, Urs Thuermann wrote:
> Thomas Gleixner <[EMAIL PROTECTED]> writes:
>
> > Please do, having the patch in mail makes it easier to review and to
> > comment.
>
> OK, here it is:
One more typo.
> This patch adds documentation for the PF_CAN protocol family.
>
> Signed-off-by: Oliv
On Mon, 17 Sep 2007, Brandeburg, Jesse wrote:
> L F wrote:
> > On 9/17/07, Kok, Auke <[EMAIL PROTECTED]> wrote:
> >> The statistic we were looking at _will_ increase when running in
> >> half duplex, but if it increases when running in full duplex might
> >> indicate a hardware failure. Probably y
The length check for truncated frames was not correctly handling
the case where VLAN acceleration had already read the tag.
Also, the Yukon EX has some features that use high bit of status
as security tag.
Original patch by Pierre-Yves Ritschard but with additions.
Signed-off-by: Stephen Hemminge
Hi,
Sorry for my error.
The problem is the current icmp_reply and ip_send_reply will
send out packets with wrong destination address. Not wrong source
address.
My point is that we should always use the source address of packets we
received as the destination address of our reply packets.
On
On Tue, 18 Sep 2007, YOSHIFUJI Hideaki / [EMAIL PROTECTED](B wrote:
In article <[EMAIL PROTECTED]> (at Mon, 17 Sep 2007 19:20:44 -0700 (PDT)), David
Miller <[EMAIL PROTECTED]> says:
From: lepton <[EMAIL PROTECTED]>
Date: Tue, 18 Sep 2007 10:16:17 +0800
Hi,
In some situation, icmp_reply an
Hi,
sorry for my previous email.
What I mean is icmp_reply and ip_send_reply
in some situation will send out packets with wrong
DESTINATION address. the source address is always
correct.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PRO
Hi,
sorry for lack of details.
let's think about ip_send_reply. it is only called
by tcp_v4_send_ack and tcp_v4_reset. I don't know why
we need a source address diffrent from ip_hdr(skb)->s_addr
icmp_reply is only called by icmp_echo and icmp_timestamp.
Is there a situation to need we use a s
On Mon, 2007-17-09 at 19:01 -0700, David Miller wrote:
> Hardirq should never try to grab the netif_tx_lock(), it is
> only for base and softirq context.
>
> Any hardirq context code taking that lock needs to be fixed.
> We could assert this if we don't already.
I snooped around it looks pretty
David Miller <[EMAIL PROTECTED]> writes:
> From: "Peter Waskiewicz" <[EMAIL PROTECTED]>
> Date: Mon, 17 Sep 2007 12:12:24 -0700
>
>> This would be a good opportunity to remove the single-allocated queue struct
>> in netdevice (at the bottom) that we had to put in to accomodate the static
>> loopba
In article <[EMAIL PROTECTED]> (at Mon, 17 Sep 2007 19:20:44 -0700 (PDT)),
David Miller <[EMAIL PROTECTED]> says:
> From: lepton <[EMAIL PROTECTED]>
> Date: Tue, 18 Sep 2007 10:16:17 +0800
>
> > Hi,
> > In some situation, icmp_reply and ip_send_reply will send
> > out packet with the wrong s
From: lepton <[EMAIL PROTECTED]>
Date: Tue, 18 Sep 2007 10:16:17 +0800
> Hi,
> In some situation, icmp_reply and ip_send_reply will send
> out packet with the wrong source addr, the following patch
> will fix this.
>
> I don't understand why we must use rt->rt_src in the current
> code,
Hi,
In some situation, icmp_reply and ip_send_reply will send
out packet with the wrong source addr, the following patch
will fix this.
I don't understand why we must use rt->rt_src in the current
code, if this is a wrong fix, please correct me.
Signed-off-by: Lepton Wu <[EMAIL PROTECTE
On Mon, 2007-09-17 at 19:05 -0700, David Miller wrote:
> Anyways, it would indeed help if you could rebase the patch
> against net-2.6.24 It would save me a ton of time.
I'll rebase it tomorrow against whatever's in
your current net-2.6.24.
cheers, Joe
-
To unsubscribe from this list: send the
On 9/17/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Mon, 17 Sep 2007 16:53:18 -0700
>
> > The Tehuti driver you should probably pull from the above git tree.
>
> Ok I added in the Tehuti driver to net-2.6.24 and made sure the
> napi_struct conversio
From: Joe Perches <[EMAIL PROTECTED]>
Date: Fri, 14 Sep 2007 12:41:48 -0700
> David? Did you ever get a chance to look at this?
> Do you want me to rebase it against your newer net-2.4.26?
>
> http://repo.or.cz/w/linux-2.6/trivial-mods.git
How can I pull from this tree?
[EMAIL PROTECTED]:~/src
From: jamal <[EMAIL PROTECTED]>
Date: Sun, 16 Sep 2007 16:41:24 -0400
> Ok, maybe i am thinking too hard with that patch, so help me out:->
> When i looked at that code path as it is today: i felt the softirq could
> be interupted on the same CPU it is running on while it already grabbed
> that tx
On Sat, 2007-09-15 at 09:21 -0400, John W. Linville wrote:
> Jeff,
>
> A few more for 2.6.24...
Hi John, how is the iwlwifi driver going? Would you like to push it to
Jeff for .24? Or you'd like me to create a patch against this branch?
Thanks,
-yi
-
To unsubscribe from this list: send the line
From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Mon, 17 Sep 2007 07:07:42 -0600
> Pavel if you are going down this route. Could you look at
> cleanup_net as well. The reverse walk there could probably
> benefit from being list_for_each_entry_reverse.
Pavel please resubmit this work after ever
From: "Peter Waskiewicz" <[EMAIL PROTECTED]>
Date: Mon, 17 Sep 2007 12:12:24 -0700
> This would be a good opportunity to remove the single-allocated queue struct
> in netdevice (at the bottom) that we had to put in to accomodate the static
> loopback. Now we can set it back to a zero element list
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Mon, 17 Sep 2007 16:53:18 -0700
> The Tehuti driver you should probably pull from the above git tree.
Ok I added in the Tehuti driver to net-2.6.24 and made sure the
napi_struct conversion was good too.
That only leaves the wireless bits :-)
-
To uns
I just managed to get a 2-port Mellanox 10Gbe pci-e NIC working with
2.6.23-rc6 + my hacks. There are some errors about scheduling
while atomic and such in the management path (ie, querying stats, etc),
but the data path looks pretty good.
At 1500 MTU I was able to send + rx 2.5Gbps on both port
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Mon, 17 Sep 2007 16:53:18 -0700
> The Tehuti driver you should probably pull from the above git tree.
>
> Andy sent me a fix-it-for-net-2.6.24 patch which I'll send. It applies
> on top of the git tree.
>
> ipg-add-ip1000a-driver-to-kernel-tree.patc
On Mon, 17 Sep 2007 16:57:03 -0700
"Nelson, Shannon" <[EMAIL PROTECTED]> wrote:
> >From: [EMAIL PROTECTED]
> >[mailto:[EMAIL PROTECTED] On Behalf Of David Miller
> >Sent: Monday, September 17, 2007 2:18 PM
> >To: netdev@vger.kernel.org
> >Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> >[EMAIL PROTE
From: "Nelson, Shannon" <[EMAIL PROTECTED]>
Date: Mon, 17 Sep 2007 16:57:03 -0700
> >From: [EMAIL PROTECTED]
> >[mailto:[EMAIL PROTECTED] On Behalf Of David Miller
> >Sent: Monday, September 17, 2007 2:18 PM
> >To: netdev@vger.kernel.org
> >Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> >[EMAIL PRO
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of David Miller
>Sent: Monday, September 17, 2007 2:18 PM
>To: netdev@vger.kernel.org
>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]
>Subject: Re: net-2.6.24 plans
[...]
>
>Andrew, I removed the troublesome IOAT patch.
On Mon, 17 Sep 2007 16:39:29 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Mon, 17 Sep 2007 14:40:37 -0700
>
> > These two:
> >
> > git://porch.greyhouse.net/gospo/tehuti-2.6.git
> > ipg-add-ip1000a-driver-to-kernel-tree.patch
> >
> > plus
On Mon, 17 Sep 2007, Denis V. Lunev wrote:
> Dhaval Giani wrote:
> > On Thu, Sep 13, 2007 at 11:51:33PM -0400, Andrew James Wade wrote:
> >> EIP: [] tcp_rto_min+0xb/0x15 SS:ESP 0068:c0596dec
As Vlad Yasevich mentioned, this one is already fixed in 23-rc6.
The forcedeth oops is unrelated, but m
On Mon, 17 Sep 2007 19:18:30 -0400
"John W. Linville" <[EMAIL PROTECTED]> wrote:
> P.S. Andrew, I'll send you a link to a new git-wireless.patch --
> I'm sure you don't want a complicated git invocation... Until then,
> I don't think you should try pulling wireless-dev...
OK, thanks.
The stuff
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Mon, 17 Sep 2007 19:18:30 -0400
> I just (minutes ago) finished the mop-up of the patch mess which
> had accumulated on me during my KS-related travel and the subsequent
> period of catching-up. (I'm sure I still missed something or botched
> som
On Mon, Sep 17, 2007 at 02:40:37PM -0700, Andrew Morton wrote:
> On Mon, 17 Sep 2007 14:18:26 -0700 (PDT)
> David Miller <[EMAIL PROTECTED]> wrote:
> > I guess a lot of this could be avoided if I simply merge in whatever
> > external stuff you're sucking in.
> plus boatloads of stuff in wireless.
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Mon, 17 Sep 2007 14:40:37 -0700
> These two:
>
> git://porch.greyhouse.net/gospo/tehuti-2.6.git
> ipg-add-ip1000a-driver-to-kernel-tree.patch
>
> plus boatloads of stuff in wireless.
Andrew, can you send these two to me under seperate cover? I'll
i
> Conceptually, I see your point and I'm ok with doing it either
> way. My only question is, would this change would make the ipoib module
> dependent upon having the bonding module loaded (to resolve all of the
> symbols)?
Yes, I guess so, if that function is in bonding. Hmm, that woul
Roland Dreier <[EMAIL PROTECTED]> wrote:
>Actually, thinking about this some more... would it be cleaner to more
>the knowledge about bonding out of the ipoib driver? in other words,
>export something similar to
>
> > +static int ipoib_slave_detach(struct net_device *dev)
> > +{
> > + int ret =
Hi Randy,
> Just a few more minor changes... Thanks again.
Again, thank you. I have applied these two typo fixes, too.
urs
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Mon, 17 Sep 2007 14:16:22 -0700
> On Mon, 17 Sep 2007 17:46:38 +0530
> Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
> > Kernel Bug is hit with 2.6.23-rc4-mm1 kernel on ppc64 machine.
> >
> > kernel BUG at include/linux/netdevice.h:339!
>
> (please
Overall idea looks good... one comment:
> +if (n->dev->flags & IFF_MASTER) {
> +/* n->dev is not an IPoIB device and we have
> +to take priv from elsewhere */
> +neigh = *to_ipoib_neigh(n);
> +if (neigh) {
> +pri
OK with me.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Sep 07, 2007 at 11:27:49AM -0700, Jay Vosburgh wrote:
> Andy Gospodarek <[EMAIL PROTECTED]> wrote:
>
> This all looks fine except for one nit (well, request for extra
> detail, really):
>
> >@@ -802,15 +802,20 @@ BROADCAST=192.168.1.255
> > ONBOOT=yes
> > BOOTPROTO=none
> > USERCTL=
On 17 Sep 2007 22:49:34 +0200 Urs Thuermann wrote:
> Thomas Gleixner <[EMAIL PROTECTED]> writes:
>
> > Please do, having the patch in mail makes it easier to review and to
> > comment.
>
> OK, here it is:
Just a few more minor changes... Thanks again.
> +3. Socket CAN concept
> +
John Heffner wrote:
Rick Jones wrote:
John Heffner wrote:
Any reason you're overloading tcpi_unacked and tcpi_sacked? It seems
that setting idiag_rqueue and idiag_wqueue are sufficient.
Different fields for different structures. The tcp_info struct
doesn't have the idiag_mumble, so to
Actually, thinking about this some more... would it be cleaner to more
the knowledge about bonding out of the ipoib driver? in other words,
export something similar to
> +static int ipoib_slave_detach(struct net_device *dev)
> +{
> +int ret = 0;
> +if (dev->flags & IFF_SLAVE) {
> +
Looks fine overall, with one minor nitpick:
> -if (unlikely(memcmp(&neigh->dgid.raw,
> +if (unlikely((memcmp(&neigh->dgid.raw,
> skb->dst->neighbour->ha + 4,
> -sizeof(union
I tried to look at the ipoib stuff in this series... this patch looks
fine but it doesn't actually touch ipoib, so the subject line is a bit
misleading...
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:/
> The IGMP enabling patch posted by me on September 2nd isn't on your list
> http://lists.openfabrics.org/pipermail/general/2007-September/040250.html
> can you add it?
Yes, I lost that somehow. I will add it to my list of things to take
a look at (no opinion yet).
- R.
-
To unsubscribe from
On 9/17/07, Domen Puncer <[EMAIL PROTECTED]> wrote:
> Export phy_mii_ioctl, so network drivers can use it when built
> as modules too.
Domen, do you want to collect all of these changes for MPC5200 FEC in
to a single patch series? The code is getting scattered around, I'll
check it over to make su
On Fri, Sep 07, 2007 at 11:27:49AM -0700, Jay Vosburgh wrote:
> Andy Gospodarek <[EMAIL PROTECTED]> wrote:
>
> This all looks fine except for one nit (well, request for extra
> detail, really):
>
> >@@ -802,15 +802,20 @@ BROADCAST=192.168.1.255
> > ONBOOT=yes
> > BOOTPROTO=none
> > USERCTL=
> > IPoIB CM handles this properly by gathering together single pages in
> > skbs' fragment lists.
> Then can we reuse IPoIB CM code here?
Yes, if possible, refactoring things so that the rx skb allocation
code becomes common between CM and non-CM would definitely make sense.
-
To unsubscribe
On Fri, Sep 07, 2007 at 11:27:49AM -0700, Jay Vosburgh wrote:
> Andy Gospodarek <[EMAIL PROTECTED]> wrote:
>
> This all looks fine except for one nit (well, request for extra
> detail, really):
>
> >@@ -802,15 +802,20 @@ BROADCAST=192.168.1.255
> > ONBOOT=yes
> > BOOTPROTO=none
> > USERCTL=
On Mon, 17 Sep 2007 14:18:26 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: David Miller <[EMAIL PROTECTED]>
> Date: Sun, 16 Sep 2007 20:22:58 -0700 (PDT)
>
> > Tomorrow (Monday) I want to rebase the net-2.6.24 tree one more time
> > to deal with all of the conflicts which exist betw
From: Rick Jones <[EMAIL PROTECTED]>
Date: Mon, 17 Sep 2007 13:30:12 -0700
> Different fields for different structures. The tcp_info struct doesn't
> have the idiag_mumble, so to get the two values shown in /proc/net/tcp I
> use tcpi_unacked and tcpi_sacked.
>
> For the INET_DIAG_INFO stuff t
From: David Miller <[EMAIL PROTECTED]>
Date: Sun, 16 Sep 2007 20:22:58 -0700 (PDT)
> Tomorrow (Monday) I want to rebase the net-2.6.24 tree one more time
> to deal with all of the conflicts which exist between
> linux-2.6/net-2.6 and net-2.6.24, but I'll likely defer that
> until the net-2.6 fixes
On Mon, 17 Sep 2007 17:46:38 +0530
Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Kernel Bug is hit with 2.6.23-rc4-mm1 kernel on ppc64 machine.
>
> kernel BUG at include/linux/netdevice.h:339!
(please cc netdev@vger.kernel.org on networking-related matters)
You died here:
static inline void na
Update the decode of sky2 registers.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/marvell.c 2007-09-17 14:03:08.0 -0700
+++ b/marvell.c 2007-09-17 14:05:44.0 -0700
@@ -183,6 +183,7 @@ static void dump_mac(const u8 *r)
case 0xb4: printf("Yukon-2 EC Ultra"
Denis V. Lunev wrote:
> I have also seen this OOPS on e1000 card. So, looks like driver independent.
>
> By the way, this one has been triggered in a semi-stable way by the
> 'git-pull'
Do you have this patch:
commit 5c127c58ae9bf196d787815b1bd6b0aec5aee816
Author: David S. Miller <[EMAIL PROTEC
L F wrote:
> On 9/17/07, Kok, Auke <[EMAIL PROTECTED]> wrote:
>> The statistic we were looking at _will_ increase when running in
>> half duplex, but if it increases when running in full duplex might
>> indicate a hardware failure. Probably you have fixed the issue with
>> the CAT6 cable.
> Uhm, '
Thomas Gleixner <[EMAIL PROTECTED]> writes:
> Please do, having the patch in mail makes it easier to review and to
> comment.
OK, here it is:
This patch adds documentation for the PF_CAN protocol family.
Signed-off-by: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-off-by: Urs Thuermann <[EMAIL P
Rick Jones wrote:
John Heffner wrote:
Any reason you're overloading tcpi_unacked and tcpi_sacked? It seems
that setting idiag_rqueue and idiag_wqueue are sufficient.
Different fields for different structures. The tcp_info struct doesn't
have the idiag_mumble, so to get the two values shown
Urs,
On Mon, 2007-09-17 at 22:22 +0200, Urs Thuermann wrote:
> Thank you very much. I have applied all your suggestions to our SVN
> repository. To reduce traffic on the list, I only repeat the pointer
> to the repository:
>
> http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/net
Hi Randy,
> Thanks for all of this informative documentation.
>
> I have some typo/spello corrections below.
Thank you very much. I have applied all your suggestions to our SVN
repository. To reduce traffic on the list, I only repeat the pointer
to the repository:
http://svn.berlios.de/svnroo
John Heffner wrote:
Any reason you're overloading tcpi_unacked and tcpi_sacked? It seems
that setting idiag_rqueue and idiag_wqueue are sufficient.
Different fields for different structures. The tcp_info struct doesn't
have the idiag_mumble, so to get the two values shown in /proc/net/tcp I
Export phy_mii_ioctl, so network drivers can use it when built
as modules too.
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
---
On 17/09/07 11:53 +0200, Sven Luther wrote:
> On Sat, Sep 15, 2007 at 02:14:44PM +0200, Domen Puncer wrote:
> > Updated and split version at:
> > http://coderock.org/
Any reason you're overloading tcpi_unacked and tcpi_sacked? It seems
that setting idiag_rqueue and idiag_wqueue are sufficient.
-John
Rick Jones wrote:
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that m
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Mon, 17 Sep 2007 11:38:09 -0700
Since small things fall more easily through cracks I thought I'd make
sure it didn't get lost?
Reposting the patch is often better because if you quote it
then the copy I have has to be meticuliou
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
Signed-off-by: Rick Jones <[EMAIL PROTECTED]>
Signed-off-by: Eric Dumazet <[EMAIL PR
On 09/17/2007 06:29 PM, Kok, Auke wrote:
> Jiri Slaby wrote:
>> On 12/23/-28158 08:59 PM, Auke Kok wrote:
>>> This incorporates the new napi_struct changes into e1000e. Included
>>> bugfix for ifdown hang from Krishna Kumar for e1000.
>>>
>>> Disabling polling is no longer needed at init time, so r
From: Rick Jones <[EMAIL PROTECTED]>
Date: Mon, 17 Sep 2007 11:38:09 -0700
> Since small things fall more easily through cracks I thought I'd make
> sure it didn't get lost?
Reposting the patch is often better because if you quote it
then the copy I have has to be meticuliously edited to remove
On 9/17/07, Kok, Auke <[EMAIL PROTECTED]> wrote:
> The statistic we were looking at _will_ increase when running in half duplex,
> but if it increases when running in full duplex might indicate a hardware
> failure. Probably you have fixed the issue with the CAT6 cable.
Uhm, 'fixed' may be prematur
Stephen Hemminger wrote:
On Mon, 17 Sep 2007 15:45:11 +0200
[EMAIL PROTECTED] wrote:
From: Daniel Lezcano <[EMAIL PROTECTED]>
Doing this makes loopback.c a better example of how to do a
simple network device, and it removes the special case
single static allocation of a struct net_device, hope
Rick Jones wrote:
> Kok, Auke wrote:
>> L F wrote:
>>
>>> tx_deferred_ok: 486
this one I wonder about, and might cause delays, I'll have to look
up what it exactly could implicate though.
>>>
>>> Please do and let me know. samba 3.0.26 helped, but the issue is
>>> still there.
>>
Since small things fall more easily through cracks I thought I'd make
sure it didn't get lost?
rick jones
Rick Jones wrote:
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can see in /proc/n
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Mon, 10 Sep 2007 11:42:18 -0700
I've been digging around to see about inducing /proc/net/tcp to show
some "interesting" things for listen sockets (eg backlog depth, its max,
and dropped connection requests). While there I've noti
I'm rebasing a 500 patch tree which has tons of merge conflicts today,
so I lack the time to answer your question.
Suffice it to say you could do a little bit of legwork to figure out
the answer by researching inet_csk_reqsk_queue_is_full() and
determining what sets the state tested by that funct
Kok, Auke wrote:
L F wrote:
tx_deferred_ok: 486
this one I wonder about, and might cause delays, I'll have to look
up what it exactly could implicate though.
Please do and let me know. samba 3.0.26 helped, but the issue is
still there.
ok, from the spec: tx_deferred_ok is what is in the
On Mon, 17 Sep 2007 12:03:28 +0200 Urs Thuermann wrote:
Hi,
Thanks for all of this informative documentation.
I have some typo/spello corrections below.
> This patch adds documentation for the PF_CAN protocol family.
>
> Signed-off-by: Oliver Hartkopp <[EMAIL PROTECTED]>
> Signed-off-by: Urs T
On Mon, 17 Sep 2007 15:45:11 +0200
[EMAIL PROTECTED] wrote:
> From: Daniel Lezcano <[EMAIL PROTECTED]>
>
> Doing this makes loopback.c a better example of how to do a
> simple network device, and it removes the special case
> single static allocation of a struct net_device, hopefully
> making mai
On Sun, 16 Sep 2007 23:43:40 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Sun, 16 Sep 2007 17:02:46 -0700 (PDT) [EMAIL PROTECTED] wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=9031
> >
> >Summary: TPC window is to cautious on send
> >Product: Networking
>
L F wrote:
>> To me it suggests that your speed is not full-duplex. Check `ethtool eth0`
>> output
>> and see if your link is full duplex or not. also check previous kernel
>> messages
>> and see what the e1000 driver posted there for link speed messages (as in
>> "e1000:
>> Link is UP speed XX
From: David Stevens <[EMAIL PROTECTED]>
Date: Sun, 16 Sep 2007 22:24:27 -0600
> Dave,
> Thanks. That rev2 was for v6-only; I didn't see anythng about the
> v4 patch (below, in case it fell through the cracks).
It did fall through the cracks, I've applied this and will
push unless some ser
From: "Ian Brown" <[EMAIL PROTECTED]>
Date: Mon, 17 Sep 2007 09:50:15 +0200
> Hello,
> This is a trivial typo correction in net/ipv4/xfrm4_policy.c which
> hunted my eye...
>
> Regards,
> Ian Brown
>
> Signed-off-by: [EMAIL PROTECTED]
Your mail client word-wrapped the patch so it doesn't app
From: Pavel Emelyanov <[EMAIL PROTECTED]>
Date: Mon, 17 Sep 2007 18:46:07 +0400
> The name struct net is too generic. There already were
> some people who wanted to have some better name (for
> easier grep for example). I propose the struct netns one.
I don't see any reason to change the name, 'n
> To me it suggests that your speed is not full-duplex. Check `ethtool eth0`
> output
> and see if your link is full duplex or not. also check previous kernel
> messages
> and see what the e1000 driver posted there for link speed messages (as in
> "e1000:
> Link is UP speed XXX duplex YYY")
fro
From: jamal <[EMAIL PROTECTED]>
Date: Mon, 17 Sep 2007 08:51:40 -0400
> On Sun, 2007-16-09 at 20:13 -0700, David Miller wrote:
>
> > This only makes sense for devices which can 1) scatter-gather
> > and 2) checksum on transmit.
>
> If you have knowledge there are enough descriptors in the driv
Jiri Slaby wrote:
> On 12/23/-28158 08:59 PM, Auke Kok wrote:
>> This incorporates the new napi_struct changes into e1000e. Included
>> bugfix for ifdown hang from Krishna Kumar for e1000.
>>
>> Disabling polling is no longer needed at init time, so remove
>> napi_disable() call from _probe().
>>
>
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Mon, 17 Sep 2007 00:10:40 -0400
> David Miller wrote:
> > We've touched so much in net-2.6.24 that we really should be auditing
> > the thing and fixing any bugs that have been added. If you're bored
> > and looking for something to do, pick an odd NAPI
On Mon, Sep 17, 2007 at 09:09:06AM -0700, Sean Hefty ([EMAIL PROTECTED]) wrote:
> >>>+addr = kmalloc(sizeof *addr, GFP_KERNEL);
> >>
> >>As a small nitpick: this wants to be sizeof(struct in_ifaddr)
>
> See chapter 14 of CodingStyle document. kmalloc(sizeof *addr... is correct.
Come on, do n
+addr = kmalloc(sizeof *addr, GFP_KERNEL);
As a small nitpick: this wants to be sizeof(struct in_ifaddr)
See chapter 14 of CodingStyle document. kmalloc(sizeof *addr... is correct.
- Sean
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMA
Daniel Lezcano wrote:
> Pavel Emelyanov wrote:
>> The name struct net is too generic. There already were
>> some people who wanted to have some better name (for
>> easier grep for example). I propose the struct netns one.
>>
>> The patch is (already) huge (sorry), but it's nothing but
>> sed -e s
Evgeniy Polyakov wrote:
Hi Steve.
On Sat, Sep 15, 2007 at 10:56:46AM -0500, Steve Wise ([EMAIL PROTECTED]) wrote:
The iWARP driver must translate all listens on address 0.0.0.0 to the
set of rdma-only ip addresses for the device in question. This prevents
incoming connect requests to the TCP
Pavel Emelyanov wrote:
The name struct net is too generic. There already were
some people who wanted to have some better name (for
easier grep for example). I propose the struct netns one.
The patch is (already) huge (sorry), but it's nothing but
sed -e s/struct net\>/struct netns/g
If this n
The name struct net is too generic. There already were
some people who wanted to have some better name (for
easier grep for example). I propose the struct netns one.
The patch is (already) huge (sorry), but it's nothing but
sed -e s/struct net\>/struct netns/g
If this name is bad as well, let's
Hi all!
I've just released my first beta of Linux Network Load Balancing
it's a driver (+ userland tool) to make decentered load balancing
clusters.
I hope someone is interested in the project and could do some testing
in decent environments (I've just done some "laboratory" test in a 3
virtua
I have also seen this OOPS on e1000 card. So, looks like driver independent.
By the way, this one has been triggered in a semi-stable way by the
'git-pull'
Regards,
Den
Dhaval Giani wrote:
> On Thu, Sep 13, 2007 at 11:51:33PM -0400, Andrew James Wade wrote:
>> I have an Oops that may be
On Mon, Sep 17, 2007 at 09:03:58AM -0400, jamal ([EMAIL PROTECTED]) wrote:
> > Did I understand you right, that you replaced trylock with lock and
> > thus removed collision handling and got better results?
>
> Yes, a small one with the 4 CPUs and no irq binding. Note that in the
> test cases i ru
On Thu, Sep 13, 2007 at 11:51:33PM -0400, Andrew James Wade wrote:
> I have an Oops that may be related:
>
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 0025
> printing eip: c037d81b *pde =
> Oops: [#1]
> last sysfs file: /devices/pci:00/:0
[snip]
> Pavel if you are going down this route. Could you look at
> cleanup_net as well. The reverse walk there could probably
> benefit from being list_for_each_entry_reverse.
Oh! Thanks a lot ;) Here's the new patch.
Log:
I proposed introducing a list_for_each_entry_continue_reverse
macro
From: Daniel Lezcano <[EMAIL PROTECTED]>
This patch replaces all occurences to the static variable
loopback_dev to a pointer loopback_dev. That provides the
mindless, trivial, uninteressting change part for the dynamic
allocation for the loopback.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTE
This patch allows to dynamically allocate the loopback
like an usual network device.
This global static variable loopback_dev has been replaced by a
netdev pointer and the init function does the usual allocation,
initialization and registering of the loopback.
This patchset is splitted in two par
From: Daniel Lezcano <[EMAIL PROTECTED]>
Doing this makes loopback.c a better example of how to do a
simple network device, and it removes the special case
single static allocation of a struct net_device, hopefully
making maintenance easier.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
Si
David Miller wrote:
> From: Vlad Yasevich <[EMAIL PROTECTED]>
> Date: Thu, 13 Sep 2007 15:34:35 -0400
>
>> Thanks to Sridhar Samudral and Paul McKenney for all the help and comments.
>> I think this is a final version, unless someone else can spot more problems.
>> I've ran this under heavy load a
Pavel Emelyanov <[EMAIL PROTECTED]> writes:
> I proposed introducing a list_for_each_entry_continue_reverse
> macro to be used in setup_net() when unrolling the failed
> ->init callback.
>
> Here is the macro and some more cleanup in the setup_net() itself
> to remove one variable from the stack :
1 - 100 of 116 matches
Mail list logo
