* Engress path / congestion detection and avoidance
From: Jeba Anandhan @ 2008-02-11 10:38 UTC (permalink / raw)
To: netdev; +Cc: matthew.hattersley
Hi All,
i have few doubts related to congestion and engress path.
1) What happens when congestion hits and how it affects engress path?.
2) How the engress traffic slow down when the congestion hits?
3) what are the variables updated when the congestion hits?
4) is it good to invoke netif_stop_queue when congestion hits?
thanks
Jeba
^ permalink raw reply
* Re: [PATCH][RESEND] drivers/base: export (un)register_memory_notifier
From: Jan-Bernd Themann @ 2008-02-11 10:47 UTC (permalink / raw)
To: Dave Hansen
Cc: Greg KH, Jan-Bernd Themann, Thomas Klein, netdev, linux-kernel,
linux-ppc, Christoph Raisch
In-Reply-To: <1202724743.8276.2.camel@nimitz.home.sr71.net>
On Monday 11 February 2008 11:12, Dave Hansen wrote:
> On Mon, 2008-02-11 at 10:49 +0100, Jan-Bernd Themann wrote:
> > are you the right person to address this patch to?
>
> You might want to check the top of the file. ;)
>
> > --- a/drivers/base/memory.c
> > +++ b/drivers/base/memory.c
> > @@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
> > {
> > return blocking_notifier_chain_register(&memory_chain, nb);
> > }
> > +EXPORT_SYMBOL(register_memory_notifier);
> >
> > void unregister_memory_notifier(struct notifier_block *nb)
> > {
> > blocking_notifier_chain_unregister(&memory_chain, nb);
> > }
> > +EXPORT_SYMBOL(unregister_memory_notifier);
>
> Is there a particular reason these can't be GPL?
>
I don't object to make them GPL. Greg, what do you think?
Regards,
Jan-Bernd
^ permalink raw reply
* Re: [patch 2.6.24-git] net/enc28j60: oops fix, low power mode
From: Claudio Lanconelli @ 2008-02-11 12:07 UTC (permalink / raw)
To: David Brownell; +Cc: netdev
In-Reply-To: <200802100954.18225.david-b@pacbell.net>
David Brownell wrote:
>> > and in the enc28j60_net_close() after enc28j60_hw_disable().
>> > Probably we don't need to set_lowpower(false) in enc28j60_net_open() since
>> > it performs a soft reset with enc28j60_hw_init() (not sure).
>>
>
> The current patch sets the device in low power mode in hw_disable(),
> and takes it out of that mode in hw_enable(). I can move them; and
> the only "soft" thing about this chip's reset is when it starts from
> a protocol command not the reset command.
>
>
I want to mean the reset software command. It's functionally
equivalent to hardware system reset, but it seems to need exit low
power mode to work flawlessly.
I have tried your latest patch. Only after the following change it
works fine (no more rx errors during ifconfig up).
I added enc28j60_lowpower(false) just before enc28j60_hw_init()
@@ -1318,8 +1347,9 @@
}
return -EADDRNOTAVAIL;
}
- /* Reset the hardware here */
+ /* Reset the hardware here (and take it out of low power mode) */
enc28j60_hw_disable(priv);
+ enc28j60_lowpower(priv, false);
if (!enc28j60_hw_init(priv)) {
if (netif_msg_ifup(priv))
dev_err(&dev->dev, "hw_reset() failed\n");
With this addition you can add Acked-by line.
Thank you.
>> After a couple of :
>>
>> ifconfig eth0 down
>> (wait just 1 second)
>> ifconfig eth0 up
>>
>> the network is frozen.
>>
>> If I do another
>> ifconfig eth0 down
>> (wait just 1 second)
>> ifconfig eth0 up
>>
>> restarts.
>> It's random, no rule.
>>
>
> I write a shell loop to do that, and added a "ping -c2" too.
> If that was done before the "sleep 1" no packets flowed.
> Afterwards, no problem -- ever.
>
> (And outside the loop, "ethool -s eth1 duplex full".)
>
>
>
I forgot to tell that during my test I have a web server running on the
board and
a client continuously requesting a page.
^ permalink raw reply
* [PATCH][AX25] ax25_route: make ax25_route_lock BH safe
From: Jarek Poplawski @ 2008-02-11 12:42 UTC (permalink / raw)
To: David Miller
Cc: Jann Traschewski, Bernard Pidoux F6BVP, Ralf Baechle DL5RB,
netdev
In-Reply-To: <000d01c86c8b$fd9e67d0$453c822c@dg8ngn>
Subject: [AX25] ax25_route: make ax25_route_lock BH safe
> =================================
> [ INFO: inconsistent lock state ]
> 2.6.24-dg8ngn-p02 #1
> ---------------------------------
> inconsistent {softirq-on-W} -> {in-softirq-R} usage.
> linuxnet/3046 [HC0[0]:SC1[2]:HE1:SE0] takes:
> (ax25_route_lock){--.+}, at: [<f8a0cfb7>] ax25_get_route+0x18/0xb7 [ax25]
> {softirq-on-W} state was registered at:
...
This lockdep report shows that ax25_route_lock is taken for reading in
softirq context, and for writing in process context with BHs enabled.
So, to make this safe, all write_locks in ax25_route.c are changed to
_bh versions.
Reported-by: Jann Traschewski <jann@gmx.de>,
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---
diff -Nurp 2.6.24-mm1-/net/ax25/ax25_route.c 2.6.24-mm1+/net/ax25/ax25_route.c
--- 2.6.24-mm1-/net/ax25/ax25_route.c 2008-02-05 07:45:38.000000000 +0000
+++ 2.6.24-mm1+/net/ax25/ax25_route.c 2008-02-11 11:58:47.000000000 +0000
@@ -45,7 +45,7 @@ void ax25_rt_device_down(struct net_devi
{
ax25_route *s, *t, *ax25_rt;
- write_lock(&ax25_route_lock);
+ write_lock_bh(&ax25_route_lock);
ax25_rt = ax25_route_list;
while (ax25_rt != NULL) {
s = ax25_rt;
@@ -68,7 +68,7 @@ void ax25_rt_device_down(struct net_devi
}
}
}
- write_unlock(&ax25_route_lock);
+ write_unlock_bh(&ax25_route_lock);
}
static int __must_check ax25_rt_add(struct ax25_routes_struct *route)
@@ -82,7 +82,7 @@ static int __must_check ax25_rt_add(stru
if (route->digi_count > AX25_MAX_DIGIS)
return -EINVAL;
- write_lock(&ax25_route_lock);
+ write_lock_bh(&ax25_route_lock);
ax25_rt = ax25_route_list;
while (ax25_rt != NULL) {
@@ -92,7 +92,7 @@ static int __must_check ax25_rt_add(stru
ax25_rt->digipeat = NULL;
if (route->digi_count != 0) {
if ((ax25_rt->digipeat = kmalloc(sizeof(ax25_digi), GFP_ATOMIC)) == NULL) {
- write_unlock(&ax25_route_lock);
+ write_unlock_bh(&ax25_route_lock);
return -ENOMEM;
}
ax25_rt->digipeat->lastrepeat = -1;
@@ -102,14 +102,14 @@ static int __must_check ax25_rt_add(stru
ax25_rt->digipeat->calls[i] = route->digi_addr[i];
}
}
- write_unlock(&ax25_route_lock);
+ write_unlock_bh(&ax25_route_lock);
return 0;
}
ax25_rt = ax25_rt->next;
}
if ((ax25_rt = kmalloc(sizeof(ax25_route), GFP_ATOMIC)) == NULL) {
- write_unlock(&ax25_route_lock);
+ write_unlock_bh(&ax25_route_lock);
return -ENOMEM;
}
@@ -120,7 +120,7 @@ static int __must_check ax25_rt_add(stru
ax25_rt->ip_mode = ' ';
if (route->digi_count != 0) {
if ((ax25_rt->digipeat = kmalloc(sizeof(ax25_digi), GFP_ATOMIC)) == NULL) {
- write_unlock(&ax25_route_lock);
+ write_unlock_bh(&ax25_route_lock);
kfree(ax25_rt);
return -ENOMEM;
}
@@ -133,7 +133,7 @@ static int __must_check ax25_rt_add(stru
}
ax25_rt->next = ax25_route_list;
ax25_route_list = ax25_rt;
- write_unlock(&ax25_route_lock);
+ write_unlock_bh(&ax25_route_lock);
return 0;
}
@@ -152,7 +152,7 @@ static int ax25_rt_del(struct ax25_route
if ((ax25_dev = ax25_addr_ax25dev(&route->port_addr)) == NULL)
return -EINVAL;
- write_lock(&ax25_route_lock);
+ write_lock_bh(&ax25_route_lock);
ax25_rt = ax25_route_list;
while (ax25_rt != NULL) {
@@ -174,7 +174,7 @@ static int ax25_rt_del(struct ax25_route
}
}
}
- write_unlock(&ax25_route_lock);
+ write_unlock_bh(&ax25_route_lock);
return 0;
}
@@ -188,7 +188,7 @@ static int ax25_rt_opt(struct ax25_route
if ((ax25_dev = ax25_addr_ax25dev(&rt_option->port_addr)) == NULL)
return -EINVAL;
- write_lock(&ax25_route_lock);
+ write_lock_bh(&ax25_route_lock);
ax25_rt = ax25_route_list;
while (ax25_rt != NULL) {
@@ -216,7 +216,7 @@ static int ax25_rt_opt(struct ax25_route
}
out:
- write_unlock(&ax25_route_lock);
+ write_unlock_bh(&ax25_route_lock);
return err;
}
@@ -492,7 +492,7 @@ void __exit ax25_rt_free(void)
{
ax25_route *s, *ax25_rt = ax25_route_list;
- write_lock(&ax25_route_lock);
+ write_lock_bh(&ax25_route_lock);
while (ax25_rt != NULL) {
s = ax25_rt;
ax25_rt = ax25_rt->next;
@@ -500,5 +500,5 @@ void __exit ax25_rt_free(void)
kfree(s->digipeat);
kfree(s);
}
- write_unlock(&ax25_route_lock);
+ write_unlock_bh(&ax25_route_lock);
}
^ permalink raw reply
* [PATCH] virtio_net: Fix oops on early interrupts - introduced by virtio reset code
From: Christian Borntraeger @ 2008-02-11 13:11 UTC (permalink / raw)
To: Avi Kivity; +Cc: dor.laor, Anthony Liguori, kvm-devel, virtualization, netdev
Avi,
this fixes a problem that was introduced by the virtio_reset patches.
Can you apply that fix to kvm.git as a bugfix, as the virtio_reset
infrastructure is not on Linus upstream yet?
Anthony, Dor,
are you ok with that change?
--
With the latest virtio_reset patches I got the following oops:
Unable to handle kernel pointer dereference at virtual kernel address 0000000000000000
Oops: 0004 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 Not tainted 2.6.24zlive-guest-10577-g63f5307-dirty #168
Process swapper (pid: 0, task: 000000000f866040, ksp: 000000000f86fd78)
Krnl PSW : 0404100180000000 000000000047598a (skb_recv_done+0x52/0x98)
R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0 EA:3
Krnl GPRS: 0000000000000001 0000000000000000 000000000efd0e60 0000000000000001
0000000000000000 000000000f866040 0000000000000000 0000000000000000
00000000008de4c8 0000000000001237 0000000000001237 000000000f977dd8
0000000000000020 00000000001132bc 000000000f977e08 000000000f977dd8
Krnl Code: 000000000047597c: e31040300004 lg %r1,48(%r4)
0000000000475982: b9040001 lgr %r0,%r1
0000000000475986: b9810003 ogr %r0,%r3
>000000000047598a: eb1040300030 csg %r1,%r0,48(%r4)
0000000000475990: a744fff9 brc 4,475982
0000000000475994: a7110001 tmll %r1,1
0000000000475998: a7840009 brc 8,4759aa
000000000047599c: e340b0b80004 lg %r4,184(%r11)
Call Trace:
([<000001500f978000>] 0x1500f978000)
[<00000000004779a6>] vring_interrupt+0x72/0x88
[<0000000000491d9c>] kvm_extint_handler+0x34/0x44
[<000000000010d2d4>] do_extint+0xc0/0xfc
[<0000000000113b5a>] ext_no_vtime+0x1c/0x20
[<000000000010a0b6>] cpu_idle+0x21a/0x230
We must initialize vdev->priv before we use the notify hypercall as
vdev->priv is used in skb_recv_done. So lets move the assignment of
vdev->priv before we call try_fill_recv.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: kvm/drivers/net/virtio_net.c
===================================================================
--- kvm.orig/drivers/net/virtio_net.c
+++ kvm/drivers/net/virtio_net.c
@@ -361,6 +361,7 @@ static int virtnet_probe(struct virtio_d
netif_napi_add(dev, &vi->napi, virtnet_poll, napi_weight);
vi->dev = dev;
vi->vdev = vdev;
+ vdev->priv = vi;
/* We expect two virtqueues, receive then send. */
vi->rvq = vdev->config->find_vq(vdev, 0, skb_recv_done);
@@ -395,7 +396,6 @@ static int virtnet_probe(struct virtio_d
}
pr_debug("virtnet: registered device %s\n", dev->name);
- vdev->priv = vi;
return 0;
unregister:
^ permalink raw reply
* Re: Protocol handler for Marvell DSA EtherType packets
From: Jesper Dangaard Brouer @ 2008-02-11 13:18 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: David S. Miller
In-Reply-To: <1201872514.17661.50.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 5251 bytes --]
Hi NetDev and Google,
The answer to my question was:
Aha, you are trying to use tcpdump to see the "encapsulated" packets,
then you also need to adjust skb->mac.raw.
I have attached the code (and inlined the receive func, for easier
commenting), as I have another question:
I use dev_get_by_index() which calls dev_hold() (via my function
m88e_get_netdevice()).
The question is:
Should I use dev_put() before or after calling netif_rx(skb).
--
Med venlig hilsen / Best regards
Jesper Brouer
ComX Networks A/S
Linux Network developer
Cand. Scient Datalog / MSc.
Author of http://adsl-optimizer.dk
LinkedIn: http://www.linkedin.com/in/brouer
On Fri, 2008-02-01 at 14:28 +0100, Jesper Dangaard Brouer wrote:
> Hi Netdev
>
> I writing a new protocol handler using dev_add_pack(). (For a Marvell
> switch chip handling DSA (Distributed Switch Architecture) Ethertype
> packets).
>
> My protocol handler works and I get the skb. But I want to remove the
> DSA Headers and send the packet back for normal processing on a
> device. (I actually just want to be able to tcpdump these packets on
> the device).
>
> I'm removing the headers by:
> skb_pull(skb, sizeof(struct dsa_header));
>
> I'm trying to retransmit it by:
> netif_rx(skb);
>
> But it seems that I just retransmit the same packet without removing
> the DSA headers.
>
> Any hints about which functions I should use the remove the DSA header?
/*
* Main DSA Receive routine.
*/
int dsa_receive(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt)
{
int res = NET_RX_SUCCESS;
struct dsa_header *dsa_hdr;
struct proto_header *proto_hdr;
struct net_device *port_dev; /* the port associated net_device*/
struct ethhdr *eth_hdr;
/*
if (skb->pkt_type == PACKET_OTHERHOST) VERBOSE("PACKET_OTHERHOST");
else if (skb->pkt_type == PACKET_BROADCAST) VERBOSE("PACKET_BROADCAST");
else if (skb->pkt_type == PACKET_MULTICAST) VERBOSE("PACKET_MULTICAST");
else if (skb->pkt_type == PACKET_HOST) VERBOSE("PACKET_HOST");
else VERBOSE("PACKET_TYPE UNKNOWN");
*/
// Access to the real mac header
eth_hdr = (struct ethhdr *)skb->mac.raw; // Same as eth_hdr(skb)
// At this point the Ethernet header has been removed, but the
// DSA EtherType header contains two extra reserved bytes,
// move the pointer past these.
//
// DEBUGOUT("Removing 2 reserved bytes from DSA EtherType tag");
skb_pull(skb, 2);
// Access to the DSA packet information
dsa_hdr = (struct dsa_header *) skb->data;
if (net_ratelimit()) {
printk(KERN_INFO);
printk("Dev:%s ", skb->dev->name);
printk("Type 0x%x ", dsa_hdr->type);
printk("Tagged 0x%x ", dsa_hdr->tagged);
// printk("Dev 0x%x ", dsa_hdr->dev);
printk("Port 0x%x ", dsa_hdr->port);
printk("Info 0x%x ", dsa_hdr->info);
printk("Prio 0x%x ", dsa_hdr->pri);
printk("Res 0x%x ", dsa_hdr->res);
printk("VLAN ID 0x%x ",dsa_hdr->vid);
printk("\n");
}
// Decoding the DSA type
switch(dsa_hdr->type) {
case DSA_TO_CPU:
{
int code = ((dsa_hdr->info)&0x06)|dsa_hdr->res;
if(IGMP_TRAP == code) {
printk("IGMP Trap\n");
} else {
printk("Unsupported code %d\n",code);
}
break;
}
case DSA_FROM_CPU:
/*Fall through*/
case DSA_TO_SNIFFER:
/*Fall through*/
if (net_ratelimit())
DEBUGOUT("Sniffer packet");
break;
case DSA_FORWARD:
/*Fall through*/
default:
break;
}
// Find the device associated with the switch port.
//
// Q: m88e_get_netdevice() calls dev_get_by_index(), which it calls dev_hold()
port_dev = m88e_get_netdevice(dsa_hdr->port);
skb->dev = port_dev;
// Move past the DSA header
skb_pull(skb, sizeof(struct dsa_header));
// TEST: if it possible to change some skb data and see it in tcpdump
// eth_hdr->h_proto = 0x9111;
/* Extract the ethertype of the encapsulated packet, and
indicate the protocol to the next layer. */
proto_hdr = (struct proto_header*) skb->data;
skb->protocol = proto_hdr->h_proto;
if (net_ratelimit())
printk(KERN_ERR "Encapsulated packet Protocol 0x%x\n",skb->protocol);
// HACK, shift the mac header, this allows packet sniffers to
// decode the packet as a normal ethernet packet, but the mac
// address will not be correct.
skb->mac.raw = skb->data - (6+6);
// Q: Is it allowed to modify the skb data, I would like to
// correct the MAC headers, but is that allowed? Do I need to
// skb_copy the packet?
// Move past the EtherType of the encapsulated packet
skb_pull(skb, sizeof(struct proto_header));
// FIXME: Perhaps we need to change skb->pkt_type to
// PACKET_HOST, to make the next protocol handlers
// accept/process the data???
//skb->pkt_type = PACKET_HOST;
// Retransmit it on a virtual switch port device... this will
// e.g. send it to the IGMP protocol handler.
res = netif_rx(skb);
// Release the device pointer
if (port_dev)
dev_put(port_dev);
return res;
drop:
kfree_skb(skb);
out:
return NET_RX_DROP;
}
static struct packet_type dsa_packet_type =
{
.type = __constant_htons(ETHERTYPE_DSA),
.dev = NULL, /* NULL is wildcarded interfaces */
.func = dsa_receive,
.data = NULL,
//.data = (void*)1, /* Set here '(void *)1' when this code can SHARE SKBs */
.next = NULL
};
[-- Attachment #2: ethertype_dsa.c --]
[-- Type: text/x-csrc, Size: 6773 bytes --]
/*
* Marvell DSA (Distributed Switch Architecture) Ethertype handling.
*
* Some Marvell switch chips support to send/trap/mirror special
* packets to another switch port. These special packets can contain
* some extra information stored in (whats called) a DSA tag. The
* chip also supports adding a special EtherType in front of the DSA
* tag, allowing a CPU (which attached to one of the switch ports)
* easier identification of DSA frames.
*
* Copyright (C) Jesper Dangaard Brouer, Visipia Aps.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
* SVN version info:
* $LastChangedDate: 2008-02-11 11:11:28 +0100 (Mon, 11 Feb 2008) $
* $LastChangedRevision: 5238 $
* $LastChangedBy: jdb $
*
*/
#include <linux/module.h>
#include <linux/kernel.h>
#include "ethertype_dsa.h"
#define MODULE_NAME "m88e_DSA"
#define M88E_DEBUG 1
#define M88E_VERBOSE 1
#include "m88e.h"
#ifndef NOTICE /* Handle if "m88e.h" debug macros are not included */
#define NOTICE(S) printk(KERN_NOTICE "NOTICE: " S "\n")
#define DEBUGOUT(S) printk(KERN_DEBUG S "\n")
#define DEBUGOUT1(S, A...) printk(KERN_DEBUG S "\n", A)
#endif/*NOTICE*/
#include <linux/netdevice.h> /* struct packet_type */
#include <linux/if_ether.h> /* struct ethhdr */
#include "m88e_dev.h" /* Access to port associated net_device's */
/*
Default EtherType set by Marvell is 0x9100, this should be changed
1) because its conflicts with double-tagging of VLANs
2) because it hits the same EtherType hash bucket (ptype_base) as IP and VLAN
*/
#define ETHERTYPE_DSA 0x9100
struct proto_header
{
unsigned short h_proto; /* packet type ID field */
} __attribute__((packed));
/*
* Main DSA Receive routine.
*/
int dsa_receive(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt)
{
int res = NET_RX_SUCCESS;
struct dsa_header *dsa_hdr;
struct proto_header *proto_hdr;
struct net_device *port_dev; /* the port associated net_device*/
struct ethhdr *eth_hdr;
/*
if (skb->pkt_type == PACKET_OTHERHOST) VERBOSE("PACKET_OTHERHOST");
else if (skb->pkt_type == PACKET_BROADCAST) VERBOSE("PACKET_BROADCAST");
else if (skb->pkt_type == PACKET_MULTICAST) VERBOSE("PACKET_MULTICAST");
else if (skb->pkt_type == PACKET_HOST) VERBOSE("PACKET_HOST");
else VERBOSE("PACKET_TYPE UNKNOWN");
*/
// Access to the real mac header
eth_hdr = (struct ethhdr *)skb->mac.raw; // Same as eth_hdr(skb)
// At this point the Ethernet header has been removed, but the
// DSA EtherType header contains two extra reserved bytes,
// move the pointer past these.
//
// DEBUGOUT("Removing 2 reserved bytes from DSA EtherType tag");
skb_pull(skb, 2);
// Access to the DSA packet information
dsa_hdr = (struct dsa_header *) skb->data;
if (net_ratelimit()) {
printk(KERN_INFO);
printk("Dev:%s ", skb->dev->name);
printk("Type 0x%x ", dsa_hdr->type);
printk("Tagged 0x%x ", dsa_hdr->tagged);
// printk("Dev 0x%x ", dsa_hdr->dev);
printk("Port 0x%x ", dsa_hdr->port);
printk("Info 0x%x ", dsa_hdr->info);
printk("Prio 0x%x ", dsa_hdr->pri);
printk("Res 0x%x ", dsa_hdr->res);
printk("VLAN ID 0x%x ",dsa_hdr->vid);
printk("\n");
}
// Decoding the DSA type
switch(dsa_hdr->type) {
case DSA_TO_CPU:
{
int code = ((dsa_hdr->info)&0x06)|dsa_hdr->res;
if(IGMP_TRAP == code) {
printk("IGMP Trap\n");
} else {
printk("Unsupported code %d\n",code);
}
break;
}
case DSA_FROM_CPU:
/*Fall through*/
case DSA_TO_SNIFFER:
/*Fall through*/
if (net_ratelimit())
DEBUGOUT("Sniffer packet");
break;
case DSA_FORWARD:
/*Fall through*/
default:
break;
}
// Find the device associated with the switch port.
port_dev = m88e_get_netdevice(dsa_hdr->port);
skb->dev = port_dev;
// Move past the DSA header
skb_pull(skb, sizeof(struct dsa_header));
// TEST: if it possible to change some skb data and see it in tcpdump
// eth_hdr->h_proto = 0x9111;
/* Extract the ethertype of the encapsulated packet, and
indicate the protocol to the next layer. */
proto_hdr = (struct proto_header*) skb->data;
skb->protocol = proto_hdr->h_proto;
if (net_ratelimit())
printk(KERN_ERR "Encapsulated packet Protocol 0x%x\n",skb->protocol);
// HACK, shift the mac header, this allows packet sniffers to
// decode the packet as a normal ethernet packet, but the mac
// address will not be correct.
skb->mac.raw = skb->data - (6+6);
// Q: Is it allowed to modify the skb data, I would like to
// correct the MAC headers, but is that allowed? Do I need to
// skb_copy the packet?
// Move past the EtherType of the encapsulated packet
skb_pull(skb, sizeof(struct proto_header));
// FIXME: Perhaps we need to change skb->pkt_type to
// PACKET_HOST, to make the next protocol handlers
// accept/process the data???
//skb->pkt_type = PACKET_HOST;
// Retransmit it on a virtual switch port device... this will
// e.g. send it to the IGMP protocol handler.
res = netif_rx(skb);
// Release the device pointer
if (port_dev)
dev_put(port_dev);
return res;
drop:
kfree_skb(skb);
out:
return NET_RX_DROP;
}
static struct packet_type dsa_packet_type =
{
.type = __constant_htons(ETHERTYPE_DSA),
.dev = NULL, /* NULL is wildcarded interfaces */
.func = dsa_receive,
.data = NULL,
//.data = (void*)1, /* Set here '(void *)1' when this code can SHARE SKBs */
.next = NULL
};
void dsa_register_handler(void)
{
// Only process DSA packets on CPU to switch device, trying to
// avoid loops.
dsa_packet_type.dev = dev_get_by_name("ixp1");
// TODO: Increase the MTU on the receiving device, the DSA
// EtherType is 4 bytes and the DSA info is 4 bytes.
NOTICE("Register: DSA EtherType packet handler");
dev_add_pack(&dsa_packet_type);
}
void dsa_unregister_handler(void)
{
NOTICE("Unregister: DSA EtherType packet handler");
dev_remove_pack(&dsa_packet_type);
}
[-- Attachment #3: ethertype_dsa.h --]
[-- Type: text/x-chdr, Size: 2018 bytes --]
/*
* Marvell DSA (Distributed Switch Architecture) Ethertype handling.
*
* Copyright (C) Jesper Dangaard Brouer, Visipia Aps.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*
* SVN version info:
* $LastChangedDate: 2008-02-11 11:11:28 +0100 (Mon, 11 Feb 2008) $
* $LastChangedRevision: 5238 $
* $LastChangedBy: jdb $
*
*/
#ifndef _ethertype_dsa_H_
#define _ethertype_dsa_H_
#include <linux/types.h>
#include <asm/byteorder.h>
struct dsa_header {
__u8 type:2,
tagged:1,
dev:5;
__u8 port:5,
info:3; // Decoding dependent on type
#if defined(__BIG_ENDIAN_BITFIELD)
__u16 pri:3,
res:1,
vid:12;
#elif defined(__LITTLE_ENDIAN_BITFIELD)
#error "Not defined for Little Endian CPUs"
#else
#error "Adjust your <asm/byteorder.h> defines"
#endif
};
// DSA Tag Types
enum {
DSA_TO_CPU = 0x0, // b00
DSA_FROM_CPU = 0x1, // b01
DSA_TO_SNIFFER = 0x2, // b10
DSA_FORWARD = 0x3, // b11
};
// DSA_TO_CPU Support codes
enum {
BDPU_TRAP = 0x0, // b000
FRAME2REG_RESPONSE = 0x1, // b001
IGMP_TRAP = 0x2, // b010
POLICY_TRAP = 0x3, // b011
ARP_MIRROR = 0x4, // b100
POLICY_MIRROR = 0x5, // b101
};
extern void dsa_register_handler (void);
extern void dsa_unregister_handler(void);
#endif
^ permalink raw reply
* AW: Problem receiving multicast/promiscuous-mode with kernel.2.6.24
From: Reither Robert @ 2008-02-11 14:26 UTC (permalink / raw)
To: David Stevens; +Cc: netdev
Visit AVD on prolight+sound in Frankfurt from 12.-15. March 2008 - Hall 8.0, Stand G16
________________________________________________________________________
Hi David,
thanks for your help. Your input is always welcome ;-)
But according to Linux Programmer's Manual it should be OK to use ifindex of 0
e.g. (http://www.rt.com/man/ip.4.html)
but maybe this document is depcecated/obsolte ...
Well anyway, i did what u suggested, used eth0.3 as interface (i'm using VLAN)
Setting ifindex to eth0 won't help .. strange, but well ...,
maybe receiving is blocked by the virtual interface somehow, should be.
The problem is, now i get unreliable results.
At first attempt, it always worked as before with ifindex=0, but now further attempts SOMETIMES works !!!
Every 3rd or forth attempt i can receive the packets. (this way maybe the same with old method, i'll investigate further)
But netstat always shows the join (and the absence, if i close socket/leave mc-group)
IPv6/IPv4 Group Memberships
Interface RefCnt Group
--------------- ------ ---------------------
lo 1 224.0.0.1
eth0 1 224.0.0.1
eth0.3 1 224.1.9.0
eth0.3 1 224.0.0.1
Do u know a way to debug this further ?
It's not so easy for me to build a small app to show the faulty behav, but i'll try.
Robert
-----Ursprüngliche Nachricht-----
Von: netdev-owner@vger.kernel.org
[mailto:netdev-owner@vger.kernel.org]Im Auftrag von David Stevens
Gesendet: Donnerstag, 07. Februar 2008 17:09
An: Reither Robert
Cc: netdev@vger.kernel.org
Betreff: Re: Problem receiving multicast/promiscuous-mode with
kernel.2.6.24
You need to join the multicast group on the interface you want
to receive it. If you're setting both imr_address and imr_index
to 0, you haven't specified an interface.
Instead of setting imr_ifindex to 0, try setting it like this:
imr.imr_ifindex = if_nametoindex("eth0");
(or whatever interface you need).
You can verify that you've joined the group on the correct
interface with "netstat -g", also. Make sure that the interface
field is correct for the group you want.
And because I can't resist mentioning it, "inet_aton" is deprecated--
suggest inet_pton() with appropriate arguments and return value
checking instead.
There was a bug fix where the sense of promiscuous mode was
backwards for multicasting, which is probably why it was accidently
(and incorrectly) working in earlier kernels.
If that doesn't do it for you, let me know; better if you can post the
full code (or even better, the smallest subset that demonstrates the
problem).
+-DLS
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: oops with ipcomp
From: Beschorner Daniel @ 2008-02-11 15:03 UTC (permalink / raw)
To: netdev; +Cc: Herbert Xu
> Does every packet from A trigger the crash?
In my last test the crash was triggered after 300MB of http output (on
the fifth run of a script downloading the same 60MB of data).
^ permalink raw reply
* Re: [PATCH][RESEND] drivers/base: export (un)register_memory_notifier
From: Greg KH @ 2008-02-11 15:22 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Jan-Bernd Themann, netdev, Dave Hansen, linux-kernel,
Thomas Klein, linux-ppc, Christoph Raisch
In-Reply-To: <200802111147.51225.ossthema@de.ibm.com>
On Mon, Feb 11, 2008 at 11:47:50AM +0100, Jan-Bernd Themann wrote:
> On Monday 11 February 2008 11:12, Dave Hansen wrote:
> > On Mon, 2008-02-11 at 10:49 +0100, Jan-Bernd Themann wrote:
> > > are you the right person to address this patch to?
> >
> > You might want to check the top of the file. ;)
> >
> > > --- a/drivers/base/memory.c
> > > +++ b/drivers/base/memory.c
> > > @@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
> > > {
> > > return blocking_notifier_chain_register(&memory_chain, nb);
> > > }
> > > +EXPORT_SYMBOL(register_memory_notifier);
> > >
> > > void unregister_memory_notifier(struct notifier_block *nb)
> > > {
> > > blocking_notifier_chain_unregister(&memory_chain, nb);
> > > }
> > > +EXPORT_SYMBOL(unregister_memory_notifier);
> >
> > Is there a particular reason these can't be GPL?
> >
>
> I don't object to make them GPL. Greg, what do you think?
They should be _GPL to match the rest of the driver core.
Care to resend this?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/5] Tsi108_eth: add missing linking to driver data
From: Jeff Garzik @ 2008-02-11 15:28 UTC (permalink / raw)
To: Alexandre Bounine; +Cc: netdev, linuxppc-dev, Josh Boyer, Zang Roy-r61911
In-Reply-To: <1B5F013528140F45B5C671039279CA5702A9609F@NANUK.pc.tundra.com>
Alexandre Bounine wrote:
> Bug fix for tsi108_eth network driver.
> This patch adds missing linking to driver data.
>
> Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
> ---
>
> diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
> linux-2.6.24-fix/drivers/net/tsi108_eth.c
> --- linux-2.6.24/drivers/net/tsi108_eth.c 2008-01-24
> 17:58:37.000000000 -0500
> +++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
> 14:30:04.000000000 -0500
> @@ -1629,6 +1629,7 @@ tsi108_init_one(struct platform_device *
> goto register_fail;
> }
>
> + platform_set_drvdata(pdev, dev);
> printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n",
> dev->name, print_mac(mac, dev->dev_addr));
> #ifdef DEBUG
ACK, but your patches are unusable because they are word-wrapped
^ permalink raw reply
* Re: [PATCH] virtio_net: Fix oops on early interrupts - introduced by virtio reset code
From: Anthony Liguori @ 2008-02-11 15:29 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Avi Kivity, dor.laor, kvm-devel, virtualization, netdev
In-Reply-To: <200802111411.15745.borntraeger@de.ibm.com>
Christian Borntraeger wrote:
> Avi,
> this fixes a problem that was introduced by the virtio_reset patches.
> Can you apply that fix to kvm.git as a bugfix, as the virtio_reset
> infrastructure is not on Linus upstream yet?
>
The reset support is in Linus's tree so we should try to push it for -rc2.
> Anthony, Dor,
> are you ok with that change?
>
Yes.
Acked-by: Anthony Liguori <aliguori@us.ibm.com>
Regards,
Anthony Liguori
> --
>
> With the latest virtio_reset patches I got the following oops:
>
> Unable to handle kernel pointer dereference at virtual kernel address 0000000000000000
> Oops: 0004 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 1 Not tainted 2.6.24zlive-guest-10577-g63f5307-dirty #168
> Process swapper (pid: 0, task: 000000000f866040, ksp: 000000000f86fd78)
> Krnl PSW : 0404100180000000 000000000047598a (skb_recv_done+0x52/0x98)
> R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0 EA:3
> Krnl GPRS: 0000000000000001 0000000000000000 000000000efd0e60 0000000000000001
> 0000000000000000 000000000f866040 0000000000000000 0000000000000000
> 00000000008de4c8 0000000000001237 0000000000001237 000000000f977dd8
> 0000000000000020 00000000001132bc 000000000f977e08 000000000f977dd8
> Krnl Code: 000000000047597c: e31040300004 lg %r1,48(%r4)
> 0000000000475982: b9040001 lgr %r0,%r1
> 0000000000475986: b9810003 ogr %r0,%r3
> >000000000047598a: eb1040300030 csg %r1,%r0,48(%r4)
> 0000000000475990: a744fff9 brc 4,475982
> 0000000000475994: a7110001 tmll %r1,1
> 0000000000475998: a7840009 brc 8,4759aa
> 000000000047599c: e340b0b80004 lg %r4,184(%r11)
> Call Trace:
> ([<000001500f978000>] 0x1500f978000)
> [<00000000004779a6>] vring_interrupt+0x72/0x88
> [<0000000000491d9c>] kvm_extint_handler+0x34/0x44
> [<000000000010d2d4>] do_extint+0xc0/0xfc
> [<0000000000113b5a>] ext_no_vtime+0x1c/0x20
> [<000000000010a0b6>] cpu_idle+0x21a/0x230
>
>
> We must initialize vdev->priv before we use the notify hypercall as
> vdev->priv is used in skb_recv_done. So lets move the assignment of
> vdev->priv before we call try_fill_recv.
>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> drivers/net/virtio_net.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: kvm/drivers/net/virtio_net.c
> ===================================================================
> --- kvm.orig/drivers/net/virtio_net.c
> +++ kvm/drivers/net/virtio_net.c
> @@ -361,6 +361,7 @@ static int virtnet_probe(struct virtio_d
> netif_napi_add(dev, &vi->napi, virtnet_poll, napi_weight);
> vi->dev = dev;
> vi->vdev = vdev;
> + vdev->priv = vi;
>
> /* We expect two virtqueues, receive then send. */
> vi->rvq = vdev->config->find_vq(vdev, 0, skb_recv_done);
> @@ -395,7 +396,6 @@ static int virtnet_probe(struct virtio_d
> }
>
> pr_debug("virtnet: registered device %s\n", dev->name);
> - vdev->priv = vi;
> return 0;
>
> unregister:
>
^ permalink raw reply
* Re: [PATCH 2.6.24] pcnet32: use NET_IP_ALIGN instead of 2
From: Jeff Garzik @ 2008-02-11 15:30 UTC (permalink / raw)
To: Don Fry; +Cc: netdev
In-Reply-To: <1202484746.10535.7.camel@new-host.home>
Don Fry wrote:
> Change hard coded 2 to NET_IP_ALIGN. Added new #define with comments.
> Tested amd_64
>
> Signed-off-by: Don Fry <pcnet32@verizon.net>
applied both
^ permalink raw reply
* Re: [PATCH 1/7] PS3: gelic: Fix the wrong dev_id passed
From: Jeff Garzik @ 2008-02-11 15:31 UTC (permalink / raw)
To: Masakazu Mokuno; +Cc: netdev, geoffrey.levand, Geert Uytterhoeven
In-Reply-To: <20080207195725.AD40.40F06B3A@sm.sony.co.jp>
Masakazu Mokuno wrote:
> PS3: gelic: Fix the wrong dev_id passed
>
> The device id for lv1_net_set_interrupt_status_indicator() is wrong.
> This path would be invoked only in the case of an initialization failure.
>
> Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
> ---
> drivers/net/ps3_gelic_net.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied 1-7
Please do not duplicate the email subject -- the change's one-line
summary -- as the first line of the email. I had to hand-edit each of
this duplicate information out, before applying the patches.
^ permalink raw reply
* Re: [PATCH 2/2] tulip: hardware mitigation simplify
From: Jeff Garzik @ 2008-02-11 15:33 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, Jeff Garzik, netdev, kristjan
In-Reply-To: <20071213093554.5c4909ed@freepuppy.rosehill>
Stephen Hemminger wrote:
> The hardware mitigation in tulip can be simpified.
> 1. The budget with new NAPI will always be less than RX_RING_SIZE
> because RX_RING_SIZE is 128 and weight is 16.
> 2. The received counter is redundunt, just use the work_done value.
> 3. Only one value is used from the mit_table[]
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
> ---
> This can wait for 2.6.25
>
> --- a/drivers/net/tulip/interrupt.c 2007-12-13 09:26:35.000000000 -0800
> +++ b/drivers/net/tulip/interrupt.c 2007-12-13 09:27:29.000000000 -0800
> @@ -21,45 +21,6 @@
> int tulip_rx_copybreak;
> unsigned int tulip_max_interrupt_work;
>
> -#ifdef CONFIG_TULIP_NAPI_HW_MITIGATION
> -#define MIT_SIZE 15
> -#define MIT_TABLE 15 /* We use 0 or max */
> -
> -static unsigned int mit_table[MIT_SIZE+1] =
> -{
> - /* CRS11 21143 hardware Mitigation Control Interrupt
> - We use only RX mitigation we other techniques for
> - TX intr. mitigation.
> -
> - 31 Cycle Size (timer control)
> - 30:27 TX timer in 16 * Cycle size
> - 26:24 TX No pkts before Int.
> - 23:20 RX timer in Cycle size
> - 19:17 RX No pkts before Int.
> - 16 Continues Mode (CM)
> - */
> -
> - 0x0, /* IM disabled */
> - 0x80150000, /* RX time = 1, RX pkts = 2, CM = 1 */
> - 0x80150000,
> - 0x80270000,
> - 0x80370000,
> - 0x80490000,
> - 0x80590000,
> - 0x80690000,
> - 0x807B0000,
> - 0x808B0000,
> - 0x809D0000,
> - 0x80AD0000,
> - 0x80BD0000,
> - 0x80CF0000,
> - 0x80DF0000,
> -// 0x80FF0000 /* RX time = 16, RX pkts = 7, CM = 1 */
> - 0x80F10000 /* RX time = 16, RX pkts = 0, CM = 1 */
> -};
> -#endif
> -
> -
> int tulip_refill_rx(struct net_device *dev)
> {
> struct tulip_private *tp = netdev_priv(dev);
> @@ -113,21 +74,10 @@ int tulip_poll(struct napi_struct *napi,
> struct net_device *dev = tp->dev;
> int entry = tp->cur_rx % RX_RING_SIZE;
> int work_done = 0;
> -#ifdef CONFIG_TULIP_NAPI_HW_MITIGATION
> - int received = 0;
> -#endif
>
> if (!netif_running(dev))
> goto done;
>
> -#ifdef CONFIG_TULIP_NAPI_HW_MITIGATION
> -
> -/* that one buffer is needed for mit activation; or might be a
> - bug in the ring buffer code; check later -- JHS*/
> -
> - if (budget >=RX_RING_SIZE) budget--;
> -#endif
> -
> if (tulip_debug > 4)
> printk(KERN_DEBUG " In tulip_rx(), entry %d %8.8x.\n", entry,
> tp->rx_ring[entry].status);
> @@ -239,9 +189,6 @@ int tulip_poll(struct napi_struct *napi,
> tp->stats.rx_packets++;
> tp->stats.rx_bytes += pkt_len;
> }
> -#ifdef CONFIG_TULIP_NAPI_HW_MITIGATION
> - received++;
> -#endif
>
> entry = (++tp->cur_rx) % RX_RING_SIZE;
> if (tp->cur_rx - tp->dirty_rx > RX_RING_SIZE/4)
> @@ -279,14 +226,14 @@ done:
> ON: More then 1 pkt received (per intr.) OR we are dropping
> OFF: Only 1 pkt received
>
> - Note. We only use min and max (0, 15) settings from mit_table */
> -
> + Note. We only use max or min values for mit */
>
> if( tp->flags & HAS_INTR_MITIGATION) {
> - if( received > 1 ) {
> + if( work_done > 1 ) {
> if( ! tp->mit_on ) {
> tp->mit_on = 1;
> - iowrite32(mit_table[MIT_TABLE], tp->base_addr + CSR11);
> + /* RX time = 16, RX pkts = 0, CM = 1 */
> + iowrite32(0x80F10000, tp->base_addr + CSR11);
I think it's disappointing to eliminate mit_table[], because that can be
modified easily in the current setup
^ permalink raw reply
* Re: [patch] pegasus.c
From: Jeff Garzik @ 2008-02-11 15:38 UTC (permalink / raw)
To: Petko Manolov; +Cc: netdev
In-Reply-To: <alpine.DEB.1.00.0801091222560.3171@bender.nucleusys.com>
Petko Manolov wrote:
> Hi Jeff,
>
> Attached you'll find a patch that is fixing a driver bug triggered when
> malformed string is passed to the 'devid' module parameter. The
> expected format is:
>
> "device_name:vendor_id:device_id:flags"
>
> but it turned out people often type:
>
> "somename::0"
>
> instead of:
>
> "somename:::0"
ACK but two process problems preventing application:
* patch is base64-encoded
* no signed-off-by included
^ permalink raw reply
* [PATCH] virtio_net: Fix oops on early interrupts - introduced by virtio reset code
From: Christian Borntraeger @ 2008-02-11 15:40 UTC (permalink / raw)
To: Jeff Garzik
Cc: Anthony Liguori, Avi Kivity, dor.laor, kvm-devel, virtualization,
netdev
In-Reply-To: <47B069E0.9040905@us.ibm.com>
Am Montag, 11. Februar 2008 schrieb Anthony Liguori:
> The reset support is in Linus's tree so we should try to push it for -rc2.
You are right. My repository was borked. will push it to Jeff Garzik. Thanks
Jeff can you schedule this fix into your network driver updates? Thanks
---
With the latest virtio_reset patches I got the following oops:
Unable to handle kernel pointer dereference at virtual kernel address 0000000000000000
Oops: 0004 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 Not tainted 2.6.24zlive-guest-10577-g63f5307-dirty #168
Process swapper (pid: 0, task: 000000000f866040, ksp: 000000000f86fd78)
Krnl PSW : 0404100180000000 000000000047598a (skb_recv_done+0x52/0x98)
R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0 EA:3
Krnl GPRS: 0000000000000001 0000000000000000 000000000efd0e60 0000000000000001
0000000000000000 000000000f866040 0000000000000000 0000000000000000
00000000008de4c8 0000000000001237 0000000000001237 000000000f977dd8
0000000000000020 00000000001132bc 000000000f977e08 000000000f977dd8
Krnl Code: 000000000047597c: e31040300004 lg %r1,48(%r4)
0000000000475982: b9040001 lgr %r0,%r1
0000000000475986: b9810003 ogr %r0,%r3
>000000000047598a: eb1040300030 csg %r1,%r0,48(%r4)
0000000000475990: a744fff9 brc 4,475982
0000000000475994: a7110001 tmll %r1,1
0000000000475998: a7840009 brc 8,4759aa
000000000047599c: e340b0b80004 lg %r4,184(%r11)
Call Trace:
([<000001500f978000>] 0x1500f978000)
[<00000000004779a6>] vring_interrupt+0x72/0x88
[<0000000000491d9c>] kvm_extint_handler+0x34/0x44
[<000000000010d2d4>] do_extint+0xc0/0xfc
[<0000000000113b5a>] ext_no_vtime+0x1c/0x20
[<000000000010a0b6>] cpu_idle+0x21a/0x230
([<000000000010a096>] cpu_idle+0x1fa/0x230)
[<000000000057dfe4>] start_secondary+0xa0/0xb4
We must initialize vdev->priv before we use the notify hypercall as
vdev->priv is used in skb_recv_done. So lets move the assignment of
vdev->priv before we call try_fill_recv.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Anthony Liguori <aliguori@us.ibm.com>
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: kvm/drivers/net/virtio_net.c
===================================================================
--- kvm.orig/drivers/net/virtio_net.c
+++ kvm/drivers/net/virtio_net.c
@@ -361,6 +361,7 @@ static int virtnet_probe(struct virtio_d
netif_napi_add(dev, &vi->napi, virtnet_poll, napi_weight);
vi->dev = dev;
vi->vdev = vdev;
+ vdev->priv = vi;
/* We expect two virtqueues, receive then send. */
vi->rvq = vdev->config->find_vq(vdev, 0, skb_recv_done);
@@ -395,7 +396,6 @@ static int virtnet_probe(struct virtio_d
}
pr_debug("virtnet: registered device %s\n", dev->name);
- vdev->priv = vi;
return 0;
unregister:
^ permalink raw reply
* Re: [PATCH 2/2] tulip: hardware mitigation simplify
From: Jeff Garzik @ 2008-02-11 15:43 UTC (permalink / raw)
To: Stephen Hemminger, David S. Miller; +Cc: netdev, kristjan
In-Reply-To: <47B06AE3.4020809@DunveganMedia.com>
Jeff Garzik wrote:
> Stephen Hemminger wrote:
>> The hardware mitigation in tulip can be simpified.
>> 1. The budget with new NAPI will always be less than RX_RING_SIZE
>> because RX_RING_SIZE is 128 and weight is 16.
>> 2. The received counter is redundunt, just use the work_done value.
>> 3. Only one value is used from the mit_table[]
>>
>> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
grrr. Mozilla Thunderbird is annoying.
Please help me out, and --don't-- reply to jgarzik@dunveganmedia.com.
T-bird's multi-profile stuff is fouling me up.
Sorry :(
Jeff
^ permalink raw reply
* AW: Problem receiving multicast/promiscuous-mode with kernel.2.6.24
From: Reither Robert @ 2008-02-11 15:46 UTC (permalink / raw)
To: David Stevens; +Cc: netdev
Visit AVD on prolight+sound in Frankfurt from 12.-15. March 2008 - Hall 8.0, Stand G16
________________________________________________________________________
OK, after some more testing, things become clearer ...
joining eth0.3 gives this strange unreliable behaviour...
Joining eth0 , and i can see the packets always floating in with tcpdump -p -i eth0.3 (or -i eth0)
But my application won't get the packets !!!
Maybe this is because i'm using pselect() to wait for incoming packets ?????
Question: Should it possible to join on a VLAN device ? Or is this something bad ???
Robert
^ permalink raw reply
* Re: [PATCH] sk98lin: remove obsolete driver
From: Jeff Garzik @ 2008-02-11 15:52 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20080130220405.02c97083@extreme>
applied to #upstream (2.6.26)
^ permalink raw reply
* Re: [2.6 patch] remove the obsolete xircom_tulip_cb driver
From: Jeff Garzik @ 2008-02-11 15:52 UTC (permalink / raw)
To: Adrian Bunk; +Cc: netdev
In-Reply-To: <20080128221412.GJ8767@does.not.exist>
Adrian Bunk wrote:
> The xircom_tulip_cb driver has been replaced the xircom_cb driver, and
> since it depended on BROKEN_ON_SMP it e.g. was no longer present in many
> distribution kernels.
>
> This patch therefore removes it.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
>
> ---
>
> drivers/net/tulip/Kconfig | 15
> drivers/net/tulip/Makefile | 1
> drivers/net/tulip/xircom_tulip_cb.c | 1726 ----------------------------
> 3 files changed, 1 insertion(+), 1741 deletions(-)
applied to #upstream (2.6.26)
^ permalink raw reply
* Re: [PATCH 10/10] atl1: reduce forward declarations
From: Jeff Garzik @ 2008-02-11 15:57 UTC (permalink / raw)
To: Jay Cliburn; +Cc: csnook, netdev, linux-kernel
In-Reply-To: <1202003412-4028-10-git-send-email-jacliburn@bellsouth.net>
applied 1-10 to #upstream (2.6.26)
^ permalink raw reply
* [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Jan-Bernd Themann @ 2008-02-11 15:57 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-kernel, netdev, linux-ppc, Thomas Klein, Themann, Jan-Bernd,
Greg KH, Christoph Raisch
Drivers like eHEA need memory notifiers in order to
update their internal DMA memory map when memory is added
to or removed from the system.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
Hi,
this is the modified version with EXPORT_SYMBOL_GPL
Regards,
Jan-Bernd
drivers/base/memory.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 7ae413f..f5a0bf1 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -52,11 +52,13 @@ int register_memory_notifier(struct notifier_block *nb)
{
return blocking_notifier_chain_register(&memory_chain, nb);
}
+EXPORT_SYMBOL_GPL(register_memory_notifier);
void unregister_memory_notifier(struct notifier_block *nb)
{
blocking_notifier_chain_unregister(&memory_chain, nb);
}
+EXPORT_SYMBOL_GPL(unregister_memory_notifier);
/*
* register_memory - Setup a sysfs device for a memory block
--
1.5.2
^ permalink raw reply related
* Re: [patch 1/3] drivers/s390/net: Kconfig brush up
From: Jeff Garzik @ 2008-02-11 16:00 UTC (permalink / raw)
To: Ursula Braun; +Cc: netdev, linux-s390, Peter Tiedemann
In-Reply-To: <20080207232607.192981000@linux.vnet.ibm.com>
applied 1-3 to #upstream (2.6.26)
Even the initial revision was outside the merge window, so it was never
going to make 2.6.25, thus I waited a bit for further comments and revisions
^ permalink raw reply
* Re: [patch 1/2] qeth: new qeth device driver
From: Jeff Garzik @ 2008-02-11 16:00 UTC (permalink / raw)
To: Frank.Blaschka; +Cc: netdev
In-Reply-To: <20080208141535.271607000@de.ibm.com>
please resend on top of the ctc driver update...
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Sam Ravnborg @ 2008-02-11 16:02 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Dave Hansen, linux-kernel, netdev, linux-ppc, Thomas Klein,
Themann, Jan-Bernd, Greg KH, Christoph Raisch
In-Reply-To: <200802111657.07534.ossthema@de.ibm.com>
On Mon, Feb 11, 2008 at 04:57:06PM +0100, Jan-Bernd Themann wrote:
> Drivers like eHEA need memory notifiers in order to
> update their internal DMA memory map when memory is added
> to or removed from the system.
Can you please add proper kernel-doc formatted comments
when you export a symbol so others can get a clue
what the exported function is supposed to do.
Sam
^ 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