* [PATCH] iproute2: use -fPIC in lib/
From: Andreas Henriksson @ 2009-09-21 7:47 UTC (permalink / raw)
To: shemminger, netdev; +Cc: Dmitry Baryshev, 547602
In-Reply-To: <39840bc80909201712o65b1c84m1bc453bf9d4329a@mail.gmail.com>
The static libnetlink.a library is exposed to other users in Debian via the
"iproute-dev" package. Apparently people are interested in using it in their
shared libraries and would like to see the code be position independent.
Patch below makes the code under lib/ build with -fPIC.
See http://bugs.debian.org/547602
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
diff --git a/lib/Makefile b/lib/Makefile
index bc270bf..da2f0fc 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -1,3 +1,4 @@
+CFLAGS += -fPIC
UTILOBJ=utils.o rt_names.o ll_types.o ll_proto.o ll_addr.o inet_proto.o
^ permalink raw reply related
* Re: [RFC] Virtual Machine Device Queues(VMDq) support on KVM
From: Rusty Russell @ 2009-09-21 7:07 UTC (permalink / raw)
To: virtualization
Cc: Stephen Hemminger, Xin, Xiaohui, kvm@vger.kernel.org,
mst@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, hpa@zytor.com,
mingo@elte.hu, akpm@linux-foundation.org
In-Reply-To: <20090901090518.1193e412@nehalam>
On Wed, 2 Sep 2009 01:35:18 am Stephen Hemminger wrote:
> On Tue, 1 Sep 2009 14:58:19 +0800
> "Xin, Xiaohui" <xiaohui.xin@intel.com> wrote:
>
> > [RFC] Virtual Machine Device Queues (VMDq) support on KVM
> >
> > Network adapter with VMDq technology presents multiple pairs of tx/rx queues,
> > and renders network L2 sorting mechanism based on MAC addresses and VLAN tags
> > for each tx/rx queue pair. Here we present a generic framework, in which network
> > traffic to/from a tx/rx queue pair can be directed from/to a KVM guest without
> > any software copy.
> >
> > Actually this framework can apply to traditional network adapters which have
> > just one tx/rx queue pair. And applications using the same user/kernel interface
> > can utilize this framework to send/receive network traffic directly thru a tx/rx
> > queue pair in a network adapter.
> >
> > We use virtio-net architecture to illustrate the framework.
> >
> >
> > |--------------------| pop add_buf |----------------|
> > | Qemu process | <--------- TX <---------- | Guest Kernel |
> > | | ---------> ----------> | |
> > | Virtio-net | push get_buf | |
> > | (Backend service) | ---------> RX ----------> | Virtio-net |
> > | | <--------- <---------- | driver |
> > | | push get_buf | |
> > |--------------------| |----------------|
> > |
> > |
> > | AIO (read & write) combined with Direct I/O
> > | (which substitute synced file operations)
> > |-----------------------------------------------------------------------|
> > | Host kernel | read: copy-less with directly mapped user |
> > | | space to kernel, payload directly DMAed |
> > | | into user space |
> > | | write: copy-less with directly mapped user |
> > | | space to kernel, payload directly hooked |
> > | | to a skb |
> > | | |
> > | (a likely | |
> > | queue pair | |
> > | instance) | |
> > | | | |
> > | NIC driver <--> TUN/TAP driver |
> > |-----------------------------------------------------------------------|
> > |
> > |
> > traditional adapter or a tx/rx queue pair
> >
> > The basic idea is to utilize the kernel Asynchronous I/O combined with Direct
> > I/O to implements copy-less TUN/TAP device. AIO and Direct I/O is not new to
> > kernel, we still can see it in SCSI tape driver.
> >
> > With traditional file operations, a copying of payload contents from/to the
> > kernel DMA address to/from a user buffer is needed. That's what the copying we
> > want to save.
> >
> > The proposed framework is like this:
> > A TUN/TAP device is bound to a traditional NIC adapter or a tx/rx queue pair in
> > host side. KVM virto-net Backend service, the user space program submits
> > asynchronous read/write I/O requests to the host kernel through TUN/TAP device.
> > The requests are corresponding to the vqueue elements include both transmission
> > & receive. They can be queued in one AIO request and later, the completion will
> > be notified through the underlying packets tx/rx processing of the rx/tx queue
> > pair.
> >
> > Detailed path:
> >
> > To guest Virtio-net driver, packets receive corresponding to asynchronous read
> > I/O requests of Backend service.
> >
> > 1) Guest Virtio-net driver provides header and payload address through the
> > receive vqueue to Virtio-net backend service.
> >
> > 2) Virtio-net backend service encapsulates multiple vqueue elements into
> > multiple AIO control blocks and composes them into one AIO read request.
> >
> > 3) Virtio-net backend service uses io_submit() syscall to pass the request to
> > the TUN/TAP device.
> >
> > 4) Virtio-net backend service uses io_getevents() syscall to check the
> > completion of the request.
> >
> > 5) The TUN/TAP driver receives packets from the queue pair of NIC, and prepares
> > for Direct I/O.
> > A modified NIC driver may render a skb which header is allocated in host
> > kernel, but the payload buffer is directly mapped from user space buffer which
> > are rendered through the AIO request by the Backend service. get_user_pages()
> > may do this. For one AIO read request, the TUN/TAP driver maintains a list for
> > the directly mapped buffers, and a NIC driver tries to get the buffers as
> > payload buffer to compose the new skbs. Of course, if getting the buffers
> > fails, then kernel allocated buffers are used.
> >
> > 6) Modern NIC cards now mostly have the header split feature. The NIC queue
> > pair then may directly DMA the payload into the user spaces mapped payload
> > buffers.
> > Thus a zero-copy for payload is implemented in packet receiving.
> >
> > 7) The TUN/TAP driver manually copy the host header to space user mapped.
> >
> > 8) aio_complete() to notify the Virtio-net backend service for io_getevents().
> >
> >
> > To guest Virtio-net driver, packets send corresponding to asynchronous write
> > I/O requests of backend. The path is similar to packet receive.
> >
> > 1) Guest Virtio-net driver provides header and payload address filled with
> > contents through the transmit vqueue to Virtio-net backed service.
> >
> > 2) Virtio-net backend service encapsulates the vqueue elements into multiple
> > AIO control blocks and composes them into one AIO write request.
> >
> > 3) Virtio-net backend service uses the io_submit() syscall to pass the
> > requests to the TUN/TAP device.
> >
> > 4) Virtio-net backend service uses io_getevents() syscall to check the request
> > completion.
> >
> > 5) The TUN/TAP driver gets the write requests and allocates skbs for it. The
> > header contents are copied into the skb header. The directly mapped user space
> > buffer is easily hooked into skb. Thus a zero copy for payload is implemented
> > in packet sending.
> >
> > 6) aio_complete() to notify the Virtio-net backend service for io_getevents().
> >
> > The proposed framework is described as above.
> >
> > Consider the modifications to the kernel and qemu:
> >
> > To kernel:
> > 1) The TUN/TAP driver may be modified a lot to implement AIO device operations
> > and to implement directly user space mapping into kernel. Code to maintain the
> > directly mapped user buffers should be in. It's just a modification for driver.
> >
> > 2) The NIC driver may be modified to compose skb differently and slightly data
> > structure change to add user directly mapped buffer pointer.
> > Here, maybe it's better for a NIC driver to present an interface for an rx/tx
> > queue pair instance which will also apply to traditional hardware, the kernel
> > interface should not be changed to make the other components happy.
> > The abstraction is useful, though it is not needed immediately here.
> >
> > 3) The skb shared info structure may be modified a little to contain the user
> > directly mapped info.
> >
> > To Qemu:
> > 1) The Virtio-net backend service may be modified to handle AIO read/write
> > requests from the vqueues.
> > 2) Maybe a separate pthread to handle the AIO request triggering is needed.
> >
> > Any comments are appreciated here.
>
> * Code is easier to review than bullet points.
>
> * Direct I/O has to be safe when page is shared by multiple threads,
> and has to be non-blocking since network I/O can take indeterminately
> long (think big queue's, tunneling, ...)
>
> * In the past attempts at Direct I/O on network have always had SMP
> TLB issues. The page has to be flipped or marked as COW on all CPU's
> and the cost of the Inter Processor Interrupt to steal the page has
> been slower than copying
The Guest shouldn't touch the packet, until the virtio net protocol says
it's finished with (just like a real NIC). Even if it's being nasty, if we
have hw csum it'll get the right csum on the wire, and if we don't we copy
internally anyway.
So I think this isn't a problem...
Rusty.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC] skb align patch
From: Eric Dumazet @ 2009-09-21 6:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jesse Brandeburg, Jesper Dangaard Brouer, netdev
In-Reply-To: <20090920142212.1106d2a1@s6510>
Stephen Hemminger a écrit :
> Based on the Intel suggestion that PCI-express overhead is
> a significant cost.
>
> Would people doing performance please measure the impact of
> changing SKB alignment (64 bit only).
I had this idea some time ago when I hit a limit on bnx2 adapter
(Giga bit link, BCM5708S), with small packets. pktgen was able
to send ~500 Mbps 'only', or 700kps if I remember well.
So I tried to align the pktgen build packet to a cache line,
it gave no difference at all, but it was on a 32 bit kernel.
(Thus my patch was for pktgen only, not a generic one as yours)
Could you elaborate why this change could be useful on 64bit ?
Thanks
>
>
> --- a/arch/x86/include/asm/system.h 2009-09-20 14:08:40.922346912 -0700
> +++ b/arch/x86/include/asm/system.h 2009-09-20 14:14:37.012371200 -0700
> @@ -455,4 +455,14 @@ static inline void rdtsc_barrier(void)
> alternative(ASM_NOP3, "lfence", X86_FEATURE_LFENCE_RDTSC);
> }
>
> +#ifndef CONFIG_X86_32
> +/*
> + * DMA to unaligned address is more expensive than the the
> + * overhead of unaligned CPU access.
> + */
> +#define NET_IP_ALIGN 0
> +#define NET_SKB_PAD L1_CACHE_BYTES
> +#endif
> +
> +
> #endif /* _ASM_X86_SYSTEM_H */
> --
^ permalink raw reply
* [PATCH 1/2] netxen: fix minor tx timeout bug
From: Dhananjay Phadke @ 2009-09-21 5:20 UTC (permalink / raw)
To: davem; +Cc: netdev
Fix minor bug in netdev tx timeout handling which could
always lead to firmware reset instead of pci function reset.
netxen_nic_reset_context() requires __NX_RESETTING bit
cleared.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
---
drivers/net/netxen/netxen_nic_main.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index f7bdde1..b8c7235 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1903,12 +1903,13 @@ static void netxen_tx_timeout_task(struct work_struct *work)
netif_wake_queue(adapter->netdev);
- goto done;
+ clear_bit(__NX_RESETTING, &adapter->state);
} else {
+ clear_bit(__NX_RESETTING, &adapter->state);
if (!netxen_nic_reset_context(adapter)) {
adapter->netdev->trans_start = jiffies;
- goto done;
+ return;
}
/* context reset failed, fall through for fw reset */
@@ -1916,8 +1917,6 @@ static void netxen_tx_timeout_task(struct work_struct *work)
request_reset:
adapter->need_fw_reset = 1;
-done:
- clear_bit(__NX_RESETTING, &adapter->state);
}
struct net_device_stats *netxen_nic_get_stats(struct net_device *netdev)
--
1.6.0.2
^ permalink raw reply related
* [PATCH 2/2] netxen: fix firmware init after resume
From: Dhananjay Phadke @ 2009-09-21 5:20 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1253510439-28464-1-git-send-email-dhananjay@netxen.com>
After successful firmware init, return instead of
falling to error path (leading to detach) after
resuming to D0 state. This was broken in recent
firmware reset rehaul.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
---
drivers/net/netxen/netxen_nic_main.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index b8c7235..b5aa974 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1469,6 +1469,7 @@ netxen_nic_resume(struct pci_dev *pdev)
}
netxen_schedule_work(adapter, netxen_fw_poll_work, FW_POLL_DELAY);
+ return 0;
err_out_detach:
netxen_nic_detach(adapter);
--
1.6.0.2
^ permalink raw reply related
* [Patch net-next]atl1c:remove compiling warning
From: jie.yang @ 2009-09-21 5:01 UTC (permalink / raw)
To: davem; +Cc: akpm, jirislaby, jcliburn, netdev, linux-kernel, Jie Yang
Set wol_ctrl_data to value 0, to remove compiling warning.
Signed-off-by: Jie Yang <jie.yang@atheros.com>
---
diff --git a/drivers/net/atl1c/atl1c_main.c b/drivers/net/atl1c/atl1c_main.c
index be2c6cf..1372e9a 100644
--- a/drivers/net/atl1c/atl1c_main.c
+++ b/drivers/net/atl1c/atl1c_main.c
@@ -2296,7 +2296,7 @@ static int atl1c_suspend(struct pci_dev *pdev, pm_message_t state)
u32 ctrl;
u32 mac_ctrl_data;
u32 master_ctrl_data;
- u32 wol_ctrl_data;
+ u32 wol_ctrl_data = 0;
u16 mii_bmsr_data;
u16 save_autoneg_advertised;
u16 mii_intr_status_data;
^ permalink raw reply related
* Re: [PANIC] pktgen panic on load
From: Stephen Hemminger @ 2009-09-21 4:35 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: netdev
In-Reply-To: <1253486747.17792.9.camel@jbrandeb-mobl2>
On Sun, 20 Sep 2009 15:45:47 -0700
Jesse Brandeburg <jesse.brandeburg@intel.com> wrote:
> just got this today after cloning Linus' tree, please let me know if you
> want .config or full dmesg
config would help (hrt, nohz, preempt, ...), and was it just on module load?
or had you started it sending?
> [ 22.441999] modprobe used greatest stack depth: 3144 bytes left
> [ 503.775093] ------------[ cut here ]------------
> [ 503.780252] kernel BUG at net/core/pktgen.c:3503!
> [ 503.785505] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
> [ 503.791575] last sysfs file: /sys/devices/system/cpu/sched_smt_power_savings
> [ 503.799443] CPU 6
> [ 503.801698] Modules linked in: pktgen(+) ixgbe mdio [last unloaded: scsi_wait_scan]
> [ 503.810313] Pid: 6120, comm: kpktgend_13 Not tainted 2.6.31 #1 S5520HC
> [ 503.817600] RIP: 0010:[<ffffffffa0029cda>] [<ffffffffa0029cda>] pktgen_thread_worker+0x76/0x1497 [pktgen]
> [ 503.828402] RSP: 0018:ffff88036dca7d80 EFLAGS: 00010297
> [ 503.834332] RAX: 0000000000000006 RBX: ffff88036d6d0fe0 RCX: 0000000000000000
> [ 503.842299] RDX: 0000000000000006 RSI: ffff8800282d3740 RDI: ffff88036dca7e18
> [ 503.850264] RBP: ffff88036dca7ee0 R08: ffff88036dca6000 R09: ffff8801ed430700
> [ 503.858231] R10: 00000000afddf7db R11: ffff8801e0423e08 R12: ffff88036d9dd9e8
> [ 503.866195] R13: ffffffffa0029c64 R14: ffff88036d9dd9e8 R15: 0000000000000001
> [ 503.874161] FS: 0000000000000000(0000) GS:ffff8800282c0000(0000) knlGS:0000000000000000
> [ 503.883196] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> [ 503.889611] CR2: 00007f1bb5b3e00f CR3: 00000001d7c91000 CR4: 00000000000006e0
> [ 503.897578] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 503.905544] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 503.913513] Process kpktgend_13 (pid: 6120, threadinfo ffff88036dca6000, task ffff88036d6d0fe0)
> [ 503.923224] Stack:
> [ 503.925472] ffff88036dca7ea0 00000002afddf7db 000000000000028c 00000000d2c939bd
> [ 503.933573] <0> ffff88036dca7e00 ffffffff8100a7b4 ffff8801f5993740 00000000afddf7db
> [ 503.942191] <0> ffff8800282d3740 ffff8801ef1897d0 ffff88036dca7e10 ffffffff8104906c
> [ 503.951002] Call Trace:
> [ 503.953739] [<ffffffff8100a7b4>] ? __switch_to+0xfd/0x23b
> [ 503.959870] [<ffffffff8104906c>] ? finish_task_switch+0x4d/0x92
> [ 503.966582] [<ffffffff8106b57b>] ? autoremove_wake_function+0x0/0x5a
> [ 503.973778] [<ffffffff8147aaa5>] ? thread_return+0x71/0xd8
> [ 503.980003] [<ffffffffa0029c64>] ? pktgen_thread_worker+0x0/0x1497 [pktgen]
> [ 503.987874] [<ffffffff8106b12e>] kthread+0x89/0x91
> [ 503.993321] [<ffffffff8100ce5a>] child_rip+0xa/0x20
> [ 503.998865] [<ffffffff8106b0a5>] ? kthread+0x0/0x91
> [ 504.004409] [<ffffffff8100ce50>] ? child_rip+0x0/0x20
> [ 504.010146] Code: 48 89 85 28 ff ff ff 48 89 85 30 ff ff ff 48 c7 85 20 ff ff ff 7b b5 06 81 65 8b 04 25 30 cc 00 00 41 3b 84 24 34 02 00 00 74 04 <0f> 0b eb fe 49 8d 94 24 38 02 00 00 48 c7 c6 a8 ec 02 a0 48 89
> [ 504.032139] RIP [<ffffffffa0029cda>] pktgen_thread_worker+0x76/0x1497 [pktgen]
> [ 504.040316] RSP <ffff88036dca7d80>
> [ 504.044227] ---[ end trace ddca71c9720a201f ]---
>
--
^ permalink raw reply
* [PATCH kernel 2.6.31-git9] 3c574_cs: spin_lock the set_multicast_list function
From: Ken Kawasaki @ 2009-09-21 4:10 UTC (permalink / raw)
To: netdev
In-Reply-To: <20090913072203.d92f1734.ken_kawasaki@spring.nifty.jp>
3c574_cs:
spin_lock the set_multicast_list,
and clean up the set_rx_mode function.
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
---
--- linux-2.6.31-git9.orig/drivers/net/pcmcia/3c574_cs.c 2009-09-20 06:53:31.000000000 +0900
+++ linux-2.6.31-git9/drivers/net/pcmcia/3c574_cs.c 2009-09-20 07:03:39.000000000 +0900
@@ -251,6 +251,7 @@ static void el3_tx_timeout(struct net_de
static int el3_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
static const struct ethtool_ops netdev_ethtool_ops;
static void set_rx_mode(struct net_device *dev);
+static void set_multicast_list(struct net_device *dev);
static void tc574_detach(struct pcmcia_device *p_dev);
@@ -266,7 +267,7 @@ static const struct net_device_ops el3_n
.ndo_tx_timeout = el3_tx_timeout,
.ndo_get_stats = el3_get_stats,
.ndo_do_ioctl = el3_ioctl,
- .ndo_set_multicast_list = set_rx_mode,
+ .ndo_set_multicast_list = set_multicast_list,
.ndo_change_mtu = eth_change_mtu,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
@@ -1153,12 +1154,23 @@ static void set_rx_mode(struct net_devic
unsigned int ioaddr = dev->base_addr;
if (dev->flags & IFF_PROMISC)
- outw(SetRxFilter | RxStation | RxMulticast | RxBroadcast | RxProm,
- ioaddr + EL3_CMD);
+ outw(SetRxFilter|RxStation|RxMulticast|RxBroadcast|RxProm,
+ ioaddr + EL3_CMD);
else if (dev->mc_count || (dev->flags & IFF_ALLMULTI))
- outw(SetRxFilter|RxStation|RxMulticast|RxBroadcast, ioaddr + EL3_CMD);
+ outw(SetRxFilter|RxStation|RxMulticast|RxBroadcast,
+ ioaddr + EL3_CMD);
else
- outw(SetRxFilter | RxStation | RxBroadcast, ioaddr + EL3_CMD);
+ outw(SetRxFilter|RxStation|RxBroadcast, ioaddr + EL3_CMD);
+}
+
+static void set_multicast_list(struct net_device *dev)
+{
+ struct el3_private *lp = netdev_priv(dev);
+ unsigned long flags;
+
+ spin_lock_irqsave(&lp->window_lock, flags);
+ set_rx_mode(dev);
+ spin_unlock_irqrestore(&lp->window_lock, flags);
}
static int el3_close(struct net_device *dev)
^ permalink raw reply
* Re: sky2 rx length errors
From: Stephen Hemminger @ 2009-09-21 1:46 UTC (permalink / raw)
To: Mike McCormack
Cc: Andrew Morton, Grozdan, linux-kernel, Stephen Hemminger, netdev
In-Reply-To: <392fb48f0909201511h34c71e0au838b52c413d517e0@mail.gmail.com>
On Mon, 21 Sep 2009 07:11:21 +0900
Mike McCormack <mikem@ring3k.org> wrote:
> 2009/9/21 Stephen Hemminger <shemminger@vyatta.com>
>
> > On Sat, 19 Sep 2009 23:35:36 -0700
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > (added cc's from the MAINTAINERS file)
> > >
> > > On Fri, 18 Sep 2009 15:41:45 +0200 Grozdan <neutrino8@gmail.com> wrote:
> >
>
> <snip>
>
> > > martian destination 0.0.0.0 from 172.23.204.1, dev eth0
> > > > sky2 eth0: rx length error: status 0x4420100 length 598
> > > > sky2 eth0: rx length error: status 0x5ea0100 length 598
> >
> > This error status occurs if the length reported by the PHY does not
> > match the len reported by the DMA engine. The error status is:
> > 0x4420100 = length 1090 + broadcast packet...
> >
> > No idea what is on your network, but perhaps there is some MTU confusion?
> > Since martian destination seems related, knowing more about that packet
> > might help.
> >
> >
> This appears to be the same problem reported at:
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/292445
>
> Mike
This really looks like multiple packets are getting smashed
together into one DMA, i.e a hardware timing related issue.
it might be possible to work around the problem
by separating them.
--
^ permalink raw reply
* r8169 64-bit DMA support
From: Robert Hancock @ 2009-09-20 23:38 UTC (permalink / raw)
To: netdev; +Cc: Francois Romieu
The r8169 driver currently disables 64-bit DMA support by default (needs
a module parameter to turn it on). This is a bit sub-optimal these days
with most new systems using more than 4GB of RAM. It was this patch back
in 2004 that disabled it:
http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commitdiff;h=c525e7cf69bfe18a1bf362558be5398e0b925d07
It's not clear (from the mails I've read) exactly what was going on in
the case that caused this to be added. Normally these days the PCI
subsystem is supposed to detect that DAC isn't usable on a machine and
refuse setting 64-bit DMA masks, it's not the driver's responsibility to
handle this. I'm guessing that when this change was made that detection
didn't exist though.
Thoughts on whether this default can be changed now? Or at least for the
PCI Express devices, which really should have nothing special about
64-bit addressing..
^ permalink raw reply
* [PANIC] pktgen panic on load
From: Jesse Brandeburg @ 2009-09-20 22:45 UTC (permalink / raw)
To: netdev
just got this today after cloning Linus' tree, please let me know if you
want .config or full dmesg
[ 22.441999] modprobe used greatest stack depth: 3144 bytes left
[ 503.775093] ------------[ cut here ]------------
[ 503.780252] kernel BUG at net/core/pktgen.c:3503!
[ 503.785505] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 503.791575] last sysfs file: /sys/devices/system/cpu/sched_smt_power_savings
[ 503.799443] CPU 6
[ 503.801698] Modules linked in: pktgen(+) ixgbe mdio [last unloaded: scsi_wait_scan]
[ 503.810313] Pid: 6120, comm: kpktgend_13 Not tainted 2.6.31 #1 S5520HC
[ 503.817600] RIP: 0010:[<ffffffffa0029cda>] [<ffffffffa0029cda>] pktgen_thread_worker+0x76/0x1497 [pktgen]
[ 503.828402] RSP: 0018:ffff88036dca7d80 EFLAGS: 00010297
[ 503.834332] RAX: 0000000000000006 RBX: ffff88036d6d0fe0 RCX: 0000000000000000
[ 503.842299] RDX: 0000000000000006 RSI: ffff8800282d3740 RDI: ffff88036dca7e18
[ 503.850264] RBP: ffff88036dca7ee0 R08: ffff88036dca6000 R09: ffff8801ed430700
[ 503.858231] R10: 00000000afddf7db R11: ffff8801e0423e08 R12: ffff88036d9dd9e8
[ 503.866195] R13: ffffffffa0029c64 R14: ffff88036d9dd9e8 R15: 0000000000000001
[ 503.874161] FS: 0000000000000000(0000) GS:ffff8800282c0000(0000) knlGS:0000000000000000
[ 503.883196] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[ 503.889611] CR2: 00007f1bb5b3e00f CR3: 00000001d7c91000 CR4: 00000000000006e0
[ 503.897578] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 503.905544] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 503.913513] Process kpktgend_13 (pid: 6120, threadinfo ffff88036dca6000, task ffff88036d6d0fe0)
[ 503.923224] Stack:
[ 503.925472] ffff88036dca7ea0 00000002afddf7db 000000000000028c 00000000d2c939bd
[ 503.933573] <0> ffff88036dca7e00 ffffffff8100a7b4 ffff8801f5993740 00000000afddf7db
[ 503.942191] <0> ffff8800282d3740 ffff8801ef1897d0 ffff88036dca7e10 ffffffff8104906c
[ 503.951002] Call Trace:
[ 503.953739] [<ffffffff8100a7b4>] ? __switch_to+0xfd/0x23b
[ 503.959870] [<ffffffff8104906c>] ? finish_task_switch+0x4d/0x92
[ 503.966582] [<ffffffff8106b57b>] ? autoremove_wake_function+0x0/0x5a
[ 503.973778] [<ffffffff8147aaa5>] ? thread_return+0x71/0xd8
[ 503.980003] [<ffffffffa0029c64>] ? pktgen_thread_worker+0x0/0x1497 [pktgen]
[ 503.987874] [<ffffffff8106b12e>] kthread+0x89/0x91
[ 503.993321] [<ffffffff8100ce5a>] child_rip+0xa/0x20
[ 503.998865] [<ffffffff8106b0a5>] ? kthread+0x0/0x91
[ 504.004409] [<ffffffff8100ce50>] ? child_rip+0x0/0x20
[ 504.010146] Code: 48 89 85 28 ff ff ff 48 89 85 30 ff ff ff 48 c7 85 20 ff ff ff 7b b5 06 81 65 8b 04 25 30 cc 00 00 41 3b 84 24 34 02 00 00 74 04 <0f> 0b eb fe 49 8d 94 24 38 02 00 00 48 c7 c6 a8 ec 02 a0 48 89
[ 504.032139] RIP [<ffffffffa0029cda>] pktgen_thread_worker+0x76/0x1497 [pktgen]
[ 504.040316] RSP <ffff88036dca7d80>
[ 504.044227] ---[ end trace ddca71c9720a201f ]---
--
Jesse Brandeburg
This email sent from Evolution, powered by Linux
^ permalink raw reply
* [RFC] skb align patch
From: Stephen Hemminger @ 2009-09-20 21:22 UTC (permalink / raw)
To: Jesse Brandeburg, Jesper Dangaard Brouer; +Cc: netdev
Based on the Intel suggestion that PCI-express overhead is
a significant cost.
Would people doing performance please measure the impact of
changing SKB alignment (64 bit only).
--- a/arch/x86/include/asm/system.h 2009-09-20 14:08:40.922346912 -0700
+++ b/arch/x86/include/asm/system.h 2009-09-20 14:14:37.012371200 -0700
@@ -455,4 +455,14 @@ static inline void rdtsc_barrier(void)
alternative(ASM_NOP3, "lfence", X86_FEATURE_LFENCE_RDTSC);
}
+#ifndef CONFIG_X86_32
+/*
+ * DMA to unaligned address is more expensive than the the
+ * overhead of unaligned CPU access.
+ */
+#define NET_IP_ALIGN 0
+#define NET_SKB_PAD L1_CACHE_BYTES
+#endif
+
+
#endif /* _ASM_X86_SYSTEM_H */
^ permalink raw reply
* [GIT *] Solos PCI ADSL driver update
From: David Woodhouse @ 2009-09-20 21:17 UTC (permalink / raw)
To: davem; +Cc: netdev
I'm sorry, I suck. I forgot I had anything outstanding to be pushed
upstream, and should have done this a while ago.
In later versions of the card's FPGA code, the RAM layout for
card<->host communication has changed -- and the new FPGA code is in the
devices which are being shipped now, so it would be really useful if we
could sneak this into 2.6.32. Sorry it's so late.
Please pull from git://git.infradead.org/users/dwmw2/solos-2.6.git
David Woodhouse (1):
solos: Add some margin-related parameters
Nathan Williams (2):
solos: support new FPGA RAM layout
solos: Check for rogue received packets
Simon Farnsworth (1):
solos: Show Interleaving details for ADSL2 and 2+
drivers/atm/solos-attrlist.c | 11 ++++++
drivers/atm/solos-pci.c | 75 +++++++++++++++++++++++++++++++++++++-----
2 files changed, 77 insertions(+), 9 deletions(-)
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [AX25] kernel panic
From: Jarek Poplawski @ 2009-09-20 21:02 UTC (permalink / raw)
To: Bernard Pidoux; +Cc: Ralf Baechle DL5RB, Linux Netdev List, linux-hams
In-Reply-To: <4AB5EAE5.6070605@upmc.fr>
On Sun, Sep 20, 2009 at 10:42:13AM +0200, Bernard Pidoux wrote:
> Hi,
>
> Here are the first events noticed since I turned on
> CONFIG_DEBUG_OBJECTS_TIMERS option.
>
> First a kernel BUG, second a kernel panic.
...
> ------------[ cut here ]------------
> kernel BUG at kernel/timer.c:913!
Alas this BUG doesn't show much (this new debugging didn't trigger
here). Maybe the patch below will be luckier.
Best regards,
Jarek P.
---
include/net/ax25.h | 36 ++++++++++++++++++++++++++++++++++++
net/ax25/af_ax25.c | 3 +++
2 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/include/net/ax25.h b/include/net/ax25.h
index 717e219..e8f6e33 100644
--- a/include/net/ax25.h
+++ b/include/net/ax25.h
@@ -252,9 +252,45 @@ typedef struct ax25_cb {
#define ax25_cb_hold(__ax25) \
atomic_inc(&((__ax25)->refcount))
+static __inline__ int ax25_timers_warn(ax25_cb *ax25)
+{
+ int err = 0;
+
+ if (del_timer(&ax25->timer)) {
+ WARN_ON_ONCE(1);
+ err = 1;
+ }
+ if (del_timer(&ax25->t1timer)) {
+ WARN_ON_ONCE(1);
+ err += 2;
+ }
+ if (del_timer(&ax25->t2timer)) {
+ WARN_ON_ONCE(1);
+ err += 4;
+ }
+ if (del_timer(&ax25->t3timer)) {
+ WARN_ON_ONCE(1);
+ err += 8;
+ }
+ if (del_timer(&ax25->idletimer)) {
+ WARN_ON_ONCE(1);
+ err += 16;
+ }
+ if (del_timer(&ax25->dtimer)) {
+ WARN_ON_ONCE(1);
+ err += 32;
+ }
+ if (err)
+ printk(KERN_WARNING "AX25_DBG: %d %p %u\n", err, ax25,
+ ax25->state);
+
+ return err;
+}
+
static __inline__ void ax25_cb_put(ax25_cb *ax25)
{
if (atomic_dec_and_test(&ax25->refcount)) {
+ ax25_timers_warn(ax25);
kfree(ax25->digipeat);
kfree(ax25);
}
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index da0f64f..f443fe0 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -58,6 +58,9 @@ static const struct proto_ops ax25_proto_ops;
static void ax25_free_sock(struct sock *sk)
{
+ if (ax25_timers_warn(ax25_sk(sk)))
+ printk(KERN_WARNING "AX25_DBG: %p %u %u %u\n", sk,
+ sk->sk_family, sk->sk_type, sk->sk_protocol);
ax25_cb_put(ax25_sk(sk));
}
^ permalink raw reply related
* [PATCH] ipv4: fib table algorithm performance improvement
From: Stephen Hemminger @ 2009-09-20 20:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev
The FIB algorithim for IPV4 is set at compile time, but kernel goes through
the overhead of function call indirection at runtime. Save some
cycles by turning the indirect calls to direct calls to either
hash or trie code.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/include/net/ip_fib.h 2009-09-20 12:16:02.819467348 -0700
+++ b/include/net/ip_fib.h 2009-09-20 12:37:53.391940040 -0700
@@ -144,18 +144,21 @@ struct fib_table {
struct hlist_node tb_hlist;
u32 tb_id;
int tb_default;
- int (*tb_lookup)(struct fib_table *tb, const struct flowi *flp, struct fib_result *res);
- int (*tb_insert)(struct fib_table *, struct fib_config *);
- int (*tb_delete)(struct fib_table *, struct fib_config *);
- int (*tb_dump)(struct fib_table *table, struct sk_buff *skb,
- struct netlink_callback *cb);
- int (*tb_flush)(struct fib_table *table);
- void (*tb_select_default)(struct fib_table *table,
- const struct flowi *flp, struct fib_result *res);
-
unsigned char tb_data[0];
};
+extern int fib_table_lookup(struct fib_table *tb, const struct flowi *flp,
+ struct fib_result *res);
+extern int fib_table_insert(struct fib_table *, struct fib_config *);
+extern int fib_table_delete(struct fib_table *, struct fib_config *);
+extern int fib_table_dump(struct fib_table *table, struct sk_buff *skb,
+ struct netlink_callback *cb);
+extern int fib_table_flush(struct fib_table *table);
+extern void fib_table_select_default(struct fib_table *table,
+ const struct flowi *flp,
+ struct fib_result *res);
+
+
#ifndef CONFIG_IP_MULTIPLE_TABLES
#define TABLE_LOCAL_INDEX 0
@@ -182,11 +185,11 @@ static inline int fib_lookup(struct net
struct fib_table *table;
table = fib_get_table(net, RT_TABLE_LOCAL);
- if (!table->tb_lookup(table, flp, res))
+ if (!fib_table_lookup(table, flp, res))
return 0;
table = fib_get_table(net, RT_TABLE_MAIN);
- if (!table->tb_lookup(table, flp, res))
+ if (!fib_table_lookup(table, flp, res))
return 0;
return -ENETUNREACH;
}
--- a/net/ipv4/fib_frontend.c 2009-09-20 12:23:52.199466411 -0700
+++ b/net/ipv4/fib_frontend.c 2009-09-20 12:26:45.969439904 -0700
@@ -125,7 +125,7 @@ void fib_select_default(struct net *net,
#endif
tb = fib_get_table(net, table);
if (FIB_RES_GW(*res) && FIB_RES_NH(*res).nh_scope == RT_SCOPE_LINK)
- tb->tb_select_default(tb, flp, res);
+ fib_table_select_default(tb, flp, res);
}
static void fib_flush(struct net *net)
@@ -139,7 +139,7 @@ static void fib_flush(struct net *net)
for (h = 0; h < FIB_TABLE_HASHSZ; h++) {
head = &net->ipv4.fib_table_hash[h];
hlist_for_each_entry(tb, node, head, tb_hlist)
- flushed += tb->tb_flush(tb);
+ flushed += fib_table_flush(tb);
}
if (flushed)
@@ -162,7 +162,7 @@ struct net_device * ip_dev_find(struct n
#endif
local_table = fib_get_table(net, RT_TABLE_LOCAL);
- if (!local_table || local_table->tb_lookup(local_table, &fl, &res))
+ if (!local_table || fib_table_lookup(local_table, &fl, &res))
return NULL;
if (res.type != RTN_LOCAL)
goto out;
@@ -200,7 +200,7 @@ static inline unsigned __inet_dev_addr_t
local_table = fib_get_table(net, RT_TABLE_LOCAL);
if (local_table) {
ret = RTN_UNICAST;
- if (!local_table->tb_lookup(local_table, &fl, &res)) {
+ if (!fib_table_lookup(local_table, &fl, &res)) {
if (!dev || dev == res.fi->fib_dev)
ret = res.type;
fib_res_put(&res);
@@ -473,13 +473,13 @@ int ip_rt_ioctl(struct net *net, unsigne
if (cmd == SIOCDELRT) {
tb = fib_get_table(net, cfg.fc_table);
if (tb)
- err = tb->tb_delete(tb, &cfg);
+ err = fib_table_delete(tb, &cfg);
else
err = -ESRCH;
} else {
tb = fib_new_table(net, cfg.fc_table);
if (tb)
- err = tb->tb_insert(tb, &cfg);
+ err = fib_table_insert(tb, &cfg);
else
err = -ENOBUFS;
}
@@ -594,7 +594,7 @@ static int inet_rtm_delroute(struct sk_b
goto errout;
}
- err = tb->tb_delete(tb, &cfg);
+ err = fib_table_delete(tb, &cfg);
errout:
return err;
}
@@ -616,7 +616,7 @@ static int inet_rtm_newroute(struct sk_b
goto errout;
}
- err = tb->tb_insert(tb, &cfg);
+ err = fib_table_insert(tb, &cfg);
errout:
return err;
}
@@ -647,7 +647,7 @@ static int inet_dump_fib(struct sk_buff
if (dumped)
memset(&cb->args[2], 0, sizeof(cb->args) -
2 * sizeof(cb->args[0]));
- if (tb->tb_dump(tb, skb, cb) < 0)
+ if (fib_table_dump(tb, skb, cb) < 0)
goto out;
dumped = 1;
next:
@@ -701,9 +701,9 @@ static void fib_magic(int cmd, int type,
cfg.fc_scope = RT_SCOPE_HOST;
if (cmd == RTM_NEWROUTE)
- tb->tb_insert(tb, &cfg);
+ fib_table_insert(tb, &cfg);
else
- tb->tb_delete(tb, &cfg);
+ fib_table_delete(tb, &cfg);
}
void fib_add_ifaddr(struct in_ifaddr *ifa)
@@ -832,7 +832,7 @@ static void nl_fib_lookup(struct fib_res
local_bh_disable();
frn->tb_id = tb->tb_id;
- frn->err = tb->tb_lookup(tb, &fl, &res);
+ frn->err = fib_table_lookup(tb, &fl, &res);
if (!frn->err) {
frn->prefixlen = res.prefixlen;
@@ -1009,7 +1009,7 @@ static void __net_exit ip_fib_net_exit(s
head = &net->ipv4.fib_table_hash[i];
hlist_for_each_entry_safe(tb, node, tmp, head, tb_hlist) {
hlist_del(node);
- tb->tb_flush(tb);
+ fib_table_flush(tb);
kfree(tb);
}
}
--- a/net/ipv4/fib_rules.c 2009-09-20 12:30:43.159471244 -0700
+++ b/net/ipv4/fib_rules.c 2009-09-20 12:32:08.709470541 -0700
@@ -94,7 +94,7 @@ static int fib4_rule_action(struct fib_r
if ((tbl = fib_get_table(rule->fr_net, rule->table)) == NULL)
goto errout;
- err = tbl->tb_lookup(tbl, flp, (struct fib_result *) arg->result);
+ err = fib_table_lookup(tbl, flp, (struct fib_result *) arg->result);
if (err > 0)
err = -EAGAIN;
errout:
--- a/net/ipv4/fib_trie.c 2009-09-20 12:23:59.409447223 -0700
+++ b/net/ipv4/fib_trie.c 2009-09-20 12:29:45.041693219 -0700
@@ -1174,7 +1174,7 @@ done:
/*
* Caller must hold RTNL.
*/
-static int fn_trie_insert(struct fib_table *tb, struct fib_config *cfg)
+int fib_table_insert(struct fib_table *tb, struct fib_config *cfg)
{
struct trie *t = (struct trie *) tb->tb_data;
struct fib_alias *fa, *new_fa;
@@ -1373,8 +1373,8 @@ static int check_leaf(struct trie *t, st
return 1;
}
-static int fn_trie_lookup(struct fib_table *tb, const struct flowi *flp,
- struct fib_result *res)
+int fib_table_lookup(struct fib_table *tb, const struct flowi *flp,
+ struct fib_result *res)
{
struct trie *t = (struct trie *) tb->tb_data;
int ret;
@@ -1595,7 +1595,7 @@ static void trie_leaf_remove(struct trie
/*
* Caller must hold RTNL.
*/
-static int fn_trie_delete(struct fib_table *tb, struct fib_config *cfg)
+int fib_table_delete(struct fib_table *tb, struct fib_config *cfg)
{
struct trie *t = (struct trie *) tb->tb_data;
u32 key, mask;
@@ -1786,7 +1786,7 @@ static struct leaf *trie_leafindex(struc
/*
* Caller must hold RTNL.
*/
-static int fn_trie_flush(struct fib_table *tb)
+int fib_table_flush(struct fib_table *tb)
{
struct trie *t = (struct trie *) tb->tb_data;
struct leaf *l, *ll = NULL;
@@ -1807,9 +1807,9 @@ static int fn_trie_flush(struct fib_tabl
return found;
}
-static void fn_trie_select_default(struct fib_table *tb,
- const struct flowi *flp,
- struct fib_result *res)
+void fib_table_select_default(struct fib_table *tb,
+ const struct flowi *flp,
+ struct fib_result *res)
{
struct trie *t = (struct trie *) tb->tb_data;
int order, last_idx;
@@ -1952,8 +1952,8 @@ static int fn_trie_dump_leaf(struct leaf
return skb->len;
}
-static int fn_trie_dump(struct fib_table *tb, struct sk_buff *skb,
- struct netlink_callback *cb)
+int fib_table_dump(struct fib_table *tb, struct sk_buff *skb,
+ struct netlink_callback *cb)
{
struct leaf *l;
struct trie *t = (struct trie *) tb->tb_data;
@@ -2020,12 +2020,6 @@ struct fib_table *fib_hash_table(u32 id)
tb->tb_id = id;
tb->tb_default = -1;
- tb->tb_lookup = fn_trie_lookup;
- tb->tb_insert = fn_trie_insert;
- tb->tb_delete = fn_trie_delete;
- tb->tb_flush = fn_trie_flush;
- tb->tb_select_default = fn_trie_select_default;
- tb->tb_dump = fn_trie_dump;
t = (struct trie *) tb->tb_data;
memset(t, 0, sizeof(*t));
--- a/net/ipv4/fib_hash.c 2009-09-20 12:23:55.799439103 -0700
+++ b/net/ipv4/fib_hash.c 2009-09-20 12:46:25.700353394 -0700
@@ -242,8 +242,8 @@ fn_new_zone(struct fn_hash *table, int z
return fz;
}
-static int
-fn_hash_lookup(struct fib_table *tb, const struct flowi *flp, struct fib_result *res)
+int fib_table_lookup(struct fib_table *tb,
+ const struct flowi *flp, struct fib_result *res)
{
int err;
struct fn_zone *fz;
@@ -274,8 +274,8 @@ out:
return err;
}
-static void
-fn_hash_select_default(struct fib_table *tb, const struct flowi *flp, struct fib_result *res)
+void fib_table_select_default(struct fib_table *tb,
+ const struct flowi *flp, struct fib_result *res)
{
int order, last_idx;
struct hlist_node *node;
@@ -366,7 +366,7 @@ static struct fib_node *fib_find_node(st
return NULL;
}
-static int fn_hash_insert(struct fib_table *tb, struct fib_config *cfg)
+int fib_table_insert(struct fib_table *tb, struct fib_config *cfg)
{
struct fn_hash *table = (struct fn_hash *) tb->tb_data;
struct fib_node *new_f = NULL;
@@ -544,8 +544,7 @@ out:
return err;
}
-
-static int fn_hash_delete(struct fib_table *tb, struct fib_config *cfg)
+int fib_table_delete(struct fib_table *tb, struct fib_config *cfg)
{
struct fn_hash *table = (struct fn_hash *)tb->tb_data;
struct fib_node *f;
@@ -662,7 +661,7 @@ static int fn_flush_list(struct fn_zone
return found;
}
-static int fn_hash_flush(struct fib_table *tb)
+int fib_table_flush(struct fib_table *tb)
{
struct fn_hash *table = (struct fn_hash *) tb->tb_data;
struct fn_zone *fz;
@@ -743,7 +742,8 @@ fn_hash_dump_zone(struct sk_buff *skb, s
return skb->len;
}
-static int fn_hash_dump(struct fib_table *tb, struct sk_buff *skb, struct netlink_callback *cb)
+int fib_table_dump(struct fib_table *tb, struct sk_buff *skb,
+ struct netlink_callback *cb)
{
int m, s_m;
struct fn_zone *fz;
@@ -787,12 +787,7 @@ struct fib_table *fib_hash_table(u32 id)
tb->tb_id = id;
tb->tb_default = -1;
- tb->tb_lookup = fn_hash_lookup;
- tb->tb_insert = fn_hash_insert;
- tb->tb_delete = fn_hash_delete;
- tb->tb_flush = fn_hash_flush;
- tb->tb_select_default = fn_hash_select_default;
- tb->tb_dump = fn_hash_dump;
+
memset(tb->tb_data, 0, sizeof(struct fn_hash));
return tb;
}
^ permalink raw reply
* Re: SO_TIMESTAMPING fix and design decisions
From: Christopher Zimmermann @ 2009-09-20 18:50 UTC (permalink / raw)
To: netdev
In-Reply-To: <1253468893.2654.6.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]
On Sun, 20 Sep 2009 10:48:13 -0700
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> wrote:
> On Sun, 2009-09-20 at 00:52 -0700, Christopher Zimmermann wrote:
> > On Sat, 19 Sep 2009 15:09:21 -0700
> > Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> wrote:
> >
> > > > hardware timestamps only work for the Intel igb driver. I have
> > > > access to two test machines with NICs supported by this driver.
> > >
> > > Intel's 82599, supported by ixgbe, also has the same IEEE 1588
> > > timestamping support in hardware. We haven't implemented the support
> > > yet in ixgbe, but the hardware is there and does work. If you were
> > > curious of the interface, the datasheet for the hardware is available on
> > > our SourceForge site (e1000.sf.net).
> >
> > hi! thanks for the reply.
> >
> > I already got the documentation for the 82576 cards I have access to. I
> > won't be able to afford another pair.
> >
> > What do you think about my idea to expose the relevant registers to
> > userspace? I believe it would not be too difficult for userspace to
> > configure the timestamps this way and would allow way more flexibility.
> > Of course I would #DEFINE the constants used to set the registers.
>
> The patch seems reasonable, but I haven't played with the igb
> timestamping very much. However, what impact will this have on the
> existing ptpd userspace daemon?
It will need to be modified. If you want to avoid this, one could keep
the HWTSTAMP_FILTER_PTP_.... defines and just redifine them to reflect
the new interface.
Where can I find this ptpd userspace daemon, which supports hardware
timestamps using the ioctl interface? ptpd.sourceforge.net doesn't.
Cheers,
Christopher Zimmermann
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH net-next-2.6] bonding: remove useless assignment
From: Nicolas de Pesloüan @ 2009-09-20 18:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Jay Vosburgh, bonding-devel
The variable old_active is first set to bond->curr_active_slave.
Then, it is unconditionally set to new_active, without being used in between.
The first assignment, having no side effect, is useless.
Signed-off-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
---
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index a7e731f..fce7233 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1084,7 +1084,7 @@ static struct slave *bond_find_best_slave(struct bonding *bond)
int mintime = bond->params.updelay;
int i;
- new_active = old_active = bond->curr_active_slave;
+ new_active = bond->curr_active_slave;
if (!new_active) { /* there were no active slaves left */
if (bond->slave_cnt > 0) /* found one slave */
^ permalink raw reply related
* Re: sky2 rx length errors
From: Stephen Hemminger @ 2009-09-20 18:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: Grozdan, linux-kernel, Stephen Hemminger, netdev
In-Reply-To: <20090919233536.f5fb700c.akpm@linux-foundation.org>
On Sat, 19 Sep 2009 23:35:36 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> (added cc's from the MAINTAINERS file)
>
> On Fri, 18 Sep 2009 15:41:45 +0200 Grozdan <neutrino8@gmail.com> wrote:
>
> > Hi,
> >
> > I have a Marvell onboard NIC (88E8053) and I've been noticing for a
> > while now a bit weird behavior with the sky2 driver. This mostly
> > occurs with newer kernels (2.6.30, 2.6.31) and my older distro kernel
> > (2.6.27.21) does not seem to have the same problem. Basically, the
> > sky2 driver will randomly and unpredictably spew rx length error
> > messages and reboot itself. I also noticed in dmesg that this mostly
> > occurs after "martian destination" messages. After this message, sky2
> > starts spewing messages as shown below and then reboots itself. It is
> > not really a big problem for me, but since I'm virtually always logged
> > in in IRC, the client always loses connection, waits for a few minutes
> > to get a response from the server and then relogs me again. I do not
> > think it's a HW problem as the Marvell NIC otherwise works perfectly
> > and I've checked my cable modem too which operates without a problem.
> > Any ideas?
> >
> > PS: please cc me as I'm not subscribed to the mailing list
> >
> > sky2 driver version 1.23
> > sky2 0000:05:00.0: PCI INT A -> GSI 36 (level, low) -> IRQ 36
> > sky2 0000:05:00.0: setting latency timer to 64
> > sky2 0000:05:00.0: PCI: Disallowing DAC for device
> > sky2 0000:05:00.0: Yukon-2 EC chip revision 2
> > sky2 0000:05:00.0: irq 53 for MSI/MSI-X
> > sky2 0000:05:00.0: No interrupt generated using MSI, switching to INTx mode.
> > sky2 eth0: addr 00:11:d8:a1:5b:0e
> > sky2 eth0: enabling interface
> > sky2 eth0: Link is up at 100 Mbps, full duplex, flow control rx
> > .....
> > .....
> > martian destination 0.0.0.0 from 172.23.204.1, dev eth0
> > sky2 eth0: rx length error: status 0x4420100 length 598
> > sky2 eth0: rx length error: status 0x5ea0100 length 598
This error status occurs if the length reported by the PHY does not
match the len reported by the DMA engine. The error status is:
0x4420100 = length 1090 + broadcast packet...
No idea what is on your network, but perhaps there is some MTU confusion?
Since martian destination seems related, knowing more about that packet
might help.
^ permalink raw reply
* Re: SO_TIMESTAMPING fix and design decisions
From: Peter P Waskiewicz Jr @ 2009-09-20 17:48 UTC (permalink / raw)
To: Christopher Zimmermann; +Cc: netdev@vger.kernel.org
In-Reply-To: <20090920095242.5cd42f1a@pundit>
On Sun, 2009-09-20 at 00:52 -0700, Christopher Zimmermann wrote:
> On Sat, 19 Sep 2009 15:09:21 -0700
> Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> wrote:
>
> > > hardware timestamps only work for the Intel igb driver. I have
> > > access to two test machines with NICs supported by this driver.
> >
> > Intel's 82599, supported by ixgbe, also has the same IEEE 1588
> > timestamping support in hardware. We haven't implemented the support
> > yet in ixgbe, but the hardware is there and does work. If you were
> > curious of the interface, the datasheet for the hardware is available on
> > our SourceForge site (e1000.sf.net).
>
> hi! thanks for the reply.
>
> I already got the documentation for the 82576 cards I have access to. I
> won't be able to afford another pair.
>
> What do you think about my idea to expose the relevant registers to
> userspace? I believe it would not be too difficult for userspace to
> configure the timestamps this way and would allow way more flexibility.
> Of course I would #DEFINE the constants used to set the registers.
The patch seems reasonable, but I haven't played with the igb
timestamping very much. However, what impact will this have on the
existing ptpd userspace daemon?
-PJ
^ permalink raw reply
* Re: [PATCH] atm: dereference of he_dev->rbps_virt in he_init_group()
From: Roel Kluin @ 2009-09-20 17:11 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, chas, linux-atm-general, netdev, akpm
In-Reply-To: <1253384847.2638.4.camel@Joe-Laptop.home>
he_dev->rbps_virt or he_dev->rbpl_virt allocation may fail, s
them. Make sure that he_init_group() cleans up after errors.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
> It looks as if it'd be clearer to not use variable ret and
> simply return -ENOMEM after the out_destroy_rbps_pool label.
Ok, thanks.
Again build, sparse and checkpatch tested.
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index 2de6406..29e66d6 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -790,11 +790,15 @@ he_init_group(struct he_dev *he_dev, int group)
he_dev->rbps_base = pci_alloc_consistent(he_dev->pci_dev,
CONFIG_RBPS_SIZE * sizeof(struct he_rbp), &he_dev->rbps_phys);
if (he_dev->rbps_base == NULL) {
- hprintk("failed to alloc rbps\n");
- return -ENOMEM;
+ hprintk("failed to alloc rbps_base\n");
+ goto out_destroy_rbps_pool;
}
memset(he_dev->rbps_base, 0, CONFIG_RBPS_SIZE * sizeof(struct he_rbp));
he_dev->rbps_virt = kmalloc(CONFIG_RBPS_SIZE * sizeof(struct he_virt), GFP_KERNEL);
+ if (he_dev->rbps_virt == NULL) {
+ hprintk("failed to alloc rbps_virt\n");
+ goto out_free_rbps_base;
+ }
for (i = 0; i < CONFIG_RBPS_SIZE; ++i) {
dma_addr_t dma_handle;
@@ -802,7 +806,7 @@ he_init_group(struct he_dev *he_dev, int group)
cpuaddr = pci_pool_alloc(he_dev->rbps_pool, GFP_KERNEL|GFP_DMA, &dma_handle);
if (cpuaddr == NULL)
- return -ENOMEM;
+ goto out_free_rbps_virt;
he_dev->rbps_virt[i].virt = cpuaddr;
he_dev->rbps_base[i].status = RBP_LOANED | RBP_SMALLBUF | (i << RBP_INDEX_OFF);
@@ -827,17 +831,21 @@ he_init_group(struct he_dev *he_dev, int group)
CONFIG_RBPL_BUFSIZE, 8, 0);
if (he_dev->rbpl_pool == NULL) {
hprintk("unable to create rbpl pool\n");
- return -ENOMEM;
+ goto out_free_rbps_virt;
}
he_dev->rbpl_base = pci_alloc_consistent(he_dev->pci_dev,
CONFIG_RBPL_SIZE * sizeof(struct he_rbp), &he_dev->rbpl_phys);
if (he_dev->rbpl_base == NULL) {
- hprintk("failed to alloc rbpl\n");
- return -ENOMEM;
+ hprintk("failed to alloc rbpl_base\n");
+ goto out_destroy_rbpl_pool;
}
memset(he_dev->rbpl_base, 0, CONFIG_RBPL_SIZE * sizeof(struct he_rbp));
he_dev->rbpl_virt = kmalloc(CONFIG_RBPL_SIZE * sizeof(struct he_virt), GFP_KERNEL);
+ if (he_dev->rbpl_virt == NULL) {
+ hprintk("failed to alloc rbpl_virt\n");
+ goto out_free_rbpl_base;
+ }
for (i = 0; i < CONFIG_RBPL_SIZE; ++i) {
dma_addr_t dma_handle;
@@ -845,7 +853,7 @@ he_init_group(struct he_dev *he_dev, int group)
cpuaddr = pci_pool_alloc(he_dev->rbpl_pool, GFP_KERNEL|GFP_DMA, &dma_handle);
if (cpuaddr == NULL)
- return -ENOMEM;
+ goto out_free_rbpl_virt;
he_dev->rbpl_virt[i].virt = cpuaddr;
he_dev->rbpl_base[i].status = RBP_LOANED | (i << RBP_INDEX_OFF);
@@ -870,7 +878,7 @@ he_init_group(struct he_dev *he_dev, int group)
CONFIG_RBRQ_SIZE * sizeof(struct he_rbrq), &he_dev->rbrq_phys);
if (he_dev->rbrq_base == NULL) {
hprintk("failed to allocate rbrq\n");
- return -ENOMEM;
+ goto out_free_rbpl_virt;
}
memset(he_dev->rbrq_base, 0, CONFIG_RBRQ_SIZE * sizeof(struct he_rbrq));
@@ -894,7 +902,7 @@ he_init_group(struct he_dev *he_dev, int group)
CONFIG_TBRQ_SIZE * sizeof(struct he_tbrq), &he_dev->tbrq_phys);
if (he_dev->tbrq_base == NULL) {
hprintk("failed to allocate tbrq\n");
- return -ENOMEM;
+ goto out_free_rbpq_base;
}
memset(he_dev->tbrq_base, 0, CONFIG_TBRQ_SIZE * sizeof(struct he_tbrq));
@@ -906,6 +914,39 @@ he_init_group(struct he_dev *he_dev, int group)
he_writel(he_dev, CONFIG_TBRQ_THRESH, G0_TBRQ_THRESH + (group * 16));
return 0;
+
+out_free_rbpq_base:
+ pci_free_consistent(he_dev->pci_dev, CONFIG_RBRQ_SIZE *
+ sizeof(struct he_rbrq), he_dev->rbrq_base,
+ he_dev->rbrq_phys);
+ i = CONFIG_RBPL_SIZE;
+out_free_rbpl_virt:
+ while (--i)
+ pci_pool_free(he_dev->rbps_pool, he_dev->rbpl_virt[i].virt,
+ he_dev->rbps_base[i].phys);
+ kfree(he_dev->rbpl_virt);
+
+out_free_rbpl_base:
+ pci_free_consistent(he_dev->pci_dev, CONFIG_RBPL_SIZE *
+ sizeof(struct he_rbp), he_dev->rbpl_base,
+ he_dev->rbpl_phys);
+out_destroy_rbpl_pool:
+ pci_pool_destroy(he_dev->rbpl_pool);
+
+ i = CONFIG_RBPL_SIZE;
+out_free_rbps_virt:
+ while (--i)
+ pci_pool_free(he_dev->rbpl_pool, he_dev->rbps_virt[i].virt,
+ he_dev->rbpl_base[i].phys);
+ kfree(he_dev->rbps_virt);
+
+out_free_rbps_base:
+ pci_free_consistent(he_dev->pci_dev, CONFIG_RBPS_SIZE *
+ sizeof(struct he_rbp), he_dev->rbps_base,
+ he_dev->rbps_phys);
+out_destroy_rbps_pool:
+ pci_pool_destroy(he_dev->rbps_pool);
+ return -ENOMEM;
}
static int __devinit
^ permalink raw reply related
* [PATCH] ax25: Fix SIOCAX25GETINFO ioctl
From: Eric Dumazet @ 2009-09-20 16:32 UTC (permalink / raw)
To: Jan Rafaj, David S. Miller; +Cc: Linux Netdev List
In-Reply-To: <alpine.LNX.2.00.0909201226001.29572@cedric.unob.cz>
Jan Rafaj a écrit :
>
> Hello Eric,
>
> Your commit 31e6d363abcd0d05766c82f1a9c905a4c974a199 introduces (among
> other things):
>
> diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
> index 61b35b9..da0f64f 100644
> --- a/net/ax25/af_ax25.c
> +++ b/net/ax25/af_ax25.c
> @@ -1780,8 +1781,8 @@ static int ax25_ioctl(struct socket *sock,
> unsigned int cmd, unsigned long arg)
> ax25_info.idletimer =
> ax25_display_timer(&ax25->idletimer) / (60 * HZ);
> ax25_info.n2count = ax25->n2count;
> ax25_info.state = ax25->state;
> - ax25_info.rcv_q = atomic_read(&sk->sk_rmem_alloc);
> - ax25_info.snd_q = atomic_read(&sk->sk_wmem_alloc);
> + ax25_info.rcv_q = sk_wmem_alloc_get(sk);
> + ax25_info.snd_q = sk_rmem_alloc_get(sk);
> ax25_info.vs = ax25->vs;
> ax25_info.vr = ax25->vr;
> ax25_info.va = ax25->va;
>
> I believe there is a typo, correctly this should be:
>
> ax25_info.idletimer = ax25_display_timer(&ax25->idletimer)
> / (60 * HZ);
> ax25_info.n2count = ax25->n2count;
> ax25_info.state = ax25->state;
> - ax25_info.rcv_q = atomic_read(&sk->sk_rmem_alloc);
> - ax25_info.snd_q = atomic_read(&sk->sk_wmem_alloc);
> + ax25_info.rcv_q = sk_rmem_alloc_get(sk);
> + ax25_info.snd_q = sk_wmem_alloc_get(sk);
> ax25_info.vs = ax25->vs;
> ax25_info.vr = ax25->vr;
> ax25_info.va = ax25->va;
>
> If this is not fixed in the master, then fix, please.
>
> Being a total kernel newbie, I've checked it against Greg K-H's 2.6.31.y
> git tree (but I'm quite unsure whether this is the real HEAD of
> latest [most up to date] development master branch), so if you know where
> I should be looking instead, I'll be grateful for any kicking into the
> right direction... (I somehow feel this should probably be the main
> Linus's syndication tree linux/kernel/git/torvalds/linux-2.6.git - feel
> free to correct me on this one please).
>
> Thanks,
>
> Jan
>
> ---
> Jan Rafaj
> University of Defence in Brno
>
Oops, Jan you are absolutely right, this part of the patch was wrong.
Dont worry, David will push your patch to netdev tree, then to Linus.
Thanks
[PATCH] ax25: Fix SIOCAX25GETINFO ioctl
rcv_q & snd_q initializations were reversed in commit
31e6d363abcd0d05766c82f1a9c905a4c974a199
(net: correct off-by-one write allocations reports)
Signed-off-by: Jan Rafaj <jr+netfilter-devel@cedric.unob.cz>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index da0f64f..d6b1b05 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -1781,8 +1781,8 @@ static int ax25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
ax25_info.idletimer = ax25_display_timer(&ax25->idletimer) / (60 * HZ);
ax25_info.n2count = ax25->n2count;
ax25_info.state = ax25->state;
- ax25_info.rcv_q = sk_wmem_alloc_get(sk);
- ax25_info.snd_q = sk_rmem_alloc_get(sk);
+ ax25_info.rcv_q = sk_rmem_alloc_get(sk);
+ ax25_info.snd_q = sk_wmem_alloc_get(sk);
ax25_info.vs = ax25->vs;
ax25_info.vr = ax25->vr;
ax25_info.va = ax25->va;
^ permalink raw reply related
* Re: [PATCH 1/2] pktgen: check for link down
From: Jesper Dangaard Brouer @ 2009-09-20 15:26 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller, Robert Olsson, Jesper Dangaard Brouer, netdev
In-Reply-To: <20090919221844.114e2e23@nehalam>
Thanks for fixing this.
Acked-by: Jesper Dangaard Brouer <hawk@comx.dk>
On Sat, 19 Sep 2009, Stephen Hemminger wrote:
> If cable is pulled, pktgen shouldn't continue slamming packets into the
> device.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> --- a/net/core/pktgen.c 2009-09-19 11:20:55.546463176 -0700
> +++ b/net/core/pktgen.c 2009-09-19 11:22:44.810509240 -0700
> @@ -1959,7 +1959,7 @@ static int pktgen_setup_dev(struct pktge
> if (odev->type != ARPHRD_ETHER) {
> printk(KERN_ERR "pktgen: not an ethernet device: \"%s\"\n", ifname);
> err = -EINVAL;
> - } else if (!netif_running(odev)) {
> + } else if (!netif_running(odev) || !netif_carrier_ok(odev)) {
> printk(KERN_ERR "pktgen: device is down: \"%s\"\n", ifname);
> err = -ENETDOWN;
> } else {
> @@ -3410,7 +3410,7 @@ static void pktgen_xmit(struct pktgen_de
> /* Did we saturate the queue already? */
> if (netif_tx_queue_stopped(txq) || netif_tx_queue_frozen(txq)) {
> /* If device is down, then all queues are permnantly frozen */
> - if (netif_running(odev))
> + if (netif_running(odev) && netif_carrier_ok(odev))
> idle(pkt_dev);
> else
> pktgen_stop_device(pkt_dev);
Hilsen
Jesper Brouer
--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
^ permalink raw reply
* Re: [iproute2] tc action mirred question
From: jamal @ 2009-09-20 13:33 UTC (permalink / raw)
To: Xiaofei Wu; +Cc: linux netdev
In-Reply-To: <908876.76571.qm@web111609.mail.gq1.yahoo.com>
On Sun, 2009-09-20 at 02:58 -0700, Xiaofei Wu wrote:
> When the link A-B is not available,
How do you detect this? Is it a path that is broken or a link?
> Could iproute2 'tc' do this?
you could use iproute2 'ip' which supports multi-nexthops, example
off top of my head (for exact syntax run "ip route help")
----
ip route add blah/24 nexthop via a.b.c.d dev wlan0 \
nexthop via e.f.g.h dev wlan1
----
You will probably need to help it by flushing route cache.
You may need to worry about loops on mirroring when the route flipping
happens and need to optimize for that. Please experiment.
cheers,
jamal
^ permalink raw reply
* Pozyskaj nowych klientów, zwieksz przychody, obniż koszty [Paweł Boratyński]
From: pb3 @ 2009-09-20 11:55 UTC (permalink / raw)
To: netdev
Witam,
reprezentuję firmę JSystems (www.jsystems.pl). Nasza firma stworzyła profesjonalny informatyczny system marketingowy, automatyzujący proces poszukiwania nowych klientów i jednocześnie znacznie obniżający koszty tego procesu. Czy mogę Państwu przesłać ofertę dotyczącą tego produktu?
Pozdrawiam
Sales Representative
Paweł Boratyński
22 405 38 45
^ permalink raw reply
* Re: [iproute2] tc action mirred question
From: Xiaofei Wu @ 2009-09-20 9:58 UTC (permalink / raw)
To: hadi; +Cc: linux netdev
In-Reply-To: <1253104099.4584.9.camel@dogo.mojatatu.com>
Hi,
I come across another problem.
network topology:
M
|
A
/ \
B D
\ /
C
node M < ---- > node C
common path: M-A-B-C
the other path: M-A-D-C
With your help I can mirror the outgoing packets(node A wlan0) to wlan1(node A), then transmit it to D. D will route them to C.
There will be another problem.
When the link A-B is not available, there is no packect going out to mirror, node M could not get to node C. (if B is broken, A use ARP to ask the MAC of B's IP addr, but no reply)
So I want to forward the incoming packets( node M -> A(eth0) ) to wlan0(node A) and wlan1(node A) at the same time, route them separately. In this case, if one path is unavailable, it will not influence the other path.
Could iproute2 'tc' do this?
regards,
wu
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ 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