Update skb with the real packet size.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/driv
Hi,
This patch was already merged in Jeff Garzik's netdev upstream branch but
needs to go into 12.6.16.y and 2.6.17rc* as it fixes a critical buffersize
skb bug that is exposed by an earlier patch by Dave Miller and Herbert
Xiu. I'm therefore resending it:
Please apply to 2.6.16.y and queue for
Hi,
On Wed, Apr 26, 2006 at 02:36:18AM +0200, Nuri Jawad told us:
> >no problems here with pppoe, kernel is 2.6.17-rc1-mm1, ppp 2.4.4-b1.
>
> Did you create a high load on the system in the manner I described?
> The bug once only appeared after about 6 hours here when line + CPU had
> been most
Signed-off-by: Kelly Daly <[EMAIL PROTECTED]>
Hacked udp.c to receive directly to VJ Channel socket.
Breaks normal UDP - sockets don't speak non-VJ anymore!
diff -r 47031a1f466c linux-2.6.16/include/linux/udp.h
--- linux-2.6.16/include/linux/udp.hThu Mar 23 06:32:12 2006
+++ linux-2.6.
Today 11:25:13
Signed-off-by: Kelly Daly <[EMAIL PROTECTED]>
Hacked NE2K driver using VJ Channels on receive.
Takes packet data and dumps it into a VJ buffer instead of skb.
Not implemented on transmit.
Useful for testing under QEMU.
-
diff -r 47031a1f466c linux-2.6.16/drivers/net/8390.
Hey guys... I've been working with Rusty on a VJ Channel implementation.
Noting Dave's recent release of his implementation, we thought we'd better
get this "out there" so we can do some early comparison/combining and
come up with the best possible implementation.
There are three patches in t
no problems here with pppoe, kernel is 2.6.17-rc1-mm1, ppp 2.4.4-b1.
Did you create a high load on the system in the manner I described?
The bug once only appeared after about 6 hours here when line + CPU had
been mostly idle. But that was the longest time between failures. Can you
test with o
On Monday 17 April 2006 11:18, Stephen Hemminger wrote:
> I don't know what you are doing different, but my 2 port SysKonnect
> card is working fine. Running SMP AMD64 and 2.6.17 latest.
>
> Showing full speed on both ports.
I missed that e-mail, sorry.
I just gave it another try, this time with
On Wed, 26 Apr 2006 00:39:00 +0200
Francois Romieu <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger <[EMAIL PROTECTED]> :
> [...]
> > > Any objection against moving mod_timer() from sky2_poll() to sky2_idle()
> > > so as to keep poll() path unmodified ?
> > >
> >
> > If traffic is moving, then I w
Stephen Hemminger <[EMAIL PROTECTED]> :
[...]
> > Any objection against moving mod_timer() from sky2_poll() to sky2_idle()
> > so as to keep poll() path unmodified ?
> >
>
> If traffic is moving, then I want the timer to keep getting rescheduled
> farther out.
If my version of the driver is not
On Tue, 25 Apr 2006 14:46:49 -0700 (PDT)
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Tue, 25 Apr 2006 10:01:49 -0700
>
> > > # Hit# miss Function:[EMAIL PROTECTED]
> > > ! 0 50505 tcp_transmit_skb():net/ipv4/[EMAIL PROTE
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 25 Apr 2006 10:01:49 -0700
> > # Hit# miss Function:[EMAIL PROTECTED]
> > ! 0 50505 tcp_transmit_skb():net/ipv4/[EMAIL PROTECTED]
...
> How about just taking off the likely/unlikely in this case.
Why remove it when we'l
On Tue, 25 Apr 2006 23:23:29 +0200
Francois Romieu <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger <[EMAIL PROTECTED]> :
> [...]
> > --- sky2-2.6.17.orig/drivers/net/sky2.c 2006-04-25 10:48:47.0
> > -0700
> > +++ sky2-2.6.17/drivers/net/sky2.c 2006-04-25 10:53:32.0 -0700
> > @
Stephen Hemminger <[EMAIL PROTECTED]> :
[...]
> --- sky2-2.6.17.orig/drivers/net/sky2.c 2006-04-25 10:48:47.0
> -0700
> +++ sky2-2.6.17/drivers/net/sky2.c2006-04-25 10:53:32.0 -0700
> @@ -2086,6 +2086,20 @@
> }
> }
>
> +/* If idle then force a fake soft NAPI poll
This is a workaround for the case edge-triggered irq's. Several users
seem to have broken configurations sharing edge-triggered irq's. To avoid
losing IRQ's, reshedule if more work arrives.
The changes to netdevice.h are to extract the part that puts device
back in list into separate inline.
Sign
Update to version 1.2
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-04-25 10:54:57.0 -0700
+++ sky2-2.6.17/drivers/net/sky2.c 2006-04-25 10:55:51.0 -0700
@@ -51,7 +51,7 @@
#include "sky2.h"
#define DRV_NAME
Update to sky2 driver. Mostly fixes to try and handle users
stuck with edge-triggered interrupts. Also, some minor cleanups.
Patches apply onto 1.1 version in 2.6.17-rc2
--
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majo
The sky2_reset function only called from sky2_probe.
Maybe the compiler was smart enough to figure this out already.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-04-25 10:53:37.0 -0700
+++ sky2-2.6.17/drivers/net/sky2.c 2006-04-25
The ALIGN() macro in kernel.h does the same math that the
sky2 driver was using for padding.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-04-25 10:47:03.0 -0700
+++ sky2-2.6.17/drivers/net/sky2.c 2006-04-25 10:47:28.0 -0700
Add an fake NAPI schedule once a second. This is an attempt to work around
for broken configurations with edge-triggered interrupts.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-04-25 10:48:47.0 -0700
+++ sky2-2.6.17/drivers/net/sky2.c
Rick Jones wrote:
lumber:~# cat /etc/udev/rules.d/010_netinterfaces.rules
KERNEL="eth*",SYSFS{address}=="00:30:6e:4c:27:3c", NAME="eth0"
KERNEL="eth*",SYSFS{address}=="00:30:6e:4c:27:3d", NAME="eth1"
KERNEL="eth*",SYSFS{address}=="00:12:79:9e:0e:d2", NAME="eth2"
KERNEL="eth*",SYSFS{address}=="00:
Jesse Brandeburg wrote:
On 4/24/06, Rick Jones <[EMAIL PROTECTED]> wrote:
The udev stuff runs after the device has already chosen it's default name.
It has to, it's part of the hotplug infrastructure, and we don't want
to depend on usermode to define the name. Just choose some other
convention
Need to allow for VLAN header when bridging.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- bridge.orig/net/bridge/br_forward.c 2006-04-10 16:17:51.0 -0700
+++ bridge/net/bridge/br_forward.c 2006-04-19 13:50:42.0 -0700
@@ -16,6 +16,7 @@
#include
#include
#incl
On Mon, 24 Apr 2006 16:25:39 -0700
Hua Zhong <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am developing a profiling tool to check if likely/unlikely usages are wise.
> I find that the following one is always a miss:
>
> # Hit# miss Function:[EMAIL PROTECTED]
> ! 0 50505 tcp_tran
On 4/19/06, David S. Miller <[EMAIL PROTECTED]> wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Thu, 20 Apr 2006 15:04:06 +1000
>
> > On Wed, Apr 19, 2006 at 09:55:13PM -0700, David S. Miller wrote:
> > > +static inline void skb_truesize_check(struct sk_buff *skb)
> > > +{
> > > + if (unlik
Begin forwarded message:
Date: Tue, 25 Apr 2006 01:57:50 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 6438] New: CISCO AIRONET 340 SERIES oops under PPC
http://bugzilla.kernel.org/show_bug.cgi?id=6438
Summary: CISCO AIRONET 340 SERIES oops under PPC
This patch provides a sysfs interface to change some properties of the
ibmveth buffer pools (size of the buffers, number of buffers per pool,
and whether a pool is active). Ethernet drivers use ethtool to provide
this type of functionality. However, the buffers in the ibmveth driver
can have an a
On 4/24/06, Rick Jones <[EMAIL PROTECTED]> wrote:
>
> > The udev stuff runs after the device has already chosen it's default name.
> > It has to, it's part of the hotplug infrastructure, and we don't want
> > to depend on usermode to define the name. Just choose some other
> > convention "eth_0"
On Tuesday 25 April 2006 16:44, John Que wrote:
> Thanks a lot !
>
> I had tried the sending RTM_GETROUTE message using a NETLINK_ROUTE
> socket in a User Space program and it went OK.
>
> It gaves correct routing struct which I could parse.
> In fact it gave the rotuing
Thanks a lot !
I had tried the sending RTM_GETROUTE message using a NETLINK_ROUTE
socket in a User Space program and it went OK.
It gaves correct routing struct which I could parse.
In fact it gave the rotuing table.
But in sending that message I did not
Zach Brown wrote:
My apologies if this is a FAQ, I couldn't find it in the archives.
We have some dudes who are syncing large amounts of data across a
dedicated long fat pipe at somewhat irregular intervals that are, sadly,
longer than the rto. They feel the pain of having to reopen the window
On Tue, 2006-04-25 at 13:30 +0200, Johannes Berg wrote:
> On Mon, 2006-04-24 at 20:33 -0400, Dan Williams wrote:
>
> > Any way to get the event handling cleanup patch into 2.6.17? It's
> > pretty much a bugfix and bcm43xx is useless with wpa_supplicant and NM
> > without the patch...
>
> No, tha
On Mon, 2006-04-24 at 20:33 -0400, Dan Williams wrote:
> Any way to get the event handling cleanup patch into 2.6.17? It's
> pretty much a bugfix and bcm43xx is useless with wpa_supplicant and NM
> without the patch...
No, that's not true, the cleanup patch is exactly that, code cleanup :)
Exte
On Mon, 24 Apr 2006, Auke Kok wrote:
> linux-os (Dick Johnson) wrote:
>> On Mon, 24 Apr 2006, Auke Kok wrote:
>>
>>> Ingo Oeser wrote:
On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
> That was another main point, yes. And the endpoints should be as
> little burden on the bottl
Horrible typo! I really should have gone to sleep now.
Correct patch attached.
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 18d7fad..c9026db 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -337,7 +337,7 @@ static inline int ip_rcv_finish(struct s
* Ini
Hi,
This is another result from my likely profiling tool ([EMAIL PROTECTED] just
sent the patch of the profiling tool to linux-kernel mailing list, which is
similar to what I use).
On my system (not very busy, normal development machine within a VMWare workstation), I
see a 6/5 miss/hit ratio
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 25 Apr 2006 09:43:49 +0200
> On Tuesday 25 April 2006 09:31, John Que wrote:
> > Hello,
> > What is the right way to determine on which interface card
> > (eth0 or eth1) will a packet be sent (according to the dest IP)?
>
> You can send a rtnetlink
On Tuesday 25 April 2006 09:31, John Que wrote:
> Hello,
> What is the right way to determine on which interface card
> (eth0 or eth1) will a packet be sent (according to the dest IP)?
You can send a rtnetlink RTM_GETROUTE message to ask the kernel.
Result is the interface index in RTA_OIF, which
Hello,
What is the right way to determine on which interface card
(eth0 or eth1) will a packet be sent (according to the dest IP)?
I have a machine with two NICS (eth0 and eth1).
I have 2 different gateways.
I need to know on which interface (eth0 or eth1) will the
packet be send according to the
39 matches
Mail list logo
