* Re: tune back idle cwnd closing?
From: John Heffner @ 2006-04-25 14:27 UTC (permalink / raw)
To: Zach Brown; +Cc: netdev
In-Reply-To: <44493980.1040708@oracle.com>
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
> between transmissions.
>
> Is there room for a compromise tunable that would be less aggressive
> about closing cwnd during idle periods but which wouldn't violate the
> spirit of 2861? No one wants broken TCP here.
>
> They mention that Solaris has the tcp_slow_start_after_idle tunable and
> that it helps their situation. I mention that only as a data point, I
> wouldn't be foolish enough to try and use the presence of something in
> Solaris as justification :)
Yours is the first complaint of this kind I recall seeing, but I've
expected for a while someone would have this type of problem. RFC2861
seems conceptually nice at first, but there are a few things about it
that bother me. One thing in particular is that a naturally bursty
application (like yours) will actually perform better by padding its
connection with junk data whenever it doesn't have real data to send.
Or equivalently, it's punished for not sending data when it doesn't need
to. I also think it may not do much good when there are connections
with significantly different RTTs.
Given that RFC2681 is Experimental (and I'm not aware of any current
efforts in the IETF to push it to the standard track), IHMO it would not
be inappropriate to make this behavior controlled via sysctl.
Thanks,
-John
^ permalink raw reply
* Re: determine outgoing interface (eth0,eth1) for a packet according to the dest IP
From: John Que @ 2006-04-25 14:44 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev
In-Reply-To: <200604250943.49422.ak@suse.de>
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 specify a certain
dest IP.
Consider the follwing simple scenario: I have 2 gateways
(one on eth0,one on eth1), and I am sending
a packet to some dest IP ; I want to know according to
that ip on which interface (or gw) it will be out
But where do I specify that certain dest IP ?
Regards,
John
On 4/25/06, Andi Kleen <ak@suse.de> wrote:
> 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 can be converted
> into a name.
>
> -Andi
>
>
^ permalink raw reply
* Re: determine outgoing interface (eth0,eth1) for a packet according to the dest IP
From: Andi Kleen @ 2006-04-25 14:48 UTC (permalink / raw)
To: John Que; +Cc: netdev
In-Reply-To: <ada605fb0604250744w73c7766as1d3ceb0d62511764@mail.gmail.com>
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 table.
> But in sending that message I did not specify a certain
> dest IP.
> Consider the follwing simple scenario: I have 2 gateways
> (one on eth0,one on eth1), and I am sending
> a packet to some dest IP ; I want to know according to
> that ip on which interface (or gw) it will be out
>
> But where do I specify that certain dest IP ?
You add RTA_SRC and RTA_DST attributes to the query.
-Andi
^ permalink raw reply
* Re: is it a backwards compatability catch-22?
From: Jesse Brandeburg @ 2006-04-25 16:09 UTC (permalink / raw)
To: Rick Jones; +Cc: Stephen Hemminger, Linux Network Development list
In-Reply-To: <444D6F78.9080309@hp.com>
On 4/24/06, Rick Jones <rick.jones2@hp.com> 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" or something like that.
>
> Is that because adding another NIC at a later time might cause it to
> grab ethN out from under what I'm trying to do with udev?
>From what I read its likely to be because there may already be a
device named "eth1" due to default naming when you are trying to
rename a device (say eth0) to eth1.
this is all because Debian now has async init, right?
BTW, since the letters in udev are all hex, it shouldn't matter
whether they are upper or lower case, IMO
Jesse
^ permalink raw reply
* [PATCH] ibmveth change buffer pools dynamically
From: Santiago Leon @ 2006-04-25 16:19 UTC (permalink / raw)
To: jgarzik, netdev
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]
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 arbitrary size (not only regular, mini, and jumbo which are
the only sizes that ethtool can change), and also ibmveth can have an
arbitrary number of buffer pools
Under heavy load we have seen dropped packets which obviously kills TCP
performance. We have created several fixes that mitigate this issue,
but we definitely need a way of changing the number of buffers for an
adapter dynamically. Also, changing the size of the buffers allows
users to change the MTU to something big (bigger than a jumbo frame)
greatly improving performance on partition to partition transfers.
The patch creates directories pool1...pool4 in the device directory in
sysfs, each with files: num, size, and active (which default to the
values in the mainline version).
Comments and suggestions are welcome...
--
Santiago A. Leon
Power Linux Development
IBM Linux Technology Center
[-- Attachment #2: ibmveth_flexbuff_ml.patch --]
[-- Type: text/x-patch, Size: 10852 bytes --]
--- a/drivers/net/ibmveth.h 2006-01-02 21:21:10.000000000 -0600
+++ b/drivers/net/ibmveth.h 2006-04-18 10:20:00.102520432 -0500
@@ -75,10 +75,13 @@
#define IbmVethNumBufferPools 5
#define IBMVETH_BUFF_OH 22 /* Overhead: 14 ethernet header + 8 opaque handle */
+#define IBMVETH_MAX_MTU 68
+#define IBMVETH_MAX_POOL_COUNT 4096
+#define IBMVETH_MAX_BUF_SIZE (1024 * 128)
-/* pool_size should be sorted */
static int pool_size[] = { 512, 1024 * 2, 1024 * 16, 1024 * 32, 1024 * 64 };
static int pool_count[] = { 256, 768, 256, 256, 256 };
+static int pool_active[] = { 1, 1, 0, 0, 0};
#define IBM_VETH_INVALID_MAP ((u16)0xffff)
@@ -94,6 +97,7 @@ struct ibmveth_buff_pool {
dma_addr_t *dma_addr;
struct sk_buff **skbuff;
int active;
+ struct kobject kobj;
};
struct ibmveth_rx_q {
@@ -118,6 +122,7 @@ struct ibmveth_adapter {
dma_addr_t filter_list_dma;
struct ibmveth_buff_pool rx_buff_pool[IbmVethNumBufferPools];
struct ibmveth_rx_q rx_queue;
+ int pool_config;
/* adapter specific stats */
u64 replenish_task_cycles;
--- a/drivers/net/ibmveth.c 2006-01-02 21:21:10.000000000 -0600
+++ b/drivers/net/ibmveth.c 2006-04-18 10:19:55.624532480 -0500
@@ -96,6 +96,7 @@ static void ibmveth_proc_register_adapte
static void ibmveth_proc_unregister_adapter(struct ibmveth_adapter *adapter);
static irqreturn_t ibmveth_interrupt(int irq, void *dev_instance, struct pt_regs *regs);
static inline void ibmveth_rxq_harvest_buffer(struct ibmveth_adapter *adapter);
+static struct kobj_type ktype_veth_pool;
#ifdef CONFIG_PROC_FS
#define IBMVETH_PROC_DIR "net/ibmveth"
@@ -133,12 +134,13 @@ static inline int ibmveth_rxq_frame_leng
}
/* setup the initial settings for a buffer pool */
-static void ibmveth_init_buffer_pool(struct ibmveth_buff_pool *pool, u32 pool_index, u32 pool_size, u32 buff_size)
+static void ibmveth_init_buffer_pool(struct ibmveth_buff_pool *pool, u32 pool_index, u32 pool_size, u32 buff_size, u32 pool_active)
{
pool->size = pool_size;
pool->index = pool_index;
pool->buff_size = buff_size;
pool->threshold = pool_size / 2;
+ pool->active = pool_active;
}
/* allocate and setup an buffer pool - called during open */
@@ -180,7 +182,6 @@ static int ibmveth_alloc_buffer_pool(str
atomic_set(&pool->available, 0);
pool->producer_index = 0;
pool->consumer_index = 0;
- pool->active = 0;
return 0;
}
@@ -301,7 +302,6 @@ static void ibmveth_free_buffer_pool(str
kfree(pool->skbuff);
pool->skbuff = NULL;
}
- pool->active = 0;
}
/* remove a buffer from a pool */
@@ -433,7 +433,9 @@ static void ibmveth_cleanup(struct ibmve
}
for(i = 0; i<IbmVethNumBufferPools; i++)
- ibmveth_free_buffer_pool(adapter, &adapter->rx_buff_pool[i]);
+ if (adapter->rx_buff_pool[i].active)
+ ibmveth_free_buffer_pool(adapter,
+ &adapter->rx_buff_pool[i]);
}
static int ibmveth_open(struct net_device *netdev)
@@ -489,9 +491,6 @@ static int ibmveth_open(struct net_devic
adapter->rx_queue.num_slots = rxq_entries;
adapter->rx_queue.toggle = 1;
- /* call change_mtu to init the buffer pools based in initial mtu */
- ibmveth_change_mtu(netdev, netdev->mtu);
-
memcpy(&mac_address, netdev->dev_addr, netdev->addr_len);
mac_address = mac_address >> 16;
@@ -522,6 +521,17 @@ static int ibmveth_open(struct net_devic
return -ENONET;
}
+ for(i = 0; i<IbmVethNumBufferPools; i++) {
+ if(!adapter->rx_buff_pool[i].active)
+ continue;
+ if (ibmveth_alloc_buffer_pool(&adapter->rx_buff_pool[i])) {
+ ibmveth_error_printk("unable to alloc pool\n");
+ adapter->rx_buff_pool[i].active = 0;
+ ibmveth_cleanup(adapter);
+ return -ENOMEM ;
+ }
+ }
+
ibmveth_debug_printk("registering irq 0x%x\n", netdev->irq);
if((rc = request_irq(netdev->irq, &ibmveth_interrupt, 0, netdev->name, netdev)) != 0) {
ibmveth_error_printk("unable to request irq 0x%x, rc %d\n", netdev->irq, rc);
@@ -550,7 +560,8 @@ static int ibmveth_close(struct net_devi
ibmveth_debug_printk("close starting\n");
- netif_stop_queue(netdev);
+ if (!adapter->pool_config)
+ netif_stop_queue(netdev);
free_irq(netdev->irq, netdev);
@@ -876,46 +887,22 @@ static void ibmveth_set_multicast_list(s
static int ibmveth_change_mtu(struct net_device *dev, int new_mtu)
{
struct ibmveth_adapter *adapter = dev->priv;
+ int new_mtu_oh = new_mtu + IBMVETH_BUFF_OH;
int i;
- int prev_smaller = 1;
- if ((new_mtu < 68) ||
- (new_mtu > (pool_size[IbmVethNumBufferPools-1]) - IBMVETH_BUFF_OH))
+ if (new_mtu < IBMVETH_MAX_MTU)
return -EINVAL;
+ /* Look for an active buffer pool that can hold the new MTU */
for(i = 0; i<IbmVethNumBufferPools; i++) {
- int activate = 0;
- if (new_mtu > (pool_size[i] - IBMVETH_BUFF_OH)) {
- activate = 1;
- prev_smaller= 1;
- } else {
- if (prev_smaller)
- activate = 1;
- prev_smaller= 0;
- }
-
- if (activate && !adapter->rx_buff_pool[i].active) {
- struct ibmveth_buff_pool *pool =
- &adapter->rx_buff_pool[i];
- if(ibmveth_alloc_buffer_pool(pool)) {
- ibmveth_error_printk("unable to alloc pool\n");
- return -ENOMEM;
- }
- adapter->rx_buff_pool[i].active = 1;
- } else if (!activate && adapter->rx_buff_pool[i].active) {
- adapter->rx_buff_pool[i].active = 0;
- h_free_logical_lan_buffer(adapter->vdev->unit_address,
- (u64)pool_size[i]);
+ if (!adapter->rx_buff_pool[i].active)
+ continue;
+ if (new_mtu_oh < adapter->rx_buff_pool[i].buff_size) {
+ dev->mtu = new_mtu;
+ return 0;
}
-
}
-
- /* kick the interrupt handler so that the new buffer pools get
- replenished or deallocated */
- ibmveth_interrupt(dev->irq, dev, NULL);
-
- dev->mtu = new_mtu;
- return 0;
+ return -EINVAL;
}
static int __devinit ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id)
@@ -960,6 +947,7 @@ static int __devinit ibmveth_probe(struc
adapter->vdev = dev;
adapter->netdev = netdev;
adapter->mcastFilterSize= *mcastFilterSize_p;
+ adapter->pool_config = 0;
/* Some older boxes running PHYP non-natively have an OF that
returns a 8-byte local-mac-address field (and the first
@@ -994,9 +982,16 @@ static int __devinit ibmveth_probe(struc
memcpy(&netdev->dev_addr, &adapter->mac_addr, netdev->addr_len);
- for(i = 0; i<IbmVethNumBufferPools; i++)
+ for(i = 0; i<IbmVethNumBufferPools; i++) {
+ struct kobject *kobj = &adapter->rx_buff_pool[i].kobj;
ibmveth_init_buffer_pool(&adapter->rx_buff_pool[i], i,
- pool_count[i], pool_size[i]);
+ pool_count[i], pool_size[i],
+ pool_active[i]);
+ kobj->parent = &dev->dev.kobj;
+ sprintf(kobj->name, "pool%d", i);
+ kobj->ktype = &ktype_veth_pool;
+ kobject_register(kobj);
+ }
ibmveth_debug_printk("adapter @ 0x%p\n", adapter);
@@ -1025,6 +1020,10 @@ static int __devexit ibmveth_remove(stru
{
struct net_device *netdev = dev->dev.driver_data;
struct ibmveth_adapter *adapter = netdev->priv;
+ int i;
+
+ for(i = 0; i<IbmVethNumBufferPools; i++)
+ kobject_unregister(&adapter->rx_buff_pool[i].kobj);
unregister_netdev(netdev);
@@ -1169,6 +1168,132 @@ static void ibmveth_proc_unregister_driv
}
#endif /* CONFIG_PROC_FS */
+static struct attribute veth_active_attr;
+static struct attribute veth_num_attr;
+static struct attribute veth_size_attr;
+
+static ssize_t veth_pool_show(struct kobject * kobj,
+ struct attribute * attr, char * buf)
+{
+ struct ibmveth_buff_pool *pool = container_of(kobj,
+ struct ibmveth_buff_pool,
+ kobj);
+
+ if (attr == &veth_active_attr)
+ return sprintf(buf, "%d\n", pool->active);
+ else if (attr == &veth_num_attr)
+ return sprintf(buf, "%d\n", pool->size);
+ else if (attr == &veth_size_attr)
+ return sprintf(buf, "%d\n", pool->buff_size);
+ return 0;
+}
+
+static ssize_t veth_pool_store(struct kobject * kobj, struct attribute * attr,
+const char * buf, size_t count)
+{
+ struct ibmveth_buff_pool *pool = container_of(kobj,
+ struct ibmveth_buff_pool,
+ kobj);
+ struct net_device *netdev =
+ container_of(kobj->parent, struct device, kobj)->driver_data;
+ struct ibmveth_adapter *adapter = netdev->priv;
+ long value = simple_strtol(buf, NULL, 10);
+ long rc;
+
+ if (attr == &veth_active_attr) {
+ if (value && !pool->active) {
+ if(ibmveth_alloc_buffer_pool(pool)) {
+ ibmveth_error_printk("unable to alloc pool\n");
+ return -ENOMEM;
+ }
+ pool->active = 1;
+ adapter->pool_config = 1;
+ ibmveth_close(netdev);
+ adapter->pool_config = 0;
+ if ((rc = ibmveth_open(netdev)))
+ return rc;
+ } else if (!value && pool->active) {
+ int mtu = netdev->mtu + IBMVETH_BUFF_OH;
+ int i;
+ /* Make sure there is a buffer pool with buffers that
+ can hold a packet of the size of the MTU */
+ for(i = 0; i<IbmVethNumBufferPools; i++) {
+ if (pool == &adapter->rx_buff_pool[i])
+ continue;
+ if (!adapter->rx_buff_pool[i].active)
+ continue;
+ if (mtu < adapter->rx_buff_pool[i].buff_size) {
+ pool->active = 0;
+ h_free_logical_lan_buffer(adapter->
+ vdev->
+ unit_address,
+ pool->
+ buff_size);
+ }
+ }
+ if (pool->active) {
+ ibmveth_error_printk("no active pool >= MTU\n");
+ return -EPERM;
+ }
+ }
+ } else if (attr == &veth_num_attr) {
+ if (value <= 0 || value > IBMVETH_MAX_POOL_COUNT)
+ return -EINVAL;
+ else {
+ adapter->pool_config = 1;
+ ibmveth_close(netdev);
+ adapter->pool_config = 0;
+ pool->size = value;
+ if ((rc = ibmveth_open(netdev)))
+ return rc;
+ }
+ } else if (attr == &veth_size_attr) {
+ if (value <= IBMVETH_BUFF_OH || value > IBMVETH_MAX_BUF_SIZE)
+ return -EINVAL;
+ else {
+ adapter->pool_config = 1;
+ ibmveth_close(netdev);
+ adapter->pool_config = 0;
+ pool->buff_size = value;
+ if ((rc = ibmveth_open(netdev)))
+ return rc;
+ }
+ }
+
+ /* kick the interrupt handler to allocate/deallocate pools */
+ ibmveth_interrupt(netdev->irq, netdev, NULL);
+ return count;
+}
+
+
+#define ATTR(_name, _mode) \
+ struct attribute veth_##_name##_attr = { \
+ .name = __stringify(_name), .mode = _mode, .owner = THIS_MODULE \
+ };
+
+static ATTR(active, 0644);
+static ATTR(num, 0644);
+static ATTR(size, 0644);
+
+static struct attribute * veth_pool_attrs[] = {
+ &veth_active_attr,
+ &veth_num_attr,
+ &veth_size_attr,
+ NULL,
+};
+
+static struct sysfs_ops veth_pool_ops = {
+ .show = veth_pool_show,
+ .store = veth_pool_store,
+};
+
+static struct kobj_type ktype_veth_pool = {
+ .release = NULL,
+ .sysfs_ops = &veth_pool_ops,
+ .default_attrs = veth_pool_attrs,
+};
+
+
static struct vio_device_id ibmveth_device_table[] __devinitdata= {
{ "network", "IBM,l-lan"},
{ "", "" }
^ permalink raw reply
* Fw: [Bugme-new] [Bug 6438] New: CISCO AIRONET 340 SERIES oops under PPC
From: Andrew Morton @ 2006-04-25 16:22 UTC (permalink / raw)
To: Dominik Brodowski, John W. Linville
Cc: netdev, bugme-daemon@kernel-bugs.osdl.org
Begin forwarded message:
Date: Tue, 25 Apr 2006 01:57:50 -0700
From: bugme-daemon@bugzilla.kernel.org
To: bugme-new@lists.osdl.org
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
Kernel Version: all under PPC
Status: NEW
Severity: blocking
Owner: drivers_network-wireless@kernel-bugs.osdl.org
Submitter: paszczus@gmail.com
Most recent kernel where this bug did not occur:
Distribution: PLD Linux
Hardware Environment: Apple PowerBook G3 with CISCO AIRONET 340 SERIES
Software Environment: gcc 3.3.x and 3.4.x
Problem Description:
Kernel oops while trying to load module yenta_socket while Airo card is inside
POMCIA slot. The problem is propably only on ppc, cause some other guy use that
card under x86 notebook and it works for him.
Steps to reproduce:
run pcmcia-cs service or modprobe yenta_socket. Oops is like that:
cs: memory probe 0xfd000000-0xfdffffff:Machine check in kernel mode.
Caused by (from SRR1=49030): Transfer error ack signal
Oops: machine check, sig: 7 [#1]
NIP: CD02ACD0 LR: CD02ACA4 SP: CB3ADC70 REGS: cb3adbc0 TRAP: 0200 Not tainted
MSR: 00049030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = cb272c70[1636] 'pccardd' THREAD: cb3ac000
Last syscall: -1
GPR00: 000000FF CB3ADC70 CB272C70 CD8AA000 00000014 00000070 00000002 CB3ADCEA
GPR08: C4822B60 CD8AB000 00000040 00001000 22002248 1001F6AC 00000000 00000000
GPR16: 00000000 00000000 00000000 10017B58 1000249C CBFB9E80 01000000 00000000
GPR24: CB3ADCEA 00000021 00000002 CBD9582C 00000000 00000000 00000002 CB3ADCEA
NIP [cd02acd0] pcmcia_read_cis_mem+0x184/0xffff64b4 [pcmcia_core]
LR [cd02aca4] pcmcia_read_cis_mem+0x158/0xffff64b4 [pcmcia_core]
Call trace:
[cd02afe0] read_cis_cache+0x144/0xffff6164 [pcmcia_core]
[cd02b648] pccard_get_next_tuple+0x7c/0xffff5a34 [pcmcia_core]
[cd02b358] pccard_get_first_tuple+0x94/0xffff5d3c [pcmcia_core]
[cd02cf98] pccard_validate_cis+0x94/0xffff40fc [pcmcia_core]
[cd8af688] readable+0x88/0xff7cba00 [rsrc_nonstatic]
[cd8af860] cis_readable+0xc8/0xff7cb868 [rsrc_nonstatic]
[cd8afb30] do_mem_probe+0x1e0/0xff7cb6b0 [rsrc_nonstatic]
[cd8afb78] inv_probe+0x30/0xff7cb4b8 [rsrc_nonstatic]
[cd8afd20] validate_mem+0x128/0xff7cb408 [rsrc_nonstatic]
[cd8afdf4] pcmcia_nonstatic_validate_mem+0xbc/0xff7cb2c8 [rsrc_nonstatic]
[cd02d378] pcmcia_validate_mem+0x34/0xffff3cbc [pcmcia_core]
[cda2ea44] pcmcia_card_add+0x28/0xfffb95e4 [pcmcia]
[cda2f5a4] ds_event+0x80/0xfffb8adc [pcmcia]
[cd0299d8] send_event+0x70/0xffff7698 [pcmcia_core]
[cd029e6c] socket_insert+0xa8/0xffff723c [pcmcia_core]
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply
* Re: skb->truesize assertion checking for TCP
From: Jesse Brandeburg @ 2006-04-25 16:49 UTC (permalink / raw)
To: David S. Miller; +Cc: herbert, netdev
In-Reply-To: <20060419.231703.35841080.davem@davemloft.net>
On 4/19/06, David S. Miller <davem@davemloft.net> wrote:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> 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 (unlikely((int)skb->truesize < sizeof(struct sk_buff)))
> > > + skb_truesize_bug(skb);
> > > +}
> >
> > I think we can go for the stronger test:
> >
> > skb->truesize < sizeof(struct sk_buff) + skb->len
>
> Agreed, let me see if that triggers on my machine before
> I commit this :-)
Um, I get a log full of these now with the 7.0.33 driver in the
kernel. BTW, it seems like it is missing a WARN_ON or
printk(__function__) - or whatever prints the function name of a
caller in the debug output.
Apr 24 15:48:36 lindenhurst-2 kernel: e1000: eth1:
e1000_watchdog_task: NIC Link is Up 100 Mbps Half Duplex
Apr 24 15:48:36 lindenhurst-2 kernel: e1000: eth1:
e1000_watchdog_task: 10/100 speed: disabling TSO
Apr 24 15:49:21 lindenhurst-2 kernel: SKB BUG: Invalid truesize (616)
len=1448, sizeof(sk_buff)=232
Apr 24 15:49:21 lindenhurst-2 last message repeated 13 times
Apr 24 15:49:21 lindenhurst-2 kernel: SKB BUG: Invalid truesize (616)
len=1408, sizeof(sk_buff)=232
Apr 24 15:49:21 lindenhurst-2 kernel: SKB BUG: Invalid truesize (616)
len=1448, sizeof(sk_buff)=232
Apr 24 15:49:21 lindenhurst-2 last message repeated 15 times
Apr 24 15:49:21 lindenhurst-2 kernel: SKB BUG: Invalid truesize (616)
len=1408, sizeof(sk_buff)=232
Apr 24 15:49:21 lindenhurst-2 kernel: SKB BUG: Invalid truesize (616)
len=1448, sizeof(sk_buff)=232
Apr 24 15:49:21 lindenhurst-2 last message repeated 97 times
I have the latest version of net/core/skbuff.c in git.
I've verified that the below patch fixes the message appearing but I
still think the message could be refined a little bit. We're working
on seperate patches for this for 17-rc and 16 stable.
Jesse
PS this is just for reference, this patch is mangled due to cut/paste
drivers/net/e1000/e1000_main.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index add8dc4..c99e878 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -3768,6 +3768,7 @@ e1000_clean_rx_irq_ps(struct e1000_adapt
ps_page->ps_page[j] = NULL;
skb->len += length;
skb->data_len += length;
+ skb->truesize += length;
}
copydone:
^ permalink raw reply related
* Re: [PATCH]: suspicious unlikely usage in tcp_transmit_skb()
From: Stephen Hemminger @ 2006-04-25 17:01 UTC (permalink / raw)
To: Hua Zhong; +Cc: davem, netdev
In-Reply-To: <444D5E73.7020803@gmail.com>
On Mon, 24 Apr 2006 16:25:39 -0700
Hua Zhong <hzhong@gmail.com> 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:Filename@Line
> ! 0 50505 tcp_transmit_skb():net/ipv4/tcp_output.c@468
>
> There is a chance that my tool is buggy, but I just want to confirm with you whether this does look suspicious and what your opinion is.
>
> Signed-off-by: Hua Zhong <hzhong@gmail.com>
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index a28ae59..743016b 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -465,7 +465,7 @@ #define SYSCTL_FLAG_SACK 0x4
> TCP_INC_STATS(TCP_MIB_OUTSEGS);
>
> err = icsk->icsk_af_ops->queue_xmit(skb, 0);
> - if (unlikely(err <= 0))
> + if (likely(err <= 0))
> return err;
>
> tcp_enter_cwr(sk);
How about just taking off the likely/unlikely in this case.
^ permalink raw reply
* [PATCH] bridge: allow full size vlan packets (repost)
From: Stephen Hemminger @ 2006-04-25 18:08 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
Need to allow for VLAN header when bridging.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
--- bridge.orig/net/bridge/br_forward.c 2006-04-10 16:17:51.000000000 -0700
+++ bridge/net/bridge/br_forward.c 2006-04-19 13:50:42.000000000 -0700
@@ -16,6 +16,7 @@
#include <linux/kernel.h>
#include <linux/netdevice.h>
#include <linux/skbuff.h>
+#include <linux/if_vlan.h>
#include <linux/netfilter_bridge.h>
#include "br_private.h"
@@ -29,10 +30,15 @@
return 1;
}
+static inline unsigned packet_length(const struct sk_buff *skb)
+{
+ return skb->len - (skb->protocol == htons(ETH_P_8021Q) ? VLAN_HLEN : 0);
+}
+
int br_dev_queue_push_xmit(struct sk_buff *skb)
{
/* drop mtu oversized packets except tso */
- if (skb->len > skb->dev->mtu && !skb_shinfo(skb)->tso_size)
+ if (packet_length(skb) > skb->dev->mtu && !skb_shinfo(skb)->tso_size)
kfree_skb(skb);
else {
#ifdef CONFIG_BRIDGE_NETFILTER
^ permalink raw reply
* Re: is it a backwards compatability catch-22?
From: Rick Jones @ 2006-04-25 18:34 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: Stephen Hemminger, Linux Network Development list
In-Reply-To: <4807377b0604250909m34f6030ar19735b3343884399@mail.gmail.com>
Jesse Brandeburg wrote:
> On 4/24/06, Rick Jones <rick.jones2@hp.com> 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" or something like that.
>>
>>Is that because adding another NIC at a later time might cause it to
>>grab ethN out from under what I'm trying to do with udev?
>
>
> From what I read its likely to be because there may already be a
> device named "eth1" due to default naming when you are trying to
> rename a device (say eth0) to eth1.
>
> this is all because Debian now has async init, right?
Beats me. I got the impression that udev things were happening "early
enough" in my case that I didn't run into the issue. still, init and
device names are presently a maze of twisty passages to me. someone else
also suggested not using the ethN stuff - or at least not starting at 0,
but start them at N where N is reasonably large. i decided to call them
lan0, lan1, etc just to be perverse and see what breaks.
> BTW, since the letters in udev are all hex, it shouldn't matter
> whether they are upper or lower case, IMO
that would be my opinion as well, certainly that was my expectation -
that I could simply "cut and paste" MAC addresses from the likes of
ifconfig output
alas, it seems that if I leave theme upper case, the renaming does not
happen. i am _guessing_ the comparison is a simple string compare. and
it doesn't _really_ know that what is being compared is a MAC address?
rick jones
^ permalink raw reply
* Re: is it a backwards compatability catch-22?
From: Michal Schmidt @ 2006-04-25 19:10 UTC (permalink / raw)
To: Rick Jones; +Cc: Linux Network Development list
In-Reply-To: <444D6396.4010004@hp.com>
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:12:79:9e:0e:d3", NAME="eth3"
> KERNEL="eth*",SYSFS{address}=="00:0c:fc:00:08:71", NAME="eth4"
^^^
BTW, you should use "==" here instead of "=". Otherwise the rules will
break with newer udev versions which behave strictly in this regard.
Michal
^ permalink raw reply
* [PATCH 0/5] sky2: version 1.2
From: Stephen Hemminger @ 2006-04-25 17:58 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
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
--
^ permalink raw reply
* [PATCH 1/5] sky2: reschedule if irq still pending
From: Stephen Hemminger @ 2006-04-25 17:58 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
In-Reply-To: <20060425175849.372221000@localhost.localdomain>
[-- Attachment #1: sky2-edge.patch --]
[-- Type: text/plain, Size: 2676 bytes --]
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.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-04-25 10:48:44.000000000 -0700
+++ sky2-2.6.17/drivers/net/sky2.c 2006-04-25 10:48:47.000000000 -0700
@@ -2093,6 +2093,7 @@
int work_done = 0;
u32 status = sky2_read32(hw, B0_Y2_SP_EISR);
+ restart_poll:
if (unlikely(status & ~Y2_IS_STAT_BMU)) {
if (status & Y2_IS_HW_ERR)
sky2_hw_intr(hw);
@@ -2123,7 +2124,7 @@
}
if (status & Y2_IS_STAT_BMU) {
- work_done = sky2_status_intr(hw, work_limit);
+ work_done += sky2_status_intr(hw, work_limit - work_done);
*budget -= work_done;
dev0->quota -= work_done;
@@ -2133,9 +2134,22 @@
sky2_write32(hw, STAT_CTRL, SC_STAT_CLR_IRQ);
}
- netif_rx_complete(dev0);
+ local_irq_disable();
+ __netif_rx_complete(dev0);
status = sky2_read32(hw, B0_Y2_SP_LISR);
+
+ if (unlikely(status)) {
+ /* More work pending, try and keep going */
+ if (__netif_rx_schedule_prep(dev0)) {
+ __netif_rx_reschedule(dev0, work_done);
+ status = sky2_read32(hw, B0_Y2_SP_EISR);
+ local_irq_enable();
+ goto restart_poll;
+ }
+ }
+
+ local_irq_enable();
return 0;
}
@@ -2153,8 +2167,6 @@
prefetch(&hw->st_le[hw->st_idx]);
if (likely(__netif_rx_schedule_prep(dev0)))
__netif_rx_schedule(dev0);
- else
- printk(KERN_DEBUG PFX "irq race detected\n");
return IRQ_HANDLED;
}
--- sky2-2.6.17.orig/include/linux/netdevice.h 2006-04-25 10:48:44.000000000 -0700
+++ sky2-2.6.17/include/linux/netdevice.h 2006-04-25 10:48:47.000000000 -0700
@@ -829,19 +829,21 @@
__netif_rx_schedule(dev);
}
-/* Try to reschedule poll. Called by dev->poll() after netif_rx_complete().
- * Do not inline this?
- */
+
+static inline void __netif_rx_reschedule(struct net_device *dev, int undo)
+{
+ dev->quota += undo;
+ list_add_tail(&dev->poll_list, &__get_cpu_var(softnet_data).poll_list);
+ __raise_softirq_irqoff(NET_RX_SOFTIRQ);
+}
+
+/* Try to reschedule poll. Called by dev->poll() after netif_rx_complete(). */
static inline int netif_rx_reschedule(struct net_device *dev, int undo)
{
if (netif_rx_schedule_prep(dev)) {
unsigned long flags;
-
- dev->quota += undo;
-
local_irq_save(flags);
- list_add_tail(&dev->poll_list, &__get_cpu_var(softnet_data).poll_list);
- __raise_softirq_irqoff(NET_RX_SOFTIRQ);
+ __netif_rx_reschedule(dev, undo);
local_irq_restore(flags);
return 1;
}
--
^ permalink raw reply
* [PATCH 5/5] sky2: version 1.2
From: Stephen Hemminger @ 2006-04-25 17:58 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
In-Reply-To: <20060425175849.372221000@localhost.localdomain>
[-- Attachment #1: sky2-1.2.patch --]
[-- Type: text/plain, Size: 387 bytes --]
Update to version 1.2
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-04-25 10:54:57.000000000 -0700
+++ sky2-2.6.17/drivers/net/sky2.c 2006-04-25 10:55:51.000000000 -0700
@@ -51,7 +51,7 @@
#include "sky2.h"
#define DRV_NAME "sky2"
-#define DRV_VERSION "1.1"
+#define DRV_VERSION "1.2"
#define PFX DRV_NAME " "
/*
--
^ permalink raw reply
* [PATCH 4/5] sky2: reset function can be devinit
From: Stephen Hemminger @ 2006-04-25 17:58 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
In-Reply-To: <20060425175849.372221000@localhost.localdomain>
[-- Attachment #1: sky2-devinit.patch --]
[-- Type: text/plain, Size: 488 bytes --]
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 <shemminger@osdl.org>
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-04-25 10:53:37.000000000 -0700
+++ sky2-2.6.17/drivers/net/sky2.c 2006-04-25 10:54:57.000000000 -0700
@@ -2219,7 +2219,7 @@
}
-static int sky2_reset(struct sky2_hw *hw)
+static int __devinit sky2_reset(struct sky2_hw *hw)
{
u16 status;
u8 t8, pmd_type;
--
^ permalink raw reply
* [PATCH 3/5] sky2: use ALIGN() macro
From: Stephen Hemminger @ 2006-04-25 17:58 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
In-Reply-To: <20060425175849.372221000@localhost.localdomain>
[-- Attachment #1: sky2-align.patch --]
[-- Type: text/plain, Size: 995 bytes --]
The ALIGN() macro in kernel.h does the same math that the
sky2 driver was using for padding.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-04-25 10:47:03.000000000 -0700
+++ sky2-2.6.17/drivers/net/sky2.c 2006-04-25 10:47:28.000000000 -0700
@@ -925,8 +925,7 @@
skb = alloc_skb(size + RX_SKB_ALIGN, gfp_mask);
if (likely(skb)) {
unsigned long p = (unsigned long) skb->data;
- skb_reserve(skb,
- ((p + RX_SKB_ALIGN - 1) & ~(RX_SKB_ALIGN - 1)) - p);
+ skb_reserve(skb, ALIGN(p, RX_SKB_ALIGN) - p);
}
return skb;
@@ -1686,13 +1685,12 @@
}
-#define roundup(x, y) ((((x)+((y)-1))/(y))*(y))
/* Want receive buffer size to be multiple of 64 bits
* and incl room for vlan and truncation
*/
static inline unsigned sky2_buf_size(int mtu)
{
- return roundup(mtu + ETH_HLEN + VLAN_HLEN, 8) + 8;
+ return ALIGN(mtu + ETH_HLEN + VLAN_HLEN, 8) + 8;
}
static int sky2_change_mtu(struct net_device *dev, int new_mtu)
--
^ permalink raw reply
* [PATCH 2/5] sky2: add fake idle irq timer
From: Stephen Hemminger @ 2006-04-25 17:58 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
In-Reply-To: <20060425175849.372221000@localhost.localdomain>
[-- Attachment #1: sky2-idle-timer.patch --]
[-- Type: text/plain, Size: 1943 bytes --]
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 <shemminger@osdl.org>
--- sky2-2.6.17.orig/drivers/net/sky2.c 2006-04-25 10:48:47.000000000 -0700
+++ sky2-2.6.17/drivers/net/sky2.c 2006-04-25 10:53:32.000000000 -0700
@@ -2086,6 +2086,20 @@
}
}
+/* If idle then force a fake soft NAPI poll once a second
+ * to work around cases where sharing an edge triggered interrupt.
+ */
+static void sky2_idle(unsigned long arg)
+{
+ struct net_device *dev = (struct net_device *) arg;
+
+ local_irq_disable();
+ if (__netif_rx_schedule_prep(dev))
+ __netif_rx_schedule(dev);
+ local_irq_enable();
+}
+
+
static int sky2_poll(struct net_device *dev0, int *budget)
{
struct sky2_hw *hw = ((struct sky2_port *) netdev_priv(dev0))->hw;
@@ -2134,6 +2148,8 @@
sky2_write32(hw, STAT_CTRL, SC_STAT_CLR_IRQ);
}
+ mod_timer(&hw->idle_timer, jiffies + HZ);
+
local_irq_disable();
__netif_rx_complete(dev0);
@@ -3288,6 +3304,8 @@
sky2_write32(hw, B0_IMSK, Y2_IS_BASE);
+ setup_timer(&hw->idle_timer, sky2_idle, (unsigned long) dev);
+
pci_set_drvdata(pdev, hw);
return 0;
@@ -3323,13 +3341,15 @@
if (!hw)
return;
+ del_timer_sync(&hw->idle_timer);
+
+ sky2_write32(hw, B0_IMSK, 0);
dev0 = hw->dev[0];
dev1 = hw->dev[1];
if (dev1)
unregister_netdev(dev1);
unregister_netdev(dev0);
- sky2_write32(hw, B0_IMSK, 0);
sky2_set_power_state(hw, PCI_D3hot);
sky2_write16(hw, B0_Y2LED, LED_STAT_OFF);
sky2_write8(hw, B0_CTST, CS_RST_SET);
--- sky2-2.6.17.orig/drivers/net/sky2.h 2006-04-25 10:48:42.000000000 -0700
+++ sky2-2.6.17/drivers/net/sky2.h 2006-04-25 10:51:33.000000000 -0700
@@ -1880,6 +1880,8 @@
struct sky2_status_le *st_le;
u32 st_idx;
dma_addr_t st_dma;
+
+ struct timer_list idle_timer;
int msi_detected;
wait_queue_head_t msi_wait;
};
--
^ permalink raw reply
* Re: [PATCH 2/5] sky2: add fake idle irq timer
From: Francois Romieu @ 2006-04-25 21:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jeff Garzik, netdev
In-Reply-To: <20060425175951.444629000@localhost.localdomain>
Stephen Hemminger <shemminger@osdl.org> :
[...]
> --- sky2-2.6.17.orig/drivers/net/sky2.c 2006-04-25 10:48:47.000000000 -0700
> +++ sky2-2.6.17/drivers/net/sky2.c 2006-04-25 10:53:32.000000000 -0700
> @@ -2086,6 +2086,20 @@
> }
> }
>
> +/* If idle then force a fake soft NAPI poll once a second
> + * to work around cases where sharing an edge triggered interrupt.
> + */
> +static void sky2_idle(unsigned long arg)
> +{
> + struct net_device *dev = (struct net_device *) arg;
> +
> + local_irq_disable();
> + if (__netif_rx_schedule_prep(dev))
> + __netif_rx_schedule(dev);
> + local_irq_enable();
> +}
> +
> +
> static int sky2_poll(struct net_device *dev0, int *budget)
> {
> struct sky2_hw *hw = ((struct sky2_port *) netdev_priv(dev0))->hw;
> @@ -2134,6 +2148,8 @@
> sky2_write32(hw, STAT_CTRL, SC_STAT_CLR_IRQ);
> }
>
> + mod_timer(&hw->idle_timer, jiffies + HZ);
> +
> local_irq_disable();
> __netif_rx_complete(dev0);
Any objection against moving mod_timer() from sky2_poll() to sky2_idle()
so as to keep poll() path unmodified ?
--
Ueimor
^ permalink raw reply
* Re: [PATCH 2/5] sky2: add fake idle irq timer
From: Stephen Hemminger @ 2006-04-25 21:30 UTC (permalink / raw)
To: Francois Romieu; +Cc: Jeff Garzik, netdev
In-Reply-To: <20060425212329.GA18035@electric-eye.fr.zoreil.com>
On Tue, 25 Apr 2006 23:23:29 +0200
Francois Romieu <romieu@fr.zoreil.com> wrote:
> Stephen Hemminger <shemminger@osdl.org> :
> [...]
> > --- sky2-2.6.17.orig/drivers/net/sky2.c 2006-04-25 10:48:47.000000000 -0700
> > +++ sky2-2.6.17/drivers/net/sky2.c 2006-04-25 10:53:32.000000000 -0700
> > @@ -2086,6 +2086,20 @@
> > }
> > }
> >
> > +/* If idle then force a fake soft NAPI poll once a second
> > + * to work around cases where sharing an edge triggered interrupt.
> > + */
> > +static void sky2_idle(unsigned long arg)
> > +{
> > + struct net_device *dev = (struct net_device *) arg;
> > +
> > + local_irq_disable();
> > + if (__netif_rx_schedule_prep(dev))
> > + __netif_rx_schedule(dev);
> > + local_irq_enable();
> > +}
> > +
> > +
> > static int sky2_poll(struct net_device *dev0, int *budget)
> > {
> > struct sky2_hw *hw = ((struct sky2_port *) netdev_priv(dev0))->hw;
> > @@ -2134,6 +2148,8 @@
> > sky2_write32(hw, STAT_CTRL, SC_STAT_CLR_IRQ);
> > }
> >
> > + mod_timer(&hw->idle_timer, jiffies + HZ);
> > +
> > local_irq_disable();
> > __netif_rx_complete(dev0);
>
>
> 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.
^ permalink raw reply
* Re: [PATCH]: suspicious unlikely usage in tcp_transmit_skb()
From: David S. Miller @ 2006-04-25 21:46 UTC (permalink / raw)
To: shemminger; +Cc: hzhong, netdev
In-Reply-To: <20060425100149.636d6a1d@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Tue, 25 Apr 2006 10:01:49 -0700
> > # Hit # miss Function:Filename@Line
> > ! 0 50505 tcp_transmit_skb():net/ipv4/tcp_output.c@468
...
> How about just taking off the likely/unlikely in this case.
Why remove it when we'll now get a 50505 to 0 hit rate?
^ permalink raw reply
* Re: [PATCH]: suspicious unlikely usage in tcp_transmit_skb()
From: Stephen Hemminger @ 2006-04-25 22:16 UTC (permalink / raw)
To: David S. Miller; +Cc: hzhong, netdev
In-Reply-To: <20060425.144649.129407913.davem@davemloft.net>
On Tue, 25 Apr 2006 14:46:49 -0700 (PDT)
"David S. Miller" <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@osdl.org>
> Date: Tue, 25 Apr 2006 10:01:49 -0700
>
> > > # Hit # miss Function:Filename@Line
> > > ! 0 50505 tcp_transmit_skb():net/ipv4/tcp_output.c@468
> ...
> > How about just taking off the likely/unlikely in this case.
>
> Why remove it when we'll now get a 50505 to 0 hit rate?
Depends on the data stream, but I guess if we are seeing high loss
we really don't care about the CPU branch prediction.
^ permalink raw reply
* Re: [PATCH 2/5] sky2: add fake idle irq timer
From: Francois Romieu @ 2006-04-25 22:39 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jeff Garzik, netdev
In-Reply-To: <20060425143042.29d636a8@localhost.localdomain>
Stephen Hemminger <shemminger@osdl.org> :
[...]
> > 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 stale, the timer will not be
rescheduled when work_done >= work_limit. I.e. the optimization
tends to vanish when the load goes up. Before this point is reached,
the long path of mod_timer() can be taken up to HZ per second.
I have no idea which balance works best.
--
Ueimor
^ permalink raw reply
* Re: [PATCH 2/5] sky2: add fake idle irq timer
From: Stephen Hemminger @ 2006-04-25 22:45 UTC (permalink / raw)
To: Francois Romieu; +Cc: Jeff Garzik, netdev
In-Reply-To: <20060425223900.GB18035@electric-eye.fr.zoreil.com>
On Wed, 26 Apr 2006 00:39:00 +0200
Francois Romieu <romieu@fr.zoreil.com> wrote:
> Stephen Hemminger <shemminger@osdl.org> :
> [...]
> > > 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 stale, the timer will not be
> rescheduled when work_done >= work_limit.
I am trying to work around possible lost IRQ's, not netdev scheduler
screw up's. If workdone >= work_limit, then it will already be
called back later when it return's 1.
^ permalink raw reply
* sky2 driver problems in 2.6.17-rc2-git6 (was: Re: kernel panic (on DHCP discover?) in sky2 driver of 2.6.17-rc1)
From: Guenther Thomsen @ 2006-04-26 0:06 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: John W. Linville, netdev
In-Reply-To: <20060417111846.5a5deccc@localhost.localdomain>
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 2.6.16.11 . One port works
fine (so far, I just did very limited testing with ttcp). The second port
does negotiate IP address via DHCP, but the packgages it receives
seem to be garbled:
--8<--
0x0000: 0000 6175 6469 7428 3131 3435 3939 3430 ..audit(11459940
0x0010: 3031 2e39 3738 3a33 3829 3a20 7573 6572 01.978:38):.user
0x0020: 2070 6964 3d33 3230 3920 7569 643d .pid=3209.uid=
12:56:23.725090 00:00:00:00:00:00 > 30:6e:6d:00:00:00 null I (s=32,r=55,P) len=42
12:56:24.603274 00:00:21:00:00:00 > 00:00:00:00:00:00 null disc/C len=43
12:56:26.619326 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
12:56:28.635346 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
12:56:29.734046 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
12:56:29.865239 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
12:56:30.651371 00:00:00:00:00:00 > a6:00:00:00:4d:04, ethertype Unknown (0xe20c), length 60:
0x0000: 0000 6175 6469 7428 3131 3435 3939 3436 ..audit(11459946
0x0010: 3031 2e33 3639 3a34 3729 3a20 7573 6572 01.369:47):.user
0x0020: 2070 6964 3d33 3239 3820 7569 643d .pid=3298.uid=
12:56:30.916718 00:00:f0:71:61:00 > 28:37:03:5b:3a:00 null I (s=16,r=0,C) len=42
12:56:30.923558 00:00:21:00:00:00 > 00:00:00:00:00:00 null rnr (r=55,C) len=42
12:56:32.667413 00:00:d0:2e:30:42 > 10:60:61:00:00:00, ethertype Unknown (0x572b), length 60:
0x0000: 0000 d675 0d00 0000 0000 0200 0000 0000 ...u............
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 ffff ffff 0000 0000 1300 0000 ..............
12:56:33.296384 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
12:56:33.303222 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
[..]
13:00:44.340062 00:00:00:00:00:00 > 5f:00:00:00:00:00 null I (s=0,r=0,C) len=42
13:00:44.672350 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
13:00:44.868724 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
13:00:45.340123 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
13:00:46.340173 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
13:00:46.688433 IP truncated-ip - 1454 bytes missing! 192.168.65.66.40313 > 192.168.65.65.5001: . 1426488980:1426490428(1448) ack 1790562292 win 1460 <nop,nop,timestamp[|tcp]>
13:00:48.704431 00:00:21:00:00:00 > 00:00:00:00:00:00 null I (s=17,r=18,C) len=42
13:00:48.886426 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
13:00:50.720463 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
13:00:52.736496 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
13:00:54.752522 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
13:00:54.927556 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
13:00:54.934394 00:00:00:00:00:00 > 00:00:00:00:00:00 null I (s=0,r=0,C) len=42
-->8--
On a different host connected to the same switch, traffic looks more like:
--8<--
2:01:49.388992 IP 192.168.64.1.ntp > 255.255.255.255.ntp: NTPv3, Broadcast, length 48
12:01:50.176550 802.1d config 8000.00:a0:d1:e1:b4:78.8026 root 8000.00:a0:d1:e1:b4:78 pathcost 0 age 0 max 20 hello 2 fdelay 15
12:01:51.235034 arp reply 192.168.64.32 is-at 00:0a:49:00:5e:8a
12:01:51.241857 arp reply 192.168.64.33 is-at 00:0a:49:00:5e:8b
12:01:51.891193 00:00:01:02:c8:58 > 45:c0:00:1c:00:20, ethertype Unknown (0xe000), length 60:
0x0000: 0001 1164 ee9b 0000 0000 0000 0000 0000 ...d............
0x0010: 0000 0000 0000 0000 0000 0000 2f6b 8c87 ............/k..
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
12:01:52.192552 802.1d config 8000.00:a0:d1:e1:b4:78.8026 root 8000.00:a0:d1:e1:b4:78 pathcost 0 age 0 max 20 hello 2 fdelay 15
12:01:52.801392 arp reply 192.168.64.34 is-at 00:0a:49:00:5e:8c
12:01:52.808240 arp reply 192.168.64.35 is-at 00:0a:49:00:5e:8d
12:01:54.208495 802.1d config 8000.00:a0:d1:e1:b4:78.8026 root 8000.00:a0:d1:e1:b4:78 pathcost 0 age 0 max 20 hello 2 fdelay 15
12:01:56.224453 802.1d config 8000.00:a0:d1:e1:b4:78.8026 root 8000.00:a0:d1:e1:b4:78 pathcost 0 age 0 max 20 hello 2 fdelay 15
12:01:58.240464 802.1d config 8000.00:a0:d1:e1:b4:78.8026 root 8000.00:a0:d1:e1:b4:78 pathcost 0 age 0 max 20 hello 2 fdelay 15
12:02:00.029320 arp reply 192.168.64.39 is-at 00:0a:49:00:5e:ff
12:02:00.256420 802.1d config 8000.00:a0:d1:e1:b4:78.8026 root 8000.00:a0:d1:e1:b4:78 pathcost 0 age 0 max 20 hello 2 fdelay 15
-->8--
I noticed that the interrupt count is very low too (the interrupt count
as shown in /proc/interrupts is much higher):
--8<--
[root@penguin1 ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:A0:D1:E1:F2:D8
inet addr:192.168.65.65 Bcast:192.168.65.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4559786 errors:0 dropped:0 overruns:0 frame:0
TX packets:4071967 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4680823977 (4.3 GiB) TX bytes:4332319475 (4.0 GiB)
Interrupt:169
eth1 Link encap:Ethernet HWaddr 00:A0:D1:E1:F2:D9
inet addr:192.168.64.199 Bcast:192.168.64.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2193 errors:0 dropped:0 overruns:0 frame:0
TX packets:29 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:180137 (175.9 KiB) TX bytes:1856 (1.8 KiB)
Interrupt:169
-->8--
I then tried 2.6.17-rc2-git6. At first it looked OK, the second ethernet
device was configured properly and I got some traffic through. Once
I started copying large files (some 5GB were successfully copied) over
NFS using a (very) fast NFS server though, traffic received by eth1 got
corrupted again:
--8<--
[root@penguin1 ~]# tcpdump -n -i eth1 -s 0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
14:23:14.049450 arp who-has 192.168.64.199 tell 192.168.64.202
14:23:14.049519 arp reply 192.168.64.199 is-at 00:a0:d1:e1:f2:d9
14:23:14.745075 arp who-has 192.168.64.199 tell 192.168.64.202
14:23:14.745082 arp reply 192.168.64.199 is-at 00:a0:d1:e1:f2:d9
14:23:14.852108 IP truncated-ip - 1454 bytes missing! 192.168.64.110.nfs > 192.168.64.199.1021: . 159991419:159992879(1460) ack 3444328765 win 64240
14:23:14.944489 00:00:00:00:00:00 > a3:00:00:00:50:04, ethertype Unknown (0x210d), length 98:
0x0000: 0000 6175 6469 7428 3131 3436 3030 3030 ..audit(11460000
0x0010: 3032 2e31 3836 3a36 3329 3a20 7573 6572 02.186:63):.user
0x0020: 2070 6964 3d33 3336 3120 7569 643d 3020 .pid=3361.uid=0.
0x0030: 6175 6964 3d34 3239 3439 3637 3239 3520 auid=4294967295.
0x0040: 6d73 673d 2750 414d 2073 6574 6372 6564 msg='PAM.setcred
0x0050: 3a20 7573 :.us
14:23:15.944703 arp who-has 192.168.64.253 tell 192.168.79.254
14:23:16.868291 arp who-has 192.168.64.199 tell 192.168.64.202
14:23:16.868301 arp reply 192.168.64.199 is-at 00:a0:d1:e1:f2:d9
14:23:16.944907 IP truncated-ip - 12 bytes missing! 192.168.64.101.netbios-ns > 192.168.64.255.netbios-ns: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
14:23:17.945113 IP truncated-ip - 12 bytes missing! 192.168.64.101.netbios-ns > 192.168.64.255.netbios-ns: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
14:23:18.884430 arp who-has 192.168.64.199 tell 192.168.64.202
14:23:18.884441 arp reply 192.168.64.199 is-at 00:a0:d1:e1:f2:d9
14:23:18.945318 IP truncated-ip - 12 bytes missing! 192.168.64.101.netbios-ns > 192.168.64.255.netbios-ns: NBT UDP PACKET(137): REGISTRATION; REQUEST; BROADCAST
-->8--
The ".audit ... PAM.sedcred" string is interesting. This is most likely
not traffic from the net, but a text inside the host's RAM. Did some
pointer get mangled?
I recompiled the kernel, now with RHFC4's gcc32. The result is similiar
(only after some data was copied using NFS, the second interface goes
bad):
--8<--
[root@penguin1 ~]# tcpdump -n -s 0 -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
15:48:02.306927 IP 192.168.64.202 > 192.168.64.199: icmp 64: echo request seq 8801
15:48:02.316088 arp who-has 192.168.64.202 tell 192.168.64.199
15:48:02.316329 arp who-has 192.168.64.199 tell 192.168.79.254
15:48:02.316335 arp reply 192.168.64.199 is-at 00:a0:d1:e1:f2:d9
15:48:02.316338 802.1d config 8000.00:a0:d1:e1:b4:78.8025 root 8000.00:a0:d1:e1:b4:78 pathcost 0 age 0 max 20 hello 2 fdelay 15
15:48:03.307095 IP 192.168.64.202 > 192.168.64.199: icmp 64: echo request seq 8802
15:48:03.307289 IP truncated-ip - 38 bytes missing! 192.168.64.202 > 192.168.64.199: icmp 64: echo request seq 8803
15:48:03.316166 arp who-has 192.168.64.202 tell 192.168.64.199
15:48:03.316397 arp who-has 192.168.64.199 tell 192.168.79.254
15:48:03.316401 arp reply 192.168.64.199 is-at 00:a0:d1:e1:f2:d9
15:48:03.316404 802.1d config 8000.00:a0:d1:e1:b4:78.8025 root 8000.00:a0:d1:e1:b4:78 pathcost 0 age 0 max 20 hello 2 fdelay 15
15:48:03.784698 IP truncated-ip - 38 bytes missing! 192.168.64.202 > 192.168.64.199: icmp 64: echo request seq 8804
12 packets captured
12 packets received by filter
0 packets dropped by kernel
-->8--
No suspect text and no zero filled packets, only truncated ones now,
but that's bad enough to stop NFS and cause bad packet loss:
--8<--
64 bytes from 192.168.64.199: icmp_seq=83 ttl=64 time=147073 ms
64 bytes from 192.168.64.199: icmp_seq=84 ttl=64 time=149073 ms
64 bytes from 192.168.64.199: icmp_seq=85 ttl=64 time=149073 ms
64 bytes from 192.168.64.199: icmp_seq=87 ttl=64 time=149073 ms
64 bytes from 192.168.64.199: icmp_seq=88 ttl=64 time=149073 ms
64 bytes from 192.168.64.199: icmp_seq=233 ttl=64 time=82023 ms
64 bytes from 192.168.64.199: icmp_seq=236 ttl=64 time=80018 ms
64 bytes from 192.168.64.199: icmp_seq=241 ttl=64 time=81018 ms
64 bytes from 192.168.64.199: icmp_seq=243 ttl=64 time=81018 ms
64 bytes from 192.168.64.199: icmp_seq=253 ttl=64 time=85018 ms
64 bytes from 192.168.64.199: icmp_seq=255 ttl=64 time=85018 ms
64 bytes from 192.168.64.199: icmp_seq=256 ttl=64 time=85629 ms
64 bytes from 192.168.64.199: icmp_seq=257 ttl=64 time=87023 ms
--- 192.168.64.199 ping statistics ---
346 packets transmitted, 63 received, +3 errors, 81% packet loss, time 345136ms
rtt min/avg/max/mdev = 80018.748/119940.275/149073.885/21090.211 ms, pipe 151
-->8--
Considering the recent NFS changes, I tried to get the system into this
state using just ttcp. With some determination, three more hosts and
a few million packets, I succeeded. This time eth0 truncated packets
and traffic slowed to a crawl (~1 good packet every 2s).
Some progress has been made, but it's not quite solid yet.
best regards
Guenther
^ permalink raw reply
* Re: Fw: Bug: PPP dropouts in >=2.6.16
From: Nuri Jawad @ 2006-04-26 0:36 UTC (permalink / raw)
To: Sven Schuster; +Cc: Andi Kleen, Jesse Brandeburg, Andrew Morton, netdev
In-Reply-To: <20060424074148.GB23340@zion.homelinux.com>
> 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 one of the 2.6.16 kernels I tried (latest was .9)? Can't say
for sure if CPU load is a factor, load on the connection seems to be.
After using 2.6.15.7 for another 5 days now with some more stress
testing, I can assure that 2.6.15 definitely does not produce any
dropouts on this machine.
For now I'll try to reproduce the effects on my second box (AMD64/nf4).
I'd be happy if someone could give me some hints on which patches I could
try to revert as the changes to ppp between the two versions look fairly
harmless. For the first time in 8.5 years, I cannot use a 'stable' kernel
release and there is really nothing special about this system.
Regards,
Nuri
^ 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